今年のアドカレ2本目です！今回は、Claude Code Actionを活用したAIレビューの導入について紹介します！
普段はZOZOTOWNのマイクロサービス基盤をEKSで構築・運用しているSREです。
今回はその自動レビューの設計やPoCの結果を交えた分析などをしようと思います！
この記事はコスト感の把握やActionsにAIを組み込む試行錯誤の記録として発信しています。AIの精度を向上させる術は確信できるものでなく感覚的で、具体的なプロンプト文や活用術はこの記事では参考にならないと思うのでご了承ください🙏
背景
ZOZOTOWNのマイクロサービス基盤はkubernetesやAWSリソース、監視で用いているdatadogの設定などの多くが1つのリポジトリで運用されており、様々なチームがそのリポジトリを利用しています。プラットフォーム基盤に詳しいSREでも完璧にキャッチアップするのが難しいほどの膨大さおよび複雑さなので、kubernetesやCloudFormationの設定ミスがサービス障害およびセキュリティインシデントにつながるリスクが課題となっています。
このような設定ミスによる障害の未然防止やセキュリティリスクの低減に関しては、kubernetesエコシステムのKyvernoでリソース設定の標準化と強制を行なっていました。しかし、ルールベースでこの制御を行うには限界があり、やはり人の目をじっくり通したレビューが必要ですが、100%正しいレビューを多忙の中出せる保証もありません。
そこで、社内でも絶賛AI活用ブームがきており、何か障害を未然に防ぐ仕組みを構築できないかと考えてClaude Code Actionの導入検討に至りました。
Claude Code Actionは、GitHub ActionsのワークフローにClaudeのAIエージェントを組み込み、コードレビュー・バグ修正・PR作成などを自動化できる機能です。
PRに対して自動でレビューコメントを投稿したり、変更内容の問題点を検出したりすることができます。
Claude Code Actionの導入
ここからは公式ドキュメントを参考にAmazon Bedrockを用いたClaude Code Actionの導入方法を紹介します！
Claude Maxプランのトークンを利用してActionsを動かす方法も存在しますが、Maxプランを複数人で共用するのはNGで、利用規約にも明記されています。
（You may not share your Account login information, Anthropic API key, or Account credentials with anyone else. You also may not make your Account available to anyone else.）
そのため、個人で登録しているMaxプランのトークンをGithubの共用リポジトリに登録すること自体も好ましくないのでは？と考えています（あくまで個人的な意見です）以上の理由から、金額は嵩みますがAmazon Bedrockを利用しています。
1. Bedrock Inference Profileの作成
まず、Claude Code Actionでmodelを利用するためのProfileをAWSアカウント上に作成します。
公式ドキュメントでは下記のようにモデル名を直接指定して利用していますが、その方法を用いる場合Inference Profileの作成は不要です。
claude_args: '--model us.anthropic.claude-sonnet-4-5-20250929-v1:0'
今回金額感の把握のためコストタグを利用したかったので、新しいInference ProfileをCloudFormationで作成しました。
InferenceProfilePlatformGHAClaudeSonnet4:
Type: AWS::Bedrock::ApplicationInferenceProfile
Properties:
InferenceProfileName: "platform-gha-claude-sonnet-4-inference-profile"
ModelSource: !Sub "arn:aws:bedrock:ap-northeast-1:${AWS::AccountId}:inference-profile/apac.anthropic.claude-sonnet-4-20250514-v1:0"
Tags:
- Key: Name
Value: "platform-gha-claude-sonnet-4-inference-profile"
- Key: CostService
Value: "develop-support"
- Key: CostTeam
Value: "platform-team"
CloudFormationの実行履歴に新しいInference Profileが表示されるので記録しておいてください。
2. OIDC Provider認証の設定
GitHub ActionsからBedrockに接続するため、OIDC Provider認証用のIAMロールを作成します。
IDプロバイダーの追加がまだの場合こちらを参考に設定してください。
IAMRoleZozoPlatformGha:
Type: AWS::IAM::Role
Properties:
RoleName: platform-gha-assume-role
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action: sts:AssumeRoleWithWebIdentity
Principal:
Federated: !Sub 'arn:aws:iam::${AWS::AccountId}:oidc-provider/token.actions.githubusercontent.com'
Condition:
StringEquals:
token.actions.githubusercontent.com:aud: "sts.amazonaws.com"
ForAnyValue:StringLike:
token.actions.githubusercontent.com:sub:
- !Sub 'repo:${PlatformRepositoryName}:pull_request'
ManagedPolicyArns:
- arn:aws:iam::aws:policy/AmazonBedrockFullAccess
Github Actionsからアクセス許可するリソースと、アクセスできるリポジトリおよびActionsのトリガーを設定します。今回はPRでレビューしてもらうことを想定しているので、pull_request でトリガーされたGithub ActionsのみBedrockのアクセスを許可するIAMロールを作成しました。
3. GitHub Appsの設定
GitHub Appsをリポジトリに追加します。
# Claude Codeのターミナルで実行
/install-github-app
表示されるGitHubの画面で対象リポジトリを追加してください。
（これはClaudeがGithubで自由に動き回るための機能で、最終的に自分が作成したworkflowではこの機能は使いませんでした）
4. GitHub Secretsの登録
1で発行したInference ProfileのARNをGitHub Secretに登録します。
5. Workflowの作成
Claude Code Actionを呼び出すworkflowを作成します。以下は簡単な例です。具体的にどういうworkflowを組んだかは後述のworkflow設計で詳しく記載します！
name: Claude Code Review
on:
pull_request:
types:
- labeled
jobs:
claude-review:
if: contains(github.event.pull_request.labels.*.name, 'claude-review-ci')
runs-on: ubuntu-latest
timeout-minutes: 30
permissions:
id-token: write
contents: read
pull-requests: write
steps:
- uses: actions/checkout@08eba0b27e820071cde6df949e0beb9ba4906955 # v4
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@a03048d87541d1d9fcf2ecf528a4a65ba9bd7838 # v5
with:
role-to-assume: arn:aws:iam::${{ secrets.AWS_ACCOUNT_ID }}:role/platform-gha-assume-role
aws-region: ap-northeast-1
- name: Run Claude Code Action
uses: anthropics/claude-code-action@8a1c4371755898f67cd97006ba7c97702d5fc4bf # v1
with:
claude_args: |
--max-turns 30
--model "${{ secrets.BEDROCK_CLAUDE_SONNET4_INFERENCE_PROFILE_ARN }}"
prompt: |
このPRの変更内容をレビューしてください。
特にサービス停止やセキュリティリスクにつながる変更がないか確認してください。
workflow設計
ここからは具体的にどのようなworkflowを作成したのかを紹介します。
実行条件
コストが未知でビビっていた＆PoC結果の追跡のため、以下の条件のみで実行するようにしました。
- PRに特定のラベルが付与されている
- 本番環境にCloudFormation・k8sの差分がある
push毎にworkflowが走ると料金がかさむため、ラベル付与をトリガーとすることで意図的な実行のみに限定するようにしました。
workflow構成
workflowは3つのジョブで構成しました。
- PRで変更されたファイルを検出し、差分のある管轄チームを特定
- k8s・cfnディレクトリ配下の変更有無やファイルリストを抽出
- Claudeによるレビューを実行
1と2のステップをGitHub Actionsで完結させました。
ただ、AIに「PRの差分を見て、どのチームの変更か判断して、適切なレビューをして」と丸投げすることも可能ですし、うまくやってくれると思います。
しかし、AIがたまに披露してくれる出力ガチャ的なものがあるため、差分のあるファイルを特定したり特定のディレクトリ配下の変更を検出するといった決定論的な処理は、従来通りActionsで実行した方が確実です。
また、Bedrockは入力トークン量でも料金が発生します。PRの全ファイルリストや変更内容をすべてAIに渡すのではなく、Actionsで必要な情報を絞り込んでからAIに渡すことで、コストを抑えられます。
サブエージェントによる効率化
上のようなworkflowに設計した理由はもう1つあります。Claude Code Actionでは、メインのエージェントから複数のサブエージェントを起動できます。この機能を活用し、変更内容に応じて専門化したエージェントがレビューを担当する設計にしました。
背景でも述べた通り、ZOZOTOWNのプラットフォーム基盤用リポジトリは膨大です。k8sのベストプラクティス、CloudFormationの注意点、各チーム固有のルール...これらすべてをプロンプトに含めると、トークン消費が膨大になります。また、関係ない情報が多いとAIの判断精度も下がるらしいです。
そのため、k8sの専門家、CloudFormationの専門家、各チームの専門家としてそれぞれ振る舞わせた方が、より深いレビューが期待できます。具体的には、上の1,2のステップでどこに差分があるのかを読み取り、下記のようにサブエージェントを起動するようなメインエージェント用のプロンプトを動的に生成します。
- k8sに差分がある場合 → Kubernetes用のサブエージェントが起動
- cfnに差分がある場合 → CloudFormation用のサブエージェントが起動
- 各チーム固有のコンテキスト（<チーム名>.md）が存在すれば、それも読み込む
各チームには過去に発生した障害の事例と教訓やチーム固有のデプロイルールなどを埋めてもらうことを想定しています。
PoC結果を受けての感想
上記のworkflowをとりあえず2週間程度試運転してみました！
その結果ですが、意外に金額がかかっていなかったです。
Claude Code Actionですが、実行後Github Actionsのworkflow summaryにかかった金額を出力してくれます。
PoCを始める前も大体1回0.5ドル程度だったので、導入時にかなり実行回数を絞って検証していました。ただ、AWSのCost Explorerを確認すると、1回あたり約0.1ドルしか使われていませんでした。（うれしい誤算）
本番環境に差分があるかつ人間が作成したPRは2週間で210個だったので、強制実行するように変更したとしても1ヶ月で0.1ドル × 420 = 42ドルと雑に見積もれます。
サービス障害を引き起こして売り上げがなくなると考えたら、まあ安いかなと言った感想です。
今後は、CI/CDへの本格的な組み込みを進め、リリースのガードレールとしての活用を目指していきます。