GitHub Copilot code review にブログ記事をレビューしてもらう

みなさんこんにちは、イノベーションセンターの @Mahito です。 普段は社内のエンジニアが働きやすくなることを目標に、 コーポレートエンジニアのような活動やエンジニア向けイベントの企画・運営をしています。

今回は、本 NTT docomo Business Engineers' Blog のレビューに、 GitHub Copilot code review を利用し始めたことと、その学びについてお話します。

なお、GitHub Copilot code review を導入以降は投稿がないので、 これが GitHub Copilot code review の初レビュー記事となっております。

企業ブログにおけるレビューの重要性と難しさ

まず、GitHub Copilot code review を導入した話の前に企業ブログのレビューについて少し説明します。

本ブログのように、現在さまざまな企業でブログが展開されています。 しかし、企業ブログでは記事を発信する際に以下のようにさまざまな観点からのレビューが必要となります。

• 内容は正確か
• 誤字脱字はないか
• 企業のブランドイメージや広報ルールに合致しているか
• 誤解を招く表現がないか
• 引用は正しくされているか
• etc...

誤字脱字には簡単なタイポから自社や他社の商標やサービス名の誤り（本来大文字にするところが小文字になっている等）なども含まれます。 また、投稿者が意図した内容と記事を読んだ人の間で解釈が異なることから問題になるケースもあります。

こうした問題を避けるためにも記事を公開する前のレビューが重要となります。

しかし、上記のような観点は機械的なレビューではカバーできないことも多く、 人の手によるレビューが必要となります。

一方、人によるレビューでは問題を見逃してしまうことや、 スキル・経験・意見の違いによって、レビューの結果のばらつきによる問題が生じることもあります。

例えば A さんには問題のない表現に見えたので指摘をしなかったが、B さんが見ると問題がある表現だった、ということがあります。

そのため、レビューワーのスキルや考え方の共有をしながら、 企業として必ず守らなければいけないルールのラインをレビュー全体で揃えていくといった難しさがあります。

本ブログにおけるこれまでの取り組みと GitHub Copilot code review 導入の背景

仕組みによるレビュー

本ブログでは記事の管理やレビューに GitHub を利用しています。

投稿者は記事を執筆した後 PR を出し、レビュアーが PR に記事の修正や改善の提案を繰り返しながら、記事をブラッシュアップしていきます。 (なお、GitHubを活用した記事公開プロセスについては、別記事「開発者ブログをリニューアルしたついでにレビューと記事公開プロセスをいい感じにしたお話」 で紹介していますので、ご興味がありましたらご覧ください) 。

以前より、レビューには textlint を用いた文章確認の仕組みを用意しています。

textlint は、文章の誤字脱字や表記ゆれ、文法確認などを行うためのツールです。 textlint を用いることで、設定したルールに基づき、 文法的な誤りや表記ゆれを自動的に検出し、レビュアーが指摘する必要のある問題を減らすことができます。

例えば、1文が長すぎるといったところや、広報ルールに沿ってない表現（「様々」は「さまざま」にするなど）を自動的に検出し、指摘できます。

PR の作成や修正がされたタイミングで GitHub Actions を用いた CI も用意しており、 投稿者の手元や PR 上で常に文章確認をしています。

昨年には、textlint では対応できない誤字脱字などの誤りが一定数あることから、 LLM を用いることでより抜けのない校正ができるのではと考え、CI に組み込んだこともあります （LLM校正CIを自社のブログに導入してみた で詳しく紹介しています）。

しかしながら、こちらは LLM のモデル更新が頻繁にあることや、プロンプト調整の難しさ、 さらに実際には指摘されるコメントの半数ぐらいが的外れな修正提案だったこともありお蔵入りとなりました。

スタッフ内でのレビュースキルの共有

上記のような機械的な仕組みを用いたレビューは、ある程度の効果はあるものの、 最終的には本ブログのスタッフによるレビューに頼ることとなっています。

一方、人によるレビューでは問題を見逃してしまうことや、 スキル・経験・意見の違いによって、レビューの結果のばらつきによる問題が生じることもあります。

例えば A さんには問題のない表現に見えたのでコメントをしなかったが、B さんが見ていれば気付ける問題だった、ということがあります。

本ブログスタッフでは、レビュースキルを共有するためにいくつかの取り組みを行っています。

例えば、新しくスタッフになってくれた人向けのドキュメント整備や、ペアレビューを実施することでレビューのスキルを共有しています。

また、レビューをしている際に不安な場合は、Slack で他のスタッフに相談することもあります。

他にも、今回のようにスタッフ自身がブログ記事を書いて、他のスタッフからのレビューを受けることで、 レビュースキルの共有がされることもあります。

GitHub Copilot code review の導入

先述の通り、一時的に導入した LLM 校正 CI はお蔵入りをしましたが、 そのアイデア自体は面白かったことや、スタッフのレビューを下支えするためにも再度 LLM を使ったレビューをできないかと考えていました。

2025年4月4日に GitHub Copilot code review がリリースされたため、活用の検討を始めました。

GitHub Copilot code review は、 GitHub Copilot がコードレビューをした上でフィードバックをくれる機能です。

また、GitHub Copilot code review は、.github/copilot-instructions.md に Copilot に対するコンテキストを追加設定することで、レビュー観点を明示的に指示できます。

上記で述べたように、新規スタッフにレビュースキルを共有するための取り組みの中で、 レビュー観点などについてはすでにドキュメント化されているので、 これを追加コンテキストとして GitHub Copilot code review に設定しました。

GitHub Copilot code review の設定

実際の設定にはスタッフ向けのレビューマニュアルからレビュー観点を抽出し、 抽出したものを Claude Code に与えて .github/copilot-instructions.md を作成してもらいました。

現在は Claude Code が出力した内容で日本語としておかしな箇所などを直したものを利用おり、 以下がその内容の一部です。

### 2. 商標およびブランド名の検証

- **目的**: 商標名およびブランド名の適切な名称使用を確実にする
- **ガイドライン**:
  - 企業および製品の正しい名称が使われているかを検証する
  - prh.ymlで既にカバーされている一般的な間違い（GitHub vs Github等）も確認する
  - 潜在的な商標侵害を特定する
  - 誤用される商標名やブランド名の修正を提案する
  - テック企業とその製品に特に注意を払う

GitHub Copilot code review の実行

GitHub Copilot code review を実行するには、 GitHub 上でプルリクエストを作成し、レビュアーに対して GitHub Copilot code review を有効にする必要があります。

レビュアーに割り当てると、あとは自動的に GitHub Copilot code review が実行され、 PR のコメントとしてレビューコメントが追加されます。

冒頭でも述べたように、本記事が GitHub Copilot code review の初レビュー記事となります。

実際に本記事のドラフトに対して GitHub Copilot code review を動かして、 GitHub Copilot code review から指摘された内容をいくつかお見せいたします。

textlint では指摘されなかった typo の指摘

確かにここは「は」を入れたほうが自然な文となりますので修正しました。 この他にも文法的な指摘や、不要なスペースの指摘など我々の textlint の設定では拾われなかった細かい typo をいくつか指摘されております。

サービス名の確認

こちら指摘されている "Claude Code" については、ツール名としては正しいです。 Claude Code は Claude の API を利用しておりサービス名としては "Claude" が正しいのかも知れませんが、 今回はツールとして Claude Code を利用したことを伝えたいので、"Claude Code" のままにしています。

今回は過検知という結果になっていますが、 商標やサービス名についても .github/copilot-instructions.md に書いた内容で確認しているのがわかりました。 また、製品名やブランド名以外にツール名についても確認するよう追加指示の必要があるとわかりました。

GitHub Copilot code review を動かしての学び

実際に GitHub Copilot code review 動かしてみて、いくつかの学びがありましたので共有しておきます。

1. 指摘の非決定性

まず、GitHub Copilot code review を動かすたびに指摘が変わるケースに遭遇しました。

こちらは内容が変わるというよりも、前回のレビューでは指摘されず修正もされなかった箇所が次回のレビューでは指摘されることがありました。

それなら最初から指摘してほしかったという気持ちになりつつも、 私自身 1 度目のレビューで見逃していた箇所に再レビュー時で気づき、申し訳無さもありながらコメントすることもあります。 そういう意味で、GitHub Copilot code review を含む生成 AI もちょっと人間っぽい不確実さがあるなと感じました。

一応対策としては、GitHub Copilot code review が一度レビューを終えた後で、 再度 GitHub Copilot code review を実行することで、指摘箇所が変わることもあるので何度か動かしてみるのもありかなと思いました。

ただ、指摘箇所が変わるということもあり、 .github/copilot-instructions.md にも書いた指示内容が正確に反映されているのか分かりづらく、 このあたりは使いながら時間をかけて調整する必要があると感じています。

2. 執筆者・レビュアーの負担軽減

こちらは普段から CI に Linter や Formatter を導入されている方はわかると思うのですが、 GitHub Copilot code review を使い機械的な指摘を受けることで、 執筆者・レビュアー双方の心理的な負担を減らすことができます。

私がコードや記事を書いている際にも簡単なミスや typo の指摘を人にされると、 「こんな簡単なところの指摘させて申し訳ない」と思うことが多々あります。

レビュアーの立場でも「こんな些細なところの指摘をして直させるのは心苦しい（でも必要だし）」と思いながら指摘することがあります。

GitHub Copilot code review を使うことで、 Linter や Formatter のように記事内容をレビュアーが確認する前に GitHub Copilot code review が問題点を指摘してくれるため、 執筆者・レビュアー間でのやりとりが減り、双方の心理的な負担を減らすことができると感じました。

3. レビュー観点の明示化によるレビュアーの観点共有

こちらは当初想定していなかったメリットではありますが、 .github/copilot-instructions.md にレビュー観点を明示化することで、レビュアーの観点を共有しやすくなると感じました。

これまでもドキュメントに記載することで共有を図っていたのですが、 今回 GitHub Copilot code review 用に .github/copilot-instructions.md を作成することで、 レビューの要点をより明示でき、的確にレビュー観点をレビュアー内で共有できるようになったと考えています。

textlint と GitHub Copilot code review の使い分け

GitHub Copilot code review がなんとなく使えることがわかりましたが、 では textlint は不要かというとそういうわけではありません。

GitHub Copilot code review は生成 AI を用いたレビューであり、 先述したようにその結果が必ずしも毎回一致するとは限りません（非決定性）。

例えば、textlint のルールとして紹介した「様々」という単語に対して、 GitHub Copilot code review は「さまざま」と修正を提案することもあれば、しない場合もあります。

このように結果が必ず一意になるように確認する場面（決定性）については、 textlint を用いた確認が有効です。

逆に、文脈などから判断が必要な場合においては、GitHub Copilot code review のような、生成 AI を用いたレビューが有効だと考えられます。

まとめ

本記事では、企業ブログにおけるレビューの難しさと、それを手助けする可能性として GitHub Copilot code review を活用する方法について紹介しました。

もちろん生成 AI の出力のため完璧でないことを前提にした運用となりますが、 これまでスタッフが確認してきたけど漏らしがちなところを GitHub Copilot code review にサポートしてもらえるのではないかと思っています。

なお、今回の記事は GitHub Copilot code review によるレビューを反映したうえでレビューアーに見てもらっていますが、 レビュアーからは記事をさらに良くするための指摘をいくつもされており、やはり人のレビューは大事だなと改めて感じています。

今回は企業ブログのレビューでの活用を紹介しましたが、 個人ブログでも活用できるかと思いますので、よろしければぜひ試してみてください。

この記事がどこかの企業や個人のブログの運営のお役に立てれば幸いです。