同じモデルに同じような質問を投げているのに、うまく運ぶ日とそうでない日があります。
AIエージェントを動かしていると、その不安定さに何度も出くわします。
原因をプロンプトの言い回しに求めて何度も書き直しても、手応えは薄いままです。
効いているのは文章の巧拙より、その瞬間にモデルの目の前へ何が並んでいるかのほうだからでしょう。
この視点に名前を付けたのがコンテキストエンジニアリングという言葉です。
プロンプトエンジニアリングの次に来た考え方
Anthropic は「推論のあいだ、最適なトークンの集合を選び、保ち続けるための戦略」と定義しています。
Effective context engineering for AI agents（Anthropic）
対象になるのは、プロンプト文だけではありません。
システムプロンプト、ツールの定義、過去のやり取り、検索で引いた文書、読み込ませたファイルも含まれます。
モデルへ届くトークンはすべてひっくるめて「コンテキスト」であり、その配合そのものを設計対象として扱うのがこの考え方になります。
一問一答で終わる使い方なら、良いプロンプトを書ければ十分でした。
ところが何十ターンも回るエージェントでは、問いが「どう書くか」から各ステップで何を載せておくかへ移ります。
同社はこの流れを、プロンプトエンジニアリングの自然な発展形として位置づけていました。
全部入れれば賢くなる、とはならない
コンテキストウィンドウが広がった今、迷ったら全部入れればよさそうにも思えます。
けれど実際には、詰め込むほど精度が落ちる現象が知られています。
Anthropic はこれを context rot（コンテキストの腐敗）と呼び、トークン数が増えるほど性能が劣化すると説明していました。
理屈はTransformerの構造に由来します。
n個のトークンがあれば関係の組み合わせはnの2乗に膨らみ、同じ注意力を薄く引き伸ばすことになります。
だからモデルには attention budget（注意の予算）があり、トークンは限られた資源で、増やすほど一つあたりの効き目が落ちる、と整理されています。
容量の上限と、実質的に使える量は別物だと考えておくと判断を誤りません。
つまり狙いは「窓を埋めること」ではなく、いちばん効くトークンだけを残すことになります。
長い作業を支える三つの手筋
では、何十分も走り続けるエージェントはどうやって窓を保つのでしょうか。
公式の解説では、実際に使われている手筋が三つ挙げられています。
一つ目はコンパクションです。
上限に近づいたら会話履歴を要約し、設計上の決定や未解決の論点だけを残して、冗長なツール出力を捨てます。
二つ目は構造化されたメモ取りです。
NOTES.md のような外部ファイルへ進捗を書き出し、窓の外に記憶を置くやり方です。
三つ目はサブエージェント構成です。
調査や検索といった作業を別のエージェントへ切り出し、親には要約だけを返させます。
どれも発想は同じで、窓を広げるのではなく、窓へ持ち込む前に減らすという方向を向いていました。
何を載せるかを決める三つの材料
日々の設計で触るのは、だいたい次の三か所になります。
- システムプロンプト … 固すぎる条件分岐と、曖昧すぎる精神論の間を狙う
- ツール定義 … 役割が重なる道具を並べない
- 例示 … 網羅ではなく、期待する振る舞いを代表する少数を選ぶ
システムプロンプトは、細かく場合分けを書き込むほど壊れやすくなります。
かといって「丁寧に判断して」とだけ書けば、共有されていない前提を勝手に補われてしまいます。
Anthropic はこの中間を Goldilocks zone と表現し、行動を導ける程度に具体的で、なお柔軟な指示を薦めていました。
ツールも同じで、似た機能が二つ並ぶと「どちらを呼ぶか」で迷いが生まれます。
例示は数を競うより、代表的な数例を丁寧に選ぶほうが効くと書かれていました。
いずれも「足す」より「選ぶ」の話になっているところが、この分野らしい部分です。
最後に
コンテキストエンジニアリングは、プロンプトを磨く技術の延長ではなく、モデルに何を見せるかを毎ターン決める設計の話でした。
窓が広がっても注意の予算は有限で、詰め込むほど薄まります。
だから長い作業では、要約・外部メモ・サブエージェントで窓に入れる前に減らすという手が取られています。
私も自分のエージェントを組むとき、まず「この情報は毎ターン必要か」を問い直すところから見直すようになりました。
毎回書いて渡していた手順そのものを外へ出す方法は、Agent Skills の記事で整理しています。
以上です。
コメントを残す