結論：Bedrock権限をGatewayへ直付けせず、STSと対象roleを二つの境界で検証する
Claude Apps GatewayのBedrock upstreamには、STSでIAM roleを引き受けてBedrockを呼ぶassume_roleが追加されています。公式changelogでは、必要なら別AWSアカウントのroleを引き受け、developerごとに一つのsessionを使う構成も示されています。
読者の課題は、Gatewayを置く運用アカウントと、Claudeを呼ぶBedrockアカウントを分離した後、どのroleに何を許可すればよいか分からないことです。解決の要点は、Gateway側のSTS:AssumeRole、対象roleのtrust policy、Bedrockのinvoke権限、モデル利用条件、CloudTrailの相関を分けて設計することです。
一次情報はClaude Code公式changelogとClaude Apps Gateway公式文書です。Bedrock接続のcredential chainや設定はAmazon Bedrock利用の公式Claude Code文書、IAMのrole信頼関係はAWS IAM公式文書を確認します。
同一アカウント直付けとassume_roleを比較する
| 構成 | 向く場面 | 主な確認点 |
|---|---|---|
| Gateway roleから直接Bedrock | 小規模でアカウント境界が不要 | roleの最小権限、モデル、リージョン、監査 |
assume_roleで同一AWSアカウント内 | 推論用roleを分離したい | STS権限、trust policy、session name、失効 |
assume_roleで別アカウント | 運用・推論・請求・データ境界を分離 | account ID、external条件、Bedrock権限、CloudTrail |
別アカウントにしただけで最小権限になるわけではありません。対象roleが広いresourceへinvokeできると、Gatewayからその範囲へ到達できます。反対にSTSだけ許可しても、対象roleの信頼関係やBedrock利用条件が不足すれば呼び出せません。role ARN、region、model ID、caller identityを一つのreadback表にします。
設計時は「誰がroleを引き受けるか」と「引き受けた後に何を呼べるか」を一つの権限にまとめないことが重要です。source accountのGateway実行roleはSTSへの入口、target accountのBedrock roleは推論への出口です。両方に広い権限を付けると、設定ミスが別アカウントへ広がります。反対に一つずつ狭めれば、拒否が起きた位置をCloudTrailとGatewayのrequest IDから切り分けられます。
developerごとのsessionを使う場合も、個人credentialをGatewayのログや設定ファイルへ保存するという意味ではありません。sessionの名前・有効期限・利用者の対応表、失効の方法、ログの閲覧権限を先に決めます。共有sessionを選ぶ場合は、利用者単位の監査が弱くなるため、別の承認記録やrequest属性で補えるかを確認します。
最初の接続は、本番の顧客データや広いmodel権限で試しません。テスト用accountと許可済みmodelを使い、拒否されるべきrole、region違い、model access不足、STS期限切れをそれぞれ再現して、エラーと監査証跡が区別できる状態を作ります。
安全に接続する8手順
- アカウント責任を分ける。Gatewayを実行するaccount、Bedrockを呼ぶaccount、ログを保管するaccountを図にし、ownerを置きます。
- 対象モデルとregionを固定する。Anthropicモデルのmodel ID、Bedrock region、価格・利用条件を公開直前に公式画面と文書で照合します。
- 対象roleを新設する。既存の人間用roleや管理者roleを流用せず、Gateway専用にします。
- trust policyを絞る。信頼するprincipal、外部識別子など組織で必要な条件、許可するaccountをAWS IAMの正本で確認します。
- 呼び出し元のSTS権限を置く。Gatewayが対象roleを引き受けるための権限を、実行roleへ必要最小限だけ与えます。
- Bedrock権限を絞る。invoke対象のmodel ARN、region、必要なguardrailやMarketplace条件を対象roleへ割り当てます。
- session単位を決める。共有sessionかdeveloperごとのsessionかを、監査の粒度、credential寿命、同時利用から選びます。
- 実identityで検証する。CloudTrail、Gatewayのrequest ID、Bedrockの呼び出し、拒否時のエラーを相関し、失敗時は元の設定へ切り戻します。
クロスアカウント運用チェックリスト
- source account、target account、log accountのownerが明記されている。
- assume_role対象のrole ARN、region、model IDが固定されている。
- trust policyとSTS権限を別のレビューとして承認した。
- Bedrock invoke対象とguardrail、Marketplace、use case条件を確認した。
- developer別sessionの採否とsession nameの規則を決めた。
- CloudTrailとGatewayログでcaller、request、modelを追える。
- role失効、deny、切戻し、障害連絡の演習を行った。
よくある質問と次の行動
対象roleにAdministratorAccessを付けて先に試してよいですか？
本番用の確認方法としては避けます。無害なmodel・region・テストaccountで必要なアクションを洗い出し、最小権限のroleへ縮めます。
STS AssumeRoleが成功すればBedrockも成功しますか？
いいえ。STSのidentityとBedrockのmodel access、region、Marketplaceやuse caseの条件は別です。両方を実際のcaller identityでreadbackします。
developer別sessionは常に選ぶべきですか？
監査の説明力は上がり得ますが、session数、credential更新、ログ保持、同時実行が増えます。責任追跡の必要性と運用コストを比較して決めます。
Bedrockの初期認証やtimeoutはClaude CodeのBedrock設定切り分け、Gatewayのnetwork境界はegress boundaryの設計、利用量の監査はOTLP転送ガイドも参照してください。Miraigentの無料診断では、account境界、role、モデル、ログ、切戻しを一枚の判断表にします。