はじめに
AIコーディングツールの普及により、コード生成速度は大幅に向上しているが、その反面でコードレビューの負荷が増大し、コードレビューの大変さを味わっている…。
そこで、AIを活用したコードレビューツールを使ってみたいと思う。
以前、PR-Agent
を使ってみたが今回は Greptile
というコードレビューツールをGitHubでの開発フローに組み込んで試してみる。
以前の記事 ↓
Greptileとは
Greptileは、AIを活用したコードレビューサービスである。
- Greptile
https://www.greptile.com/
主な特徴
- リポジトリ全体のインデックス化: コードベース全体を理解した上でレビューを実施
- GitHub/GitLab連携: PRに自動でレビューコメントを追加
PRレビューのサンプル
公式ページでサンプルとして紹介されているプルリクエストのページは以下となる。
- feat: salesforce custom query
https://github.com/onyx-dot-app/onyx/pull/5158
導入手順
1. アカウント作成
Greptileの公式サイトからアカウントを作成する。
※今回はGitHub
アカウントでのサインアップを行った。
- 2週間の無料トライアルが利用可能
サインアップし、組織を作成すると以下の管理画面となる。

2. GitHubリポジトリとの連携
AI Code Review Bot
→ Setting
を選択し、 CONNECT
を選択する。

↓
Authorize Greptile Apps
を選択する。

↓
個人の方の katsuobushiFPGA
に入れてみる。

↓
All repositories
にしておく。
※範囲を限定したい場合は、Only select repositories
にする。

↓
連携が完了すると以下のページにリポジトリ一覧が表示される。

3. リポジトリを選択する
今回有効にしたいリポジトリを選択する。
リポジトリにチェックを入れた後、ENABLE SELECTED
を選択する。

4. PRの設定
PRに何を含めるかを設定できる。
今回は以下のように設定した。
項目 | 説明 | 設定内容 |
---|---|---|
PR概要設定 | 要約はコメントとして投稿されます | ✅ PRサマリーを生成する |
要約の投稿場所 | 別個のコメントの代わりに、PRの説明に要約を追加します | コメント形式で投稿 |
PR概要 | 変更点のテキスト要約を含める | ✅ 有効 |
シーケンス図 | 変更のシーケンス図を生成する | ✅ 有効 |
問題表 | 評価が変更された重要なファイルの表を表示する | ✅ 有効 |
信頼スコア | PRの信頼度評価を含める | ✅ 有効 |
PRサマリーは、Greptileによって生成されたPRの変更のサマリーであり、PRにコメントとして追加される。

5. レビューの開始
設定は完了した。
PRのコメントで @greptileをすれば再レビューができるようになっているとのこと。
というわけでリポジトリを見てみる。

↓
もう閉じているPRに @greptile
をしたら目の絵文字がきた!

↓
ちょっとするとレビューがついてきた。
全文は以下の通り。

6. コメントレベル
Greptileの感度とコメントタイプを設定できる。
Strictness Level(厳密さレベル)
レベル | 説明 | 設定内容 |
---|---|---|
low | 低い感度での検出 | 重要な問題のみ指摘 |
med | 中程度の感度での検出 | ✅ バランスの取れたアプローチで重要な問題に焦点 |
high | 高い感度での検出 | 細かい問題まで全て指摘 |
Comment Types(コメントタイプ)
タイプ | 説明 | 設定内容 |
---|---|---|
syntax | 構文エラーや文法の問題 | ✅ 有効 |
logic | ロジックや実装の問題 | ✅ 有効 |
style | コードスタイルや規約の問題 | ✅ 有効 |

レビューのフィードバックについて
コメントに 👍や👎で良い/悪いかを評価できるとのこと

フィルターについて
フィルターは、どのプルリクエストがレビューされるかを制御するのに役立つ機能である。
フィルターの概要
- 目的: レビュー対象のPRを絞り込み、不要なレビューを回避
- 設定場所: 設定ページで新しいフィルターの追加・削除が可能
- 効果: 特定の条件に合致するPRのみをレビュー対象とする
主なフィルター条件
フィルター種類 | 説明 | 使用例 |
---|---|---|
Labels | 特定のラベルが付いたPRをフィルタ | documentation ラベルを除外 |
Authors | 特定のユーザーのPRを制御 | Bot作成のPRを除外 |
Branches | 特定のブランチ名のPRをフィルタ | main ブランチのみ対象 |
Keywords | PRタイトルや説明の特定キーワード | WIP を含むPRを除外 |

カスタムコンテキストについて
Greptileでは、チーム固有のルール(チーム独自のコーディング規約やレビュー方針)やガイドラインをCustom Contextとして設定できる。
- Custom Context & Learning
https://www.greptile.com/docs/code-review-bot/custom-context

設定方法
- 手動設定: 管理画面から直接ルールを記述
- 自動学習: 人間のレビューコメントから自動でルールを生成
- ファイル連携: リポジトリ内のドキュメントファイルを参照
Custom Contextの例
## コーディング規約
### 必須事項
- 関数には必ずJSDocコメントを付与する
- console.logは本番コードでは使用禁止
- 型定義は明示的に行う
- エラーハンドリングは必須
### 推奨事項
- 関数名は動詞から始める
- 変数名はcamelCaseを使用
- magic numberは定数として定義
### 禁止事項
- var文の使用禁止(let/constを使用)
- 直接的なDOM操作の禁止
- ハードコードされたURL・APIキー
設定時の注意点
項目 | 説明 | 推奨対応 |
---|---|---|
自動追加ルール | 人間のレビューから自動生成される | 定期的な監視・調整が必要 |
重複ルール | 同じ内容のルールが複数追加される | 定期的な整理・統合 |
過剰指摘 | 特定ルールで過度に指摘される | ルールの調整・無効化 |
スコープ管理 | 全リポジトリに適用される | プロジェクト固有設定の検討 |
実際の使用方法
基本的なワークフロー
- PR作成: 通常通りPull Requestを作成
- 自動レビュー: ドラフトからオープンに変更すると自動でレビューが開始
- 手動レビュー依頼:
@greptile
メンションでレビューを依頼
レビュー依頼の方法
# 方法1. Pull Requestを作成する
# 方法2. メンションをつけてPRにコメントする
@greptile このPRをレビューしてください
実際のレビュー例
タイポの検出
Greptileは細かいタイポも検出する
- // Calcualte the total amount
+ // Calculate the total amount
デバッグコードの検出
- console.log("Debug: user data", userData);
// 本番環境に不要なデバッグコードを指摘
コーディング規約違反の指摘
// 指摘例: JSDoc形式でのコメント推奨
/**
* ユーザー情報を取得する
* @param {string} userId - ユーザーID
* @returns {Promise<User>} ユーザー情報
*/
function getUser(userId) {
// ...
}
参考
Greptile公式サイト
https://www.greptile.com/Greptile User Manual
https://www.greptile.com/docs/introduction最新のAIコードレビューを導入してみたら意外とスムーズだった話
https://speakerdeck.com/zabeth129/zui-xin-noai-kodorebiyuwodao-ru-sitemitarayi-wai-tosumuzudatutahuaGreptile によるレビューのオススメ、Claude Code 等のお供にどうぞ
https://note.com/hi_noguchi/n/n8654741422ae
おわりに
AIコードレビューツールは、現代の開発チームにとって必須のツールになりつつあると考えている。
手元のツールでもAI
を使ってのコードレビューが可能であるが、強制力が低く、レビューを通したコードかどうかもレビュアーにとってはわからない。
なので、GitHub や GitLab などの ホスティングサービスでPRのコードレビューをAIが行うということが重要であると思っている。
今回は、Greptile
というAIコードレビューツールを試してみたが、導入が簡単であったため、その部分での苦労はなかった。
カスタマイズ性も高そうなので、業務で試してみてもよさそうだなと思う。
資金がない個人開発には少しハードルが高そう。(というより個人であれば手元でレビューするという方法でよい気がする。)