WEB操作をAPI化するという事（本題）

村井@C-RISEです。
前回の記事で、「WEB操作のAPI化」について書こうと思ったのですが、前段が長くなりすぎたので、今回が本題となります。

クラウドサービスだったらAPI対応するよね

まず、「WEB操作をAPI化する」とはどういう事か。
クラウドBOT®は、WEBブラウザの操作手順を自動記録する事でシナリオを作成しBOT化するRPA機能を提供しています。
この機能をBrowsing BOT、略してB-BOTと読んでいます。

このBOTをAPIとして呼び出せるというのは以前の記事にも書いた通りです。
でも、他のクラウド型RPAサービスでも、作成したBOTをAPIから実行できる機能が提供されています。
私は、この「BOTをAPIから実行する」か「BOTをAPIとして実行する」かは似て非なるものと考えています。

これは言葉遊びではなく、サービスの設計思想のお話でもあり、BOTにどのような役割を持たせて、どこに焦点を当てて機能設計されているかという事でもあります。

RPAとは定形作業をロボットに任せる事

多くの場合、RPAは人間の定形作業をロボットに任せる事を目的に導入されます。そのため、操作シナリオも「人が操作する手順」をベースに「ロボットの場合はどのような手順にしようか」と検討されるのです。
例えば、下記のような手順です。

①商品一覧のExcelファイルを開いてデータをクリップボードへコピー
②WEBブラウザで画面のフォームにデータをペーストして登録ボタン押下
③登録時に発行された商品IDを画面の中から選択しクリップボードへコピー
④Excelファイルに商品IDをペーストして保存

そうして出来上がったBOTを「APIから実行する」場合、呼び出し元の手順は下記のようになります。

①入力に必要なデータをExcel形式で出力して所定の場所に配置する。
②APIからBOTを実行する。
③BOTが出力したExcelファイルを開いて結果を読み込む

この時の「②APIからBOTを実行する」というのは、作業ロボットの起動スイッチを入れるようなイメージになります。
ここに必要な資料を置いておくから作業が終わったら記入して戻しておいてね。といった利用イメージです。
(※後述しますが、他のRPAサービスのBOTが引数に対応していないという事ではありません)

RPA機能でAPI化を実現する

では、クラウドBOT®のRPA機能(B-BOT)はどうかというと、以前の記事でも紹介した通り、

APIが無いWEBシステムに対する連携手段としてのRPA

という位置付けで設計されています。
つまり、業務上の「作業手順」よりWEBシステムに対する「データ入出力」に焦点を当てているのです。
そのため、RPA機能(B-BOT)のシナリオにはExcelファイルの読み込みや外部API連携、OCR機能等、WEBブラウザを使わない操作を登録する事ができません。
対象のWEBシステム/サービスに対してWEBブラウザからどのようなデータを入力して、どのようなデータを取り出すのかだけをシナリオ化します。
これは、APIの代替手段としてのRPA機能という目的から考えると自然な事でもあります。
一般的にREST APIを使ってシステム間連携をする場合、外部システムからHTTP/HTTPS通信で接続して、XMLやJSONといった電文形式で引数を渡し、応答データとして返ってきたXML/JSONを受け取ります。
このAPIと同等の機能をWEB画面操作で実現する場合、下記のような仕組みが必要となります。

①外部システムからJSON形式の引数を受付
②WEB画面のフォームデータとしてWEBシステムにデータをPOST送信
③WEBシステムから応答されたHTMLを解析し必要な値を抽出
④外部システムにJSON形式で応答

このような仕組みを非エンジニアの方でもノーコードで作成できるようにと開発されたのがB-BOTのエディタです。

自動で操作とデータを分離

例えば、自動記録機能で作業手順を登録した後に、API化する場合
・どの値を引数にするか、デフォルト値をどうするか
・どの値を変数にするか、変数名をどうするか
・どの値を返り値にするか
・ループ処理(while文やfor文)の繰り返し条件や範囲をどうするか
といった処理フローを考えながらシナリオを修正する必要があります。
これらは既にプログラミングスキルが要求される行為です。
もし、その自動記録されたシナリオがJavaScript等のコードであれば尚更です。

クラウドBOT®は、ユーザがブラウザ上で操作した内容を自動解析し、操作とデータを分離しながら記録します。
さらに、BOTの入力値と出力値も自動的に定義します。
操作の自動記録が終わってBOTを保存する時には既にBOT内のデータ構造や入出力定義がされていて、そのままAPIとして使う事ができます。

ここまで話してきましたが、そもそも非エンジニアがAPIを作れたとしても使えないのでは？と思われた方も居られるかもしれません。
もちろん、非エンジニアがAPIを使う事は想定していません。
ただ、対象のWEBシステムのREST APIとして機能するBOTである事が大事なのです。
APIとして機能するという事は、処理に必要なデータは引数として渡し、処理の結果は返り値として受け取る事ができるので、前述したエクセルファイル等でのデータ引き渡しは不要です。
これは、このBOTを一つのモジュール、つまり部品として利用する場合に非常に重要な要素となります。
BOTを実行する為に必要なデータは入力値のみで、BOTの実行結果は出力値として受け取れる。
こうする事によって、データファイルの置き場所や同時実行時の衝突等に依存する事なくBOTを実行する事が可能になります。
そして、非エンジニアの方も、iPaaS機能(C-BOT)で連携接続できるモジュールの一つとしてBOTを利用する事ができるようになります。

今回、クラウドBOT®は、B-BOT機能を先行してリリースしました。
それは、全体の完成まで時間がかかるという事もありますが、まずはB-BOTだけでもWEBサイトを簡単にAPI化して連携できるようになるという点と、B-BOTの機能が本当に非エンジニアの方に受け入れてもらえるのかを確認したいと考えたからです。

でも業務自動化の為のRPAとしても使えるんです

ここまで、さんざんAPIの為のRPAだと言ってきましたが、あくまでそういった用途に最適化された設計になっているという事であって、いつもの日常業務のWEB操作を自動化できないかと言えば「できる」のです。
実際に既にそのような用途で活用頂いてます。
そして、上記で誤解を恐れず、他のRPAサービスのAPIは「BOTを起動する為に使う」と書きましたが、調べた限り他サービスでもAPIに引数を定義して実行する事ができます。
それぞれ、この様な用途でしか使えないという事ではなく、サービスの方向性としてどこを向いているかという設計思想の話しだとご理解下さい。

まだ、色々と書きたい事もありますが、クラウドBOT®の正式サービス開始も近づいてきていて、タスクも積み上がってきてるので一旦このあたりでWEB操作をAPI化するお話は締めたいと思います。
せっかくNoteを書き始めたので、今後もクラウドBOT®の開発経緯や思い、実際の利用手順のご紹介等を時々書いていきたいと思います。
ここまで読んで頂きありがとうございました。