--- title: "OpenAI Agents APIとは？セッション実装・料金とSDKとの違い【2026年10月】" url: "https://www.issoh.co.jp/tech/details/18736/" published: 2026-10-22 updated: 2026-10-22 categories: ["ChatGPT"] publisher: "株式会社一創" --- # 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の概要ページ](https://developers.openai.com/api/docs/guides/agents-api/overview)は、このAPIを「OpenAIが管理するAPIを通じてCodexハーネスを使えるようにするもの」と定義しています。 ### 2026年9月10日公開のパブリックベータで使える機能と提供条件 [OpenAIの発表記事](https://openai.com/index/introducing-the-agents-api/)によると、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](https://github.com/openai/openai-python/blob/main/CHANGELOG.md)で3.13.0（2026年9月10日）にAgents APIの対応が入り、3.22.0（同9月29日）でブラウザを操作する[computer useツール](https://developers.openai.com/api/docs/guides/agents-api/tools/computer-use)が追加されました。 ### agent・environment・session・eventsの4要素で読む処理の流れ 概要ページは4つの要素で説明しています。agentはモデル・指示・ツール・MCPサーバーの組み合わせ、environmentはファイルを読みコマンドを実行する場所、sessionはタスクに取り組み続ける永続的なエージェントのインスタンス、events と items はセッションへの入力とそこで生まれた出力です。利用者の入力が1回の作業単位（ターン）を始めます。 押さえどころは、ハーネスと実行環境が分かれている点です。[アーキテクチャの解説](https://developers.openai.com/api/docs/guides/agents-api/architecture)では、モデルとツールのループを回してセッションを保つのはOpenAI側のハーネスで、コマンドを実行するのは別の環境だと説明しています。ハーネスは[GitHubで公開されているCodex](https://github.com/openai/codex)と同じオープンソースのコードが土台です。ローカルで動かすCodexの使い方は[Codexの使い方・料金・モデルの解説](https://www.issoh.co.jp/tech/details/6968/)にまとめています。 ### Agents SDK・Responses APIとの違いを状態管理と実行場所で比べる表 OpenAIの[エージェント実行方式の比較](https://developers.openai.com/api/docs/guides/agents)をもとに、3つの違いを整理します。 | 観点 | Agents API | Agents SDK | Responses API | | -------- | ----------- | ---------- | ------------- | | ループを回す場所 | OpenAIのハーネス | 自社アプリ | 自社アプリ | | 状態の保存 | セッションとアイテム | 自社ストレージ | 手動の履歴管理 | | 実行環境 | ホスト型・自社・なし | 自社とパートナー | 自社 | | 組み込みの手間 | 少ない | 中くらい | 多い | Agents SDKは、デプロイ・保存・承認・実行基盤の制御をアプリ側に残すライブラリです。Responses APIはモデルを直接呼ぶ低レベルのAPIで、ループもツール実行もすべて自分で書きます。Responses APIの位置づけは[Responses APIとChat Completions APIの違いと移行判断](https://www.issoh.co.jp/tech/details/5961/)で解説しています。 ## Pythonでセッションを作りイベントで完了を判定する実装手順 ここからは[公式クイックスタート](https://developers.openai.com/api/docs/guides/agents-api/quickstart)の流れに沿って、最小の構成を組み立てます。 ### APIキーの権限3種と openai 3.13.0以降を用意する初期設定 [Agents APIのベータFAQ](https://help.openai.com/en/articles/20001551-agents-api-beta-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のイベント処理 判定でつまずきやすいのは、セッションがアイドルになっただけでは成功と言えない点です。[イベントとアイテムの解説](https://developers.openai.com/api/docs/guides/agents-api/sessions/events)のコードを短くすると次の形になります。 ``` 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で届く呼び出し内容の読み方 手順は[関数ツールの公式ガイド](https://developers.openai.com/api/docs/guides/agents-api/tools/functions)のとおりです。`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`で送り直し、関数を再実行しません。利用者の追加メッセージを送るときも、[セッションの解説](https://developers.openai.com/api/docs/guides/agents-api/sessions)にあるとおり送信ごとに`Idempotency-Key`を発行して保存します。結果が4MiBを超えると拒否されるため、検索結果の全件ではなく必要な列に絞って返してください。 ## 実行環境とサブエージェント設定による運用コストと責任の分担基準 同じタスクでも、どこでコマンドを動かすかで料金と運用の負担が変わります。 ### none・openai\_hosted・self\_hostedを処理内容で選ぶ判断基準 [エージェント設定の解説](https://developers.openai.com/api/docs/guides/agents-api/configuration)とアーキテクチャのページから、3つの選び方をまとめます。 | environment.type | 向く処理 | 管理の責任 | | ---------------- | --------------------- | --------------- | | none | 質問応答・外部ツールの呼び出しだけ | 環境の管理なし | | openai\_hosted | スクリプト実行・ファイル編集・成果物の作成 | OpenAIが作成と管理 | | self\_hosted | 社内ネットワークや独自ソフトが必要 | 起動・再接続・停止・保存は自社 | `none`ではシェル・パッチ適用・ワークスペースのファイルが使えません。社内のファイルサーバーや閉域のデータベースに触れる処理は`self_hosted`になりますが、ハーネスとモデルの推論はOpenAI側に残ります。隔離環境の考え方は[サンドボックスの役割と限界の解説](https://www.issoh.co.jp/column/details/13470/)も参考になります。 ### multi\_agentの同時実行数6と関数ツール非対応という制約の扱い [マルチエージェントの解説](https://developers.openai.com/api/docs/guides/agents-api/multi-agent)によると、`multi_agent.enabled`を`true`にすると親エージェントが作業を分けてサブエージェントへ任せます。同時に動くサブエージェントの数は`max_concurrent_subagents`で決め、既定値は6です（親は数えません）。 設計で効く制約は2つあります。サブエージェントは関数ツールを使えないため、自社システムへの書き込みは親エージェントに集めます。また、親と子は同じファイルシステムを共有し、子ごとに別の環境は作られません。同じファイルを複数の子に編集させる分け方は衝突を生むので、出力先のディレクトリを子ごとに分ける指示を書いておきます。 ### 追加料金なしでも利用時にかかるトークン単価とコンテナ料金の試算 [APIの料金ページ](https://developers.openai.com/api/docs/pricing)では、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の料金とデータ境界の解説](https://www.issoh.co.jp/tech/details/17702/)で比べています。 ## 日本企業がOpenAI Agents APIを採用する条件と見送る業務の線引き 機能が揃っていても、データの扱いで対象外になる業務があります。ベータの制約を先に当てはめます。 ### 米国のみのデータ所在地とZDR非対応で対象外になる業務データ ベータFAQには、データ所在地は米国のみで、ZDRには対応しないと書かれています。`self_hosted`を選んでもZDRの対象にはなりません。セッションの状態は続きの作業のために保持され、不要になったセッションと成果物は削除できます。 この条件では、国内保管を契約で約束している顧客データ、医療・金融の規制データ、ZDRを前提に社内承認を得た案件は載せられません。個人情報を含む業務は、委託先の所在国を定めた社内規程に照らしてから判断します。条件を満たせない場合は、データを匿名化した前処理だけをAgents APIに任せる分け方が現実的です。 ### 長時間の調査やコード実行を非同期で任せる処理は採用してよい条件 採用してよいのは、数十分から数時間かかる調査・集計・コード生成を、待たずに投げて後から結果を受け取る処理です。障害時のログ調査をサブエージェントに分けて並べる、リポジトリの修正案を作って検証まで回す、といった用途が当たります。発表記事でも、エラー率の調査を配備・エラー・依存関係の3つに分けて任せる例が示されています。 この型なら、コンテキストの圧縮や切断からの復旧を自作せずに済み、開発の工数はツールの定義と結果の受け取りに絞れます。 ### 1往復で終わる処理や承認を握る業務はResponses APIか自社実装を選ぶ 見送るのは2つの場面です。1つは、問い合わせの分類や要約のように1回の呼び出しで終わる処理で、セッションの保持とサンドボックスの費用が無駄になります。もう1つは、送金や受発注のように人の承認を挟む操作が多い業務で、承認の記録と差し戻しを自社のワークフローで握るほうが監査に耐えます。「ベータのまま基幹業務の書き込みを任せる」のは避けるべき失敗パターンです。 どの処理をAgents APIに任せ、どこを自社のコードに残すかの切り分けは、業務フローとデータの区分を並べると決めやすくなります。社内で判断がつかない場合は、要件の段階で[AIエージェント開発の相談窓口](https://www.issoh.co.jp/service/ai/agent/)に持ち込むと、実行環境の選定から関数ツールの設計まで一緒に詰められます。 ## 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起動と権限設計](https://www.issoh.co.jp/tech/details/18217/)で解説しています。 ### 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へ移す利点が大きくなります。 ### ストリームが切れたらタスクはやり直しになりますか？ やり直しにはなりません。セッションと保存済みの作業はOpenAI側に残る仕組みです。ストリームは取りこぼしたイベントを再送しないため、セッションと保存済みのアイテムを取得して状態を確かめ、結果待ちの関数呼び出しがあれば保存しておいた結果を同じIDで返します。そのうえでイベントの購読をやり直します。 ## 関連記事 - [OpenAI Agent Builderとは？ノードの仕組みと2026年11月30日終了・移行先の選び方](https://www.issoh.co.jp/tech/details/9204/)：終了するノーコードのワークフロー基盤と、その移行先の選び方です。 - [OpenAI Assistants APIとは｜使い方・料金と2026年8月終了・Responses API移行](https://www.issoh.co.jp/tech/details/3461/)：状態を持つ旧APIの終了と、Responses APIへの移行手順です。 - [GPT-6 Astraとは？提供3経路の料金とデータ境界の判断【2026年9月】](https://www.issoh.co.jp/tech/details/17702/)：Agents APIの例で使われる上位モデルの料金とデータの扱いです。 - [MCPとは？AIと外部ツールをつなぐ標準規格とMCPサーバーの仕組み・作り方を解説](https://www.issoh.co.jp/column/details/12966/)：Agents APIにつなぐMCPサーバーの基本です。 - [Computer Useの仕組み｜スクリーンショットと座標で画面を操作する動作原理をClaude・OpenAI・Geminiで比較](https://www.issoh.co.jp/tech/details/11518/)：Agents APIに追加されたcomputer useの動作原理です。 --- 出典: [OpenAI Agents APIとは？セッション実装・料金とSDKとの違い【2026年10月】]()（株式会社一創）