「AI 駆動開発をやってみたいが、結局どういう順番で何をやればいいのか」という問いは、ツール選定よりも先に多くのチームが詰まるところです。Claude Code や Cursor の使い方を調べると個別の Tips は山ほど出てきますが、要件定義から運用まで一本の流れとしてどう繋がるのか、誰が何を担うのか、各工程で何が成果物として残るのか、という全体像が見えにくい。本記事はその全体像を、7 つの工程・チーム体制・成果物の 3 つの軸で一望できるように整理します。

先に結論を述べると、AI 駆動開発の進め方は「工程の並びそのもの」ではなく「各工程の重心」が従来開発と変わります。何を作るかを言語化する上流と、AI の出力を検証するレビューに人間の時間を寄せ、コードを書く工程は AI が大きく巻き取る。この重心移動を踏まえて工程を設計できているかどうかが、速度と品質を両立できるかの分かれ目です。AI 駆動開発そのものの定義や従来開発との違いは AI 駆動開発とは？従来開発との違い・進め方 で扱っているので、本記事は「具体的にどう進めるか」に焦点を絞ります。

AI 駆動開発の全体フロー(7 工程)

まず全体像です。AI 駆動開発の工程は、大きく次の 7 つに分けて捉えると流れが掴みやすくなります。

工程主な作業主担当成果物
1. 要件定義課題・対象ユーザー・スコープの確定プロダクト責任者要件メモ・ユーザーストーリー
2. 仕様策定受け入れ条件の言語化、ルール整備仕様担当・テックリード仕様 (spec)・CLAUDE.md
3. テスト設計受け入れ条件をテストへ翻訳エンジニア + AI失敗するテスト
4. 実装テストを Green にするコード生成AI + エンジニア実装コード・Pull Request
5. レビューAI 一次レビュー・人間最終レビューAI + レビュアーレビュー記録・修正コミット
6. リリースマージ・デプロイ・段階公開エンジニア・運用リリースノート・本番反映
7. 運用監視ログ・指標の観測、改善の起票運用・全員監視ダッシュボード・改善 Issue

工程の名前だけ見ると従来の開発と変わりません。違いは中身です。従来は実装(4)に人間の時間が集中していましたが、AI 駆動開発では実装を AI が大きく巻き取る代わりに、仕様策定(2)・テスト設計(3)・レビュー(5)へ人間の時間が移ります。コードを速く書けるようになった分、何を作るかを決める時間と、出てきたものを確かめる時間の比重が相対的に上がる、という構造を頭に入れておくと、以降の各工程の力点が理解しやすくなります。

この 7 工程は一方通行ではなく、運用(7)で得た知見が要件(1)や仕様(2)に戻る循環で回します。一度作った仕様やルールファイルは資産として蓄積され、二巡目以降の速度に効いてきます。fixit が実プロジェクトで標準にしている開発プロセスの詳細は 開発プロセス にまとめています。

以下、各工程を順に掘り下げます。

要件定義・仕様策定の進め方

AI 駆動開発で最も多い手戻りは、コードのバグではなく「そもそも作るものが違った」という上流のずれです。AI は指示された範囲を高速に形にしますが、指示が曖昧なら曖昧なまま、それらしい実装を作り上げてしまう。だからこそ、人間がコードを書いていた時代以上に「何を作るか」を先に言語化しておく価値が跳ね上がります。

要件定義では「解く課題」を先に固める

要件定義の工程では、機能の一覧を並べる前に、誰のどんな課題を解くのかを一文で言えるところまで絞り込みます。ここが曖昧だと、後続のすべての工程に曖昧さが伝播します。具体的には、対象ユーザー、解決したい課題、今回のスコープに入れること・入れないことを、要件メモとユーザーストーリーの形で残します。AI に壁打ち相手として要件を整理させるのは有効ですが、最終的に何を作るかを決めるのは人間の責任である点は崩しません。

仕様策定では受け入れ条件まで言語化する

仕様策定では、要件を「受け入れ条件」のレベルまで具体化します。ここでいう仕様 (spec) は、後で読む資料ではなく、実装とテストを駆動する一次情報として扱います。「ログイン機能」とだけ書くのではなく、入力が不正なときにどう振る舞うか、上限を超えたらどうなるか、といった条件を箇条で固めておく。この受け入れ条件が次の工程でそのままテストになります。

仕様を AI と人間の双方が参照する一次情報にする設計の進め方は 仕様駆動開発を AI で実践する で詳述しています。あわせて、コーディング規約・使ってよいライブラリ・レビュー基準といったプロジェクトのルールを CLAUDE.md などのルールファイルに書き、リポジトリに置きます。仕様とルールをファイルとして残し、口頭やチャットの会話に閉じ込めないことが、この後の工程で AI を機能させる前提になります。

テスト先行と AI による実装

仕様で受け入れ条件が固まったら、実装より先にテストを用意します。AI 駆動開発でテストを先に書くのは、TDD の作法を踏襲しているからというより、AI に対する「動く受け入れ条件」を先に手渡すためです。

テストを先に書く理由

テストを先に用意すると、AI が実装を生成したときに、その実装が仕様を満たしているかを機械的に判定できます。テストがない状態で AI に実装を任せると、それらしく動くが受け入れ条件を満たさないコードが生まれても気づけません。先に失敗するテスト (Red) を置き、それを Green にする実装を AI に書かせることで、仕様・テスト・実装の三者を最初から噛み合わせられます。テスト自体の生成も AI が得意とする領域なので、受け入れ条件を渡して下書きを作らせ、人間が抜け漏れを補うやり方が実務的です。

テストを先に書かせるループの具体的な回し方は AI 駆動 TDD — テストを AI に先に書かせる開発フロー で詳しく扱っています。

実装は小さな単位で AI に委ねる

実装工程では、一度に大きな範囲を任せず、機能や受け入れ条件の単位で小さく切って AI に依頼します。「この仕様の受け入れ条件をすべて満たす実装を書き、用意したテストを通す」と指示し、どのテストが通ったかを確認しながら進める。範囲が大きいほど AI の出力はぶれやすく、レビューも難しくなるため、Pull Request が小さく保たれる粒度に分割するのが品質と速度の両面で効きます。実装が一巡したら、生成されたコードが既存の規約に沿っているか、仕様にない挙動が紛れ込んでいないかを次のレビュー工程で確かめます。

AI コードレビューと品質ゲート

AI が実装量を増やすほど、開発の律速はコードを書く速さではなくレビューの速さに移ります。ここを設計せずに AI へ任せる範囲だけ広げると、レビューが追いつかず品質が崩れるか、レビューがボトルネックになって速度が出ないかのどちらかに陥ります。AI 駆動開発では、レビューを二段の品質ゲートとして組み立てます。

一段目|機械と AI による自動チェック

一段目は人間の目に入る前の自動チェックです。CI で、用意したテストが全て通ること、リンタや型チェックが通ること、仕様由来のテストがマージ条件として満たされていることを機械的に確認します。さらに AI による一次レビューを挟み、規約違反・明らかなバグ・仕様との食い違いといった定型的な指摘を先に拾わせる。ここで定型的な指摘を片付けておくと、人間のレビュアーは本質的な判断に集中できます。

二段目|人間による最終レビュー

二段目は人間による最終レビューです。AI の一次レビューが拾えるのは定型的な観点が中心で、「この設計でドメインの要求を本当に満たすのか」「将来の変更に耐えるか」といった文脈に依存する判断は人間が担います。レビューでは、実装が仕様のどの受け入れ条件に対応するのかを確認し、仕様にない挙動が混入していないかを見る。マージしてよいかの最終判断と、その責任は人間が持つ前提を崩さないことが、AI に任せる範囲を広げても品質を保つ要になります。

AI を前提にしたレビュー体制とゲートの組み方は AI コードレビューの設計 で具体的に整理しています。

リリースと運用監視

レビューを通った変更は、リリース工程でマージ・デプロイし、本番に反映します。AI 駆動開発だからといってリリースの作法が特別に変わるわけではありませんが、変更の流量が増えやすい分、小さく出して素早く戻せる体制の価値が上がります。

具体的には、Pull Request を小さく保ち、マージ後は自動でデプロイされる導線を整え、利用者への影響が大きい変更では段階公開や機能フラグで影響範囲を絞る。問題が起きたときに即座に切り戻せるようにしておくことで、変更の流量が増えても安全に回せます。リリースノートには、何の受け入れ条件を満たす変更なのかを残し、後から追跡できるようにします。

運用監視の工程では、ログやエラー、応答時間、利用状況といった指標を観測し、想定どおり動いているかを確かめます。ここで得た気づきは改善 Issue として起票し、要件・仕様の工程へ戻す。AI 駆動開発の 7 工程は一方通行ではなく、運用で得た一次情報が次の開発を駆動する循環で回す、という点をここで改めて押さえておきます。蓄積した仕様・ルール・テストは資産として残り、二巡目以降の立ち上がりを速くしてくれます。

チーム体制と役割分担

「AI 駆動開発には専用の大きな組織が必要なのでは」と身構える必要はありません。既存のチームに役割を足す形で始められます。鍵になるのは次の 3 つの役割です。

ひとつめは、要件と仕様、受け入れ条件を言語化する役割です。何を作るかを決め、それを AI と人間の双方が読める一次情報に落とす、上流の要となる役回りです。ふたつめは、AI の出力をレビューしてマージ可否を判断する役割です。AI が実装量を増やすほどレビューが律速になるため、レビューできる人を確保できているかが体制設計の中心になります。みっつめは、CLAUDE.md などのルールファイルや CI、デプロイ導線といった土台を整備する役割です。この土台が AI の出力品質を底上げします。

少人数のチームなら一人が複数の役割を兼ねても回りますが、AI に任せる範囲が広がるほどレビューの負荷が増える点は意識しておく必要があります。役割を分けるときに最も避けたいのは「AI が書いたから誰もちゃんと見ていない」状態です。最終的な品質と意思決定の責任は人間が持つ、という線をどの体制でも引いておくことが、AI 駆動開発を安全に回す前提になります。

少人数でも安全に回せる仕組みとして、ルールファイルの整備と二段の品質ゲートが効くのは、ここまで見てきたとおりです。

従来開発とのスケジュール比較

最後に、工程ごとの時間配分が従来開発とどう変わるかを整理します。下表は典型的な傾向を示したもので、実際の比率は案件やフェーズによって変わりますが、重心の移り方を掴む目安になります。

工程従来開発の時間配分AI 駆動開発の時間配分変化の理由
要件定義・仕様策定中大何を作るかを先に厳密に言語化する
テスト設計小中受け入れ条件をテストへ翻訳する比重が上がる
実装大小コード生成を AI が大きく巻き取る
レビュー中大出力検証が律速になり人間の時間が集中する
リリース・運用中中作法は大きく変わらないが流量が増える

ポイントは、速くなるのは実装(コードを書く時間)であって、上流とレビューはむしろ手厚くなることです。「AI で全工程が一律に速くなる」という期待で上流とレビューを削ると、手戻りで結局遅くなります。逆に言えば、上流とレビューに人間の時間を寄せ、実装を AI に委ねる工程設計ができていれば、全体としての速度と品質を両立できます。これが冒頭で述べた「工程の並びではなく重心が変わる」の中身です。この重心移動の効果を数字で確かめる KPI の設計は AI 駆動開発の生産性をどう計測するか — KPI 設計の実務 で具体的に整理しています。

二巡目以降は、蓄積した仕様・ルール・テストが効いて立ち上がりが速くなるため、初回の上流投資は回数を重ねるほど回収されていきます。最初の一巡を丁寧に設計しておくことが、その後の速度につながります。

まとめ

AI 駆動開発の進め方は、要件定義・仕様策定・テスト設計・実装・レビュー・リリース・運用監視という 7 工程で捉えられます。工程の並びは従来開発と大きく変わりませんが、何を作るかを言語化する上流と、AI の出力を検証するレビューに人間の時間を寄せ、コードを書く実装は AI が大きく巻き取る、という重心の移動が本質です。テストを実装より先に用意し、AI の一次レビューと人間の最終レビューで二段の品質ゲートを置くことで、速度と品質を両立できます。体制は既存チームに役割を足す形で始められ、最初の一巡で蓄積した仕様・ルール・テストが二巡目以降の速度に効いてきます。

AI 駆動開発の進め方を自社のプロダクトにどう落とし込むか、工程設計や体制づくりからご相談いただけます。AI 駆動開発のクリエイティブスタジオである fixit が、要件定義から運用まで伴走します。まずは 無料相談 からお気軽にお問い合わせください。