Edited at

RPAとiPaaSはどう使い分ける?組み合わせる?

ここ2~3年もてはやされているRPAであるが、いくつかのプロジェクトを見てきた経験でいうと、決して「魔法の杖」などではなく適用する業務と状況、体制を考えたうえで臨まないと、後で大きなコストを払うことになることは『RPAに適した業務、適さない業務』や『RPAの失敗事例よくある話とその対策』で述べた。自動化できそうな提携業務を選び、業務整理をしたうえで自動化するかどうかを決めるといった手順が重要である。

その際、業務の汎用性によって以下のようなレベルを定義して、それぞれのレベルで適切なソリューションを使用したほうがいいことも述べた。

業務汎用性
プレイヤーと提供/作業内容

レベル3

パッケージベンダー
パッケージソフトウェアとAPIの提供

レベル2

SIer
システム間連携 (APIの呼び出しプログラム)の構築

レベル1

業務の現場メンバー
(1) iPaaS, RPA
(2) 手作業の外注
(3) 従業員による手作業

この中で業務汎用性が低い「レベル1」で業務の現場メンバーによって自動化するか外注するかで仕分けする部分に「RPA」を位置づけているわけだが、同時に「iPaaS」も記載している。このiPaaSとは何か、RPAと何が違ってどう使い分ければいいのかについて考えてみたいと思う。


"iPaaS" とは何か?

"Integration Platform as a Service"の略で、クラウド統合プラットフォームとも呼ばれる。ガートナーが2011年に行っている提言1によれば、定義は「個々の組織内または複数の組織間におけるオンプレミス型およびクラウド・ベースのプロセス、サービス、アプリケーション、データのあらゆる組み合わせを接続する統合フローの開発、実行、ガバナンスを可能にするクラウド・サービスのスイート」とのことです。もう少し簡単にいうと、「クラウドサービス(やオンプレミス)のシステム同士を接続・統合するクラウドサービス」ということになる。2011年にはこの単語が存在していたので、RPAと比べても古い概念であることがわかる。


システム統合は古くからある概念、ただしクラウドの統合が新しい

昔からSIerに所属している諸君であれば、「システム統合」「アプリケーション統合」という単語は昔から聞きなれている単語であろう。SOA (サービス指向アーキテクチャ, Service-Oriented Architecture) 、EDI (電子データ交換, Electronic Data Interchange)、EAI (企業内アプリケーション統合, Enterprise Application Integration)、ETL (抽出/変換/読み込み, Extract/Transform/Load)、ESB (エンタープライズ・サービス・バス, Enterprise service bus)といった関連するバズワードもなじみの深いものが多いと思う。実装としてはミドルウェアを用意したり、バッチ処理でつないだりしてデータを変換/交換する仕組みを作るという、まさにSIという仕事の中核のひとつである。

それではiPaaSは何が違うかというと、SaaSに代表されるクラウドサービスが企業にかなり普及してきたために、クラウドサービス同士でデータ変換/交換のニーズが高まってきたことにより、クラウド上に「システム統合」「アプリケーション統合」を行ってくれるサービスが必要になってきたということである。つまり、いままであった概念のクラウド版ということになる。また、後で述べるが、SIerだけでなく業務の現場でも扱えるような、クラウドならではのお手軽なユーザーインターフェイスが伴っているサービスも存在することも挙げられる。


iPaaSはどういうところが優れているのか~RPAの弱点を補うiPaaS

それでは、「記録したタスクをGUI上で直接繰り返すことで自動化を実行し、APIを備えていない製品で自動化を使用する際の障壁を低くすることができる」RPAと、iPaaSは何が違うのか、どう使い分ければいいのかについて見ていこう。


iPaaSはAPI連携が基本、動作がより安定する

iPaaSは、各クラウドサービスが提供するクラウドAPIをクラウドサービスからコールすることによりインターネット上でデータ変換/統合を行うところが大きな特徴である。実行環境はクラウドサービス側である。RPAでもAPIをコールできるアクティビティ/アクションを備えている製品もあるが、基本はデスクトップの操作記録によるパソコンの操作を介しての連携であり、実行環境はクライアント側となる。



【RPAとiPaaSの動作の違いの概念図。黄色がiPaaS、グレーがRPAによる連携】

image.png

一般に、API連携の方が画面操作による連携よりも動作が安定する。また、デスクトップパソコン上での動作よりもサーバー上での動作の方が安定する。したがって、iPaaSによる動作の方がRPAよりも安定すると、一般的には言えるだろう。UIが変わらないレガシーシステムはRPAで、UIが頻繁に変わるシステムはiPaaSで連携すべし、という主張もある。

一方、iPaaSが連携できる相手はAPI連携の仕掛けが提供されている相手先に限定される。それ以外のクラウドサービスとは連携できない。日本国内限定のサービスなどは、対象に含まれないことが多いだろう。そのような時はRPAを使うことになる。


現場ユーザーでも使える「レシピ」の概念

iPaaS製品は、ワークフローをビジュアルに作成していくタイプのアプリケーションになっていることが多いが、統合開発環境(IDE)によるコーディングも交えた設計が必要なものもある。しかし、中には、いままでの「システム統合」「アプリケーション統合」製品と異なり、クラウドならではのお手軽さを反映した、誰でも使えるWebベースのワークフローアプリケーションのようなユーザーインターフェイスを持っているものがある。API接続の仕方についても典型的なユーザーシナリオで組み合わせがテンプレート化されていて初心者でもそれを使えばすぐにクラウドアプリケーション統合ができる、という「レシピ」などと呼ばれる仕掛けを搭載している。このような製品であれば、あまり難しいことがわからない現場のユーザーが自分たちでワークフローを組み立てることが可能となる。


レシピの概念を持つiPaaSの例


IFTTT

「イフト」と読む。2010年にサービスがスタートし、レシピを使ってFacebook、Evernote、Weather、Dropboxなどの数々のクラウドサービス同士で連携することができる、レシピ型iPaaSの草分け的存在である。消費者向けクラウドサービスの統合が多かったがSalesforce、Office 365などの企業向けのサービスも多く登録されている。個人または企業がレシピを開発、登録することも可能。GoogleAssistantやamazon alexaなどのAIスピーカーやIoT機器との連携もできる。英語UIのみ。無料。

https://ifttt.com/

image.png


Zapier

「ザピエル」と読む。2012年にサービスがスタートし、1500以上のアプリと接続できるという。連携するアプリを視覚的に組み合わせてテンプレートを作成する。英語UIのみ。月毎100タスクまで無料、企業向けには年額約80万円で月毎10万タスクまで使えるプランがある。

https://zapier.com/

image.png


Microsoft Flow

マイクロソフト社が提供しているiPaaSで、Dynamics関連製品であるPower Platform製品の一部。2016年にリリースされ、250個以上の「コネクタ」をサポートしているという。プランにより利用できるコネクタが異なる。日本語UIあり。月毎750回実行まで無料、月額約1,600円/ユーザー (年額約2万円)、組織全体の共有で約55,000円 (年額約70万円)のプランが存在。

日本時間11月5日から始まったMicrosoft Ignite 2019にて、Microsoft FlowがPower Automate / Power Virtual Agentに進化して、画面のレコード機能 (=RPA)機能も実装することを発表しました。早くもRPA+iPaaSの融合が起きそうです。2

https://flow.microsoft.com/ja-jp/

image.png


Workato

2013年にサービスを開始。コミュニティレシピを搭載し、300種類以上のクラウドサービスに対応。Slack/Microsoft Teamsなどにボット機能を搭載して、APIの自動連携だけでうまくいかない作業を人に聞くことで、非定型業務の領域にも踏み込めることが特徴といえる。英語UIのみ。利用できるコネクタの種類、オンプレミス対応などにより、無料、年間約80万円~300万円のプランが存在。(直接メーカーと取引した場合。販売にパートナー制度を取っており、日本のパートナーを通した価格は異なるようである。)

https://www.workato.com/

image.png


その他のiPaaS製品

MuleSoft Anypoint Platform (by Salesforce)、Boomi (by Dell)、Informatica Intelligent Cloud Servicesなどが存在する。これらは、IDEの中でワークフローを自分で組み立てていき、必要に応じてコーディングを行い、デプロイを行うといった形式となっている。また、サービス側のAPI自体を設計するといった高度な開発もできるようになっているものもある。iPaaSの中でもSIer向けによりプロフェッショナルな仕組みを提供している。費用はこちらの形の方が高価で、iPaaS市場 (金額ベース) をけん引しているのはこちらの製品群である。


(おまけ) iPaaS市場に関する考察

iPaaSは今後伸びるのか?乗っかってもいいのか?いくつかの観点から世の中に出ている情報から考察してみた。


iPaaS自体の市場性

ガートナーによるとiPaaS市場は2017年には対前年比72%、2018年には対前年比55%の成長をしてきたということだが、成長のスピードがかなり落ちてきているという。2018年と2019年に出たレポートでは、グローバル市場の大きさがまるで違うということだ3。2018年の時点では、CAGR 42.1%、2024年時点で86億USDになるといわれていたが、2019年のレポートではCAGR11.9%、2022年で12億USDであるという。両者は違う調査会社から出されたものとはいえ、予測があまりにも違いすぎる。これはiPaaS市場の置かれた微妙な状況を表している。iPaaSはガートナーによると「iPaaS単体では収益性が難しいため、2~3年のうちに大きな業界再編が起こりベンダーは1/3となる4」という。


RPAとiPaaSの市場規模の対比

ガートナーではRPAソフトウェア市場は2018年でグローバルで6.8億USD、2022年には24億USD (CAGR37.1%)になるとみている。他の調査会社のものもそんなに大きな差はなさそうである5。2018年時点での両者の市場規模はiPaaSがRPAの約2倍あったようである。今後については、iPaaS市場の予測がどうなるかにもよるが、最新の予測同士を比べてみると、伸び率はRPA市場のほうが高そうであり、市場の大きさもRPA市場のほうがどんどん大きくなっていくようである。

ちなみに、日本におけるRPA市場はというと、IDCの調査データによれば2018年で155億円 (対前年比113%成長)であるという。ガートナーのデータと比べてみると、日本市場はグローバル市場の約20%程度を占めることになる。

また、iPaaS製品とRPA製品は単価やライセンス、価格にサービスのどこまでを含まるかといった考え方が異なるため、単純に金額の比較だけで利用社数、利用インスタンス数の比較にはならないことに注意したい。


検索ワード数からの対比

RPAもiPaaSもバズワードといわれるが、いったいそれぞれどれくらいバズっているのかについて、Googleトレンドを見てみた。結果は以下の図の通りである。

image.png

image.png

結論としては、世界でも日本でもRPAという用語に比べてiPaaSはバズっていないのである。また、世界ではiPaaSは年を追うごとに上昇トレンドであるが、日本ではその傾向はみて取れない。最近大きなピークがあったくらいである。

このことから、iPaaSという単語は市場には広く普及しておらず、調査会社が製品・サービスを分類する都合上、iPaaSというカテゴリを作り出して分類している可能性もあるだろう。また、iPaaSは最近大手のソフトウェア製品・サービス提供ベンダーに合併吸収されているため、iPaaS市場として出ている金額のどこまでが純粋なiPaaSとしての金額なのかについても疑問が残るだろう。ベンダーごとのばらつきも大きいと思われる。

ちなみに、レシピの概念を持つiPaaS同士で比べたトレンドは以下のとおりである。IFTTTは全世界でも日本でも抜群の知名度があったが、世界的には最近はZapierがIFTTTを追い抜かしつつあるようだ。Mirosoft Flowもそれに続いている。日本ではIFTTTがまだダントツで有名なようである。

image.png

あと、IFTTTとiPaaSの検索数の絶対量を比較したトレンドも見ておこう。iPaaSという単語は流行っていないが、IFTTTなどの「レシピの概念を持つiPaaS」の個別製品名は、RPAほどではないが、トレンドに上がってきていることになる。

image.png


まとめ

iPaaS製品は、いまのところアプリケーション提供側の大手ベンダーによる買収が多いが、もしかしたらRPAベンダーによる買収でRPAの弱みを強化するといったことが起こるかもしれない。アプリケーション提供側のベンダーによる買収だと、どうしても自社のサービスが優先されてしまいユーザー側の都合の考慮がおろそかになってしまう。そういう意味では、アプリケーションベンダーからは中立的なRPAベンダーによる買収の方が、市場にとってはメリットがあるように筆者は考える。いずれにしても、RPAとiPaaSのいいところを組み合わせれば、現場レベルでもより安定したアプリケーション統合を提供できるのではないだろうか。


参考記事