この記事はnote株式会社 Advent Calendar 2023の23日目の記事です。

こんにちは、あたまがきんに君です。今日は珍しく、ITエンジニアとしての記事を書こうと思います。トピックは、弊チームが抱えていたPRレビューの課題感とその解決手段としてPR-Agentを導入した話をします。

PRレビューの課題

レビュー待ちのPRがリリースのボトルネックにならないようにしたい

私が作成したレビュー待ちのPRは一番多い時で23個溜まっていました。自分以外のチームメンバーが2人で、リリース承認までに必要なレビュワーが2人だったので、チーム総動員でPRのレビューをしなければなりませんでした。その結果、レビュワーのリソースが不足してしまいどんどんPRが溜まってしまいました。

PRが溜まってしまうということは、リードタイムやデプロイ頻度に負の影響を与えているので、開発生産性の観点からは好ましくない状態になります。

また、遠い昔のPRにレビューコメントをいただいたとしても、思い出すことにも労力が必要になるため、個人としても生産性が下がってしまいます。

ケアレスミスによって発生するコミュニケーションを減らしたい

レビュワーがせっかく時間を割いてくれたのに、こちら側のケアレスミス（テストの追加し忘れや、文言のミスやtypoなど）で差し戻されて、再度レビューをお願いすることがたまにありました。

気をつけていれば必要のないコミュニケーションですが、セルフレビューだけではケアレスミスは無くしきれないと思います。また、こういったケアレスミスの指摘に関しては、レビュワー側も気を遣ったりするので、コミュニケーションコストが意外と高かったりします。

PRのディスクリプションを書く時間を削減したい

弊チームはそれぞれが異なる領域の機能開発をしていたので、レビュー負荷が高かったです。そのため、少しでもレビュワーのリソースを削減するためにPRをできるだけ細かく分割しつつ、ディスクリプションを丁寧に書く必要がありました。

そうなると、PRのディスクリプションを書く時間が増えるので、なんとかこの時間を減らすことができれば良いなと思っていました。

そこでPR-Agentの導入を検討

PR-Agentとは

Codium AI によってオープンソースで開発されている 大規模言語モデル を使ったプルリクエストを便利にするためのAIツールです。PRの自動レビューやレビューコメント追加、ディスクリプションの作成、コード提案などの様々なタスクが実行できます。

要するに、今までは0次レビュー（セルフレビュー）までは自分でできましたが、1次レビューまで自分で完結できるようになります。

これを提案して、リリース承認に必要なレビュワーの人数を1人減らせるところまで持っていけたら最高だなと思っていました。

実際に手元で試してみてAIに指摘されたこと

• formの方がstringよりemailの方が適切だよ

• エラーハンドリングがあった方が良いよ

• エラーメッセージ等はハードコードするんじゃなくて設定ファイルから読んだ方がいいよ

• コメントアウトに誤字があります

• 支払い方法の表示ロジックが複雑になっています。リファクタした方がいいかも。

• 正規表現が用いられているけどちゃんとテストしたの？

思ったよりちゃんと指摘してくれるし、どんなに情けないミスを指摘されても、機械に言われるとノーダメージってところが良いですね。

PR-Agentの導入について

こちらの記事を参考にGithub Actionsのself-hosted-runnerで動かすことにしました。

上記の記事ではPR作成時に実行されるようですが、弊社ではトリガーはPrReview, PrDescribe, PrImproveというラベルを付与したタイミングにしました。またレビューやディスクリプションの作成、コード提案が完了したときは、付与したラベルを削除して、PrReviewDone, PrDescribeDone, PrImproveDoneというラベルを付与するようにしました。

jobs:
  pr_agent_review:
    runs-on: self-hosted
    if: contains(github.event.pull_request.labels.*.name, 'PrReview')
    permissions:
      issues: write
      pull-requests: write
      contents: write
    name: Run AI source code review by PR-Agent
    steps:

      (中身は省略)

      - name: Remove PrReview label
        if: always()
        uses: actions-ecosystem/action-remove-labels@v1
        with:
          labels: PrReview

      - name: Add PrReviewDone label if succeeded
        if: success()
        uses: actions-ecosystem/action-add-labels@v1
        with:
          labels: PrReviewDone

PR-Agent導入における検討事項

PR-Agentに限らず、生成AI系のツールを導入する上で考慮しなければならない点がいくつかあります。

AIに読み込ませる情報（今回はソースコードやブランチの情報）が情報セキュリティのガイドラインにおいてどのレベルの秘匿情報になるか

• 弊社で定められているガイドラインでソースコードが何情報に当たるかをチェック

• 生成AI系のツール導入のガイドラインがあったので目を通す

• 情報セキュリティ部門に確認

OpenAIのAPI Keyをどのように管理するかや、万が一漏れた場合の対処をどうするか

• Azure OpenAIを利用すればアクセス制限やRate Limitが設定できる

• 万が一漏れても、github actionsのself-hosted-runnerのIPでアクセス制限をかけるようにするから問題ない

費用対効果

• 1ヶ月あたりのPR数と1PRあたりに何回リクエストするか

 -> ここはgithubの指定期間にマージされたPRを検索すれば出ます

• 1回のリクエストあたりのトークンサイズはどれくらいか

 -> PR-AgentはMaxのトークンサイズが設定できます

• どんなうまみがあるか

-> リリース承認に必要なレビュワーを1人減らすという方針で考えていたので、レビュワーのリソースを半減できると考えたらだいぶお得

今後の課題

まずは使ってもらって、声を集めて一つずつ改修していくことをやりたいです。

今見えている範囲で言えば、設定ファイルからカスタム指示を出せるので、プロンプトをカスタマイズしていきたいのと、PRのディスクリプションのアウトプットフォーマットを弊社のPRディスクリプション作成のガイドラインにフィットさせたいなと思っています。

あとは、ドメインや弊社の実装ルールを加味した上でのレビューは返ってこないので、究極は弊社のコードを全て学習した上でレビューを行ってくれるAIレビュワーを作りたいですね。

最後に

実は、PR-Agentを導入しようとしていたタイミングでちょうど、リリース承認に必要なレビュワー数を1人にしようという方針になったのでPR-Agentの導入とは関係なく私の目的は達成されました。

ただ、レビュワーの責任が増えてしまったり、見落としがあったり、ケアレスミスによって発生するコミュニケーションを減らせたりすると思うので、そういった部分のカバーにはなると思います。

皆さんもぜひ導入を検討してみてください。