Conversations API は「前の response をつなぐだけ」の限界を超える state の器

要点

要点まとめ

この guide の主題は『会話を続ける方法』そのものより、session や device や長時間 job をまたいでも使える state をどこに置くかである。
OpenAI は自動 state 管理の入口としてまず Responses API を勧めつつ、より長く共有したい状態には Conversations API という会話オブジェクトの持ち方も示している。
manual state 管理も残るが、`store=false` なら表示テキストだけを残せば済むわけではなく、必要な output items や reasoning item を戻す責任が増える。
日本の開発者にとっての実務価値は、便利な継続機能ではなく durable state、retention、compaction、監査の設計分岐として読める点にある。

読解

何が変わったのか

この guide は、`previous_response_id` で前 response をつなぐだけの継続から、会話状態を durable object として扱う方向を明示しています。Responses API を自動 state 管理の入口として勧めつつ、より長く共有したい状態には Conversations API を組み合わせる。conversation object を作れば messages、tool calls、tool outputs などの items を長く持てる単位ができ、session や device をまたいだ再開と共有を整理しやすくなります。

日本の文脈

なぜ重要か

日本の小規模開発では、会話状態をとりあえず `previous_response_id` の鎖で済ませがちです。しかしその設計は、共有、再開、保持期間、compaction、監査の段階で破綻しやすい。Conversations API は、その破綻点を早めに見える化します。PM や創業者にとっても、state を vendor 側にどこまで預けるかは便利さだけでなく retention と責任分界の判断です。

技術ポイント

技術的ポイント

`previous_response_id` は前 response を参照して文脈を継ぐ簡易な state 方式であり、guide は自動 state 管理の入口として Responses API を勧めている。
`conversation object` は durable identifier を持つ長寿命オブジェクトで、messages、tool calls、tool outputs などの items を格納し、複数 session や job をまたいで共有できる。
manual state 管理では `response.output` 全体を次の `input` に足す必要があり、`store=false` なら encrypted reasoning を含む output items を戻す例が示されている。`output_text` だけでは state が欠けうる。
data retention は response object と conversation items で扱いが違う。guide 上では response object は通常 30 日保存で、conversation に付いた items はその 30 day TTL の対象外と説明されている。
context window は無限ではないため、conversation を持てば終わりではない。いつ要約し、何を落とし、何を durable state として外部 DB に逃がすかという compaction 設計が残る。

用語

英日キーワード

英語	日本語	補足
previous_response_id	前回レスポンス参照ID	直前 response を基点に文脈を継ぐ簡易方式。共有、再開、監査の要件が増えると鎖管理が苦しくなる。
Conversations API	会話状態API	durable な conversation object を管理する API。長時間 job や複数 device をまたぐ state の置き場として使う。
conversation object	会話オブジェクト	messages、tool calls、tool outputs などの items を長く持てる会話単位。shared state の主単位になりうる。
encrypted reasoning	暗号化 reasoning 項目	manual state 管理時に次 request へ戻せる reasoning item。表示テキストだけでは継続に必要な state が欠ける場合がある。
compaction
30 day TTL	30日保持期限	response object の通常保持期間として案内される期限。conversation items とは retention の扱いが同一ではない。

試す

試すなら

今の実装が `previous_response_id` 連鎖だけで済んでいるなら、再開、共有、監査のどれが必要かを先に棚卸しする。
長時間 job や複数 device 継続があるなら、conversation object を state の主単位にするか検討する。
manual state を続けるなら、`output_text` だけでなく `response.output` と reasoning item をどこまで保持するか確認する。
retention 方針を明文化し、conversation に残すもの、自前 DB に写すもの、compaction で落とすものを分ける。

注意

注意点

公式ガイド上では公開日が明示されていない。ここで確実なのは 2026-06-14 時点で確認した内容だけである。
Conversations API を使えば state 設計が不要になるわけではない。保持方針、要約、監査、削除責任は残る。
`previous_response_id` を使っても過去 input token 課金は消えないと guide 上に注意がある。コスト面でも『つなぐだけで安い』とは限らない。