この投稿は、言語モデルを使った開発が、プロンプトに適した言葉や言い回しを見つけることから、より広い問いに答えることへと移りつつあると論じる。その問いとは、どのようなコンテキストの構成がモデルの望ましい振る舞いを最も生み出しやすいか、というものである。投稿はこの実践を コンテキストエンジニアリング と名づけ、プロンプトエンジニアリング の自然な発展として位置づける。プロンプティングがモデルに与える指示に関わるのに対し、コンテキストエンジニアリングは推論時に存在するトークンの集合全体 — システム指示、ツール、外部データ、メッセージ履歴のすべて — に関わる。
投稿の中心的な主張は、コンテキストは収穫逓減を伴う有限の資源であるというものである。投稿は コンテキストロット について needle-in-a-haystack 形式のベンチマークを引き、その理由を説明する枠組みとして アテンション予算 を提示する。Transformer のアテンションは n 個のトークンに対して n² 個のペアの関係を生み出し、訓練データの分布は短いシーケンスに偏っており、コンテキスト長を延ばす手法はある程度の精度を犠牲にする。ここから投稿は指針となる原則 — 望ましい結果の可能性を最大化する、シグナルの強いトークンの可能な限り小さな集合を見つけること — を導き、それがシステムプロンプト、ツール、例にとって何を意味するかを順に論じる。
後半は、取得と、コンテキストウィンドウに収まりきらないタスクへと話題を移す。投稿は、この分野が埋め込みベースの推論前の取得から ジャストインタイムのコンテキスト取得 へと、しばしば両者のハイブリッドとして移行しつつあると述べ、長期にわたる作業のための 3 つの手法 — コンパクション、構造化ノートテイキング、サブエージェントアーキテクチャ — を示す。全体を通して、Claude Code が具体例として用いられている。
要点
- コンテキストエンジニアリングとは、LLM の推論中に最適なトークンの集合をキュレーションし維持するための戦略の集合であり、プロンプトエンジニアリングの自然な発展である。これは 2 つの用語の関係についての Anthropic 自身の捉え方である。
- コンテキストロット — コンテキストウィンドウ内のトークン数が増えるにつれて想起の精度が低下すること — はすべてのモデルで現れるが、劣化が緩やかなモデルもある。投稿はこれを needle-in-a-haystack 形式のベンチマークに関する研究に基づくものとしている。
- LLM には有限のアテンション予算があり、投稿はその原因を、Transformer のアテンションにおける n² 個のペアの関係、短いシーケンスが支配的な訓練データの分布、そして位置エンコーディングの補間がもたらすトークン位置の精度の低下に求めている。その結果は、急な崖ではなく性能の勾配として説明されている。
- 良いコンテキストエンジニアリングとは、望ましい結果の可能性を最大化する、シグナルの強いトークンの可能な限り小さな集合を見つけることである。
- システムプロンプトは適切な高度に置かれるべきである — 脆いハードコードされた if-else のロジックと、共有されたコンテキストを誤って前提とする曖昧なガイダンスとの間に。これは、Anthropic が実際に目にしていると報告する 2 つの失敗モードに基づく、投稿自身の推奨である。
- 過剰な機能を網羅したり、曖昧な判断ポイントを生み出したりする肥大化したツールセットは、Anthropic が報告する最もよくある失敗モードの 1 つである。ある状況でどのツールを使うべきかを人間のエンジニアが明確に言えないのであれば、エージェントにそれ以上を期待することはできない。
- few-shot の例は、プロンプトに詰め込まれたエッジケースの羅列ではなく、多様で典型的な事例を厳選した集合であるべきである。
- 投稿はエージェントについて単純な定義 — ループの中で自律的にツールを使う LLM — を採用しており、これに落ち着いてきたと述べ、Anthropic の外部の定式化に由来するものとしている。
- エージェントが軽量な識別子を保持し、実行時にデータを読み込むジャストインタイムのコンテキスト取得こそ、投稿がエンジニアリングの実践の向かう先と見ているものであり、事前の取得と実行時の取得のハイブリッドが最も効果的な構成であることが多いとする。示される根拠は、Anthropic 自身の製品での経験と、同社が顧客の間で観察していることである。
- より大きなコンテキストウィンドウがこの問題を解消するとは見込まれていない。投稿は、当面の間、最も強いエージェント性能が求められる場面では、あらゆるサイズのウィンドウがコンテキスト汚染と情報の関連性の問題にさらされ続けると論じる。
- コンパクション、構造化ノートテイキング、サブエージェントアーキテクチャは、それぞれ異なる形のタスクに適している — 順に、広範なやり取り、明確なマイルストーンを伴う反復的な開発、そして並列の探索が効果を発揮する複雑な調査である。
- より賢いモデルほど規定的なエンジニアリングを必要としなくなるため、投稿はエージェントの設計が人間によるキュレーションを次第に減らす方向に向かうと見込んでいる。それでも変わらない助言は「うまくいく最も単純なことをせよ」である。
背景
この投稿は Anthropic の Applied AI チームによって書かれ、例を Anthropic 自身の製品から取っているため、その推奨は主に、測定による比較ではなく、同チームのエンジニアリング経験と、顧客とともに作業する中で観察したと報告する事柄に基づいている。投稿は自らを、ベンチマークの集合ではなく、制御可能で効果的なエージェントを構築するための洗練されたメンタルモデルを提供するものとして提示しており、そのガイダンスが制御された結果ではなくチームの観察に由来することを明言している。主張のいくつかは、内容を改めて述べる代わりにリンクしている以前の文章 — コンテキストロット、ツール設計、同社自身のマルチエージェントの取り組み、そして採用しているエージェントの定義について — に依拠しているため、それらの点の裏付けは投稿自体には示されていない。