AI アシスタントを数十ターンにわたる、あるいは数時間続く長い会話で使うとき、最も多い不満は「賢さが足りない」ではなく「後半になるほど最初に決めたルールを忘れ、回答もどんどんずれていく」というものです。原因はモデルの知能ではなく、コンテキストウィンドウ(context window)が有限のトークン予算だという点にあります。2026 年には Claude、Gemini、GPT など先端モデルのほとんどが百万トークンのウィンドウを標準搭載していますが、それでも長い会話はこの予算を使い切り、重要な制約はウィンドウから押し出され、コストは加速的に増え、注意も薄まっていきます。コンテキストエンジニアリングとは、この固定された予算のなかで「何を残し、何を捨て、何を圧縮し、どこへ移すか」を決める一連の工学的手法です。
コンテキストウィンドウは有限の予算:長い会話がぶつかる三つの壁
会話履歴の一段ごと、貼り付けた文書一つひとつが、ウィンドウのトークン枠を消費します。会話が長くなると、順に三つの壁にぶつかります。
- 容量の硬い壁:ウィンドウには上限があり、超えれば履歴は切り詰められ、最も古いメッセージが黙って捨てられます。冒頭で決めたルールや制約も含めてです。
- コストと遅延の壁:多くの API は入力トークンで課金し、毎ターン履歴全体を再送します。長い会話の費用は線形ではなく加速的に増えます。ウィンドウが大きいことは安いことを意味しません。Google は Gemini 2.5 Pro の 20 万トークンを超えるリクエストを、入力百万トークンあたり 1.25 ドルではなく 2.5 ドルで課金します。百万トークンのウィンドウを埋めることは、毎ターン上位料金を払うのと同じです。
- 精度の壁:研究では「中間で迷子になる(lost in the middle)」と呼ばれます。情報がウィンドウ内にあっても、モデルは中間に置かれた内容への注意が最も弱くなります。ノイズを詰め込むほど、肝心の指示は薄められてしまいます。
つまり、ウィンドウを満杯にしても AI は賢くなりません。むしろ高く、遅く、注意散漫になります。コンテキストエンジニアリングの目的は、最小のトークンで、正しいタイミングにモデルへ正しい情報を届けることです。
「長く話すほど鈍る」は錯覚ではない:context rot の研究証拠
長い会話での劣化は主観だと片付けられがちですが、体系的なデータが存在します。2024 年、スタンフォード大学とカリフォルニア大学バークレー校のチームは「Lost in the Middle」を発表し、U 字型の曲線を示しました。答えが長い入力の先頭か末尾にあるとき精度は最も高く、中間では大きく崩れます。2025 年、Chroma の「context rot」研究は対象を 18 の先端モデル(Claude Opus 4、GPT-4.1、Gemini 2.5、Qwen3 を含む)に広げ、同じ結論に至りました。入力トークンが増えるほど、どのモデルも性能が低下し、しかもウィンドウ上限に達するはるか手前で下がり始めます。その LongMemEval テストでは、同じ質問に約 300 トークンの精選された文脈を与えたほうが、約 11.3 万トークンの完全な履歴を与えるより明らかに精度が高くなりました。研究はまた、意味的には近いが無関係な「妨害段落」がモデルを積極的に誤らせ、幻覚の回答に繰り返し現れることも見出しています。
重要な含意は、これが Transformer の注意機構の構造的な性質であり、「ウィンドウの大きい新モデルに替える」だけで解決する能力の不足ではない、という点です。内容を詰め込むほど精度が落ちる以上、コンテキストの管理は任意ではなく、長い会話システムの基本工学です。
スライディングウィンドウと切り詰め:最も省力だが健忘症になる
最も直感的な方法はスライディングウィンドウで、直近 N ターンだけを残し、古いものは自動的に淘汰します。追加計算がほとんど不要で実装コストが最も低く、「たいてい直近の文脈だけで足りる」カスタマーサポートの問答のような場面に向きます。代償は完全な健忘です。ユーザーが冒頭で設定した好み・身元・制約がウィンドウから外れた瞬間、AI は聞いたことがないかのように振る舞います。よくある落とし穴は、ユーザーが最初に「金額はすべて新台湾ドルで」と伝えても、30 ターン後にはその一言が消え、AI が再び米ドルで答え始めることです。だからこそ、純粋な切り詰めが単独で使われることはまれで、通常は重要メッセージの「ピン留め」や、淘汰前の要約と組み合わせ、重要な制約を一緒に捨てないようにします。
要約圧縮と compaction:履歴を精髄へ凝縮する
まるごと捨てるより、古い会話を要約に圧縮して残すほうが賢明です。よくある手法はローリング要約で、履歴が設定したトークン閾値に達すると、より古い部分をモデルに渡して数点の要点へ凝縮させ、要約が原文を置き換えて会話を続けます。Anthropic は 2025 年 9 月のコンテキストエンジニアリング指針でこれを compaction と呼び、Claude Code の実装原則を明かしています。要約時にはアーキテクチャ上の決定、未解決のバグ、重要な実装詳細を意図的に残し、冗長なツール出力や重複メッセージは捨てる、というものです。
費用対効果は明確です。会話が長くなるほど、「要約してから送る」ほうが「原文をまるごと再送する」より安くなる効果は大きくなり、1 ターンあたりの平均コストを長期的に押し下げます。ただし成否は要約の品質次第です。繰り返し圧縮すると「コンテキストドリフト」が起こり、正確な数字や微妙な制約がターンごとに蒸発します。鍵は「何が何でも残すべき項目」を明示的に定義することです。注文番号、顧客の身元、確定済みの決定などは、モデルの自由裁量に任せて重要な前提まで圧縮させるのではなく、要約時の必須保持項目として指定すべきです。
分割と外部退避:記憶をウィンドウの外へ、必要なときに取り戻す
背景資料の量がウィンドウ容量をはるかに超えるとき、正しいやり方は無理に詰め込むことではなく退避(offload)です。完全な履歴と文書を意味的にまとまった断片(chunking)に切り分け、ウィンドウの外の外部ストレージに保存し、毎ターン現在の質問に最も関連する数断片だけをウィンドウへ取り戻します。これにより有効な知識量はウィンドウの大きさに縛られなくなり、ウィンドウへ入るのはその時点で高度に関連する内容だけになるため、「中間で迷子になる」問題も直接和らぎます。
分割のパラメータは品質を直接左右します。実務では一般用途で 1 断片あたり約 512 トークン、断片間に 1〜2 割の重なりを持たせ、境界をまたぐ重要な事実を切断しないようにすることが多く勧められます。Microsoft Azure の公式文書は、512 トークン・重なり 2 割 5 分を出発点として推奨しています。方法としては、意味的分割は Chroma のテストで最高約 91.9% の再現率を示し、固定長の 85〜89% を上回りました。しかし Vectara の NAACL 2025 研究は、単純な固定 200 トークンの分割が実データでは意味的分割に匹敵、あるいは上回ることも多いと注意を促し、3 つの埋め込みモデルにわたる検証の結果、分割設定が検索品質に与える影響は埋め込みモデルの選択に劣らないと結論づけました。つまりアルゴリズムに悩むより、断片長と重なりを正しく調整するほうが効きます。なお、ここで扱うのは「今のこの長い会話」の履歴をウィンドウの外に置いて随時取り出すことであり、単一の会話の容量工学です。会話やユーザーをまたぐ長期記憶ストアを構築することとは別の階層の問題です。
重要情報のピン留めと戦略の組み合わせ:圧縮で制約を失わせない
あらゆる圧縮・淘汰の戦略には共通のリスクがあります。捨ててはいけないものを捨ててしまうことです。ゆえにコンテキストエンジニアリングは「何があっても在席すべき」重要情報を意図的に残さねばなりません。よくある方法は、システム指示・ユーザーの身元・硬い制約をウィンドウの固定位置にピン留め(pin)し、スライドや要約の影響を受けないようにすることです。より堅牢なのは、これらの重要事実を構造化された状態(たとえば会話に応じて更新される項目表)として抽出し、圧縮可能な自由会話とは分けて管理することです。四つの戦略の得失は次のとおりです。
| 戦略 | 適した場面 | 利点 | 代償 |
| スライディングウィンドウ | 直近の文脈だけで足りる短い流れ | ほぼ無コスト、実装が最も簡単 | 冒頭のルールと制約を失う |
| 要約圧縮 | 長い会話だが経緯を残す必要がある | 少ないトークンで大量の履歴を保持 | モデル呼び出しが一回増え、要約品質が成否を決める |
| 分割+外部退避 | 背景資料がウィンドウよりはるかに大きい | 有効な知識量がウィンドウに縛られない | 検索基盤が必要、分割品質に配慮が要る |
| 重要情報のピン留め | 決して忘れてはならない硬い制約がある | 核心の指示が常に在席する | 固定枠を占有し、範囲を人手で定める必要がある |
実務ではこの四つを単独で使うことはまれで、一本のパイプラインへ組み合わせます。重要な制約をピン留めし、直近の会話は原文で残し、より古い履歴は要約に圧縮し、巨大な背景は外部検索へ退避します。あるチームはスライディングウィンドウ、関連性検索、構造化状態を組み合わせ、1 リクエストあたりの平均トークンを約 1.8 万から 6,500 へ、およそ 64% 削減しながら、回答品質を落としませんでした。組み合わせの比率は、会話がどれほど長いか、どこまでコストを許容できるか、どの情報が絶対に失われてはならないかで決まります。
恩梯科技(Nerdtechnic)のコンテキストエンジニアリング支援
長い会話での安定した性能は、ウィンドウの大きいモデルに替えることではなく、トークン予算を要所に使うコンテキストエンジニアリングから生まれます。恩梯科技は企業の AI アシスタントやエージェント導入を支援する際、まず実際の会話の長さ、コストの上限、必ず残すべき重要情報を計測し、そのうえでスライディング、要約圧縮、分割退避、重要情報のピン留めを組み合わせた戦略を設計し、観測可能な指標で精度と 1 ターンあたりのコストを検証します。これにより AI は長い会話のなかで焦点を保ち、コストを抑え、しかも肝心の瞬間に、あなたが最初に伝えたあの一つのルールを忘れません。コンテキストをきちんと管理してこそ、AI は「会話が上手」から「長く話しても頼れる」へと進化します。
参考資料