OPENAI SEARCH INSIGHT

2026.09.13 / OpenAI最新情報

OpenAI、Agents APIを公開ベータで提供開始

この記事で分かること: OpenAIが公開ベータとして発表したAgents APIの機能、公式に確認できる提供内容、日本の開発・運用チームが評価すべき設計上の論点を知りたい。

OpenAIは2026年9月10日、エージェント構築向けのAgents APIを公開ベータとしてリリースした。管理されたCodexハーネスを利用しつつ、セッションのオーケストレーション、コンテキスト圧縮、復旧をOpenAI側に任せられることが、公式発表で示された中核である。

開発者は、複数ターンにまたがって作業を継続する耐久性のあるセッション、進行状況のストリーミング、自前ツールやMCPサーバーとの接続を利用できる。実行環境はOpenAIホストのサンドボックスに加え、自社インフラまたは対応プロバイダーのサンドボックスを接続する選択肢も公式に案内されている。

OpenAIがAgents APIを公開ベータで発表

今回の発表の対象は、OpenAIのFeatureとして公開されたAgents APIである。公式公開日は2026年9月10日で、提供段階はpublic beta、すなわち公開ベータと明記されている。一般提供への移行時期、料金、利用可能な国・契約・組織の範囲について、確認済みの公式本文には記載がない。

Agents APIは、単に会話の応答を得るためのAPIというより、タスクを継続して進めるエージェントの実行基盤を意図した発表と読める。ただし、公式本文が具体的に列挙した機能は、管理されたCodexハーネス、セッション管理、コンテキスト圧縮、復旧、ツール・MCP接続、サンドボックス実行である。

公式発表で確認できる主要機能

第一に、開発者は管理されたCodexハーネスを使ってエージェントを構築できる。ハーネスの内部実装、利用できるモデルの詳細、性能指標、モデル選択の仕組みは、今回確認した公式本文では説明されていない。実装判断では、発表文にない仕様を前提に設計しないことが重要になる。

第二に、OpenAIはセッションのオーケストレーション、コンテキスト圧縮、リカバリーを扱うとしている。長時間または複数ターンの処理では、会話履歴や作業状態の扱いが運用負荷になりやすい。Agents APIはこのうち基盤側で扱う領域を明示した点に特徴がある。

第三に、耐久性のあるセッションでターンをまたいだ作業を継続できる。利用者からの追加指示、途中で止まった作業の再開、複数の工程に分かれる処理などで、状態をどの単位で保持・引き継ぐかはアプリケーション設計の論点となる。公式発表は継続実行を可能にする方向性を示している。

第四に、進行状況をストリーミングできる。完了結果だけを返す非同期処理とは異なり、アプリケーション側は処理の途中経過をユーザー画面、監視基盤、業務ワークフローに反映する設計を検討できる。ただし、イベントの種類、順序保証、再接続時の仕様は確認済み本文には含まれない。

ツール連携と実行環境の選択肢

Agents APIでは、自前のツールおよびMCPサーバーを接続できる。MCPは外部の機能や情報源をエージェントに接続する際の重要な接点になり得るため、既存の社内API、検索、文書管理、チケット管理、業務システムをどう公開するかが実装上の焦点になる。

一方で、ツールを接続できることは、無制限の権限付与を意味しない。公式発表はツールの認可設計、監査ログ、データ保持、ネットワーク到達性、秘密情報の受け渡し方を説明していない。日本企業の導入チームは、これらを自社のセキュリティ要件に照らして別途定義する必要がある。

実行先については、OpenAIホストのサンドボックスを使う方法と、自社インフラまたは対応プロバイダーからサンドボックスを接続する方法が案内された。処理対象データの所在、ネットワーク分離、既存の実行基盤、監査要件に応じ、どの実行環境を選ぶかを比較できる構成である。

ただし、「対応プロバイダー」がどこまでを指すか、接続要件や責任分界、各環境での機能差があるかどうかは、今回の確認済み本文だけでは分からない。調達や本番導入を進める際は、公開ベータである点も含め、利用条件と技術仕様を個別に確認する段取りが必要になる。

日本の開発チームが見直すべき設計

まず評価したいのは、現在アプリケーション側で実装している状態管理の範囲である。会話履歴の保存、長期タスクの再開、失敗時の再試行、コンテキスト量の制御を独自に抱えている場合、Agents APIが扱う領域との境界を整理するとよい。移行の可否より先に、責務の重複を可視化したい。

次に、耐久性のあるセッションを業務上の案件、ユーザー、承認フローのどれに対応付けるかを決める必要がある。セッションを長く保持するほど便利になる一方、権限変更、担当交代、誤操作の取り消し、機微情報の扱いといった業務要件も複雑になる。アプリケーション固有の状態は明確に分離する設計が望ましい。

ストリーミングを採用するなら、利用者に何を途中表示するかも検討対象となる。処理中であること、ツール実行の承認待ち、失敗と再試行、最終完了を区別できれば、業務利用時の不透明さを抑えやすい。もっとも、どの進捗情報がAPIから得られるかは、公式発表文だけでは確定できない。

ツールとMCPサーバーについては、読み取り専用から始め、更新・送信・削除など副作用のある操作を分離する方法が考えられる。これは公式仕様の説明ではなく、編集部が推奨する一般的な実務上の評価観点である。重要操作には人の確認、呼び出し記録、対象範囲の制限を組み合わせるべきだ。

導入前に確認したい運用・統制項目

公開ベータのAPIを評価する際は、機能の有無だけでなく、障害時にどこまで復旧を任せ、どこから自社が制御するかを明文化したい。OpenAIはリカバリーを扱うとしているが、復旧の条件、保証水準、データ整合性、利用側が行うべき対応の詳細は確認済み本文にない。

検証環境では、同じタスクを複数ターンへ分割した場合の継続性、途中での追加指示、外部ツール失敗時の挙動、ストリーミング表示の中断時対応を確認する価値がある。これはAgents APIの公式な性能保証を示すものではなく、導入判断のために自社ワークロードで確かめるべき観点である。

特に社内データを扱うケースでは、サンドボックス選択とMCP接続を別々に審査しない方がよい。実行環境、ツール権限、接続先、ログ、データ分類を一つの経路として把握することで、エージェントが実際にアクセスできる範囲を評価しやすくなる。

Agent Memories編集部の考察

編集部は今回の発表を、エージェント開発で繰り返し生じる「状態を持つ実行」をAPI基盤へ寄せる動きとして注目する。従来、モデル呼び出しそのものよりも、履歴圧縮、再開、失敗処理、ツール実行のつなぎ込みがプロダクト実装を重くしがちだったためである。

ただし、管理機能が増えるほど、開発チームは自前で見えていた内部状態を抽象化された形で扱うことになる。したがって、採用基準は開発速度だけでは足りない。セッションの観測可能性、運用時の調査容易性、ツール権限の最小化、障害時の代替運用を、早い段階で評価項目に入れるべきだ。

日本の実務では、部門ごとに異なる業務システムや承認手順との接続が導入の難所になりやすい。Agents APIを使う場合も、最初から広い業務権限を与えるのではなく、検索、要約、下書き作成など影響範囲を限定した用途で、セッション継続とツール連携の価値を測る進め方が現実的だろう。

よくある質問

Agents APIは正式版として提供されたのか

いいえ。OpenAIの確認済み公式発表では、Agents APIはpublic beta（公開ベータ）としてリリースされた。正式提供への移行予定や提供条件の詳細は、今回の本文では明らかにされていない。

Agents APIで何をOpenAI側に任せられるのか

公式発表では、セッションのオーケストレーション、コンテキスト圧縮、リカバリーをOpenAIが扱うとしている。また、管理されたCodexハーネスを使ったエージェント構築が案内されている。

自社のツールやMCPサーバーは接続できるのか

できる。公式本文は、自前のツールとMCPサーバーを接続できると明記している。ただし、認証方式、権限管理、接続可能な構成、監査機能の詳細は、確認済みの発表文には記載されていない。

実行環境はOpenAIのサンドボックスに限られるのか

限られない。OpenAIホストのサンドボックスで実行できるほか、自社インフラまたは対応プロバイダーからサンドボックスを接続できると案内されている。どの環境が利用可能かという詳細条件は別途確認が必要である。

まとめ

OpenAIのAgents APIは、管理されたCodexハーネス、セッション継続、コンテキスト圧縮、リカバリー、進捗ストリーミング、ツール・MCP接続、サンドボックス実行を掲げるエージェント開発向けの公開ベータAPIである。発表日は2026年9月10日だ。

導入を検討する開発・AI専門職は、まず自社の状態管理とツール統合の実装を棚卸しし、責務境界を確認したい。その上で、実行環境、データ経路、権限、監査、復旧時の運用を小規模な検証で評価することが、公開ベータ段階の新基盤を実務へつなげる鍵になる。

本カテゴリはMiraigent / Agent Memoriesによる非公式編集記事です。OpenAIとの提携・承認・後援を示すものではありません。