Paytner Tech Blog

ペイトナーのテックブログです

AIレビュー、実際使ってみてどうなん?〜AIレビュー導入して1ヶ月

はじめに

ペイトナーファクタリング事業部でEMをやっている 脇田(@shimpeee_)です。

チームの開発生産性向上のため、この一年多くの取り組みを行なってきました。活動内容はこちらの記事にまとめています。

paytner.hatenablog.com

今年実施した取り組みの一つとして、チームにAIコードレビューツールである「CodeRabbit」を導入しました。AIコードレビューだけで1記事書けそうだったので、別記事として書いています。

導入から、1ヶ月ほどが経過しました。
結論としては、費用対効果高くてめちゃくちゃいいね!という手応えなので、今後もがんがん使っていきたいと思っています。
実際使ってみてどうなの?という所感をつらつらと書いていきます。

coderabbit.ai

導入背景

Xのタイムラインで『もう初回コードレビューはAIに任せる時代になった - CodeRabbit -』の記事を見たのがきっかけです。

zenn.dev

僕のいるペイトナーファクタリング事業の開発チームは、ジュニア〜ミドルメンバー比率が高く、一部のシニアメンバーにコードレビューの負荷が偏っているのが現状です。

中長期での根本解決策としては、シニアメンバーの採用や育成によるボトムアップが選択肢となってきますが、短期的にはレビュー負荷を下げる施策を積み上げることで生産性改善を行っています。

ChatGPTやGitHub Copilotの登場により、アウトプット速度にブーストがかかり、今後レビュワーの負荷がさらに高まっていくのは避けられません。レビューに関してもAIの力を使うことができれば、一気に状況打開できるのではないか・・!?と期待に胸を膨らませました。

導入時の注意点

CodeRabbit には、GitHub Actionsで利用するOSS版(coderabbitai/ai-pr-reviewer)と、有料のPro版(https://coderabbit.ai/) があるので混同しないよう注意が必要です。

基本機能としてはほぼ同じで、相当ヘビーな使い方をしない限りはOSSの方がコストメリット大きいと判断し、うちで導入したのはOSS版の方です。

さくっと検証

まずはCodeRabbitがどれくらいのポテンシャルを持っているのか、個人のリポジトリで試してみることにしました。

モデルは GPT-3.5 と GPT-4 の2種類から選べます。 軽く触ってみた感覚としては、GPT-3.5ではあまり賢くなく実用は難しそうでしたが、 GPT-4 であればかなり細かいところまで見てくれて、十分実用に乗せられると感じました。

気になるコスト面ですが、何度か自分で動かしてみた実績と冒頭紹介した記事の内容にて大きな乖離はなく、1レビューあたり平均0.3ドルほどでした。

まずはコストを抑えて初回レビュー時のみ CodeRabbit を走らせるとしても、GPT-4でAPIを動かすためのChatGPTの有料化料金(20$/mon)とOpenAI API の従量課金分を合わせても トータルコスト $50 ほどの想定です。

この安さなら費用対効果も大きそうということで、CTOも二つ返事で導入OKしてくれました。

効果

実際にチームに導入し運用開始して1ヶ月ほどが経過しました。メンバーからも、「想像より賢いな」「人間の仕事なくなるぞこりゃ・・・」といった驚きの声が上がるほど、手応えを感じています。

レビュー工数削減

レビュー工数の削減に大きく貢献してくれています。正直、導入前の期待以上と言えます。

導入前に一番期待していた部分としては、「実装者のスキル関係なく、注意すれば防げたよね」というケアレスミスレベルの軽微な指摘を拾ってもらうことです。

リンターやフォーマッター等を入れていても、それらでカバーしきれないタイポや不必要な空白・インデント等の指摘はどうしても一定発生してしまいます。軽微なミスをレビューで指摘するのは、レビュワー・レビュイー双方にとって辛いことです。

軽微な指摘はCodeRabbitに任せ、本来集中すべき設計やビジネスロジック等を人間が見るようになればいいなと思っていました。

実際使ってみると、ケアレスミスに関してはかなりの精度で拾ってくれている印象です。たまに明らかな英語スペルタイポなのにスルーしたりと完璧ではないではないですが、それでも十分な効果です。

さらに、ケアレスミスだけでなく、セキュリティやパフォーマンス、保守性の観点においても指摘してくれます。メンバー全員抜けていたような重要なセキュリティ観点でのレビューコメントをもらった時には、思わず「あんた賢いな」と返事の来ないAIに向かってコメントを返したりしています。

「ここ、考慮できる?大丈夫?確認してね」のようなレビューコメントをCodeRabbitからたくさんもらいます。考慮した上であえてその実装にしている場合は、「ちゃんと考慮済みだよ、大丈夫」と実装者がコメントを返します。その一連のやりとりをレビュワーが見ることで、「ああ、考慮したうえでこの実装なんだな」と、コンテキストの補足になるプラスの副作用もあります。

24時間365日動いてくれる

チームには、平日の夜や土日が稼働のメインである副業メンバーもいます。彼らのPRに対しては、お互いの稼働時間が合わないのでレビュー⇄レビュー修正のサイクルがどうしても遅くなりがちです。

しかし、当たり前ですがAIなら24時間365日働いてくれます。いつ何時でもAIによる一次レビューを受けられるのは、非常にありがたいです。

分かりやすいレビューコメント

人間によるレビューだと、指摘された側が指摘内容を十分に理解できず、「何を指摘されているのか分からない」「なぜ指摘されたのか分からない」などが発生し、互いの認識を擦り合わせるための追加のコミュニケーションが必要になることがしばしば発生します。

CodeRabbit による指摘では、それがほとんど発生しないです。 AIには体力の概念がないので、毎回200~300文字ほどの文字量で丁寧にコメントしてくれます。おかげで、「何を指摘されているのか分からない」ということは観測する限り発生していない気がします。すごいです。

自分の意見を齟齬なく伝えることが大事だと分かっていても、人間であれば毎回ここまで丁寧にはできないのが正直なところだと思います。逆にいうと、齟齬なく伝えるには1つのレビューコメントであっても200〜300文字くらい使う覚悟が必要ということですね。。

課題

今後も継続して使っていきたいと思えるほどの十分すぎるメリットはありますが、いくつか課題もあります。

自分たちのコーディングルールに反する指摘

当然CodeRabbitは我々のコーディングルールを知らないので、コーディングルールに反する指摘もあります。

Web上のドキュメントを読み込んでレビューの制約に加えることができるかをCodeRabbitのDiscordコミュニティで質問したところ、「そのように学習しているはずなので、いけるはずだ!」という返答がきました。

コーディング規約のドキュメントを外部公開し、CodeRabbitに読み込ませて規約に沿ったレビューができるかどうかを、これから試すところです。

文脈は読み取れない

まあ、さすがにそれは無理だよね、という感想。ここは人間が見るべきポイントです。

どちらかというと、過剰気味

細かくレビューしてくれるのはありがたいのですが、基本的に指摘内容は厳しめで過剰だなという印象です。拾ってほしい観点を見逃すよりは何倍もマシなのですが。

細かいチューニングは必要そうです。

運用方針

うちのチームでは、以下のような設定で運用しています。

name: ai-pr-reviewer

permissions:
  contents: read
  pull-requests: write

on:
  pull_request:
    types: [labeled, unlabeled]

concurrency: # 同時に2つのジョブが走ったら進行中のジョブをキャンセルさせる機構を使用し、ラベルを外すと処理がキャンセルされるようにしている
  group: ${{ github.repository }}-${{ github.event.number || github.head_ref || github.sha }}-review
  cancel-in-progress: true

jobs:
  review:
    runs-on: ubuntu-latest
    if: github.event.label.name == 'ai-review' && github.event.action == 'labeled' # 付与されたラベルが ai-review だった場合のみ実行
    timeout-minutes: 30
    steps:
      - uses: coderabbitai/openai-pr-reviewer@latest
        env:
          GITHUB_TOKEN: ${{ secrets.AI_PR_REVIEWER_GITHUB_TOKEN }}
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        with:
          debug: false
          review_simple_changes: false
          review_comment_lgtm: false
          openai_light_model: gpt-4-1106-preview
          openai_heavy_model: gpt-4-1106-preview
          openai_timeout_ms: 900000 # 15分.
          language: ja-JP
          system_message: |
            あなたは @coderabbitai(別名 github-actions[bot])で、OpenAIによって訓練された言語モデルです。
            あなたの目的は、非常に経験豊富なソフトウェアエンジニアとして機能し、コードの一部を徹底的にレビューし、
            以下のようなキーエリアを改善するためのコードスニペットを提案することです:
              - ロジック
              - セキュリティ
              - パフォーマンス
              - データ競合
              - 一貫性
              - エラー処理
              - 保守性
              - モジュール性
              - 複雑性
              - 最適化
              - ベストプラクティス: DRY, SOLID, KISS
              - タイポ
              - マジックナンバー
              - 統一感のない、もしくは無意味な空白やインデント
            以下については、コメントをしないでください
              - ポジティブで、問題点のない修正
          summarize: |
            次の内容でmarkdownフォーマットを使用して、最終的な回答を提供してください。

              - *ウォークスルー*: 特定のファイルではなく、全体の変更に関する高レベルの要約を80語以内で。
              - *変更点*: ファイルとその要約のテーブル。スペースを節約するために、同様の変更を持つファイルを1行にまとめることができます。

            GitHubのプルリクエストにコメントとして追加されるこの要約には、追加のコメントを避けてください。
          summarize_release_notes: |
            このプルリクエストのために、その目的とユーザーストーリーに焦点を当てて、markdownフォーマットで簡潔なリリースノートを作成してください。
            変更は次のように分類し箇条書きにすること:
              "New Feature", "Bug fix", "Documentation", "Refactor", "Style",
              "Test", "Chore", "Revert"
            例えば:
            ```
            - New Feature: UIに統合ページが追加されました
            ```
            回答は50-100語以内にしてください。この回答はそのままリリースノートに使用されるので、追加のコメントは避けてください。

system_message にプロンプトを書きます。現状のプロンプトは非常に抽象的な指示しかしていませんが、十分実用できるレベルです。

冒頭紹介した記事と変えているポイントは、レビューのトリガーです。

うちのチームでは、特定のラベルが付与されたらCodeRabbitが動くようにしています。

on:
  pull_request:
    types: [labeled, unlabeled]

初回レビュー時は、自動でラベルが付与されるようGitHub Actionsで設定しています。

初回レビュー以降も、手動でラベルを付与することで開発者の任意のタイミングでAIレビューを実行できます。

多少コストはかさみますが費用対効果は十分高いと分かったので、レビュー負荷軽減・開発速度向上のため、初回レビューだけでなく何度でも実行しましょうという方針にしています。

実際にかかったコスト

気になるコスト面ですが、導入とほぼ同時期にOpenAIから発表されたモデル「GPT4 Turbo」 が従来のGPT4の 1/2~1/3 ほどの安さで、当初想定していたよりも2〜3倍ほど多く使っていますが GPT4 Turbo のおかげでコストは当初の想定通りにおさまっています。

今後の展望

1ヶ月ほど運用してみての所感としては、費用対効果は非常に高く、今後もガンガン使っていきたいと思います!

(補足)ソースコードをクラウドサービスのAIに投入するリスクに対する会社としてのスタンス

ソースコードをクラウドサービスのAIに投入するリスクに対しては、ネット上でも賛否の議論が巻き起こる話題です。

ペイトナーとしては、ゼロリスクは存在しないという前提で、CodeRabbitの プライバシーポリシー 4.2項を根拠に、サービスに対して最低限の信頼をし、リスク以上のリターンがあると捉え導入することに決めました。

4.2 No Usage for Model Training


Neither CodeRabbit nor OpenAI use the data collected as part of the code review to train, refine, or otherwise influence our models or any third-party models. Our commitment is to use the data solely for the purpose of reviewing the code in accordance with the user's request, and no other utilization takes place. Note: Open-source projects is an exception. We use OSS to train our systems.

(以下DeepL翻訳)


4.2 モデルトレーニングへの使用禁止


CodeRabbitとOpenAIのいずれも、コードレビューの一環として収集したデータを、当社モデルまたはサードパーティモデルのトレーニング、改良、またはその他の影響を与えるために使用しません。私たちのコミットメントは、ユーザーの要求に従ってコードをレビューする目的のみにデータを使用することであり、それ以外の利用は行われません。

注:オープンソースプロジェクトは例外です。私たちのシステムをトレーニングするためにOSSを使用します。

coderabbit.ai

終わりに

最後まで読んでいただきありがとうございました!!!

ペイトナーに少しでも興味を持っていただけましたら是非、ペイトナー 採用情報 をご覧ください!!

現在ペイトナーでは、以下ポジション積極採用中です!!!

  • リードエンジニア

paytner.co.jp