![見出し画像](https://assets.st-note.com/production/uploads/images/19071745/rectangle_large_type_2_72060d1d81c1d20f07a15c4bc560c907.jpeg?width=1200)
WEB操作をAPI化するという事(その前に)
村井@C-RISEです。
前回の記事で、「クラウドBOT®︎」はWEB操作をAPI化するという記事を書きました。その辺りを少しずつ掘り下げて書いていきたいと思います。
まずは、iPaaSとRPAについて
API化の話の前に、iPaaSとRPA等の用語について簡単に整理してみたいと思って書き始めたのですが、記事の大半がこの内容になってしまったのでタイトルに(その前に)を追記しました。記事の構成力が低くてすみません。
私自身、iPaaSやRPAという言葉を漠然と使っていましたが、私が普段これらの言葉を使う時は、
・iPaaS :複数のサービス(SaaS)をAPIで統合するIFTTT、Zapier的なサービス
・RPA :人間が行う画面操作をロボットで自動化する仕組み
といったイメージで考えていました。
他の方の記事でも、「画面操作のRPA」「API連携のiPaaS」という意味合いで対比されているケースが多いように感じました。
でも、これから記事を書いていく上で曖昧な認識のままだと色々混乱すると思ったので、それぞれについて調べてみました。
■ iPaaS(integration Platform-as-a-Service)とは
直訳すると「サービスとしての統合プラットフォーム」です。
以下Google検索で「iPaaSとは」で調べてみたトップ3のサイトです。
第1位のサイト「ipswitch」は、ガートナーが定義する
個々の組織内または複数の組織内のオンプレミスとクラウドベースのプロセス、サービス、アプリケーション、およびデータの任意の組み合わせを結び付ける統合フローの開発、実行および管理を可能にする一連のクラウドサービス
という長い定義と、MuleSoftがわかりやすく言い換えたものとして
iPaaS はクラウド内およびクラウドと企業間の統合を構築し展開するためのプラットフォームです。
という説明を紹介しています。こではAPIについては一切触れられておらず、最後に「iPaaS 市場は比較的新しいため、機能提供する標準的な方法はまだ確立されていません。」と、2019年1月時点ではまだiPaaSの標準的なモデルは確立されてないと言ってます。
第2位のサイト「SaaSサーチ」では、iPaaSを
異なるアプリケーション同士をつなげ、データを統合したりシステムを連携させたりすることができるクラウドサービスです。
と説明しており、
iPaaSで可能となるのは、オンプレミスのシステムとSaaSのシステムの連携、さらに、SaaSのシステムと別のSaaSのシステムなどクラウド同士でのシステム連携です。
と連携先にはSaaSサービスだけではなくオンプレミスも含めると説明しています。ここで主要サービスとして「Workato」と「MuleSoft」、「Boomi」を紹介していますが、MuleSoftの説明において
対応しているアプリケーションやデータ、デバイス接続のためのAPIの作成、接続、実装、管理を包括的に行ってくれます。
と、デバイスも接続対象に含めている事がわかります。さらに、アプリやデバイスが提供しているAPIやコネクタ機能を再利用して、一元管理できるようにするという事から、iPaaS上で既存APIを再利用して新たなAPIを作成する事ができるという事のようです。このあたりはクラウドBOT®の考え方に近いなと思いました。
そして、第3位のサイト「HubSpot」では、
クラウドやオンプレミスのサービス内のさまざまなアプリケーション、システム、テクノロジーを連携する、クラウドベースのプラットフォーム
と説明されており、さらにiPaaSの仕組みとして
API(Application Programming Interface)や構築済みのコネクターの形式を取る場合もあれば、他の形式のルールになる場合もあります
と、APIに限らず様々な形式で連携する場合もあるとの事でした。
尚、私がiPaaSサービスとしてイメージしていたIFTTTは上位3件では紹介されておらず、Zapierについては第3位のHubSpotでのみ紹介されていました。
■ RPA(Robotic Process Automation)とは
直訳すると、ロボットによる工程の自動化ですね。
こちらも「RPAとは」でGoogle検索してみました。
こちらは、認識ずれもあまり無さそうなので簡単に列記します。
第1位のサイト「ビジネス+IT」では、
事務作業を担うホワイトワーカーがPCなどを用いて行っている一連の作業を自動化できる「ソフトウェアロボット」のことである
としています。
ここで挙げられている特徴は下記の通り、
【長所】
・正確に作業を実施できる
・人間に比べ、作業スピードが圧倒的に速い
・24時間365日、休まず働き続けることができる
【短所】
・アクシデントや例外処理に弱い。遭遇した際には、作業が止まる
・あらかじめ命令されたことしかできない(判断できない)
・複雑なことを実施させるためには、タスク分解された多工程の命令を与えなければならない
やはり定形作業を得意とするデジタルレイバーという認識ですね。
第2位は「NTT Data」のWinactorのサイトですね。
Winactorは国内シェアNo1らしいです。
ホワイトカラーのデスクワーク(主に定型作業)を、ルールエンジンやAI(人工知能)などの技術を備えたソフトウェアのロボットが代行・自動化する概念、と定義されています。
という記載だったので、どこで定義されてるのかなと思ったら「※RPA BANK調べ」だそうです。
RPAは定形作業が得意としつつも、AIの採用が進んでいるのは判断能力もRPAに持たせていこうという流れなんでしょうね。
そして第3位のサイト「LISKUL」です。
ここでは、
バックオフィス業務などをはじめとするホワイトカラー業務をソフトウェアに組み込まれたロボットが代行する取り組み、およびその概念を指します。
と説明されていて上位3件ともほぼ同じ説明でした。
iPaaSか?RPAか?DPAか?
こうして調べてみるとiPaaSとRPAは対照的な仕組みでもなく、広い意味で効率的な仕組みをつくるという点では共通する部分もあるが、基本的に
iPaaSは、「複数のシステムを統合するプラットフォームサービス」であり、
RPAは、「ロボットが人間の作業を代行して自動化する事」という様にそれぞれ独立した概念なんですね。
昨年、Microsoft flowがRPA的な自動操作機能に対応してPower Automateになりました。これは、MicrosoftがRPAサービスを提供したというより、iPaaSサービスの連携方法の一つとして自動操作に対応した訳です。
このようにiPaaSとRPAは今後融合していく事も十分考えられます。
では、RPAの画面自動操作に対して、API連携で自動化する事を何と言うのかを調べてみるとDPAと言うそうです。
DPAはデジタル・プロセス・オートメーションの略ですが、Power AutomateはAPI連携のDPAと、画面操作のRPAの両方に対応したiPaaSと言える訳ですね。
これをクラウドBOT®に当てはめると、DPAのA-BOTと、RPAのB-BOTをつなげるiPaaSのC-BOTとなると思います。
尚、DPAは別の意味としてデスクトップ・プロセス・オートメーションの略として使われる場合もあるそうなので注意が必要です。
WEB操作をAPI化するという事
ここまで記事タイトルと全く関係の無さそうな用語の定義について調べてきた訳ですが、なぜ長々とRPAやiPaaSの定義について書いてきたかと言うと、今クラウドBOT®が実現しようとしているサービスの位置付けを確認するという意味が大きいです。
もともとクラウドBOT®を構想した時には、世の中のRPAやiPaaSの製品郡を調査して使ってみて、それらを超える仕組みを作ろうと考えた訳ではなく、自分たちが直面した課題を世の中に一般に拡大して考えた時に「こんな仕組みがあったらいいよね」という思いから始まりました。
その一つがWEB操作をAPI化するという事でした。
なので、ここで一旦「クラウドBOT®」をiPaaSやRPA、DPA、BPA、IPA…等色々な自動化関連の用語に当てはめた時、一体どこに位置付けられるのか、もしくはどの用語にも当てはまらない事なのかを整理して、それからクラウドBOT®の仕組みについて語りたいなと思ったのです。
今回、上記に書いた以外にも色々調べていく中で、クラウドBOT®の仕組みに近いなと思ったサービスがPower Automateでした。クラウドBOT®のWEB操作をAPI化するという機能(B-BOT)は、Power AutomateのRPA機能に近い役割になるのだと思います。
Power AutomateはDPA→RPAの順に対応したiPaaSですが、クラウドBOT®はRPA→DPAの順に対応を予定しています。(※現状はRPA機能のみを提供しています。)
私自身、Power Automateを触っていないのであまり深くは語れないのですが、Power AutomateのRPA機能はWeb操作とデスクトップ操作に対応しているのに対してクラウドBOT®はWEB操作のみに特化しています。
Poewr AutomateのRPA機能がAPIとしても機能するのか私は知らないのですが、そのような記述は見当たりませんでした。上記に書いたようにサービスの構成としては近さを感じますが、ライセンス体系や使われ方等を見ていくと、やはりコンセプトは異なるのと感じました。
少し長くなったので一旦終わりたいと思いますが、WEB操作のAPI化についてはもう少し色々書きたい事があるので、また改めて記事を書きたいと思います。
ここまで読んでいただきありがとうございました。
この記事が気に入ったらサポートをしてみませんか?