Skip to Content
Docs02. 設計コンテキストの圧縮と隔離
上級context-engineeringmemorymulti-agent更新: 2026-09-10この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

コンテキストの圧縮と隔離

この記事の目的

長時間・長対話でコンテキストが増え続け・汚染されていく問題に対する 2 大手段 — 圧縮(compaction)(履歴をまとめて容量を空ける)と隔離(isolation)(そもそも増やさない・混ぜない)— を設計できるようになります。メモリと状態管理が示す圧縮の基本手法の先にある、トリガ設計・失敗モード・サブエージェントによる分離までを扱います。

対象読者

  • 数十ステップ〜数時間動く Agent で、コンテキストの肥大・汚染に対処するエンジニア
  • 「会話が長くなると同じ議論をループする / 過去の決定と矛盾する」問題に直面しているエンジニア

前提知識

本文

概要: 増やさない・まとめる・混ぜない

コンテキストが健全さを失う原因は 2 つです — 量(増え続けてコスト増・希釈・上限到達)と汚染(古い決定・無関係な脱線・信頼できない内容が判断を狂わせる)。これに対する手段も 2 つに整理できます。

コンテキストの圧縮と隔離: 概要: 増やさない・まとめる・混ぜないの図コンテキストの圧縮と隔離: 概要: 増やさない・まとめる・混ぜないの図
コンテキストの圧縮と隔離: 概要: 増やさない・まとめる・混ぜないの図
図を元の大きさで表示

図の中をスクロールして読めます。キーボードでは図の領域へ Tab で移動し、矢印キーを使います。読み終わったら、この見出しをもう一度選ぶと閉じます。

コンテキストの圧縮と隔離: 概要: 増やさない・まとめる・混ぜないの図コンテキストの圧縮と隔離: 概要: 増やさない・まとめる・混ぜないの図

圧縮が「溜まったものをまとめる」事後策なのに対し、隔離・外部化は「そもそも 1 つのコンテキストに溜め込まない」事前策です。長いタスクほど、事後の圧縮に頼りきらず事前の設計で量と汚染を抑えるのが要点になります。

圧縮のトリガ: いつ実行するか

圧縮を「上限にぶつかったら自動で」任せると、最悪のタイミング(重要な作業の途中)で損失圧縮が起き、直後の品質が落ちます。トリガは設計対象です。

残すものと落とすもの

圧縮は損失圧縮です。メモリと状態管理が説く「圧縮後も必ず残す情報のリスト」を、実務の粒度まで具体化します。

必ず残す落としてよい
ユーザーが指定した制約・要件途中の試行錯誤の生ログ
すでに下した決定と、その理由冗長なツール出力(要点だけ残す)
未解決の課題・保留事項解決済みの脇道の議論
外部成果物への参照(ファイルパス・ID)成果物の全文(参照に置換)
現在の計画・進捗一般的な前置き・確認の往復

要点は、「決定」と「決定に至った試行錯誤」を区別することです。試行錯誤の生ログは落としてよいですが、決定そのものと理由を落とすと、後で同じ議論を蒸し返します(後述の失敗モード)。要約プロンプトには、この「残すリスト」を明示的に埋め込みテキストや画像を、意味的な近さが距離に対応する数値ベクトルに変換したもの。RAG・記憶・分類の土台で、「何が近いか」はモデルで変わるため自社データで評価して選ぶ。モデル変更は全チャンクの再インデックスを伴う。ます。

段階的圧縮と要約の階層化

一度に全履歴を 1 つの要約に潰すと、古い決定ほど細部が失われます。より頑健なのは階層化です。

外部化という第三の道

圧縮の前に、そもそも履歴に溜めない選択があります。作業状態を構造化して履歴の外に持つと、コンテキストは「作業の生ログ」ではなく「現在の状態への参照」で済みます(メモリと状態管理の作業状態層)。

  • タスクリスト・計画: 進捗を構造化データ(やること・完了・保留)として外部に持ち、コンテキストには現在地だけを載せる
  • メモファイル・スクラッチパッド: 決定事項・調査結果を Agent 自身が書き出すファイルに残し、必要時に読み返す。長い探索で「さっき調べたことを忘れる」を防ぎます
  • 成果物の外部化: 大きな生成物(コード・ドキュメント)はファイル・DB に置き、履歴には参照(パス・ID)だけ残す

外部化は圧縮より情報損失が小さく(捨てるのでなく移すため)、中断・再開や外部監視とも相性が良い一方、参照を辿る手段(読み出しツール)と、状態を最新に保つ規律が要ります。

隔離とサブエージェント: コンテキストを分けて汚染を防ぐ

もう 1 つの手段が隔離です。ここでの隔離は「性能を上げるためのマルチエージェント複数の Agent ループが、それぞれ独立したコンテキストを持って分担・協調する構成。」ではなく、コンテキストを分離すること自体を目的とした委譲を指します(マルチエージェントの一般論は シングルエージェントとマルチエージェント・オーケストレーションパターンが正本)。

  • 探索の隔離: 大量の中間出力を生む調査(多数の検索・ファイル読み)をサブエージェントに委譲し、結果の要点だけを親に返す。親のコンテキストは探索の生ログで汚れず、要点だけが残ります。長い調査ほど効果が大きい定番パターンです
  • 関心の分離: 独立に進められるサブタスクを別コンテキストに分けると、互いのノイズが混ざりません(シングルエージェントとマルチエージェントの「コンテキスト分離が効く理由」の実践)
  • 信頼境界としての隔離: 信頼できないコンテンツ(Web ページ・受信メール・共有文書)の処理を低権限の子に分けると、そこで直接使える権限を制限できます。ただし要約にも攻撃者の指示は残りえます。コンテキストを分けただけで、親が受け取る内容まで信頼済みになるわけではありません(詳細は プロンプトインジェクションが正本)
  • 隔離の代償: サブエージェントは親の文脈を共有しないため、必要な前提を渡し漏れると的外れな結果を返します。委譲の境界は「独立して完結でき、要点だけ返せばよい」単位に引きます

境界では、子の戻り値を「抽出した事実・出典参照・未確認事項」のような出力契約にし、スキーマ・サイズ・参照先をコード側で検証します。自由記述の要約もデータとして扱い、システム指示やユーザーの承認へ昇格させません。親がその内容を根拠にツールを使うときは、親の権限・送信先制限と実行前承認を独立して適用します。構造化出力LLM の出力を JSON Schema などの機械可読なスキーマに従わせる技術。後続の処理がコードである出力(分類・抽出・スコア)に使う。は形式を制約するもので、内容の無害性の保証ではありません(OWASP の Agent 向け防御 )。

仕切り直しの判断: 汚染したら作り直す

圧縮も隔離も追いつかず、コンテキストが汚染して抜け出せなくなることがあります(同じ失敗の反復・矛盾した状態)。このとき最も効く手段が、現在のコンテキストを捨てて、外部化した状態から作り直す仕切り直しです。

  • 検知: 同一ツールの同一引数での反復、進捗のない往復の増加、過去の決定と矛盾する言動は、汚染のサインです(検知の仕組みは 可観測性とトレーシング・ループ設計側)
  • 作り直し: 「経緯の要約 + 外部化した作業状態(計画・決定・成果物の参照)」から新しいコンテキストを再構築します(メモリと状態管理の再開と同じ手続き)。だからこそ、平時から決定と状態を外部化しておくことが仕切り直しを可能にします
  • 判断: 圧縮で回復するか仕切り直すかは、「汚染が局所的(古い脱線)か全体的(状態の不整合)か」で決めます。全体が矛盾しているなら、まとめ直すより作り直すほうが速いことが多いです

圧縮の失敗モード

圧縮は便利さゆえに、失敗が見えにくいのが危険です。

  • 決定の消失 → 議論のループ: 「すでに決めたこと」が要約から抜けると、Agent は同じ論点を蒸し返し、下手をすると前と違う結論を出します。最も頻度が高く、最も高くつく失敗です。対策は「残すリスト」の徹底
  • 制約の消失 → 逸脱: ユーザーの禁止事項・要件が要約で消えると、以降それを破ります。安全に関わる制約は要約任せにせず、システムプロンプト側の固定部分に持たせる選択もあります
  • 偽の連続性: 要約が滑らかだと、情報が失われたことに人もモデルも気付きにくいものです。圧縮の前後で重要情報が保持されているかを検証する仕組み(残すリストとの照合)を入れます
  • タイミングの悪さ: 作業の途中で圧縮が入ると直後の品質が落ちます。フェーズ境界トリガで回避します

思考ブロックと会話履歴の結び付き

暗号化・署名付きの思考ブロックは、本文の要約と同じように切り貼りできるとは限りません。2026-09-01 公開の Claude Fable 5.1 では、思考ブロックより前の system・tools・履歴を変更すると、そのブロックの結び付きが無効になります。2026-08-31 以降の新規アカウントでは検査が強制され、再送は既定で 400 エラーになります。

履歴を追記する方式、対応するサーバー側の compaction / context editing、思考を再送しない方針を決めたクライアント側要約を使い分けます。一時的な指示は、対応するターン限定 system 機構で追加し、過去の本文を挿入・削除しません。また Fable 5.1 の思考は旧モデルでは破棄されます。フォールバック時には可視の結論・未完了作業・承認状態を別に保存し、思考の引継ぎだけに依存しない設計にします。

実務での注意点

アンチパターン

  • 上限到達まで圧縮を自動任せにする → 最悪のタイミングで損失圧縮が起き、直後の品質が落ちる → 閾値 + フェーズ境界でトリガを設計する
  • 決定とその理由まで要約で落とす → 同じ議論をループし、前と矛盾する結論を出す → 「必ず残すリスト」に決定・制約・未解決点を入れて要約プロンプトに埋め込む
  • すべてを 1 つのコンテキストに溜め込む → 量と汚染の両方が悪化する → 探索はサブエージェントに隔離し、状態は外部化する
  • 子の要約を信頼済みの命令として親へ戻す → 要約に残った間接インジェクションが親の権限で実行される → 子を低権限にし、戻り値をデータとして検証し、親の権限制約・実行前承認を維持する(プロンプトインジェクション)
  • 汚染したコンテキストを圧縮で立て直そうとし続ける → 不整合な状態をまとめ直すだけで抜け出せない → 外部化した状態から仕切り直す
  • 仕切り直せる設計を平時に用意していない → いざ汚染しても作り直す材料がない → 決定・計画・成果物を平時から外部化しておく

チェックリスト

  • 圧縮のトリガ(閾値 + フェーズ境界)が設計されている(上限まかせでない)
  • 「圧縮後も必ず残す情報」のリストがあり、要約プロンプトに埋め込まれている
  • 決定と、決定に至った試行錯誤を区別して扱っている
  • 作業状態(計画・決定・成果物)が履歴の外に構造化されている
  • 大量の中間出力を生む探索をサブエージェントに隔離している
  • 非信頼コンテンツを扱う子の権限が制限され、戻り値の出力契約・検証と、親の独立した権限制約・承認がある
  • 汚染の検知手段(反復・矛盾)と、外部化状態からの仕切り直し経路がある

関連トピック

参考資料

TODO・未確認事項

なし

コンテキスト設計の実践パターンオーケストレーションパターン