OpenAIが新たに発表したエージェント機能には、共通する狙いがあります。サービスごとにAPIが用意されるのを待つのではなく、人が使うのと同じアプリや画面をAIエージェントに直接操作させることです。OpenAIでコンピューター操作（画面、マウス、キーボードを通じてAIモデルがソフトウェアを操作する機能）の製品開発とエンジニアリングを率いる担当者によると、この方式でソフトウェアを操作するエージェントは、日常的なデジタル作業をすでに平均的な人より速くこなしています。次の目標は熟練したパワーユーザーを上回る速さで、それが実現すれば本当の意味でリアルタイムに反応する製品が可能になります。ここでは、アシスタントのDotからGPT-6.1 Sol、Agents API、Decisions APIまで、新しい要素がどう組み合わさるのか、そして開発者がいま何を確認すべきかを整理します。

エージェントごとに専用のコンピューター

DotはOpenAIの新しいパーソナルアシスタントで、コンピューター操作の機能が組み込まれています。これまでのシステムは、隔離されたブラウザーかユーザー自身のマシンの中でしか動けませんでした。Dotはエージェントごとにクラウド上の専用Linux仮想マシンを割り当て、その環境は継続して保たれます。

この設計によって、エージェントが扱える範囲は大きく広がります。完全なデスクトップ環境があるので、ネイティブのデスクトップアプリとWebブラウザーを並行して使えます。ほぼすべてのソフトウェアは人がグラフィカルな画面で操作する前提で作られているため、こうした環境を持つエージェントは、開発者向けAPIのないサービスも含め、人がコンピューターで行う作業の大半を原理的に引き受けられます。具体的な例は次のとおりです。

  • 鶏肉とご飯の量をグラム単位で指定する食事宅配の定期注文は、手作業で設定すると2時間かかりました。GPT-6.1 Solに任せると同じ注文が15分で終わり、約8倍の速さでした。
  • コミュニティへの投稿やサムネイルのA/Bテスト設定など、公開APIのないYouTubeのクリエイター向けツールの作業も、まさに向いている候補です。OpenAI社内の開発者体験チームは、すでにYouTubeの運用をコンピューター操作エージェントに任せています。
  • ほかにも、カスタマーサポートでのサインイン、本人確認、アカウントのトラブル対応や、DNSレコードの設定、高額な請求書の支払いをエージェントが処理した例があります。

スクロール矢印付きで積み重なったスクリーンショットと、構造化された画面要素のツリー

▲ スクリーンショットから画面構造へ

スクリーンショットから画面の構造へ

以前のコンピューター操作はピクセル情報だけが頼りでした。エージェントはスクリーンショットを撮り、スクロールし、また撮って、それらの画面をつなぎ合わせていました。この1年で、次の三つが変わりました。

以前 現在
断片的なスクリーンショットとスクロール DOM（Document Object Model）から得るページ構造とOSのアクセシビリティツリーで、画面全体を一度に把握
往復通信ごとにクリック1回 生成したJavaScriptで複数の操作を一度に実行
想定外のバグやポップアップで行き詰まる 失敗したステップを調べ、状態を診断して自らデバッグ

モデルはタスクに合わせて入力を使い分け、アクセシビリティツリー、Playwrightによるブラウザー自動化、スクリーンショットを組み合わせます。アクセシビリティ技術はもともとスクリーンリーダーのために作られたものですが、いまでは言語モデルがボタン、ラベル、テキスト欄をトークン効率のよい形で取り出すのに役立っています。画面の構造全体を把握できるため、モデルはばらばらの単発操作を重ねる代わりに、複数ステップのスクリプトを一度に書けます。

DevDayで披露されたAppshotsは、この方式をユーザーの手元で使えるようにする機能です。CodexやChatGPTでCommandキーを2回押すと、生のピクセルではなく、アプリのメタデータ、構造、アクセシビリティツリーを取り込みます。通常のスクリーンショットではリンク先や途中で切れたカレンダーの予定名といった情報が失われますが、Appshotsはそれらを保ったまま渡します。Codexでは添付ファイルをクリックすると送られた生のアクセシビリティデータを確認でき、ツール呼び出しを展開すると、エージェントが複数の画面操作をまとめるために書いたJavaScriptも見られます。

いちばん遅いのはWebサイトの側

DevDayの基調講演では、コンピューター操作の速度が7倍になったと示されました。この向上は、モデルとハーネス（モデルがツールを使えるようにするソフトウェア層）がともに改善した結果です。日々の進歩は小さく見えても、数カ月積み重なると信頼性と速度は大きく変わります。コストも下がりました。GPT-6.1 Solの価格は、一般的な作業ではAstraの約5分の1、コンピューター操作の作業では約7分の1です。

推論が速くなるにつれ、ボトルネックはモデルの外へ移ります。エージェントがDoorDashで注文すると、実行時間の大半はページの読み込みを待つことに費やされます。固定の待ち時間を入れるとその分だけ時間を無駄にするため、ページの描画が終わった瞬間からエージェントが次の操作をするまでの間隔を縮めることが課題です。ブラウザーの読み込みイベントを待つほうが決め打ちの待機より優れていますが、画面が更新されても明確な合図を出さないWebアプリはまだ多くあります。カスタマーサービスのチャットにも独自の遅れがあり、返答までに30秒から3分かかります。

OpenAIが開発者にAgents APIを勧める理由

OpenAIはコンピューター操作をAgents APIに組み込み、CodexやChatGPTが使っているのと同じツール実行用のハーネスを外部の開発者にも提供しました。独自のハーネスを作ることもできますが、OpenAIは自社のハーネスでモデルを学習させているため、公式の実装には精度、レイテンシー、コストの面で利点があります。

もう一つの前提条件は信頼です。重要な作業をエージェントに任せる点では、早期導入者が一般の利用者よりはるかに先を行っており、普及には安全策が欠かせません。

  • 金銭の支払いなど取り消せない操作の前には、ユーザーに確認を求めます。
  • エージェントがアクセスできる範囲を、作業に必要なドメインとアプリに限定します。

開発の進め方も変わります。エージェントはアプリを修正してビルドし、実行して見た目と動作の両方を確認できるため、これまで開発者がモデルの書いたコードに対して手作業で行っていた品質確認を引き受けます。画面を見ながら行うプレイテストはレイアウトの崩れを見つけ、同じ能力は既存アプリの画面を1枚ずつ再現する作業にも役立ちます。

モニター上でアプリをテストするロボットと、人の承認を待つ確認ダイアログ

▲ エージェントの自己テストとユーザー確認

速い判断と長い作業の使い分け

Decisions APIは、素早い分類と1ステップの判断を対象にしています。長い推論を省いた小さなモデルを並列で動かし、レイテンシーを抑えます。OpenAIのAPI製品責任者によると、これは新しいモデルではありません。既存のLunaの重みで動き、最初のトークンが出るまでの時間に合わせて推論基盤を調整し、構造化された出力を並列のバッチで評価します。最初のバージョンはゼロショットで提供し、専用のファインチューニングを行う前にフィードバックを集める方針で、Lunaの画像認識機能も追加の連携作業なしでそのまま使えます。

OpenAIが挙げる主な用途は二つです。

  • 大量の分類。OpenAI社内のユーザーオペレーションチームは、寄せられるサポートチケットの振り分けにこのAPIを採用しました。
  • コンピューター操作の流れの中での素早い一手。Astraのような高度なモデルは複数ステップのスクリプトを丸ごと書けますが、Decisions API上のLunaは次の一操作を選びます。

OpenAIは、GPT Liveがユーザーと会話しながら作業を振り分け、Decisions APIが会話を止めずにツールを呼び出す音声の構成も試しています。

限界もはっきりしています。推論を行わないDecisions APIは長い作業やあいまいな作業には向かず、速い実行と熟慮した推論を両立させる方法は、まだ研究段階の課題です。

エージェントに向けたAPIの変更点

長時間動作し、対話的にやり取りするエージェントに向けて、いくつかのプラットフォーム更新が行われました。

  • 非同期のツール呼び出し: GPT-6とともに導入され、時間のかかるツールを起動したままモデルが生成と推論を続け、ツールが終わったら結果を受け取れます。
  • ターン途中のステアリング: モデルが推論している最中に、開発者が新しい指示を差し込めます。
  • WebSocket: アプリとモデルの間で全二重の接続を保ち、ツールを何度も往復で呼び出す際のオーバーヘッドを減らします。
  • 応答の高速化: Responses APIのバックエンドを書き直し、最初のトークンが出るまでの時間とトークン間の間隔を短縮しています。
  • キャッシュの保証: 30分以内のキャッシュヒットを保証し、企業ユーザー向けの12時間保証はまだプレビュー段階です。キャッシュ書き込み料金を前払いしてプロンプトを事前にウォームアップでき、診断ツールでプロンプトの先頭部分がどこでキャッシュに当たらなくなるかを確認できます。
  • コンパクション: Agents APIではハーネスの中で自動的に行われます。Responses APIでは、設定したトークン数に達するとサーバーが履歴を圧縮するほか、compactコマンドで自分で実行することもできます。

OpenAIは、最先端モデルを現時点で可能な最高速度に近づけるUltrafastモードも発表しました。それ以前の効率化によって、Lunaの価格はすでに約80%下がっています。

開発者がいま取り組むべきこと

OpenAIの方向性は、オールインワンのエージェント用フレームワークよりも、コンピューター、判断の呼び出し、キャッシュといった部品を重視しているように見えます。OpenAIのAPI製品責任者は、低レベルの基本機能と使いやすい上位の抽象化のバランスを、決済の基本機能の上で多くの製品が育ったStripeでの経験になぞらえて説明しています。実践的な次の一歩は次のとおりです。

  1. 公開APIのない、複数ステップの繰り返し作業を選び、コンピューター操作エージェントに任せてみます。
  2. エージェントには、固定のタイマーではなく読み込みイベントなどのページの合図を待たせます。
  3. 支払いなど取り消せない操作の前にユーザーの確認を挟み、各エージェントのアクセスを必要なドメインに限定します。
  4. 素早い分類や1ステップの判断はDecisions APIに回し、複数ステップの作業は大きなモデルに任せます。
  5. システム指示とプロンプトの先頭部分を一定に保ってキャッシュヒット率を高め、診断ツールでキャッシュが途切れる箇所を見つけます。