Context Compressionとは？ 長い文脈を「短くしても意味を失わない」ための技術

生成AIの説明で「Context Compression」という言葉を見かけたら、まず「モデルそのものを小さくする技術」ではなく、モデルに渡す文脈を短くする技術だと捉えると分かりやすくなります。長い会話履歴、検索で集めた文書、ツールの実行結果、few-shot例などをそのまま詰め込むと、入力トークンが増え、料金や待ち時間が増えるだけでなく、context windowの上限に近づきます。そこで、必要な情報を残しながら入力を小さくするのがContext Compressionです。

なぜ「長いcontext window」だけでは解決しないのか

モデルが扱えるcontext windowは拡大してきましたが、長く入れられることと、長く入れた情報を常にうまく使えることは同じではありません。入力が増えれば計算量やコストも増えますし、質問に関係の薄い情報が大量に混ざれば、重要な記述が埋もれることもあります。したがってContext Compressionの目的は、単に「上限に収める」だけではなく、モデルが見るべき情報の密度を上げることにもあります。

Microsoft ResearchのLLMLingua系列は、この考え方を具体化した代表例です。LLMLinguaでは、入力中の重要度が低いトークンを判定して削減し、LongLLMLinguaでは長文質問応答などを想定して質問に関係する情報を優先して圧縮・再配置します。ここから分かるのは、Context Compressionが「全部を短い要約に書き換える」だけの話ではないという点です。^[1][2]

要約との違い

要約はContext Compressionの一方法になり得ます。しかし両者は同義ではありません。要約は通常、人間にも読みやすい短い文章へ意味をまとめます。一方、prompt compressionでは、人間には不自然でもLLMが必要情報を解釈できる形を狙うことがあります。また、全文を要約せず、質問に関係する段落だけ残す、重複する文を落とす、低重要度トークンを削る、といった方法もあります。

この違いは実務上重要です。契約条件、数値、否定表現、例外、固有名詞、コード断片などは、自然な要約を優先すると落ちやすいことがあります。「読みやすく短くなった」ことと「下流タスクに必要な情報が保存された」ことは別の評価です。

RAGではどこを圧縮するのか

Retrieval-Augmented Generation（RAG）では、検索結果として複数の文書チャンクを取得し、それをLLMへ渡します。このとき取得結果が多すぎると、関係の薄い部分までcontextを占有します。そのためretrieval後に、質問と関係する文だけを抽出したり、複数チャンクを再構成したりするContext Compressionが使われます。

ただし、これはretrievalそのものとは違います。retrievalは「どの情報を取り出すか」を決め、compressionは「取り出した情報をどの程度・どの形でモデルへ渡すか」を調整します。検索精度が悪いまま圧縮だけ工夫しても、必要な証拠が最初から取得されていなければ回答は改善しません。

「圧縮率20倍」をどう読むか

研究や製品説明には「4x」「10x」「20x」といった圧縮率が登場します。この数字だけで品質を判断してはいけません。圧縮率は、元の入力長、データセット、モデル、タスク、評価指標によって意味が変わります。高い圧縮率を実現しても、回答精度、引用可能性、数値保持、論理関係の保持が落ちれば、目的によっては失敗です。^[3]

見るべきなのは、圧縮後に何が維持されたかです。質問応答なら正答率、要約なら重要情報の網羅、コードなら実行結果、RAGなら根拠との整合性など、下流タスクに対応した評価が必要です。

Context Compactionとの違い

似た言葉にContext Compactionがあります。現在のAIエージェント文脈では、Compactionは長く続く会話やagent loopがcontext windowを使い切らないよう、過去状態を小さな継続用状態へ畳み直す仕組みを指すことが多くなっています。これに対しContext Compressionは、単発の長いprompt、検索結果、文書集合なども含む、より広い「入力を小さくする」技法群として理解すると整理しやすいでしょう。

ただし用語はまだ完全に標準化されていません。製品や論文によってcompressionとcompactionを近い意味で使うこともあるため、名称だけで機能を決めつけず、実際に何を保存し何を捨てる処理なのかを確認する必要があります。

何を推論してはいけないか

Context Compressionを使っているからといって、情報損失がないとは限りません。圧縮処理は通常、何を重要とみなすかという判断を伴います。その判断を誤れば、質問に必要な条件や例外を削除することがあります。また、入力が短くなったからといって、モデル自体の知識が増えたり推論能力が上がったりするわけでもありません。

Context Compressionは「より少ないcontextで同じ仕事を狙う」技術です。成功かどうかは、短くなったことではなく、必要な仕事をどれだけ維持できたかで判断します。

元のニュースや製品説明へ戻ったときの確認ポイント

「Context Compression対応」と書かれていたら、何を圧縮するのか、圧縮方式は抽出・要約・token削減・query-aware選択のどれか、品質を何で評価したか、重要な数値や引用元を追跡できるかを確認してください。圧縮率だけを見ず、精度・latency・cost・context上限とのトレードオフを見ることが、実際の性能を読み違えないコツです。

実用チェックリスト

• 圧縮対象は何か
• 重要度の決め方は何か
• 下流タスク性能を圧縮前後で比較しているか
• 数値・否定・例外・引用元が保持されるか
• retrieval不足をcompressionで補っていると誤解していないか

関連するAI用語

• G172：Context Compaction
• G170：Context Engineering
• G169：Chunking
• G158：RAG

注・出典

1. Microsoft Research — LLMLingua Series — LLMLinguaはprompt compressionとして不要トークンを除き、長文入力のcost/latency/context制約を軽減する研究系列。 ↩
2. Microsoft Research — LongLLMLingua — query-aware compressionと再配置により長文contextの重要情報認識を改善する例。 ↩
3. Microsoft Research — LLMLingua paper page — 圧縮比は実験条件依存であり、性能保持を評価する必要があることの根拠。 ↩

AI協働制作について

本記事は、著者が独自に設計した指示、参照資料、出典確認規則、著作権確認および監査工程を組み込んだChatGPT等の生成AIを、情報収集の補助、資料整理、構成検討、草稿作成、文章校正および監査補助に使用して制作しました。記事の対象範囲、情報源の採否、構成、解釈および最終表現は著者が判断し、最終稿を承認しています。著者は、本記事の正確性、独自性、引用、著作権処理および公開内容について責任を負います。制作工程の詳細は「AI協働制作方針」をご覧ください。