pull request のライフサイクル全体で GitHub Copilot コードレビューを活用する

Copilotコード レビュー のための、ドラフト プル リクエストからマージまでの再現可能なワークフローを構築します。

この記事で

はじめに

Copilotコード レビュー は、プル要求ワークフローの一部として使用する場合に最も効果的です。 このチュートリアルでは、手動レビューと自動レビューのどちらを選択するか、下書きプル要求の早期にレビューを要求し、マージ前に再レビューをトリガーするタイミングを決定する方法について説明します。

また、カスタマイズ、スキル、MCP サーバー、ランナー オプションを使用して、ニーズに合わせて Copilotのレビューを調整するタイミングについても学習します。

プル リクエストのライフサイクルに沿って作業する

レビュー モデルを選択し、ドラフトとアクティブなプル要求の早期フィードバックを設定します。

チームに適したレビュー モデルを選択する

Copilotコード レビュー は、プル要求のライフサイクル内の 1 つ以上のポイントで手動で実行するか、自分でトリガーするか、または自動的に実行できます。 手動レビューを使用すると、 Copilotコード レビュー の重み付けを正確に制御できます。 自動レビューにより一貫したレビュー範囲を確保でき、オープン時、ドラフト時、または新しいプッシュのたびに実行するかどうかを選択できます。

モデルの確認最適な用途なぜでしょうか
手動レビュー要求文脈依存度の高い変更、または選択的な使用
Copilotは、別のパースペクティブが必要な場合にのみトリガーできます。
オープンなプル リクエストの自動レビュー幅広く一貫した対応を求めるチームすべてのプル要求は、個々の習慣に頼ることなくベースライン フィードバックを受け取ります。
ドラフト プル リクエストの自動レビューより早いフィードバック ループを必要とするチーム作成者は、人間によるレビューを開始する前に問題を修正できます。
新規プッシュ時の自動レビュー複数回の改訂を伴う変化の速いプルリクエスト
Copilot は、プル リクエストの変化に応じて大幅な更新を再評価します。

セットアップ手順については、 GitHub Copilot を使ったコードレビュー と GitHub Copilotによる自動コード レビューの構成 を参照してください。

ドラフトプルリクエストの早い段階で Copilotコード レビュー を使用する

Copilotコード レビューを使用して下書きプル要求を確認すると、チームにレビューを要求する前に、コードを早期に信頼できるチェックを行うことができます。

便利な下書きワークフローは次のとおりです。

  1. 下書きとして pull request を開きます。
  2. Copilotコード レビューの下の**** からレビューを要求するか、下書きプル要求の自動レビューを有効にします。
  3. 正確性、セキュリティ、明確な保守容易性の問題など、信頼度の高いフィードバックに最初に対処します。
  4. 更新をプッシュし、主要なコメントが解決されたことを確認します。
  5. pull request を人間のレビューの準備ができているとマークします。

このアプローチにより、チームは、以前にキャッチされた可能性のある明らかな問題ではなく、設計のトレードオフと製品への影響について、より多くの人間のレビュー時間を費やすことができます。

レビューの品質を調整する

再レビューを要求するタイミングと、カスタマイズ、外部コンテキスト、ランナーが付加価値を追加する場所を決定することで、レビューの品質を向上させます。

マージ前に再レビューを使用する

大幅な変更の後、以前のフィードバックに対処しながら、新しいリスクが導入されたかどうかを確認するための再レビューを要求します。

次の場合に再レビューを要求します。

  • サービスまたはパッケージの境界を越えて複数のファイルを更新します。
  • セキュリティ依存またはデータ依存の動作を変更します。
  • 提案された変更の大規模なバッチを適用し、最終的なパスを必要とします。

アクティブなプル要求を頻繁に更新するチームの場合、新しいプッシュで自動レビューを有効にすると、フィードバックを最新の状態に保ちながら手動の再レビュー要求を減らすことができます。

カスタマイズをワークフローに合わせる

カスタマイズは、各ファイルの種類がワークフローのレビュー決定ポイントをサポートする場合に最も役立ちます。

  • ほとんどのプル要求に適用する必要があるリポジトリ全体のレビューの期待に対しては、 .github/copilot-instructions.md を使用します。
  • コードベースのさまざまな部分に異なる標準がある場合は、エージェント固有のガイダンスとパス固有のガイダンスに .github/instructions/**/*.instructions.md を使用します。
  • AGENTS.mdを使用して、意図的なパターン、アーキテクチャの境界、レビューの優先順位など、関連性を向上させるリポジトリ コンテキストを提供します。

これらのファイルは、プル要求中にレビュー担当者が決定する必要のある内容に焦点を当てたままにしておきます。 完全なエンジニアリング ハンドブックに変換しないでください。

カスタマイズのしくみと例の詳細については、 カスタム命令を使用してCopilotのコードレビュー機能を引き出す を参照してください。

エージェント スキルと MCP サーバーを使用して、特別なレビュー目標を達成する

エージェントのスキルと MCP サーバーは、チームが組織固有のコンテキストに依存するレビューを必要とする場合に最も価値があります。

再利用可能なレビュー ルーチンが必要な場合は、エージェント スキルを使用します。次に例を示します。

  • 移行プル要求に標準チェックリストを適用する。
  • モノレポで言語別またはフレームワーク別のレビュー工程を実行する。
  • 承認や課金ロジックなど、特定のリスク領域の優先順位付け。

レビューがプル要求自体の外部でコンテキストを参照する必要がある場合は、MCP サーバーを使用します。次に例を示します。

  • プル要求の変更を問題、インシデント、またはサービスの所有権データにリンクします。
  • 内部システムからの予想されるロールアウトまたは運用コンテキストの確認。
  • 外部ドキュメント ソースに対する実装の詳細の検証。

セットアップの詳細については、 GitHub Copilot のスキルを追加する と リポジトリの MCP サーバーを構成する を参照してください。

セルフホステッド ランナーが必要かどうかを決定する

多くの場合、GitHub には標準の Copilotコード レビュー ホステッド ランナーで十分であり、セットアップは不要です。これらはデフォルトで設定されています。

必要に応じ、セルフホステッド ランナーまたはより大きいランナーを検討してください。

  • レビュー ワークロードの負荷が高い場合のパフォーマンスが向上します。
  • 組織で必要な内部システムへのネットワーク アクセス。

Copilotコード レビューは、より深いコンテキスト収集やツール呼び出しなどのエージェント操作にGitHub Actionsを使用するため、ランナーが必要です。 GitHub でホストされるランナーを利用できず、サポートされているセルフホスト オプションがどれも正しく構成されていない場合、レビューはより制限の多いモードで実行されます。

計画とセットアップの詳細については、 AUTOTITLE を参照してください。

チーム のシナリオ推奨されるワークフロー
頻繁にプル要求を行う小規模なチームすべてのプル要求に対して自動レビューを有効にし、早期フィードバックの下書きを確認し、変更が大きい場合はマージ前に手動で再レビューを使用します。
複数の技術スタックが混在する大規模なモノレポ自動レビューを有効にし、新しいプッシュをレビューし、各主要領域にパスごとの指示を追加し、繰り返し発生するレビュー パターンにはスキルを使用します。
セキュリティに依存するコードベースまたは規制されたコードベース下書きの pull request レビューと、マージ前に必要な再レビューを使用し、リポジトリ全体のセキュリティの期待を.github/copilot-instructions.mdに保ち、GitHubの外部に格納されているインシデントまたはコンプライアンス コンテキストに MCP サーバーを使用します。
内部プラットフォームの依存関係を持つチーム自動レビューから始めて、セルフホステッド ランナーと MCP コンテキストを追加するのは、有用なレビュー フィードバックに内部システム アクセスが必要な場合のみです。

次のステップ