バイブコーディング時代にこそDocDD（Document Driven Development）が効く——AI×設計ドキュメントで「作り直し地獄」を防ぐ実践ガイド【2026年版】

2025〜2026年はソフトウェア開発のパラダイムが根本から変わった年です。Claude Code、Cursor、GitHub Copilotなどの自律型AIコーディングツールにより、エンジニアは自然言語で要件を伝えるだけで大量のコードを生成できるようになりました。いわゆる「バイブコーディング（vibe coding）」の時代です。 しかし現場では新しい問題が生まれています。「雰囲気で書かせたら動いたけれど、本番で使えない」「あとで仕様変更が入ったら全部書き直し」「AIが気の利いた拡張をしすぎて、コードベースが整合性を失う」——こうした「作り直し地獄」が、AIコーディングの高速性を帳消しにしています。本記事では、その解決策として注目されている DocDD（Document Driven Development、ドキュメント駆動開発） について、実践的な使い方を解説します。

「設計ドキュメント（Design Doc）を先に書いてから実装する」という考え方を略して DD と呼ぶケースもありますが、ソフトウェア業界では DDD（Domain-Driven Design、ドメイン駆動設計）が既に定着しており、略称で衝突します。本記事では混同を避けるため、Zenn のokikusan氏が2025年7月に公開した記事で提案されている DocDD（Document Driven Development） の呼称を採用します。 DocDDとはひとことで言えば、「ドキュメントを一次情報の源泉とし、コードとテストはそこから生成される従属物として扱う開発プロセス」です。AIコーディング時代において特に強力に機能する理由は、後述します。 参考記事: okikusan「AI駆動ドキュメント駆動開発（DocDD）実践ガイド：設計・実装・テストを自動化する新時代の開発プロセス」（Zenn、2025年7月7日）

バイブコーディングは、元々Andrej Karpathy（OpenAI創業メンバー、元Tesla AI Director）が2025年初頭にX（旧Twitter）で提唱した言葉です。「コードを書くのではなく、AIに雰囲気（vibe）を伝えて書いてもらう」スタイルを指します。AIコーディングツールの能力が急速に高まったことで、 - 自然言語で機能を依頼 → AIが実装 - 動作を確認してフィードバック → AIが修正 - ループを回しながら機能を肉付け というワークフローが主流になりつつあります。素早くプロトタイプを作るには最強のスタイルである一方、プロダクション品質のコードを長期運用するフェーズでは弱点が露呈します。

AIに「雰囲気」で書かせたときに発生する典型的な問題は次の5つです。 1. 要件ドリフト: AIが毎回微妙に違う実装を提案し、積み重なるうちに「もともと何を作りたかったのか」が見えなくなる 2. 設計の不在: 個別の機能は動くが、全体のアーキテクチャに一貫性がなく、機能追加のたびに矛盾が発生する 3. データモデルの不整合: APIのレスポンス形状・DBスキーマ・フロントの型定義が食い違い、後から整合させる工数が膨らむ 4. テストされない「それっぽい」実装: 見た目は動くが、境界条件・例外ケース・並行処理などでバグが潜在 5. 引き継ぎ不能: 設計意図がコードにもコメントにも残らず、後任のエンジニア（や未来の自分）が理解できない

DocDD（Document Driven Development）は、コードを書き始める前に Design Doc（設計書）を書いて、そこから実装を進める開発スタイルです。Google・Meta・Stripeなど、大規模システムを運用する開発組織では以前から当たり前に行われてきた手法で、AIコーディング時代に再評価されています。 okikusan氏の記事では、DocDD の要点として次のような考え方が提案されています（概要を要約）。 - ドキュメントを「一次情報の源泉」として位置付け、コードとテストはそこから生成される従属物として扱う - Why → What → How の順序を厳密に守ることで部分最適を防ぐ - Front-matter（ドキュメント冒頭のYAML）で依存関係を明示し、変更伝播を自動化する - 人間はドメイン知識の言語化に専念し、AIが実装・テスト生成を担当する 本記事では、この方針を「バイブコーディングの弱点を埋める実践テクニック」として具体的に落とし込んでいきます。詳細な理論はokikusan氏の元記事をあわせてお読みください。

新機能を作る前に最低限書いておきたい項目は以下の7つです。

この7項目があれば、AIに具体的かつブレのない実装指示を出せます。okikusan氏の元記事ではさらに、Front-matterでのID・依存関係・ステータス・承認者の明示、`#approved` `#DoNotEdit` `#NeedsHumanCheck` 等のタグ管理までカバーされており、大規模プロジェクトで運用する場合はこちらも参照することを推奨します。

株式会社オブライトでは、上記の7項目テンプレを出発点として、以下のフローを標準運用にしています。これはokikusan氏のDocDDの基本思想（ドキュメントを一次情報源にする）の上に、弊社が日々のAI開発で磨いてきた実務的なやり方です。 1. 7項目テンプレを手元で箇条書き: 機能の背景・目的・スコープ・ざっくりの方針だけ粗く書き出す（10〜15分） 2. AIと壁打ち: その粗いメモをClaude CodeやClaudeチャットに渡し、「抜け漏れ・矛盾・代替案・エッジケースを指摘して」と依頼。AIは「ここ曖昧」「この制約は？」「このデータモデルだと拡張性が低い」等を返してくる 3. やり取りを踏まえて plan.md を書く: 壁打ちで浮上した論点を吸収しつつ、7項目テンプレに沿った設計書を `docs/plan/<feature>.md` として確定。人間が最終判断を下す場 4. plan.md をAIに読ませて実装依頼: Claude Codeに `CLAUDE.md` から `docs/plan/<feature>.md` を参照させ、「この設計書に沿って実装」と指示。AIは曖昧さゼロの状態から実装を始められる 5. 実装中にズレを発見したら plan.md から直す: コードを直す前にドキュメントを直す。これが一次情報源を保つ鉄則 このフローの肝は、AI壁打ちで設計品質を上げてから plan.md に落とす こと。最初から完璧なドキュメントを書こうとせず、AIを「設計レビュアー」として使って粗いメモを磨いていきます。いきなり実装を依頼するより手戻りが激減します。

DocDD のドキュメントをあらかじめ書いておくと、AIコーディングの精度が劇的に上がります。理由はシンプルで、設計書そのものが最高品質のプロンプトになるからです。 - 曖昧さの消失: 「いい感じに」「普通に」「適切に」といった曖昧ワードが排除されるため、AIの想像で勝手に決める余地がなくなる - 再利用性: 同じドキュメントを複数のAI（Claude Code・Cursor・Codex等）に渡して比較できる。セッションを跨いでも同じ設計意図を再入力できる - レビュー可能性: 実装前に人間がレビューできるため、設計レベルのミスを実装前に検出できる - ドキュメント兼用: 設計書がそのままコードベースの仕様資料になる。未来の自分や後任が理解できる - バージョン管理: git管理することで、設計判断の変遷が追跡できる - 変更伝播（okikusan氏の指摘）: Front-matterで依存関係を明示しておけば、1つの要件が変わったときに関連ドキュメント・コード・テストへの波及をAIが自動で処理できる

主要なAIコーディングツールでのDocDD活用パターンは次の通りです。

共通するのは「設計書をツールが常に参照できる位置に置いておく」ことです。okikusan氏の記事では、Front-matterでのメタデータ管理（ID・depends_on・status・承認者等）と `docs/` 配下の構造化テンプレートが推奨されており、プロジェクト規模が大きくなるほど有効です。

DocDDへの典型的な反論と、それへの回答です。 反論1: 「AIが速くなったのだから設計書なんて書いている時間がもったいない」 → 書かなかった結果の作り直しコストの方が圧倒的に高いです。設計書に1時間かけて作り直しを10時間防げるなら、純利益9時間です。 反論2: 「アジャイルなのでドキュメントは書かない主義」 → DocDDは完璧な詳細設計書ではなく、現時点での合意をまとめた軽量ドキュメントです。アジャイル原則に反しません。StripeやLinear等のアジャイル組織も実際に使っています。 反論3: 「プロトタイプならドキュメントなしで動かしてから考えればいい」 → 使い捨てのプロトタイプならバイブコーディング単独で問題ありません。しかし「このプロトタイプがそのまま本番になる」ケースは現場で頻発します。最初からドキュメントを書くクセをつけると、そのまま本番移行できます。 反論4: 「AIに設計書も書かせればいい」 → 設計書は「何を作るか」を人間が決めるための場です。AIに「何を作るべきか」自体を決めさせるとビジネス要件との乖離が起きます。弊社フローの Step 2（AI壁打ち）のようにAIを壁打ち・レビュー相手として使うのは問題ありませんが、最終判断は人間が下してください。

株式会社オブライトでは、社内のソフトウェア開発プロジェクトでDocDD駆動のAI開発を標準化しています。 - 機能単位で plan.md を作成: 新機能を着手する前に1〜3ページの設計書を必ず書く（AI壁打ちを活用） - Claude Codeに CLAUDE.md / docs/plan をコンテキストとして読み込ませる: 実装時に設計意図が毎回参照される - コードレビューで設計書との整合性もチェック: PRレビュー時に「plan.mdと違うこと」をしていないか確認 - 設計書そのものも git 管理: 設計判断の履歴がコミットに残る この体制により、AIで高速開発しつつ、長期運用に耐える品質を維持できています。Web開発・業務システム構築・AI BPOの受託案件のいずれでもこの方針を採用しています。

Q1. 設計書はどのくらいの長さで書けばいいですか？ 機能の大きさによりますが、1機能あたり1〜3ページ（A4相当）が目安です。10ページ超えは詳細化しすぎ、1ページ未満はスコープ過小の可能性があります。 Q2. 設計書を書くのは誰の役割ですか？ 実装を担当するエンジニア本人が書くのが理想です。他人に書かせると設計意図が伝わらず、結局実装中に解釈が揺れます。複数人プロジェクトではテックリードが最終レビュー。弊社では「7項目メモ → AI壁打ち → plan.md確定」を全員が手を動かして行います。 Q3. DocDDとRFCの違いは何ですか？ RFCは組織レベルの技術選定（例: 採用言語、認証基盤の選定など）で使われる重量ドキュメント、DocDDの plan.md は機能単位の軽量設計書です。RFC ⊃ plan.md と捉えると分かりやすいです。 Q4. AIに設計書レビューもやらせていいですか？ 穴探し・矛盾指摘・代替案提示をAIに依頼するのは有効で、弊社フローでも Step 2（AI壁打ち）として積極的に使います。ただし最終判断は人間が下してください。AIは「妥当な選択肢」は出しますが「ビジネス上の正解」を知らないため。 Q5. 既存プロジェクトで途中からDocDDを導入するには？ 新機能から始めてください。既存コードをすべてドキュメント化する必要はありません。新規開発分だけでも半年後には大きな差が出ます。okikusan氏の記事でも、段階的導入を前提とした構造化テンプレートが提案されています。 Q6. DocDDの書き方を学ぶのにおすすめの資料は？ 本記事で参照している okikusan氏のZenn記事（下記参考文献参照）が体系的で分かりやすいです。英語圏では「Design Docs at Google」「Stripe Increment誌のDesign Docs記事」「Will Larson著『An Elegant Puzzle』」などが定番です。 Q7. オブライトにDocDD駆動のAI開発を依頼できますか？ はい。Web開発・業務システム・AI BPOの受託案件で、DocDD駆動のAI開発体制を採用しています。既存プロジェクトのAI開発移行支援、設計書テンプレート導入支援もご相談いただけます。まずはお問い合わせまたはAI導入コンサルティングをご覧ください。

- okikusan「AI駆動ドキュメント駆動開発（DocDD）実践ガイド：設計・実装・テストを自動化する新時代の開発プロセス」Zenn、2025年7月7日公開。https://zenn.dev/okikusan/articles/024dfd71536d68 - 本記事の「DocDD」呼称、「ドキュメントを一次情報の源泉とする」思想、Front-matterによる依存関係管理・変更伝播、AIが能動的に矛盾を検出するワークフローの考え方は、同記事を参照しています。概念の要約部分のみを引用し、具体的な実装の落とし込み・オブライト社内の運用フロー・FAQは弊社オリジナルです。詳細な理論は元記事をあわせてお読みください。 - Andrej Karpathy, "vibe coding" （X投稿、2025年初頭）

AIコーディングの高速性は、DocDDの事前設計とかけ合わせることで初めて持続可能な開発速度になります。設計書は古臭いドキュメント作業ではなく、AI時代の「最高のプロンプト」です。作り直し地獄に陥らないために、今日から次の新機能で「7項目メモ → AI壁打ち → plan.md → AIに読ませて実装」のフローを試してみてください。 - AI導入コンサルティング: AI駆動開発の体制構築支援 - ソフトウェア開発: DocDD駆動のAI開発を前提とした受託開発 - お問い合わせ: 設計書テンプレート提供・既存プロジェクトへの導入支援もご相談ください