1. レビュー体制の限界とAIレビューへの期待
スパイダープラスでWeb開発を担当している高森です。
今回は、直近の開発フローの課題であった「コードレビュー工数の増大」を解決するために、AIレビューを本格導入し、開発体制をどう変革したかについてお話しします。
これまでの開発体制と課題
スパイダープラスのWeb開発チームでは、コードの品質を担保するため、Pull Request (以下PR) のレビューを必ず2名体制で行っていました。
この体制は品質を支えてきましたが、組織の成長や複数のプロダクト開発が同時に進行するにつれ、以下のような課題が顕在化しました。
- レビュアーの負担増大とボトルネック化：
- レビュアーの人数は変わらないが、同時進行するプロジェクトにより1日に数百行、1週間で何千行というPRレビューを実施するということが起こる。
- 開発者の負担が増大し、特に知見の多いシニアエンジニア層に負荷が集中。
- レビュー待ち時間が発生し、開発サイクルが遅延。
- 非効率なレビュー指摘の往復：
これらの対応が開発者の心理的負荷にもなっていました。
AI導入の検討
AIを活用してレビュアーの負担を減らせないかという議論は以前からあり、GitHub Copilotによるコードレビューを試したことはありましたが、当時は核心を突くレビューがなされているようには感じられず本格導入には至っていませんでした。
既存手法の限界に直面する中、品質担保と効率化の両立を求め、「AIコードレビューの本格導入」が検討の価値ありとなっていきました。
2. AIコードレビューの内容と運用
GitHub Copilot エージェント モードの活用
転機はあるシニアエンジニアがGitHub Copilot エージェント モードに目をつけてレビューを実施したことでした。
エージェント モードが本格的にリリースされて以降、コーディング支援にとどまらず、不具合の調査やレビュー依頼前のチェックなど、様々な活用を試みていましたが、この強力な機能をレビュアーの1人としても活用できる可能性を模索し、実際に運用に乗せるべく試行錯誤を重ねていきました。
| ステップ | 担当者/ツール | 役割とプロセス |
|---|---|---|
| 1. 開発 | エンジニア & AI | エージェント機能などを活用しコーディングを実施。 |
| 2. PR作成 | エンジニア | pushを行い、PRをテンプレートの状態で作成 |
| 3. AI一次レビュー | GitHub Copilot エージェント | エージェントにPRのテンプレートの「不足している箇所を埋める」よう指示。同時に、コード規約、潜在バグ、セキュリティ等の自動レビューを実施。 |
| 4. セルフレビュー | エンジニア | AIの指摘を受け、エンジニアがその指摘を判断・修正し、その履歴をPRコメントに残す。。 |
| 5. レビュー依頼 | エンジニア | 修正・確認が済んだら、AIレビューの内容を含めてレビュー結果として投稿し、人間のレビュアーに依頼。 |
| 6. 人間によるレビュー | 人間レビュアー (1名) | AIコードレビューの内容（指摘・修正履歴）を含めて確認し、設計やロジックなど、より文脈に依存したレビューと最終承認を行う。 |
運用プロセスとAIの役割
試験運用では「AIレビューと人間1名で品質が担保できるかどうか」を確認しました。このトライアルでAIが静的解析や規約チェックなどの一次レビューを高い精度で代替できることが確認できたため、Web開発チームでは、従来の「人間2名」から「AI + 人間1名」体制へと舵を切ることができました。
実際の開発・レビューフローは以下の通りです。
このフローで重要なのは、AIの指摘を鵜呑みにせず、エンジニアがセルフレビューで判断する工程を設けたことです。これにより、AIの弱点を補いつつ、PRを出す前の品質を大きく引き上げることができました。
AIの得意・不得意
AIレビューを運用する中で、その特性が明確になりました。
⭕ AIが得意なこと (一次レビュー領域)
- 単純なミス・規約チェック: typoや単純な構文チェック、命名規則、不要なコードなど、機械的かつ全体網羅的な指摘。
- 静的解析: 潜在的なバグやセキュリティの脆弱性の指摘。
- ドキュメント補完: PRテンプレートの記載漏れなど、情報の網羅性のチェック。
❌ AIが苦手なこと (文脈・設計領域)
- 設計意図の認識不足: 複雑なシステム構造や、既存処理をなぜこのPRで変更/流用しないのかといった設計意図に関わる部分の指摘。
- 重複提案: 既存の処理を無視して、同じ機能を持つコードを重複して生成・提案することがある。
- 全体最適の判断: プロダクト全体のパフォーマンスや、長期的な保守性を考慮したアドバイス。
3. AIコードレビュー導入による効果
AIコードレビューの導入効果
AIコードレビューの導入により、定量的な効果が明確に出ました。
また、人間レビュアーの負担が軽減したことは、単に時間の短縮以上の恩恵をもたらしました。
- 人間リソースの集中:
- 浮いた時間を、システムの設計・ロジックレビューや、新たな機能開発、技術的な負債の解消といった、人間にしかできない付加価値の高い作業に集中できるようになりました。
- 心理的ストレスの軽減:
- 「また同じような単純ミスを指摘しなくてはいけない」というレビュー側、「こんな初歩的なミスで指摘を受けた」という開発者側の双方の心理的ストレスが軽減されました。
さらに、期待していなかったポジティブな変化もありました。
- 抜け漏れ指摘による品質向上:
- 人間が見逃しがちな境界条件や、細かなセキュリティの抜け漏れをAIが指摘することで、最終的なコードの品質が底上げされました。
4. 今後の展望
現状のAIレビューがもたらす恩恵と限界
今回のAIコードレビュー導入は、Web開発チームに大きな恩恵をもたらしました。
- 工数削減と効率化: 単純な一次レビューをAIに任せることで、人間のレビュアーの工数を大幅に削減し、開発サイクルの遅延を防ぐことができました。
- 品質と集中力の向上: 人間は、システムの設計意図やビジネスロジック、全体最適に関わるレビューにリソースを集中できるようになり、結果としてコードの品質とレビュアーの満足度が向上しました。
しかし、この取り組みを通じて、AIレビューの限界についても明確に認識しています。それは「完全自動化は困難であり、人間による文脈レビューは不可欠である。」ということです。
AIは静的なコード解析や規約チェックには圧倒的な強さを発揮しますが、なぜそのコードが必要なのかという設計意図や、プロダクトの文脈、ビジネス要件を完全に理解することはできません。
AIがアウトプットした指摘に対する「最終的な判断」を下し、「なぜそうしたのか」という履歴を残すのは、常に人間である必要があります。
今後の展望
今回のAIレビュー導入を効率化の第一歩として、今後はAIの活用領域をさらに拡大し、開発文化全体を進化させていきたいと考えています。
- AIの活用領域拡大:
- コードレビューに留まらず、テストコードの自動生成支援や、PRの内容に基づいたドキュメントの自動更新など、開発プロセス全体でAI活用を模索しています。フローとして組み込めるように試行錯誤を続けていきます。
- 技術的負債の解消とAIフレンドリーな設計:
- 現在スパイダープラスでは技術的負債の解消を重点的に行っています。負債解消に伴って、AIがレビューしやすい、疎結合でモジュール化されたAIフレンドリーな設計を目指していければと考えています。
AIを信頼できないコードを生成すると思って避けていたこともありましたが、得意不得意を把握することで役割分担しながら開発に活かすことができるようになりました。
あくまでも人間の開発を強力にサポートする存在として活用し、効率を最大化できるように体制を整えていくことが重要だと思っています。
これからも、AIと人間が協力し、高品質かつ効率的な開発を実現する最良の方法を追求していきたいと思います。
ところで、スパイダープラスでは仲間を募集しています。こうした分野に関心のある方はぜひ生身の人間どうしお話しましょう！
