コンピューター操作とは何か、なぜ重要なのかコンピューター操作は、広範な影響をもたらすシンプルな発想です。モデルに質問への回答を求めるのではなく、Web サイトの閲覧、フォームへの入力、ワークフローのクリック操作など、ソフトウェアを操作してタスクを最初から最後まで自律的に完了させます。
これにより、一連の予約手続き、EC サイトでの購入、多段階の旅行計画、対応する適切な API がないバックオフィス業務など、現在は複数のインターフェースに分断されている多様な実務タスクに対応できます。これらは新しい課題ではありません。新しいのは、汎用モデルで解決できる見込みが立ったことです。
Anthropic と OpenAI の最近のシステムは、単に行動するだけでなく、状態を推論し、エラーから復旧し、その場でタスク固有の解決策を構築するエージェントを実証しています。これにより、ブラウザーはエージェントの汎用実行環境になりますが、同時に、その環境をどこまでモデルに公開すべきかという設計上の問題が生じます。
初期のシステムは、ブラウザーを安全な定義済みアクションの固定セットでラップすることで、この問題に対処しました。本稿で論じるように、このアプローチは限界に達しつつあります。
ブラウザーエージェントを構築する際には、「モデルを過度に信頼してはいけない」というおなじみの発想があります。
そこで、ブラウザーをラップします。click、type、scroll、select、read_text といった定義済みツールを公開します。Document Object Model（DOM）を簡略化します。アクション空間を縮小します。自ら設計した抽象化を通じて、動作を理解しやすく制御可能なものにしようとします。
出発点としては妥当です。しかし長期的なアーキテクチャとしては、次第に不適切なものになっています。
フロンティアモデルの進歩に伴い、問題はもはやモデルにツールが足りないことだけではなくなっています。基盤となるシステムの情報を過度にそぎ落とす抽象化を介して、モデルに操作を強いていることが問題なのです。雑然として動的な環境を固定のアクションインターフェースに圧縮し、情報が失われた状態でモデルに優れた成果を求めています。
このトレードオフの魅力は薄れつつあります。
私たちが検討してきた転換は、説明こそ簡単ですが、もたらす影響は重大です。エージェントを定義済みアクションの選択機構として扱うのではなく、制約付き実行環境内で動作するプログラム生成機構として扱います。
モデルは大幅に進歩し、抽象化されたガードレールを必要としなくなりました。必要なのは、目標を達成するまでタスクを設計、実行、反復するための完全なアクション空間です。
本稿では、抽象化を多用するブラウザー自動化から、制約を設けたコンピューター操作への転換と、この方法でシステムを設計したときに何が変わるのかを取り上げます。
固定されたアクションインターフェースの考え方自体が間違っているわけではありません。問題は、Web がその想定どおりに動かないことです。
最新のインターフェースは React、Vue、Angular を基盤とし、非同期の状態更新、合成イベントシステム、独自のライフサイクルを持つクロスオリジン iframe 内のサードパーティ製ウィジェットを利用しています。「この入力欄に入力する」というラッパーが正しく機能するのは、そのページにおける入力の定義が、こちらの定義と一致する場合だけです。一致しないページは数多くあります。値を直接設定すると、フレームワークの変更検出を完全に迂回してしまうことがよくあります。入力欄は埋まっているように見えます。しかし、検証は実行されません。フォームは機能しないままです。
この問題にはパッチを当てられます。React の入力欄に特例を追加し、フォーカス後に blur イベントを発行し、状態を読み取る前にネットワークがアイドル状態になるまで待つこともできます。個々のパッチは、その場では正しく機能します。しかし、それらが積み重なると、保守が次第に難しくなり、すでに遭遇したサイトにますます特化したシステムになります。
より根深い問題は、インタラクションの仕組みに関する前提を抽象化レイヤーに組み込んだ後で、Web 側の前提が異なると判明することです。
Stripe や Adyen を介して、クロスオリジン iframe 内に埋め込まれた決済フォームを考えてみましょう。このフォームは別のオリジンにあるため、ラッパーから直接アクセスできません。read_text ツールでは、フォーム内部の状態を確認できません。type ツールでは、フォームの入力欄を指定できません。ラッパーベースのエージェントは、ここで行き詰まります。この抽象化は、メイン文書を対象に設計されています。しかし、実際のタスクは抽象化から見えない場所にあります。
同様の不一致は、もっと分かりにくいフローでも発生します。フレームワークが制御するドロップダウンでは、表示されている要素が実際のコントロールではないため、直接クリックしてもまったく反応しないことがあります。基盤側の状態遷移を発生させるには、一連のキーボードイベントが必要な場合があります。外から見ると、その UI はクリックできるように見えます。抽象化は「クリック」と指示します。しかし何も起こりません。
あるいは、表示中の DOM の更新が内部状態の変化より遅れる、多段階のモーダルフローを考えてみましょう。正しい次のアクションは、ラッパーから見える要素にまだ反映されていない状態遷移に左右されます。ラッパーベースのエージェントはシステムの不完全な情報に基づいて動くため、早すぎるタイミングで行動したり、古い状態を読み取ったりします。
いずれの場合も、抽象化によってエージェントが本当に必要とするシグナルが隠されています。
ライブ DOM を調べ、フレーム境界について推論し、その画面に応じたインタラクション手順を生成するなど、より低いレベルで動作するモデルなら、こうした状況にも対処できます。モデル自体が本質的に賢くなったわけではありません。そぎ落とされていた情報にアクセスできるようになったのです。
私たちが目指してきた変更は、簡単に説明できます。モデルに定義済みアクションを選ばせる代わりに、より低レベルの実行環境を与え、抽象化の設計ではなく実行時ポリシーによって制約を設けます。
この設計判断の背景には、より低レベルのプリミティブツールを優先し始めた業界全体の変化があります。堅牢でありながらモデルの環境適応力を奪う専用ツールをハードコードするのではなく、実行時に修正し、高品質なコードを生成するというエージェント本来の能力を活用する方向への転換です。
多くの開発者が主要ツールとして Claude Code を採用していることや、業界全体でターミナルベースのエージェントへの移行が進んでいることを考えてみましょう。Claude Code の最大の強みはモデル自体ではなく、より低レベルのハーネスです。より少数で、モジュール性が高く、低レベルのツール、つまりターミナルをモデルに与えると、ツール呼び出しの性能が向上します。主な理由は、コンテキストウィンドウを圧迫する汎用ツールを使おうとする代わりに、エージェントが推論し、目の前のタスクに合わせて専用スクリプトを作成できるためです。
ブラウザー自動化では、すべてを定義済みアクションの固定セットに当てはめるのではなく、モデルがページの現在の状態を直接調べ、フレームを移動し、現在のインターフェース専用のインタラクションコードを構築できるということです。
モデルは選択機構というより、実行時のコード作成者として振る舞います。現在の状態を調べ、インターフェースについて推論し、その状況に固有のインタラクションロジックを生成します。複数ステップの手順を構築し、通常とは異なるフローに適応し、結果を検証してから先へ進むことができます。アクションが失敗すると、モデルは基盤側のエラーを確認し、自ら修正します。これは強力である一方、リスクも高まります。しかし、実際の問題の構造には、はるかに近いアプローチです。
重要なのは、抽象化レイヤーをなくしても、システムの規律が失われるわけではないことです。規律を担う場所が変わるのです。
従来、ラッパー設計とエッジケース処理が担っていた役割は、3 つの場所へ移ります。運用トレーニングの一形態となるプロンプト、移動範囲、機密性の高いアクション、再試行の動作などの境界を適用する実行環境、そしてタスクが成功したかどうかだけでなく、中間ステップが正しかったかも評価する評価レイヤーです。壊れやすい抽象化を減らす。周囲のシステムを強化する。
この転換により、システム全体の能力が向上する一方で、製品コードはむしろ簡素になることがよくあります。インタラクションパターンを再利用可能なラッパーとして組み込む代わりに、エージェントが実行時に動作を生成します。専用ツールやエッジケース向けロジックを増やし続けるのではなく、少数の強力なプリミティブと、制約を設けた実行環境を維持します。
これにより、システムの汎化の仕方も変わります。ラッパーベースのエージェントは、すでに構築済みのラッパーに似たタスクにはうまく汎化できます。実行環境に制約を設けたエージェントは、見た目のインターフェースが異なっていても、共通の実行基盤を持つタスクに汎化できます。
たとえば、検索フォーム、予約フロー、設定ページの操作は、UI 上ではまったく異なって見える場合があります。しかし、その下では状態の読み取り、イベントの発火、結果の検証、非同期更新の処理といったパターンを共有しています。このレベルで動作するシステムは、異なるタスクにも自然に応用できます。
再利用できる要素はアクションの一覧ではありません。状態を調べ、安全に行動し、結果を検証するモデルの能力です。
この取り組みから得られた最も明確な教訓は、モデルに補助機能を増やしても信頼性は得られないということです。むしろ、より少数で強力なプリミティブを与え、それらに適切な制約を設けることで信頼性が高まる場合が多いのです。過剰な支援は、タスクの実行方法に関する前提をハードコードしてしまいます。制約は安全な動作範囲を定めるとともに、モデルが局所的により優れた解決策を見つけられるようにします。
より強力な実行環境には、より厳密な安全性モデルも必要です。エージェントが少数の定義済みアクションに制限されなくなると、実質的に実在するソフトウェアを直接操作することになります。その時点で、リスク特性は一変します。
設計時に考慮すべき点は 4 つあります。
データの露出。エージェントが実際のインターフェースを操作すれば、機密情報に遭遇することがよくあります。そのため、マスキングとアクセス制御を厳格に行う必要があります。データを開示するのは実行に必要な場合に限り、可観測性の仕組みがシステムで最も機密性の高い部分にならないよう、ログやトレースも慎重に扱う必要があります。
実行範囲。強力なエージェントに無制限の操作を許してはなりません。実際には、移動できる場所、アクセスできるドメイン、操作を許可するシステムを制限する必要があります。こうした制約はプロンプト上の慣例に任せず、実行環境のレベルで適用すべきです。
環境への信頼。最新のインターフェースには、誤解を招く、あるいは明確な攻撃を意図した指示、コンテンツ、フローが含まれる可能性があります。ページコンテンツを介したプロンプトインジェクションは、現実に存在する攻撃対象領域です。エージェントが意図しない指示に従わないよう、システムには明確な指示の優先順位、検証チェック、終了条件が必要です。
自律性のスペクトラム。すべてのアクションを完全に自律化すべきではありません。多くの本番環境では、自律性を段階的なものとして扱うことが重要です。探索や実行では高いエージェント性を発揮させながら、特定の種類のアクションには承認を必須とすることもできます。
根本原則は単純です。モデルに与える権限を強めるなら、それを取り巻くシステムも強化する必要があります。ポリシーを伴わない自律性は、本番環境には対応できません。
私たちは、「どのブラウザーアクションを公開すべきか」と問うのをやめました。
代わりに、「モデルに完全なアクション空間を提供するには何ができるか、そして安全性を保つために、その周囲へどのような実行時ポリシーを構築すべきか」と問い始めました。
この捉え直しにより、重視するものが変わります。アクションの分類体系やラッパーの網羅性は、それほど重要ではなくなります。実行時ポリシー、可観測性、ステップ単位の評価がより重要になります。モデルの能力とシステム設計は、互いに代替できるものではありません。モデルが進歩するほど、システムが担う役割は小さくなるどころか、より重要になります。
デモで動くブラウザーエージェントが成功するのは、多くの場合、タスクが限定的で環境も協力的だからです。本番システムに必要なのは別のものです。制約付きの実行、計測可能な動作、そして正しい結果と偶然の成功を区別できる評価です。
ラッパー設計を減らす。システムエンジニアリングを増やす。
本稿ではブラウザーエージェントに焦点を当てましたが、これはコンピューター操作をシステム工学として捉える、より広い考え方につながります。