AI駆動開発の一つの解
― 20人月→2人月にした、探索と実装を分離する開発フレームワーク

はじめに ― 10倍の生産性は、方法論の切り替えから生まれた

見積もり段階で20人月規模と算出されたシステムがありました。従来なら、まず要件定義に2〜3ヶ月、設計に1〜2ヶ月、そこから開発チームを組んで……というスケジュールが普通です。

ところが、このプロジェクトでは1人のエンジニアがAI駆動の開発ツールを使い、2ヶ月弱でリリースまで完了しました。結果として10倍以上の生産性向上です。

ただ、誤解のないように言えば、これは「AIがすごいから速かった」という単純な話ではありません。速さの本質は、開発プロセスそのものを組み替えたことにありました。

最初から要件を固めにいかなかった。抽象的な要望をもとにプロトタイプを作り、早期にユーザーに触ってもらい、フィードバックを受けて改善する。このサイクルをベロシティを落とさずに回し続け、仕様は「最初に決めるもの」ではなく「徐々に発見するもの」として扱いました。

この経験を通じて確信したのが、「探索」と「実装」では、そもそも必要なプラクティスが違うということです。

AI駆動の開発方法論はまだ発展途上であり、業界全体で試行錯誤が続いています。本記事では、この経験も踏まえた一つの考え方として、プロジェクトの「探索期」と「実装期」を分離し、各フェーズに最適なプラクティスを適用するハイブリッドフレームワークを提示します。唯一の正解ではなく、読者の現場での議論のたたき台になれば幸いです。

1. 開発プロジェクトの「2つのフェーズ」

あらゆる開発プロジェクトは、程度の差こそあれ、2つの異質なフェーズを含んでいます。

探索フェーズ：何を作るべきかが未確定な段階です。ユーザー自身が何を欲しいか言語化できず、ToBeモデル（目指すべき姿）もまだ仮説にすぎません。PMIの調査でも「多くの場合、クライアントはプロジェクトの初期段階で自分が何を必要としているか分かっていない。動くものを見て、試して、初めて要件の理解が深まる」とされています。

実装フェーズ：何を作るかは決まった。ここからは品質、セキュリティ、保守性を担保しながら作り込む段階です。Claude Codeのベストプラクティスでは「実装前に計画を立てることは交渉の余地がない」とされ、Google ChromeのAddy Osmani氏も「コーディング前の設計、テスト、標準の維持は、AIがコードの半分を書く時代にはむしろ一層重要になる」と述べています。

従来の開発方法論の構造的な課題は、この2つを同じフレームワークで扱おうとしてきたことにあるのではないか。これが筆者の実務経験から得た仮説です。

2. 各手法は「探索」と「実装」をどう扱ってきたか

ウォーターフォール ― 探索を「計画」に閉じ込めた

プロジェクト全体の20〜40%の時間が要件定義と設計に投入され、ユーザーが触れるものはテストフェーズまで存在しません。Barry Boehmの研究（1981年）では、初期に発見できた問題が後工程で発覚すると、修正コストは50〜200倍に膨らむとされています。「作ってみないと分からない」という問題への回答がないまま要件を確定させる構造です。

アジャイル/スクラム ― 探索と実装を混ぜたが、調整コストが重い

「動くソフトウェアで学ぶ」という思想は正しかった。しかしスクラムの運用に落とすと、別の問題が見えてきます。

2週間スプリントの時間配分を目安として積み上げると（チーム規模やスプリント長によって幅がありますが）：セレモニーに10〜12%、バックログリファインメントに5〜10%、技術的負債に15〜30%、コンテキストスイッチに10〜15%。新しい価値を生む実装に使える時間はスプリント全体の33〜50%程度という試算になります（Scrum Guide推奨値、Scrum.org Stefan Wolpers氏、Calculator Academy等に基づく）。

これはスクラムの設計ミスではありません。実装コストが高い時代には「4時間プランニングで議論して手戻りを減らす」のは合理的でした。しかし、AIで実装コストが下がった今、4時間の議論より複数プロトタイプを30分で作って見せた方が速い場面が増えています。

最近では構想・画面設計を先に行い、全体像を固めてからアジャイル開発に入るアプローチも一般的です。合理的な発想ですが、構想フェーズの成果物（画面モックアップや業務フロー図）はあくまで「静的」なもので、ユーザーが実際に触って検証できるわけではありません。さらに構想と開発が直列に並ぶため全体のリードタイムも長くなりがちです。AIで実装コストが劇的に下がった今、動くプロトタイプを先に作った方がスピード・コスト両面で改善される場面が増えています。

Spec-Driven Development ― 実装には強いが、探索の前提がない

「仕様が真実の源」という主張には正当性があります。曖昧なプロンプトより明確な仕様を渡した方が、AIはより良いコードを生成します。CLAUDE.mdのようなContext Engineeringも同じ方向性です。

ただし根本的な問い：その「良い仕様」をどうやって手に入れるのか。 仕様を書けるということは、何を作るべきかがすでに分かっているということ。探索フェーズへの回答がない。

Vibe Coding ― 探索は速いが、品質の仕組みがない

アイデアを数時間でプロトタイプにできる探索のスピードは圧倒的。しかし「Vibe Codingの二日酔い」（Fast Company, 2025年9月）が示す通り、品質・セキュリティ・保守性の担保がない。VeraCodeの調査（2025年）でも、LLM生成コードの機能は向上しているがセキュリティの改善は限定的と報告されています。

現場の実感として「動くものは速くできるけど、本番に持っていけない」というのは、まさにこの問題です。

3. 5つの手法を「探索 × 実装」で比較する

この表から見えるのは、どの手法にも「得意なフェーズ」と「苦手なフェーズ」があるということです。ハイブリッドの発想は、各手法の強みを組み合わせることにあります。

4. ハイブリッドフレームワークの一案 ― Discover-Build-Crystallize + Spec-Driven

4-1. 全体構造

ここでは、筆者が実務を通じて試行してきたアプローチを整理して提示します。あくまで一つのモデルであり、現場の状況に応じたカスタマイズが前提です。

探索期は「何を作るべきか」を発見し、実装期は「発見されたもの」を高品質に作り込む。Crystallize（結晶化）がその切替点です。

4-2. 探索期：Discover-Build-Crystallize

Discover（発見）― 数時間

ユーザーの曖昧な要望やコンサルのToBe仮説を起点に、AIでプロトタイプを素早く生成します。ここでの本質は、議論や文書ではなく動くもので仮説を検証すること。実装コストが下がった今、見積もりをつける時間でプロトタイプが作れてしまう。であれば、まず作って触ってもらった方が速い。場合によっては複数案を同時に作って比較することもできます。

Build & Test（構築と即時検証）― 数時間〜数日

ユーザーの反応をもとに即座に修正・再構築。フィードバックサイクルが「2週間」から「数時間」に圧縮されます。

DXプロジェクトでは、ここでコンサルのToBeモデルと現場の現実のギャップが即座に露呈します。仕様書では「正しい」業務フローが、動かすと「現場では使えない」と分かる。逆に、仕様書には載っていなかった現場の工夫がフィードバックとして顕在化する。プロトタイプがコンサルと現場の共通言語になるわけです。

ただし、探索期であってもTDD的なテスト生成は並行で走らせておくのが望ましいでしょう。品質の「レール」は最初から敷いておくに越したことはありません。

Crystallize（結晶化）― 数日

「これが正しい」という合意が形成されたら、発見された正解を保守可能な形に定着させます。

• 仕様ドキュメント：プロトタイプから抽出された機能仕様・業務フロー
• テストスイート：探索期に生成されたテストの整理と拡充
• AIコンテキスト：CLAUDE.mdやプロジェクト規約の構造化
• セキュリティ要件：探索期に特定されたリスクの明文化

このCrystallizeこそが、Vibe Codingの速さとSpec-Drivenの構造を橋渡しするポイントです。「動くプロトタイプはあるけど、これをどうやって本番品質にするの？」という現場の問いに対する回答が、ここにあります。

4-3. 実装期：業界のベストプラクティスをフル適用

Crystallizeで生成された仕様を入力として、ここからはSpec-Driven + Context Engineering + TDDのアプローチが有効だと考えます。具体的には以下のようなプラクティスが活用できます。

• Osmani氏の「15分のウォーターフォール」——迅速だが構造化された計画手法
• CLAUDE.mdによるContext Engineeringで、AIに適切な文脈を与える
• PEV（Plan → Execute → Verify）ループによる段階的な実装

GitHub Spec KitやAWS Kiro、JetBrains Junieといったツールも、仕様が結晶化された状態でこそ真価を発揮します。

実装期の進め方自体は、現在の業界ベストプラクティスと変わりません。違うのは「その仕様がどこから来るか」だけです。最初から机上で書くのではなく、探索期のプロトタイプ検証を経て結晶化された仕様が入力になる。それがこのフレームワークの特徴です。

4-4. 実践から見えたこと ― 20人月のシステムを2ヶ月弱で

冒頭で触れた案件の話に戻ります。

このプロジェクトでは、従来の「まず要件を固める」というプロセスを取りませんでした。抽象的な要望を起点に、AI駆動の開発ツールでプロトタイプを作成し、早い段階からユーザーにトライアルしてもらいました。

フィードバックをもとに改善し、またトライアル。このサイクルをベロシティを落とさずに回し続けることで、仕様は「決めるもの」ではなく「発見するもの」になっていきました。結果的に、見積もり20人月規模のシステムを1人のエンジニアが2ヶ月弱でリリース。10倍以上の生産性向上です。

振り返ると、この案件がうまくいった理由は3つあると考えています。

第一に、静的な構想ではなく動くプロトタイプで検証したこと。 一般的に、開発前にシステム構想や画面設計を行い、全体像を固めてからアジャイル開発に入るアプローチがあります。合理的な考え方ですが、構想フェーズの成果物はどうしても静的です。画面モックを見て「いいですね」と言ったユーザーが、動くものを触ると「やっぱりここはこうしたい」となる。この案件では最初から動くものを作ったことで、そのギャップを初期に潰すことができました。

第二に、構想と開発を直列にせず、探索と実装を並行的に進めたこと。 構想フェーズに数ヶ月かけてから開発に入る従来のアプローチと比べ、動くプロトタイプが構想そのものを兼ねるため、プロセス全体のリードタイムが劇的に短くなりました。スピードだけでなく、コスト面での差も圧倒的です。

第三に、仕様を「結晶化」するプロセスがあったこと。 プロトタイプで検証された要件は、ある時点で仕様として定着させました。ここからは品質重視のSpec-Driven開発に切り替える。この「切替点」があったからこそ、速度と品質を両立できたと思っています。

もちろん、これは小規模プロジェクトだったからこそ成立した面もあるでしょう。しかし「探索と実装を分離し、フェーズに応じてプラクティスを切り替える」という考え方自体は、規模を問わず応用できるのではないかと考えています。

4-5. なぜCrystallizeが鍵なのか

仕様は「最初に書くもの」（Spec-Driven）でも「不要なもの」（Vibe Coding）でもありません。プロトタイプから発見された正解を結晶化した「成果物」です。

この位置づけにより、以下の可能性が見えてきます：

• Vibe Codingの弱点（品質・保守性の欠如）を補完し
• Spec-Drivenの弱点（「誰が仕様を書くのか」問題）に一つの回答を提供し
• アジャイルの弱点（探索と実装の混在による調整コスト）を分離できる可能性がある

5. DXプロジェクトへの実践的インパクト

コンサルの「机上の空論」に検証の手段が生まれる

従来：コンサルがToBeを描く → 要件定義書を渡す → 半年後にユーザーが触る → 「思ったのと違う」

ハイブリッド：コンサルがToBe仮説を描く → その場でプロトタイプ生成 → 現場ユーザーが触って検証 → 1〜2週間で合意形成 → 結晶化された仕様で本格実装

コンサルの論理的な正しさと現場の経験的な正しさが、プロトタイプという共通言語で即座に対話できる。要件定義フェーズ（3〜6ヶ月）がDiscover-Build-Crystallizeの1〜2サイクルに圧縮されます。ただし「圧縮」は「省略」ではありません。業務分析もステークホルダーの合意形成も、プロトタイプを介した対話という形で、より短期間かつ高精度に実施されます。

開発チームの「板挟み」に構造的な整理がつく

「早く作って」と言われるからVibe Coding的に進める → 品質問題が出る → 「ちゃんと設計して」と言われる → 設計に時間がかかる → 「早く作って」...

このループは、探索と実装を同じフレームワークで扱っている限り繰り返されがちです。ハイブリッドモデルでは「今は探索期だから速度重視、Crystallize後は品質重視」と明確に切り替えることで、チームの判断基準が整理しやすくなると考えています。

自社のプロジェクトに当てはめてみる

ここまで読んで「考え方は分かるが、自社でどう始めればいいのか」と感じた方もいるかもしれません。一つの出発点として、以下の問いをチーム内で議論してみてください。

• 今進めているプロジェクトは、探索期と実装期のどちらにあるか？ もし「要件が固まっていない」「ユーザーの本当のニーズがまだ見えない」なら、それは探索期です。探索期のプロジェクトに実装期のプラクティス（詳細設計、精度の高い見積もり等）を求めていないか、振り返ってみてください。
• ユーザーが動くものに触れるまで、どれくらいの時間がかかっているか？ もし数ヶ月かかっているなら、その間に発生する認識のズレは避けられません。プロトタイプで早期検証する余地がないか、検討してみてください。
• 「仕様」はどの段階で、誰が書いているか？ 仕様が最初に決められるものとして扱われているなら、それは暗黙にウォーターフォールの前提に立っています。仕様を「探索の成果物」として位置づけ直すだけでも、プロジェクトの進め方は変わります。

探索期の「終わり」をどう判断するか

ハイブリッドモデルを試す上でよく出る問いが「探索期をいつ終わらせるか」です。明確な正解はありませんが、以下のシグナルが目安になります。

• ユーザーからのフィードバックが「新しい発見」から「細かい調整」に変わってきた
• ステークホルダー間で「この方向で進めよう」という合意が取れた
• プロトタイプが複数回のイテレーションを経て安定してきた

こうしたシグナルが揃ったら、Crystallizeに移行するタイミングです。具体的な成果物としては、プロトタイプの動作をベースにした機能仕様書、探索期に書いたテストを整理したテストケース一覧、CLAUDE.md等のAIコンテキストファイル、そして非機能要件やセキュリティのチェックリストなどが挙げられます。「何を作るか」ではなく「何が出来上がっていればCrystallize完了か」をチームで合意しておくと、切替の判断がしやすくなります。

6. 高速開発のためのガードレール

スピードが上がるほど、品質とセキュリティの「レール」は重要になります。

探索期のレール：TDD（プロトタイプと同時にテスト生成）、セキュリティスキャン自動化、Gitによる探索過程の追跡

実装期のレール：Spec-Drivenによる仕様への適合検証、CLAUDE.md等によるContext Engineering、CI/CDパイプラインでの自動テスト・静的解析

AnthropicはContext Engineeringを「プロンプトエンジニアリングの自然な進化形」と位置づけています。CLAUDE.mdのようなプロジェクトコンテキストの整備は、Crystallize後の実装期において、AIに適切な制約と文脈を与えるための基盤です。

ここで見落とされがちなのが、スピードが上がるほどセキュリティリスクも加速するという点です。AI駆動で開発速度が10倍になったとき、脆弱性の混入速度も10倍になりかねない。探索期に生成されたプロトタイプコードがそのまま本番に紛れ込むリスク、AIが生成するコードに含まれる既知の脆弱性パターン——これらに対処するには、開発プロセスの中にセキュリティのガードレールを組み込む必要があります。セキュリティは「開発が終わってから考えるもの」ではなく、探索期から実装期まで一貫して走るレールです。

必要なのはブレーキではなくガードレール。フェーズごとに異なるレールを敷くことで、スピードと品質を両立させます。

まとめ ― ベストプラクティスはこれから作られる

AI駆動の開発方法論は、まだ業界全体で試行錯誤が続いているフェーズにあります。Spec-Driven DevelopmentやContext Engineeringなど様々なアプローチが提唱され、現場で検証が進んでいる段階です。本記事で提示したハイブリッドフレームワークも、その議論の中の一つの案に過ぎません。

ただ、一つ確信を持って言えることがあります。「探索」と「実装」では求められるプラクティスが異なる。この認識は、どの方法論を採用するにしても有効ではないでしょうか。

ウォーターフォールの計画の規律、アジャイルの学習サイクル、Spec-Drivenの品質、Vibe Codingの探索速度。それぞれの強みは、適用する文脈が正しければ今も有効です。問うべきは「どの方法論が正しいか」ではなく、「今、このプロジェクトは探索期か実装期か」。

この問いを立てるだけでも、チームの判断基準は少し明確になるかもしれません。そして、その問いに対する答え方のベストプラクティスは、これから私たち実務家の現場で作られていくものだと思います。

もちろん、すべてのプロジェクトにこのフレームワークが万能に適用できるわけではありません。規制産業のコンプライアンス要件や大規模基幹システムのアーキテクチャ設計では、従来の計画的アプローチが適切な場面もあるでしょう。しかし「ToBeが正しいのか分からない」「要件が固まらない」という課題を抱えるプロジェクトにとって、探索と実装の分離は試してみる価値のある考え方ではないでしょうか。

皆さんの現場ではどうでしょうか。この記事が、チーム内での議論のきっかけになれば嬉しく思います。

参考文献

よくある質問（FAQ）