AIコンテキストエンジニアリングとは、エージェントを取り巻く情報、制約、指示のすべてを設計し、エージェントが何を見られるのか、何をすべきなのか、新しい状況や不足したデータに直面した際にどう行動するのかを理解できるようにすることだ。Stack OverflowのエンジニアリングディレクターであるDoug Whitleyと、プロダクトディレクターであるAsh Zadeの説明によれば、目的は利用可能なデータをすべてエージェントに与えることではなく、予測可能な結果を伴うタスクを完了するために必要な、限定されたコンテキストを提供することにある。
これはStack Overflow Blogが「No Dumb Questions」シリーズの一環として公開した対談で語られたもので、コンテキストエンジニアリング、コンテキストインフラストラクチャ、コンテキストエンジニアリングの違いに加え、これらの概念とRAGおよびMCPという2つの技術との関係、そして企業がすべてを社内で構築するのではなく、既製のソリューションを購入する理由について議論された。
インフラストラクチャからエンジニアリングへ
Whitleyは、コンテキストインフラストラクチャとコンテキストエンジニアリングを区別している。前者はコンテキストをどのように保存し、表示し、エージェントに提供するかに関係する。一方、後者はシステムの設計と、その構成要素を特定の方法で整理する理由に焦点を当てる。実行面でのコンテキストエンジニアリングは、アルゴリズム、プログラミング言語、使用するツールの選択など、実際にシステムを構築することに関係する。
Whitleyは、RAGをこの3つのレベルが交わる領域に位置付けている。インデックス、コンテキストストア、検索方法はインフラストラクチャの側面を表し、.NET、Python、Rustなどの言語でシステムを構築することはエンジニアリングの側面を表す。一方、アーキテクチャはシステム全体の形と、その動作方法を規定するルールを定める。MCPについては、Whitleyは特定の要件を持つプロトコルだと捉えているが、それをシステムに統合するかどうか、どの言語を使うか、どの機能に対応させるかは、いずれも設計上の判断である。
エージェントが下す判断の範囲を狭める
Zadeは、自動車のタイヤを探す例を使ってこの考え方を説明している。エージェントを図書館に送り、「タイヤ」を検索させると、航空機、自転車、手押し車に関する情報も見つける可能性がある。これらはすべて、要求された単語に一致するためだ。しかし、適切に設計されたシステムは、最初からタスクが自動車用タイヤ、あるいは特にスポーツカー用タイヤに関するものだと定め、利用できる情報をその範囲に限定する。
Zadeは、こうした指示をテキストプロンプトだけに記載しても、エージェントがそれに従う保証にはならないと考えている。そのためコンテキストエンジニアリングでは、エージェントがアクセスできるデータを制御するとともに、不完全または不正確な情報に直面したときに何をするかを定める必要がある。このようにして、エージェントの判断からいくつかの変数を取り除き、情報が信頼できるか、検索範囲を広げるべきかをエージェント自身に判断させないようにする。
この仕組みにはエージェントのメモリも含まれる。エージェントがこれまでに完了したこと、学習したこと、やり取りしたこと、構築したものを保持できるようにするためだ。複数のエージェントが動作する場合や、タスクがいったん停止して後で再開される場合、このメモリの重要性はさらに高まる。
信頼性、権限、人間による介入
両氏によれば、Stack Internalは、コンテキストを信頼性の仕組みと専門家による検証フローに結び付ける例である。知識は高、中、低の信頼度に分類され、信頼度が中または低の場合、エージェントが不確かな知識に基づいて判断するのではなく、ユーザーをその分野の専門家に誘導して、情報を検証したり不足を補ったりできる。
データ保護は、エージェントが特定の情報を見られるかどうかという問題にとどまらない。その情報がユーザーには利用可能でも、エージェントが実行するタスクには適さない場合がある。そのため両氏は、2つの制御レベルを説明している。
- ソース権限：エージェントは、Slack、MS Teams、Google Drive、SharePointなど、検索対象となるシステムでユーザーの権限を引き継ぐ。
- 範囲：ユーザーは、より広いデータセットへのアクセス権を持っている場合でも、エージェントが利用できるデータの範囲を狭められる。
- 新しいデータ：エージェントが作成したりシステムに返したりする内容を制限できる。まずユーザーに送信し、一般的なナレッジベースに自動的に追加したり、チームと共有したりしないようにできる。
この区別は、コンテキスト管理が検索だけに関係するのではなく、エージェントが作成するメモリと知識の制御も含むことを示している。
なぜ企業はソリューションを構築するのではなく購入するのか？
Whitleyは、コンテキストエンジニアリングを構築することは可能だが、課題はコードを書くことだけではないと述べている。企業がSlack、MS Teams、Google Drive、SharePoint、Confluence、GitHub、Jiraからデータを集める場合、どのようにインデックス化、フィルタリング、再ランキングを行うか、そして矛盾した情報、不足した情報、不正確な情報にどう対処するかを決めなければならない。
Zadeは、作業の大部分は信頼性そのものを定義することに関係すると考えている。熟練したユーザーは、AIの出力が自分の期待や過去の経験と一致するとき、その出力を信頼できるかもしれない。しかし、この方法は、AIに依頼する分野の専門知識を持たない人には同じ程度には利用できない。そのため、この仕組みには、情報を集めるための技術的なソリューションだけでなく、何が情報を信頼に値するものにするのかについての議論も必要になる。
Whitleyはさらに、既製のソリューションを購入すれば、他の顧客が直面した問題から蓄積された知見を得られる可能性があると述べている。そこにはエッジケースや日常的な問題も含まれ、彼によれば、チームはそれらをおよそ20のカテゴリーに分類しているという。ただし、両氏は社内構築を否定していない。ユースケースが新しい場合や、企業が独自の設計判断を必要とする場合には、社内構築が適している可能性がある。
WhitleyとZadeにとって、コンテキストエンジニアリングの品質は、システムの柔軟性と、一貫性があり予測可能な出力を提供する能力によって測られるのであって、単一のタスクに範囲を狭めることだけによって測られるのではない。また、情報を早い段階でフィルタリングすれば、エージェントが処理するトークン数を減らせる可能性がある。自動車の本を検索する方が図書館全体を検索するより低コストであり、タイヤのページを検索する方が本をすべて確認するより低コストだからだ。最終的な目標は、エージェントが想定されたタスクを実行できるようにし、越えるべきでない限界に達したときには停止するか、人間の支援を求めるようにすることである。