アジャイルAI駆動開発のすすめ

〜仕様駆動開発の落とし穴と、その先へ〜

はじめに

「AIにコードを書かせたら開発が爆速になる」

そんな期待を胸に、AI駆動開発を導入したチームは多いのではないでしょうか。

実際、ChatGPTやClaudeといったLLMは驚くほど高品質なコードを生成してくれます。要件を伝えれば設計書を書いてくれますし、設計書を渡せば実装コードを出力してくれます。これは革命的です。

しかし、いざ本格的に運用してみると、「あれ、思ったほど速くならないな」と感じることはないでしょうか。

私たちのチームも同じ壁にぶつかりました。そして気づいたのは、AIを導入しても、プロセス自体がウォーターフォールのままでは速度が出ないということでした。

本稿では、私たちが経験した課題と、そこから見えてきた「アジャイルAI駆動開発」という新しいアプローチについて共有します。

1. 従来のAI駆動開発（仕様駆動開発）とは

そもそも、どんなアプローチなのか

AI駆動開発として広く採用されているのは、仕様駆動開発と呼ばれるアプローチです。

流れはシンプルです。要求をもとにAIが要件書を作り、その要件書をもとに技術設計書を作り、設計書をもとに実装計画を作り、最後に実装コードを生成します。

要求 → 要件書 → 技術設計書 → 実装計画書 → 実装コード

各段階でAIがドキュメントを生成し、人間がレビュー・承認してから次へ進みます。きれいな直列のフローです。

このアプローチの背景にある考え方

仕様駆動開発の根底には、こんな思想があります。

「AIは詳細な仕様があれば正確なコードを書ける」 — だから、まず仕様を固めよう
「上流の品質が下流を決める」 — だから、要件書からしっかり作ろう
「段階的なレビューで品質を担保できる」 — だから、各フェーズでチェックしよう

これ自体は間違っていません。特に大きな機能開発や、複雑なシステムでは有効なアプローチです。

実際のワークフロー例

典型的なワークフローはこんな感じになります。

Step 1: 要件書を生成
  「この機能を追加したい」→ AIが要件書を出力
  → チームでレビュー → OKなら次へ

Step 2: 技術設計書を生成
  要件書をもとに → AIが技術設計書を出力
  → チームでレビュー → OKなら次へ

Step 3: 実装計画書を生成
  設計書をもとに → AIが実装計画を出力
  → チームでレビュー → OKなら次へ

Step 4: 実装コードを生成
  計画書をもとに → AIがコードを出力
  → コードレビュー → マージ

各ステップでプロンプトのテンプレートを用意し、前段階の成果物をインプットにして次の成果物を生成します。ドキュメントがどんどん積み上がっていきます。

2. AI駆動開発の問題点

問題1: ウォーターフォールの呪縛

ここまで読んで、「あれ、これってウォーターフォールでは？」と思った方は鋭いです。

そう、仕様駆動開発は本質的にウォーターフォールモデルなのです。だから、ウォーターフォールが抱える問題がそのまま発生します。

フィードバックループが長い。

小さな機能追加でも、要件書を書いて、レビューして、設計書を書いて、レビューして...と進めていくと、あっという間に数日が経ちます。実装自体は30分で終わるのに、プロセスを回すのに1週間かかる、なんてことが起きます。

手戻りのダメージが大きい。

実装フェーズで「あ、設計がおかしかった」と気づいても、設計書を直して、実装計画を直して、実装をやり直して...と連鎖的な修正が発生します。AIが書いているとはいえ、それぞれレビューが必要ですから、結局時間がかかります。

問題2: 全部同じプロセスで回してしまう

これが意外と見落とされがちな罠です。

「一覧画面に項目を1つ追加する」というタスクと、「新しい集計機能を追加する」というタスク。どちらも同じフルプロセスで回していないでしょうか？

タスク	実際の作業量	仕様駆動での工数
表示項目を1つ追加	30分	4〜8時間
バリデーション修正	15分	4〜8時間
新規画面を追加	2日	2〜3日（妥当）
大規模機能追加	1週間	1週間（妥当）

小さなタスクにフルプロセスを適用すると、オーバーヘッドが実作業を大幅に上回ってしまいます。これでは本末転倒です。

問題3: ドキュメントを作ることが目的化する

「要件書を書いたから、次は設計書」「設計書を書いたから、次は実装計画」

このフローが定着すると、いつの間にかドキュメントを作ること自体が目的になってしまいます。

実際には不要な詳細まで書き込んでしまう
ドキュメント間の整合性を保つのに時間を取られる
「前のドキュメントにこう書いてあるから」と思考停止する

ドキュメントは手段であって目的ではありません。でも、プロセスとして固定化されると、この当たり前のことを忘れてしまいがちです。

問題4: AIの強みを活かしきれていない

ここが一番重要なポイントかもしれません。

人間のチーム開発では、設計者と実装者が別人であることが多いです。だから設計書は「他者への伝達手段」として必要になります。

でも、AIは違います。AIは設計者と実装者を兼ねることができるのです。

考えてみてください。AIは会話の中で設計意図を保持したまま実装ができます。手戻りがあっても、再生成すればいいだけでコストが低いです。同じAIが設計も実装もするなら、解釈のブレも生じません。

なのに、わざわざ設計書という「中間成果物」を作って、それをまたAIに読ませて実装させている。これって、人間向けに設計されたプロセスをそのままAIに適用しているだけではないでしょうか？

3. アジャイルAI駆動の提言

基本的な考え方

私が提案するのは、タスクの大きさに応じてプロセスを変えるというシンプルなアプローチです。

小さいタスクは最短ルートで。大きいタスクはしっかり設計を。当たり前のことですが、これをちゃんとやるだけで、開発のスピードは大きく変わります。

加えて、AIの特性を活かすことも重視します。設計と実装を分けずに同時に進めることで、中間成果物を減らし、フィードバックを速くします。

タスクサイズを3つに分ける

まず、タスクを3つのサイズに分類します。

サイズ	こんなタスク	目安の期間
S（小）	項目追加、バリデーション修正、文言変更	1日以内
M（中）	新規画面、新規API、中規模の機能改修	2〜3日
L（大）	複数機能にまたがる変更、新規概念の導入	1週間以上

判断基準はシンプルです。

変更するファイルが1〜2個で、既存のパターンを踏襲するだけ → S
変更するファイルが3〜5個、または新しいAPIや画面を追加 → M
複数の機能に影響する、DBスキーマ変更を伴う、1週間以上かかりそう → L

サイズごとに違うプロセスで

ここが肝心なところです。サイズごとにプロセスを変えます。

Sサイズ: 即実装

要求 → AIが即座に実装 → PRレビュー → 完了

設計書は書きません。変更内容を数行のサマリとして残すだけです。とにかくシンプルに、速く回します。

Mサイズ: 軽量設計

要求 → AIが設計メモ+実装を同時に生成 → PRレビュー → 完了

設計と実装を別々にせず、AIに一気に出力させます。設計メモはあくまでコードと一緒に出力されるもので、別途レビューのステップを挟みません。

Lサイズ: しっかり設計

要求 → 設計書 → 設計レビュー → サブタスクに分割 → 各タスク実装 → 完了

大きなタスクは従来通りしっかり設計します。ただし、設計書は1つのドキュメントに統合して、ドキュメントの数は減らします。

「設計と実装の同時進行」という発想

Sサイズ・Mサイズでは、設計と実装を分けないというのがポイントです。

人間が設計するときは、まず頭の中で考えて、それを言語化して設計書にして、その設計書を見ながら実装します。設計と実装は別のフェーズになります。

でもAIは違います。AIは「こういう設計で実装して」と言えば、頭の中（コンテキスト）に設計を保持したまま、そのまま実装まで進められます。

だったら、わざわざ設計書という中間成果物を作る必要はありません。「要件を伝えて、実装コードと一緒に設計メモも出力して」と頼めばいいのです。

[従来]
人間 → 設計書を作って → AI、設計書を読んで → 実装コードを出力

[提案]
人間 → 要件を伝えて → AI、設計しながら実装 → 設計メモ+コードを同時出力

こうすることで、レビューの回数も減りますし、フィードバックも速くなります。

4. 新規プロンプト構成

サイズ別プロンプトの設計

従来のワークフローでは、段階ごとに複数のプロンプトを用意していました。

[従来]
01_要求_to_要件書.md
02_要件書_to_技術設計書.md
03_技術設計書_to_実装計画書.md
04_実装計画書_to_コード.md

これを、サイズ別の3つのプロンプトに統合します。

[提案]
task_small.md   # Sサイズ用（1プロンプトで完結）
task_medium.md  # Mサイズ用（軽量設計+実装）
task_large.md   # Lサイズ用（設計→実装の2フェーズ）

Sサイズプロンプトの概要

入力: チケット情報、補足説明

出力:

変更サマリ（何をなぜ変えたか、3〜5行）
実装コード
動作確認手順

特徴:

既存の類似実装を検索し、パターンを踏襲
プロジェクトの知識ベース（contexts）を参照
設計書を書かない代わりに「変更理由」を残す

Mサイズプロンプトの概要

入力: チケット情報、補足説明

出力:

設計メモ（要求サマリ、影響範囲、DB/API変更、実装方針）
実装コード
テストコード
動作確認手順

特徴:

設計メモと実装を同時出力
判断に迷う場合は実装前に人間に質問
影響範囲をレイヤー別に整理

Lサイズプロンプトの概要

Phase 1（設計）の出力:

設計書（概要、技術設計、実装方針、サブタスク分割、テスト方針）

Phase 2（実装）の出力:

サブタスクごとの実装コード

特徴:

設計レビューを挟んでから実装に進む
複数の設計ドキュメントを1つに統合
サブタスクに分割して段階的に実装

5. ディレクトリ構造の変更

Before（従来の構造）

ai_workflow/
├── contexts/           # プロジェクト知識（維持）
├── templates/          # ドキュメントテンプレート
│   ├── requirements_template.md
│   ├── technical_design_template.md
│   └── implementation_plan_template.md
├── prompt/             # 段階別プロンプト
│   ├── 01_to_requirements.md
│   ├── 02_to_technical_design.md
│   ├── 03_to_implementation_plan.md
│   ├── 04_to_code.md
│   └── 05_to_subtasks.md
└── tickets/            # チケット別ドキュメント
    └── TICKET-001/
        ├── requirements.md
        ├── technical_design.md
        └── implementation_plan.md

After（提案する構造）

ai_workflow/
├── contexts/           # プロジェクト知識（維持・強化）
│   ├── ARCHITECTURE.md
│   ├── DOMAIN_KNOWLEDGE.md
│   ├── CODING_STANDARDS.md
│   └── API_CONVENTIONS.md
├── prompt/             # サイズ別プロンプト
│   ├── task_small.md       # Sサイズ用
│   ├── task_medium.md      # Mサイズ用
│   ├── task_large.md       # Lサイズ用
│   ├── sizing_guide.md     # サイズ判定ガイド
│   └── git/                # Git操作用（維持）
└── tickets/            # チケット別ドキュメント
    └── TICKET-001/
        └── design.md       # M,Lサイズのみ作成

変更のポイント

項目	Before	After
プロンプト数	5個（段階別）	3個（サイズ別）
テンプレート	3種類	不要（プロンプト内に定義）
チケット別ドキュメント	3ファイル	0〜1ファイル
contexts	維持	維持・強化

削減されるもの:

段階別プロンプト（5個 → 統合）
ドキュメントテンプレート（3個 → 削除）
チケット別の複数ドキュメント（設計メモ1つに統合）

強化するもの:

プロジェクト共通の知識ベース（contexts）
サイズ判定のガイドライン

6. ドキュメントを減らす代わりに、何を残すか

「ドキュメントを減らして大丈夫なの？」という不安はもっともです。

私の提案は、プロジェクト共通の知識ベースとテストで代替する、というものです。

プロジェクト共通の知識ベース（contexts）

タスクごとに設計書を書く代わりに、プロジェクト全体で共有すべき知識を整理しておきます。

contexts/
├── ARCHITECTURE.md      # システム構成、レイヤー構造
├── DOMAIN_KNOWLEDGE.md  # 業務用語、業務ルール
├── CODING_STANDARDS.md  # コーディング規約
└── API_CONVENTIONS.md   # API設計の規約

AIはこれらを参照して実装するので、一貫性のあるコードが生成されます。しかも、contextsを更新すれば以降のすべてのタスクに反映されますから、知識が陳腐化しにくいです。

テストで仕様を表現

細かい仕様はドキュメントではなくテストで表現します。

test("ロックされたデータは編集できない", () => {
  const data = createLockedData();
  expect(() => data.edit()).toThrow("編集できません");
});

これなら仕様がコードとして残りますし、仕様変更があればテストが落ちて気づけます。ドキュメントより信頼性が高いです。

7. 品質をどう担保するか

ドキュメントを減らすと品質が下がるんじゃないか。そう心配する声もあるでしょう。

以下の方法で品質を担保しています。

1. PRレビューを重視する

設計レビューを省略する代わりに、PRレビューの質を上げます。コードだけでなく、設計の妥当性もPRレビューで確認します。設計メモがあればそれも見ます。

2. コードコメントで意図を残す

なぜその設計にしたのか、コードコメントで説明します。後からコードを見た人が意図を理解できるようにします。

3. 判断に迷ったら人間に聞く

AIには「判断に迷う場合は実装前に質問して」と指示しておきます。重要な設計判断を勝手に決めさせません。

8. 期待される効果

効率化の効果

指標	従来	アジャイルAI駆動
Sサイズの所要時間	4〜8時間	30分〜1時間
Mサイズの所要時間	2〜3日	1〜2日
レビュー待ち回数	4〜5回	1〜2回
ドキュメント作成工数	大	小〜中

特にSサイズのタスクでは、所要時間が1/8〜1/4に短縮されます。これは、小さなタスクが多いプロジェクトほど大きな効果を発揮します。

フィードバック速度の改善

[従来]
要求 → 要件書(1日) → レビュー(0.5日) → 設計書(1日) → レビュー(0.5日)
→ 実装計画(0.5日) → レビュー(0.5日) → 実装(1日) → レビュー(0.5日)
= 約5.5日

[Sサイズ]
要求 → 実装(0.5時間) → レビュー(0.5日)
= 約0.5〜1日

フィードバックが速くなることで、軌道修正も早期に行えます。

品質の維持

ドキュメントを減らしても、以下により品質は維持されます。

contextsの活用: プロジェクト共通知識により一貫性を確保
テストによる仕様表現: 仕様がコードとして残り、変更検知が可能
PRレビューの重視: 設計妥当性もコードレビューで確認

柔軟性の向上

タスク規模に応じた適切なプロセス選択により、以下が実現します。

小さいタスクは高速に回転
大きいタスクは従来通り慎重に設計
状況に応じてサイズを変更可能（実装中に規模が判明した場合など）

9. 導入のステップ

いきなり全面的に切り替えるのはリスクが高いです。まずは小さく始めましょう。

Step 1: Sサイズから試す

既存の小さなタスクで新しいプロセスを試します。従来のプロセスと所要時間・品質を比較して、効果を確認します。

Step 2: 知識ベースを整備する

設計書を省略するには、プロジェクト共通の知識が整備されている必要があります。既存のドキュメントから共通化できる情報を抽出して、contextsとして整理します。

Step 3: 徐々に適用範囲を広げる

Sサイズで成功したら、Mサイズにも適用してみます。Lサイズは最後です。急がず、段階的に進めましょう。

まとめ

AI駆動開発は、たしかに開発を効率化する可能性を秘めています。でも、AIを導入するだけでは不十分です。プロセス自体をAIの特性に合わせて再設計する必要があります。

従来の仕様駆動開発の問題点を整理すると、こうなります。

ウォーターフォール型で、フィードバックが遅い
全タスクに同じ重いプロセスを適用してしまう
AIの強み（設計と実装の統合）を活かせていない

私の提案は、シンプルです。

タスクサイズで分ける: 小さいタスクはシンプルに、大きいタスクはしっかりと
設計と実装を同時に: AIの特性を活かして中間成果物を減らす
ドキュメントより知識ベースとテスト: 共通知識の整備と、テストによる仕様表現

これで、小さなタスクの所要時間は劇的に短くなります。レビュー回数も減ります。フィードバックが速くなります。

もちろん、このアプローチが万能というわけではありません。チームの状況やプロジェクトの特性によって、最適解は変わるでしょう。大事なのは、「従来のプロセスをそのままAIに適用する」という思考停止から抜け出すことです。

AIは道具です。道具は使い方次第で価値が決まります。AIの特性を理解し、それに合わせたプロセスを設計する。そうすることで、AI駆動開発は本当の意味で「爆速」になれるのだと思います。