Gemini Code AssistでPRレビューしてもらう際のカスタマイズ設定について
最近Gemini Code Assistを活用して、PRレビューをしてもらうようにしたのですが、その際に調べた内容についてのまとめです。
特に導入後のカスタマイズについての内容になります。
カスタムスタイルガイドの追加
リポジトリ内に、.geminiフォルダを用意して、その中にconfig.yamlやstyleguide.mdを用意すると、そのプロジェクト用の設定を追加することができます。
config.yaml
config.yamlには、PRレビューする際にコメントの重要度の設定や最大コメント数など、レビュー時の挙動の設定をすることができます。
デフォルトでは以下のような設定がされているようです。
have_fun: false
code_review:
disable: false
comment_severity_threshold: MEDIUM
max_review_comments: -1
pull_request_opened:
help: false
summary: true
code_review: true
ignore_patterns: []
それぞれのフィールドの詳細は以下のような感じになっています。
-
have_fun:
boolean- 初期のPRサマリーに詩を含めるなどの機能を有効にします
- デフォルト:
false
-
code_review:
boolean- コードレビューの設定
-
disable:
boolean- GeminiがPRに対してアクションを実行することを無効にするかどうか
- デフォルト:
false
-
comment_severity_threshold:
string（LOW,MEDIUM,HIGH,CRITICAL）- 考慮するレビューコメントの最小重要度を設定
- デフォルト:
MEDIUM
-
max_review_comments:
integer- 考慮するレビューコメントの最大数を設定（-1で無制限）
- デフォルト:
-1
-
pull_request_opened:
object- PRが開かれた際のイベント設定
-
help:
boolean- PR上でヘルプメッセージ（コマンド利用方法など）を投稿するかどうか
- デフォルト:
false
-
summary:
boolean- PRサマリーを生成するかどうか
- デフォルト:
true
-
code_review:
boolean- コードレビューの内容を投稿するかどうか
- デフォルト:
true
-
ignore_patterns:
array- Gemini Code Assistが無視するファイルやディレクトリのリスト
- このリストのパターンにマッチするファイルは、レビューの対象から外される
- デフォルト:
[]（空の配列）
チームの方針によると思うのですが、例えばGeminiにレビューしてもらった際に、重要度がHigh Priority以上のものだけ対応するといった場合には、comment_severity_thresholdにHIGHを指定することで必要な部分だけコメントを見ることができるようになりますし、summaryなど必要なければコメントさせないようにすることもできるので、チームの方針によってカスタマイズすることができそうでした。
styleguide.md
styleguide.mdには、自社独自のコーディング規約を追加することができ、より自社にあったレビューをすることができるようになります。
特に指定がされていない場合は、以下のような観点からレビューをしてくれるようです。
カスタム スタイルガイドが指定されていない場合、Gemini Code Assist は次の主要なカテゴリでコードレビューを行います。
正確性: コードが意図したとおりに機能し、エッジケースを処理し、論理エラー、競合状態、API の誤った使用をチェックします。
効率性: パフォーマンスのボトルネックや最適化の対象となる領域（ループの過剰、メモリリーク、非効率なデータ構造、冗長な計算、過剰なロギング、非効率な文字列操作など）を特定します。
保守性: コードの読みやすさ、モジュール性、言語の慣用句とベスト プラクティスへの準拠性を評価します。変数、関数、クラスの不適切な命名、コメントやドキュメントの欠如、複雑なコード、コードの重複、不整合な形式、マジックナンバーを対象としています。
セキュリティ: 機密データの安全でない保存、インジェクション攻撃、アクセス制御の不備、クロスサイト リクエスト フォージェリ（CSRF）、安全でない直接オブジェクト参照（IDOR）など、データ処理や入力検証の潜在的な脆弱性を特定します。
その他: プル リクエストの審査では、テスト、パフォーマンス、スケーラビリティ、モジュール性と再利用性、エラー ロギングとモニタリングなど、その他のトピックも考慮されます。
styleguide.mdに対しては、例えばPythonのプロジェクトの場合には、以下のような内容を記載することで、Gemini Code Assistがより精度の高いチーム固有のレビューを行うことができるようになります。
**命名規則:**
- 関数名や変数名は snake_case を使用
- クラス名は PascalCase を使用
- 定数は UPPER_CASE を使用
- プライベート属性には先頭にアンダースコア（_）を付ける
**docstring:**
- すべての関数とクラスには適切なdocstringを記載
- Google形式のdocstringを使用
- パラメータ、戻り値、例外についても記載
**型ヒント:**
- 型ヒントを使用してコードの可読性を向上させる
**コメント:**
- 明確で簡潔なコメントを記載（「何を」ではなく「なぜ」を説明）
- 適度にコメントを使用（自己説明的なコードを心がける）
- 完全な文章で記載（大文字始まり、適切な句読点）
**ログ出力:**
- 標準のloggingモジュールを使用
- 適切なレベル（DEBUG、INFO、WARNING、ERROR、CRITICAL）でログを出力
- デバッグに必要な文脈情報を含める
**エラーハンドリング:**
- 具体的な例外を使用（Exceptionのような広範囲な例外は避ける）
- 例外を適切に処理し、情報的なエラーメッセージを提供
- try...except文を使用して例外が発生する可能性のあるコードを分離
まとめ
AIコードレビューを導入することで、人間がレビューする前に問題になりそうな部分をAIが指摘してくれるので、大幅に時間を短縮することができました。
もちろん、AIにレビューしてもらった内容が全て正しいという訳ではないと思うので、人間がチェックする必要はありますが、レビューの時間削減につながると思うので、ぜひ導入してみてください。
参考
Discussion