AWS CodeArtifact CodeGuru 補完運用 Vol4 シリーズ完結 Terraform

1. この記事について

1-1. 本記事のゴール

本記事は aws-code-family シリーズ完結弾として、Vol1-3 で構築した CI/CD パイプラインに欠けていた 2 つの補完運用を追加する。

第一に CodeArtifact による社内パッケージレジストリの構築だ。npm/pip/maven/nuget のパッケージを組織内で一元管理し、upstream proxy 経由で外部レジストリを安全にキャッシュする実装を Terraform + AWS CLI + コンソールの 3 形式で完走する。upstream 設定・IAM Token 12時間期限への対処・CodeBuild 自動認証統合まで踏み込んだ実務レベルの実装を示す。

第二に CodeGuru Reviewer/Profiler による継続的な品質改善だ。Reviewer は PR ごとに CWE/OWASP ベースの静的解析を自動実行し、Profiler は本番 Lambda/ECS のフレームグラフで CPU ホットスポットを可視化する。2サービスの棲み分けと料金設計まで解説する。

さらに Bedrock Agents (WP:1992) との使い分け軸を §7 で提示し、「定型ルール適用は CodeGuru / カスタム AI ロジックは Bedrock」という選定指針を確立する。Action Group 統合パターンと CodeGuru の CWE ルール体系の比較で、現場の選択判断を明確にする。

本記事を読み終えたとき、読者は Vol1-4 チートシートを片手に、設計 → ビルド → デプロイ → 品質保証 → パッケージ管理という本番運用パイプラインを Terraform で完全実装できる状態になっている。各章で Terraform HCL / AWS CLI / コンソール 3形式の実装例を提供するため、既存環境への段階的な組み込みにも対応できる。

本記事で扱う主要 Terraform リソースは以下の通りだ。

• aws_codeartifact_domain / aws_codeartifact_repository / aws_codeartifact_repository_permissions_policy
• aws_codegurureviewer_repository_association
• aws_codeguruprofiler_profiling_group
• IAM 関連: aws_iam_role / aws_iam_role_policy_attachment (CodeArtifact / CodeGuru 両対応)

シリーズ全4巻のコードは一貫した変数設計 (var.project / var.environment / var.region) を共有しているため、Vol2-3 の Terraform モジュールとそのまま組み合わせて使用できる。

1-2. 読者像

想定読者: aws-code-family Vol1-3 を読了し、CodeBuild・CodePipeline・CodeDeploy の基本実装を習得済みのエンジニア。加えて、「チーム内でパッケージを共有管理したい」「PR のコードレビューを自動化したい」「本番 API の遅延原因をボトルネック分析したい」という課題を抱える中級レベル以上の実務者を対象とする。

必須前提知識チェックリスト: 以下の項目を確認してから読み進めてほしい。

• Terraform の基本構文 (resource / variable / output / data) が読み書きできる
• IAM Role の信頼関係設計と sts:AssumeRole の仕組みを理解している
• CodeBuild の buildspec.yml 記述経験がある (Vol2 修了レベル)
• GitHub または CodeCommit でのブランチ運用・PR フロー経験がある
• aws CLI の基本コマンドが使える (プロファイル切り替え・--query オプション等)

上記チェックリストの大半が未確認であれば、Vol1-3 から順に読むことを推奨する。

本記事で身につくこと:

• CodeArtifact の Domain/Repository/Package 3層設計と upstream proxy 構成
• IAM Token 認証 (12時間期限) の自動更新と CodeBuild 統合パターン
• CodeGuru Reviewer の PR 自動統合とコスト試算 (月あたり PR数による料金計算)
• CodeGuru Profiler のエージェント組み込みとフレームグラフの読み方
• Terraform でこれら全サービスの完全 IaC 実装
• Bedrock Agents との棲み分け判断軸 (定型 vs カスタム AI ロジック)
• Vol1-4 全体を俯瞰したチートシートと落とし穴10選

1-3. なぜ今これを書くか

AWS CodeArtifact は 2019年にリリースされ、GitHub Packages や JFrog Artifactory の AWS ネイティブ代替として普及しつつあるが、日本語技術記事では「公式ドキュメントの紹介レベル」にとどまるものが多く、upstream proxy 設定・IAM Token 12時間期限への実務対処・CodeBuild との統合パターンまで踏み込んだ記事は稀少だ。CodeGuru も同様で、Reviewer と Profiler の棲み分けを解説した国内記事はほとんど存在しない。

さらに 2023年以降、Bedrock の普及により「AI でコードレビューしたい」という要件が急増し、「CodeGuru Reviewer か Bedrock Agents か」という選定判断が現場で求められている。本記事はこの比較軸を §7 で正面から扱い、実務判断に直結する選定フローを提供する。

aws-code-family シリーズとして、本記事は Vol1-3 で構築したパイプラインの「最後のピース」を担う。シリーズ全4巻を通読するだけで、設計から品質保証まで本番レディな CI/CD 環境を一から構築できる。この完走価値を最大化することが本記事の執筆動機である。

特にパッケージガバナンスの観点から、2024年以降は Log4Shell・XZ Utils のようなサプライチェーン攻撃事例が増加しており、外部レジストリへの直接依存を遮断して内部承認済みパッケージのみを使用する組織的ポリシーの重要性が増している。CodeArtifact の upstream proxy + Package Origin Control はこのニーズに直接応えるアーキテクチャだ。本記事はそのセキュリティ観点も含めて実装を解説する。

本番運用クオリティのゴールラインとしては、以下の状態を目標とする。

• CodeArtifact Domain が KMS 暗号化で保護され、社内パッケージが upstream proxy 経由でキャッシュされている
• CodeBuild の buildspec.yml で IAM Token が自動更新され、12時間制限を意識せずに CI が回る
• CodeGuru Reviewer が全 PR に静的解析を自動実行し、CRITICAL 指摘が即日対応される運用が確立されている
• CodeGuru Profiler が本番 ECS/Lambda に組み込まれ、フレームグラフで CPU ホットスポットが継続的に可視化されている

1-4. 本記事の構成

本記事は §1〜§8 で構成される。通し読みでも、目的の章から読み始めても理解できるよう各章は独立性を保っている。

読み方の指針:
– CodeArtifact の概念から始めたい → §2 → §3 の順で読む
– CodeGuru Reviewer の PR 統合だけ知りたい → §4 から読む
– Bedrock との選定で迷っている → §7 から読む
– シリーズ全体を振り返りたい → §8 のチートシートを参照する

aws-code-family シリーズ完結への道のり:

本記事は4巻構成シリーズの完結弾だ。各 Volume が担うレイヤーと依存関係を理解することで、パイプライン全体像が見えやすくなる。

[Vol1 選定] ← サービス選定・GHA/ecspresso 使い分け (WP:2104)  ↓[Vol2 ビルド] ← CodeBuild VPC 統合・マルチアーキテクチャ (WP:2127)  ↓[Vol3 デプロイ] ← CodePipeline V2・CodeDeploy Blue/Green (WP:2152)  ↓[Vol4 品質・パッケージ] ← CodeArtifact・CodeGuru・Bedrock 比較 (本記事)

シリーズを Vol1 から順に読むことで、AWS 上の本番 CI/CD パイプラインを一から設計・実装・運用できる完全なロードマップが得られる。本記事を最後まで読んだとき、「設計から品質保証まで、Terraform 一本で全部書ける」という確かな手応えを届けることが目標だ。

Vol3: CodePipeline V2 + CodeDeploy 本番運用

2. CodeArtifact 全体像 (npm/pip/maven/nuget・upstream proxy・GitHub Packages比較)

2-1. CodeArtifact 基本概念

CodeArtifact のリソースモデルは Domain → Repository → Package の3層で構成される。この階層を理解することが設計の出発点となる。

Domain (ドメイン)

Domain は CodeArtifact の最上位リソースで、組織またはビジネスユニット単位でパッケージ管理の境界を定義する。

• 1つの AWS アカウントに複数の Domain を作成できる (通常は組織全体で1つが推奨)
• Domain レベルで KMS カスタムキーによる暗号化を設定する
• クロスアカウント共有: resource-based policy で他アカウントの IAM Role に Domain 内リポジトリへのアクセスを委任できる
• Domain 名はリージョン内で一意。一度作成したら変更不可

resource "aws_codeartifact_domain" "main" {  domain= "my-org"  encryption_key = aws_kms_key.codeartifact.arn  tags = { Project  = var.project Environment = var.environment  }}resource "aws_kms_key" "codeartifact" {  description = "CodeArtifact domain encryption key"  deletion_window_in_days = 7}

# Domain 作成 (CLI)aws codeartifact create-domain \  --domain my-org \  --encryption-key arn:aws:kms:ap-northeast-1:123456789012:key/xxx# コンソール: CodeArtifact → Domains → Create domain

Repository (リポジトリ)

Repository は Domain 内に作成するパッケージの集合体で、プロジェクト・チーム・用途単位で分割する。

• 1つの Domain に複数の Repository を作成できる
• Repository には upstream (上流リポジトリ) を設定でき、キャッシュ・代理取得が可能
• 代表的なパターン:
• internal-npm: チーム内共有パッケージのみを格納する
• npm-store: npmjs.org の upstream proxy キャッシュ専用
• shared-libs: 複数チームが利用する共通ライブラリ

# 内部パッケージ用リポジトリresource "aws_codeartifact_repository" "internal_npm" {  repository= "internal-npm"  domain = aws_codeartifact_domain.main.domain  domain_owner = data.aws_caller_identity.current.account_id  upstream { repository_name = aws_codeartifact_repository.public_npmjs.repository  }}# public npmjs.org proxy 用リポジトリ (upstream 専用)resource "aws_codeartifact_repository" "public_npmjs" {  repository= "public-npmjs-com"  domain = aws_codeartifact_domain.main.domain  domain_owner = data.aws_caller_identity.current.account_id  external_connections { external_connection_name = "public:npmjs"  }}

# リポジトリ作成 (CLI)aws codeartifact create-repository \  --domain my-org \  --domain-owner "$(aws sts get-caller-identity --query Account --output text)" \  --repository internal-npm \  --description "Internal npm packages"# upstream 設定aws codeartifact update-repository \  --domain my-org \  --domain-owner "$(aws sts get-caller-identity --query Account --output text)" \  --repository internal-npm \  --upstreams upstreamRepositoryName=public-npmjs-com# コンソール: CodeArtifact → Repositories → Create repository → Upstream repositories に追加

Package (パッケージ)

Package は Repository 内に格納される個別のパッケージで、format/namespace/name/version の4要素で一意に識別される。

• format: npm / pypi / maven / nuget / swift / cargo / generic のいずれか
• namespace: npm では @scope、maven では groupId に相当
• version: semver 形式 (npm/pip/nuget) または maven 形式
• パッケージのメタデータ (description/license/tags) はコンソールや API で確認可能

# パッケージ一覧 (CLI)aws codeartifact list-packages \  --domain my-org \  --repository internal-npm \  --format npm \  --query 'packages[*].{Name:name,Namespace:namespace}' \  --output table# コンソール: CodeArtifact → Repositories → internal-npm → Packages

2-2. 対応パッケージ形式

CodeArtifact が対応するパッケージ形式は 2024年時点で以下の通りだ。形式によって external_connection (public registry への接続) の有無と GA リリース時期が異なる。

実務上の注意点:

• Ruby (RubyGems) は 2024年時点で非対応。Ruby プロジェクトでは GitHub Packages または Gemfury を検討。
• swift は external_connections ブロック指定不可 (社内パッケージの配布のみ)。
• generic 形式は CI のビルド成果物 (zip/jar/wheel) を管理するのに便利。バージョン管理付き S3 の代替として使える。
• maven / gradle は同じ maven 形式を共用。external_connection_name = "public:maven-central" で Maven Central をプロキシできる。

# pypi リポジトリ設定例resource "aws_codeartifact_repository" "public_pypi" {  repository= "public-pypi"  domain = aws_codeartifact_domain.main.domain  domain_owner = data.aws_caller_identity.current.account_id  external_connections { external_connection_name = "public:pypi"  }}resource "aws_codeartifact_repository" "internal_pip" {  repository= "internal-pip"  domain = aws_codeartifact_domain.main.domain  domain_owner = data.aws_caller_identity.current.account_id  upstream { repository_name = aws_codeartifact_repository.public_pypi.repository  }}

# 形式ごとのパッケージ publish 例# npmaws codeartifact login --tool npm --domain my-org \  --domain-owner "$(aws sts get-caller-identity --query Account --output text)" \  --repository internal-npmnpm publish# pip (twine 経由)aws codeartifact login --tool pip --domain my-org \  --domain-owner "$(aws sts get-caller-identity --query Account --output text)" \  --repository internal-pippip install twinetwine upload --repository codeartifact dist*"

buildspec.yml (Python プロジェクト例)

version: 0.2env:  variables: DOMAIN: mycompany REGION: ap-northeast-1  parameter-store: ACCOUNT_ID: /codebuild/account-idphases:  install: runtime-versions:python: "3.11" commands:- pip install --upgrade pip setuptools wheel  pre_build: commands:- echo "Configuring CodeArtifact pip authentication..."- aws codeartifact login --tool pip --domain $DOMAIN --domain-owner $ACCOUNT_ID --repository internal-pypi --region $REGION- echo "CodeArtifact pip login successful"  build: commands:- pip install -r requirements.txt- python -m pytest tests/ -v --tb=short  post_build: commands:- python -m build- |  if [ "$PUBLISH_PACKAGE" = "true" ]; then REPO_URL=$(aws codeartifact get-repository-endpoint --domain $DOMAIN --domain-owner $ACCOUNT_ID --repository internal-pypi --format pypi --query repositoryEndpoint --output text) python -m twine upload --repository-url $REPO_URL dist*"

Terraform: CodeBuild IAM Role への CodeArtifact 権限付与

Vol2 の CodeBuild モジュールで作成した IAM Role に以下のインラインポリシーを追加する。sts:GetServiceBearerToken は Resource: "*" + Condition での付与が必須。

resource "aws_iam_role_policy" "codebuild_codeartifact" {  name = "codebuild-codeartifact"  role = aws_iam_role.codebuild.id  policy = jsonencode({ Version = "2012-10-17" Statement = [{  Sid = "CodeArtifactDomainAccess"  Effect = "Allow"  Action = [ "codeartifact:GetAuthorizationToken", "codeartifact:GetRepositoryEndpoint", "codeartifact:ReadFromRepository", "codeartifact:PublishPackageVersion", "codeartifact:PutPackageMetadata"  ]  Resource = [ aws_codeartifact_domain.main.arn, "${aws_codeartifact_domain.main.arn}/*"  ]},{  Sid= "STSGetBearerToken"  Effect= "Allow"  Action= ["sts:GetServiceBearerToken"]  Resource = "*"  Condition = { StringEquals = {"sts:AWSServiceName" = "codeartifact.amazonaws.com" }  }} ]  })}

コンソール操作: CodeBuild プロジェクトとの接続確認

1. CodeBuild コンソール → 対象プロジェクト →「環境」タブ → サービスロール ARN を確認
2. IAM コンソール → 対象ロール → codeartifact:GetAuthorizationToken / sts:GetServiceBearerToken が含まれることを確認
3. ビルドログ → pre_build フェーズで CodeArtifact npm login successful が出力されることを確認
4. 成功後、CodeArtifact コンソール → リポジトリ →「パッケージ」タブでキャッシュ済みパッケージを確認

3-5. 落とし穴 (本番で踏みやすいポイント)

4. CodeGuru Reviewer (PRレビュー自動化)

AWS CodeGuru Reviewer は機械学習を活用した静的コードレビューサービスだ。GitHub・CodeCommit・Bitbucket リポジトリと連携し、PR (Pull Request) が作成・更新されるたびに自動でコードを解析してインラインコメントを投稿する。開発者は CI/CD パイプラインを止めずに、セキュリティ脆弱性・コードスメル・パフォーマンス問題を PR 単位で継続的に検出できる。

Vol1-3 で構築した CodePipeline/CodeBuild パイプラインに CodeGuru Reviewer を組み込むことで、「ビルド成功 = 品質保証済み」の基準を引き上げられる。特に Java/Python の大規模プロダクトで効果が高く、CWE (Common Weakness Enumeration) ベースのセキュリティ検出は SonarQube 有償版に匹敵するレベルだ。Amazon 社内で 10 億行以上のコードを学習データとして構築された ML モデルが、一般的な静的解析ツールでは検出しにくいパターンを拾い上げる。

4-1. 対応言語と検出カテゴリ

対応言語 (11言語)

⚠️ 重要: 上記以外の言語 (C/C++/Rust/Elixir 等) はレビューが実行されても検出件数ゼロになる。多言語モノレポで非対応言語のみの変更 PR に対してもコストは発生するため、リポジトリ構成と対応言語を事前に照合することが必須だ。

検出カテゴリ

CodeGuru Reviewer が検出する問題は 4 カテゴリに分類される。

4-2. 連携設定 (Terraform / AWS CLI / コンソール)

リポジトリを CodeGuru Reviewer と関連付ける方法は 3 通りある。

Terraform (推奨)

aws_codegurureviewer_repository_association リソースで GitHub/CodeCommit/Bitbucket を関連付ける。GitHub 連携には CodeStar Connection が必要だ。

# CodeStar Connection (GitHub OAuth 認証の実体)resource "aws_codestarconnections_connection" "github" {  name = "github-connection"  provider_type = "GitHub"}# CodeGuru Reviewer リポジトリ関連付け (GitHub)resource "aws_codegurureviewer_repository_association" "github_main" {  repository { github_enterprise_server {connection_arn = aws_codestarconnections_connection.github.arnname  = "my-app-repo"owner = "myorg" }  }  tags = { Env  = var.env Service = "CodeGuruReviewer"  }}# CodeCommit リポジトリ連携 (OAuth 不要・シンプル)resource "aws_codegurureviewer_repository_association" "codecommit_main" {  repository { codecommit {name = aws_codecommit_repository.app.repository_name }  }}# CodeGuru Reviewer 用 IAM Roleresource "aws_iam_role" "codeguru_reviewer" {  name = "codeguru-reviewer-role-${var.env}"  assume_role_policy = jsonencode({ Version = "2012-10-17" Statement = [{Effect = "Allow"Principal = { Service = "codeguru-reviewer.amazonaws.com" }Action = "sts:AssumeRole" }]  })}resource "aws_iam_role_policy_attachment" "codeguru_reviewer" {  role = aws_iam_role.codeguru_reviewer.name  policy_arn = "arn:aws:iam::aws:policy/AmazonCodeGuruReviewerFullAccess"}

GitHub の場合は Terraform Apply だけでは有効化されない。Apply 後にマネジメントコンソールで CodeStar Connection の OAuth 認証ハンドシェイクを手動実施する必要がある。この手順を踏まないと Association が Pending のまま進まない。

AWS CLI

# GitHub リポジトリ連携 (CodeStar Connection ARN が必要)aws codeguru-reviewer associate-repository \  --repository '{ "GitHubEnterpriseServer": {"ConnectionArn": "arn:aws:codestar-connections:ap-northeast-1:123456789012:connection/xxxxxxxx","Name": "my-app-repo","Owner": "myorg" }  }'# CodeCommit リポジトリ連携 (OAuth 不要)aws codeguru-reviewer associate-repository \  --repository '{"CodeCommit": {"Name": "my-codecommit-repo"}}'# 関連付け一覧確認 (State で有効化状態を確認)aws codeguru-reviewer list-repository-associations \  --query 'RepositoryAssociationSummaries[*].{Name:Name,State:State,Arn:AssociationArn}' \  --output table

コンソール

1. マネジメントコンソール → CodeGuru → Reviewer → Associated repositories
2. Associate repository をクリック
3. リポジトリプロバイダを選択 (GitHub / GitHub Enterprise / CodeCommit / Bitbucket)
4. GitHub の場合: Connect to GitHub → OAuth 認証 → リポジトリを選択
5. CodeCommit の場合: リージョン内のリポジトリ一覧から選択してそのまま確定
6. Associate をクリック → State が Associated になれば完了

4-3. PR コメント自動投稿

Association 完了後、リポジトリに PR を作成すると CodeGuru Reviewer が自動で解析を開始し、問題箇所にインラインコメントを投稿する。

recommendation severity (5段階)

検出コメント例 (Python — ハードコードシークレット)

# 検出されるコード (Critical 対象)db_password = "MySecretPass123!"# CodeGuru Reviewer が PR コメントとして投稿する内容:# [Critical] hardcoded-credentials (CWE-798)# Severity: Critical# Recommendation: Store credentials in AWS Secrets Manager#or use environment variables.

AWS CLI で Recommendation 一覧を取得する

# 最新の Code Review ARN を取得REVIEW_ARN=$(aws codeguru-reviewer list-code-reviews \  --type PullRequest \  --query 'CodeReviewSummaries[0].CodeReviewArn' \  --output text)# Recommendation 一覧 (Severity・ファイル・説明)aws codeguru-reviewer list-recommendations \  --code-review-arn "$REVIEW_ARN" \  --query 'RecommendationSummaries[*].{File:FilePath,Sev:Severity,Desc:Description}' \  --output table# Code Review の状態と分析行数を確認aws codeguru-reviewer describe-code-review \  --code-review-arn "$REVIEW_ARN" \  --query 'CodeReview.{State:State,Lines:MetricsSummary.MeteredLinesOfCodeCount}' \  --output json

GitHub Actions との統合 (SARIF 自動アップロード)

jobs:  codeguru-review: runs-on: ubuntu-latest permissions:security-events: writeid-token: writecontents: read steps:- uses: actions/checkout@v4  with: fetch-depth: 0- uses: aws-actions/configure-aws-credentials@v4  with: role-to-assume: ${{ secrets.AWS_ROLE_ARN }} aws-region: ap-northeast-1- uses: aws-actions/codeguru-reviewer@v1.1  with: s3_bucket: codeguru-reviewer-${{ secrets.AWS_ACCOUNT_ID }}- uses: github/codeql-action/upload-sarif@v3  with: sarif_file: codeguru-results.sarif.gz

4-4. 料金と大量 PR 時のコスト爆発対策

料金体系

CodeGuru Reviewer の料金は「分析した行数」ベースだ。PR の差分行数ではなくリポジトリ全体の対象行数で計算される点に注意が必要だ。

月額コスト試算 (Standard)

シナリオ A: 小規模チーム  リポジトリ 10,000行 × 月 20 PR = $1,000/月シナリオ B: 中規模チーム  リポジトリ 50,000行 × 月 30 PR = $7,500/月シナリオ C: 大規模チーム (危険水域)  リポジトリ 200,000行 × 月 100 PR = $100,000/月

大規模リポジトリ × 高頻度 PR の組み合わせで月額数万〜数十万ドルに達する事例がある。導入前に必ずコスト試算を行うこと。

⚠️ コスト爆発対策

# AWS Budgets でアラート設定 (月 $500 上限の例)aws budgets create-budget \  --account-id "$AWS_ACCOUNT_ID" \  --budget '{ "BudgetName": "CodeGuruReviewerMonthlyBudget", "BudgetLimit": {"Amount": "500", "Unit": "USD"}, "TimeUnit": "MONTHLY", "BudgetType": "COST", "CostFilters": {"Service": ["AWS CodeGuru Reviewer"] }  }' \  --notifications-with-subscribers '[{ "Notification": {"ComparisonOperator": "GREATER_THAN","NotificationType": "ACTUAL","Threshold": 80,"ThresholdType": "PERCENTAGE" }, "Subscribers": [{"Address": "ops-team@example.com","SubscriptionType": "EMAIL" }]  }]'

コンソールでのコスト確認手順

1. CodeGuru コンソール → Reviewer → Associated repositories
2. 対象リポジトリを選択 → Code reviews タブ
3. 各 Code Review の Lines of code analyzed 列で分析行数を確認
4. AWS Cost Explorer → サービスフィルタ: CodeGuru Reviewer で月次推移監視

月次上限の設定は CodeGuru コンソール単体ではできない。AWS Budgets + Cost Anomaly Detection の組み合わせで異常コストを早期検知する運用が必須だ。

4-5. 落とし穴と対処法

落とし穴 1: 対応言語外・低精度言語で結果がゼロ件

Go や Kotlin は対応言語一覧に含まれているが、検出精度は Java/Python より大幅に低い。特に Go は「レビューは実行されたが 0 件」というケースが頻発する。非対応言語または精度が低い言語は SonarQube・Semgrep・Snyk 等の専用ツールと組み合わせること。CodeGuru Reviewer は Java/Python メインのリポジトリで最大の効果を発揮する。

落とし穴 2: GitHub Association が Pending のまま解消されない

GitHub の CodeStar Connection は Terraform Apply だけでは有効化されない。コンソールで OAuth 認証ハンドシェイクを手動実施しないと Pending 状態が続く。

# Association の State を確認するaws codeguru-reviewer list-repository-associations \  --query 'RepositoryAssociationSummaries[*].{Name:Name,State:State}' \  --output table# State: Pending → コンソールで OAuth 認証が必要# State: Failed  → Connection ARN の誤りまたは権限不足を確認# State: Associated → 正常 (PR 作成時にレビューが走る)

落とし穴 3: 大量 PR による意図せぬコスト増大

Feature Branch 戦略でブランチが乱立するプロジェクトでは、1日数十 PR が飛び交い月額が数万ドルに跳ね上がる。Association を解除しても既に分析済み PR の料金は取り消しできない。導入初月は必ず AWS Budgets + Cost Anomaly Detection を設定し、PR 規模の上限 (例: 500行/PR) をチームルール化することを推奨する。

落とし穴 4: 誤検知への過剰対応でレビュー文化が崩壊

CodeGuru Reviewer は機械学習ベースのため誤検知が発生する。特に社内独自フレームワークやカスタムライブラリのパターンは「コードスメル」として誤判定されやすい。PR コメントに @aws-codeguru-reviewer suppress と返信すると以降の同一パターンを抑制できる。チーム内で「Info/Low は参考情報・Critical/High のみ必須修正」のガイドラインを定め、適切な粒度でレビュー文化を維持することを推奨する。

5. CodeGuru Profiler (本番パフォーマンス分析)

CodeGuru Profiler は本番環境で稼働中のアプリケーションの CPU/メモリ/レイテンシを継続的にサンプリングし、フレームグラフとして可視化するプロファイリングサービスです。アプリケーションコードを一切変更せずに軽量エージェントを追加するだけで、ホットスポット特定から最適化サイクルまでを自動化します。Vol3 (CodePipeline) でデプロイしたアプリケーションの本番品質を担保する補完レイヤーとして機能します。

5-1. Profiler 概要

対応ランタイムとプラットフォーム

Lambda の場合は compute_platform = "AWSLambda" を明示しないとデータが正しく集計されません。EC2/ECS/EKS/Fargate には Default を使用します。

フレームグラフ種別

初回は CPU + Heap Summary から開始し、Latency は X-Ray 連携後に Cost と組み合わせて分析すると ROI が明確になります。

5-2. Profiling Group 設計

Profiling Group はプロファイルデータを集約する論理ユニットです。環境 (dev/stg/prd) × サービス単位で作成し、cross-environment 汚染を防止します。

Terraform

resource "aws_codeguruprofiler_profiling_group" "app_prd" {  name = "${var.project_name}-${var.environment}-app"  compute_platform = "Default"  # EC2/ECS/EKS/Fargate の場合  agent_orchestration_config { profiling_enabled = true  }  tags = { Environment = var.environment ManagedBy= "Terraform"  }}resource "aws_codeguruprofiler_profiling_group" "lambda_prd" {  name = "${var.project_name}-${var.environment}-lambda"  compute_platform = "AWSLambda"  # Lambda の場合は必須  agent_orchestration_config { profiling_enabled = true  }  tags = { Environment = var.environment ManagedBy= "Terraform"  }}

compute_platform は作成後に変更できません。誤設定の場合はリソースを destroy して再作成してください。

AWS CLI

# EC2/ECS/Fargate 用 Profiling Group 作成aws codeguru-profiler create-profiling-group \  --profiling-group-name "myapp-prd-app" \  --compute-platform Default \  --agent-orchestration-config profilingEnabled=true \  --tags Environment=prd# Lambda 用 Profiling Group 作成aws codeguru-profiler create-profiling-group \  --profiling-group-name "myapp-prd-lambda" \  --compute-platform AWSLambda \  --agent-orchestration-config profilingEnabled=true# Profiling Group 一覧確認aws codeguru-profiler list-profiling-groups --output table# Profiling Group の詳細確認aws codeguru-profiler describe-profiling-group \  --profiling-group-name "myapp-prd-app"

コンソール操作

1. CodeGuru コンソール → 左メニュー「Profiler」→「Profiling groups」
2. 「Create profiling group」をクリック
3. Name: myapp-prd-app、Compute platform: Standard (= Default) を選択
4. Agent orchestration: Profiling enabled をオン
5. Tags: Environment=prd を追加して「Create」

5-3. エージェント設定

エージェントはアプリケーションプロセス内に埋め込まれ、デフォルトで 5 分ごとにサンプリングデータを CodeGuru Profiler へ送信します。

Java エージェント

Maven (pom.xml):

<dependency>  <groupId>software.amazon.codeguruprofiler</groupId>  <artifactId>codeguru-profiler-java-agent</artifactId>  <version>2.5.2</version></dependency>

Gradle (build.gradle):

dependencies {  implementation 'software.amazon.codeguruprofiler:codeguru-profiler-java-agent:2.5.2'}

JVM 起動オプション (ECS タスク定義・EC2 起動スクリプト共通):

java \  -javaagent:/opt/codeguru-profiler-java-agent.jar \  -Dcom.amazonaws.codeguruprofiler.profilingGroupName=myapp-prd-app \  -Dcom.amazonaws.codeguruprofiler.region=ap-northeast-1 \  -jar app.jar

Python エージェント

# インストールpip install codeguru-profiler-agent# Lambda Layer としてパッケージ化する場合pip install codeguru-profiler-agent -t python/lib/python3.11/site-packages/zip -r codeguru-profiler-layer.zip python/

Lambda ハンドラへの組み込み (lambda_function.py):

from codeguru_profiler_agent import with_lambda_profiler@with_lambda_profiler(profiling_group_name="myapp-prd-lambda")def handler(event, context): return process(event)

EC2/ECS での起動 (app.py):

import codeguru_profiler_agentprofiler = codeguru_profiler_agent.Profiler( profiling_group_name="myapp-prd-app", region_name="ap-northeast-1")profiler.start()run_application()

IAM ロール設定

エージェントが CodeGuru Profiler にデータを送信するには AmazonCodeGuruProfilerAgentAccess マネージドポリシーが必要です。EC2 インスタンスプロファイル、ECS タスクロール、Lambda 実行ロールのいずれにもアタッチ可能です。

resource "aws_iam_role_policy_attachment" "codeguru_profiler_agent" {  role = aws_iam_role.app_task.name  policy_arn = "arn:aws:iam::aws:policy/AmazonCodeGuruProfilerAgentAccess"}

5-4. フレームグラフ読み方

フレームグラフは横軸が「全体 CPU 時間に占める割合」、縦軸が「コールスタックの深さ」を表します。横幅が広いフレームがホットスポットです。

Heap Summary の活用

• Live objects count: GC 後も残存するオブジェクト数の推移 → メモリリーク検出指標
• Allocated heap: ピーク時の割当量とその後の解放パターン → GC 頻度の評価
• Recommendation Engine: 自動検出した最適化提案 (例: ArrayList の初期容量拡大でリサイズコストを削減)

ホットスポット特定→最適化サイクル

① CPU フレームグラフで横幅 > 5% のフレームを特定  ↓② Recommendation Engine の提案を確認  ↓③ コード修正 + Vol3 CodePipeline で自動デプロイ  ↓④ 「Compare profiles」で before/after スナップショット比較  ↓⑤ Cost フレームグラフで CPU 削減率を ROI 換算

CodeGuru Profiler はスナップショット比較機能 (「Compare profiles」) を内蔵しており、デプロイ前後の差分を視覚的に確認できます。

5-5. X-Ray 連携

X-Ray の分散トレーシングと Profiler を組み合わせることで、「どのリクエストが遅いか (X-Ray)」と「なぜ遅いか (Profiler)」を同一の観点で分析できます。X-Ray トレース ID が Profiler サンプリングデータに付与され、特定リクエストのコールスタックを遡ることができます。

# ECS タスク定義: X-Ray デーモンを sidecar として追加aws ecs register-task-definition \  --container-definitions '[ {"name": "xray-daemon","image": "amazon/aws-xray-daemon","essential": false,"portMappings": [{"containerPort": 2000, "protocol": "udp"}] }, {"name": "app","environment": [  {"name": "AWS_XRAY_DAEMON_ADDRESS", "value": "xray-daemon:2000"},  {"name": "CODEGURU_PROFILER_GROUP_NAME", "value": "myapp-prd-app"}] }  ]'

X-Ray と Profiler を同時に有効化すると、CodeGuru コンソールの「Profiler」タブに「View in X-Ray」リンクが表示され、遅延リクエストのトレースから直接コールスタックへ遷移できます。

5-6. 落とし穴

6. Terraform完全実装 (CodeArtifact Domain/Repository + CodeGuru 全HCL)

6-1. ディレクトリ構成

modular 構成でサービスごとにファイルを分割し、変更影響範囲を最小化します。

terraform/├── variables.tf # プロジェクト名/環境/リージョン/KMS Key ARN├── codeartifact.tf # Domain / Repository / permissions_policy├── codeguru.tf  # Reviewer association + Profiler profiling_group├── iam.tf # 各サービス信頼関係 + マネージドポリシーアタッチ└── outputs.tf# domain ARN / repository URL / profiling group ARN

6-2. variables.tf

variable "project_name" {  description = "プロジェクト識別名 (リソース命名に使用)"  type  = string  default  = "myapp"}variable "environment" {  description = "デプロイ環境 (dev / stg / prd)"  type  = string  default  = "prd"}variable "aws_region" {  description = "AWS リージョン"  type  = string  default  = "ap-northeast-1"}variable "kms_key_arn" {  description = "CodeArtifact Domain 暗号化用 KMS Key ARN"  type  = string  sensitive= true}variable "codestar_connection_arn" {  description = "GitHub 連携用 AWS CodeStar Connection ARN"  type  = string}variable "aws_account_id" {  description = "AWS アカウント ID (permissions_policy で使用)"  type  = string}

6-3. codeartifact.tf

# Domain: 組織単位のパッケージ管理ルートresource "aws_codeartifact_domain" "main" {  domain= "${var.project_name}-${var.environment}"  encryption_key = var.kms_key_arn  # KMS 暗号化必須 (省略すると AWS マネージドキー)  tags = { Environment = var.environment ManagedBy= "Terraform"  }}# npmjs.com の upstream proxy リポジトリresource "aws_codeartifact_repository" "npm_upstream" {  repository = "${var.project_name}-npm-upstream"  domain  = aws_codeartifact_domain.main.domain  external_connections { external_connection_name = "public:npmjs"  }}# 社内 npm レジストリ (npmjs upstream proxy 付き)resource "aws_codeartifact_repository" "npm" {  repository = "${var.project_name}-npm"  domain  = aws_codeartifact_domain.main.domain  upstream { repository_name = aws_codeartifact_repository.npm_upstream.repository  }  tags = { PackageFormat = "npm" Environment= var.environment  }}# pypi.org の upstream proxy リポジトリresource "aws_codeartifact_repository" "pypi_upstream" {  repository = "${var.project_name}-pypi-upstream"  domain  = aws_codeartifact_domain.main.domain  external_connections { external_connection_name = "public:pypi"  }}# 社内 PyPI レジストリ (pypi upstream proxy 付き)resource "aws_codeartifact_repository" "pypi" {  repository = "${var.project_name}-pypi"  domain  = aws_codeartifact_domain.main.domain  upstream { repository_name = aws_codeartifact_repository.pypi_upstream.repository  }  tags = { PackageFormat = "pypi" Environment= var.environment  }}# Repository レベルの permissions policy (CodeBuild からの publish 許可)resource "aws_codeartifact_repository_permissions_policy" "npm" {  repository= aws_codeartifact_repository.npm.repository  domain = aws_codeartifact_domain.main.domain  policy_document = jsonencode({ Version = "2012-10-17" Statement = [{  Sid = "AllowCodeBuildRead"  Effect = "Allow"  Principal = { AWS = aws_iam_role.codebuild_role.arn  }  Action = [ "codeartifact:GetAuthorizationToken", "codeartifact:ReadFromRepository", "codeartifact:GetRepositoryEndpoint"  ]  Resource = "*"},{  Sid = "AllowPublish"  Effect = "Allow"  Principal = { AWS = "arn:aws:iam::${var.aws_account_id}:root"  }  Action= ["codeartifact:PublishPackageVersion", "codeartifact:PutPackageMetadata"]  Resource = "*"} ]  })}

6-4. codeguru.tf

# CodeGuru Reviewer: CodeCommit リポジトリ連携# GitHub/Bitbucket の場合は var.codestar_connection_arn を使用するresource "aws_codegurureviewer_repository_association" "main" {  repository { codecommit {name = "${var.project_name}-${var.environment}" }  }  tags = { Environment = var.environment ManagedBy= "Terraform"  }}# CodeGuru Profiler: EC2/ECS/Fargate 用resource "aws_codeguruprofiler_profiling_group" "app" {  name = "${var.project_name}-${var.environment}-app"  compute_platform = "Default"  agent_orchestration_config { profiling_enabled = true  }  tags = { Environment = var.environment ManagedBy= "Terraform"  }}# CodeGuru Profiler: Lambda 用resource "aws_codeguruprofiler_profiling_group" "lambda" {  name = "${var.project_name}-${var.environment}-lambda"  compute_platform = "AWSLambda"  agent_orchestration_config { profiling_enabled = true  }  tags = { Environment = var.environment ManagedBy= "Terraform"  }}

6-5. iam.tf

# CodeBuild 用 IAM ロール (CodeArtifact Token 取得権限)resource "aws_iam_role" "codebuild_role" {  name = "${var.project_name}-${var.environment}-codebuild"  assume_role_policy = jsonencode({ Version = "2012-10-17" Statement = [{Effect = "Allow"Principal = { Service = "codebuild.amazonaws.com" }Action = "sts:AssumeRole" }]  })}resource "aws_iam_role_policy" "codeartifact_read" {  name = "CodeArtifactRead"  role = aws_iam_role.codebuild_role.id  policy = jsonencode({ Version = "2012-10-17" Statement = [{  Effect = "Allow"  Action = [ "codeartifact:GetAuthorizationToken", "codeartifact:GetRepositoryEndpoint", "codeartifact:ReadFromRepository"  ]  Resource = "*"},{  Effect= "Allow"  Action= "sts:GetServiceBearerToken"  Resource = "*"  Condition = { StringEquals = {"sts:AWSServiceName" = "codeartifact.amazonaws.com" }  }} ]  })}# CodeGuru Reviewer 用 IAM ロールresource "aws_iam_role" "codeguru_reviewer" {  name = "${var.project_name}-${var.environment}-codeguru-reviewer"  assume_role_policy = jsonencode({ Version = "2012-10-17" Statement = [{Effect = "Allow"Principal = { Service = "codeguru-reviewer.amazonaws.com" }Action = "sts:AssumeRole" }]  })}resource "aws_iam_role_policy_attachment" "codeguru_reviewer_full" {  role = aws_iam_role.codeguru_reviewer.name  policy_arn = "arn:aws:iam::aws:policy/AmazonCodeGuruReviewerFullAccess"}# ECS タスクロール (CodeGuru Profiler エージェント用)resource "aws_iam_role" "app_task" {  name = "${var.project_name}-${var.environment}-app-task"  assume_role_policy = jsonencode({ Version = "2012-10-17" Statement = [{Effect = "Allow"Principal = { Service = "ecs-tasks.amazonaws.com" }Action = "sts:AssumeRole" }]  })}resource "aws_iam_role_policy_attachment" "codeguru_profiler_agent" {  role = aws_iam_role.app_task.name  policy_arn = "arn:aws:iam::aws:policy/AmazonCodeGuruProfilerAgentAccess"}

6-6. outputs.tf

output "codeartifact_domain_arn" {  description = "CodeArtifact Domain ARN"  value = aws_codeartifact_domain.main.arn}output "npm_repository_url" {  description = "npm リポジトリエンドポイント URL"  value = aws_codeartifact_repository.npm.repository_endpoint}output "pypi_repository_url" {  description = "PyPI リポジトリエンドポイント URL"  value = aws_codeartifact_repository.pypi.repository_endpoint}output "app_profiling_group_arn" {  description = "アプリケーション用 Profiling Group ARN"  value = aws_codeguruprofiler_profiling_group.app.arn}output "lambda_profiling_group_arn" {  description = "Lambda 用 Profiling Group ARN"  value = aws_codeguruprofiler_profiling_group.lambda.arn}output "codeguru_reviewer_association_id" {  description = "CodeGuru Reviewer リポジトリ関連付け ID"  value = aws_codegurureviewer_repository_association.main.id}

6-7. Terraform/CLI/コンソール 3点セット まとめ

# Terraform デプロイ手順cd terraform/terraform initterraform plan -var-file=prd.tfvarsterraform apply -var-file=prd.tfvars# デプロイ後: npm 認証設定 (CI/CD パイプラインの buildspec に組込)DOMAIN_NAME=$(terraform output -raw codeartifact_domain_arn | awk -F'/' '{print $NF}')OWNER=$(aws sts get-caller-identity --query Account --output text)TOKEN=$(aws codeartifact get-authorization-token \  --domain "${DOMAIN_NAME}" \  --domain-owner "${OWNER}" \  --query authorizationToken \  --output text)NPM_URL=$(terraform output -raw npm_repository_url)npm config set registry "${NPM_URL}"npm config set //${NPM_URL#https://}:_authToken "${TOKEN}"

コンソール確認手順:

1. CodeArtifact コンソール → Domains → myapp-prd → Repositories → myapp-npm → 「View connection instructions」でパッケージマネージャ別の認証コマンドを自動生成
2. CodeGuru コンソール → Profiler → myapp-prd-app → 「Profiling data」タブでフレームグラフを確認
3. IAM コンソール → Roles → myapp-prd-app-task で AmazonCodeGuruProfilerAgentAccess のアタッチ状況を確認

7. Bedrock Agents との比較・使い分け

7-1. CodeGuru Reviewer vs Bedrock Agents — 根本的な違い

AWS の AI サービスには「静的解析特化の CodeGuru」と「汎用 LLM の Bedrock Agents」という 2 つのアプローチが存在する。同じ「コード品質改善」という文脈でも、両者は設計思想から根本的に異なる。

CodeGuru Reviewer: ルールベースの静的解析 AI

• 事前学習済みのセキュリティ/品質ルール (CWE/OWASP/Best Practices) を適用
• 同じコードに対して常に同じ結果を返す決定論的 (Deterministic) 動作
• PR 単位でトリガー・開発者へのコメント自動投稿に特化
• 対応言語: Java/Python/JavaScript/TypeScript/C#/Ruby/Go/Kotlin/Scala/Swift/PHP の 11言語
• 料金: Standard $0.50/100行・Enterprise $0.10/100行

Bedrock Agents: 汎用 LLM ベースの AI エージェント

• Claude/Titan 等の Foundation Model をベースとした生成 AI
• コンテキストに応じた柔軟な応答・コード生成・複数ツール連携が可能
• 非決定論的 (Non-Deterministic): 同じ入力でも確率的に結果が変わり得る
• 対応言語: Foundation Model が理解できる任意の言語 (事実上制限なし)
• 料金: invoke 単位 (入出力トークン × モデル単価)

CodeGuru Reviewer は 「何を検出するかが明確に定義されている」 領域で圧倒的な安定性を発揮する。一方で Bedrock Agents は 「何をすべきかを柔軟に決定できる」 領域で真価を発揮する。

7-2. 料金比較と月次コスト試算

CodeGuru Reviewer 料金体系

CodeGuru Reviewer は分析したコード行数に基づく課金モデルを採用している。

# 月次コスト試算 (Standard プラン)pr_per_month = 200 # PR 数avg_lines_per_pr = 300# 平均変更行数unit_cost_per_100_lines = 0.50  # Standard 料金monthly_cost = pr_per_month * avg_lines_per_pr / 100 * unit_cost_per_100_lines# = 200 * 300 / 100 * 0.50 = $300/月# Enterprise プランならmonthly_cost_enterprise = 200 * 300 / 100 * 0.10  # = $60/月

注意: PR 1件あたりの課金対象は「変更されたコード行数」ではなく「リポジトリ内の全コード行数」となる場合がある (最新料金は AWS 公式ページを要確認)。大規模リポジトリでは Enterprise プランの検討が必須。

Bedrock Agents 料金体系

Bedrock Agents の料金は使用する Foundation Model のトークン単価に依存する。

# コードレビュー 1回あたりの試算 (Claude 3 Haiku 使用)# 入力: システムプロンプト(1,000) + コード(2,000) = 3,000 トークン# 出力: レビュー結果(1,500 トークン)input_cost  = 3000 / 1_000_000 * 0.25# $0.00075output_cost = 1500 / 1_000_000 * 1.25# $0.001875total_per_call = input_cost + output_cost  # $0.002625/回# 月 200 回呼び出しならmonthly_cost = 200 * 0.002625  # $0.525/月

少量呼び出しであれば Bedrock Agents の方が大幅に安価になる。ただし、Bedrock Agents はセットアップ・プロンプト設計・運用保守コストを含めたトータル TCO での比較が重要。

7-3. 統合パターン: Bedrock Agents から CodeGuru API を呼び出す

Bedrock Agents と CodeGuru は「競合」ではなく「相互補完」として活用できる。Bedrock Agents の Action Group に CodeGuru Reviewer API を組み込むことで、AI が「まず静的解析 (CodeGuru) を実行 → 結果をコンテキストとして LLM で高度な分析・説明文生成」という高度なワークフローを実現できる。

参照: Bedrock Agents 本番運用ガイド (cmd_082 WP:1992)

アーキテクチャ概要

[開発者] → PR 作成 ↓[CodeGuru Reviewer] → 静的解析・CWE/OWASP 検出 ↓ 検出結果 (JSON)[Bedrock Agent Action Group] ↓ Lambda で CodeGuru API → 解析結果取得[Foundation Model (Claude)] ↓ 人間が読みやすいレビューコメント生成 ↓ 修正案コード生成[PR コメント] ← 自動投稿

Terraform 実装 (Bedrock Agent + CodeGuru 統合 Lambda)

resource "aws_lambda_function" "codeguru_action" {  function_name = "${var.project}-codeguru-action"  runtime = "python3.12"  handler = "handler.lambda_handler"  role = aws_iam_role.codeguru_action_role.arn  filename= data.archive_file.codeguru_action.output_path  environment { variables = {REGION = var.aws_region }  }}resource "aws_iam_role_policy" "codeguru_action_policy" {  name = "${var.project}-codeguru-action-policy"  role = aws_iam_role.codeguru_action_role.id  policy = jsonencode({ Version = "2012-10-17" Statement = [{Effect = "Allow"Action = [  "codeguru-reviewer:ListCodeReviews",  "codeguru-reviewer:DescribeCodeReview",  "codeguru-reviewer:ListRecommendations"]Resource = "*" }]  })}

Lambda ハンドラ (Python)

import boto3import jsondef lambda_handler(event, context): """Bedrock Agent Action Group: CodeGuru 検出結果取得""" action  = event.get("actionGroup") function= event.get("function") parameters = {p["name"]: p["value"] for p in event.get("parameters", [])} if function == "get_code_review_results":  pull_request_id = parameters.get("pull_request_id")  reviewer_client = boto3.client("codeguru-reviewer")  reviews = reviewer_client.list_code_reviews(Type="PullRequest",States=["Completed"]  )  results = []  for review in reviews["CodeReviewSummaries"]:if pull_request_id in review.get("PullRequestId", ""): recs = reviewer_client.list_recommendations(  CodeReviewArn=review["CodeReviewArn"] ) results.extend(recs["RecommendationSummaries"])  response_body = {"TEXT": {"body": json.dumps(results, ensure_ascii=False)}}  return {"actionGroup": action,"function": function,"functionResponse": {"responseBody": response_body}  }

このパターンにより、Bedrock Agent は CodeGuru の機械的な検出結果を「開発者が理解しやすい説明文」や「具体的な修正コード提案」に変換できる。両者の強みを組み合わせた次世代レビューパイプラインとして機能する。

AWS CLI での動作確認

# Bedrock Agent を呼び出して CodeGuru 統合レビューを実行aws bedrock-agent-runtime invoke-agent \  --agent-id "${BEDROCK_AGENT_ID}" \  --agent-alias-id "${BEDROCK_AGENT_ALIAS_ID}" \  --session-id "pr-review-$(date +%s)" \  --input-text "PR #42 のコードレビュー結果を取得して改善提案を日本語でまとめて" \  --output json \  | jq -r '.completion'# CodeGuru Reviewer のレビュー状況を直接確認aws codeguru-reviewer list-code-reviews \  --type PullRequest \  --states Completed \  --query 'CodeReviewSummaries[*].{Name:Name,State:State,PRId:PullRequestId}' \  --output table

7-4. 選定フロー — どちらを使うべきか

以下のフローで技術選定を行うことを推奨する。

新たな「コード品質改善」ニーズが発生 ↓Q1: 要件は「決まったルールでの静的チェック」か？ │ ├─ Yes → CodeGuru Reviewer が第一候補 ││ │├─ 対応 11言語内？ → Yes → CodeGuru Reviewer 採用 │└─ 11言語外？ → Bedrock Agents (LLM でルール適用) │ └─ No (カスタム/対話型ニーズ)  ↓ Q2: 「コードの説明・任意変換・自然言語での質問応答」が必要か？  │  ├─ Yes → Bedrock Agents  └─ No → 要件を再整理本番パフォーマンス最適化ニーズ → CodeGuru Profiler (フレームグラフ・Java/Python・実行時プロファイリング)

3サービス使い分けサマリ

8. シリーズ完結まとめ + Vol1-4 チートシート + よくある落とし穴10選

8-1. シリーズ完結宣言

本記事 Vol4 をもって、aws-code-family シリーズ全4巻が完結した。

Vol1 でサービス選定の軸を確立し、Vol2 で CodeBuild によるビルド基盤を構築、Vol3 で CodePipeline V2 + CodeDeploy による本番デプロイパイプラインを実装、そして Vol4 (本記事) で CodeArtifact による社内パッケージ管理と CodeGuru による継続的なコード品質・パフォーマンス改善を補完運用として追加した。これにより、設計 → ビルド → デプロイ → 品質保証 → パッケージ管理というエンタープライズ CI/CD パイプラインの全ライフサイクルが一本の Terraform コードベースで実現できる。

8-2. Vol1-4 チートシート

aws-code-family シリーズ各 Volume の主要 Terraform リソースと AWS CLI ワンライナーをまとめる。

# Vol1: パイプライン一覧確認aws codepipeline list-pipelines --output table# Vol2: CodeBuild ビルド手動実行aws codebuild start-build \  --project-name my-build-project \  --query 'build.{id:id,status:buildStatus}' \  --output table# Vol3: CodePipeline 手動実行aws codepipeline start-pipeline-execution \  --name my-pipeline \  --query 'pipelineExecutionId' \  --output text# Vol4: CodeArtifact Token 取得 (CI 環境で毎回実行)export CODEARTIFACT_TOKEN=$(aws codeartifact get-authorization-token \  --domain my-domain \  --domain-owner "$(aws sts get-caller-identity --query Account --output text)" \  --query authorizationToken \  --output text)

8-3. よくある落とし穴10選

本シリーズ Vol1-4 を通じて遭遇しやすいトラップを集約する。

1. CodeArtifact Token の12時間期限切れ
CodeArtifact の認証トークンはデフォルト12時間で失効する。長時間稼働する CodeBuild ジョブや夜間バッチ内でトークンを再取得しないと認証エラーが発生する。buildspec.yml の pre_build フェーズで毎回取得する設計が必須。

2. upstream proxy 設定漏れで public registry に直接アクセス
upstream を設定しないと、CI が CodeArtifact を経由せず npmjs.org/pypi.org へ直接アクセスし続ける。--upstreams upstreamRepositoryName=public-npmjs-com を忘れずに設定。

3. CodeArtifact Domain の KMS 暗号化漏れ
aws_codeartifact_domain の encryption_key を省略するとデフォルト暗号化になる。セキュリティポリシーでカスタム KMS キー必須の環境では Terraform 適用後に差分が発生し続ける。

4. CodeGuru Reviewer 大量 PR でコスト爆発
Standard プランで大規模リポジトリ (10万行超) に大量の PR をレビューすると月額数千ドルになる可能性がある。Enterprise プランへの切り替えや、対象ブランチ/リポジトリの絞り込みが必要。

5. CodeGuru Profiler agent の本番性能影響
Profiler エージェントはサンプリングにより CPU オーバーヘッドが発生する (通常 1-5%)。高スループット Lambda 関数では compute_platform = "AWSLambda" を指定し、サンプリング率を調整すること。

6. Profiling Group の命名衝突 (環境間)
aws_codeguruprofiler_profiling_group のリソース名はグローバル一意ではなくアカウント+リージョン内で一意。${var.env}-${var.project}-profiler のような命名規則で dev/stg/prod を区別しないと競合する。

7. CodeArtifact Repository の permissions policy 漏れ
aws_codeartifact_repository_permissions_policy を設定しないと、他チームの IAM ロールからリポジトリへのアクセスができない。クロスアカウント共有の場合は特に codeartifact:GetAuthorizationToken を明示的に許可する必要がある。

8. CodeGuru Reviewer の対応言語外で結果ゼロ
Go/Kotlin 等の言語は対応しているが、Swift/PHP は 2024年時点でサポートが限定的。対応外の言語主体のリポジトリでは Reviewer を有効化しても検出件数がゼロとなり、コスト対効果が著しく低下する。

9. Bedrock と CodeGuru の使い分け軸を曖昧に運用
「AI でコードレビューしたい」という曖昧な要件で両サービスを併用するとコストが二重になる。§7 の選定フローを参考に、「定型ルール適用 → CodeGuru Reviewer」「カスタム分析/説明文生成 → Bedrock Agents」と明確に分担すること。

10. Vol1-4 の通読なしに Vol4 だけを導入
CodeArtifact/CodeGuru は CodeBuild (Vol2) や CodePipeline (Vol3) と統合して初めて真価を発揮する。Vol4 単独での導入は設定の複雑さを増すだけになりやすい。Vol2/Vol3 の基盤が整った後に Vol4 を追加するロードマップを推奨する。

8-4. シリーズ完結後の歩み方

本シリーズを通読した読者は、以下のロードマップで本番運用品質の AWS CI/CD パイプラインを実現できる。

Week 1-2: Vol1 (サービス選定)  → AWS Code* / GHA / ecspresso のどれを使うべきか判断軸を確立Week 3-4: Vol2 (CodeBuild)  → ビルド環境の Terraform 完全実装・マルチアーキテクチャ対応Week 5-6: Vol3 (CodePipeline V2 + CodeDeploy)  → Blue/Green + Canary デプロイ・本番ロールバック自動化Week 7-8: Vol4 (本記事・CodeArtifact + CodeGuru)  → 社内パッケージ管理 + コード品質/パフォーマンス継続改善Week 9+: AI 拡張フェーズ (発展)  → Bedrock Agents (WP:1992) を Action Group で CodeGuru と統合  → AI 駆動コードレビュー + 自律型 CI/CD パイプラインへ

本シリーズは AWS仕様の変更に応じて随時更新する予定だが、Terraform リソース名や CLI オプションは AWS 公式ドキュメントで常に最新版を確認することを推奨する。Vol1-4 を通じて本番運用 CI/CD パイプラインを構築・運用する全エンジニアのご健闘を祈る。

Vol1: シリーズ起点 – 全体像+選定
Vol2: CodeBuild 完全活用
Vol3: CodePipeline V2 + CodeDeploy