AIエージェント基盤は「自作」から「選択」へ、OpenAI Agents APIの仕組み｜2026年9月15日版
OpenAIが2026年9月10日に公開ベータ版として提供を始めた「Agents API」は、AIエージェントの開発で必要になる実行ループ、長時間セッション、コンテキスト管理、ツール連携をマネージドサービスとして提供します。
核心は、モデル性能の更新だけではありません。開発者がエージェント基盤を一から組み立てるのではなく、管理されたハーネスを利用し、実行環境やデータの置き場所を選べるようになったことです。
- Agents APIは全開発者が利用できる公開ベータ版
- OpenAIがエージェントの実行ループとコンテキストを管理
- コードの実行環境はOpenAI管理、外部事業者、自社環境から選択可能
- MCP、独自関数、Web検索、サブエージェントに対応
- API自体の追加料金はなく、モデル、ツール、実行環境の使用料が発生
Agents APIで何が変わったのか
従来のエージェント開発では、モデルをAPIで呼び出すだけでは足りませんでした。モデルの応答を読み取り、必要なツールを実行し、その結果を再びモデルへ渡すループをアプリケーション側で維持する必要があります。
処理が数時間に及ぶ場合は、さらに仕事が増えます。
- 途中経過とセッション状態の保存
- コンテキスト上限に近づいた際の情報整理
- エラーや中断からの復旧
- ファイル、パッケージ、認証情報の管理
- 複数タスクの並列実行と結果の統合
- 各処理を追跡するためのログや監視
Agents APIでは、このうちモデルを動かすためのエージェント・ハーネスをOpenAIが運用します。開発者はタスク、モデル、ツール、実行環境などを指定してセッションを作成し、業務固有のデータや処理に集中できます。
ただし、アプリケーション全体を自動で完成させるサービスではありません。何を許可するか、どのデータへ接続するか、結果を誰が確認するかは、引き続き導入側の設計事項です。
ハーネスと実行環境を分離
今回の設計で重要なのは、エージェントを制御するハーネスと、コードやファイルを扱う実行環境が分けられている点です。
ハーネスはOpenAIが管理
ハーネスは、モデルの呼び出し、ツール選択、コンテキスト維持、サブエージェントの調整を担います。OpenAIはCodexで使われているハーネスを基盤とし、モデルの更新に合わせてバージョン管理された機能を提供すると説明しています。
長いセッションでは、コンテキスト上限へ近づくと過去の情報を自動的に圧縮します。単純に古い会話を削るのではなく、作業継続に必要な情報を残すことが狙いです。
実行場所は用途に合わせて選ぶ
コードを動かし、ファイルを保存するサンドボックスには複数の選択肢があります。
- OpenAI管理環境：導入を早めたい場合に向く
- 外部サンドボックス事業者：CPU、GPU、メモリ、起動時間などを用途に合わせて選べる
- 自社管理環境やVPC：データ配置やネットワーク境界を自社で管理したい場合に向く
OpenAI管理サンドボックスでは、コード実行、ファイル操作、成果物の作成が可能です。必要なファイルやパッケージ、スキル、プラグインも環境へ追加できます。
ここがポイント: OpenAIに任せるのはエージェントの制御部分です。機密データをどこに置き、コードをどこで動かすかは、導入企業が要件に応じて選べます。
長時間処理を支える3つの機能
Agents APIは、短いチャット応答よりも、調査、障害分析、コード改修といった複数工程の仕事を意識した構成です。
1. セッションをまたぐコンテキスト管理
作業が長引けば、会話履歴やツールの実行結果がコンテキストを圧迫します。Agents APIはセッションの状態を維持し、必要に応じて過去の文脈を圧縮します。
開発者にとっては、要約の実行時期や引き継ぐ情報を管理する独自処理を減らせる可能性があります。一方で、自動圧縮後も業務上重要な条件や証拠が保持されるかは、実データを使った評価が欠かせません。
2. 必要なツールだけを読み込む
大量のツール定義を毎回モデルへ渡すと、入力トークンとコストが増えます。Agents APIのツール検索は、必要な定義を必要な時点で読み込む仕組みです。
利用できる接続方式には、次のものがあります。
- MCPサーバー
- アプリケーション独自の関数
- Web検索などの組み込みツール
プログラムによるツール呼び出しでは、複数処理の並列実行や結果の絞り込みも可能です。大量の検索結果をそのまま会話へ戻さず、必要な情報だけをコンテキストへ渡せることが、精度と費用の両面で重要になります。
3. サブエージェントによる並列化
大きな仕事を独立した小さな仕事へ分け、複数のサブエージェントへ委任できます。それぞれが個別のコンテキストを持ち、主エージェントが結果をまとめる構造です。
たとえばシステム障害の調査なら、デプロイ履歴、エラーログ、外部依存サービスを別々に確認できます。ただし、分割数を増やせばモデル呼び出しや実行環境の使用量も増えます。並列化は無料の高速化ではなく、所要時間と費用を交換する設計として扱う必要があります。
日本の開発者と企業が確認すべきこと
導入判断では、「エージェントを作れるか」より「本番環境で制御できるか」が焦点になります。
開発者
既存の自作ループを置き換える場合は、まず小規模な業務で比較するのが現実的です。
- 中断後に正しい状態から再開できるか
- 自動圧縮後も重要な制約が残るか
- ツール検索が適切な機能を選べるか
- サブエージェントの結果に重複や矛盾がないか
- 失敗時のログから原因を追跡できるか
公開ベータ期間中は仕様が変わる可能性もあります。重要な処理では、APIバージョンの固定、再試行条件、停止手段を用意しておくべきです。
企業利用者
顧客情報や社内文書を扱う場合、モデルだけでなく実行環境まで含めたデータフローの確認が必要です。
- 入力、ツールの戻り値、生成ファイルが保存される場所
- 外部MCPサーバーへ送信される情報
- サンドボックスが接続できるネットワーク範囲
- 認証情報の保管方法と権限の有効期間
- 人による承認が必要な操作
- ログの保存期間と監査方法
特に、送信、公開、削除、決済、設定変更などの操作をエージェントへ任せる場合は、実行直前の承認や権限分離が必要です。ハーネスが管理されても、業務上の責任までサービス側へ移るわけではありません。
料金は「API無料」だけで判断しない
OpenAIによると、Agents API自体に追加料金はなく、使用したモデルのトークンやツールに応じて課金されます。OpenAI管理サンドボックスなど、選択した実行環境の費用も別に確認する必要があります。
費用を見積もる際は、少なくとも次の項目を分けます。
- 主エージェントのモデル入力・出力
- サブエージェントが追加で消費するトークン
- Web検索など有料ツールの呼び出し
- サンドボックスの起動時間と計算資源
- 長時間セッションの再試行や失敗コスト
単発のデモでは安く見えても、並列処理や長時間実行を増やすと総額は変わります。従来基盤との比較では、API料金だけでなく、自作オーケストレーターの開発・監視・保守にかかる工数も含める必要があります。
継続ウォッチ
Agents APIは公開ベータ段階です。次に見るべき点は明確です。
- 一般提供までにAPI仕様と互換性保証がどう整備されるか
- 自動コンテキスト圧縮を検証・制御する機能が追加されるか
- セッション、ツール、サブエージェントを追跡する監視機能の詳細
- OpenAI管理環境と自社環境で使える機能に差が出るか
- 長時間処理における障害復旧と費用上限の設定方法
今回の発表で、AIエージェント開発の競争軸はモデル選びだけではなくなりました。ハーネスをどこまでサービス側へ任せ、データと実行権限をどこに残すか。まず確認すべきなのは、その境界を自社の構成図に描けるかどうかです。