長いAPI会話を圧縮すると何が残る？Compactionと原文保存の違い

情報確認日：2026年10月15日

OpenAI APIのCompactionは、長い会話の続きに必要な状態を、少ないトークンで持ち越す仕組みです。返される圧縮情報は暗号化された、人が読むための形式ではありません。会話の全文、原資料、判断の経緯を後から確認したい場合は、それらを別に保存します。

ここでは開発者向けのResponses APIを扱います。ChatGPTの履歴保存や、別サービスの会話書き出しボタンの説明ではありません。OpenAIの現行公式ガイドに沿って、2つの方式と保存の違いを整理します。

圧縮は、長い会話を続けるための処理

会話が長くなると、以前の指示、回答、ツールの結果などが入力の領域を使います。Compactionは、後の処理に必要な状態を持ち越しながら、コンテキストの大きさを抑えるために利用します。

「全部を忘れずに、人が読める短い議事録を作る」ことと同じではありません。公式は、圧縮項目を不透明で人の解釈を意図しないものと説明しています。中身を読んで、全発言がそのまま残っているかを確かめる保管形式には向きません。

圧縮後も、重要な金額・期限・承認条件・参照ファイルが次の作業で正しく扱われるかを、代表的な処理で確認します。圧縮したことだけで、保存や検証が完了したとは扱いません。

現行ガイドでは、Responsesの作成リクエストでcontext_managementとcompact_thresholdを設定します。処理時のトークン数が閾値を超えると、サーバー側で圧縮が行われます。

この方式では、別途/responses/compactを呼ぶ必要はありません。応答ストリームに暗号化された圧縮項目が含まれ、それが次の処理へ必要な状態を持ち越します。

入力配列を自分で管理する方式では、通常どおり出力項目を追加します。previous_response_idで会話をつなぐ方式では、各回の新しい利用者メッセージを渡してIDを引き継ぎます。両方の方式を混ぜて、履歴を二重に送らないよう実装を確認します。

公式は入力配列方式について、最新の圧縮項目より前を落としてリクエストを小さくする方法も案内しています。一方、previous_response_id方式では手動で削らないよう区別しています。

明示的に圧縮する場合は、/responses/compactへ現在のコンテキストウィンドウを送ります。メッセージだけでなく、ツール等の項目も対象です。送る時点で、入力がモデルのコンテキスト上限に収まる必要があります。

返されるものは、暗号化された圧縮項目だけとは限りません。前のウィンドウから保持された項目も含みます。公式は、返されたウィンドウを次の入力として、そのまま渡すよう案内しています。

サーバー側方式で古い項目を減らす説明を、この独立エンドポイントの出力へそのまま当てはめないでください。「圧縮項目だけ残せばよい」と独自に切り取る実装は、公式の出力の扱いと異なります。

会話を後で調べる必要があるなら、利用者メッセージ、モデルの出力、ツールの入出力を、アプリ側の保存ルールに従って記録します。添付や成果物は、本文のURLだけでなく、必要なファイルと版も管理します。

個人情報や秘密情報を含むログを無制限に保存するという意味ではありません。保存目的、アクセスできる人、保管期間、削除方法を組織で決めます。圧縮項目の保管と、監査・業務用の原文ログを分けます。

公式ガイドは、サーバー側圧縮でstore=falseを使う場合のZDRとの関係も説明しています。ただし、アプリが自分で保存したログまで自動的に消える設定ではありません。自社側の保存とAPI側のデータ取扱いを別々に確認します。

本番へ入れる前に、秘密情報を含まない試験用の長い会話を用意します。圧縮前に示した期限や制約、作業済みの範囲を、圧縮後の処理が正しく使えるかを確認します。

不一致があれば、モデル、リクエストの方式、圧縮項目の受け渡し、必要な資料への再アクセスを調べます。圧縮後の自然な回答だけで成功とせず、原文と完成した成果物を照合してください。原文を読み返す必要に備えた保存は、会話を続けるための圧縮と並行して設計します。

執筆・検証：カネさん（政経プラスチャンネル運営）＋ ChatGPT

ほかの記事を探す