AIネイティブ・ドキュメント駆動開発（AI-DDD）標準規約

1. はじめに：AI-DDDの基本理念と目的

現代のソフトウェア開発において、生成AIの活用はもはや「補助」ではなく「前提」である。本規約が定義するAI-Native Document Driven Development（AI-DDD）は、AIと人間が共生する環境下で、システムの整合性を極限まで高めるための戦略的フレームワークである。

理念の定義：ドキュメントを正（Source of Truth）とする

AI-DDDの核心は、「ドキュメントが正（Source of Truth）であり、コードはその副産物に過ぎない」という逆転の発想にある。従来の開発ではドキュメントは事後の記録であったが、本手法ではドキュメントこそがAIを駆動させる「燃料」であり、設計思想そのものである。

組織的メリットの抽出

• 認識の不一致を根絶： 打ち合わせの「生の熱量」をAIが構造化し、曖昧な要件を実装前に排除する。
• 属人化の徹底排除： 全ての設計意図を doc/ 配下に集約し、AIが文脈を継承することで、担当者の交代コストをゼロにする。
• AI実装精度の最大化： 洗練されたドキュメントをAIに供給することで、ハルシネーション（もっともらしい嘘）を抑止し、一貫した品質を担保する。

成果物の位置づけ

本規約におけるドキュメントは、静的な報告書ではない。それはAIエージェントに次のアクションを指示し、プロジェクトの状態を即座に復元するための**「開発を動かすエンジン」**である。この理念を具現化するため、まずはAIが最も効率的に動作するための「開発基盤」を定義する。

--------------------------------------------------------------------------------

2. 開発インフラと技術スタックの標準化

AIが自律的に動作し、環境依存によるエラーを最小化するためには、予測可能なインフラ構成が不可欠である。環境の統一こそが、AIによる開発自動化の成功率を左右する。

標準環境の定義

開発は、Windows Subsystem for Linux (WSL2) 内の ~/projects/[project-name] を起点とする。ホストOSとの差異を排除し、AIエージェントがファイル操作やシェル実行を確実に行える環境を強制する。

技術スタックの指定

AIの学習データ量が多く、かつ型定義や構造が堅牢な以下のスタックを標準とする。

AIエージェントの役割分担

• NotebookLM: 非構造化データ（音声・メモ）の「蒸留」と、全資産を統合した資料生成を担当。
• Codex (VS Code): 仕様の「審議」と、人間との対話を通じた論理構築を担当。
• Claude Code: Dockerコンテナ内での「自律実装」と、テスト駆動による品質検証を担当。

この標準化された環境を基盤として、次に示す「4つの主要プロセス」を厳格に執行する。

--------------------------------------------------------------------------------

3. AI-DDD 4フェーズ・プロセス・ガイドライン

各フェーズは次ステップの「トリガー」となる連鎖構造を持つ。情報の欠損を許さないこのサイクルが、AI-DDDの生命線である。

3.1 抽出フェーズ（Extraction）

会議録音等の「生の熱量」を、AIが理解可能な「構造化データ」へ変換する。

• プロセス： 録音を文字起こしし、NotebookLMへ投入。構造化レポート、スライド、インフォグラフィックを生成する。
• 成果物要件： 単なる要約ではなく、クライアントの真の意図や「なぜこれが必要か（Why）」という背景情報を必ず保持すること。これが欠落すると、後のフェーズでAIが誤った設計判断を下す原因となる。

3.2 審議フェーズ（Critical Design）

AIにドキュメントを「攻撃」させ、論理の穴を塞ぐ。

• AIとの対話： Codex/Claude Codeに対し、構造化データを元に「実装者の視点」で逆質問を行わせる。
• 論理への攻撃： データが空の場合、通信タイムアウト、権限エラー等のエッジケースを意図的にリストアップさせ、人間がその判断を確定させる。この「衝突」を経て、ドキュメントは「実装可能な要件」へと昇華される。

3.3 設計・タスク分解フェーズ（Design & Orchestration）

確定した要件を技術的な「航海図」へ落とし込む。

• 設計図の自動出力： doc/requirements/ 配下に、DBマイグレーション案、API定義（Swagger）、Vueコンポーネント構成図（Mermaid形式）を出力する。
• GitHub Issueへの変換： 完了定義（Acceptance Criteria: AC）を必須としたIssueに分解する。ACがない場合、AIはタスクの終着点を見失う。登録は GitHub CLI を用い、人間が介在せずともAIが実装を開始できる状態にする。

3.4 実装・検証フェーズ（Implementation & Testing）

ドキュメントを正とした、自律的なビルドループを回す。

• 自律実装サイクル： Claude CodeがDockerコンテナ内でコーディングを行い、同時に php artisan test 等のUnitテストを自律実行する。
• 品質担保： **「テスト通過がコミットの絶対条件」**であることを厳命する。失敗時はAI自身がログを解析し、自動修正ループを回す。

実装後の情報は、組織の資産として永続化される必要がある。次に、AIを共同開発者として機能させるための行動規範を定義する。

--------------------------------------------------------------------------------

4. AIをチームメンバーとして活用するための行動規範

AIとの一貫性のあるコミュニケーションこそが、プロジェクトの成功率を決定づける。

「状況把握」の定型化

VS Code起動時、開発者は必ず**「今の状況を教えて」**というプロンプトから開始すること。AIは以下の優先順位で情報をスキャンし、即座にコンテキストを同期しなければならない。

1. docs/progress-status.md（現在の立ち位置と完了Issue）
2. GitHubのオープンなIssue（残タスク）
3. doc/ 配下の最新設計書と実装コードの整合性

コンテキスト維持の義務（AI Context Continuity）

AIの記憶力は、リポジトリ内の最新ドキュメントに依存する。実装完了後、README.mdおよび doc/ 配下を常に最新化することは、次回作業時にAIが「前回の続き」を正しく把握するための絶対義務である。これを怠ることは「技術負債」ならぬ「ドキュメント負債」を生み、AIのパフォーマンスを著しく低下させる。

人間による最終検閲

AIの出力に対する論理チェックは人間の責任である。特にセキュリティ、パフォーマンス、ビジネスロジックの核心については、人間が最終的なゲートキーパー（論理チェック責任者）となる。

日々の開発で蓄積されたドキュメントは、最終的にビジネス価値へと昇華される。

--------------------------------------------------------------------------------

5. 知見の昇華と資産管理（Documentation Assets）

ドキュメントの「逆流（フィードバック）」が組織に透明性と再利用性をもたらす。

ドキュメント階層の定義

以下のディレクトリ構造を標準とし、AIと人間が情報を瞬時に検索可能にする。

• docs/requirements/architecture.md（システム構成図）
• docs/requirements/db.md（ER図・テーブル定義）
• docs/requirements/api.md（エンドポイント定義）
• docs/requirements/decisions/（技術選定理由：ADR）
• docs/progress-status.md（進捗状況の正本）

NotebookLMへの再投入プロセス

マイルストーン到達時、doc/ 配下の全ドキュメントを再度NotebookLMにインポートする。

• 成果物の変容： 現場の実装記録から、経営層向けのプレゼン資料、デモシナリオ、開発白書を自動生成する。
• ビジネス活用： エンジニアリングの細部が、このプロセスを経て「経営判断材料」へと変容する。

規約の締めくくり

AI-DDDの継続的な運用は、ドキュメントを「負債」から「資産」へと変える。この規約を遵守することで、組織は個人の記憶に頼ることなく、AIと共に成長し続ける**「学習する組織」**へと進化する。我々が書くのは単なるコードではない。未来のチームが参照し、AIが理解し、組織が活用する「生きた知見」そのものである。