RPAの技術基盤と現状

RPA（ロボティック・プロセス・オートメーション）は、ソフトウェアロボットによって人間のコンピューター操作を模倣する自動化技術です。RPAロボットは、システムへのログイン、データのコピー&ペースト、フォームの入力、レポートのダウンロードといった一定の操作フローを記録し、繰り返し実行できます。バックエンドシステムの改修やAPIインターフェースの開発は一切不要です。市場で広く使われているRPAプラットフォームには、UiPath、Automation Anywhere、SS&C Blue Prism、Microsoft Power Automateなどがあります。

RPAの核心的な強みは「非侵襲性」にあります。既存システムのUI層で動作するためバックエンド開発リソースを必要とせず、導入のハードルが比較的低く、短期間で大量の反復作業を自動化できます。過去10年間、RPAは企業のプロセス自動化で最も広く採用されてきたツールの一つであり、財務、人事、シェアードサービスセンターなど、帳票やレポートを中心とする部門で特に普及率が高い傾向にあります。ただし実際の採用率は企業によって大きく異なるため、単一の市場採用率の数字を当てはめるのではなく、自社業界の公開調査や同業他社へのヒアリングを参考にすることをお勧めします。

しかし、RPAには明確な限界もあります。RPAロボットは「ルール駆動型」であり、あらかじめ設定された固定フローしか実行できません。ボタンの位置が変わる、項目名が変更される、ポップアップウィンドウに確認ボタンが一つ増えるといった、アプリケーションのインターフェースへのわずかな変更でも、ロボットが失敗し、手動での再設定が必要になることがあります。さらに重要なのは、RPA自体には「理解能力」がないという点です。非構造化文書の内容を読み取ることも、例外的な状況に直面して柔軟に判断することも、文脈理解が必要なタスクを処理することもできません。実務上、RPAプロジェクトで最もよく直面する課題は保守負担です。業務プロセスやシステムインターフェースの変更頻度が、ロボットの再調整が必要になる回数を左右することが多く、このコストは導入評価の段階でしばしば過小評価されています。

AI Agentの中核的な相違点

AI Agentの設計思想は、RPAとは根本的に異なります。RPAが「ルールの実行者」であるのに対し、AI Agentは「目標の達成者」です。RPAへの指示は「Aボタンをクリックし、B項目をコピーし、Cシステムに貼り付ける」という形になりますが、AI Agentへの指示は「本日承認待ちの経費申請をすべて処理してほしい」という形になります。Agentはタスクの目標を自律的に理解し、実行手順を計画し、その過程で様々な例外に対処し、タスク完了後に結果を報告します。

AI Agentの中核となる技術的ブレークスルーは、3つの側面に表れています。第一に非構造化データの理解です。AI AgentはPDF、スキャン文書、メール本文、契約条項といった非構造化情報を読み取ることができ、これはRPAがほぼ手を出せない領域です。第二に文脈理解と例外処理です。プロセスの途中で想定外の状況（顧客の問い合わせが複数部門にまたがる、契約書に特殊な条項があるなど）が発生した場合、AI Agentは状況を理解した上で合理的な判断を下せますが、RPAは処理を止めて人手による対応を待つしかありません。第三に自然言語による対話です。ユーザーは決まった形式に従うことなく、自然言語でAI Agentにタスクを指示できるため、利用のハードルが大幅に下がります。

機能・能力の比較表

注：上表は技術特性の方向性を示す比較であり、固定的な仕様ではありません。実際の構築工数、保守負担、成功率は、プロセスの複雑さ、システムがAPIを備えているか、データ品質、ガバナンスの成熟度によって大きく変わるため、自社のプロセスで試作した実測結果を基準にすることをお勧めします。

どのプロセスがRPAに向き、どのプロセスがAI Agentに向くか

選定における第一の判断基準は、技術の新旧ではなく、プロセスそのものの「判断密度」です。あるプロセスの最初から最後まで、すべてのステップを明確なルールとして書き出せて、入力フォーマットが固定的で、例外がほとんどない場合、それはRPAの得意領域です。毎日決まった時間にレポートをダウンロードして変換する、Aシステムの固定項目のデータをBシステムに移す、アカウントを一括作成する、明細書のフォーマットを変換するといった業務です。このようなタスクにAgentを使うのはむしろ無駄であり、判断力を得られないまま不確実性だけが増します。

逆に、プロセスの中に「内容を理解して初めて次にどう動くかがわかる」部分がある場合は、AI Agentの出番です。メールと添付ファイルからクレームの種類と緊急度を判断する、契約書を読んで標準条項と異なる箇所を見つける、フォーマットが不揃いな複数の仕入先の見積もりを整理する、非構造化の申請内容を構造化された項目に変換するといった業務です。判断方法はシンプルです。新入社員向けのSOPを書こうとして、「状況による」「顧客が～と言及した場合は～」といった条件分岐だらけになるなら、そのプロセスは通常RPAの能力範囲を超えています。

中間領域は、処理を切り分けて対応するのが適しています。多くの企業プロセスは純粋なルールでも純粋な判断でもなく、「ルール→判断→ルール」というサンドイッチ構造になっています。現実的なやり方は、判断が必要な部分をAgentに任せ、その前後のデータ取得と書き込みはRPAまたは直接的なAPI呼び出しに任せることです。そしてその境界において明確なデータフォーマットを定義し（例えばAgentに固定されたスキーマのJSONを出力させるなど）、後段の処理が引き続き予測可能で機械的な操作であるようにします。

この2つの技術は失敗の仕方もまったく異なり、この点は機能リストよりも評価の際に注目すべきです。RPAの典型的な失敗は「脆性破壊」です。システムの改版、ブラウザの更新、ポップアップウィンドウに手順が一つ増えるといった変化で、ロボットは完全に停止します。良い点は、失敗が明白であり、すぐに気づけることです。AI Agentの典型的な失敗は「静かに間違える」ことです。一見もっともらしい結果を出力し続けるものの、誤った箇所を引用したり、金額の桁を読み間違えたり、複数ステップのタスクの途中で本来の目標からずれたりします。さらに、同じ入力でも必ずしも同じ出力が得られるとは限らないため、事後の監査と再現はRPAより困難です。そのためAgentを導入する際は、出力フォーマットの検証、重要項目のルールチェック、実行と推論の完全な記録、そして高リスクな操作（支払い、外部送信、データ削除）に対する人による確認ゲートを同時に構築する必要があります。

サプライヤーを評価する際は、検証可能な項目に質問を絞ることをお勧めします。このプロセスの成功基準はどう定義され、誰が検収するのか。失敗した際、システムはどうやって自らの失敗を認識するのか、停止するのか続行するのか。実行のたびに、確認可能な完全な履歴（どのツールを呼び出したか、どのデータを読んだか、何を根拠に判断したか）が残るのか。モデルやプラットフォームのバージョンが更新された際、既存のプロセスはどのように回帰テストされるのか。権限はどう分割され、Agentが触れられるデータの範囲は最小権限の原則で制限されているか。そしてプロセスの修正が必要になった際、IT部門、事業部門、サプライヤーのうち誰が担当し、どれくらいの時間がかかるのか。これらの質問への答えは、どんな比較表よりも導入後の実際の体験を予測する材料になります。

コストと導入の複雑さ

コスト比較では、「初期構築コスト」と「総保有コスト（TCO）」を区別する必要があります。RPAの初期構築コストは、バックエンドのAPI開発が不要なUI録画方式のため、通常AI Agentより低く、導入も速く進みます。しかし、RPAの長期的な保守コストはしばしば過小評価されています。保守工数の主な要因は、対象システムのインターフェースやプロセスの変更です。ERPの改版、Webフロントエンドの調整、フォーム項目の追加・変更のたびに、ロボットの再録画と回帰テストが必要になる可能性があります。この数字に汎用的な値はなく、ロボットの数、関係するシステムの数、それらのシステムが年に何回改版されるかに左右されます。見積もるには、他社の平均値を当てはめるのではなく、自社の変更履歴とチケットを振り返って確認する必要があります。

AI Agentの初期構築コストは、主にAPI連携のエンジニアリング、プロンプトとツールの設計、そして見落とされがちな評価・監査の仕組みの構築から生じます。すでに良好なAPIエコシステムを持つ企業であれば、統合コストは妥当な範囲に抑えられますが、システムが古くAPIを備えていない企業では、初期投資が大きくなります。Agentの運用コストは別の場所へと移ります。モデルの推論費用は利用量に応じて増加し、モデルやプラットフォームのバージョンが更新されるたびに出力品質の再検証が必要になり、ナレッジベースとプロンプトも継続的な保守が必要です。つまり必ずしも安くなるわけではなく、コストの中身が「インターフェースの修正」から「品質の維持」へと置き換わるのです。

他社の回収期間を引用するより、自社で簡単な3年間の試算をしてみることをお勧めします。少なくとも以下の項目を含めてください。両方式の構築工数（人月）と外部費用、年間の想定変更回数×1回あたりの対応工数、Agentの推論利用量と単価、例外案件のうち依然として人手対応が必要な割合とその人件費、そして監査・回帰テスト・教育訓練への固定投資です。これらを埋めていくと、多くの場合、転換点は2つの変数に大きく左右されることがわかります。対象システムが年に何回改版されるか、そしてプロセスのうち本当に判断が必要な割合はどれくらいかです。前者が高ければRPAに不利に、後者が低ければAgentは割に合わなくなります。最初から全社的な計画を立てるより、まず1～2つの代表的なプロセスで試作し、その結果を他のプロセスに外挿するほうがはるかに現実的です。

RPAからAI Agentへの移行パス

すでにRPAに投資している企業にとって、AI Agentへのアップグレードは「すべてを取り壊してゼロからやり直す」ことを意味しません。現実的な移行戦略は3段階で進めます。第一段階は「痛点の特定」です。既存のRPAロボットの保守ログを見直し、保守コストが最も高い、故障が最も頻発する、あるいは例外に対応できず大量の人手介入が必要になっているプロセスを洗い出します。これらがAI Agentによる置き換えの最優先候補になります。

第二段階は「並行構築」です。選定したプロセスについて、RPAロボットを稼働させたままAI Agentを構築し、まずAgentを「補助モード」で運用します（Agentが提案を出し、人が確認した上で実行する）。1～3か月分のパフォーマンスデータを蓄積し、Agentの精度と安定性が基準を満たしたことを確認したら、完全自動モードへ切り替えてRPAロボットを停止します。

第三段階は「適用範囲の拡大」です。AI Agentが保守コストの高いRPAプロセスの置き換えに成功したら、さらに一歩進んで、RPAがこれまでカバーできなかった領域を開拓します。非構造化文書の理解が必要な調達契約審査、複数システムをまたいだデータ統合が必要な業績分析、自然言語対話が必要な社員向けHRセルフサービスなどです。これらの領域の自動化は、RPA時代をはるかに超える生産性向上を企業にもたらします。

ハイブリッドアーキテクチャのベストプラクティス

多くの企業シナリオにおいて、RPAとAI Agentは二者択一の関係ではなく、協調して機能する補完的な技術です。典型的なハイブリッドアーキテクチャでは、AI Agentが「頭脳」として理解・計画・意思決定を担い、RPAロボットが「手足」としてAPIを公開できないレガシーシステムの操作を担います。例えば、AI Agentが受領した調達申請を分析し、調達ポリシーに適合しているかを判断し、最適な仕入先を算出したうえで、RPAロボットを呼び出して（API非対応の）旧式ERPシステムへの発注データ入力を完了させる、といった形です。

このハイブリッドアーキテクチャは製造業のシナリオでよく提案されます。一部の企業の生産管理システム（MES）やERPが比較的古いバージョンのままであったり、APIがあっても限定的な機能しか公開していなかったりする一方で、全面的なアップグレードにはコストとダウンタイムのリスクが伴うためです。このような場合、AI AgentとRPAを組み合わせる手法により、コアシステムを置き換えることなく部分的な自動化のメリットを先に得ることができます。ただし適用できるかどうかは、そのシステムのインターフェースの安定性と変更頻度を事前に確認する必要があり、そうしなければ脆弱な部分を先送りするだけになってしまいます。

ハイブリッドアーキテクチャを選択する際は、明確な役割分担の原則を確立することをお勧めします。APIに到達できるシステムは常にAI Agentが直接連携し、UI操作しかできないレガシーシステムはRPAが引き続き実行を担当します。同時に、AI AgentがRPAロボットの実行状況を監視できるようにし、RPAが失敗した際には自動でアラートをエスカレーションするか、代替フローに切り替えられるようにして、自動化フロー全体の信頼性を維持します。

境界の設計は、ハイブリッドアーキテクチャの成否を左右する要です。実務上は、AgentとRPAの間を明確なデータ契約として定義することをお勧めします。Agentは構造化された項目（例えば仕入先コード、金額、勘定科目、信頼度スコア）を出力することのみを担当し、RPAはその項目に従ってデータを入力することのみを担当し、双方とも相手の挙動を推測しません。契約には必須項目のチェックと数値範囲のチェックを含め、検証に通らない出力は一律に書き込み段階へ進まず、人手のキューへ回します。さらに、信頼度しきい値と金額しきい値による二重ルールを設けることをお勧めします。信頼度が低い、または金額が高い案件は一律に人による確認へ回し、実測結果の蓄積に応じて自動化の割合を段階的に広げていく方が、最初から全開にするより安全です。

可観測性についても、あわせて設計しておく必要があります。少なくとも、実行ごとの入力元、Agentがどのツールをどのパラメータで呼び出したか、生成された構造化出力、検証に通ったかどうか、最終的に誰が承認したかを記録し、その判断を再現できるだけの記録を残すべきです。こうした記録は、プロセスに問題が起きた際に根本原因を追跡できる唯一の手がかりであり、内部監査や情報セキュリティ部門から最もよく求められる要件でもあります。稼働後になってから補おうとすると、コストは通常はるかに高くつきます。