検索
連載

「セルフレビュー時間大幅短縮」　GitHub Copilotコードレビュー、“組織全体”で成果を出すには？：＠IT Techブログ PickUp（TISインテックグループ編）

AIによるコーディングが当たり前になる中、有識者によるコードレビューや細かな指摘に時間を取られていませんか。本稿は、GitHub Copilotを開発者自身のセルフレビューに活用することで、セルフレビュー品質を高め、有識者の稼働集中を和らげる取り組みを紹介します。さらに、組織全体の効率化に向けた施策として、コードレビュー用プロンプトの整備や共有・再利用の工夫にも踏み込みます。

Share
Tweet
LINE
Hatena

注目のテックブログから「現場の知恵」をあなたに――

各社のエンジニアが発信する「テックブログ」。その熱量を＠IT編集部がピックアップ。 生成AI前提時代に向けて環境が激変する中、“隣のエンジニア”は何を感じ、何を考え、どうアクションしているのか？――試行錯誤のプロセス、成功の鍵、変化に立ち向かうマインドなど現場のリアル、ナレッジを凝縮してお届けします。


本稿はTISインテックグループが運営する、開発現場から生まれた技術ノウハウを公開するサイト「Fintan」上で2025年1月28日に掲載した記事を転載するものです。そのため、用字用語の統一ルールなどが、＠ITのものと異なります。ご了承ください。


「＠IT Techブログ PickUp（TISインテックグループ編）」のインデックス

連載目次

本稿のポイント

  • GitHub Copilotのコードレビュー活用により、開発者のセルフレビュー時間を大幅に短縮し、品質向上を実現。
  • 独自開発したVisual Studio Codeの拡張機能「Promptis」とレビュープロンプトの整備により、組織全体での効率的な活用を推進。
  • 人間の適切な関与を維持しながら、AIツールを補助的に活用することで、コードレビューのプロセス全体を最適化。

GitHub Copilot Chatでコードをセルフレビュー

　GitHub Copilot Chatに自然言語で記述されたレビューチェックリストを入力することで、コードの改善点の有無を即座に得ることができます。ルールベースのチェックでは拾いづらい抽象表現でのレビューが可能です。

抽象表現でのコードレビュー例

　コードレビューに使用するプロンプト例および、GitHub Copilot Chatでコードレビューを行った出力例を以下に示します。

コードレビュープロンプト

コードを評価し、結果をmarkdown表形式で示す。表以外は表示しないこと。
表に続けて、結果が×,△のものに対して改善案を示して。
## 表
観点、結果(○,×,△,-)、指摘
## チェック観点
・各モジュール・クラス・関数は単一責任の原則に従っているか
・大きすぎる関数やクラスは適切に分割されているか
・継承の深さは適切か、不必要な継承を避けているか
・コードの重複を避け、DRYの原則を順守しているか
・命名規則はPEP8に準拠し、わかりやすいか
・ファイル構造は論理的で整理されているか

コードレビュー結果例


AIコードレビュー結果（サンプル）

AIコードレビューの利点：開発者ローカルで行える

　GitHub Copilot Chatを用いたAIコードレビューは開発者環境で行うことができます。

　既存の静的解析ツールに加えて、抽象表現での開発者自身のセルフレビューにより、コード品質が向上します。

AIコードレビューの導入メリット

　AIコードレビュー導入前後を比較して、導入メリットをみていきましょう。

【1】レビュー時間と労力を節約

　第一に、開発者自身のセルフレビューの一部が代替され、作業負担が減ります。

　AIコードレビューの導入前のセルフレビューが約60分とすると、導入後は約10分程度まで短縮可能です。

【2】開発者のセルフレビュー品質の向上

　AIコードレビューは、24時間365日即座にフィードバック可能です。開発途中段階でこまめにチェック可能で、迅速なフィードバックループが確立できます。また、一貫性のある評価基準での分析が可能で、見落としやすい細かい問題も検出可能です。特に、非機能観点のコード品質向上に著しい効果があります。

　開発者の時間の21%はバグ修正に費やされており[1]、本番環境でのバグ発見時の修正は10倍のコストが発生すると仮定すると[2]、バグの早期発見による生産性効果は大きいです。


バグの早期発見による生産性効果の試算例

【3】有識者のレビュー作業負担の軽減・役割の変化

　大規模開発では、新規着任者、ジュニアのエンジニアを含む複数名が並行して製造を行います。

　AIコードレビューの導入前は、コード品質の均一化のために有識者レビュー時間の大半が費やされるのが実情でした。命名規則の統一やコードの可読性など、機能品質以外のレビュー指摘も多く検出されます。有識者の稼働が集中し、レビュー待ち→レビュー→修正→再レビューのサイクルが長期化する傾向がありました。

　AIコードレビューの導入後は、開発者のセルフレビュー品質が向上したことにより有識者レビューの負担が軽減されました。

　有識者の負担が軽減されることによって、有識者(人間)によるコードレビューの質も向上します。コード品質の最終チェックに集中でき、アーキテクチャ評価や戦略的判断により多くの時間を確保可能になります。

AIコードアシスタントとの付き合い方

　AIコードレビューを使いこなすにあたり、注意すべき点もあります。

AIコードレビューの注意点

　AIコードレビューの注意点を以下にまとめます。

  • AIはビジネスロジックの理解が限定的
  • 一般的でないチーム特有の個別方針や特殊な要件への対応は限定的
  • 出力の一貫性を保つには、プロンプトの工夫が必要
  • 組織全体で活用可能なプロンプトの共有と再利用がキーとなる

　これらの注意点に対しては、組織的な対策を講じることでAIコードレビューの効果を最大化することができると考えます。

人間の関与(Human in the Loop)の重要性

　AIのコード提案を主体ではなく補助的なツールとして位置づけることは重要です[3]。特にクリーンで重複のない効率的なコードとなっているかを意識し、コードの提案を受け入れる場合は、後のコードレビューをセットで行います。

　コード品質の判断はAI任せにするのでなく、人間（有識者）によるレビュー品質をいかに高めるかという観点でAIを扱うことが肝要です。その点で後述するコードレビュープロンプトの整備が有効となります。

「組織全体の効率化」に向けた施策

　TISでは、AIコードレビューの生産性効果の最大化に向けてふたつの施策を展開しています。

１. コマンド簡単呼び出し

　GitHub Copilotを用いた独自ツールを開発し、Visual Studio Code（VS Code）エクステンション「Promptis」として公開しています。

　このツールは事前に用意したレビュー用プロンプトをコマンド一発で呼び出し、連続実行を可能とします。

　人間が行う操作はワンタッチで、100以上のコードのレビューのチェック項目を数分で終わらせることができます。

　複数のレビュー対象ファイルを順に読み込んで、一括してレビューすることもできます。

　このツールはすでに実践導入されていて、高い生産性効果と品質効果を出しています。


複数のReactコードファイルを、一回のコマンド実行で連続レビューさせている

Tips

　GitHub CopilotとPromptisを活用したAIコードレビューに関連する記事として、下記もよろしければご覧ください。

インフラコードに対するAIコードレビュー：GitHub CopilotとPromptisの活用


２. コードレビュー用プロンプトの整備

　TISの開発で使用されることが多い主要なプログラミング言語・アプリケーションフレームワークに適したレビュー用のプロンプトを整備し、AIコードレビューで呼び出しやすい形式（mdファイル）にして配布しています。プロンプトは、AIのレビュー品質の揺らぎを減らすための記述方法に統一しています。

　また、AIによるコードレビュー精度を上げるにはレビュー用のプロンプトファイルは細かく分けた方がベターです。TISでは、プログラミング言語・アプリケーションフレームワーク別、コンポーネント別、レビュー観点別の複数のコードレビュープロンプトを順次拡充しています。

まとめ

　本稿では、TISにおけるGitHub Copilotを用いたAIによるコードレビューの活用についてご紹介しました。

　AIによるコードレビューは人間のチェックを完全に代替するものではありません。また、組織としての最適なレビュープロセスの整備自体は、AIが解決してくれるものではありません。AIコードアシスタントのメリットを最大限享受するには、AI利用の注意点を認識し、AIツール利用を含む開発プロセスそのものを適切にコントロールすることが必要です。

参考資料

  1. Stecklein, Jonette M., Dabney, Jim, Dick, Brandon, Haskins, Bill, Lovell, Randy, Moroney, Gregory. “Error Cost Escalation Through the Project Life Cycle“. NASA Technical Reports Server (NTRS). 2004年6月19日 (参照 2025-01-27).
  2. Eick, Stephen G., Graves, Todd L., Karr, Alan F., Marron, J. S., Mockus, Audris. “Does Code Decay? Assessing the Evidence from Change Management Data“. IEEE Transactions on Software Engineering. 1999年 (参照 2025-01-27).
  3. Thoughtworks. “Technology Radar Vol 31“. Thoughtworks Technology Radar. 2024年10月 (参照 2025-01-27).

元ブログもチェック！

元記事はコチラ。ぜひチェックしてみてください！


Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る