GitHub Copilotで書いたコード、レビューはどうしてる？

GitHub Copilotで書いたコード、レビューはどうしてる？
AI時代のコードレビュー最前線　〜AIにどこまで任せる？これからのコードレビューを考える〜
https://rosca.connpass.com/event/403621/

Transcript

1. GitHub Copilotで書いたコード、レビューは どうしてる？ AI時代のコードレビュー最前線 FutureOne株式会社 草場 友光
2. • ドラクエ大好き ドラクエ10のプレイ時間→ 1キャラ目：2716時間 2キャラ目：919時間 3キャラ目：801時間 4キャラ目：190時間(配信用) 自己紹介 • 2022/08-2027 Microsoft MVP (Microsoft Azure, Developer Technologies) • tomo_kusaba 第001462号
3. 注意 • 個人の見解・解釈が多分に入っています。 • 見解の相違・事実誤認などありましたらご指摘ください。
4. 今日の目的 • GitHub Copilot でコードを書く量が増えてくると、必ず聞かれ ることがあります。「そのコード、レビューはどうしてるんです か？」という質問です。 • Copilot は強力なツールである一方でミスをすることもあり、提 案は常に検証するべきです。 • 今回は、私が個人のテンプレートリポジトリで試している「AI に書 かせたコードを、AI 自身と人間でどう多層的にレビューするか」 という実践を整理します。
5. AIにコードを書かせっぱなしは。。。 • 最近のLLMの性能向上はめざましいものがある。 • だからといってAIはいつも完璧な実装するとは限らない。 • 同じプロンプトで同じ結果とは限らない。 • 何らかの方法でレビューは必要
6. DotnetTemplateでの 多層エージェントレビューの実践例 役割 書き込み 主な仕事 orchestrator なし 要求を整理し、どの専門レビューが必要かを振り分ける code writer あり 実装・テストの作成、指摘の反映 code reviewer なし 差分に対する一般的な観点でのレビュー accessibility checker なし ASP.NET Core UI 変更時のアクセシビリティ専門レビュー C# / .NET specialist なし 言語・フレームワーク固有の慣習やパフォーマンスの観点でのレ ビュー review checker なし 複数レビューの指摘を集約し、正当な指摘かどうかを精査する
7. Rubber duckレビュー • Agentレビューだけでは似たような前提でのAgent同士でのレ ビューで完結してしまう可能性がある。 • GitHub Copilot CLI・GitHub Copilot appの機能として実 装されている/rubber-duckコマンド • また、GitHub Copilot appでは 既定有効になっている。
8. モデルの多様性によるレビュー • Rubber-duckの仕組みがそうであるようにOpenAIのモデル を使って仕事をしていたら、Anthropicのモデルでレビューする • 同じ会社のモデルは癖の傾向が似る傾向にある。 • 違う会社のモデルにレビューさせた方がより違う角度からの指摘 が入る傾向がある。
9. Copilot code review • PR時にコードレビューする機能 • ここで指摘される項目は少なめですぐに収束する傾向 • プロジェクトの方針からずれる指摘事項もあるので注意
10. AIによるレビューの限界その1 • 局所的には良くても全体的な設計判断を間違える可能性 • 1つのクラスとしては妥当に見えても既存のクラス設計やモジュール分割 の方針とずれた設計になる可能性 • 差分だけを見ているとわかりにくくアーキテクチャ全体を知っている人間 の判断が必要 • 実装規模が大きいほど、要件の一部が漏れがち • 複数ファイルに渡る大きな実装、ソリューション全体にかかるような実装 では依頼した用件の一部が実装がから抜け落ちる • 動いているように見えるが、よく見ると用件のすべてを満たしていないこ ともある
11. AIによるレビューの限界その2 • 意図しない副作用に気づきにくい • グローバルな状態、キャッシュ、イベント発火のタイミングなどドメイン知識がないと気づ けない副作用は気づきにくい • AIのレビューでも見逃されがち • パフォーマンス改善の余地を見落とす • 単純なアルゴリズムであればAIはよく改善してくれます。 • 同じ処理ができるライブラリー間でのパフォーマンス差などの最適余地はやる・やらない を含めてシニアレベルのエンジニアでないとなかなか判断がしにくいところ • 特に、文字列処理(補完文字列でよいのか、StringBuilder使うのか、 ReadOnlySpan使うのか) • ただ、狭いスコープでのパフォーマンス改善をさせたらAIにはもはや人間は勝てない。
12. AIによるレビューの限界その3 • 古いライブラリーや非推奨のAPIを使ってしまう • 学習データの時期や参照した情報により古い書き方をしてくる場合があ ります。 • C#の場合は新しい文法が1年単位で入ってきます。 • 新しい文法の方がよりわかりやすくかけることが多いです。 • また、ライブラリーに関しても特にAIエージェント方面は移り変わりが激 しいです。 • このあたりは、人による判断が必要になってきます。
13. 人間によるレビュー 観点 機械的に拾えること 人間の文脈判断が必要なこと 構文・型 コンパイルエラー・型不整合・コーディング規約 (.editconfig) 不要 セキュリティ 既知の脆弱なパターン、シークレットの混入 業務要件に照らしたリスク許容の判断 テスト カバレッジ不足、アサーション欠如 テストシナリオが業務的に妥当か 設計 循環的複雑度、重複コードの検出 クラス分割・責務境界が将来の変更に耐えるか 要件充足・スコープ 差分とタスク記述の機械的な突合 大規模な変更で要件の一部が漏れていないかの確認 パフォーマンス 明白な N+1、同期 I/O のブロッキング 許容できる遅延かというビジネス上の判断 ライブラリ/API 既知の非推奨シグネチャの検出 移行の優先順位、影響範囲の見積もり 副作用 静的解析で拾える単純な副作用 ドメイン知識が必要な意図しない副作用
14. 4層のレビュー • 複数Agentによるレビュー • rubber-duckによるレビュー • Copilot code review • 人間によるレビュー
15. 責任 • AIがいくら高度化しても人がコミットしている 人が最終的にリリースしている以上その責任からは逃れられない • AIはなにか障害が起きたとき、損害が発生したときその主体には なり得ません。 • 最終的に人間が責任を負うことになるので、最後は人間がレ ビューまたはリファクタリングして「この変更をプロダクトに入れて 良い」という判断をするプロセスが必要と考えます。
16. まとめ • AIに任せきらず、多層的に確認をする仕組みを作ること。 • AIによる多角的なレビューそしてそこからどうしても漏れるとこ ろがあるので最後は人間によるレビューは必要。 • 現時点では、変更差分についてすべてのコードを確認していると ころです。 • ここは、AIによってコード量が増える中最も大変なところですが 最終責任を持つというところで必要なところと考えてます。
17. 宣伝
18. C# Kaigi 2026(9/19)
19. おしまい