# 包括的なレジストリ移行ガイド
* AWS エージェントレジストリ — パブリックプレビューから一般提供への移行*
## 序章
2026 年 8 月 6 日に一般提供 (GA) としてリリースされるにあたり、 AWS Agent Registry はサービスプリンシパル、データ、API モデルに大きな変更を導入しています。パブリックプレビュー中に AWS エージェントレジストリを使用した場合は、次の 3 つの領域にまたがる移行を完了する必要があります。
1. **名前空間と設定の変更** – AWS エージェントレジストリを AWS Bedrock AgentCore 名前空間から独自の専用名前空間に移動しています。この名前空間の変更は、 AWS エージェントレジストリにのみ適用されます。Identity、Gateway、Runtime、Policy など、他のすべての AgentCore サービスは影響を受けません。 AWS エージェントレジストリの場合、サービス名前空間は から `bedrock-agentcore`に変わります`agent-registry`。これは、エンドポイント、IAM ポリシー、SDK クライアント、CLI コマンド、リソース ARNs、オブザーバビリティ統合など、サービスを参照するすべての表面に影響します。新しい名前空間を使用するには、コードとインフラストラクチャを更新する必要があります。
1. **API スキーマの変更** – レジストリとレジストリレコードのデータモデルは、パブリックプレビュー中のお客様からのフィードバックに基づいて更新されます。これらの変更により、既存の API スキーマとの下位互換性が損なわれます。API リクエストとレスポンスを構築または解析するアプリケーションコードは、新しい名前空間への移行の一環として、新しいスキーマを反映するように更新する必要があります。
1. **データ移行** – 既存のレジストリとレジストリレコードを古い名前空間から新しい名前空間に移行する必要があります。データを抽出し、新しいスキーマに変換して、新しい名前空間にロードするための移行ツールが用意されています。データは同じアカウントとリージョンに移行され、名前空間のみが変更されます。
このガイドでは、移行の計画と実行に役立つbefore-and-afterの例を使用して、各領域について詳しく説明します。
## 移行のタイムラインを教えてください。
この移行では、次の 2 つの重要なマイルストーンを覚えておく必要があります。
+ **2026 年 **8 月 6 日 — AWS エージェントレジストリが一般利用可能になり、新しい`agent-registry`名前空間が正式に起動します。既存のレジストリとレコードがある場合は、 `bedrock-agentcore`および `agent-registry`名前空間に同時にアクセスできます。移行ツールが [agentcore-samples GitHub リポジトリ](https://github.com/awslabs/agentcore-samples)で利用可能になります。移行プロセスを開始できます。
**注記**
2026 年 8 月 6 日の時点で既存のレジストリまたはレコードがない新規のお客様は、 `bedrock-agentcore`名前空間から AWS エージェントレジストリにアクセスすることはできません。`agent-registry` 名前空間から直接 AWS エージェントレジストリの使用を開始します。
+ **2026 年 9 月 17** 日 — 移行ウィンドウは終了します。古い`bedrock-agentcore`名前空間はこの日にシャットダウンします。サービスへの読み取り/書き込みアクセスと、古い名前空間に残っているデータが失われます。この日以降は、 `agent-registry`名前空間を使用する必要があります。
## 名前空間と設定の変更
`agent-registry` 名前空間は次の場所で置き換え`bedrock-agentcore`られます。このセクションでは、変更されるすべての表面を一覧表示し、コードを更新する方法の例を示します。
**重要**
名前空間の変更は、 AWS エージェントレジストリによって提供される APIs にのみ影響しますが、AgentCore Identity などの AWS AWS Bedrock AgentCore の残りの部分には影響しません。 AgentCore したがって、ワークロード ID と OAuth 認証情報プロバイダーリソースは `bedrock-agentcore`名前空間の下に残ります。
### サービスエンドポイント
アプリケーションは、新しいエンドポイントホスト名を指す必要があります。新しいエンドポイントは `.api.aws`ドメインを使用します。
| Surface | 古い値 | [新しい値] |
| --- | --- | --- |
| データプレーンエンドポイント | `bedrock-agentcore.{region}.amazonaws.com` | `agent-registry.{region}.api.aws` |
| コントロールプレーンエンドポイント | `bedrock-agentcore-control.{region}.amazonaws.com` | `agent-registry-control.{region}.api.aws` |
### IAM とセキュリティ
参照するすべての IAM ポリシー、サービスコントロールポリシー (SCPsおよびアクセス許可の境界を更新`bedrock-agentcore`する必要があります。リソース ARNs新しい名前空間を反映するように変更されます。
| Surface | 古い値 | [新しい値] |
| --- | --- | --- |
| IAM アクションプレフィックス | `bedrock-agentcore:*` | `agent-registry:*` |
| サービスプリンシパル | `bedrock-agentcore.amazonaws.com` | `agent-registry.amazonaws.com` |
| レジストリ ARN | `arn:aws:bedrock-agentcore:{region}:{account}:registry/{id}` | `arn:aws:agent-registry:{region}:{account}:registry/{id}` |
| ARN を記録する | `arn:aws:bedrock-agentcore:{region}:{account}:registry/{id}/record/{rid}` | `arn:aws:agent-registry:{region}:{account}:registry/{id}/record/{rid}` |
ARNs を解析または保存するオートメーションがある場合は、それらのリファレンスも更新します。IAM アクションプレフィックスまたはサービスプリンシパルの条件を持つカスタムポリシーは、新しい値と一致するように更新する必要があります。 AWS エージェントレジストリに関連付けられた IAM アクセス許可の完全なリストを確認するには、[AWS 「 エージェントレジストリ IAM アクセス許可リファレンス](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/registry-iam-permissions.html)」を参照してください。
**注記**
現在 AWS 、エージェントレジストリアクセスに [BedrockAgentCoreFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/BedrockAgentCoreFullAccess.html) AWS 管理ポリシーを使用している場合 ([BedrockAgentCoreFullAccess ポリシーの詳細](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/security-iam-awsmanpol.html#security-iam-awsmanpol-BedrockAgentCoreFullAccess)を参照）、新しい **AgentRegistryFullAccess** 管理ポリシー (GA で利用可能) に置き換える必要があります。古い BedrockAgentCoreFullAccess 管理ポリシーは、`agent-registry:*`アクセス許可を含めるように更新**されません**。
### SDK、CLI、インフラストラクチャ
アプリケーションコード、デプロイスクリプト、infrastructure-as-code テンプレートを更新して、新しいクライアントクラスと CLI 名前空間を参照します。
| Surface | 古い値 | [新しい値] |
| --- | --- | --- |
| Dataplane SDK クライアントクラス | `BedrockAgentCoreClient` | `AgentRegistryClient` |
| Controlplane SDK クライアントクラス | `BedrockAgentCoreControlClient` | `AgentRegistryControlClient` |
| CLI 名前空間 | `aws bedrock-agentcore` | `aws agent-registry` |
| Service Quotas コード | `bedrock-agentcore` | `agent-registry` |
以前に`bedrock-agentcore`サービスコードでカスタムクォータの引き上げをリクエストした場合は、 でそれらを再リクエストする必要があります`agent-registry`。
### オブザーバビリティとイベント
CloudTrail Lake クエリ、Athena クエリ、SIEM 統合、EventBridge ルール、CloudWatch ダッシュボード、および古い名前空間を参照するアラームを更新します。
| Surface | 古い値 | [新しい値] |
| --- | --- | --- |
| CloudTrail イベントソース | `bedrock-agentcore.amazonaws.com` | `agent-registry.amazonaws.com` |
| EventBridge ソース | `aws.bedrock-agentcore` | `aws.agent-registry` |
| CloudWatch 名前空間 | `AWS/BedrockAgentCore` | `AWS/AgentRegistry` |
### 例: IAM ポリシーの更新
すべての IAM ポリシーでアクションプレフィックスとリソース ARN 名前空間を置き換えます。
**前 (パブリックプレビュー):**
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"bedrock-agentcore:CreateRegistry",
"bedrock-agentcore:GetRegistry",
"bedrock-agentcore:UpdateRegistry",
"bedrock-agentcore:ListRegistries",
"bedrock-agentcore:DeleteRegistry",
"bedrock-agentcore:CreateRegistryRecord",
"bedrock-agentcore:GetRegistryRecord",
"bedrock-agentcore:UpdateRegistryRecord",
"bedrock-agentcore:ListRegistryRecords",
"bedrock-agentcore:DeleteRegistryRecord",
"bedrock-agentcore:SubmitRegistryRecordForApproval",
"bedrock-agentcore:UpdateRegistryRecordStatus",
"bedrock-agentcore:SearchRegistryRecords"
],
"Resource": ["arn:aws:bedrock-agentcore:us-west-2:123456789012:*"]
}]
}
```
**後 (一般提供):**
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"agent-registry:CreateRegistry",
"agent-registry:GetRegistry",
"agent-registry:UpdateRegistry",
"agent-registry:ListRegistries",
"agent-registry:DeleteRegistry",
"agent-registry:CreateRegistryRecord",
"agent-registry:GetRegistryRecord",
"agent-registry:UpdateRegistryRecord",
"agent-registry:ListRegistryRecords",
"agent-registry:DeleteRegistryRecord",
"agent-registry:SubmitRegistryRecordForApproval",
"agent-registry:UpdateRegistryRecordStatus",
"agent-registry:SearchDiscoverableRegistryRecords",
"agent-registry:ListDiscoverableRegistryRecords",
"agent-registry:GetDiscoverableRegistryRecord"
],
"Resource": ["arn:aws:agent-registry:us-west-2:123456789012:*"]
}]
}
```
**注記**
`BatchGetDiscoverableRegistryRecord` API には独自の IAM アクションはありません。リクエストされた各レコードを `agent-registry:GetDiscoverableRegistryRecord`アクションに対して承認します。ポリシーに を使用する`GetDiscoverableRegistryRecord`ための が含まれていることを確認します`BatchGet`。
**重要**
ワークロード ID と OAuth 認証情報プロバイダーリソースは、 `bedrock-agentcore`名前空間の下に残ります。レジストリが OAuth または IAM 認証情報との URL 同期 (`source.fromUrl`) を使用する場合は、新しいアクセス許可とともに次の`agent-registry:*`アクセス許可を保持する必要があります。
```
"bedrock-agentcore:CreateWorkloadIdentity",
"bedrock-agentcore:GetWorkloadIdentity",
"bedrock-agentcore:DeleteWorkloadIdentity"
```
すべての`bedrock-agentcore`アクションを置き換えないでください。これらの ID リソースは、古い名前空間を意図的に保持します。
### 例: SDK クライアント設定の更新
SDK 呼び出しのサービス名、クライアントクラス、エンドポイント URL を更新します。
**前 (パブリックプレビュー):**
```
import boto3
session = boto3.Session(region_name="us-west-2")
cp_client = session.client(
"bedrock-agentcore-control",
endpoint_url="https://bedrock-agentcore-control.us-west-2.amazonaws.com"
)
dp_client = session.client(
"bedrock-agentcore",
endpoint_url="https://bedrock-agentcore.us-west-2.amazonaws.com"
)
```
**後 (一般提供):**
```
import boto3
session = boto3.Session(region_name="us-west-2")
cp_client = session.client(
"agent-registry-control",
endpoint_url="https://agent-registry-control.us-west-2.api.aws"
)
dp_client = session.client(
"agent-registry",
endpoint_url="https://agent-registry.us-west-2.api.aws"
)
```
### 例: CLI コマンドの更新
すべてのスクリプトとオートメーションで CLI 名前空間を置き換えます。
**前 (パブリックプレビュー):**
```
aws bedrock-agentcore-control create-registry \
--name "MyRegistry" \
--description "Production registry" \
--region us-west-2 \
--endpoint-url https://bedrock-agentcore-control.us-west-2.amazonaws.com
```
**後 (一般提供):**
```
aws agent-registry-control create-registry \
--name "MyRegistry" \
--description "Production registry" \
--region us-west-2 \
--endpoint-url https://agent-registry-control.us-west-2.api.aws
```
## API スキーマの変更
名前空間の移行に加えて、一般提供用にレジストリとレジストリレコードのデータモデルを更新しました。これらの変更により、パブリックプレビューからのフィードバックに基づいて API の一貫性と拡張性が向上します。このセクションでは、アプリケーションコードを更新できるように、各変更カテゴリを前後の例で説明します。
### 変更 1: レジストリエンティティの更新
レジストリのデータプレーンへのアクセス方法を制御するレジストリリソースの認可設定が、目的を明示する専用`discoveryConfiguration`ラッパーの下に置かれるようになりました。承認設定 (`PENDING_APPROVAL`ステータスに送信されたレコードが`APPROVED`ステータスに自動的に移行するかどうかを制御する) は、ブール型から拡張可能な列挙型配列に移行します。
特定のフィールドの変更は次のとおりです。
+ `authorizerType` と `authorizerConfiguration`は新しい`discoveryConfiguration`オブジェクト内で移動されます。
+ `approvalConfiguration.autoApproval` (ブール値) は `approvalConfiguration.autoApprovalRules` (列挙文字列の配列) に置き換えられます。値は、 と同じ意味`"APPROVE_ALL"`を持ちます`autoApproval: true`。列挙型リストで指定されたルールが適用されます。(null) を指定しない場合、承認が必要です。
**前 (パブリックプレビュー):**
```
{
"name": "string",
"description": "string",
"authorizerConfiguration": { ... },
"authorizerType": "string",
"approvalConfiguration": {
"autoApproval": true
}
}
```
**後 (一般提供): 承認あり ALL**
```
{
"name": "string",
"description": "string",
"discoveryConfiguration": {
"authorizerConfiguration": { ... },
"authorizerType": "string"
},
"approvalConfiguration": {
"autoApprovalRules": ["APPROVE_ALL"]
}
}
```
**After (一般提供): 列挙型リストに NULL を含む**
```
{
"name": "string",
"description": "Registry with manual approval only",
"approvalConfiguration": {
"autoApprovalRules": []
}
}
```
### 変更 2: レジストリレコードの新しい必須フィールド
レジストリレコードは、より良い分類と重複排除をサポートするために、2 つの新しい必須の最上位フィールドを取得します。`CreateRegistryRecord` API を使用してレジストリレコードを作成するときは両方のフィールドを指定する必要があり、後で `UpdateRegistryRecord` API を使用して変更できます。
| フィールド | タイプ | 説明 |
| --- | --- | --- |
| `name` | 文字列 (必須) | お客様が指定できるレジストリ内の一意の識別子。レジストリでは、すべてのレコードに一意の名前が必要です。`recordVersion` も存在する場合、 `name`と の組み合わせは一意`recordVersion`である必要があります。 |
| `recordType` | 列挙型 (必須) | レコードのセマンティックタイプ。有効な値は、`AGENT`、`MCP`、`SKILL`、`CUSTOM` です。で有効なプライマリ記述子キーを決定します`descriptors`。`ListRegistryRecords` や などの APIs を使用して`SearchDiscoverableRegistryRecords`、このセマンティックタイプで結果をフィルタリングできます。 |
### 変更 3: レジストリレコードの再構築
`descriptors` フィールドは、識別されたユニオンからフラットキー構造に変わります。
前のモデルでは、 `descriptorType`フィールド (`MCP`、`A2A`、`AGENT_SKILLS`、`CUSTOM`) が内部シェイプを決定しました。この結合された記述子コンテンツは、粗いプロトコルまたは形式分類になります。そのフィールドは存在しません。別の最上位属性`recordType`である は、セマンティック分類に置き換えます。API は、構造的にシェイプするのではなく、実行`recordType`時に各 に有効な記述子キーを適用します。の各最上位キーは、詳細なプライマリ記述子タイプ (、、`a2aAgentCard``mcpServer``agentSkillsDefinition`、 など) を表す`descriptors`ようになりました`custom`。補足記述子 (、 など`tools``skillMd`) は、プライマリ記述子の の下にネストされます`additionalData`。`inlineContent` フィールドは になります`data`。フィールド`schemaVersion`と `protocolVersion`フィールドは に統合されます`dataSchemaVersion`。
最上位`synchronizationConfiguration`属性は になり`source`、各記述子 (`additionalData`子を含む) 内を移動します。
既存の`name`フィールドは になり`displayName`、意味がより明確になります。net-new `name`フィールドは重複排除キーとして機能し、レジストリ内のすべてのレコードで一意である必要があります。同じレコード`recordVersion`に対して `name`と の両方を指定する場合、それらの組み合わせは一意である必要があります。
次のフィールドの名前が変更されました。
| Before | After | 注意事項 |
| --- | --- | --- |
| `name` | `displayName` | レコードの名前を表示します。また、重複排除キーである新しい`name`フィールドもあります。 |
| `descriptorType` | 削除済み | 最上位`recordType`フィールドに置き換えられます。 |
| `inlineContent` | `data` | 各記述子内のコンテンツペイロード。 |
| `schemaVersion` / `protocolVersion` | `dataSchemaVersion` | すべての記述子タイプの統合バージョンフィールド。 |
| `synchronizationConfiguration` | `source` | 各記述子内を移動しました (`additionalData`子を含む）。 |
**前 (パブリックプレビュー):**
```
{
"recordId": "string",
"name": "string",
"descriptorType": "string", // A2A, MCP, AGENT_SKILL, CUSTOM
"descriptors": {
"agent": {
"a2aAgentCard": {
"inlineContent": "string",
"schemaVersion": "string"
}
},
"agentSkills": {
"skillDefinition": {
"inlineContent": "string",
"schemaVersion": "string"
},
"skillMd": {
"inlineContent": "string"
}
},
"mcp": {
"server": {
"inlineContent": "string",
"schemaVersion": "string"
},
"tools": {
"inlineContent": "string",
"protocolVersion": "string"
}
},
"custom": {
"inlineContent": "string"
}
},
"synchronizationType": "URL",
"synchronizationConfiguration": {
"fromUrl": {
"url": "string",
"credentialProviderConfigurations": [
{
"credentialProvider": { ... },
"credentialProviderType": "string"
}
]
}
},
...
}
```
**後 (一般提供):**
```
{
"recordId": "string",
"displayName": "string",
"name": "string",
"recordVersion": "string",
"recordType": "AGENT" | "MCP" | "SKILL" | "CUSTOM",
"descriptors": {
"a2aAgentCard": {
"data": "string",
"dataSchemaVersion": "string",
"source": { "fromUrl": { "url": "string", "credentialProviderConfigurations": [...] } }
},
"mcpServer": {
"data": "string",
"dataSchemaVersion": "string",
"source": { "fromUrl": { ... } },
"additionalData": {
"tools": { "data": "string", "dataSchemaVersion": "string" }
}
},
"agentSkillsDefinition": {
"data": "string",
"dataSchemaVersion": "string",
"additionalData": {
"skillMd": { "data": "string", "dataSchemaVersion": "string", "source": { "fromUrl": { ... } } }
}
},
"custom"?: {
"data": "string"
}
},
"metadata": Document
...
}
```
以下の制約が適用されます。
レコードごとに 1 つのプライマリ記述子キーを正確に入力できます。あたりの有効なプライマリ記述子`recordType`は次のとおりです。
+ **エージェント:** `a2aAgentCard`、`mcpServer`、 `custom`
+ **MCP:** `mcpServer`、 `custom`
+ **スキル:** `agentSkillsDefinition`、 `custom`
+ **カスタム:** `custom`
`source` は、単一の最上位ブロックではなく、記述子ごとです。スキーマ内の`source`フィールドを持つ記述子 - `mcpServer`および にアタッチします`a2aAgentCard`。`tools` 子 ( の下`mcpServer.additionalData`)、`agentSkillsDefinition`親、`custom`および記述子には がありません`source`。
GA `source.fromUrl`では、 のみがサポートされています。
自動同期は、 `mcpServer`および`a2aAgentCard`プライマリ記述子、つまり MCP および AGENT レコードタイプに対してのみトリガーされます。`skillMd` 子`source`の は保持されますが、同期の実行には使用されず、SKILL レコードは自動同期できません。CUSTOM レコードは、 `data`を直接指定して手動で作成する必要があります。
### 変更 4: データプレーンフィルターの更新
`SearchRegistryRecords` は `SearchDiscoverableRegistryRecords` () になります`POST /discoverable-records-search`。そのリクエストとレスポンスは、新しいフィールド名とデータモデルを取得します。
+ でフィルタリングします `recordType` ( を置き換えます`descriptorType`)。
+ でフィルタリングします `recordVersion` ( を置き換えます`version`)。
+ レスポンスは、 なしで、新しい形式の記述子を返します`credentialProviderConfigurations`。
MCP 検索ツールは `search_registry_records`になり`search_discoverable_registry_records`、新しい記述子形式を返し、新しいフィルター名を使用します。
### 変更 5: 新しいブラウジング APIs
2 つの新しいデータプレーン APIs承認されたレコードでのブラウジングとカタログエクスペリエンスの構築をサポートします。これらの APIs明示的な移行は必要ありません。ここでは、GA の AWS エージェントレジストリ API モデルへの追加として言及します。
**ListDiscoverableRegistryRecords** — 承認されたレジストリレコードのページ分割されたリストを返します。これを使用して、公開されたコンテンツにブラウジングインターフェイスを構築します。
```
// HTTP: POST /registries/{registryId}/discoverable-records-list
{
"registryId": "string", // path param, required (ARN or ID)
"maxResults": 1-100, // query param, optional
"nextToken": "string", // query param, optional
"filters": [ { "name": "recordType", "values": ["MCP"] } ]
}
{
"registryRecords": [
{
"registryArn": "string",
"recordArn": "string",
"recordId": "string",
"name": "string",
"displayName": "string",
"description": "string",
"recordType": "string",
"recordVersion": "string",
"status": "string",
"createdAt": "string",
"updatedAt": "string"
}
],
"nextToken": "string"
}
```
**BatchGetDiscoverableRegistryRecord** — 1 回の呼び出しで 1 つ以上のレジストリにまたがるレコードのバッチの完全な詳細を取得します。
```
// HTTP: POST /discoverable-records-batch
{
"entries": [
{ "registryId": "reg-AAA", "recordIds": ["rec-111", "rec-222"] }
]
}
{
"registryRecords": [
{
"registryArn": "string",
"recordArn": "string",
"recordId": "string",
"name": "string",
"displayName": "string",
"description": "string",
"recordType": "string",
"descriptors": { ... },
"recordVersion": "string",
"status": "string",
"createdAt": "string",
"updatedAt": "string"
}
],
"errors": [
{
"registryId": "string",
"recordId": "string",
"errorCode": "RESOURCE_NOT_FOUND" | "ACCESS_DENIED" | "INTERNAL_ERROR",
"message": "string"
}
]
}
```
レスポンスには、完全なレコードの詳細を含む`registryRecords`配列と、取得できなかったレコードの`errors`配列が含まれます。
起動時に、1 つのエントリ (1 つのレジストリ、1～100 個のレコード IDs。グループ化されたシェイプは、将来のリリースでクロスレジストリバッチ処理と前方互換性があります。
### 変更 6: APIs構造化フィルターパラメータを採用する一覧表示
パブリックプレビューでは、List APIs各フィルタリング可能なフィールドを独自のクエリパラメータ (、 など) として公開`--status READY`します`--recordType MCP`。GA では、単一の構造化`filters`パラメータがこれらの個別のパラメータを置き換えます。`filters` 値は`{ "name": "", "values": [""] }`エントリのリストで、 `name`はドット区切りの属性パスです。ネストされたフィールドを含む新しいフィルタリング可能なフィールドは、新しい API パラメータではなく新しい`name`パスになります。リストオペレーションも から `GET`に変更されます`POST`。ページ分割パラメータ (`maxResults`、`nextToken`) は変更されません。
**前 (パブリックプレビュー):**
```
GET /registries?status=READY&authorizerType=AWS_IAM
GET /registries/{registryId}/records?name=my-agent&status=APPROVED&recordType=MCP
```
**後 (一般提供):**
```
// ListRegistries
// POST /registries-list
{
"filters": [
{ "name": "status", "values": ["READY"] },
{ "name": "discoveryConfiguration.authorizerType", "values": ["AWS_IAM"] }
],
"maxResults": 100,
"nextToken": "string"
}
// ListRegistryRecords
// POST /registries/{registryId}/records-list
{
"filters": [
{ "name": "name", "values": ["my-agent"] },
{ "name": "status", "values": ["APPROVED"] },
{ "name": "recordType", "values": ["MCP"] }
],
"maxResults": 100,
"nextToken": "string"
}
```
## データ移行
既存のレジストリとレジストリレコードを `bedrock-agentcore`名前空間から `agent-registry`名前空間に移行する必要があります。移行を支援するスクリプトを提供しています。このスクリプトは、既存のデータの抽出、古いスキーマから新しいスキーマへの変換、新しい名前空間のレジストリへのロードを処理します。スクリプトは、同じアカウントとリージョン内の`agent-registry`名前空間に新しいレジストリを作成します。既存のすべてのレコードを古いレジストリから新しいレコードに移行し、名前空間と API スキーマの変更を考慮します。
### 移行アプローチの選択
適切なアプローチは、レジストリの使用状況と運用環境の規模によって異なります。
#### ケース 1: 直接スクリプト実行による小規模な移行
+ **プロファイル:** 5 レジストリ未満、100 レコード未満。ターゲットアカウントのターミナルまたは CloudShell に直接アクセスできます。
+ **アプローチ:** 移行 Python スクリプトを直接実行します。スクリプトはプレビュー名前空間に接続し、レジストリとレコードを一覧表示し、データを GA スキーマに変換して、新しい名前空間に作成します。これは最も簡単なパスであり、インフラストラクチャのデプロイは必要ありません。
#### ケース 2: Lambda または Glue によるマネージド移行
+ **プロファイル:** ターゲット環境に直接ターミナルアクセスできないか、マネージド実行モデルを優先します。
+ **アプローチ:** 移行を AWS Lambda 関数または Glue AWS ジョブとしてデプロイします。移行エンジンは同じ extract-transform-load ワークフローを実行しますが、アカウント内のマネージドジョブとして実行されます。ほとんどのアカウントでは、完全な移行は 15 分以内に完了します。
移行エンジン:
+ プレビュー名前空間からレジストリとレコードを**抽出**し、全ロードと増分ロードの両方をサポートします。すべての API レスポンスをページ分割し、データをステージング場所にシリアル化します。
+ API スキーマの変更 (フィールド名の変更、記述子の再編成、新しい必須フィールド) を適用して各レコードを**変換**します。
+ 変換されたデータを新しい`agent-registry`名前空間に**ロード**し、GA API を使用してレジストリとレコードを作成します。
+ 移行された内容、発生したエラー、検証のためのレコード数をまとめた**レポートを生成します**。
#### ケース 3: アクティブな本番ワークロードのデュアル書き込み移行
+ **プロファイル:** パブリックプレビュー APIs、本番環境で新しいデータをアクティブに書き込みます。
+ **アプローチ:** デュアル書き込み移行戦略を使用して、移行中のデータ損失を回避します。
+ **ライターの更新** – プレビュー名前空間と新しい`agent-registry`名前空間の両方に同時に書き込むようにアプリケーションを変更します。
+ **重複排除を使用して移行スクリプトを実行する** – 移行ツールを実行して履歴データを移行します。スクリプトは `name`フィールドに基づいて重複排除されるため、新しい名前空間に (デュアル書き込みから) 既に存在するレコードは重複しません。
+ **リーダーを切り替える** – すべてのデータが新しい名前空間に存在することを確認したら、 からのみ読み取るようにアプリケーションを更新します`agent-registry`。
+ **デュアル書き込みの削除** – 新しい名前空間ですべての読み取りと書き込みが成功したことを確認したら、プレビュー名前空間ライターをアプリケーションから削除します。
### 移行の検証
移行を実行したら、データが正しく移行されたことを確認します。
+ `list-registries` CLI コマンドを使用して新しい名前空間内のすべてのレジストリを一覧表示し、カウントがソースと一致することを確認します。
+ レジストリごとに、 を使用してレコード数を比較します`list-registry-records`。
+ 個々のレコードをスポットチェックして、記述子が正しく変換されたことを確認します (フィールドの名前変更、記述子の再編成）。
+ 「名前空間と設定の変更」セクションの説明に従って、IAM ポリシー、エンドポイント、SDK クライアントを更新します。
+ 新しい名前空間を使用して、アプリケーションが正常に読み書きできることを確認します。
## よくある質問
### AWS エージェントレジストリの変更点
AWS エージェントレジストリは、パブリックプレビュー`bedrock-agentcore`名前空間から一般公開されている`agent-registry`名前空間に移行しています。移行には、名前空間と設定の変更 (エンドポイント、IAM、SDK、CLI、ARNs、オブザーバビリティ）、API スキーマの変更 (レジストリとレコードの再構築されたデータモデル）、データ移行 (既存のレジストリとレコードを新しい名前空間に移動する) の 3 つの領域があります。
### `bedrock-agentcore` 名前空間で Registry を引き続き使用できますか?
`bedrock-agentcore` 名前空間での既存のレジストリの使用状況は、移行期間中も中断することなく動作し続けます。ただし、データ移行とコード更新の両方を完了するのに十分な時間を確保するために、ツールが利用可能になったらすぐに移行を開始することをお勧めします。
ただし、2026 年 8 月 6 日の時点で既存のレジストリまたはレコードがない場合は、2026 年 8 月 6 日以降は AWS エージェントレジストリ`bedrock-agentcore`の名前空間にアクセスできません。2026 年 8 月 6 日現在の既存のレジストリまたはレコードがある場合は、移行期間中 (2026 年 8 月 6 日～2026 年 9 月 17 日) エージェント AWS レジストリ`bedrock-agentcore`の名前空間にアクセスできます。
### データは自動的に移行されますか?
いいえ。提供されている移行ツールを使用して、移行を自分で開始する必要があります。スケールに基づく利用可能なアプローチの詳細については、「データ移行」セクションを参照してください。
### どのような API スキーマの変更が含まれていますか?
名前空間の変更に加えて、レジストリエンティティ ( でグループ化された認可設定`discoveryConfiguration`)、レジストリレコードの新しいフィールド (`name` および )、レジストリレコードの再編成 (記述子のフラット化、フィールドの名前変更`recordType`)、検索 API フィルターの更新 (`recordType`、`recordVersion`)、新しいブラウジング API (`ListDiscoverableRegistryRecords`、`BatchGetDiscoverableRegistryRecord`)、リストオペレーションの構造化フィルターの 6 つの領域で APIs データモデルを更新しました。
### データ移行にはどのくらいの時間がかかりますか?
移行時間は、アカウントのレジストリとレコードの数によって異なります。レコード数が 100 未満のアカウントの場合、ローカルで を実行すると移行が数分で完了します。数千のレコードを持つアカウントの場合、マネージドジョブとして を実行すると、移行が 15 分以内に完了するはずです。
### アクティブな書き込みを含む大規模なデプロイがある場合はどうなりますか?
本番環境のプレビュー名前空間にデータをアクティブに書き込む場合は、「ケース 3」で説明されているデュアル書き込み移行戦略を使用します。このアプローチにより、両方の名前空間に同時に書き込み、重複排除を使用して履歴データを移行し、読み取りをカットオーバーすることで、移行中にデータが失われることがなくなります。
### ヘルプはどこで入手できますか?
移行に関するご質問やサポートについては、 [AWS サポート](https://aws.amazon.com/support)にお問い合わせください。