来る2020年5月20日、Automation Anywhere 主催のDeveloper Meetupがあり、筆者も参加予定です。
テーマは「落ちないBotの作り方」。
AIのインテグレーションなど、攻めのイメージの強いAutomation Anywhereのイベントにしては地味なテーマかなと思いましたが、それほどBot開発者にとってこの点は切実な課題なのでしょう。
登壇の枠はすでに埋まっていましたが、このテーマについてはIQ Botの視点でも一家言あるので、この場を借りて叫んでみます。
#IQ Bot的「落ちないBotの作り方」
##①：推奨（最適）スペックのサーバーを使う
これはオンプレの場合のみで、クラウドの場合は関係ないのですが、サーバーのスペックは最適要件に適合するものを使うことを強くお勧めします。
IQ Botのインストール要件はこちら（ベンダー公式ドキュメントサイト）にあります。
ハードウェアとソフトウェアの要件は、日本語版では最適要件の他に「最小要件」なるものが載っていますが、最新版である英語版からは最小要件の記載が削除されています（2020.5.12現在）。
筆者も最小要件のマシンでテストしていた時期がありますが、その経験からも最適スペックの使用を強くお勧めします。
最小だと挙動が遅かったり、分類の処理で固まりやすかったりしましたが、最適スペックに変えたら一気に快適になりました。
推奨要件を満たすハードウェアの導入は、本番導入であれば当たり前なのですが、検証段階では渋られることもままあるようです。
「検証用途で8core 32GB RAMのサーバー？ 手持ちのPCでどうにかできないの？」
などと言われてしまうケースもあるようですが、IQ BotはAIを使うソリューションです。
計算量多いです。 CPU食います。
なので検証用途であっても、オンプレであれば最適スペックのサーバーを入れて検証することを強くお勧めします。
##②：CRサーバーとIQ Botサーバーは分離
これもオンプレの場合のみで、クラウドの場合は気にしなくていいのですが、CRサーバ―とIQ Botサーバ―は物理的に分離しましょう。
同梱でも動くことは動くので、検証用途のみであれば同梱も可能です。
（でもベンダーとしてはあくまでも分離を推奨しているようです）
ですが、本番では必ず分離しましょう。
①の話ともつながっているのですが、IQ BotはAIを使うソリューションです。
計算量多いです。 CPU食います。 （大事なことなので二回目です）
IQ Botサーバーに十分なスペックを見積もって落とさない設計にすることは当然なのですが、IQ Bot側がCPUを多く使っている影響をCR側に与えないために、CRとIQ Botのサーバーは必ず分離しましょう。
2020.5.14 追記：検証用途等でどうしても同梱させざるを得ない場合について、番外編を公開しました！
##③：DBも十分な容量を確保
これもクラウドでは気にする必要ないですが、オンプレでは気にしておく必要があります。
DBが容量不足になると、IQ Botの処理が極端に遅くなったり、処理が固まったりするからです。
DBサーバーのスペックもこちら（ベンダー公式サイト）に記載があります（2020.5.12現在、英語版にのみ記載あり。日本語版は記載なし）。
DBの互換性はこちら。
DBの容量に関しては、一番影響するのは、学習時にアップロードする帳票（画像データ）の枚数です。
学習時にアップロードした帳票は、マッピング設定の画面で帳票イメージを再現するために、暗号化した画像データとしてDBに取り込まれ、インスタンスが存在し続ける限り保管されます。
なのでこの部分が容量には一番影響します。
また、誤り検知をして検証（Validation）に回った場合も、検証画面に帳票イメージを表示するために一時的に画像データが保管されますが、こちらは検証が完了した時点（こちらのSuccessとInvalidの振り分けが完了した時点）で破棄されます。
一時的なデータではありますが、IQ Botを夜間バッチなどで処理して大量の書類が検証に回るフローを想定している場合は、検証でため込まれる画像データの枚数も考慮に入れて容量を見積もる必要があります。
筆者が使っている検証環境では１台のサーバーにCR、IQ Bot、DB（SQL Express）を同梱させていて、検証用途であればこれで事足りる場合もありますが、本番ではDBサーバも分離させておいた方がいいです。
##④：ユーザーの配布は同時接続数の上限以内にしておく
Automation Anywhereのライセンス体系では、RPAはCRの台数やBC,BRのユーザー数によって金額が決まりますが、IQ Botの場合は処理ページ数が課金の対象であって、IQ Bot関連のユーザーはいくら作っても課金の対象にはなりません。
なので、IQ Botサーバー１台に対してIQ Botの管理者なり開発権限を１００人に付与しようと思ったらできるし、それで追加料金等がかかることはないんですが、「落ちないBot」という観点でいえば、同時接続の上限以内にしておくことが望ましいです。
同時接続の上限は、V11.3.4以降でIQ Botサーバー１台あたり２０。
それ以前のV11系統とA2019系統（記事掲載日現在の最新バージョンはA2019.12）では５です。
この「同時接続」の定義は、IQ Bot側のUIにログインして管理や開発を行っているユーザーや、BCやBRからIQ Botをつついているユーザーをすべて含みます。
同時接続の上限はパフォーマンス上の推奨要件で、上限を超えるユーザーが同時に接続してもエラーが出るわけではなく、結果的に普通に動いてしまうこともあるようです。
ですが、CPU計算量をたくさん使う分類の処理などが同時に走ると、サービスダウンなどの問題が起こりやすくなります。
こうした事態を未然に防ぐには、発行するユーザー数を同時接続の上限以内にしておくことが手っ取り早いし確実なのかなと思います。
たとえば、IQ Botの本番稼働を夜間バッチで組んでいるのであれば、IQ Botのアクセス権限を持っているBRは（A2019のシングルサーバーなら）５台までにしておく。
そして昼間にIQ Botにアクセスするであろう管理者や開発権限を持ったユーザーも、５人までにしておく、など。
IQ Botの稼働が日中処理の場合は、それに合わせてサーバーの台数なり、BR・管理側のユーザー数などを調整する必要があります。
##⑤：IQ Botにアップロードをかける前に、拡張子のチェックを組み込む
ここまでの話はすべて「Botの作り方」というよりはインフラサイジングの話でしたが、ここにきてやっと本当に「Botの作り方」の話です。
IQ Botを動かすためのBotは、基本的にはこちらの記事で紹介したように、フォルダ内の画像ファイルを一括処理する形で組む場合が多いと思います。
インプットとなる画像ファイルは、こちらの記事にも記載のとおり、PDF,JPG,Tiff,PNGを扱うことができ、これらが混在していても大丈夫です。
（Tiffの拡張子は.tiffでも.tifでも大丈夫です）
ですが、インプットのフォルダ内にそれ以外の形式のファイルが入っていると、エラーになります。
インプットファイルを入れる専用のフォルダを用意して、関係ないファイルはそこに入れないようにするという運用を通常はすると思いますが、Botの側でも関係ない拡張子のファイルが入ってきた場合を想定して、関係ない拡張子が入ってきたらメールを飛ばすなりの処理を組み込んでおくと確実です。
フォルダ内に別のフォルダがあっても無視してくれますが、.zipファイルなどは読もうとしてエラーになるので注意です。
##⑥：インプットファイルのPathやファイル名は短めに
これは厳密には「落ちないBot」の話ではないんですが、IQ Botの入力ファイルのフルパスがVarcharで255文字を超えると、Botが落ちるわけでもなくエラーが出るわけでもなく単純に出力ファイルが吐かれないというえらいことが起こります。
こちらはベンダーに強めの改善要望出していますが、今今の対応としてはフォルダパスは短めにし、ファイル名も事前に適切な長さの名前に変更しておくことをおすすめします。
##⑦：誤り検知やカスタムロジックを適切に使用し、出力データの質を確保
IQ Botで紙データをCSV化しているということは、つまり、そのあとに続く事務処理を自動化したいからだと思います。
たとえば帳票上は「令和2年5月12日」という日付が書いてあっても、後続システムの日付の入力欄が西暦年と月と日にそれぞれ分かれていたら、それに適した形でCSVを作っておく必要があります。
こうした「後続システムの特性を考慮してのデータ加工」は、もちろんIQ Botの後でRPA側でやってもいいのですが、IQ Botが備えている誤り検知やカスタムロジックを使ったほうが簡単にデータが成型できる場合もあります。
帳票によって異なる日付の形式を揃えておく、といったひと手間を処理の上流であるIQ Bot側でかけておくことによって、後続のRPAをより組みやすく、落ちにくくすることができます。
#まとめ
いかがでしたか？
①～④はBotの作り方というよりはインフラサイジングの話でしたが、経験上、IQ Botが固まったり落ちたりする原因はほぼほぼインフラのスペック不足にあったので、あえて挙げておきました。
⑤～⑦はBotの作り方の話です。
この記事を参考に、ぜひみなさんも「落ちないIQ Bot」を作ってみてください。