RPAを見直す――AI時代の実行方式と運用移管

Wangらは、人と現代の大規模言語モデルを、それぞれ異なる制約を持つ有限な処理主体として捉え、片方だけでなく共同システム全体を設計単位にする理論枠組みを提案しました。[1] 新規の企業データを分析した論文ではなく、RPA、業務再設計、確認待ち、運用移管の効果も測っていません。本稿はこの論文を、RPAの有効性を証明する根拠ではなく、仕事の受け渡しを再点検するための設計レンズとして使います。

確認者とAIの双方が詰まったとき、原因は一つではありません。不要な工程、重複する統制、入力の欠陥、曖昧な規則、AI出力の全件確認、例外の集中、担当者不足が同じ待ち行列に見えます。まず案件単位で、何を待っているか、誰が何分使ったか、差し戻し理由は何かを分けます。受け手をAIから人へ、あるいは人からRPAへ変えるのは、原因を特定した後です。

重複確認も、直ちに無駄とは限りません。職務分離、不正防止、法令上の承認であれば、削るのではなく目的と証跡を残します。逆に、同じ項目を別形式へ転記するだけなら、工程をなくすか、正本システムで一度だけ確定する候補です。ここでの成果は自動化率ではなく、残す理由を説明できない工程を承認対象から外すことです。

Milani、Kubrak、Navaは、40件の公刊事例を整理し、古い技術を新しい技術へ単に置き換えるだけでなく、デジタル技術の能力を使った複数の業務再設計方法を分類しました。[2] これは著者らが40社へ介入した比較試験ではなく、BPRをRPAより先に終えるほど成果が上がるとも示していません。それでも、既存のクリック手順をそのまま自動化する前に、業務目的と工程の必要性を問い直す根拠になります。

本稿の出発点は、業務全体のボトルネック分析を終え、廃止・統合・簡素化の判断をした後です。残った下位工程ごとに、正本となるデータ、開始条件、完了状態、禁止操作、例外、変更頻度、失敗時の影響を一行で書きます。書けない工程は、実装方式を選ぶ前に業務責任者へ戻します。

大規模な改修を待てない場合、期限付きRPAが合理的なこともあります。ただし「早く作れる」を恒久運用の根拠にはしません。暫定策には、終了日、次の見直し日、置換先、止めた後の処理方法を同時に付けます。期限が更新され続けるなら、更新理由と累積保守費を再承認します。

• 残す理由：顧客価値、法令、内部統制、次工程のどれに必要か
• 正本状態：どのシステムのどの状態を完了とみなすか
• 変更条件：画面、権限、入力、規則の変更を誰から受け取るか
• 終了条件：置換、廃止、費用超過、例外増加のどれで止めるか

Syedらの125文献のスコーピングレビューでは、RPA候補として、規則に基づくこと、反復すること、構造化されたデジタル入力、標準化、十分な文書、少ない例外といった特徴が先行文献で繰り返し挙げられていました。[3] ただし、当時の資料には業界白書も多く、処理量や手順の安定性を必須とするかも一致していません。検証済みの万能な採点表ではなく、候補を絞る質問として使います。

RPAは、決められた手順に沿ってパソコン上の操作を自動で繰り返す仕組みです。プログラムは明示した規則に従いますが、業務結果は画面、権限、周辺システム、データ、実行時点の状態にも左右されます。したがって「同じ入力なら必ず同じ結果」ではなく、正しい完了状態を別の方法で照合できる工程を候補にします。

生成AIは、文章の分類、情報抽出、下書き、候補提示のように、入力の揺れを解釈する部分で役立つ場合があります。しかし、自信表示は正しさの独立検証ではないため、本稿では後続処理の許可条件にしません。機械的に検証できる条件、低い失敗影響、人の承認のいずれもない出力は、RPAやAPIへ直結させず保留します。

• 入力の意味と形式をそろえられる
• 実行してよい条件と禁止条件を書ける
• 正本システムの状態から完了を照合できる
• 例外の種類と連絡先を事前に決められる
• 画面、権限、規則の変更頻度を把握できる
• 誤実行を封じ込め、必要な取消または補償ができる

Hermらは、35件の導入報告、専門家8人へのインタビュー、5社でのワークショップからRPA導入枠組みを作りました。画面を介するRPAは、システムを深く統合する方法より堅牢性が低い場合があり、将来の仕組みまでの橋にもなり得ると論じています。[4] 一方で、迅速性を優先して現行工程をほぼそのまま自動化した事例も扱い、業務再設計とRPA開始の順序は状況で変わるとしています。方式の優劣や成功率を比較した研究ではありません。

ここで並べるものは、同じ階層の五択ではありません。基幹システムは正本状態と業務規則を持ち、APIはシステム同士を画面操作なしでつなぎ、RPAは主に画面上の決定済み操作を行います。AIは解釈や候補生成、人は価値判断、例外、説明責任、承認を担います。必要なら業務フロー機能が待ち、再開、人の作業をつなぎます。一つの案件で複数を組み合わせるのが通常です。

Catalysphereが提案する比較順は、固定順位ではありません。まず正本システムの設定や既存機能で閉じるかを確認し、次にAPIなど画面に依存しない接続を検討します。それが期限、費用、移行リスクに合わず、規則と完了状態が明確な画面操作だけが残るとき、RPAを候補にします。文章解釈をAIが補助し、RPAが登録し、取り消せない例外だけ人が承認する構成もあります。

• 正本：最終的に正しいとみなす状態を保持する
• 接続：システム間で入力と結果を受け渡す
• 操作：決められた登録、照合、更新を実行する
• 判断：曖昧さ、例外、価値の衝突を扱う
• 調整：待ち、再開、人の作業、処理順をつなぐ

規則や画面が頻繁に変わる、入力の意味がそろわない、例外が多い、完了状態を照合できない、処理量が少なく保守費が上回る。このいずれかが強い工程は、RPAを初期候補から外します。APIや基幹改修の提供予定が近い場合は、作らず待つ方がよいこともあります。逆に改修待ちが数年に及ぶなら、終了日付きのRPAと恒久改修を待つ場合を、総リスクの比較対象にします。

取り消せない操作や影響の大きい処理は、一律に自動化禁止とはしません。ただし、独立承認、処理前後の照合、二重実行防止、権限分離、誤処理時の取消または補償を追加できなければ候補から外します。送金、通知、登録のような外部状態は、ボットの版を戻しても元へ戻りません。技術の復旧と業務結果の回復を別々に設計します。

少量で変化の大きい仕事は、人が処理した方が安い場合があります。RPAを作ること自体を成果にせず、開発、監視、認証情報、変更試験、障害対応、廃止までを含む総負担と、人が継続した場合の負担を比べます。数値のない段階では、少なくとも費用が発生する役割と頻度を列挙し、見えない保守をゼロとして扱いません。

Syedらのレビューは、画面の解像度や配置、周辺システム、業務規則の変更でRPAが停止したり誤った経路へ進んだりする課題を整理し、正常経路だけを記録すると例外やまれな事象を落とし得ると指摘しました。[3] これは故障率の推定でも、現在の全製品に監視機能がないという主張でもありません。既知の故障要因を試験項目へ変える根拠です。

KokinaとBlanchetteの会計・財務領域の探索的複数事例には、失敗経路の洗い出し、処理を小さく分ける設計、ボットの復旧が長引くとき人の作業へ戻す運用例が含まれます。[5] 小標本で、大手RPA提供者経由の参加者募集もあり、これらの方法が復旧時間や損失を減らすと比較検証した研究ではありません。

そこで本稿は、通常時の処理件数に加え、作成者を外した障害演習を受入証拠の一つにすることを提案します。業務チームは、最後に確定した正本状態、処理中、未処理、処理済みを区別し、二重実行を防ぎます。処理を止め、未処理案件を容量内で手動継続し、承認済みのボット版を再配備し、処理済み案件を照合します。必要なら返金、逆仕訳、訂正通知など、その業務固有の取消・補償を依頼します。

人へ戻す経路も、名前だけでは存在しません。必要な権限、画面、手順、技能、処理容量が残り、想定する復旧時間内に第三者が開始できることを試します。例外が一斉に人へ集中して通常業務を超えるなら、自動化範囲を縮めるか、縮退時に優先する案件を決めます。

• 検知：停止、業務上の例外、周辺障害、原因不明を区別する
• 封じ込め：新しい実行を止め、影響する案件を切り離す
• 継続：未処理案件を人が扱える容量、権限、データを確認する
• 技術復旧：承認済み版を再配備し、変更後の代表案件を再試験する
• 業務回復：処理済み案件を照合し、取消、訂正、補償を完了する

Noppenらは、文献26件、オランダ4組織、2ラウンドのDelphi調査から、業務部門が一定の自律性を持ち、RPAを支援する専門チームが背後で支える体制向けに11の指針を提案しました。[6] 能力評価、実地指導、開発基準、文書、試験、再利用部品、途中の品質確認、技術審査、周辺システムの変更連絡を含みます。ただし、中央集約型より優れること、保守工数が下がること、引継ぎ後の成果を測った研究ではありません。

本稿では、業務成果を承認する人、日常運用を担う人、技術的に支援する人、重大変更と再開を独立確認する人を分けて記録します。これはCatalysphereの責任分担例であり、すべての組織に同じ四役を要求する研究結果ではありません。小規模で低影響なら兼務できても、自分の変更を自分で最終承認する関係には、別の確認者または代替統制を置きます。

引継ぎは三段階にします。最初は作成者同席、次は作成者が答えず観察、最後は作成者不在で、監視、例外処理、変更試験、停止、手動継続、技術支援への連絡、再開判断を実演します。

ここで「作成者不在」は「技術支援不在」ではありません。業務チームは検知、停止、影響確認、手動継続、支援要請、業務上の取消・補償を担い、専門チームはボット、認証、共通部品、配備の技術復旧を担います。重大変更と再開は独立した承認者が確認します。未達があれば、影響度に応じて是正、共同運用の継続、対象範囲の縮小、移管延期を選びます。

専門チームをなくすことが移管の目的ではありません。業務チームは日常状態と例外の意味を所有し、専門チームは設計基準、共通部品、認証、難しい障害、変更審査を支えます。誰へ連絡すべきか分からない状態も、作成者へ何でも戻る状態も受入不可です。

会議へ持ち込む成果物は、技術の比較表ではなく「実行方式・移管受入票」です。自動化対象となる一つの下位工程と一つの実行構成につき一票を作り、残す理由、正本、接続、操作、判断、調整、成功条件、状態を変えてはいけない条件、停止条件、例外容量、取消・補償、担当者、移管試験結果を置きます。試験ログと障害記録は票からリンクする証跡へ分けます。AI、RPA、人という製品・担当名から始めず、業務状態と責任から埋めます。

演習前に、業務責任者は最大検知時間、許容する例外滞留または未処理量、手動継続の最低処理能力、技術支援へ連絡して着手するまでの最大時間、業務回復の期限を工程ごとに記録します。固定の全社値を発明せず、失敗影響と通常時の容量から決め、独立承認者が合否と未達時の共同運用、範囲縮小、延期、停止の分岐を承認します。

承認の順番は明快です。不要または重複する工程を残す理由がなければ廃止・統合へ戻す。規則と完了状態を説明できなければRPAへ進めない。正本、二重実行防止、停止、処理済み案件の回復を説明できなければ自動実行へ進めない。作成者不在の演習が事前条件を満たさなければ、完全移管へ進めない。期限付きRPAは、終了日と置換先が失われた時点で再承認します。

この記事が提案するのはRPAの復権ではありません。業務を見直した後に残る処理を、確率的な解釈、明示規則、画面操作、正本状態、人の責任へ分け、候補の保守可能性を比較して組合せを選ぶことです。最初に測るのはRPAの成功率ではなく、例外の年齢、確認時間、停止の検知時間、手動継続できる件数、作成者不在で復旧に着手できる時間です。その結果が許容範囲を外れた工程だけを、共同運用、対象縮小、別方式、または停止へ戻します。

• 存在理由と正本：なぜ残し、何を確定状態とするか
• 実行構成：接続、操作、判断、待ち、承認を誰が担うか
• 停止と回復：どの失敗で止め、未処理と処理済みをどう扱うか
• 運用責任：誰が日常確認し、誰が変更、重大例外、再開を承認するか
• 移管証拠：作成者不在の演習日、結果、未達項目、次の是正日
• 廃止条件：置換先、終了日、累積保守費、例外増加をいつ見直すか