1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

copilotに指定のルールを元にコードレビューをしてもらう(実装中)

1
Last updated at Posted at 2025-08-22

もくじ
https://tera1707.com/entry/2022/02/06/144447

やりたいこと

github copilotに、自分の書いたコード(今書いているコード)をレビューしてもらいたい。

また、部署指定のコーディングルールがあるので、そのルールに従っているかどうかという観点でcopilotにレビューをしてほしい。

と思っていろいろやったが、なかなかうまくいかなかった。

あれこれ試して、いろいろ妥協して、少々面倒さが残るがこれならとりあえず使えるかな?というラインにたどり着いたかなと思ったので、その時の成果物とやり方をメモしたい。

前提

  • 2025/08/23に実験実施
  • VSCode 1.103.2 使用
  • C#コードをレビュー対象とした

成果物

この「.github」フォルダ内が成果物一式。

以前自分で作成したツールのコードをレビューさせる感じにした。

構成はこうなっている。
中身は、右側に書いた通り。

.githubフォルダ
│  CodingGuidelineCs.md         ← コーディングルール(ルールの中身は適当)
│  copilot-instructions.md        ← copilotへの前提inputファイル 
│  readme.md                ← 作ったものの説明ファイル
└─promptsフォルダ
        PleaseReviewThisFileAll.prompt.md ← チャット入力定型文プロンプト1
        ThisIsOurCodingRule.prompt.md   ← チャット入力定型文プロンプト2

copilot-instructions.mdは、以前こちらで調べた、githubにあらかじめいろいろ指示しておくためのファイル。

また、2つのxxxxxxxxx.prompt.mdは、以前こちらで調べた、copilotでチャットで指示する際の定型文のようなもの。

この辺を組み合わせて、なんとか楽してレビューをしてもらうようにする。

今回の「レビュー」とは?

レビューというと、

  • コードを書きながら、今書いた部分が正しいかどうかをレビューしてもらう
  • 担当分のPRを出したコード(≒1機能分?)をすべてまるっとレビューしてもらう

があるのかなと思うが、今回は前者の「コードを書きながらレビューしてもらう」を試すこととする。

※まるっとレビューしてもらう方式は、難しそうなので別途いずれやってみる。

手順

成果物の中にあるreadme.mdの内容だが、こういう手順なら、安定してレビューしてもらえている。

# Copilotを使ったレビューをするときの手順

## コーディングルールやガイドラインがある場合

slnファイルがあるフォルダに、「.github」フォルダをコピーする。

VSCodeの「フォルダを開く」で、slnファイルがあるフォルダを開く。

コーディングルールやガイドラインのファイルを、VSCodeエディタで開く。  
(サンプルとして.githubフォルダの中の「CodingGuidelineCs.md」を置いているので、そのファイルを開く)

チャット欄に「このファイル全体が私たちのコーディングルールです。すべて読み込んでください。」と指示する。  
(チャット欄で「/」を入力し、出てきたプロンプト候補から「ThisIsOurCodingRule」を選んでEnterを押してもOK)

レビュー対象のC#コードをエディタで開く。

チャット欄に「このC#のコードファイルの全体をコードレビューしてください。」と指示する。
(チャット欄で「/」を入力し、出てきたプロンプト候補から「PleaseReviewThisFileAll」を選んでEnterを押してもOK)

指定のルールで、レビューが行われる。  

## コーディングルールやガイドラインがない場合

レビュー対象のC#コードをエディタで開き、チャット欄に「このC#のコードファイルの全体をコードレビューしてください。」と指示する。


## その他

copilot-instructions.md に、レビューするときの振る舞いを指定している。  

Copilotがレビューする際の前提を変えたいなどある場合は、ここを編集してもよい。

上記の手順にした流れ/経緯

あらかじめルールを読み込ませておく、がどうしても出来なかった

copilot-instructions.mdに、「コードレビューをするときは、xxxxxフォルダにある「CodingGuidelineCs.md」を予め読み込んでからレビューすること」などと書いて、毎回ルールを読み込まなくてもよいようにしたかったが、どうしても「あらかじめ読んでおく」ことができなかった。

公式にも、そのように書かれていたので、現状どうしようもないのだと思われる。

このページによると、下のような指示を書いてもうまくいかないらしい。

image.png

なので一旦あきらめた。

ルールをどうやって読み込ませるか?

ルールをどうやって読み込ませるかをいろいろ試したところ、結局

ルールのmdファイルをvscodeエディタで開いた状態で「これがルールです。全部読み込んでください」

と指示する、が一番安定していた。

他にも、チャット欄で、ルール.mdのファイルパスをしていて「<ファイルパス>がルールなので、読み込んでください」などを試したが、うまくいくときもあるが、うまくいかないときの方が多かった。

チャット欄で「〇〇のファイルを読み込んでください」とか「http:www.xxxxxxを読んでください」的な指示は、うまくいくときもあるがうまくいかないときの方が多かった気がする。

これも上の公式にあったうまくいかない指示の中の「外部リソースを参照する要求はうまくいかない」に該当するのかもしれない。

※私の指示の仕方がまずいだけな可能性も大きいのだが、私がうまくできない時点で「安定して実施できる」ではないかな。。。

レビュー対象をどうやって指定するか?

これも、vscodeで開いた.csファイルを、

  • vscodeで開いたフォルダからの相対パスで指定
  • 絶対パスで指定
  • xxxx.csという名前だけで指定

などやってみたが、どうにもうまくいかない。
(ファイルが見つかりません、と言われる)

で、結局、「今開いているファイルをレビューして」が一番安定していた。

うまく意図通りにいったのかいってないのかがわかりにくい

これが一番問題だと思うのだが、

レビュー対象をうまく指定できなかったときは、「ファイルがみつからない」と言ってレビューできないからまだいいのだが、「ルールを〇〇.mdから読んでください」と言ってからレビューしてもらうと、「〇〇.mdをルールとして読み込みました。そのルールをもとにレビューします」的なことをいうにもかかわらず、ルールには載っていない、一般的なベストプラクティス的な内容でレビューしているように見えるときが度々あった。

これも、実はルールは読み込めててルール違反はないが、一般的ベストプラクティス的にはおかしいのでそっちを指摘してくれてる、という可能性もあるが、それがそうなのか、実はやっぱりルールを読み込めてないだけなのかが判別できない。
(ルールのファイルをちゃんと読み込めてますか?というと、読み込めてるよ、と言うが、本当かどうかわからない...)

最後まで、ある程度疑わずにはいられなかった

最終的に、私の感触としては、

coppilotを100%信用して、丸ごとレビューさせることは無理だ、
信用度50%で、残り半分はcopilotの言ってることが本当かどうか確かめながら進めるしかない。
適切に疑ってみてあげられる範囲は、1メソッド~1ファイルの範囲だな。
つまり、今コードを書きたての、開いてるこのファイル~今見えてるこのメソッドの範囲だな。

となった。
(プロジェクトやソリューション全部をレビューしたよ、結果はこれだよ、と言われても、本当かどうか、私には一度に確認する自信がない)

補足(レビュー対象の指定あれこれ)

上の手順では、
copilotにレビュー対象を指定する際、vscodeでそのファイルを開いて「このファイルをレビューして」と言っているが、エディタ上でカーソルを置いていたり、範囲選択している場所を「ここをレビューして」と指定することもできる。

局所的に、書き方がこれでいいのかどうかを聞きたいときは、そのやり方がよさそう。

補足2(copiplotにレビューのためのルールを指定する意味はあるか?)

ここまで、copilotに部署のコーディングルールでレビューをしてもらう、を調べたのだが、果たして部署のルールで、という縛りをすることが正しいか?と途中で疑問を抱いた。

ルールは時間経過で古くなりがちで、かつそのルールを作った人のスキルや指向(好み)にも左右されるイメージがある。

それに対して、ルールを指定しなければ、copilotはたぶん今現在の新しいルールで、特定の個人の指向ではない、世間一般で間違いない基準でレビューしてくれているのだと思う。

そこをあえて「部署ルール」で縛る必要あるか?

特殊な事情で「ウチではこう書かねばならない」という避けらない事情はありうるが、よっぽどの事情でない限り、縛る必要ないなと感じた。(つまり、copilotがレビューするなら、部署固有のルール自体いらない、もあり得るかも?)

※「ルール」には、ルールを守ることで、技術が未熟な人を半強制的に一定のレベルまで引き上げるという役目もあると思うので「ルールがない」は無理かもだが、レビューするうえであえて「copilotにそのルールを強制する」必要はない気がした。

補足3(アーキテクチャや設計の話をするのはGithubCopilotよりWindowsCopilotの方がいい?)

ここでいうwindows coppilotはコレのこと。

image.png

github copilotはコレのこと。

image.png

Windows Copilotに、github copilotとwindows copilotはどう違うのかを聞いたところ、こういっていた。

image.png

本当かどうか?わからないが、個人の感触としては、本当な感じもしている。

AI間の得手不得手がどうというのはおいておくとして、

1ファイル~1メソッドの範囲の「コードレビュー」くらいが、github copilotにさせるレビューの適正範囲で、それ以上の設計レベルの話は別でやったほうがよいのかな?と思った。(検証はできてません)

参考

copilot-instructions.md

プロンプト.md

「あらかじめ読んでおく」はうまくいかないよという公式記事

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?