Anthropicが提唱する「Context Engineering」- プロンプトエンジニアリングの次の段階
元記事
Effective context engineering for AI agents - Anthropic Engineering Blog
なぜ今話題になっているのか
Anthropicが10月に公開したこの記事は、Hacker Newsで147ポイントを獲得し、AI開発者コミュニティで活発な議論を巻き起こしています。特にShopify CEOのTobias Lütkeがこのコンセプトについてツイートしたことで、「Context Engineering」という言葉が一気に業界の注目を集めました。
興味深いのは、多くの開発者がコメント欄で「これは実務で直面している問題そのものだ」と共感している点です。あるエンジニアは「各社がコンテキスト管理の重要性について語るのに、まともなツールを提供している企業がひとつもない」と指摘し、100以上の「いいね」を集めています。
実際の数値として、Anthropicはこの手法で39%のパフォーマンス向上と84%のトークン削減を達成したと報告しており、これは単なる理論ではなく実用的な価値があることを示しています。
どんな内容？
簡単に言うと、「プロンプトエンジニアリング」から「コンテキストエンジニアリング」へのシフトを提案する内容です。
従来のプロンプトエンジニアリングは「どういう指示文を書くか」に焦点を当てていました。一方、コンテキストエンジニアリングは「LLMに渡すトークン全体をどう最適化するか」という、より広い視点で考えます。
記事では「Context Rot」という現象を紹介しています。これはコンテキストが長くなるにつれて、LLMが情報を思い出す能力が低下する現象です。Transformerアーキテクチャはトークン間でN²の関係性を作るため、コンテキストが長くなると計算コストが指数関数的に増えていきます。
前にマルチターンの会話エージェント作った時、履歴を全部詰め込んだらレスポンスタイムが5秒超えて使い物にならなくなった経験があるんですが、これってContext Rotが原因だったのかもしれません。
開発者が注目しているポイント
Hacker Newsのコメント欄で特に議論が盛り上がったのは、実装上の課題についてです。
「コンテキストの20%以上を使わないようにしている」という開発者のコメントが印象的でした。長いコンテキストウィンドウがあっても、実際には使い切らない方がパフォーマンスが良いという実体験に基づく意見です。これ、本当にそうで、200kトークンのウィンドウがあっても40k程度に抑えた方が安定するんですよね。
記事が提案する3つの長期タスク対応手法について、多くの開発者が実践的な価値を認めています：
- Compaction（圧縮）: 会話履歴を要約してコンテキストを節約
- Structured Note-Taking（構造化メモ）: 重要情報をコンテキスト外に保存
- Sub-Agent Architectures（サブエージェント）: 専門特化したエージェントに作業を委譲
特にサブエージェントのアプローチは実際のマイクロサービスの考え方に近いですね。前にモノリシックなエージェント作ったら、ツール選択の精度が落ちて困ったことがあります。今思えば、サブエージェントに分割すれば良かったのかも。
実用性の考察
すぐに使える具体的なアドバイスもいくつかありました。
システムプロンプトの書き方では、XMLやMarkdownで明確にセクション分けすることを推奨しています。複雑すぎず、曖昧でもない、「適切な高度」での指示が重要とのこと。
ツール設計については、「肥大化したツールセットは最もよくある失敗パターン」と指摘されています。これは本当に共感できて、以前20個くらいツールを渡したらLLMが適切なツール選択できなくなって、結局8個に絞ったらうまくいった経験があります。
Just-in-timeアプローチという概念も面白いです。最初から全データを詰め込むのではなく、軽量な識別子を使って必要なタイミングで動的にデータを読み込む方式。ただ、これって実装するとなると、データ取得のレイテンシとコンテキスト削減のトレードオフをどう評価するか悩みそうです。
実装面での課題として、OpenTelemetryを使ったトレーシングの必要性や、DSPyのようなプロンプト最適化ツールの活用が議論されていました。ただ、ある開発者が「コンテキストエンジニアリングの具体的戦略は現状、企業の企業秘密になっている部分が多い」と指摘していたのが印象的でした。
料金面での影響も無視できません。トークン使用量を84%削減できるということは、月100万円のAPI費用が16万円になる計算です。特に大規模なエージェントシステムを運用している場合、この差は相当大きいはずです。
所感
正直、記事を読んで最初に思ったのは「これって当たり前のことじゃない？」でした。
でも、自分がこれまで実装してきたエージェントを振り返ると、Context Rotの存在を知らずにコンテキスト詰め込みすぎてパフォーマンス劣化させてたり、ツールセットを肥大化させて精度落としてたり、結構やらかしてます。
Anthropicがやったのは、多くの開発者が経験的に「こうした方が良い」と感じていたことを、きちんと体系化して再現可能な手法として提示したことです。N²の計算コストの話とか、「認知リソース」というメタファーとか、理論的な裏付けがあると実装判断しやすくなります。
ただ、「既存のパイプラインにどう組み込むか」が一番の課題かもしれません。Compactionやサブエージェント化って、アーキテクチャの大幅な変更が必要になるケースも多そうで、リファクタリングコストとのバランスをどう取るか。
あと、この記事で触れられてないのが、マルチモーダル入力（画像とか）が入ってきた時のコンテキスト管理です。画像1枚で数千トークン消費するから、Context Engineeringの重要性はさらに高まりそうですが、そのあたりのベストプラクティスはまだ確立してない気がします。
とはいえ、当面は「コンテキストは貴重で有限なリソース」という考え方が、AI開発の基本になりそうです。Shopify CEOが反応したのも納得で、実際に大規模システムを運用している人ほど、この記事の価値が分かるんだろうなと思います。
Discussion