AIスクラムチームのこれまでの軌跡
これまで10本のAIスクラムチームの記事を書いてきました。諸般の事情で途中からZennに投稿していたのですが、Qiitaから始まったAIスクラムチームはQiitaで終わらせようと思い、最終回としてこちらに投稿します。
これまでのAIスクラムチームの軌跡と総括、また今後の展望について記載します。
すべての始まり、AIスクラムチームの誕生
約3か月前にGitHub Copilotを用いて、AIエージェントだけでのスクラム開発の検証を始めました。試した各種プロンプトやスキル、エージェント設定や、AI作業の概要などを記載したAIスクラムチーム誕生回の記事です。
2026年2月のClaude Opus 4.6の登場や、GitHub Copilotの機能拡充に伴い、AIだけで人間の開発様式、つまり汎用的なスクラムフレームワークを実現できるのではないかと思い立ったのがきっかけでした。ふたを開けてみると、想像以上にAIチームは自律的に機能しました。今回の旅の最初の一歩です。
チームへのアドホックイベントの実施
AIスクラムチームがある程度きちんと開発をできることがわかったので、アドホックなイベントをチーム作業に差し込んでみたのがこのセキュリティ監査回になります。当然ではあるのですが、様々なセキュリティ監査の結果を、PBIや障害リストに記録し、きちんと対応していきました。ちなみにこのセキュリティ監査は単独での利用もできるので、もしよろしければご自身のプロジェクトにかけてみてください。その後も何度も使っていますが、とても良いです。かなり綿密に見てくれます。
(なお、この記事と前の記事のみQiita/Zennの両方に投稿しています。結果的に記事が分散し、SEO的にもよくなかったのかなと思って反省しています…)
チーム環境のクラウド化
当初私のローカルPC上のGitHub Copilot CLIを使っていたのですが、複数のAIエージェントが並列に開発を進める中でマシンスペックが足りなくなってしまいました。具体的にはTeamsやPowerPointがまともに動作しなくなってしまい、本業に悪影響を及ぼしだしたため実行環境をクラウドに移行してみました。
ただ、GitHub Agentic Workflow自体はとても素晴らしい仕組みなのですが、まだ安定しているとはとても言えない状況であったため、現在はクラウド上にVMを立てて、そこで実行するようにしています。とはいえ、スマホからGitHub経由でAIチームに指示を出す体験は、検証としてはとても面白いものでした。GitHub Agentic Workflowの今後の改善と安定化に期待です。
AIから人間へレビューする
自律的なAIチームの作業をどう確認するのかは、非常に重要なポイントです。最初から仕組みとして品質報告書を作成させるようにしていたのですが、通常の人間開発と同じようにお披露目レビュー会をAIに主催させられないか、ということで検証したのがこの記事になります。
生成AIの速度に依存はするものの、動きとしては人間のようにブラウザを操作しながら説明してくれる体験ができました。設計書の説明をさせる、などもできそうです。AI成果物の確認はクリティカルなテーマですので、人間からのレビューとともに、AIから人間へのレビューも有効かなという結果でした。
チームメンバーの増員
しばらく自律的に開発を進めていたAIスクラムチームですが、改善アクションとして品質関連作業が積みあがっていった結果、実際の機能開発が少なくなってしまうという問題が出てきました。当初開発者は2人だったので、どちらかが常に報告書の作成やテストなどをしている感じです。そこで、開発者を増員する対応をしたのがこの記事です。単純に開発者を増やすと計画やレビューなどの連携時間が増えてしまうため、開発だけスポットで支援するAIメンバーを追加しました。
結果設定次第では柔軟なメンバー増員が可能であることが検証でき、開発速度も上がりました。記事ではスポットの認識が私とAIで異なったためのドタバタ劇も記載しています。
AIの成果物をAIにレビューさせる
順調に開発していたAIスクラムチームですが、GitHub Copilotの標準設定変更に伴い、虚偽報告や手抜き作業が多数発覚しました。今回は設定変更による劣化でしたが、今後もモデルの変更や標準設定変更による劣化はあり得るため、プロセスとして、AIが作成した成果物をAIによってレビューさせる仕組みを導入した形です。
結果として虚偽や不正を防ぐことはもちろん、これまで以上に成果物の品質が安定しました。異なったAIモデルで相互にレビューさせる仕組みは、ある程度品質が求められる場面ではマストだと考えます。
AIに指示遵守を徹底させる
ハーネスの強化できちんと動くようになったAIチームですが、AIモデルの進化にともない、AIが勝手に指示を変える事態が発生しました。特に頭のいいモデルほどこれをやります。「指示にはこう書いてあるけども、この方が効率がいいからこうやる」みたいな流れです。ただし期待している動きと変わるためよろしくないケースも多々あります。そこでcopilot-instructionsなどに"指示を遵守"すること、などを記載したのですが、その指示すらも無視して作業をすることがありました。
そこで、人間の手法、唱和を取り入れてみました。作業の開始前にAIに「指示を遵守します」と発言させてから作業をさせたところ、指示無視がなんと体感ゼロになりました。
AIモデルの進化に伴い有効性が変わる可能性が高い手法ですが、どうにも指示に従ってくれない、みたいな状況があれば試してみて損はないかと思います。
AIチームのナレッジ・ノウハウを共有する
AIスクラムチームの開発も長期にわたり、その結果改善アクションなども大量に実施されるようになっていきました。AIチームは結局はテキストの指示（プロンプト、スキルなど）で構成されているため、この改善アクションなどのノウハウをテキストで横展開させられないかという試みです。元々改善アクションをためる仕組みはあったので、そこから実際の改善アクション・ノウハウを記載したのがこの記事になります。
AIチームが自律的に、「設計並走」「テスト先行」「3層CI」「git worktree」といった、人間の開発現場でもおなじみの手法を導入していきました。もちろん実際の業務観点で見れば、最初からこういったノウハウやルールはいれておくべきところです。ですが、AIスクラムチームはAIたちだけで、ほぼゼロの状態からこういった改善をしていくのだと見てもらえたらなと思います。
現実世界の環境をきちんと操作させる
AIによる相互レビューや、指示遵守をしてなお、実際の環境を触らないという安全機構と思われる動きが確認されました。AIチームが作ったタスクにクラウド環境作成や削除があっても、それを実行しないという動きです。
もともと人間が環境操作を依頼する場合は問題なく動くのですが、AIたちだけの作業サイクルの中で環境操作が出てくると途端に作業を回避します。そこで、AIたちに作業を実施するスキルを実行する前に人間が作業承認の旨一言添える形をとりました。結果きちんとクラウド環境を作成・削除・変更できるようになりました。（たまに人間が一言を忘れて作業を回避されたりすることはありましたが…^^;）
複数AIチームによる協業
AIスクラムチームは、現実では数か月ですが、AI世界では1年間相当の開発を継続してきました。そこで現実の開発体制を模倣し、3チーム体制を組んだ開発を検証したのがこの記事になります。
.NETのフロントエンド開発チーム、Java/PostgreSQLのバックエンド開発チーム、Azureインフラ基盤チームの3チーム体制を構成し、スプリント単位で各チーム間の情報共有や確認を行いながら開発を進めさせてみました。結果、現実世界で2日、AI世界で2週間後に、コード4万行、ドキュメントや補足資料を含めると50万行(!)のAzure上で実際に動くシステムがデプロイできました。
一方で人間側の認知負荷は非常に高いです。すごいスピードで作業をする3つのチームを見るのはつらいものがありました。また記事ではチーム連携の仕組みも最適化できてはいないのですが、動きとしてチームが協業することは検証できたかと思います。
AIスクラムチームの可能性
さまざまな検証、改善を繰り返してきたAIスクラムチームですが、現実の開発業務などで使うことはできるのでしょうか。私の答えは「NoよりのYes」です。条件付きではありますが、十分に実用の射程に入っていると感じています。
仕組みとしてスクラムを行いながら開発をできることは確認できておりますし、必要なガイドラインやルール・ポリシーがあれば、それを適用しながら開発を進められることは間違いありません。品質面はレビューや相互チェックの仕組みでかなり担保できるようになったため、むしろ残る論点は責任の所在です。そこさえクリアにできれば、実際に使えるものだと思います。
一方で、いくつかの課題・改善エリアが見えています。代表的なものは以下の通りです。
- 過剰、あるいは無駄なコミュニケーションコスト（トークン）の発生
- 人間と同様の時間ベースの作業見積もりがAIに適さない点
- コンテキストを共有できない複数作業を、単一AIが連続実施することによる精度劣化
- 補足資料などの成果物が、保管場所・命名規則ともに統一されない点（これはルールの設定次第ですが）
- 不要なAI同士の連携が多発し、時間がかかる点
- 擬人化はチーム構造の理解に役立つ一方、並行作業前提では人格付与が必須ではない点
特に気になるのはコストの観点です。人間の人件費に比べれば安いモノではありますが、不要な連携によりコストが増加し、それに合わせて時間がかかるところは正直無駄だと感じています。
そのため、既存スクラムをベースとしたAIならではのスクラムが必要になるのだろうと思っています。裏を返せば、ここはプロセスを設計し直す余地がまだ大きく残っているということでもあります。ちなみにレトロスペクティブを通じた改善は素晴らしいものであったので、繰り返しのループ構造をもつスクラムの仕組みをベースとするのは、かなり有効だと考えます。
AIスクラムチームの冒険はこれからだ！
素晴らしい開発、面白い検証をAIスクラムチームとともに実施してきました。その過程で、有効性と多数の課題の両方が見えてきたように思います。
記事を書いているちょうどそのタイミングでOpus 4.8が登場してきたように、AIの進化は今後も続きますし、GitHub Copilot側の改善も続きます。このままでも良い部分と、変えていくべき部分の両方が出てくることは間違いありません。
一方で、AIチームの必要性は間違いなく高まっていくと考えています。「現在の精度・ツールではここまでしかできない」というハードルも、現状のペースであれば半年～一年後には解消しているのではないでしょうか。
AIやツールの改善を継続的にウォッチしながら、AIならではのスクラム的なプロセスを考えていきつつ、AIスクラムチームの旅は一旦終了としたいと思います。これまで本作を含めて全11本のブログを読んでいただきありがとうございました。
それでは最後に、AIスクラムチームとともにお別れしたいと思います。
………「俺たちの冒険はこれからだっ！」
(第一部 完)