はじめに
AIを副操縦士として使うだけなら、まだ人間が主担当です。
でも、AIエージェントに1タスク任せた瞬間、これまでと話は変わります。
必要になるのは「便利な使い方」ではありません。どこまで任せるか、どこで止めるか、どう品質を担保するかという設計です。
前編では、私たちの6人スクラムチームがAI活用をLv1（壁打ち）からLv2（副操縦士）へ進めるなかで、速さと信頼のねじれ、レビューコストの増大、仕様駆動開発への移行までを書きました。
前編はこちら：
この後編で扱うのは、その先のLv3です。AIを「副操縦士」ではなく「担当者」として迎えるなら、スクラムのどこを作り直す必要があるのかを整理します。
なお、この記事は「完成した設計」ではなく、現在検証中の設計と、その中で見えてきた問いを整理したものです。設計途中の論点や未解決の問いも含まれています。
この後編で扱うこと
- Lv3は、なぜLv2の延長では済まないのか
- 何をAIエージェントに任せて、何を任せないのか
- 委任を成立させるために、スクラムの運営にどんなガードレールが必要か
Part 1：Lv2とLv3の概念整理
Lv3は、Lv2の延長に見えて別物
Lv2までは、人間が主担当です。AIは横に座る副操縦士であり、仕様作成や実装やテストを一緒に進める相手です。
Lv3は違います。人間が要件を整理し完了条件を定め、仕様化から先をAIエージェントが自律的に進める状態です。つまり、Lv3の論点は「もっと賢いAIを使うこと」ではなく、人間の手をどう空け、その代わりに何を管理し直すかにあります。
Lv2とLv3の最大の違いは**「誰が作業主体か」**です。Lv2は人間が主体（AIは補助）、Lv3はエージェントが主体（人間は統制）という構造になります。
私たちがいま考えている役割分担は、ざっくり言うとこうです。
- 人間メンバー：アーキテクチャ判断、要件整理、受け入れ判断、最終承認を担う
- 副担当AI（Lv1/Lv2）：壁打ち、調査、個人作業の副操縦士として使う
- AIエージェント（Lv3）：仕様化、実装、テスト、ドキュメント更新などを委任されて動く
Lv3の狙いは、単に1人あたりの作業を速くすることではありません。人間の手を空け、並列に走る作業の本数を増やすことです。Lv2で頭打ちになった改善幅を、委任と並列化で突破できるか。それが次の勝負どころです。
Part 2：私たちが現在やっていること
※ここからは現在進行中の取り組みです
何を任せると伸び、何を任せると危ないか
「委任する」とは、タスクを丸投げすることではありません。文脈、制約、完了条件をセットで渡すことです。
私たちがすでに実践している仕様駆動開発のフローは、そのままLv3の土台になります。
その上でLv3（エージェント化）では、要件整理と完了条件の定義は人間が担い、仕様化から先をAIに委任する点が変更となります。
この委任原則は、Lv2運用を土台にしつつ、Lv3導入に向けて実験運用している暫定方針です。
現時点での委任原則はこうです。
- 委任してよいもの：要件と完了条件が明確で、テストで完了を確認できるタスク
- 委任しないもの：アーキテクチャの選択、ステークホルダー説明、価値判断を含む意思決定
- 慎重に判断するもの：既存コードへの大きな変更、セキュリティやパフォーマンスに影響するタスク
Lv2との一番大きな違いは、「AIがどこまで自律的に進めるか」です。Lv2は人間の手が空きません。Lv3は、人間が先に要件と完了条件を定義しておけば、仕様化以降の実装ループそのものはエージェントに回させられる可能性があります。
例えば、入力バリデーション追加のような局所改修をLv3方式で回すと、最小の流れは次のようになります。
- 人間が要件と完了条件を定義する（対象API、異常系、受け入れ条件）
- AIエージェントが仕様化し、テストケース作成から実装まで実行する
- 人間がレビューして受け入れ判断し、不整合があれば差分フィードバックする
- AIエージェントが修正を反映し、テストとドキュメント更新まで完了させる
Part 3：これから設計していること
※ここからは設計段階の話です
管理統制は、監視ではなくガードレール
AIエージェントで怖いのは、怠けることではありません。間違った方向に、迷いなく、しかも速く進めてしまうことです。
だから必要なのは、「ちゃんと見張ろう」ではなく、外れたときに止められる仕組みです。私たちがこれから整備しようとしているのは、次の4つです。
1. 委任ルールの文書化
どのタスクをエージェントに委任できるか、どんな制約を与えるかをチームルールとして文書化します。PBRやスプリントプランニングの段階で、「このタスクはエージェント主担当にできる」と判断できる状態を作るためです。
具体的には、ユーザーストーリーのDescriptionやAcceptance Criteriaに設計上の制約と受け入れ条件を明記することになります。Acceptance CriteriaをGherkin法などで書いているなら、そのまま委任条件として使える可能性があります。
2. Definition of Done の更新
AI生成コードを含む成果物には、追加のチェック項目が必要です。チームによって差が出る部分なので、まずは暫定ルールで回し、レトロで更新していくのが現実的だと思っています。
AIエージェントが主担当のタスクにおける DoD 追加項目（例）：
- [ ] 要件・完了条件・仕様との整合性が確認されている
- [ ] 人間のエンジニアがコードレビューを完了している
- [ ] テストカバレッジが既定の閾値を下回っていない
- [ ] アーキテクチャ上の選択理由が記録されている
- [ ] 既存のコードスタイル・規約と整合している
3. フィードバックループの設計
エージェントが詰まっている状態や、意図と違う方向に進んでいる状態を、人間が早期に検知できる仕組みが必要です。夜間でも動けるのがエージェントの強みですが、朝見たら盛大に逸脱していた、では困ります。
しかし最初はどのようにエージェントが間違えるのか、という知見がないため、一時的にこの困った状況を受け入れざるを得ないと考えます。
導入初期は、プルリクレビューを人間の手で重点的に実施し、共通する確認項目はサブエージェントやスキルで徐々に自動化し、エージェントが自律的に軌道修正を図る仕組みを作っていくのが現実的だと考えています。
4. スクラムイベントへの組み込み
エージェントを運用するなら、スクラムイベントにも入り口が必要です。
- スプリントプランニング：エージェント主担当タスクの識別と、レビューコスト込みの見積もり
- デイリースクラム：どのタスクを、どのエージェントが、どこまで進めているかの透明化
- スプリントレビュー：エージェント生成の成果物に対する品質評価
- レトロスペクティブ：委任がうまくいった条件、失敗した条件の振り返り
- リファインメント：委任可能にするためのユーザーストーリー整備
「有能だが厄介な新しいチームメンバー」として扱う
私たちのチームは Azure DevOps でタスク管理とバックログ管理をしています。エージェントを本当にチームメンバーとして扱うなら、タスクボードへの組み込み方という実務的な問いが避けられません。
AIエージェントは、ある種「有能だが厄介な新しいチームメンバー」です。
- 与えられたタスクを勤勉にこなし、24時間でも動ける
- しかし、「できない」とは自己申告しにくい
- 意図しないやり方で問題を解こうとすることがある
- タスクボードは読めても、他メンバーと自然に相談はしない
人間なら、途中で違和感を口にしたり、横に相談したりできます。AIエージェントはそこが弱い。だから、黙って走り続ける前提で設計する必要があります。
もうひとつ気になっているのが、振り返りの設計です。人間の作業には文脈や迷いがあります。なぜその実装を選んだか、どこで悩んだか、という語られなかった履歴がレトロスペクティブを豊かにします。AIエージェントにはその側面が薄い。
エージェントにどう振り返らせ、次のスプリントの改善につなげるか。これはまだ、やってみないとわからない論点です。
まだ答えが出ていない問い
※ここからはまだ答えが出ていない問いです
Lv3への移行にあたって、私たちにはまだ答えが出ていない問いがいくつかあります。
- エージェントの「ベロシティ」をどう計測するか。人間の開発速度と同じ単位で語るべきなのか
- Azure DevOps のタスクボード上で、エージェントの状態と進捗をどう可視化するか
- エージェントが積み上げた技術的負債を、どのタイミングで誰が検知して対処するか
- 委任が増えることで、人間メンバーのエンジニアリングスキルはどう変化するか
- 「エージェントに任せてよかった」と「やっぱり人間がやるべきだった」の判断基準をどう作るか
- エージェントに「振り返り」に相当する仕組みを設計できるか
これらは、机上で答えを出し切るより、実際に試しながら詰めていくしかないと思っています。
おわりに
前編の結論は、AI導入で最初に必要になったのは個人技よりチームのルールだった、ということでした。
後編の結論は、その先でAIを「担当者」にするなら、話はツール導入では終わらず、チーム運営そのものの設計になる、ということです。
スクラムガイドの拡張パック「AI and Scrum」なども参考にしつつ、チームに合った方法を探さなくてはいけません。
委任ルール、DoD、タスクボード、スクラムイベントでの透明化。ここを作らずにLv3へ進むと、たぶん「速いけれど制御できない」状態になります。
次スプリントで試す最小セット
まずは次の3点から始めるのが現実的です。
- リファインメントで4軸判定し、スプリントプランニング前に委任ルールを1ページで確定する（PO+開発メンバー）
- レトロスペクティブでDoD追加5項目を見直し、次スプリント開始時に適用する（チーム全体）
- デイリースクラムなど日次で実行ログを確認し、逸脱があれば当日中に介入する（担当開発者）
2026年度は、このあたりの仮説検証を進め、結果をまた共有したいと思います。
参考資料
- Agile Manifesto — Beck, Fowler, Sutherland ほか17名（2001年）
- Scrum Guide 2020 — Ken Schwaber & Jeff Sutherland
- AI and Scrum — Scrum Guide Expansion Pack v2026.1 — Ralph Jocham & Jeff Sutherland（CC BY-NC-ND 4.0）
- TDD, AI agents and coding with Kent Beck — The Pragmatic Engineer（2025年6月）
- The Future of Software Engineering with AI: Six Predictions — The Pragmatic Engineer（2026年2月）