MENU

AWSのサービスを使ってコードレビューしてみる

アフィリエイト広告を利用しています

読みたい場所へジャンプ

はじめに

みなさんは生成AIは使っていますでしょうか?最近は検索結果にもAIによる解説画面が一番上に出てきたりと、今や自然と使用する環境になってきてますね。
業務でも積極的にAIを使用する機会が増えてきました。エンジニアだと、AIを利用したい業務の一つに「コードの添削」があります。Githubなどでコード管理をしていて、PRを出されたときに、レビューする箇所が多いと大変なので、見落としがないようにAIにレビューしてもらうということです。今回は、AWSの生成AIサービスの一つである「Bedrock」を使用したGithub上のPRレビューをさせる方法について書いていきます。

Bedrockとは

Bedrockとは、主要なAI企業やAWSが開発したAIの基盤モデルを、APIを介して生成AIアプリケーションを構築・運用できるサービスです。テキスト生成や画像生成、チャットボットなどの生成AIサービスを利用することができます。

ファンデーションモデルを使用してジェネレーティブな AI アプリケーションを構築 — Amazon Bedrock — AWS

基盤モデルもいくつか種類が揃っています。(Geminiはありません)

利用する基盤モデルが「リクエスト可能」であれば、モデルのリクエスト許可申請を行い、少し待つとアクセス許可されます。具体的な開始方法は以下です。
Amazon Bedrock の開始方法 – Amazon Bedrock

Bedrockの基盤モデルが使えるようになったら、今度はGithubとの連携準備です。
連携には、AWSのIAMロールでのBedrock API使用許可が必要ですが、OpenID ConnectでGithub ActionsからAWSアカウントに対して認証認可することで実現できます。
IAMロールは下のような感じです。API使用を許可するGithubリポジトリやユーザの制限もかけられます。

{
    “Version”: “2012-10-17”,
    “Statement”: [
        {
            “Sid”: “RoleForGitHubActions”,
            “Effect”: “Allow”,
            “Principal”: {
                “Federated”: “arn:aws:iam::AWSaccount:oidc-provider/token.actions.githubusercontent.com
            },
            “Action”: “sts:AssumeRoleWithWebIdentity”,
            “Condition”: {
                “StringEquals”: {
                    “token.actions.githubusercontent.com:aud”: “sts.amazonaws.com
                },
                “StringLike”: {
                    “token.actions.githubusercontent.com:sub”: [
                        “repo:repogitry-name:*”
                    ]
                }
            }
        }
    ]
}

レビュー方法

コードレビューさせるために、以下のPublic Github Repogitry を使用します。
セキュリティ的に気になったりや独自カスタマイズしたい場合は、自身で管理しているプライベートGithub上にフォークして使いましょう。

GitHub – tmokmss/bedrock-pr-reviewer: AI-based Pull Request Summarizer and Reviewer with Chat Capabilities.

上記の詳細は以下になります。
・Github上でプルリクイベント発生または、レビューコメントが書かれた際に発動します。(issue commentでは発動しません)
・レビューを無効にしたい場合は、「/reviewbot: ignore」をPR descriptionに追記することで可能
・日本語に変更可能。
・system_messageは、review_botへの指示が可能。
・summarizeは、PRの要約をコメントで追記。書き方を指定可能。
・summarize_release_notesは、PR descriptionに追記で、リリースノートを記載。書き方を指定可能。
・review_file_diffで、レビュー時のふるまいを指示可能。

レビューカスタマイズ例

summarize_release_notes: |
            以下の構成でリリースノートを作成してください:
            1. **概要**: プルリクエストの主な目的(100字程度)
            2. **詳細な変更点**: 各ファイルや機能ごとの具体的な変更内容(箇条書き)
            3. **技術的変更点**: バックエンド/フロントエンドの実装詳細(該当する場合)

            コードの変更内容を詳細に反映し、500字以内にまとめてください。
            日本語で記述し、専門用語は適宜英語で補足してください。
review_file_diff: |
            レビューを行う際には以下のガイドラインに従ってください:

            – 各変更に対して具体的な問題点を指摘し、一般的な称賛や説明は避ける
            – 賞賛のコメントは一切せず、改善点に焦点を当てる
            – 問題を見つけた場合は、その影響と修正案を明確に説明する
            – コードの改善点がある場合は、具体的なコード例を提示する
            – 意図した変更かどうかの確認は避ける
            – 変更の目的を尋ねたり、なぜこの変更をしたのかを推測する質問は避ける
            – 差分外の宣言や定義も考慮し、差分のみで未知の変数と判断しない
            – 以下のような潜在的なバグや問題点を積極的に指摘してください:
              – エッジケースの未処理
              – 例外処理の漏れ
              – 境界値の問題
              – 並行処理の問題(競合状態、デッドロックなど)
              – メモリリーク
              – パフォーマンスの問題(不要なループ、非効率なアルゴリズムなど)
              – セキュリティの脆弱性
              – 型の不一致やNullポインタの可能性
              – API使用の誤り

このあたりを独自にカスタマイズして、実際にレビューをさせるたものがこちらです。

リリースノート
PR要約

コードレビューはこんな感じです。

このような形で、AIによるコードレビューが実現できます。ただ、時より誤ったレビューをしていたり、不要なレビューコメントをしていたりするので、最終的に人の目による確認は必要です。カスタマイズや学習により改善はしてけるとは思います(;^ω^)

さいごに

今回は、AWSの生成AIサービス利用の一例をご紹介しました。
AIを活用したサービスは、ビッグデータやディープラーニングの登場によって日々進歩し、生活に取り入れられています。AIが自動でやってくれることで、仕事やプライベートでも快適になりましたが、「AIが絶対に正しいわけではない」ことを意識し、最終的に人間が確認、管理することが必要です。
勿論便利なサービスなので皆さんも是非、AIを正しく理解して活用してみてください。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

社会人10年目、IT業界6年目のインフラエンジニア
大学では数学系を専攻し、新卒で鉄道会社の電気技術職に従事
もっと自身が活躍できるところへと思い転職、現在に至る
Ansible、AWS CDK、TerraformとIaC案件の経験が多め

コメント

コメントする

読みたい場所へジャンプ