OpenAI が Agents API をパブリックベータで公開 — セッション管理・文脈圧縮・復旧をプラットフォーム側が持つ

要約

OpenAI は 2026-09-10、Agents API をパブリックベータとして公開しました。

このAPIの中核は、エージェントを動かすうえで必ず必要になるが、本質的な価値を生まない部分を OpenAI 側が引き受けるという点にあります。公式が挙げているのは3つです。セッションのオーケストレーション、コンテキストの圧縮（context compaction）、中断からの復旧（recovery）。

エージェントを自前で組んだことがあれば、この3つが何を指すかはすぐ分かるはずです。会話が長引けばコンテキスト長の上限に当たるので、どこかで履歴を要約して畳む仕組みが要ります。処理が数分から数十分に及ぶので、途中で接続が切れたときに再開できる必要があります。複数のツール呼び出しを順番に回すための進行管理も要ります。どれもモデルの賢さとは無関係で、しかし作らないと動かない部分です。

提供される機能は次のとおりです。永続セッション（durable sessions）でターンをまたいで作業を継続でき、進捗をストリーミングで受け取れます。開発者側の自前ツールを接続でき、MCP サーバーとも接続できます。

実行環境の選択肢が用意されている点も重要です。 OpenAI がホストする環境で動かすほか、自社インフラや対応ベンダーのサンドボックスへ接続して動かせます。同日、Cloudflare が Containers を実行環境として使うリファレンス実装を公開しており、この「外部サンドボックス接続」が机上の選択肢ではないことが同時に示されました。

なお、Agents API は Codex へのアクセスを提供する経路としても位置づけられています。Cloudflare 側の告知では「OpenAI が管理する API を通じてアプリケーションに Codex へのアクセスを与える」と説明されています。

何が変わったか

• Agents API がパブリックベータで公開された
• セッションのオーケストレーション、コンテキスト圧縮、復旧を OpenAI 側が担当する
• 永続セッションでターンをまたいだ作業継続ができる
• 進捗をストリーミングで受け取れる
• 自前ツールと MCP サーバーを接続できる
• 実行環境を OpenAI ホスト / 自社インフラ / 対応ベンダーのサンドボックスから選べる
• 同日、Cloudflare Containers が外部実行環境のリファレンス実装として公開された

業務インパクト（一般企業向け）

この更新が変えるのは、エージェント開発における「作らなくてよい部分」の線です。

これまで社内でエージェントを試そうとすると、最初の数週間はほぼ基盤づくりに消えていました。会話履歴をどう畳むか、途中で落ちたらどう再開するか、ツール呼び出しの順序をどう管理するか。業務知識とは何の関係もない配管工事に人手が取られ、そこで力尽きて PoC が止まるというのは、よくある失敗の形でした。

その部分が API 側に移るということは、自前実装の価値が「ツールと業務知識」の側に寄るということです。自社のどの業務システムをツールとして露出させるか、どういう手順で何を判断させるか、どこで人が承認するか。ここは外部のプラットフォームには作れません。評価すべきは、配管を作れる人ではなく、業務を分解できる人になります。

一方で、新しく重い選択が1つ増えました。実行環境をどこに置くかです。

OpenAI ホストの環境で動かすのが一番簡単ですが、エージェントが触るデータとネットワークの範囲を自社で決めたい場合は、自社インフラか対応ベンダーのサンドボックスを選ぶことになります。社内システムに接続する構成、あるいは顧客データを扱う構成では、この選択がそのまま情報統制の設計になります。「まず動かす」段階と「本番に載せる」段階で、置き場所が変わりうることを最初から前提にしておくのが安全です。

ベータであることの扱いも決めておく必要があります。 パブリックベータは仕様が変わりうる状態です。業務の基幹部分に据えるのは早く、「壊れても業務が止まらない範囲」から入れるのが妥当です。具体的には、社内向けの調査・下書き生成・定型レポートの作成といった、結果を人が必ず見る工程からになります。

副業・個人活用視点

個人開発の観点では、これは「一人で作れる範囲」を広げる更新です。

エージェントの配管部分は、一人で作ろうとすると現実的に重い部分でした。コンテキスト圧縮を自前で実装して、要約の質が落ちて挙動が不安定になる、という経験をした人は少なくないはずです。そこが外部化されると、個人が仕上げられるのは「特定業務に特化したツール群」という、本来価値のある部分になります。

受託の観点では、提案の中身が変わります。「エージェント基盤を構築します」という提案は、今後説得力を失っていきます。 基盤はプラットフォームが持つからです。代わりに強くなるのは、**「御社のこの業務を、こう分解して、この順序でエージェントに渡します」**という、業務側に踏み込んだ提案です。見積もりの内訳も、基盤構築の工数から、業務ヒアリングとツール実装の工数へ移ります。

MCP サーバーを接続できる点は、既に MCP でツールを作っている人にとって直接の追い風です。 一度作ったツールが、Claude 側でも OpenAI 側でも使えるという状態に近づきます。特定ベンダーに寄せない形でツール資産を積めるので、いま MCP でツールを書いておく価値は上がりました。

ただし、実務で請ける前に確認すべき点があります。ベータ段階の API を納品物に含めるかどうかです。仕様変更で動かなくなったときの責任範囲を、契約時に明示しておかないと後で揉めます。「ベータであること」「変更時の改修は別途」を見積書に一行入れておくのが無難です。