🙄

AI駆動ドキュメント駆動開発（DocDD）実践ガイド：設計・実装・テストを自動化する新時代の開発プロセス

2025/07/07に公開

 1. DocDD × AIドリブン開発とは何か？✨──ドキュメント駆動開発の本質と狙いDocDD（Document Driven Development） は、

「ドキュメントを一次情報とし、コードやテストはその従属物として自動生成・同期させる」

開発プロセスです。

ドキュメントの構造化と依存関係の可視化を最初から行い、

ClaudeCode（Claude APIを活用したCLIツール）やCursor等のAI開発ツールを使って変更伝播を自動化します。
ClaudeCodeとは: Anthropic社が提供するClaude APIを活用したコマンドラインツールです。ローカルのファイルシステムにアクセスし、ドキュメントの解析・生成・更新を自動化できます。

 これによって実現する世界観 🌟自然言語で書かれたテキストをもとに、ドキュメント作成 → コード作成 → テストコード作成を一気通貫で実現できる世界
つまり：
📝 ビジネス要件を自然言語で記述 → AIが構造化ドキュメントに変換
💬 Q&Aや議事録も含めて自然言語を活用 → 不明点や曖昧な点の履歴を辿れる
📋 構造化ドキュメントから設計書を自動生成 → 仕様の一貫性を保証
💻 設計書からコードを自動生成 → 実装の品質と速度を両立
✅ コードからテストを自動生成 → 品質保証の自動化

 自然言語の活用とドメイン知識の構造化 📚DocDDでは、自然言語資産を開発プロセスに組み込み、ビジネスサイドがドメイン知識の体系化に集中できる環境を提供します：

 活用可能な自然言語資産
Q&A履歴: Slackやメールでのやり取りから仕様の意図を抽出

議事録: 意思決定の経緯と背景を構造化して保存

レビューコメント: PRやドキュメントへのフィードバックを仕様に反映

不明点メモ: 「ここがよくわからない」という疑問も記録し、後で解決策と紐付け
これらが検索可能・追跡可能な形で管理され、「なぜこの仕様になったのか」を後から辿れます。

 双方向変換による人間とAIの協働 🔄DocDDはAIライクなフォーマットと人間フレンドリーなフォーマットの双方向変換も実現します：

YAML/JSON（AI向け） → Markdown/SVG（人間向け）: 構造化データを読みやすいドキュメントに変換

自然言語（人間の発想） → 構造化データ（AIの処理）: 事前定義されたスキーマに基づく変換

 構造化データへの変換ルール定義 📐自然言語を構造化データに変換するには、明確なスキーマとルール定義が必要です：
# 要件定義スキーマの例
requirement_schema:
  type: object
  required: [id, title, description, acceptance_criteria]
  properties:
    id: 
      type: string
      pattern: "^REQ-[0-9]{4}$"
    title: 
      type: string
      maxLength: 100
    description: 
      type: string
    acceptance_criteria:
      type: array
      items:
        type: object
        required: [condition, expected_result]
実際の変換例：
【自然言語での要求】
「注文確定後でも、発送前ならキャンセルできるようにしたい。
ただし、特注品はキャンセル不可で。キャンセル料は無料がいいな。」
↓ AIが構造化データに変換
# 生成された構造化データ
requirement:
  id: REQ-0234
  title: 注文キャンセル機能の実装
  description: |
    注文確定後、発送前の段階で顧客が注文をキャンセルできる機能を実装する。
    特注品は例外としてキャンセル不可とする。
  acceptance_criteria:
    - condition: 注文が確定済みかつ発送前の状態
      expected_result: キャンセルボタンが表示され、キャンセル処理が可能
    - condition: 商品が特注品フラグ付き
      expected_result: キャンセルボタンは非表示
    - condition: キャンセル処理実行時
      expected_result: キャンセル料は0円で処理される
  business_rules:
    - type: cancellation_period
      value: "注文確定後〜発送前まで"
    - type: excluded_items
      value: ["特注品"]
    - type: cancellation_fee
      value: 0
  status: draft
  created_by: AI
  needs_review: true
変換の品質保証：
🔍 エンジニアによる検証: 生成された構造化データの妥当性確認
📏 スキーマバリデーション: 定義済みルールへの準拠チェック
🔄 フィードバックループ: 変換精度の継続的改善

 新しい役割分担 👥🤖人間の役割：
🎯 ビジネス価値の定義と優先順位付け
💭 自然言語での要求・疑問・アイデアの収集と整理
✅ AIが生成した成果物の妥当性確認とフィードバック
🔍 不明点や矛盾点の発見と問いかけ
AIの役割：
🔨 自然言語を構造化ドキュメントに変換
🏗️ ドキュメントからコード・テスト・図表を自動生成
🔄 変更の影響範囲を検出し、関連箇所を自動更新
📊 技術的な整合性チェックと最適化提案
🌉 ビジネスとエンジニアの架け橋: 双方の言語を翻訳・仲介

 言語の壁を超えるコミュニケーション 🌏母国語での自然なコミュニケーションが可能に：
🇯🇵 日本語で要件定義 → AIが技術仕様に変換 → コード生成（英語変数名）
🗣️ 専門用語の自動翻訳: 「在庫引当」→ "inventory allocation"
💬 文化的ニュアンスの理解: 「お客様」という敬語表現から重要度を推測
# 多言語対応の例
input_japanese: "在庫が足りない時は、VIP会員を優先してください"
output_code_comment: "// Priority allocation for VIP members when stock is insufficient"
domain_term_mapping:
  在庫: inventory
  VIP会員: vip_member
  優先: priority_allocation
グローバルチームでの協働も円滑に：
各国のエンジニアが母国語で仕様を理解
ドメイン用語集が自動的に多言語対応
コードは統一された英語で生成
これにより、**「人間が考え、AIが形にし、人間が確認する」**という理想的な開発サイクルが実現します。人間は創造的な思考に集中でき、AIは機械的な作業を高速・高品質に処理します。

 AIチャットボットがハブとなる世界 🤝AIがハブとして実現すること：
📝 ビジネス要件の技術翻訳: 「売上向上」→「顧客セグメント別施策機能」
🔧 技術質問のビジネス翻訳: 「正規化」→「データの重複を避ける設計」
🎯 双方向の確認と調整: 不明点を適切な相手に適切な言葉で問い合わせ
📊 リアルタイムモデリング: 対話しながらドメインモデルを構築・可視化

 ⚠️ 重要な注意点：AIは万能ではないAIの限界を理解し、人間が適切にサポートすることが成功の鍵：
🚨 AIは完璧ではない
文脈理解の限界：業界特有の暗黙知は理解できない
創造性の限界：革新的なアイデアは人間から生まれる
判断の限界：倫理的・戦略的判断は人間が行う
👥 人間（特にビジネス側）の重要な役割
📋 情報の準備: AIが理解しやすい形で要件を整理
🔍 情報収集: 競合分析、市場調査、顧客の声など
📝 文脈の提供: 背景情報や制約条件を明示的に伝える
✅ 最終判断: AIの提案を評価し、採用可否を決定
【成功するAI活用の例】
❌ 悪い例：「いい感じのシステム作って」
✅ 良い例：「月間リピート率を現在の15%から25%に上げたい。
          主要顧客は30-40代女性。予算は500万円。
          既存の顧客DBと連携必要。3ヶ月以内にリリース」
AIがやりやすい環境を作ることが、人間の新たな責務となります。

 ClaudeCodeによるAI主体の開発へ 🤖ClaudeCodeをボットとして活用することで、さらに革新的な開発スタイルが可能になります：
AIが主体的に行えること：
🔍 仕様の不明点を自動洗い出し: フォルダ構成やファイル名、タグを解析して矛盾や欠落を検出
💬 ビジネス側との直接対話: エンジニアを介さずにAIが要件をヒアリング
📝 ドキュメントの自動作成: 会話から仕様書を生成し、確認を求める
🎯 能動的な提案: 「この部分が曖昧です」「こういう実装はどうですか」と問いかけ
従来の開発プロセスからの脱却：
【従来】
ビジネス → エンジニア（通訳） → ドキュメント → 実装

【DocDD + ClaudeCode】
ビジネス ⇄ AI（対話・提案） → 構造化ドキュメント → 自動実装
         ↑                        ↓
         └─── 人間（確認・承認） ←──┘
この世界では、エンジニアは「通訳者」から「レビュアー・アーキテクト」へと役割が変化します。AIが主体となってビジネス要求を技術仕様に落とし込み、人間はその妥当性を判断する立場になります。
必要な前提条件：
📁 適切なフォルダ構成（後述の「推奨リポジトリ構成」参照）
🏷️ 一貫したタグ管理（後述の「メタデータとタグ付け」参照）
📋 構造化されたテンプレート（後述の「Front-matter」説明参照）
これらが整備されていれば、AIは人間のエンジニアと同等以上の精度で要件定義から実装まで行えるようになります。

 人間はドメイン定義に専念する世界 🎯DocDDが実現する究極の姿は、人間がドメイン知識の定義に専念し、AIがそれを具体化するという分業体制です：
人間の新たな役割：
🧠 ドメイン知識の言語化: 業界特有のルールや慣習を明文化
💡 ビジネス価値の定義: 何が重要で何が重要でないかの判断
🎨 概念モデルの設計: エンティティと関係性の本質的な定義
📐 境界づけられたコンテキストの設定: システムの責任範囲の明確化
これにより、さらなるドメイン駆動設計（DDD）の深化が実現します。人間は「どう作るか」ではなく「何を作るか」「なぜ作るか」に集中できるようになります。

 暗黙知の言語化と知識構造の形式 📝人間に求められる最も重要なスキルは、暗黙知を言語化し、体系的に構造化することです：

 言語化すべき暗黙知🗣️ 業務ルールの明文化: 「いつもこうしてる」を「なぜそうするのか」まで含めて記述
📋 例外パターンの列挙: 「こういう時は特別に...」という知識を網羅的に文書化
🔗 因果関係の説明: 「AだからB」という論理的つながりを明確に

 知識構造の形式
Q&A形式: よくある質問と回答をペアで管理

ユースケース記述: 具体的な業務シナリオを詳細に記載

例外・エッジケース集: 特殊な処理や例外的な業務フローを文書化

用語集・ドメイン辞書: 業界特有の用語や概念を定義

 AIとの連携を強化する仕組み1. 体系的なファイル・フォルダ構造 📁
docs/
├── domain/           # ドメイン知識
│   ├── qa/          # Q&A集
│   │   ├── order_management_qa.md
│   │   └── customer_service_qa.md
│   ├── glossary/    # 用語集
│   └── rules/       # ビジネスルール
├── usecases/        # ユースケース
└── readme.md        # 全体の関連性を説明
2. メタデータとタグ付け 🏷️
---
title: "注文キャンセルに関するQ&A"
tags: 
  - "#order"
  - "#cancellation"
  - "#customer-service"
  - "#business-rule"
related_files:
  - "usecases/order_cancel.md"
  - "domain/rules/cancellation_policy.md"
last_updated: 2025-08-03
---
3. README.mdでの関連性明記 📝
# ドメイン知識リポジトリ

## 📂 ファイル構造と関連性
- `qa/` - ビジネスQ&A → `usecases/` の具体的な実装仕様
- `rules/` - ビジネスルール → `qa/` で参照される制約条件
- `glossary/` - 用語定義 → 全ファイルで使用される共通語彙

## 🔄 更新ルール
1. Q&Aに新規追加 → 関連するusecaseも更新
2. ビジネスルール変更 → 影響するQ&Aをgrep検索して修正
3. 用語追加 → glossaryとREADMEの両方を更新

 整合性担保の実践例 💡サンプル: 配送料金ルールの変更

Q&A更新 (qa/shipping_qa.md)
## Q: 配送料金はどのように計算されますか？
A: 2025年8月より、以下のルールで計算されます：
- 購入金額3,000円以上: 送料無料
- 購入金額3,000円未満: 全国一律500円
- 離島・一部地域: 追加料金1,000円

#shipping #pricing #business-rule-2025-08

ビジネスルール更新 (rules/shipping_rules.md)
shipping_fee_rules:
  effective_date: "2025-08-01"
  standard:
    threshold: 3000
    fee_below_threshold: 500
    fee_above_threshold: 0
  remote_area:
    additional_fee: 1000
    areas: ["沖縄県", "離島"]
自動伝播トリガー
# AIが関連ファイルを検出して更新提案
$ claude-code update-related --file="qa/shipping_qa.md"

検出された影響範囲:
- usecases/checkout_process.md (配送料計算部分)
- api/shipping_calculator.yaml (料金計算API仕様)
- tests/shipping_fee_test.md (テストケース)

すべて更新しますか？ [Y/n]
このように、ファイル名・フォルダ構造・タグ・READMEの組み合わせにより、AIが関連性を理解し、一気通貫での更新が可能になります。

 ClaudeCodeの実践的な使用例 🚀ここでは、ClaudeCodeを実際に使った開発フローを詳しく見ていきましょう。
1. 初期セットアップ
# ClaudeCodeのインストール
npm install -g claude-code

# プロジェクトの初期化
claude-code init

# Claude.mdの自動生成
claude-code generate-rules --output=docs/Claude.md
2. Claude.mdの詳細設定例
# Claude.md - DocDDプロジェクトルール

## 🏗️ プロジェクト構造
- すべてのドキュメントは`docs/`配下に配置
- 依存関係は必ずFront-matterで明示
- 変更は必ずドキュメントから開始

## 📋 ドキュメント種別と必須フィールド

### ビジネス要件 (business_requirement)
必須フィールド:
- id: BR-XXXX形式
- stakeholder: 要求元
- business_value: ビジネス価値
- kpi: 測定可能な指標

### ユースケース (usecase)
必須フィールド:
- id: UC-XXXX形式
- actors: アクター一覧
- preconditions: 事前条件
- postconditions: 事後条件
- main_flow: 基本フロー
- alternative_flows: 代替フロー
- exception_flows: 例外フロー

### 画面要件 (screen_requirement)
必須フィールド:
- id: SR-XXXX形式
- usecase_refs: 関連UC
- components: UI要素一覧
- validations: 入力検証ルール
- accessibility: アクセシビリティ要件

## 🏷️ タグルール
- #draft: レビュー前
- #approved: 承認済み
- #deprecated: 非推奨
- #DoNotEdit: AI編集禁止
- #NeedsHumanCheck: 人間確認必須

## 🔄 変更伝播ルール
1. ビジネス要件の変更 → 全依存ドキュメントを再生成
2. ユースケースの変更 → 画面要件とAPI仕様を更新
3. ドメインルールの変更 → 全関連テストケースを再生成

## 🤖 AI生成時の制約
- 生成コードには必ず元ドキュメントへの参照をコメントで記載
- テストケースは境界値と異常系を必ず含める
- 命名規則はプロジェクトの既存コードから学習
3. インタラクティブな変更伝播の実行例
# ビジネス要件を更新
$ claude-code update docs/business/BR-0001_customer_segmentation.md

ClaudeCode: BR-0001の変更を検出しました。
影響範囲を分析中...

検出された依存関係:
├── docs/uc/UC-0105_segment_analysis.md
├── docs/uc/UC-0106_targeted_marketing.md
├── docs/screen/SR-2001_segment_dashboard.md
├── docs/api/API-3001_segment_query.yaml
└── docs/tests/TEST-4001_segment_scenarios.md

これらのドキュメントを更新しますか？ [Y/n]: Y

[1/5] UC-0105を更新中...
  - business_valueフィールドを新しいKPIに合わせて修正
  - 新しいセグメント条件を基本フローに追加
  ✓ 完了

[2/5] UC-0106を更新中...
  - マーケティング施策の優先順位を更新
  - 新セグメントに対応するシナリオを追加
  ✓ 完了

[3/5] SR-2001を更新中...
  - ダッシュボードに新しいセグメント表示を追加
  - フィルター条件を拡張
  ✓ 完了

[4/5] API-3001を更新中...
  - クエリパラメータに新セグメント条件を追加
  - レスポンススキーマを拡張
  ✓ 完了

[5/5] TEST-4001を更新中...
  - 新セグメント条件の境界値テストを生成
  - 既存テストケースとの整合性を確認
  ✓ 完了

すべての更新が完了しました。
変更内容をレビューしますか？ [Y/n]: Y

# 差分表示モードで各ファイルの変更を確認...
4. AIとの対話的な仕様策定
$ claude-code chat

ClaudeCode: DocDDプロジェクトへようこそ。どのようなお手伝いをしましょうか？

You: 新しい割引機能を追加したいです。VIP会員は20%、一般会員は10%の割引を適用します。

ClaudeCode: 割引機能の要件を整理させていただきます。以下の理解で正しいでしょうか？

1. 対象: 会員種別による割引
   - VIP会員: 20%割引
   - 一般会員: 10%割引
   
2. 確認事項:
   - 非会員の扱いは？（割引なし？）
   - 割引の適用条件は？（全商品対象？）
   - 他の割引との併用は？（ポイント割引、クーポン等）
   - 割引上限金額の設定は必要？

You: 非会員は割引なし、全商品対象、他の割引とは併用不可、上限なしでお願いします。

ClaudeCode: 承知しました。以下のドキュメントを生成します：

1. ビジネス要件（BR-0234_member_discount.md）
2. ユースケース（UC-0567_apply_member_discount.md）
3. ドメインルール（DR-0123_discount_rules.md）

生成を開始してもよろしいですか？ [Y/n]: Y

[生成中...]

生成が完了しました。内容を確認しますか？ [Y/n]: Y

--- docs/business/BR-0234_member_discount.md ---
---
title: 会員種別割引機能
id: BR-0234
type: business_requirement
stakeholder: マーケティング部
business_value: 会員ロイヤリティ向上による売上増加
kpi:
  - name: VIP会員の購買頻度
    target: 20%向上
    measurement_period: 3ヶ月
  - name: 一般会員のVIP会員転換率
    target: 15%向上
    measurement_period: 6ヶ月
created_date: 2025-08-03
status: draft
---

## 概要
会員種別に応じた自動割引機能を実装し、会員の購買意欲向上と
ロイヤリティ強化を図る。

## 要件詳細
1. **割引率**
   - VIP会員: 購入金額の20%割引
   - 一般会員: 購入金額の10%割引
   - 非会員: 割引なし

2. **適用条件**
   - 全商品が割引対象
   - 会員ステータスは注文時点で判定
   - 割引上限金額: なし

3. **制約事項**
   - 他の割引（クーポン、ポイント割引等）との併用不可
   - 最も割引率の高いものを自動適用

[以下、生成されたドキュメントが続く...]

 レガシーフォーマットからの脱却 🚫AIが読みづらいフォーマットはレガシー化：
❌ Excel: セル結合や色分けに依存した暗黙的な情報伝達
❌ PDF: 構造化されていない見た目重視のドキュメント
❌ PowerPoint: 視覚的だが論理構造が不明確なスライド

 AIフレンドリーな情報伝達 🤖AIに適した形式での情報提供：
✅ 適切な分割: 長大なテキストは論理的な単位で分割（トークン制限を考慮）
✅ 構造化された羅列: YAML/JSONの深いネストもAIには自然
✅ 冗長な記述: 同じことを別の表現で繰り返すことで精度向上

 ⚠️ トークン制限への対応長大なドキュメントの分割戦略：
# ドキュメント分割の例
large_document:
  main: requirements_overview.md      # 概要（2,000トークン以内）
  sections:
    - requirements_detail_01.md       # 機能要件1-5（各3,000トークン以内）
    - requirements_detail_02.md       # 機能要件6-10
    - requirements_detail_03.md       # 非機能要件
  cross_references:
    - type: "depends_on"
      from: "requirements_detail_02.md"
      to: "requirements_detail_01.md"
分割の目安：
📏 1ファイル3,000-4,000トークン以内（日本語で約6,000-8,000文字）
🔗 相互参照で関連性を維持
📑 インデックスファイルで全体構造を管理
そしてAIは、これらを人間が読みやすい形に変換：
📊 図表への変換: 複雑な関係性をビジュアル化
📝 要約の生成: 重要ポイントを抽出してサマリー作成
🎨 インタラクティブなドキュメント: 必要な部分だけを展開できる階層構造
この循環により、人間の創造性とAIの処理能力が最大限に活かされる開発体制が実現します。

 従来の開発からDocDDへの転換従来の開発：「コード → ドキュメント → テスト」の順で作業
🛠 コードが真実の源泉 → ドキュメント後回し → 乖離問題
📄 ドキュメント更新 → 実装・テスト未連動 → 再現性なし
🧪 テストは後追い → 仕様変更に追随せずバグ誘発
DocDDの3つの柱：
ドキュメントを Source of Truth に据える
依存グラフでドキュメント間の関係性を明示・構造化する
生成AIで、変更を全方位に伝播・再生成する
これにより、要件変更 → ドキュメント → 設計 → コード → テストがシームレスに連動し、部分最適による全体破綻を防ぎます。

 ここまでのまとめ：理想と現実のギャップ 🌉ここまで、DocDD × AIドリブン開発の理想的な世界観を描いてきました。しかし、現実の開発現場では、この理想を阻む様々な問題が存在します。
理想の世界：
📝 ドキュメントが常に最新で、すべての真実の源泉
🔄 変更が自動的に関連箇所へ伝播
🤖 AIが人間の意図を正確に理解し、適切な成果物を生成
しかし現実では：
💔 ドキュメントとコードの乖離が日常的に発生
🏚️ 部分的な更新による全体の不整合
😵 担当者の変更で設計意図が失われる
次章以降では、これらの問題がなぜ発生するのか、そしてDocDDがどのようにしてこれらの課題を解決するのかを、具体的な事例とともに解説していきます。
まずは、多くの開発現場で起きている「逆転現象」から見ていきましょう。

 2. 逆転現象🔥──ドキュメント依存が崩れると何が起きるか？
 2.1 典型例：UI先行による部分最適UXデザイナーが Figma で画面刷新
開発者が UI コードを修正

画面要件ドキュメント は更新
一方、ユースケース や ビジネス要件 は放置
数週間後、そのユースケースを基にAPI設計すると、

最新UIに合わない旧仕様API が誤って採用され、大規模バグが発生。

 2.2 逆転が発生する理由
依存宣言不在：どのドキュメントが他に依存するか未定義

伝播ルール欠如：更新時に下流を巻き込む運用がない

AI非可読フォーマット：Excel/PPT/Figmaでは自動同期困難

 2.3 "画面ありき"開発の落とし穴🎨 UI先行 → ビジネスゴールが不明確
👥 ドメイン知識が担当者に偏在
🏁 「画面作成」が目的化 → 本質的価値喪失
DocDDは、**「Why → What → How」**の順でドキュメントを生成し、

AIが再生成可能な構造化を徹底します。

 2.4 番外編：スピード優先でドキュメント後回し🕳 コードのみ更新 → 設計意図散逸
🔒 非エンジニア理解困難
🧩 コード可読性低下 → AIも解読不能
結果、属人化・ブラックボックス化が進行。

DocDDではまずドキュメント修正 → コード・テスト再生成し、

変化に強い体制を構築します。
「ドキュメントを書かないと、誰も保守できなくなる」

 3. 全体プロセスの骨子🔗――「内から外への依存構造」DocDDでは、ドキュメント間の依存関係を**内側（ドメイン）→外側（UI/API）**で

構造化します。これはクリーンアーキテクチャの原則と同様です。
ビジネス要件 (Why) → ユースケース (What) → 画面要件/API (How) → 実装・テスト

 3.1 三位一体展開⚙️――DocDDで実現する3つの同期DocDDの三位一体とは、同一の構造化ドキュメントから以下を同時に生成し、

整合性を保つ仕組みです：
テスト生成🧪
単体テスト ← ドメインルール
結合テスト ← ユースケース/外部連携
E2Eシナリオ ← 画面要件
非機能テスト ← NFR定義
モデリング🗺
ER図/クラス図 ← 自然言語要件
ステートマシン定義 ← UCの例外/状態遷移
**タスク管理(Epic/Issue)**🛠
BDDシナリオ→Epic/Issue自動生成
テスト失敗→仕様曖昧箇所をDocsへ逆入力
これにより、設計→実装→検証→改善が一気通貫で行われます。

 3.2 生成物修正のフィードバックループ 🔄AIが生成したコードやドキュメントは完璧ではありません。DocDDでは修正をSource of Truthに還元する仕組みが重要です：
修正フィードバックの流れ：
🤖 AIがコード生成: ドキュメントから初期実装を自動生成
👨‍💻 人間が修正: バグ修正や最適化を実施
📊 差分解析: 修正内容をAIが解析し、ドキュメント更新案を生成
✅ 承認・反映: 人間が確認後、ドキュメントを更新
🔄 再生成: 更新されたドキュメントから関連箇所を再生成
# 修正フィードバックの例
original_spec:
  validation: "メールアドレスの形式チェック"
  
generated_code:
  regex: "^[a-zA-Z0-9]+@[a-zA-Z0-9]+\\.[a-zA-Z]+$"
  
human_fix:
  regex: "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$"
  reason: "RFC5322準拠のため、より厳密な検証が必要"
  
doc_update_proposal:
  validation: 
    rule: "RFC5322準拠のメールアドレス形式チェック"
    examples:
      valid: ["user.name+tag@example.com", "test@sub.domain.co.jp"]
      invalid: ["@example.com", "user@", "user..name@example.com"]
このループにより、実装の知見がドキュメントに蓄積され、次回の生成精度が向上します。

 4. フェーズ別INPUT→OUTPUT📑以下の表は前フェーズのOUTPUTが現フェーズのINPUTになるよう設計されています。


#
フェーズ
INPUT（前）
OUTPUT（次）


1
AS-IS整理
ヒアリング記録、Q&Aテキスト、議事録
業務フロー図、課題一覧

2
ビジネス課題定義
業務フロー図
課題/KPI、ビジネスゴール

3
システム要件定義
課題/KPI
機能一覧、構成図、非機能要件

4
ユースケース定義
機能一覧
UC記述（IN/OUT/例外）、図

5
外部連携要件定義
UC記述、API仕様
IF仕様、エラー設計

6
ドメインルール
UC記述、業務制約
ER図、ドメインルール表

7
画面要件定義
UC IN/OUT、ドメインルール
画面一覧、バリデーション

8
ワイヤーフレーム
画面要件
JSON構造ワイヤー

9
Figma最終UIデザイン（ハイファイ）
ワイヤーフレーム
Figmaで作成された完成形UI（画面要件を精緻化）

10
Figma最終UIデザインからの画面要件アップデート
Figma上で加えられた変更箇所（UI上の差分）
最終的なUI仕様を構造化ドキュメントに反映


 5. AI協働ガイドライン📘――実践チェックリストDocDDでは構造化されたドキュメントを用いて、設計・実装・テストまでを一貫したサイクルでつなげます。そのためには、ドキュメント同士の依存関係が明確であり、変更が発生した際にAIが適切に伝播を行える状態であることが重要です。
ここでは、DocDDを現場で運用する際に押さえておくべき具体的なテクニックや、ClaudeCodeなどのAIと連携するためのドキュメント設計上のベストプラクティスを整理します。
依存宣言をFront-matter（フロントマター）で定義

depends_on: ["docs/uc/cart.md"] のように明記
Front-matter（フロントマター）とは？

ドキュメント冒頭の---で囲まれたYAML形式のメタデータ領域です。

依存関係やドキュメント種別、タグ、伝播制御などを記述し、AIが構造を理解するための手がかりとなります。
例：
---  
title: "注文キャンセルユースケース"  
type: "usecase"  
depends_on:  
  - "domain/order.md"  
  - "screen/order-cancel.md"  
tags:  
  - "#uc"  
  - "#order"  
propagate: manual  
---  
Claude.mdでルール一元化

命名規約、タグ一覧、必須フィールドをまとめる
フォルダ構成・命名統一

docs/uc/, docs/screen/, docs/domain/ などを整理
暗黙知 → テキスト化

前述の「暗黙知の言語化」セクションで詳述した方法で業務ルールを記述
フィードバック → 即 Docs修正

テスト失敗やバグ報告後、Patch PR（修正用のプルリクエスト）でドキュメントを更新
タグ管理で再生成範囲を制御

#DoNotEdit / #NeedsHumanCheck を設定
生成元と出力物を明確分離

Markdown/YAML（構造化テキスト形式）は一次ソース、Excel/PPTは出力専用

 6. AI依存ドキュメントへの視点転換🧠DocDDにおいては、ドキュメントを「設計情報の一次ソース」として運用するため、単に読みやすい文章を書くのではなく、AIが理解・処理しやすい形式で整備することが求められます。
これは従来の「人が見るためのドキュメント」から、**「AIと人が協調して使うためのドキュメント」**への大きな発想転換です。
したがって、DocDDを効果的に活用するには、人間依存からAI依存への思考シフトが必須です。
このような形式へのシフトは、変更の再現性・再利用性・テスト自動化に直結します。AIにとって構造が明確であることは、要件の変更伝播やテストケース生成、影響範囲特定など、すべての自動化処理の基盤となります。

 主なシフトポイント
非構造 → 構造：Excel/PPT/FigmaをMarkdown/YAML/JSON（テキストベースの構造化形式）に変換し、AIが解析しやすいスキーマとして整備

前提明記：IN/OUT/例外などを必須フィールドとして定義し、AIが必要情報を見逃さないようにする

暗黙知可視化：前述の言語化手法により、業務ルール・慣習を明文化し、全員とAIが参照可能にする

即反映＆再生成：開発フィードバック（テスト失敗やバグ報告）を受けたらPatch PR（修正用のプルリクエスト）でDocsを更新し、AIで自動再生成を実行

 7. 非構造資料のAI対応変換📂前章ではAIが処理しやすい構造化ドキュメントの重要性を述べました。

しかし現場にはExcel・PowerPoint・Figmaといった非構造資料が残っています。

DocDDではそれら既存資産を「読み捨てず」、AIが読み取れる形式へ変換・取り込むことで全体プロセスに統合します。


元形式
AI対応形式
備考


Excel仕様書
YAMLスキーマ
カラム→プロパティマッピング

PowerPoint
PlantUML（テキストベースの図表記法）
図を構造化して構成図に落とし込む

Figma
JSON diff (#SpecGap)
差分をPatch PR素材として取り込み可能


 8. 推奨リポジトリ構成📁ClaudeCode運用を前提としたフォルダ構成例です。
docs/
├── Claude.md               # ルール集（命名規約・タグ・必須項目）
├── uc/                     # ユースケース定義
├── domain/                 # ドメインルール・エンティティ
├── screen/                 # 画面要件定義
├── nfr/                    # 非機能要件
├── externals/              # 外部連携API仕様
├── design/                 # ワイヤーフレーム・UI要素
├── inputs/                 # Patchやディスカッション素材
└── tests/                  # 自動生成テストコード雛形

 9. 実践チュートリアル：TODOアプリで体験するDocDD 📱ここでは、シンプルなTODOアプリを題材に、DocDDの開発フローを実際に体験していきましょう。セットアップから仕様変更までの一連の流れを通じて、DocDDの威力を実感できます。

 9.1 プロジェクトのセットアップ
 ステップ1: プロジェクト初期化# プロジェクトディレクトリの作成
mkdir todo-docdd && cd todo-docdd

# ClaudeCodeでプロジェクト初期化
claude-code init --template=docdd

# 生成されるフォルダ構造
todo-docdd/
├── docs/
│   ├── Claude.md           # プロジェクトルール
│   ├── README.md          # ドキュメント関連性の説明
│   ├── business/          # ビジネス要件
│   ├── usecases/          # ユースケース
│   ├── domain/            # ドメインルール
│   ├── screen/            # 画面要件
│   └── api/               # API仕様
├── src/                   # 生成されるソースコード
├── tests/                 # 生成されるテストコード
└── .docdd/               # DocDD設定ファイル

 ステップ2: 初期要件の定義$ claude-code chat

ClaudeCode: 新しいDocDDプロジェクトへようこそ！どのようなアプリケーションを作成しますか？

You: シンプルなTODOアプリを作りたいです。基本的な機能として、タスクの追加、完了/未完了の切り替え、削除ができればOKです。

ClaudeCode: TODOアプリの要件を整理します。以下の機能で間違いないでしょうか？

基本機能:
1. タスクの追加（タイトルと説明）
2. タスクの完了/未完了切り替え
3. タスクの削除
4. タスク一覧の表示

追加で検討したい機能:
- タスクの編集機能は必要ですか？
- 期限設定は必要ですか？
- 優先度設定は必要ですか？
- カテゴリ分けは必要ですか？

You: 今回はシンプルに、基本機能のみでお願いします。編集機能は追加してください。

ClaudeCode: 承知しました。以下のドキュメントを生成します：

 9.2 ドキュメントの自動生成
 ビジネス要件の生成# docs/business/BR-0001_todo_app.md
---
title: TODOアプリケーション基本機能
id: BR-0001
type: business_requirement
stakeholder: プロダクトオーナー
business_value: タスク管理の効率化による生産性向上
kpi:
  - name: タスク完了率
    target: 20%向上
    measurement_period: 1ヶ月
created_date: 2025-08-03
status: approved
---

## 概要
個人のタスク管理を効率化するためのシンプルなTODOアプリケーション。
直感的なUIで日常のタスクを簡単に管理できる。

## 機能要件
1. **タスク管理**
   - タスクの作成（タイトル、説明）
   - タスクの編集
   - タスクの削除
   - タスクの完了/未完了状態の管理

2. **表示機能**
   - 全タスクの一覧表示
   - 完了/未完了でのフィルタリング
   - タスクの作成日時表示

## 非機能要件
- レスポンスタイム: 全操作1秒以内
- ブラウザ対応: Chrome, Firefox, Safari最新版
- モバイル対応: レスポンシブデザイン

 ユースケースの生成# docs/usecases/UC-0001_create_task.md
---
title: タスク作成
id: UC-0001
type: usecase
depends_on:
  - ../business/BR-0001_todo_app.md
actors:
  - ユーザー
preconditions:
  - アプリケーションが起動している
postconditions:
  - 新しいタスクがリストに追加されている
  - タスクは未完了状態である
created_date: 2025-08-03
status: approved
---

## 基本フロー
1. ユーザーが「新規タスク」ボタンをクリック
2. システムがタスク入力フォームを表示
3. ユーザーがタイトルを入力（必須）
4. ユーザーが説明を入力（任意）
5. ユーザーが「作成」ボタンをクリック
6. システムがタスクを保存
7. システムがタスク一覧を更新
8. システムが成功メッセージを表示

## 代替フロー
### 3a. タイトル未入力
1. ユーザーがタイトルを入力せずに「作成」をクリック
2. システムがエラーメッセージ「タイトルは必須です」を表示
3. 基本フロー3に戻る

## 例外フロー
### 6a. 保存エラー
1. システムがタスク保存に失敗
2. システムがエラーメッセージ「タスクの作成に失敗しました」を表示
3. ユーザーが再試行またはキャンセルを選択

 ドメインモデルの生成# docs/domain/task_model.md
---
title: タスクドメインモデル
id: DM-0001
type: domain_model
depends_on:
  - ../usecases/UC-0001_create_task.md
  - ../usecases/UC-0002_toggle_task.md
  - ../usecases/UC-0003_delete_task.md
  - ../usecases/UC-0004_edit_task.md
created_date: 2025-08-03
status: approved
---

## エンティティ定義

### Task
タスクを表現する中核エンティティ

#### 属性
| 属性名 | 型 | 必須 | 説明 | 制約 |
|--------|-----|------|------|------|
| id | string | ✓ | タスクの一意識別子 | UUID v4形式 |
| title | string | ✓ | タスクのタイトル | 1-100文字 |
| description | string | - | タスクの詳細説明 | 0-500文字 |
| isCompleted | boolean | ✓ | 完了状態 | デフォルト: false |
| createdAt | datetime | ✓ | 作成日時 | ISO 8601形式 |
| updatedAt | datetime | ✓ | 更新日時 | ISO 8601形式 |

#### ビジネスルール
1. **タイトル必須ルール**: タスクは必ずタイトルを持つ
2. **状態遷移ルール**: 
   - 新規作成時は必ず未完了状態
   - 完了↔未完了は何度でも切り替え可能
3. **更新日時ルール**: 任意の属性変更時にupdatedAtを更新

#### 状態遷移図
```mermaid
stateDiagram-v2
    [*] --> 未完了: 作成
    未完了 --> 完了: 完了にする
    完了 --> 未完了: 未完了に戻す
    未完了 --> [*]: 削除
    完了 --> [*]: 削除

## 9.3 コードの自動生成

### TypeScriptでの実装例

```bash
$ claude-code generate --target=typescript --output=src/

ClaudeCode: ドキュメントからTypeScriptコードを生成します...

生成されるファイル:
- src/domain/task.ts (ドメインモデル)
- src/usecases/taskUseCases.ts (ユースケース実装)
- src/api/taskApi.ts (API実装)
- src/components/TaskList.tsx (UIコンポーネント)
- src/tests/task.test.ts (テストコード)

生成を開始しますか？ [Y/n]: Y
生成されたコード例：
// src/domain/task.ts
// Generated from: docs/domain/task_model.md

export interface Task {
  id: string;
  title: string;
  description?: string;
  isCompleted: boolean;
  createdAt: Date;
  updatedAt: Date;
}

export class TaskEntity implements Task {
  constructor(
    public id: string,
    public title: string,
    public description: string = '',
    public isCompleted: boolean = false,
    public createdAt: Date = new Date(),
    public updatedAt: Date = new Date()
  ) {
    this.validateTitle(title);
  }

  private validateTitle(title: string): void {
    if (!title || title.trim().length === 0) {
      throw new Error('タイトルは必須です');
    }
    if (title.length > 100) {
      throw new Error('タイトルは100文字以内で入力してください');
    }
  }

  toggleComplete(): void {
    this.isCompleted = !this.isCompleted;
    this.updatedAt = new Date();
  }

  update(title: string, description?: string): void {
    this.validateTitle(title);
    this.title = title;
    if (description !== undefined) {
      this.description = description;
    }
    this.updatedAt = new Date();
  }
}

 9.4 仕様変更への対応
 シナリオ: 優先度機能の追加数週間後、ユーザーから「タスクに優先度を設定したい」という要望が届きました。
$ claude-code chat

You: タスクに優先度（高・中・低）を追加したいです。優先度でソートできるようにもしてください。

ClaudeCode: 優先度機能の追加について、既存ドキュメントへの影響を分析します...

影響を受けるドキュメント:
1. BR-0001_todo_app.md - ビジネス要件に優先度機能を追加
2. UC-0001_create_task.md - タスク作成時の優先度選択を追加
3. UC-0004_edit_task.md - タスク編集時の優先度変更を追加
4. UC-0005_sort_tasks.md - 新規：優先度でのソート機能
5. DM-0001_task_model.md - Taskエンティティに優先度属性を追加
6. SR-0001_task_list.md - 画面要件に優先度表示とソート機能を追加

これらの変更を実行してよろしいですか？ [Y/n]: Y

 自動更新されたドメインモデル# docs/domain/task_model.md の差分
@@ -20,6 +20,7 @@
 | title | string | ✓ | タスクのタイトル | 1-100文字 |
 | description | string | - | タスクの詳細説明 | 0-500文字 |
 | isCompleted | boolean | ✓ | 完了状態 | デフォルト: false |
+| priority | enum | ✓ | 優先度 | high, medium, low |
 | createdAt | datetime | ✓ | 作成日時 | ISO 8601形式 |
 | updatedAt | datetime | ✓ | 更新日時 | ISO 8601形式 |

@@ -29,6 +30,10 @@
 2. **状態遷移ルール**: 
    - 新規作成時は必ず未完了状態
    - 完了↔未完了は何度でも切り替え可能
+3. **優先度ルール**:
+   - 新規作成時のデフォルトは「中」
+   - 優先度は作成後も変更可能
+   - ソート順: 高 > 中 > 低
 3. **更新日時ルール**: 任意の属性変更時にupdatedAtを更新

 コードへの自動反映// src/domain/task.ts の自動更新
export enum TaskPriority {
  HIGH = 'high',
  MEDIUM = 'medium',
  LOW = 'low'
}

export interface Task {
  id: string;
  title: string;
  description?: string;
  isCompleted: boolean;
  priority: TaskPriority;  // 追加
  createdAt: Date;
  updatedAt: Date;
}

// ソート関数も自動生成
export function sortTasksByPriority(tasks: Task[]): Task[] {
  const priorityOrder = {
    [TaskPriority.HIGH]: 0,
    [TaskPriority.MEDIUM]: 1,
    [TaskPriority.LOW]: 2
  };
  
  return tasks.sort((a, b) => 
    priorityOrder[a.priority] - priorityOrder[b.priority]
  );
}

 9.5 学びのポイントこのチュートリアルを通じて、以下のDocDDの特徴を体験できました：
ドキュメント起点の開発
すべての変更はドキュメントから開始
コードは常にドキュメントに従属
変更の自動伝播
一つの要件変更が関連するすべてのドキュメントに波及
コードも自動的に更新される
整合性の維持
ドキュメント間の依存関係により不整合を防止
テストも同時に更新され、品質を保証
AIとの協働
自然言語での要求をAIが構造化
面倒な作業はAIが代行、人間は本質に集中

 10. アンチパターンとFAQ 🚨DocDDを実践する中で陥りがちな落とし穴と、その回避方法を紹介します。

 10.1 よくあるアンチパターン
 ❌ アンチパターン1: ドキュメントの過度な細分化症状:
1つの機能に対して10個以上のドキュメントを作成
ドキュメント間の依存関係が複雑すぎて把握困難
小さな変更でも大量のドキュメント更新が必要
原因:
「詳細であればあるほど良い」という誤解
ドキュメントの粒度に関する基準の欠如
解決策:
# ❌ 悪い例：過度に細分化されたドキュメント
docs/
├── usecases/
│   ├── login/
│   │   ├── UC-0001_enter_username.md
│   │   ├── UC-0002_enter_password.md
│   │   ├── UC-0003_click_login_button.md
│   │   └── UC-0004_validate_credentials.md

# ✅ 良い例：適切な粒度
docs/
├── usecases/
│   └── UC-0001_user_login.md  # ログインプロセス全体を1つのUCに
ガイドライン:
ユースケースは「ユーザーが達成したい一つの目標」単位で作成
技術的な実装詳細はドキュメントではなくコードで表現
依存関係が5階層を超えたら構造を見直す

 ❌ アンチパターン2: AIへの過度な依存症状:
AIが生成したドキュメントをレビューせずに承認
ビジネスロジックの理解をAIに丸投げ
エラーメッセージの意味を理解せずに再実行を繰り返す
実例:
# ❌ 悪い例
$ claude-code generate --auto-approve --skip-review

# AIが誤った解釈でドキュメントを生成
# → ビジネス要件と乖離したシステムが完成
解決策:
# ✅ 良い例
$ claude-code generate --interactive

ClaudeCode: 生成したドキュメントをレビューしてください
[レビューモードで内容を確認]

You: 優先度の定義が逆になっています。高優先度が最優先です。

ClaudeCode: 指摘事項を反映して再生成します...

 ❌ アンチパターン3: レガシー思考の持ち込み症状:
ExcelやWordでドキュメントを作成してから変換
コードを先に書いてからドキュメントを生成
Front-matterを使わず、ファイル名だけで関連を表現
解決策:

最初からDocDD前提の構造で作業を開始する：
# ✅ 新規プロジェクトの正しい始め方
1. claude-code init でプロジェクト構造を生成
2. claude-code chat で要件をAIと対話的に整理
3. 生成されたMarkdown/YAMLを直接編集
4. 依存関係は必ずFront-matterで明示

 10.2 FAQ（よくある質問）
 Q1: 既存プロジェクトへの導入方法は？A: 段階的な導入をお勧めします：
# Phase 1: 新機能から適用
- 新しく追加する機能からDocDDを適用
- 既存コードはそのまま維持

# Phase 2: 重要な機能から逆ドキュメント化
$ claude-code reverse-engineer --target=src/core/payment.ts
# 既存コードからドキュメントを生成

# Phase 3: 段階的な移行
- リファクタリング時にDocDD化
- チーム全体の理解が深まってから全面適用

 Q2: ドキュメントの粒度はどう決める？A: 以下の基準を参考にしてください：


ドキュメント種別
推奨粒度
目安


ビジネス要件
機能単位
1つのEpicに相当

ユースケース
ユーザーゴール単位
5-15ステップ程度

ドメインモデル
集約単位
関連する3-7エンティティ

API仕様
リソース単位
RESTfulな1リソース

画面要件
画面単位
1つの画面/ダイアログ


 Q3: AIが意図通りに動かない時は？A: 以下のデバッグ手順を試してください：
# 1. 詳細ログを有効化
$ claude-code --debug generate

# 2. 依存関係の可視化
$ claude-code visualize-deps --output=deps.svg

# 3. スキーマ検証
$ claude-code validate --strict

# 4. プロンプトの明確化
$ claude-code chat --system-prompt="プロジェクトの背景：ECサイトのリニューアル"

 Q4: チームでの運用のコツは？A: 以下の実践が効果的です：
役割分担の明確化
# .docdd/team-roles.yaml
roles:
  product_owner:
    - ビジネス要件の作成/承認
    - 優先順位の決定
  developer:
    - ユースケース/技術仕様の作成
    - 生成コードのレビュー
  designer:
    - 画面要件の作成
    - UIフィードバック
レビュープロセスの確立
# プルリクエストテンプレート
## DocDDチェックリスト
- [ ] ドキュメントから変更を開始した
- [ ] 依存関係を更新した
- [ ] claude-code validate が成功
- [ ] 影響範囲を確認した
定期的な勉強会
週1回のDocDD相談会
成功事例の共有
アンチパターンの振り返り

 Q5: パフォーマンスの問題は？A: 大規模プロジェクトでの対策：
# .docdd/config.yaml
performance:
  # 並列処理の有効化
  parallel_generation: true
  max_workers: 4
  
  # キャッシュ設定
  cache:
    enabled: true
    ttl: 3600
    
  # 増分生成
  incremental: true
  
  # 大規模ドキュメントの分割
  split_threshold: 5000  # 5000行を超えたら自動分割

 11. After & AS‑IS比較──起点と伝播構造📖DocDD導入前（AS‑IS）と導入後（DocDD）の開発スタイルを比較し、

ドキュメント起点の変化と伝播フローの違いを明示します。


比較項目
AS‑IS
DocDD


仕様起点
Figma/Excel/会話など人間中心

docs/以下の構造化ドキュメント

変更伝播
担当者依存、抜け漏れ発生
ClaudeCodeが依存関係を自動検出・一括伝播

テスト生成
実装後に手動作成
構造化ドキュメントからAIが自動生成

整合性担保
コードとドキュメントが乖離しやすい
ドキュメント→コード→テストの一方向整合

保守性
属人化・ブラックボックス化
ドキュメント更新→自動再生成で常に最新状態を維持

DocDDではすべての起点がdocsに集中し、

変更→再生成→展開のサイクルを自動化することで、

保守負荷の大幅な軽減と品質向上を実現します。

 おわりに 🎉DocDD × AIドリブン開発で、ドキュメントとAIを武器に変化に強いチームを築きましょう！
AIがビジネスとエンジニアの架け橋となり、自然言語から価値を生み出す新しい開発スタイルの時代が始まります。
コメント・フィードバックはZennコメント欄やX(Twitter)までお寄せください。

Happy Document Driven & AI-Driven Development! 📚🤖✨

#	フェーズ	INPUT（前）	OUTPUT（次）
1	AS-IS整理	ヒアリング記録、Q&Aテキスト、議事録	業務フロー図、課題一覧
2	ビジネス課題定義	業務フロー図	課題/KPI、ビジネスゴール
3	システム要件定義	課題/KPI	機能一覧、構成図、非機能要件
4	ユースケース定義	機能一覧	UC記述（IN/OUT/例外）、図
5	外部連携要件定義	UC記述、API仕様	IF仕様、エラー設計
6	ドメインルール	UC記述、業務制約	ER図、ドメインルール表
7	画面要件定義	UC IN/OUT、ドメインルール	画面一覧、バリデーション
8	ワイヤーフレーム	画面要件	JSON構造ワイヤー
9	Figma最終UIデザイン（ハイファイ）	ワイヤーフレーム	Figmaで作成された完成形UI（画面要件を精緻化）
10	Figma最終UIデザインからの画面要件アップデート	Figma上で加えられた変更箇所（UI上の差分）	最終的なUI仕様を構造化ドキュメントに反映

元形式	AI対応形式	備考
Excel仕様書	YAMLスキーマ	カラム→プロパティマッピング
PowerPoint	PlantUML（テキストベースの図表記法）	図を構造化して構成図に落とし込む
Figma	JSON diff (#SpecGap)	差分をPatch PR素材として取り込み可能

ドキュメント種別	推奨粒度	目安
ビジネス要件	機能単位	1つのEpicに相当
ユースケース	ユーザーゴール単位	5-15ステップ程度
ドメインモデル	集約単位	関連する3-7エンティティ
API仕様	リソース単位	RESTfulな1リソース
画面要件	画面単位	1つの画面/ダイアログ

比較項目	AS‑IS	DocDD
仕様起点	Figma/Excel/会話など人間中心	`docs/`以下の構造化ドキュメント
変更伝播	担当者依存、抜け漏れ発生	ClaudeCodeが依存関係を自動検出・一括伝播
テスト生成	実装後に手動作成	構造化ドキュメントからAIが自動生成
整合性担保	コードとドキュメントが乖離しやすい	ドキュメント→コード→テストの一方向整合
保守性	属人化・ブラックボックス化	ドキュメント更新→自動再生成で常に最新状態を維持

1. DocDD × AIドリブン開発とは何か？✨──ドキュメント駆動開発の本質と狙い

これによって実現する世界観 🌟

自然言語の活用とドメイン知識の構造化 📚

活用可能な自然言語資産

双方向変換による人間とAIの協働 🔄

構造化データへの変換ルール定義 📐

新しい役割分担 👥🤖

言語の壁を超えるコミュニケーション 🌏

AIチャットボットがハブとなる世界 🤝

⚠️ 重要な注意点：AIは万能ではない

ClaudeCodeによるAI主体の開発へ 🤖

人間はドメイン定義に専念する世界 🎯

暗黙知の言語化と知識構造の形式 📝

言語化すべき暗黙知

知識構造の形式

AIとの連携を強化する仕組み

整合性担保の実践例 💡

ClaudeCodeの実践的な使用例 🚀

レガシーフォーマットからの脱却 🚫

AIフレンドリーな情報伝達 🤖

⚠️ トークン制限への対応

従来の開発からDocDDへの転換

ここまでのまとめ：理想と現実のギャップ 🌉

2. 逆転現象🔥──ドキュメント依存が崩れると何が起きるか？

2.1 典型例：UI先行による部分最適

2.2 逆転が発生する理由

2.3 "画面ありき"開発の落とし穴

2.4 番外編：スピード優先でドキュメント後回し

3. 全体プロセスの骨子🔗――「内から外への依存構造」

3.1 三位一体展開⚙️――DocDDで実現する3つの同期

3.2 生成物修正のフィードバックループ 🔄

4. フェーズ別INPUT→OUTPUT📑

5. AI協働ガイドライン📘――実践チェックリスト

6. AI依存ドキュメントへの視点転換🧠

主なシフトポイント

7. 非構造資料のAI対応変換📂

8. 推奨リポジトリ構成📁

9. 実践チュートリアル：TODOアプリで体験するDocDD 📱

9.1 プロジェクトのセットアップ

ステップ1: プロジェクト初期化

ステップ2: 初期要件の定義

9.2 ドキュメントの自動生成

ビジネス要件の生成

ユースケースの生成

ドメインモデルの生成

9.4 仕様変更への対応

シナリオ: 優先度機能の追加

自動更新されたドメインモデル

コードへの自動反映

9.5 学びのポイント

10. アンチパターンとFAQ 🚨

10.1 よくあるアンチパターン

❌ アンチパターン1: ドキュメントの過度な細分化

❌ アンチパターン2: AIへの過度な依存

❌ アンチパターン3: レガシー思考の持ち込み

10.2 FAQ（よくある質問）

Q1: 既存プロジェクトへの導入方法は？

Q2: ドキュメントの粒度はどう決める？

Q3: AIが意図通りに動かない時は？

Q4: チームでの運用のコツは？

Q5: パフォーマンスの問題は？

11. After & AS‑IS比較──起点と伝播構造📖

おわりに 🎉

Discussion