ロボティック・プロセス・オー トメーションの悪い面

Robotic Process Automation
Author: Spiros Alexiou, Ph.D., CISA, CSX-F, CIA
English

ビジネスプロセスには、販売の登録、付加価値税の計 算、請求書の送付、製品の梱包と配送、在庫の更新、 売掛金の回収など、一連の作業が含まれます。従来、 このような作業は、1人または複数のオペレーターに よって行われてきましたが、各オペレーターの職務の 種類、情報の共有または処理、入力ミスなどの人為エ ラーや処理エラー、人件費、処理速度などの問題が伴 いました。コンピューターが登場し、今まで人間が 行ってきた作業は、コンピュータープログラミングに より自動化されました。

ロボティック・プロセス・オートメーション(RPA) は、予め定義されたシンプルな規則に従い、作業員が 行う作業(ファイルを開く、レコードの読み取り、電 子メールの送信など)を実行するために、仮想ロボッ ト(業界用語ではより親しみを込めて「ボット」と呼 ばれる)を使用することを指します。

各作業を実行するボットの存在が一部で牽引材料とな り、RPAは現在盛んに使用されています。文献が示す ように、監査では自らの作業にRPAが使用されていま すが、いくつかの欠点も指摘されています1。つま り、RPAは、以下の2つの要素から構成されます。

  • 事業体は、継続監査活動などの独自の内部実践手 法にボットが存在するかどうかを評価するよう監 査に依頼します。ボットは、事前に定義された基 準に合わせて例外リストを作成します。.
  • 事業体は、RPAの採用を考慮してRPAリスクを評価 するよう監査に依頼します。同時に、監査は、RPA が杜撰なプランニングの修正に使用されることが あり、その過程で、プロセス全体が適切に計画さ れていた場合には存在しないリスクが追加で発生 することを伝えなければなりません。

先に述べたように、一連の作業を実行するソフトウェ アなどの(RPA以外の)オートメーションは、遅くと も1970年代に導入されました。例えば、ファイルの 形で通知をチェックし、そのファイルを読み取って、 情報を実行するプログラムがあります。情報に基づく アクションには、別のタスクの開始または停止が含ま れる場合があります。このような独立型自動プログラ ムは、デーモンと呼ばれ、バックグラウンドで実行さ れます。毎分おきにディレクトリをチェックする、新 しいファイルを検出する、そのファイルを開いて読み 取る、選択したコンテンツをデータベースなどの別の プログラムに挿入するなどのアクションを実行し、 Unixのcronコマンドなどを使用して毎日指定時刻にバ ックアップを取ることもできます。アプリケーション は、オペレーターが起動を実行するものの、人の介入 やアクション情報なしに他のデーモンレスな方法でも 交信します。例えば、ユーザーがウェブブラウジング にHTTPS (Hypertext Transfer Protocol Secure)を使用 するとき、ブラウザとサーバーは、安全な接続に必要 なパラメータを自動的にネゴシエートします。つま り、ユーザーは介入したり、詳細を把握したりする必 要はありません。重要なのは、RPAの登場以前にも、 ほぼ半世紀にわたってオートメーションが採用されて きたという事実です。では、なぜRPAが必要なので しょうか?この質問に答えるには、RPAの仕組みと従 来の単純なオートメーションとの相違点に注目する必 要があります。

 

RPAは、従来の単純なオートメーションと似たように 機能することもありますが、ウェブページのHTML (Hypertext Markup Language)の読み取りと解読、デ ータやボタンの配置、ウェブページのHTMLコードか らのデータ読み取り、データ処理、最終的な結果のエ クスポート/表示などの新しい機能を追加します。こ れは、従来のデーモンと似た機能で、オペレーターが 受けるものと同じ影響を与え、十分に機能するのが一 般的です(ファイルを開く、レコードを読み取る、ル ールに基づいてコピーまたは判断する、電子メールを 送信したり、ブラウザを開いて入力したりすることで 処理する等)。ただし、以下のように結果が異なり ます。

  • オペレーターは、クリアテキストまたは可逆的に 解読可能な形式で、必要なパスワードをRPAに保存 しなければなりません。当該アプリケーションが ハッシュインジェクション(この場合、暗号化さ れたパスワードで十分)を用いて機能しない場合、 RPAへのアクセス権を持つユーザーであればパスワ ードを取得できます。これは、従来のデーモンと原 則として違いがないことは言うまでもありません。
  • とりわけ、ウェブベースではないアプリケーショ ンの場合、RPAは「スクリーンスクレイピング」を 使用することがあります。これは、最終手段とみ なされ、実際にそのとおりです2 。スクリーンスク レイピングは、光学文字認識(OCR)を使用して、人 間が行うように画面出力を読み取りますが3、それ は意味があるでしょうか?元々、データはデジタ ル形式で存在しますが、RPAは画面上にデータを出 力してから、それを読み取ってデジタル形式に戻 す必要があります。OCRが、1000米ドルの請求書 の小数点を100万米ドルと読み間違えたらどうなる でしょうか?あるいは、画面上にゴミが付着した ため、売掛金フォームに記載された小数点を読み 間違えることもあります。オペレーターはデジタ ル信号を容易に読み取ることができないため、人 間のためにビジュアル表示が必要です。ところ が、デジタル信号の読み取りは、コンピューター の最も基本的な機能です。中には、100パーセント のOCR精度を謳っているベンダーもあり4、OCRの 安定性5を高めるために人工知能(AI)を使用する高 度なアルゴリズムが採用されていますが、それで もリスクは残ります。とりわけ、監査にとって は、永久に無人でミスがなく機能するプログラム はありえません。通常、ベンダーはエラーがない ことを保証したり、損害を補償したりすることは ないのです。OCRを巡る議論の中には、「画像に ごくわずかな修正を加えるだけで、学習させたデ ィープニューラルネットワークも簡単に騙すこと ができる」と指摘している研究もあります6。さら に、OCRは文字を認識することを重視するのが一 般的ですが、小数点の見逃しや読み取り間違いに 対して保険会社が保護してくれても、文字が必ず しも鮮明であるとは限りません。画面上の画素が 粗かったり、ゴミが付着していたり、照明が反射 していたりすると、読み取り間違いのエラーが発 生するのではないでしょうか?また、RPAによる自 動化を選択する場合、エラーが発生すると「不釣 り合いな代償」となるプロセスがRPAの落とし穴で あると指摘している論文もあります7。エラーに対 する保護やフォールバックソリューションは、( スクリーンスクレイピング)RPAソリューションと して一般的に使用できないということも理解され ています8

プロセス全体を自動化することが正しいソリューショ ンといえます。元のデジタルデータを画面に出力して から読み取る方法以外に、デジタルデータの自動読み 取りよりも単純な方法があるでしょうか?しかも、エ ラー発生を抑え、より迅速かつ効率的な方法です。

「人間が徹底的な確認作 業を実行したい場合、ボット によって実行されたタスクを 再実行することを意味するの で、ボットの利点が事実上否 定されてしまいます」

それでも、スクリーンスクレイピングRPAが実行可能 なソリューションとして議論されるのはなぜでしょう か?その答えには、API (Application Programming Interface)やインターフェイスが不足または欠如して いるクローズドな専用システム、時代遅れのプログラ ミング言語で記述されたコードで稼働する旧式システ ム、これらのシステムの設計不良など、さまざまな理 由があります。RPAはよりマシなように見えます。シ ステムは、最初から定型作業向けにオペレーターを採 用するか、あるいは需要が高まり拡張されると、定型 作業向けにオペレーターを採用するよう設計されてい ることが多いです。もちろん、定型作業を最初に自動 化し、人の介入やスクリーン出力なしに、ルールに基 づいてタスクを実行する自動ルーチンにデータを提供 することが正しいソリューションです。また、ソース コードは、所有権、予算または読み取りの問題で利用 不可または変更不可であることが多いため、既存シス “ 「人間が徹底的な確認作 業を実行したい場合、ボット によって実行されたタスクを 再実行することを意味するの で、ボットの利点が事実上否 定されてしまいます」 ” 3 ISACA JOURNAL VOL 5 テムの追加または拡張としてオートメーションを構築 することはできません。公平に見て、RPAはプログラ マーへの依存を制限します(ただし、RPAソリュー ションへの依存を高めます)。

小数点の読み取り間違いなどの問題に対処するため に、追加の人間によるコントロールを導入すると、人 間は特にボットエラーの可能性が低い場合などにボッ トのいいなりになる傾向があるため、別の問題が発生 します。人間が徹底的な確認作業を実行したい場合、 ボットによって実行されたタスクを再実行することを 意味するので、ボットの利点が事実上否定されてしま います。タスクとリスクが十分に重大であるため、用 心深い人間の注意が必要な場合、最初にタスクを人間 に割り当てるべきです。ボット自体によって引き起こ されるリスクを排除すれば、さらに良いでしょう。

言うまでもなく、ITシステムに付き物のリスクが存在 しないわけではなく、軽視すべきでもありません。こ のようなリスクシナリオは、RPAのライフタイム全体 に関わるものですが、開発から運用、所有、セキュリ ティ、ロギング、モニタリング、業務継続、変更管 理、インシデント管理(ボットはエラーを起こしてク ラッシュする可能性がある)、処分までのITシステム のライフタイムとは根本的に異なります。

「監査が知って実践すべき は、リスクの存在を認識し、 RPAが使用される理由がニー ズによるものであって、プラ ンニングの不備ではないと確 認することです。」.

結論

人間を機械に置き換えることによるコストカットの魅 力があるため、RPAは今後も広く採用される可能性が 高いです。監査が知って実践すべきは、リスクの存在 を認識し、RPAが使用される理由はニーズによるもの であって、プランニングに不備はないと確認すること です。新しいシステムは、RPAを念頭に置いて設計す るべきではなく、設計によって自動化すべきです。オ ープンソースのコードへのアクセスに、コードを拡張 するための知識とスキルを組み合わせると、大きなメ リットがあります。RPAはオートメーションであり、 一般的にオートメーションは便利なものです。ただ し、スクリーンスクレイピングRPAは、効率性と安全 性に欠けるオートメーションであり、適切なオートメ ーションにはない潜在的に重大なリスク要因を取り込 みます。多くの意思決定者は、RPAの仕組みを理解し ていないため、監査は、スクリーンスクレイピング RPAがフルオートメーションの代用には不足してお り、第一の選択肢ではなく、最後の手段にすべきこと を指摘しなければなりません。RPAにより自動化する 新しいシステムを設計しても、まったく意味がありま せん。すべての問題を何らかの方法で解決する魔法の ような手段を求めるのではなく、プロセスの内容とそ れを最適化する方法を考慮するのが正解です。

その他にもRPAの落とし穴は存在しますが、いくつか の論文でRPAの「不備」が議論されています。9, 10, 11, 12, 13ほとんどがRPAの用途に焦点を絞っており、テク ノロジー自体には焦点を絞っていません。現在、RPA は、原則として変更されない反復的なノンインテリ ジェント(ルールベースの)タスクを実行するようプ ログラムされています。アプリケーションの画面レイ アウトでの変更などの予想外のシナリオを処理でき ず、追加設定なしに機能することもありません。通常 は、関連プロセスに合わせたカスタマイズが必要で す。同様に、プロセスとタスクは個別に存在せず、通 常は入力を必要とし、他のタスクやプロセスに出力を 提供します。これらの相互依存関係も重要です。ただ し、RPAがハンマーなら世界が釘というわけではあり ません。同じ最終目標を達成するにあたり、より安全 で効率的な方法が存在するなら、それに越したことは ありません。

脚注

1 Struthers-Kennedy, A.; A. Poulikakos; “RPA: First Steps to Greater Internal Audit Efficiency,” Corporate Compliance Insights, 16 November 2018, https://www.corporatecomplianceinsights.com/rpa-first-steps-to-greater-internal-audit-efficiency/
2 KPMG, “Internal Audit and Robotic Process 2 Automation: Considerations for Assessing and Leveraging Intelligent Automation”
3 Techopedia, “Screen Scraping,” https://www.techopedia.com/definition/16597/screen-scraping
4 UiPath, “Screen Scraping Software for Desktop and Web-Screen Scraping that Works Everywhere,” https://www.uipath.com/solutions/technology/screen-scraping
5 Sporici, D.; “Evaluating the Robustness of OCR Systems,” Coding.Vision, 7 September 2019, https://codingvision.net/ai/evaluating-the-robustness-of-ocr-systems
6 Qian, S.; “Adversarial Robustness of Optical Character Recognition (OCR),” Medium, 19 September 2019, https://medium.com/@sharon.qian.10/adversarial-robustness-of-optical-character-recognition-ocr-91eedc36ef6
7 AIMultiple, “20 RPA Pitfalls and the Checklist for Avoiding Them [2020 update],” 1 January 2020, https://blog.aimultiple.com/rpa-pitfalls/
8 Morphy, E.; “Why RPA Implementation Projects Fail,” CMSWire, 5 March 2019, https://www.cmswire.com/information-management/why-rpa-implementation-projects-fail/
9 Casey, K.; “Why Robotic Process Automation (RPA) Projects Fail: Four Factors,” Enterprisers Project, 18 June 2019, https://enterprisersproject.com/article/2019/6/rpa-robotic-process-automation-why-projects-fail
10 Hewlett, G.; “Five Most Critical Points of Failure in RPA Implementation,” Assurity, 12 November 2019, https://assurity.nz/insights/five-most-critical-points-of-failure-in-rpa-implementation/
11 Iluri, S.; “Top 10 Reasons Why Automation Efforts Fail,” Skan
12 Trefler, A.; “The Big RPA Bubble,” Forbes, 2 December 2018, https://www.forbes.com/sites/cognitiveworld/2018/12/02/the-big-rpa-bubble/
13 Leonards, A.; “What Can We Learn From RPA Failures?” Raconteur, 9 September 2019, https://www.raconteur.net/technology/rpa-failures

Spiros Alexiou, Ph.D., CISA, CSX-F, CIA

大手企業で過去12年間、IT監査人を務めてきました。ITシステム分野で24年 を超える経験を有し、高度なコンピュータープログラムを数多く手がけてき ました。連絡先の電子メールアドレスは、spiralexiou@gmail.comです。