APIで前の回答IDを渡せば指示も料金も省ける？会話の継続と入力トークン

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

Responses APIのprevious_response_idで会話を続けても、過去の入力が無料になるわけではありません。また、前回のinstructionsは次の生成へ自動では引き継がれません。会話の内容を渡す仕組みと、毎回守らせる指示、入力の課金を分けて管理します。

回答IDは、前の会話へつなぐ手掛かり

APIでは通常、各生成リクエストに、その回に必要な文脈を渡します。previous_response_idを指定すると、前の回答へつなげた会話を作れます。前の文章を毎回手作業で組み立て直す負担を減らす方法です。

例えば、最初に文章の要点をまとめ、次に「2番目の項目を詳しく」と聞くとき、前の回答IDを指定すれば、何の2番目かを会話の文脈で扱えます。公式の会話状態ガイド

ただし、IDを使うことは、会話を永久に記憶する機能ではありません。ChatGPTのメモリ設定や、CodexがPCに保存するメモリとも別の仕組みです。

instructionsは、回答の目的、語調、書式など、生成時の振る舞いを指定するパラメーターです。公式の文章生成ガイドは、この指定が現在の生成リクエストだけに適用されると説明しています。

previous_response_idを使う場合も、以前のinstructionsが次回の文脈に残るわけではありません。アプリが毎回守ってほしい条件は、次の生成にも明示する必要があります。指示の有効範囲

これは説明用の構成例です。アプリが裏で指示を付けているかは、実際の送信内容で確認します。利用者の画面に指示文が見えないことと、APIへ送っていないことは同じではありません。

次の入力が「もっと短く」の一言でも、モデルが参照する会話は一言だけではありません。公式ガイドは、回答IDを使ってつないだ場合にも、連鎖内の過去の入力トークンが入力として課金されると明記しています。

トークンはAIが文章を扱う処理単位で、日本語の文字数とは一致しません。IDの文字数だけを数えたり、新しい質問だけを料金表へ掛けたりすると、会話全体の利用量を見落とします。

キャッシュが適用される入力は、対象モデルの料金区分に従って扱われます。しかし、回答IDを使えば過去の文脈がすべて無料になるという仕組みではありません。見積りではモデル、入力・出力の利用量、適用される料金区分を確認します。

回答をつなぐ方法は、モデルのコンテキスト上限をなくしません。コンテキストは、一回の処理で使う入力、出力、モデルによっては推論用のトークンを収める範囲です。

長い資料と何度もの修正を積み重ねると、必要な量が増えます。過去を全部必要とするのか、要点を引き継ぐのか、別の会話へ移すのかを用途に応じて決めます。省略する場合も、日付・金額・確定条件などを落としてよいとは限りません。

必要な原文と、生成を続けるための文脈は別に管理します。IDだけを業務記録に残し、後で原資料や回答を読み直せると決め付ける方法は避けます。

公式の会話状態ガイドでは、Responseオブジェクトは標準で30日保存され、作成時のstore: falseでこの保存を無効にできるとしています。ただし、機能固有の一時保存や、組織のデータ管理条件は別途確認が必要です。

一方、Conversations APIは、会話自体に持続する識別子を持たせ、メッセージやツールの結果などを保存する方法です。Conversationの項目には、Responsesの30日の自動期限は適用されません。

「前の回答へつなぐ」と「長期の会話オブジェクトを作る」は、似た目的でも保存の条件が異なります。必要のない情報まで長く保存しないよう、利用する方式と削除・保管の運用を先に確認します。

開発担当者は、最初に送信先のプロジェクトと回答IDが正しいかを確認します。別の会話のIDや、取得できないIDを使っていないかを、アプリの記録と照合します。

次に、当該リクエストのinstructionsとinputを確認します。「前回に指定したから」という理由で、今回の必須条件が抜けていないかを調べます。会話内容の参照と、指示の継続をここで分けられます。

最後に、上限、保存設定、エラー、利用量を確認します。出力が条件を守ったかは結果でも検証し、IDが返ったことだけで正しい引き継ぎができたとは判定しません。

問い合わせには、日時、モデル、エラー、該当の回答ID、キーを除いた最小のリクエスト例を用意します。これにより、文脈のつなぎ方、指示の不足、保存・取得の条件を具体的に切り分けられます。

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

ほかの記事を探す