「RPAはもう古い。これからはAIエージェントの時代だ」
最近、こうした話を聞く機会が増えたと思います。社内でRPAを回している会社ほど、「うちもそろそろ置き換えるべきか」と気になっているのではないでしょうか。
先に結論を書きます。AIエージェントは、RPAの上位版ではありません。受け持つ仕事の種類が違います。 RPAは「決まった手順を、決まったとおりに繰り返す」ための道具です。AIエージェントは「途中で判断が要る工程」を受け持つための道具です。
つまり、比べるべきは賢さではなく、置き換えようとしている仕事が、手順書に書き切れるかどうかです。ここを混同すると、RPAで十分に回る仕事に、高くて挙動の読みにくい仕組みを入れることになります。逆に、RPAで無理やり回してきた「例外だらけの仕事」は、エージェントに寄せると楽になる可能性があります。
以下は、当社が自社のマーケティングをAIエージェントで運用してきた範囲での整理です（2026年9月時点）。RPA製品やエージェント製品の比較ではありませんし、「置き換えたら何割減った」といった実測値もここでは出しません。自社の業務を仕分けるための問いとして読んでください。
まず、両者の動き方を並べてみます。
RPAは、人がパソコンでやっている操作を、そのまま記録して再生する仕組みです。「このシステムを開いて、この欄に、この表の値を貼り付けて、保存する」。手順が決まっていれば、疲れず、間違えず、何度でも同じように動きます。
その代わり、手順から外れたものに弱い。画面のレイアウトが変わった、入力元の表に想定外の空欄があった、取引先がいつもと違う書式で請求書を送ってきた。こういうとき、RPAは止まるか、黙って間違った値を入れます。
AIエージェントは、目的を渡されて、そこまでの道筋を自分で組み立てる仕組みです。「この問い合わせに返信案を作って」「この資料を読んで、要点を社内向けにまとめて」。途中で読む、比べる、選ぶ、書くという判断が入ります。
その代わり、毎回まったく同じ動きをする保証がありません。 同じ入力でも、出てくる文面は少しずつ違います。そして、間違えるときも、もっともらしく間違えます。
表にすると、こうなります。
| RPA | AIエージェント | |
|---|---|---|
| 得意な仕事 | 決まった手順の反復 | 読む・比べる・書くといった判断を含む工程 |
| 苦手なこと | 手順から外れた入力、画面の変更 | 毎回同じ結果を出すこと |
| 間違え方 | 止まる、または決まった箇所で同じように間違える | もっともらしい形で、毎回違う場所を間違える |
| 確認のしかた | 最初に動作を確かめれば、あとは例外の監視 | 出力のたびに、人が中身を見る必要がある |
いちばん下の行が、実務では大きな差になります。RPAは「作るまで」が大変で、動き出せば確認は軽い。エージェントは「作るのは速い」けれど、動いている間ずっと確認の手間がかかる。ここを見落として「エージェントのほうが柔軟だから」と置き換えると、確認の手間がどこかに湧いてきます。
見分け方は、二つの問いで足ります。
新しく入った人に、手順書だけを渡して任せられるかを考えてみてください。
手順書に書き切れる仕事は、RPA（または通常のシステム連携）の領域です。 わざわざAIに判断させる理由がありません。判断が入らない仕事に判断する仕組みを入れても、ぶれが増えるだけです。
手順書に書けるはずの仕事でも、実際には例外が多いことがあります。取引先ごとに書式が違う、担当者が手で直している箇所がある、「このお客さんだけは別の扱い」がある。
例外がたまにしか出ないなら、RPAで回して、例外だけ人に回せば済みます。問題は、例外のほうが本流になっている仕事です。RPAのシナリオが例外処理で膨らみ、少し条件が変わるたびに止まり、結局そのたびに人が直している。こういう仕事は、RPAで回していること自体が負担になっています。
この二つの問いを組み合わせると、だいたい次のように分かれます。
| 例外が少ない | 例外が多い | |
|---|---|---|
| 手順書に書ける | RPA・システム連携で回す | 例外の中身を見る。書式の違いを読み取る部分だけAIに任せる余地がある |
| 手順書に書けない | そもそも稀。まず手順化できないかを考える | AIエージェントの候補。ただし人の確認を前提に設計する |
右上のマスが、実はいちばん相談の多いところです。「RPAが止まって困っている」という仕事の多くは、全体を置き換えなくても、例外を読み取る一段だけをAIに任せ、あとはRPAで流すという組み合わせで片づくことがあります。全部をエージェントに置き換える前に、この形を検討してみてください。
仕分けを間違えたときの失敗は、方向によって違います。
RPAで済む仕事にエージェントを入れた場合。 毎回の出力を人が確認しなければならず、以前より手間が増えます。しかも、RPAなら起きなかった「たまにだけ違う値が入る」という、見つけにくい間違いが混ざります。定型の転記や集計は、判断が要らないぶん、ぶれが入ると困る仕事です。
エージェント向きの仕事をRPAで回し続けた場合。 シナリオが例外処理で膨らみ、保守できる人が限られていきます。誰かが異動した瞬間に止まる、という状態になりやすい。これは道具の性能ではなく、道具と仕事の組み合わせの問題です。
もう一つ、見積もりの段階で起きる混同もあります。AIエージェントの提案を受けたとき、その中身が実は「決まった手順の自動化」だった、というケースです。判断が入らない工程であれば、エージェントである必要はありません。見積もりの行に何が乗っているかは、AI導入の見積もりは、どの行に何が乗っているのかで整理しています。
仕分けの結果、エージェントに寄せる仕事が見つかったとします。そのときに先に決めておくべきことは、性能の比較ではありません。間違えたときに、どこで止めるかです。
当社は自社のマーケティングを、集客・教育・販売・計測の四つの工程に分けてAIエージェントで運用しています。そのうえで、外に出る直前には必ず人の承認を挟んでいます。AIが単独で公開・配信することはありません。どの工程をAIに任せ、どこに人を置いているかは私たちの働き方で公開しています。
任せるか人が持つかの線は、「間違えたときに取り返しがつくか」で引いています。社内向けの下書きは、間違えても直せば済みます。顧客に届くメールや公開される記事は、出てしまったら戻せません。この考え方は業務のAI化は「戻せる仕事」から始めてくださいとAIが書いたものは、誰がどこで確認するのかに詳しく書きました。
RPAにはこの設計がほとんど要りません。毎回同じ動きをするからです。エージェントを入れるということは、この確認の設計も一緒に引き受けるということです。 その手間を見込んだうえで、それでも例外処理に追われるより楽になるか。判断の基準はそこです。
いまRPAで回している仕事、またはこれから自動化したい仕事について、次の順に確認してみてください。
この中で最初にやるべきは、2です。例外の多さは、仕組みを作った人ではなく、毎日それを直している人しか知りません。
AIエージェントは、RPAを置き換えるための道具ではなく、RPAでは届かなかった仕事に手を伸ばすための道具だ、と私たちは考えています。自社のどの仕事をどちらに寄せればいいのか、一緒に仕分けたいときはお問い合わせからご相談ください。