はじめに
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コードレビューツールを試してみたが、導入が簡単であったため、その部分での苦労はなかった。
カスタマイズ性も高そうなので、業務で試してみてもよさそうだなと思う。
資金がない個人開発には少しハードルが高そう。(というより個人であれば手元でレビューするという方法でよい気がする。)