1. 開発理念とAI-Native DDDの定義
現代のエンジニアリングにおいて、開発速度のボトルネックは「実装」ではなく「文脈（コンテキスト）の維持」にある。本仕様書が定義する「AIネイティブ・ドキュメント駆動型開発（AI-DDD）」は、従来の「動くソフトウェア」を至上命題としたアジャイル開発を再定義し、**「コードはドキュメントの副産物である」**という哲学を中核に据える。
人間が意思決定（Why/What）に特化し、AI（Claude Code/Codex）が執行（How）を担う分業モデルにおいて、ドキュメントは単なる記録ではなく、AIを駆動させる「実行可能な仕様書」として機能する。この戦略の最大益は、開発プロセスの「脱ブラックボックス化」である。ドキュメントを「正」のエンジンとすることで、AIは常に最新の設計意図を把握し続け、長期的なプロジェクト保守における技術負債の蓄積を根本から抑止する。
2. 標準開発基盤（WSL/Docker）の構成仕様
AIエージェントの自律性を最大化するためには、環境の不確実性を排除した「予測可能な実行基盤」が不可欠である。本プロトコルでは、開発環境をWSL2およびDockerに完全固定する。
ディレクトリ構造とアクセス
ホストOS（WSL2）上のパス ~/projects/[project-name] を起点とする標準構造を厳守せよ。AIによるファイル走査コストを最小化し、相対パスの解釈ミスを防ぐことが目的である。
ポート設定プロトコル
プロジェクト間での衝突を回避し、AIがポート番号からサービスを識別できるよう、以下の固有ポート設定を義務付ける。
- Application (Laravel/Vite): 8021
- Database (MySQL): 3321
コンテナ構成要件
docker-compose.yml は、Laravel 12（PHP 8.3+）、MySQL 8.4、Vue.js（Vite）を含む標準スタックで構成せよ。環境構築をコード化（IaC）し、AIに対してコンテナ内での操作権限を付与することで、AIはログ解析を通じた自己修正ループを自律的に実行可能となる。
「So What?」：基盤固定の戦略的意義
環境を厳格に固定することは、単なる利便性のためではない。これは**「コンテキスト・ウィンドウの最適化」**である。AIがパスやポート、ミドルウェア構成を「推測」するために費やすトークン消費をゼロに抑えることで、実装の純粋なロジック生成にリソースを集中させ、開発スピードを極限まで加速させる。また、コンテナ内に境界を設けることで、ホストシステムの整合性を保ちつつAIの自律試行を許可する安全策としても機能する。
3. 技術スタック詳細と統合ルール
AIによるコード生成時のハルシネーション（もっともらしい嘘）を抑制するため、技術スタックごとに厳格な「型」と「設計の境界」を定義する。
バックエンド：Laravel 12 (PHP 8.3+)
- Migration/Eloquent: データベース設計は常にMigrationファイルを唯一の真実（Source of Truth）とし、ドキュメント内のER図（Mermaid）と完全同期させよ。
- Policy: 認可ロジックは必ずPolicyクラスに集約せよ。これはAIがセキュリティ要件を自動検証するための「論理のガードレール」となる。
フロントエンド：Vue.js (Vite) Reactの場合もあり
- 開発基準: Composition API および
<script setup>の使用を必須とする。SFC（Single File Component）の構造を予測可能に保つことで、AIによるコンポーネント生成の精度を担保せよ。 - State管理: リアクティビティ（ref/reactive）の設計指針を事前にドキュメント化し、データフローを明示せよ。
API連携：インターフェース定義
OpenAPI/Swagger形式を用いたインターフェース定義を強制する。フロントエンドとバックエンドの境界を「型」で縛ることで、結合フェーズにおけるAIの推論ミスを物理的に排除せよ。
「So What?」：厳格な型定義の効果
各スタックに「型」と「規約」を強制することは、AIにとっての**「論理的制約」**となる。自由度を制限することで、AIが誤った推論を行う余地を奪い、結果としてハルシネーションの発生率を統計的に低下させる。
4. AI-DDD 4フェーズ・ワークフロー・プロトコル
本プロトコルは、人間とAIがコンテキストを同期しながら進む、4つのパイプライン・フェーズで構成される。
- Extraction（抽出）: NotebookLMを用い、打ち合わせ等の「生の熱量」を構造化せよ。プロジェクトの背景、目的、制約事項をAIが処理可能なコンテキストへと変換する。
- Refinement（研磨）: Codexによる逆質問プロセスを通じ、仕様の「穴」を解消せよ。ここでは**「Issueは契約である」**という原則に基づき、AIと人間の合意内容をGitHub Issue（Acceptance Criteria付き）として確定させる。
- Implementation（執行）: Claude Codeによる実装フェーズ。Dockerコンテナ内でのUnitテスト自動実行を命令し、テストが成功するまでAIに自己修正ループを回させよ。
- Synchronization（同期）: GitHub CLIを用いたIssueクローズと同時に、
doc/配下（/architecture,/api,/db,/decisions）およびREADME.mdを自動更新せよ。
「So What?」：非同期コミュニケーションの最大化
各フェーズでドキュメントを「正」の出力とすることで、属人性を完全に排除する。これにより、開発者は詳細なコードを読み込むことなく、ドキュメントとIssueを確認するだけでプロジェクトの現状を把握可能となり、非同期コミュニケーションの質が飛躍的に向上する。
5. AIエージェント操作自動化とコマンド標準化
人間がAIに対し「最小の入力で最大の文脈を復元」させるため、インターフェースをコマンドレベルで標準化する。
状況把握コマンド（Tell me status）
AIに対し「今の状況を教えて」と命じた際、AIは以下の優先順位で情報をスキャンし、報告する義務を負う。
progress-status.md: 現在のプロジェクト上の立ち位置。GitHub Issue: 未完了タスクと完了定義（AC）の把握。Unit Test Result: 直近の実行結果と整合性。
自律実行と自己修正
php artisan test や npm run test:unit を自律的に実行し、エラーログを解析してコードを修正するサイクルをAIの標準動作として定義せよ。人間はエラーを修正するのではなく、AIに修正方針を提示するのみに留める。
ドキュメント自動反映チェックリスト
実装完了後、AIは必ず以下のドキュメントを更新しなければならない。
doc/requirements/内のMermaid図解。ADR（アーキテクチャ決定記録）への変更理由の追記。next-phase-roadmap.mdの進捗更新。
「So What?」：コンテキスト・スイッチ・コストの極小化
コマンドの標準化は、AIの「作業開始コスト」をゼロに近づける。これにより、人間がプロジェクトに復帰した際の認知負荷を劇的に軽減し、複数のプロジェクトを横断する際のコンテキスト・スイッチを容易にする。
6. 情報の昇華：NotebookLMによる知見の循環
開発過程で生成・蓄積されたドキュメントは、単なる記録からビジネス価値を創出する「資産」へと昇華させる。
逆流プロセス（Sublimation）
実装がマイルストーンに到達した際、以下のソース資産をNotebookLMへ再投入せよ。
- 再インポート対象:
README.md、doc/requirements/内の全ファイル、ADR。 - 生成成果物: ステークホルダー向けプレゼン資料案、開発白書（Development White Paper）、デモシナリオ。
「So What?」：ドキュメントの資産化
開発ドキュメントが単なる「エンジニアのためのメモ」から、経営判断や外部説明責任を果たす「経営資産」へと変化する。この循環プロセスにより、ドキュメント作成の労力は、将来の意思決定コストの削減として直接的なリターンを生む。
総括
AI-Native DDDは、人間を「コードの記述者」から「システムの指揮者」へと昇華させる。本プロトコルを遵守することで、AIは常に最高精度のコンテキストを維持し、人間はより高度な抽象レイヤーでの意思決定に専念することが可能となる。すべてのドキュメントが開発を牽引し、コードはその軌跡として自動生成される――これこそが、次世代の開発標準である。
