アフィリエイト広告を利用しています
はじめに
みなさんは生成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上でプルリクイベント発生または、レビューコメントが書かれた際に発動します。(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使用の誤り
このあたりを独自にカスタマイズして、実際にレビューをさせるたものがこちらです。


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

このような形で、AIによるコードレビューが実現できます。ただ、時より誤ったレビューをしていたり、不要なレビューコメントをしていたりするので、最終的に人の目による確認は必要です。カスタマイズや学習により改善はしてけるとは思います(;^ω^)
さいごに
今回は、AWSの生成AIサービス利用の一例をご紹介しました。
AIを活用したサービスは、ビッグデータやディープラーニングの登場によって日々進歩し、生活に取り入れられています。AIが自動でやってくれることで、仕事やプライベートでも快適になりましたが、「AIが絶対に正しいわけではない」ことを意識し、最終的に人間が確認、管理することが必要です。
勿論便利なサービスなので皆さんも是非、AIを正しく理解して活用してみてください。

コメント