Zenn
👨‍🔬

Draft Driven Development：壊れることを前提にしたAI開発手法を考えてみた(実験的)

に公開
個人開発
Cursor
OpenAI
生成 AI
tech

概要

AIを活用した開発手法（例：Vibe Coding）が注目されていますが、プロジェクトが大きくなるにつれ、以下のような課題が浮上します。

  • 全体のアーキテクチャを無視して局所的なタスクに集中してしまう
  • コード量が増えると、AIが初期の設計意図や制約を「忘れ」、一貫性のない提案をする
  • 開発者が明確なガイドラインやタスクのスコープを提供しないと、AIがその場しのぎの解決策を生成する

これにより、プロジェクト後半でコード生成がうまくいかず、修正に手間がかかる問題が頻発します。この課題を解決する実験的な手法として、「Draft Driven Development（ドラフト駆動開発）」というものを考えてみました。

1. Draft Driven Developmentとは？

Draft Driven Developmentは、まず動くコード（Draft）を素早く作り、そこから設計を固めて本番用コード（Production）に昇格させる 開発手法です。以下の特徴を持っています。

  • DraftとProductionの分離：ディレクトリレベルで明確に分け、品質基準を満たしたコードのみをProductionに昇格
  • スピードと品質の両立：自由な試作で素早くアイデアを形にし、厳格な審査で品質を担保

なぜ“逆転”と"分離"が必要なのか？

従来の「設計→コーディング」という順序は、AI時代では以下のような理由で難しい場合があります。

  • アイデア先行の開発：多くの開発者は詳細な設計をせず、アイデアをコードで試す（AIのコード生成を通じて仕様が具体化されるため、設計が流動的）
  • AIの制約：AIはファイル単体を見ても、それが試作中か正式なコードかを判断できない（これが意図しない複雑性やコードの汚染を引き起こす）

そこで、コーディングが設計に先行するスタイルを前提に、DraftとProductionを物理的に分離することで、自由な試作と品質管理を両立させます。

2. Draft Driven Development

Draft Driven Developmentを支えるのは「2層コンテキスト管理」と「Draft-Drivenワークフロー」です。

2-1.2層コンテキスト管理

Draft（自由な発散）とProduction（厳格な収束）をディレクトリレベルで分離し、AIが適切に動作する環境を構築します。以下はNext.jsプロジェクトを例にしたディレクトリ構造です。

──
├── README.md
├── package.json
├── next.config.js
├── public/
├── src/
│   ├── app/                 
│   │    ├── page.tsx         # 正式なルート（production）
│   │    └── layout.tsx       # レイアウト
│   ├── drafts/               # Draftエリア（実験用コード）
│   │    ├── components/
│   │    ├── features/
│   │    ├── lib/
│   │    └── README.md
│   ├── components/           # 正式なコンポーネント
│   ├── features/             # 正式なドメイン機能
│   ├── lib/                  # 正式なライブラリ
│   ├── hooks/                # 正式なカスタムフック
│   ├── styles/               # グローバルスタイル
│   └── types/                # 型定義
├── .gitignore
├── tsconfig.json
└── .eslintrc.js
  • Draftエリア：アイデアを自由に試し、失敗を許容。制約を最小限に。
  • Productionエリア：型安全性、SOLID原則、テスト整備を必須とし、厳格な品質を要求。

2-2.Draft-Drivenワークフロー

Draftで試作し、動くプロトタイプで機能を確定。設計を整理して品質を高め、昇格ゲートで審査後、Productionに移動します。このサイクルでスピードと品質を両立します。

フェーズ 目的 特徴 成果物
Draftコーディング アイデアを素早く形にし、試作する 制約なし、自由な実装。要件変動を許容。 動くプロトタイプコード
設計整理フェーズ コードを本番品質に近づける SOLID原則・型安全性・テストコードを追加。設計見直し。 正式昇格候補コード
昇格ゲート 本番環境に耐えるか審査する レビューにより品質基準（設計、テスト、命名、一貫性）を満たすか確認 合格: 正式ディレクトリ移動
不合格: Draftへ戻し修正

3.具体的な実施手順

3-1.Draft配下のファイルテンプレート化

Draft配下のファイルは**.draft.tsのような命名規則を採用し、以下のテンプレートを保持します。これにより、試作の目的や状態を明確化します。

// drafts/components/SampleButton.draft.tsx

/**
 * Draft Name: SampleButton
 * Purpose: ユーザーにクリックさせるためのサンプルボタン試作
 * Status: Drafting
 *
 * TODO:
 * - [ ] デザインブラッシュアップ
 * - [ ] ロジック整理
 * - [ ] テスト追加
 */

'use client';

import React from 'react';

export const SampleButton = () => {
  return (
    <button className="p-2 bg-blue-500 text-white rounded">
      Sample Button
    </button>
  );
};

3-2.コードの昇格

プロトタイプが機能することを確認したら、以下のステップでProductionへの昇格を進めます。

3-2-1.プロンプトの生成

Draftの目的と役割を明確化し、AIにリファクタリングを依頼するプロンプトを作成します。

このDraftコードの目的と役割は以下の通りです：

【目的】
- ユーザーがボタンを押すことでAPIリクエストを発行

【役割】
- UI表示
- APIトリガー

以下のリファクタリングを行ってください：
- TypeScriptの型を明示
- 冗長なコードや仮コードを削除
- 命名規則（PascalCase, camelCase）に準拠
- コードを関数やコンポーネント単位に分割
- プロジェクトのアーキテクチャ（例：Presentation層/Domain層）に準拠
- 最低限のユニットテストを作成

3-2-2.コード修正とファイル分割

AIにプロンプトを渡し、型安全性の確保や責務分離を行います。以下は分割例です。

分割の具体例

ファイル 役割
Button.tsx ボタンの見た目（UIコンポーネント）
useButtonHandler.ts ボタンのビジネスロジック（カスタムフック）
api.ts API呼び出しロジック

3-2-3.昇格ゲートの実施

修正されたファイルに関して下記のプロンプトを投げます

あなたはDraft Driven Developmentの昇格ゲート審査員です。以下のコードを読み、昇格基準を満たしているか判定してください。

【昇格基準】
1. 動作要件：明らかなエラーなく、期待通りの動作をするか
2. 型安全性：TypeScriptの型エラーなし（any/unknownの濫用禁止）
3. 命名規則：変数名、関数名、コンポーネント名が命名規則に準拠
4. コード設計：アーキテクチャパターンに沿った責務分離、Fat Componentや巨大関数の排除
5. 不要コード：仮コード、console.log、コメントアウトの削除
6. テスト：主要ロジックのユニットテストが存在
7. ドキュメント：ファイル先頭に目的・役割・使い方を記載

【出力フォーマット】
- 判定結果：（昇格可 / 昇格不可）
- 不合格理由：（リスト形式で具体的に）
- 修正指示：（箇条書きで具体的に）

対象コード：
（コードをここに貼る）

ここまでがDraft Driven Developmentの一連のワークフローです！

4.本当にDraft Driven Developmentは必要か？

ここまでDraft-Driven Developmentについて書いてきましたが、改めて冷静に立ち返ると、そもそもこんな仕組みが本当に必要なのか？という根本的な疑問も当然あります。
この章では、あえてこの手法に対する「懐疑的視点」も整理しておきます。

4-1. 従来の手法でも十分では？

従来の開発手法――例えば、

  • Gitブランチ運用（featureブランチ→pull request→main統合）
  • PRレビューによる品質管理
  • lintや型検査、テストによる自動チェック

これらをちゃんと運用していれば、実は DraftとProductionを分ける物理的な仕組み は不要な場合も多いです。「設計→実装→レビュー」という流れを自然に回せるなら、わざわざDraft環境を設ける必要はないと思います。

4-2. 「Draftに溜める」こと自体がリスクにもなる

Draftフォルダにコードをどんどん溜め込むと、永遠に昇格されないコード、誰もメンテしない「墓場化ファイル」が生まれる可能性もあります。これは技術的負債の温床になりかねません。
「Draft」という場所が安心感を生んでしまい、結局、品質向上や設計整理が後回しになるリスクもあります。

4-3. 小さく開発して小まめにリファクタする、という原則を守れるなら不要

そもそもソフトウェア開発の原則は、 大きく作らず、小さく作って、素早く回す こと。
これを守れるなら、DraftとProductionを分ける必要すらないわけです。

  • 小さな機能ごとにきちんと設計して
  • ちゃんと型をつけて
  • 小さい単位でリリースする

これを地道に回すほうが、プロジェクトとしては堅実なケースもあります。

5. まとめ

今回まとめたDraft-Driven Developmentは、間違いなく「超実験的」な発想です。
今すぐ全ての現場で使えるものではありません。

ただ、AIがコーディングパートナーとなりつつある今、

  • 設計より先にコードが出てきてしまう
  • とりあえず動くものを作ってから考える
  • コードを通して仕様が形作られていく

こんな新しい開発スタイルが現実に起きているのも事実です。
その過渡期を乗り越えるための「雑に作る自由」と「品質を守る仕組み」を同時に持つ道具として、役立つ場面があるかもしれません。

もしこの考え方が、誰かの「ちょっと新しい開発の仕方」を考えるヒントになったなら嬉しいです。
またアップデートしていきたいので、ぜひ意見ください！

Discussion