2026年9月30日時点で、OpenAI Agents APIのComputer useは、OpenAIが用意するブラウザをエージェントに操作させる機能で、2026年9月29日（米国時間）のDevDay 2026で追加されました。使うための設定は3か所で、ツールにcomputer_useを足し、環境の種類をopenai_hostedにして、desktopを有効にします。ただし、サイトごとのアクセスの承認とサインインの入力は、利用者のアプリが受け持つ作りです。
土台のAgents APIは、2026年9月10日にパブリックベータとして公開されたAPIです。OpenAIがCodexのハーネス（モデルとツールのループを回し、作業の状態を保つ仕組み）を動かし、アプリはタスクを送って結果を受け取ります。DevDay 2026の発表は、Computer useに加えて、Codexのマルチエージェント機能・ツール検索・ツール呼び出し・コンテキストの圧縮をアプリに持ち込めると書き、提供範囲を「APIと、Pro 500・EnterpriseのCodexとChatGPT Work」としています。
この記事の要点（2026年9月30日時点）
- Agents APIは2026年9月10日にパブリックベータで公開され、9月29日（米国時間）にComputer useが加わりました。どちらもOpenAIのAPIの変更履歴に載っています
- ブラウザはOpenAI側の環境で動きます。公開サイトも含めて、新しいオリジン（サイトの出どころ）ごとに利用者の承認が要り、ネットワークを有効にしても承認は省けません
- サインインはメールアドレス・パスワード・確認コードに対応し、パスキーとQRコードには対応していません。サインインを求められるのはメインのエージェントだけです
- 料金の説明は「モデルのAPI料金・OpenAIのツールの標準料金・サンドボックスのコンテナ料金」の3つで、Computer use単体の単価は料金ページに見当たりません
- データの保管先は米国のみで、Zero Data Retention（ZDR）には対応していません。自前のサンドボックスを選んでも変わりません
対象読者：エージェントのループやサンドボックスを自前で組んでいる開発者、Agents SDKやResponses APIのComputer useを使っているチーム。読み終えたらできること：Computer useの最小構成を動かし、承認とサインインの処理を設計して、今の実装から移すかどうかを判断できます。
この記事は、developers.openai.comにあるAgents APIのドキュメント（概要・Quickstart・Architecture・Computer use・サンドボックス・マルチエージェント・料金など）と、APIの変更履歴、OpenAIの「DevDay 2026 Recap」を2026年9月30日に読んで整理したものです。コードはドキュメントの例をそのまま載せています。
OpenAI Agents APIのComputer useとは｜9月29日に加わった機能
OpenAIのAPIの変更履歴は、2026年9月29日の項目で「Agents APIにComputer useを追加した。エージェントはOpenAIが用意するブラウザでタスクを完了でき、Webサイトへのアクセスの承認とサインインはアプリが扱う」と書いています。同じ日に公開されたDevDay 2026 Recapは、「ソフトウェアを操作してタスクを完了するエージェントを作れる」「土台の基盤はOpenAIが動かすので、チームはアプリ作りに集中できる」と説明しました。
| 日付（米国時間） | 出来事 | 出典 |
|---|---|---|
| 2026年9月3日 | GPT-6 Astraを公開。今回読んだAgents APIのドキュメントの例は、すべてこのモデル（gpt-6-astra）を使う |
APIの変更履歴 |
| 2026年9月10日 | Agents APIをパブリックベータで公開。セッションの段取り・コンテキストの圧縮・回復をOpenAIが受け持つ | APIの変更履歴 |
| 2026年9月29日 | DevDay 2026で、Agents APIにComputer useを追加 | APIの変更履歴・DevDay 2026 Recap |
開発者から見て変わった点は、ブラウザを動かす環境と操作のループを、OpenAI側に任せられるようになったことです。Responses APIのComputer useでは、ブラウザやデスクトップの環境を利用者が用意し、モデルが返した操作を自分のアプリで実行します（Responses API側のガイドの説明）。Agents APIのComputer useでは、ブラウザはOpenAIの環境で動き、アプリが扱うのは承認とサインインの入力、そして結果の確認です。
Agents APIとは｜CodexのハーネスをOpenAIが動かすAPI
Agents APIの概要ページは、このAPIを「Codexのハーネスに、OpenAIが管理するAPIとしてアプリからアクセスできるようにしたもの」と説明しています。セッション・作業の段取り（オーケストレーション）・コンテキストの圧縮・障害からの回復はOpenAIが受け持ち、アプリはツールを用意して、エージェントが作業する環境を選びます。
Architectureのページは、全体を3つの部品で説明しています。
- Codexのハーネス：OpenAIが動かすCodexのインスタンスで、モデルとツールのループを回し、エージェントのセッションを保ちます
- 環境：エージェントがコマンドを実行し、コードを動かし、ファイルを扱う場所です。リモートのサンドボックス、手元のノートPC、Dockerのコンテナ、AWS Lambdaの関数のどれでもよいと書かれています
- アプリケーションサーバー：エージェントと自社の製品をつなぐ利用者のコードです。タスクを送り、イベントを受け取り、関数ツールの呼び出しを処理します
環境は、OpenAI側のサンドボックス（openai_hosted）、自前のサンドボックス（self_hosted）、環境なし（none）の3つから選びます。質問に答えるだけ、外部サービスのツールを呼ぶだけのエージェントなら、環境なしでも動きます。
4つの基本の用語
| 用語 | 概要ページの説明 |
|---|---|
| Agent | エージェントが使うモデル・指示・ツール・MCPサーバー |
| Environment | エージェントがファイルに触れ、スキルを読み込み、コマンドを実行するサンドボックスやコンピューター。無くてもよい |
| Session | タスクをこなし、入力に応える、長く続くエージェントの実体 |
| Events and items | エージェントに送る入力と、セッションの中で出てくる出力 |
セッションの流れは、セッションを作る、タスクを渡す、進み具合を追う（ストリーミングかWebhook）、続きを頼むか作業中に指示を足す、の4段です。セッションの状態はOpenAIが保つので、会話の文脈を作り直さずに、ターンをまたいで作業を続けられます。
Responses API・Agents SDKとの関係
OpenAIの「Agents」のページには、3つの実行方法を比べる表があります。要点を訳すと次のとおりです。
| 観点 | Agents API | Agents SDK | Responses API |
|---|---|---|---|
| 向いている用途 | OpenAIがエージェントを管理し、進み具合を保存する長いタスク | 独自のツールと手順を持つエージェントをアプリの中で作る | モデルを直接呼ぶ、またはエージェントを一から作る |
| エージェントが動く場所 | OpenAIが動かすCodexのハーネス | アプリの中（SDKが動く） | アプリの中（ホスト側の段取りも選べる） |
| 組み込みの手間 | 低い | 中くらい | 高い |
| タスク間の状態 | セッションの設定・ターン・アイテムを保存 | 自社の保存先とSDKのセッション、またはResponsesの会話の状態 | 履歴を手で管理、応答のつなぎ、またはConversations |
| 実行環境 | OpenAI側のサンドボックス・自前のサンドボックス・なし | 自社の実行環境と、サンドボックス事業者との連携 | 自社の実行環境 |
同じページは、Agents APIが「コンテキストの自動の圧縮、マルチエージェントの段取り、プログラムからのツール呼び出し、MCPサーバー」を含むと書き、Agents SDKについては「デプロイ・保存・承認・実行環境との連携をアプリ側で制御できる」と説明しています。Agents SDKの実装とコストの考え方は、当サイトのOpenAI Agents SDK完全ガイドで整理しています。
Computer useでできること｜OpenAI側のブラウザで操作する
Agents APIのComputer useは、エージェントにWebサイトを移動させ、ブラウザの画面を操作させる機能です。ドキュメントは用途として、Webサイトのテスト、情報の収集、画面からのアプリの操作の3つを挙げています。ブラウザはOpenAIが用意した環境の中で動き、アプリはセッションを始めてイベントを追い、エージェントはブラウザで見たものをもとに次の操作を決めます。
設定は3か所
Computer useのドキュメントの手順では、次の3か所を設定します。APIリファレンスはcomputer_useを「OpenAI側のセッションでのブラウザ操作」、desktop.enabledを「デスクトップとブラウザ用のプロキシを用意するかどうか」と説明しており、desktopを省くとテンプレートの設定を引き継ぐか、無効になります。
| 設定する場所 | 値 | 意味 |
|---|---|---|
agent.tools |
{ "type": "computer_use" } |
ブラウザ操作のツールを足す |
environment.type |
openai_hosted |
OpenAI側のサンドボックスで動かす |
environment.desktop.enabled |
true |
デスクトップとブラウザ用のプロキシを用意する |
include_screenshots（任意・ツールの設定） |
true |
操作ごとのスクリーンショットをAPIの出力に含める（既定はfalse） |
操作の記録とスクリーンショット
ブラウザの操作は、セッションの出力にcomputer_use_callというアイテムとして出ます。各アイテムには、どのターンの操作か（turn_id）、操作の説明（title）、状態（in_progress・completed・failed・incomplete）、スクリーンショット（output）が入ります。このアイテムは1回の操作の記録で、エージェントの最終的な答えや、ターン全体の完了を表すものではありません。
スクリーンショットは既定ではAPIの出力に含まれません（エージェント自身は画面を見ています）。include_screenshotsをtrueにすると、各操作の最後の画面がJPEGのdata URLで返りますが、操作によってはnullになります。ドキュメントは、スクリーンショットにはページやアカウントの機密が映りうるので、権限のある人にだけ見せ、アプリのログに残さないよう求めています。
OpenAIの3つの「Computer use」の違い
OpenAIには、名前の似た機能が3つあります。検索で出てくる情報がどれの話かを取り違えやすいので、ドキュメントの記載で並べます。
| 機能 | 画面を動かす場所 | 操作を実行する側 | 使う入口 |
|---|---|---|---|
| Agents APIのComputer use（今回の発表） | OpenAI側の環境のブラウザ | OpenAIが動かすハーネス | Agents API |
| Responses APIのComputer use | 利用者が用意するブラウザやデスクトップ | 利用者のアプリ（モデルが書いたコード、またはcomputerツールが返す操作を実行） | Responses API |
| ChatGPTデスクトップアプリのComputer Use | 手元のmacOS・Windowsの画面 | ChatGPT（Computer Useのプラグイン） | ChatGPT WorkとCodex（対応地域） |
Responses API側の使い方は、GPT-5.4の時点の記事ですがGPT-5.4のネイティブComputer Use｜APIの使い方で扱っています。2026年9月30日時点のResponses APIのガイドは、GPT-6 Astraではコードを書かせて実行する方式を勧め、computerツールも引き続き使えると書いています。
最短の動かし方｜ドキュメントのコードで確かめる
ここでは、Computer useのドキュメントにある「公開されている開発者サイトでAgents APIのQuickstartを探し、題名とURLを答えさせる」例を、Pythonで順に動かす流れを示します。ドキュメントが示す手順は5段で、最初のセッションでcomputer_use・openai_hosted・desktopの3か所を設定します。
- ブラウザのセッションを作る（セッションIDを控える）
- タスクを送りイベントを追う
- オリジンの承認とサインインに応える
- メインのエージェントのターンの完了と結果の確認
- 記録を読みセッションを削除
下のコードは、この5段を4つの手順に分けて載せます。承認に応える関数を、タスクを送る前に定義しておくためです。
事前の準備
APIキーは、OpenAI Platformのプロジェクトで作るアプリケーション用のキーで、セッションの操作にapi.agents.readとapi.agents.write、モデルの推論にapi.responses.writeの権限が要ります（Quickstartの前提条件）。キーはエージェントのサンドボックスの外に置きます。リクエストにはOpenAI-Beta: agents=v1のヘッダーが必要で、公式のSDKは自動で付けます。cURLで呼ぶ時だけ自分で付けます。
export OPENAI_API_KEY="your-api-key"pip install --upgrade openaiまずAgents APIだけを試す（Quickstart）
Computer useの前に、Agents APIそのものが動くかを確かめるなら、Quickstartの例が最小です。OpenAI側のサンドボックスでtree.pyを書いて実行させ、流れてくるイベントを表示します。
from openai import OpenAI
with OpenAI() as client:
with client.beta.agents.sessions.create(
agent={
"model": "gpt-6-astra",
"instructions": "Write clean code, run it, and report the actual output.",
},
environment={"type": "openai_hosted"},
input="Create tree.py, a Python script that prints a readable tree of the files in the current directory. Run it and show me the output.",
stream=True,
) as events:
for event in events:
print(event.to_json(indent=None), flush=True)イベントにagent.session.turn.completedが出たら、エージェントが報告した実行結果を確かめます。Quickstartは「ターンが完了しても、すべてのツールが成功したとは限らない」「agent.session.idleだけでは成功を意味しない」と注意しています。
手順1 ブラウザのセッションを作る
Computer useのドキュメントの例です。ツールにcomputer_use（スクリーンショットあり）を指定し、環境はopenai_hostedでdesktopを有効にしています。この時点ではタスクは始まりません。先頭のimportと最後のready_to_deleteは、後の手順で使います。
import base64
import os
from pathlib import Path
from openai import OpenAI
client = OpenAI()
session = client.beta.agents.sessions.create(
agent={
"model": "gpt-6-astra",
"instructions": "Read public documentation in the browser. Do not sign in or change any website data. Report the page title and URL you find.",
"tools": [{"type": "computer_use", "include_screenshots": True}],
},
environment={
"type": "openai_hosted",
"desktop": {"enabled": True},
"network": {"access": "enabled"},
},
)
print("Session ID:", session.id, flush=True)
ready_to_delete = False手順2 オリジンの承認に応える関数を用意する
ブラウザは新しいサイトに入る前に、利用者の承認を求めてきます。この関数は、依頼の種類がbrowser_origin_accessならオリジンと理由を表示してapprove・deny・cancelを選ばせ（何も入力しなければdeny）、公開ページを読むだけのこの例では、サインインの依頼（browser_authentication）を取り消します。
def respond_to_origin_approval(client, session_id, approval):
request = approval.request
if request.type == "browser_origin_access":
print(request.reason or "The browser needs access to an origin.")
print("Origin:", request.origin)
while True:
decision = (
input("Allow this origin? [approve/deny/cancel; default: deny] ")
.strip()
.lower()
or "deny"
)
if decision in {"approve", "deny", "cancel"}:
break
print("Enter approve, deny, or cancel.")
response = {"type": "browser_origin_access", "decision": decision}
elif request.type == "browser_authentication":
print("This public-page task does not sign in; cancelling the request.")
response = {"type": "browser_authentication", "action": "cancel"}
else:
raise RuntimeError(f"Unsupported computer-use approval: {request.type}")
client.beta.agents.sessions.events.create(
session_id,
events=[
{
"type": "agent.session.input.computer_use_approval_request_result",
"request_id": approval.request_id,
"response": response,
}
],
)手順3 タスクを送り、結果を追う
イベントのストリームを先に開いてから、タスクを送ります。agent.session.requires_actionが来たらセッションを取り直し、required_actionsにある承認の依頼に応えます。メインのエージェント（subagent_idがNone）のターンが完了したところで終わります。
handled_requests = set()
completed = False
with client.beta.agents.sessions.events.stream(session.id) as events:
client.beta.agents.sessions.events.create(
session.id,
events=[
{
"type": "agent.session.input.message",
"input": [
{
"role": "user",
"content": [
{
"type": "input_text",
"text": "Open https://developers.openai.com in the browser. Find the Agents API quickstart, then report its page title and URL.",
}
],
}
],
}
],
)
for event in events:
if event.type == "agent.session.requires_action":
current = client.beta.agents.sessions.retrieve(session.id)
for approval in current.required_actions:
if (
approval.type == "computer_use_approval_request"
and approval.request_id not in handled_requests
):
respond_to_origin_approval(client, session.id, approval)
handled_requests.add(approval.request_id)
elif event.type == "agent.session.turn.output_text.done":
print(event.text, flush=True)
elif event.type == "agent.session.turn.completed":
if event.turn.subagent_id is None:
completed = True
print()
break
elif event.type in {
"agent.session.turn.failed",
"agent.session.turn.cancelled",
}:
if event.turn.subagent_id is None:
raise RuntimeError(f"Browser task ended: {event.type}")
elif event.type == "error":
raise RuntimeError(event.error.message)
elif event.type in {
"agent.session.failed",
"agent.session.environment.failed",
}:
raise RuntimeError(f"Session failed: {event.type}")
else:
raise RuntimeError("Stream closed before the browser task finished.")ドキュメントは、イベントのストリームを閉じてもタスクは止まらないと書いています。止める時は、ターンを取り消すイベント（agent.session.input.cancel）を送ります。接続が切れて結果が分からない時は、同じセッションを取り直し、required_actionsを見てから次の操作を決めます。
手順4 記録を読み、セッションを削除する
ターンが終わったら、client.beta.agents.sessions.items.listでcomputer_use_callのアイテムを読み、操作の記録とスクリーンショットを確かめます。ブラウザの状態を使う続きのタスクは同じセッションに送れますが、ログインのCookieは期限が切れることがあり、環境を作り直すとブラウザの状態は消えます。使い終わったら、必要な結果を取り出してからセッションを削除し、環境の後片付けを依頼します。
if ready_to_delete:
client.beta.agents.sessions.delete(session.id)動作環境：Python、beta版のAgents APIを含む版のopenaiパッケージ（ドキュメントの指定は「beta版のAgents APIを含む版のSDK」で、版の番号は書かれていません）。本番環境で使用する前に、必ずテスト環境で動作確認してください。
サイトの承認とサインイン｜アプリ側が受け持つ2つの確認
Agents APIのComputer useでは、ブラウザの操作そのものはOpenAI側で進みますが、2種類の確認はアプリが受け持ちます。1つはサイトのオリジン（出どころ）ごとのアクセスの承認、もう1つはサインインの入力です。どちらもagent.session.requires_actionのイベントで知らされ、セッションのrequired_actionsにcomputer_use_approval_requestとして入ります（requires_actionが合図です）。
オリジンの承認（browser_origin_access）
- 公開サイトも含めて、新しいオリジンに入る前に承認が要ります。ネットワークのアクセスを有効にしても、承認したことにはなりません
- 決定はapprove・deny・cancelの3つで、同じ
request_idを付けてagent.session.input.computer_use_approval_request_resultのイベントで返します。一度受理された決定を変えると409になります - オリジンの承認の依頼は、そのターンが続く間は残り、サインインのような5分の期限はありません。履歴に専用のアイテムは残らないので、
required_actionsで扱います
注意したいのは、オリジンの承認が「個々の操作の前の確認」ではないことです。ドキュメントは、購入や破壊的な変更などの前に確認を必ず挟みたいなら、そうした操作ができない資源にブラウザを限定するか、自分で制御するブラウザの実行環境を使うよう書いています。関数ツールで確認を取る方法は、エージェントがその関数を呼ぶことに頼るからです。Webサイトの内容は信頼できないものとして扱い、ページの文言が許可を与えたり、利用者の指示を上書きしたりすることはできない、とも書かれています。
サインイン（browser_authentication）
非公開のGitHubリポジトリのIssueを読むように、サインインが要るタスクで使います。利用者がログイン方法を選び、認証情報をチャットの外で入力できるように、サインインの処理はアプリが受け持ちます。
- サインインを求められるのはメインのエージェントだけで、サブエージェントは求められません
- 対応しているのはメールアドレス・パスワード・確認コードで、パスキーとQRコードでのサインインには対応していません。これらが必須のサイトは、この流れではサインインできません
- 依頼には、理由（
reason）、認証情報の送り先（credential_origin）、入力欄（fields）、ログイン方法（options）が入ります。ログイン方法がある時は利用者に選ばせ、その方法の入力欄だけを出します - 応答はsubmit・cancelのどちらかです。値は専用のイベント（
actionにsubmit）だけで渡し、通常のメッセージや関数ツールの結果に入れません。専用のイベントで送った値はモデルの入力に入らず、履歴の応答アイテムにも残りません - 入力した値はメールアドレスも含めて機密として扱い、画面では伏せ、ログや分析に残さず、送信後は入力欄を消します。認証情報の送信では、HTTPやSDKの自動の再試行を切ります
- 送り先が表示されない、または見覚えがなく確かめられない時は、依頼を取り消すよう求められています
- サインインの依頼は5分で期限切れになり、入力中にターンが終わることもあります。1回の送信は入力欄6つまで、値は1つ16,384文字まで、合計120 KiBまでです
202が返っても、それは送信が受理されたという意味で、サインインの成功ではありません。結果はターンの完了まで追う必要があります。
応答の結果ごとの対処
| 結果 | アプリがすること |
|---|---|
202 |
送った値を消し、イベントで結果を追う |
400 |
応答の種類・選んだ方法・入力欄のID・必須の値を、保留中の依頼と照らす。取り消しとオリジンの応答では入力欄を付けない |
404 |
セッションID・依頼のID・応答の種類を確かめ、セッションを取り直す（依頼がもう無いことがある） |
409 |
セッションを取り直す。依頼の期限切れ、ターンの終了、別の応答の受理のどれかが考えられる |
| 受理の前に接続が切れた | 受理されたかは不明として扱い、つなぎ直してセッションを取り直してから、再送するかを決める |
サインインの送信をやり直す時は、同じ依頼のID・同じログイン方法・同じ値の組み合わせで送ります。同じ内容の再送で、ブラウザのフォームにもう一度入力されることはありません。受理後に値を変えると409になり、新しくサインインするには、エージェントからの新しい依頼が要ります。
途中で利用者に質問したい時
タスクの途中で利用者に確認や選択を求めたい時は、関数ツールを定義します（ドキュメントの例ではrequest_user_responseという名前）。agent.session.requires_actionで保留中のfunction_callを見つけ、その引数で質問を表示し、答えをagent.session.input.tool_resultで返します。関数ツールの結果はモデルから見え、セッションの履歴に残るため、パスワードや確認コードはこの方法では集めず、サインインの流れを使います。
サンドボックスの選び方｜OpenAI側・自前・環境なし
Agents APIの環境は3種類で、セッションを作る時にenvironment.typeで選びます。Computer useのブラウザは、ドキュメントの手順どおりopenai_hostedで動かします。APIリファレンスもcomputer_useを「OpenAI側のセッションでのブラウザ操作」と定義しています。
| environment.type | 用意する側 | できること | 向いている場面 |
|---|---|---|---|
none（環境なし） |
用意しない | 質問への回答、リモートのMCPや関数ツールの呼び出し。組み込みのBashとapply patch、ワークスペースのファイル、executorのMCPは使えない | 計算やファイルが要らないエージェント |
openai_hosted |
OpenAIが用意 | Python・Node.js・コマンドラインのツールが入ったLinuxのワークスペース。Computer useのブラウザもここで動く | スクリプトの実行、ファイルの編集、成果物の作成、ブラウザの操作 |
self_hosted |
利用者が用意（自前の環境でcodex exec-serverを動かす） |
自社のイメージ・計算資源・非公開のネットワークで、コマンドとツールを実行 | 自社の基盤や社内のネットワークが要る作業 |
OpenAI側のサンドボックス（openai_hosted）
作業場所は/workspaceです。必要な設定だけを足します。
packages：Python・システム・npmのパッケージを入れる（pandas==2.2.3のように版を固定できる）setup_commands：エージェントが動き出す前に、順にシェルのコマンドを実行する。0以外で終わるとエージェントは始まらないfiles：入力ファイルを、Files APIのIDかbase64で渡すenv：文字列の環境変数。エージェントが生成したコードからも読めるため、秘密の値はVaultsの認証情報で環境の外に置く。PATH・CODEX_*・OPENAI_API_KEYなどの予約名は受け付けないskills・plugins・capability_directories：スキルとプラグインを足すenvironment_template_id：保存した設定を、セッションをまたいで使い回す。テンプレートより広いネットワークの許可には上書きできない
| container_size | vCPU | メモリ |
|---|---|---|
small |
1 | 1 GB |
medium（既定） |
2 | 4 GB |
large |
4 | 16 GB |
ファイルはサンドボックスがある間はターンをまたいで残り、/workspace/outputsに置いたファイルは、ターンの完了時に変更できない成果物（artifact）として公開され、サンドボックスが消えた後もダウンロードできます。接続中のサンドボックスには、ターンの合間も含めて生存確認（keep-alive）が送られ、作業と生存確認が1時間止まると削除されることがあります。この時間は変えられません。セットアップの状態はGET /v1/agents/environments/{environment_id}で確かめ、provisioningは準備中、connectedは準備完了です。
自前のサンドボックス（self_hosted）
自前の環境でも、ハーネスを動かすのはOpenAIです。利用者は環境の中でcodex exec-server（executor）を動かし、executorがハーネスの依頼に応じてシェルのコマンドを実行し、ファイルを読み書きし、ローカルのMCPサーバーを使います。executorは環境IDと権限を絞ったキーで登録し、WebSocketでつないで命令を受け取ります。接続はすべて外向きで、切れたらつなぎ直します。ドキュメントの準備と起動のコマンドは次のとおりです。
mkdir -p /workspace
npm install -g @openai/codex@alphacodex exec-server \
--remote "<session.environment.remote_url>" \
--environment-id "<session.environment.id>"- 外向きの接続を許可するホストは、登録用の
https://api.openai.comと、命令と結果のやり取り用のwss://codex-cloud-environments.chatgpt.comの2つです - executorには、Platformのダッシュボードの「Agents」タブで作る環境キーを
CODEX_API_KEYとして渡します。このキーは環境をつなぐことだけに使え、ほかのAPIの操作には使えません。アプリのOPENAI_API_KEYは環境の外に置きます - 環境の用意・つなぎ直し・停止と、残したいファイルの保存は利用者の受け持ちです
ドキュメントには、Modal・Cloudflare・Vercel・Daytona・Blaxel・E2B・Runloop・DigitalOcean・AWS Lambda MicroVMs・Oracle Cloud Infrastructure（OCI）の10の事業者向けの手順があります。事業者の選び方は、当サイトのE2B・Daytona・Modal完全比較も参考になります。
安全策｜ネットワーク・鍵・データの扱い
Sandbox securityのページは、最初に「エージェントが生成したコードは、その環境で使えるファイル・認証情報・ネットワークにアクセスできる」と書いています。Computer useを含むAgents APIの安全策は、この前提から組み立てます。
ネットワークを絞る
| network.access | 動き |
|---|---|
enabled |
外向きの通信を許可する（テンプレートの設定を引き継がない限り既定） |
disabled |
外向きの通信を止める |
restricted |
allowed_domainsに書いたホストだけを許可する |
restrictedでは、api.example.comのような完全なホスト名を1〜100個書きます。ワイルドカード・プロトコル・パス・ポートは書けず、サブドメインとリダイレクト先はそれぞれ別に書きます。Computer useでは、目的のサイトに加えて、ページの部品やリダイレクトに要るドメインも許可します。オリジンの承認はネットワークの設定とは別の判断で、ネットワークの制限を上書きしません。なお、ホスト側で動かすstdioのMCPサーバーは、現在enabledが必要です。
鍵と認証情報を環境の外に置く
- アプリのキーには、セッション用の
api.agents.read・api.agents.writeと推論用のapi.responses.writeを与え、Vaultsを管理するならapi.vaults.read・api.vaults.writeを足します - 外部サービスの認証情報は環境の外に置きます。OpenAI側のサンドボックスからAPIを呼ぶ時は、Vaultsの秘密を環境変数として使います。サンドボックスのコードには仮の値だけが見え、承認したホストへの通信でだけ、ネットワークのプロキシが本物の値を付けます
- 利用者や作業ごとに環境を分け、データを共有してはいけない利用者を同じ環境に入れません。アプリや作業ごとに専用のOpenAIのプロジェクトを作ることも勧められています
- 保存した秘密を環境に注入すると、エージェントが生成したコードから見えてしまいます。長く使う認証情報は秘密の管理の仕組みに置き、定期的に入れ替えます
サンドボックスの分離の考え方は、当サイトのAIエージェント サンドボックス設計｜gVisor比較でも整理しています。
データの保管先と保持
概要ページは、Agents APIのデータの保管先（データレジデンシー）は現在米国のみで、Zero Data Retention（ZDR）には対応していないと書いています。自前のサンドボックスを選んでも、ZDRの対象にはなりません。データの扱いのページ（Data controls in the OpenAI platform）の表では、/v1/agentsは次のとおりです。
| 項目 | /v1/agents |
|---|---|
| 学習への利用 | なし |
| 不正利用の監視のための保持 | 30日 |
| アプリの状態の保持 | 削除するまで |
| Zero Data Retentionの対象 | 対象外 |
| Private Retention with PSPとSafety Retentionの対象 | 対象外 |
セッションの状態は、ターンをまたいで作業を続けるために保存されます。使い終わったセッションと公開した成果物は削除できます。機密の情報を扱うかどうかは、この保持の条件を社内の規程と照らして決めてください。
安全の仕組みで止まる場合と、実行の上限
エラーの一覧には、安全の仕組みがリクエストを止めた時のコードとしてcyber_policyとmisalignment_policy_violationがあります。また、Responses API側のComputer useのガイドは、画面を操作させる時の注意として次の4つを挙げています。
- 分離したブラウザやVMと、許可するサイトと操作の一覧で環境を絞る
- 画面の内容を信頼しない（ページや文書の文言は許可にならない）
- 購入・データの送信・破壊的な変更など、取り返しにくい操作は利用者に確認させる（フォームへの機密の入力も送信に当たる）
- 手数・時間・費用の上限を決めて取り消せるようにし、モデルの最終回答だけでなく実際の結果を確かめる
Codex由来の機能｜マルチエージェント・ツール検索・圧縮
DevDay 2026 Recapは、Agents APIが「Codexのマルチエージェント機能・ツール検索・ツール呼び出し・コンテキストの圧縮」をアプリに持ち込むと書いています。ドキュメントで対応する設定を拾うと次のとおりです。
| 機能 | Agents APIでの設定 | 既定と注意 |
|---|---|---|
| マルチエージェント | agent.multi_agent.enabledをtrueにする |
同時に動くサブエージェントは既定で6（まとめ役を除く）。max_concurrent_subagentsで変える |
| ツール検索 | agent.toolsに{ "type": "tool_search" }を足し、後から読み込ませたい関数にdefer_loading: trueを付ける |
関数の定義は、既定ではすべて最初に読み込む。MCPのツールは、モデルと提供元が対応していれば自動で検索の対象になる |
| ツール呼び出し | 関数ツールとMCPに加え、プログラムからのツール呼び出し（Programmatic Tool Calling）が既定で有効 | ハーネスがexecツールを渡し、生成したJavaScriptの中から既存のツールを呼べる。止める時は{ "type": "programmatic_tool_calling", "enabled": false } |
| コンテキストの圧縮 | 設定なし（ハーネスが前の作業を要約して、文脈の長さを管理する） | Responses APIでは、context_managementのcompact_thresholdを自分で設定する |
| 作業中の指示（steering） | 作業中のセッションにagent.session.input.messageを送る |
受け付けられない時はactive_turn_not_steerableが返る |
マルチエージェントの例
マルチエージェントのページの例は、2つのリリースノートを別々のサブエージェントに読ませ、結果を1つの要約にまとめます。環境もツールも要りません。
from openai import OpenAI
client = OpenAI()
with client.beta.agents.sessions.create(
agent={
"model": "gpt-6-astra",
"instructions": "Delegate each release to a separate subagent. Ask each to extract customer-visible changes and required migration steps using only its release notes. Wait for both results, then combine them into one release summary with release labels. Do not invent missing details.",
"multi_agent": {"enabled": True, "max_concurrent_subagents": 2},
},
environment={"type": "none"},
input="Release A: Search now supports filtering by date. Existing queries continue to work. Release B: The export endpoint now returns a download URL instead of file bytes. Update clients to fetch that URL.",
stream=True,
) as events:
for event in events:
print(event.model_dump_json())ハーネスが、サブエージェントを作る・メッセージを送る・待つ・中断するためのツールを自動で用意するので、自分で宣言する必要はありません。サブエージェントは、設定したMCPのツールとその認証情報、Web検索の設定を引き継ぎ、環境のファイルとコマンドラインのツールも使えますが、関数ツールには対応していません。まとめ役とサブエージェントは同じファイルシステムを使い、サブエージェントを作っても環境は増えません。どのエージェントが動いたかは、ターンのsubagent_idで分かります（メインのエージェントはnull）。
ツール検索とプログラムからのツール呼び出し
ツール検索のガイドは、関数を最初にすべて読み込む方法と、defer_loading: trueで必要な時に読み込む方法を比べています。前者は、使わない定義も文脈を占め、定義を変えるとキャッシュ済みの先頭部分が使えなくなることがあります。後者は、関数の数が多く、各タスクで使うのが一部だけの時に向きますが、探す手順が1つ増え、目的のツールを見つけられるかに左右されます。1つのセッションで両方を混ぜることもできますが、一般には勧めていません。
プログラムからのツール呼び出しは、JavaScriptの中からツールを呼んでも、ツールが動く場所は変わりません。シェルのコマンドはサンドボックスで、関数ツールは利用者のアプリケーションサーバーで動きます。環境なし（none）のセッションでも使えます。
コンテキストの圧縮と作業中の指示
概要ページは、ハーネスが「前の作業を要約して、コンテキストウィンドウを管理する」と書いています。Responses APIで長い会話を続ける時は、context_managementにcompact_thresholdを設定して圧縮を有効にしますが、Agents APIではこの部分をOpenAIが受け持ちます。作業中のセッションに追加のメッセージを送るとそのターンの向きを変えられ、待機中なら新しいターンが始まります。モデル・推論の強さ（reasoning.effort）・service_tierは既存のセッションでも次のターンから変えられますが、ツール・指示・multi_agentは変えられず、新しいセッションが必要です。
料金と対象プラン｜2026年9月30日時点で書かれている範囲
Agents APIの概要ページの料金の節は、「モデルの利用は選んだモデルのAPI料金、OpenAIのツールは標準料金、OpenAI側のサンドボックスは標準のコンテナ料金」と書いています。Agents APIそのものの利用料は書かれていません。Computer use単体の単価も、2026年9月30日に確認した料金ページには行がなく、公式に確認できていません。
モデルとコンテナの単価
ドキュメントの例で使うgpt-6-astraの単価は次のとおりです（料金ページ・100万トークンあたり・1ドル150円で換算）。
| gpt-6-astra | 入力 | キャッシュ済みの入力 | キャッシュの書き込み | 出力 |
|---|---|---|---|---|
| 短い文脈（Short context） | 10ドル（1,500円） | 1ドル（150円） | 12.50ドル（1,875円） | 50ドル（7,500円） |
| 長い文脈（Long context） | 20ドル（3,000円） | 2ドル（300円） | 25ドル（3,750円） | 75ドル（11,250円） |
ほかのモデルをAgents APIで指定できるかは、2026年9月30日時点で公式に確認できていません。APIリファレンスのmodelは文字列の指定で、使えるモデルの一覧はありません。GPT-6.1 Solのモデルページも、対応するエンドポイントの一覧にAgents API（v1/agents）を載せていません。
| コンテナのメモリ | 単価（コンテナ1つ・20分あたり） | Agents APIのサイズ（当社の当てはめ） |
|---|---|---|
| 1 GB | 0.03ドル（4.5円） | small（1 vCPU・1 GB） |
| 4 GB | 0.12ドル（18円） | medium（2 vCPU・4 GB・既定） |
| 16 GB | 0.48ドル（72円） | large（4 vCPU・16 GB） |
料金ページのこの行は「Hosted ShellとCode Interpreter」のコンテナの単価で、対象のコンテナのセッションは分単位の課金、1セッションの最低は5分と書かれています。Agents APIのサイズと並べたのは、メモリの量で当てはめた当社の読み方で、ドキュメントに対応表はありません。OpenAIのツールでは、たとえばWeb検索が1,000回あたり10ドル（1,500円）で、検索で取り込んだ内容のトークン代（モデルの単価）が別に加わります。
費用に入るもの
Observability and usageのページによると、エージェントは1つのタスクでモデルを何度も呼び、そのたびに次の分が費用になります。
- 入力トークン：エージェントの指示、ツールの定義、会話の履歴、利用者の入力、ファイルや画像、ツールの結果
- キャッシュ済みの入力トークン：一致した先頭部分の再利用で、キャッシュ済みの単価で課金
- 出力トークン：生成した文章、ツール呼び出しの引数、推論。推論のトークンは出力として課金
このほか、サブエージェントのモデル呼び出し、再試行、ツール、サンドボックスの計算資源、外部サービスの料金を足して考えます。セッションとターンのusageは分かる範囲の記録で、nullのこともあり、あとで変わることもあるため、請求の確定値ではありません。キャッシュの書き込みの数も出ないので、キャッシュの書き込みに単価があるモデルでは、正確な請求額をusageだけでは出せません。
試算例（実測値ではありません）
前提を置いた計算の例です。gpt-6-astraで入力100万トークン・出力10万トークン（キャッシュなし・短い文脈の単価）なら、入力10ドルと出力5ドルで計15ドル（2,250円）です。サンドボックスは、4 GBのコンテナの単価をmediumに当てはめると、20分で0.12ドル（18円）です。ブラウザのタスクで実際に何トークン使うかは、タスクと画面の数で変わります。自社の代表的なタスクでusageを記録してから見積もってください。
対象プラン
APIでは、Agents APIのパブリックベータとして使えます（リクエストにOpenAI-Beta: agents=v1のヘッダーが付きます）。DevDay 2026 Recapは提供範囲を「APIと、Pro 500・EnterpriseのCodexとChatGPT Work」と書いていますが、CodexとChatGPT Workの中でどの機能として使えるのかは、2026年9月30日時点で公式に確認できていません。Pro 500は、同じDevDayで発表されたProの新しい階層で、利用枠はChatGPT Plusの25倍と説明されています。なお、ChatGPTデスクトップアプリのComputer Use（手元のmacOS・Windowsを操作する機能）は、対応地域でChatGPT WorkとCodexから使える別の機能です。
自前のループ・Agents SDKから移すかの判断
ここからは当社の見方です。ドキュメントの比較表と制限をもとに、今の実装をAgents APIに置き換えるかどうかを観点ごとに分けました。
| 観点 | Agents APIに任せやすい | 今の実装を残したい |
|---|---|---|
| 作業の長さと状態 | 長く続くタスクで、セッションと回復を任せたい | 1回の呼び出しで終わる短い処理で、状態は自社で持ちたい |
| ブラウザの確認 | 読むだけの作業やサイトのテストで、OpenAI側のブラウザで足りる | 購入や削除の前に確認を必ず挟みたい（自分で動かすブラウザが要る） |
| データの扱い | 米国での保管と、アプリの状態の保持（削除するまで）を受け入れられる | ZDRが必要、または米国以外のデータ保管が必要 |
| サインイン | メールアドレス・パスワード・確認コードで入れるサイト | パスキーやQRコードが必須のサイト |
| ツールの形 | MCPとWeb検索が中心で、関数ツールはメインのエージェントで足りる | サブエージェントにも関数ツールを持たせたい |
| モデル | ドキュメントの例と同じgpt-6-astraで足りる |
ほかのモデルを使いたい（Agents APIでの対応は確認できていない） |
移す時の進め方
- 公開ページを読むだけのブラウザのタスクを1つ選び、今の実装と同じ入力で動かす
- オリジンの承認とサインインの処理を先に作る。ドキュメントの例と同じく、入力がなければ
denyにする network.accessをrestrictedにして、必要なホストだけを許可する- ターンの
usageと、ダッシュボードのログの「Agents」タブの記録で、費用と所要時間を今の実装と比べる - ZDRや米国以外での保管が要る処理は、今の実装に残す
自前のループを残す場合
ブラウザを自分で動かす必要がある時は、Responses APIのComputer useで、環境と操作のループを自社で持ちます。ループの組み方と上限の決め方は、Claudeの例ですがComputer Use本番運用ガイドが参考になります。エージェントの基盤をAPIで借りる形はほかの会社にもあり、AnthropicのClaude Managed Agentsと並べて比べる手もあります。
【要注意】よくある失敗パターン
Computer useを組み込む時に起こりやすい読み違いを5つ挙げます。
失敗1：ネットワークを有効にすれば、どのサイトにも入れると考える
❌ network.accessをenabledにしただけでタスクを送り、承認の処理を書かない
⭕ agent.session.requires_actionを受けて、オリジンの承認に応える処理を先に書く
なぜ重要か：公開サイトも含めて、新しいオリジンごとに承認が要ります。ネットワークの設定は承認の代わりになりません。
失敗2：オリジンを承認すれば、購入や削除の前にも確認が入ると考える
❌ 決済や管理画面のあるサイトを承認し、あとはエージェントに任せる
⭕ 取り返しのつかない操作ができない資源にブラウザを限定するか、確認を必ず挟める自前のブラウザの実行環境を使う
なぜ重要か：ドキュメントは、オリジンの承認は個々の操作の前の確認を強制しないと書いています。関数ツールで確認する方法は、エージェントがその関数を呼ぶことに頼ります。
失敗3：イベントのストリームを閉じればタスクが止まると考える
❌ 画面を閉じる処理で、ストリームの接続だけを切る
⭕ 止める時はagent.session.input.cancelでターンを取り消す
なぜ重要か：ストリームを閉じてもタスクは止まりません。利用者が画面を閉じた後も、ブラウザの操作が続いてしまいます。
失敗4：パスワードを通常のメッセージや関数ツールの結果で渡す
❌ 利用者が入力したパスワードを、エージェントへのメッセージに含める
⭕ browser_authenticationの依頼に、専用のイベント（actionにsubmit）で返す
なぜ重要か：専用のイベントで送った値はモデルの入力に入らず、履歴にも残りません。関数ツールの結果はモデルから見え、履歴に残ります。
失敗5：202が返ったので、サインインできたと判断する
❌ 送信が202で返ったら、サインイン済みとして次の処理に進む
⭕ イベントを追い続け、ターンの完了と、エージェントが報告した結果で確かめる
なぜ重要か：202は受理の意味で、サインインの成功ではありません。サインインの依頼は5分で期限切れになり、入力中にターンが終わることもあります。
よくある質問
OpenAI Agents APIの料金はいくらですか？
Agents APIそのものの利用料は、2026年9月30日時点のドキュメントに書かれていません。かかるのは、選んだモデルのAPI料金、OpenAIのツールの標準料金、OpenAI側のサンドボックスのコンテナ料金です。ドキュメントの例で使うgpt-6-astraは、100万トークンあたり入力10ドル（1,500円）・出力50ドル（7,500円）です。Computer use単体の単価は、料金ページに見当たりません。
APIキーにはどの権限が必要ですか？
セッションの操作にapi.agents.readとapi.agents.write、モデルの推論にapi.responses.writeが要ります。Vaultsを管理するならapi.vaults.readとapi.vaults.writeを足します。自前のサンドボックスでは、環境をつなぐことだけに使える環境キーを別に作り、CODEX_API_KEYとして渡します。
Agents SDKとは何が違いますか？
Agents APIは、OpenAIが動かすCodexのハーネスでエージェントを動かし、セッションの設定・ターン・アイテムを保存します。Agents SDKは、アプリの中でSDKがエージェントのループを回し、デプロイ・保存・承認・実行環境との連携をアプリ側で制御します。OpenAIの比較表では、組み込みの手間はAgents APIが「低い」、Agents SDKが「中くらい」です。
日本国内でのデータ保管やZDRには対応していますか？
対応していません。概要ページは、Agents APIのデータの保管先は現在米国のみで、Zero Data Retention（ZDR）にも対応していないと書いています。自前のサンドボックスを選んでもZDRの対象にはなりません。/v1/agentsは学習に使われず、不正利用の監視のための保持は30日、アプリの状態は削除するまで保持されます。
ChatGPTのデスクトップアプリのComputer Useと同じものですか？
別の機能です。デスクトップアプリのComputer Useは、ChatGPT WorkとCodexから、手元のmacOSやWindowsの画面を操作します。Agents APIのComputer useは、OpenAI側の環境で動くブラウザを、APIで作ったエージェントに操作させます。
GPT-6.1 Solなど、ほかのモデルでも使えますか？
2026年9月30日時点で公式に確認できていません。今回読んだAgents APIのドキュメントの例はすべてgpt-6-astraで、APIリファレンスのmodelは文字列の指定で、使えるモデルの一覧はありません。GPT-6.1 Solのモデルページの対応エンドポイントにも、Agents APIは載っていません。
自社のブラウザや社内のネットワークで動かせますか？
コマンドの実行やファイルの操作は、自前のサンドボックス（self_hosted）で自社の環境に置けます。環境の中でcodex exec-serverを動かし、外向きの接続でAPIにつなぎます。一方、Computer useのブラウザは、ドキュメントの手順ではOpenAI側の環境（openai_hosted）で動きます。ブラウザを自社で動かしたい場合は、Responses APIのComputer useを使う形になります。
まとめ
OpenAI Agents APIは、CodexのハーネスをOpenAIが動かすAPIで、2026年9月29日（米国時間）のDevDay 2026でComputer useに対応しました。ブラウザはOpenAI側の環境で動き、設定はcomputer_use・openai_hosted・desktopの3か所です。サイトごとの承認とサインインはアプリが受け持ち、データの保管先は米国のみで、ZDRには対応していません。料金は、モデル・ツール・コンテナの料金の合計として見積もります。
最初にやることは3つです。Quickstartの例で自社のAPIキーの権限を確かめる、公開ページを読むだけのブラウザのタスクで承認の処理を作る、ZDRや米国以外での保管が要る処理を洗い出して今の実装に残す範囲を決める。Agents SDKとの違いをもう一度確かめたい場合は、OpenAI Agents SDK完全ガイドを参考にしてください。社内でエージェントの使い方や決まりを設計する段階で相談先が必要な場合は、UravationでもAIエージェントの導入を支援しています。
運営元 Uravation よりAIエージェントを構想から本番運用まで進める順番と、体制・KPIの決め方をまとめた資料を無料で公開しています。 AIエージェント導入ロードマップを受け取る（無料）
参考・出典
- Agents API（概要） — OpenAI APIドキュメント（参照日: 2026-09-30）
- Computer use（Agents API） — OpenAI APIドキュメント（参照日: 2026-09-30）
- Agents API quickstart — OpenAI APIドキュメント（参照日: 2026-09-30）
- Architecture — OpenAI APIドキュメント（参照日: 2026-09-30）
- Configuring Agents — OpenAI APIドキュメント（参照日: 2026-09-30）
- Run and continue sessions — OpenAI APIドキュメント（参照日: 2026-09-30）
- OpenAI-hosted sandboxes — OpenAI APIドキュメント（参照日: 2026-09-30）
- Self-hosted sandboxes — OpenAI APIドキュメント（参照日: 2026-09-30）
- Sandbox security — OpenAI APIドキュメント（参照日: 2026-09-30）
- Multi-agent — OpenAI APIドキュメント（参照日: 2026-09-30）
- Observability and usage — OpenAI APIドキュメント（参照日: 2026-09-30）
- Errors and recovery — OpenAI APIドキュメント（参照日: 2026-09-30）
- Agents（実行方法の比較） — OpenAI APIドキュメント（参照日: 2026-09-30）
- Create session（APIリファレンス） — OpenAI APIリファレンス（参照日: 2026-09-30）
- Tool search — OpenAI APIドキュメント（参照日: 2026-09-30）
- Programmatic Tool Calling — OpenAI APIドキュメント（参照日: 2026-09-30）
- Compaction — OpenAI APIドキュメント（参照日: 2026-09-30）
- Computer use（Responses API） — OpenAI APIドキュメント（参照日: 2026-09-30）
- Data controls in the OpenAI platform — OpenAI APIドキュメント（参照日: 2026-09-30）
- Pricing — OpenAI APIドキュメント（参照日: 2026-09-30）
- GPT-6.1 Sol（モデルページ） — OpenAI APIドキュメント（参照日: 2026-09-30）
- Changelog — OpenAI APIの変更履歴（2026年9月10日・9月29日の項目・参照日: 2026-09-30）
- Computer Use（ChatGPT・Codex） — ChatGPTとCodexのドキュメント（参照日: 2026-09-30）
- DevDay 2026 Recap — OpenAI（2026年9月29日・参照日: 2026-09-30）
