活動別の構成: 開発・技術調査・テスト・受け入れ・運用・保守・SRE

全体のアーキテクチャ(関連図)

何をどの順でやるかではなく、部品どうしが「何でつながっているか」を1枚にしたもの。推論の入口は手元(Claude Code・Desktop)と無人実行(CodeBuild の claude -p)の2つだけで、どちらも Bedrock の jp. 推論プロファイルに集まる。人の判断(承認・マージ・ロールバック)は CodeCommit・CodePipeline・ECS に対して直接行い、Claude の線はそこに届かない。

描いていないもの: Systems Manager Patch Manager(managed nodes のみ。Fargate には使わない)、Guardrails(任意)、Organizations の SCP(IAM の箱に含めた)、SNS から人へのメール。

SAP 版: 本番を SAP Commerce Cloud + Composable Storefront にした場合

本番を SAP Commerce Cloud(SAP が運用する Public Cloud)と Composable Storefront にし、配備と運用を Cloud Portal で行う場合。手元・認証・統制・記録・推論は 1 枚目とまったく同じで、開発・CI/CD もほぼ同じ(テストと Claude のレビューは CodeBuild のまま)。変わるのは右下だけで、ECS / CloudWatch / X-Ray の代わりに SAP の環境・Dynatrace・OpenSearch が来る。AWS 側には「Cloud Portal の API を叩く線」と「Dynatrace の通知を受ける口」の 2 つが残る。

ゾーン	AWS 版と	SAP 版で何が変わるか
手元(社内の端末)	同じ	同じ。Claude Code / Desktop の推論先は Bedrock jp. のまま
認証・統制・記録	同じ	同じ。Secrets Manager に Cloud Portal の技術ユーザーの client secret と、ミラー Git のトークンが加わる
推論(Bedrock jp.)	同じ	同じ
開発・CI/CD	同じ	ほぼ同じ。ECR とそのイメージスキャンは不要(本番のイメージは SAP の Builder が作る)。CodeBuild に「main / release をミラー先へ git push --mirror」のジョブが増える。CodePipeline の承認後の配備先が ECS から Cloud Portal の API に変わる
本番と監視	変わる	差し替え。環境(開発 / ステージング / 本番)は SAP が Azure 上で運用し、Cloud Portal からビルド・デプロイ・エンドポイント・スケーリングを操作する。監視は Dynatrace(SAP が提供)、ログは OpenSearch と Cloud Portal。CloudWatch アラームの代わりに Dynatrace の Problem notification(Webhook)を AWS 側の API Gateway で受ける
社外	変わる	Cloud Portal が clone できる Git(GitHub / GitLab / Bitbucket)が加わる。Slack は Dynatrace からも直接通知できる

配備(Cloud Portal の API)

• 人が CodePipeline で承認したあと、CodeBuild または Lambda が Cloud Portal の API を呼ぶ: createBuild(branch・name)→ getBuildProgress で待つ → createDeployment(buildCode・environmentCode・databaseUpdateMode・strategy)
• API の入口は https://portalapi.commerce.ondemand.com/v2/subscriptions/{subscriptionCode}/...。認証は Cloud Portal で作る技術ユーザーの OAuth2(client_credentials、トークンは 3600 秒)で、ヘッダーは x-approuter-authorization: Bearer
• databaseUpdateMode は NONE / UPDATE / INITIALIZE、strategy は ROLLING_UPDATE / RECREATE / GREEN(Blue-Green)。INITIALIZE と Rolling update は同時に選べない。JS Storefront aspect は新しい API aspect が起動してから配備される
• ロールバックは「前のビルドを再デプロイ」。Blue-Green の採用判断(createDeploymentDecision)も人が Cloud Portal で行う

ソースの行き先(ミラー)

• Cloud Portal の Builder は GitHub / GitLab / Bitbucket の Git か、VPN / NAT でつないだ私設 Git を clone する。CodeCommit は SAP の資料に列挙されていない
• そのため CodeCommit を正本のまま、main / release の更新(EventBridge の referenceUpdated)で CodeBuild が git push --mirror する案にした。ミラー先のトークンは Secrets Manager
• 別案は、客先と SAP の間で VPN / NAT を組んで CodeCommit を直接 clone させる。どちらにするかは SAP に確認

監視と Claude の原因調査

• Dynatrace は Cloud Portal の環境詳細 → Monitoring → Status から S-user(2要素認証)で SSO。CUSTOMER_SYS_ADMIN がアラートプロファイル(Management Zone = Customer-Admin)と Problem notifications(Webhook / Slack / Jira 等)を設定し、Webhook は秘密 URL と秘密ヘッダーを有効にする
• Webhook を API Gateway → Lambda で受け、Lambda が検証・まとめ・重複排除をして CodeBuild を StartBuild(問題 ID と理由つき)。CodeBuild の claude -p は Dynatrace API(問題・メトリクス・イベント・エンティティの読み取り)で状況を取り、原因の仮説と確認手順を S3 と SNS → Q Developer in chat applications → Slack に出す
• Dynatrace API の PAT は S-user 個人に紐づき、SAP は技術ユーザーを作れない。離任で S-user が止まると PAT も止まる。無人の読み取りに誰の S-user を使うかは客先と決める
• 環境ログは OpenSearch、ビルド / デプロイのログは Cloud Portal。SAP 側の作業・障害は Cloud Operations Notifications、重大障害は P1 チケット

Composable Storefront

• リポジトリは core-customize(Commerce の拡張と manifest.json)と js-storefront(Composable Storefront の Angular プロジェクトと manifest.json)。Builder が両方をビルドし、JS Storefront は SSR で環境の aspect として動く
• 手元の Claude Code での開発と CodeBuild のテスト(ユニット・lint・Claude のレビュー)は AWS 版と同じ。CodeBuild が Composable Storefront の npm 依存(SAP の RBSC)に届く経路は要確認

客先・SAP と詰める点

• Cloud Portal が clone する Git をどこに置くか(ミラー / VPN 接続)。CodeCommit 直結は SAP の資料にない
• Dynatrace の PAT を誰の S-user で発行し、ローテーションと離任をどう扱うか
• Webhook の受け口(API Gateway)を社外から受けるので、秘密ヘッダーの検証と送信元の IP 制限
• Composable Storefront の npm 依存(RBSC)を CodeBuild から取る経路と認証
• Cloud Portal の技術ユーザーの権限範囲(環境ごとに分けられるか)と、本番環境への createDeployment を人の承認なしに呼ばせない仕組み

描いていないもの: Cloud Portal の環境のスケーリング・証明書・データバックアップの API、CDN(客先が置く場合)、Dynatrace の Synthetic / RUM、SAP Cloud Identity による Cloud Portal のログイン、SAP 側の内部構成。

SAP 側の出典(2026-10-11 に確認)

• SAP Help: Cloud Portal API Documentation(portalapi.commerce.ondemand.com/v2、技術ユーザーの OAuth2、x-approuter-authorization)
• SAP Help: createBuild(branch・name)
• SAP Help: createDeployment(databaseUpdateMode・strategy の値)
• SAP Help: Deployments(Platform Update Mode・Deployment Mode・JS Storefront aspect の順)
• SAP Help: Builds(Builder は専用環境で動き、外から到達できない)
• SAP Help: Environments(環境 = Kubernetes・DB・メディア)
• SAP Help: Monitoring(SAP が標準で監視する事象)
• SAP Help: Accessing Dynatrace(S-user・2要素認証・Cloud Portal から SSO)
• SAP Help: Receiving Monitoring Notifications(アラートプロファイル・Problem notifications・秘密 URL / ヘッダー)
• SAP Help: Generate Personal Access Tokens(S-user 個人に紐づく。技術ユーザー不可。スコープ)
• SAP Help: Access to logs in the Cloud Portal(環境ログ・デプロイログ・ビルドログ)
• SAP Learning: Preparing to Connect the Code Repository(GitHub / GitLab / Bitbucket、VPN / NAT の私設リポジトリ)
• SAP Learning: Analyzing the Code Repository(core-customize / js-storefront / manifest.json)
• SAP-samples: cloud-commerce-sample-setup(js-storefront は SSR 構成の Spartacus)

開発

手元の Claude Code で実装し、PR ごとに自動レビューを受け、人がマージする。

フェーズ1: 実装(開発者の手元)

#	誰から → 誰へ	何を送る / 何が返る	種別
1	管理者(客先) → IAM (ユーザー・アクセスキー)	CreateAccessKey(開発者用の IAM ユーザー。ポリシーは jp. の推論プロファイルだけ Allow)	要求
2	IAM (ユーザー・アクセスキー) → 管理者(客先)	アクセスキー ID とシークレット(この1回だけ表示)	応答
3	管理者(客先) → 開発者	払い出し(安全な経路で。開発者は ~/.aws/credentials の profile に置く)	要求
4	開発者 → Claude Code (CLI / IDE / Desktop の Code タブ)	依頼(作業内容 + 受け入れ条件。AWS_PROFILE を指定して起動)	要求
5	Claude Code (CLI / IDE / Desktop の Code タブ) → Bedrock (jp. 推論プロファイル)	InvokeModelWithResponseStream(会話 + ツールの結果。そのアクセスキーで SigV4 署名)	要求
6	Bedrock (jp. 推論プロファイル) → Claude Code (CLI / IDE / Desktop の Code タブ)	応答(文章、または「このツールを呼べ」)	応答
7	Claude Code (CLI / IDE / Desktop の Code タブ) → フック (.claude/hooks/*.sh)	PreToolUse(ツール名・引数の JSON を標準入力で)	要求
8	フック (.claude/hooks/*.sh) → Claude Code (CLI / IDE / Desktop の Code タブ)	allow / ask / deny + 理由(終了コード 0 / 2、または JSON)	応答
9	Claude Code (CLI / IDE / Desktop の Code タブ) → Claude Code (CLI / IDE / Desktop の Code タブ)	ツール実行(ファイル編集・npm test など)	要求
10	Claude Code (CLI / IDE / Desktop の Code タブ) → フック (.claude/hooks/*.sh)	PostToolUse(結果の JSON)	要求
11	フック (.claude/hooks/*.sh) → Claude Code (CLI / IDE / Desktop の Code タブ)	整形の結果・追加の文脈(additionalContext)	応答
12	Claude Code (CLI / IDE / Desktop の Code タブ) → フック (.claude/hooks/*.sh)	Stop(終わろうとした)	要求
13	フック (.claude/hooks/*.sh) → Claude Code (CLI / IDE / Desktop の Code タブ)	テスト未実行なら block + 理由(stop_hook_active で1回だけ)	応答
14	Claude Code (CLI / IDE / Desktop の Code タブ) → 開発者	報告(変更一覧・テスト結果・受け入れ条件との対応)	応答
15	Bedrock (jp. 推論プロファイル) → CloudTrail	記録(呼び出した IAM ユーザー・時刻・inferenceRegion)	自動(通知・記録)
16	管理者(客先) → IAM (ユーザー・アクセスキー)	定期のローテーション: 2本目の鍵を作って配り、古い鍵を UpdateAccessKey で Inactive → 削除	要求

5〜13 は1回の依頼の中で何度も繰り返す。認証は Identity Center の SSO ではなく、客先が IAM で払い出す長期のアクセスキー。IAM ユーザーの鍵なので AWS_SESSION_TOKEN は要らない(公式)。ユーザーのポリシーは jp. の推論プロファイルだけを許可し、SCP が global を Deny(本編 #jp-only)。フックは最善努力で、絶対に通さない操作は permissions.deny と IAM。

フェーズ2: PR 作成と自動レビュー(CodeCommit → EventBridge → CodeBuild)

#	誰から → 誰へ	何を送る / 何が返る	種別
1	Claude Code (開発者の手元) → CodeCommit	git push(claude/ ブランチ。開発者の認証情報で)	要求
2	Claude Code (開発者の手元) → CodeCommit	CreatePullRequest(タイトル・本文・元 / 先ブランチ)	要求
3	CodeCommit → Claude Code (開発者の手元)	pullRequestId	応答
4	CodeCommit → EventBridge (ルール)	イベント「CodeCommit Pull Request State Change」(pullRequestCreated / pullRequestSourceBranchUpdated。PR ID とコミット ID。本文は無い)	自動(通知・記録)
5	EventBridge (ルール) → CodeBuild (claude -p)	StartBuild(environmentVariablesOverride に PR ID・コミット ID)	要求
6	CodeBuild (claude -p) → CodeCommit	GetPullRequest / GetDifferences(差分を取る)	要求
7	CodeCommit → CodeBuild (claude -p)	差分・PR のメタ情報	応答
8	CodeBuild (claude -p) → CodeBuild (claude -p)	テスト実行(buildspec)	要求
9	CodeBuild (claude -p) → Bedrock (jp. 推論プロファイル)	claude -p(差分 + pr-review-rules の本文を --append-system-prompt-file で)	要求
10	Bedrock (jp. 推論プロファイル) → CodeBuild (claude -p)	レビュー結果(--output-format json の .result)	応答
11	CodeBuild (claude -p) → CodeCommit	PostCommentForPullRequest(テスト結果 + 指摘。1件 10,240 文字まで、超えたら分割)	要求
12	CodeBuild (claude -p) → CodeCommit	UpdatePullRequestApprovalState(テスト合格のときだけ、ビルドのサービスロールで承認)	要求
13	CodeCommit → CodeBuild (claude -p)	commentId / 承認状態	応答

4 のイベントにコメント本文は入らない(コメントで起動する形なら GetComment で本文を取る)。11・12 はビルドのサービスロールの権限。ビルド自身の投稿で再起動しないよう、ルールの detail は pullRequestCreated と pullRequestSourceBranchUpdated に絞る。CI は --bare 起動なのでリポジトリのスキル・フックは自動では読まれない。

フェーズ3: 人のレビューと承認・マージ

#	誰から → 誰へ	何を送る / 何が返る	種別
1	レビュー担当(人) → CodeCommit	PR を開く(差分・コメント・テスト結果を読む)	要求
2	CodeCommit → レビュー担当(人)	差分・ビルドのコメント・承認状態	応答
3	レビュー担当(人) → CodeCommit	直してほしい点をコメント(PostCommentForPullRequest)	要求
4	CodeCommit → 開発者	通知(SNS 経由)。開発者はフェーズ1に戻って直し、push すると 2 が再度走る	自動(通知・記録)
5	レビュー担当(人) → CodeCommit	承認(UpdatePullRequestApprovalState)	要求
6	CodeCommit → 承認ルールテンプレート (人1 + ビルド1 を要求)	承認が揃ったかの評価(EvaluatePullRequestApprovalRules)	要求
7	承認ルールテンプレート (人1 + ビルド1 を要求) → CodeCommit	approved / 不足(人の承認とビルドの承認の両方が要る)	応答
8	レビュー担当(人) → CodeCommit	MergePullRequestBySquash など(main へ)	要求
9	CodeCommit → IAM (codecommit:References)	呼び出し元のロールに main へのマージ権限があるか	要求
10	IAM (codecommit:References) → CodeCommit	許可(マージ担当のロール)/ 拒否(開発者・CI のロールには codecommit:References の Deny)	応答
11	CodeCommit → レビュー担当(人)	マージコミット(または承認不足・権限なしのエラー)	応答

Claude はこのフェーズに登場しない(コメントに答えて直すのは開発者がフェーズ1で)。承認ルールの上書き権限も人に限る。

流れ(要約)

1. 客先が IAM で払い出した認証情報(IAM ユーザーのアクセスキー)を開発者が ~/.aws/credentials の profile に置き、Claude Code(CLI / IDE / Desktop の Code タブ)がその鍵で Bedrock jp. に推論を送る(Identity Center の SSO は使わない)
2. implementer が実装し、フックが整形・危険操作の遮断・テスト未実行の差し戻しを行う
3. claude/ ブランチに push → CodeCommit に PR
4. EventBridge のルールが CodeCommit の PR イベント(pullRequestCreated / pullRequestSourceBranchUpdated)で CodeBuild を起動し、テストと claude -p を実行(--bare なので pr-review-rules の本文は --append-system-prompt-file で渡す)、結果を PR のコメントで返す(1コメント 10,240 文字まで)
5. 承認ルールテンプレートが必要な承認数を要求し、IAM の codecommit:References 条件(開発者と CI のロールに付け、マージ担当のロールは除く)が main への直接 push とマージを拒否する。承認ルールの上書き権限も人に限る。人が承認してマージ

本編のサンプルとの対応

implementer / reviewer / tech-lead と、フック8本・管理設定の雛形(本編 #ops-kit・#team)

サブスクリプション契約ならどう変わるか

手元の実装とレビューは同じ。CodeCommit のままなら CI の形も同じ(GitHub Actions の claude-code-action や Code Review は GitHub 前提)。Remote Control で手元のセッションをスマホから続けられる。推論は Anthropic 側で処理される。

注意

• 認証は IAM ユーザーのアクセスキー(長期)。AWS はユーザーあたり最大2本の鍵を持てるので、新しい鍵を配ってから古い鍵を無効化する形でローテーションする。漏えいしたら UpdateAccessKey で Inactive にする。Claude Code は標準の認証情報チェーン(AWS_PROFILE / ~/.aws/credentials)を読むので、IAM ユーザーの鍵では AWS_SESSION_TOKEN は不要(公式)。CodeCommit への git は、同じ IAM ユーザーの HTTPS Git 認証情報か git-remote-codecommit で
• CI の buildspec は --bare で起動しているので、リポジトリのスキル・フックは自動では読まれない(--append-system-prompt-file で渡す)
• フックは最善努力。絶対に通さない操作は permissions.deny と IAM
• CodeCommit の「Comment on Pull Request」イベントにはコメント本文が入らない。@claude のようにコメントで起動するなら、起動した側が GetComment で本文を取る(本編 #aws-ci)
• ビルド自身のコメントや push で再起動するループは自前で防ぐ(本編 #aws-ci)

• Claude Code: Amazon Bedrock(認証情報の渡し方。IAM ユーザーの鍵なら AWS_SESSION_TOKEN は不要) ↗
• IAM: Manage access keys for IAM users(ユーザーあたり最大2本・ローテーション) ↗
• CodeCommit: Setup for HTTPS users using Git credentials(IAM ユーザーの Git 認証情報) ↗
• Claude Code on Amazon Bedrock(IAM・リージョン接頭辞) ↗
• Hooks reference ↗
• CodeCommit: Monitoring events(PR のイベント) ↗
• CodeCommit: Approval rule templates ↗
• CodeCommit: Limit pushes and merges to branches(codecommit:References) ↗
• CodeCommit: Create an approval rule(承認者プールに assumed role) ↗
• AWS CodeCommit returns to general availability(AWS ブログ) ↗
• Run Claude Code programmatically(--bare・-p) ↗
• Claude Desktop on third-party platforms(Overview) ↗

技術調査

CLI では WebSearch が無いので公式ドキュメントに直接当たる。Desktop on 3P なら同梱の websearch サーバーで検索もできる。判断は ADR に残す。

フェーズ1: Claude Code で原典を読む(CLI / IDE)

#	誰から → 誰へ	何を送る / 何が返る	種別
1	調べる人 → Claude Code (aws-docs-lookup)	問い(何を・どの版で・どこまで確かめたいか)	要求
2	Claude Code (aws-docs-lookup) → Bedrock (jp. 推論プロファイル)	推論(問い + aws-docs-lookup の当たり先の型)	要求
3	Bedrock (jp. 推論プロファイル) → Claude Code (aws-docs-lookup)	「この URL を WebFetch で読む」(ツール呼び出し)	応答
4	Claude Code (aws-docs-lookup) → api.anthropic.com (WebFetch の事前確認)	事前確認(URL のホスト名だけ)	要求
5	api.anthropic.com (WebFetch の事前確認) → Claude Code (aws-docs-lookup)	確認結果	応答
6	Claude Code (aws-docs-lookup) → 公式ドキュメント (docs.aws.amazon.com など)	GET(URL)	要求
7	公式ドキュメント (docs.aws.amazon.com など) → Claude Code (aws-docs-lookup)	本文(HTML → Markdown に変換)	応答
8	Claude Code (aws-docs-lookup) → Bedrock (jp. 推論プロファイル)	推論(本文を添えて)	要求
9	Bedrock (jp. 推論プロファイル) → Claude Code (aws-docs-lookup)	逐語の引用 + 答え、または「記載なし / 取得できず」	応答
10	Claude Code (aws-docs-lookup) → 調べる人	答え(引用・URL・取得日つき)	応答

閉域網で api.anthropic.com に出られないなら skipWebFetchPreflight か通信許可が要る。社内文書を足すなら 6〜7 の代わりに Knowledge Bases を MCP サーバーか aws CLI で呼ぶ(構成案)。

フェーズ2: Claude Desktop on 3P で探してから読む

#	誰から → 誰へ	何を送る / 何が返る	種別
1	調べる人 → Claude Desktop (Chat / Cowork)	問い	要求
2	Claude Desktop (Chat / Cowork) → Bedrock (jp. 推論プロファイル)	推論	要求
3	Bedrock (jp. 推論プロファイル) → Claude Desktop (Chat / Cowork)	「検索せよ」(ツール呼び出し)	応答
4	Claude Desktop (Chat / Cowork) → websearch サーバー (管理者が配る MCP)	検索(検索語)	要求
5	websearch サーバー (管理者が配る MCP) → 検索プロバイダ (Brave / Tavily / Exa / 自作)	クエリ(検索語がそのままプロバイダに渡る)	要求
6	検索プロバイダ (Brave / Tavily / Exa / 自作) → websearch サーバー (管理者が配る MCP)	結果(URL・抜粋)	応答
7	websearch サーバー (管理者が配る MCP) → Claude Desktop (Chat / Cowork)	結果一覧	応答
8	Claude Desktop (Chat / Cowork) → 公式ドキュメント	取得(coworkEgressAllowedHosts に入れたホストだけ。または内蔵ブラウザ)	要求
9	公式ドキュメント → Claude Desktop (Chat / Cowork)	本文	応答
10	Claude Desktop (Chat / Cowork) → Bedrock (jp. 推論プロファイル)	推論(本文を添えて)	要求
11	Bedrock (jp. 推論プロファイル) → Claude Desktop (Chat / Cowork)	答え	応答
12	Claude Desktop (Chat / Cowork) → 調べる人	答え(URL つき。原典を読む規律はフェーズ1と同じ)	応答

5 で検索語が社外のプロバイダに出る(推論の国内処理とは別の話)。プロバイダの鍵を headers で配ると全端末が同じ鍵になり利用者が取り出せるので、利用額の上限を決めるか headersHelper で利用者ごとの鍵にする。Desktop の既定では隔離環境から推論先にしか出られないので、8 は許可の設定が無いと失敗する。

フェーズ3: 設計判断を ADR にして PR で確定

#	誰から → 誰へ	何を送る / 何が返る	種別
1	調べる人 → Claude Code (code-architect)	判断の下書きを依頼(選択肢・制約・フェーズ1〜2 で集めた根拠)	要求
2	Claude Code (code-architect) → Bedrock (jp. 推論プロファイル)	推論(根拠 + architecture-review の観点)	要求
3	Bedrock (jp. 推論プロファイル) → Claude Code (code-architect)	ADR の下書き(文脈・選択肢・決定・影響・未確認の点)	応答
4	Claude Code (code-architect) → Claude Code (code-architect)	docs/adr/NNNN-*.md に書く(Edit(docs/adr/**) だけ事前許可)	要求
5	Claude Code (code-architect) → 調べる人	下書きと「未確認」の一覧	応答
6	調べる人 → CodeCommit	git push + CreatePullRequest	要求
7	CodeCommit → レビュー担当	通知(SNS 経由)	自動(通知・記録)
8	レビュー担当 → CodeCommit	コメント(根拠の不足・別案)または承認	要求
9	レビュー担当 → CodeCommit	マージ(決定を確定するのは人)	要求

ADR の「決定」欄を書くのは人。Claude は選択肢と根拠を並べるまで。

フェーズ4: 技術調査 フェーズ4(代替): Web に出られないとき、Knowledge Bases に取り込んで社内で引く

#	誰から → 誰へ	何を送る / 何が返る	種別
1	文書係 (管理者) → S3 (文書置き場)	PutObject(公式文書のオフライン版: PDF / llms.txt、社内の設計書・議事録。取り込み日をメタデータに)	要求
2	文書係 (管理者) → Bedrock Knowledge Bases (bedrock-agent / agent-runtime)	StartIngestionJob(データソース = その S3)	要求
3	Bedrock Knowledge Bases (bedrock-agent / agent-runtime) → S3 (文書置き場)	文書の読み取り	要求
4	Bedrock Knowledge Bases (bedrock-agent / agent-runtime) → Bedrock Knowledge Bases (bedrock-agent / agent-runtime)	分割 → 埋め込みモデルでベクトル化 → ベクトルストアへ保存	要求
5	文書係 (管理者) → Bedrock Knowledge Bases (bedrock-agent / agent-runtime)	GetIngestionJob	要求
6	Bedrock Knowledge Bases (bedrock-agent / agent-runtime) → 文書係 (管理者)	状態(取り込んだ件数・失敗した文書)	応答
7	調べる人 → Claude Code + KB 検索の MCP サーバー	問い	要求
8	Claude Code + KB 検索の MCP サーバー → Bedrock (jp. 推論プロファイル)	推論(問い。WebFetch は閉じているので KB のツールが候補)	要求
9	Bedrock (jp. 推論プロファイル) → Claude Code + KB 検索の MCP サーバー	「KB を検索せよ」(MCP ツール QueryKnowledgeBases)	応答
10	Claude Code + KB 検索の MCP サーバー → Bedrock Knowledge Bases (bedrock-agent / agent-runtime)	Retrieve(bedrock-agent-runtime。問い・knowledgeBaseId・件数)	要求
11	Bedrock Knowledge Bases (bedrock-agent / agent-runtime) → Claude Code + KB 検索の MCP サーバー	一致した断片 + 出典(S3 の URI・スコア)	応答
12	Claude Code + KB 検索の MCP サーバー → Bedrock (jp. 推論プロファイル)	推論(断片を添えて)	要求
13	Bedrock (jp. 推論プロファイル) → Claude Code + KB 検索の MCP サーバー	答え + 引用(出典の URI)、または「取り込んだ文書に記載なし」	応答
14	Claude Code + KB 検索の MCP サーバー → 調べる人	答え(出典 = 取り込んだ文書と取り込み日)	応答

答えられる範囲は 1 で取り込んだ文書まで。鮮度は取り込み日まで。10 の経路は AWS Labs の bedrock-kb-retrieval MCP サーバー(KB に mcp-multirag-kb=true のタグが要る)か aws CLI の bedrock-agent-runtime retrieve。Knowledge Bases は bedrock-agent / agent-runtime 側の機能で Mantle 入口では使えない(構成案)。

流れ(要約)

1. 調べる人が Claude Code に問いを渡す
2. aws-docs-lookup の当たり先(公式の URL の型)に沿って WebFetch で取得。取得前にホスト名だけ api.anthropic.com に送られる
3. 逐語を根拠に答え、見つからなければ「記載なし / 取得できず」と書く
4. Desktop on 3P を使う人は、配られた websearch サーバーで当たり先を探してから、同じ規律で原典を読む
5. 設計判断なら code-architect が ADR を下書きし、CodeCommit の PR で人がレビュー
6. 社内文書も探したいとき、または Web に出られない閉域網では、Knowledge Bases に文書を取り込んで引く(フェーズ4。下の「Web に出られないときの代替案」も参照)。Claude Code から呼ぶ経路は AWS Labs の MCP サーバーか aws CLI で、構成案

本編のサンプルとの対応

aws-docs-lookup / code-architect + architecture-review(本編 #ops-kit)

サブスクリプション契約ならどう変わるか

WebSearch が使えるので当たり先を知らなくても探せる。WebFetch の規律(逐語・区別)はそのまま有効。

注意

• WebFetch の preflight を塞いでいる閉域網では skipWebFetchPreflight か通信許可が要る
• websearch サーバーは選んだ検索プロバイダ(Brave・Tavily・Exa・自作)に検索語を送る(公式: Search queries go to whichever backend you configure)。社外に出してよい語の決めと、プロバイダの選定は組織の判断(推論の国内処理とは別の話)
• Desktop の既定では隔離環境から推論先にしか出られない。検索で見つけた原典を読むには coworkEgressAllowedHosts に docs.aws.amazon.com などを足すか、builtinBrowserEnabled を有効にする(内蔵ブラウザも既定はオフ)
• websearch のベンダー鍵を headers で配ると全端末で同じ鍵になり、利用者が取り出せる(公式は被害を課金の濫用に限定と説明)。利用額の上限を決めるか、headersHelper で利用者ごとの鍵にする
• Knowledge Bases は bedrock-agent / bedrock-agent-runtime 側の機能(入口は Bedrock の通常の API 側)で、Mantle 入口では使えない。本編の用語解説を参照

• Claude Code: Tools reference(WebFetch / WebSearch) ↗
• Claude Code: Permissions ↗
• Amazon Bedrock Knowledge Bases ↗
• Bedrock API: Retrieve(bedrock-agent-runtime) ↗
• Bedrock API: StartIngestionJob(bedrock-agent) ↗
• AWS General Reference: Bedrock endpoints(bedrock-agent-runtime.ap-northeast-1 がある) ↗
• AWS Labs MCP: Bedrock KB Retrieval MCP Server(README。タグ mcp-multirag-kb、ツール ListKnowledgeBases / QueryKnowledgeBases) ↗
• AWS Labs MCP: AWS Documentation MCP Server(README。read_documentation / search_documentation、MCP_USER_AGENT) ↗
• Claude Code: Network configuration(HTTPS_PROXY・必要なホスト・skipWebFetchPreflight) ↗
• Claude Code Docs: llms.txt(全文書の索引。llms-full.txt が全文) ↗
• Claude Desktop on third-party platforms(Overview。websearch サーバー・内蔵ブラウザ) ↗

テスト

観点の洗い出しとテストの作成は Claude、実行は CI、合否と不安定なテストの扱いは人。

フェーズ1: 観点表とテストを書く(開発者の手元)

#	誰から → 誰へ	何を送る / 何が返る	種別
1	開発者 → Claude Code (qa + qa-test-plan)	観点表とテストを依頼(受け入れ条件つき)	要求
2	Claude Code (qa + qa-test-plan) → Bedrock (jp. 推論プロファイル)	推論(受け入れ条件 + qa-test-plan の本文)	要求
3	Bedrock (jp. 推論プロファイル) → Claude Code (qa + qa-test-plan)	観点表・テストコード・「テストを実行せよ」	応答
4	Claude Code (qa + qa-test-plan) → Claude Code (qa + qa-test-plan)	テスト実行(npm test / mvn test など)	要求
5	Claude Code (qa + qa-test-plan) → フック (test-marker・stop-check)	PostToolUse(Bash の結果の JSON)	要求
6	フック (test-marker・stop-check) → Claude Code (qa + qa-test-plan)	test-marker: 「テストが走った」印を残す	応答
7	Claude Code (qa + qa-test-plan) → フック (test-marker・stop-check)	Stop	要求
8	フック (test-marker・stop-check) → Claude Code (qa + qa-test-plan)	stop-check: 印が無ければ block + 理由	応答
9	Claude Code (qa + qa-test-plan) → 開発者	観点表・テスト・実行結果(「走らせた」事実の報告)	応答
10	開発者 → CodeCommit	git push + CreatePullRequest(テストコードを含める)	要求

落ちたテストを消す・skip にするのを禁じるのは文章の約束。機械で守るのはフェーズ3の人のレビュー。

フェーズ2: CI で単体・結合・E2E を実行(無人)

#	誰から → 誰へ	何を送る / 何が返る	種別
1	CodeCommit → EventBridge (ルール)	イベント「CodeCommit Pull Request State Change」(PR の作成・更新)	自動(通知・記録)
2	EventBridge (ルール) → CodeBuild	StartBuild(環境変数に PR ID・コミット ID)	要求
3	CodeBuild → ECR (テスト用イメージ)	イメージの取得(ブラウザ・DB 入りのテスト用イメージ)	要求
4	ECR (テスト用イメージ) → CodeBuild	イメージ	応答
5	CodeBuild → Secrets Manager	GetSecretValue(テスト用の鍵)	要求
6	Secrets Manager → CodeBuild	値(ログに出さない)	応答
7	CodeBuild → CodeBuild	単体・結合・E2E を実行	要求
8	CodeBuild → S3	PutObject(レポート・録画・カバレッジ)	要求
9	CodeBuild → CloudWatch Logs	ビルドログ(自動で送られる)	自動(通知・記録)
10	CodeBuild → Bedrock (jp. 推論プロファイル)	失敗したときだけ claude -p(失敗ログ + 差分)	要求
11	Bedrock (jp. 推論プロファイル) → CodeBuild	失敗の要約(どのテストが・何で・怪しい箇所)	応答
12	CodeBuild → CodeCommit	PostCommentForPullRequest(結果 + 要約 + S3 の場所)	要求
13	CodeBuild → CodeCommit	UpdatePullRequestApprovalState(全部合格のときだけ)	要求

CodeCommit に GitHub の「必須チェック」は無い。承認ルールの承認者プールにビルドの assumed-role を入れ、13 の承認を必須にして代用する(公式: 承認者プールは assumed role に対応。構成案)。

フェーズ3: 人が受け入れ条件と突き合わせて判定

#	誰から → 誰へ	何を送る / 何が返る	種別
1	テックリード / レビュー担当 → CodeCommit	PR を開く	要求
2	CodeCommit → テックリード / レビュー担当	テスト結果のコメント・失敗の要約・ビルドの承認状態	応答
3	テックリード / レビュー担当 → テックリード / レビュー担当	受け入れ条件(tech-lead の観点表)と突き合わせる	要求
4	テックリード / レビュー担当 → Claude Desktop (任意)	(任意)「この失敗は仕様か実装か」と聞く	要求
5	Claude Desktop (任意) → Bedrock (jp. 推論プロファイル)	推論	要求
6	Bedrock (jp. 推論プロファイル) → Claude Desktop (任意)	見立て(根拠の行つき)	応答
7	Claude Desktop (任意) → テックリード / レビュー担当	見立て	応答
8	テックリード / レビュー担当 → CodeCommit	承認、または差し戻しのコメント	要求
9	テックリード / レビュー担当 → CodeCommit	マージ(人のルールとビルドのルールの両方が揃ったとき)	要求

判定は人。Claude の見立ては材料。

流れ(要約)

1. qa が観点表とテストコードを書き、CodeCommit の PR に含める
2. EventBridge が PR イベントで CodeBuild を起動し、単体・結合・E2E を実行、成果物を S3、ログを CloudWatch Logs へ
3. 失敗したときだけ claude -p でログを要約し、PR にコメント
4. 結果と要約を見て、tech-lead の受け入れ条件と突き合わせ、人が承認・判定(承認ルールテンプレートで承認を必須に)

本編のサンプルとの対応

qa + qa-test-plan / tech-lead / test-marker・stop-check(本編 #ops-kit)

サブスクリプション契約ならどう変わるか

手元は同じ。CodeCommit のままなら CI の形も同じ(Anthropic 管理の環境では、リポジトリの取得と PR 作成は GitHub が前提。非 GitHub は読み取り専用のバンドルで送れるが結果は push で戻せない。自社の self-hosted environment で CodeCommit が使えるかは未確認)。

注意

• Claude の「テストが通った」は「走らせた」事実の報告。落ちたテストを消す・skip にする行為を禁じるのは文章の約束で、機械で守るなら PR のレビューで見る
• CodeCommit に GitHub の「必須チェック」と同じ機能は無い。代わりに、承認ルールの承認者プールに CodeBuild の assumed-role を入れ、テストが通ったときだけビルドが承認する形にできる(公式: 承認者プールは Lambda や CodeBuild が使う assumed role にも対応。構成案)。人の承認は別のルールで必須にする
• E2E の実行環境(ブラウザ・DB)は CodeBuild のイメージ側で用意する

• CodeCommit: Monitoring events(PR のイベント) ↗
• CodeCommit: Create an approval rule(承認者プールに assumed role) ↗
• Claude Code: Hooks reference(Stop / PostToolUse) ↗
• Claude Code: Create custom subagents ↗

受け入れ

本番に出す前に、材料は Claude が揃え、Go / No-Go は人が押す。承認の記録を残す。

フェーズ1: Go / No-Go の材料を揃える(リリース担当の手元)

#	誰から → 誰へ	何を送る / 何が返る	種別
1	リリース担当 → Claude Code (/release-check)	/release-check(対象の版・範囲)	要求
2	Claude Code (/release-check) → CodeCommit	前回のリリースタグからの差分と PR の一覧(git log / GetDifferences / ListPullRequests)	要求
3	CodeCommit → Claude Code (/release-check)	コミット・PR・レビューのコメント	応答
4	Claude Code (/release-check) → Bedrock (jp. 推論プロファイル)	推論(差分 + テスト結果 + 未解決の指摘 + release-check の本文)	要求
5	Bedrock (jp. 推論プロファイル) → Claude Code (/release-check)	材料(変更一覧・影響範囲・残る指摘・確認してほしい項目)	応答
6	Claude Code (/release-check) → リリース担当	材料(Go / No-Go を書かせるかはチームの決め)	応答
7	リリース担当 → CodeCommit	リリース用のタグ / ブランチ(release/x.y)を push	要求

法務・契約に関わる案件は、Claude には材料だけ出させて判断は書かせない。

フェーズ2: ステージングへ配備してカナリアで叩く(自動)

#	誰から → 誰へ	何を送る / 何が返る	種別
1	CodeCommit → EventBridge (ルール)	イベント「CodeCommit Repository State Change」(referenceCreated / referenceUpdated: release/*)	自動(通知・記録)
2	EventBridge (ルール) → CodePipeline	StartPipelineExecution	要求
3	CodePipeline → CodeBuild	ビルド・配備のアクション(ソース = そのコミット)	要求
4	CodeBuild → ECS Fargate (ステージング)	UpdateService(新しいタスク定義へ)	要求
5	ECS Fargate (ステージング) → CodeBuild	配備の状態(安定したか)	応答
6	CloudWatch Synthetics → ECS Fargate (ステージング)	カナリア(定期に主要な画面・API を叩く)	要求
7	ECS Fargate (ステージング) → CloudWatch Synthetics	応答(成功 / 失敗・スクリーンショット)	応答

カナリアのシナリオ(どの画面を・何秒で)は人が決める。

フェーズ3: 材料をまとめて承認を依頼(自動)

#	誰から → 誰へ	何を送る / 何が返る	種別
1	CodePipeline (手動承認アクション) → CodeBuild (claude -p)	要約のアクション	要求
2	CodeBuild (claude -p) → CloudWatch Synthetics	GetCanaryRuns(直近の結果)	要求
3	CloudWatch Synthetics → CodeBuild (claude -p)	成功 / 失敗・スクリーンショットの場所	応答
4	CodeBuild (claude -p) → Bedrock (jp. 推論プロファイル)	claude -p(差分 + テスト結果 + カナリアの結果 を要約)	要求
5	Bedrock (jp. 推論プロファイル) → CodeBuild (claude -p)	受け入れ用の要約(何が変わる・何を確かめた・残る懸念)	応答
6	CodeBuild (claude -p) → S3	PutObject(要約・証跡)	要求
7	CodePipeline (手動承認アクション) → SNS	手動承認アクションで停止 → 承認依頼を Publish	要求
8	SNS → 確認者 (発注側)	通知(メール。要約の S3 の場所を含む)	自動(通知・記録)

7 で止まったまま7日たつと、承認も却下もされないアクションは失敗扱い。

フェーズ4: 確認者が納得して承認、本番へ(人)

#	誰から → 誰へ	何を送る / 何が返る	種別
1	確認者 (発注側) → S3	要約・差分・結果を取得(通知の場所から。コンソールか署名付き URL)	要求
2	S3 → 確認者 (発注側)	文書	応答
3	確認者 (発注側) → Claude Desktop (Chat / Cowork)	質問(この変更で何が変わる? 前回との違いは?)	要求
4	Claude Desktop (Chat / Cowork) → Bedrock (jp. 推論プロファイル)	推論(文書を添えて)	要求
5	Bedrock (jp. 推論プロファイル) → Claude Desktop (Chat / Cowork)	答え	応答
6	Claude Desktop (Chat / Cowork) → 確認者 (発注側)	答え	応答
7	確認者 (発注側) → CodePipeline	PutApprovalResult(Approved / Rejected + コメント)	要求
8	CodePipeline → ECS Fargate (本番)	承認後のステージ: 本番へ配備(UpdateService)	要求
9	CodePipeline → CloudTrail	7 の操作が記録される(呼び出し元・時刻)	自動(通知・記録)

承認できる人は IAM で絞る。確認者の Desktop で Chat を使うなら chatTabEnabled を true にして配る(既定はオフ)。CloudTrail で長期に残すには trail を作る。

流れ(要約)

1. リリース担当が /release-check を起動し、Go / No-Go の材料を揃える
2. CodeCommit のリリースタグ(ブランチ)をソースに CodePipeline が起動し(変更は EventBridge で検知)、ステージングに配備し、Synthetics のカナリアが叩く。CodeBuild の claude -p が差分と結果を要約して S3 に残す
3. 手動承認アクションで止まり、SNS が承認依頼を通知
4. 発注側の確認者が Desktop on 3P で材料を読み(要約・結果・差分)、質問して納得してから承認(人)。承認後に本番へ
5. 承認の操作は CloudTrail に残る

本編のサンプルとの対応

release-check / tech-lead / qa(本編 #ops-kit)。役割分担は本編 #ops の「段取り」

サブスクリプション契約ならどう変わるか

材料づくりは同じ。ステージングの確認を Chrome 拡張や Computer use(Pro / Max)で Claude に操作させる選択肢が増える。承認そのものは変わらず人。

注意

• Claude に Go / No-Go を書かせるか、材料だけ出させるかはチームの決め(法務・契約に関わる案件は後者)
• 手動承認の承認者は IAM で絞る(誰でも押せる状態にしない)。7日以内に承認も却下もされないとアクションは失敗扱い
• CloudTrail で承認の操作を長期に残すには trail を作る(Event history は直近のみ)
• 確認者の Desktop で Chat を使うなら chatTabEnabled を true にして配る(既定はオフ)。Chat でのコード実行は chatAdvancedFileAnalysisEnabled が別に要り、その隔離環境にネットワークは無い

• CodePipeline: Add a manual approval action ↗
• CloudWatch Synthetics (canaries) ↗
• Claude Code: Extend Claude with skills(disable-model-invocation) ↗
• Claude Desktop on third-party platforms(Overview) ↗

運用

毎朝の点検と、アラートからの自動一次調査。無人実行は AWS 側で、本番の変更は人。

フェーズ1: 毎朝の点検(無人)

#	誰から → 誰へ	何を送る / 何が返る	種別
1	EventBridge Scheduler → CodeBuild (claude -p)	StartBuild(毎朝 09:00 JST。少なくとも1回届く)	要求
2	CodeBuild (claude -p) → CloudWatch	DescribeAlarms / GetMetricData / StartQuery(読み取りだけ)	要求
3	CloudWatch → CodeBuild (claude -p)	アラーム状態・メトリクス・ログの集計	応答
4	CodeBuild (claude -p) → Bedrock (jp. 推論プロファイル)	claude -p(点検結果 + daily-health の本文を --append-system-prompt-file で)	要求
5	Bedrock (jp. 推論プロファイル) → CodeBuild (claude -p)	点検レポート(異常の有無・前日との差・見るべき項目)	応答
6	CodeBuild (claude -p) → CodeCommit	CreateCommit(reports/YYYY-MM-DD.md を専用ブランチへ)+ CreatePullRequest	要求
7	CodeCommit → CodeBuild (claude -p)	pullRequestId	応答
8	CodeBuild (claude -p) → SNS	Publish(PR の場所 + 要点)	要求
9	SNS → 当番	通知(メール、または Q Developer in chat applications 経由で Slack)	自動(通知・記録)

同じ日に2回走っても同じファイルに書く(冪等)。IAM の権限は CloudWatch の describe / get / list / start-query と、CodeCommit の該当ブランチへの書き込みだけ。

フェーズ2: アラート時の一次調査(無人)

#	誰から → 誰へ	何を送る / 何が返る	種別
1	ECS Fargate (本番) → CloudWatch (アラーム)	ログ・メトリクス(awslogs ドライバ / エージェント)	自動(通知・記録)
2	CloudWatch (アラーム) → CloudWatch (アラーム)	アラームが ALARM に(しきい値、またはログ異常検知)	要求
3	CloudWatch (アラーム) → SNS	アラーム通知(名前・状態・理由)	自動(通知・記録)
4	SNS → Lambda (まとめ・重複排除)	配信(少なくとも1回)	自動(通知・記録)
5	Lambda (まとめ・重複排除) → Lambda (まとめ・重複排除)	まとめ・重複排除(同じアラームが N 分内なら起動しない)	要求
6	Lambda (まとめ・重複排除) → CodeBuild (claude -p)	StartBuild(environmentVariablesOverride にアラーム名・時刻・理由)	要求
7	CodeBuild (claude -p) → CloudWatch (アラーム)	GetLogEvents / StartQuery / GetMetricData(前後 30 分)	要求
8	CloudWatch (アラーム) → CodeBuild (claude -p)	周辺のログ・メトリクス	応答
9	CodeBuild (claude -p) → Bedrock (jp. 推論プロファイル)	claude -p(アラーム + ログ + incident-triage の本文)	要求
10	Bedrock (jp. 推論プロファイル) → CodeBuild (claude -p)	調査メモ(事実・仮説・次に見る所・修正案)	応答
11	CodeBuild (claude -p) → CodeCommit	CreateCommit + CreatePullRequest(incidents/YYYY-MM-DD-*.md)	要求
12	CodeBuild (claude -p) → SNS	Publish(PR の場所)	要求

緩和・ロールバックは Claude にさせない(ビルドのロールに権限を渡さない)。CodeCommit に Issue は無いので置き場は PR か S3 + SNS(構成案)。

フェーズ3: 当番の判断(人 + Desktop)

#	誰から → 誰へ	何を送る / 何が返る	種別
1	SNS → Q Developer in chat applications	配信(トピックを購読)	自動(通知・記録)
2	Q Developer in chat applications → Slack	チャンネルに投稿(アラーム + PR の場所)	自動(通知・記録)
3	Slack → 当番	通知	自動(通知・記録)
4	当番 → Claude Desktop (Code タブ)	調査メモ(PR)の続きを依頼(incident-triage)	要求
5	Claude Desktop (Code タブ) → CloudWatch	describe / get / start-query(当番の権限で)	要求
6	CloudWatch → Claude Desktop (Code タブ)	ログ・メトリクス	応答
7	Claude Desktop (Code タブ) → Bedrock (jp. 推論プロファイル)	推論	要求
8	Bedrock (jp. 推論プロファイル) → Claude Desktop (Code タブ)	絞り込んだ原因候補と確認手順	応答
9	Claude Desktop (Code タブ) → 当番	同上	応答
10	当番 → ECS Fargate (本番)	緩和(UpdateService で前のタスク定義へ戻す、など)。人の操作	要求
11	当番 → Slack	対応を記録	要求

Desktop の予定タスクは、寝ていた間の分の扱いが公式2ページで異なる(「起きたときに走る」と「飛ばされる」)。時刻に厳密な点検はフェーズ1のように AWS 側に置く。

フェーズ4: 推論費用の見張り(Budgets)

#	誰から → 誰へ	何を送る / 何が返る	種別
1	Bedrock (jp. 推論プロファイル) → AWS Budgets	利用料(請求データに反映。更新は1日最大3回)	自動(通知・記録)
2	AWS Budgets → AWS Budgets	実績 / 予測がしきい値を超えたか	要求
3	AWS Budgets → SNS	Publish(予算の通知)	要求
4	SNS → 管理者	メール / Slack	自動(通知・記録)
5	AWS Budgets → IAM / SCP	予算アクション: Deny の IAM ポリシーを当てる(対象は IAM ユーザー / グループ / ロール。この案件は IAM ユーザーなので直接)	要求
6	IAM / SCP → Bedrock (jp. 推論プロファイル)	以後の InvokeModel が Deny になる	自動(通知・記録)
7	管理者 → IAM / SCP	復旧(アクションの取り消し・ポリシーの解除)	要求

1 の更新間隔のため即時の上限ではない。トークンの上限は Bedrock 側のクォータ(本編 #aws-glossary)と組み合わせる。

流れ(要約)

1. EventBridge Scheduler が毎朝 CodeBuild を起動し、claude -p "/daily-health" が CloudWatch を読み取り(describe / get / start-query)で点検し、レポートを CodeCommit の reports/ に PR で残して SNS で通知
2. 本番アプリのログ・メトリクスで CloudWatch のアラームが ALARM → SNS
3. SNS → Lambda がアラートをまとめ・重複排除し、本文つきで StartBuild。incident-triage が調査して CodeCommit の PR(調査メモと修正案)に書く
4. 同じ SNS から Q Developer in chat applications が Slack に通知。当番が読み、必要なら手元の Desktop on 3P で incident-triage を続けて判断
5. Budgets が推論費用の予算を見張り、超えたらアクションで IAM ポリシーを当てる(対象は IAM ユーザー / グループ / ロール。Identity Center のロールは保護されていて SCP になるが、この案件は IAM ユーザーなので直接当てられる)。更新は1日最大3回なので即時の上限ではない。CloudTrail で処理リージョンを監査

本編のサンプルとの対応

daily-health / incident-triage / sre / jp-only-policy(本編 #ops-kit)。全部入りプランの部品(本編 #ops)

サブスクリプション契約ならどう変わるか

ルーティン(スケジュール / API トリガー)はリポジトリの取得に GitHub が要る(公式: Routines need GitHub access to clone repositories)ので、CodeCommit のままなら無人実行は AWS 側のまま(self-hosted environment での可否は未確認)。Slack への返答は Claude Tag。詳細は本編 #sub-ops。

注意

• SNS → Lambda も EventBridge Scheduler も「少なくとも1回」届く方式。重複排除は Lambda 側と、起動される側の冪等性で
• CodeCommit の公式機能に Issue 管理は見当たらない(本編の確認範囲)。調査結果の置き場は PR(メモのファイルを含む)か S3 + SNS 通知にする(構成案)
• CloudWatch の読み取りは IAM で describe / get / list / start-query に絞る。スキルの allowed-tools も同じ形に
• Q Developer in chat applications の東京リージョン提供は本編で確認済み
• Desktop の予定タスクは、寝ていた間の分を「起きたときに走る」(3P の Features 表)と「飛ばされる」(Code の予定タスク文書)で公式2ページの書きぶりが違う。時刻に厳密な点検は AWS 側に置く

• EventBridge Scheduler: What is ↗
• Lambda: Invoking with Amazon SNS(at-least-once) ↗
• CloudWatch: Log anomaly detection ↗
• Amazon Q Developer in chat applications ↗
• AWS Budgets actions(IAM ポリシー / SCP) ↗
• AWS Budgets: 更新は1日最大3回 ↗
• Claude Desktop on third-party platforms(Overview。予定タスク) ↗

保守

依存・言語・フレームワーク・OS・モデルの更新を、定期ジョブと監査役と CI で回し続ける(Dependabot は GitHub の機能なので使わない)。

フェーズ1: 更新の検知と更新 PR の作成(無人)

#	誰から → 誰へ	何を送る / 何が返る	種別
1	EventBridge Scheduler → CodeBuild (claude -p)	StartBuild(週次)	要求
2	ECR 拡張スキャン (Inspector) → EventBridge (ルール)	イベント「Inspector2 Finding」(CVE・イメージ・重大度)	自動(通知・記録)
3	EventBridge (ルール) → CodeBuild (claude -p)	StartBuild(環境変数にイメージ名・CVE)	要求
4	CodeBuild (claude -p) → CodeBuild (claude -p)	npm outdated / mvn versions:display-dependency-updates(版の一覧)	要求
5	CodeBuild (claude -p) → リリースノート (公式)	WebFetch(リリースノート・移行ガイド)	要求
6	リリースノート (公式) → CodeBuild (claude -p)	本文	応答
7	CodeBuild (claude -p) → Bedrock (jp. 推論プロファイル)	claude -p(版の差 + 破壊的変更 + リリースノート)	要求
8	Bedrock (jp. 推論プロファイル) → CodeBuild (claude -p)	更新案(どの版へ・何が壊れうる・必要な変更)	応答
9	CodeBuild (claude -p) → CodeBuild (claude -p)	変更を適用してテスト	要求
10	CodeBuild (claude -p) → CodeCommit	CreateCommit(deps/* ブランチ)+ CreatePullRequest(更新内容・根拠・未確認の点)	要求
11	CodeCommit → CodeBuild (claude -p)	pullRequestId	応答

CodeCommit に Dependabot は無いので定期ジョブで代用(構成案)。OS は Patch Manager(managed nodes)。本番が Fargate ならイメージの更新で追う。

フェーズ2: 更新 PR の自動監査(無人)

#	誰から → 誰へ	何を送る / 何が返る	種別
1	CodeCommit → EventBridge (ルール)	イベント「CodeCommit Pull Request State Change」	自動(通知・記録)
2	EventBridge (ルール) → CodeBuild (claude -p)	StartBuild(PR ID)	要求
3	CodeBuild (claude -p) → CodeCommit	GetDifferences	要求
4	CodeCommit → CodeBuild (claude -p)	差分	応答
5	CodeBuild (claude -p) → CodeBuild (claude -p)	テスト	要求
6	CodeBuild (claude -p) → Bedrock (jp. 推論プロファイル)	claude -p(差分 + 言語・フレームワーク別の監査: angular-audit / spring-audit / typescript-audit / java-audit の該当分)	要求
7	Bedrock (jp. 推論プロファイル) → CodeBuild (claude -p)	[高 / 中 / 低] の指摘(根拠の行つき)	応答
8	CodeBuild (claude -p) → Bedrock (jp. 推論プロファイル)	claude -p(差分 + security-audit)	要求
9	Bedrock (jp. 推論プロファイル) → CodeBuild (claude -p)	セキュリティの指摘	応答
10	CodeBuild (claude -p) → Bedrock (jp. 推論プロファイル)	claude -p(マイグレーション / SQL があれば db-review)	要求
11	Bedrock (jp. 推論プロファイル) → CodeBuild (claude -p)	DB の指摘(ロック・インデックス・後方互換)	応答
12	CodeBuild (claude -p) → CodeCommit	PostCommentForPullRequest(統合した指摘。10,240 文字で分割)	要求
13	CodeBuild (claude -p) → CodeCommit	UpdatePullRequestApprovalState(テスト合格 かつ 高が 0 のとき)	要求

6〜11 は並行でもよい。--bare 起動なので各スキルの本文は --append-system-prompt-file で渡す。監査スキルに書いた版の事実は 2026-10-07 時点。

フェーズ3: 人の判断・配備・配備後の監視

#	誰から → 誰へ	何を送る / 何が返る	種別
1	レビュー担当 → CodeCommit	指摘を読む(大きい更新なら ADR を要求)	要求
2	レビュー担当 → CodeCommit	承認 + マージ(main)	要求
3	CodeCommit → EventBridge (ルール)	イベント「CodeCommit Repository State Change」(referenceUpdated: main)	自動(通知・記録)
4	EventBridge (ルール) → CodePipeline	StartPipelineExecution	要求
5	CodePipeline → ECS Fargate (本番)	配備(UpdateService。手動承認アクションを挟むかはチームの決め)	要求
6	ECS Fargate (本番) → CloudWatch	メトリクス・ログ	自動(通知・記録)
7	CloudWatch → CloudWatch	配備後のしきい値 / 異常検知(回帰)	要求
8	CloudWatch → SNS	アラーム → 運用のフェーズ2へ	自動(通知・記録)
9	レビュー担当 → ECS Fargate (本番)	回帰なら前のタスク定義へ戻す(人)	要求

使っている jp. のモデルの EOL(model-lifecycle / model-lifecycle-legacy)を保守の項目に入れる。

流れ(要約)

1. EventBridge Scheduler が定期に CodeBuild を起動し、依存の新しい版を調べて(npm outdated・Maven/Gradle の版確認など)、Claude が更新 PR を CodeCommit に作る(構成案)。ECR 拡張スキャン(Inspector)の脆弱性検出も更新の起点(EventBridge にイベントが出る)
2. PR イベントで CodeBuild がテストと claude -p を回し、言語・フレームワーク別の監査役が [高/中/低] の指摘を PR に返す
3. セキュリティ監査と DB の点検を並行。大きな更新は ADR
4. 人が承認してマージし、配備後の回帰を CloudWatch で見る
5. OS は Patch Manager、モデルは Bedrock のモデルカードの EOL(本編の用語解説)で期限を追う

本編のサンプルとの対応

言語・フレームワーク別の監査役4本 + security-auditor / db-reviewer / code-architect(本編 #ops-kit)

サブスクリプション契約ならどう変わるか

Code Review(GitHub App)やルーティンの GitHub トリガーは GitHub のリポジトリが前提なので、CodeCommit では使えない。手元の reviewer と CI の claude -p は同じ。

注意

• 監査スキルに書いた版の事実は 2026-10-07 時点。スキル先頭の「版を確かめる」で確かめ直す
• Patch Manager の対象は managed nodes(EC2・オンプレ・VM など)。本番が ECS Fargate なら OS ではなくコンテナイメージの更新(ECR の拡張スキャン)で追う
• Bedrock のモデルは Legacy → EOL の期限がある(本編 #aws-glossary)。2026-09-07 以降に出たモデルとそれ以前で文書が別(model-lifecycle / model-lifecycle-legacy)。使っている jp. のモデルの期限を保守の項目に入れる

• EventBridge Scheduler: What is ↗
• CodeCommit: Approval rule templates ↗
• Amazon ECR: Scan images for software vulnerabilities ↗
• AWS Systems Manager Patch Manager ↗
• Amazon Bedrock: Model lifecycle(2026-09-07 以降のモデル) ↗
• Amazon Bedrock: Model lifecycle(それ以前のモデル) ↗

SRE

SLO を数え、予算の燃え方で動き、障害の後に仕組みを直す。計測は AWS、解釈と下書きは Claude、判断は人。

フェーズ1: SLO の計測とバーンレートのアラーム(自動)

#	誰から → 誰へ	何を送る / 何が返る	種別
1	ECS Fargate (本番) → CloudWatch Application Signals	メトリクス・トレース(ADOT / CloudWatch エージェント。対応は Java・Python・Node.js・.NET)	自動(通知・記録)
2	ECS Fargate (本番) → X-Ray	トレース(セグメント)	自動(通知・記録)
3	CloudWatch Application Signals → CloudWatch Application Signals	SLI → SLO の達成率・エラーバジェット・バーンレート	要求
4	CloudWatch Application Signals → CloudWatch (アラーム)	SLO のメトリクス(アラームの元)	自動(通知・記録)
5	CloudWatch (アラーム) → CloudWatch (アラーム)	バーンレートのアラームが ALARM(しきい値と窓は人が決める)	要求
6	CloudWatch (アラーム) → SNS	通知	自動(通知・記録)
7	SNS → Lambda	配信(少なくとも1回)	自動(通知・記録)
8	Lambda → CodeBuild (claude -p)	StartBuild(SLO 名・時刻・バーンレート)	要求

バーンレートのしきい値と窓はチームの決め。Claude に決めさせない。

フェーズ2: SLO 消費時の調査(無人)

#	誰から → 誰へ	何を送る / 何が返る	種別
1	CodeBuild (claude -p) → Application Signals	list-service-level-objectives / batch-get-service-level-objective-budget-report	要求
2	Application Signals → CodeBuild (claude -p)	SLO の定義・残りのエラーバジェット	応答
3	CodeBuild (claude -p) → X-Ray	GetTraceSummaries(遅い・失敗のトレース)/ BatchGetTraces	要求
4	X-Ray → CodeBuild (claude -p)	トレース(どの依存で時間を使ったか)	応答
5	CodeBuild (claude -p) → CloudWatch Logs	StartQuery / GetQueryResults(該当時間のログ)	要求
6	CloudWatch Logs → CodeBuild (claude -p)	ログ	応答
7	CodeBuild (claude -p) → Bedrock (jp. 推論プロファイル)	claude -p(SLO + トレース + ログ + sre の本文)	要求
8	Bedrock (jp. 推論プロファイル) → CodeBuild (claude -p)	調査メモ(影響範囲・原因候補・直近の変更との関係・次の手)	応答
9	CodeBuild (claude -p) → CodeCommit	CreateCommit + CreatePullRequest(incidents/)	要求
10	CodeBuild (claude -p) → SNS	Publish(PR の場所)	要求
11	SNS → 当番	通知	自動(通知・記録)

AWS Labs の CloudWatch MCP サーバーに SLO 専用ツールは無い。SLO は aws CLI(application-signals)で読むか、Application Signals 用 MCP サーバーを使う。

フェーズ3: 週次の SLO レビュー(無人 → 人)

#	誰から → 誰へ	何を送る / 何が返る	種別
1	EventBridge Scheduler → CodeBuild (claude -p)	StartBuild(週次)	要求
2	CodeBuild (claude -p) → Application Signals	batch-get-service-level-objective-budget-report(1週間)	要求
3	Application Signals → CodeBuild (claude -p)	SLO ごとの達成率・バジェットの残り	応答
4	CodeBuild (claude -p) → CloudWatch (アラーム履歴)	DescribeAlarmHistory(1週間)	要求
5	CloudWatch (アラーム履歴) → CodeBuild (claude -p)	鳴ったアラーム・時刻	応答
6	CodeBuild (claude -p) → CodeCommit	1週間の変更(GetCommit / ListPullRequests)	要求
7	CodeCommit → CodeBuild (claude -p)	コミット・PR	応答
8	CodeBuild (claude -p) → Bedrock (jp. 推論プロファイル)	claude -p(以上 + sre-ops-review の本文)	要求
9	Bedrock (jp. 推論プロファイル) → CodeBuild (claude -p)	週次レポート(変更の影響・アラームの妥当性・戻す手順の有無)	応答
10	CodeBuild (claude -p) → CodeCommit	CreatePullRequest(reports/sre/YYYY-WW.md)	要求
11	SRE → CodeCommit	読む。しきい値の変更は人が決めて別の PR で	要求

レポートの提案をそのまま採用しない。アラームを消す・緩める判断は人。

フェーズ4: 障害後のポストモーテムとランブック(人 + Desktop)

#	誰から → 誰へ	何を送る / 何が返る	種別
1	当番 → Claude Desktop (Cowork)	時系列・調査メモ・チャットの記録を渡す(手元のファイル)	要求
2	Claude Desktop (Cowork) → Bedrock (jp. 推論プロファイル)	推論	要求
3	Bedrock (jp. 推論プロファイル) → Claude Desktop (Cowork)	ポストモーテムの下書き(非難なし・時系列・根本原因・対策)	応答
4	Claude Desktop (Cowork) → 当番	下書き	応答
5	当番 → Claude Desktop (Cowork)	今回の手順からランブックの下書きを依頼	要求
6	Claude Desktop (Cowork) → Bedrock (jp. 推論プロファイル)	推論	要求
7	Bedrock (jp. 推論プロファイル) → Claude Desktop (Cowork)	ランブックの下書き(手順・確認点・戻し方)	応答
8	Claude Desktop (Cowork) → 当番	下書き	応答
9	当番 → CodeCommit	docs/postmortems/ と runbooks/ に PR	要求
10	チーム → CodeCommit	レビュー・確定(対策の期限と担当は人が決める)	要求

緩和・ロールバックは人。Desktop(Cowork)の隔離環境は既定で推論先にしか出られない。

流れ(要約)

1. 本番アプリのメトリクスとトレースを Application Signals と X-Ray が集め、SLO とバーンレートを計算
2. SLO の消費が速いとアラーム → SNS → Lambda → CodeBuild の claude -p(sre)が SLO・トレース・ログを読んで CodeCommit の PR(調査メモ)に報告し、SNS で通知
3. 週次は EventBridge Scheduler から sre-ops-review で、変更の影響・アラームの妥当性・戻す手順を点検
4. 障害の後、Claude(CodeBuild の sre、または当番の Desktop on 3P の Cowork)がポストモーテムとランブックを下書きし、人が確定
5. 緩和・ロールバックは人

本編のサンプルとの対応

sre + sre-ops-review / incident-triage(本編 #ops-kit)。SLI の数え方は /training 第28期

サブスクリプション契約ならどう変わるか

ルーティン + クラウドセッションはリポジトリの取得と PR 作成に GitHub が要る。CodeCommit のままなら無人実行は AWS 側のまま(本編 #sub-ops の注意)。

注意

• AWS Labs の CloudWatch MCP サーバーに SLO 専用ツールは無い(本編 #sub-ops)。SLO はアラームかメトリクスとして読むか、別の Application Signals 用 MCP サーバー(AWS Labs)を使う
• Application Signals が対応する言語・基盤は限られる(公式: Java・Python・Node.js・.NET、EKS・ECS・EC2 で検証)。使う前に対応表を確認
• バーンレートのしきい値と窓はチームの決め。Claude に決めさせない

• CloudWatch Application Signals ↗
• CloudWatch: Service level objectives ↗
• AWS X-Ray: What is ↗
• EventBridge Scheduler ↗
• Claude Desktop on third-party platforms(Overview。Cowork) ↗

早見表: 機能 × 活動

● 主役(その活動の「流れ」の主経路に出る)/ ○ 補助(図・部品の一覧・注だけに出る、または代替案としての言及)/ 空欄 その活動では使わない。Amazon Bedrock は全活動の前提なので常に ●。

7つの活動に共通する原則

1. Claude がやるのは「読む・書く・比べる・下書きする」まで。マージ・承認・本番の変更・DB の変更は、どの活動でも人。
2. 無人で動くものは AWS 側(EventBridge → CodeBuild / ECS → claude -p)に置き、Bedrock の jp. に固定する。Anthropic 側のルーティンは使わない(サブスク契約なら置き換わる)。
3. 歯止めは3段: 機械で止める(permissions.deny・IAM)、人に確認を出す(フックの ask・手動承認)、文章でお願いする(スキル・CLAUDE.md)。どの操作がどの段かを言えるようにしておく。
4. 読み取りの権限と書き込みの権限を分ける。調査・点検の役割は describe / get / list / start-query だけの IAM で動かす。
5. 記録を残す: 推論の処理リージョン(CloudTrail)、誰が承認したか(CloudTrail)、何を確かめて何を確かめていないか(報告の形式)。
6. リポジトリは CodeCommit。PR のイベントは EventBridge で拾い、本文が要るものは GetComment で取る。Issue 管理が見当たらないので調査結果は PR か S3 + SNS に置く。GitHub 前提の機能(Code Review・ルーティンの GitHub トリガー・Dependabot)は使わない設計にする。必須チェックの代わりは承認ルール(ビルドのロールを承認者に)。
7. 開発者以外の入口は Claude Desktop on 3P。会話とメモリは端末内に残り、Anthropic 側のクラウドセッション・利用者どうしの共有・スマホ・音声・Computer use は無い。設定(推論先・MCP・スキル)は MDM / ブートストラップ / 管理コンソールで配る。

部品の説明・雛形・出典は本編 Amazon Bedrock で Claude を使う、この構成に至った問いの連鎖は Bedrock 調査の記録 にあります。