はじめに
本記事では、Claude Code（LLM）を活用して、READMEやPRテンプレートに記載された手動チェック項目を自動化するGitHub Actionsを実装した事例を紹介します。
特に、「LLMが自動的に理解・実装できた部分」と「人間による詳細な説明が必要だった部分」の違いに焦点を当て、LLMとの協働における勘所をお伝えします。
背景と課題
私たちのチームでは、BigQueryのViewを管理するリポジトリを運用しています。PRを作成する際、作者・レビュアーは以下のような項目を手動でチェックする必要がありました。
PRテンプレートのチェックリスト（抜粋）
- [ ] viewのクエリ末尾にセミコロン`;`がないこと
- [ ] viewの中で、一時的なUDF（ `CREATE TEMP FUNCTION 〜` ）を使用していないか
また、READMEには「許可済みのプロジェクト・データセット一覧」として、Viewで参照できるテーブルの一覧が記載されていました。
## 許可済みのプロジェクト・データセット一覧
### プロジェクト
- project-a
- project-b
### データセット
- project-c.dataset-d
どちらも、手動で確認できますし、仮に見落としてもデプロイ用のGitHub Actionsでエラーになるため、わざわざ自動化の仕組みを作る優先度は高くありませんでした。
しかし、LLMに依頼することで短時間で実装できるなら話は別です。今回、LLMを活用してこれらのチェックを自動化してみました。
LLMへの依頼と結果
LLMが自動的に理解・実装できたもの
Claude Codeに下記のように依頼しました。
READMEとPRテンプレートを読み込んで、手動でチェックしている制約をGitHub Actionsで自動化してください
LLMはPRテンプレートを解析し、以下のようなチェックについては追加の説明なしに実装できました。
| インプット（PRテンプレートの記述） | 実装されたバリデーション |
|---|---|
viewのクエリ末尾にセミコロン;がないこと |
SQLファイルの最終行がセミコロンで終わっていればエラー |
| viewの中で、一時的なUDF（CREATE TEMP FUNCTION）を使用していないか | SQLファイル内にCREATE TEMP FUNCTIONが含まれていればエラー |
これらはPRテンプレートの記述から「何をチェックすべきか」が明確であり、LLMが自律的に実装方法を判断できました。
人間による詳細な説明が必要だったもの
一方、READMEに記載されている「許可されたテーブル参照」のチェックについては、LLMは自動的に実装できませんでした。そのため、以下のような情報を追加で伝えました。
READMEの`## 許可済みのプロジェクト・データセット一覧`についてもチェックしたいです
具体的には
SELECT ...
FROM `AAA.BBB.CCC`
INNER JOIN `XXX.YYY.ZZZ` ...
というsqlファイルがあったとして、
(
`AAA`/`XXX`に対して、
`###プロジェクト`にかかれているプロジェクト名である
)
または、
(
`AAA.BBB`/`XXX.YYY`に対して、
`### データセット`にかかれているデータセット名である
)
ことをチェックしたいです
この情報を伝えることで、LLMは以下のバリデーションを実装できました。
| インプット（人間の説明） | 実装されたバリデーション |
|---|---|
| READMEに許可リストがある + テーブル参照の形式 | SQLファイル内のテーブル参照を抽出し、READMEの許可リストと照合。許可されていないテーブル参照があればエラー |
成果物の精度
最初のバリデーション実装では、LLMはシェルスクリプトをGitHub ActionsのYAMLファイルに直接書き出しました。長いシェルスクリプトがYAMLにベタ書きされている状態だったため、以下のように指示しました。
シェルスクリプトはyamlに直接書かず、scriptsフォルダに分離してください
このリポジトリには既にscripts/フォルダが存在していたためか、LLMはすぐに方向転換してくれました。そして、それ以降に追加したバリデーションでは、最初からscripts/配下に個別のシェルスクリプトとして生成し、YAMLからはそれらを呼び出すだけのシンプルな構成で実装してくれるようになりました。
バリデーション以外での活用
PR上でのアノテーション表示
GitHub Actionsのアノテーション機能を活用することで、問題のある行がPRのFiles changedタブ上に直接表示されます。
ただし、最初の実装ではアノテーションがファイルに紐づいて表示されませんでした。GitHub Actionsのログにはエラーメッセージが出ているものの、PRの画面上には表示されない状態でした。
下記のようにLLMに報告したところ、
GitHub Actionsを実行した結果、エラーにはなっていますが、アノテーションがファイルに紐づいて表示されていません
アノテーションに行番号（line=パラメータ）が追加されました。修正後はレビュアーが該当箇所をすぐに確認できるようになりました。
テストPRの作成
実装完了後、動作確認用のテストPRもLLMに作成してもらいました。
- バリデーション失敗ケース（意図的にルール違反を含むファイル）
- エラーファイルに対し、アノテーションが表示されていること
- バリデーション成功ケース（正常なファイル）
まとめ
今回の実装では、READMEやPRテンプレート自体は一切変更していません。既存のドキュメントをそのまま「仕様書」としてLLMに渡し、そこからバリデーションロジックを生成してもらいました。READMEに記載のバリデーションに関する補足はしたものの、少しの対話でGitHub Actionsが完成しました。
今回の経験から、優先度の低いタスクも、LLMの活用の機会の一つだと感じました。少ない労力で、地味だけど便利な自動化が手に入りました！