ai-agents-for-beginners

AIエージェントのためのコンテキストエンジニアリング

(上記の画像をクリックするとこのレッスンの動画が視聴できます)

AIエージェントを構築するアプリケーションの複雑さを理解することは、信頼できるエージェントを作る上で重要です。プロンプトエンジニアリングを超えた複雑なニーズに対応するために、情報を効果的に管理するAIエージェントを構築する必要があります。

このレッスンでは、コンテキストエンジニアリングとは何か、そのAIエージェント構築における役割について見ていきます。

はじめに

このレッスンで扱う内容は以下の通りです：

• コンテキストエンジニアリングとは何か、そしてそれがプロンプトエンジニアリングとどう違うのか。

• 効果的なコンテキストエンジニアリングの戦略、包括的に書き方、選択、圧縮、分離の方法。

• AIエージェントを脱線させる可能性のある一般的なコンテキストの失敗例とその対処法。

学習目標

このレッスンを終えた後、以下のことが理解できるようになります：

• コンテキストエンジニアリングを定義し、それをプロンプトエンジニアリングと区別できる。

• 大規模言語モデル（LLM）アプリケーションにおけるコンテキストの主要な構成要素を特定できる。

• エージェントの性能を向上させるために、コンテキストの書き方、選択、圧縮、分離のための戦略を適用できる。

• 毒性、注意散漫、混乱、衝突などの一般的なコンテキストの失敗を認識し、緩和技術を実装できる。

コンテキストエンジニアリングとは何か？

AIエージェントにとって、コンテキストとはAIエージェントが特定の行動を取る計画を推進するものです。コンテキストエンジニアリングとは、AIエージェントがタスクの次のステップを完了するために必要な正しい情報を持っていることを保証する実践です。コンテキストウィンドウはサイズが制限されているため、エージェント開発者は情報の追加、削除、凝縮を管理するシステムやプロセスを構築する必要があります。

プロンプトエンジニアリング vs コンテキストエンジニアリング

プロンプトエンジニアリングは静的な単一の指示セットに焦点を当て、AIエージェントを効果的に指導するためのルールセットを作ります。一方、コンテキストエンジニアリングは、初期のプロンプトを含む動的な情報セットを管理し、時間の経過とともにAIエージェントが必要とするものを確実に持つようにする方法です。コンテキストエンジニアリングの主な考え方は、このプロセスを再現可能で信頼できるものにすることです。

コンテキストの種類

コンテキストは単一のものではないことを忘れてはいけません。AIエージェントに必要な情報は様々なソースから来る可能性があり、それらのソースにアクセスできるようにするのは私たちの責任です：

AIエージェントが管理する必要がある可能性のあるコンテキストの種類には以下が含まれます：

• 指示: これはエージェントの「ルール」のようなもので、プロンプト、システムメッセージ、少数ショット例（AIに方法を示す）、使用可能なツールの説明を含みます。ここでプロンプトエンジニアリングとコンテキストエンジニアリングの焦点が交差します。

• 知識: これは事実、データベースから取得された情報、あるいはエージェントが蓄積した長期記憶を含みます。エージェントが異なる知識ストアやデータベースにアクセスする必要がある場合は、Retrieval Augmented Generation (RAG)システムの統合も含まれます。

• ツール: これはエージェントが呼び出せる外部関数、API、MCPサーバーの定義と、それらを使ったときに得られるフィードバック（結果）です。

• 会話履歴: ユーザーとの継続的な対話です。時間が経つにつれて会話は長く複雑になり、コンテキストウィンドウのスペースを取ります。

• ユーザーの好み: 時間をかけて学習されたユーザーの好き嫌いの情報です。これらは保存され、重要な意思決定時に呼び出されてユーザーを支援します。

効果的なコンテキストエンジニアリングの戦略

計画戦略

良いコンテキストエンジニアリングは良い計画から始まります。以下のアプローチはコンテキストエンジニアリングの概念適用を思考し始めるのに役立ちます：

明確な結果を定義する - AIエージェントに割り当てられるタスク結果は明確に定義する必要があります。「AIエージェントがタスクを完了した後、世界はどうなっているのか？」という問いに答えます。つまり、ユーザーがAIエージェントと対話した後に得る変化、情報、反応は何かを明らかにすることです。
コンテキストのマッピング - 結果を定義したら、次に「AIエージェントはこのタスクを完了するためにどんな情報が必要か？」という問いに答えます。これにより、その情報がどこにあるかコンテキストをマッピングできます。
コンテキストパイプラインの作成 - 情報の所在が分かったら、「エージェントはどうやってこの情報を手に入れるか？」という問いに答えます。これは、RAGの利用、MCPサーバーや他のツールの活用など様々な方法で行えます。

実践戦略

計画は重要ですが、情報がエージェントのコンテキストウィンドウに流れ込み始めたら、それを管理する実践的な戦略が必要になります：

コンテキストの管理

一部の情報は自動的にコンテキストウィンドウに追加されますが、コンテキストエンジニアリングはより積極的にこれらの情報を操作することが求められ、いくつかの戦略で実行できます：

エージェントスクラッチパッド これはAIエージェントが1回のセッション中の現在のタスクやユーザーインタラクションに関する関連情報をメモする機能です。これはコンテキストウィンドウの外側にあり、ファイルやランタイムオブジェクトとして存在し、必要に応じて後からそのセッション中にエージェントが取り出せます。
メモリーズ スクラッチパッドは単一セッションのコンテキスト外で情報を管理するのに適しています。メモリーズはエージェントが複数セッションにわたり関連情報を保存・取得できるようにします。これには要約、ユーザーの好み、将来の改善のためのフィードバックなどが含まれます。
コンテキストの圧縮 コンテキストウィンドウが大きくなり制限に近づくと、要約やトリミングの手法を使えます。最も関連性の高い情報だけを残すか、古いメッセージを削除します。
マルチエージェントシステム マルチエージェントシステムの開発は、それぞれのエージェントが独自のコンテキストウィンドウを持つため、一つのコンテキストエンジニアリングの形態です。どのようにそのコンテキストが共有・受け渡されるかを計画する必要があります。
サンドボックス環境 エージェントがコードを実行したり、ドキュメント内の大量情報を処理する必要がある場合、結果を処理するのに大量のトークンを消費します。これらすべてをコンテキストウィンドウに格納する代わりに、このコードを実行し結果やその他関連情報のみを読み取るサンドボックス環境を利用できます。
ランタイムステートオブジェクト これは、エージェントが特定情報にアクセスする必要がある状況を管理するために情報のコンテナを作成することです。複雑なタスクの場合、サブタスクごとの結果を段階的に保存することで、その特定のサブタスクにのみ結びついたコンテキストを維持できます。

コンテキストの検査

これらの戦略のいずれかを適用したら、次のモデル呼び出しで実際に何が渡されたのかを確認する価値があります。役立つデバッグの質問は：

エージェントは過剰なコンテキスト、間違ったコンテキスト、必要なコンテキストの欠落のどれかを読み込んだか？

この質問に答えるために、未加工のプロンプトやツールの出力、メモリ内容のログは必要ありません。運用環境では、カウント、ID、ハッシュ、ポリシーラベルといった小さなコンテキスト検査レコードを好んで使います：

選択: 候補チャンク、ツール、メモリがいくつ考慮され、いくつ選ばれたか、またどのルールやスコアが他をフィルターアウトしたかを追跡。
圧縮: ソース範囲またはトレースID、要約ID、圧縮前後の推定トークン数、次の呼び出しから未加工コンテンツが除外されたかを記録。
分離: 別のエージェント、セッション、サンドボックスで実行されたサブタスク、返されたバウンデッドサマリー、大きなツール出力が親エージェントのコンテキスト外に留まったかを記録。
メモリとRAG: 取得ドキュメントID、メモリID、スコア、選択ID、編集状態を完全取得テキストの代わりに保存。
安全性とプライバシー: 機密性の高いプロンプトテキスト、ツール引数、ツール結果、ユーザーメモリ本文の代わりに、ハッシュ、ID、トークンバケット、ポリシーラベルを優先。

目的はより多くのコンテキストを保持することではありません。開発者がどのコンテキスト戦略が実行され、次のモデル呼び出しに意図通りに影響を与えたかを判断できるだけの十分な証拠を残すことです。

コンテキストエンジニアリングの例

例えば、AIエージェントに 「パリへの旅行を予約して」 と頼むとします。

• プロンプトエンジニアリングだけを使う単純なエージェントは、単に「分かりました、パリにはいつ行きたいですか？」 と答えるでしょう。その時点でユーザーが尋ねた直接の質問だけを処理します。

• コンテキストエンジニアリングの戦略を適用するエージェントはそれ以上のことをします。応答する前に、システムは：

◦ あなたのカレンダーを確認して空いている日を調べる（リアルタイムデータの取得）。

◦ 過去の旅行の好みを思い出す（長期記憶から）、例としては好みの航空会社、予算、直行便の好みなど。

◦ フライトやホテル予約のための利用可能なツールを特定。

そして、例としての応答はこうなります：「こんにちは[あなたの名前]さん！10月の第1週は空いていますね。[好みの航空会社]の直行便で、いつもの予算[予算]内でパリに向かう便を探しましょうか？」。このような豊かでコンテキストに配慮した応答は、コンテキストエンジニアリングの力を示しています。

一般的なコンテキストの失敗

コンテキストポイズニング

何か: ハルシネーション（LLMによって生成された誤情報）やエラーがコンテキストに入り込み、それが繰り返し参照されることで、エージェントが不可能な目標を追ったり、意味のない戦略を展開する状態。

対策: コンテキスト検証と検疫を実装する。情報が長期記憶に追加される前に検証を行う。潜在的なポイズニングが検出されたら、新しいコンテキストスレッドを開始して悪い情報の拡散を防ぐ。

旅行予約の例: エージェントが小さな地方空港から遠く離れた国際都市への直行便が実際には存在しないのに幻覚として生成し、この存在しないフライト情報がコンテキストに保存されます。後に予約を頼むと、その不可能な経路のチケットを探し続けて繰り返しエラーが起きます。

解決策: フライト情報をエージェントの作業コンテキストに追加する前に、リアルタイムAPIでフライトの存在と経路を検証するステップを実装。検証が失敗した場合、その誤った情報は「検疫」され、それ以上使用されません。

コンテキストの注意散漫

何か: コンテキストが大きくなりすぎて、モデルが蓄積された履歴に過剰に注目し、訓練で学んだことを活用できなくなり、繰り返しや役に立たない行動を取る。モデルはコンテキストウィンドウが満杯になる前からミスをし始めることがあります。

対策: コンテキストの要約を使う。蓄積情報を定期的に短い要約に圧縮し、重要な詳細を残し不要な履歴を削除して「リセット」効果を持たせる。

旅行予約の例: 長期間にわたり様々な夢の旅行先の話をし、2年前のバックパッキング旅行の詳細まで話しています。最終的に「来月の安いフライトを探して」 と頼むと、エージェントは古くて無関係な詳細に埋もれ、バックパッキングの装備や過去の旅程について尋ね続け、現在の要求を無視してしまいます。

解決策: あるターン数を超えたりコンテキストが大きくなったら、エージェントは最近の会話の最も関連する部分を要約し、現在の旅行日程や目的地に焦点を当てた圧縮された要約を次のLLM呼び出しに使い、不要な過去の会話は破棄します。

コンテキストの混乱

何か: 不要なコンテキスト、特に利用可能なツールが多すぎる場合にモデルが悪い応答を生成したり関係のないツールを呼び出す。特に小規模モデルで起こりやすい。

対策: RAG技術を使ったツールのロードアウト管理を実施する。ツール説明をベクターデータベースに保存し、特定タスクに最も関連性の高いツールのみを選択する。研究では30未満に制限することが推奨されている。

旅行予約の例: あなたのエージェントは多数のツールにアクセス可能：book_flight, book_hotel, rent_car, find_tours, currency_converter, weather_forecast, restaurant_reservationsなど。あなたが「パリの移動に最適な方法は？」と尋ねると、多数のツールのためエージェントは混乱し、パリの中でbook_flightを呼び出したり、公共交通機関を好むのにrent_carを呼び出そうとしたりします。これはツールの説明が重複するか、最適なものを識別できないためです。

解決策: ツール説明に対するRAGを使用。パリの移動について尋ねたとき、システムはあなたのクエリに基づきrent_carやpublic_transport_infoのような最も関連性の高いツールのみを動的に取得し、LLMに焦点を絞ったツールの「ロードアウト」を提示します。

コンテキストの衝突

何か: コンテキスト内で矛盾する情報が存在し、一貫性のない推論や悪い最終応答につながる。これは情報が段階的に到着し、初期の誤った仮定がコンテキストに残っている場合に起こりやすい。

対策: コンテキストプルーニングとオフローディングを使用する。プルーニングは新しい詳細が到着した際に古くて矛盾する情報を削除すること。オフローディングはモデルに別の「スクラッチパッド」作業スペースを与えて、メインコンテキストを乱さず情報を処理できるようにします。

旅行予約の例： 最初にエージェントに「エコノミークラスで飛びたい」と伝えます。会話の途中で気が変わり、「実は今回の旅行はビジネスクラスにしましょう」と言います。両方の指示がコンテキストに残っていると、エージェントは矛盾した検索結果を受け取ったり、どちらの希望を優先すべきか混乱したりする可能性があります。

解決策： コンテキストの剪定を実装します。新しい指示が古い指示と矛盾する場合、古い指示がコンテキストから削除されるか、明示的に上書きされます。あるいは、エージェントはスクラッチパッドを使って矛盾する希望を調整し、最終的に一貫した指示だけがエージェントの行動を導くようにします。

コンテキストエンジニアリングについてもっと質問がありますか？

他の学習者と交流したり、オフィスアワーに参加したり、AIエージェントに関する質問に回答してもらうために、Microsoft Foundry Discordに参加しましょう。

前のレッスン

Agentic Protocols

次のレッスン

Memory for AI Agents

免責事項：本書類は AI 翻訳サービス Co-op Translator を使用して翻訳されています。正確性を期していますが、自動翻訳には誤りや不正確な部分が含まれる可能性があることをご承知おきください。原文の原語版が正式な情報源とみなされるべきです。重要な情報については、専門の人間による翻訳を推奨します。本翻訳の利用により生じたいかなる誤解や解釈違いについても、当方は責任を負いかねます。

This site is open source. Improve this page.