コンピュータ利用の時代：AIエージェントが実際にソフトウェアを実行できるようになる時

2025年には自律型エージェントの実現が約束され、チャット機能がリリースされました。そして2026年には、実際にその機能が実現しました。大きな転換点となったのは、コンピュータ操作です。このモデルは画面を認識し、マウスとキーボードを操作し、人間のようにソフトウェアをナビゲートします。AnthropicはこれをパブリックAPIとしてリリースしました。OpenAIはOperatorをリリースしました。Browserbase、Multi-On、Lutraは、これを実運用可能にするインフラストラクチャを提供しました。

デザイナーと開発者のための実践的なプレイブック。コンピュータ操作とは何か、どこで実装されているのか、どこで問題が発生するのか、エージェントフレンドリーなUIに必要な要素、そして真のエージェントと単なるデモを分ける開発上の決定事項について解説します。

コンピュータ操作こそがチャット時代を終わらせた機能

チャットはAIのためのUIでした。コンピュータ操作は、まさに「身体」です。モデルはピクセルを認識し、クリックする場所を判断し、ツール呼び出しを行い、次のスクリーンショットを待ちます。このたった一つの基本要素が、クリーンなAPIがなくてもあらゆるワークフローを可能にします。ベンダーポータルへのデータ入力、エクスポート機能のないダッシュボードからのデータ取得などです。 2つのWebアプリ間でのスケジュール管理。AIは賢くなったのではなく、手が生えたのです。

実際のコンピュータ利用とは

ループは機械的です。モデルはスクリーンショットと目標を受け取ります。そして、座標をクリック、文字列を入力、キーを押す、スクロール、待機といった構造化されたアクションを返します。ホストはアクションを実行し、次のスクリーンショットを返します。完了するか、行き詰まるまでこれを繰り返します。

魔法はありません。このモデルは、リモートデスクトップを駆動する視覚拡張推論エンジンです。マルチモーダルモデルがUIを読み取って操作できるほど高性能になったため、この仕組みが機能します。しかし、実際のソフトウェアは複雑で、ピクセル単位で完璧な設計図は最初の誤った仮定に耐えられないため、実現は困難です。

2026年に出荷される3つの形態

現在、コンピュータ利用は3つの形態で提供されており、それぞれがスタックの異なるレイヤーに賭けています。Anthropic コンピュータ利用は、APIとして公開される生の機能です。 OpenAI Operatorは、OpenAIのブラウザ上で動作する監視型コンシューマーエージェントです。Browserbase、Multi-On、Lutraは、独自のエージェント製品を開発・提供するチーム向けのサーバーレスインフラストラクチャレイヤーです。

これは機能比較ではなく、スタックのどの部分を自社で管理するかという決定です。

Anthropic コンピュータ利用、基本的な機能

Anthropic コンピュータ利用は最も低レベルの機能であり、仮想デスクトップを認識し、マウスとキーボードを制御するモデルです。サンドボックスを起動し、モデルをそのサンドボックスに接続し、アクションを実行してスクリーンショットをフィードバックするホストコードを記述します。Replit AgentとDevinは、最も負荷の高いエージェント処理にこのパターンを採用しており、エージェントがブラウザだけでなくデスクトップアプリケーションも制御する必要がある場合に最適な選択肢です。

収益性に欠ける部分。サンドボックス、セキュリティモデル、アクションループ、リトライロジック、コストメーターはすべてユーザーが管理します。各ステップでスクリーンショットが送信されるため、トークンの使用頻度が高くなります。レイテンシはステップあたり2～6秒です。汎用的な機能を備え、複雑な操作も動作します。

OpenAI Operator、監視型ブラウザエージェント

OpenAI Operatorは、ユーザーがリアルタイムで監視するホスト型ブラウザエージェントです。コンシューマー向けです。自然言語で目標を入力すると、ブラウザタブが開き、いつでも実行を一時停止、引き継ぎ、または停止できます。ショッピング、スケジュール管理、フォーム入力、ドキュメント検索、簡単な調査などに最適です。

しかし、収益性は限られています。OperatorはOpenAIの環境内でサンドボックス化されているため、エージェントを自社製品に組み込むことはできません。認証フローでは、サインイン時にユーザーの操作が必要です。強力なアンチボット対策が施されたサイトでは動作しません。非標準イベントを使用するカスタムJSアプリでは、動作が不安定になる可能性があります。エンドユーザーにとって、今日最もスムーズなコンピュータ利用体験を提供します。開発者にとっては、ツールではなく競合相手です。

Browserbaseとサーバーレスブラウザエージェント

Browserbase、Multi-On、Lutraは、ブラウザエージェントを本番環境で利用可能にするインフラストラクチャを提供します。Browserbaseは、エージェントコードで操作できるサーバーレスホスト型Chromiumフリートです。Multi-Onは、開発者APIを備えたブラウザエージェントです。Lutraは、同じプリミティブ上にワークフローエージェントを構築します。ほとんどのエージェント処理はブラウザベースであり、デスクトップサンドボックスは過剰であるという前提に基づいています。

エージェント製品を開発するチームにとって、このレイヤーは通常、適切な出発点となります。ホスト型ブラウザ、セッション永続化、スクリーンショットキャプチャ、独自のフリートを運用することなく並行処理が可能です。コストは、完全なAnthropicスタックよりも抽象化レベルが低く、認証とストレージの制御が制限されることです。

現在、コンピュータ利用が本番環境で利用されている分野

コンピュータ利用は、限定的ではあるものの有用なタスクセットで機能します。ブラウザベースの調査、スケジュール管理、フォーム入力、APIのないシステムからのドキュメント取得、軽量な品質保証、ベンダーポータルの自動化、エクスポートできないダッシュボードからのデータ抽出。開発チームは汎用的なインテリジェンスを売り込むのをやめ、特定のタスクに特化したツールを売り込むようになった。

成功のパターンは、狭い範囲、監視された実行、明確な成功基準、行き詰まった際の迅速な人間への引き継ぎだ。Replit Agentはダッシュボードのデプロイに利用している。Devinは長時間のエンジニアリングタスクの中でベンダーコンソールを操作する。Operatorは消費者の買い物と旅行を処理する。Multi-Onは営業と運用向けの垂直ワークフローを実行する。どれも汎用エージェントではない。しかし、どれも優れた製品だ。

コンピュータ利用が依然として破綻する点

コンピュータ利用は、リアルタイムの判断、複雑なマルチアプリワークフロー、基本的なログイン以上の認証が必要なあらゆる場面で破綻する。これらの問題を曖昧にするデモは無視すべきだ。AdeptのACT-1は、まさにその典型的な例だ。美しいデモだったが、持続可能な製品にはならず、チームは最終的に方向転換した。

うまくいかない点。エージェントがグラフを読み取って判断を下す必要があるタスク。状態がアプリ間で受け渡される、4つか5つのアプリにまたがるワークフロー。大量のカスタムJavaScript、動的なID、あるいは強力なアンチボット対策が施されたサイト。MFA、OAuthの更新、またはユーザーが共有したがらないセッショントークンを必要とするフロー。20ステップを超える長期タスクは、エラー率が累積的に上昇し、失敗率が高くなります。自動化したいワークフローのうち、コンピュータ利用が占める割合はおそらく10～15%程度でしょう。勝ち残った製品は、まさにその10%を的確に捉えていました。

エージェントフレンドリーなUIの設計上の留意点

製品がコンピュータ利用エージェントにとって有用であるためには、UIがエージェントにとって読みやすいものでなければなりません。現在のほとんどの製品のUIはそうではありません。エージェントはピクセルを読み取ります。視覚的な構造、予測可能なパターン、そして明確なラベルが必要です。UIをエージェントフレンドリーにする要素はすべて、アクセシビリティにもつながります。同じチェックリストが両方に有効です。

今こそ、アクセシビリティがオプションではなくなる時です。クリーンでアクセシブルなコンポーネントライブラリを既に提供しているチームは、このラウンドで既に勝利を収めています。ホバーのみのトリガー、カスタムキャンバスウィジェット、そして曖昧なアイコンのみのボタンで構築されたチームは、次のユーザー層にとって自社製品が存在しないことに気づくでしょう。

エージェントフレンドリーなUIチェックリスト

エージェントのアクセスを必要とするあらゆる製品インターフェースで、このチェックリストを実行してください。意図的に簡潔にまとめています。

1. セマンティックなHTML。実際のボタン、実際の入力フィールド、実際の見出し、実際のラベル。見た目は正しくても、支援技術にとって意味をなさないカスタムdiv要素は、エージェントにとっても意味をなしません。

2. 予測可能なパターン。同じアクションはすべてのページで同じ場所に配置されます。主要なCTAは一貫した位置に配置されます。フォームは単一のレイアウトで統一されます。ナビゲーションは再配置されません。

3. アクセシブルなラベル。すべてのインタラクティブ要素には、明確で人間が読みやすいラベルが付けられます。アイコンのみのボタンにはaria-label属性が付けられます。フォームフィールドには、プレースホルダーではなく、明示的で目に見えるラベルが付けられます。

4. 明確な視覚的階層。エージェントはスクリーンショットからページの内容を読み取る必要があります。強いコントラスト、明確なセクション分け、一貫したフォントサイズ。人間にとってスキャン可能なものは、モデルにとってもスキャン可能です。

5つ目。ホバー専用のトリガーは使用しないでください。重要なものはすべて、ホバー状態でなくてもアクセスできるようにする必要があります。ホバー専用のメニュー、ツールチップ、削除機能は、エージェントの世界ではもはや不要です。エージェントはホバーしません。

開発上の留意点：ツール使用 vs コンピュータ使用 vs ハイブリッド

コンピュータ使用は最終手段としてのみ使用すべき機能です。ツール使用API​​は、クリーンなAPIインターフェースを備えたあらゆるものにおいて、コスト、レイテンシ、信頼性の面で優れています。ハイブリッドパターンは、ほとんどの運用システムで採用されています。

ツール使用は直接的です。エージェントが関数を呼び出し、関数が構造化データを返します。コストは低く、レイテンシは速く、信頼性は高いです。モデルコンテキストプロトコルと主要なツール使用API​​がこの領域をカバーしています。APIでラップできるものはすべてツール使用を使用してください。システムにAPIがない場合、APIの公開を拒否する場合、または所有していないサードパーティ製UIの背後にアクションが隠されている場合、コンピュータの使用はフォールバック手段となります。

ハイブリッドパターンが優れています。可能な限りツールを使用し、ロングテールなケースのみコンピュータを使用します。ツール呼び出しは数セントですが、コンピュータ使用ステップはわずか10セントです。90%ツール使用、10%コンピュータ使用のエージェントは、純粋なコンピュータ使用エージェントの10分の1のコストで提供できます。

次世代エージェントが実際に使用できる製品の提供、またはデモウェアに多額の費用をかけずにスタックにコンピュータ使用を組み込む方法についてサポートが必要ですか？Brainy を雇用する。ClaudeBrainyは、適切なモデルレイヤーを備えたスキルパックとプロンプトライブラリとしてClaude スキルで提供され、AppBrainyは、エージェントにスクリーンショットではなく実際の作業を実行させたいチーム向けに完全な製品ビルドを提供します。

2026年に出荷される実際のコンピュータ利用製品

Replit Agentは、クリーンなAPIがない状態で、デプロイとインフラ構築のステップでClaudeコンピュータ利用を実行します。Devinは、長時間のエンジニアリングタスクの中で、ベンダーのコンソール、ダッシュボード、管理パネルをナビゲートします。Operatorは、消費者のショッピング、スケジュール管理、フォーム入力処理を担当します。Browserbaseは、多数の垂直統合型エージェントスタートアップを支えています。Multi-Onは、営業および運用向けのブラウザネイティブなワークフロー自動化を提供します。Lutraは、その上に構築されたワークフロービルダーです。

これらの製品に共通するパターンは、狭い範囲、迅速なハンドオフ、可視的な状態、十分なエラー回復、そして実際のコスト計算です。彼らは、優れたエンジニアリングチームが不安定な依存関係を扱うのと同じように、コンピュータ利用を扱います。ラップ、バインド、計測、そして障害への備え。

どのチームも陥る4つの障害モード

1つ目は、汎用エージェントの罠です。チームは、本来ツール利用呼び出しで済むワークフローにコンピュータ利用を選択し、エージェントはAPI呼び出しなら100ミリ秒で済む処理に30秒と50セントを費やします。修正：ツールを優先的に使用し、ロングテールの場合のみコンピュータを使用する。

2. 監視スキップの罠。実データを変更するワークフローで監視なしのエージェントを実行すると、ステップ17でミスが発生し、データが失われる。修正：破壊的な操作はすべて監視付きで実行し、書き込みには確認ゲートを設け、デフォルトでドライランを実行する。

3. 脆弱なセレクタの罠。プロンプトが特定のUI状態に依存し、ターゲットサイトが更新されると、エージェントがサイレントにクラッシュする。修正：ピクセル座標ではなく、インテントに基づいてプロンプトを作成する。実サイトで毎週テストを行う。

4. コスト盲の罠。機能をリリースした後、請求書が届き、ユニットエコノミクスが成り立たない。修正：リリース前にタスクごとのコストをモデル化する。1回の実行あたり50セント未満であれば通常は採算が取れる。1回の実行あたり5ドルを超えることは稀である。

デザイナーと開発者のための意思決定マトリックス

デザイナー、フロントエンド開発者、バックエンド開発者、創業者。それぞれの役割によって最初の行動は異なる。

​​| 役割 | 最初の行動 | 理由 |

|---|---|---|

| デザイナー | エージェントフレンドリーなUIチェックリストを実行する | 現在のUIのほとんどはエージェントから見えません。まずこれを修正しましょう。 |

| フロントエンド開発者 | セマンティックHTML、ARIAラベル、予測可能なコンポーネントパターンを実装する | AI製品の導入をリリースするのと同じ作業がエージェント互換性も実現します。 |

| バックエンド開発者 | 製品が公開するすべてのアクションに対して、ツールで使用できるAPIサーフェスを構築する | コストと信頼性の面ではツール使用が優位です。コンピュータ使用はフォールバックです。 |

| 創業者 | 真の価値を提供する最小限のエージェントワークフローを選択する | 狭い範囲のワークフローが優位です。汎用的なエージェントは不利になります。 |

作業は均等に分配されていません。デザイナーとフロントエンド開発者はエージェントの可読性を担当し、バックエンド開発者はツール使用を担当します。創業者は担当する分野を選択します。

FAQ

AIのコンピュータ使用とは何ですか？

コンピュータ使用とは、AIモデルが画面を認識し、マウスとキーボードを制御し、人間のようにソフトウェアを操作できるようにする機能です。 Anthropic コンピュータ利用、OpenAI オペレーター、そしてBrowserbase、Multi-On、Lutraのブラウザネイティブエージェントは、2026年時点で実運用レベルの実装となっています。このモデルはスクリーンショットを撮影し、アクションを選択し、ツール呼び出しを行い、次のスクリーンショットを待ちます。

Anthropic コンピュータ利用はOpenAI オペレーターよりも優れていますか？

それぞれに異なる優位性があります。Anthropic コンピュータ利用は開発者向けの基本的な機能です。オペレーターはホスト型のコンシューマー向け製品です。開発者はAnthropic コンピュータ利用、またはBrowserbaseスタイルのインフラレイヤーを選択します。エンドユーザーはオペレーターを選択します。これらは異なる役割であり、直接競合するものではありません。

ブラウザエージェントで会社全体を管理できますか？

いいえ、そしてそのようなことを謳う製品は投資すべき製品ではありません。コンピュータ利用は、一般的なチームのワークフローのせいぜい10～15%程度をカバーするでしょう。成功のパターンは、特定のワークフローに特化したエージェントと、人間への迅速なハンドオフです。AdeptのACT-1は、汎用エージェントの野望を大規模に実現した好例と言えるでしょう。

AIエージェント向けに製品を再設計する必要はありますか？

セマンティックHTML、予測可能なパターン、明確なラベルを備えたアクセシブルなUIを提供していれば、ほぼ準備は整っています。しかし、ホバーのみのメニュー、カスタムキャンバスウィジェット、ラベルのないアイコンボタンを使用している製品の場合は、再設計が必要です。アクセシブルなUIはエージェントにとって使いやすい設計です。

ツール使用API​​よりもコンピュータ使用を選択すべきなのはどのような場合ですか？

ほとんどの場合、コンピュータ使用を優先すべきではありません。APIが存在する場合、コスト、レイテンシ、信頼性の面でツール使用API​​が優位です。コンピュータ使用は、APIが存在しないシステムの代替手段となります。2026年の実稼働エージェントのほとんどはハイブリッド型で、90%がツール使用、10%がコンピュータ使用となるでしょう。

コンピュータ使用への移行がもたらす真のメリット

コンピュータ使用は、より賢いチャットボットを生み出すものではありません。AIが人間と同じようにツールを扱えるようになる、それが初めて実現したのです。これは全く異なるカテゴリーの製品であり、ワイヤーフレームから設計に携わるチームが今後12ヶ月間を支配します。

多くのチームは依然としてエージェントを、自律性を付加したチャット機能として捉えています。一方、先行しているチームは、エージェントをチームと同じソフトウェアを使用する同僚として扱っています。前者は別のチャットタブをリリースし、後者は実際に機能する製品をリリースします。AIコードエディタの比較は、同じシフトの開発側をカバーしています。

今後1年以内に製品にエージェントが関わる場合（ほとんどの製品がそうなるでしょう）、今四半期に行う設計上の決定が、エージェントがユーザーを支援するか、あるいは完全に無視されるかを左右します。チェックリストを実行し、ワークフローを選択し、小さな成功を積み重ねましょう。

次世代のエージェントが実際に使用できる製品をリリースしたい場合、あるいはデモウェアに四半期を費やすことなく、コンピュータ利用をスタックに組み込みたい場合は、Brainy を雇用するを参照してください。ClaudeBrainyはスキルパックとプロンプトライブラリを提供しています。AppBrainyは、エージェントにスクリーンショットではなく実際の作業をさせたいチーム向けに、完全な製品ビルドを提供しています。