はじめに
ウォーターフォール、アジャイル、スクラム。ソフトウェア開発のプロセスモデルは時代とともに進化してきましたが、いずれも共通する暗黙の前提があります。それは 人間がコードを書く ということです。
スクラムでは、スプリント計画で開発チームが見積もりを行い、デイリースクラムで進捗を共有し、スプリントレビューで動くものをデモする。この一連のフローは、人間の作業速度・コミュニケーション特性・認知負荷を前提に設計されています。
しかし、AI駆動で開発を行うチームでは、この前提が根本的に変わります。コードの生成速度は桁違いに速くなる一方で、「要件を正しく定義する」「品質を検証する」という工程の重要性が圧倒的に増す。ボトルネックが「実装」から「意思決定と品質検証」に移るのです。
Qurated Labでは、スクラムのフレームワークを尊重しつつ、AIチームに最適化した開発プロセスを設計・運用しています。この記事では、従来のスクラムとの対比を通じて、AI駆動開発におけるプロセス設計の考え方を共有します。
補足： プロジェクト開始時のインセプション（ビジョン策定・RFP生成・アーキテクチャ選定など、いわゆるSprint 0以前の準備工程）については、それ自体が大きなテーマのため、別記事にて紹介予定です。本記事では、スプリント開発が始まる段階からのプロセスに焦点を当てます。
スクラムの「3つの柱」はAI駆動でも変わらない
まず確認しておきたいのは、スクラムの根幹である透明性・検査・適応の3つの柱は、AI駆動でもそのまま有効だということです。むしろ、AIの方が得意な側面すらあります。
ただし、それぞれの「意味」が変わります。
graph TB
subgraph "スクラムの3つの柱"
T["透明性 Transparency"]
I["検査 Inspection"]
A["適応 Adaptation"]
end
subgraph "従来のスクラム"
T1["朝会での口頭共有 タスクボードの更新 バーンダウンチャート"]
I1["スプリントレビューで成果物を確認 レトロスペクティブでプロセスを振り返り"]
A1["次スプリントの計画に反映 プロセス改善を議論"]
end
subgraph "AI駆動のスクラム"
T2["AIの判断根拠を記録 レビュー結果の構造化ログ 品質メトリクスの自動収集"]
I2["CIゲートでの自動検査 異なるAIモデルによるクロスレビュー カバレッジの定量計測"]
A2["学習システムが成功/失敗パターンを蓄積 信頼度に基づき次回の判断を自動最適化"]
end
T --> T1
T --> T2
I --> I1
I --> I2
A --> A1
A --> A2
style T fill:#1a6b35,stroke:#27ae60,color:#fff
style I fill:#1a6b35,stroke:#27ae60,color:#fff
style A fill:#1a6b35,stroke:#27ae60,color:#fff
特に大きな変化は 適応 です。従来のスクラムでは、レトロスペクティブで「次はこうしよう」と話し合い、チームの意識や行動として改善を図ります。一方、AI駆動では成功・失敗パターンが信頼度スコア付きで自動記録され、次のスプリントでは高信頼度のパターンが優先適用される。 改善 が意識ではなくシステムとして実装される点が決定的に異なります。
ロールの再定義 ── 人間は「意思決定者」へ
従来のスクラムには3つの明確なロールがあります。AI駆動開発では、これらの役割分担がどう変わるのかを整理します。
graph TB
subgraph "従来のスクラムロール"
PO_T["プロダクトオーナー 要件定義 / 優先順位決定"]
SM_T["スクラムマスター プロセス管理 / 障害除去"]
DEV_T["開発チーム 設計 / 実装 / テスト"]
end
subgraph "AI駆動スクラム：人間の役割"
PO_H["プロダクトオーナー（人間） ビジネス要件の策定 バックログの優先順位決定 計画の承認"]
SM_H["承認・監督者（人間） AIが提案したプロセスの承認 異常時の介入判断 ステークホルダーとの対話"]
end
subgraph "AI駆動スクラム：AIの役割"
PLAN["Planner 実装計画の自動生成"]
ARCH["Architect 設計方針の検証"]
IMPL["開発エージェント群 TDD駆動の実装"]
REV["レビューエージェント群 コード / セキュリティ / クロスレビュー"]
LEARN["学習システム パターン記録 / 自動最適化"]
end
PO_T -.->|"変化なし"| PO_H
SM_T -.->|"役割が縮小"| SM_H
DEV_T -.->|"AIが主体に"| IMPL
PO_H -->|"承認"| PLAN
SM_H -->|"監督"| LEARN
PLAN --> ARCH
ARCH --> IMPL
IMPL --> REV
REV --> LEARN
style PO_H fill:#2c3e50,stroke:#ecf0f1,color:#fff
style SM_H fill:#2c3e50,stroke:#ecf0f1,color:#fff
style PLAN fill:#1a6b35,stroke:#27ae60,color:#fff
style ARCH fill:#1a6b35,stroke:#27ae60,color:#fff
style IMPL fill:#1a6b35,stroke:#27ae60,color:#fff
style REV fill:#1a6b35,stroke:#27ae60,color:#fff
style LEARN fill:#1a6b35,stroke:#27ae60,color:#fff
「核心的な変化は、人間の役割が『作業者』から『意思決定者・承認者』にシフトすることです」
プロダクトオーナーの役割は本質的に変わりません。「何を作るべきか」「何が優先か」というビジネス判断は、依然として人間にしかできない領域です。
一方、スクラムマスターの役割は大きく縮小します。進捗追跡・品質ゲート管理・プロセスの実行はAIが自律的に行うため、人間は「AIが正しく機能しているかの監督」と「ステークホルダーとの対話」に集中します。
開発チームについては、AIエージェント群が実装・テスト・レビューを担い、人間は設計判断の承認やスコープ変更の意思決定に関与する形になります。
セレモニーのアレンジ ── 何が変わり、何が残るか
スクラムの5つのイベントそれぞれを、AI駆動でどうアレンジしているかを具体的に解説します。
スプリント計画（Sprint Planning）
従来のスプリント計画では、チーム全員が集まり、バックログアイテムの見積もりとタスク分解を議論します。プランニングポーカーで見積もり、ホワイトボードでタスクを分解し、合意形成を図る。この工程に数時間を費やすのが一般的です。
AI駆動では、このフローが根本的に変わります。
sequenceDiagram
participant PO as プロダクトオーナー（人間）
participant AI_PLAN as Planner
participant AI_ARCH as Architect
participant AI_TP as Test Planner
participant BACKLOG as バックログ
PO->>BACKLOG: 優先順位を確定
Note over AI_PLAN: 自動的に起動
AI_PLAN->>BACKLOG: バックログを読み込み
AI_PLAN->>AI_PLAN: 技術スタック検出
AI_PLAN->>AI_PLAN: 既存コードベース分析
par 並列分析
AI_PLAN->>AI_ARCH: アーキテクチャ影響を確認
AI_PLAN->>AI_TP: テスト戦略を策定
end
AI_ARCH-->>AI_PLAN: 設計上の制約・推奨事項
AI_TP-->>AI_PLAN: テスト方針・カバレッジ目標
AI_PLAN->>AI_PLAN: タスク分解・依存分析・準拠ドキュメント割当
AI_PLAN-->>PO: 計画書を提示
Note over PO: 人間が内容をレビュー
alt 承認
PO->>AI_PLAN: 計画を承認
Note over AI_PLAN: スプリント開始
else 修正依頼
PO->>AI_PLAN: フィードバック
AI_PLAN->>AI_PLAN: 計画を修正
AI_PLAN-->>PO: 修正版を提示
end
変わった点: 計画の「精度」と「速度」が飛躍的に向上します。AIはコードベース全体を把握した上で依存関係を分析し、タスク分解を行います。人間の議論の焦点は「何をどう分解するか」から この計画で本当にビジネス価値を届けられるか に移ります。
計画書には、各タスクの準拠ドキュメント（アーキテクチャガイド・テスト規約・セキュリティガイドラインなど）が自動で割り当てられるため、実装フェーズでの品質基準のブレを防ぎます。
デイリースクラム
従来のデイリースクラムでは、チーム全員が15分で「昨日やったこと / 今日やること / 障害」を共有します。
AI駆動では、この3つの情報はリアルタイムで自動記録・可視化されているため、人間が毎朝報告する必要がありません。進捗追跡システムが各タスクのステータス・完了率・品質メトリクスを常時更新し、異常（たとえばビルド失敗の連続やカバレッジの急落）が発生した時のみ人間にアラートが飛ぶ仕組みです。
変わった点: デイリースクラムは「報告の場」から 異常時の判断の場 に変わります。順調に進んでいる日はセレモニー自体が不要になり、問題が発生した時にのみ人間が介入判断を行います。
ストーリー実装（スプリントの中核作業）
ここが最も大きく変わる部分です。従来の「開発者がコーディング → テスト → レビュー」というフローが、AIエージェント群による5フェーズワークフローに置き換わります。
sequenceDiagram
participant PO as 人間（承認者）
participant ORCH as オーケストレーター
participant TDD as TDD Guide
participant CR as Code Reviewer
participant SR as Security Reviewer
participant GR as Gemini Reviewer
participant CI as CI/CDゲート
participant LEARN as 学習システム
Note over ORCH: Phase 1: Exploration
ORCH->>ORCH: コードベースを探索 既存パターンを理解
Note over ORCH: Phase 2: Planning
ORCH-->>PO: 実装方針を提示
PO->>ORCH: 承認
Note over ORCH: Phase 3: Implementation（TDD駆動）
ORCH->>TDD: ストーリー実装を開始
loop 各タスクについて
TDD->>TDD: SCAFFOLD（インターフェース定義）
TDD->>TDD: RED（失敗するテスト作成）
TDD->>CI: 実行 → 失敗を確認
TDD->>TDD: GREEN（最小限の実装）
TDD->>CI: 実行 → 成功を確認
TDD->>TDD: REFACTOR
TDD->>CI: カバレッジ確認
end
Note over ORCH: Phase 4: Review
ORCH->>CR: コードレビュー依頼
CR->>CR: CRITICAL/HIGH/MEDIUM に分類
alt セキュリティ関連の変更
CR->>SR: セキュリティレビュー依頼
SR-->>CR: セキュリティレポート
end
CR-->>ORCH: 一次レビュー結果
ORCH->>ORCH: 指摘事項を修正
ORCH->>GR: Geminiクロスレビュー依頼
GR->>GR: 異なるAI視点で再検証
GR-->>ORCH: セカンドオピニオン
Note over ORCH: Phase 5: Verify
ORCH->>CI: 全品質ゲート検証
CI-->>ORCH: 静的解析 / テスト / カバレッジ / サイズ制限
ORCH->>LEARN: 成功・失敗パターンを記録
ORCH-->>PO: 完了報告
従来との最大の違い: 実装・テスト・レビューの各工程が分離された別々の作業ではなく、TDD 7ステップとして一体化されている点です。「まずテストを書き、失敗を確認し、最小限の実装で通し、リファクタリングする」というサイクルをAIが自律的に回します。
さらに、レビューフェーズでは異なるAIモデルによるクロスレビューが必須です。開発を担当したAIとは別のAIモデルが独立した視点で検証することで、単一モデルのバイアスを排除します。
スプリントレビュー（Sprint Review）
従来のスプリントレビューでは、動くプロダクトをステークホルダーにデモし、フィードバックを収集します。
AI駆動でも、デモの実施とフィードバック収集は人間が担います。ただし、デモシナリオの準備やスプリントの成果サマリーはAIが自動生成するため、準備工数が大幅に削減されます。
変わった点: デモ準備の自動化に加え、スプリント中に収集された定量データ（カバレッジ推移・レビュー指摘数・修正完了率など）が自動的にレポート化されるため、ステークホルダーへの説明がデータに裏打ちされたものになります。
レトロスペクティブ（Retrospective）
ここがAI駆動スクラムで最も革新的に変わる部分です。
sequenceDiagram
participant TEAM as チーム（人間）
participant AI as AIメトリクス分析
participant LS as 学習システム
participant KB as ナレッジベース
participant NEXT as 次のスプリント
Note over AI: スプリント終了時に自動起動
AI->>AI: 定量メトリクスを集計（カバレッジ推移・バグ率・レビュー指摘傾向・ビルド成功率）
AI->>LS: スプリント中の判断パターンを分析
LS->>KB: 成功パターンを記録（信頼度スコア付き）
LS->>KB: 失敗パターンを記録（回避ルール付き）
AI-->>TEAM: データに基づく改善ポイントを提示
TEAM->>TEAM: 人間の視点で議論（ビジネス判断・ユーザー体験・チームの感覚的な気づき）
TEAM->>KB: 人間の知見を追加
Note over KB: 信頼度が閾値を超えたパターンは「Instinct」に昇格
KB-->>NEXT: 高信頼度パターンを次スプリントに自動適用
従来のレトロスペクティブとの違い: 従来は「KPT（Keep / Problem / Try）」のような形式で感覚的に振り返りを行い、改善は次スプリントでのチームの行動変容に依存していました。
AI駆動では、定量データの自動分析に加え、学習システムが成功・失敗パターンを信頼度スコア付きで蓄積します。たとえば「認証関連のコード変更時にセキュリティレビューを並行実行したケースではバグ検出率が高かった」というパターンが高信頼度に達すると、次回以降は自動的にそのパターンが適用される。 改善が「意識」ではなく「仕組み」として定着するのが最大の差異です。
ただし、ビジネス判断やユーザー体験に関する感覚的な気づきはAIでは拾えないため、人間によるディスカッションは引き続き不可欠です。AIのデータ分析と人間の感性を組み合わせることで、レトロスペクティブの質が向上します。
AI駆動で新たに加わった仕組み
従来のスクラムには存在しないが、AI駆動だからこそ必要になった仕組みがいくつかあります。これらは、スプリントサイクルの中で以下のように機能しています。
graph TB
subgraph "スプリントサイクル"
PLAN["Sprint Planning"]
IMPL["ストーリー実装"]
REVIEW["Sprint Review"]
RETRO["Retrospective"]
PLAN --> IMPL --> REVIEW --> RETRO
RETRO -->|"次Sprint"| PLAN
end
subgraph "AI駆動で追加された仕組み"
CROSS["異なるAIモデルによるクロスレビュー"]
LEARN["継続的学習システム 信頼度スコア付きパターン蓄積"]
GATE["品質ゲートの自動強制 カバレッジ / 静的解析 / コードサイズ制限"]
CHECK["チェックポイント＆ロールバック"]
end
CROSS -.->|"Phase 4で適用"| IMPL
GATE -.->|"Phase 5で適用"| IMPL
CHECK -.->|"Phase開始時に作成"| IMPL
LEARN -.->|"Phase完了時に記録"| IMPL
LEARN -.->|"分析結果を提供"| RETRO
LEARN -.->|"高信頼度パターンを自動適用"| PLAN
style CROSS fill:#1a3a5c,stroke:#2980b9,color:#fff
style LEARN fill:#1a3a5c,stroke:#2980b9,color:#fff
style GATE fill:#1a3a5c,stroke:#2980b9,color:#fff
style CHECK fill:#1a3a5c,stroke:#2980b9,color:#fff
異なるAIモデルによるクロスレビュー
人間の開発チームでは「コードを書いた本人ではなく別のメンバーがレビューする」のが鉄則です。AI駆動でも同じ原理を適用し、開発・一次レビューを行ったAIモデルとは意図的に異なるAIモデルがセカンドオピニオンを提供します。
これにより、単一モデルの学習データに起因するバイアスや、特定パターンの見落としを補完します。レビュー結果が対立した場合の解決ルールも事前に定義されており、重大度に基づいて判断されます。
継続的学習システム
各スプリントで行われたレビュー結果、検出された問題、適用された修正パターンが、成功・失敗それぞれ信頼度スコア付きで記録されます。
学習パターンには3段階のライフサイクルがあります。新しいパターンは低い信頼度で「pending」として記録され、複数回の成功実績を重ねると信頼度が上昇し、閾値を超えると「Instinct（直感）」に昇格して優先的に自動適用されるようになります。逆に、失敗パターンは回避ルールとして記録され、同じ過ちを繰り返さない仕組みが働きます。
これは、従来のレトロスペクティブの「Try（次に試すこと）」を自動化・定量化したものと言えます。
品質ゲートの自動強制
カバレッジ・静的解析エラー・コードサイズ・セキュリティスキャンなどの品質基準をCIゲートとして実装し、基準を満たさないコードは物理的にマージできない仕組みにしています。
従来のスクラムでは、レビューの厳密さは個人のスキルや意識に依存しがちです。AI駆動では、品質基準をシステムとして強制することで、「まあいいか」という妥協を構造的に排除します。
チェックポイント＆ロールバック
AIの判断が常に正しいとは限りません。そのため、各フェーズの開始時にコードベースのスナップショットを自動取得し、問題が発生した場合に即座にロールバックできる仕組みを設けています。
これは、人間がAIの作業を安心して任せるための安全装置です。「AIに任せたら取り返しがつかない」という不安を解消するために、ロールバックポイントを細かく設定しています。
人間に残る不可欠な役割
AI駆動スクラムは「人間不要」のモデルではありません。むしろ、人間がより高次の判断に集中できるモデルです。
AIでは代替できない、人間が担うべき領域を明確にしておきます。
graph LR
subgraph "人間が担う領域"
BIZ["ビジネス要件の策定 何を作るべきかの判断"]
STAKE["ステークホルダーとの対話 フィードバック収集 期待値調整"]
ETHICS["倫理的判断 プライバシー / アクセシビリティ / ユーザー体験の感性的評価"]
APPROVE["承認ゲート 計画承認 / リリース判断 / スコープ変更"]
SUPERVISE["AIの監督 学習パターンの妥当性確認 異常時の介入判断"]
end
subgraph "AIが担う領域"
PLAN_AI["計画立案 / タスク分解"]
CODE_AI["設計 / 実装 / テスト"]
REVIEW_AI["コードレビュー / セキュリティ検証"]
PROGRESS_AI["進捗追跡 / 品質計測"]
LEARN_AI["パターン学習 / 自動最適化"]
end
BIZ ===|"人間が決定"| PLAN_AI
APPROVE ===|"人間が承認"| CODE_AI
SUPERVISE ===|"人間が監督"| LEARN_AI
style BIZ fill:#2c3e50,stroke:#ecf0f1,color:#fff
style STAKE fill:#2c3e50,stroke:#ecf0f1,color:#fff
style ETHICS fill:#2c3e50,stroke:#ecf0f1,color:#fff
style APPROVE fill:#2c3e50,stroke:#ecf0f1,color:#fff
style SUPERVISE fill:#2c3e50,stroke:#ecf0f1,color:#fff
style PLAN_AI fill:#1a6b35,stroke:#27ae60,color:#fff
style CODE_AI fill:#1a6b35,stroke:#27ae60,color:#fff
style REVIEW_AI fill:#1a6b35,stroke:#27ae60,color:#fff
style PROGRESS_AI fill:#1a6b35,stroke:#27ae60,color:#fff
style LEARN_AI fill:#1a6b35,stroke:#27ae60,color:#fff
Human-in-the-Loop： AIは計画を立案しますが、それを実行に移すかどうかは人間が判断します。AIは実装しますが、リリースするかどうかは人間が決定します。この「承認ゲート」の設計が、AI駆動開発の信頼性を担保しています。
導入へのステップ ── まずどこから始めるか
いきなりすべてをAI駆動にするのは現実的ではありません。既存のスクラムチームがAI駆動へ移行するための段階的なパスを、たとえば以下のように設計することが可能です。
graph LR
L1["Level 1 テスト自動生成の導入"]
L2["Level 2 コードレビューのAI化"]
L3["Level 3 計画立案のAI支援"]
L4["Level 4 スプリント全体のAI駆動化"]
L1 -->|"品質基盤を構築"| L2
L2 -->|"レビュー精度向上"| L3
L3 -->|"プロセス全体最適化"| L4
style L1 fill:#1a3a5c,stroke:#2980b9,color:#fff
style L2 fill:#1a3a5c,stroke:#2980b9,color:#fff
style L3 fill:#1a3a5c,stroke:#2980b9,color:#fff
style L4 fill:#1a6b35,stroke:#27ae60,color:#fff
Level 1: テスト自動生成の導入 ── TDDの7ステップワークフローをAIに担わせ、テストの網羅性を向上させる。既存の開発フローは変えず、テスト工程のみAI化する最もリスクの低い入口です。
Level 2: コードレビューのAI化 ── 人間のレビューに加え、AIによるコードレビューとセキュリティスキャンを導入。この段階で品質ゲートのCI実装を行い、品質基準を「ルール」として定着させます。
Level 3: 計画立案のAI支援 ── スプリント計画において、AIがタスク分解・依存分析・準拠ドキュメント割当を自動生成。人間はレビュー・承認に集中する形へ移行します。
Level 4: スプリント全体のAI駆動化 ── 実装・テスト・レビュー・学習の全工程をAIエージェント群が自律的に実行し、人間は意思決定と監督に特化。ここまでの各レベルで蓄積された学習パターンが、プロセス全体の品質を支えます。
まとめ ── 進化し続けるプロセス
スクラムの本質は「透明性・検査・適応」のサイクルを回し続けることです。AI駆動でもこの本質は変わりません。変わるのは 誰がどの作業を担うか の配分です。
AIは実装・テスト・レビュー・進捗管理を担い、人間はビジネス判断・承認・監督・ステークホルダーとの対話に集中する。この役割分担を明確にし、品質ゲートと学習システムで担保する。それがQurated LabのAI駆動スクラムです。
ただし、ここで紹介したモデルは現時点でのスナップショットに過ぎません。
AIの能力は日々進化しています。半年前には不可能だったことが今は可能になり、今は人間が担っている判断の一部も、将来的にはAIが担えるようになるかもしれません。私たちのプロセスモデル自体も、AI技術の進化に合わせて動的に変化し続けています。継続的学習システムがスプリントごとに最適化を行っているように、プロセスモデル自体もまた、常に「適応」し続ける対象です。
今後もこのKnowledge & Insightsでは、AI駆動開発の実践から得られた知見を発信し続けます。プロセスモデルに大きなアップデートがあった際には、改めてその変化と学びを共有する予定です。