AgentCore Registry入門 ~マルチアカウントでどう使うの~

2026/05/13(木) JAWS-UG東京支部 春のAgentCoreアップデートまつり での登壇資料です。

Transcript

1. AgentCore Registry入門 ~マルチアカウントでどう使うの~ 2026/05/13 (水) JAWS-UG東京支部 春のAgentCoreアップデート解説まつり 福地開
2. Who am I ? 福地 開 (ふくち はるき) @har1101mony 所属：NECソリューションイノベータ/JAWS-UG東京 業務：Agent Builder 実績：AWS Community Builders (AI Engineering) 2025 Japan AWS Jr.Champions 2025 Japan All AWS Certifications Engineers
3. 今日話すこと 1 AgentCore Registryとは？ 何を管理し、何を実行しないのか 2 複数アカウントでの集約 実体を移動せず、中央カタログに載せる 3 URL同期 AssumeRoleと同期アクセスを分けて考える 4 Manual登録 条件が揃わない場合でもカタログ化する 5 使い分け 運用で迷わない判断軸に落とす この資料のゴール Registryを「発見と統制のカタログ」 として捉え、クロスアカウントで登録 するときの選択肢を整理する。 前提 エージェントやMCPサーバーの実体は 元のアカウントや外部環境に残る。 Registryにはメタデータを載せる。 03
4. AgentCore Registryとは？ Agent / MCP server / Skill / Custom Resource を 検索・レビュー・統制するための中央カタログ Account A MCP server Account B Agent External / SaaS Skill / Custom → AgentCore Registry Record / Revision / Approval → Consumers Search / Review / Governance • 検索対象は承認済みRecord • 説明・所有者・Endpoint・認証方式などを管理 • 実体の配置場所は問わない 04
5. RegistryはGatewayではない AgentCore Registry 役割: 探す / 承認する / 統制する 主な使い方: Record検索、レビュー、メタ データ管理 MCP endpoint: search_registry_records AgentCore Gateway 役割: 呼び出す / まとめる / 実行面を提供 する 主な使い方: 複数MCPやAPI/Lambdaを1つ のMCP interfaceに集約 RegistryにはGateway自体も登録できる 見つける 呼び出す Registryに載せる = 発見可能にする Gatewayにまとめる = 実行面を統合する 05
6. 疑問: 複数アカウントに点在したら？ 基本的に1つのアカウントにMCPサーバーやエージェントが集約されることはありえないはず 複数アカウントに点在するとき、1つのRegistryに集約しないといけないのでは？ WORKLOAD ACCOUNT A MCP server Agent WORKLOAD ACCOUNT B Gateway (MCP server) Runtime (A2A / MCP) CENTRAL ACCOUNT AgentCore Registry 中央カタログ Record Record Record metadata endpoint information 解決の考え方: MCPサーバーやエージェントの実体はそのままに、 メタデータなどの情報だけを1つのRegistryに集約する 06 →
7. 方法1: URL同期 MCPサーバー/エージェントカードからメタデータを取得し、Registryレコードを作成・更新する方式。 クロスアカウントでは、登録者のAssumeRoleと、Registry側の同期アクセスを分けて考える。 08
8. URL同期で必要な権限は2系統 1. Publisher権限 中央RegistryにRecordを作成・更新・承認申請 する権限。 例: ワークロード側のCIや登録者が、中央アカウ ントのPublisher RoleをAssumeRoleする。 2. 同期時のアクセス権限 Registryが同期時に対象endpointを読み取るため の権限。 IAM / OAuth / Publicなど、対象の認証方式に合 わせてRegistry側から到達できる必要がある。 Workload CI sts:AssumeRole → Publisher Role Create / Update → Registry URL synchronization → Endpoint metadata取得 どちらか一方だけでは足りない。申請しても、Registryがendpointを読めなければ URL同期は完了しない。 09
9. JWT認証のMCP/エージェントを登録する場合 前提: 対象endpointがOAuth2.0/OIDC準拠のJWTで保護されていること(CustomJWTAuthorizerConfiguration)。 中央(Registry)アカウントとワークロードアカウントの双方で事前作業が必要。Cognitoが典型的なIdP例。 ワークロード側 (MCP/Agent提供) の作業 ① IdPを整備 (典型例: Amazon Cognito) ・User Pool + App Client を作成し client_credentials grant を有効化 ・Resource Server を定義し scope を発行 (例: agentcore/invoke) ・Hosted UI ドメインを設定し token endpoint を公開 ② Runtime/Gateway 側に inbound JWT authorizer を設定 ・discoveryUrl は .../.well-known/openid-configuration が必須 ・allowedAudience / allowedClients / allowedScopes / customClaims のいずれか1つ以上を必ず指定 ・同期用 App Client の client_id を allowedClients に登録 ③ endpoint を Registry から到達可能に ・Public 公開 or VPC Endpoint/PrivateLink を整備 中央(Registry)アカウント側の作業 ① 同期用Oauthクレデンシャルの保管 ・ワークロードから受領した client_id / client_secret を Secrets Manager に保管 ・同期Jobの実行Roleに secretsmanager:GetSecretValue を付与 ② 同期処理の実装 ・token endpointへ client_credentials grant でアクセスし access_token を取得 ・Authorization: Bearer ヘッダで endpoint を読み取り、 tools/agent metadata を Registry Record に書き戻し ・token のキャッシュと期限切れ時の再取得を実装 上記いずれかが満たせない場合 → Manual 登録 (IdPがclient_credentials非対応/Authorization Codeのみ・中央にクレデンシャルを置けない・ endpointが閉域でRegistryから到達不可・customClaimsが3rdパーティ呼出を想定していない 等)。 また、Manualでも実体の呼び出し権限は別途必要。 10
10. 解決策2: Manual登録 Registryがendpointを読みに行かず、登録者がDescriptor情報を明示的に入力する方式。 クロスアカウントの同期アクセスを作れない場合でも、カタログ掲載から始められる。 Descriptorを作る 名前 / 説明 / endpoint / owner / auth → Draft Record Create / Update → Review Approve / Reject → Approved Catalog Searchable Manual登録の強み ・対象endpointへの同期アクセスを作らなくて よい ・Skill / Custom / 固定メタデータと相性がよい ・まずは中央カタログに載せる、という運用を始 めやすい 注意点 ・ツール定義や説明の更新は手動管理になる ・利用者が実体を呼び出すための認証・ネットワ ーク設計は別途必要 11
11. URL同期とManualの使い分け 観点 URL同期 Manual登録 向いている対象 MCP server / 同期可能なAgent endpoint Skill / Custom / 固定メタデータ / 同期不可の endpoint 必要条件 Registryからendpointへ到達でき、認証情報を提示 できる 登録者がDescriptorを用意できる 運用の特徴 ツール情報やスキーマ変更を追随しやすい 更新は明示的に管理する クロスアカウント 観点 Publisher権限とSyncアクセス権限を設計する 登録時点ではendpoint読取権限を要求しない 結論: 条件が揃えばURL同期。揃わない、またはまず公開したいならManual登録。 どちらも承認後に検索対象になる。 12
12. まとめ 1 Registryは中央カタログ Agent / MCP / Skillを見つけ 、レビューし、統制する場所 。実行面そのものではない。 2 クロスアカウントは 権限を分ける Registryへ書くPublisher権限 と、endpointを読むSyncアク セス権限を別々に設計する。 3 URL同期とManualを使い分け る 条件が揃えばURL同期。揃わ なければManualで中央カタ ログ化から始める。 AgentCore Registryで、Agent・MCP・Skillsを管理しよう まずは「何を見つけたいか」「どこまで自動同期したいか」から設計する。 13