AIエージェント vs RPA

ボットが実際に何をするのか

アーキテクチャから始めましょう。なぜなら、AIエージェントとRPAの比較はそれによって決まるからです。最大のRPAベンダーであるUiPathは、そのソフトウェアロボットを「画面やシステムとのインタラクションにおいて人間の行動を模倣する」と説明し、「データ入力、ファイル移動、取引処理などの反復的でルールベースのタスクを処理する」としています。Microsoftのデスクトップフロー、Power Automate内のRPA製品も、機械的な用語で同じことを言っています：アプリケーションのUI要素、画像、または座標を使用して「機械とインタラクションする」ことができます。「ターミナルエミュレーター、現代のウェブおよびデスクトップアプリケーション、Excelファイル、フォルダーなどのレガシーアプリケーション」に対してです。ボットは、デスクの人と一緒に参加して実行することも、独自のマシンで無人で実行することもできます。

具体的なタスクを考えてみましょう：APIのない古い在庫システムに商品受領を予約することです。ボットはアプリケーションを開き、メニューを通って受領フォームに移動し、発注書を検索し、各行の数量フィールドにタブを移動し、数字を入力して保存キーを押します。人がその手順を一度記録しました；ボットはそれを何千回も再生し、より速く、数字を転置することなく行います。安定したアプリケーションで高ボリュームかつ他の方法がない場合、それは良い取引であり、多くの財務およびオペレーションチームで自らのコストを回収しています。

ベンダーはどこに適合するかを言い、その通りです。UiPath自身の枠組みは「高ボリューム、反復的、ルールベースのタスク、特に複数のシステムにまたがるもの」です：ボリューム、決定論、そして他に何も提供しないシステムへのアクセスです。正直な比較はそれらをテーブルに置きます。

なぜそれが壊れるのか、そしてそれが欠陥ではない理由

画面は人との契約です。そのレイアウト、ラベル、タブの順序、保存ボタンの位置は、目とポインタに対する約束であり、機械には約束されていません。ベンダーが数量フィールドを新しいタブに移動したり、確認ポップアップを追加したり、メニューの名前を変更したりすると、人は気づかずに数秒で適応します。ボットは失敗するか、さらに悪いことに、数量を間違ったフィールドに入力して保存します。その失敗はRPAベンダーの能力について何も示していません。ボットに与えられたインターフェースが露呈しているのです。

言語モデルが画面を操作する際にも同じ制限が適用されます。Anthropicのコンピュータ使用はClaudeに「デスクトップ環境のスクリーンショット、マウス、キーボードの制御」を与え、他に何も存在しない場所では本当に役立ちます。しかし、Anthropic自身のドキュメントは、より厳密なインターフェースが利用可能な場合にはそれから離れるように指示し、ウェブページ内での作業にはブラウザツールを推奨し、「実際の世界において意味のある結果をもたらす可能性のある決定を確認するために人間を求める」と述べています。モデルが画面を操作する場合、画面の脆さを引き継ぎ、その上に独自の変動性を加えます。これは二つのカテゴリの中で最も魅力的でない組み合わせであり、多くの「AI駆動のRPA」の提案がこれに該当します。

エージェントが呼ぶ別の名称

エージェントのために構築されたビジネスシステムを操作するエージェントは、決して画面を見ません。システムに何ができるかを尋ね、各ツールの名前、モデル用に書かれた説明、入力のスキーマ、および読み取り専用か、データを破壊できるか、二回呼び出すことが安全かどうかを示すオプションの注釈を含むツールのリストを受け取ります。モデルコンテキストプロトコルはこの交換を標準化します：クライアントはツールのリストを要求し、モデルは一つを選び、クライアントは型付き引数で呼び出し、サーバーはそれを実行して結果を返します。仕様はサーバーに「すべてのツール入力を検証する」ことと「適切なアクセス制御を実装する」ことを要求し、クライアントには「監査目的のためにツールの使用を記録する」ことを指示します。以下は、以前の受領書を使用したそのようなツールの形です。

{
  "name": "receiveStock",
  "description": "Book goods received against a purchase order into a warehouse location. Fails if the order is closed or the caller cannot receive at that location.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "order_ref": { "type": "string", "description": "Purchase order reference" },
      "location_id": { "type": "string", "description": "Warehouse location to receive into" },
      "lines": {
        "type": "array",
        "items": {
          "type": "object",
          "properties": {
            "sku": { "type": "string" },
            "quantity": { "type": "integer", "minimum": 1 }
          },
          "required": ["sku", "quantity"]
        }
      }
    },
    "required": ["order_ref", "lines"]
  },
  "annotations": { "readOnlyHint": false, "destructiveHint": false, "idempotentHint": false }
}

仕様が説明する形のMCPツール定義で、ボットがフォームに入力していた同じ受領書のためのものです。フィールド名は例示的です。重要なのは、ツールが契約であり、契約は画面ではできない方法でバージョン管理、検証、権限付与ができるということです。

変更時に何が起こるかを比較してください。ベンダーが受領書画面を再設計します：ボットは壊れ、ツールはそのままです。ベンダーがツールに必須フィールドを追加します：それは公開された契約へのバージョン管理された変更であり、ツールリストで発表され、エージェントは次の呼び出しで新しいスキーマを読み取ります。アイデンティティを比較してください。ボットは数年前に誰かが与えたアクセス権を持つサービスアカウントとしてログインします。エージェントは自分が代表する人としてツールを呼び出し、権限チェックはツール内で、すべての呼び出しに対してその人の役割に基づいて実行されます。

決定論的と確率論的：誰も隠すべきでない取引

エージェント側にはコストがあり、RPAベンダーは自社のエージェントドキュメントでそれを正確に述べています：ロボットは「構造化されたロジックと固定されたルールに従い」、エージェントは「パターンとリアルタイムデータに基づいて意思決定を行う確率的アプローチを取ります」。同じ手順を再生するボットは、同じ入力に対して同じ結果を出し、それを証明できます。同じ意図を持つエージェントは、通常は同じ道を取りますが、必ずしもそうではありません。再現性が示されなければならない規制されたステップや、月に百万件の同一取引の場合、決定論的な選択肢がより良い選択であり、そうでないと言うことは販売になるでしょう。

エージェントの利点は変動に限定されています。受領書が注文と一致しない場合、サプライヤーが一つの行に対して二つの納品を送った場合、数量は妥当だが単位が間違っている場合、ボットにはそのための分岐がなく、停止するか、自信を持って間違ったことをします。エージェントは不一致を読み取り、注文を確認し、一致するものを予約し、残りについては人に尋ねます。それはかつて誰かのデスクにあった例外のキューの作業であり、エージェントのための作業です。

RPAを使うべき時、エージェントを使うべき時

両方を使用し、システムが下で決定すること

現在、ベンダーが説明するパターン、実際に機能するものは、エージェントが決定し、ボットが他に何もないシステムで実行するというものです。UiPathは、ロボットがエージェントと並んで「実行スタックにおける補完的な役割を果たす」と表現しています。その配置では、ボットはエージェントのツールの一つです：レガシースクリーンに対するラップされた決定論的アクションで、エージェントはそれを呼び出すタイミングを選択し、ボットが返すものを処理する責任があります。時間が経つにつれて、ボットは一つずつ退役し、背後のシステムが独自のツールを獲得しますが、エージェント側は何も変更する必要がありません。

これにより、決定はビジネスシステムに戻ります。Soisは、ボットが必要ないように構築されています：ワークスペースはMCPサーバーであり、個人が行えるすべてのアクションは名前付きツールとして公開され、すでに使用しているエージェント（Claude、ChatGPT、または任意のMCPクライアント）は、ワークスペースアドレスを追加し、一度サインインすることで接続します。ツールはエージェントが見る前に個人の役割によってフィルタリングされ、実行時に再度確認されるため、アクセスは閉じられます；支出は統合ごとに上限が設定されます；すべての呼び出しはその入力と結果と共に記録されます。まだレガシーシステムを並行して運用している場合、ボットはそのシステムに留まり、エージェントはそれをもう一つのツールとして扱います。

コアシステムがスクリーンのみの場合、RPAは橋渡しであり、それに恥はありません。重要なのは、次に購入するシステムがRPAを必要とするかどうかです。

人々が尋ねる質問

この文書は、記載されている製品が変更される際にレビューされます。次回の予定レビュー： 2026年12月4日.