2026年版: AIエージェント時代のScrum運用ガバナンス

まず現実を直視する

「AIエージェントでScrumを回している」と言うチームの多くは、実際には従来Scrumの外側に自動化を足しただけです。その結果、スプリント計画はブレ、PR量だけ増え、ふりかえりで同じ課題が反復されます。

原則: エージェントは“可変信頼度の実行能力”

エージェントをチームメンバー擬人化で扱うと責任境界が曖昧になります。実務では、エージェントを信頼度が揺れる実行キャパシティとして扱うほうが機能します。

バックログ設計を2軸化する

各ストーリーを次の2軸で分類します。

実装複雑度（依存・影響範囲・統合難易度）
エージェント適合度（生成可能性・再現性）

2x2で運用すると判断が速くなります。

高複雑 × 低適合: 人手主導
高複雑 × 高適合: 人手主導 + エージェント補助
低複雑 × 高適合: エージェント先行 + 軽量レビュー
低複雑 × 低適合: 後回し/再定義

スプリント計画の補正ポイント

1) 見積もりに信頼度バンドを付ける

ストーリーポイントに加え、信頼度を明示します。

C1: 高信頼（既知パターン、テスト十分）
C2: 中信頼（手戻り可能性あり）
C3: 低信頼（探索要素が大きい）

C2/C3比率が高いスプリントは、速度予測を保守的に補正します。

2) 生成時間と検証時間を分ける

40分で生成できても、検証に2時間かかるケースは普通です。ここを分離しないと、計画精度は崩れます。

Agent支援ストーリーのDefinition of Done

実行コンテキスト（指示・条件）を記録
受入条件と生成差分の対応を明示
依存更新のセキュリティ検査通過
境界条件/失敗系をレビュアーが確認
重要機能はロールバック手順を残す

「マージ済み」を「Done」と同義にしないことが重要です。

レビュー運用: 2レーン制

Lane A: 低リスク定型変更（テンプレート準拠）
Lane B: 設計・セキュリティ・横断影響あり（深いレビュー）

どちらに入るかは、PR作成者の自己申告ではなくルールで自動判定します。

ふりかえりは“個別事象”で終わらせない

再発しやすい失敗を分類し、仕組みに反映します。

API前提の幻覚
過剰リファクタ
非機能要件の取りこぼし
古い文脈による誤環境編集

対策はテンプレート、CIチェック、Issueフォームへ再利用可能な形で戻します。

役割の再定義

PO: 受入条件と失敗条件をより具体化
SM: ストーリー件数よりレビュー詰まりを監視
開発者: 実装量より分解力・検証力・設計整合へ重心移動

技術力が不要になるのではなく、必要な技術力の中身が変わります。

3スプリント導入パターン

Sprint 1: 低リスク領域で試行し計測開始
Sprint 2: 信頼度バンドと2レーンレビュー導入
Sprint 3: Agent向けDoDを強制し、キャパシティ再調整

この3サイクルで、速度と品質のバランスが安定しやすくなります。

まとめ

Scrumが壊れる原因はAIの存在ではなく、努力・検証・責任の前提を更新しないことです。信頼度を明示し、工程設計を再構築したチームだけが、AIエージェントを継続的な競争力に変えられます。