はじめに
2025年はAIエージェント元年とも言われ、これまでの1問1答的なチャット利用の範囲から、より複雑な業務を任せていくAIエージェントのユースケースが多くなりました。
従来は、いわゆる「プロンプトエンジニアリング」の重要性が繰り返し指摘されていましたが、より複雑なAIエージェントの形となる中で、プロンプトエンジニアリングを含む広範な概念として「コンテキストエンジニアリング」が提唱され、現在はAIエージェント開発におけるメインストリームとなっています。
プロンプトエンジニアリングは知っているが、コンテキストエンジニアリングはざっくりとしか理解していない。。という方に向けて、今回は、今後もAIエージェント開発の肝となっていくコンテキストエンジニアリングのコンセプトと、その重要性についてまとめていきます。
コンテキストエンジニアリングとは
Context Engineeringがトレンドとなったきっかけは、AI界の重鎮である Andrej Karpathy氏による以下のツイートです。
https://x.com/karpathy/status/1937902205765607626
ここでAndrej Karpathy氏は、プロンプトエンジニアリングに留まらず、LLMのコンテキストに何を入れるかを設計する技術としてコンテキストエンジニアリングの重要性を指摘しています。
コンテキストエンジニアリングに含まれる要素の概観を掴むには、Google Deep MindのPhilipp Schmid氏による以下の図がわかりやすいでしょう。
従来のプロンプトエンジニアリングはシステムプロンプトとユーザープロンプトの指示をどう作るかという話でしたが、プロンプトエンジニアリングに加え、短期記憶や長期記憶、RAG、ツール、構造化出力なども含めた広範な概念としてコンテキストエンジニアリングが説明されています。
コンテキストエンジニアリング自体はあくまで概念であるため明確な定義はなく、その中で議論される構成要素や技術的なアプローチも常に移り変わっていきます。
そのため、コンテキストエンジニアリングについては、一段抽象化して本質的な意味を捉えておいたほうが、全体の理解も速くなる上、今後の変化に対するキャッチアップも楽になるでしょう。
車を全く知らない人が車について勉強する時に、車には、エンジン、アクセルとブレーキ、ハンドル、ワイパーがあって・・・と、一つ一つの構成要素を覚えていく事は非常に効率が悪く、車は「人を乗せて遠くまで移動するための物」という事を理解すれば、その動力となるエンジン、運転するためのアクセルとブレーキ、雨が降った時のためのワイパーなどの必要性が自然と理解できるでしょう。
そうすれば、カーナビやチャイルドシートなど、車が発明された当初はなかった新しい物が出てきた時も、その必要性から逆算して自然とキャッチアップできます。
では、コンテキストエンジニアリングとは一体何かというと、コンテキストエンジニアリングとは要するに「AIエージェントが働く環境作り」の事です。ポイントになるのは、AIの能力をいかに最大限引き出す環境を作れるかという事であり、この点をもう少し直感的に理解できるように考えていきましょう。
AIを擬人化して考える
AIの話にすると論点がずれがちになるので、ここでは擬人化して考えてみましょう。
あなたの会社でとてつもなく優秀な人材が採用できたとします。経歴もスキルも文句なしでやる気もある優秀な人材で、おそらく社内の誰よりも優秀なのでは？とあなたも内心思っています。そして、この優秀な人材があなたの直属の部下となりました(ここからは便宜的に彼とします)。彼はとてつもなく優秀ですが、入社初日なので会社内部の事や業務については当然何も知りません。
彼の能力を最大限引き出すにはどうすれば良いでしょうか？
ここでまず、上司の動きとして最悪なケースは「何も必要な情報を渡さない」という事です。実際こういう方もいると思いますが、「優秀だから何でもできるだろう」と思って、業務等について何の説明もなくいわば放置するような形です。
彼は優秀なのでやる気がありますが、そもそもこの職場で何が求められているのか、やって良い事とダメな事は何なのか、誰が何の業務をしていて誰に聞けばいいのかという事がわからず、ただただ困惑してしまいます。一挙手一投足がフレーム問題のようになり、ある種最も当たり障りのない行動しかできなくなるでしょう。
これでは宝の持ち腐れなのですが、次にNGとなるケースは、先ほどとは逆に「あらゆる情報を渡してしまう」という事です。
社内の組織情報、社内のシステムについても全て説明し、他部署も含む社内の全てのドキュメントも参照できるようにしました。社内データベースの全データへのアクセス権も付与したので、ある種彼に手が届かない情報はありません。
ではこれで彼が問題なく業務を遂行できるようになるかというと、何も情報を渡さないよりはまだましですが、これでもまだ上手く動けません。なぜなら今度は逆に「選択肢が多すぎる」からです。
どのタイミングで誰に聞くのが適切なのか、どのシステムを参照すべきなのか、ドキュメントから参照すべきなのかデータベースから抽出すべきなのかなど、あらゆる選択肢の中で、取りうる行動の種類が多すぎるため逆に動けなくなってしまいます。
おそらく彼は非常に優秀なので、試行錯誤しながら何とか前に進もうと頑張ると思いますが、当たりに対して外れの割合が明らかに多いため、ほとんどが手戻りのリサーチ地獄のような形になるでしょう。
選択肢が多すぎるという事は、同時に調査・検討時間の増加と手戻りの可能性を増やす事になるため、必ずしも働きやすい環境とは言えません。
では、彼がその非常に高い能力を存分に発揮するためにはどうすれば良いでしょうか？
まずは、業務の目的を共有します。これはそもそも誰のために実施する何のための業務なのか、品質はどの程度のレベルが求められていて、時間はどの程度かけて良いのか、やってよい事とやってはいけない事などの業務の全体感を共有します。
その上で、業務の基本的なフローを共有します。
業務は大きく5つのステップからなり、ステップ1では、Aシステムからまずは基本データを抽出し、データベースBの値と照合、ステップ2では、このシステムCとウェブサイトDを使って調査・分析を実施、ステップ3では、過去の社内情報をフォルダD内のドキュメントを参照して・・・という形で業務フローの概要とその時々で使うべきシステム、また参考となる情報を説明します。XXで困った時は〇〇さんに聞いてというような情報も非常に助けになるでしょう。
そして、最終アウトプットはパワーポイントで、社内のデザインカラーはこれを利用、役員向けの資料なので抽象度は高めで、前回の資料がこれなのでこれを参照して作成して欲しいとまで指示してあげれば一気に業務の解像度が上がります。
もちろん彼は優秀なので、一挙手一投足のレベルまで指示する必要はありません。ある程度の幅を決めてあげれば、その中で最善と思われる選択を取りながら、わからない所は勝手に進めずに質問もしてくれるでしょう。
自分が部下の立場でも、何も指示されない、または関係ない情報も含めあらゆる情報を渡される上司に比べ、上記のように適切な情報を与えてくれる上司がいる環境は非常に働きやすいと感じるでしょう。そして、これがコンテキストエンジニアリングの本質になります。
つまり、人間の優秀な部下においても、必要な情報を必要なタイミングで適切に渡してあげる事が非常に重要であるのと同様に、AIに対しても、適切な情報を適切なタイミングで利用できるように導いてあげる事、その場を整えてあげる事がコンテキストエンジニアリングになります。
そう考えると、コンテキストエンジニアリングに出てくる構成要素が自然に理解できるようになります。
まず、システムプロンプトは上記の目的にあたり、大上段の方針の共有になります。そして、ユーザープロンプトはもう一歩具体化した指示内容になります。
短期記憶は自分のそれまでの行動や結果を記憶するために当然必要で、長期記憶は業務横断のベストプラクティス・ナレッジ集のような位置付けとして機能します。
必要に応じて関連情報を取得するためにRAGの仕組みがあり、社外情報・Web検索などを含め、特定の作業を支援してくれるツール、そして最終アウトプットがどのような形式なのかという事を指定する構造化出力の仕組みがあります。
上記には出ていませんが、チームとして協業して特定のタスク自体を任せるという事であればサブエージェントの仕組みも当然出てくるでしょう。
このようにLLMが一度に持てる情報(コンテキストウィンドウのサイズ)は限られているので、その中でどのタイミングでどの情報を渡すかという事が重要であり、これは人間が一度に情報処理できる量に限りがあるのと同じ話です。
いわば、コンテキストエンジニアリングで最も重要になるのは、情報の足し算ではなく、情報の「引き算」です。
「AIエージェントは自律的に自分で判断しながら、情報を取捨選択して業務を遂行していく」と聞いてあらゆる情報やツールを渡そうとしてしまうケースが多いのですが、この足し算の戦略は上手くいきません。
MCPがかなり話題になった時も、とにかく色んなツールをMCPで繋げば、AIエージェントが何でもできるようになる喧伝される風潮がありましたが、これはただただAIに解かせる問題を難しくしているだけで、AIのパフォーマンス低下に繋がります。
優秀な部下が働きやすい環境を提供してあげるのと同様に、いたずらに情報を足すのではなく、適切なタイミングで適切な情報が利用できる環境を作ってあげる事がコンテキストエンジニアリングの本質であり、AIエージェント開発の肝になります。
自身のユースケースを踏まえ「どうすればAIエージェントが働きやすい環境が作れるか？」という事を考えれば、自ずとそれぞれの必要な技術要素には辿り着く上に、まだ出ていないアプローチの検討も可能になるでしょう。
コンテキストエンジニアリングはある種のアート
直感的にはわかりやすいですが、あくまで概念であるため何が正解なのかという事はわかりません。ベストプラクティスは色々とありますが、それらを全て採用すればAIエージェントの品質が向上するという単純な話でもありません。
Andrej Karpathy氏がコンテキストエンジニアリングはいわばアートだと指摘しているように、AIエージェント開発は設計者の総合芸術のような形になりつつあります。
そもそもAIを踏まえた上で業務フローはどうするべきか、人間との役割分担、自動化の割合はどの程度を狙うか、ユーザーとのやり取りのUXはどうすべきかなど、正しく検討を進めていけば、コンテキストウィンドウの話だけに留まらず、そもそもLLMで処理すべきかどうかも含めた検討が必要になります。これはそれぞれ独立に進められるものではなく相互に深く関連した領域になります。
業務ドメインの知識も当然必要ながら、AIエージェントの利用箇所を見極めながらフロー全体を組み上げていく設計力、AIエージェントの内部設計力、必要となる参照情報自体も整備するデータエンジニアリングのスキルなど、アーキテクトとしてかなりのバランス感覚と総合力が求められます。
これがAIエージェントがPoC止まりでなかなか実用レベルに至る事が少ない理由の一つです。プロンプトエンジニアリングやAIの実装ができるだけでは不十分で、AIの力を最大限引き出せるような全体設計が重要になります。
つまり、LLMの利用領域においては、AIエンジニアに求められる力はAIが働く環境作りであると言えます。
AIは適切な環境さえ用意してあげれば、人間には出せない速度と品質で業務を遂行してくれます。どんなスーパーカーもボロボロで舗装されていない道路を速く走る事はできません。
コンテキストの病理学
Google DeepMindのPhilipp Schmid氏は、上述の記事の中で、「AIエージェント開発における8割の失敗が文脈情報の欠落に起因する」と述べています。これは単に情報を多く渡せば良いという点ではない事について、少し深掘っておきましょう。
重要な概念として「コンテキストの病理学」という4つのポイントが以下の記事で説明されています。
1. Context Poisoning（コンテキスト汚染）
これは、誤った情報が一度コンテキストに入り込むと、その誤情報が後続の推論で何度も参照され続けてしまい、本来求めていた結果とは異なる行動をAIエージェントが取ってしまうという事です。
DeepMindのGemini 2.5でポケモンをプレイする実験において、間違ったゲーム状態や達成不可能な目標を一度コンテキストに含めてしまうとその目標を前提に意味不明な戦略を延々と繰り返すという事象がおきました。
Context は記憶であり、AIエージェントの指針となるため、一度誤った情報が入ると、誤りが修正されにくく、時間とともに増幅するという課題があります。
これはある種当たり前ですが、雑多な情報をAIエージェントに渡してしまうと、意図せずその中に実質的な誤りが含まれていた場合、AIエージェントは論理的に明らかにおかしいと判断できない限りはその情報を参照して行動してしまいます。
コンテキストに含む情報においては量以上にその質が重要になります。
2. Context Distraction（コンテキスト過多による注意散漫）
AIに一度に多すぎる情報を詰め込むと、たとえそれらの情報がすべて関連していても、膨大なコンテキストが最も核心的な指示を埋もれさせ、AIが重要な点を掴めない状態になります。
いわゆるLost in the Middleで指摘されているように、コンテキスト最大長と実用上まともに推論できる長さは別物になるので、とにかくコンテキストに情報を詰め込めば良いという事ではなくむしろ逆効果になります。
これは、部下の前に大量の関連資料を山積みにすると、むしろ最も重要な情報が見つけられない事と同等であり、なるべく必要な情報を最小限渡す必要があります。
3. Context Confusion（不要情報による混乱）
これはコンテキストに関係ない情報やツール定義を入れすぎるとモデルがそれらを意味があるものとして扱ってしまい性能が低下するという現象の事です。
MCPでのツール接続における実験で、1つのツールだけを渡した場合と、不要なツールも含め複数のツールも渡した場合では、後者の場合、全モデルで性能が低下するという現象が見られました。
コンテキストに入れたものは、モデルにとって無視できない情報であるため、ただただノイズが付加された形になります。
部下に対して、関係のない情報を含めとにかく共有しようとする方が時々いますが、関係のない情報はノイズでしかなく、むしろ情報過多により判断が鈍るため、パフォーマンスの低下に繋がります。
4. Context Clash（コンテキストの衝突）
これはコンテキスト内の情報同士がそもそも矛盾しており、競合しているようなケースです。
RAGなどでも注意が必要ですが、バージョン管理が正しくされていないドキュメントで新しい情報と古い情報を読み取ってしまう場合、そもそもの参照情報自体が矛盾しているため、AIエージェントが適切な判断を下せなくなります。
皆さんも整理されていない社内ドキュメントなどで、同じ内容に対する資料が複数あり、どちらが正なのかよくわからないという経験をした事があるのではないでしょうか。
とにかくたくさん情報を渡した方が良いと考え、既に無効になっているドキュメントもAIエージェントの参照対象にしてしまうと、古い情報も含めて引っ張ってきてしまい、判断自体ができないか、先にヒットした情報を正として処理してしまいます。
ドキュメントやツールを含め、データを参照させる場合は、その先にある情報にそもそも矛盾がないかを担保しておく必要があります。
まとめ
いかがだったでしょうか？
AIエージェントの「自律」という言葉に過度に引っ張られ、多数の情報やツールを一挙に渡してしまう事は、既に見てきたようにAIエージェント開発においては最も避けるべき手段になります。
AIエージェント開発の肝であるコンテキストエンジニアリングは、適切なタイミングで適切なコンテキストをAIエージェントに渡す事、またAIエージェントが自ら参照できる状態を整える事であり、これは人間と同様にAIエージェントが働きやすい環境作りに他なりません。
いわばアートであり、業務プロセスやデータ整備も含むいわば総合芸術のような領域となっていくため、コンサルタント・アーキテクトの腕の見せ所になるでしょう。
更に、業務サイドとしても、部下への指示が的確でマネジメントの上手い方がプロジェクトマネージャーになると、良いAIエージェントの構築に繋がるのではないでしょうか。 AIエージェントの設計・開発は、要件定義から運用まで一気通貫で支援しています。もう少し詳しい話を聞いてみたいという方はこちらからどうぞ。
