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

# コンテキストエンジニアリング ## 定義 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]]) - **[[Boris Tane]] はブログとオブザーバビリティ書籍で同一主張を独立に再展開し、書籍側は「ドメイン知識」層を6層に具体化した**: [[@2026__Boris Tane Blog__The Software Development Lifecycle Is Dead]] の中心テーゼ「エージェントで構築するものの品質は、エージェントに与えるコンテキストの品質に正比例する」は、[[@2026__OReilly__Observability Engineering 2E - Chapter 10 The Role of AI Agents for Observability]] でほぼ同じ言葉(「エージェントは与えられたコンテキストの分だけしか機能しない」)として再登場する。書籍側はオブザーバビリティ実務に絞ることで、本ページの「コンテキストの構成要素」が挙げる抽象的な「ドメイン知識」層を、サービストポロジー・命名規則・デプロイコンテキスト・既知の問題・直近インシデント・ビジネスコンテキストという具体的な6層に分解しており、抽象原則(ブログ)と実務チェックリスト(書籍)という異なる粒度で同一著者の主張が独立に補強し合っている。(Source: [[@2026__Boris Tane Blog__The Software Development Lifecycle Is Dead]], [[@2026__OReilly__Observability Engineering 2E - Chapter 10 The Role of AI Agents for Observability]]) - **コーディングエージェントの台頭がコンテキストの供給源そのものを侵食するという逆説**: 本ページのブログ由来の記述はコンテキストエンジニアリングを「人間が入力側を設計する新しい実践」として肯定的に描くが、書籍第10章は同じ潮流の負の側面を指摘する。人間の監督が少ない状態でコーディングエージェントがコードを書き・デプロイする速度が上がるほど、エンジニアが日常的な執筆・デバッグ・運用を通じて築くはずだったメンタルモデル(暗黙のドメイン知識)自体が形成されにくくなり、コンテキストエンジニアリングが前提とする「人間が持つ暗黙知を機械可読にする」という営みの原資が先細りするおそれがある。コンテキストエンジニアリングの実践が広がるほど、その供給源(人間の現場経験)が同時に痩せていくという自己矛盾的な力学がある。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 10 The Role of AI Agents for Observability]]) - **オントロジーとセマンティック規約は「ドメイン知識」層を人間の暗黙知ではなく機械検証可能な契約として供給する**: 第10章がドメイン知識を6層のチェックリストとして具体化したのに対し、第17章([[AIサンドイッチアーキテクチャ]]、Frank Chen)はさらに一段踏み込み、ドメイン知識を`IntervalSeries`・`Tariff`・`BillSet`・`ActionPlan`という明示的スキーマと、Coverage・Arithmetic・Determinismという不変条件へ形式化する。これにより「エージェントに何を伝えるか」という第10章の問いは「エージェントの出力を何で検証するか」という不変条件ベースの問いへ発展し、コンテキストエンジニアリングの射程が入力設計だけでなく出力側のガードレール設計まで広がることを示す。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 10 The Role of AI Agents for Observability]], [[@2026__OReilly__Observability Engineering 2E - Chapter 17 Ontologies as a Shared Language for Humans and AI]]) - **AI エージェント開発領域で先に定式化された「コンテキストの品質が差別化要因」という主張は、推薦システム(RecSys)領域でも独立に同型の転換として現れる**: [[Netflix]] の GenRec([[@2026__Netflix TechBlog__GenRec - Towards LLM-native Recommendation at Netflix]])は、本ページが扱ってきた「AI エージェントへの入力設計」とは全く異なる文脈——LLM バックエンドの推薦ランカーの学習——で、同じ「context engineering」という語を「特徴量エンジニアリングの代替」という意味で独立に使う。本ページの4層(インテント・ドメイン知識・観察データ・コード設計の文脈)がエージェントの行動設計を対象とするのに対し、GenRec の文脈は「ユーザー履歴・アイテムメタデータ・時系列文脈をどこまで言語化しトークン予算内に収めるか」という**情報圧縮・優先順位付け**の問題であり、[[LLM Wikiパターン]] が扱う「何を人間が入力し何を LLM に委ねるか」よりも、[[エージェントメモリ]] が扱う「限られたコンテキストウィンドウの中で何を保持し何を圧縮・破棄するか」という設計問題に近い。両分野が独立に「特徴量/仕様書エンジニアリングからコンテキストエンジニアリングへ」という同型の転換を報告している点は、コンテキストエンジニアリングが AI エージェント固有の実践ではなく、LLM を中核コンポーネントとして用いるシステム設計一般に共通する原理である可能性を示唆する。(Source: [[@2026__Netflix TechBlog__GenRec - Towards LLM-native Recommendation at Netflix]], [[@2026__Boris Tane Blog__The Software Development Lifecycle Is Dead]]) - **コンテキストの品質は、入力情報の豊富さだけでなく、不要なツール定義・ポーリング・応答をモデルの作業ループから外す設計でも改善できる**: 既存ページが扱ってきたインテント、ドメイン知識、観察データ、コード・設計文脈の供給に加え、Uber はCLIによる動的なMCP解決、ツール検索、コードモード、AI Context Graphを組み合わせる。前者は必要情報を増やす設計、後者は不要な情報と中間ターンを減らす設計であり、コンテキストエンジニアリングが検索精度だけでなく、実行軌跡のコストと正確性を同時に扱うことを示す。(Source: [[@2026__Uber__Running a Software Factory Efficiently at Uber Scale]], [[@2026__Boris Tane Blog__The Software Development Lifecycle Is Dead]], [[@2026__OReilly__Observability Engineering 2E - Chapter 10 The Role of AI Agents for Observability]]) ## 未解決の問い - コンテキストの品質はどう測定・改善するか？ - コンテキストエンジニアリングを専門とするロール（コンテキストエンジニア）は独立した職種として成立するか？ - オブザーバビリティデータの自動フィードバックが「エージェントへのコンテキスト品質」を保証するには何が必要か？ - エージェントメモリの自律的管理（メモリ形成・進化・検索の自動化）が進むと、コンテキストエンジニアリングの人間側の役割はどう変わるか？メモリが自己最適化すれば、人間が設計すべきコンテキストの範囲は狭まるのか、それとも別の次元（メタコンテキスト）に移行するのか？ - MCE の外側ループ(skill 進化)は ACE の Curator ルールとどこまで統合可能か。MCE が「機構と内容の分離」を提示した以上、ACE はより特殊化された(内側ループのみの)MCE インスタンスとして再定式化できるか。 - ACE・MCE のような自動コンテキスト管理と、[[ハーネス自己進化]]が扱うハーネスコード自体の自己改善は、どこまで同じ最適化階層に統合されうるか。 - コーディングエージェントの普及によるメンタルモデル形成の空洞化(書籍第10章)が進んだとき、人間の暗黙知に代わるコンテキストの供給源はどこに求められるか。エージェント自身のログ・実行履歴・インシデント記録から機械的にコンテキストを蒸留する仕組み(ACE の Reflector に近い発想)が、人間の暗黙知の代替になりうるか、それとも人間にしか埋められない領域が構造的に残るか。