※ 本記事は2026年6月時点の情報をもとにしています。 GitHub Copilot code reviewやエージェントスキル、MCP連携などの機能は活発に更新されており(一部は public preview 段階)、AIの進化にともなって仕様・挙動・推奨設定が今後変わる可能性があります。実際に設定する際は、最新の公式ドキュメントもあわせてご確認ください。
はじめに
GitHub Copilot にコードレビューをやらせてみたものの、「指摘が浅い」「見てほしいところを見てくれない」「毎回ブレる」——そんな“イマイチ感”を抱えている人は多いのではないでしょうか。コーディング規約まで用意して食わせているのに精度が上がらない、と。
実はその原因の多くは、Copilot の使い方そのものにあります。しかも、よかれと思ってやっている工夫が、かえって逆効果になっていることも少なくありません。この記事では、Copilot のコードレビュー(およびレビュー用スキル)の精度を上げるための考え方と、具体的な見直しポイントを整理します。
まず知っておきたい大前提
Copilot code review は LLM ベースであり、本質的に非決定的です。同じコードでも毎回まったく同じ指摘が返るとは限らず、指示どおりに必ず動くわけでもありません。
ここで重要なのが、「すべての問題を漏れなく指摘して」「もっと正確に」といった網羅性を促す指示は、むしろ逆効果になるということ。GitHub の公式ガイドでも、こうした曖昧で一般的な指示はノイズになってモデルを混乱させると明言されています。Copilot はもともとその方向にチューニングされているため、「全部見て」と念押しするほど精度が下がりかねないのです。
つまり、「規約を全部詰め込んで漏れなくレビューさせる」というアプローチ自体が、性能を頭打ちにしている可能性が高い、ということです。
解決の鍵は「役割分担」
「漏れなく」を本当に担保したいなら、AI に全部やらせるのではなく、決定的に判定できるものはツールに任せるのが正解です。
- フォーマット、未使用変数、命名規則の形式的なチェック → Linter / フォーマッタ
- 型の不整合 → 型チェッカ
- 既知の脆弱性パターン → 静的解析(SAST)
こうした「機械が確実に判定できるもの」は CI で必ず落とすようにし、Copilot にはツールでは拾えない領域だけを担当させます。たとえば設計の妥当性、命名の意図、可読性、そして差分だけを見ても分からない文脈の理解——こうした“人間的な判断”こそが LLM の得意分野です。
規約の全項目を Copilot に丸投げするのではなく、「ツールでは見られない観点」に絞り込む。これだけで指摘の質はぐっと上がります。
精度を上げる具体的な見直しポイント
ここからは、レビュー用スキルや設定を具体的にどう直すかを見ていきます。
1. スキルの「発火条件(description)」を最優先で見直す
これはスキルを使ううえで最も多い“つまずき”です。SKILL.md は YAML フロントマターの name と description、そして本文で構成されており、Copilot は description を読んで「いつそのスキルを使うか」を判断します。
ここが曖昧だと、そもそもスキルが読み込まれず、汎用的なレビューに落ちてしまいます。「何に対して・どんなときに使うスキルなのか」を具体的に書きましょう。レビュー専用なら、ディレクトリ名を .github/skills/code-review/ のように“レビュー用”と分かる名前にしておくと、確実に読み込まれます。
2. 「常時ONの規約」と「詳細なスキル」を分ける
GitHub が推奨しているのは、役割で2つに分けることです。
- ほぼ全タスクに共通する単純な規約(コーディング標準など)→ 常時読み込まれる
.github/copilot-instructions.md - 込み入った手順・観点 → スキル
既存の規約をぜんぶ1つのスキルに詰め込んでいるなら、まずこの仕分けから始めると効果的です。
3. 言語別ルールはパス指定で切り出す
言語ごとのルールは、.github/instructions 配下の *.instructions.md に分け、applyTo フロントマターで対象を絞れます(例:applyTo: "**/*.ts")。全部を1ファイルに混ぜるより、関連するルールだけがレビュー時に適用されるので、精度・効率ともに上がります。
4. 中身は「短く・構造化・命令形」で
- 見出しと箇条書きで整理する
- 長い文章より、短い命令文(「X より Y を優先」)にする
- 良い例 / 悪い例のコードブロックを添える
長すぎる指示は挙動が不安定になります。目安として、1,000 行を超えるとブレやすく、4,000 文字を超えるなら削る方向で見直すとよい、とされています。
5. 効かない指示・ノイズになる指示を消す
次のような指示は Copilot code review では効かない、あるいはノイズになります。
- コメントの体裁・フォントの変更
- PR のマージをブロックさせる、といったレビュー以外の動作
- 外部リンク(Copilot はリンクを辿りません。必要な情報は本文に書き写す)
- 「正確に」「全部指摘して」のような曖昧な指示
また、1つのガイドラインに複数の意図を詰め込まないことも大切です。1ルール=1観点を心がけましょう。
さらに踏み込むなら:差分の外の文脈を渡す
レビューに必要な情報が、必ずしも差分の中にあるとは限りません。仕様や背景は別のツールにあることも多いはずです。最近のアップデート(public preview)では、こうした差分の外側にある文脈を MCP やエージェントスキル経由でレビューに持ち込めるようになりました。さらに、複雑な PR をより推論能力の高いモデルに回す分析ティアも追加されています。チーム全体でレビュー基準を揃えたい場合に有効です。
運用面のコツ
- PR は小さく分ける。 大きすぎる PR はコンテキストを超過し、精度が落ちます。
- 一度に完璧を狙わない。 小さく始めて、実際の指摘を見ながら反復的に改善するのが、結局いちばんの近道です。
なお、リポジトリ設定 UI の旧「coding guidelines」機能を使っている場合は、カスタムインストラクションへの移行にともない廃止予定なので、スキルや instructions ベースに寄せておくと安心です。
まとめ
Copilot のコードレビューを「漏れなく」に近づける鍵は、AI に全部やらせようとしないことです。
- 機械的に判定できるものは Linter や静的解析に任せ、CI で落とす
- Copilot には「ツールでは見られない観点」だけを任せる
- スキルの
description(発火条件)を具体的に書く - 常時ON の規約とスキルを分け、言語別はパス指定で切り出す
- 指示は短く構造化し、効かない指示・曖昧な指示は消す
LLM の非決定性は前提として受け入れたうえで、決定的なチェックはツールに、判断が必要な部分は AI に——この役割分担ができると、レビューはぐっと頼れるものになります。
※ 繰り返しになりますが、本記事は 2026 年 6 月時点の情報です。 Copilot のコードレビュー関連機能は今後も進化していくため、設定の前に最新の公式ドキュメントをご確認ください。