なぜAIエージェントの「コンテキスト要約」を信じてはいけないのか？情報蒸発の罠

はじめに：「要約すれば無限に動く」という甘い神話

自律型AIエージェントを長期タスク（バグ調査、機能追加、大規模リファクタリングなど）で走らせる際、開発者が必ず直面するのがコンテキストウィンドウのトークン枯渇問題です。

現代のLLMは128kや1Mといった長大なコンテキストを受け入れられるようになりましたが、それでも推論コストの高騰、レスポンス遅延、そして長文入力に伴うアテンションの希釈（Attention Dilution）は避けられません。そこで多くのエージェントフレームワーク（LangChainの ConversationSummaryMemory や各種自律型コーディングツールの Auto-Compaction 機能）が提示するのが、次のような処方箋です。

「会話が長くなってきたら、過去のターンをLLM自身に自然言語で要約させ、コンテキストをコンパクトに圧縮してセッションを延命すればよい」

一見すると極めて理にかなった美しいアイデアに思えます。「人間も過去の細かい会話は忘れて要約で覚えているのだから、AIも同じように要約すれば無限に作業を続けられるはずだ」と。しかし、この甘い誘惑を信じてコード生成エージェントの本番運用に「コンテキスト要約」を組み込んだ瞬間、次のような不可解な怪奇現象が多発することになります。

ゾンビ試行の再発: 30分前に「このビルドフラグを使うと環境非互換でパニックする」と実証して棄却したはずのアプローチを、要約を挟んだ直後にまったく同じ手順で再び実行し始める。
型シグネチャの劣化と幻覚: 厳密に定義されていたはずの型定義や引数の境界条件が忘れ去られ、雑なプリミティブ型や存在しないプロパティにアクセスするコードを生成する。
偽の前提の定着: 過去の単なる仮説や失敗した推論が、要約文のニュアンスのブレによって「確定した仕様」として固定化され、エージェントが架空の前提に基づいた修正を強行する。

なぜ、会話の要約を挟んだだけでエージェントの知能はここまで急激に劣化するのでしょうか？それは、自然言語サマライザーの基本特性と、ソフトウェアエンジニアリングが要求する情報特性の間に、決して埋めることのできない構造的断絶（情報蒸発：Information Evaporation）が存在するからです。

情報蒸発（Information Evaporation）の解剖学：LLMは何を削ぎ落とすのか

LLMに会話ログを要約させると、人間向けには「これまでの経緯が綺麗にまとまった読みやすい文章」が出力されます。しかし、「人間が読んで気持ちいい要約」と「コード生成器が推論に必要な情報セット」は完全に真逆です。LLMの要約器は、まさにエンジニアリングの命命綱である微細なコンテキストを「冗長な枝葉」と誤認して蒸発させてしまいます。

1. 「負の知識（Tried & Failed）」の不可逆的切捨

自律開発において、最も価値の高い情報は「何が動いたか」ではなく「何を試して、どのパラメータで、どう失敗したか（負の知識）」です。

例えば、エージェントがターミナルで実行した以下のような生ログがあったとします。

$ go test -tags=musl ./...
# github.com/example/service/internal/crypto
fatal error: runtime: bsdthread_register error (error 22)
[FAIL] musl build failed due to macOS dynamic linker incompatibility.
Workaround: MUST use standard CGO with -tags=darwin_arm64.

この試行錯誤ログを汎用的なサマライザーに通すと、どう要約されるでしょうか？驚くべきことに、多くのLLMサマライザーは次のような1行に圧縮してしまいます。

「環境構築において、go test を用いたビルドおよびテストの検証を実施した。」

この要約によって、-tags=musl がmacOSの動的リンカでクラッシュした事実、そして -tags=darwin_arm64 を使わなければならないという具象パラメータと回避策（Workaround）が綺麗さっぱり蒸発します。コンテキストが要約に置き換わった次のターン、エージェントは何の躊躇もなく再び go test -tags=musl を叩き、同じクラッシュを引き起こして無限ループに陥るのです。

2. 型シグネチャと暗黙的制約の平坦化

ソフトウェア開発は、1ビットの差異や1つのNull許容性、ステータスコードの境界値が全体を左右する極めて厳密な世界です。

userId は単なる string ではなく、タイムスタンプ順ソートが必須の UUIDv7 形式でなければならない。
外部決済APIは 409 Conflict を返した場合のみ Idempotency-Key の再生成を要求する。
キャッシュのTTLは 500ms 以内に収めないとスプリアス・ウェイクアップが発生する。

こうした「コードの契約（Contract）」は、自然言語の文脈要約においては「瑣末な実装詳細」として平坦化され、「ユーザーIDの採番と外部APIエラーハンドリングを設計した」といった抽象概念に丸められます。その結果、要約後のエージェントは userId: string = "user_123" のようなダミー実装を平気で出力し、システム全体の整合性を破壊します。

3. 多段要約による「ハルシネーションの沈殿（Sedimentation）」

さらに危険なのが、セッションが長引くにつれて発生する多段要約（要約されたテキストをさらに要約する連鎖）です。

情報理論における伝言ゲームと同じで、1回目の要約で生じたわずかなニュアンスの歪み（「Aの可能性も示唆された」）が、2回目の要約では「Aを前提とする方針」に変換され、3回目の要約では「ユーザーがAを強く要望した」という確定した虚構事実として沈殿・固定化されます。一度サマリーとして定着したハルシネーションは、元の生ログがコンテキストから消去されているため、エージェント自身が決して検証・反証できない不可逆の「偽の記憶」となって開発者を苦しめ続けます。

コードで比較する：ナイーブな要約プロンプト vs 現場の現実

実際に、エージェント基盤でよく使われる典型的な要約パイプラインをコードで見てみましょう。

ナイーブな要約実装の例

以下は、トークン数がしきい値を超えた際に、過去のメッセージ履歴をLLMに要約させる一般的なコードスニペットです。

// アンチパターン：会話履歴を自然言語で再帰要約するナイーブな実装
async function compactConversationHistory(
  messages: ChatMessage[],
  llm: LanguageModel
): Promise {
  const prompt = `
以下の開発セッションの対話履歴を読み、重要な決定事項、作業の進捗、
現在発生している課題を漏れなく要約してください。
不要なツール出力や詳細なログは除外し、簡潔にまとめてください。

【対話履歴】
${formatMessages(messages)}
`;

  // LLMに自然言語要約を生成させる
  const summaryText = await llm.generateText(prompt);

  // 過去ログをすべて破棄し、サマリーメッセージ1件に置き換える
  return [
    {
      role: 'system',
      content: `これまでの開発履歴の要約:\n${summaryText}`
    },
    // 最新の数ターンだけを残す
    ...messages.slice(-3)
  ];
}

このプロンプトの致命的な欠陥は、「不要なツール出力や詳細なログは除外し、簡潔にまとめてください」 という指示です。プロンプトエンジニアリングの観点では常識的な指示に見えますが、エージェント開発においては「死刑宣告」に等しい一文となります。

情報の種類	要約前の生コンテキスト	LLM要約後のテキスト（情報蒸発）
失敗したコマンド	`curl -X POST /v1/charge -H "Idempotency-Key: abc" → HTTP 422 {"code": "KEY_EXPIRED"}`	「決済APIの疎通確認を行い、レスポンスのエラー処理を検討した」（422とKEY_EXPIREDが完全消失）
型の境界条件	`type Status = 'PENDING' \| 'SETTLED' \| 'VOIDED'; // 'FAILED'は存在しない！`	「取引状態を表すStatus型を定義した」（許容値が消え、後で 'FAILED' を勝手に捏造）
ユーザーの拒絶指示	`ユーザー: 「Redisは依存関係が増えるから絶対に使わないで。SQLiteで完結させて」`	「キャッシュおよびストレージ構成について議論し、軽量な設計を目指すこととした」（Redis禁止の強い制約が曖昧化）

この表を見れば明らかなように、要約を経ることで「具体性（Concrete）」がすべて「抽象性（Abstract）」へと不可逆変換されてしまいます。コードを書く主体に必要なのは100%の具体性であり、美しく抽象化された散文ではないのです。

情報論的考察：なぜコード文脈は「非可逆圧縮」に耐えられないのか

なぜ一般的なチャットボットでは機能する要約が、プログラミングエージェントでは致命傷になるのでしょうか？その理由は、自然言語とプログラミング言語が持つ情報エントロピーの冗長性（Redundancy）の違いにあります。

人間同士の日常会話や小説などの自然言語テキストは、極めて高い冗長性を持っています。単語をいくつか削ったり同義語で置き換えたりしても、全体の意味（セマンティクス）は損なわれません。これはJPEG画像やMP3音声と同じで、「人間が知覚する大筋に影響がない高周波成分を削ぎ落とす非可逆圧縮（Lossy Compression）」が極めて有効に機能する領域です。

しかし、プログラミング言語と実行環境のやり取りは、ZIPファイルや暗号化データと同じ「冗長度ゼロ」の決定論的領域です。

関数の引数の順番が1つ入れ替われば型エラーになる。
SQLのクエリ条件で WHERE deleted_at IS NULL が1箇所抜ければ全レコードが流出する。
環境変数名が AUTH_SECRET なのか JWT_SECRET_KEY なのかの違いだけでプロセスは起動に失敗する。

ここにおいて「だいたいこんな感じの作業をした」という要約は、ZIPファイルの途中のバイト列を「だいたいこんなバイナリだった」と適当に間引くのと全く同じ行為です。非可逆圧縮をかけた瞬間、コードコンテキストは復元不能に破損し、クラッシュを引き起こすのは数学的な必然なのです。

脱・会話要約：現場がたどり着いた「構造化スナップショット＆再水和」設計

では、肥大化するコンテキストを前に、現場のエンジニアはどう立ち向かうべきなのでしょうか？

その答えは極めてシンプルです。「LLMによる自然言語要約を一切信用せず、会話履歴をセッション間で引き継がない」というアーキテクチャへの完全移行です。エージェントを「過去の記憶を引きずりながら延命する長寿プロセス」として扱うのをやめ、「タスクごとに使い捨てられるステートレスなエフェメラルワーカー」として設計し直すのです。

現場基準：自律エージェントのコンテキスト三層分離アーキテクチャ

エージェントの作業状態は「会話ログ」ではなく、ファイルシステムとGitに直接コミットされた3つの構造化ファイルにのみ永続化します。

要件・仕様の正本（Single Source of Truth）: docs/Spec.md（画面番号、API仕様、型定義）
実行状態スナップショット（State Machine）: docs/Task.md（完了フェーズ、現在地、次の依存関係）
負の知識レジストリ（Tried & Failed Ledger）: docs/Failed_Attempts.md（試行して失敗した具体策と理由）

実践：負の知識レジストリ（Tried & Failed Ledger）の実装

「失敗したアプローチを二度と繰り返させない」ための最も確実な方法は、要約させることではなく、機械可読なMarkdownテーブルとしてファイルに明示的に追記・保存することです。


# 試行失敗・禁止事項レジストリ（Tried & Failed Ledger）

| ID | 試行した手法・パラメータ | 発生したエラー / 棄却理由 | 回避策 / 正しい方針 |
|---|---|---|---|
| F-001 | `go test -tags=musl ./...` | macOSで動的リンカエラー (error 22) 発生 | `-tags=darwin_arm64` を必須指定する |
| F-002 | `POST /v1/charge` に固定Key送信 | 422: `KEY_EXPIRED` (有効期限10分超過) | リクエストごとに `UUIDv7` を新規発行 |
| F-003 | セッションストアに `ioredis` を追加 | ルール違反（外部ミドルウェア依存禁止） | SQLiteの `WALモード` + インメモリテーブルで代用 |

エージェントの「再水和（Rehydration）」プロトコル

コンテキストが一定量（例えば全体の40〜50%）に達したとき、または1つのマイルストーン（Phase）が完了したとき、エージェントは過去の会話履歴を一切保持せずにセッションを即座に破棄（Kill）します。

そして、新しいエージェントを立ち上げる際、以下の決定論的再水和プロンプトを注入して最小限のクリーンなコンテキストを再構築します。

# 新規エージェント起動時の再水和プロンプト（Rehydration）

あなたは新規に起動されたシニアエンジニアエージェントです。
過去の会話履歴は一切存在しません。現在のプロジェクト状態をファイルから直接読み取ってください。

【必須ロード順序】
1. `docs/Spec.md`: システムの要件と型定義（Single Source of Truth）を確認せよ。
2. `docs/Task.md`: 現在の進捗フェーズと、次に着手すべき「単一のタスク」を確認せよ。
3. `docs/Failed_Attempts.md`: 過去に試行して失敗した手法のリストを読み込み、これらと同じアプローチを絶対に繰り返すな。
4. Git最新コミット: 直前の差分を確認し、コードベースの最新状態から作業を再開せよ。

推測による実装を禁ずる。曖昧な点は必ずユーザーに二者択一の質問を行え。

比較項目	自然言語要約（Compaction）	構造化スナップショット＆再水和
状態の保持場所	LLMの揮発性メモリ（サマリー文字列）	リポジトリの実ファイル（Git / Markdown）
情報の欠損率	極めて高い（負の知識・型情報が蒸発）	ゼロ（決定論的に明記された情報のみ伝達）
ゾンビ試行の再発	頻繁に発生（同じ失敗を繰り返す）	構造的に根絶（失敗テーブルで即時ブロック）
コンテキスト効率	要約文＋最新数ターンで肥大化継続	常に最小限（タスク直結のファイルのみ展開）

この再水和アーキテクチャを導入すると、エージェントはどれだけタスクが長引いても「常にセッション1ターン目の研ぎ澄まされた集中力と推論精度」を維持したまま、着実にタスクを1つずつ片付けていくことが可能になります。過去の膨大なゴミトークンを引きずらないため、API呼び出しコストも大幅に削減されます。

まとめ：エージェントの知性は「記憶の長さ」ではなく「忘却と再構成の規律」に宿る

人間は過去の経験をぼんやりとした「要約」として記憶し、直感で補完しながら会話することができます。しかし、その人間の特性をAIエージェントにそのまま模倣させようとすることは、工学的な誤謬（ごびゅう）です。

自然言語要約は不可逆な情報破壊である: エンジニアリングに必要な型、パラメータ、負の知識はサマライザーによって真っ先に蒸発する。
状態をプロンプトの中に閉じ込めるな: 会話履歴に頼らず、すべての決定と現在地を Spec.md や Task.md などの永続ファイルへ外部化する。
失敗をテーブル化せよ: 試行錯誤の歴史は「負の知識レジストリ」として構造化し、新セッションに強制ロードさせる。
エージェントを使い捨てろ（Ephemeral Worker）: コンテキストが汚れる前にセッションを破棄し、クリーンな状態でスナップショットから再水和する。

AIエージェントの真の信頼性は、「いかに多くの会話を長く記憶し続けられるか」ではなく、「いかに不要な会話を綺麗さっぱり忘れ、Gitとドキュメントという絶対の正本から決定論的に現在の立ち位置を再構築できるか」という規律（Protocol）の上にのみ成立します。甘い要約の幻想を捨て、状態をファイルに固定すること——それこそが、自律開発パイプラインを泥沼のループから救い出す唯一の道なのです。