2026.05.16

AI駆動開発のワークフロー全体像 ― 要件から運用までの新しい流れ

  • AI
  • プロジェクト推進
  • 開発組織
白い丸角のカードに、日本語の大きな見出し『AI駆動開発のワークフロー全体像 — 要件から運用までの新しい流れ』が中央に表示されたデザイン。背景は青の幾何学模様で、下部に IT COMPASS のロゴと“Powered by lanitech” の表記が見える。

AI駆動開発のワークフロー全体像 ― 要件から運用までの新しい流れ

「AIで開発が変わる」と言われ続けて数年。経営会議で「うちもAI駆動開発を本格化したい」と声が上がるものの、現場に降ろした瞬間に「結局どこから手をつければいいのか」という質問が返ってくる。CTOや開発リーダーに頻繁に相談されるのが、まさにこの 全体ワークフロー の話だ。AIをコード生成だけのツールとして使うか、要件定義から運用まで通した協働モデルとして組み込むかで、得られる成果はまったく違う。本稿では、AI駆動開発(AIDD)が従来開発とどう違うのかを、6つのフェーズに沿って整理する。経営層が次のIT投資を判断する材料として、また現場リーダーがチームに展開する設計図として活用してほしい。

要点:AIDDのワークフローは「直列・人間中心」から「並列・人間+AI協働」に変わる。各工程でのAIの位置づけ・主役・KPIを明確にすることが、定着とスケールの鍵。

1. 全体像 ― 6フェーズで人間とAIの主従が入れ替わる

AIDDのワークフローは、要件定義 → 仕様化 → 設計 → 実装 → 検証 → 運用 の6フェーズで整理できる。従来のSDLC(ソフトウェア開発ライフサイクル)と並びは同じだが、各フェーズで「誰が主役か」が大きく変わる。要件定義や設計判断のような 意思決定が重い工程 では人間が主役のまま、AIは補助に回る。一方、実装や検証のような 再現性・網羅性が問われる工程 では、AIが主役になり、人間はレビュアーに回る。この主従の入れ替わりを理解しないまま「全部AIに任せる」「全部人間がやる」と振れると、品質も生産性も中途半端になる。

フェーズ主役AI活用度中心KPI
  1. 要件定義
👤 人間補助仮説検証回数
  1. 仕様化
👤+🤖 協働仕様カバレッジ
  1. 設計
👤 人間レビュー指摘削減率
  1. 実装
🤖 AIリードタイム
  1. 検証
👤+🤖 協働中〜高自動テスト網羅率
  1. 運用
👤 人間デプロイ頻度・MTTR

💡 ポイント:6フェーズすべてに「主役」「AI活用度」「KPI」を割り当てたワンシートを作るだけで、現場と経営の議論が一気に揃う。最初の30分で作って配るだけで価値が出る。

2. フェーズ1:要件定義 ― 顧客対話は人間、整理はAI

要件定義は、顧客や市場の理解、ビジネス価値の特定、優先順位付けが中心だ。ここは人間が主役で、AIは整理補助に徹する。顧客との対話、ステークホルダーの利害調整、暗黙知の引き出しは、AIには代替できない。一方で、議事録のサマリ、ステークホルダー意見の構造化、競合・市場リサーチの一次情報整理、ユーザーストーリーのドラフト生成といった 構造化・要約・草案づくり は、AIに任せるべき領域だ。重要なのは、AI出力を「叩き台」と割り切る姿勢を組織で共有すること。叩き台を磨き込む過程こそが、要件の質を決める。

作業人間AI
顧客ヒアリング◎ 主役×
議事録作成△ 確認◎ 主役
競合リサーチ整理△ 判断◎ 主役
要件の優先順位付け◎ 主役△ 補助
ユーザーストーリー草案○ 修正◎ 主役

⚠️ 注意:顧客との対話を「AIで効率化」しようとする現場ほど、要件の浅いプロジェクトが量産される。対話の場は人間が主役で持ち続けることが、後工程の品質を決定づける。

3. フェーズ2:仕様化 ― 受け入れ条件をAIで網羅する

仕様化は、要件を実装可能な粒度に分解し、ユーザーストーリーや受け入れ条件に落とす工程だ。ここは人間とAIの協働が最も効果を発揮するフェーズで、AIで一気に加速できる。要件をユーザーストーリー形式に変換する、受け入れ条件を網羅的に書き出す、エッジケースを洗い出す、仕様書のフォーマットを統一する ― いずれもAIが得意な領域だ。一方、業務知識の補強や、業界固有の制約の織り込みは人間が担う。仕様書を Source of Truth(正本) として扱い、後工程の実装・検証・運用すべてが参照する位置に置くことで、AIDDのワークフローは初めて回り始める。

AI活用領域効果
ユーザーストーリー変換仕様作成時間が約60%削減
受け入れ条件の網羅生成カバレッジが大幅向上
エッジケース洗い出し後工程の手戻りが減少
フォーマット統一レビュー速度が向上
仕様書の更新追従ドリフトが減少

💡 ポイント:仕様書を「人間が書く」から「AIが書いて人間が承認する」に転換できると、仕様化の所要時間が劇的に減り、後工程の手戻りも下がる。

4. フェーズ3:設計 ― 選択肢はAIに、選ぶのは人間

設計フェーズでは、アーキテクチャ判断、技術選定、データ設計、API設計といった 将来の運用コストを決める意思決定 が中心になる。ここは人間が主役で、AIは壁打ち相手に徹する。AIは「選択肢を網羅的に出す」のは得意だが、「どれを選ぶか」は経験と組織文脈に依存するため、人間の判断が不可欠だ。設計の選択肢提示、既存パターンとの比較、ER図やシーケンス図のドラフト、セキュリティ観点のレビューは、AIに任せて加速する。一方、技術選定の最終判断や、長期運用を見据えたトレードオフの評価は、CTOや経験豊富なアーキテクトが担う。

設計判断推奨フロー
アーキテクチャ選定AIが3案提示 → 人間が選定
データモデル設計AIが正規化提案 → 人間が業務整合性を判断
API設計AIが標準パターン提示 → 人間がドメイン整合
セキュリティ設計AIがチェックリスト生成 → 人間が深堀り
パフォーマンス設計AIがボトルネック仮説 → 人間が実測判断

📊 経営判断のコツ:設計フェーズでAIに過度に依存すると、説明可能性が失われ、後の経営会議で「なぜこの構成か」を答えられなくなる。意思決定の根拠は人間が言語化できる状態を保つ。

5. フェーズ4:実装 ― AIが主役、人間はレビュアーに回る

実装は、AIDDで最も生産性インパクトが大きいフェーズだ。コード記述、ユニットテスト記述、ドキュメント生成のいずれもAIが主役になり、人間はレビューと統合判断に回る。仕様からコードを生成する、ボイラープレートを自動化する、テストケースを網羅的に生成する、ドキュメントを自動更新する、複数の独立タスクを並列処理する ― この5点で、従来比2〜5倍のスループットが現実的に出る。ただし、レビュー文化が整っていない組織でこのフェーズだけAIに振ると、品質が劣化するスピードも同じく加速する。レビューと自動テストの両輪を整える前に「AIで実装速度を上げる」と振ると、後工程の検証コストで全部相殺される。

自動化対象期待効果
ボイラープレート生成約70%削減
ユニットテスト記述網羅率向上+時間削減
ドキュメント生成同期コストが大幅減
並列タスク処理スループットが2〜5倍
リファクタ提案技術的負債の可視化

⚠️ 注意:レビュー体制が整っていない状態で実装フェーズだけAI化すると、品質劣化のスピードも同じく加速する。レビュー文化と自動テストを先に整える順序を厳守する。

6. フェーズ5:検証 ― AI生成テストを人間が最終承認する

検証フェーズは、ユニットテスト、統合テスト、E2Eテスト、コードレビューを通じて、生成されたコードの品質を担保する工程だ。ここも人間とAIの協働が必須で、AIで自動化を進めながら最終判断を人間が握る構造が望ましい。テストケース生成、E2Eシナリオ生成、コードレビューの一次チェック、パフォーマンステスト設計はAIが担い、リリース可否の最終判断やセキュリティクリティカルな部分の深堀りレビューは人間が担う。AIレビューは「補助線」と捉え、人間レビューを置き換えるものではないという前提を組織で共有しておく。

検証作業人間AI
ユニットテスト生成△ 確認◎ 主役
統合テスト設計○ 主役○ 補助
E2Eシナリオ生成△ 確認◎ 主役
コードレビュー一次△ 確認◎ 主役
リリース判断◎ 主役×

💡 ポイント:「AIレビュー → 人間レビュー → 自動テスト → 統合テスト」の4段構えにすると、各工程で違う観点が掛かり、抜け漏れが大幅に減る。

7. フェーズ6:運用 ― 障害対応は人間、ログ分析はAI

運用フェーズでは、デプロイ、モニタリング、障害対応、継続改善を行う。ここは人間が主役で、AIは監視・分析の補助に回る。ログ要約、異常検知の支援、障害原因の仮説生成、改善提案はAIが担い、障害発生時の最終判断や顧客対応は人間が担う。AIに障害対応そのものを任せると、誤った対応で被害を拡大させるリスクがあるため、運用フェーズではAIを「最初の一次切り分け」までに留めるのが現実解だ。MTTR(平均復旧時間)やデプロイ頻度などDORA指標を継続的にトラッキングし、改善サイクルを回す。

運用タスク人間AI
デプロイ実施◎ 主役△ 自動化補助
ログ要約△ 確認◎ 主役
異常検知○ 判断◎ 主役
障害原因仮説○ 判断◎ 主役
顧客対応◎ 主役×

⚠️ 注意:AIに障害対応の判断まで委ねると、誤った修正で被害を拡大させる事故が起きる。AIは「一次切り分け」までで止め、復旧アクションは人間が決定する。

8. ワークフロー全体のKPI設計 ― DORA指標を軸に

ワークフロー全体の改善は、体感ではなく数字で評価する。DORA(DevOps Research and Assessment)指標 ― デプロイ頻度・リードタイム・変更失敗率・MTTR ― を軸に、各フェーズのKPIを連動させる。経営会議では「AIDD導入後、デプロイ頻度が週1回 → 日次へ」「リードタイムが30日 → 7日へ」といった数字で進捗を語れるようにする。フェーズごとのKPIをダッシュボード化し、月次で経営会と現場が同じ画面を見て議論する状態を作ることが、定着の最終条件になる。

DORA指標改善前の目安改善後の目安
デプロイ頻度月数回日次〜週数回
リードタイム数週間数日
変更失敗率15〜30%5〜15%
MTTR数時間〜1日1時間以内

📊 経営判断のコツ:DORA指標は世界標準で他社比較ができるため、経営会議で「うちの開発組織の競争力」を客観的に語れる数少ない指標。AIDD投資の成果は必ずDORAで報告する。

9. ワークフロー最適化の5つのレバー

ワークフローを最適化する際に効くレバーは、概ね5つに集約される。第1に、仕様を Source of Truth にすること。第2に、自動テストを設計言語として使うこと ― テストが書けない仕様は仕様ではない、という文化を作る。第3に、並列化できる工程を見極め、AIに同時実行させる仕組みを整えること。第4に、レビュー文化を全工程に組み込み、AIの暴走を防ぐ唯一の手段として機能させること。第5に、DORA指標で改善サイクルを回すこと。この5つを揃えるだけで、AIDDの定着確度は大きく上がる。

レバー効果
仕様を Source of Truth に工程間ドリフトが減少
テストを設計言語に仕様の検証可能性が向上
並列化の徹底スループットが向上
レビュー文化の浸透品質劣化を防止
DORA指標の運用改善が定量で見える

💡 ポイント:5レバーすべてを同時に動かすのではなく、自社の弱点1〜2点に絞って90日で集中改善するほうが、結果的に速く成果が出る。

10. 経営層が押さえるべきワークフロー再設計の論点

経営層がAIDDのワークフロー再設計を判断する際の論点は3つある。第1に、ツール投資の前にプロセス再設計の議論を済ませることだ。Claude Code や Cursor を導入する前に、6フェーズの主役・KPI・レビュー体制を決めておかないと、ツール費だけが膨らむ。第2に、ガバナンスとセキュリティのルール整備を並行で進めることだ。AI利用ポリシー、権限設計、知財・契約ルールの3点が揃っていないと、現場が萎縮するか、逆に無防備に走るかの両極端になる。第3に、経営会議への定例レポートを設計し、DORA指標を中心に進捗を見える化することだ。

論点確認事項
プロセス再設計6フェーズの主役・KPI・レビュー体制が文書化されているか
ガバナンスAI利用ポリシー・権限設計・知財ルールの3点セット
経営報告DORA指標ベースの月次レポートが運用されているか
教育投資レビュアー育成・プロンプトスキル研修の計画
段階展開パイロット → 横展開 → 全社の3段階ロードマップ

📊 経営判断のコツ:「ツール導入 → プロセス変更」ではなく「プロセス設計 → ツール選定 → ガバナンス整備 → 段階展開」の順番を厳守すると、投資対効果が桁違いに高くなる。

まとめ

AI駆動開発のワークフローは、要件定義から運用までの6フェーズで、人間とAIの役割分担を明示することで初めて機能する。AIに全部任せるのでも、人間が全部やるのでもなく、フェーズごとに主役を切り替える設計が本質だ。仕様を Source of Truth に置き、テストを設計言語として使い、並列化とレビューを両立させ、DORA指標で改善サイクルを回す。この5つを揃えた組織が、AIDD時代の競争優位を握る。経営層は、ツール導入の前にプロセス再設計とガバナンス整備の順序を厳守してほしい。

AIDDワークフロー導入チェックリスト

  • [ ] 6フェーズの主役・AI活用度・KPIを1枚にまとめてある
  • [ ] 仕様書がチーム全員から参照される Source of Truth になっている
  • [ ] 受け入れ条件をAIで網羅的に生成する仕組みがある
  • [ ] 設計判断の根拠が文書化されている
  • [ ] 実装フェーズの前にレビュー体制が整っている
  • [ ] AIレビュー+人間レビューの2段構えになっている
  • [ ] 自動テストが仕様の検証可能性を担保している
  • [ ] DORA指標が月次で計測・報告されている
  • [ ] AI利用ポリシーが文書化され全員に共有されている
  • [ ] パイロット → 横展開 → 全社の3段階ロードマップがある
  • [ ] 経営会議への定例レポートが設計されている

IT COMPASSのAI駆動開発支援

IT COMPASS では、CTO経験者が外部CTO・技術顧問として、AI駆動開発のワークフロー設計・展開を伴走支援しています。

支援できること

  • 🎯 AIDDワークフロー設計:6フェーズの主役・KPI・レビュー体制の設計と現場展開
  • 🛠 ツール選定とパイロット設計:Claude Code / Cursor / GitHub Copilot 等の評価・PoC設計
  • 🛡 ガバナンス・セキュリティ整備:AI利用ポリシー、権限設計、知財・契約ルール
  • 👥 開発組織の再設計:AIエージェントを前提としたチーム編成・役割定義・評価制度
  • 📈 経営会議への定例参加:取締役会・経営会向けのDORA指標ベースKPI設計と進捗レポート

こんな方におすすめ

  • 開発プロセス全体をAIDDに合わせて再設計したいCTO・開発リーダーの方
  • 工程別のAI活用度を整理し、現場と経営に共通言語を作りたい経営企画・PMの方
  • DORA指標で改善サイクルを定量的に回したい開発マネジメント層の方

お問い合わせ

スポット相談(1回/契約不要・最短当日)から、月額契約での継続伴走まで、フェーズに応じて柔軟に対応します。

👉 IT COMPASS お問い合わせフォーム

経営と技術の両面から、御社のAI駆動開発ワークフローを一緒に設計しましょう。

監修者

西脇靖紘 プロフィール写真

西脇 靖紘(lanitech合同会社 代表取締役CEO 兼 CTO)

「テクノロジーで人と社会をつなぐ」をミッションに、企業のDX推進・AI導入支援から、デジタル教育・地域共創まで幅広く活動。エンジニアとしての現場経験と経営視点を活かし、外部CTO・AIコンサルティングなどを通じて企業のデジタル変革を支援している。著書はオライリー・ジャパンから複数刊行。

 
lanitech合同会社 webサイト

まずは
お気軽にご相談ください

無料相談・チェックリスト提供中。
まずは小さく始められます。

Services

提供サービス

外部CTO支援

詳しく見る

経営
アドバイザリング
(技術×経営)

詳しく見る

開発組織構築・
スケール支援

詳しく見る

IT投資計画の
策定支援

詳しく見る

ITコスト最適化・
ベンダーマネジメント

詳しく見る

技術顧問
(Technical Advisor)

詳しく見る

ライトプラン
(スポット相談)

急ぎの経営・ITトラブルに。
1回のみ/契約不要で利用できる、
オンライン相談プランです。

セキュリティ
壁打ちプラン
(中小企業向け)

IT・セキュリティ・
DX相談
(経営者向け)

CTO相談室