AWSはAmazon Bedrock AgentCore Identityで、利用者が事前に用意したAWS Secrets Managerの機密を認証情報プロバイダーに参照させられる機能を発表した。サービスが自動生成していた認証情報を、自社管理の既存機密に差し替えられるようになった。
AWSは2026年6月2日、Amazon Bedrock AgentCore Identityで利用者が事前に用意したAWS Secrets Managerの機密を参照できる機能を発表した。これまでサービスが自動生成・管理していた認証情報を、自社管理の既存機密に差し替えられるようになった。
既存の機密の識別子（ARN）とJSONキーを指定するだけで認証情報プロバイダーに参照させられる。利用者管理の暗号鍵（KMS）・ローテーション・タグ・リソースポリシーを利用者側で完全に制御でき、APIキー方式とOAuthクライアントシークレット方式の両方に対応する。同一リージョン内なら別のAWSアカウントの機密も参照できるが、リージョンをまたぐ共有は非対応だ。外部コネクター経由で取り込んだ第三者の機密管理ツールの機密も利用できる。
規制環境で「すべての認証情報を自社管理の鍵で暗号化する」といった要件を満たしたままAIエージェントを運用できる点が、本番導入の判断に直結する。機密を更新しても認証情報プロバイダーを再作成する必要がなく、エージェントは止まらずに新しい値を読み込む。
この変化で何が要点か。図解と出典つきで一目で。
構造化された事実を最初に。誰が何をいつどこでなぜどのように。
AI エージェントは外部サービス（CRM、Slack、GitHub など）の API を呼び出すため、実行時に認証情報を安全に渡す必要がある。コードへの直書きやプロンプトへの露出を避けることが、本番運用のエージェント構築における主要課題だった。AgentCore Identity は認証情報プロバイダーとトークン保管庫を通じて、外部連携ごとに機密を自動生成・管理してきた。ただし従来は、生成時に独自のタグ・自動更新（ローテーション）ポリシー・利用者管理の暗号鍵（KMS）を設定できなかった。
企業は既存の機密管理ガバナンス（暗号化・ローテーション・アクセス制御・監査タグ）をそのままエージェント基盤に拡張できるようになる。規制環境で「すべての認証情報を自社管理の鍵で暗号化する」といった要件を満たしたまま AI エージェントを運用できる点が、本番導入の判断に直結する。機密を更新しても認証情報プロバイダーを再作成する必要がなく、エージェントは止まらずに新しい値を読み込む。
AWSは2026年6月2日、Amazon Bedrock AgentCore Identityで利用者が事前に用意したAWS Secrets Manager（認証情報の保管庫）の機密を参照できる機能を発表した。これまでAgentCore Identityはサービス側が認証情報を自動生成・管理しており、利用者は生成時に独自タグ・自動更新（ローテーション）ポリシー・利用者管理の暗号鍵（KMS）を設定できなかった。
今回の変更で、既存の機密の識別子（ARN）とJSONキーを指定するだけで、認証情報プロバイダーにその機密を参照させられる。
You retain full control over its encryption configuration, rotation, replication, tags, and resource policies, just as you would manage other secrets in Secrets Manager.
引用は「暗号化設定・ローテーション・レプリケーション・タグ・リソースポリシーを、他のSecrets Manager機密と同じように完全に制御できる」という意味だ。AIエージェントの本番運用で最大の壁だった「認証情報を誰がどう管理するか」が、利用者側に戻る。
得をするのは、まず規制環境でAIエージェントの本番化を止めていた企業だ。「すべての認証情報を自社管理の鍵で暗号化する」「監査タグを付ける」といった要件を、利用者管理の暗号鍵（KMS）とリソースポリシーで満たせるようになる。
次に、既にSecrets Managerでローテーションや暗号化のガバナンスを構築済みの実装チームが得をする。エージェント用に機密を作り直さず、既存機密をARN指定で再利用できる。設定は管理コンソール・コマンドライン（CLI）・AIコーディングエージェントのいずれからも可能だ。
さらに、AWS Secrets Managerの外部コネクター経由で取り込んだ第三者の機密管理ツールの機密も使えるため、既存ベンダーを乗り換えずに接続できる。
一方、機密を複数リージョンに分散させ越境参照する構成は、リージョンをまたぐ機密共有が非対応のため、そのままでは使えない。同一リージョン内なら別のAWSアカウントの機密は参照できる。
今回の機能で実装上重要なのは、機密を更新しても認証情報プロバイダーを再作成する必要がない点だ。サービスが自動生成する従来方式では、機密の差し替えがエージェントの設定変更を伴った。今回は参照先の機密の値を更新すれば、エージェントは止まらずに新しい値を読み込む。
対応する方式は2つある。APIキー方式と、OAuthクライアントシークレット方式（外部サービスへのアクセス許可をやり取りするための認証情報）だ。CRM・Slack・GitHubなど、エージェントが実行時に呼び出す外部APIの認証情報を、コードに直書きせず安全に渡せる。
You can also choose a secret from another AWS account within the same AWS Region, though cross-Region secret sharing isn't supported.
引用のとおり、同一リージョン内なら別アカウントの機密も選べるが、リージョン越境の共有は対象外だ。この境界は構成設計の最初に押さえておきたい。
立場別、明日から動ける一手。
自社の暗号鍵・ローテーション・監査タグ要件が、AgentCore Identityの利用者管理機密でどこまで満たせるかを公式ブログで確認する。
認証情報をサービス自動生成のまま使う場合と、既存Secrets Manager機密を再利用する場合の運用負荷とガバナンス適合度を比較する。
既存の機密のARNとJSONキーを認証情報プロバイダーに指定し、機密更新時にエージェントが止まらず新しい値を読むかを試す。
発表直後のため、本トピックそのものへの反応は限定的で、エンタープライズ向けAI基盤に関する周辺の動きが並行して話題になっている。
公式発表と各所の反応から編集部が要約した主な論点です。個別のX投稿そのものは下部のセクションに表示されます。
「既存のセキュリティ・コンプライアンス・ガバナンスのワークフローでOpenAIを使える」
OpenAIのフロンティアモデルとCodexがAmazon Bedrock上で一般提供となり「既存のセキュリティ・コンプライアンス・ガバナンスのワークフローでOpenAIを使える」という文脈が共有されている。AWS上でのエンタープライズAI構築の選択肢拡大という大きな流れの中で、AgentCore Identityの認証情報管理強化も位置づけられている。
※トレンド検出時刻付近の人気投稿を表示
OpenAI frontier models and Codex are now generally available on AWS, giving enterprises a new way to build on Amazon Bedrock with OpenAI through the security, compliance, and governance workflows they already use. This is also the beginning of a broader expansion of OpenAI…
Get a full technical breakdown of this agent, and see what happened when we rain it ran it against 2025 GDP data for all 27 EU member states.