context-engineering-blueprint — LLM 開発のための情報統治

LLM 支援開発で生成される文書に、位置づけ・出所・依存・現行性を与えて追跡可能にするための情報統治体系である。仕様を Markdown で公開し、MIT ライセンスで提供する。プラグインや拡張ではなく、LLM に渡して各プロジェクトで実装させる文書として配る。

これは何か

このリポジトリは、情報統治の単一仕様（spec/context-engineering-blueprint.ja.md）を公開する。仕様は、文書の位置づけ（現行・廃案・未決・根拠）を構造に書き込み、人間と LLM の双方が追跡できる状態を作る方法を定義する。文書型のテンプレートは、仕様の付録 A〜C に含む。

利用者は仕様を LLM（主に Claude）に渡し、自分のプロジェクトに合う形で実装するよう依頼する。実装形態はプロジェクトが選ぶ。プレーンな docs/ でも、CLAUDE.md / AGENTS.md の規約でも、Claude Code の Skills と Hooks でもよい。

何を解決するか

LLM 支援開発では、仕様・実装・調査・判断・廃案・未決が、同じ粒度と同じ見た目で並ぶ。後から読むと、どれが現行で、何に依存し、なぜそこにあるかが分からない。LLM 自身も、廃案や古いログを現行として再採用する。

対策として常時コンテキストを増やすと、コーディングエージェントの成功率はむしろ下がり、推論コストは増える（ETH Zürich & LogicStar.ai, arXiv:2602.11988, 2026）。本体系は、量を増やすのではなく、各情報片に位置づけ・出所・依存・現行性を付与して追跡可能にする。

思想（3点）

• 文書は資産ではなく負債である。生成はほぼ無料になったが、読む・保守する・内容を信頼してよいか見極めるコストは人間に残る。少なく書き、積極的に消し、各事実の正本を一つだけ保つ。
• LLM の典型的失敗（廃案復活・未決の既決化・仕様と実装の取り違え）は、情報の位置づけが文書構造に書かれていないことに起因する。位置づけ・出所・依存・現行性を構造化して追跡可能にする。
• コンテキストは多いほど良いのではない。常時投入は最小の非自明な事実に絞り、CLAUDE.md / AGENTS.md は知識の集積ではなく、入口だけを示す最小限の案内にする。

使い方

1. 仕様（spec/context-engineering-blueprint.ja.md）の全文をコピーする。
2. LLM に貼り付け、下のプロンプトを添えて実装を依頼する。
3. LLM が提案した実装方針を確認し、プロジェクトに合わせて調整する。

コピー用プロンプト（例）:

添付の仕様（LLM 開発のための情報統治）を読み、このリポジトリに合う形で
情報統治を実装してください。

- 実装形態は問わない。プレーンな docs/、CLAUDE.md / AGENTS.md の規約、
  または Claude Code の Skills + Hooks のうち、このプロジェクトに最も
  使いやすい形を選んでください。
- 最小構成から始める。空のフォルダ群を先に作らない。
- まず実装方針を提案し、私の承認を得てから着手してください。

仕様は Claude Code プラグインを参照実装として記述する。プラグイン化は必須ではない。各プロジェクトは、上のプロンプトのとおり、自分に合う形態を選べる。文書を一つずつ手で作る場合は、仕様の付録 A〜C にある文書型テンプレートをコピーして使う。

リポジトリ構成

context-engineering-blueprint/
├── README.md                       # このファイル
├── LICENSE                         # MIT
├── CONTRIBUTING.md                 # 寄稿の方針と文章規範
└── spec/
    └── context-engineering-blueprint.ja.md   # 単一仕様（貼り付けて実装させる正本。付録に文書型テンプレート）

保証できること、できないこと

本体系の効果は、適切に運用された場合に、特定の失敗類型を検出・早期発見できることに限定される。100% の予防は構造上できない。

検出・早期発見できるもの（構造で対処）:

• 必須メタデータの欠落、ステータス語彙の逸脱、ID とファイル名の不一致、型とフォルダの不整合。
• 無効な参照（dead link）と依存グラフの破れ。
• 廃案・未決・禁止事項の常時不在による退行と既決化。
• 現行文書の陳腐化の疑い（レビュー期限の超過）。

人間レビューとテストに委ねるもの（構造だけでは閉じない）:

• 仕様が実装どおりに動くかの最終検証。これはテストの責務である。
• 抽象的なビジネス要求が真のニーズを満たすかの判断。
• 暗黙の前提の記述漏れ。人間が書き忘れた前提は、構造では補完できない。
• LLM の確率的逸脱と、外部依存（API 仕様・価格・法令）の予告なき変更。

なぜ Skill / Hook として配布しないのか

仕様を Markdown で配ると、各プロジェクトが自分に合う形で実装できる。プレーンな docs/ で足りるプロジェクトもあれば、Skills と Hooks まで必要なプロジェクトもある。固定したプラグインを配ると、この選択肢を奪う。

Markdown は依存関係を持たず、どの LLM・どの環境でも読める。仕様を貼って依頼するだけで実装に入れる。これが「一枚を渡せばどこでも使い回せる」の意味である。

ライセンス

MIT License。LICENSE を参照。商用利用・改変・再配布を許可する。

出典

主要な裏付けは仕様の付録 D に示す。コンテキスト最小化の知見は ETH Zürich & LogicStar.ai, arXiv:2602.11988（2026）に、日本語技術文書規範は JTCA『日本語スタイルガイド』と波頭亮『思考・論理・分析』に基づく。あわせて、記録管理（ISO 15489）、要求工学（ISO/IEC/IEEE 29148）、ADR（Michael Nygard）、Diátaxis、C4 モデルを参照する。