# コンテキストエンジニアリング ## 定義 AI エージェントに与える情報の品質を設計・管理する実践。[[Boris Tane]] の表現によれば「エージェントで構築するものの品質は、エージェントに与えるコンテキストの品質に正比例する」。 従来のソフトウェア工学における「プロセスの厳密さ」が差別化要因だったのに対し、AI エージェント時代では**コンテキストの品質**が差別化要因になるという転換を指す。([[@2026__Boris Tane Blog__The Software Development Lifecycle Is Dead]]) ## コンテキストの構成要素 AI エージェントに与えるコンテキストは複数の層から構成される： - **インテント（意図）**: 何を作りたいか・何を達成したいか - **ドメイン知識**: システムの構造・制約・過去の決定 - **観察データ**: オブザーバビリティシステムから流れてくる実行時フィードバック - **コード・設計の文脈**: 現在の実装状態・周辺コンポーネントとの依存関係 ## 従来プロセスとの対比 | 従来 SDLC | コンテキストエンジニアリング | |---|---| | 仕様書を書く | 適切なインテントを供給する | | コードレビューで品質を担保 | エージェントが自己検証できるコンテキストを整える | | テストフェーズで検証 | 観察結果をエージェントへフィードバックする | | スプリント計画でスコープを管理 | エージェントへのコンテキスト境界を管理する | ## オブザーバビリティとの関係 コンテキストエンジニアリングの実用的な核心の一つが、オブザーバビリティシステムによる自動フィードバック。本番システムの観察データを自動でエージェントへ流し込む仕組みが、コンテキストの鮮度と精度を保つ。これは [[agentic SRE]] における「モニタリング → エージェント → 修復」ループと同一の構造である。 ## ACE と MCE: プレイブックとしてのコンテキスト管理 [[Lilian Weng]] は [[@2026__Lil'Log__Harness Engineering for Self-Improvement]] で、コンテキストエンジニアリングの発展形として2つの手法を紹介する。いずれも「コンテキストを増え続けるプロンプトとして扱わない」という共通の問題意識に立つ。 **Agentic Context Engineering(ACE)**([Zhang et al. 2025](https://arxiv.org/abs/2510.04618))は、コンテキストを「進化するプレイブック」として扱う。Generator(軌跡生成)・Reflector(成功/失敗からの知見蒸留)・Curator(構造化された増分エントリでの更新)の3役分担を持ち、Curator はプロンプト全体を書き換えるのではなく (identifier, description) 形式の箇条書きを決定論的ロジックでマージする。これにより「コンテキスト崩壊」と「rewrite のたびに簡潔になりすぎる簡潔性バイアス」の両方を防ぐ設計になっている。 **Meta Context Engineering(MCE)**([Ye et al. 2026](https://arxiv.org/abs/2601.21557))は ACE をさらに一段抽象化し、コンテキスト管理の**機構**(mechanism、how)とコンテキストの**内容**(artifact、what)を分離する。MCE skill $s=(\rho_s,F_s)$ が入力 $x$ をコンテキスト $c=F_s(x;\rho_s)$ に写像し、内側ループが訓練データ上でコンテキストを最適化する一方、外側ループが検証データ上で skill 自体を進化させる二層最適化 $\text{Inner: }c_s^*=\arg\max_{c_s}J_\text{train}(c_s;s)$、$\text{Outer: }s^*=\arg\max_{s\in\mathcal{S}}J_\text{val}(c_s^*)$ を行う。ACE の更新規則が手作業のルールベースだったのに対し、MCE は skill の進化(過去 skill の交叉によるメタレベルエージェントの新 skill 生成)まで自動化する点が本質的な違い。(Source: [[@2026__Lil'Log__Harness Engineering for Self-Improvement]]) ## 横断的知見 - **ACE/MCE と本ページ既存の「コンテキストの構成要素」との対応**: 本ページが定義する4層(インテント・ドメイン知識・観察データ・コード設計の文脈)のうち、ACE・MCE が主に自動化するのは「観察データ」層(ロールアウトからの知見蒸留)である。Boris Tane(2026)の「コンテキストの品質が差別化要因」という主張は人間が入力側を設計する立場だが、ACE・MCE は蒸留・更新の**機構自体**を自動化する点で、[[エージェントメモリ]]の「自律的メモリ管理」の系譜(本ページ既存の横断的知見を参照)に接続する。ACE の Reflector・Curator は、エージェントメモリのサーベイ(Hu+ 2025)が論じる「自己進化的なメモリ管理」の具体的な実装例と位置づけられる。(Source: [[@2026__Lil'Log__Harness Engineering for Self-Improvement]], [[@2026__Boris Tane Blog__The Software Development Lifecycle Is Dead]], [[@2025__arXiv__Memory in the Age of AI Agents]]) - **[[LLM Wikiパターン]] との接続**: Karpathy の「人間はキュレーターと問いかけ者に専念する」という主張は、コンテキストエンジニアリングの入力側の実践形態の一つである。Karpathy が「bookkeeping は LLM に」と言う一方、Tane は「コンテキスト品質が差別化要因」と言う——両者は AI エージェント時代における人間の付加価値が「何を入力するか」に移ることで一致している。 - **[[Human-out-of-the-loop]] との接続**: 稲見昌彦が論じた「ループの外に出た人間の行先」は、コンテキストエンジニアリングによって「ループへの入力を設計する者」として再定義される可能性がある。 - **[[エージェントメモリ]]との射程の違い**: Hu+ (arXiv2025) のサーベイでは、コンテキストエンジニアリングはエージェントメモリと部分的に重なるがイコールではないと位置づけられている。コンテキストエンジニアリングがエージェントへの**入力側**（プロンプト・ツール出力・状態の設計）に焦点を置くのに対し、エージェントメモリはコンテキストウィンドウの外に広がるパラメトリックメモリや潜在メモリ、自己進化的なメモリ管理までを射程とする。Tane (2026) の「コンテキスト品質が差別化要因」と Hu+ (2025) の「メモリの自律化が次のフロンティア」は、エージェント設計の入力面と蓄積面という補完的な二面を照射している。(Source: [[@2026__Boris Tane Blog__The Software Development Lifecycle Is Dead]], [[@2025__arXiv__Memory in the Age of AI Agents]]) - **組織固有語彙の吸収は埋め込み側の注釈という具体的な実装で対処されている**: Amazon の SRE エージェント(Papapanagiotou, SREcon25 EMEA)は、社内俗称(例: ロードバランサーを指す "tardigrade")が汎用 LLM に理解されない問題に対し、RAG の埋め込み生成時に組織固有語彙の注釈を付与する対処を行った。これはコンテキストエンジニアリングが扱う「ドメイン知識」層(本ページ「コンテキストの構成要素」参照)を、検索・埋め込みパイプラインの設計問題として具体化した一事例であり、プロンプト設計だけでなく RAG のインデクシング段階もコンテキスト品質の管轄範囲であることを示す。(Source: [[@2025__SREcon25EMEA__Modernizing Incident Response with LLMs, RAG, and the MCP]]) ## 未解決の問い - コンテキストの品質はどう測定・改善するか？ - コンテキストエンジニアリングを専門とするロール（コンテキストエンジニア）は独立した職種として成立するか？ - オブザーバビリティデータの自動フィードバックが「エージェントへのコンテキスト品質」を保証するには何が必要か？ - エージェントメモリの自律的管理（メモリ形成・進化・検索の自動化）が進むと、コンテキストエンジニアリングの人間側の役割はどう変わるか？メモリが自己最適化すれば、人間が設計すべきコンテキストの範囲は狭まるのか、それとも別の次元（メタコンテキスト）に移行するのか？ - MCE の外側ループ(skill 進化)は ACE の Curator ルールとどこまで統合可能か。MCE が「機構と内容の分離」を提示した以上、ACE はより特殊化された(内側ループのみの)MCE インスタンスとして再定式化できるか。 - ACE・MCE のような自動コンテキスト管理と、[[ハーネス自己進化]]が扱うハーネスコード自体の自己改善は、どこまで同じ最適化階層に統合されうるか。