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
- Gemini Code Assist アプリページへ移動
- アプリをインストールする
- svelte-todo リポジトリを有効にする
参考: 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 | `` | マージ前に必ず修正が必要 |
| ask | `` | 意図や背景の確認 |
| imo | `` | 改善提案 (任意対応) |
| nits | `` | 些細な指摘 |
| good | `` | 良い実装の称賛 |
## アラート
特に強調したい指摘には 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

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

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

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

`recieve` は `receive` のタイポです。
```
## 指摘のトーン
- **言語: 日本語で記述する**
- 断定ではなく提案ベース ("〜した方が良いかもしれません")
- 必ず理由を添える ("なぜならこのパスは外部から呼ばれるため...")
## 対象外
- テストファイル内のマジックナンバー
- 自動生成コード (`*_pb.go`, `*.gen.ts` など)2. 動作確認
動作確認は次のPR作成で試します。
補足
- ノイズを減らす →
comment_severity_threshold: MEDIUM以上のみにする - 特定ディレクトリだけレビュー →
ignore_patternsで除外 - コーディングスタイル共有 →
styleguide.mdに書いておけば AI がコーディングスタイル等のレビュー指示に従う @gemini-code-assistをメンションすると追加質問にも答える/gemini reviewコマンドで再レビューをトリガ