davidkimai/Context-Engineering は何をしているかプロンプトエンジニアリングの次の段階＝「Context Engineering（文脈設計）」を第一原理から体系化したハンドブック兼コース。2025年の1400論文サーベイ（arXiv:2507.13334）を軸に、理論・実装・テンプレ・プロトコル・エージェントまでを一本化した教材リポジトリ。
Context は「ユーザーが送る単一プロンプト」ではなく、推論時にモデルへ与えられる情報ペイロード全体（例・メモリ・検索結果・ツール・状態・制御フロー等、モデルがタスクを遂行するために必要な全構成要素）。
数式的には C = A(c₁, c₂, …, cₙ) — 複数の文脈要素を関数 A で組み立てたもの、と定式化されている。
比喩としては生物学的な階層メタファーを採用：
atoms（単一プロンプト）
→ molecules（few-shot）
→ cells（メモリ）
→ organs（マルチエージェント）
→ neural systems（認知ツール）
→ neural/semantic fields（場としての文脈）
00_COURSE/、全12週）4ブロック構造：
| ブロック | 週 | 内容 |
|---|---|---|
| Foundations | 1–4 | 00_mathematical_foundations / 01_context_retrieval_generation / 02_context_processing / 03_context_management — 形式化・最適化・情報理論・Bayes、RAG基礎、長文脈・自己精錬・マルチモーダル、メモリ階層と圧縮 |
| System Impl | 5–8 | 04_retrieval_augmented_generation / 05_memory_systems / 06_tool_integrated_reasoning / 07_multi_agent_systems |
| Integration | 9–10 | 08_field_theory_integration / 09_evaluation_methodologies — 場の理論・評価 |
| Frontier | 11–12 | 10_orchestration_capstone — メタ再帰、量子意味論、自己改善、キャップストーン |
各章は 00_overview.md → labs/*.ipynb → templates/ / implementations/ → case_studies/ という共通構成。
補助ディレクトリとして 00_foundations/（atoms〜unified field theory の14本の読み物）、10_guides_zero_to_hero/、20_templates/、30_examples/、60_protocols/、70_agents/ などが対応。
記事草稿で提示した 3 層モデル：
| 層 | 主語 | 定義 |
|---|---|---|
| Human Context | 人間/組織 | 目的に照らして解釈・選択・整形された情報 |
| Agent Context | エージェント | そのエージェントを成立させる構成の束(モデル・ツール・メモリ・ポリシー) |
| Window Context | コンテキストウィンドウ | 推論時にLLMが実際に読むトークン列 |
| 層 | カバー度 | 根拠 |
|---|---|---|
| Window Context | ◎ 中核 | Karpathy の定義をそのまま引用、01_context_retrieval_generation / 02_context_processing（長文脈・自己精錬）/ 03_context_management（メモリ階層・圧縮）/ 04_RAG / 05_memory_systems は全部ウィンドウ充填の話 |
| Agent Context | ○ 後半で扱う | 06_tool_integrated_reasoning / 07_multi_agent_systems / 10_orchestration_capstone / 70_agents/ / 60_protocols/。生物学メタファーの “organs”（マルチエージェント）以降がここに相当 |
| Human Context | × ほぼ空白 | 人間側の解釈・キュレーションを独立した工学対象として扱う章は見当たらない。あくまで AI に食わせる側の視点 |
「主に Window Context を扱っているが、Agent Context まで地続きで拡張している」が正確な理解。リポジトリの骨格である atoms → molecules → cells → organs → fields の比喩は、ちょうど Window 層から Agent 層への拡張プロセスをなぞっており、記事草稿の「現状の Context Engineering は Window と Agent、特に Window」という観測と一致する。
Human Context 層が空白、という指摘も妥当。
00_foundations/ 9〜12章（＋13, 14）について本題（コンテキストウィンドウの詰め方）から離れて、「文脈を離散トークン列ではなく連続場として扱ったら何が見えるか」という物理学・力学系的な比喩をまとめて展開しているブロック。
| 章 | 中身 | 何の比喩か |
|---|---|---|
| 09 Persistence and Resonance | トークンを保存せず「活性パターンの共鳴」で情報を持続させる発想 | 場の共鳴・減衰 |
| 10 Field Orchestration | 複数の意味場を同時に動かし合成する | ベクトル場の重ね合わせ |
| 11 Emergence and Attractor Dynamics | 会話や推論に現れる安定パターンを「アトラクタ」としてモデル化 | 力学系・引き込み現象 |
| 12 Symbolic Mechanisms | ICML Princeton 2025 の研究（LLM 内部に創発する symbol-abstraction / induction / retrieval heads） | 記号処理の創発 |
（13 Quantum Semantics、14 Unified Field Theory も同じ路線の延長で、観測者依存の意味論・全体統合を論じる）
実務的な Window Context Engineering からは距離のあるメタ理論パート。位置付けは：
3 層モデルで言えば、Window/Agent のさらに奥に “fields” という第4層を仮置きしようとしているように読める。記事で切り捨てて問題ない領域。むしろ Human Context を論じる上では邪魔になるかもしれない。
物理の「場」の比喩を文脈に持ち込んだもので、厳密な技術用語というより 再定式化のためのレンズ。
今までの文脈工学は「離散トークンをウィンドウにどう並べるか」の話。対して場モデルは「意味が連続媒体の上に広がる活性パターン」として文脈を捉え直す。
| 従来 | 場モデル |
|---|---|
| トークン列の編集 | 連続空間上の活性分布 |
| 「何を残す／削る」 | 「どのパターンを共鳴させ続けるか」 |
| 明示的メモリ | 共鳴による暗黙の持続 |
ウィンドウに「何トークン詰めるか」というミクロな最適化問題を、「意味の地形にどんなアトラクタ (安定点) を作るか」というマクロな動力学問題として扱い直したい、というのが彼らの野心。アトラクタ・共鳴・創発・量子意味論といった語彙はすべてこの地形の記述語。
ない。 場そのものがモデル内部の観測可能な構造に対応している保証はなく、あくまで設計者の思考枠組みとして提示されている（12章の Symbolic Mechanisms だけは ICML 論文に基づく実証があるが、”場” 概念は主に比喩）。
位置付けを端的に言えば：
違いは「何を議論の単位にするか」だけ。トークン語彙だと「この 500 トークンをどう削るか」の話しかできないが、場の語彙だと「この対話にどんな安定状態を作りたいか」「どの意味を共鳴させ続けたいか」という設計レベルの議論ができる、というのが著者の売り込み。
「トークンという低級語彙を抽象化した、著者流の高級語彙体系」と理解するのが正確。Human Context Engineering も、同じく独自の高級語彙を立てる企てになるはずで、構造的には似た挑戦をすることになる。
独自語彙を立てるときは、低級語彙との翻訳規則をどこまで示すかが説得力の分かれ目になる。