Responses APIの状態管理を比較する
CHATGPT / AIChatGPTなどの生成AIを活用して運営・記事制作・更新を行っています。制作方針
Responses APIの手動履歴、previous_response_id、Conversations APIを、保存寿命、再開性、入力token課金、障害時の全履歴再送で比較します。公式仕様と推論を分け、実測していない範囲も明記します。
先に結論
Responses APIの状態管理は、便利さだけで決めず、誰が履歴を保持するか、どの期間で再開するか、失敗時に何を再送するかで選びます。短い一時処理ならアプリ側の手動履歴とstore: false、通常の連続ターンならprevious_response_id、セッションやjobをまたぐ耐久的な状態ならConversations APIを候補にします。これは公式仕様からの設計整理であり、性能・料金の実測結果ではありません。
確認日時: 2026年8月20日（Asia/Tokyo）
対象仕様: OpenAI公式conversation state guide、Developer quickstart、Models documentationの現行記載。公式例のmodel名はgpt-5.6です。
検証区分: 公式資料を比較した机上調査・検証設計です。この制作環境ではAPI接続、token使用量、レイテンシ、失敗復旧、削除処理を実測していません。
適用外: 特定アカウントの契約料金、全modelのcontext window、組織ごとのdata control、tool callの本番監査を一般化すること。
比較対象と固定する条件
比較対象は、同じ入力とmodelを使って状態だけを変える三方式です。Responses APIの公式guideは、手動履歴、previous_response_idによる継続、Conversations APIによる長期オブジェクトを別の選択肢として説明しています。
- 手動履歴: アプリがuser入力とResponse outputを保存し、次の
inputへ明示的に追加します。公式例はstore: falseでこの方式を示します。 - ID継続: 1回目の
response.idを2回目のprevious_response_idへ渡します。前の文脈を自前で組み直さずに続けられます。 - 会話Object: Conversations APIで耐久的な識別子を持つconversationを作り、Responses APIと組み合わせます。公式guideではsession、device、jobをまたいで使える長期オブジェクトと説明されています。
検証用の固定条件は、同一model名、同じsystem相当の指示、同じ2ターンのuser入力、同じ出力上限、同じリージョン・ネットワーク経路、同じSDK版、同じ再試行規則です。model名だけを固定しても、SDKやアカウント条件が変われば結果を同一視できません。
保存寿命と再開性を分けて読む
公式guideによれば、Response objectは既定で30日保存され、store: falseで保存動作を無効化できます。一方、Conversation objectとそのitemsは30日TTLの対象外です。したがって「Response IDを持っている」ことと「無期限に会話を再開できる」ことは同じではありません。
手動履歴はアプリのDBや一時領域に保存する範囲を自分で決められますが、削除・暗号化・アクセス制御・履歴の完全性も自分の責任になります。ID継続は実装が短くなる一方、IDの可用期間、権限境界、上流の保存設定を設計に織り込む必要があります。Conversations APIは再開性の構造を持たせやすい一方、長く残るmessages、tool call、tool outputをどの目的で保持するかを先に定義します。
入力token課金と障害時のフォールバック
公式guideは、previous_response_idを使ってもchain内の過去入力tokenは入力tokenとして課金されると明記しています。IDを渡したから入力コストがゼロになる、あるいは会話が圧縮される、と推論してはいけません。実際の金額はmodel・契約・時点の公式料金情報で別途確認します。
IDを解決できない場合の設計は、次のように分けます。公式guideがprevious_response_id: nullとfull contextによる復旧を明記しているのはWebSocket modeであり、通常HTTPにも同じ復旧が保証されるという記載ではありません。
- 同一conversation、対象ID、認証主体、model設定の取り違えを記録し、まず自動リトライを止める。
- 再送してよいデータだけを選び、保存した全履歴を無条件に送らない。
- 通常HTTPではAPI errorと保存設定を確認し、手動履歴で新しいResponseを作る復旧手順を別途検証する。WebSocket modeで未cacheのIDを解決できない場合は、公式guideに沿って
previous_response_id: nullとfull contextで新しいturnを作る。 - 再送時のtoken増加、context window超過、秘密情報の露出を監査し、再開成功と同一回答を混同しない。
このフォールバックの成否や速度は環境依存です。実行ログ、token数、例外、再送したデータ量を測定しない限り、復旧率やコストを数値で主張しません。
観測方法と適用範囲
実測するなら、方式ごとに同じ2ターンを最低限10回ではなく、目的に応じた回数を事前に決め、各回のrequest開始時刻、Response IDの関連、入力・出力token、HTTP status、待ち時間、再試行回数、保存操作、失敗分類を記録します。値は平均だけでなく分布と外れ値を残し、アプリ側のDB時間とAPI時間を分けます。
| 方式 | 向いている場面 | 先に決める境界 |
|---|---|---|
| 手動履歴 | 短命・保存範囲を自分で制御したい処理 | 履歴の暗号化、削除、再送上限 |
| previous_response_id | 実装を短くした連続turn | Responseの寿命、権限、入力token課金 |
| Conversations API | session・device・jobをまたぐ状態 | 耐久保存、アクセス制御、監査、削除方針 |
この表は優劣の測定結果ではなく、公式仕様から設計上の確認点を整理したものです。tool callやtool outputを扱う場合は、会話の見た目だけでなく、どのitemを保存・再実行してよいかを別途決めます。
判断基準と未検証範囲
本番へ採用する前に、次の順で判断します。まず保存してよいデータと削除期限を決め、次に障害時にfull contextを再送できるかを確認し、最後に同じ条件でtokenとレイテンシを実測します。保存要件がないのに耐久Objectを選ぶ、またはID継続を使えば入力課金が減ると期待する、という順序は避けます。
未検証なのは、各方式の実レイテンシ、実料金、同時実行時の挙動、全modelのcontext window、組織のdata control、削除APIを含む運用手順です。これらは公式仕様を読んだだけでは環境固有の結論にならないため、固定条件を作ってから検証します。
入門記事
まず1回目のResponseとresponse.idを取得する場合は、同日公開の入門ガイドで最短手順を確認してください。
参考資料
- OpenAI API Conversation state guide（3方式、保存期間、課金、WebSocket modeの復旧例を2026年8月20日に確認）
- OpenAI API Developer quickstart（Responses APIとSDKの現行例を2026年8月20日に確認）
- OpenAI API Models（modelの確認先を2026年8月20日に確認）
