AIエージェントとRPAの違い｜権限・例外・保守の3軸で使い分ける

「うちはもうRPAを動かしています。それでもAIエージェントは要るんですか」。導入のご相談で、いちばん多く受け取る問いです。

すでに動いている仕組みがあるほど、この問いは重くなります。止めれば現場が混乱し、放っておけば二重の投資になる。どちらへも振り切れないまま、判断だけが先送りになります。

この記事は、AIエージェントとRPA・ワークフロー自動化の違いを、手順を誰が組むかという1点から整理します。素材は公式資料と、運営元WEBMARKSの運用実測です。

案内役は3人です。若葉さんが言葉の意味から尋ね、大森部長が投資と体制の側から確かめ、鈴木さん（本誌監修）が答えます。

01AIエージェントとRPAの違いは、結局どこにあるんですか？

若葉さん

若葉さんの発言

どちらも「自動化」と呼ばれますよね。何が別物なんでしょう。

鈴木さん

鈴木さんの発言

台本があるかどうかだと思っています。台本どおりに演じるのがRPA、あらすじだけ渡されてその場で台詞を作るのがAIエージェントです。

結論は3点です。

1. RPA・ワークフロー自動化は、人が固定した手順を速く正確に繰り返す仕組みです。
2. AIエージェントは、目標だけを受け取り、状況に応じて手順を自分で組み直します。
3. 既存のRPA資産を止める必要はなく、例外処理と判断が要る境界にだけ足すのが実務上の使い分けです。

Anthropicは、あらかじめ書かれた経路で道具とLLMを動かす仕組みを「ワークフロー」と呼び、進め方まで自分で決める仕組みを「エージェント」として分けています（出典: Anthropic公式）。RPA・ワークフロー自動化は、この分類でいう固定経路の代表です。

呼び名が「自動化」で揃っているせいで、つい同じ棚に並べて優劣を比べたくなります。ただ、比べる軸は速さでも賢さでもありません。手順を書くのが誰か、その1点です。

02RPA・ワークフロー自動化は、AI導入の前から何をしてきた仕組みなんですか？

若葉さん

若葉さんの発言

RPAとワークフロー自動化は、そもそも別のものですか。

鈴木さん

鈴木さんの発言

つなぎ方が違うだけで、手順を先に決めておく点は同じです。画面をなぞるか、システム同士を直接つなぐか。分かれるのはそこだけです。

RPA（Robotic Process Automation）は、人があらかじめ決めた手順を、画面操作や定型入力の形でそのまま繰り返すソフトウェアです。Microsoftは、一度組んだ手順を毎回同じルールで実行し、疲れず判断もぶれない点をRPAの特徴として説明しています（出典: Microsoft公式）。

ワークフロー自動化（iPaaS・ノーコード連携）も、手順を固定する点では変わりません。違うのは接続の方法で、画面を操作する代わりにシステム同士をAPIやトリガーでつなぎます。「Aが起きたらBを実行する」という条件式で動く仕組みです。

いずれも、人が最初に手順を設計し、実行のたびに同じ経路をたどります。世の中には他にも多くの製品がありますが、本記事では代表例の名前を挙げるにとどめます。

03手順を誰が組むかで、AIエージェントとRPAの違いはどこまで広がるんですか？

Google Cloudは、AIエージェントを目標に向けて自律的に動き、道具と推論を使って作業を進めるソフトウェアと説明しています（出典: Google Cloud公式）。目標だけを受け取るという設計から、内部の動き方まで変わります。

AIエージェントの内部では、目標に届くまで次の5段が繰り返されます。

1. 目標を受け取る：達成したい状態と、触ってよい範囲を読む
2. 使える道具を確認する：接続済みのファイル操作・検索・外部サービスを把握する
3. 1手打つ：目的に近づく操作を1つ選んで実行する
4. 結果を読む：出力や差分が想定どおりかを判定する
5. 次の手を決める：合えば次へ、外れれば別の手順を試す

RPA・ワークフロー自動化にも複数の工程はありますが、順番と分岐条件はすべて事前に固定されています。実行中に「この手順のままでよいか」を判定し直す4と5にあたる段が、そもそも組み込まれていません。

差が表に出るのは、想定外が起きたときです。RPAは画面のボタン位置をもとに動くため、レイアウトが変わると次へ進めず処理を止めます。AIエージェントは想定外の出力を4で検知し、5で別の手順を試す余地を持ちます。ただし判定を誤る（ハルシネーション）こともあり、5で選び直した手順が常に正しいとは限りません。

04MCPでつなぐAIエージェントと、RPAのスクリプトの違いはどこですか？

MCP（Model Context Protocol）は、AIアプリと外部システムをつなぐ標準規格です（出典: MCP公式）。RPAが用途ごとに専用の画面操作スクリプトを組むのに対し、AIエージェントは接続済みのMCPサーバーから、そのつど必要な道具を選んで呼び出します。

手順を全部書く代わりに、道具を選ぶ行為そのものを預ける設計です。預けた分だけ書く量は減りますが、選べる範囲を最初に絞る仕事が新しく生まれます。減るのは作業で、増えるのは設計だと考えてください。

呼び方に惑わされない見方も要ります。RPAベンダーの中には、例外処理にAIを組み込んだ製品を出しているところもあります。その製品が想定外を検知して手順を自分で選び直しているなら、名前がRPAのままでも、実態は4と5を持つ側に寄っています。製品名ではなく、4と5があるかどうかで判定してください。

05権限・例外処理・保守で見ると、AIエージェントは何が変わるんですか？

大森部長

大森部長の発言

現場の使い勝手より、うちは保守が心配です。どちらが軽いのでしょうか。

鈴木さん

鈴木さんの発言

軽い重いというより、作り直す対象が入れ替わります。片方は手順そのもの、もう片方は渡す権限と指示の出し方です。

3つの対比軸を1つの表にまとめます。

保守の負担は、固定ルールで動く仕組み全般に共通する弱点です。運営元WEBMARKSには、固定ルールだけで判定する仕組みが3日間で233回誤って発火した記録があります。原因は、ファイルの更新時刻という手がかりを、状況によって読み違えたことでした（2026-07-10、社内タスク台帳の記録）。

壊れ方はもう1種類あります。書いたのに動いていない、という止まり方です。常駐の自動化ジョブは設計8本に対し、稼働していたのは1本でした（2026-07-28時点）。自動再開パトロールの最終実行日は2026-07-13で、実測の日まで15日が空いています。

固定ルールで動く仕組みは、前提が崩れても声を上げません。RPA・ワークフロー自動化も条件分岐を固定ルールで組む点は同じ構造なので、前提が崩れたときに気づける仕組みを別に持ちます。

権限の渡し方も、保守と切り離せません。渡す範囲を画面や特定のAPIに絞るRPAは、想定外の操作が起きにくい代わりに、対象が増えるたびに設定を作り直します。AIエージェントは接続済みの道具から都度選ぶため作り直しは減りますが、選べる範囲そのものを最初に絞る設計が要ります。

06いま動いているRPAを止めて、AIエージェントに置き換えるべきですか？

大森部長

大森部長の発言

置き換えたほうが将来的に得だ、という話も聞きます。判断はどこでしますか。

鈴木さん

鈴木さんの発言

止める理由が現場に無いなら、急ぎません。困りごとが出ている工程から順に足すほうが、投資も検証も小さく済みます。

置き換える前に、いま動いているRPA・ワークフロー自動化が安定しているかを確かめます。条件分岐の少ない定型業務で問題なく動いているなら、差し替える理由はありません。

Anthropicは、複雑さを足すのは、それが明確に成果を改善するときだけにすべきだと述べています（出典: Anthropic公式）。単純な仕組みで足りる業務にAIエージェントを足すと、判断の余地が増えるぶん検証の手間も増えます。

置き換えを検討する価値があるのは、次の状態にある業務です。

• 例外処理のたびに、人が手順書を書き直している
• 画面や連携先の仕様変更で、年に何度も手順が止まっている
• 定型から外れた入力が一定数混ざり、RPA・ワークフロー自動化では弾いて終わっている

どれも、あらかじめ書いた手順の外側に出た状態です。5段ループのうち、4（結果を読む）と5（次の手を決める）が、ちょうどこの領域を担います。

逆に、失敗しても実害が小さく手順も変わらない業務は、既存のまま置いておくほうが保守の対象を増やさずに済みます。置き換えないという判断も、同じ土俵の上にある選択肢です。

07請求書処理では、AIエージェントとRPAはどこで役割を分けるんですか？

重なるのは「決まった手順を繰り返す」という入口の工程です。分かれるのは、その手順から外れたときにどうするかです。

請求書処理で考えます。届いたPDFから金額・取引先・日付を読み取り、会計システムへ転記する部分は、毎回同じ手順で終わるためRPAに向きます。取引先ごとに書式が違う請求書や手書きの請求書が混ざると、この手順は止まります。

読み取れなかった請求書の扱いをAIエージェントが判断し、書式の違いを吸収したうえで同じ会計システムへ転記する。この分担なら実務で機能します。支払いの実行は金額を確定させる取り消せない操作なので、どちらの方式で処理した請求書でも人が確認します。

入口をRPA・ワークフロー自動化に任せたまま、出口と例外だけをAIエージェントに渡す。これが既存資産を捨てない使い分けです。どこまで任せてよいかは任せる・任せないの判断基準で、取り消せない操作を止める設計は承認ゲートの置き方で扱っています。

08うちの業務がAIエージェントとRPAのどちらに向くか、導入の前に何を見て決めるんですか？

使い分けを4つの判断基準に落とし込みます。

1. 手順を完全に固定できるか（できるならRPA・ワークフロー自動化が第一候補です）
2. 例外や表記ゆれの発生頻度は高いか（高いならAIエージェントを検討します）
3. 画面やAPIの仕様変更はどのくらいの頻度で起きるか（頻度が高いほど保守コストを比べます）
4. 失敗時の影響は対外的で取り消せないか（該当するなら、どちらの方式でも人間ゲートを置きます）

4つのうち1つでも「AIエージェントが向く」に偏るからといって、RPA・ワークフロー自動化をすぐ止める理由にはなりません。この基準は、既存の仕組みにAIエージェントを足す場所を決めるための材料です。

読む順番にもこつがあります。埋まっている区画ではなく、どちらとも言い切れない区画から読んでください。そこが、入口と例外で担当を分ける場所になります。

09RPAとAIエージェントを一緒に使うと、AI活用の現場で何につまずくんですか？

つまずきの典型は4つです。

• 同じフォルダやデータをRPAとAIエージェントの両方が書き換え、競合が起きる
• 既存のRPAを試すつもりで、権限を広く渡しすぎて画面操作の範囲まで奪う
• RPAが止まった原因を確かめず、AIエージェントに任せれば直るはずだと思い込む
• 例外処理をAIエージェントに任せたのに、送信・公開などの人間ゲートを設定し忘れる

最初のつまずきは、範囲を分けずに両方を同じ対象へ向けたときに起きます。RPAが監視しているフォルダへAIエージェントが書き込む前に、人へ確認させる設計が有効です。

{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "ask",
    "permissionDecisionReason": "RPAが監視するフォルダへの書き込みは人に確認します"
  }
}

Claude Codeは、ツール実行の直前に発火するPreToolUseフックを提供しています。settings.jsonのhooksにmatcher付きで登録し、判定はallow・deny・ask・deferの4つで返します（出典: Claude Code公式）。RPA・ワークフロー自動化が触る範囲をこの仕組みで見える化すれば、競合を実行の前に止められます。

10AI社員に任せる前に、RPAとの担当範囲はどう確かめるんですか？

担当範囲を分けたつもりでも、触っている対象が重なっていることがあります。確かめ方は、仕組みの名前で区切らず、触る対象で数えることです。同じフォルダ、同じ台帳、同じ受信箱を、両方が見ていないか。

項目には順番があります。前半は、いまの状態を数えるためのものです。数えないまま線を引くと、引いた線が現場の実感と合わず、結局どちらも中途半端に動きます。

後半は、これから決めるためのものです。足す範囲を境界に絞ったか、取り消せない操作を人の側に残したか、担当が重なっていないか。決めた内容は、次の担当者が読める場所に書いておきます。口頭の合意は、担当が替わった時点で消えます。

最後の1つは後回しにされがちです。変更の頻度を定期的に見る担当を決めておかないと、どちらの仕組みも「動いているはず」のまま放置されます。前章で見た、書いたのに動いていなかった常駐ジョブと同じ壊れ方です。

11よくある質問

12まとめ｜今日やる3つのこと

分かれ目は、手順を誰が組むかという1点でした。そこから権限・例外処理・保守の3軸へ広がり、実務での答えは置き換えではなく、書いた手順の外側に足すことでした。