主要なポイント
- 実効的なコンテキストウィンドウは、宣伝されているよりはるかに小さいです。1Mトークンモデルでも、~100Kトークンを超えるあたりからパフォーマンスがはっきり劣化します — 整合性（コヒーレンシ）が悪化し、幻覚が増え、計画のズレが起きます。全ウィンドウを「運用目標」ではなく「容量制限」として扱ってください。
- 長期（ホライズン）の作業にはサブエージェントが不可欠です。スコープされたタスクをサブエージェントに委譲することで、各エージェントを「スマートゾーン」に保ち、コンテキスト汚染を防ぎます。「メインエージェントがすでに委譲した作業を重複してしまう」ことで起きる「焦り（impatience）問題」に注意してください。
- コンテキスト制御はMCPサーバよりも、スキル＋CLIが勝ります。スキルは段階的なコンテキスト開示と動的なフィルタリングを提供します。MCPサーバは、フィルタリングが限られたまま不透明なコンテキストを押し出してきます — すべてのトークンが重要になるとき、その差は決定的です。
- コンテキストは希少なリソースであり、能力ではありません。コンパクション戦略、サブエージェントのアーキテクチャ、ツールの選定はすべて、コンテキストを軽く、スコープされ、新鮮に保つことを目的に設計すべきです。
私はコーディングエージェントをかなりの頻度で使っています — 主にCopilot CLIとSDKですが、Claude Codeやその他のエージェント型ツールも併用しています。さらに、1Mトークンのコンテキストモデル（Codex 5.4とOpus/Sonnet 4.6）も使っています。以下の例はCopilot CLIのワークフローから引いてきたものですが、ここで示すパターンは、長いコンテキストモデル上で動作する任意のコーディングエージェントに当てはまります。Claude Code、Cursor、Windsurf、Aider、そしてあなたが使っているどんなツールでもです。根本的な制約はツール固有ではなく、モデルのレベルにあります。
私のワークフローは、多くの人が最初に始める地点から大きく進化しました。多くの開発者は「1Mトークン」を見て「全部をモデルに投げればいい」と考えます。しかし結果は予想どおり悪いです。整合性がより悪化します。幻覚が増えます。計画は認識できないほどズレていきます。コンテキストウィンドウの全体は「運用目標」ではなく「容量制限」です。
以下は、私がこれらのツールを使う方法を根本的に変えた3つのパターンです。
1. 「スマートゾーン」は、あなたが思うよりずっと小さい
これらのモデルは最大100万トークンのコンテキストウィンドウに対応していますが、実効的なパフォーマンス領域はそれより大幅に小さい — しかも理由は付随的なものではなく、アーキテクチャ的なものです。
制限が存在する理由
多くの1Mトークンモデルは、短いコンテキストの先行モデルと比べて、基本的により大きい／より賢いわけではありません。YaRN（Yet another RoPE extensioN — https://arxiv.org/pdf/2309.00071）のような数学的手法によって、パラメータを増やさずにモデルのシーケンス長を引き伸ばし、拡張コンテキストを実現しています。コンテキストウィンドウは大きくなりますが、モデルの中核となる推論能力 — HumanLayerが「instruction budget（指示予算）」と呼ぶもの (https://www.hlyr.dev/blog/long-context-isnt-the-answer) — は同じままです。
instruction budgetとは、モデルが確実に従うことができる指示の数で、遵守率が落ち始めるまでの上限を指します。これは、コンテキストウィンドウのサイズではなく、モデルのパラメータ数やinstruction tuning（指示チューニング）の品質と強く相関します。instruction budgetをスケールせずにコンテキストを5倍に拡張すれば、より多くの情報を入れることはできますが、実際にはモデルがそれを「注意して処理する」点では良くなりません。HumanLayerはClaude Opus 4.6（1Mコンテキスト）をテストした際、instruction遵守が能力限界のところだけでなく、短いコンテキストのOpus 4.5と比べて、あらゆるコンテキスト長にわたって劣化することを、手ずから確認しています。
こう考えてください。コンテキストウィンドウは「干し草の山」であり、そこにツール呼び出し、ドキュメント、ファイルが入っています。次の行動の質は、正しい「針」 — その時点の状態に対する最も関連性の高い指示 — を見つける能力に依存します。モデルの「針を見つける力」を改善せずに干し草の量だけ5倍にしてしまうと、信号はより深いところに埋もれてしまいます。
実際にどんな劣化として現れるか
さまざまなプロンプトとコンテキストサイズでの実験を通じて、約100Kトークンを超えたあたりから、モデルの性能がはっきりと劣化し始めます。現れ方としては以下の通りです。
- タスクのコヒーレンシ悪化 — モデルが全体の目的を見失う
- 推論の信頼性低下 — 論理の連鎖が崩れる
- 幻覚率の増加 — モデルが自信を持って詳細を捏造する
- 長期タスクでの計画のズレ — 複数ステップの計画が進行方向から外れていく
- 指示への不従 — デザインドキュメントを無視する、簡単な指示を誤解する、あるいはもっと軽いコンテキストならしないような些細なミスをする
これは机上の話ではありません。私は、80Kトークンではクリーンで筋の通った出力を出していたエージェントが、同じタスクとコードベースで150Kトークンになると崩壊するのを見てきました。劣化は二値的ではなく、グラデーションとして進みます。ただし転換点は十分に一貫しているため、私はワークフローをそれに合わせて設計してきました。HumanLayerも同様のパターンを観察しており、有効に使えるウィンドウのパーセンテージではなく、100Kトークンで警告が発火するように切り替えたそうです。
うまくいく方法
- 自動コンパクションを早めに発火させる。コンテキストウィンドウが満杯になるのを待たないでください。モデルの最大容量よりかなり下の位置にコンパクションのしきい値を設定します。
- 定期的にコンテキストウィンドウをクリアする。進捗をディスクに保存してください（調査ドキュメント、仕様書、タスクリストなど）。その後、現在のフェーズに必要なものだけを読み込む新しいセッションを始めます。
- 最大詰め込み（max-packing）のプロンプトをやめる。モデルが1Mトークンを許容しているからといって、それを使うべきだという意味ではありません。完全なウィンドウは、想定外のコンテキスト増加に備える「余白（headroom）」として扱い、運用時の目標点にしないでください。
実務上のルールはこれです。完全な1Mウィンドウを「運用目標」ではなく「容量制限」として扱ってください。コンテキストが増えても、それがそのまま能力の増大ではありません。ウィンドウを十分に下回る状態を保つようにワークフローを設計しましょう。
2. 長期（ホライズン）の作業はサブエージェントを使って肩代わりさせる
私が見つけた最も効果的なパターンの1つは、メインエージェントのコンテキストを調整し、複雑な、あるいは長時間かかるタスクを処理するためにサブエージェントを立ち上げることです。
考え方はシンプルです。すべてを1つのエージェントのコンテキストウィンドウに詰め込むのではなく、スコープされた作業を、それぞれが自分自身のコンテキストウィンドウで動作するサブエージェントに委譲します。オーケストレーション（統括）するエージェントは、圧縮された結果を受け取ります。オーケストレーション側のコンテキストは軽く保たれます。各サブエージェントには、必要な情報だけが渡されます。
これは、コンテキスト劣化の問題に直接対処します。複数のエージェントに仕事を分散することで各エージェントを100Kトークン未満に保てるなら、合計コンテキストが300K+になるはずのタスクでも、「スマートゾーン」に留まれます。
オーケストレーター・パターン
以下は、私が使っているオーケストレーター用サブエージェントのテンプレートです（HumanLayerによるサブエージェントのオーケストレーションに関する作業をベースにしつつ、私のワークフロー向けに修正しています）：
---
name: orchestrator
description: "Orchestrate sub-agents to accomplish complex long-horizon tasks without losing coherency by delegating to sub-agents."
tools: ["execute", "agent", "edit", "search", "read"]
---
You are a sub-agent orchestrator. The most important tool available to you
is the one that dispatches sub-agents: either `Agent` or `Task`.
All non-trivial operations should be delegated to sub-agents.
Delegate research and codebase understanding tasks to codebase-analyzer,
codebase-locator, and pattern-locator sub-agents.
Delegate running bash commands (particularly ones likely to produce lots
of output) to Bash sub-agents.
Use separate sub-agents for separate tasks, and launch them in parallel —
but do not delegate tasks with significant overlap to separate sub-agents.
重要な設計上の判断:
- タスクごとにサブエージェントを分ける — 関連のない作業間で文脈が混ざる（コンテキスト汚染）ことを防ぐ
- 並列実行 — サブエージェントは独立したタスクに対して同時に作業できる
- 重複する委任をしない — 重複した作業や、競合する出力を避ける
The Impatience Problem
挙動上の癖として、指摘しておく価値のある点があります。これらのモデルの学習後（ポストトレーニング）における挙動は、小さいモデルの実行パターンを好む傾向があります。実際には、メインエージェントがせっかちになります。すでにサブエージェントに委任されたタスクを、メインエージェント自身が完了しようとしてしまうのです。
それではサブエージェントの目的がまったく失われます。結果として次のようになります:
- コンテキスト汚染 — メインエージェントがサブエージェント側で進行中の作業を重複して行う
- 重複作業 — 無駄な計算（コンピュート）と、潜在的に競合する出力
- 計画のズレ — メインエージェントの計画が、サブエージェントの実行から乖離する
- オーケストレーションの一貫性の喪失 — 委任構造が崩れる
だからこそ私は、この指示をすべてのオーケストレータのプロンプトに明示的に含めています:
"IMPORTANT: Sometimes sub-agents will take a long time. DO NOT attempt to do the job yourself while waiting for the sub-agent to respond. Instead, use the time to plan out your next steps, or ask the user follow-up questions to clarify the task requirements."
これは特定のツールに依存するものではありません。モデルレベルの挙動として、学習後の最適化によって「待つ」のではなく「何かをする」ことをモデルに求める傾向があります。私は最初に Copilot CLI でそれを見つけましたが、同じパターンは Claude Code、Cursor、そして他のエージェント型システムでも見られます。この明示的な指示は、どのエージェントを使っているかに関係なく、そのデフォルトを上書きします。
3. MCP サーバよりも Skills + CLIs を優先する
実際のところ、エージェントのツール統合では私は一貫して MCP サーバよりも Skills + CLIs を優先しています。
理由はコンテキスト制御です。Skills と CLIs は次をサポートします:
- 段階的なコンテキスト開示 — プロンプトウィンドウに入るコンテキストの内容、タイミング、形式をあなたが正確に制御できる
- 動的フィルタリング — 現在のタスクに基づいて、取得するコンテキストの範囲を絞り込める
一方で MCP サーバは多くの場合、次のようになりがちです:
- 不透明なコンテキストを押し込む — サーバ側が何を含めるかを決め、プロンプトに入る内容をあなたがほとんど見通せない
- フィルタリングが限定的 — MCP のアーキテクチャ設計の都合で、コンテキスト注入の粒度を制御しにくい
この違いは、100K+ トークンの領域付近で運用するようになった時点で致命的に重要になります。コンテキストの1トークンごとに意味があるとき、エージェントが「現時点で何を知っているか」を厳密に制御する必要があります。Skills はそのための制御をあなたに提供します。MCP サーバはしばしばそれを提供しません。
発見可能な能力のための Skill レジストリ
動的に発見してダウンロードできる能力でコーディングエージェントを基盤づけるために、知っておくべきレジストリが 2 つあります:
- Agent Skills Directory — 再利用可能なエージェントスキルの厳選ディレクトリ: https://skills.sh/
- microsoft/skills — Microsoft のオープンソーススキルリポジトリ: https://github.com/microsoft/skills
これらのレジストリにより、エージェントはスキル定義で一次コンテキストを不必要に膨らませることなく、能力を見つけて取り込めます。必要になったときにスキルを読み込み、使い、その後コンテキストは回収されます。
パターン
3 つのヒントはいずれも、同じ根本原則を指しています。コンテキストは希少なリソースであり、能力ではない、ということです。
モデルの能力は十分です。コンテキストウィンドウも十分に大きい。しかし実効的な運用領域は、理論上の最大値よりもはるかに小さいのです。あなたがやるすべてのこと — 圧縮戦略、サブエージェントのアーキテクチャ、ツールの選択 — は、コンテキストを軽量に保ち、範囲を絞り、常に新鮮に保つことを目的に設計されるべきです。
制約のあるシステムにおけるメモリのように、コンテキストを扱ってください。慎重に割り当てましょう。積極的に解放しましょう。余裕があるからといって、それを使うべきだと決めつけないでください。
参考文献
- HumanLayer, "Long-Context Isn't the Answer": https://www.hlyr.dev/blog/long-context-isnt-the-answer
- Peng et al., "YaRN: Efficient Context Window Extension of Large Language Models": https://arxiv.org/pdf/2309.00071
- The Agent Skills Directory: https://skills.sh/
- Microsoft Skills Repository: https://github.com/microsoft/skills
