この記事の要点
- 判断の柔軟性とシステムの操作手段を分けて考える
- 既存RPAやAPIをAIと併用する選択肢を持つ
- 画面変更・曖昧な指示・重複実行まで試す
- 入力の変動を確認
- 判断方法を選ぶ
- 実行手段を選ぶ
- 例外を検証
違いは「賢さ」より、処理の決め方にある
RPAは、業務ソフトやブラウザー上で繰り返す操作を自動化する方法です。Microsoftのデスクトップフローも、こうした反復操作の自動化を説明しています。入力条件や画面が安定し、手順を明確に決められる処理では、既存のRPAが有力な選択肢になります。
AIエージェントは、目的と状況に応じてモデルが次の処理や利用する機能を選ぶ構成を指すことがあります。一方、AIを呼び出していても手順を固定しているシステムはあります。製品名に「AI」があるかではなく、どこが柔軟に変わり、どこが固定されるかを確認してください。
なお、現在のRPA製品にもAI機能やAPI連携があります。両者を排他的な製品カテゴリと考えると比較を誤ります。本記事は実装方式の使い分けを整理するもので、特定製品の優劣を示すランキングではありません。
4つの軸で比較する
| 検討軸 | ルール・RPAを軸にする候補 | AIを加える候補 |
|---|---|---|
| 入力 | 形式が固定された項目 | 自由記述、メール、表記揺れ |
| 処理順序 | 同じ条件なら同じ順序 | 状況で追加調査が変わる |
| 求める出力 | 厳密な計算・定型登録 | 分類候補、要約、回答案 |
| 例外 | ルールで判別できるもの | 内容を読まないと分からないもの |
たとえば取引先コードから金額を集計する部分は、データベースや通常のプログラムで処理できます。メールの「先週と同じ条件で」という依頼を解釈する部分にはAIを検討できますが、参照すべき注文が一つに決まらない場合は人へ確認を返します。
AIを使うべきかという問いと、画面操作でつなぐべきかという問いも別です。システムに安定したAPIがあるなら、AIの判断結果を検証してAPIで実行できます。APIがない部分にRPAを使う構成も可能ですが、画面変更時の保守を見積もる必要があります。
受注登録なら「読む・確かめる・登録する」を分ける
以下は当社の構成案です。注文メールをAIが読み、商品候補・数量・納期を整理します。その後、商品マスタと取引条件を通常のプログラムで照合します。不一致がなければ承認画面へ渡し、承認済みデータをAPIまたはRPAで登録します。最後に登録番号を取得して元の依頼と結び付けます。
重要なのは、AIの文章をそのまま画面へ貼り付けないことです。数量は数値、商品は許可されたコード、納期は日付として検証します。自由文に含まれる指示で登録先や処理範囲が変更されないよう、実行機能を限定します。
画面操作が失敗した際は、登録が完了しているのか不明な状態を区別してください。同じボタンを押し直す前に登録済みかを確認し、判別できなければ担当者へ渡します。この部分はモデルの性能を上げるだけでは解決しません。
選定前に、成功例と同じ数だけ失敗条件を考える
- 注文書のレイアウトが変わった場合、必要項目を正しく取得できるか。
- 同じ名前の商品が複数ある場合、勝手に確定せず確認へ回せるか。
- RPAの処理途中で画面が切り替わった場合、誤った登録を止められるか。
- 登録直後に通信が切れた場合、二重登録を防げるか。
- 業務と関係のない命令が添付文書に書かれていても、実行されないか。
- 担当者が不在のとき、未処理の理由と期限を別の人が把握できるか。
これらは推奨する検証項目であり、すべての会社に同じ合格率を当てはめるものではありません。誤登録が後工程へ与える影響によって、許容条件と人の確認範囲を決めます。
比較試験：同じ業務で二つの構成を試す
既存RPAが稼働している場合、全面刷新案だけでなく、入力の読み取りにAIを追加する案を比較します。対象の入力と完了条件を同じにし、既存方式、AIを追加した方式の双方で、担当者の確認・修正まで記録します。
例として、注文メールから転記する処理を考えます。定型メール、表記が異なるメール、必要項目が欠けたメールを用意し、それぞれで正しい注文に結び付くかを確認します。AIが欠けた値を推定して埋めるのではなく、不足として人へ返せるかも比較します。
比較表には処理時間と費用だけでなく、原因が分かるまでの調査時間を入れます。失敗時に入力・判断・操作のどこで止まったか追えない構成は、日常運用で負担になり得ます。画面変更が発生したときの修正手順も候補会社へ実演を依頼します。
対象の件数や例外の比率を明示し、短い試験で出た結果をそのまま全社へ当てはめないようにします。選ぶのは「AIらしい構成」ではなく、自社の入力条件と保守体制で続けられる構成です。
ライセンス費以外の運用負担も比べる
比較する費用は、ライセンス、開発、モデル利用料だけではありません。画面変更の修正、マスタ更新、例外の確認、利用者対応、テストの継続を含めます。既に動いているRPAを全面刷新すると、作り直しと再教育が必要になる場合もあります。
まず処理が止まる原因を分けましょう。入力形式の揺れが原因ならAIを試す余地がありますが、マスタの不備や承認者の不在が原因なら、先に業務ルールを直す方が効果的かもしれません。技術の追加が必要とは限りません。
発注時は「AIエージェント一式」ではなく、読む範囲、判断する範囲、操作する範囲、保守する範囲を明記します。RFPの整理表と既存システム連携の設計を使うと、候補各社に同じ前提を伝えられます。
参考にした一次情報
- Microsoft Learn「Introduction to desktop flows」
デスクトップ上の反復操作を自動化するRPAの説明を参照。
- Anthropic「Building effective agents」
あらかじめ決めた処理経路を使うワークフローと、モデルが処理を選ぶエージェントの区別を参照。
参照日: 2026年10月1日。リンク先の説明は機能・設計原則の確認に用いています。本記事の業務例や推奨する進め方は当社の提案であり、引用元が当社サービスや効果を保証するものではありません。
既存のRPAを活かしたAI実装も、ご相談いただけます。
現在の業務フロー、利用データ、例外対応をもとに、AIに任せる範囲と人が判断する箇所を整理します。仕様が固まる前のご相談も承ります。