デモには目を奪われます。AIが複雑な予約手続きを進め、複数のアプリケーションを切り替え、行政機関のフォームに入力し、数時間に及ぶタスクを自律的に完了します。2024～2025年には、AnthropicのComputer Use、OpenAIのOperator、GoogleのProject Mariner、そして新興企業の一群が、人間のようにコンピューターを操作するエージェントを披露しました。
2026年現在、こうしたツールは実在し、実際に機能します。本番環境への導入に成功している企業もあります。しかし、その導入形態はデモとは異なります。対象範囲はより狭く、制約はより厳しく、周囲にはガードレールが張り巡らされています。本記事では、本番システムとデモを分けるパターンを取り上げます。
基本事項は中級者向けの記事で説明しました。本記事ではさらに踏み込み、本番環境でのパターン、繰り返し見られる失敗、経済性、そして大規模環境で本当に役立つコンピューター操作システムをリリースする方法を解説します。
本番環境の実情
実際の本番導入では、いくつかのパターンが見られます。
パターン1：狭いタスクが主流です。 本番導入は、具体的で明確に定義されたタスクで成功します。「何でもする」ことでも、「どのWebサイトでも操作する」ことでもありません。特定のサイト上の特定のワークフローです。
パターン2：厳格なスコープ設定。 タスクの範囲は厳しく限定されます。エージェントに許可されるのは、特定のサイト上の特定の操作だけです。範囲外の状況では、即興で対応せず停止します。
パターン3：自律的な探索より記録済みワークフロー。 本番導入の多くでは、完全自律型のエージェントではなく、記録済みワークフロー（一度定義した手順を、必要に応じて調整しながら再生する方式）を使用します。その方が信頼性が高く、保守も容易です。
パターン4：重大な操作では人間を介在させる。 大きな影響を伴う操作（財務、法務、顧客向けなど）は、必ず人による確認を経ます。
パターン5：徹底的な監視。 すべての操作を記録し、異常を検知し、緊急停止スイッチを用意します。運用チームがダッシュボードを監視します。
パターン6：コスト規律。 経済性は重要です。「AIがすべてをこなす」という理論上の導入案の多くは、人間やRPAという代替手段と比較すると採算が合いません。
パターン7：汎用型より特化型。 本番導入では、あらゆる用途に汎用のコンピューター操作モデルを使うのではなく、特化型モデル（または用途に特化した設定）を使う傾向があります。
こうしたパターンは、本番AIに典型的な姿と一致します。マーケティングが示唆するより対象範囲が狭く、ガードレールが強固です。
本番環境でコンピューター操作エージェントが活躍する領域
コンピューター操作が適している具体的なタスクの種類を見ていきます。
1. APIのないサイトからのデータ抽出
多くのエンタープライズツール、行政ポータル、小規模なB2BサービスにはAPIがありません。APIがあっても、大きな機能の抜けがあることもあります。コンピューター操作エージェントは、UIを操作してデータを抽出できます。
本番環境での例：
- 50以上の取引先ポータルから請求書を取得する。
- 裁判所システムのWebサイトから事件データを抽出する。
- 競合他社の価格ページをスクレイピングする。
- コンプライアンス報告ポータルからデータを集約する。
代替手段が人間による退屈なクリック作業なら、コンピューター操作には明確な利点があります。
2. 大規模なフォーム入力
同じ種類のフォームを多数の異なるサイトに送信します。各サイトは少しずつ異なり、APIが理想的ではあるものの存在しません。
例：
- 行政機関への申請（機関ごとに独自のポータルがある）。
- コンプライアンス関連の届出。
- 取引先システムへの顧客オンボーディング。
- SaaSツールのアカウント設定。
3. UIテストと品質保証
コンピューター操作エージェントは、優れたQAテスターになります。アプリを操作し、ユーザーフローを試し、問題を報告できます。
例：
- Webアプリのエンドツーエンドテスト。
- ビジュアルリグレッションテスト。
- アクセシビリティ監査。
- 複数のデバイスにまたがるユーザーフローの検証。
これはRPAに近い領域ですが、AIにはUIの変更に対応できる柔軟性があります。
4. アプリケーション横断ワークフロー
単一の統合ポイントがなく、複数のアプリケーションにまたがるタスクです。
例：
- CRMからデータを取得して整形し、分析ツールへアップロードする。
- カスタマーサポートのチケットを基にプロジェクト管理ツールでタスクを作成し、CRMのステータスを更新する。
- 複数の社内ツールからレポートを集約する。
アプリを直接統合できない、または統合しない場合、エージェントが柔軟な橋渡し役になります。
5. 反復的な多段階プロセス
同じ担当者が繰り返し行っているタスクです。
例：
- 30段階のプロセスで新規顧客をオンボーディングする。
- 2つのシステム間で毎週データを照合する。
- 複数の情報源からデータを取得する必要がある定期レポートを作成する。
プロセスが明確に定義され、頻繁に繰り返され、現在は人間のクリック操作で行われているなら、自動化の候補です。
依然として失敗する領域
逆に、コンピューター操作エージェントがまだ本番利用に適していないタスクもあります。
1. 判断を要するタスク
「良い取引先を探してほしい」。エージェントは取引先のサイトを閲覧できますが、自社固有のニーズにとって何が良いかを判断することはできません。
2. 目新しいUIパターンを持つタスク
これまで見たことのない新しいサイトです。エージェントは、一般的でないUIの慣習を見つけることに苦労します。独自設計より、一般的なパターン（フォーム、一覧、ナビゲーションメニュー）でうまく機能します。
3. 強力なボット対策があるタスク
多くのサイトは、自動操作を積極的に検知して遮断します。エージェントが回避できる場合もありますが（相応の労力が必要です）、終わりのないいたちごっこになります。多くの場合、割に合いません。
4. 重大な影響を伴う個別操作
支払いの送信、法的文書への署名、誰かに代わる公開投稿などです。誤操作の影響範囲が大きいため、人による確認が不可欠です。
5. 現実世界のコンテキストを要するタスク
エージェントが見られるのは画面上の情報だけです。その顧客との関係、チームの直近の状況、政治情勢は把握していません。コンテキストが不足するタスクは失敗します。
6. 自由度の高い探索
「最安の商品を探して」「この人物について徹底的に調べて」など、明確な完了基準がないタスクです。エージェントは空回りを続けるか、早すぎる段階で停止します。
アーキテクチャ
本番用コンピューター操作システムには、次のレイヤーがあります。
┌─────────────────────────────────────┐
│ オーケストレーション │ スケジュール、再試行、エスカレーション
├─────────────────────────────────────┤
│ タスク定義とスコープ │ エージェントがすること、しないこと
├─────────────────────────────────────┤
│ エージェントランタイム │ Anthropic / OpenAI / Browserbase
│ （Computer Use SDK） │
├─────────────────────────────────────┤
│ ブラウザ／デスクトップ環境 │ 分離されたサンドボックス
├─────────────────────────────────────┤
│ 認証とセッション │ 認証情報、Cookie、MFAの処理
├─────────────────────────────────────┤
│ 結果の処理 │ 取得、検証、保存
├─────────────────────────────────────┤
│ 監視とアラート │ リアルタイムの可観測性
└─────────────────────────────────────┘
各レイヤーを順に見ていきます。
タスク定義
最も重要なステップです。エージェントが行うことを狭く定義します。
優れたタスク定義には次の項目が含まれます。
トリガー。 何がタスクを開始しますか（スケジュール、イベント、手動）。
入力。 エージェントはどのデータを持ちますか（特定のレコード、構造化されたフォームデータ）。
スコープ。 どのサイト、どの操作、UI内のどの経路が対象ですか。
成功基準。 どの状態になれば完了ですか。
停止条件。 何が起きたらタスクを途中で終了しますか。
出力。 エージェントはどのデータを返しますか。
エラーのセマンティクス。 失敗をどのように分類し、報告しますか。
定義が不十分なタスク：「週次コンプライアンスレポートを提出する」。
明確に定義されたタスク：
タスク：週次コンプライアンスレポートをポータルXに提出する。
トリガー：cron、毎週月曜日の午前9時。
入力：
- /reports/weekly.csvにあるレポートデータファイル（CSV）
- 環境変数から取得する提出者情報（氏名、ID）。
- シークレット管理システムから取得する認証情報。
スコープ：
- サイト：https://portal.example.gov/submit（およびそのサブパス）
- 許可する操作：移動、クリック、入力、アップロード、送信、スクリーンショット。
- 禁止事項：外部サイトへのアクセス、アカウント設定の変更、提出フローからの離脱。
成功基準：
- 提出IDが記載された確認ページを受け取る。
- 提出IDを取得する。
停止条件：
- 確認を受信：成功。
- CAPTCHA：人間へエスカレーション。
- ログイン失敗：人間へエスカレーション。
- フォーム検証エラー：報告して停止。
- 5分でタイムアウト：報告して停止。
出力：
- 提出ID。
- 確認ページのスクリーンショット。
- タイムスタンプ。
エラー：
- 検証：記録し、担当者へ通知し、再試行しない。
- 認証：記録し、運用担当へ通知し、再試行しない。
- ネットワーク：1回再試行し、その後エスカレーションする。
本番環境では、このレベルの具体性が必要です。「レポートを提出する」で済むのはデモです。
スコープの強制
スコープは単なる説明ではありません。実行時に強制します。
URL許可リスト。 エージェントは、定義済みのパターンに一致するURLにしか移動できません。許可リスト外への移動は遮断されます。
操作のフィルタリング。 許可する操作の種類を限定します。「コンピューターを自由に操作する」のではなく、個別に許可された操作だけを実行できます。
要素のフィルタリング。 ページによっては、エージェントが決して操作すべきでない要素（設定、ログアウト、危険なボタン）があります。これらは認識レイヤーから除外できます。
時間制限。 タスクには厳格な上限時間を設けます。N分以内に完了しなければ中止します。
ステップ数の制限。 タスクには最大ステップ数を設けます。エージェントのループと同じ考え方です。
実装方法はプラットフォームによって異なります。Anthropic Computer Use、OpenAI Operator、Browserbaseはそれぞれ異なる仕組みを備えています。原則は共通です。スコープはプロンプトに記述するだけでなく、ランタイムで強制してください。
認証
認証は常につきまとう課題です。本番導入では、エージェントのセッションを認証する必要があります。
事前認証済みセッション。 人間が一度ログインし、セッションのCookieやトークンを取得します。エージェントはそのセッション内で操作し、必要に応じて更新します。
サービスアカウント。 サイトが対応している場合は、エージェント専用のアカウントを使用します。権限を限定し、監査ログを残します。
認証情報の注入。 エージェントは実行時に認証情報を受け取り、それを使ってログインした後に破棄します。安全な保管と取り扱いが必要です。
MFAの処理。 難しい課題です。選択肢は次のとおりです。
- エージェントが計算できるTOTPシークレットを使用する。
- 承認のためMFAを人間に回す。
- MFAの代わりにAPIトークンを利用できるアカウントやサイトを使用する。
OAuth。 現代的なサイトではOAuthフローがうまく機能します。エージェントは、人間が一度承認したフローからトークンを取得します。
基本原則は、エージェントに人間と同等のアカウントアクセス権を持たせないことです。範囲が限定され、監査でき、無効化できる認証情報を持たせてください。
結果の検証
エージェントが成功を報告したら、検証します。
成果物を取得する。 スクリーンショット、ダウンロードしたファイル、出力データを取得します。エージェントの報告をうのみにせず、証拠を確認してください。
成功条件を確認する。 フォームは実際に送信されましたか。確認情報はありますか。データは正しかったですか。
クロスチェックする。 別の経路（API、確認メール、データベースの確認）で成功を検証できるなら、実施してください。
異常を検知する。 今回の実行は異常に長くなかったか、短くなかったか、コストが高くなかったかを確認し、外れ値を調査します。
基本原則は、エージェントが間違っている可能性を前提にすることです。エージェントの自己申告から独立した検証手段を用意してください。
エラー処理
コンピューター操作タスクには多様な失敗があります。それぞれを分類し、適切に処理します。
ネットワークエラー。 サイトの停止やタイムアウトです。バックオフを伴う再試行を行います。
認証失敗。 ログインの失敗やセッションの期限切れです。認証情報を更新するか、エスカレーションします。
UIの変更。 サイトが変更され、想定していた要素が見つかりません。停止し、保守担当へ通知します。
検証エラー。 フォーム入力が拒否されました。記録して通知し、やみくもに再試行しないでください。
ボット対策による検知。 CAPTCHAやアクセス遮断です。エスカレーションし、場合によってはそのサイトをブラックリストに登録します。
エージェントの混乱。 エージェントが行き詰まる、ループする、決められた手順から外れる状態です。停止し、記録して、調査します。
クォータ／レート制限。 サイトがエージェントをレート制限しました。バックオフして再試行するか、後で実行するようスケジュールします。
カテゴリごとに異なる対応が必要です。悪いパターンは「エージェントが失敗したので再試行する」です。良いパターンは「エージェントがカテゴリXで失敗したので、手順Xに従う」です。
監視
すべての操作を記録し、すべての実行を追跡し、すべての異常を表面化します。
実行ごとのログ：
- 開始／終了のタイムスタンプ。
- 実行したすべての操作。
- すべてのスクリーンショット。
- 結果（成功／失敗／エスカレーション）。
- コスト。
- パフォーマンス指標。
実行ごとのダッシュボード： 運用チームは、実行中の処理、直近の失敗、キューの深さを確認できます。
集計指標：
- タスクの種類ごとの成功率。
- レイテンシーの分布。
- 実行1回あたりのコスト。
- 異常率。
アラート：
- 成功率がしきい値を下回る。
- 実行1回あたりのコストが急増する。
- 特定の種類の失敗が増える。
- サイトのUIが変更された可能性がある（同じステップで直近に複数回失敗）。
この監視により、問題がインシデントになる前に検知できます。
経済性
率直に問うべきなのは、コンピューター操作が代替手段より安いかどうかです。
コスト：
- 実行1回あたりのコスト：通常はタスクの複雑さに応じて€0.50～€5（ビジョンモデルの呼び出しは高価です）。
- インフラ：マネージドランタイム（Browserbaseなど）または自社運用。
- 保守：サイトが変わるとタスクが壊れます。継続的な作業が多少必要です。
代替手段：
- 時給€30の人間：10分のタスクは€5、1分のタスクは€0.50です。
- RPAツール：実行1回あたりのコストは低いものの、構造化された自動化が必要です。
- APIの直接統合：呼び出し1回あたりははるかに安価ですが、APIが存在する必要があります。
- 海外へのアウトソーシング：時給€5～10で、社内の人間と同様の計算が成り立ちます。
次の場合、経済性はコンピューター操作に有利です。
- サイトにAPIがない。
- タスクにある程度の長さがあり、自動化によって固定費を回収できる。
- 人間の作業時間が積み重なるだけの処理量がある。
- サイトが比較的安定している（保守負担が小さい）。
次の場合、経済性はコンピューター操作に不利です。
- APIが存在する（そのAPIを使ってください）。
- タスクが短く、実行頻度も低い。
- サイトが絶えず変わる。
- タスクに例外ケースが多すぎる（保守負担が大きい）。
有用な方法は、コンピューター操作と人間についてタスク1件あたりのコストを見積もり、それぞれ処理量を掛けて比較することです。
機能する本番パターン
導入に成功している事例から、いくつかのパターンを紹介します。
パターン1：「記録済みレシピ」方式
処理量が多く範囲の狭いタスクでは、明示的な手順を含むワークフローを一度記録し、その後は入力ごとにわずかに調整しながらエージェントに再生させます。
これは従来のRPAに近いものの、軽微な差異（ボタンが少し移動した、確認ダイアログが1つ増えたなど）に対応できるAIの柔軟性があります。
完全な自律操作より、はるかに信頼できます。
パターン2：「抽出と送信」の分割
多くのワークフローには2つの段階があります。
- どこかからデータを抽出する。
- どこかへデータを送信する。
この2つを別々のエージェント実行（またはレシピ）に分割すると、構成が明快になります。各段階の成功基準が明確になり、一方の失敗がもう一方に波及しません。
パターン3：「人間によるチェックポイント」
エージェントが準備作業を自律的に進め、「実行準備完了」の状態を提示して人間の承認を求めます。人間がレビューして承認すると、エージェントが実行します。
支払い、公開投稿、機密性の高い提出に使用されます。エージェントが準備時間を削減し、人間が誤りを見つけます。
パターン4：「専門エージェント」
1つの汎用エージェントではなく、特定のタスクに特化したエージェントを用意します。それぞれを固有のワークフローに合わせて調整、テスト、保守します。
汎用の「どのWebサイトでも操作する」エージェントは保守が困難です。「週次コンプライアンスレポートを提出する」エージェントなら単純明快です。
パターン5：「RPAへのフォールバック」
AIの柔軟性が実際には必要ないタスク（サイトが安定し、ワークフローが固定されている場合）では、従来のRPA（Playwrightスクリプト、Selenium）へフォールバックします。そのような場合は、こちらの方が安価、高速で、信頼性も高くなります。
コンピューター操作は、AIの柔軟性が価値を加える場合に限定して使用してください。
パターン6：「バッチ実行」
処理量の多いタスクでエージェントをオンデマンド実行しないでください。作業をバッチ化し、スケジュールに従ってエージェントを並列実行します。
たとえば、「ユーザーがリクエストを送信したらエージェントを即時実行する」のではなく、リクエストをキューに入れ、15分ごとのバッチでエージェントを実行します。負荷を平準化し、アーキテクチャを簡素化できます。
起こり得る問題
よくある失敗モードを簡潔に挙げます。
サイトが変更された。 エージェントは6か月間完璧に動作していましたが、サイトの再設計ですべてが壊れます。監視していなければ、怒ったユーザーから知らされます。
ボット対策に検知された。 サイトがボット検知を導入し、エージェントの失敗が徐々に増えます。最終的にはアカウントが停止されます。
行き詰まったタスクでコストが急増した。 エージェントが分かりにくいページでループします。1サイクルごとにビジョンモデルが呼び出され、1時間で€100かかります。
誤った操作を実行した。 エージェントが違うボタンをクリックしました。注文を確定する代わりにキャンセルしたり、別の相手にメッセージを送ったりします。
MFAで行き詰まった。 エージェントがMFAを通過できません。本番の処理が滞り、キューが増えます。
アカウントが停止された。 サイトが通常と異なる操作を検知し、アカウントを停止しました。アカウントが復旧するまで、同種のタスクはすべて停止します。
認証情報が漏えいした。 エージェントが誤ってログやスクリーンショットに認証情報を露出させました。セキュリティインシデントです。
プライバシー上の問題が起きた。 エージェントが、ログに保存されるスクリーンショットへ意図せずPIIを写し込みました。
こうした問題のほとんどは、前述のパターンで予防できます。しかし、いずれも実際の導入で起きています。それぞれに応じた防御策を構築してください。
経済性：モデルケース
これは顧客事例ではなく、モデル化したシナリオです。あえてそのように明記しています。検証不能な「匿名事例」より、自社の数値で再計算できるROIモデルの方が有用だからです。
タスク： 12の異なる行政機関のポータルへ定期的なコンプライアンスレポートを提出します。エストニアでいえば、今なおフォームごとの入力が必要なポータル、たとえばe-MTAの申告、Statistics Estoniaの調査票、EUレベルの提出を想定してください。
手作業の基準値： 12ポータル × 90分 = 週18時間。諸経費込みの時給を€30とすると、週€540です。
自動化後：
- エージェントの実行：12 × 約€2（ビジョンモデル＋ブラウザインフラ）= 週€24。
- 保守：月に約2エンジニア時間、時給€100で、週換算約€50。ポータルは変わります。この予算を確保しなければ、自動化は気付かないうちに機能しなくなります。
- 失敗対応：自律実行の成功率が92%なら、週におよそ1回は人間へエスカレーションされます。レビュー時間を30分とすると、週€15です。
- 合計：約€90／週。約€450／週、年間約€23,000の節約。
ここで、実効性の有無を決める数値が2つあります。
1つ目は成功率です。およそ85%を下回ると、人間による付き添い対応で節約分が失われます。信頼して任せる前に、2週間のシャドー運用で測定してください。ベンダーのスライドに記載された値をそのまま使ってはいけません。
2つ目は保守による劣化です。ポータルの再設計は毎回システムを壊し、12のポータルを抱えていれば年に数回は起こります。1営業日以内に修正する担当者を指名できないなら、手作業の方が安価でした。
導入チェックリスト
コンピューター操作システムを本番環境へ導入する場合：
- タスクの範囲が狭く、明確に定義されている。
- スコープが説明だけでなく、実行時に強制されている。
- ステップ数／時間／コストの上限が設定されている。
- 安全な認証情報を使用する認証戦略がある。
- ボット対策を考慮している（正規のアカウントを使用し、レート制限を尊重する）。
- エラーの分類と処理がある。
- エージェントの自己申告から独立して結果を検証している。
- 監視とアラートがある。
- 緊急停止スイッチがある。
- 重大な操作では人間を介在させている。
- 監査ログを記録している。
- プライバシー／PIIを適切に扱っている。
- 代替手段と比較してコスト面の合理性がある。
- サイト変更時の保守計画がある。
どれも簡単な項目ではありません。1つでも省けばリスクが生じます。
タスクに技術を合わせる
本番環境のコンピューター操作エージェントとブラウザエージェントは、話題になるデモとは姿が異なります。狭いタスク、強固なガードレール、徹底的な監視、人間によるチェックポイント、現実的な経済性が必要です。
適切なタスクであれば、本当に役立ちます。APIのないサイトからのデータ抽出、大規模なフォーム入力、アプリケーション横断ワークフロー、反復的なUI操作などです。実際の本番導入で、実際に時間と費用を節約できます。
一方、自由度の高い判断、目新しいUI、重大な影響を伴う個別操作など、不適切なタスクにはまだ対応できません。無理に使おうとしないでください。
重要なのは、技術とタスクを適合させる能力です。適切に導入すれば、コンピューター操作エージェントは本番AIスタックの有用なツールになります。導入を誤れば、新たな失敗モードを持ち込む高価な手段になります。
狭いタスクを選び、ガードレールを構築し、絶えず監視し、一貫して保守してください。そうすることで、コンピューター操作エージェントは本番システムに置く価値を生み出します。
