📜

ドキュメント駆動開発に備える

に公開
GitHub Copilot
docdd
SDD
tech

動機

LLM 関連技術の急速な進展により，GitHub Copilot や Claude Code などの LLM 技術を利用した開発ツールが常態化するようになりました．特に，AI を用いて自然言語でソフトウェア開発を進める vibe coding は，Collins Dictionary の 2025 年の単語[1]にも選出されるほどのバズワードとなり，今年のソフトウェア開発業界で大いに注目されました．Vibe coding によって開発速度が劇的に速くなった一方で，開発を LLM に任せることによる問題として一貫性のない実装，運用の困難性，セキュリティリスクの生成などが挙げられるようになりました．

これらの問題を解決してくれる開発手法，それが ドキュメント駆動開発（Document-driven development; DocDD[2]） だと私は考えています．DocDD では，開発文書を開発の最も重要なものとして位置づけ，機能実装に先んじて文書を作成することを徹底します．特にテスト駆動開発（TDD）と相性が良く，仕様や振る舞いを先に文書化してから，それをテストコードに落とし込み，その後に実装と進めることで，文書の内容に従って一貫性のある開発が実現できるようになります．最近では，仕様書を作成してから実装へと移行する 仕様駆動開発（Specification-driven development; SDD） という考え方が注目されています．AWS の開発する Kiro や GitHub による Spec Kit などがその代表的なツールとして挙げられます．本来こうした開発手法は，ドキュメントを作成することによる時間や人件費の肥大化が問題となっていましたが，LLM の登場によりその問題を乗り越えられるようになりました．AI 中心の開発と欠点を補い合う，理に適った方法論なのではないかと個人的に期待しています．

では，実際にドキュメント駆動開発を行うとなったとき，どのように開発を進めるとより効率的で品質の高い成果が得られるのでしょうか？　LLM を利用した開発において，現在何が課題となっていて，どのように解決されるべきなのでしょうか？　この記事では，こうした疑問の答えを実験によって探っていこうという内容になっています．

実験設定

  • 目的：ドキュメント駆動開発における現状の課題を探る．
  • 環境：
    • エディタ：Visual Studio Code
    • エディタ拡張機能：GitHub Copilot Chat 0.33.4
    • Agent モードを利用
  • 実施概要：
    • ドキュメント駆動開発における課題と目標を設定し，実験用プロジェクトを作成する．
    • GitHub Copilot で利用できる以下のモデルについてそれぞれ試行する．
      • GPT-4o
      • GPT-5.1
      • GPT-5.1-Codex
      • Claude Haiku 4.5
      • Claude Sonnet 4.5
      • Claude Opus 4.5
  • 実施日：2025 年 12 月 7 日

実験1：日本語の文書を生成

  • 目的：
    • AGENTS.md が機能することを確認する．
    • 文書を同じ言語で統一して記述できることを確認する．
  • 課題：
    • ex1
    • AGENTS.md に All Markdown documents MUST be written in Japanese. と記載する．
    • Generate a feature requirement specification of a countdown timer app into `docs/specs/countdown-timer.md`. とチャットで指示する．
  • 目標：
    • docs/specs/countdown-timer.md に，自然な日本語で書かれた文書ファイルが生成される（内容については問わない）．

各モデルの結果

モデル 結果
GPT-4o ex1-gpt-4o
GPT-5.1 ex1-gpt-5_1
GPT-5.1-Codex ex1-gpt-5_1-codex
Claude Haiku 4.5 ex1-claude-haiku-4_5
Claude Sonnet 4.5 ex1-claude-sonnet-4_5
Claude Opus 4.5 ex1-claude-opus-4_5

総合評価

文書を日本語で生成することは，どのモデルでも特に問題ないようでした．ただし，一般的でないカタカナ語など英語から無理やり訳しただけで定義が曖昧になっているような言葉は，仕様としての厳密性を欠く要因となるため注意したいです．実際の文書では，ドメインの用語集を用意したり，プロジェクト内の用語定義を作成したりして，曖昧さを排除する工夫が必要になると考えられます．

実験2：テンプレートに従った生成

  • 目的：
    • 文書が決められた形式に従って柔軟に生成されることを確認する．
    • 文書が決められた場所に作成されることを確認する．
  • 課題
    • ex2
    • .github/prompts/init-requirement.prompt.md に，要求仕様書を決められたテンプレート通りに docs/specs/<feature-name>/requirements.md に作成するような指示を記載する．
    • /init-requirement カウントダウンタイマー機能 とチャットで指示する．
  • 目標
    • docs/specs/countdown-timer/requirements.md に，テンプレート通りの形式で要求仕様書が生成される．
    • 対象となる利用者やその想定ストーリー，機能要件・非機能要件のカテゴリ数や小項目数など，その内容に応じて個数が増減している．

各モデルの結果

モデル 結果
GPT-4o ex2-gpt-4o
GPT-5.1 ex2-gpt-5_1
GPT-5.1-Codex ex2-gpt-5_1-codex
Claude Haiku 4.5 ex2-claude-haiku-4_5
Claude Sonnet 4.5 ex2-claude-sonnet-4_5
Claude Opus 4.5 ex2-claude-opus-4_5

総合評価

テンプレート通りの形式で文書を生成することは，どのモデルでも問題なく実現できました．テンプレート内で列挙すべき項目数については，Claude 系モデルは特に指示がなくても項目数を柔軟に変更していましたが，GPT 系モデルはテンプレートに基本的に忠実で，今回の実験としては後者は要求仕様としては考慮不足という評価になりそうです．柔軟性を求めるか忠実さを求めるかはテンプレートの設計次第にはなりそうですが，一貫性のためにはテンプレートの柔軟性も指示に盛り込むことが重要だと感じました．

実験3：ID追跡

  • 目的：
    • 記載通りの ID を目的通り活用できることを確認する．
    • 要求 → 設計 → テストの関連付けを明示し，一貫性の向上やレビュー負荷の低減が実現できることを確認する．
  • 課題
    • ex3
    • .github/prompts/init-external-design.prompt.md に，要求仕様書に書かれた ID を関連付ける形で外部設計書を docs/specs/<feature-name>/external-design.md に作成するような指示を記載する．
    • docs/specs/countdown-timer/requirements.md に要求仕様書を用意する．
    • /init-external-design countdown-timer とチャットで指示する．
  • 目標
    • 要求仕様書の各要求に対する ID を適切に外部設計と関連付けている．

各モデルの結果

モデル 結果
GPT-4o ex3-gpt-4o
GPT-5.1 ex3-gpt-5_1
GPT-5.1-Codex ex3-gpt-5_1-codex
Claude Haiku 4.5 ex3-claude-haiku-4_5
Claude Sonnet 4.5 ex3-claude-sonnet-4_5
Claude Opus 4.5 ex3-claude-opus-4_5

総合評価

GPT-4o は，要求仕様書の各要求を一対一に外部設計に関連付けするような戦略を取っていましたが，REQ-4 の要求や非機能要件に対応する設計項目が抜けていたり，画面遷移に関する設計が不足していたりと，要求を十分に満たせていない印象でした．GPT-5.1 系モデルは GPT-4o とは異なり，設計に関連する複数の要求 ID をまとめて関連付けるような工夫が見られましたが，要求にない API 設計やデータ設計にも無理やり要求 ID を関連付けていたり，説明が要求を十分に満たすような内容になっていなかったりと，やはり要求を十分に満たせていない印象でした．Claude 系モデルは，要求にない設計項目については要求 ID を空欄にして，要求を満たす設計項目については適切に関連付けを行うなど，より要求の内容を反映した設計になっている印象でした．全体的に GPT 系モデルよりも Claude 系モデルの方が要求に対して正確に設計項目を作成できていましたが，Claude Opus だけが今回の設計に API 設計やデータ設計が不要であることを見抜いていました．

まとめ

この記事では，ドキュメント駆動開発を実際に運用するための課題等を実験によって分析することを試みました．どのモデルでもプロンプトの書式に沿った文書を生成できていましたが，Claude 系モデルの方が少ない指示でも柔軟に対応できている印象を受けました．また，複雑な課題になればなるほど，Claude Opus のようなより性能の高いモデルの優位性がみられる結果となりました．

ここでは 3 つの課題設定について実験しましたが，他にも試してみたい課題はいくつか考えられます．例えば，設計に沿ってテストが生成できるか，開発中の知見を記録して再利用できるか，など挙げられます．今後も実験を継続してさらに知見を深めていき，ドキュメントを主体とする開発への備えとしたいです．

脚注

  1. https://blog.collinsdictionary.com/language-lovers/collins-word-of-the-year-2025-ai-meets-authenticity-as-society-shifts/ ↩︎

  2. DDD だとドメイン駆動設計（Domain-driven design）と略称が被ってしまうため，敢えて DocDD としているのだと思っています．古い文献では DDD と略しているものもみられました． ↩︎

Discussion