まずは簡単な仕事から始めよう:会議の日程調整だ。
ユーザーから "明日、すぐに同期できるか試してみよう "と言われたら?
プロンプト・エンジニアリングだけに頼るAIなら、「はい、明日で結構です。何時に予定しますか?" と答えるかもしれない。 この返答は正しいが、現実世界の理解が欠けているため、機械的で役に立たない。
カレンダーは明日のスケジュールが埋まっていることを示し、相手とのメール履歴はあなたのコミュニケーション・スタイルがインフォーマルであることを示唆し、コンタクト・リストは相手を重要なパートナーとしてマークし、AIは直接ミーティングの招待状やメールを送ることができるインストゥルメンタル・アクセスを持っている。
その時点で、「ヘイ、ジム!調べてみたら、明日のスケジュールは完全に埋まっているんだ。木曜日の午前中なら空きがあるようですが、ご都合はいかがですか?もしよければ、招待状を送ります」。
この違いは、2番目のAIモデルがそれ自体「より賢い」からではなく、より完全な「コンテキスト」にあるからである。単一命令の最適化から動的な情報環境の構築へのこのパラダイムシフトは、今日のAIアプリケーション開発における最も重要な進化である。
コンテクスチュアル・エンジニアリングとは何か?
ラージ・ランゲージ・モデル(LLM)は新しいタイプのオペレーティング・システムのようなもので、そのコンテキスト・ウィンドウはRAMである。コンテキスト・エンジニアリングの核となる仕事は、このRAMを効率的に管理し、各操作の前に最も重要な情報を入れることである。
より工学的な定義はこうだ:コンテクスチュアル・エンジニアリングとは、大規模な言語モデルに対して、問題解決のための適切な情報やツールを適切なタイミングで適切な形式で提供する動的なシステムを設計・構築する学問分野である。
それが管理する "コンテクスト "は、3次元7次元のシステムである:
- 指示する。 AIの行動規範とアイデンティティに関するシステムレベルの手がかりを定義する。
- ユーザープロンプト。 ユーザーから寄せられた具体的な問題や課題。
- 短期記憶(状態/歴史)。 現在の対話の対話履歴は、対話の継続性を保証する。
- 長期記憶。 ユーザーの好みなど、複数の会話にまたがる永続的な知識。
- 取得した情報 RAGのような手法を通じて、外部からリアルタイムで得た知識。
- 利用可能なツール。 AIが呼び出せる関数やAPIのリスト。
- 構造化された出力。 JSONを返すリクエストなど、AIの出力形式の定義。
なぜ文脈が重要なのか?失敗の4つのモード
Agentシステムのパフォーマンスが悪い場合、その根本的な原因はコンテキスト管理の問題であることがよくあります。長すぎるコンテキストや低品質なコンテキストは、通常、次の4つの障害モードにつながります:
- 文脈中毒。 誤った情報や、モデルの錯覚によって生み出された情報が文脈に入り込み、その後の判断を汚染する。
- コンテクスト・ディストラクション。 余分な情報が多すぎると、コアとなる指示の内容が埋もれてしまい、モデルがミッションの目的から逸脱してしまう。
- 文脈の混乱。 文脈のあいまいな部分や不必要な部分が、最終的なアウトプットの精度に影響する。
- 文脈の衝突 文脈のさまざまな部分で、事実上あるいは論理上の矛盾がある。
これらの課題に体系的に対処するため、開発者たちはコンテキストを管理するための4つの中核戦略を考え出した。
コンテクスチュアル・エンジニアリングのコア戦略
1.書き込み:情報を外部ストレージに保存します。
「Write "は、エージェントが限られたコンテキストウィンドウの外でメモを取り、重要な情報を保存する機能を提供することです。
- スクラッチパッド。 タスク内の短期記憶の一種。例えば
Anthropic
この研究により、その "ヴェニュー "が、"ヴェニュー "であることが示された。LeadResearcher
エージェントは複雑なタスクを実行する前に、考え抜かれたプランを外部メモリに「書き込み」、コンテキストの過負荷によってコアプランが失われるのを防ぐ。 - 思い出だ。 エージェントがセッションをまたいで情報を記憶できるようにします。エージェントと同じように
ChatGPT
メモリー機能、開発ツールCursor
歌で応えるWindsurf
そのすべてに、ユーザーとのインタラクションに基づいて長期記憶を自動的に生成し、保存するメカニズムが含まれている。
2.選択:関連するコンテキストをオンデマンドでウィンドウに取り込む
"選択 "は、膨大な外部情報から現在のタスクの最も重要な部分を選び出し、適切なタイミングでコンテキストウィンドウに配置する役割を担う。
- 特定のファイルから選択してください。 成熟したエージェントの中には、特定のファイルを読むことでコンテキストを取得するものもある。例えば
Claude Code
と読みます。CLAUDE.md
ファイルとCursor
その代わりに、ルール・ファイルをコーディング仕様の読み込みに使用する。これは、「手続き記憶」を選択する効率的な方法である。 - ツールセットから選択する。 多数のツールが利用可能な場合、RAGテクノロジーは手元のタスクに最も関連性の高いツールを動的に検索して「選択」し、ツール選択の精度を数倍に高める。
3.圧縮:必要なものを残し、冗長性を減らす
「圧縮」は、重要な情報を失うことなく、コンテキストが占めるトークン数を減らすことを目的としている。
- 文脈の要約。 対話の履歴が長くなりすぎた場合は、LLMを呼んで要約してもらうこともできる。
Claude Code
その典型的な例が「オート・コンパクト」機能で、コンテキストの使用量が95%を超えると、完全な会話履歴が自動的に要約される。 - コンテキスト・トリミング。 ルールベースのフィルター。最も単純なアプローチは、単に対話の最も初期のラウンドを削除することであるが、より高度なアプローチは、特別に訓練された「コンテキスト・プルナー」モデルを使用して、重要でない情報を特定し、削除する。
4.分離:複雑なタスクに対処するためにコンテキストを分割する
分離」の核となる考え方は「分割と征服」であり、異なるコンテキストが分離された環境で処理されるように、大きなタスクを分解することである。
- マルチエージェント。 複雑なタスクを、独立したコンテキストウィンドウを持つ複数のエキスパートエージェントに分解します。
Anthropic
は、複数のサブエージェントが並行して作業するチームが、研究タスクにおいて、巨大なコンテキストを持つ単一のエージェントをはるかに凌駕することを発見した。 - サンドボックス化された環境。 コード実行タイプのタスクでは、実行プロセスをサンドボックス内に隔離することができる。
HuggingFace
なCodeAgent
は、LLMがコードの生成を担当し、サンドボックス内でコードが実行された後、最もクリティカルな実行結果のみがLLMのコンテキストに返され、完全な実行ログは返されない例である。
コンテキスト・エンジニアリングのためのツール:LangGraphとLangSmith
上記のような複雑な戦略を実現するには、十分に柔軟で制御可能なフレームワークが必要だ。LangChain
生態系における LangGraph
歌で応える LangSmith
そのために強力なサポートが用意されている。
ラングラフ は、制御されたエージェントを構築するための低レベルフレームワークです。エージェントのワークフローをステートチャートとして構築し、コンテキストエンジニアリングのニーズに完全にマッチするように設計されています:
- 状態オブジェクト。 完璧な "ステージング・エリア"(書き込み用)として、またコンテキストの "分離 "エリアとして機能する。ステートに様々なフィールドを定義することができ、そのいくつかはLLMに公開され、いくつかは必要に応じて "選択的に "使用される内部ステートとなる。
- 持続と記憶。 内蔵のチェックポイント機能とメモリー・モジュールによって、短期記憶と長期記憶の「書き込み」と「選択」が簡単にできる。
- カスタマイズ可能なノード。 ダイアグラムの各ノードは、プログラム可能なステップです。ツールを起動した直後に結果を要約するなど、ノードに「圧縮」ロジックを簡単に実装できます。
- マルチ・インテリジェント・ボディ・アーキテクチャー。
LangGraph
以下のような情報を提供する。supervisor
歌で応えるswarm
CMSのようなライブラリーは、複雑なマルチインテリジェンスシステムの構築をネイティブにサポートし、コンテクストの「分離」を可能にする。
ラングスミス これはObservabilityプラットフォームです。通常のアプリケーションをデバッグするように、エージェントの意思決定プロセスの各ステップを明確にトレースすることができます。これにより、コンテキストエンジニアリングの診断と最適化に不可欠な洞察が得られ、Eval機能を通じて最適化戦略の有効性を検証することができます。
キュー・エンジニアリングの「錬金術」からコンテクスチュアル・エンジニアリングの「システム科学」まで、これはテクノロジーの進化であるだけでなく、信頼性が高く強力なAIアプリケーションを構築するための必然的な道でもある。この技術をマスターすることは LangGraph
歌で応える LangSmith
このようなツールは、AIエンジニアのコアコンピテンシーになりつつある。