「コンテキストエンジニアリング」という言葉自体は、もうこのサイトでも何度か扱ってきた。だが、その一次情報——Anthropic公式が実際にどう定義しているか——はまだ読んでいなかった。答えは明快で、コンテキストは容量の話ではなく有限の注意力予算の話だった。
Anthropic公式が定義する「コンテキストエンジニアリング」の中身と、ツール数の絞り込み・サブエージェントへの隔離・その場検索という3つの具体的な間引き手法。
以前「プロンプト設計の時代は終わった」という記事で、海外の実践者たちの間で争点がプロンプトからコンテキスト管理に移っている、という話を扱った。今回読むのは、その言葉の一次情報にあたるAnthropic公式のエンジニアリングブログだ。
公式の定義はシンプルだ。コンテキストエンジニアリングとは、モデルがタスク完了までの各ステップで、次のトークンを生成するために「見えている」情報の集合を最適化する作業を指す。プロンプトの言葉選びを工夫する「プロンプトエンジニアリング」の、さらに一段上の設計層という位置づけになる。
この記事のいちばんの核心は、コンテキストを「容量」ではなく「予算」として捉え直している点にある。
コンテキストウィンドウが大きくなっても、問題は解決しない。トークンを詰め込めるかどうかより、モデルがその中の重要な情報にどれだけ注意を向けられるかが結果を左右する。
無関係な情報や古い情報が混ざり込むほど、モデルは本当に必要な部分を見失いやすくなる。公式ブログはこれをコンテキストの劣化として明確に問題視している。「念のため全部渡す」がむしろ逆効果になりうる、という指摘だ。
限られた予算をどう配分するかという設計問題である以上、これは一回きりの工夫ではなく、タスクの種類ごとに繰り返し調整する継続的な設計作業になる。
ここが核心。コンテキストウィンドウは容器ではなく予算だ。多く積めば良い結果が出るわけではなく、何を積んで、何を積まないかの判断そのものが精度を左右する。
公式ブログが挙げる手法は、抽象論だけでなく実装レベルまで具体的だ。個人開発の規模でもそのまま応用できるものを3つ抜き出す。
MCPサーバーを何個も繋ぎ、ツール定義をすべて常時読み込ませる構成は、それだけでコンテキストの予算を消費する。今のタスクに必要な範囲だけを有効にする設計が推奨されている。
大きな調査や大量のログ読み込みは、メインの会話とは別のサブエージェントに切り出し、要約だけをメインに戻す。メインの文脈を汚さずに済む、という発想はClaude Code自体の設計思想とも重なる。
関連しそうなファイルを最初から全部渡すのではなく、必要になった時点でモデル自身に検索・取得させるJust-in-time方式。結果として渡る情報量は減るが、的中率は上がる。
ここからはAnthropic公式の説明と、私がこのページの加筆案を作るために行った小規模な比較実験を分けて扱う。対象タスクは「この記事の弱点を特定し、削除なしで追加できる検証案を提案する」。同じ指示を、渡す資料だけ変えて3回実行した。
今回の1回では、Bの適量条件が9/10点で最高だった。Aは記事内の不足を正しく指摘したが、根拠が記事本文に偏った。Cはサイト全体の課題まで広げた一方、Art28への具体的な提案が薄くなり、不要な推測も増えた。
この結果は1回の小規模実験であり、モデル・温度・指示文・タスクが変われば結果も変わりうる。サブエージェントの実行環境がないため、今回は同一モデルで条件ごとの入力を分離して実施した。再現用の入力一覧、出力、採点表は記事と同じ管理フォルダに保存している（外部公開を意味しない）。
以前の記事で挙げた「タスク分割・状態のファイル化・文脈の間引き」に、公式の裏付けが加わった形になる。今日から見直せる範囲だけ挙げる。
出典: Anthropic Engineering — Effective context engineering for AI agents