AIコードレビュー「ai-pr-reviewer」のプロンプト改善

この記事は GMOインターネットグループ Advent Calendar 2024 2日目の記事です。

こんにちは!
GMO NIKKO株式会社の石丸です。

今回はAIによるコードレビューツール「ai-pr-reviewer」のレビュー精度を向上させるために行ったチューニングや独自で実装したプロンプトについて紹介します。

はじめに

CodeRabbitの「ai-pr-reviewer」はGitHubのPull Requestに対してAIが自動でコードレビューやPull Requestの要約を行うコードレビュー支援ツールです。

GitHub Actionsで簡単に導入することが可能ですが、レビューの精度や頻度、フォーマットなど、デフォルトの状態では複数の観点で改善が必要だと感じたため、この記事では実際にカスタマイズした設定ファイルやプロンプトの一部を紹介します。

本記事では「ai-pr-reviewer」の概要や導入の背景・効果については紹介しないため、機能の概要や導入方法は公式のREADMEをご確認ください。
ai-pr-reviewer/README.md at main · coderabbitai/ai-pr-reviewer

本記事で紹介する「ai-pr-reviewer」は2024年11月現在メンテナンスモードに移行しており、新たに設計された「CodeRabbit Pro」の利用が推奨されています。
ただ、「ai-pr-reviewer」は引き続き利用することが可能で、現在も様々な技術ブログで取り上げられているツールの一つなので、本記事が「ai-pr-reviewer」の精度改善の参考になれば幸いです。
また、「ai-pr-reviewer」に限らず、生成AIをコードレビューに活用するためのヒントとしても本記事を読んでいただけると嬉しいです。

プロンプトのカスタマイズ方法

冒頭で紹介した通り、「ai-pr-reviewer」はGitHub Actionsで動作します。
READMEで紹介されているGitHub Actionsの設定ファイルは以下の通りです。

name: Code Review

permissions:
  contents: read
  pull-requests: write

on:
  pull_request:
  pull_request_review_comment:
    types: [created]

concurrency:
  group:
    ${{ github.repository }}-${{ github.event.number || github.head_ref ||
    github.sha }}-${{ github.workflow }}-${{ github.event_name ==
    'pull_request_review_comment' && 'pr_comment' || 'pr' }}
  cancel-in-progress: ${{ github.event_name != 'pull_request_review_comment' }}

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: coderabbitai/ai-pr-reviewer@latest
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        with:
          debug: false
          review_simple_changes: false
          review_comment_lgtm: false

引用元:ai-pr-reviewer/README.md at main · coderabbitai/ai-pr-reviewer

上記の設定ファイルはOpenAIのモデルや各種キーなどの最低限の設定のみで、コードレビューや要約のためのプロンプトは以下のように設定されています。
※設定ファイルが長いため以下のリンクから直接ご確認ください。

ai-pr-reviewer/action.yml at main · coderabbitai/ai-pr-reviewer

上記のファイルを参考に、各自の設定ファイルで summarizesummarize_release_notes などの要素にプロンプトを設定することが可能です。

改善した内容

言語の設定

デフォルトでは英語でコードレビューや要約などのコメントが追加されるため、日本語で動作させるための設定を行いました。
公式のドキュメントでは language: ja-JP で設定が可能との説明がありますが、この設定のみでは稀に英語でレスポンスが返ってくることがありました。

そのため、language: ja-JP の設定に加えて、プロンプト自体を日本語に書き換えました。
※私の環境ではlanguageの設定とプロンプトの日本語化のみで改善しましたが、それでも状況が変わらない場合はプロンプトに「必ず日本語で返答してください」と指定してもよいかもしれません。

プロンプトの改善

日本語に書き換えたプロンプトは system_message , summarize, summarize_release_notesの3つです。
単にデフォルトのプロンプトを日本語に翻訳するだけではなく、主に以下の方針でプロンプトの修正・追記を行いました。

  • ノイズとなる不要なレビューコメントの制限
  • 日本語で自然な表現に(普段の開発で馴染みのない表現や指摘は除外)
  • 日本語への翻訳に合わせて文字数を調整

system_message

system_message は主にコードレビューに利用されるプロンプトです。
デフォルトの状態では「このコードは問題ありません」のような修正の提案ではないコードコメントが追加されることがあったため、上記の返答を制限するプロンプトを追記しています。

今回はRuby on Railsのアプリケーションに対して実装したため、「Ruby on Railsの思想やベストプラクティスに則っているか」と追記しましたが、それぞれの環境に合わせて言語・フレームワークのバージョンやコーディング規約に関するプロンプトを追記するのも良いと思います。

system_message: |
  あなたは `@coderabbitai`(別名 `github-actions[bot]`)で、OpenAIによって訓練された言語モデルです。
  あなたの役割は、非常に経験豊富なソフトウェアエンジニアとして、コードの一部を徹底的にレビューし、
  次のような内容を改善するコードスニペットを提案することです:
    - ロジック
    - セキュリティ
    - パフォーマンス
    - データ競合
    - 一貫性
    - エラーハンドリング
    - 保守性
    - モジュール性
    - 複雑性
    - 最適化
    - 誤字脱字
    - マジックナンバー
    - 無意味な空白や統一感のないインデント
    - Ruby on Railsの思想やベストプラクティスに則っているか
  軽微なコードスタイルの問題やコードコメント, ドキュメントの不足については指摘しないでください。
  「このコードは問題ありません」のような修正の提案ではないコメントも避けてください。
  全体的なコード品質を向上させるために、重要な問題点の特定と解決に集中し、軽微な問題は意図的に無視してください。
  ただし、誤字脱字やマジックナンバーなどの修正はコードの品質向上につながるため、修正を提案してください。

summarize

summarize はPull Requestの要約のために利用される設定です。
summarize に関しても以下の課題を改善するため、独自のプロンプトを追記しました。

  • マークダウン形式のテキストをコードブロックで囲ってしまうケースがあり、見出しやテーブルが見辛くなる
  • 日本語での出力に合わせて文字数を微調整
summarize: |
  最終的な回答を次の内容でMarkdown形式で記載してください:
  - **概要**: 全体の変更点を日本語300文字以内で高レベルに要約してください。特定のファイルに関する要約は不要です。
  - **変更点**: 変更されたファイルとその要約をMarkdown形式の表にまとめてください。似たような変更があるファイルは、一つの行にまとめてスペースを節約してください。
  この要約は、GitHubのプルリクエストにコメントとして追加されるため、追加のコメントは避けてください。
  見出しは「概要」と「変更点」とし、これらはH2の形式で文章を作成してください。
  「```」のコードブロックは不要です。

summarize_release_notes

summarize_release_notes はPull Requestに対してリリースノートを生成するためのプロンプトです。
summarizeと同様に日本語化に加えて文字数やフォーマットの調整を行いました。

summarize_release_notes: |
  プルリクエストのリリースノートを簡潔に作成してください。
  変更の目的とユーザーへの影響に焦点を当て、変更を「新機能」「バグ修正」「リファクタリング」「コードスタイル」「テストコード」「変更の取り消し」に分類してください。
  例えば、
  - 新機能: ユーザーの検索機能を追加
  といった箇条書き形式で記載します。
  それぞれの箇条書きの回答は日本語で200〜300文字に制限してください。
  コードレベルの詳細の変更に関する回答は不要で、エンドユーザーに影響がある機能を強調してください。
  この回答はそのままリリースノートに使用されるため、追加のコメントは避けてください。

モデルの指定

デフォルトでは、全体の要約などに利用される軽量なタスク(openai_light_model)には gpt-3.5-turbo、レビューなどの高度なタスク(openai_heavy_model)には gpt-4 が設定されています。
OpenAIのモデルは進化が早いため、以下のようにGitHub Actionsの変数で管理するようにしました。
※私の環境ではそれぞれ gpt-4o を設定しています

openai_light_model: ${{ vars.OPENAI_LIGHT_MODEL }}
openai_heavy_model: ${{ vars.OPENAI_HEAVY_MODEL }}

トリガーの設定

デフォルトではすべてのPull Requestに対して動作するため、チームの開発フローに合わせて特定のブランチのみ動作するように設定しました。

on:
  pull_request:
    branches:
      - develop
  pull_request_review_comment:
    types: [created]

まとめ

以上が「ai-pr-reviewer」の導入後に実施したカスタマイズの一例です。
デフォルトの状態では参考になるコメントも一部はあったものの、的外れなコメントや本筋ではないコメントで通知やコメントが埋め尽くされてしまいむしろノイズになってしまう・・・という状態でしたが、今回のカスタマイズを行うことで実用レベルまで精度が向上したと実感しています。

今後は引き続き「ai-pr-reviewer」のチューニングを行いつつ、CodeRabbit ProGitHub(GitHub Copilot)の進化 にも注目しながら積極的にAI活用を進めていきます!

ブログの著者欄

石丸 智輝

GMO NIKKO株式会社

Webアプリケーションエンジニア。 広告配信サービスの開発・運用を経験し、現在は開発に携わりながら開発メンバーや組織のマネジメントに従事。 GMOアドパートナーズテックブログの運用やエンジニア採用・研修, エンジニアイベント企画などの技術広報に関わる業務も担当。 2024年4月よりGMOインターネットグループ「デベロッパーエキスパート」として活動を開始。

採用情報

関連記事

KEYWORD

採用情報

SNS FOLLOW

GMOインターネットグループのSNSをフォローして最新情報をチェック