Operator型エージェントAPIで堅牢なWeb自動化を構築する
OpenAIのOperatorは2025年1月にリリースされ、Web自動化についての議論をすぐに変えました。壊れやすいCSSセレクターやXPathクエリの代わりに、AIをウェブサイトに向けて「 groceriesを買って」と言えるようになりました。動くことは動く——時々。課題は常に、プロダクションシステムに耐えうるほど信頼性を高めることでした。
私は6週間かけて、クライアントの内部ツール向けにOperatorスタイルの自動化パイプラインを構築しました。400の異なるワークフローにわたる約12,000回のページインタラクションを処理しました。
コアアーキテクチャ：3層モデル
私が見てきた本番グレードのOperatorシステムはすべて3層アーキテクチャを使っています。
第1層：ブラウザ制御。 これが基盤——エージェントがコマンドできるヘッドレスまたはヘッド付きブラウザインスタンス。Playwrightがここで支配的な選択肢になりました。重要な能力は単にクリックやタイピングだけでなく、ページの状態を構造化フォーマットでエージェントに読み返すこと。信頼性の高い状態読み取りがなければ、エージェントは blindness飛行です。
第2層：エージェント推論。 ページ状態を解釈し、次に取るアクションを決定し、次のコマンドを生成するLLMです。2026年初頭時点でGPT-4oとClaude 3.5 Sonnetが最も一般的な選択肢です。エージェントはページの構造化表現——通常是アクセシビリティツリーか簡略化されたDOM——を受け取り、離散的なアクションを出力します：クリック、タイプ、スクロール、ナビゲート、抽出。
第3層：オーケストレーションとリカバリー。 ほとんどのチュートリアルが飛ばす接着層です。リトライロジック、チェックポイント管理、エラー分類、ヒューマンインザループのエスカレーションを処理します。プロダクションでは、この層が重労働の80%を行います。
ページ状態抽出の実際の仕組み
システム全体の信頼性は一つのことにかかっています：エージェントがページの現在の状態を正確に認識できるかどうか。
フィルタリング後、典型的なページは500ノードから約60〜80のアクション可能な要素に削減されます。トークン消費は約70%減少し、エージェントの精度はベンチマークスイートで約72%から91%に向上しました。
エラー回復：最も重要な部分
ここがほとんどの自動化プロジェクトが失敗する場所です。
3ティアのリカバリーシステムを構築しました：
ティア1：自動リトライ（エラーの約60%を処理）。2秒待ってリトライ、スクロールして要素を可視化、Cookieバナーを閉じるなどのシンプルな戦略。
ティア2：エージェントガイド付きリカバリー（エラーの約30%を処理）。エラー状態がコンテキスト付きでLLMにフィードバックされます。エージェントが代替アプローチを提案します。
ティア3：人間へのエスカレーション（エラーの約10%を処理）。システムがチェックポイントを保存し、スクリーンショット付きの詳細な失敗レポートを生成し、人間オペレーターに通知します。
プロダクションでは、複雑なマルチステップワークフローで89%の自律完了率を達成しています。
トークンコストの現実
お金の話をしましょう。典型的なマルチステップワークフロー（8〜12アクション）で、タスクあたり約8,000〜15,000の入力トークンと500〜1,000の出力トークンを消費します。LLMコストだけでもタスクあたり約$0.08〜0.15です。
2つの戦略でコストを40%削減しました：単純なステップにはより安いモデル（GPT-4o-mini）を使用し、ページ状態スナップショットをキャッシュします。
プロダクションデプロイチェックリスト
- 再利用可能なインスタンスによるブラウザプール管理
- 対策検出対策：ステルスプラグイン、ユーザーエージェントローテーション
- Redisによるチェックポイント永続化
- ドメインごとのレート制限
- 初日からのコストモニタリング
Operatorスタイルの自動化は強力ですが、魔法の杖ではありません。89%の自律完了率は聞こえがいいですが、12ステップのワークフローで11%の失敗率は、タスクの約73%が人間の介入なしに完了することを意味します（0.89^12）。それでも良い——従来の自動化よりずっと良い——ですが「セット＆フォゲット」ではありません。ヒューマンインザループのオーバーヘッドを予算化し、エラーリカバリーを注意深く設計し、すべてを監視してください。