{
  "issue": "2026-08-01",
  "generated_at": "2026-08-01T07:00:00+09:00",
  "theme": {
    "title": "コンテキストエンジニアリング — 「何を見せるか」ではなく「何を見せないか」を設計する",
    "category": "context-engineering",
    "lede": "プロンプトの言い回しを工夫する段階は終わり、エージェントに何を見せて何を見せないかを設計する段階に移った。Anthropic・Cursor・Manusが相次いで公式ブログで具体的な実装を公開し、圧縮・分離・遅延取得という共通の語彙が固まりつつある。単に情報を増やすとモデルの精度がむしろ落ちる「context rot」が実証された今、コンテキストは足すものではなく削るものだという前提の転換が起きている。",
    "tldr": [
      "事前に全部読み込むのではなく、ファイルパスやURLなど軽量な参照を渡して実行時に取得する「Just-in-Time retrieval」がCursorやAnthropicの標準手法になった。",
      "コンテキスト上限に近づいたら要約して仕切り直す「コンパクション」と、要約に残らない詳細をファイルへ逃がす「構造化ノート」が長時間タスクの生命線になっている。",
      "サブエージェントへの分割は調査・検索など出力を要約に圧縮できるタスクに限定し、コーディングのような状態共有が必要なタスクではコンテキストを割らず見せる範囲を絞る方が安全。"
    ],
    "sections": [
      {
        "heading": "「全部載せる」から「その場で取りに行く」への転換",
        "body_html": "<p>Just-in-Time retrieval とは、ファイルパスや URL、検索クエリのような軽量な識別子だけをエージェントに渡し、実際に必要になった時点でツール経由で本体を取得する設計を指す。事前にすべての候補データを読み込んでおく方式と対比され、<code>grep</code> や検索ツールを使って自ら情報を探しに行く挙動を、人間が資料を都度参照する動きに近づけるという発想が根底にある。</p><p>この方式に業界が収束しつつあるのは、事前ロードがコストとレイテンシを増やすだけでなく、無関係な情報が多いほどモデルが本当に必要な箇所に注意を向けにくくなるためだ。Cursor は MCP ツールの説明文をフォルダに同期し必要な時だけ選択的に読み込む方式に切り替え、MCP ツールを呼び出すセッションでトークン消費量を46.9%削減したとA/Bテストの結果を公式ブログで報告している。</p>",
        "examples": [
          {
            "product": "Claude Code（Anthropic）",
            "approach": "ファイルパスやURLなど軽量な識別子だけを渡し、実行時にツール経由で必要な情報を取得する",
            "detail": "公式エンジニアリングブログが、全データを事前に読み込む方式より人間の情報収集の仕方に近いこの方式を context engineering の柱の一つとして明記している",
            "source_url": "https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents"
          },
          {
            "product": "Cursor",
            "approach": "MCPツールの説明文をフォルダに同期し、必要な時だけ選択的にロードする方式へ切替",
            "detail": "A/Bテストで、MCPツールを呼び出すセッションのトークン消費量を46.9%削減したと公式ブログで数値付きで報告している",
            "source_url": "https://cursor.com/blog/dynamic-context-discovery"
          }
        ],
        "takeaway": "ツールの説明やドキュメントを起動時に全部読み込む設計は見直す価値がある。ファイルパスやクエリのような軽量な参照に置き換えられないか、既存のツール定義を棚卸しするところから始めるのが良い。"
      },
      {
        "heading": "長時間タスクの生命線は「圧縮」と「外部メモ」",
        "body_html": "<p>コンパクションは、コンテキスト上限に近づいた会話の内容を要約し、その要約から新しいコンテキストウィンドウを開始する手法だ。要約時にはアーキテクチャ上の決定事項や未解決の課題を優先して残し、冗長なツール出力は捨てる。これと組み合わせて使われる構造化ノートは、要約にも残らない細部を進捗ログとしてファイルなどコンテキスト外の永続領域へ書き出し、必要になれば読み戻す仕組みだ。</p><p>この2つが必須になっているのは、数千ステップに及ぶような長時間タスクは、どれだけウィンドウを広げても単純な拡大だけでは対応しきれないからだ。Anthropic は Sonnet 4.5 のリリースに合わせて memory tool をパブリックベータで提供し、ポケモンを長時間プレイし続けるエージェントが地図や達成事項をノートとして書き残しながら数千ステップを継続した実例を公式ブログで公開している。</p>",
        "examples": [
          {
            "product": "Claude Code / memory tool（Anthropic, Sonnet 4.5）",
            "approach": "コンテキスト上限に近づいた会話を要約して新しいウィンドウに引き継ぐコンパクションと、要約に残らない詳細をファイルへ書き出す構造化ノートを併用",
            "detail": "Sonnet 4.5のリリースと同時にmemory toolをパブリックベータ提供し、数千ステップに及ぶ長時間タスク（ポケモン攻略）での実例を公式ブログで公開している",
            "source_url": "https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents"
          }
        ],
        "takeaway": "コンテキストウィンドウは大きくしても際限なく使えるわけではない。長時間タスクを設計するなら、要約でリセットするコンパクションと、要約からこぼれる情報をファイルへ退避する仕組みを最初から分けて用意する。"
      },
      {
        "heading": "コンテキストを分けるか、ひとつに保つか — サブエージェントと単一コンテキストの分岐",
        "body_html": "<p>サブエージェントによるコンテキスト分離は、詳細な調査や検索を担当する子エージェントに独立したコンテキストウィンドウを与え、親エージェントには1000〜2000トークン程度に凝縮した要約だけを返す設計だ。詳細な探索過程は子エージェント側で破棄され、親側のコンテキストは肥大化しない。</p><p>一方で、この分割が向くのは出力を要約に圧縮できる調査・検索系のタスクに限られる。Manus はコーディングのように状態を継続的に共有し続ける必要があるタスクでは、エージェントを分割してコンテキストを分けるのではなく、単一の長いコンテキストを維持したままツールの利用可否をロジットのマスキングで動的に切り替える方式を採用したと公式ブログで説明している。ツールをコンテキストから物理的に取り除くとKVキャッシュのヒット率が崩れコストと速度が悪化するため、「見せる範囲を絞る」操作をコンテキスト分割ではなくマスキングで行っているという。</p>",
        "examples": [
          {
            "product": "Claude Code（Anthropic）",
            "approach": "調査系のサブエージェントには独立したコンテキストウィンドウを与え、親エージェントには1000〜2000トークンの要約だけを返す",
            "detail": "詳細な探索コンテキストはサブエージェント側で破棄し、親エージェントのコンテキストを圧迫しない設計だと公式ブログで説明している",
            "source_url": "https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents"
          },
          {
            "product": "Manus",
            "approach": "ツールをコンテキストから動的に削除・分離するのではなく、単一の長いコンテキストを維持したままロジットのマスキングでツールの利用可否だけを切り替える",
            "detail": "ツールをコンテキストから物理的に取り除くとKVキャッシュのヒット率が崩れコストと速度が悪化するため、状態共有が必要なタスクではコンテキストを割らない方針だと公式ブログで説明している",
            "source_url": "https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus"
          }
        ],
        "takeaway": "サブエージェント分割が効くのは、出力を要約に圧縮できる検索・調査系のタスクに限られる。状態を共有し続ける必要があるタスク（コーディングなど）では、コンテキストを割るより見せる範囲を動的に絞る方が安全。"
      }
    ]
  },
  "editorial": "コンテキストエンジニアリングという言葉が指しているのは、結局「モデルに何を見せないか」を決める設計判断だ。トークン単価が下がりウィンドウが広がるほど、この判断の質はモデル性能ではなく人間の設計側で差がつくようになる。",
  "quick_picks": [
    {
      "title": "Context Rot: 入力トークンが増えるほどLLMの精度は落ちる",
      "summary": "Chromaが18種のSOTAモデルを対象に検証したレポートで、ウィンドウが埋まっていなくても入力長が伸びるだけで単純なタスクの精度が本来の限界よりずっと手前で30〜50%落ちる例を示した。本文で扱った「圧縮・遅延取得でコンテキストを削る」設計判断の裏付けとなるデータだ。",
      "url": "https://www.trychroma.com/research/context-rot"
    },
    {
      "title": "LangChain、コンテキストエンジニアリングを4操作に整理",
      "summary": "write・select・compress・isolateの4つの操作としてコンテキスト管理を分類した公式ブログ。本文で扱ったコンパクション（compress）とサブエージェント分離（isolate）は、この分類のうち2つの実装例にあたる。",
      "url": "https://www.langchain.com/blog/context-engineering-for-agents"
    }
  ]
}
