「AIエージェントが出てきたから、もうRPAはいらない」——ここ最近、現場でよく聞くようになった言葉です。
私も業務自動化の相談を受けるたびに同じ問いにぶつかります。結論から言うと、私の答えは「RPAは死んでいない。ただし役割は変わった」です。この記事では、実際に両方を現場に入れてきた立場から、RPAとAIエージェントをどう棲み分け、どう併用するかを判断基準つきで整理します。対立ではなく、組み合わせの話です。
「RPAはもう古い」と言われるのはなぜか
RPAが不要論を言われる理由ははっきりしています。RPAは「画面の座標とルールをなぞる」自動化なので、入力が少しでも揺らぐと止まるからです。
私が自治体向けの報告書提出を自動化したときも、まさにここでハマりました。Webフォームに毎月50項目を手入力する作業を、Playwrightでブラウザ自動化して3時間→10分に短縮できたのですが、翌年フォームのUIが変わった瞬間にスクリプトが全滅しました。原因は要素の指定をCSSセレクタに頼っていたことで、data属性ベースに書き換えて事なきを得ました。
# UI変更に弱い書き方（class名は変わりやすい）
page.click(".btn-primary.submit-form")
# UI変更に強い書き方（data属性は変わりにくい）
page.click("[data-testid='submit-report']")
この「揺らぎに弱い」という弱点を、AIエージェントは自然文や多少のレイアウト変化を吸収して埋めてくれます。だから「RPAはAIに置き換わる」という話が出るわけです。でも、私はこの整理は雑すぎると感じています。
RPAとAIエージェントは、そもそも土俵が違う
両者は競合技術ではなく、得意な入力の性質が違うだけです。手元で両方を運用してきた実感を表にまとめると、こうなります。
| 観点 | RPAが向く | AIエージェントが向く |
|---|---|---|
| 入力 | 構造化・定型（CSV・固定フォーム） | 非構造化・ゆらぎ（自然文・画像・雑多なメール） |
| 判断 | ルールを明文化できる | 都度の判断・例外処理が要る |
| 出力 | 決定論的（毎回まったく同じ） | 文脈依存（毎回変わりうる） |
| 実行コスト | 安い（推論不要） | 推論コストがかかる |
| 監査・再現性 | ログが厳密で再現可能 | 出力の検証が別途必要 |
| 変更への強さ | 画面・仕様変更に弱い | 多少の揺らぎを吸収する |
この表を一言でまとめると、**「決定論的な作業はRPA、判断を伴う作業はAIエージェント」**です。この軸で切ると、現場の判断がかなり楽になります。
RPAに任せたほうがいい領域
「AIでやったほうが賢そう」に見えても、RPA（スクリプト自動化を含む）のほうが確実な領域があります。私が実際にRPA側に倒した例を2つ挙げます。
1. 毎日決まった時刻に走る定型バッチ。 ある現場で、毎朝9時に担当者が手動実行していた日次集計バッチが、その人の体調不良で3日間止まり月次レポートに影響が出たことがありました。私はこれをcronに載せ替えただけです。判断は一切要らず、失敗時だけSlackにアラートを飛ばす構成にしました。
# 毎朝9時に日次集計を実行し、失敗時はログ付きで通知
0 9 * * * /opt/batch/daily_aggregate.sh || /opt/batch/notify_slack.sh "集計バッチ失敗"
導入後3ヶ月、遅延も漏れもなく安定稼働しています（＝手動オペレーションの発生回数がゼロになった、という測り方です）。ここにAIエージェントを噛ませる意味はありません。入力も手順も固定で、判断がゼロだからです。推論コストを払うだけ損になります。
2. 構造化データの転記・入力。 前述のフォーム入力（3時間→10分）もこの типです。CSVという構造化された入力を、決まった項目に流し込むだけ。ここで大事なのは「毎回まったく同じ結果になる」再現性で、これはRPAの独壇場です。むしろAIに任せると、たまに気を利かせて余計な変換をしてしまうリスクがあります。
AIエージェントに任せたほうがいい領域
逆に、RPAでは書ききれない「判断」がボトルネックになっている業務は、AIエージェント側に倒します。
1. 分類と振り分け。 カスタマーサポートの初回応答が平均8時間かかっていた現場では、遅延の原因が「問い合わせの分類と担当者アサイン」に人手がかかっていたことでした。ここを内容のキーワード分析で自動分類し、適切な担当者に自動アサインする仕組みに変えたところ、初回応答時間が8時間→1.5時間に短縮しました。「どの箱に入れるか」の判断は、ルールを全部書き出すのが難しく、AIの判断が効く領域です。
2. 文脈に応じた文面の生成。 営業のフォローアップメールを、案件ステータスをトリガーに自動で下書き生成する仕組みを入れたことがあります。ポイントは**「下書きまで自動、送信は人間」**にしたことで、送り忘れがゼロになり成約率が15%向上しました（社内の月次成約データで前後比較）。文面は案件ごとに文脈が変わるのでAIが下書き、最終判断は人間が握る——この線引きが効きました。
ここで重要なのは、AIエージェントを入れるときも**「判断の外側は人間が承認する」**設計にしていることです。決定論でない以上、出力の検証と承認をセットにしないと現場では怖くて使えません。この承認フロー設計は別記事に詳しく書いています。
棲み分けの判断フロー — 「決定性」で切る
では、目の前の業務をどちらに振るか。私は次のチェックリストで判断しています。上から順に見て、1つでもNoが出たらAIエージェント寄り、全部Yesなら迷わずRPAです。
- 入力は構造化されているか（CSV・固定フォーム・DBなど）
- 手順を最後まで明文化できるか（曖昧な判断が挟まらないか）
- 出力は毎回同じであるべきか（再現性が価値になるか）
- 実行頻度が高く、推論コストを避けたいか
- 監査ログの厳密さが求められるか
このチェックの前提として、業務を工程に分解するステップが欠かせません。以前、属人化した月次決算を引き継ぐために全手順を72ステップに分解したことがあるのですが、この分解をやって初めて「どのステップが決定論的で、どのステップに判断が要るか」が見えました。RPAかAIかの二者択一で悩む前に、まず業務を工程まで割ることをおすすめします。多くの場合、答えは「片方」ではなく「工程ごとに使い分け」になります。
実際は「併用」が一番強い
現実の業務は、決定論の工程と判断の工程が混ざっています。だから私が組む自動化はほぼ全部ハイブリッドです。典型的な流れはこうです。
- 入口（RPA）: フォームやメールから構造化データを取得・整形する
- 中間（AIエージェント）: 内容を分類・判断し、必要な文面や振り分けを生成する
- 出口（人間 or RPA）: 人間が承認し、確定後はRPAが決まった宛先へ確実に流し込む
先ほどのサポート業務も、実際は「問い合わせ取得（定型処理）→分類・回答案生成（AI）→送信（人間承認後に定型送信）」という3層でした。RPAを捨ててAIに全部やらせると、決定論であるべき送信部分まで揺らいでしまう。逆にAIを入れないと、分類のボトルネックが残る。両方を層で分けるのが、いま一番コスパの良い設計だと感じています。
まとめ
- RPAは死んでいない。**決定論的な作業（定型入力・定時バッチ・厳密な監査）**では今も最強
- AIエージェントは判断・分類・非構造化入力で真価を出す
- 迷ったら「決定性で切る」——手順を最後まで明文化できるならRPA、判断が挟まるならAI
- 現実の業務は工程を分解して併用するのが一番強い
結局のところ、私にとってこの問いは「RPA vs AIエージェント」ではなく、「この工程は決定論か、判断か」という一段細かい問いに置き換わりました。ツールを敵味方で分けるのをやめて、工程を性質で分ける。そう考えるようになってから、自動化の設計で迷う時間が目に見えて減りました。RPAという枯れた技術を、AIの時代にどう活かすか——それを考えるほうが、置き換え論よりずっと生産的だと思っています。
私はこの「決定性で切る」やり方に落ち着きましたが、現場ごとにもっと良い線引きがあるはずです。みなさんは、RPAとAIエージェントの棲み分けをどんな基準で判断していますか？ 「この工程はAIに任せて失敗した／成功した」という実例があれば、ぜひコメントで教えてください。