AIエージェントとRPAの違いは業務判断に出る
目次
RPAで自動化したはずの処理が、画面の小さな変更で止まる。担当者はエラー通知を見て、結局いつものExcelと管理画面を開く。
一方で、AIエージェントなら何でも自律化できるのかというと、そんなに都合よくはいかない。判断を任せるほど、ログ、権限、停止条件、レビューの設計が重くなる。
RPAとAIエージェントの違いは、単に「古い自動化」と「新しい自動化」ではない。分かれ目は、業務の中に判断があるかどうかだ。決まった手順を速く正確に繰り返すならRPAが強い。状況を読み、選択肢を比べ、人に確認しながら進めるならAIエージェントの領域になる。
AIエージェントとRPAの違いは判断の有無にある
RPAは、あらかじめ決めた手順を画面操作として再現する仕組みだ。請求データを開く、基幹システムへ入力する、ファイル名を変えて保存する、定型メールを送る。こうした作業は、人がやると退屈でミスも起きるが、ルールが固定できれば自動化しやすい。
日立ソリューションズのRPA解説でも、RPAは決められたルールや基準に沿って作業するものとして整理されている。ここは現場感と合う。RPAは「決まっている作業」を壊さず回すための道具だ。
だから、RPAを検討するときは最初にこう聞くとよい。
- 入力項目は毎回同じか
- 分岐条件を表にできるか
- 例外が出たら人に戻せばよいか
- 操作対象の画面やファイル形式は安定しているか
- 実行結果の正誤を機械的に判定できるか
この問いにほぼ「はい」と答えられるなら、AIエージェントを持ち出す前にRPAで十分なことが多い。むしろRPAのほうが説明しやすい。監査もしやすい。失敗したときの原因も追いやすい。
AIエージェントは判断を含む業務に向く
AIエージェントは、目的、文脈、利用できる道具を受け取り、次に何をするかを選ぶ仕組みだ。IBMのAIエージェント解説では、利用可能なツールでワークフローを組み立て、自律的にタスクを実行するシステムとして説明されている。
ここで大事なのは「自律」という言葉を雑に扱わないことだ。自律とは、好き勝手に動くことではない。与えられた範囲の中で、状況に応じて判断することだ。
たとえば営業事務なら、問い合わせ文面を読み、既存顧客か新規リードかを判定し、CRMを確認し、必要なら担当者に確認し、返信案を作る。これは単純な画面転記ではない。文面のニュアンス、過去の商談履歴、担当者の空き状況、送ってよい資料の範囲が絡む。
UiPathのAgentic Automation説明も、AIエージェントが環境を認識し、推論し、目標達成のために一連の行動を作る方向へ自動化が進んでいると説明している。RPAが消えるという話ではない。RPAで固定した手順の前後に、判断や調整を担う層が乗ってくる。
違いは「作業」ではなく「業務フロー」で見る
RPAとAIエージェントを比べるとき、ツール名から入ると迷う。先に業務フローを分解したほうが早い。
見るべき点は5つある。
- 入力: 構造化データか、メール、PDF、議事録、チャットのような非構造データか
- 判断: 条件分岐で足りるか、文脈理解や優先順位づけが必要か
- 実行: 画面操作だけか、複数システムをまたぐ調整か
- 例外: 例外時に止めればよいか、代替案を作る必要があるか
- 説明: 後から「なぜその判断をしたか」を説明する必要があるか
RPAは、入力から実行までが直線的な業務に強い。AIエージェントは、途中で「読む」「比べる」「確認する」「戻す」といった判断が入る業務に向く。
この違いは、AI導入で最初につまずく「何を自動化する？」問題の正体でも扱った論点と近い。自動化対象を作業単位で見ると、どれも自動化できそうに見える。ところが業務フローとして見ると、人が暗黙に判断している箇所が見えてくる。
RPAをAIエージェントで置き換えない
「AIエージェントが出てきたからRPAは不要」という見方は、少し雑だ。実務では置き換えより分担で考えるほうがよい。
たとえば、請求書処理を考える。
RPAに向くのは、確定した請求データを会計システムへ入力する部分だ。入力列、金額、取引先コード、保存先が決まっていれば、手順化しやすい。
AIエージェントに向くのは、その前後だ。請求書PDFを読み、発注書や契約条件と突き合わせ、金額や支払条件に違和感があるかを確認し、人に聞くべき論点を整理する。承認者の不在を見て代替フローを提案する。ここには判断がある。
Microsoft Copilot Studioの概要でも、エージェントとフローを組み合わせ、反復タスクや外部サービス連携を扱う構成が示されている。エージェントが全部を抱えるのではなく、決まった処理はフローや既存の自動化基盤に渡し、判断と調整 をエージェント側に置く。この分担が自然だ。
導入前に決めるべき境界
AIエージェントを業務に入れるなら、先に境界を決める。ここを曖昧にすると、便利そうなデモはできても、現場運用で止まる。
決めるべき境界は、最低でも次の6つだ。
- 何を読んでよいか
- どのシステムを操作してよいか
- どの条件なら人に確認するか
- どこまで自動実行してよいか
- 失敗時に何をログへ残すか
- 判断理由を誰がレビューするか
これはAIエージェントだけの話ではない。社内AIエージェントは権限設計からで書いたように、社内AIは「できること」を増やすほど、先に「してはいけないこと」を設計する必要がある。導入前の全体像は、AI社員とは?導入前に見る3つの違いもあわせて確認してほしい。
RPAは手順が固定されているぶん、権限境界を絞りやすい。AIエージェントは文脈を読めるぶん、許可範囲が曖昧になりやすい。だから、AIエージェントを導入するほど、権限、停止条件、確認フローの設計が要る。
監査しやすさはRPA、例外対応はAIエージェント
RPAの強みは、後から追いやすいことだ。どのステップで止まったか、どの画面で失敗したか、どの条件分岐に入ったかを比較的説明しやすい。大量処理や統制が必要な業務では、この説明しやすさが効く。
AIエージェントの強みは、例外対応だ。メールの文面が少し違う。添付ファイルの形式が変わる。前回の商談内容を踏まえて返信を変える。こうした揺れに対して、人間の判断に近い形で対応しやすい。
ただし、例外対応を任せるなら、監査の設計も一緒に置く。プロンプト、参照したデータ、使ったツール、出した判断、確認者、最終実行結果を残す。ここを省くと、AIエージェントの判断は「なんとなく動いたブラックボックス」になる。
生成AI PoCの成功基準は本番化の前に決めるでも同じことを書いた。PoCの段階で評価条件を決めないと、本番化の判断が感想になる。AIエージェントも同じだ。何をもって成功とするかを、実行前に決めておく。
使い分けのチェックリスト
導入前の整理として、次のように分けると判断しやすい。
RPAで始める業務:
- 画面操作や転記の手順が固定されている
- 入力データの形式が安定している
- 例外発生時は止めて人に戻せばよい
- 大量処理や監査性が優先される
- 成功条件を機械的に判定できる
AIエージェントを検討する業務:
- メール、議事録、PDFなど非構造データを読む
- 過去履歴や社内ルールを参照して判断する
- 複数システムをまたいで次の行動を決める
- 人に確認すべき論点を整理する
- 例外時に代替案やエスカレーションを作る
RPAとAIエージェントを組み合わせる業務:
- AIエージェントが判断し、RPAが確定済み手順を実行する
- RPAが処理し、例外だけAIエージェントが分類する
- AIエージェントが担当者に確認し、承認後にRPAへ渡す
- ログと成果物をCRMやSlackに残し、人間が最終確認する
この組み合わせが現実的だ。AIエージェントを「万能な担当者」と見なすより、判断、確認、実行、記録を分けて設計するほうが壊れにくい。
Atsumellの視点: 先に業務を仕様化する
AIエージェントとRPAの違いを決める作業は、結局、業務を仕様に落とす作業だ。
どこまでが定型作業か。どこからが判断か。判断にはどの情報が必要か。人に戻す条件は何か。実行してよい範囲はどこまでか。これらを言葉にしないままツールを選ぶと、導入後に「思ったより動かない」「怖くて任せられない」という状態になる。
Atsumellでは、AIエージェントを作る前に、業務フロー、権限、例外条件、評価条件を整理する。RPAで十分なところはRPAでよい。AIエージェントを入れるなら、判断の根拠と停止条件まで仕様化する。
RPAとAIエージェントの違いで迷ったら、ツール比較表を見る前に、業務フローを1本描いてみるとよい。直線で流れる作業はRPAへ。途中で人の判断が入る作業はAIエージェントへ。両方が混ざるなら、判断と実行を分ける。
その分解ができると、AI導入はかなり現実的になる。派手な自律化より、止めどころが分かる自動化のほうが、現場では長く使われる。
