AI駆動開発のやり方｜工程と承認ゲートの設計

AI駆動開発のやり方を調べると、たいていはツールの選び方に行き着きます。ただ、実際に手が止まるのは、どこで人が承認し、何をもって完了とするかが決まっていないときでした。この記事では、工程の分け方・承認ゲートの置き方・完了条件の決め方の3つを順に整理します。手法の全体像から確認したい場合はAI駆動開発をご覧ください。

AI駆動開発のやり方は工程の設計から決まる

AIに任せる範囲を広げると、成果物が出てくる速度は上がります。上がった分だけ、人の確認が追いつかない場所に問題が溜まります。Google CloudのDORA 2025年レポートは、自動テストやバージョン管理、速いフィードバックループが整っていないチームでは、変更量の増加がそのまま不安定さにつながると報告しました。同レポートでは回答者の90%が業務でAIを使い、80%以上が生産性の向上を実感している一方、30%は生成されたコードをほとんど信頼していないとも答えています。

この落差は、ツールを替えても縮みません。埋めるのは工程の設計で、最初に決めるのは次の3点です。

• 工程をどう分けるか（何を作り終えたら次へ進むか）
• 承認ゲートをどこに置くか（誰が何の観点で見るか）
• 完了の基準は何か（着手できる状態と、終わったとみなす状態）

この3つが決まっていれば、使うエージェントが変わっても進め方は変わりません。逆にここが空白のままだと、生成が速くなった分がそのまま手戻りの量になります。

工程はどこまで分けるか

AIが設計書からテストコードまで一続きで出すようになると、従来は自然に分かれていた工程の輪郭が溶けます。溶けて困るのは、省略されても誰も気づかない工程です。名前を付けて独立させておくと、飛ばしたことが見えるようになります。

分ける粒度は案件の規模で変わります。gaipackは実行フェーズを8つに細分化して運用しており、内訳はAIDDスキームのご紹介にまとめています。設計を先に固めてから実装へ進む考え方そのものは仕様駆動開発で扱っています。

AI駆動開発のやり方を支える承認ゲートの置き方

工程を分けただけでは手戻りは減りません。分けた境目に、人が承認する地点を置きます。置く場所によって、指摘が出たときに巻き戻る範囲が変わるためです。

置き場所を決めたら観点を割り当てます。同じ成果物でも、見る人が変われば出てくる指摘が変わります。

つまずくのはスケジュールのほうです。レビューを予定の隙間に入れると、指摘が出たときに直す時間が残りません。各ゲートに最低1週間のバッファを先に確保しておくと、生成の速さがレビュー待ちの行列に化けるのを防げます。gaipackが標準にしている6段階の割り当ては、同じくAIDDスキームのスライドで公開しています。

完了の基準を工程ごとに決める

終わったの定義が人によって違うと、レビューのたびに前提のすり合わせから始まります。着手できる状態（DoR）と、終わったとみなす状態（DoD）を工程ごとに書いておきます。

見積もりができないときは、見積もりを急がずに不足している情報を特定します。ここを飛ばすと、着手後に前提が変わって作り直しになりやすいためです。受け入れ基準はGiven / When / Then（Gherkin形式）で書いておくと、実装の指示とテスト項目の両方にそのまま使えます。書き方はPRDと受け入れ基準をGherkinで書くで具体的に扱っています。

反復のリズムに載せる

工程・ゲート・完了条件が決まったら、繰り返しの単位に載せます。2週間スプリントなら、前半に不明点の解消と実装、中盤に中間レビュー、末日に最終レビューと振り返りを置く並びが回しやすい形です。

差し込みの扱いも先に決めます。原則は次スプリント対応、重大な不具合だけ責任者の判断で即時に入れる、という線を引いておくと、スプリントの途中でゲートの位置がずれません。要件定義の標準化で手戻りを減らした例は要件定義を標準化し開発の手戻りを約 66% 削減で紹介しています。

AI駆動開発のやり方でつまずく3つのポイント

工程を決めた後に起きやすいのは、次の3つです。どれも実装ではなく順番の問題として現れます。

つまずき1：インプットを整えないまま着手する

出力の品質はインプットの品質で決まります。資料が散らばったまま着手すると、生成物を人が読み直す時間のほうが増えます。整理度合いが低い案件では前整理を挟み、そのうえで適用範囲を判断します。AIへ何を読ませるかの設計はコンテキストエンジニアリングで扱っています。

つまずき2：レビューを最後にまとめる

Stack Overflowの2025年開発者調査では、開発者が挙げた最大の不満が「ほとんど正しいが少しだけ違うAIの出力」への対処で66%、次いで「AIが生成したコードのデバッグに時間がかかる」が45%でした。惜しい出力ほど発見が遅れるため、小さく承認して次へ進むほうが結果として速くなります。

つまずき3：AIの実行範囲を決めないまま任せる

どこまで自動で実行させるかを決めずにエージェントを動かすと、意図しない変更が混ざります。権限の線引きはコーディングエージェントの権限設計で具体的に扱っています。

AI駆動開発のやり方に関するよくある質問

進め方でよく聞かれる点をまとめます。

AI駆動開発のやり方はアジャイル開発と両立しますか

両立します。スプリントの枠組みはそのままに、承認ゲートの位置と完了条件を明示する形になります。スクラムのイベントを置き換える必要はありません。

小規模なプロジェクトでも工程をすべて分ける必要がありますか

規模によって省ける工程はあります。ただし省く判断は、案件の特性を確認したうえで意識的に行います。名前を付けずに自然と抜け落ちるのと、理由を決めて省くのは別のことです。

AI駆動開発のやり方はどこから始めるとよいですか

1機能やPoC規模から始め、効果を測ってから範囲を広げます。要件定義の工程から整えたい場合はAIDD 要件定義が入口になります。

工程を決めても効果が出ないときは何を見ればよいですか

先にインプットの整理度合いを確認し、次に承認ゲートの位置を確認します。この2つが揃っていない状態では、ツールを入れ替えても結果は変わりにくいためです。

まとめ

AI駆動開発のやり方は、次の3つの設計に整理できます。

• 工程を分けて名前を付け、省略されやすいインプット整理と設計レビューを飛ばせなくする
• 承認ゲートを工程の境目に置き、それぞれに観点と1週間のバッファを割り当てる
• 着手条件と完了条件を工程ごとに決め、終わったの定義を揃える

どの工程から手を付けるかは、いまの開発プロセスと資料の整い方によって変わります。自社の進め方に合わせた設計について、お気軽にご相談ください。