LLMの会話履歴をどう設計するか｜全量・直近N・要約・検索の7方式と壊れやすい境界

チャットやエージェントを本番に出すと、だいたい同じ順番で問題が出ます。最初は品質、次にレイテンシ、そして「会話が長くなると急におかしくなる」という報告です。5往復目までは正確だったのに、15往復目には最初に伝えた制約を無視する。あるいは、料金だけが会話の長さに比例して膨らんでいく。この記事では、会話履歴(コンテキスト・メモリ)の設計を、7つの方式の比較と、実装で実際に壊れる境界の話として整理します。判断の根拠になる部分は各社の公式ドキュメントと論文を確認しながら書いています。

症状:長い会話で何が起きているのか#

現場で報告される「長い会話だと変になる」は、少なくとも4種類の別の現象が混ざっています。

1つ目は、指示の消失です。会話の冒頭で与えた制約(出力形式、禁止事項、対象範囲)が、後半で無視されます。履歴を要約で圧縮している場合、要約器が「制約」を重要な情報だと判断せず落としているケースが典型です。

2つ目は、コストとレイテンシの膨張です。ステートレスなAPIでは、毎ターン過去の全履歴を送り直します。Anthropicのコンテキストウィンドウのドキュメントは、リクエストに含まれるものはすべてコンテキストウィンドウに数えられるとしています。システムプロンプト、messages内の全メッセージ(ツール結果・画像・ドキュメントを含む)、そしてツール定義です。加えて、そのターンでモデルが生成した出力も、拡張思考を含めて次のターンの入力になります。つまり会話が続くほど入力トークンは単調増加します。

3つ目は、途中で会話が破綻して回復しないパターンです。序盤に立てた誤った前提を後半まで引きずり、訂正しても戻らない。これは後述する論文が正面から扱っています。

4つ目は、上限への衝突です。Anthropicのドキュメントによれば、入力だけでコンテキストウィンドウを超える場合は400 invalid_request_error(prompt is too long)が返ります。Claude 4.5以降のモデルでは、入力トークンとmax_tokensの合計が超える場合はリクエスト自体は受理され、生成中に上限に達するとstop_reason: "model_context_window_exceeded"で停止します。以前のモデルではバリデーションエラーになりますが、model-context-window-exceeded-2025-08-26のベータヘッダを付けると同じ挙動にオプトインできる、とも書かれています。

なぜ起きるのか:容量の問題ではない#

まず押さえておきたいのは、コンテキストウィンドウが広ければ解決するわけではない、という点です。

Anthropicのコンテキストウィンドウのドキュメントは、より大きなコンテキストウィンドウはより複雑で長いプロンプトを扱えるようにするが、コンテキストは多ければ自動的に良いというものではない、と明記しています。そして、トークン数が増えるにつれて正確さと想起(accuracy and recall)が劣化する現象をcontext rotと呼び、「コンテキストに何を入れるかを吟味することは、どれだけの容量が使えるかと同じくらい重要になる」としています。

Anthropicのエンジニアリングブログ「Effective context engineering for AI agents」は、これをattention budget(注意の予算)という言い方で説明しています。同記事はコンテキストエンジニアリングを「LLMの推論中に、最適なトークン(情報)の集合をキュレーションし維持するための戦略の集合」と定義したうえで、Transformerがトークン間の総当たりの関係を計算する構造上、コンテキストは有限の資源として扱うべきで、限界効用は逓減すると述べています。

Googleの長文脈のドキュメントも同じ方向の注意を書いています。Geminiモデルは各種のneedle-in-a-haystack(干し草の中の針)型の検索評価で高い性能を出すとしつつ、複数の情報を同時に取り出す必要がある場合には性能が落ちうるとし、性能は文脈次第で大きく変動しうると述べています。また、実務的な助言として、クエリや質問はプロンプトの末尾(他のすべてのコンテキストの後)に置いたほうが性能が良くなる、としています。

マルチターン特有の劣化:能力ではなく「ばらつき」#

もう1つ、容量とは別の要因があります。情報が複数ターンに分散していること自体が難しい、という問題です。

Laban, Hayashi, Zhou, Nevilleによる論文「LLMs Get Lost In Multi-Turn Conversation」(arXiv:2505.06120)は、単一ターンとマルチターンを大規模シミュレーションで比較しています。同論文の要旨は、テストしたトップクラスのオープン/クローズドのLLMがいずれもマルチターンで単一ターンより有意に低い性能を示し、6つの生成タスクで平均39%の低下があったと報告しています。

興味深いのはその内訳です。同論文は20万件を超えるシミュレーション会話の分析から、性能低下を「aptitude(能力)のわずかな低下」と「unreliability(不安定さ)の大幅な増加」の2成分に分解しています。論文中の図1では、マルチターン設定について能力が-15%、不安定さが+112%(2倍以上)と示されています。ここでの能力は最良ケースのシミュレーション結果、不安定さは最良ケースと最悪ケースの差として定義されています。なお本文側の記述では、能力の低下はFullからShardedへの平均で16%と有意でない水準にとどまる一方、不安定さは平均112%増加した、とされています。検証対象は8つのモデルファミリから選んだ15のLLMです。

原因についても踏み込んでいます。同論文は、LLMは早いターンで仮定を置き、最終的な解を早すぎるタイミングで出そうとし、それに過度に依存する傾向があるとしています。要旨の言葉を借りれば「会話で誤った方向に進むと、道に迷って戻ってこない」という現象です。

7つの方式を比較する#

以上を踏まえて、履歴の扱い方を7つに分けて整理します。実務ではこれらを組み合わせますが、単独の性質を把握しておくと組み合わせの判断がしやすくなります。

各方式の補足#

(a)全量そのままは、実は最初の選択肢として悪くありません。数往復で完結する問い合わせなら、加工しないほうが安全で、しかもプロンプトキャッシュの恩恵を最大化できます。Anthropicのプロンプトキャッシュのドキュメントは、自動キャッシュを使うと会話が伸びるにつれてキャッシュ位置も自動的に前進し、各リクエストで最後のキャッシュ可能ブロックまでがキャッシュに書かれ、それ以前は読み出しになる、という逐次キャッシュの動作を説明しています。履歴を加工しない限り、この形が素直に効きます。

(b)直近Nターンと(c)トークン予算での切り詰めは、実装が最も簡単な代わりに、いちばん静かに壊れます。LangChainの短期メモリのドキュメントは、メッセージを削除する際は結果として残るメッセージ履歴が妥当であることを必ず確認するよう明記し、ほとんどのプロバイダはツール呼び出しを含むassistantメッセージの後に対応するtool結果メッセージが続くことを要求する、と注意しています。機械的に古い順に落とすと、この対が割れます。

(d)(e)の要約は、実務で広く使われる形です。プロバイダ側の機能としても提供され始めています。Anthropicのcompaction(ベータ、ベータヘッダcompact-2026-01-12)は、コンテキストウィンドウの上限に近づくとサーバ側で古い文脈を要約する機能で、ドキュメントによればClaude 4.6以降のモデル向けにベータ提供されています。既定のトリガ閾値は入力15万トークン(設定可能な最小値は5万トークン)です。仕組みとしては、要約を含むcompactionブロックが応答に返り、以降のリクエストではそのブロックより前のコンテンツブロックがAPI側で自動的に落とされます。ドキュメントは、compactionブロックを次のリクエストに渡し返す必要があると明記しています。応答のテキストだけを取り出して積むと、この状態が黙って失われます。

(f)ベクトル検索は、履歴が非常に長く、参照が散発的な場合に効きます。ただし会話履歴を検索対象にすると、文書検索とは違う難しさが出ます。「さっき言ったやつ」のような指示語が多く、単独のターンだけを取り出すと意味が確定しないためです。ターン単位ではなく話題の区切り単位でまとめる、直近数ターンは検索を通さず必ず原文で入れる、といった補強が要ります。

(g)構造化した状態は、実装コストが最も高い代わりに、いちばん壊れにくい形です。Anthropicのcontext engineeringの記事も、長時間タスクの手法としてcompaction・structured note-taking(構造化されたノート取り)・sub-agentアーキテクチャの3つを挙げており、2つ目がこれに当たります。同記事は、エージェントがコンテキストウィンドウの外に永続化するノートを定期的に書き、後で読み戻すことで、稼働中のコンテキストを消費せずに長時間タスクの記憶を保てる、と説明しています。

選び方の判断軸#

方式そのものより、選ぶための軸を先に決めるほうが実務では速く進みます。4つの質問で絞れます。

実務上の出発点としては、(a)全量から始めて、実測で困ってから(e)要約+直近全文に移り、エージェントならツール結果の扱いを別建てにする順序を勧めます。最初から(f)や(g)を作り込むと、たいてい過剰設計になります。

壊れやすい境界#

ここからがこの記事の本題です。会話履歴の設計は、動かないバグではなく「静かに品質が落ちるバグ」を生みます。実際に踏みやすい境界を6つ挙げます。

1. 要約でシステム指示や制約が消える#

要約器に「これまでの会話をまとめて」と投げると、要約器は会話の内容を要約します。ユーザーが途中で述べた制約(「金額は税抜きで」「社外秘の情報は出さないで」)は、流れとしては些末に見えるため落ちやすい。

対処は、要約の対象と保護対象を分けることです。システムプロンプトは要約に含めず常に原文で先頭に置き、ユーザーが述べた制約は要約とは別に「制約リスト」として構造化して保持します。つまり(e)と(g)の併用です。要約プロンプト側でも、決定事項・未解決事項・守るべき制約を項目立てで出させると落ちにくくなります。

2. ツール結果が履歴を肥大させる#

エージェントでは、ファイル内容や検索結果がそのまま履歴に積まれます。Anthropicのcontext editingは、この問題に特化した機能です。clear_tool_uses_20250919ストラテジは、ドキュメントの表現では「Claudeが処理し終えたあとの古いツール結果(ファイル内容や検索結果など)はもう必要ない」という前提に立ち、古いものから順にツール結果をクリアし、削除したことを示すプレースホルダのテキストに置き換えます。

パラメータの既定値は、公式ドキュメントによればtriggerが入力10万トークン(tool_usesでの指定も可)、keepが直近3組のツール呼び出しと結果、clear_tool_inputsはfalse(既定ではツール結果だけをクリアし、Claude自身のツール呼び出しは残す)です。加えて、消してはいけないツールをexclude_toolsで除外できます。

自前で実装する場合も考え方は同じです。ツール結果は本文と同じ重みで扱わず、別のライフサイクルを持たせます。

3. 途中を削るとプロンプトキャッシュのプレフィックスが崩れる#

これがコストとレイテンシに直撃する境界です。

Anthropicのプロンプトキャッシュのドキュメントは、キャッシュのプレフィックスがtools->system->messagesの順に作られるとし、キャッシュのブレークポイント以前の内容を変更すると、そのキャッシュエントリと以降のすべてが無効になると説明しています。ブレークポイントまでのプレフィックス全体の累積ハッシュを計算しているため、どこか1文字でも変われば別のハッシュになる、という仕組みです。過去のユーザーメッセージやアシスタントメッセージを編集した場合も同様に、以降のキャッシュが無効になります。

OpenAIのプロンプトキャッシュのドキュメントも同じ性質を書いています。利用可能なブレークポイントを後ろ向きにたどって最長の一致プレフィックスを探す仕組みであり、ブレークポイント以前で内容や関連設定が変わると、その変更以降のプレフィックスは一致できない、としています。モデル、ツール定義、スキーマ、推論設定、出力形式、コンテキスト管理の設定を変えるとキャッシュはリセットされます。

つまり、「トークンを減らすために古いターンを削る」という操作は、同時に「キャッシュ読み出しを捨てて全量を再びキャッシュ書き込みする」という操作でもあります。削って浮くトークンより、キャッシュを失って増える課金のほうが大きい、という逆転が起こりえます。

Anthropicのcontext editingのドキュメントは、この点を正面から扱っています。ツール結果のクリアはキャッシュされたプロンプトのプレフィックスを無効化するため、キャッシュ無効化に見合うだけのトークンをクリアするべきであり、そのために毎回最低限クリアするトークン数を保証するclear_at_leastパラメータを使う、と説明しています。クリアのたびにキャッシュ書き込みのコストが発生するが、以降のリクエストは新しくキャッシュされたプレフィックスを再利用できる、とも書かれています。

4. 途中の指示変更が要約で丸められる#

会話の途中で運用側が指示を追加したい場面があります(モード切り替え、注意事項の注入など)。素朴な実装は、トップレベルのシステムプロンプトを書き換えることです。しかしプレフィックス階層の先頭を変えるので、キャッシュは全滅します。

Anthropicのプロンプトキャッシュのドキュメントは、一部のモデルで、トップレベルのsystemフィールドを編集する代わりに{"role": "system"}のメッセージをmessagesに追加することで、キャッシュされたプレフィックスを変えずに会話の途中でシステム指示を追加できる、と説明しています(ドキュメントによればClaude Sonnet 5では利用できず、トップレベルのsystemフィールドを使うことになります)。使えるモデルかどうかは公式の対応表で確認してください。

この機能が使えない場合でも、設計の考え方は変わりません。運用側の指示は、ユーザー発話と同じ層に混ぜて要約対象にしない。要約に飲まれると「途中で切り替えたはずのモードが後半で元に戻る」という再現しにくい不具合になります。

5. PIIや権限外の情報が履歴に残り続ける#

会話履歴は、放っておくと個人情報の貯蔵庫になります。しかも永続化され、保存先によっては保持期間の設定も別建てです。

OpenAIのconversation stateのドキュメントは、レスポンスオブジェクトが既定で30日間保存されること、storeをfalseにすると自動保存を無効化できることを説明しています。加えて、Conversationオブジェクトとその中のアイテムは30日のTTLの対象ではない、とされています。会話に紐づけたものは、明示的に消さない限り残るということです。

Anthropicのmemory toolのように、クライアント側でファイルとして永続化する仕組みではさらに直接的です。同ドキュメントは、メモリツールはクライアント側で動作し、Claudeはファイル操作を要求するだけで実行するのはアプリケーション側だとしたうえで、セキュリティ上の考慮として、機微情報の書き込みを防ぐ検証、ファイルサイズの上限、長期間アクセスされていないメモリファイルの定期削除、パストラバーサル対策(/memories/../../secrets.envのような経路を検証で弾く)を挙げています。

実務的には、履歴に入れる前にマスキングする、権限が変わったら該当ターンを引かない、会話単位の保持期間を業務要件から決める、の3点を先に決めておくのが安全です。ここは法務やセキュリティ要件と直結するため、自社の状況に合わせて確認してください。

6. 履歴の機械的な加工がAPIの制約に触れる#

最後に、実装レベルで即座にエラーになる境界です。

Anthropicのコンテキストウィンドウのドキュメントは、ツール結果を返す際には、対応するツール要求に付随するthinkingブロックを署名込みで一切変更せずに含める必要があるとし、APIは暗号署名でthinkingブロックの真正性を検証するため、thinkingブロックを変更するとエラーを返す、と明記しています。履歴を再構築する処理がブロックを正規化したり、空白を整えたりすると、ここで落ちます。

同様に、過去のthinkingブロックがコンテキストに残るかどうかはモデルによって異なります。同ドキュメントによれば、あるモデル群では既定で保持されて入力トークンとして数えられ、別のモデル群では渡し返しても自動的に除去されます。履歴管理コードが、モデルによって異なる前提の上に立っていないかは確認する価値があります。

OpenAI側にも似た注意があります。conversation stateのドキュメントは、推論モデルをステートレスに(履歴を自前で組み立てて)呼ぶ場合、応答のoutput配列の全アイテムを保持するよう述べています。Responses APIは既定で暗号化された推論アイテムを返すため、テキストだけを抜き出して積むとこれが失われます。

会話状態をどこに置くか#

方式が決まったら、次は置き場所です。選択肢は3つあります。

クライアント側に持つ形は、ブラウザやアプリが履歴を保持して毎回サーバに送ります。実装は軽い一方、送られてきた履歴を信用することになるため改竄への耐性がなく、システムプロンプトや制約をサーバ側で再付与する前提でなければ使えません。

サーバ側に持つ形は、自前のDBに会話を保存し、リクエストごとに組み立てます。もっとも自由度が高く、監査ログや保持期間の管理もやりやすい形です。LangGraphのpersistenceのドキュメントは、この層を明示的にモデル化しています。checkpointerがグラフの状態スナップショットを保存し、thread_idで識別されるスレッド単位の短期メモリを提供する構成で、実装としてInMemorySaver(プロセス再起動で消える)、SqliteSaver(開発向け)、PostgresSaver/AsyncPostgresSaver(本番向け)が挙げられています。さらにスレッドをまたぐ長期メモリとしてstoreがあり、ユーザーの好みや事実といったアプリケーション定義のkey-valueデータを保持できる、とされています。この「スレッド内の短期」と「スレッドをまたぐ長期」の分離は、フレームワークを使わない場合でも設計の型として有用です。

プロバイダ側に持つ形は、APIの状態管理機能に預けます。OpenAIのconversation stateのドキュメントは、メッセージ配列を自分で組み立てて渡す方法、previous_response_idで応答を数珠つなぎにする方法、そしてConversationsという永続オブジェクトに状態を保持する方法の3つを挙げています。手数は最も少なくなりますが、保持期間の扱いが異なる点と、プロバイダを移す際の移植性は評価に入れておく必要があります。

再現性とデバッグのためのログ設計#

会話履歴のバグは、再現できないと直せません。最低限、次の項目をターンごとに残すことを勧めます。

とくに最後の項目は軽視されがちですが、「なぜ制約が消えたのか」を調べるとき、要約文が残っているかどうかで調査時間が桁で変わります。要約は再生成すると別物になるため、後から復元できません。

評価:マルチターンの回帰セットを作る#

履歴設計の変更は、単一ターンの評価セットでは検出できません。マルチターン専用の回帰セットが要ります。

作り方の骨子は、前述の論文の手法がそのまま参考になります。同論文は、完全に指定された1つの指示を複数の「シャード」に分割してターンごとに開示するSharded設定と、同じシャードを箇条書きで1つの指示に連結したConcat設定を比較しています。Concatは検証用のベースラインで、FullとConcatの両方に成功するのにShardedで失敗するなら、原因は言い換えではなくマルチターンであること自体にある、と切り分けられます。自社で作るときも同じ形にできます。

切り詰めの前後を比較するときは、指標を2つ並べます。1つは正答率(またはルーブリックのスコア)、もう1つは1会話あたりの合計入力トークンです。この2軸でプロットすると、「トークンを3割削ったら正答率が1割落ちた」という交換条件が見えます。どこで妥協するかは業務側の判断ですが、材料がないまま圧縮率だけを上げていく状態は避けられます。

なお、要約に使うモデルは本番の応答に使うモデルと分けて記録してください。安いモデルに任せると入力コストは下がりますが、制約の取りこぼしが増えることがあります。

監視:本番で見る数字#

評価セットは変更前の判断に使い、監視は変更後の劣化検知に使います。見るべき数字は多くありません。

会話の長さの分布(ターン数とトークン数のp50/p95)は、設計の前提が崩れていないかを見るためのものです。想定より長い会話が増えていれば、圧縮の発生頻度も上がっています。圧縮・切り詰めの発生率が全リクエストの1割を超えるようなら、加工が例外ではなく通常運転になっているということなので、方式そのものを見直す合図です。

キャッシュ読み出しトークンの比率は、コストの健康診断です。Anthropicのドキュメントによれば、cache_creation_input_tokensとcache_read_input_tokensの両方が0なら、そのプロンプトはキャッシュされていません(モデルごとに最小のキャッシュ可能トークン数があり、それ未満だとエラーにならずキャッシュされないだけ、とされています)。OpenAIもGPT-5.6以降で1,024の可視入力トークン、それ以前のモデルで2,048という下限を示しています。Googleの暗黙キャッシュにもモデル世代ごとの最小入力トークン数があり、ドキュメントではGemini 2.5世代が2,048、Gemini 3世代が4,096とされています。会話が短いうちはキャッシュが効かないのが正常なので、会話の長さと合わせて見る必要があります。

停止理由の分布は、上限への衝突を検知するためのものです。コンテキスト超過に気づいていない状態は避けたいところです。

小さく始める順番#

一度に全部は作れないので、効果と工数の比で並べます。

よくある質問#

まとめ#

会話履歴の設計は、「何トークンまで送るか」という容量の話に見えて、実際は「何を捨てられるか」を決める判断です。そして捨てる判断を間違えても、システムは動き続けます。落ちるのは品質だけです。

順番としては、まず計測、次に全量のままキャッシュを効かせる、それからツール結果を別扱いにする、回帰セットを作ってから要約を入れる、という並びが安全です。最初から凝った圧縮を作り込むと、効果を測れないまま複雑さだけが増えます。

そして、境界の話を覚えておいてください。要約は制約を落とします。切り詰めはツール呼び出しの対を割ります。途中の書き換えはキャッシュのプレフィックスを壊します。履歴の永続化はPIIを残します。thinkingブロックの加工はエラーになります。どれも、実装した瞬間には気づけない種類の問題です。

最後に、マルチターンでの劣化は履歴設計だけでは消えません。論文が示したのは、能力そのものより不安定さが大きく増えるという構図でした。であれば、長い会話を長いまま完璧に扱おうとするより、要件が固まった時点で一度整理し直す導線を業務フローとUIの側に用意するほうが、実務としては現実的な着地点だと考えています。