03. 長文脈と effective context window

LLM を使った開発でよく話題になるのが、

「コンテキストウィンドウが ○○ 万トークン！」
「でも実際にはそんなにちゃんと覚えてくれなくない？」

というギャップです。

このノートでは、Claude Code のような長文脈対応エージェントが「なぜ大量の情報をそれなりに扱えるのか」 を、以下の観点から整理します。

max context window と effective context window の違い
ポジショナル埋め込み（Positional Embedding） とその限界
RoPE 系のアイデア を含む長文脈向けの拡張
Attention の計算量削減 とトークン効率化
チャンク分割＋要約 による階層的なコンテキスト管理

⚠ 注意
ここで述べる内容は、一般的な LLM の設計と公開情報をベースにした整理＋推測 です。
Anthropic（Claude）の内部実装は非公開であり、「こういう系統の工夫をしているはず」というレベルで読んでください。

🎯 この記事のゴール

max context と effective context の違いを、感覚ではなく言語化して理解する
なぜ「長いプロンプトでもそれなりに意味を保てる」のか、その構造をイメージできる
ポジショナル埋め込み・Attention・チャンク圧縮の役割を整理しておく
Claude Code の「長くても破綻しにくい感じ」を自分の言葉で説明できるようになる

🧩 max context window と effective context window

max context window とは？

モデルに「物理的に」入力できるトークンの最大長です。

例: 200k tokens、100万トークン など
これは 「バッファの大きさ」 の話でしかない
この数字が大きいほど、とりあえず突っ込める情報量は増える

effective context window とは？

一方で、

実際にモデルが意味を保持して、
推論にちゃんと使える「実質的な範囲」

を effective context window と呼びます。

max が 200k でも、
実際には 最後の数万トークンしかまともに効いていない こともある
真ん中あたりの情報が抜け落ちる lost-in-the-middle 問題もここに関係

イメージ図

graph LR
    A["コンテキスト全体
    （200k tokens）"] --> B["先頭付近
    覚えている"]
    A --> C["中央付近
    薄れている / 抜けがち"]
    A --> D["末尾付近
    よく効く"]

    classDef strong fill:#DCFCE7,stroke:#16A34A,color:#052E16;
    classDef weak   fill:#FEE2E2,stroke:#DC2626,color:#7F1D1D;

    class B,D strong;
    class C weak;

🧠 ポジショナル埋め込み（Positional Embedding）とは何か？

LLM は「単語の順番」を理解できないと意味を解釈できません。
そのため、各トークンに “位置情報” をベクトルとして付与する仕組み が必要になります。
これが ポジショナル埋め込み（Positional Embedding） です。

たとえば：

「犬が人を噛んだ」
「人が犬を噛んだ」

単語の並びが違うだけで意味は全く異なる。
この “並び（順序）” をモデルが扱えるようにするのがポジショナル埋め込み。

🔤 ポジショナル埋め込みの一般的な方式

LLM が「位置」を表現する方法にはいくつか代表例があります。

1. Learned Positional Embedding（学習された埋め込み）

各位置に対応するベクトルを 学習時に獲得 する方式
例:
- pos=1 → (v1, v2, v3, …)
- pos=2 → (w1, w2, w3, …)

メリット

柔軟で性能が高い

デメリット

学習時より長い位置を扱うのが苦手
長文脈では「後ろの方の位置」が破綻しやすい

2. Sinusoidal Positional Embedding（正弦波ベース）

Transformer 論文で採用された方式
位置 n に対して sin(n / 10000^{2i/d}) といった正弦波を組み合わせてベクトル化する

メリット

数式に基づくため、理論上は無限長の位置でも埋め込み可能

デメリット

離れた位置どうしの関係性が弱まりやすい
長文脈では性能が急落しやすい

⚠️ 従来方式の共通の限界

どちらの方式にも共通して以下の課題があります：

学習時より長い位置を与えると性能が急激に落ちる
位置が離れすぎると「距離感」をうまく表現できない
long context（10万〜100万トークン）の扱いに向いていない

この限界を克服するために登場したのが、次に説明する RoPE（Rotary Positional Embedding）系の発想 です。

🌀 RoPE（Rotary Positional Embedding）系の発想

⚠ Anthropic（Claude）が RoPE をそのまま採用しているわけではありません。
ただし 多くの長文脈モデルが RoPE または類似の拡張方式を採用している のは事実です。

RoPE のコアアイデアは：

「位置情報そのものではなく、位置を “回転（rotary）” として表現する」

という特殊な方式。

🔍 ざっくりしたイメージ

トークンが 1 つ進むごとに、ベクトルに「一定の角度の回転」が加わる
ベクトルの相対角度が「位置関係」を表現する
これにより、相対距離 を捉えやすくなる

結果として：

学習時以上の長距離でも破綻しにくい
離れた位置のトークンどうしの関係も維持されやすい
長文脈の扱いが改善される

🔍 Attention（単語どうしを見比べる計算）も重要

ポジショナル埋め込みだけでなく、
Attention の計算そのものを効率化する工夫も必要 です。

なぜ Attention は重いのか？

Self-Attention は：

「すべてのトークンと、すべてのトークンを見比べる」

という処理で、計算量は O(n²)。

例：

10k トークン → 100M 比較
100k トークン → 10^10 比較（現実的に不可能）

最適化の例（一般的な手法）

ローカルアテンション：近くのトークンを優先して見る
重要トークンの強調
チャンク分割 と 粗い／細かいの二段階処理
MQA（Multi-Query Attention）：Key/Value を共有してメモリ削減
KV Cache：過去の計算結果を再利用

こうした工夫により、
effective context window（実質的に意味が理解できる範囲） が広がる。

🧱 チャンク分割＋要約による階層構造

モデリング（Attention）の工夫に加えて、
コンテキスト前処理の段階でも長文最適化が行われます。

代表例：

長文を チャンクに分割
各チャンクを要約
要約同士でさらに推論
必要なチャンクだけを再参照

要するに：

“全部を細かく見る” のではなく
“まず粗く、必要なところだけ細かく見る”

という階層構造で処理する。

Claude Code のようなエージェントではさらに：

thinking block → 次ターンで削除
履歴 → 要約して圧縮
MCP → 必要な情報だけを取りに行く

という 複数レイヤーでのコンテキスト圧縮 が加わります。

🧵 全体像：長文脈処理は “単一の技術” ではなく多層構造

長文を扱う性能は「モデル本体のサイズ」では決まりません。
次のような複数レイヤーの総合力です：

graph TD
    A["【アプリ層（Claude Code）】
    thinking block削除 /
    履歴圧縮 / MCP"] --> B["【前処理層】
    チャンク分割 / 要約 /検索"]
    B --> C["【モデル層】
    RoPE系 / Attention最適化 /
    KV Cache / MQA"]
    C --> D["【ハードウェア層
    GPU / メモリ / キャッシュ"]

    classDef app fill:#EEF2FF,stroke:#4F46E5,color:#111827;
    classDef prep fill:#ECFEFF,stroke:#06B6D4,color:#0F172A;
    classDef model fill:#ECFDF5,stroke:#16A34A,color:#052E16;
    classDef hw fill:#F9FAFB,stroke:#9CA3AF,color:#111827;

    class A app;
    class B prep;
    class C model;
    class D hw;

📌 まとめ：long context が「実用になる」理由

長文脈が実務で使えるレベルになった理由は、単一の技術ではなく複数レイヤーの総合力によるものです。

🔧 1. モデル（LLM）側の改良

RoPE 系の位置表現
→ 相対的な位置関係を扱えるため長文でも破綻しにくい
Attention の最適化
→ ローカルアテンション・重要度制御などで O(n²) の爆発を抑制
MQA / KV Cache
→ Key/Value 共有＋キャッシュで計算とメモリを大幅削減

🧱 2. チャンク＋要約による階層的処理

いきなり全文を処理しない
→ 長文はチャンクに分割
必要なチャンクだけ精読
→ 要約 → 再検索 → 再要約の階層構造で情報を効率化

🤖 3. エージェント層（Claude Code）の工夫

thinking block を削除
→ 推論過程の大量トークンを次ターンで完全除去
履歴の圧縮
→ “結論だけ” を保持し続け長期タスクでも破綻しにくい
MCP で必要な情報だけ取得
→ ファイル全文を渡さず、最低限の情報だけ LLM に与える

🎯 結論

これらの “多層構造” が組み合わさることで、

コンテキストが長くても破綻しにくい
記憶の劣化がゆっくりになる
実務レベルでの長文脈タスクが安定して運用可能

という 実用的な long context 処理 が成立しています。