CodeRabbit を１ヵ月開発チームで実際に使ってみました！

ラブグラフでCTOをしております横江( @yokoe24 )です！

以前 Zenn で
『もう初回コードレビューはAIに任せる時代になった - CodeRabbit -』という記事が流行りました。

私たちのチームで実際に使ってみましたので、
事前準備や使ってみての便利さ、どのくらいの料金がかかったのかについてお伝えいたします！

事前準備

ラブグラフの親会社であるMIXIでは、
はたらく環境推進本部が中心となって
Azure OpenAI Service の API キーの払い出しをおこなってくれています。

また、『噂のAIレビューをAzure OpenAIでできるようにしてみた』の記事の作者さんが、
OSS版CodeRabbit を Azure OpenAI API で動くようにしたものを公開してくれています。

https://github.com/Wisteria30/ai-pr-reviewer

今回はこれを使用しました。

なお、使用にあたっては、
Azure OpenAI Service 以外へデータを送っていなさそうかコードをよく読んだ上で、
リポジトリを社内向けにフォークして、そのリポジトリの特定ブランチを常に参照するようにしました。
これで自社のコードが漏洩する可能性をなるべく少なく出来ている……はず……。

GitHub Actions の追加

CodeRabbit が動くよう、ほかの記事を参考にしつつ、
GitHub Actions 用の YAML ファイルをリポジトリに追加しました。

なお、 GITHUB_TOKEN 以外の AZURE_OPENAI_API_KEY などのシークレット変数は、
『GitHub Actions でのシークレットの使用 - GitHub Docs』の記事にあるような設定が必要です。

name: Code Review by AI

permissions:
  contents: read
  pull-requests: write

on:
  pull_request:
    types:
      - opened
      - ready_for_review
      - reopened
    branches-ignore:
      - main

concurrency:
  # 同時実行されるジョブがプルリクごとで1つになるよう制御している
  group: ${{ github.repository }}-${{ github.event.number || github.head_ref || github.sha }}-${{ github.workflow }}
  # 新しいジョブを開始するために現在実行中のジョブは中止する
  cancel-in-progress: true

jobs:
  review:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: lovegraph/ai-pr-reviewer-pub@v1-dev
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          AZURE_OPENAI_API_KEY: ${{ secrets.AZURE_OPENAI_API_KEY }}
          AZURE_OPENAI_API_INSTANCE_NAME: ${{ secrets.AZURE_OPENAI_API_KEY }}
          AZURE_OPENAI_API_DEPLOYMENT_NAME: ${{ secrets.AZURE_OPENAI_API_DEPLOYMENT_NAME }}
          AZURE_OPENAI_API_VERSION: 2023-12-01-preview
        with: # Ref: https://github.com/coderabbitai/ai-pr-reviewer?tab=readme-ov-file#reviewer-features
          debug: true
          review_simple_changes: false
          review_comment_lgtm: false
          openai_light_model: gpt-4
          openai_heavy_model: gpt-4
          openai_timeout_ms: 900000 # 15分
          language: ja-JP
          path_filters: |
            !**/*.lock
          # 以降、 https://zenn.dev/minedia/articles/7928ef7545b393 をもとに改良
          system_message: |
            あなたは Ruby on Rails や JavaScript に精通したプログラマーです。
            渡されたコードについて改善点を見つけ、変更する理由を説明した上で、変更後のコード例を示してください。
            改善点がない場合には絶対にコメントをしないでください。

            特に以下の点を指摘してください:
              - 誤解を招いたり、実態を正確に表していない命名があるか
              - 適度に変数を定義し自己ドキュメントされているか
              - 冗長な書き方のコードがないか
              - ファイル内で @var のようなインスタンス変数しか定義していないのに var のような変数名を使っていないか、またはその逆
              - N+1問題（N+1 query problem）を引き起こす箇所
              - 読んで理解が難しい箇所にコメントが適切にされているか
              - コメントの内容は日本語として読んでわかりやすく、簡潔に説明できているか
              - 理解の難しい複雑な条件式が作られていないか
              - 新しいメソッドを定義したときにテストコードを書いているか
              - テスト内の説明文は、テストの内容をわかりやすく適切に表しているか
              - 明らかなセキュリティの問題があるか

            誰にとっても読みやすいコードになるよう、改善点を見つけたら積極的にレビューしてください。
            あなたに渡されるコードは一部分であるため、未定義のメソッドやクラスなどの指摘については消極的にしてください。
          summarize: |
            次の内容で Markdown フォーマットを使用して、最終的な回答を提供してください。

              - *レビューのしやすさ*: 変更ファイル数などをもとに、レビュアーにとってのレビューのしやすさを 0.0-10.0 点で評価してください。どうすればレビューがしやすくなるかを教えてください。
              - *概要*: 特定のファイルではなく、全体の変更に関する高レベルの要約を80語以内で。
              - *ファイルごとの変更点*: ファイルとその要約のテーブル。スペースを節約するために、同様の変更を持つファイルを1行にまとめることができます。

            GitHubのプルリクエストにコメントとして追加されるこの要約には、追加のコメントを避けてください。
          summarize_release_notes: |
            このプルリクエストのために、その目的とユーザーストーリーに焦点を当てて、Markdown の形式で簡潔なリリースノートを作成してください。
            変更は次のように分類し箇条書きにすること:
              "新機能", "バグ修正", "リファクタリング", "デザイン", "テスト", "ドキュメント", "その他"

            例:
              - 新機能: 管理画面のユーザー一覧画面に、検索機能が追加されました
              - バグ修正: 変数の定義が漏れている問題が修正されました

            回答は50-100語以内にしてください。不要な空行を見つけたら削除しておいてください。

CodeRabbit はレビューコメント以外にも、
「このメソッドは〇〇をするメソッドで、〇〇のために追加されました」みたいな説明コメントを追加することが多いので
『改善点がない場合には絶対にコメントをしないでください。』 と強めに書いたのですが、
それでも説明コメントを入れてくることはそこそこありました。
（もちろん、この指示を入れていない場合よりはマシでしたが…！）

『レビューのしやすさ』 という項目をサマリとして表示させるようにしたのも工夫ポイントです。
点数付けが甘めで、８，９，１０点のどれかしか付かなかった印象ですので、
ここは指示をもう少し細かく書いてみるとなおよかったと思います。

実際に使ってみてどうだったか

レビューに関しては、効果的だと感じる瞬間が多くはありませんでした。

よりよいコードへの改善提案を適切にしてくれることはあまりなかったのですが、
以下のような「この変更で本当に合ってる？」というコメントは、
レビュアーに聞かれる前に説明することができ、やりとりを１往復減らせたので効率的だったと思います。

レビュー機能自体よりも、変更の概要についてをプルリクエスト内に書いてくれる機能が、
レビュー時の観点がジャンルごとにまとまっていてレビューしやすくなるため、チーム内で好評でした。

いくらかかったの？

うちのチームで１日に出るプルリクエストの数はおおむね５つ。
料金は、１プルリクエストに含まれるファイルの、ファイル全体における文字数や、
8k モデルを使うか、32k モデルを使うかでも料金が変わってくるので一概には言いにくいのですが、
gpt-4-32k モデルを使うとおおむね営業日あたり 2,000 円前後かかっていた印象です。（※日によって大きく上下します）

月で言うと 40,000 円くらいでしょうか。

これを踏まえて今後も使うかというと、
「さすがに高いかなー・・・」という結論に至りました。

8k モデルを使うと料金は安くできますが、
ファイルのコード量が 8k トークンを超えているとそのファイルのレビューはスキップされてしまいます。
どのモデルを使うかはコストと利便性を踏まえて熟考しなくてはなりません。

最後に

まだまだプルリクのレビューを生成AIに任せるのは、
料金や実用性の観点でちょっと早いかなという印象ではありました。

意外な副次的効果としては、
AIにどういうところをレビューしてもらいたいか書いたことが、
プルリクエストで自分がどういうところを見ているのかの言語化になったことです。

特に以下の点を指摘してください:
  - 誤解を招いたり、実態を正確に表していない命名があるか
  - 適度に変数を定義し自己ドキュメントされているか
  - 冗長な書き方のコードがないか
  # ... 以下略

インターンの方に「レビューって普段どういうこと見ていますか？」と聞かれたときに、
「そういえばこの YAML ファイルにまとまっている観点かも！」と説明が容易になりました。

AIへの指示を緻密にするほど実用性は高くなると思いますので、
CodeRabbit を使用してみた他の方の YAML ファイルも見てみるとおもしろそうに思いました！