2026.10.22 ChatGPT

OpenAI Agents APIとは？セッション実装・料金とSDKとの違い【2026年10月】

OpenAI Agents APIは、Codexを動かしているエージェントの実行基盤（ハーネス）を、APIから呼び出して自社のアプリケーションに組み込める仕組みです。2026年9月10日にパブリックベータとして公開されました。この記事では、セッションとイベントで動く仕組み、Agents SDK・Responses APIとの違い、Pythonでセッションを作り自社の関数を呼ばせる実装、実行環境の選び方と料金の試算を、2026年10月22日時点の公式ドキュメントに沿って整理します。最後に、データの所在地とゼロデータ保持（ZDR）の制約から、日本企業で採用してよい業務と見送る業務の線を引きます。

まとめ：OpenAI Agents APIの要点と採用を決める3つの判断材料

Agents APIは「エージェントのループをOpenAI側に任せ、道具と実行環境だけを自社で用意する」ためのAPIです。会話の状態、コンテキストの圧縮、サブエージェントの調整、切断からの復旧をOpenAIが受け持つため、何時間も続く調査やコード実行を少ないコードで回せます。API自体の追加料金はなく、払うのはモデルのトークンとツール、ホスト型サンドボックスのコンテナ料金です。

採否は3点で決まります。1つ目は、処理が長時間・多段階か。1往復で終わるならResponses APIで足ります。2つ目は、エージェントのループを自社で持つ必要があるか。承認フローや保存先を細かく握りたいならAgents SDKが向きます。3つ目は、データを米国で保持してよいか。2026年10月時点でデータ所在地は米国のみ、ZDRにも対応していないため、規制の厳しいデータを扱う業務は対象から外します。

OpenAI Agents APIの仕組み：Codexハーネスをセッションで呼ぶAPI

公式のAgents APIの概要ページは、このAPIを「OpenAIが管理するAPIを通じてCodexハーネスを使えるようにするもの」と定義しています。

2026年9月10日公開のパブリックベータで使える機能と提供条件

OpenAIの発表記事によると、Agents APIは2026年9月10日にすべての開発者向けにパブリックベータとして公開されました。正式提供（GA）の時期は示されていません。主な機能は、長いセッションでの自動的なコンテキスト圧縮、必要なツール定義だけを読み込むツール検索、コードでツール呼び出しを並列・連鎖させるプログラム的ツール呼び出し、サブエージェントへの並列委任、MCPサーバーと自社関数の接続です。

実行環境は、OpenAIのホスト型サンドボックス、自社のインフラ、パートナーのサンドボックスから選びます。パートナーにはBlaxel・Cloudflare・Daytona・DigitalOcean・E2B・Modal・Oracle・Runloop・Vercelの9社が挙がっています。ベータの間はリクエストにOpenAI-Beta: agents=v1ヘッダが必要で、公式SDKでは自動で付く仕様です。Pythonのopenaiライブラリは、CHANGELOGで3.13.0（2026年9月10日）にAgents APIの対応が入り、3.22.0（同9月29日）でブラウザを操作するcomputer useツールが追加されました。

agent・environment・session・eventsの4要素で読む処理の流れ

概要ページは4つの要素で説明しています。agentはモデル・指示・ツール・MCPサーバーの組み合わせ、environmentはファイルを読みコマンドを実行する場所、sessionはタスクに取り組み続ける永続的なエージェントのインスタンス、events と items はセッションへの入力とそこで生まれた出力です。利用者の入力が1回の作業単位（ターン）を始めます。

押さえどころは、ハーネスと実行環境が分かれている点です。アーキテクチャの解説では、モデルとツールのループを回してセッションを保つのはOpenAI側のハーネスで、コマンドを実行するのは別の環境だと説明しています。ハーネスはGitHubで公開されているCodexと同じオープンソースのコードが土台です。ローカルで動かすCodexの使い方はCodexの使い方・料金・モデルの解説にまとめています。

Agents SDK・Responses APIとの違いを状態管理と実行場所で比べる表

OpenAIのエージェント実行方式の比較をもとに、3つの違いを整理します。

観点	Agents API	Agents SDK	Responses API
ループを回す場所	OpenAIのハーネス	自社アプリ	自社アプリ
状態の保存	セッションとアイテム	自社ストレージ	手動の履歴管理
実行環境	ホスト型・自社・なし	自社とパートナー	自社
組み込みの手間	少ない	中くらい	多い

Agents SDKは、デプロイ・保存・承認・実行基盤の制御をアプリ側に残すライブラリです。Responses APIはモデルを直接呼ぶ低レベルのAPIで、ループもツール実行もすべて自分で書きます。Responses APIの位置づけはResponses APIとChat Completions APIの違いと移行判断で解説しています。

Pythonでセッションを作りイベントで完了を判定する実装手順

ここからは公式クイックスタートの流れに沿って、最小の構成を組み立てます。

APIキーの権限3種と openai 3.13.0以降を用意する初期設定

Agents APIのベータFAQによると、Platformのプロジェクトでアプリケーション用のAPIキーを作り、セッション操作用のapi.agents.readとapi.agents.write、モデル呼び出し用のapi.responses.writeを付けます。キーはエージェントのサンドボックスの外に置くことが条件です。

pip install --upgrade "openai>=3.13.0"
export OPENAI_API_KEY="(Platformで発行したアプリケーション用キー)"

サンドボックス内のコマンドからキーが読めると、エージェントが誤ってファイルやログに書き出すおそれがあります。キーはアプリケーションサーバーの環境変数か秘密情報の管理基盤に置き、環境へ渡すファイルとは分けてください。

curlでセッションを作成しストリームで結果を受け取るリクエスト例

セッションの作成はPOST /v1/agents/sessionsの1回です。モデル・指示・実行環境・最初の依頼をまとめて送ります。

curl --no-buffer --fail-with-body https://api.openai.com/v1/agents/sessions \
  -H "OpenAI-Beta: agents=v1" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "agent": {
      "model": "gpt-6-astra",
      "instructions": "Write clean code, run it, and report the actual output."
    },
    "environment": { "type": "openai_hosted" },
    "input": "Create tree.py that prints the files in the current directory. Run it.",
    "stream": true
  }'

"stream": trueで進捗のイベントが順に返ります。応答に含まれるセッションIDは保存しておきます。続きの依頼、切断後の状態確認、Platformの管理画面のLogsでの調査に同じIDを使うためです。指示とツール設定の合計は4MiB（4,194,304バイト）未満に収める必要があります。

ターンの完了・失敗・キャンセルを判定するPythonのイベント処理

判定でつまずきやすいのは、セッションがアイドルになっただけでは成功と言えない点です。イベントとアイテムの解説のコードを短くすると次の形になります。

from openai import OpenAI

client = OpenAI()

def stream_session(session_id, handle_event):
    with client.beta.agents.sessions.events.stream(session_id) as events:
        for event in events:
            handle_event(event)
            match event.type:
                case "agent.session.idle":
                    continue
                case "agent.session.failed" | "agent.session.environment.failed":
                    raise RuntimeError(event.type)
                case "agent.session.turn.failed" | "agent.session.turn.cancelled":
                    if event.turn.subagent_id is None:
                        raise RuntimeError(event.type)
                case "agent.session.turn.completed":
                    if event.turn.subagent_id is None:
                        return
    raise RuntimeError("ターン終了前にストリームが切れた。保存済みの状態を取得する")

subagent_idがNoneのイベントだけが親エージェントのターンです。サブエージェントの完了で処理を打ち切ると、親の作業が途中のまま結果を読むことになります。ターンが完了してもツール単位では失敗している場合があるため、最後は出力の中身も確かめます。

自社の業務システムを関数ツールでつなぐ required_actions の処理

社内のデータベースや基幹システムを触らせる場合は、関数ツールを定義し、エージェントの呼び出しを自社のコードで実行して結果を返します。

関数ツールの定義とrequired_actionsで届く呼び出し内容の読み方

手順は関数ツールの公式ガイドのとおりです。agent.toolsに名前・説明・引数のJSON Schemaを書きます。

{
  "type": "function",
  "name": "get_customer",
  "description": "Look up a customer by ID.",
  "parameters": {
    "type": "object",
    "properties": { "customer_id": { "type": "string" } },
    "required": ["customer_id"],
    "additionalProperties": false
  }
}

エージェントが結果を必要とすると、セッションはagent.session.requires_actionを送り、required_actionsにtype・turn_id・call_id・name・argumentsが入ります。履歴に関数呼び出しが残っていても結果待ちとは限らないので、返すべき呼び出しは必ずrequired_actionsで判断します。セッションに実行環境をつないでも、関数はその環境では動きません。実行するのはアプリケーションサーバーかワーカーです。

tool_resultで結果を返し切断時の二重実行を防ぐPython実装

保留中の呼び出しを処理してagent.session.input.tool_resultで返すコードです。セッションを取得して読む形にしておくと、ストリームが切れた後の再開にも同じ関数を使えます。

import json

HANDLERS = {"get_customer": lambda a: {"customer_id": a["customer_id"], "plan": "pro"}}

def answer_required_actions(session_id):
    session = client.beta.agents.sessions.retrieve(session_id)
    for action in session.required_actions or []:
        action = action.to_dict()
        if action["type"] != "function_call":
            continue
        result = {"type": "agent.session.input.tool_result",
                  "turn_id": action["turn_id"], "call_id": action["call_id"]}
        try:
            output = HANDLERS[action["name"]](action["arguments"])
            result.update(success=True, output=json.dumps(output, ensure_ascii=False))
        except Exception as e:
            result.update(success=False, error=str(e))
        client.beta.agents.sessions.events.create(session_id, events=[result])

注文の登録のように副作用のある関数は、session・turn・callの3つのIDをキーに実行結果を保存してから返します。切断後は保存済みの結果を同じturn_idとcall_idで送り直し、関数を再実行しません。利用者の追加メッセージを送るときも、セッションの解説にあるとおり送信ごとにIdempotency-Keyを発行して保存します。結果が4MiBを超えると拒否されるため、検索結果の全件ではなく必要な列に絞って返してください。

実行環境とサブエージェント設定による運用コストと責任の分担基準

同じタスクでも、どこでコマンドを動かすかで料金と運用の負担が変わります。

none・openai_hosted・self_hostedを処理内容で選ぶ判断基準

エージェント設定の解説とアーキテクチャのページから、3つの選び方をまとめます。

environment.type	向く処理	管理の責任
none	質問応答・外部ツールの呼び出しだけ	環境の管理なし
openai_hosted	スクリプト実行・ファイル編集・成果物の作成	OpenAIが作成と管理
self_hosted	社内ネットワークや独自ソフトが必要	起動・再接続・停止・保存は自社

noneではシェル・パッチ適用・ワークスペースのファイルが使えません。社内のファイルサーバーや閉域のデータベースに触れる処理はself_hostedになりますが、ハーネスとモデルの推論はOpenAI側に残ります。隔離環境の考え方はサンドボックスの役割と限界の解説も参考になります。

multi_agentの同時実行数6と関数ツール非対応という制約の扱い

マルチエージェントの解説によると、multi_agent.enabledをtrueにすると親エージェントが作業を分けてサブエージェントへ任せます。同時に動くサブエージェントの数はmax_concurrent_subagentsで決め、既定値は6です（親は数えません）。

設計で効く制約は2つあります。サブエージェントは関数ツールを使えないため、自社システムへの書き込みは親エージェントに集めます。また、親と子は同じファイルシステムを共有し、子ごとに別の環境は作られません。同じファイルを複数の子に編集させる分け方は衝突を生むので、出力先のディレクトリを子ごとに分ける指示を書いておきます。

追加料金なしでも利用時にかかるトークン単価とコンテナ料金の試算

APIの料金ページでは、100万トークンあたりの単価が次のとおりです（2026年10月22日時点）。

項目	単価
gpt-6-astra 入力／キャッシュ入力／出力	10ドル／1ドル／50ドル
gpt-6.1-sol 入力／キャッシュ入力／出力	2ドル／0.10ドル／10ドル
コンテナ 4GB	20分あたり0.12ドル（分単位・最低5分）

入力20万トークン・出力2万トークンを使い、4GBのサンドボックスを30分動かすセッションを単価から計算すると、gpt-6.1-solで約0.78ドル、gpt-6-astraで約3.18ドルです。キャッシュが効けば入力の費用は下がり、長いコンテキストでは単価が上がる料金体系です。セッションごとのトークン量はPlatformのLogsで確認できるので、まず10件ほど流して1件あたりの実額をつかんでから上限を決めます。上位モデルの料金差はGPT-6 Astraの料金とデータ境界の解説で比べています。

日本企業がOpenAI Agents APIを採用する条件と見送る業務の線引き

機能が揃っていても、データの扱いで対象外になる業務があります。ベータの制約を先に当てはめます。

米国のみのデータ所在地とZDR非対応で対象外になる業務データ

ベータFAQには、データ所在地は米国のみで、ZDRには対応しないと書かれています。self_hostedを選んでもZDRの対象にはなりません。セッションの状態は続きの作業のために保持され、不要になったセッションと成果物は削除できます。

この条件では、国内保管を契約で約束している顧客データ、医療・金融の規制データ、ZDRを前提に社内承認を得た案件は載せられません。個人情報を含む業務は、委託先の所在国を定めた社内規程に照らしてから判断します。条件を満たせない場合は、データを匿名化した前処理だけをAgents APIに任せる分け方が現実的です。

長時間の調査やコード実行を非同期で任せる処理は採用してよい条件

採用してよいのは、数十分から数時間かかる調査・集計・コード生成を、待たずに投げて後から結果を受け取る処理です。障害時のログ調査をサブエージェントに分けて並べる、リポジトリの修正案を作って検証まで回す、といった用途が当たります。発表記事でも、エラー率の調査を配備・エラー・依存関係の3つに分けて任せる例が示されています。

この型なら、コンテキストの圧縮や切断からの復旧を自作せずに済み、開発の工数はツールの定義と結果の受け取りに絞れます。

1往復で終わる処理や承認を握る業務はResponses APIか自社実装を選ぶ

見送るのは2つの場面です。1つは、問い合わせの分類や要約のように1回の呼び出しで終わる処理で、セッションの保持とサンドボックスの費用が無駄になります。もう1つは、送金や受発注のように人の承認を挟む操作が多い業務で、承認の記録と差し戻しを自社のワークフローで握るほうが監査に耐えます。「ベータのまま基幹業務の書き込みを任せる」のは避けるべき失敗パターンです。

どの処理をAgents APIに任せ、どこを自社のコードに残すかの切り分けは、業務フローとデータの区分を並べると決めやすくなります。社内で判断がつかない場合は、要件の段階でAIエージェント開発の相談窓口に持ち込むと、実行環境の選定から関数ツールの設計まで一緒に詰められます。

OpenAI Agents APIのよくある質問：ベータ版の制約と移行の疑問

検討の段階でよく出る疑問に、2026年10月22日時点の公式情報で答えます。

Agents APIとAgents SDKはどちらを選べばよいですか？

エージェントのループと状態の保存をOpenAIに任せてよいならAgents API、承認フローや保存先、実行基盤を自社で握りたいならAgents SDKです。Agents APIは組み込みの手間が少ない代わりに、データ所在地が米国のみでZDRに対応しません。データの条件が合わない場合は、SDKで自社のサーバーにループを置く構成を選びます。

Agents APIを使うのに追加の料金はかかりますか？

Agents APIそのものの料金はありません。モデルのトークン料金、Web検索などのツール料金、ホスト型サンドボックスのコンテナ料金がかかります。コンテナは4GBで20分あたり0.12ドルで、分単位・最低5分で課金されます。自社のサーバーで環境を動かす場合、その計算資源の費用は自社の負担です。

ChatGPTのworkspace agentsのAPIとは同じものですか？

別の製品です。Agents APIはPlatformのAPIキーで自社アプリからエージェントを動かす開発者向けのAPIで、workspace agentsはChatGPT BusinessやEnterpriseで業務担当者が作る共有エージェントです。workspace agentsにも起動用のAPIがありますが、対象も認証方式も違います。詳しくはChatGPT workspace agentsのAPI起動と権限設計で解説しています。

Agent BuilderやAssistants APIからAgents APIへ移行できますか？

自動の移行手段は用意されていません。Assistants APIは2026年8月に終了しており、Agent Builderは2026年11月30日に終了予定です。Agent Builderの公式の移行先の1つは、ワークフローをAgents SDKのコードとして書き出す方法です。Agents APIは移行先の候補の1つで、ワークフローを関数ツールと指示に組み直して載せ替えます。長時間の処理やサンドボックスでのコード実行が要るワークフローほど、Agents APIへ移す利点が大きくなります。