どんな人向けの記事か
- コードレビュー（プルリク対応）によって、業務がひっ迫している人
- Open AI APIを利用してみたい人
- GitHub Actionsに興味がある人
- AIによって、業務を効率化してみたい人
導入の背景
社内にコードレビューを対応するレビュアーが少ないので、
レビュアーがレビューに時間を取られ、通常業務がひっ迫していた。
レビュアーを早急に増やすことが必要だったが、
時間と労力がかかるため、現実的では無い。
そこで、現在発展を続けているＡＩ技術を利用して、コードレビュー自動化を行うことにした。
CodeRabbit（ai-pr-reviewer）導入した背景
まず今回使用するCodeRabbit（ai-pr-reviewer）についての説明を簡単に行います。
公式の概要には以下のように書かれています。
CodeRabbit(ai-pr-reviewer)は、OpenAIのgpt-3.5-turboとgpt-4モデルを使用した、AIベースのGitHubプルリクエストのコードレビュアーとサマライザーです。
GitHubアクションとして使用するように設計されており、すべてのプルリクエストとレビューコメントに対して実行するように設定することができます。
一言で表すと、”AIレビュアーがGitHub Actionsを使用して、人の代わりにレビューすること”ができます。
また、今回CodeRabbit（ai-pr-reviewer）を選定した一番の理由に、簡単に導入できることがあります。
公式リポジトリからコードをyamlファイルにコピペして、Open AIのAPI keyを取得すれば、使用することができます。
精度を上げるためには、詳細にプロンプトを設計する必要がありますが、非常に簡単に始めることができます。
ただ、実際に導入するためには、注意点もあるので、一つずつ説明していきます。
参考記事：もう初回コードレビューはAIに任せる時代になった - CodeRabbit -
※本記事は、参考記事と重複している部分もあります。
導入手順
1. yamlファイルの作成
まず、公式リポジトリやGitHub Actionsを参照し、yamlファイルを作成します。
この時に、ワークフロー構文を参照して、pull_requestイベント時などの詳細構成も設定できます。
今回参照したコードでは、以下二つの部分を変更しました。
run-name, system message
run-name (※社内ランナーがある場合のみ)
社内で所有しているGitHub IPアドレス制限の適用をしている場合は、社内で使用しているランナーを登録する。
runs-on：ubuntu-latest → 社内ランナー
system_message(重要) 参照：action.yml
本記事で一番重要な部分になります。
プロンプトを設定することで、AIの性格を変更することができます。
社内のコーディング規約やディレクトリの構成を設定することで、社内ルールを守ったレビュアーを作ることができます。
また他の記事では、日本語でレビューするワークフローの設定を行っていますが、
本記事では、外国人とのやり取りやトークン毎の価格設定を考えて、プロンプトは英語で設定しております。
（日本語より、英語の方が少ないトークンで表現できるため。）
name: Open-Review
permissions:
contents: read
pull-requests: write
on:
pull_request:
paths:
branch:
# types: [opened, created]
pull_request_review_comment:
# types: [created, edited, deleted]
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: // 社内のランナーを設定
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: true
review_comment_lgtm: true
openai_light_model: gpt-3.5-turbo-0613
openai_heavy_model: gpt-3.5-turbo-0613
openai_timeout_ms: 900000 #15min
# language: ja-JP // 日本語の場合に設定
system_message: | # 社内のコーディング規約やディレクトリ構成を設定
If you have pull requests, please comment according to the following code conventions.
-How to declare
1.Variables and functions should be declared in camelCase.
2.Constants should be declared in CONSTANT_CASE.
3.Types and classes should be declared in PascalCase.
4.DynamoDB Attributes should be declared in snake_case.
5.File names should consist of lower-case letters and hyphens......
2. Open AIのAPI keys の設定
基本的にはこちらの記事を参照して作業を行いました。
ここで取得したOpen AIのAPI keys はGitHubシークレットに設定する必要があります。
もし社内で所有するGitHubがある場合は、組織シークレットに設定することで、リポジトリ毎に設定する手間が省けます。
3. GitHub にpushによる確認作業
最後に確認作業に移ります。
エラーを含むコードを記入したファイルと作成したyamlファイルをGitHubにpushすることで、正常に動作しているかを確認します。
何度か動作させて、先ほど説明したプロンプトを最適化していくことで、チューニングを行っていきます。
補足 ～Open AI APIについて～
Open AI APIは従量課金制のため、使用した分だけ支払うことになります。
公式の記載によれば、それぞれのモデル（GPT-4 , GPT-3.5など）は、1000トークンあたりの価格が決められています。
今回で言うと、設定されたプロンプト（入力）とAIのレビュー（出力）を合算したトークンにより、金額が決まります。
また、公式で、実際に文字を入力することで、トークン数を確認することもできます。
GPT-3.5を使用している場合は、レート制限により、リクエスト数が制限されてしまいます。
レート制限を上げる、テキストの整合性や論理性をより正確なものにしたい場合は、GPT-4を使用することお勧めします。
ただ、GPT-4は有償版になるため、無駄なトークンは削減する必要があります。
節約のためには、レビューのタイミングを制限することやプロンプト（入力）のトークン数を削減することが重要になります。
また、公式サイトでusage limit という制限があります。
デフォルトで125ドルで設定されており、上限に達するとAPIを使用できなくなるため、注意が必要になります。
その他の参照サイト：
【性能比較】GPT-3.5 vs GPT-4、違いはどこにある？
OpenAIのAPIを使うならUsage Limit(=使用制限)に注意
まとめ
今回は、CodeRabbit（ai-pr-reviewer）により、コードレビュー自動化を行いました。
プロンプトによりレビューの精度を高めることで、よりよいAIレビュアーを設計し、今後の業務の効率化を図ってみてください。