Skip to content

Section 3: Gemini Code Assist による、プルリクレビュー

使うツール: Gemini Code Assist for GitHub (GitHub App)

Gemini Code Assist for GitHub とは

Gemini Code Assist for GitHub https://codeassist.google

GitHubのプルリクエストを自動的にレビューし、コードの変更や修正を自動的に提案してくれる。 1日あたり33件のプルリクエストまでレビューしてもらえる。

目的

  • PR レビューで本当に高いのは「指摘する時間」よりも、レビュー開始までの待ち時間。Gemini を入れると、PR を open した瞬間に一次レビューが走る
  • 人間レビュアーには設計判断・仕様判断・チーム事情の確認に集中してほしい。typo、境界値、null 安全性、単純な見落としは AI に先に拾わせる
  • レビュー結果が GitHub 上に残るので、チーム全員が同じコメント・同じ差分・同じ判断履歴を見られる。個人のローカル確認で終わらない
  • 実装に Claude を使っている場合、レビューも Claude だけだと「同じモデルの思い込み」を見逃しやすい。別モデル (Gemini) の視点 を挟むことで、片方が見落としたパターンや別解にも気付ける

完成形

  • PR を open すると Gemini Code Assist がレビューコメントを投稿

設定

GitHub で Gemini Code Assist を設定する https://developers.google.com/gemini-code-assist/docs/set-up-code-assist-github

参考: https://zenn.dev/yamazaking/articles/gemini-code-assistant-tutorial

手順

1. 設定ファイル

設定ファイルなしでも動くが、リポジトリに設定ファイルを置いてカスタマイズできる。

.gemini/config.yaml

yaml
# .gemini/config.yaml
# Gemini Code Assist for GitHub の設定
# 参考: https://developers.google.com/gemini-code-assist/docs/review-github-code

have_fun: false           # 絵文字ノリを抑える
code_review:
  disable: false
  comment_severity_threshold: MEDIUM   # LOW ノイズを抑制
  max_review_comments: -1              # 無制限
  pull_request_opened:
    help: false           # "How to use" メッセージを毎回出さない
    summary: false        # PR サマリコメントを付与
    code_review: true     # 自動レビュー
  pull_request_synchronized:
    code_review: true     # push の度に再レビュー
ignore_patterns:
  - "**/*.lock"
  - "**/dist/**"
  - "**/build/**"
  - "**/node_modules/**"

.gemini/styleguide.md

md
# チームレビュー観点 (for Gemini Code Assist)

この文書は Gemini Code Assist がレビュー時に参照するチーム規約です。
人間向けに読めるマークダウンで書けば Gemini が解釈します。

## レビューラベル

各指摘の冒頭に以下のいずれかのラベルバッジを付けてください。

| ラベル | バッジ                                                           | 意味                     |
| ------ | ---------------------------------------------------------------- | ------------------------ |
| must   | `![must](https://img.shields.io/badge/review-must-critical.svg)` | マージ前に必ず修正が必要 |
| ask    | `![ask](https://img.shields.io/badge/review-ask-9b71ae.svg)`     | 意図や背景の確認         |
| imo    | `![imo](https://img.shields.io/badge/review-imo-yellow.svg)`     | 改善提案 (任意対応)      |
| nits   | `![nits](https://img.shields.io/badge/review-nits-inactive.svg)` | 些細な指摘               |
| good   | `![good](https://img.shields.io/badge/review-good-success.svg)`  | 良い実装の称賛           |

## アラート

特に強調したい指摘には GitHub のアラート構文を併用してください。

| 種別           | 用途                                                                                        |
| -------------- | ------------------------------------------------------------------------------------------- |
| `> [!WARNING]` | 問題を回避するために直ちに注意を払う必要がある緊急情報                                      |
| `> [!CAUTION]` | 特定の行動のリスクやマイナスの結果についてのアドバイス                                      |
| `> [!NOTE]`    | 知っておくと有用な補足情報                                                                  |
| `> [!TIP]`     | より良い書き方のヒント (ライブラリの便利機能、新しい言語機能など、コードベース外の知識共有) |

## 観点とラベルの対応

### セキュリティ → `must` + `> [!CAUTION]`

- ハードコードされた秘密情報 (API キー / パスワード / トークン) がないか
- ユーザー入力のサニタイズ / パラメータ化クエリ
- 認可チェック漏れ

### エラーハンドリング → `must` または `imo`

- 例外を握りつぶしていないか (`must`)
- 境界 (外部 API / ユーザー入力) でのバリデーション (`must`)
- リトライ・タイムアウトの考慮 (`imo`)

### 可読性 → `imo` または `nits`

- 関数 50 行以内 / ファイル 800 行以内 / ネスト 4 段以内 (`imo`)
- マジックナンバーは定数化されているか (`imo`)
- 命名・空白・コメントの細かな指摘 (`nits`)

### 良い実装 → `good`

設計判断が優れている、テストが丁寧、適切な抽象化など、積極的に拾って称賛してください。

### タイポ → `nits`

コード内・ドキュメント問わず、タイポを見つけたら指摘してください。

## コメント例

```markdown
![must](https://img.shields.io/badge/review-must-critical.svg)

> [!CAUTION]
> ここでユーザー入力を直接 SQL に展開しているため SQL インジェクションのリスクがあります。
> プレースホルダを使用する形に修正した方が良いです。
```

```markdown
![imo](https://img.shields.io/badge/review-imo-yellow.svg)

この関数は 80 行を超えているため、〜の責務を別関数に切り出すと読みやすくなりそうです。
```

```markdown
![nits](https://img.shields.io/badge/review-nits-inactive.svg)

> [!TIP]
> PHP 8.1 から Enum が使えるので、こうした定数群は Enum 化するとより安全になります。
```

```markdown
![nits](https://img.shields.io/badge/review-nits-inactive.svg)

`recieve``receive` のタイポです。
```

## 指摘のトーン

- **言語: 日本語で記述する**
- 断定ではなく提案ベース ("〜した方が良いかもしれません")
- 必ず理由を添える ("なぜならこのパスは外部から呼ばれるため...")

## 対象外

- テストファイル内のマジックナンバー
- 自動生成コード (`*_pb.go`, `*.gen.ts` など)

2. 動作確認

動作確認は次のPR作成で試します。

補足

  • ノイズを減らすcomment_severity_threshold: MEDIUM 以上のみにする
  • 特定ディレクトリだけレビューignore_patterns で除外
  • コーディングスタイル共有styleguide.md に書いておけば AI がコーディングスタイル等のレビュー指示に従う
  • @gemini-code-assist をメンションすると追加質問にも答える
  • /gemini review コマンドで再レビューをトリガ

2026-05-07 開催 / 開発フロー自動化ハンズオン