OpenAI Agents APIとは？Codexの仕組みをAPIから使う方法・料金・導入前の注意点【2026年9月】

「AIエージェントを作りたいが、長時間の実行管理、ツールの呼び出し、途中失敗からの復旧まで自分で実装するのは重い」。そんな開発者に向け、OpenAIは2026年9月10日、Agents APIをパブリックベータとして発表しました。Codexを支えるエージェント実行の仕組みを、開発者が自分のアプリケーションから利用できるAPIです。

ただし、「APIの利用料が無料」「コードを渡せば安全に完全自動化できる」という話ではありません。APIそのものへの追加料金はない一方でモデルやツール、OpenAIがホストするサンドボックスの使用料がかかります。データの取り扱いにも重要な制約があり、公式ドキュメントではAgents APIのデータレジデンシーは現時点で米国のみ、ゼロデータ保持（ZDR）非対応と明記されています。

本記事では、2026年9月18日に確認した公式発表と技術資料を基に、何が新しくなったのか、導入前の判断材料、最初の検証方法をSE・フリーランスSE向けに整理します。以下に示すコードは公式クイックスタートに基づく例で、筆者自身による動作検証や顧客案件での導入実績を示すものではありません。

Agents APIとは？Codexの何を使えるようにするのか
仕組みを理解する4つの要素
Agents SDKや通常のモデルAPIと何が違う？
最初に試す手順：APIキー、モデル、セッション
料金は無料なのか？モデル・ツール・サンドボックスを分ける
導入前の重要事項：データ保存場所とZDR、認証情報
よくある失敗：イベントを受け取っただけで成功と判断する
SE実務での使いどころと、向いていないケース
まとめ：まずは非機密データで小さく検証する
参考情報

Agents APIとは？Codexの何を使えるようにするのか

Agents APIが公開するのは、単にAIモデルに質問を送る窓口ではありません。OpenAIが管理するCodexハーネスを使い、セッションの状態保持、作業の調整、長い会話の文脈を圧縮する処理、復旧などをまとめて扱える仕組みです。ここでいう「ハーネス」は、モデルの呼び出しだけでなく、道具の利用、作業の継続、複数エージェントへの分担を支える実行基盤を指します。

2026年9月10日の公式発表によると、Agents APIはすべての開発者を対象とするパブリックベータです。OpenAIがハーネスを維持管理し、開発者は使用するモデル、ツール、実行環境を選びます。実行環境はOpenAI管理のサンドボックス、自社インフラ、提携する環境プロバイダーなどから選ぶ構成が説明されています。実際の利用条件や対象モデルはプロジェクトの設定を確認してください。

たとえばアプリケーションから「障害の発生状況を調べる」という作業を渡し、エージェントに許可した監視ツールから情報を得て、調査結果を成果物としてまとめてもらう使い方が考えられます。ただしこれは利用設計の例です。障害原因の正確性を自動保証する機能でも、エージェントが本番の復旧操作を無条件に実行してよいという意味でもありません。

前に公開したGPT-5.5終了に伴うCodexモデル設定の移行記事は、既存のCodex利用者がモデル名を更新する話です。今回のAgents APIは、自分のアプリケーションにエージェントの実行基盤を組み込むための別の発表・別の検索意図を扱います。

仕組みを理解する4つの要素

公式概要では、主要な概念が「エージェント」「環境」「セッション」「イベントとアイテム」に整理されています。用語を把握しておくと、障害時にどこで止まったかを切り分けやすくなります。

要素	役割	実務で確認する点
エージェント	モデル・指示・ツールなどの設定	何を実行させ、何を禁止するか
環境	ファイルやコマンドを扱う実行場所	ネットワーク、権限、機密データの範囲
セッション	会話や進捗を保持する作業単位	再開方法、削除条件、状態管理
イベントとアイテム	入力や実行途中・結果の記録	成功判定、失敗時の監査情報

セッション内の1回の作業サイクルが「ターン」です。公式資料によれば、ターンは非同期で実行でき、ストリーミングまたはWebhookで進捗を受け取れます。同じセッションを再利用して作業を続けられるため、アプリケーション側で毎回ゼロから文脈を組み立てる必要を減らせます。一方、セッションの状態があることは業務の処理が成功したこととは別です。

長い作業では、古い文脈を要約・圧縮するコンパクションや、独立した作業をサブエージェントに任せる仕組みも案内されています。並列化できるからといって、互いに同じファイルを書き換えたり、異なる判断で本番操作を実行したりしてよいわけではありません。責任範囲と承認ルートはアプリケーション側で設計する必要があります。

Agents SDKや通常のモデルAPIと何が違う？

初学者が迷いやすいのは「Agents API」と「Agents SDK」の名前です。通常のモデルAPIでは、アプリケーションがリクエストを出し、必要に応じてツール呼び出し結果を返す処理を組み立てます。Agents SDKはエージェントの構成やワークフローを自分のランタイム側で実装する選択肢です。これに対しAgents APIでは、OpenAIが管理するハーネスがエージェントのループやセッションを受け持ちます。

どちらかが一律に上位という関係ではありません。既存システムの一部として単発の応答を使うだけなら、マネージドな長期セッションの仕組みを追加する理由がない場合もあります。独自の実行制御や保存条件が厳しいシステムでは、自社で管理する構成の方が要件を検討しやすい可能性があります。逆に、長時間作業やサブエージェントの調整に多くの実装工数を使っているなら、Agents APIの検証対象になります。

選定では「モデルの回答品質」だけでなく、実行基盤を誰が管理するか、障害時に何を再開するか、ツールの認証情報をどこで持つかを比較してください。名称が似ているだけで、ChatGPTの利用契約からAgents APIの利用権限や料金が自動的に決まるとは考えない方が確実です。

最初に試す手順：APIキー、モデル、セッション

公式クイックスタートでは、OpenAI Platformのプロジェクトでアプリケーション用APIキーを作り、セッション操作用のapi.agents.read、api.agents.writeと、モデル推論用のapi.responses.writeを付与するよう案内しています。APIキーはエージェントがコードを実行するサンドボックスの外部で管理してください。開発者が使う端末に設定するときも、ソース管理へ誤ってコミットしないよう注意が必要です。

Pythonの公式SDKを使う場合は、ドキュメントにpip install --upgrade openaiという導入方法が示されています。リクエストではbeta.agents名前空間を使用し、cURLで直接呼び出す際はOpenAI-Beta: agents=v1ヘッダーが必要です。SDKではこのヘッダーが自動的に付けられると説明されています。

最小の確認は、公式クイックスタートにある「tree.pyを作り、ディレクトリツリーを表示させる」ような、結果を簡単に確認できる仕事から始めることです。モデルの指定例として公式資料にはgpt-6-astraが掲載されています。これは公式サンプルに登場する識別子であり、すべての利用者・契約で無条件に使用できると保証するものではありません。

from openai import OpenAI

with OpenAI() as client:
    with client.beta.agents.sessions.create(
        agent={"model": "gpt-6-astra"},
        environment={"type": "openai_hosted"},
        input="Create tree.py and run it to print a directory tree.",
        stream=True,
    ) as events:
        for event in events:
            print(event.to_json(indent=None), flush=True)

上記は公式の呼び出し形式に基づいて短くした学習用のコード例であり、本記事では実行していません。まずダミーのファイルだけを扱う環境で、イベントの内容、生成ファイル、実行結果を確認します。いきなり実プロジェクトや顧客のリポジトリを渡す必要はありません。サンプルが失敗した場合は、API権限、モデル利用可否、実行環境、SDKの対応状況をそれぞれ確認します。

料金は無料なのか？モデル・ツール・サンドボックスを分ける

OpenAIの発表はAgents API自体に追加料金はないと説明しています。しかし、これは「実行しても請求されない」という意味ではありません。公式ドキュメントでは、選んだモデルのAPI料金、使用するツールの標準料金、OpenAIホスト型サンドボックスの標準コンテナ料金がそれぞれ関係すると記載されています。

たとえば長い調査を何度も継続する構成では、モデルによる推論、検索などのツール利用、実行環境の使用時間が費用に影響する可能性があります。実際の合計金額はモデル、ツール、環境、実行回数によって変わります。2026年9月18日に確認した上記の発表だけから、案件ごとの確定料金や定額上限を算出することはできません。

フリーランスSEが見積もるなら、まず単一タスクを複数回試し、モデル・ツール・コンテナの使用状況を区別して記録します。単なる成功率だけでなく、「成果物を1件採用できるまでの費用」と「レビューや失敗時のやり直し時間」を合わせて比較すると、運用費に近い数字になります。顧客向けに見積額を提示する場合、試験運用中の実測値と将来の予算仮定を混ぜないことも大切です。

導入前の重要事項：データ保存場所とZDR、認証情報

業務導入の判断では、機能より先にデータ条件を確認したいところです。OpenAIのAgents API概要は、現時点で対応するデータレジデンシーは米国のみで、ゼロデータ保持（ZDR）には非対応と明記しています。サンドボックスを自社ホストに変えたとしても、Agents API自体がZDR対象になるわけではない、とも説明されています。

したがって、顧客との契約や社内規程でデータの保管地域・保持条件が指定されているなら、環境の種類を選ぶだけで適合すると判断できません。扱うデータの種類、送信先、保存条件を事前に確認し、条件を満たせない場合は機密データを投入せず、別構成を検討します。保存条件の適合について本記事だけで法的・契約的判断を行うものではありません。

セキュリティ文書は、エージェントが生成したコードは実行環境から見えるファイル、資格情報、ネットワークにアクセスできると警告しています。アプリケーションのAPIキーや外部サービスの長期的なシークレットをサンドボックス内へ置かず、ワークロードを分離し、必要な通信先だけを許可する設計が基本です。外部サービスへ接続するなら認証情報ブローカーなどを検討し、エージェントが任意の秘密情報を読み取れる構成を避けます。

業務システムのテストでは、まず匿名化したダミーデータと読み取り専用のツールだけを使い、外部送信、本番変更、削除などの高影響操作は追加しないことを勧めます。これは製品が最初からその制約を保証するという意味ではなく、アプリケーション側で設けるべき運用上の対策です。

よくある失敗：イベントを受け取っただけで成功と判断する

エージェントの実行は非同期で、APIがセッションを作成できたことと仕事が完了したことは別です。公式クイックスタートはagent.session.turn.completedを確認し、実際の結果も検証するよう案内しています。agent.session.idleは追加の入力を受け付ける状態を意味しますが、直前のターンが成功した証拠にはなりません。完了したターン内に、失敗したツール呼び出しが含まれる場合もあります。

Webhookを利用する設計では、受信した通知の署名を検証したうえでセッションやターンの詳細を再取得し、最終状態を確認することが必要です。署名なしのPOSTを処理したり、通知の本文だけで「顧客への処理完了」と更新したりするのは避けてください。Webhookの処理が遅い場合、公式資料は本番環境でのキュー利用にも言及しています。

通信が切れた場合も同様です。作業がすでに進んでいる可能性があるため、同じ依頼を無条件に再送すると二重実行の原因になります。ストリーム切断後はセッションと保存済みのアイテムを取得し、既存のターンが動いているか、成果物が残っているか確認してから再試行を判断します。送信・課金・本番更新など副作用があるツールを追加するなら、アプリケーション側で重複実行防止や承認を設計してください。

OpenAIホスト型サンドボックスのドキュメントでは、作業終了後にセッション削除とクリーンアップを依頼するよう案内されています。ストリームを閉じる操作はタスクのキャンセルを意味しません。費用だけでなく、不要な実行環境を残さない運用にも注意が必要です。

SE実務での使いどころと、向いていないケース

想定される活用の一つは、匿名化した障害ログや公開可能なテストデータの調査です。ログの収集を読み取り専用ツールに限定し、調査、原因候補の整理、検証手順の提案をエージェントに任せ、実際の復旧判断は人間が行う構成が考えられます。別の例では、テスト用リポジトリで不具合を再現し、成果物として差分や報告書を生成する方法があります。どちらも提案であって、本記事での実証済み事例ではありません。

Agents APIを検討しやすいのは、長時間の作業を継続させたい、複数ツールの利用やサブエージェントの調整に開発工数を使っている、実行状況と結果をアプリから管理したい場合です。一方、単発のテキスト生成しか必要ないアプリ、データレジデンシーやZDR要件が今回の提供条件と合わない案件、実行基盤を自社で完全に統制する必要がある案件では、導入の前提から再確認が必要です。

新しいAPIを採用すること自体を目的にせず、どの開発負担を減らしたいかを明確にしましょう。公開ベータの段階では仕様や提供条件が変わる可能性もあります。顧客への提案では、未検証の省力化率や費用削減率を確定値として示さず、小規模なPoC（概念実証）の条件、期間、評価項目を取り決めて進めるのが現実的です。

まとめ：まずは非機密データで小さく検証する

Agents APIは、CodexのハーネスをAPI経由で使えるようにする2026年9月10日発表の新しい選択肢です。長時間のセッション、ツール利用、進捗確認をまとめて扱える点は、複雑なエージェントの基盤を自作している開発者にとって検討材料になります。一方、料金は利用したモデル・ツール・サンドボックスに応じて発生し、米国のみのデータレジデンシー、ZDR非対応という条件も無視できません。

最初の一歩としては、公式クイックスタートのような小さなファイル作成タスクを、非機密の使い捨て環境で動かす構成を検討します。次にターンの成功判定、エラー時の再取得、権限の分離、成果物の確認、使用料金の記録を順に確かめます。技術的に実行できることと、顧客のデータを使って業務に導入してよいことを分けて判断してください。