Claude Code、1Mコンテキスト時代への設計指針：200K時代の常識をどう更新するか
本記事は、Claude Codeが1Mコンテキストウィンドウを全プランで一般提供（GA）したことを受け、従来の200Kトークン前提の設計判断を再評価し、新しい設計指針を提示している。1M GAにより、まず料金面で大きな変化があった。ベータ期間中の200K超リクエストに適用されていたプレミアム価格（入力2倍、出力1.5倍）が完全に廃止され、標準料金で1Mまで利用可能となった。また、精度面では、Opus 4.6がMRCR v2ベンチマークで1M時に76%を達成したが、256K時の93%と比較すると精度低下（Context Rot）が確認されており、実用的な上限は「Smart Zone」（容量の約40%）である約400Kトークンと推定されている。
設計判断の更新点として、まず「Compaction戦略」は、単なる「枠の確保」から「タスクの意味的区切り」へと目的を更新すべきと指摘。次に「サブエージェント分割」は、コンテキスト節約が動機から弱まるため、分割理由を「コスト最適化」や「並列処理」に絞るべきと提言。また、「CLAUDE.mdのサイズ」は、固定コストの相対比率が低下したため、制限を「目安」に緩和し、判断精度向上に寄与する情報を積極的に盛り込むべきとしている。さらに、「セッション設計」は、中規模タスクであれば分割なしで完走可能となり、タスク完了まで連続して走らせる設計への移行が推奨される。最後に、「モノレポでの読み込み範囲」は、パッケージ間のインターフェース変更など、関連パッケージの一括読み込みが有利なケースが増えている。
一方で、重要な原則として、重要な指示は「先頭・末尾」に配置すること、Prompt Cachingの恩恵を最大化するためにCLAUDE.mdの構造を安定させること、そして「情報の選別と構造化（Context Engineering）」が不可欠である点を強調している。また、コスト面では、Extended Thinkingトークンが支配的なコスト要因となるため、調査タスクをHaikuサブエージェントに委譲するなど、コスト最適化の視点を持つことが重要である。
背景
大規模言語モデル（LLM）のコンテキストウィンドウが200Kから1Mへと大幅に拡大したことが背景にある。これにより、AIエージェントの設計や利用方法に関する従来の「常識」が通用しなくなり、より高度な設計判断が求められるようになった。本記事は、この技術的進化に伴う実務的なガイドラインを提供している。
重要用語解説
- コンテキストウィンドウ: LLMが一度に処理できる情報（トークン数）の最大容量。1Mは100万トークンを指し、大量の情報を一度に参照可能にすることを示す。
- Compaction: コンテキストウィンドウ内で使用されたトークンを自動的に整理・圧縮し、重要な情報だけを残すプロセス。コンテキストの「ノイズ」を減らす目的がある。
- Smart Zone: コンテキストウィンドウの容量全体ではなく、精度が最も高く維持されると推定される領域（本記事では容量の約40%）を指す。容量が大きくても、このゾーンを超えると精度が落ちるリスクがある。
今後の影響
LLMの利用設計は、単なる「容量の大きさ」から「コスト効率」と「情報の選別（Context Engineering）」へと重点が移る。開発者は、コンテキストを最大限に活用するだけでなく、どの情報を、どのタイミングで、どのモデル（Haiku/Opus）で処理するかという戦略的な判断がより重要になる。これにより、AIエージェントの設計がより複雑化し、専門的な知識が求められるようになる。