ブループリントを唯一の真理源にする ── TEAM OS の D0/D1/D2 スタック

プロジェクトの「ドキュメント」は、たいてい地層のような化石になっています。三スプリント前の途中まで書いた設計メモ、誰も信用していない wiki ページ、リライト前にしか正しくなかった仕様書、コードと乖離した Notion、誰かの頭の中にある暗黙知。どれも*真理そのもの*ではなく、どれも*ある程度の真理*です。新しく入ってきた人にはどれが正解か区別がつかず、結局聞いて回り、答えはさらに分岐します。これがソフトウェアプロジェクトの既定状態であり、AI エージェントはこれを改善しません。むしろ悪化させます — 最初に見つけた化石から平気で外挿していくからです。

TEAM OS はこの問題をひとつのもので置き換えます — ブループリントです。ドキュメントでも wiki でもなく、構造として「唯一の真理源」と定義されたプロジェクト成果物です。機能変更、新機能追加、実装変更 — どれもまずブループリントを更新します。コードがブループリントと食い違ったら、誰かが別の判断を下すまではブループリントが勝ちます。フレームワークはブループリントを、建築現場が設計図を扱うように扱います。コードは建造、ブループリントは設計図。設計図にない場所にコンクリートは流さない。

完全性の基準は物理的です。 ブループリントが完全であるとは、それを手にしたエンジニアが新たな製品判断・アーキテクチャ判断を必要とせずに実装に入れる、ということです。残るのは実装上の選択肢のみ。これがブループリントを「完了」と宣言する前に走らせるテストです。実装中に「これはどう動くべき？」「どのサブシステムが所有する？」という形の問いが出てきたなら、ブループリントは不完全であり、回答は作業を続ける前にブループリントに戻されます。標語に聞こえますが、実は検証可能な性質です — 開発のどの時点でも、「いまブループリントにない、どんな新しい判断を下さねばならなかったか？」と尋ねられる。それが非自明なものなら、ブループリントは失敗しています。

スタックは三層の幅を持ちます。 D0 は製品定位 — その製品は何か、誰のためか、MVP の境界はどこか、満たすべき非機能要件は何か、成功はどう測るか、システムはどう分割されるか。D1 は製品設計 — 機能仕様、ユーザーストーリー、UI、五種類のノード定義、そしてそれらを貫くデータモデル。D2 は技術設計 — 技術選定、ノードモジュール、API、DB テーブル、EXT 外部依存、配備トポロジ。脇には二つの支柱が立ちます。プロジェクト固有の語彙を一度きり固定する用語集、そして D9 — 非自明な選定（ライブラリ、ベンダー、モデル、アルゴリズム）を、却下された代替案とその理由とともに残す選定ログ。

フレームワークの初期版は D0〜D9 の九層ありました。 そのうち六つを削除しました。それらが追跡していた仕事が不要だったからではなく、同じ仕事を既に行っている姉妹サブシステムを各層が重複していたからです。D3（タスク日程）はタスクサブシステムに吸収。D4（変更ログ）は type=change のタスクへ。D5（テストケース表）は完全に解消 — 完全なブループリントには既に全てのノード・契約・KPI が定義されており、テストは別文書ではなくブループリントから読むべきです。D6（リリースチェックリスト）はデプロイ Skill の完了基準になりました。D7（経験文書）は寿命別の三層を持つメモリサブシステムに再構成。D8（記憶アーカイブ）は、現代のエージェントランタイムがすべて行っているプラットフォーム自動保存になりました。残ったのは D0/D1/D2 + D9。余分な層を取り除くことで、スタックは小さく*かつ*正確になりました — 残った各部品が、ただひとつの居場所を持つようになったからです。

分類器は同型です。 同じ「コア／サイド／補助」三分類が、システム階でも機能階でも効きます。システム階：コアシステムを取り除くと製品が成り立たない。サイドシステムはコアシステムに影響、あるいはゲートする出力を持つ。補助システムはコアシステムに影響しない。機能階：コア機能はコアフロー上にある。サイド機能は支線としてコアフローに入力・ゲートで合流する。補助機能はコアフローに触れない。一文、二階層 — 新しい仕事はカテゴリ境界を議論することなく、これだけで三つの箱のひとつに分類できます。

全ての流れは五種類のノードに解けます。 TIN は端末入力 — ユーザーが直接生み出したもの。DIN はデータ入力 — 別のシステムが生成し、ユーザー経由で渡されたもの。TOUT は端末出力 — ユーザーが知覚する反応。DOUT はデータ出力 — ユーザーが他で使える構造化資産。STATE は状態書き込み — システムがユーザーを介さず中間ストアに書く。これがアルファベットの全てです。ユーザーストーリーはこれらのノードを通る経路。機能は特定のサブシステムを通る経路の集合。ブループリントはその経路の和集合と、それを実装するモジュールの集合です。

データはノードグラフへの入り方で分類します。 情報はノードを流れるもの（瞬時／積累／記録／一時の四つの下位分類）。規則はノード内部のロジック（設計者規則／ユーザー設定）。資源はノードが参照するもの（設計者定義／メディア素材／ユーザー生成物）。これは誰かがホワイトボードで思いついた三分類ではなく、「このデータはグラフの中で何をしている？」と問うとノードモデルから自動的に落ちてくるものです。ブループリントは、製品に登場する全ての概念（気分、ギフト、好感度、会話）を、実データファイルに昇格する前にこの三列に埋めることを強制します — DB のカラムが欠落する前に、定義の欠落を捕まえる仕組みです。

D2 は D1 を必ず指し戻さねばならない。 D2 で宣言される全てのノードモジュールは、自分が支える D1 機能を列挙する必要があります。D1 の呼び出し元を指せないモジュールは存在すべきではない。この一条が、他のどんなチェックよりも多くのアーキテクチャ的逸脱を殺します。同時にブループリントは双方向にナビゲート可能になります — D1 → D2 で実装を探し、D2 → D1 で正当化を辿る。事業上の用途のないモジュールも、実装するモジュールのない機能も、どちらも残れません。

ブループリントは一つの git 成果物です。 プロジェクトリポジトリの中に置かれ、バージョン管理され、差分が出て、レビュー可能。外部サービスも、管理された wiki も、何かを「覚える」モデルも要らない。タスクを割り当てられた AI エージェントは、ブループリントをただのファイルとして読み、自身もただのファイルである変更を書き戻し、コードの隣にコミットします。人間のレビュアーも同じファイルを読む。特権チャンネルは存在しない。これが、エージェントがプロジェクトに途中から参加して数ターンで役に立てるようになる性質の根です — 新人エンジニアと同じやり方でブループリントを読み、ブループリントが全ての場所を教えてくれる。

ブループリントがプロジェクト管理を解決すると主張しているわけではありません。意見の不一致は依然として起き、決定は古び、難しい選択はやはり人間が下します。ブループリントが解決するのは「真理はどこにあるか」という一つの問いだけ — そしてその一問が具体的に答えられているだけで、それ以外の摩擦がかなり減ります。