{
  "issue": "2026-08-11",
  "generated_at": "2026-08-11T07:00:00+09:00",
  "theme": {
    "title": "コンテキスト圧縮はどこで行うべきか — API・モデル訓練・ハーネス、3層に割れた実装場所",
    "category": "context-compaction",
    "lede": "長時間稼働するコーディングエージェントは、いずれ必ずコンテキストウィンドウの上限にぶつかる。この「古い会話をどう畳んで続きを走らせるか」という課題に対し、直近半年で Anthropic・OpenAI・Microsoft がほぼ同時に対処したが、実装した層がそれぞれ違う。API のオプション、モデルの訓練対象、ハーネスのランタイム機能——同じ問題への解が3層に分かれたのは、この機能がどこに置いても動くという裏返しでもある。",
    "tldr": [
      "Anthropic は compaction をサーバーサイド API のオプションとして実装し、モデル本体は変更していない",
      "OpenAI は GPT-5.1-Codex-Max で圧縮判断そのものを訓練対象にし、モデルが自分の履歴を刈り込む",
      "Microsoft は Agent Framework のランタイム層に compaction を組み込み、todo 管理やツール承認と同列に扱う"
    ],
    "sections": [
      {
        "heading": "サーバーサイド API という選択 — Anthropic の compact_20260112",
        "body_html": "<p>Anthropic の Context Compaction API は、入力トークン数が設定した閾値（デフォルト15万トークン、最小5万トークン）に達すると、API 側が会話を要約して <code>compaction</code> ブロックを生成する。以降のリクエストでは、このブロックより前の内容は自動的に破棄され、要約から会話が継続する。クライアント側で要約ロジックを書く必要はない。</p><p>この方式の要点は、モデルの重みには一切手を入れず、API 呼び出し時のオプション（ベータヘッダーと <code>context_management</code> パラメータ）として提供している点にある。要約に使うプロンプトも <code>instructions</code> で丸ごと差し替えられるため、圧縮の挙動をアプリ側で制御できる。AWS Bedrock・Google Cloud・Microsoft Foundry でも同一仕様が使えるのは、モデル非依存でAPIレイヤーに閉じているからだ。</p>",
        "examples": [
          {
            "product": "Claude Opus 5 / Sonnet 5（Anthropic, Context Compaction API）",
            "approach": "入力トークンが閾値到達で自動要約し、以降のリクエストは要約ブロックから継続する",
            "detail": "自前で要約ロジックを実装していたチームが置き換え対象にできる、最も仕様が具体的なcompaction実装。2026年3月のClaude Opus 4.6で先行導入され、1Mトークンウィンドウでの検索精度をSonnet 4.5比76%対18.5%まで改善したと報告されている",
            "source_url": "https://platform.claude.com/docs/en/build-with-claude/compaction"
          }
        ],
        "takeaway": "自前で「古い会話を要約してプロンプトに詰め直す」ロジックを書いているなら、まず標準APIのcompactionオプションに置き換えられないか確認するのが先。車輪の再発明を避けられる。"
      },
      {
        "heading": "モデル自身に刈り込みを学習させる — OpenAI Codex-Max のcompaction",
        "body_html": "<p>OpenAI の GPT-5.1-Codex-Max は、複数のコンテキストウィンドウをまたいで動作するよう訓練段階で学習した初めてのモデルだとされる。Codex アプリケーション上でコンテキスト上限に近づくと、モデル自身が重要な情報を保持しながら履歴を刈り込み、新しいウィンドウで作業を継続する。この繰り返しにより、単一タスクを24時間以上続けられたという社内評価が報告されている。</p><p>Anthropic方式との違いは、要約が外付けのAPI機能ではなく、モデルの意思決定そのものに埋め込まれている点だ。どの情報が「タスクに効くか」の判断を、汎用的な要約プロンプトではなくモデルの学習済みポリシーに委ねている。引き換えに、この挙動はそのモデル専用であり、他モデルに持ち出せない。</p>",
        "examples": [
          {
            "product": "GPT-5.1-Codex-Max（OpenAI）",
            "approach": "compactionを訓練対象に組み込み、モデル自身が履歴の取捨選択を判断する",
            "detail": "外付けの要約ラッパーではなく学習済みモデルの挙動としてcompactionを実装した点が、APIオプション方式との明確な対比になる",
            "source_url": "https://openai.com/index/gpt-5-1-codex-max/"
          }
        ],
        "takeaway": "汎用の要約API（移植性が高いが浅い）と、訓練済みモデル任せの圧縮（そのモデル専用だが文脈保持が深い）はトレードオフ。モデルを固定できるプロダクトなら後者の恩恵が大きい。"
      },
      {
        "heading": "ハーネス層に押し込む — Microsoft Agent Framework の統合ランタイム",
        "body_html": "<p>Microsoft は2026年6月のBuildで、Agent Framework の Harness を GA にした。ここでは自動コンテキスト圧縮が独立機能ではなく、todoリストによるplan/execute管理、ツール承認エージェント、バックグラウンドエージェントへのタスク委譲などと同じランタイム層の一部として提供される。ツール呼び出しが連続する長いループの途中でトークン使用量を監視し、上限に達する前に会話履歴を圧縮する。</p><p>API層でもモデル層でもなく、その中間の「ハーネス」に置いたのは、実運用のエージェントがそもそも生のモデルAPIを直接叩くのではなく、独自のハーネスを介して動いていることが多いからだ。圧縮だけを個別実装させるより、他のランタイム機能とまとめて提供する方がチームの重複実装を減らせる。</p>",
        "examples": [
          {
            "product": "Agent Framework Harness（Microsoft, GitHub Copilot / Foundry 連携）",
            "approach": "context compactionをtodo管理・ツール承認・バックグラウンドエージェントと同じランタイム層でGA化",
            "detail": "2026年4月の1.0リリースに続き6月のBuildでGAに到達、自前ハーネスを持つチームが個別実装をやめて乗り換えられる水準の完成度",
            "source_url": "https://www.infoq.com/news/2026/08/agent-framework-harness-ga/"
          }
        ],
        "takeaway": "自分たちでハーネスを組んでいるなら、compactionを単独機能として作り込む前に、公開フレームワークがどの層にまとめているかを見て、同じ粒度で設計するかどうかを判断する。"
      }
    ]
  },
  "editorial": "3社とも「古い文脈を畳んで続ける」という結論自体は同じで、違うのはそれをAPIオプション・訓練対象・ランタイム機能のどの層に固定したかだけだ。自分のプロダクトがモデルを差し替える可能性があるならAPI層、特定モデルに賭けられるなら訓練層、独自ハーネスを持つなら実行時層——という具合に、選ぶべき層は自分のアーキテクチャの固定度合いに従う。",
  "quick_picks": [
    {
      "title": "Claude Opus 4.6、adaptive reasoningとcontext compactionを同時導入",
      "summary": "2026年3月、Anthropicは長時間エージェントワークフローでの性能劣化に対処するためcompactionを先行導入し、1Mトークンウィンドウでの検索精度を大幅改善したと報告した。本号で扱ったcompact_20260112 APIの前身にあたる機能追加。",
      "url": "https://www.infoq.com/news/2026/03/opus-4-6-context-compaction/"
    },
    {
      "title": "Windsurf改めDevin Desktop、エージェント間でコンテキストを共有する「Spaces」を導入",
      "summary": "Cognitionは2026年、Windsurfをデスクトップ版DevinのIDEとして統合し、セッション・PR・ファイル・プロジェクト状態をまたいでコンテキストを共有するSpaces機能を追加した。個々のセッション内の圧縮ではなく、セッション横断の文脈共有という別角度からの解。",
      "url": "https://devin.ai/blog/windsurf-is-now-devin-desktop"
    }
  ]
}