Open Responsesとは何か ― LLMアプリケーションの設計を支える共通API仕様

はじめに

Open Responsesは、
2026年1月15日にリリースされた、LLM（大規模言語モデル）向けの共通API仕様です。

本記事では、Open Responses を 「新しいAPIの一種」としてではなく、
LLMアプリケーションの設計・実装・運用に何をもたらすのか
という観点で整理します。

Open Responses とは

Open Responses は、LLMを利用するための 共通API仕様です。

まず明確にしておくべき点として、Open Responses は次のようなものではありません。

• 実行環境ではありません
• SDKやフレームワークではありません
• 特定のモデルやプロバイダーを提供するものでもありません

Open Responses が定義しているのは、

① LLMにリクエストを送り、
② 処理が進み、
③ 結果が返ってくるまでの「形式」と「ルール」

です。

つまり、アプリケーションとLLMの間にある
インターフェースそのものを標準化する試みです。

なぜ Open Responses が必要なのか

実務でLLMを使っていると、次のような状況に直面します。

• 出力が途中で欲しい
• ツール呼び出しを組み込みたい
• 複数ステップの処理を1つの流れとして扱いたい
• モデルやプロバイダーを切り替えたい

従来のLLM APIは、
「入力 → 最終テキスト出力」という単純な前提で作られており、
これらを実現しようとすると、アプリケーション側が複雑になります。

Open Responses は、
こうした要求を API仕様の段階で受け止める ために設計されています。

出力の考え方がどう変わるか

出力は「結果」ではなく「過程」

Open Responses では、
LLMの出力は単一のテキストではありません。

• モデルの中間的な出力や判断（思考）
• 次に何をするかの判断（ツール使用の判断）
• ツール実行結果
• 最終出力

これらが Item という単位で、
順序を持った流れとして表現されます。

この図が示しているのは、
入力の違いではなく APIが返す情報の粒度の違いです。

Open Responses では、
途中で何が起きたかも含めて API の正式な出力になります。

処理の流れをリアルタイムに扱える

Open Responses は、
すべての処理が終わってから結果を返す前提ではありません。

処理の進行に応じて、

• Item が追加される
• テキストが追加される
• レスポンスが完了する

といった 状態の変化が順次通知されます。

クライアントは、
結果を待つのではなく 状態の変化を受け取り続ける 形で動きます。

これにより、

• ストリーミングUI
• 処理途中の状態可視化
• クライアント側での中断対応

といった実装を、
特別な工夫なしに組み込めます。

ツール連携を前提にした仕様

Open Responses では、
ツール呼び出しは「例外的な機能」ではありません。

• ツールを使う判断
• ツールの実行
• ツールの結果を踏まえた次の処理

が、すべて 同じ出力の流れの中に含まれます。

そのため、検索、計算、外部API呼び出しといった処理を、出力構造に沿って扱う形で組み込めます。

Open Responses が定義している仕様の範囲

Open Responses は、
考え方だけでなく 実装を前提にした定義まで含めて整理されています。

API構造（Reference）

Open Responses では、APIのリクエスト・レスポンスについて、

• どんなフィールドが存在するか
• それぞれが何を意味するか
• どんな構造でやり取りされるか

が 仕様として明確に定義されています。

実務的には、

• リクエスト

  • model
  • input（配列）
  • tools（任意）
  • stream / max_output_tokens など

• レスポンス

  • id
  • status
  • output（配列）

• Item

  • item.id
  • item.type
  • item.status
  • content（配列）

といった構造が前提になります。

正しく実装されているかを確認する仕組み（Compliance）

Open Responses には、
仕様に沿って実装できているかを確認するためのテストも用意されています。

Compliance は、

• ベースURL
• モデル
• APIキー
• 認証方式

を設定し、
仕様で定義されたテストをそのまま実行できる仕組みです。

Open Responses は、

①仕様を定義し
②実装し
③正しいか検証する

ところまでを 一続きで想定した設計になっています。

実装者視点で整理すると

Open Responses を前提にすると、
実装時の設計を次のように整理できます。

クライアント実装

• 出力を Item 単位で扱える
• 状態に応じた分岐を構造として記述できる
• ストリーミング処理を前提に実装できる

サーバー／プロキシ実装

• 複数モデルの差異を吸収しやすい
• 仕様に沿ったレスポンスを返せばよい
• 実装ごとの挙動のズレを抑えられる

将来の変更

モデル変更、プロバイダー切り替え、機能追加が発生しても、アプリケーション側の入出力構造や制御フローを大きく書き換えずに対応できるようになるでしょう。

まとめ

Open Responses は、

• LLMを「テキスト生成エンジン」としてではなく
• 「状態を持って振る舞うコンポーネント」として扱うための
  共通API仕様です。

出力の構造、処理の流れ、ツール連携、検証方法まで含めて定義されているため、
設計・実装・運用を通した実務の中で、採用可否を具体的に判断できます。

少なくとも、今後のLLMアプリケーション設計を考える上で、
無視できない仕様であることは間違いありません。