🧠 AI プロダクト動向

2026-08-11 発行(読了 5 分)

実プロダクトのアーキテクチャ・使用例から AI 開発の現在地を週 3 回・1 号 1 テーマで深掘り

今号のテーマ CONTEXT-COMPACTION

コンテキスト圧縮はどこで行うべきか — API・モデル訓練・ハーネス、3層に割れた実装場所

長時間稼働するコーディングエージェントは、いずれ必ずコンテキストウィンドウの上限にぶつかる。この「古い会話をどう畳んで続きを走らせるか」という課題に対し、直近半年で Anthropic・OpenAI・Microsoft がほぼ同時に対処したが、実装した層がそれぞれ違う。API のオプション、モデルの訓練対象、ハーネスのランタイム機能——同じ問題への解が3層に分かれたのは、この機能がどこに置いても動くという裏返しでもある。

TL;DR — 3 行で
📐 パターン 1: サーバーサイド API という選択 — Anthropic の compact_20260112

Anthropic の Context Compaction API は、入力トークン数が設定した閾値(デフォルト15万トークン、最小5万トークン)に達すると、API 側が会話を要約して compaction ブロックを生成する。以降のリクエストでは、このブロックより前の内容は自動的に破棄され、要約から会話が継続する。クライアント側で要約ロジックを書く必要はない。

この方式の要点は、モデルの重みには一切手を入れず、API 呼び出し時のオプション(ベータヘッダーと context_management パラメータ)として提供している点にある。要約に使うプロンプトも instructions で丸ごと差し替えられるため、圧縮の挙動をアプリ側で制御できる。AWS Bedrock・Google Cloud・Microsoft Foundry でも同一仕様が使えるのは、モデル非依存でAPIレイヤーに閉じているからだ。

Claude Opus 5 / Sonnet 5(Anthropic, Context Compaction API)
入力トークンが閾値到達で自動要約し、以降のリクエストは要約ブロックから継続する
自前で要約ロジックを実装していたチームが置き換え対象にできる、最も仕様が具体的なcompaction実装。2026年3月のClaude Opus 4.6で先行導入され、1Mトークンウィンドウでの検索精度をSonnet 4.5比76%対18.5%まで改善したと報告されている
📄 一次ソース
示唆: 自前で「古い会話を要約してプロンプトに詰め直す」ロジックを書いているなら、まず標準APIのcompactionオプションに置き換えられないか確認するのが先。車輪の再発明を避けられる。
📐 パターン 2: モデル自身に刈り込みを学習させる — OpenAI Codex-Max のcompaction

OpenAI の GPT-5.1-Codex-Max は、複数のコンテキストウィンドウをまたいで動作するよう訓練段階で学習した初めてのモデルだとされる。Codex アプリケーション上でコンテキスト上限に近づくと、モデル自身が重要な情報を保持しながら履歴を刈り込み、新しいウィンドウで作業を継続する。この繰り返しにより、単一タスクを24時間以上続けられたという社内評価が報告されている。

Anthropic方式との違いは、要約が外付けのAPI機能ではなく、モデルの意思決定そのものに埋め込まれている点だ。どの情報が「タスクに効くか」の判断を、汎用的な要約プロンプトではなくモデルの学習済みポリシーに委ねている。引き換えに、この挙動はそのモデル専用であり、他モデルに持ち出せない。

GPT-5.1-Codex-Max(OpenAI)
compactionを訓練対象に組み込み、モデル自身が履歴の取捨選択を判断する
外付けの要約ラッパーではなく学習済みモデルの挙動としてcompactionを実装した点が、APIオプション方式との明確な対比になる
📄 一次ソース
示唆: 汎用の要約API(移植性が高いが浅い)と、訓練済みモデル任せの圧縮(そのモデル専用だが文脈保持が深い)はトレードオフ。モデルを固定できるプロダクトなら後者の恩恵が大きい。
📐 パターン 3: ハーネス層に押し込む — Microsoft Agent Framework の統合ランタイム

Microsoft は2026年6月のBuildで、Agent Framework の Harness を GA にした。ここでは自動コンテキスト圧縮が独立機能ではなく、todoリストによるplan/execute管理、ツール承認エージェント、バックグラウンドエージェントへのタスク委譲などと同じランタイム層の一部として提供される。ツール呼び出しが連続する長いループの途中でトークン使用量を監視し、上限に達する前に会話履歴を圧縮する。

API層でもモデル層でもなく、その中間の「ハーネス」に置いたのは、実運用のエージェントがそもそも生のモデルAPIを直接叩くのではなく、独自のハーネスを介して動いていることが多いからだ。圧縮だけを個別実装させるより、他のランタイム機能とまとめて提供する方がチームの重複実装を減らせる。

Agent Framework Harness(Microsoft, GitHub Copilot / Foundry 連携)
context compactionをtodo管理・ツール承認・バックグラウンドエージェントと同じランタイム層でGA化
2026年4月の1.0リリースに続き6月のBuildでGAに到達、自前ハーネスを持つチームが個別実装をやめて乗り換えられる水準の完成度
📄 一次ソース
示唆: 自分たちでハーネスを組んでいるなら、compactionを単独機能として作り込む前に、公開フレームワークがどの層にまとめているかを見て、同じ粒度で設計するかどうかを判断する。
✍️ 編集後記 3社とも「古い文脈を畳んで続ける」という結論自体は同じで、違うのはそれをAPIオプション・訓練対象・ランタイム機能のどの層に固定したかだけだ。自分のプロダクトがモデルを差し替える可能性があるならAPI層、特定モデルに賭けられるなら訓練層、独自ハーネスを持つなら実行時層——という具合に、選ぶべき層は自分のアーキテクチャの固定度合いに従う。
🔗 今号の動向ピックアップ
📚 過去号
2026-09-15
エージェント実行基盤のマネージド化 — 3社が同時に「実行環境を貸す側」に回ったOpenAIが9月10日、Codexハーネスをagents/environments/sessions/eventsの4プリミティブに集約した Agents API を公開ベータで公開。基盤自体の追加課金はなくトークン・ツール実費のみ。
2026-09-12
コンテキストは会話ログではない — Working Context / Session / Memory / Artifacts への分離が実装標準になったGoogle ADKは2026年9月、コンテキストを Working Context・Session・Memory・Artifacts の4層に分離し、閾値到達で非同期に要約するcompactionを実装したと公式ブログで説明した。
2026-09-10
Agent Skills という第3のレイヤー — プロンプトでもRAGでもなく「必要になるまで読まない」設計Agent Skillsは「メタデータ(~100トークン)→本文(<5000トークン推奨)→付随ファイル」の3段階でコンテキストに読み込む、プログレッシブディスクロージャー設計。
2026-09-08
エージェント評価の再設計 — テキスト一致から状態検証、そして「修正がテストになる」仕組みへAnthropicはテキスト一致の判定から、環境の状態が実際に変わったかを見る outcome/state チェックへの転換を公式に推奨している。
2026-09-03
長時間稼働エージェントの状態管理 — 「会話の保存」から「プロセスの永続化」へGoogle ADKやMastraは、ツール呼び出しなどステップの境界ごとに実行状態をシリアライズして外部ストレージに書き込み、コンテナが落ちても直前のステップから再開できる設計に収束している。
2026-09-01
コードレビューエージェントの設計 — 差別化は検出率ではなく、文脈の取り方と『直すところまで』の範囲に移ったGitHub Copilot・Qodo・Cursor Bugbot・Cloudflareの内製ツールが、diff単体の解析から脱却し、リポジトリ全体・PR履歴・過去の指摘への反応まで動的に文脈を取りに行く設計へ収束している
2026-08-29
構造化出力は「お願い」から「強制」へ — 3社がグラマー制約デコーディングで足並みを揃えた2026年OpenAI・Anthropic・Google の主要3社が、JSON Schema をトークン生成レベルで強制する「グラマー制約デコーディング」に共通で対応した
2026-08-27
マルチエージェント協調 — 割っていいのは「コンテキストの切れ目」だけAnthropic は Research 機能で並列サブエージェントを使い内部評価で90.2%の性能改善を報告するが、トークン消費は通常の約15倍になるとも明記している。
2026-08-25
エージェントのメモリ設計 — 生ログでも単一要約でもなく、書き換え可能な単位に分解するClaude は2026年7月、記憶を単一のローリング要約から個別の書き換え可能なエントリへ移行。ChatGPT は非同期の「Dreaming」処理で古い事実を時制ごと書き換える。
2026-08-22
プロンプトキャッシュはコスト最適化ではない — 「プレフィックス固定」というアーキテクチャ制約キャッシュ命中率はもはや副次指標ではなく、Manus はこれを「本番エージェントで最重要のメトリック」と明言している。
2026-08-20
接続ツールが増えるほど遅くなる問題 — コード実行と検索遅延ロードの2つの答えAnthropicは公式エンジニアリングブログで、MCPツールをコードAPIとして提示しファイルシステム越しにオンデマンドで読み込ませる方式により、あるタスクのトークン消費を150,000から2,000(98.7%減)に削減したと報告した
2026-08-18
MCPエージェントの認可設計 — 同意画面を「増やす」実装と「無くす」実装に分岐したMCPの権限設計は「サーバー単位のOAuth」から「ツールごとのスコープ」へ移り、WorkOSやCloudflareが個別ツール内での権限チェックを標準パターンとして提示している。
2026-08-15
エージェントの評価・観測性 — 「最終出力の一致」から「軌跡(トラジェクトリ)の妥当性」へAnthropic は Tasks/Graders/Transcripts の三要素でエージェント評価を構造化し、1回でも成功する確率 pass@k と毎回成功する確率 pass^k を分けて計測する運用を提示した。
2026-08-13
モデルルーティング — 1モデルに全部背負わせない設計が標準になったVercel AI GatewayやGitHub Copilot Autoは、ヒューリスティック分類→難易度ティア判定→プロバイダ違いのフォールバック、という二段構成のタスク別ルーティングをすでに標準実装にしている。
2026-08-08
エージェントのコード実行基盤 — サンドボックスは「重い専用マシン」と「軽いアイソレート」に分かれ始めたCloudflare Sandboxes と Vercel Sandbox はどちらも「持続する専用マシン」型サンドボックスをGA化し、スナップショット復元でコールドブート30秒を2秒程度まで縮めた。
2026-08-06
RAG 構成パターンの現在地 — 二段構成の次は、検索そのものをエージェントに埋め込むPerplexity は Vespa 上で lexical・embedding のハイブリッド検索から cross-encoder rerank へ絞り込む多段構成を採り、Databricks は同じ構成を単一パラメータで追加できる機能として一般化した。
2026-08-04
ワークフロー型 vs エージェント型 — 複雑さを足す前に何を確かめるかAnthropic は「経路を誰が決めるか」で workflow と agent を定義し、単純な方から試すべきだと明言している。
2026-08-01
コンテキストエンジニアリング — 「何を見せるか」ではなく「何を見せないか」を設計する事前に全部読み込むのではなく、ファイルパスやURLなど軽量な参照を渡して実行時に取得する「Just-in-Time retrieval」がCursorやAnthropicの標準手法になった。
2026-07-30
マルチエージェント協調 — 「書き込みを一本化する」が唯一の合意点になった理由Cognition は2025年、複数エージェントの並行書き込みが矛盾した判断を生むとして「マルチエージェントを作るな」と主張したが、2026年4月に態度を転換し「書き込みは一本化し、エージェントは行動ではなく知性を提供する」構成に絞って実例を公開した
2026-07-28
エージェントのメモリ設計 — 保存容量ではなく「書き込みの境界線」を設計するAnthropic は Claude Managed Agents の記憶をファイルとして保存し、監査ログ・ロールバック・スコープ別パーミッションを標準機能として public beta で提供している
2026-W30
エージェントの評価・観測性 — 「良さそう」を数値にする前に何を測らないかを決めるAnthropic は Claude Code の品質劣化が6週間、内部の eval・コードレビュー・単体テストをすべてすり抜けていたと自ら公表し、変更ごとの広範な eval とソーク期間の導入を表明した