AIエージェントに外部API、SaaS、社内ツールを触らせるチームにとって、認証情報をどこで管理するかは実装の細部ではなく、本番運用の境界線です。
AWSは2026年6月1日、Amazon Bedrock AgentCore Identityで、既存のAWS Secrets Manager secret ARNをCredential Providerから参照できるようになったと発表しました。これにより、AgentCore Identityに認証情報を渡す方法は、サービス側に任せる方式だけでなく、自社で作成、タグ付け、暗号化、ローテーションしているSecrets Manager secretを使う方式も選べるようになります。
この記事では、Amazon Bedrock AgentCore IdentityのSecrets Manager参照対応を、AIエージェントの外部認証情報管理で何を確認すべきかに絞って整理します。確認日は2026年6月4日、Asia/Tokyo時点です。
Amazon Watch JapanはAmazon.com, Inc.、Amazon Web Services, Inc.および各関係会社と提携していない独立サイトです。この記事は製品・サービス更新の確認を目的としており、投資助言ではありません。
3行まとめ
このテーマをもう少し広げて見るなら、AWS Step FunctionsのAgentCore推論ステップとは：AIエージェントをワークフローに組み込む前に確認すべきこと と AWS ConfigがBedrock AgentCore/SageMaker系9リソースに対応：AI基盤の設定監査で確認すべきこと も合わせて確認してください。AgentCore Identityで認証情報の境界を確認した後、AgentCoreを業務ワークフローへ組み込む時の監査・承認・実行履歴を続けて確認できます。
Credential Providerで、Secrets Managerのsecret ARNとsecret内のJSON keyを指定できるようになりました。
タグ、customer managed KMS key、resource policy、rotation、監査を既存運用に合わせやすくなります。
secretsmanager:GetSecretValue、必要に応じたkms:Decrypt、同一リージョン制約、東京リージョン対応、料金の切り分けを確認します。
BYO secretは移行必須ではなく、既存の秘密情報管理をAgentCore Identityにもそろえる選択肢です。
- Amazon Bedrock AgentCore IdentityのCredential Providerで、既存のAWS Secrets Manager secret ARNとJSON keyを指定して、API keyやOAuth client secretを参照できるようになりました。
- 価値が出やすいのは、タグ、customer managed KMS key、resource policy、automatic rotation、監査などを既存のSecrets Manager運用にそろえたいチームです。
- 先に見るべきなのは、
secretsmanager:GetSecretValue、必要に応じたkms:Decrypt、同一リージョン制約、東京リージョン対応、AgentCore IdentityとSecrets Manager/KMSの料金の切り分けです。
今回の需要シグナルは、AWS What’s NewとAWS Machine Learning Blogの同日発表に加え、AgentCoreの料金、実装、ベストプラクティスをめぐるAWSコミュニティの関心です。ただし、仕様や料金の根拠にはAWS公式発表、AWS Blog、Developer Guide、Pricingページを使っています。
AgentCore Identityで何が変わったのか
- 1外部API認証情報
API keyやOAuth client secretをアプリケーションコードやプロンプトへ埋め込まずに扱います。
- 2既存Secrets Manager secret
利用者が事前に作成したsecretを、ARNでCredential Providerに渡します。
- 3JSON key指定
ARNだけでなく、secret value内のapiKeyやclientSecretなどのキー名も固定します。
- 4AgentCore Identity
Credential Providerやtoken vaultを通じて、エージェントの外部ツール接続を支えます。
- 5外部ツール呼び出し
GitHub、Slack、Salesforce、社内APIなどへの認証を、管理済みのsecret参照で行います。
変化の中心は、顧客が管理するSecrets Manager secretをCredential Providerから直接参照できるようになった点です。
Amazon Bedrock AgentCore Identityは、AIエージェントが外部ツールやリソースへアクセスするための認証情報を扱う機能です。エージェントがGitHub、Slack、Salesforce、社内API、OAuth providerなどを呼ぶ場合、アプリケーションコードやプロンプトにsecretを埋め込むのではなく、Credential Providerやtoken vaultを通じて認証情報を扱う設計になります。
今回の発表で変わったのは、Credential Providerが使うsecretの作り方です。従来はAgentCore Identityが顧客アカウント内にservice-managed secretを作成、管理する方式が中心でした。新しい対応では、利用者があらかじめ作成したSecrets Manager secretを指定し、そのARNとsecret内のJSON keyをCredential Providerに渡せます。
Credential Providerが既存secret ARNを参照できる
根拠
AWS What’s Newは、Amazon Bedrock AgentCore IdentityのCredential Providerで既存のAWS Secrets Manager secret ARNを直接参照できるようになったと説明しています。これにより、AgentCore Identityだけを例外的な秘密情報管理にする必要が下がります。
たとえば、外部APIのAPI keyをすでにSecrets Managerで管理し、タグ、KMS key、ローテーション、CloudTrail監査、削除手順まで決めているチームなら、その管理境界をAgentCore Identityにも持ち込めます。AIエージェントが使うsecretだけ別ルールになると、監査や棚卸しで見落としが起きやすくなります。BYO secretは、その例外を減らすための選択肢です。
API keyとOAuth client secretの扱いが広がる
確認項目
AWS Machine Learning Blogでは、API keyとOAuth client secretの両方で、Secrets Manager ARNとJSON keyを指定する流れが示されています。ここで大事なのは、ARNだけでは足りないことです。Credential Providerは、指定されたsecretの中にあるどのJSON keyを読むかも必要とします。
つまり、既存secretをそのまま使えるかどうかは、secretの名前だけでなく、secret valueの構造にも左右されます。apiKey、clientSecret、keyのようなキー名をどこで固定するか、ローテーションLambdaや手動更新でその構造を壊さないか、複数環境でキー名がずれないかを先に確認する必要があります。
便利になるほど責任範囲も変わる
注意点
BYO secretは、自由度を増やす機能です。タグ、CMK、resource policy、automatic rotation、Secrets Manager external connectors、クロスアカウント運用を自社の標準に寄せられます。
一方で、自由度が上がるほど利用者側の責任も増えます。secret valueの形式、JSON key名、KMS key policy、resource policy、rotation失敗時の戻し方、削除保護、監査ログの所有者は、サービス側に丸投げできません。AgentCore Identityの機能として読むより、自社の秘密情報管理にAgentCoreをどう参加させるか、という見方が実務的です。
Amazon Bedrock系の監視まで含めて見たい場合は、公開済みのAmazon Bedrock MantleにCloudWatchメトリクス追加の記事も参考になります。今回のテーマは認証情報管理ですが、AgentCoreを本番投入するなら監視設計も同じタイミングで見ておきたいところです。
BYO secretを選ぶべきケースと選ばないケース
セキュリティや監査の判断は単純な勝敗ではなく、既存運用の成熟度と統制要件で変わります。
今回の更新は「全員が今すぐ既存Secrets Manager参照へ移るべき」という話ではありません。短いPoCならservice-managed secretの方が軽い場合もあります。逆に、監査、KMS、タグ、ローテーションが厳しいチームでは、BYO secretを使わない方が例外運用になりやすいこともあります。
判断の軸は、secretの所有者と運用ルールです。
既存のSecrets Manager運用があるチームは候補になる
評価基準
すでにAWS Secrets Managerを使い、外部API keyやOAuth client secretを一元管理しているチームでは、BYO secretの価値が出やすくなります。理由は単純で、AgentCore Identity向けのsecretも、既存の命名、タグ、KMS、rotation、監査、削除手順に乗せられるからです。
とくに、アプリケーションチームとセキュリティチームが分かれている組織では、secretをどのアカウントで作るか、誰が値を更新できるか、どのKMS keyを使うかが先に決まっていることがあります。その場合、AgentCore Identityが新しく作るservice-managed secretより、既存secretを参照させる方がレビューしやすくなります。
小さなPoCではservice-managedのままでもよい
条件
短期PoC、単一アカウント、単一リージョン、厳密なCMK要件なし、手動ローテーションで十分、という段階では、service-managed secretの方が運用は軽いかもしれません。
ただし、PoCのまま本番へ進めるときは注意が必要です。エージェントが使う外部API keyは、ユーザーの代わりに情報を読む、投稿する、チケットを更新する、支払いフローに触れる、といった強い権限を持つことがあります。PoCのsecret管理を本番に持ち込む前に、secretの所有者、環境分離、rotation、監査、失効手順を決め直してください。
規制・監査・FinOpsでは意味が大きい
根拠
AWS What’s Newでは、従来方式では作成時のresource tags、customer managed key、組織固有のgovernance controlsを適用しにくいことが摩擦として説明されています。ここは、統制部門やFinOpsが見るべきポイントです。
たとえば、secretにアプリID、データ分類、コストセンター、所有チーム、環境名を必ず付ける運用をしている場合、タグを自社ルールで作成時から付けられることは大きな差です。customer managed KMS keyを必須にしている環境でも、先に作成したsecretの暗号化設定を維持したままCredential Providerへ渡せます。
実装で最初に見る権限とKMS
token vaultのCMKと、BYO secretを暗号化するSecrets Manager側のCMKは分けて確認します。
BYO secretの実装で最初に詰まりやすいのは、APIの書き方よりも権限です。Credential Providerにsecret ARNを指定しても、AgentCore Identityがsecret valueを読めなければ外部API認証は成立しません。
確認する対象は、Secrets Manager secret、必要に応じたKMS key、クロスアカウントのresource policy、Credential Providerの参照設定です。
secretsmanager:GetSecretValueを許可する
確認項目
AWS Machine Learning Blogの前提条件では、AgentCore Identity service principalにsecretへのsecretsmanager:GetSecretValueアクセスを与える必要があると説明されています。
ここで雑に広い権限を付けると、せっかくBYO secretで統制を強めた意味が薄れます。許可は、対象secret ARN、対象リージョン、対象アカウント、Credential Providerの用途に合わせて絞るべきです。セキュリティ専用アカウントにsecretを置く場合は、resource policyだけでなく、OrganizationsやSCP、VPC endpoint policy、監査ログの所有者も合わせて確認します。
customer managed KMS keyではkms:Decryptも見る
条件
secretをcustomer managed KMS keyで暗号化している場合、AgentCore Identityがsecretを読むためにKMSの復号権限も必要になります。KMS key policy、IAM policy、grantのどこで許可するかは、自社のKMS運用に合わせて決めます。
混同しやすいのは、AgentCore Identityのtoken vault暗号化と、Secrets Manager secretの暗号化です。AgentCore IdentityのData encryptionドキュメントはtoken vaultの暗号化について説明しています。一方、今回のBYO secretでは、Credential Providerが読むSecrets Manager secret側の暗号化と復号権限も確認対象になります。
この2つを同じ「KMS設定」として片付けると、レビューで抜けが出ます。token vaultのCMK、Secrets Manager secretのCMK、KMS key policy、CloudTrailでのDecryptイベントを分けて見てください。
クロスアカウント参照は同一リージョンに閉じる
根拠
AWS Machine Learning Blogは、別AWSアカウントのsecretも同一AWSリージョン内なら選べる一方、cross-Region secret sharingはサポートされないと説明しています。
日本のAWS利用者にとっては、東京リージョンのAgentCore Identityから参照するsecretは、東京リージョンに置く設計を基本にする、という読み方になります。セキュリティアカウントに集約する場合でも、リージョンをまたいで1つのsecretを読ませる設計にしない方が安全です。
認証基盤全体のリージョン設計を見直しているチームは、Amazon Cognitoのmulti-Region replication記事も合わせて読むと、KMS、リージョン、DRの論点を分けやすくなります。
ローテーションと運用で詰まりやすいところ
- secret value更新
Secrets Managerのrotationや手動更新で、新しいAPI keyやOAuth client secretを格納します。
- JSON key維持
clientSecretやapiKeyなど、Credential Providerが読むキー名を変えないようにします。
- 次回読み取り
AgentCore Identityが次回読み取り時に更新値を取得できるかを確認します。
- 外部API認証
旧credentialの有効期限、新credentialの反映、agentの再試行を別々に見ます。
- rollbackと監査
失敗時はsecret version、外部API側の失効、GetSecretValue、KMS Decryptを追って戻し方を確認します。
ローテーションは更新できることだけでなく、失敗したときに原因へ辿れて戻せることまで含めて検証します。
BYO secretの魅力の一つは、既存のローテーション運用をAgentCore Identityにも適用しやすいことです。AWS Machine Learning Blogでは、secret valueをローテーションすると、AgentCore Identityが次回読み取り時に更新値を取得し、Credential Providerを更新または再作成しなくてよい例が説明されています。
ただし、ローテーションがあるから安全、とは言い切れません。外部API側のclient secret更新、旧secretの有効期限、agentの再試行、JSON keyの固定、監査ログの確認までセットで見なければ、ローテーションが障害原因になります。
次回読み取りの挙動を確認する
検証ポイント
ローテーション後にAgentCore Identityが更新値を読む、という説明は重要です。Credential Providerを作り直さずに済むなら、運用負荷は下がります。
それでも、本番前には検証が必要です。旧credentialを外部API側でいつ無効化するか、新credentialが外部IdPやSaaS側でいつ有効になるか、AgentCore Identityが次回読み取りを行うタイミングで認証が切れないかを確認します。ローテーション直後、旧credential失効直前、外部API側の反映遅延、認証失敗時の再試行は、別々のテストケースにした方が見落としにくくなります。
JSON keyの変更は設定に響く
注意点
secret ARNが同じでも、値を格納するJSON keyを変えると、Credential Providerが期待する値を読めない可能性があります。ローテーションLambdaや手動更新でJSON構造を変えてしまうと、secret自体は存在するのに認証だけ失敗する、という厄介な状態になります。
Credential Providerの設定、secret value schema、rotation code、runbook、監査手順に、同じJSON key名が入っているか確認してください。clientSecretで作ったのに、次のローテーションでsecretへ変える、といった小さな差が障害になります。
監査では参照関係を見る
確認項目
監査で見るべきなのは、誰がsecretを読んだかだけではありません。どのCredential Providerが、どのsecret ARNとJSON keyを参照しているかも必要です。
CloudTrailでは、Secrets ManagerのGetSecretValue、KMS Decrypt、Credential Providerの作成・更新、secret rotation、resource policy変更を追います。インシデント時には、外部API credentialの失効、secret versionのrollback、Credential Providerの無効化、resource policyの遮断をどの順で行うかも決めておくべきです。
対象リージョンと東京リージョンの読み方
US East (N. Virginia)、US East (Ohio)、US West (Oregon)、Canada (Central)。
Mumbai、Seoul、Singapore、Sydney、Tokyoが対象に含まれます。東京リージョン利用ではsecretも同じリージョンで確認します。
Frankfurt、Ireland、London、Paris、Stockholm。
cross-Region secret sharingはサポートされないため、AgentCore Identity、Secrets Manager、KMS keyを同じリージョンで整理します。
KMS、Secrets Manager、外部APIエンドポイント、ログ集約先のリージョン差分も見積もりに影響します。
What’s NewのBYO secret対象リージョンと、AgentCore Identity全体のSupported Regions表は分けて確認します。
AWS What’s Newでは、今回のBYO secret対応は14のAWSリージョンで一般提供とされています。対象にはAsia Pacific (Tokyo)が含まれます。
対象リージョンは、US East (N. Virginia)、US East (Ohio)、US West (Oregon)、Canada (Central)、Asia Pacific (Mumbai)、Asia Pacific (Seoul)、Asia Pacific (Singapore)、Asia Pacific (Sydney)、Asia Pacific (Tokyo)、Europe (Frankfurt)、Europe (Ireland)、Europe (London)、Europe (Paris)、Europe (Stockholm)です。
What’s Newの対象とAgentCore全体の表を混ぜない
注意点
Supported AWS RegionsのDeveloper Guideには、AgentCoreの各機能がどのリージョンで使えるかの表があります。ただし、ここで注意したいのは、AgentCore Identity全体の対応リージョンと、今回のBYO secret対応の発表対象を混ぜないことです。
本文作成時点では、What’s NewがBYO secret対応の対象リージョンを示し、Supported RegionsページがAgentCore Identityの対応状況を示しています。導入判断では、両方を見て、自社が使うリージョンが対象か確認してください。
東京リージョンで使うならsecretも同じリージョンで見る
条件
cross-Region secret sharingがサポートされないという制約は、東京リージョン利用者にとって重要です。東京リージョンでAgentCore Identityを使うなら、参照するSecrets Manager secret、必要なKMS key、CloudTrail/CloudWatchの集約先、外部APIへの通信経路も、東京リージョンを起点に整理します。
Secrets Managerには別途、レプリカやマルチリージョン運用の設計論点があります。しかし、AgentCore IdentityのCredential Providerが参照できる条件は、今回の公式資料で確認できる範囲に限定して読むべきです。推測でDR構成を組むより、まず同一リージョンでの参照を確実に通す方が安全です。
リージョン差分は料金と遅延にも波及する
評価基準
リージョンは、可用性だけの問題ではありません。KMS keyはリージョンに紐づきます。Secrets Manager secretもリージョンごとに管理されます。外部APIがグローバルSaaSなら、東京リージョンからの呼び出し遅延や失敗時の再試行も見ます。
AgentCore Identityのリージョン、Secrets Managerのリージョン、KMS keyのリージョン、外部APIのエンドポイント、監査ログの集約先を1枚に並べると、どこに責任境界があるかが見えやすくなります。
料金はAgentCore Identityだけで見ない
RuntimeまたはGateway経由で追加料金がない条件と、OAuth token/API key requestの課金条件を分けて読みます。
保存するsecret数とAPI call数を、BYO secretの利用頻度に合わせて見積もります。
customer managed KMS keyのストレージ、Decryptなどのrequest、ローテーションを別項目にします。
secret更新、外部API更新、失敗時の再試行で増える処理を見ます。
監査ログ、エラー検知、アラート、調査に必要なログ保管も費用に含めます。
AgentCore Identityだけを見て無料と判断せず、secret管理全体でどこに費用が出るかを確認します。
料金の確認では、AgentCore Identityの価格表だけを見ると抜けが出ます。BYO secretは、AgentCore Identityの機能であると同時に、Secrets Manager、KMS、rotation、CloudTrail、CloudWatchを巻き込む運用です。
Runtime/Gateway経由ではIdentity追加料金がない条件を確認する
根拠
Amazon Bedrock AgentCore Pricingでは、AgentCore RuntimeまたはAgentCore Gateway経由でAgentCore Identityを使う場合、AgentCore Identityの使用に追加料金は発生しないと説明されています。その他のシナリオでは、AWS以外のリソース向けにエージェントからリクエストされたOAuth tokenまたはAPI keyについて、1,000 requestあたり0.010 USDと示されています。
ここで短絡して「無料」と読まないでください。無料または追加料金なしとされる条件がどの利用経路に限られるのか、OAuth token/API key requestの数がどう増えるのか、agentの再試行や複数ツール呼び出しで上振れしないかを確認します。
Secrets ManagerとKMSは別サービスとして見る
確認項目
AWS Secrets Managerの料金ページでは、保存するsecretの数とAPI call数に基づいて料金が発生すると説明されています。料金例では、secret 1件あたり月額0.40 USD、API call 10,000回あたり0.05 USDの例が示されています。
AWS KMSの料金ページでは、customer managed KMS keyのストレージ、キー使用量、ローテーション、無料利用枠などが説明されています。BYO secretでcustomer managed KMS keyを使うなら、KMS keyそのものとDecryptなどのAPI requestも見積もり対象です。
ローテーションとログも見積もりに入れる
上振れ要因
Secrets Managerのローテーションは、外部APIの安全性を高める一方で、rotation Lambda、API call、KMS request、失敗時の再試行、監査ログを増やします。agentが短いtoken lifetimeで何度もcredentialを取得する設計なら、AgentCore Identity側のrequest数も増えます。
費用比較は、AgentCore Identityだけでなく、secret管理全体で行ってください。service-managed secretとBYO secretのどちらが安いかではなく、自社の統制要件を満たした状態で、どのコストがどこに出るかを見るのが現実的です。
導入前に試す検証シナリオ
成功する検証だけでなく、失敗が静かに見落とされないかを先に確認します。
公式発表を読んだだけで本番へ入れるより、最初に失敗条件を作った方が安全です。とくにsecretやKMSの権限は、成功するケースだけ見ても本番障害への備えになりません。
API key credential providerで既存secretを読む
成功条件
まず、Secrets Manager secretにAPI keyをJSONで格納し、Credential Providerでsecret ARNとJSON keyを指定する検証をします。成功条件は、agentが外部APIを呼べること、secret値がプロンプトやログに露出しないこと、CloudTrailでSecrets ManagerとKMSのアクセスを追えることです。
ここでは、外部APIの認証成功だけでなく、Credential Providerの作成結果、GetSecretValue、KMS Decrypt、外部API側の認証ログを並べて確認します。
OAuth client secretをローテーションする
失敗時に疑う箇所
次に、OAuth client secretをSecrets Managerで更新し、Credential Providerを再作成せずに次回読み取りで更新値を使えるかを試します。外部IdP側の旧secret有効期間、新secretの反映、agentの再試行、認証失敗時のアラートをセットで見ます。
失敗時に疑う箇所は、JSON key名のずれ、secret versionのstage、KMS decrypt権限、resource policy、外部IdP側の反映遅延、agent側のretry/backoffです。ローテーションは「更新できる」だけでは足りず、「失敗したときに戻せる」まで確認してください。
権限を意図的に外して失敗ログを見る
評価基準
本番前には、secretsmanager:GetSecretValueなし、kms:Decryptなし、cross-account resource policy不足、別リージョンsecret指定のケースも用意します。これらは成功しないためのテストです。
目的は、権限不足が静かに失敗しないか、運用者がどのログから原因へ辿れるかを確認することです。障害時runbookには、エラー別に見るログ、担当チーム、戻し方を入れておくと実運用で助かります。
AIモデルや開発者向け導入判断の文脈では、公開済みのOpenAI GPT-5.5/5.4とCodex on Amazon Bedrockの記事も関連します。AgentCore Identityは、こうしたAI基盤を本番のツール連携へ広げるときに効いてくる領域です。
まとめ
既存Secrets Manager運用、CMK、タグ、rotation、resource policy、監査をAgentCore Identityにもそろえたい場合の選択肢です。
GetSecretValue、kms:Decrypt、同一リージョン、ログ、失敗時runbookが曖昧なら先に棚卸しします。
短期PoCや単純な検証では、service-managed secretの方が運用負荷を抑えられる場合があります。
今回の更新は必ずBYO secretへ移る合図ではなく、自社のsecret管理成熟度に合わせて選ぶための選択肢です。
Amazon Bedrock AgentCore Identityの既存Secrets Manager参照対応は、AIエージェントに外部APIを触らせるチームにとって、secret管理の例外を減らす更新です。既存のSecrets Manager運用、CMK、タグ、rotation、resource policy、監査をAgentCore Identityにもそろえられるなら、BYO secretは検証する価値があります。
一方で、短期PoCや単純な検証ではservice-managed secretの方が軽い場合もあります。今回の更新は、必ずBYO secretへ移るべきという合図ではありません。自社のsecret管理がどこまで成熟しているか、AgentCore Identityにどの外部権限を渡すのか、失敗時に誰が止めるのかを見て判断する更新です。
2026年6月のAWS/Bedrock関連更新は、月次まとめページでも追跡しています。AgentCore Identityのドキュメントや料金が更新された場合は、公式資料の確認を優先してください。
次に読むなら
次に読むなら
参照した主な情報源
- AWS What’s New: Amazon Bedrock AgentCore Identity now allows you to bring your own secrets with AWS Secrets Manager
https://aws.amazon.com/about-aws/whats-new/2026/06/agentcore-identity-secrets-manager/
- AWS Machine Learning Blog: Reference your own AWS Secrets Manager secrets in Amazon Bedrock AgentCore Identity
https://aws.amazon.com/blogs/machine-learning/reference-your-own-aws-secrets-manager-secrets-in-amazon-bedrock-agentcore-identity/
- Amazon Bedrock AgentCore Developer Guide: Configure credential provider
https://docs.aws.amazon.com/ja_jp/bedrock-agentcore/latest/devguide/resource-providers.html
- Amazon Bedrock AgentCore Developer Guide: Data encryption
https://docs.aws.amazon.com/ja_jp/bedrock-agentcore/latest/devguide/identity-data-encryption.html
- Amazon Bedrock AgentCore Developer Guide: Supported AWS Regions
https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agentcore-regions.html
- Amazon Bedrock AgentCore の料金
https://aws.amazon.com/jp/bedrock/agentcore/pricing/
- AWS Secrets Manager の料金
https://aws.amazon.com/jp/secrets-manager/pricing/
- AWS Key Management Service の料金
https://aws.amazon.com/jp/kms/pricing/