- 「プロンプトエンジニアリング」から一歩進んだ 「コンテキストエンジニアリング」へと議論が移行 している
- コンテキストとは単なるプロンプト文ではなく、LLMが回答を生成する前に参照できるあらゆる情報（指示、会話履歴、長期メモリ、外部情報、利用可能なツールなど） を意味する
- エージェントの成功と失敗は今や モデルの性能よりもコンテキストの質に左右される
- 高度化したエージェント は、ユーザーのカレンダー、過去のメール、連絡先など多様な文脈を統合し、より実際の問題解決に近い応答を生成する
- コンテキストエンジニアリング は 状況に応じた動的なシステム設計 であり、適切な情報とツールを正確なタイミングでLLMに提供するプロセスである
Context Engineeringとは何か
- 最近、AI分野で 「コンテキストエンジニアリング」 という用語が急速に広がっている
- 従来の 「プロンプトエンジニアリング」 が単一の質問や命令文の設計に集中していたのに対し、コンテキストエンジニアリングはそれよりも広範で強力なアプローチである
- Tobi Lutkeはこれを「LLMが作業を信頼できる形で解けるよう、あらゆるコンテキストを提供する技術」と定義している
コンテキストの主要要素
- エージェントシステムがうまく機能するかどうかは、作業メモリ（working memory）にどの情報が含まれるか に大きく左右される
- エージェントの失敗の大半はモデルの問題ではなく、適切なコンテキストの不足 が原因である
コンテキストの構成要素
- システムプロンプト／指示: モデルの振る舞いを定義する基本指示、例、ルールなど
- ユーザープロンプト: ユーザーの直近の要求や質問
- 状態／会話履歴: 現在までの会話の流れと文脈情報
- 長期記憶: 複数段階にわたる過去の会話、ユーザーの好み、過去プロジェクトの要約、モデルが長期的に記憶するよう学習された情報の集まり
- RAG（検索拡張生成）: 外部文書、データベース、APIなどから取得した最新で関連性の高い情報
- 利用可能なツール: モデルが呼び出せる関数、組み込みツールの定義（例: check_inventory, send_email など）
- 構造化出力: モデルが従うべき応答形式の定義（例: JSON）
コンテキストが重要な理由
- 実際に 効果的なAIエージェントを作る要因 は、複雑なコードやモデル品質ではなく、どれだけ適切なコンテキストを提供できるか にある
- 単純な「デモ用」エージェントはユーザーの要求だけを受け取って基本的な応答しか返さない一方、「魔法のような」エージェントは豊富なコンテキストを考慮して、はるかに有用で人間らしい返答を生成する
- 比較
- 低品質（デモ）エージェント: 単純な依頼だけを見て、型どおりの返答しか生成しない。例: 「明日お時間ありますか？」というメールに「明日は可能です。何時がよろしいですか？」のような機械的な返答をする
- 高品質（魔法のような）エージェント: 自分のカレンダー、過去のメール履歴、相手の身元情報、必要なツール呼び出しの選択肢まで活用し、自然で状況に合った返答を生成できる。例: 「明日は予定が埋まっていて、木曜の午前が空いているので招待をお送りしました。ご都合がよければお知らせください」
- このように、アルゴリズム やモデルが重要なのではなく、作業に合った正しいコンテキストを提供することが成功要因である
- AIエージェントの失敗の大半はモデルではなく、コンテキスト設計の失敗 の結果である
プロンプトエンジニアリングからコンテキストエンジニアリングへの進化
- プロンプトエンジニアリングが1行のテキスト指示の最適化に焦点を当てるのに対し、コンテキストエンジニアリングははるかに広い範囲の情報、ツール、構造的設計を含む
- コンテキストエンジニアリングとは、「必要な情報とツールを、適切な形式とタイミングで、LLMがタスクを達成できるよう体系的に提供するための設計・構築の専門能力」である
コンテキストエンジニアリングの特徴
- システム全体の設計: コンテキストとは単なるプロンプトテンプレートではなく、LLM呼び出し前に動作するシステム全体の成果物である
- 動的生成: タスクに応じて、カレンダー／メール／Web検索などさまざまな情報をリアルタイムで選択・加工する
- 必要な情報とツールを適切なタイミングで提供: 「Garbage In, Garbage Out」の原則どおり、モデルに不要な情報や欠落した情報がないようにすることが重要である
- 形式の明確さが重要: 情報を投入する際は散漫に並べるのではなく、要約・構造化が必要であり、ツールの使い方も明確に伝えなければならない
結論
- 強力で信頼できるAIエージェント開発 の本質は、「魔法のようなプロンプト」や最新モデルではなく、コンテキストエンジニアリング（コンテキストの設計と提供） にある
- これは単なる技術的課題を超え、ビジネス要件と目的に合った情報・ツール・構造化出力の定義など、全方位的なシステム設計能力が必要 となる
- LLMが課題を完遂できるよう、正確なタイミングで適切な情報を正しい形式で提供すること が核心である
参考資料
2件のコメント
名前だけが変わっている感じが強いですね。
Hacker Newsのコメント
私は最近このテーマについてブログを書いたことがあるので、私の記事 - Context Engineeringを参照してほしい
Drew Breunigの記事はこのテーマを本当に見事に扱っていると思う
タイミング的にはたまたま「context engineering」というミームが広まっていた時期だったが、実際にはそのミームとは無関係に取り組んだもの
How Long Contexts Fail - 長いコンテキストが失敗する理由では、長いコンテキストがどのように問題を引き起こすのか、いわゆる「context rot」がどう発生するのかをさまざまな形で説明している
How to Fix Your Context - あなたのコンテキストを修正する方法では、Tool Loadout、Context Quarantine、Context Pruning、Context Summarization、Context Offloading など、さまざまなテクニックに名前を付けて問題の解決策を提示している
Drew Breunigの投稿はぜひ読む価値があると思う
これは自分でエージェントを作る場合だけでなく、今エージェントコーディングを使うときにも本当に重要
こうした限界や挙動はしばらく続く見込み
誰が最初に context エンジニアを自動化する Logic Core を開発するのか楽しみ
これもまた**「1か月もののスキル」**だと思う
結局は多くの他の流行と同じように、すぐ消えるだろう
こうした問題はLLM研究の世界では、現行LLMの産物と見なされている
すでに何百万ものツールを同時に使い、安定したロングコンテキストを扱う方法の研究が進んでいる
今後は、他プロバイダーとの接続が必要な特殊ケースを除けば、たいていは1つのエージェントだけで十分になるだろう
現行LLMを前提に未来のエージェントシステムを設計している人たちは、LangChainのようになる可能性が高い
GPT-3向けに作られたLangChainが、GPT-3.5でたちまち時代遅れになったのと同じこと
LLMを使ったことがある人や、LLMがどう動くか知っている人にはかなり自明な話
プロンプトエンジニアリングという「スキル」も、一時的な目玉であって長続きしないのは明らかだった
基本的には、LLMに入力（コンテキスト）と行動（出力）を与えること、そしてそのために多くのパイプライン作業が必要という話
「強力で信頼できるAIエージェントの構築は、魔法のプロンプトやモデル更新探しから離れていく」という結論には同意する
「適切な情報とツールを、適切なフォーマットとタイミングで提供するコンテキストエンジニアリング」にもっと集中すべきというのはその通り
しかし、その「適切なフォーマット」と「適切なタイミング」が本質的に定義されていないなら、結局はまだ「魔法の解」を追っているのではないか
「適切な情報」が「LLMに十分正確な答えを出させる情報」だというなら、本質的にプロンプトエンジニアリングと違いはないと思う
こうした非決定的なマシンには、結局「プロンプトを試して結果を見る」という以外に信頼できるヒューリスティックはあまりない
結局は終わりなき魔法的思考
今「プロンプトエンジニアリング」を「コンテキストエンジニアリング」に言い換えても、結局は不確実な空間の中で効く何かを見つけるためにあれこれいじり続ける行為
本質的にはオーバーフィッティング
プロンプトエンジニアリングとは結局それ
「適切なフォーマット、適切なタイミング」が本質的に定義されていないことが問題
実際、「AIをうまく使う方法」系の助言の多くはこの問題から出発している
結局は太鼓を叩いて祈祷をするようなもの
最新の理論的フレームワークでは、この過程を2つの段階、探索（Exploratory）と発見（Discovery）に分けている
探索段階は、一種の空中物質散布装置だと考えればいい
識別しやすいマーカー物質（たいていは排泄物の比喩）を高速で投入する
発見段階は、その拡散パターンを分析することとして概念化される
この2段階を要約すれば、「とりあえずやってみる」の次に「結果を確認する」と表現できる
今さら「プロンプトエンジニアリング」が大したスキルではないと皆が気づき始めたので、AI業界では目標の基準がずっと動き続けている感じがする
新しいスキルは結局「プログラミング」
昔のスキルと同じ
こういうものを理解したければ、自分でプログラムを書けばいい
LLMの訓練、推論の実行、挙動の分析をするプログラムを書いていくうちに、ますます理解できるようになる
私は最初のころには理論や期待する結果があったが、実際にLLMをさまざまな方法で訓練してみた後では、まったく違う結果と確信を得た
実際にツールを実装する過程が決定的な差を生む
私自身は中級程度の機械学習プログラミング経験しかないが、中規模のコンパイラを自分で作ってみたことが、複雑なシステムで良い結果を得る鍵だと思っている
Karpathyがどうやってこれを理解したと思う？
答えはKarpathyのブログにある
コンパイラを理解したければコンパイラを書いてみろという助言と同じ
技術的には正しいが、たいていの人はそこまで深く入りたいわけではない
この議論はだんだん、WoWのようなゲームのフォーラムでゲーマーたちが戦略を試し、奇妙な集団言語で言い争っている様子に似てきた気がする
いわゆる戦略というのはほとんど試行錯誤で見つけるもので、そのグループ内でしか通じない言葉で語られる
プログラミングも徐々にゲーミフィケーションの時代に適応している
パワーユーザーが偽の戦略を初心者や、ゲーム好きすぎる経営陣に売りつける現象
実際、以前のエンタープライズソフトウェアの流行のときにも似たことが繰り返されていた
今回はただ、その「パワーユーザー主導の流行」が、開発者、つまりビルダーたちが持っていた影響力・統制・ワークフローの領域にまで深く入り込んできたというだけ
最近の開発者が感じている感情は、かつてQA、SRE、CS職の人たちが「これがトレンドらしい！」とツールや慣行を押しつけられたときの気分と大して変わらないだろう
結論:
「強力で信頼できるAIエージェントの構築では、魔法のプロンプトやモデル更新ではなく、ビジネス用途に合った正しい情報とツールを、正しいフォーマットとタイミングで提供するコンテキストエンジニアリングが重要」
これは実は人間にもまったく同じように当てはまる原理
適切なタイミングで正しい情報を与えれば、人間もよりうまく解決できる
私はこうした表面的な機械学習と人間の比較トレンドは好きではない
洞察もないし、ほとんど当たってもいない
結局は環境の中で効果的に目標ボタンを見つけて押すこと
従来のソフトウェアエンジニアリングと大きくは変わらない
結果が少し非決定的なだけ
私はいつもUXやプロダクト担当に、「モックアップ、要件、受け入れ基準、サンプルの入出力、この機能がなぜ重要なのか」などについて繰り返し説明を求めている
脳をスキャンして欲しいものを取り出せない以上、現実的には欲しいものをきちんと説明することが絶対に必要
単なる「勘」に頼ってはいけない部分
より多くのコンテキストではなく、より良いコンテキストが重要
（代表例: X-Y problem）
最新のLLMに非常に優れたコンテキストを与えても、なお失敗する
うちの会社ではこの点をもう2年以上深く掘っている
「コンテキストが答えだ」という立場への盲信には驚かされる
ある時点からは、AIなしで直接作業したほうが早いと思う
そのほうが少なくとも何かしら有益な教訓は残るし、LLMのコンテキスト作成に何時間も費やすことにはならない
十分なコンテキストを与えたのにLLMが失敗するケースが気になる
具体例を共有してもらえるとありがたい
魔法のプロンプト探しが本当に「プロンプトエンジニアリング」だったことはない
本質的には常に「コンテキストエンジニアリング」だった
多くのAI自称専門家がこれをプロンプトエンジニアリングとして売り込んできたが、実際には本質をよく分かっていなかったのだと思う
RAG（検索拡張生成）は今年突然生まれた概念ではない
埋め込み、ベクターDB、グラフDBなどの複雑なノウハウをラップするツールもどんどん一般化している
大手プラットフォームも関連ツールを改善し、より多くのエコシステムを提供している
いつも同じ問題に対して新しい概念を作り、名前だけ変えているように感じる
結局は焚き火の前で太鼓を叩きながら呪文を唱えるシャーマンの儀式の繰り返し
悪魔を召喚する気分で、正しい呪文を正しい言葉で唱えて、こちらの命令にちゃんと従ってくれることを願うしかない状況だった
自分の中では、信頼性、再現性、強力なテストカバレッジを求めるエンジニアの心と、今の制御不能な複雑さとの間で葛藤している
こういうシステムで大規模なデモをやる人たちは本当に尊敬する
昔、セキュリティ脆弱性の研究デモをしていたころを思い出す
どれだけ準備しても、現場ではいつ結果がねじれるか分からず、発表中に冷や汗をかいた記憶がある
自分の経験と本当に近い見方
LLMにコンテキストを入れるとき、「この情報だけで人間は解けるだろうか？」という問いをよく使う
以前 text2SQL 製品を作っていたとき、モデルが失敗すると実際のデータアナリストも「そのテーブルは古いです。今はこのテーブルを使います」のように答えることがあった
結局、LLMも「人間のアナリスト」に必要なコンテキストが不足すれば間違えるということ
この話題で欠けているものがあるとすれば、それはまさに「評価（evaluations）」
AIプロジェクトで評価がなかったり、雑に済まされたりしているのを今でも見ると驚く
評価は従来のエンジニアリングにおけるテストよりも重要
評価セットはそれほど大きくなくてもよく、問題領域をうまくカバーしていれば十分
それがなければ、ただの「推測」にすぎない
そして私は、「この情報だけで人間が解けるか？」と自分に問いかけることが多い
人間にも解けない問題をLLMが解いてくれると期待していた経験がある
伝統的なコンピュータプログラミングの法則
「プログラマが英語でコーディングできるようにしようとすると、実際にはプログラマが英語でもまともに書けないことが分かる」
半分冗談だが、ある程度は真実
たいていの自然言語はそれほど明確ではない
もし英語で非常に正確にやりたいことを表現できるなら、むしろそれを機械が解釈する言語でそのまま書けたはず
Yes/No質問をすると、50%の確率で嘘の答えが返ってくる
そういう特性がある
私はモデルが実際に作業を始める前に、こうした質問を先にさせることがある
たとえば、不確かな点があれば質問すること、既存で使われているコードパターンの例を求めること、という指示を与える
すでに使われているテンプレートを例として使えるよう誘導する
データサイエンティストのふりをしている人たちは評価を望まない
だから実際に収益化されている製品以外では、評価がほとんど存在しない
「王様は裸だ」と言ってしまうと金にならないからだ
実務で本当に必要な場合には、必ず評価作業が入る