スクラム開発 × AIコーディング：アジャイル環境での仕様管理実践ガイド【2025年版】¶
スクラムに AI コーディングを組み込むと、従来の「ストーリー＋AC＋レビュー」だけでは仕様ドリフトが起きやすい。Claude Code / Copilot / Cursor を使うチーム向けに、ユーザーストーリー・AC・DoD・レビュー観点を 2025 年版にアップデートする具体手順をまとめた。
関連ガイド¶
- 仕様書 vs コード vs プロンプト：ドキュメント戦略の比較
- Claude Code 自動許可ガイド（運用設計）
- Claude Code インストール＆環境構築
- GitHub Copilot カスタムインストラクション実践
- Codex CLI 承認モードの安全な使い分け
- Claude Code プロジェクト管理ベストプラクティス
スクラム現場の「最低限仕様」運用と、その前提の崩壊¶
多くのスクラムチームでは、仕様を PBI 上の最小限の情報に集約している。ユーザーストーリーは「As a 〜, I want 〜, so that 〜」形式、受け入れ条件（AC）はシナリオベース。アジャイルマニフェストの「動くソフトウェアを」の精神が、実務上は「分厚い仕様書より対話で前に進もう」という運用に落ちている。
人間だけで開発していたときは、これで回っていた。開発者はチームの文脈を知っており、「この PO の言う"シンプル"はだいたいこれぐらい」と暗黙に補完できた。足りなければ口頭で確認して済んだ。
AI コーディングが入ると、この前提が崩れる。
AI コーディングが持ち込むギャップ¶
AI の本質的なリスクは、曖昧さを無視することではない。曖昧なところを"いい感じ"に補完してしまうことにある。
典型的なズレのパターン¶
1. チームの暗黙知を知らない
ストーリー：「一覧画面には最近追加されたアイテムを上に表示すること」
チーム内では「最近＝過去30日」「種別でソート優先度が変わる」が共通認識。しかし AI はその場で都合の良い解釈を決めてしまう。
2. "ベストプラクティス"で仕様を書き換える
AC：「アクセスはシングルサインオン利用ユーザーに限定すること」
仕様書には「A 社 IdP の SAML」と明記されているのに、AI は「OIDC の方がモダン」と判断して OIDC 前提で実装しようとする。
3. コンテキストの取りこぼし
ストーリーをまとめて渡すと、AI が一部の前提を単純に「忘れる」。PBI 単位では整合していても、横断的な制約が抜ける。人間なら「前のストーリーでこう決めたな」と思い出せるところを、AI は素直に忘れる。
プロジェクトレベルのコンテキスト管理
Claude Code の CLAUDE.md や Cursor Rules のように、プロジェクトレベルのコンテキストを保持する仕組みは登場しつつある。ただし現時点では適切に運用できているチームは少なく、暗黙知の補完問題は残っている。
レビューでも拾いきれない¶
PR レビュー側にも圧力がかかっている。AI によるコード生成で 1 PR あたりのコード量が増え、レビュアーは「ロジック＋設計＋セキュリティ＋スタイル」で手一杯。「そもそもこれ、仕様と違う」まで見る余裕がない。
結果、「テストは通っているし、コードも悪くない。でも何かモヤる」→ リリース後に仕様との乖離が判明、というケースが増える。
AC の構造を変える：What / Rule / How¶
AI を前提にしたとき最初に効くのは、AC の粒度と構造を変えることである。
「冗長に書け」ではなく「AI が迷子になる箇所」を明示する¶
たとえば「一覧画面に最近追加されたものを上に表示」だけでなく、以下を足す。
- 「最近」の定義（過去◯日、タイムゾーン）
- ソート優先順位（
created_at DESCか、更新日時か） - ページングや上限（100件まで、など）
全部を書こうとすると破綻するので、AI が勝手に決めそうな箇所だけに絞るのがポイント。
AC の 3 分類¶
| 種別 | 内容 | 例 |
|---|---|---|
| AC-What | ユーザーから見える振る舞い | 「〜できること」「〜が表示されること」 |
| AC-Rule | 業務ルール・ビジネス制約 | 料金計算ロジック、権限制御、SLA |
| AC-How(critical) | クリティカルな実装制約 | データソース、暗号化方式、キャッシュ利用有無 |
AC-How(critical) には「ベストプラクティスに任せると危ない部分」だけを載せる。
書く基準の目安：
- What：「AI が別の選択をしそうな箇所」（曖昧な表現がある場合）
- Rule：「間違うとビジネス影響が出る箇所」（計算ロジック・権限・料金）
- How：「AI が勝手に変更すると危険な箇所」（セキュリティ・コンプライアンス・性能）
判断のドラフトは開発者が作り、PO/SM がリスク観点でレビューする。
Jira / Azure Boards での記載例： Description 内に ### 受け入れ条件 として AC-W1, AC-R1, AC-H1 のようにラベル付け。または種別ごとのカスタムフィールドでチェックリスト化する。
How を AC に含めるか、別仕様に切るか¶
セキュリティ・コンプラ・性能に直結する部分は AC-H として PBI 上に書く。単なる実装好みレベルの How は ADR や設計メモに寄せて AC には書かない。「AI に絶対にやってほしくないこと」だけを AC-H に載せる運用が現実的。
PBI の粒度について¶
AI コーディングで実装速度が上がると、従来より大きめの PBI を許容できるようになる。ただし AI に正しく作らせるには AC を十分に書く必要がある。つまり「PBI を小さく分割する手間」が「AC を詳細に書く手間」に置き換わる。投資先がシフトしているという認識を持っておくとよい。
DoD とレビューのアップデート¶
DoD に「Spec–Test–Code 整合性」を追加する¶
従来の DoD に、次の一行を追加する。
「PBI の AC／テスト／コードの整合性チェックが実施されていること」
具体的には、開発者が AC–テスト–コードの対応を確認するか、AI に「この AC とテスト・コードに矛盾がないか」をレビューさせるステップを挟む。
PR 前の AI レビュー確認¶
AI コーディングを使うなら、AI レビューもセルフチェックとして使うのが合理的。開発者が PBI のストーリー＋AC と変更差分を AI に渡し、不整合や抜け漏れを指摘させる。人間のレビュアーは、それを踏まえて設計・品質・リスクに集中する。
プロンプト例：
以下のユーザーストーリーと受け入れ条件に照らして、
変更コードに仕様との不整合や抜け漏れがないか確認してください。
【確認観点】
- AC にあるのに実装されていない振る舞い
- 実装されているが AC に書かれていない振る舞い
- AC-Rule（業務ルール）との矛盾
- AC-How(critical)（実装制約）への違反
【出力フォーマット】
不整合がある場合：
- [AC-W1] 実装漏れ：〜
- [AC-R2] 矛盾あり：〜（実装では〜となっている）
問題がない場合：「✅ 問題なし」
【ユーザーストーリー】
{ストーリー本文}
【受け入れ条件】
{AC-W, AC-R, AC-H の一覧}
【変更差分】
{Diff}
実行タイミング：
- 推奨：ローカルでコミット前に手動実行
- 中級：PR 作成時に GitHub Actions で自動実行し、結果をコメント投稿
- 上級：pre-commit hook に組み込み
AI セルフチェックの限界
万能ではなく発展途上の手法。過信せず、人間レビューとの併用が前提。
レビュー観点を 3 レイヤに分ける¶
| レイヤ | 視点 | 確認内容 |
|---|---|---|
| What | PO 寄り | ストーリーと AC-What / AC-Rule が満たされているか |
| Interface | 外部影響 | API / イベント / DB スキーマの変更が他コンポーネントと矛盾していないか |
| How | 開発者 | パターン・テスタビリティ・パフォーマンス・セキュリティ |
AI セルフチェックは What/Rule と Code の整合性に使い、人間レビューは Interface/How にフォーカスする。Interface 層は AI が勝手に変更すると他チームへの影響が大きいため、特に注意が必要。
Interface 層の検出方法： openapi-diff で API 仕様変更を検出、buf breaking で Protobuf の後方互換性チェック、マイグレーションファイルの diff レビューなど。ツールがない場合は AC-H に「API 契約変更時は別途レビュー必須」と明記する。
仕様ドリフトの管理¶
実装中に「やっぱりこうした方がいい」が出てくるのは避けられない。AI で実装速度が上がるほど、仕様が実装に追い越されるケースは増える。これを禁止するのではなく、検知・吸収するルールを決めておく。
実装変更の 3 レベル¶
| レベル | 内容 | 対応 |
|---|---|---|
| 1 | 軽微な判断（AC の解釈範囲内） 例：文言の微調整、UI の並び順 | PBI コメントにメモ、PO が後で確認 |
| 2 | ビジネスロジックに影響（影響範囲小） 例：バリデーション条件追加、計算ロジック調整 | AC-Rule の更新を PR マージ前の必須条件にする |
| 3 | 外部契約・料金体系に影響 例：API 契約変更、課金ロジック変更 | PBI を分割し、新ストーリーとして事前に PO と合意 |
「レベル 2 以上は AC を更新してからマージ」を DoD に組み込むだけでも、仕様と実装の乖離はかなり減らせる。
スプリントレビューに仕様更新を含める¶
スプリントレビューで、実装された機能に加えて、更新された仕様（AC / スキーマ / ADR の変更点）も軽く振り返る。全変更を細かく見る必要はなく、「仕様が変わったポイントのトップ 3 を共有する」程度のライトな運用で十分。
スプリント運用の変化¶
スプリント期間の短縮という選択肢¶
2 週間スプリントが多かったのは、実装に時間がかかり 1 週間では意味のあるインクリメントを出せなかったからである。AI で実装速度が上がれば、1 週間スプリントも現実的になる。
フィードバックサイクルが速くなり、「作ったけど違った」の発見が早まる。ただし、AC の整備とレビュープロセスの効率化が先に必要。実装は速くなってもレビュー負荷や仕様ドリフト検知に時間がかかる場合、短縮は逆効果になる。「やるべき」ではなく「選択肢が増えた」と捉えるのが妥当。
見積もりの重要性が下がる可能性¶
従来、見積もりが重要だったのは実装がボトルネックだったからである。AI で実装速度が上がると、ボトルネックは「何を作るか」「作ったものが正しいか」の検証に移る可能性がある。
ただし AI の出力品質のばらつきは大きく、手戻りを含めると実装時間が減っていないチームも多い。見積もりが不要になるかはチームの AI 活用成熟度次第。見積もりに使っていた時間を AC の詳細化やスプリントゴールの明確化に振り向ける、という判断はあり得る。
時間の使い方のシフト¶
| 活動 | 従来 | AI 導入後 |
|---|---|---|
| 実装・コーディング | 多い | 減少 |
| 見積もり・プランニング | 一定 | 減少傾向 |
| AC・仕様の詳細化 | 少なめ | 増加 |
| レビュー・品質確認 | 一定 | 増加 |
| 仮説検証・フィードバック | 少なめ | 増加 |
投資先が「実装」から「仕様の明確化」と「検証」にシフトしている。
チームへの導入の進め方¶
いきなり「全ストーリーで Spec–Test–Code 整合性チェックをやります」は確実に反発される。
ロール別のメッセージ¶
PO 向け： 目的は仕様を重くすることではなく、期待と実装のズレを減らすこと。リワークが減り、AI で実装が速くなる分「何を作るか」の判断がより重要になる。
SM 向け： レビュー詰まりの一因が仕様の曖昧さなら、ストーリー / AC / DoD の見直しはプロセス改善そのもの。「ドキュメントを増やす」ではなく「レビュー時の悩みを前倒しで整理する」提案として伝える。
開発者向け： AI が仕様を書き換えたときの防波堤になる。AC / DoD / AI セルフチェックを整えておけば、「AI に騙されて変なコードを書いた人」扱いされにくい。自己防衛ラインとして機能する。
最小パターンから始める¶
| パターン | 内容 |
|---|---|
| 高リスクだけ | 課金 / 権限 / 外部 API 連携に限定して AC 分割＋AI セルフチェックを試す |
| 新規機能だけ | 既存改修には深追いせず、新規エピックから適用 |
| AI セルフチェックだけ | DoD に「AI による Spec–Code チェック実施」を 1 行追加するだけ |
| スプリント短縮を試す | 1〜2 スプリントだけ 1 週間を試し、AC の準備が追いつくか検証 |
段階的に導入すれば「プロセスが重くなった」という反発を抑えつつ、AI 活用のガードレールとして受け入れられやすくなる。
まとめ¶
AI コーディングが入ることで、スクラムの「最低限仕様＋対話で吸収」モデルにはひずみが出る。対応の方向性は 4 つ。
- AC の構造を変える — What / Rule / How(critical) に分解し、AI が勝手に決めそうな部分だけ明示する
- DoD に Spec–Code 整合性チェックを追加する — AI セルフチェックを PR 前に挟み、人間レビューの負荷を下げる
- 仕様ドリフトを管理する — 実装先行をレベル分けし、レベル 2 以上は AC 更新必須のルールを設ける
- スプリント運用を見直す — 期間の短縮、見積もりの軽量化、時間配分のシフトを検討する
高リスクストーリーや新規機能から段階的に始めれば、重いプロセスにならずに済む。
AI コーディングは実装速度を上げる一方で、仕様と実装のズレを検知しにくくする。そのギャップを埋めるガードレールとして、ストーリー / AC / DoD / スプリント運用のアップデートには検討の価値がある。
変わらないもの
説明責任を人が担うこと、スプリントゴール中心の運用、透明性・検査・適応というスクラムの根底にある価値観は、AI 時代でも不変。