はじめに
AIがタスクをこなす上で、全く的外れなことをすることがあるのはなぜだろうと思ったことはありませんか？
実はそれはAIの賢さやシステムプロンプトだけの問題ではなく、コンテキストが関係しています。
今回はAnthropicが発表した、AIエージェント開発における新しいアプローチコンテキストエンジニアリングについて解説しつつ実践的なアプローチも紹介していこうと思います。
そもそもコンテキストとは
AIの世界では、コンテキストとはモデルが応答する前に「見る」すべてのものです。それはユーザーからAIに対する指示だけではなく、以下のようなものが含まれます。
- ユーザーとの過去の対話履歴
- 外部知識（例：ドキュメント、DB、検索結果）
- システムの状態や実行ツール情報
- エージェントがこれまでに取ったアクションや判断
など、AIの判断や応答に影響を与えるすべての背景情報 の総称です。
人間同士の会話でも「前提を共有しているかどうか」で会話の質が変わるように、AIでもコンテキストがどれだけ充実しているかでアウトプットの質が左右されます。
適切なコンテキストがなければ、最新の大規模言語モデル（LLM）でさえ、何をすればいいかわからなくなってしまいます。
コンテキストエンジニアリングは、AIを正しく動作させるためにこれらの情報をキュレーションすることです。
コンテキストエンジニアリングとは
なぜコンテキストエンジニアリングは重要なのか
従来のプロンプトエンジニアリングは主に一度の動作の最適化に焦点を当てていました。しかし、AIエージェントは複数のターンにわたって推論を続け、動的に情報を取得します。この違いは決定的です。
ですが、エージェントは複数の回数ループを繰り返していくことがあります。
その中で増え続けていく情報から何を渡すのか決めていく必要があります。
AIエージェントを構築する上でなぜ重要になるのか
ではなぜこのようなコンテキストエンジニアリングが、AIエージェントを構築する上で重要になってくるのでしょうか。実は、LLMには人間のように集中力のようなものがありモデルごとにその集中力の上限が決まっています。コンテキストを与えれば与えるほど情報は追加できますが、モデルの集中力は減っていくとされています。
下記はそれを示した図になります
そしてモデルの集中力がなくなった時にコンテキストの劣化・腐敗(以降腐敗と言います)といった現象が発生するとされています。
これにより与えた情報を思い出せなくなったり、正答率の低下などLLMがタスクを実行する上で重要な影響があるといえます。
また、この現象はさまざまなモデルでも同様に発生します。
コンテキストの腐敗のペースはそれぞれですが、どのモデルでも一定の箇所でスコアが下がっていることからこの現象はモデルの性能などに依存せず、LLMそのものの性質になっています。
なぜコンテキストの腐敗が発生するのか
ではなぜこのコンテキストの腐敗といった現象が発生するのか。もう少し詳しくみていこうと思います。
多くはLLMがトランスフォームアーキテクチャに基づいていることが原因となります。（トランスフォームアーキテクチャは以下を参照。）
ざっくりいうと、各トークンが全ての他のトークンを参照するようになります。LLMはそれらの関係性を全て追うので、コンテキストが増えれば増えるほど追う関係性は増えていきます。例えば、ここでのトークン数を n とすると、トークン間の関係は n²になります。
例：
- 1,000トークン → 約100万の関係
- 10,000トークン → 約1億の関係
このようにコンテキストが長くなるほど、モデルが追いかける関係性が爆発的に増え、コンテキストの腐敗が進んでいきます。
性能の劣化問題について
ここで気をつけたいのは、ある長さを超えたら突然ダメになるのではなく、徐々に精度が落ちていくという点です。
だからこそ、「なんとなく動いているな〜」と感じたり、「なんか動いてるけど正確さや一貫性が微妙やな〜」といった事象がおきてしまいます。
コンテキストエンジニアリングの重要性について
ここまで述べた内容を考慮して、AIエージェントを構築する上でコンテキストが重要であると理解できたかと思います。その際は、以下の点を意識すべきです。
- 情報を闇雲に詰め込まない
- 何を・どの順序で・どの粒度で渡すか意識する
- 不要な情報をどう捨てるか
これらのコンテキストエンジニアリングが、能力の高いAIエージェントには不可欠になってきます。
アプローチの具体例
では、実際にどのような具体的なアプローチが考えられるのか、今回はAnthropicがブログ内で触れているアプローチを紹介していこうと思います。
コンテキストの要約
長くやり取りを続けていると、どうしてもコンテキストが膨らんできます。
そのまま続けると、重要な情報が埋もれてしまい、精度が落ちていきます。
そこで使われるのが、途中までのやり取りを要約して、あらためて続ける という方法です。
- これまでの会話や作業内容をまとめる
- 設計の決定事項や未解決の問題は残す
- 古いログやツールの出力は捨てる
Claude Code では、この要約をモデル自身に作らせ、
要点だけを新しいコンテキストとして引き継いでいます。
「全部を覚え続ける」のではなく、必要な情報だけを整理して持ち直す という考え方です。
構造化メモを使用する
もう一つよく使われるのが、重要な情報をコンテキストの外に保存する というやり方です。
たとえば、
- 進捗メモ
- TODO リスト
- 途中までの結論や判断理由
などを、ファイルやストレージに書き出しておきます。
こうしておけば、
- コンテキストを圧迫しない
- セッションを跨いでも状態を引き継げる
- 必要になったら再度読み込める
という状態を作れます。
Anthropic の記事では、これを agentic memory と呼んでいますが、
やっていること自体はメモを取って保存しておくに近いです。
サブエージェントを使う
これは最もメジャーな例かもしれませんね笑
タスクが複雑になってくると、1つのエージェントにすべてをやらせるのは厳しくなります。（その分コンテキストが肥大化するため）
そこで、役割を分けるというアプローチが出てきます。
こうすることで、細かい探索の文脈をメイン側に持ち込まずに済みます。
また、コンテキストを適切に分散させることができるのでそれぞれのエージェントが適切に応答できるようになります。
結果として、
- コンテキストが肥大化しにくい
- 並列に作業を進めやすい
- 全体像を見失いにくい
といったメリットがあります。
こういったマルチエージェントな構成はStrandsAgentとかだと簡単にできるので嬉しいですね！
さいごに
ここまででコンテキストエンジニアリングについてまとめてみました。
コンテキストエンジニアリングという言葉は少し大げさに聞こえますが、やっていること自体はそこまで特別なものではありません。
Anthropic の記事を読んでいても、「モデルをどう使うか」以前に情報をどう整理し、どう渡すか が重要だという話が繰り返し出てきます。
AIエージェントがより賢くなっていくほど、「全部をモデルに任せる」のではなく、モデルが動きやすい形を用意する ことの比重は大きくなっていくはずです。
この記事が、エージェントを作るときに「コンテキストをどう扱うか」を考えるきっかけになれば幸いです。
参考