OpenAI Responses API、新機能とツールを大幅追加――開発者体験の向上と高度な制御機能を実現

2025 年、OpenAI は新しい Responses API を発表し、これまでの Chat Completions API と並ぶ形で公式 SDK・ドキュメントの中心に据えた…

2025 年、OpenAI は新しい Responses API を発表し、これまでの Chat Completions API と並ぶ形で公式 SDK・ドキュメントの中心に据えた。「LLM をコールするだけの薄い API」から、「ツール呼び出し・状態管理・マルチモーダル・Reasoning を統合したエージェント実行ランタイム」へ ― API の役割が大きく前進したリリースである。本稿ではエンジニア兼意思決定者の視点から、Responses API の位置付け、新機能、開発者体験の変化、そして実業務システムへの組み込み方を整理する。

Responses API とは何か ― Chat Completions API との違い

Chat Completions API は 2023 年の登場以来、事実上のデファクトとなった LLM 呼び出しインターフェースである。messages を渡し、choices[0].message を受け取る ― このシンプルさがエコシステムの拡大を支えた。一方で、エージェント／ツール連携／マルチターンの状態管理を組み立てる際、「会話履歴の保持」「tool_calls のループ」「ツール結果の差し込み」「JSON 構造化出力の検証」をすべて自前で実装する必要があった。

Responses API はこの「アプリ層に逃げていた共通配線」を API 内部に取り込んだ。input として平文・メッセージ・画像・ファイルを混在させ、tools で組み込みツールやカスタム関数を渡すと、1 回のコールでツール呼び出しのループを完結させ、最終応答（と中間 reasoning trace）を返す。Chat Completions が「LLM のステートレスな関数呼び出し」だとすれば、Responses は「LLM ＋ ツール群を束ねた実行コンテキスト」に近い。

ポイント

Responses API は Chat Completions の置き換えではなく、エージェント／ツール連携前提のアプリ向けに最適化された別系統である。プレーンな単発推論は Chat Completions のままで構わない。一方、Web 検索・ファイル検索・コード実行・画像生成などをまとめて扱うのであれば、Responses 側に寄せたほうが配線が劇的に短くなる。

Chat Completions と Responses の比較表

観点Chat Completions APIResponses API
主用途単発・短いマルチターン推論ツール統合エージェント／長い対話／マルチモーダル
入力形式messages 配列input（テキスト・メッセージ・画像・ファイル混在可）
状態管理クライアント側で履歴を保持previous_response_id でサーバ側に状態
ツール呼び出しtool_calls を受け取り再 POST する手動ループAPI 内部で自動ループ。結果のみ受領
組み込みツールなし（自前実装）Web search / File search / Code interpreter / Image generation 等を tools 指定だけで利用
構造化出力JSON mode / function callingresponse_format に JSON Schema を直接指定
Reasoning モデルo-series でも基本同一インターフェースreasoning trace の出し分け・サマリ取得を API レベルでサポート
ストリーミングtoken delta を SSEイベントタイプ別の SSE（response.output_text.delta 等）

新機能・ツール 7 選

1. 統合的なツール呼び出し（Built-in Tools）

最も大きな変化は、OpenAI が運用するツール群を tools パラメータで指定するだけで利用できる点である。

  • Web search：最新情報を反映した回答を生成。引用元 URL もメタデータに付随。
  • File search：事前にアップロードしたベクター化ファイル群を検索。社内ドキュメント Q&A の典型実装が劇的に短くなる。
  • Code interpreter：サンドボックス上で Python を実行。CSV 集計やグラフ生成、数値計算をモデルに委譲できる。
  • Image generation：応答の途中で画像を生成して返す。
  • Computer use（プレビュー）：仮想ブラウザ／OS 操作。

これまで RAG パイプラインや「関数定義 → ベクター DB 接続 → 検索結果整形 → 再投入」を自前で組んでいた工程の多くが、API 側に吸収される。

2. ストリーミングの強化

従来の Chat Completions のストリーミングは「token の delta を順番に流す」単一チャネルだったが、Responses では イベントタイプが構造化されており、テキスト・ツール開始／終了・reasoning サマリなどを区別して受け取れる。UI 側で「いま検索しています」「コードを実行しています」というステータス表示を出すのが極端に簡単になる。

3. 内蔵メモリ／状態管理

レスポンスは response.id を持ち、次回リクエストで previous_response_id を渡すと、サーバ側で会話履歴と中間 reasoning が引き継がれる。アプリ側で会話履歴を DB に永続化する負担が薄れ、特にプロトタイプ段階の実装コストが下がる。

注意

本番運用では previous_response_id によるサーバ側状態に頼り切らず、会話メタデータ（user_id、session_id、要約、監査ログ）は自社 DB に持つのが推奨される。サーバ側状態は再現性・監査・移行容易性の観点で制約があり、長期保存される保証も用途依存だからである。

4. マルチモーダル入出力

テキスト・画像・ファイル（PDF 等）を input に混ぜて投入できる。出力もテキスト＋画像＋構造化 JSON の同居が自然に扱える。OCR・帳票読み取り・図面 Q&A など、これまで複数 API を組み合わせて作っていたパイプラインを単一の Responses コールに集約できる場面が増える。

5. 構造化出力（JSON Schema）

response_format に JSON Schema を直接渡し、出力をその構造で受け取る。バリデーションが API 側で担保されるため、「JSON で返してくれと書いたのに自然文が混じる」事故が大幅に減る。バックエンドが TypeScript / Pydantic で型を持つ体制と相性が良い。

6. Reasoning モデル統合

o シリーズ（reasoning モデル）が Responses では一級市民として扱われ、reasoning summary をオプションで取得できる。デバッグ・監査・人的レビューの土台として有用で、業務系の判断タスク（与信・採用・医療補助など）で「なぜそう判断したか」のトレースを残しやすい。

7. エージェント実装の標準化

Responses API は OpenAI 公式の Agents SDK の基盤としても位置付けられている。「ツール呼び出しのループ」「ハンドオフ」「ガードレール」「トレース」といったエージェント基本要素が API ＋ SDK の設計レベルで提示されているため、独自フレームワークを内製する前に「公式の言葉で書く」選択肢が現実的になった。

開発者体験はどう変わるか ― Before / After のコード比較

「Web 検索を使って最新情報を踏まえた回答を返す」を例に、両者の実装ボリュームを比べる。

Before：Chat Completions ＋ 自前のツール配線

from openai import OpenAI client = OpenAI()

tools = [{ "type": "function", "function": { "name": "web_search", "parameters": {"type":"object","properties":{"q":{"type":"string"}}}, }, }]

messages = [{"role":"user","content":"今週の生成 AI 主要ニュースを 3 行で"}] r1 = client.chat.completions.create(model="gpt-4.1", messages=messages, tools=tools) call = r1.choices[0].message.tool_calls[0] search_result = my_search_engine(call.function.arguments) messages += [r1.choices[0].message, {"role":"tool","tool_call_id":call.id,"content":search_result}] r2 = client.chat.completions.create(model="gpt-4.1", messages=messages) print(r2.choices[0].message.content)

After：Responses API ＋ 組み込み Web search

from openai import OpenAI client = OpenAI()

resp = client.responses.create( model="gpt-4.1", input="今週の生成 AI 主要ニュースを 3 行で", tools=[{"type": "web_search"}], ) print(resp.output_text)

自前のツール定義、tool_calls のディスパッチ、結果の差し戻しがすべて消える。実装ボリュームは 半分以下に縮む。構造化出力も同様に、JSON Schema を直接渡すだけで型安全に値を取り出せる。

schema = { "type": "object", "properties": { "company": {"type": "string"}, "amount": {"type": "number"}, "due_date": {"type": "string", "format": "date"}, }, "required": ["company", "amount", "due_date"], }

resp = client.responses.create( model="gpt-4.1", input=[{"role":"user","content":"添付の請求書から 3 項目を抽出"}, {"role":"user","content":[{"type":"input_file","file_id":"file_abc"}]}], response_format={"type":"json_schema", "json_schema":{"name":"invoice","schema":schema}}, ) invoice = resp.output_parsed

業務システムへの組み込み事例

カスタマーサポート ― FAQ ＋ 過去チケット検索の一体化

従来は「ベクター DB の構築」「検索 API のラップ」「LLM 呼び出し」「引用整形」を別レイヤーで実装していた。Responses ＋ File search を採用すると、社内ナレッジを OpenAI 側にアップロードするだけで「検索 → 引用付き回答」が完結する。一次対応の自動化と、ヒューマン対応に回す案件の判別を同じ API で扱える。

社内ナレッジ検索 ― 部門横断の意思決定支援

議事録・契約書・仕様書を File search にロードし、Code interpreter と組み合わせると、「過去 3 年分の契約から自動更新条項のあるものを抽出して件数集計」のような検索＋集計の合わせ技が単一フローで成立する。BI ツールほど重くなく、検索だけのシステムよりは賢い、という中間ゾーンを埋める用途で強い。

営業支援 ― 提案準備の所要時間圧縮

Web search で対象企業の最新動向を取得し、社内のサービス資料（File search）と突合し、構造化出力で「提案ストーリーの骨子」を JSON で受け取る。営業担当者は出力を編集するだけで提案資料の初稿が手元に残る。

実装上の注意

組み込みツールは便利な反面、業務データの所在・ログ要件・レイテンシ・モデル更新の影響を必ず事前に評価したい。社内ナレッジを File search にアップロードする前に、データ分類（社外秘 / 個人情報 / 顧客機密）と利用同意の整理を済ませておくこと。Reasoning summary を残す設計と人的レビューを挟むワークフロー設計を組み合わせると、業務適用の信頼性が一段上がる。

移行のステップとコスト試算

既存の Chat Completions 実装を持つチームが Responses へ寄せる際は、いきなり全面置換せず、ユースケース単位で段階的に移すのが現実的である。

  1. 棚卸し：自前ツール、RAG、JSON 強制パース、エージェントループを抱えるユースケースを抽出。
  2. PoC：1 つのユースケースを Responses ＋ 組み込みツールで再実装し、配線量・レイテンシ・出力品質を比較。
  3. 運用設計：会話状態の永続化方針（自社 DB 主管 / previous_response_id 補助）と reasoning summary の取り扱い、監査ログの粒度を決定。
  4. 段階移行：新規ユースケースから Responses を採用し、既存 Chat Completions 実装は安定運用のまま据え置く。
  5. 共通化：複数チームで再利用する「企業向けエージェント基盤」を Responses ＋ Agents SDK で定義し、社内 SDK 化。

コストはツール呼び出し回数・モデル世代・トークン量で変動するため断定は避ける。重要なのは「API 利用料単価」ではなく「ユースケース 1 件あたりの総コスト（人件費 + API + 運用）で比較する」視点である。Responses 移行は API 利用料が同等であっても、自前配線・保守工数・障害対応の削減で総コストが下がる構図になりやすい。

はてなベースの AI システム実装支援

はてなベース株式会社では、OpenAI Responses API ・ Agents SDK を活用した 業務エージェント設計・社内ナレッジ検索基盤・AI ワークフロー自動化の実装を支援している。要件定義から PoC、本番運用、監査・ログ設計、社内展開まで一気通貫で伴走する。

  • Chat Completions 実装の Responses 移行アセスメント
  • File search ／ Code interpreter を組み込んだ社内ナレッジエージェント
  • 営業・カスタマーサポート・経理など部門別の AI 業務自動化
  • Reasoning モデルを用いた判断系タスクのワークフロー設計

「Responses API を業務に組み込みたいが、自社の運用・セキュリティ要件にどう乗せるか」を検討中の方は、ぜひ お問い合わせフォーム よりお気軽にご相談いただきたい。