現役 PM が教える AI 駆動開発フロー 2026｜要件定義からリリースまでの一気通貫ワークフローを公開

「AI でコードを書く」と「AI 駆動開発で実務を回す」は別物です。前者はツール利用、後者はワークフロー全体の設計です。本記事では現役 8 年目 PM の「やむぅ。」が、要件定義→設計→実装→レビュー→リリースの各フェーズで AI をどう使い分け、チームでどう運用するかを、実プロダクト運用知見をベースに解説します。

AI 駆動開発の実務フローとは何ですか？

AI 駆動開発の実務フローは、5 フェーズすべてで AI を「サポーター・同僚」として組み込み、人間が「承認・判断・責任」を担う設計です。AI 任せでも人間任せでもなく、明確な役割分担をすることで成り立っていきます。

5 フェーズ全体俯瞰

AI に任せる範囲を広げると速くなり、人間が判断する範囲を広げると品質が上がる。実務ではこの 2 つのバランス調整と責任が重要。

フェーズ 1: 要件定義で AI をどう使うのですか？

要件定義は「顧客対話の質」が最大の変数です。自分(個人開発)でも顧客相手でも大事なのは、言葉・不言葉から「本当に欲しいもの」の核心を掴むことです。AI は対話の下書き・記録・整理を担当して情報の漏れを防ぎつつ形式的に情報を網羅し、人間は顧客と直接対話して言葉の解釈や発言外からの要求引き出し、優先度を決めるといった認識・コミュニケーションの役割を担います。

要件定義での AI 活用パターン

「人間にしかできない」要件定義タスク

• 顧客の表情・声のトーンから本音を読み取る
• 複数顧客の要望から優先度を判断する
• 「実装しない機能」を明確に決める
• ステークホルダー間の利害調整
• 予算・期間との折り合いをつける

要件定義の本質は「顧客が本当に欲しいもの」を引き出すこと。AI だけではここが漏れる可能性が高い(と感じた)。

フェーズ 2: 設計で AI をどう使うのですか？

設計フェーズは「複数の選択肢を出す」を AI が担い、「どれを選ぶか」を人間が判断。ADR（Architecture Decision Record）で意思決定を残す運用が鉄則です。

設計での AI 活用パターン

ADR の最小テンプレート

# ADR-001: 認証に Supabase Auth を採用する

## ステータス
Accepted（2026-05-22）

## コンテキスト
学生 1 人で MVP を立ち上げる必要があり、認証実装に時間をかけられない。

## 検討した選択肢
1. Supabase Auth — BaaS で完結、RLS と統合
2. Clerk — UI コンポーネントが豊富
3. Auth0 — エンタープライズ実績

## 決定
**Supabase Auth を採用**。RLS との統合がシームレスで、学生プランで MAU
50,000 まで対応可能。

## 結果
- 認証実装にかかる時間: 30 分（自前実装の 1/20）
- ロックイン: 中（Auth0 / Clerk への移行は将来可能）

詳細な ADR 運用は AI 出力評価・破壊・修復の 5 手法 §「ADR で判断を残す」を参照。

設計フェーズでの NG パターン

• AI に「最適な設計」を聞いて鵜呑み → 正しいっぽい場合だと後々詰む
• ADR を書かない → 3 ヶ月後に「なんでこうしたか」が分からなくなる
• 設計と実装を同時にやる → 後戻りコストが膨らむ

フェーズ 3: 実装で AI をどう使うのですか？

実装フェーズは AI の貢献が最大化される領域。「実装速度 7.5 倍」を実現できますが、diff を ちゃんとレビューする運用が品質維持の鍵です。

実装での AI 活用パターン

AGENTS.md の標準テンプレート

# プロジェクトコンテキスト

## スタック
- Next.js 16 / TypeScript 5 / Tailwind v4 / Supabase / Vercel

## 命名規則
- ファイル: kebab-case.tsx
- コンポーネント: PascalCase
- 定数: SCREAMING_SNAKE_CASE

## 禁止事項
- any / unknown 型の使用禁止
- TypeScript class は基本不使用（Error 継承等の例外を除く）
- console.error は logger.error を使用

## ディレクトリ構成
- app/: Next.js App Router
- features/: Feature-Driven 分割
- components/: 共通コンポーネント
- utils/: ユーティリティ
- lib/: 外部サービス統合

## テスト方針
- vitest で unit 中心、integration は API のみ
- カバレッジ目安 70%

実装フェーズでの 5 段階レビュー

AI 出力を採用するかどうかは、毎回 5 段階で評価する:

詳細は AI 出力評価・破壊・修復の 5 手法 §「5 段階評価フレームワーク」を参照。

フェーズ 4: レビューで AI をどう使うのですか？

コードレビューは「人間 + CI + AI レビューア」の 3 重防御。AI レビューはあくまで補助で、人間の最終承認は省略してはいけない。

レビュー段階での 3 重防御

GitHub Actions に AI レビューを組み込む例

name: AI Review
on: pull_request
jobs:
  ai-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: AI review via Claude
        uses: anthropics/claude-code-action@v1
        with:
          api-key: ${{ secrets.CLAUDE_API_KEY }}
          prompt-file: .github/review-prompt.md

実際の設定は Claude Code Action 公式ドキュメント を参照。

AI レビューだけで任せるリスク

• ハルシネーション残りを見逃す可能性
• プロジェクト固有性を理解できない
• 責任の所在が AI には無い（最終的に人間が負う）

「AI レビューを通したから OK」を承認理由にすると、事故が起きた時にどうしようもなくなる。無条件であなたの責任になるから。AI レビューは人間レビューの 補助として位置付ける。

フェーズ 5: リリースで AI をどう使うのですか？

リリースフェーズは「自動化 + 監視」が中心。AI は監視設定や障害対応の支援に強みを発揮しますが、リリース判断は人間が担います。

リリースでの AI 活用パターン

Vercel + Supabase での標準リリースフロー

障害対応で AI が活きる場面

• エラーログの大量解析: 大量のスタックトレースを AI に要約させる
• 影響範囲の特定: 「このエラーが起きるとどのテーブルに影響するか」を聞く
• ポストモーテムの初稿: 5W1H 構造で下書きを生成

チーム開発と個人開発で AI の使い方はどう違いますか？

チーム開発では「共有ルール」が重要、個人開発では「速度」が重要。同じ AI ツールでも運用設計が変わります。

チーム開発 vs 個人開発の AI 運用比較

チーム開発で AI 駆動開発を標準化する 5 ステップ

1. AGENTS.md をリポジトリで共有 — 全員が同じ規約で AI を動かす
2. Code of Conduct に「AI 出力を必ずレビューする」を明記
3. Prompt Library をチーム共有（よく使うプロンプトを集約）
4. AI レビューの GitHub Actions を全 PR に適用
5. 月次で AI 駆動開発の振り返り（生産性 / 品質 / 課題）

「自分だけ AI を使う」より「チーム全員が同じ AI 駆動開発フロー」のほうが組織の生産性は飛躍的に上がる。

※実務・チームでAI導入が許可されている場合に限ります。

AI 駆動開発で実務生産性はどれくらい上がりますか？

実装フェーズで 2〜3 倍、レビューフェーズで 1.5 倍、リリースフェーズで 2 倍が僕の体感値です。ただし要件定義・設計の質が低いと、実装の速さが裏目に出ます。

フェーズ別の生産性向上目安

生産性を最大化する 3 つの条件

1. AGENTS.md でプロジェクト規約を AI に伝える（毎回プロンプトに書かない）
2. diff レビューを 1 行ずつ実施（採用するかしないかを毎回判断）
3. テストコードを並行で書かせる（実装と同時にテストが揃う）

「AI で 2.5 倍速くなる」は事実だが、これは実装フェーズに限った話。要件定義の質が悪いと「速く間違ったものを作る」だけになる。

よくある質問

Q1: AI 駆動開発を導入したらシニアエンジニアの仕事は減りますか？

A1: シニア需要は減るより、むしろ増えると予想。AI が書ける範囲が広がると、その出力を評価・修復できるシニアの需要が逆に増えます。ジュニアの仕事（指示通りにコードを書く）が減るのは妥当。シニアでもAI使えなく生産性あげられなければ枠としては減る一方と予想。

Q2: 個人開発で AI 駆動開発フローを全部やる必要はありますか？

A2: 要件定義と設計は省略 OK（自分が顧客なので頭の中で完結）。実装・レビュー・リリースは個人開発でもフルでやる価値があります。ただし練習としてやってみるのもOK。

Q3: チームで AI 駆動開発を導入するときの最大の障壁は？

A3: 「AI 出力を採用するかどうかの判断基準がメンバーごとにバラバラ」が最大の障壁。5 段階評価フレームワークを Code of Conduct に明記し、レビュー基準を統一することが解決策。

Q4: AI 駆動開発で品質が下がるリスクはありますか？

A4: あります。人間レビューを省略すると確実に下がる。「AI が書いた → CI が通った → マージ」のフローだとハルシネーション・脆弱性が残ります。3 重防御（人間 + CI + AI レビュー）を必ず維持。

Q5: 中小企業・受託開発で AI 駆動開発を導入する手順は？

A5: 「1 プロジェクト 1 人」から始めるのが安全。先行者が AGENTS.md と Prompt Library を整備 → 成功事例を社内共有 → 全プロジェクトに展開。3〜6 ヶ月で組織標準化が現実的。

Q6: AI 駆動開発で失われるエンジニアスキルはありますか？

A6: 「コードを 1 行ずつ書く力」は確かに減ります。ただし「設計判断 / 品質保証 / アーキテクチャ思考」は逆に研ぎ澄まされます。AI に丸投げする層は淘汰されつつ、AI を指揮する層が勝ち残ってくといった構造変化が起こると考えます。

Q7: ProFact では AI 駆動開発の実務フローをどう教えますか？

A7: ProFact は 要件定義 → 設計 → 実装 → レビュー → リリースの全工程を、現役 PM のやむぅ。が実プロジェクト題材で 1on1 で伴走します。Cursor や Claude Code といったAIを用いて実務運用を 6 ヶ月で叩き込みます。詳細は AI 共生型エンジニア完全ロードマップ 2026 を参照。

Q8: AI 駆動開発の学習はどこから始めるべきですか？

A8: 「手元のプロジェクト 1 つで AIを導入する」から始めるのが最短経路。チュートリアル用プロジェクトでは学習効果が出ません。詳細な手順は Cursor を実務で使いこなす完全ガイド 2026 を参照。

Q9: 実際の仕事にAI を導入されている企業は多いですか？

A9: 正直まだ少ないです。海外とは違い、日本はセキュリティや多重下請け構造が理由で「許可されてない」「下流にそんなコスト出せない」「そもそもネット接続が許されていない」などでAI導入されていないのかなというのが現状っぽいです。

まとめ

• AI 駆動開発の実務フローは 5 フェーズすべてで AI を「副操縦士」として組み込む
• 各フェーズで AI の役割と人間の役割を明確に分担
• 実装は 2〜3 倍速になるが、要件定義 / 設計の質が低いと裏目に出る
• ADR で 設計判断を必ず記録、3 ヶ月後の保守可能性を担保
• レビューは 人間 + CI + AI レビューの 3 重防御
• チーム開発では AGENTS.md と Prompt Library の共有が標準化の鍵
• 「コードを書く力」より「AI を指揮する力 / 評価する力」が市場価値

関連記事:

• AI 共生型エンジニア完全ロードマップ 2026
• Cursor を実務で使いこなす完全ガイド 2026
• AI 出力評価・破壊・修復の 5 手法
• Stripe 連携でマネタイズする最短手順
• 起業・個人開発で結果を出すための実装力 2026

本記事の生産性向上目安・運用パターンは 2026 年 5 月時点の現役 PM 観測値および公開情報に基づきます。実プロジェクトでの効果はチーム規模・スキル・既存スタックで変動します。