WHATISAI｜第2章

レバー①文脈
── 「入れるほど良い」は嘘

ハーネスの一本目のレバーは文脈（context）。多くの人が「関連しそうな情報を、全部渡せばいい」と考えます。 これは半分正しく、半分は逆効果。なぜ「全部入れる」と精度が落ちるのか ── 仕組みから握ると、文脈は操れるレバーになります。

本文の点線の専門用語は、タップすると意味が出ます。知らない言葉だけ開けばOK。

まず、正しい半分文脈が、出力を条件づける

LLMは次の一語を確率で予測しますが、その確率は文脈全体を条件に決まります。だから、型定義・既存パターン・明確な制約を文脈に置けば、それらと食い違う出力の確率は下がる。これが「コンテキストエンジニアリング」が効く数理的な理由です。Karpathy はこう定義しました。

「すべての本格的なLLMアプリで、コンテキストエンジニアリングとは、次の一歩のために、ちょうど良い情報でコンテキストウィンドウを満たす繊細な技術と科学である。」 — Andrej Karpathy, 2025
広く使われる比喩
LLM＝CPU、コンテキストウィンドウ＝RAM。 そして、そのRAMに「何を・いつ」載せるかを決めるOSが、あなたのコンテキスト設計です。RAMは有限。だから、何を載せるかより何を載せないかが効いてくる。

そして、危うい半分コンテキストは「腐る」

RAMが有限なら、詰め込めば溢れる ── だけではありません。という、もっと厄介な性質があります。文脈を増やすほど、一つひとつの情報への注目が薄まり、肝心の指示が"ノイズに埋もれる"のです。

触って確かめる：文脈は「増やすほど」良くはならない文脈に積むトークン数をスライダーで増やしてください。各列は位置ごとの注目度。赤い列が肝心の指示（中央付近）。増やすほど、全体が薄まり中間が沈む ── これがコンテキスト腐敗です。

位置ごとの注目度　肝心の指示

肝心の指示の効き：75%
肝心の指示は、しっかり効く

※ 概形デモ（実モデルの数値ではない）。実機の研究でも、長いコンテキストを持つモデルが公称容量のはるか手前から劣化し、中間位置の文書は精度が大きく落ちる（"lost in the middle"）と報告されている。注意機構の計算量がトークン数の二乗で、個々の注目が薄まるのが数理的な理由。最適化の方向は「長くする」ではなく「高信号だけ入れる」。

スライダーを右に振ると、赤い「肝心の指示」が沈んでいくのが見えたはずです。これは比喩ではなく、観測された現象 ── 200Kトークン入る最新モデルでも、で中間文書の精度が大きく落ちる、と報告されています。

仕組みを見るなぜ薄まるのか ── 注意の二乗コスト

理由は、Transformer の注意機構にあります。各トークンは、他のすべてのトークンとの関係を計算する。だからトークン数 nn に対し、関係の数は n2n^2 で増えます。

関係の数  ∝  n2(例: n=100,000  →  1010)\text{関係の数} \;\propto\; n^2 \quad(\text{例: } n=100{,}000 \;\to\; 10^{10})
この式は要するに
10万トークン入れると、100億の関係を計算することになる。そして注目度は で「合計1」に正規化される ── つまりパイは一定。関係が増えるほど、一つひとつの取り分（注目度）は薄まる。これが「腐敗」の数理的な正体です。

だから最適化の方向は、直感に反して ──

  1. 文脈は「長くする」のではなく
  2. 高信号なものだけを入れる（低信号は積極的に捨てる）
  3. 溢れる前にやセッション分割でリセットする
まず予想してみる

エージェント用の指示書（CLAUDE.md / AGENTS.md）。良い運用はどちら？

発展発展：コンテキスト腐敗の実証と、対策の数理▼ 数式が苦手な方は飛ばしてOK

① 実証（Chroma, 2025）：GPT-4.1・Claude Opus 4 を含む18モデル全てで、コンテキスト長の増加に伴う品質低下を確認。公称のウィンドウ容量よりはるか手前から劣化が始まる傾向がある。そして中間位置に置かれた情報は、精度が大きく落ちる（Liu ら2023 "lost in the middle"）。

② なぜ softmax で薄まるか：注意重みは ai=esi/∑jesja_i = e^{s_i}/\sum_j e^{s_j} で、総和が必ず1。候補（トークン）が増えるほど、各 aia_i の平均は 1/n1/n に向かって下がる。高信号トークンも、無関係トークンの海に薄められる。

③ 効く対策（Claude Code での具体）：(a) サブエージェントで隔離 ── 調査・実装・レビューを別エージェントに分け、各自が小さく高信号な文脈を持つ（第4章）。(b) /compact で圧縮 ── 長い往復を要約してコンテキストを作り直す。溢れる前に。(c) 外部化 ── 進捗・決定を CLAUDE.md やファイル（進捗ファイル・gitログ・構造化JSON）に書き出し、コンテキスト外に永続化する。これらは第4章・実践編で掘ります。

⚠ 時点依存の注記：「50Kトークンで劣化」等の閾値は、モデル改良で変わりうる（議論中）。普遍なのは「注意は二乗コストで希釈される」という構造であって、特定の数値ではない。出典: Chroma "Context Rot"、Anthropic "Effective Context Engineering"、Claude Code Best Practices。

第2章のひとこと

文脈レバーの極意は、足すことではなく
「何を捨てるか」を設計すること。

── 次にエージェントが的外れな動きをしたら、まず疑ってください。「情報が足りない」のではなく、「肝心の指示が、他の文脈に埋もれている」のかもしれない。