RPAの限界とAIエージェントへの移行——ルールベース自動化が崩れる5つの壁と次の打ち手

RPAが「使えなくなる瞬間」——現場で起きている3つの症状

RPAは、定型業務の自動化手段として多くの企業に普及しました。しかし導入から1〜2年が経過した段階で、「当初の期待ほど使えていない」という声が現場から上がり始めるケースは少なくありません。これはRPAそのものの失敗ではなく、ルールベースの自動化が持つ適用範囲の天井に到達したサインです。

以下の3つの症状は、その天井に差し掛かった企業が共通して経験するものです。

画面レイアウトが変わるたびに止まるロボット

RPAは画面上の要素の位置・名称・構造を記録し、その通りに操作を再現します。そのため、対象システムのUIがアップデートされると、ロボットは正しい操作対象を見失い、処理を停止させます。

基幹システムのバージョンアップ、SaaSツールの定期的なUI改修、あるいはExcelのテンプレート変更——こうした変化は業務上避けられません。その都度、担当者がロボットの設定を修正する必要があり、「止まるたびに直す」サイクルが常態化しているケースがあります。

例外処理のたびに人が割り込む構造

RPAが自動処理できるのは、あらかじめ想定されたパターンに合致するデータや手順に限られます。請求書のフォーマットが取引先ごとに異なる、申請内容に不備があって確認が必要、といった状況が発生した瞬間、ロボットは処理を中断し、人間の判断を待ちます。

例外が発生するたびに担当者が割り込み、手作業で対応して再開させる——この構造では、自動化の恩恵が例外の頻度に反比例して薄まっていきます。業務の複雑性が高い領域ほど、この問題は顕著に現れます。

保守・修正コストがROIを侵食していく現実

RPAの導入時に算出したROIは、多くの場合、保守コストを過小評価しています。ロボットの数が増えるほど、管理・監視・修正の工数も比例して増加します。専任担当者が不在の場合、情報システム部門がその負荷を吸収し続けることになります。

初期の削減工数と、その後の保守工数を通算すると、費用対効果が逆転しているケースも珍しくありません。RPAの「限界」は技術的な欠陥ではなく、ルールが固定されたシステムを変化する業務環境に合わせ続けることの構造的なコストとして現れています。

RPAの構造的な限界——なぜルールベースでは突破できないのか

RPAは「決まった手順を、決まった画面で、繰り返す」ことに特化したツールです。この設計思想そのものが、RPAの強みであると同時に、構造的な限界の根拠にもなっています。

RPAが得意なこと・苦手なことを仕分ける

RPAが安定して機能するのは、次の条件がすべて揃っている業務です。

• 入力データが定型フォーマットである
• 処理のルールが例外なく明文化できる
• 操作対象のシステム画面が変わらない

請求書の金額転記や受発注データの登録など、条件が安定している業務では高い精度を発揮します。一方で、これらの条件のいずれかが崩れた瞬間に、RPAは止まるか、誤処理を起こすかのどちらかになります。「できないこと」が発生する原因は、ツールの品質ではなく、ルールベースという設計の原理にあります。

非構造化データとイレギュラー判断——RPAが処理できない業務の実態

現場の業務には、ルールとして書き下せない判断が数多く存在します。たとえば以下のようなケースです。

• 取引先から届くPDFの請求書が、フォーマットごとに項目の位置が異なる
• メール本文に記載された納期変更の連絡を読み取り、基幹システムに反映する
• 担当者が口頭で把握している与信判断のルールを処理に組み込む

これらはいずれも、人間であれば文脈から意味を読み取って対応できます。しかしRPAは、あらかじめ定義された座標・キーワード・条件分岐の外側にある情報を解釈する機能を持ちません。非構造化データやイレギュラーな判断が介在する業務は、原理的にRPAの処理対象外です。例外処理の限界は、実装の問題ではなく構造の問題です。

仕様変更・組織変更のたびに発生するスクラップ＆ビルド問題

RPAのもうひとつの弱点は、変化への追随コストが高い点です。システムのUIが更新されると、ボタンの位置やフォームの構造が変わり、RPAのスクリプトはそのまま動かなくなります。業務プロセスの変更や組織改編が起きれば、ロボットの処理フローを一から組み直すケースも少なくありません。

導入時には「一度作れば動き続ける」という期待を持たれやすいRPAですが、実際には保守・改修のコストが積み上がり続けます。スクラッチで作り直すたびに工数と費用が発生し、現場の担当者がメンテナンス対応に追われるという状況は、多くの企業で共通して見られます。変化が多い業務環境ほど、RPAの維持コストは高止まりする構造になっています。

AIエージェントとRPAの違い——何が根本的に変わるのか

RPAからAIエージェントへの移行を検討する際、「AIのほうが賢い」という感覚的な理解だけでは判断の根拠になりません。両者の違いは、技術的な優劣ではなく設計思想そのものの違いです。以下の5つの軸で整理します。

RPAとAIエージェントの比較表——5つの判断軸で整理する

RPAが「決めたことをやり切る自動化」だとすれば、AIエージェントは「決まっていないことを考えながら進める自動化」です。この差が、例外処理や保守コストの悩みに直結しています。

LLMが「判断」を持つとはどういうことか

AIエージェントの中核には、LLM（Large Language Model：大規模言語モデル）が使われるケースが増えています。LLMは、膨大なテキストデータを学習することで、文脈を読んで「次に何をすべきか」を推論する能力を持ちます。

RPAが「条件Aなら処理B」という固定の分岐で動くのに対し、LLMベースのAIエージェントは「この状況はどう解釈できるか」「次のステップは何が適切か」を動的に判断します。事前にすべての条件をルールとして書き出す必要がないため、「ルールなき判断」が求められる業務——たとえば、内容が毎回異なるメール対応や、様式が統一されていない請求書の処理——にも対応できます。

ただし、LLMの推論は確率的であり、常に正解を出すわけではありません。だからこそ、設計の段階で「どこまでをAIに任せ、どこで人が確認するか」を決めておくことが重要です。

Human-in-the-Loop——AIが判断を人に委ねる設計という選択肢

AIエージェントの大きな特徴のひとつが、Human-in-the-Loop（人間参加型ループ）という設計の考え方です。AIが自信を持って判断できない場面や、ビジネス上のリスクが高い処理では、AIが自律的に完結させるのではなく、人に確認を求めるフローを組み込むことができます。

たとえば、契約金額が一定額を超える発注処理では、AIが内容をドラフトした上で担当者の承認を必須とする、といった設計が可能です。これはRPAには備わっていない柔軟性であり、「AIに任せきりにする」のではなく「AIと人が役割を分担する」という運用を実現します。

RPAからAIエージェントへの移行で変わるのは、ツールではなく自動化の設計思想そのものです。何をルールで縛り、何を推論に委ねるか——この判断がシステム設計の中心に来ることを、意思決定者として把握しておく必要があります。

AIエージェントが突破する5つの壁——RPAでは解けなかった業務の実例

RPAが「止まる」場面の多くは、非構造化データ・判断の連鎖・例外対応という3つの要因が絡み合っています。以下では、CLANEが実務で関与した事例を踏まえながら、AIエージェントがどのようにこれらを突破するかを5つのパターンで整理します。

メール・PDFの非構造化テキストを読んで処理する

RPAはあらかじめ決められた座標・フィールド・フォーマットを前提に動作します。そのため、差出人によって文面が異なる問い合わせメールや、レイアウトが統一されていない取引先のPDFを読み取ろうとすると、データの取得に失敗して処理が止まります。

AIエージェントはメール本文や非定型PDFを自然言語として読み込み、「この依頼は何を求めているか」「金額と納期はどこに書かれているか」を文脈から判断します。CLANEが関与した案件では、書式が異なる複数の取引先からの注文書PDFを読み取り、基幹システムへの転記までを自動化した事例があります。RPAでは対応フォーマットごとにシナリオを作り直す必要がありましたが、AIエージェントでは同一フローのままフォーマット差異を吸収できました。

複数システムをまたぐ判断と実行を一貫して担う

RPAは「Aシステムからデータを取得してBシステムに入力する」という直線的なフローは得意です。しかし、取得したデータの内容によって次の処理先が変わる場合、分岐ロジックを事前にすべて定義しなければなりません。分岐パターンが増えるほど、シナリオの複雑さは指数的に膨らみます。

AIエージェントは「この受注金額であれば与信確認が必要」「この顧客区分なら承認フローを挟む」といった判断を、文脈と業務ルールをもとに自律的に行います。CRMで顧客情報を確認し、ERPで在庫を照合し、承認が必要であればワークフローツールに起票する——という一連のフローを、複数システムをまたいで一貫して実行することが可能です。

例外が起きたとき自律的に対処する、または人に確認する

RPAの例外処理は「エラーが出たら止まる、またはアラートを投げる」が限界です。止まった業務を誰かが手動で拾い直す運用は、結果的に担当者の工数を増やす皮肉な状況を生みます。

AIエージェントは例外が発生したとき、その内容を解釈して対処方法を判断します。軽微な不整合であれば自律的に補完・修正し、判断が難しいケースであれば担当者にSlackやメールで確認を投げ、回答を受けてから処理を再開するという対話型のリカバリーが可能です。「止まる」のではなく「判断を人と分担する」設計に切り替えられます。

社内ナレッジを参照して回答・起票・転記まで完結させる

社内問い合わせ対応では、規程・マニュアル・過去事例といったナレッジを参照したうえで回答を生成し、必要に応じてチケットを起票するという一連の流れが求められます。RPAはテキスト生成や文書検索の機能を持たないため、この種の業務には本質的に対応できません。

AIエージェントはRAG（Retrieval-Augmented Generation：検索拡張生成）を用いて社内ドキュメントを参照し、質問に対して根拠のある回答を生成します。回答に加えて、問い合わせ内容をヘルプデスクシステムに起票したり、規程を参照して申請書の該当欄を転記したりといった後続アクションまで一貫して実行できます。

業務ルールの変更をプロンプト更新だけで吸収する

RPAでは業務ルールが変わるたびにシナリオを修正・テスト・リリースするサイクルが必要です。変更頻度が高い業務ほど保守コストが積み上がり、結果として「ルールが変わっても古いRPAをそのまま動かす」という運用リスクが生じます。

AIエージェントは業務ルールをプロンプトとして管理するため、ルール変更はプロンプトの書き換えで対応できるケースが多くあります。たとえば承認金額の閾値変更や、対応可能な問い合わせカテゴリの追加といった変更は、コードを書き直すことなく吸収できます。もちろんシステム連携の変更には別途対応が必要ですが、業務ロジックの変更に対する柔軟性はRPAと比較して大幅に高くなります。

移行の前に確認すべきこと——「全面切り替え」でなく「共存・段階移行」が現実解

全廃ではなく「RPA＋AIエージェント」の共存設計という考え方

RPAの限界が見え始めると、「いっそ全部AIエージェントに切り替えよう」という発想になりがちです。しかし、これは現実的ではありません。

RPAが本来得意とする領域——画面操作が固定されており、例外もほぼ発生しない完全定型業務——では、今もRPAは安定して機能しています。そこをわざわざ置き換えることは、コストと移行リスクを不必要に高める結果になります。

現実的なアプローチは、「RPAが確実に動く部分はそのまま残し、判断・例外処理・非構造化データが絡む部分だけをAIエージェントに置き換える」という共存設計です。RPAを「入力・出力の実行層」として活かしながら、判断が必要な箇所にのみAIエージェントを組み合わせる構成も選択肢の一つになります。

移行を検討すべき業務の見極め方——3つのチェック軸

どの業務をAIエージェントへ移行すべきかを判断するために、以下の3つの軸でセルフアセスメントしてみてください。

• ① 判断の複雑度：業務の中に「条件分岐が多い」「担当者が都度判断している」場面が含まれているかどうか。定型処理のみであればRPAで十分です。
• ② 例外の発生頻度：月に何件、ルール外のケースが発生しているかを確認します。例外が全体の5〜10%を超えている場合、RPAの保守対応が常態化している可能性があります。
• ③ 保守コストのROI悪化度：シナリオ修正・テスト・再リリースにかかる工数が、自動化による削減工数を上回っていないか。逆転しているなら移行の優先度は高いといえます。

3つのうち2つ以上に該当する業務は、AIエージェントへの移行を具体的に検討する段階に入っています。

段階的移行のロードマップイメージ

移行は一度に行う必要はありません。次のような段階を踏むことで、現場への影響を抑えながら進められます。

1. 現状の棚卸し：稼働中のRPAシナリオを「完全定型」「判断あり」「例外多発」の3種類に分類します。
2. パイロット対象の特定：例外発生頻度が高く、保守コストが嵩んでいる業務を1〜2本選び、AIエージェントで代替できるか検証します。
3. 共存フェーズの設計：パイロットで効果が確認できたら、RPAと並走させながら徐々に対象業務を拡張します。全廃のタイミングは、運用実績が積み上がってから判断します。

「RPAからAIエージェントへの移行」は、切り替えではなく段階的な役割の再配置として捉えることが、現場の混乱を最小化しながら移行を進める上で重要な視点です。

AIエージェント移行で生じる新たな論点——導入前に押さえておくリスクと設計思想

「AIエージェントを導入すれば、RPAの課題はすべて解決できる」という論調を見かけることがあります。しかし、CLANEが開発実務を通じて得た実感は少し異なります。AIエージェントへの移行は確かに大きな可能性を持ちますが、同時にRPAとは異なる種類のリスクと設計上の論点が生じます。意思決定者が「過剰な期待」ではなく「正しい期待値」で検討できるよう、導入前に押さえておくべき論点を整理します。

ハルシネーションと業務精度——誤出力をどう抑制するか

LLM（大規模言語モデル）を活用するAIエージェントは、文脈を読んで柔軟に判断できる反面、事実と異なる内容を自信を持って出力する「ハルシネーション」のリスクを持っています。

RPAは定義されたルール通りにしか動かないため、誤動作の原因は特定しやすいです。一方、AIエージェントの誤出力は出力結果を見るまで検知できないケースがあります。請求書の金額読み取りや契約書の条件抽出など、精度が業務に直結する場面では、出力をそのまま後工程に流すのではなく、検証ロジックや人による確認ステップを設ける設計が現実的です。

誰がAIの判断を承認するか——承認・監査フローの設計

AIエージェントが「判断」を行う以上、その判断に対して誰が責任を持つかを明確にする必要があります。たとえば、AIが自動生成した発注データや顧客への返信文を、そのまま外部に送信するフローは慎重に設計しなければなりません。

CLANEが開発に関わるシステムでも、AIエージェントの出力を業務の最終アクションに直結させず、承認者が内容を確認してから実行する「ヒューマン・イン・ザ・ループ」の構成を採用するケースが少なくありません。完全自動化を目指す前に、どのアクションに承認を挟むか、承認ログをどう保持するかを業務フローレベルで定義することが重要です。

社内データとLLMの境界——セキュリティと情報管理の論点

AIエージェントが社内システムのデータを参照・処理する場合、そのデータがどこに送信されるかを把握しておく必要があります。クラウド型のLLM APIを利用する構成では、入力したデータがモデルの学習に使われる可能性やログに残る可能性について、利用規約の確認が欠かせません。

また、LLMの利用量に応じてAPIコストが変動するため、処理件数が増えるほどコストが膨らむ構造も見落とせません。RPA導入時のライセンスコストと異なり、AIエージェントは「使うほど課金される」モデルが多く、費用対効果の試算には実際のトークン消費量をもとにしたシミュレーションが必要です。

これらの論点は、AIエージェント移行を否定するものではありません。しかし、設計の初期段階で想定しておかないと、導入後に運用コストの急増やセキュリティインシデントの遠因になりかねないため、RPA脱却・AI移行を進める上で事前に検討しておく価値があります。

まとめ——RPAの限界はAIエージェントへの移行タイミングのシグナルである

RPAの限界は、ツールの欠陥ではありません。「あらかじめ決まったルールを正確に実行する」という設計思想そのものの境界線です。例外処理の頻発、保守コストの膨張、人間の判断への依存——これらのシグナルは、業務がルールベースの自動化の適用範囲を超えたことを示しています。

その境界を超えた領域に有効なのが、AIエージェントです。非定型のデータを読み解き、文脈に応じて判断し、複数のシステムやツールを横断しながら自律的にタスクを完了する——RPAが「手順の実行」を担うのに対し、AIエージェントは「目的の達成」を担います。この違いが、両者の使い分けを決定づけます。

ただし、現実的な移行は段階的・共存的なアプローチが基本です。定型業務はRPAで継続し、例外処理や判断が介在する業務からAIエージェントに切り替えていく進め方が、リスクとコストの両面で合理的です。「全面切り替え」を前提にすると、現場の混乱や投資の無駄を招きやすくなります。

また、移行にあたっては精度の担保、ハルシネーションへの対処、既存システムとの接続設計、ログと監査の整備など、RPA導入時とは異なる論点の整理が先決です。技術選定より先に、業務設計と運用設計を固めることが成否を分けます。

CLANEは、定型業務の自動化からナレッジワークの自律実行まで、幅広い業務領域を対象としたAIエージェントの設計・開発を手がけています。RPAの脱却やAIエージェントへの移行を検討する際、設計思想の段階から伴走できる体制を持っています。