RPA と Agent の使い分け・移行戦略

この記事の目的

既存の RPA(ロボティック・プロセス・オートメーション)資産を持つ組織が、AI AgentLLM を判断の中枢に置き、ツールを使いながら、目標達成までの手順を実行時に自律的に決めて実行するシステム。 との使い分け・共存・段階的移行を判断できるようになります。両者の特性の違い・それぞれが壊れる場所・共存パターン・移行の優先順位付け・運用統制の引き継ぎを、製品選定に踏み込む前の判断軸として持ち帰れる状態を目指します。

対象読者

• すでに RPA を運用しており、AI Agent の導入・置き換えを検討している業務部門・情報システム部門・RPA 開発者
• 「RPA を全部 Agent にすべきか」を問われて、切り分けの軸がほしい PM・テックリード

前提知識

• Workflow 型 vs Agent 型の使い分け — 決定的な手順と適応的な判断の使い分け(本記事の商流版)
• ユースケース発見と要件定義 — どの業務を自動化対象に選ぶかの判断

本文

概要: 「RPA を全部 Agent に」は問いの立て方が間違っている

RPA は、画面操作や API 呼び出しなどを事前に定義したフローで実行する自動化です。記録・再生は作成方法の 1 つで、条件分岐やセレクターを使う実装もあります。一方 AI Agent は、モデルが状況に応じて実行する手順を選ぶ構成です。どちらも対象システムの状態や入力に影響されるため、フローが固定されていても実行成功や同一結果を保証しません。

この 2 つは対立技術ではなく、得意な場所が違う道具です。全面置き換えの効果は業務と実装で変わるため、費用・成功率・保守負担を比較します。正しい問いは「どの業務のどの部分を、どちらに任せるか」です。以下では、その切り分けの軸を整理します。この判断はWorkflow 型 vs Agent 型の使い分けの考え方を、既存の RPA 資産がある現場に当てはめたものです。

特性比較

• 保守コストの構造が違う: RPA の保守コストは「対象画面が変わるたびに直す」形で発生します。Agent の保守コストは「意図どおり判断できているかを評価し続ける」形で発生します。どちらもゼロにはならず、負担の性質が違うことを前提に総保有コストを見ます
• 確実性を捨てられない業務に注意: 会計・決済・在庫更新のように、毎回同じ結果でなければ困る処理は、確率的な Agent に丸ごと任せるべきではありません。判断は Agent、確定的な実行は決定的な仕組み、と分けます

RPA が壊れる場所と Agent が揺れる場所(相補性)

両者の弱点には重なりもあります。対象業務で失敗する箇所を分けて観測し、組み合わせる価値を評価します。

• RPA が壊れる場所: 対象システムの画面レイアウト変更、想定外のダイアログ、入力データの表記ゆれ。座標・文言に依存する実装では変化で止まる場合があります。セレクターや API を使う実装でも依存先の互換性確認は必要です。例外処理の追加による保守負担も測ります
• Agent が揺れる場所: 同じ入力でも出力がぶれる、判断を誤ってももっともらしく続行する、コストが読みにくい。Agent は「意図で吸収できる」代わりに、確実性の保証が構造的に弱いです
• 相補性: 表記ゆれや例外の判断候補は Agent が提示し、確定した処理の事前定義された実行手順は RPA・API が担う、という分担を検討します。どちらも誤認・実行失敗に備えて結果を検証し、例外時の引き取り先を決めます

共存パターン

全面置き換えではなく、次のような共存が実務的です。既存 RPA 資産を活かしながら、判断が要る部分だけを Agent 化します。

図を元の大きさで表示

図の中をスクロールして読めます。キーボードでは図の領域へ Tab で移動し、矢印キーを使います。読み終わったら、この見出しをもう一度選ぶと閉じます。

• パターン 1: RPA の中の判断ステップだけ LLM 化: 既存の RPA フローはそのまま使い、その中の「人が目視で判断していた 1 ステップ」(書類の分類・記載内容の妥当性チェックなど)だけを LLM 呼び出しに置き換えます。導入リスクが小さく、効果を測りやすい始め方です
• パターン 2: Agent が RPA をツールとして呼ぶ: Agent が業務全体を判断・オーケストレーション複数の LLM 呼び出しや Agent の実行順序とデータの流れを制御すること。直列・並列・ルーティングなどの定番パターンがある。し、確定した定型処理は既存の RPA を「ツール」として呼び出す構成です。RPA 資産を捨てずに、判断の柔軟性を上から足せます(Workflow 型 vs Agent 型の使い分けのオーケストレーション)
• どちらも「決定的な部分は決定的なまま」: 共通するのは、確実性が要る処理を Agent の確率的判断に溶かさないことです。Agent は判断・接着に使い、実行境界に権限・入力検査・重複防止・結果照合を残します。RPA/API も失敗しうるため、外部処理の結果不明を成功とみなしません

移行の優先順位付け

限られた予算で移行するなら、保守負債が大きく・判断で楽になる業務から着手します。

• 画面操作依存で壊れやすい RPA を優先: 対象システムの画面変更で頻繁に止まる RPA は、保守コストが高く、API や Agent の柔軟な操作(ブラウザ・コンピュータ操作の実装)で楽になる余地が大きい候補です。ただし computer use 自体もまだ発展途上のため、まずは API 化を優先し、画面操作は最後の手段にします
• 例外処理が肥大した RPA を優先: 分岐と例外対応でスクリプトが複雑化した RPA は、判断を Agent に委ねる案と、フローの整理や API 化を比較します
• 確実性が最優先の業務は後回し(または対象外): 会計確定・決済のような処理は、Agent 化の効果より確実性の低下リスクが上回りがちです。急いで移行しません
• 効果測定をセットにする: どの移行も、ユースケース発見の成功基準を先に決め、移行前後で保守コスト・処理時間・エラー率を比較します

RPA と Agent を統合する製品の確認例

UiPath Maestro の公式概要 は、ロボット・エージェント・人を含む業務プロセスのオーケストレーションを説明しています(確認日: 2026-09-10)。これは統合製品の一例であり、すべての RPA ベンダーが同じ提供範囲・統制機能を持つという意味ではありません。

製品選定では、次を個別の公式仕様・契約・試験で確認します。

• 既存ロボットや API を呼べるか、失敗・結果不明・再試行をどう扱うか
• 人の承認、実行権限、監査ログがどの単位で適用されるか
• クラウド・閉域網インターネットから物理的・論理的に隔離され、外部 API に到達できないネットワーク。クラウド型の AI コーディングエージェントは通信自体が通らず原理的に使えない。真の air-gapped 運用は、OSS エージェント + ローカル/自社ホストモデル(外部送信ゼロ)でのみ成立し、監査・SSO などの統制は運用側で担保する。・自社運用のどこで推論し、データがどこへ送られるか
• 利用可能なモデル、他社エージェントとの連携範囲、プラン・地域による差は何か
• 開発・実行・推論・監査保存を含めた費用を自社の処理量で見積もれるか

本記事の共存パターンは設計案です。製品のデモを見た後も、自社のデータ経路・結果の整合性・統制要件を満たすかを PoC本番導入を判断するために必要な「問い」を、期間を区切って検証する使い捨て前提の試作。デモの成功ではなく、本物のデータ分布での測定結果を成果物とする。 で評価します。

2026-09-10 時点では、製品名だけでなく 機能・実行基盤・版・期限を次のように分けて確認します。

これらは選定時に確認する差分の例です。WorkHQ の 2025.25 以前の同梱部品は既にサポート対象外と公式告知に記載されており、9 月末の対象版以外なら保守されるとは判断できません。

統制の引き継ぎ(運用統制・監査)

RPA には長年かけて作られた運用統制(誰が・いつ・何を実行したかの記録、承認フロー、変更管理)があります。Agent 化でこれを失うと、統制の後退になります。

• 監査証跡を引き継ぐ: RPA の実行ログに相当するものを、Agent でも残します。何を入力に・どう判断し・どのツールを・どう実行したかのトレース(可観測性とトレーシング)を、既存の監査要件に合う粒度で確保します
• 承認フローを維持する: RPA で人の承認を挟んでいた重要操作は、Agent でもHuman-in-the-Loopとして承認点を残します。自律度を上げる判断は、統制の要件とセットで行います
• 変更管理を移植する: RPA の「変更時のレビューとテスト」に相当する運用を、プロンプト・ツール・モデルの変更に対しても用意します(回帰テストと CI 組み込み)。RPA が依存先の変更で影響を受けることに加え、Agent はモデル更新でも挙動が変わるため、変更管理の対象が増えます
• 権限を絞る: RPA ロボットに広すぎる権限を与えていた場合、Agent 化はそれを見直す好機です。実行アカウントの権限を業務に必要な最小限に絞ります(エージェントの認証・認可)

実務での注意点

アンチパターン

チェックリスト

関連トピック

• Workflow 型 vs Agent 型の使い分け — 決定的な手順と適応的な判断の使い分け(本記事の基盤)
• ブラウザ・コンピュータ操作の実装 — 画面操作を Agent に行わせる場合の実装と限界
• ユースケース発見と要件定義 — 移行対象業務の選定と成功基準
• Human-in-the-Loop 設計 — RPA の承認フローを Agent に引き継ぐ設計
• 可観測性とトレーシング — RPA の実行ログに相当する監査証跡
• エージェントの認証・認可 — ロボット権限の最小化
• 企業システム環境の制約と対応 — 閉域網・データ経路要件(ベンダー選定の観点)

参考資料

• UiPath Maestro, Overview  — Agent、ロボット、人を統合するオーケストレーションの公式実装例。製品横断の普及率や精度の根拠にはしません(アクセス日: 2026-09-10)

• WorkHQ Announcements  — GA と部品別保守期限(アクセス日: 2026-09-10)

• Maestro 2.2510.2  / クラスタ構成  — 自己ホストと TaaS の配置(アクセス日: 2026-09-10)

• Copilot Studio computer use  / harnesses  / agent flows  — モデル別の提供状態とフローの違い(アクセス日: 2026-09-10)

• NTT-AT 2025-09-04 告知  / WinActor V7  — AI 連携条件と現行機能(アクセス日: 2026-09-10)

• Automation Anywhere 2026-05-19 発表  — 機能別 GA / preview / 予定(アクセス日: 2026-09-10)

TODO・未確認事項