Microsoftが「コンテキストの圧縮」を実測　1割未満のセッションがトークンの4割超

米Microsoft Researchは11月13日、研究紹介の番組「Microsoft Research Focus」の第98回を公開し、コーディングエージェントのコンテキストの圧縮を測った論文を紹介した。圧縮は、履歴がコンテキストウィンドウに収まらなくなった時に、要約で置き換えて空きを作る処理だ。

GitHub Copilotの1350万セッションのうち、圧縮が起きたのは7.8%だった。そのセッションが総トークン消費の44.2%を占め、圧縮の後はキャッシュヒット率の中央値が99.0%から27.0%に落ちる。論文はMicrosoftの研究者らが自社の製品の記録と自分たちの方式について書いたものだ。

圧縮が起きた回がトークンの4割超を使う

論文の2節と表1によると、研究チームは2026年6月のGitHub Copilotのエージェントの記録を調べた。対象は320万人の1350万セッションで、LLMの呼び出しは7.6億回にのぼる。圧縮が起きたのは7.8%のセッションで、それらが総トークン消費の44.2%を占めた。

番組のページは同じ結果を「8%未満」「44%」と丸め、「total AI processing costs」と書く。論文の言い方はトークンの消費量で、金額ではない。

圧縮はプロンプトを大きく削り、キャッシュも崩す。論文の1節と2節によると、1回の圧縮でプロンプトは中央値で72.9%縮む。キャッシュヒット率の中央値は圧縮の前の99.0%から後の27.0%に落ち、圧縮にかかる時間はターンの実行時間の中央値で約22%を占めた（図1）。

対策としてチームは「APEC」を示した。履歴を区間ごとに裏で要約し、前の要約を書き換えずに後ろへ足していく。先頭の部分が変わらないので、次の呼び出しでもキャッシュが効く。

5.2節と表3では、APECの正答率は77.95%で、枠の90%で圧縮する従来の方式（Sync-H）より8.66ポイント高かった。総コストはSync-Hより25.3%低く、要旨と番組のページは「最大25.4%」と書く。

圧縮の直後のキャッシュヒット率は、履歴を丸ごと要約し直す方式の7.39〜8.96%に対し、APECは31.28%だった（5.2節と図5）。別のモデルGPT-5.4でも正答率は同様に上がったと、5.3節と表4は書く。

本番の記録と自作の課題で測った

本番の数字は、Visual StudioとVS CodeのGitHub Copilotのエージェントの記録から取った。記録にあるのは時刻、所要時間、モデル名、トークン数、キャッシュヒット率などだ。どのモデルが何割を占めたかは資料に記載がない。

方式の比べ合いには、新しいベンチマーク「CompactionBench」を使った。チームが10以上の既存のコーディングのベンチマークを調べると、圧縮がほとんど起きなかったからだ。CompactionBenchは4つのリポジトリの8つの版上げを、変更履歴の315項目に分け、同じセッションで順に頼む。採点は各リポジトリのテストで行う（付録A）。

主な評価のハーネスはOpenClaudeで、モデルはGPT-5.6 Sol、effort（推論の深さ）はextra-highだ。コンテキストウィンドウは40万トークンで、各方式を5回ずつ回した。圧縮は、40万から出力の枠12.8万を引いた量の90%か50%に達した時に始まる（5.1節）。

本番の分布の全部は写さない

論文は付録A.1で、CompactionBenchが本番のトークン、ツール、セッションの長さの分布のすべてに一致するとは主張しないと書く。狙うのは、依頼が続いて履歴が伸び、圧縮で空きを作ってまた伸びるという、圧縮が起きるセッションの振る舞いの再現だという。

ベンチマークの寿命にも留保を付けた。5.3節によると、100万トークンの枠でも重い課題では圧縮が起きた。だがモデルの枠が伸びれば、圧縮を起こすにはもっと長く重い課題に作り直す必要があるかもしれないと論文は書く。

論文は査読前のプレプリントだ。著者8人のうち6人がMicrosoftの所属で、残る2人は米イリノイ大学の所属である。番組もMicrosoft Researchが作った。第三者による再現と、APECのコードの公開先、製品に入れたかは資料に記載がない。

自分の仕事で試すなら

試す手順は、論文の測り方を小さくすればよい。まず手元のエージェントの記録から、圧縮が起きたセッションの数と、そのセッションが使ったトークンの割合を出す。論文の7.8%と44.2%が比べる相手になる。

次に、圧縮の直前と直後の呼び出しで、キャッシュヒット率を比べる。論文の本番の中央値は99.0%から27.0%だった。下がり幅が同じくらい大きいなら、圧縮の後に呼び出しの先頭の再計算が増えていると読める。トークンの割合は上の割合で別に確かめる。

設定を変えて比べる時は、圧縮を始める点と要約の量を変え、正答率と総コストと時間を並べる。論文は圧縮を始める点を枠の90%と50%で比べ、要約の上限と残す履歴の量も変えて試した（5.1節と5.3節）。課題には、同じリポジトリに依頼を順に足していく形を選ぶ。既存のコーディングのベンチマークでは圧縮がほぼ起きないと、論文の3節が示している。

編集部の見方

編集部は、圧縮をたまに起きる例外ではなく、長いセッションのトークン消費の中心として扱うべきだと見る。圧縮が起きた1割弱のセッションに総トークンの4割超が集まり、直後にキャッシュヒット率も大きく落ちるからだ。長く回すエージェントの費用を見直す時は、モデルの単価より先に、圧縮の回数とその前後のキャッシュヒット率を自分の記録で出したい。数字は1社の製品の記録と自作のベンチマークに基づくので、他のハーネスで割合が大きく違えば、この見方は改める。