Open Responsesとは何か？

Open Responses は、OpenAPI 3.1 ドキュメントとして公開されたオープン仕様で、プロバイダーをまたいで言語モデルを呼び出す際の単一のリクエストおよびレスポンスの形を記述します。これは OpenAI Responses API をベースにしています。つまり model、input、そして任意で tools を POST /v1/responses に送信すると、プロバイダー固有の形式ではなく、型付きのアイテムとセマンティックなストリーミングイベントが返ってきます。OpenAI は 2026-01-15 に Open Responses を立ち上げ、Apache 2.0 の下でライセンスされ、2026-10-22 に OpenAI はそれを Agentic AI Foundation (AAIF) に寄贈しました。AAIF は MCP もホストしている Linux Foundation の組織です。

最後のステップがニュースです。この仕様は今や技術憲章、運営委員会、そして中立なホームを持っています。この記事では、それが何を定義しているのか、誰が実装しているのか、AAIF への移管で何が変わるのか、そして依存しているエンドポイントが準拠しているかどうかを確認する方法を扱います。基盤となる API に馴染みがない方は、OpenAI Responses API の使い方から始めてください。

Open Responses が定義するもの

仕様は問題を率直に説明しています。プロバイダーは同じ構成要素（メッセージ、ツール呼び出し、ストリーミング、マルチモーダル入力）に収束してきましたが、それぞれが異なる方法でエンコードしています。Open Responses は 1 つのエンコーディングを選び、それを書き留めます。

現在の OpenAPI ドキュメントはバージョン 2026-04-24 で、小さなサーフェスをカバーしています。

操作	内容
`POST /responses` (`createResponse`)	レスポンスを作成する（ストリーミングかどうかを問わない）
`/responses` 上の WebSocket	永続ソケット経由で同じレスポンスモデルを提供（2026-04-24 に追加）
`POST /responses/compact` (`compactResponse`)	長い会話向けに圧縮された入力ウィンドウを返す

リクエストボディは、OpenAI の API を使ったことがある方なら期待するであろうフィールドを受け付けます。model、input、instructions、tools、tool_choice、stream、store、previous_response_id、reasoning、text、truncation、temperature、top_p、max_output_tokens、prompt_cache_key、その他いくつかです。レスポンスオブジェクト（ResponseResource）は id、status、output、usage、error、および送信した設定のエコーを保持します。このドキュメントは合計 108 個のスキーマを定義しており、そのほとんどがアイテム型とストリーミングイベント型です。

設計を支える 3 つの考え方があります。

アイテムがコンテキストの単位である

モデルが読み取るもの、生成するものはすべてアイテムです。message、function_call、function_call_output、reasoning アイテムです。アイテムは双方向なので、あるターンの出力をそのまま次のターンの入力として戻すことができます。各アイテム型はその type フィールドで判別され、それぞれ独自のスキーマを持ちます。

アイテムはステートマシンでもあります。それぞれが in_progress から completed または incomplete（トークン予算が尽きた場合）へと移行し、incomplete のアイテムは最後に出力されるものでなければならず、レスポンス全体が incomplete としてマークされます。ステータスは、サーバーがそのアイテムを保存したかどうかについては何も述べていません。永続化は別の関心事です。

ストリーミングは生の差分ではなくセマンティックイベントである

stream: true を設定すると、サーバーは Content-Type: text/event-stream と定義されたイベントシーケンスで応答しなければなりません。出力アイテムは response.output_item.added で始まります。その中のテキストは response.content_part.added として到着し、続いて繰り返される response.output_text.delta イベント、次に response.output_text.done と response.content_part.done が続きます。アイテムは response.output_item.done で閉じられます。ストリームは終端イベントで終わらなければなりません。response.completed、response.failed、または response.incomplete です。末尾の [DONE] は任意であり、クライアントはそれなしで終わるストリームも処理しなければなりません。

Open Responses のストリーミングイベント順序の図：output_item.added、content_part.added、繰り返される output_text.delta、output_text.done、content_part.done、output_item.done、その後に終端の completed、failed、または incomplete イベント

これはクライアントコードにとって最も重要です。2 つのプロバイダーが同じイベントを同じ順序で発行するなら、1 つの SSE パーサーが両方で機能します。SSE テストガイドでは、これらのストリームをイベントごとに検査する方法を示しています。

名前空間付き拡張を伴う安定したコア

プロバイダーは独自のアイテム型、ツール、ストリーミングイベントを追加できますが、それらにプロバイダースラッグを接頭辞として付ける必要があります。仕様自体の例は openai:web_search_call です。接頭辞付きの型を認識しないクライアントは、壊れることなくそれをスキップできます。これにより、ウェブ検索やファイル検索のようなホスト型ツールがプロバイダー機能のままである一方で、仕様がポータブルであり続けるのです。

契約の残りの部分

仕様の上に構築する前に知っておく価値のあるルールがいくつかあります。

2 種類のツール。 外部でホストされるツール（関数、MCP サーバー）はプロバイダーの外で実行されます。関数の場合、モデルは function_call を発行し、あなたがそれを実行し、一致する call_id を持つ function_call_output を返送します。内部でホストされるツール（例えば OpenAI のファイル検索）は、制御を返すことなくプロバイダー内で実行されます。
tool_choice と allowed_tools。 tool_choice は auto（デフォルト）、required、none、または 1 つの関数を指定するオブジェクトを取ります。allowed_tools は、すべてのツールを表示したまま、モデルが呼び出せるツールを制限するので、tools 配列を編集してキャッシュされたプロンプトを無効にしてしまうことがありません。サーバーはそれを厳格な制限として強制しなければなりません。
previous_response_id。 サーバーは新しいリクエストを previous_response.input + previous_response.output + input の順で扱わなければならないので、トランスクリプトを再送する必要がありません。
Reasoning アイテムは、生の content、不透明な encrypted_content ブロブ、ユーザーに安全な summary、またはその任意の組み合わせを保持できます。
エラーは type（server_error、invalid_request、not_found、model_error、too_many_requests）に加えて code、param、message を保持します。ストリーム途中では、エラーの後に response.failed が続きます。

2026-04-24 の改訂（変更履歴）では WebSocket トランスポートが追加されました。各ターンは response.create メッセージで始まり、1 つの接続は一度に 1 つのレスポンスを処理し、接続は 60 分に制限され（エラーコード websocket_connection_limit_reached）、store: false の継続は接続ローカルのメモリに保持され、その状態が失われると previous_response_not_found で失敗します。同じ改訂では /responses/compact、アシスタントメッセージの任意の phase フィールド（commentary または final_answer）が追加され、logprobs が任意になりました。

Open Responses と Chat Completions の比較

Chat Completions は依然として最も広く模倣されている LLM インターフェースです。違いは形にあります。Chat Completions はメッセージを保持する choices を返し、ツール呼び出しはその中に押し込まれていますが、Responses モデルは型付きアイテムのフラットなリストを返します。推論ステップ、3 つのツール呼び出し、最終メッセージは、それぞれ独自のステータスを持つ別個の順序付けられたオブジェクトになり、エージェントループにより適しています。

並列図：Chat Completions は content と 3 つの tool_calls を choices[0].message の中に入れ子にするが、Open Responses は reasoning、3 つの function_call アイテム、メッセージからなるフラットな output リストを返し、それぞれにステータスがある

私たちは 3 つの支配的な形式を実際のリクエストとともに並べて比較しました。Chat Completions vs Anthropic Messages vs Responses API をご覧ください。OpenAI 自身のサーフェス間で選ぶ場合は、Agents API vs Responses API vs Agents SDK の分解が Responses の位置づけをカバーしています。

誰が実装しているか

サポーターリストには AWS Bedrock、Databricks、Hugging Face、LM Studio、Nvidia、Ollama、OpenRouter、Red Hat、Vercel、vLLM が OpenAI と並んで含まれています。Anthropic と Google は名前を挙げられたサポーターには含まれていません。どちらも依然として独自のネイティブ形式を提供しています。

「サポート」は幅広い範囲をカバーするので、使用するランタイムの詳細を確認してください。

Ollama は v0.13.3 で POST /v1/responses を追加しました。その互換性ドキュメントには「非ステートフルなフレーバーのみがサポートされています」と書かれています。ストリーミング、関数ツール、推論サマリーは機能しますが、previous_response_id、conversation、truncation は機能しません。履歴は自分で再送します。
LM Studio はバージョン 0.3.39 で http://localhost:1234/v1/responses エンドポイントを互換にしました。previous_response_id、ビジョンモデル用のリモート画像 URL、logprobs を含みます。セットアップについては LM Studio ガイドをご覧ください。

規模感をつかむために、API Evangelist は 9 月 13 日にベースラインを取得しました。OpenAI 互換を主張し、読み取り可能な OpenAPI ドキュメントを公開している 120 のプロバイダーのうち、26 が POST /responses を宣言しており、POST /chat/completions を宣言している 105 と対照的です。ベースラインの狙いは、中立なガバナンスがその数を動かすかどうかを測定することです。

Agentic AI Foundation への移管で変わるもの

AAIF は 2026-10-22、サンノゼで開催された AGNTCon + MCPCon North America で、他の 3 つの新プロジェクト、Agent Skills（Anthropic から）、OpenEnv（Hugging Face から）、OpenSandbox（Alibaba から）とともに Open Responses を発表しました。これにより AAIF は最初の年にホストするプロジェクトが 10 になり、MCP、Agent2Agent プロトコル、AGENTS.md、goose、agentgateway、Agent Router に並びます。それらがどう組み合わさるかを整理しているなら、私たちの MCP vs A2A 解説が良い出発点です。

変わるもの：

ガバナンス。 このプロジェクトは現在「Open Responses a Series of LF Projects, LLC」であり、2026-10-21 に採択された技術憲章を持ちます。当初はプロジェクトのメンテナーである Technical Steering Committee が技術的決定を所有し、参加は憲章に従う者なら誰でも可能です。
他のベンダーにとっての信頼性。 1 社が所有する仕様は製品です。財団の下にある仕様は、競合他社がライバルに従っているように見えずに採用するのが容易です。

変わらないもの：

OpenAI 自身の API。 api.openai.com 上の Responses API は独自の機能とリリーススケジュールを維持します。Open Responses はポータブルなコアを記述しており、OpenAI 固有のツールは openai: 接頭辞の背後に留まります。
ワイヤーフォーマット。 移管に伴う新しい仕様バージョンはありません。最新リリースは依然として 2026-04-24 であり、日付付きリリースは不変です。
準拠性。 サポーターリストに載っているからといって、あるエンドポイントがテストに合格するわけではありません。まだ合否インデックスを公開している人はいないので、依存しているエンドポイントは自分で確認してください。

受け入れテストでエンドポイントを確認する

このプロジェクトは独自の受け入れテストを提供しています。コンプライアンスページは、任意のベース URL、モデル、キーに対してブラウザで 10 のテストを実行します。基本的なテキスト応答、ストリーミング、システムプロンプト、ツール呼び出し、画像入力、マルチターン履歴、アシスタントの phase ラベル、コンパクションエンドポイント、そして model を欠いた compact リクエストに対するネガティブテストです。さらに 7 つの WebSocket テスト（順次ターン、store: false の継続、再接続回復、失敗した継続後のキャッシュ削除）は CLI からのみ実行されます。

git clone https://github.com/openresponses/openresponses
cd openresponses && bun install
bun run test:compliance --base-url http://localhost:11434/v1 --api-key ollama

各 HTTP リクエストと各 WebSocket ターンには 30 秒の期限があり、タイムアウトはそのテストのみを失敗させます。Ollama のような非ステートフルなランタイムは、設計上、継続テストに失敗すると予想されます。

コーディングエージェントに Apidog CLI でテストさせる

受け入れテストは、サーバーが今日仕様に従っているかどうかを教えてくれます。しかし、デプロイしたり、Ollama をアップグレードしたり、プロバイダーを切り替えたりするたびに、アプリが呼び出すエンドポイントを監視するわけではありません。そのためには、仕様を Apidog プロジェクトにインポートし、コーディングエージェントに Apidog CLI を使って回帰テストを書いて実行させましょう。

CLI とエージェントスキルを一度インストールします。

npm install -g apidog-cli@latest
apidog auth login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com   # プロンプトが表示されたらエージェントを選択

次に Claude Code、Codex、または Cursor に 1 つのプロンプトを与えます。

https://www.openresponses.org/openapi/openapi.json をダウンロードして、
Apidog プロジェクト <id> にインポートしてください。ベース URL
http://localhost:11434/v1 で環境 "local-ollama" を作成してください。POST /responses の
テストケースを追加してください：200、ステータス "completed"、type "message" の出力アイテムを
期待するもの；stream: true で response.completed で終わる text/event-stream を期待するもの；
"model" なしで error.type フィールドを持つ 4xx エラーを期待するもの。それらを実行して、
失敗を要約してください。

エージェントはスキーマを読み、何かを書く前にペイロードを検証し、ケースを実行します。

curl -sLO https://www.openresponses.org/openapi/openapi.json
apidog import --project <id> --format openapi --file ./openapi.json
apidog environment create local-ollama --project <id> --base-url http://localhost:11434/v1
apidog cli-schema get test-case-create
apidog cli-schema validate test-case-create --file case.json
apidog test-case create --project <id> --file case.json
apidog run --test-case <caseId> --project <id> -e <envId> -r cli,json

仕様の servers エントリは https://api.openai.com/v1 を指しているので、プロバイダーごとに 1 つの環境を追加し、同じケースをそれぞれに対して実行してください。それがポータビリティの主張をテストしたものです。apidog run ... -r junit の行をパイプラインに入れておけば、フィールドを落とすランタイムアップグレードがビルドを失敗させます（CI/CD ガイド）。Claude Code での Apidog CLI はエージェントのセットアップを詳しくカバーしています。

FAQ

Open Responses は OpenAI Responses API と同じですか？ いいえ。Open Responses はそれから派生した仕様です。OpenAI の Responses API は OpenAI 専用の追加機能を備えた 1 つの実装であり、Ollama、LM Studio、vLLM は他の実装です。

Open Responses は今誰が所有していますか？ 2026-10-22 以降、Linux Foundation の下の Agentic AI Foundation プロジェクトであり、Technical Steering Committee を備えた LF Projects シリーズとして運営されています。Apache 2.0 の下でライセンスされています。

Anthropic は Open Responses をサポートしていますか？ Anthropic は名前を挙げられたサポーターには含まれていません。同じ日に Agent Skills を AAIF に寄贈しましたが、Claude のネイティブインターフェースは依然として Messages API です。

仕様ファイルはどこにありますか？ https://www.openresponses.org/openapi/openapi.json にあり、日付付きリリースは GitHub リポジトリにあります。

次のステップ

製品が最も頻繁に呼び出す 1 つのエンドポイントを選び、それに対してブラウザの受け入れテストを実行し、仕様を Apidog にインポートして、エージェントがデプロイごとにそれらのチェックを実行し続けられるようにしましょう。始めるには Apidog をダウンロードしてください。