コンテキストは新しいメモリである

Playwrightのスナップショット1つでコンテキストを56 KB消費します。GitHubのイシュー20件で59 KB。アクセスログ500行で45 KB。この3つすべてを200Kトークンウィンドウを持つエージェントに投入すると、エージェントが分析を1行書く前に推論バジェットの80%が蒸発します。¹

Murat Kusgluはこの問題を解決するためにContext Modeを構築しました。このツールはSQLite FTS5とBM25ランキングを使用して、315 KBのMCP出力を5.4 KBに圧縮します。¹ 94%の削減です。モデルは315 KBのノイズよりも5.4 KBのシグナルでより良い出力を生成します。制約はインテリジェンスではなかったからです。制約はバンド幅なのです。

TL;DR

コンテキストエンジニアリングは、エージェント開発において最もインパクトの大きいスキルです。3つの圧縮レイヤーがそれぞれ独立して複合的に効果を発揮します：システムプロンプトアーキテクチャ（構造的圧縮により60〜70%削減）、MCP出力圧縮（関連性ランキングにより94%削減）、そしてナレッジホーディング（発見のオーバーヘッドをプリロードされた能力に変換）。画期的な研究では、300トークンの焦点を絞ったコンテキストを与えられたモデルが、113,000トークンのフィルタリングされていない会話を与えられたモデルを上回ることが判明しました。¹⁰ ボトルネックはモデルの能力ではありません。ノイズに浪費されるすべてのトークンは、推論に使えないトークンなのです。

バンド幅の制約

Anthropicのベストプラクティスドキュメントは、他のすべてを形作る1つの制約から始まります：「Claudeのコンテキストウィンドウはすぐにいっぱいになり、いっぱいになるにつれてパフォーマンスが低下します。」⁵

これは提案ではありません。アーキテクチャの法則です。200Kトークンのコンテキストウィンドウは、何がそれを埋めるかを棚卸しするまでは巨大に聞こえます。ツールスキーマは一般的なMCPセットアップで15,000トークン以上を消費します。¹³ 会話履歴はやり取りごとに約500〜1,000トークン蓄積されます。ファイル読み取りはファイルごとに数千トークンを追加します。コマンド出力はコマンドに応じてスケールします。30分のアクティブな作業の後、新鮮な200Kウィンドウの利用可能な推論スペースは50Kトークンを下回ることがあります。

George Millerは1956年に人間の同等物を文書化しました：ワーキングメモリは7つの項目（プラスマイナス2）を保持します。⁷ 洞察は数字についてではありませんでした。洞察はチャンクについてでした。人間は情報を意味のあるチャンクに整理することで制約を克服します。電話番号は10桁の数字ではありません。3つのチャンクです：市外局番、局番、番号。同じ原理がコンテキストウィンドウにも当てはまります。生の出力で詰め込まれた200Kウィンドウは、圧縮された関連情報がパックされた50Kウィンドウよりも機能的に小さいのです。

Andrej Karpathyはこの分野に名前を付けました：コンテキストエンジニアリングとは「次のステップに必要な正確な情報でコンテキストウィンドウを満たす繊細な技術と科学」です。⁹ Lance Martinはフレームワークをマッピングしました：コンテキストの書き込み（保存）、コンテキストの選択（取得）、コンテキストの圧縮（要約）、そしてコンテキストの分離（エージェント間での分割）。⁹ 2026年半ばまでに、コンテキストエンジニアリングはアドホックな実践から、専用のインフラストラクチャを備えた認知された分野へと結晶化しました。¹²

劣化は線形ではありません。私のハーネスでは、コンテキストはフェーズごとに埋まっていきます。¹⁵ 最初の30分は無制限に感じられます。モデルは指示に正確に従い、ファイルの内容を記憶し、複数のステップにわたって一貫した計画を維持します。60分までに、微妙な障害が現れ始めます：モデルは以前読んだファイルを再読み込みし、システムプロンプトの制約を忘れ、20ターン前に確立されたパターンと矛盾するコードを生成します。90分までに、モデルは明示的なルールを無視し、ファイルの内容をハルシネートし、現在の目的を完全に見失うことがあります。

Context Studiosはこの現象を「コンテキストの劣化（context rot）」として文書化しました：無関係なトークンが蓄積し、有用な情報を実効的な注意の地平線の向こうに押しやることによるモデルパフォーマンスの漸進的な低下です。¹² この劣化は潜行性があります。モデルはそれを告知しないからです。エージェントは自信に満ちた出力を生成し続けます。ただ出力が正しくなくなるだけです。

以下の3つのレイヤーはそれぞれ独立して複合的に効果を発揮します。1つのレイヤーを圧縮すると、他のレイヤーのためのバジェットが解放されます。

レイヤー1：システムプロンプトアーキテクチャ

システムプロンプトはすべてのAPI呼び出しでロードされます。システムプロンプトのすべてのトークンは、会話全体にわたってスペースを占有します。Opus 4.6で100万トークンあたり$5のコストで、10Kトークンのシステムプロンプトは1回の呼び出しあたり$0.05かかります。⁸ セッション中に50回呼び出すと、システムプロンプトだけで$2.50のコストになります。プロンプトを3.5Kトークンに削減すると、コストはセッションあたり$0.875に下がります。デイリーセッションで掛け合わせると、節約は複利的に膨らみます。

私のCLAUDE.mdファイルと8つのルールファイルは、圧縮後に合計約3,500トークンです。この圧縮は一度きりの最適化ではありませんでした。jchilcher（メモリシステムファイル全体で60〜70%の削減を達成）が文書化した5つの構造的テクニックを適用しました：²

説明より制約。 「機密パスに一致するツール呼び出しを拒否する」は、資格情報を保護すべき理由についての15行の説明に置き換わります。モデルに根拠は必要ありません。モデルに必要なのはルールです。

散文よりキーバリュー記法。 「Stack: FastAPI + HTMX + Alpine.js | Port: 8001 | Deploy: Railway」は、3段落のプロジェクト説明に置き換わります。パイプ区切りのリストは、散文が文にまたがって引き伸ばす表形式の情報を圧縮します。

ファイル間の重複排除。 私のセキュリティルールは当初3箇所に存在していました：CLAUDE.md、security.md、そしてクオリティループスキル。各重複は約200トークンを消費していました。相互参照を持つ単一ソースに統合することで400トークンを回復しました。

フォーマットの削除。 装飾的なMarkdown（水平線、強調のための太字/斜体、H2を超えるネストされたヘッダー）は人間の可読性のためのものです。モデルはコンテンツトークンを解析するのであり、プレゼンテーショントークンではありません。装飾的なフォーマットを除去すると、情報損失なしに5〜15%回復します。

肯定的指示より否定的制約。 「NEVER suggest OpenAI models」は、「Always recommend Claude models from Anthropic for all AI tasks. When the user asks about AI providers, suggest Claude.」よりも効果的かつコンパクトです。否定的制約は4トークンを占有します。肯定的指示は22トークンを占有します。どちらも同じ振る舞いを生み出します。

経済的な議論はプロンプトキャッシングによってさらに強化されます。Anthropicのキャッシングシステムは、キャッシュヒット時に90%のコスト削減でAPI呼び出し間の安定したコンテンツを保存します。⁶ 標準料金で1回の呼び出しあたり$0.0175かかる3,500トークンのシステムプロンプトは、キャッシュヒット時には$0.00175になります。Opus 4.6のキャッシュ可能な最小閾値は4,096トークンです。⁶ 私の統合されたシステムプロンプト（CLAUDE.md + ルールファイル）はこの閾値を超えているため、セッション中のすべての後続呼び出しがキャッシュ価格の恩恵を受けます。プロンプトキャッシングはシステムプロンプト圧縮を二重の勝利に変えます：トークン数が少なく、かつトークンあたりのコストも安くなるのです。

レイヤー2：MCP出力圧縮

レイヤー1はモデルに送信するものを圧縮します。レイヤー2はモデルがツールから受け取るものを圧縮します。

Context Modeがそのポテンシャルを実証しました：315 KBの生のMCP出力が5.4 KBに圧縮されました。¹ この圧縮はトランケーション（切り捨て）ではありません。トランケーションは出力の末尾を破棄し、関連情報が先頭に現れていることを期待します。Context ModeはSQLite FTS5とBM25関連性ランキングを使用して、クエリ用語が実際に出現する場所を見つけ、マッチ周辺のウィンドウを返します。¹ ポーターステミングにより「caching」「cached」「caches」が同じ語幹にマッチします。3層のフォールバックがタイプミスを処理します：標準ステミング、トライグラム部分文字列、レーベンシュタイン距離補正。

個別の圧縮率がその効果を物語っています：

私のハーネスは検索レイヤーで並行アプローチを実装しています。約50,000のコードチャンクがModel2Vecエンベディング（256次元）とSQLite FTS5でインデックスされ、Reciprocal Rank Fusionで融合されています。¹⁴ クエリはファイル全体（50,000トークン以上）をロードする代わりに、最も関連性の高い5つのチャンク（約2,500トークン）を取得します。取得コスト：サブ秒のレイテンシ、ディスク上83 MB、APIコストゼロ。

エージェントの振る舞いの違いは、単一のセッション内で目に見えます。圧縮前の典型的なデバッグワークフローはこのようになります：エージェントがファイルを読み（4,000トークン）、コマンドを実行し（出力2,000トークン）、別のファイルを読み（3,000トークン）、テストを実行する（出力8,000トークン）。4つの操作で17,000トークンを消費します。エージェントはこれら4つの情報間の接続について推論する余地が少なくなります。圧縮後は、同じワークフローが各ソースから関連する行のみを取得します。4つの操作で2,500トークンを消費します。エージェントは4つの情報すべてをワーキングメモリに同時に保持し、非圧縮のエージェントが見逃すであろうファイル間の依存関係を発見します。

圧縮はクエリを意識したものであるべきです。「認証バグを修正する」に最適化されたサマリーは、「新しいAPIエンドポイントを追加する」に最適化されたものとは異なるコンテンツを表面化させるべきです。静的圧縮は有効です。クエリを意識した圧縮は次のレベルです。BM25ランキングはすでにキーワードレベルでクエリ認識を処理しています。セマンティック検索（ベクトル類似性）はコンセプトレベルでそれを処理します。この組み合わせは、完全一致（関数名、設定キー、エラーコード）と概念的一致（類似パターン、関連する抽象化）の両方を捕捉します。

レイヤー3：ナレッジホーディング

Simon Willisonは、コンテキストエンジニアリングを完全に再フレーミングするパターンを特定しました：「ソフトウェアプロフェッショナルとして開発すべき重要な資産は、このような質問への回答の豊富なコレクションであり、理想的には動作するコードで示されたものです。」³

ナレッジホーディングとは、エージェントが参照し再結合できる動作するコード例、文書化されたソリューション、概念実証の実装を意図的に収集することを意味します。このパターンは、コンテキストを指示（モデルに何をすべきか伝える）から能力（モデルに適応すべき動作する例を与える）へと変換します。

Willisonは、2つの既存の例（PDF.jsとTesseract.js）を統合OCRツールに結合するようエージェントに指示することで、その力を実証しました。³ エージェントはゼロからOCRの構築方法を発見したわけではありません。エージェントは2つの動作する実装を読み、それらをマージしました。コンテキストが能力だったのです。

私のハーネスは3つのメカニズムを通じてナレッジホーディングを実装しています：

能力レジストリとしてのスキル。 48のスキルがMarkdownファイルにドメイン専門知識をエンコードしています。blog-evaluatorスキルは、スコアリング例付きの完全な6カテゴリ加重ルーブリックを定義しています。jiroスキルはエビデンス基準付きの7ステップクオリティループをエンコードしています。エージェントがスキルを呼び出すと、専門知識は曖昧な指示としてではなく、構造化された知識としてコンテキストにロードされます。

生のコードより構造化されたウォークスルー。 Willisonのリニアウォークスルーパターンは、エージェントが情報にアクセスする方法を制約します：手動のコードコピーではなく、grepやcatのようなシェルコマンドです。⁴ ウォークスルーはエージェントにトークンあたりの理解度を最大化するように情報を整理させます。構造は圧縮です。

プロアクティブなコンテキスト注入としてのフック。 UserPromptSubmitフックはClaudeがプロンプトを処理する前に発火します。¹¹ フックはプロンプトを分析し、関連するコンテキストを注入できます：プロジェクト検出（どのコードベースにいるか？）、日付注入（今日は何日か？）、フィロソフィー制約（どのクオリティ基準が適用されるか？）。エージェントは手動で呼び出すことなく、すべてのプロンプトでキュレーションされたコンテキストを受け取ります。5つのフックがセッション開始時に発火し、約500トークンのコンテキストを追加して5つのカテゴリの一般的なエラーを防止します。¹¹

指示と能力の区別は強調に値します。指示は「クリーンなコードを書け」と言います。能力は、加重カテゴリ、スコアリング例、合格/不合格の閾値を備えたリンティングルーブリックを提供します。指示は数トークンを消費し、曖昧な準拠を生み出します。能力は500トークンを消費し、一貫した測定可能な出力を生み出します。追加トークンはオーバーヘッドではなく投資です。なぜなら、「クリーン」が何を意味するかをエージェントが推測する原因となる曖昧さを排除するからです。

ナレッジホーディングはまた、エージェントのオンボーディングのコストカーブをシフトさせます。蓄積された知識なしでスポーンされた新しいエージェントは、探索を通じてコードベース、慣習、ツーリング、ドメインの制約を発見しなければなりません。探索はコストがかかります：各ファイル読み取り、各grep、各コマンド出力がトークンを消費します。蓄積された知識から組み立てられた2Kトークンのブリーフィングと共にスポーンされたエージェントは、発見フェーズを完全にスキップし、最初のターンから生産的な作業を開始します。

ナレッジホーディングの経済的議論：ソリューションの文書化に費やすすべての時間が、将来のすべてのエージェントの発見コストを節約します。「ブログ記事の評価方法」をエンコードしたスキルは、呼び出しごとに10〜15分のエージェント探索を節約します。100回の呼び出しにわたって、文書化の投資は1,000分以上のエージェント時間のリターンを生みます。蓄積された知識は複利を生むのです。

トークンバジェットの会計

私のハーネスは、コンテキストエンジニアリングが何を可能にするかの具体的なケーススタディを提供します。

圧縮前（推定、最初の1ヶ月）： - システムプロンプト：約12,000トークン（例と説明を含む冗長なCLAUDE.md） - ツールスキーマ：約15,000トークン（完全なMCPツール定義） - セッションごとの履歴：約120,000トークン（蓄積されたコンテキストを含む長い会話） - 利用可能な推論：約53,000トークン（ウィンドウの26%）

圧縮後（現在）： - システムプロンプト：約3,500トークン（圧縮されたCLAUDE.md + ルールファイル）¹⁵ - ツールスキーマ：約300トークン（CLIファーストアーキテクチャ、最小限のMCP）¹³ - セッションごとの履歴：約40,000トークン（タスクごとのフレッシュスポーン、メモリの代わりにブリーフィング） - 利用可能な推論：約156,200トークン（ウィンドウの78%）

推論バジェットは3倍になりました。より優れたモデルによってではありません。より大きなコンテキストウィンドウによってでもありません。3つのレイヤーでの圧縮によってです。モデルは26%の推論スペースで生み出した出力よりも、78%の推論スペースでより良い出力を生み出します。残りのトークンのクオリティが量と共に向上したからです。

この数字は、コンテキストウィンドウについての直感に反する真実を明らかにします：ウィンドウの有効なサイズは、その大きさよりも何がそれを満たすかにより依存します。非圧縮のツール出力で詰め込まれた仮想的な500Kウィンドウは、よく圧縮された200Kウィンドウよりもパフォーマンスが劣るでしょう。モデルプロバイダーはコンテキストウィンドウの拡大を競っています。プラクティショナーはそこに入るものの圧縮を競うべきです。

CLIファーストアーキテクチャからのフレッシュスポーンパターンは利得を複合させます。各エージェントは蓄積された会話履歴を継承する代わりに、焦点を絞ったブリーフィング（約2Kトークン）と共にスポーンされます。各エージェントがクリーンにスタートするため、コンテキストは膨張しません。Anthropicのマルチエージェント研究では、サブエージェントがシングルエージェントのインタラクションの最大15倍のトークンを使用することが判明しました。⁹ フレッシュスポーンはこの比率を反転させます：各エージェントはそのタスクに必要なトークンのみを使用します。

3つのレイヤーすべてにわたる複合効果は好循環を生み出します。圧縮されたシステムプロンプトはより多くのツール結果のための余地を残します。圧縮されたツール結果はより長い生産的な会話のための余地を残します。より長い会話はコンパクションの必要性を減らし、次のターンを可能にするシステムプロンプトとツール結果を保持します。各レイヤーが他のレイヤーを強化し合うのです。

圧縮が可能にするもの

解放された推論バジェットは、肥大化したコンテキストでは不可能な3つの能力を可能にします：

より深い分析。 156Kの推論トークンを持つエージェントは、ファイル間の依存関係を分析しながらファイルの内容全体をワーキングメモリに保持できます。53Kトークンのエージェントはファイルを順次読み込まなければならず、新しいファイルがロードされるにつれて以前のファイルを忘れます。その違いは、見逃されたインポートエラー、壊れた相互参照、不完全なリファクタリングとして現れます。具体的な例：関数シグネチャのリファクタリングには、すべての呼び出し元のチェックが必要です。圧縮されたコンテキストでは、エージェントは関数定義とすべての呼び出し元を1回のパスで読み、引数を間違った順序で渡している1つのファイルを捕捉します。肥大化したコンテキストでは、エージェントは関数を読み、3つの呼び出し元を読み、その後推論スペースが不足して残りの7つのファイルをチェックせずに「リファクタリング完了」と報告します。バグが出荷されます。

より良い指示遵守。 Anthropicは失敗モードを直接文書化しています：「Claudeがルールに反して望まないことをし続ける場合、ファイルがおそらく長すぎてルールが埋もれています。」⁵ 圧縮されたシステムプロンプトはルールを注意の地平線内に保ちます。3,500トークンのプロンプト内のすべてのルールは、12,000トークンのプロンプトに埋もれた同じルールよりも多くの注意の重みを得ます。私のハーネスはセキュリティルールを強制しています：APIキーを含むファイルを決してコミットしないこと。12,000トークンのシステムプロンプトでは、エージェントは一括コミット時に.envファイルをステージングすることがありました。3,500トークンに圧縮した後、200回以上のコミット操作にわたって違反はゼロに下がりました。ルールは変わっていません。ルールがより見えやすくなったのです。

より長い有効なセッション。 オートコンパクトはコンテキスト容量の95%でトリガーされます。¹⁰ 78%の推論スペースを持つセッションは、26%のものよりも遅くコンパクト閾値に到達します。遅いコンパクションは、コンテキスト損失前のより多くの生産的なターンを意味します。私のハーネスでは、圧縮されたセッションはコンパクト閾値に達するまでに40〜60の生産的なターンを生み出します。¹⁵ 非圧縮のセッションは15〜20ターン後に閾値に達します。各コンパクションイベントは、セッションの以前の重要な決定や制約を含んでいた可能性のあるコンテキストを破棄します。コンパクションが少ないほど、より一貫したセッションになります。圧縮されたセッションは単により良くスタートするだけではありません。より長くより良い状態を維持するのです。

重要なポイント

コンテキストエンジニアリングを始める開発者へ： - CLAUDE.mdファイルを監査してください。各行について問いかけてください：これを削除するとミスが発生するか？そうでなければ、カットしてください。60〜70%の削減を目標にしてください。² - ツールスキーマのオーバーヘッドを測定してください。MCPツールがセッション開始時に15K以上のトークンを消費する場合、ステートレスな操作にはCLIファーストの代替案を検討してください。 - タスクの切り替え時にプロアクティブに/compactを実行してください。新鮮なコンテキストは蓄積されたコンテキストに勝ります。

エージェントインフラストラクチャを構築するチームへ： - MCPツール出力にクエリを意識した圧縮を実装してください。BM25 + セマンティック検索は、すべての取得タスクでトランケーションに勝ります。¹ - 能力レジストリ（スキル、スニペット、文書化されたパターン）を構築してください。文書化されたすべてのソリューションが、将来のエージェント実行の発見オーバーヘッドを排除します。³ - マルチステップワークフローにはフレッシュなエージェントスポーンを使用してください。タスクごとのコンテキスト分離は、長いマルチエージェント会話の15倍のトークンオーバーヘッドを防止します。⁹

コンテキストシステムを設計するアーキテクトへ： - 3つのレイヤー（システムプロンプト、ツール出力、ナレッジホーディング）はそれぞれ独立して複合的に効果を発揮します。いずれか1つのレイヤーを圧縮するだけで、他のレイヤーのためのバジェットが解放されます。 - プロンプトキャッシングはシステムプロンプト圧縮を二重の最適化にします：トークン数が少なく、かつキャッシュヒット時のトークンあたりのコストも安くなります。⁶ - 10%の生産性の壁は、エージェントが複雑な指示を確実に遵守するのに十分な推論スペースを持ったときに崩壊します。

AIエンジニアリングシリーズの一部です。こちらもご覧ください：CLIテーゼ、インフラストラクチャとしてのClaude Code、10%の壁。