はじめに
こんにちは。レバレジーズデータ戦略室 データアーキテクトグループの辰野です。
皆さんは、特殊なファイル形式やカスタムルールに対するコードレビューの自動化に課題を感じたことはありませんか？
レバレジーズではGoogle CloudのサービスであるDataformを使用しているのですが、ここで採用されている独自のファイル形式「SQLX」に対するコーディングチェックは、その一つだと思います。
本稿では、私が試行的に実装した「VScodeとGitHub Copilotを用いたSQLXファイルの自動レビュー機能」について、具体的な内容と残る課題についてご紹介します。
同じような課題をお持ちの方にとって、少しでもヒントになれば幸いです。
※VScode、Github Copilot、Dataformのサービスに関する説明は割愛します
なぜ自動化しようと思ったのか？
DataformはGithubとの連携が可能なため、開発者はDataformで作業後にプルリクエストを作成し、レビュアーが承認をしたものだけマージする、という形でコードを管理しています。
Dataformはブラウザ上で作業を行えますが、その場でコンパイルエラーの検知は可能であるものの、それ以外のコーディングチェック機能は備わっていません。（※投稿日時の情報）
そのため、コンパイルエラー以外のコーディングについてはレビュアーがチェックする必要がありました。
データ戦略室で定めたコーディング規約を、複数名のレビュアーが目検でチェックしていたことから、指摘箇所の偏りや見逃しが起きたりとブレが生じ、また負担も大きい状態でした。
この状態を脱却すべく、最低限自動でチェックできる観点については自動化できないか検討することになりました。
広く流通している機能を使わなかった理由
SQLは、VScodeで自動でフォーマットする拡張機能があったり、SQLFluffを使用してカスタマイズしたルールを適用させることも可能です。
このあたりについて、データエンジニア組織のほうで調査が行われていたのですが、SQLX用のライブラリが少なく、かつデータ戦略室のコーディング規約用にカスタマイズすることが難しいという結論に至りました。
このことから、LLMを使って解決する方法を考えてみることにしました。
今回試した内容
レバレジーズでは以前からGithub Copilotが導入されていたこともあり、今回、こちらを活用した2つの方法を試しました。
参考にそれぞれやったことをご紹介します。
※投稿日時点でBusinessプランを利用
方法1: Github.com上のプルリクエストの説明欄に指示を入れてレビューさせる
やったこと
元々、プルリクエストの説明欄に、いくつか簡単な指示を入れておき、ReviewersにCopilotを割り当てて、その内容に沿ってレビューさせるということは実装されていました。
上記を参考に、さらにコーディング規約に沿った細かいレビューをさせるよう指示してみることにしました。
具体的には、全部で30個弱あるコーディング規約から、1つずつ項目を追加していき、漏れなく指摘されているかをチェックしていきました。
（画像1：プルリクエストの説明欄にレビュー観点を1つずつ追加していった例）
結果
観点を1、2項目だけ追加してレビューさせてみたところ、漏れなくチェックされました。
（画像2：レビュー観点に沿って指摘された例）
しかし、レビュー観点を増やしていくにつれ、チェック漏れや問題のない箇所まで指摘されてしまいました。
（画像3：不等号の前後の半角スペースを入れるルールについては指摘があったものの、current_date()でタイムゾーンを指定するルールについては指摘されなかった例）
レビュー観点を構造的に書いてみるなども試しましたが、項目が多いとどうしても網羅的にはチェックされませんでした。
所感
公式に明示されている箇所は見つけられませんでしたが、恐らく、指示の文字数が多いと、すべての内容を網羅的に読み取ることが難しいようです。（具体例を書くと精度が上がるかもとも思いましたが、さらに文字数が増えることから試しはしませんでした。）
もう一つの方法で使用する「Copilot code review」のカスタム命令については、最初の4,000文字分のみが有効という記述があった（参考｜GitHub Docs「About repository custom instructions」2025/12/02）ので、似たような制約があるのではないかと考えられます。
方法2: VScodeでカスタム指示とGithub Copilot Chatを使用してレビューさせる
やったこと
まずは公式のCopilot code reviewにある機能のうち、カスタム指示でCopilot のレビューをカスタマイズする方法（参考｜GitHub Docs「Customizing Copilot's reviews with custom instructions」2025/12/02）を参考に、必要なファイルを用意しました。用意したファイルと記述した内容のイメージは以下です。
.github\copilot-instructions.mdファイル- 概要：ワークスペース内で常に参照するファイル
- 目的：最低限の指示を読み込ませる
- イメージ：
このリポジトリでコードレビューを行う際には、以下の指示を厳守してください： ## 共通設定 - レビューは必ず **日本語** で書いてください。 ## 重点チェック項目 - 対象が `.sql` または `.sqlx` の場合、以下ファイルのコーディング規約を必ず参照してレビューしてください。： - `.github/prompts/sqlx_must.prompt.md`
.github\prompts\sqlx_must.prompt.mdファイル- 概要：特定のファイルパターンに該当するファイルの時に参照するファイル
- 目的：SQLXファイルのときだけレビューさせる必須観点を読み込ませる（対象ファイルを限定することもそうですが、一度に多くの情報は読み込めないことを考慮し、観点は別のファイルに明記している）
- イメージ：
--- applyTo: "**/*.sqlx" language: "ja" --- # 必須コーディング規約 以下はSQLおよびSQLXファイルのコーディング規約です： - レターケースの規約 - 予約語、関数、設定パラメータは全て小文字にする - スペース - 全て半角スペースを使用する - テーブルエイリアス - joinしている場合は必ずエイリアスが指定されている - その他 - SQLの改行前後のカンマは、次の行の先頭に記載されている - 複数のテーブルをjoinしている時は、全てのカラムのプレフィックスにエイリアスされたテーブル名をつける - with句を使用した中間テーブルの命名には、プレフィックスに必ず "temp_" をつける - クエリの参照テーブルに、ref関数を漏れなく使用している
.vscode\setting.jsonファイル- 概要：VScode上での設定を明記するファイル
- 目的：prompts配下のmdファイルを読み込ませるための設定を行う
- イメージ：
{
"chat.promptFiles": true
}
用意したファイルは以上です。
これらのファイルを対象リポジトリにマージします。
次に、VScodeでGithub Copilotを使用できるように設定をします。
具体的な説明は割愛しますが、Github Copilotが有効になったあとに、VScodeの公式に書いてあるセットアップの方法（参考｜Visual Studio Code「Set up GitHub Copilot in VS Code」2025/12/02）で設定できました。
設定後、上部にあるチャットアイコンから、「チャットを開く」をクリックします。
チャット画面が開くので、入力枠下にあるモードとモデルを選択します（※モデルは変化していくため投稿日時点での選択している情報）
- モード：
Agent - モデル：
Claude Sonnet 4
チャット欄で、例えばこのファイルを.github\copilot-instructions.mdに沿ってレビューし、修正箇所を直接ファイルに書いてください。というメッセージを送信すると、レビューが開始します。
現在開いているファイルと、レビュー観点のファイルを読み込み、レビュー結果が送られてきました。また、修正箇所については分かりやすく提案してくれます。
指摘された内容について、指摘箇所ごとに「Keep」「Undo」を選択したり、ファイル全体で「保持」「元に戻す」の選択が可能で、修正内容を即時反映することが可能です。
所感
1つ目の方法よりも圧倒的に精度が高く、またその場で修正内容を反映できる点も良かったです。
今回用意したファイルについて、Github.com上でのプルリクエスト時にReviewersにCopilotを割り当てても参照してレビューはしてくれますが、調査した時点ではやはり精度が低いと感じました。
そのため、「現時点ではVScodeでのレビューが、最も精度が高く、簡単に実現できる方法である」と判断し、まずは全員がこの方法でレビューを実施してから、レビュアーに依頼を出すという運用をしてみることになりました。
おわりに
導入してから2ヶ月ほど経ちましたが、コーディング規約に関してレビュアーから指摘されることは格段に減ったと感じます。
VScodeでレビューさせると結構指摘されることが多く、やはり目検では限界があるなと改めて実感しました。
レビューする際にもこの機能を使用することで、負担も減りました。
最終的には、レビュー必須観点はすべて自動でレビューさせ、レビュアーの役割はクエリの設計チェックだけにしたいと考えています。
そのために、精度を上げるにはどうすればいいのか、もっと最適な方法はないのかを、引き続き模索する必要があります。
また、GitHubやCopilot、Dataform自体の機能・精度が進化することにも期待し、最新の情報を常にキャッチアップし、より良いレビュー環境の構築を目指していきます。
進展があった際には、続きの記事を書きたいと思います。
