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、監査の設計分岐として読める点にある。
読み終えたら次へ
この1本で終わらせず、同じ目的・同じテーマ・近い原典へ進めます。
何が変わったのか
この 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 上に注意がある。コスト面でも『つなぐだけで安い』とは限らない。
この記事は役に立ちましたか
公益的に続けるため、役に立った点や読みづらかった点だけを短く送れます。メールアドレスは不要です。