- 複数のLLMプロバイダー間の相互運用性を目指すオープンソース規格とエコシステムで、OpenAI Responses APIをベースに共通インターフェースを定義
- リクエストとレスポンスを共有スキーマで記述し、最小限の変換作業だけで複数のモデルプロバイダー上で同じ方法で実行可能
- メッセージ、ツール呼び出し、ストリーミング、マルチモーダル入力などの共通コンポーネントを一貫した構造で整理し、エージェントワークフローの実装に適している
- 安定したコアの上でプロバイダーごとの拡張を許容する構造で、拡張性と非断片化を同時に追求
- OpenRouter, Vercel, Hugging Face, LM Studio, Ollama, OpenAI, vLLMなど多数のビルダーが参加するコミュニティを基盤に運営
概要
- Open ResponsesはOpenAI Responses APIをベースにしたオープンソース規格とツールエコシステム
- 言語モデルの呼び出し、ストリーミング結果の処理、エージェント構成作業をプロバイダー非依存で行えるように設計されている
- 共通スキーマとツーリング層を通じて単一インターフェースの体験を提供
なぜOpen Responsesなのか
- LLM APIはメッセージ、ツール呼び出し、ストリーミング、マルチモーダル入力など類似した構成要素を共有しているが、それぞれ異なるエンコード方式を使用している
- Open Responsesはこれを統合する公開された共通規格を提供し、重複実装の負担を減らす
- 一度定義したリクエストと出力構造を複数のプロバイダーで再利用できる
設計原則
- マルチプロバイダーを前提とした設計で、単一スキーマを多様なモデルプロバイダーにマッピング可能
- ストリーミングイベント、ツール呼び出しパターン、モデル出力の最小単位としてitemsの概念を使い、エージェントワークフローに適した構造を提供
- 一般化されていない機能についてはプロバイダーごとの拡張を認めつつ、コアの安定性維持を優先
コミュニティとエコシステム
- マルチベンダー環境を前提としたオープンコミュニティプロジェクトとして運営されている
- OpenRouter, Vercel, Hugging Face, LM Studio, Ollama, OpenAI, vLLMなど多様な組織がロゴ掲載で参加を示している
- 移植性、相互運用性、共通基盤を重視する開発者中心のコミュニティが形成されている
スペックの特徴
- Items中心の共通スキーマによりメッセージ/ツール呼び出し/推論状態を同じ単位で表現し、入力も出力もitemとしてやり取りされる構造
- レスポンスとitemを状態マシンとして定義し、
in_progress→completed/failed/incompleteのようなライフサイクルを明示的に管理
- ストリーミングをテキスト断片ではなくsemantic eventsとして標準化し、
response.output_item.addedで始まりdelta→doneで閉じるパターンを固定
- ツールを**外部実行（開発者/サードパーティ）と内部実行（プロバイダーホスト）**に区別し、
tool_choice/allowed_toolsで呼び出し可能範囲を強制する制御プレーンを提供
previous_response_idにより以前の入力+出力をサーバーがコンテキストとして再構成し、会話の継続/再送の最小化を支援、truncationで「切り詰め許可 vs 超過時は失敗」を選択可能- 標準外の拡張は
provider_slug:プレフィックスで分離し、カスタムhosted toolは対応するitem typeを必ず提供して、ログ取得とラウンドトリップが可能な「レシート」を残す
- エラーは構造化されたerror objectで返し、ストリーミング中のエラーは**
response.failed**イベントで終了
1件のコメント
おお……実装していたものがあったんですが、これで枠組みを作るべきですね