序章移行のタイムラインを教えてください。名前空間と設定の変更 API スキーマの変更データ移行よくある質問

包括的なレジストリ移行ガイド

AWS エージェントレジストリ — パブリックプレビューから一般提供への移行

序章

2026 年 8 月 6 日に一般提供 (GA) としてリリースされるにあたり、 AWS Agent Registry はサービスプリンシパル、データ、API モデルに大きな変更を導入しています。パブリックプレビュー中に AWS エージェントレジストリを使用した場合は、次の 3 つの領域にまたがる移行を完了する必要があります。

名前空間と設定の変更 – AWS エージェントレジストリを AWS Bedrock AgentCore 名前空間から独自の専用名前空間に移動しています。この名前空間の変更は、 AWS エージェントレジストリにのみ適用されます。Identity、Gateway、Runtime、Policy など、他のすべての AgentCore サービスは影響を受けません。 AWS エージェントレジストリの場合、サービス名前空間はから bedrock-agentcoreに変わりますagent-registry。これは、エンドポイント、IAM ポリシー、SDK クライアント、CLI コマンド、リソース ARNs、オブザーバビリティ統合など、サービスを参照するすべての表面に影響します。新しい名前空間を使用するには、コードとインフラストラクチャを更新する必要があります。
API スキーマの変更 – レジストリとレジストリレコードのデータモデルは、パブリックプレビュー中のお客様からのフィードバックに基づいて更新されます。これらの変更により、既存の API スキーマとの下位互換性が損なわれます。API リクエストとレスポンスを構築または解析するアプリケーションコードは、新しい名前空間への移行の一環として、新しいスキーマを反映するように更新する必要があります。
データ移行 – 既存のレジストリとレジストリレコードを古い名前空間から新しい名前空間に移行する必要があります。データを抽出し、新しいスキーマに変換して、新しい名前空間にロードするための移行ツールが用意されています。データは同じアカウントとリージョンに移行され、名前空間のみが変更されます。

このガイドでは、移行の計画と実行に役立つbefore-and-afterの例を使用して、各領域について詳しく説明します。

移行のタイムラインを教えてください。

この移行では、次の 2 つの重要なマイルストーンを覚えておく必要があります。

2026 年 8 月 6 日 — AWS エージェントレジストリが一般利用可能になり、新しいagent-registry名前空間が正式に起動します。既存のレジストリとレコードがある場合は、 bedrock-agentcoreおよび agent-registry名前空間に同時にアクセスできます。移行ツールが agentcore-samples GitHub リポジトリで利用可能になります。移行プロセスを開始できます。

注記
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 アクセス許可リファレンス」を参照してください。

注記

現在 AWS 、エージェントレジストリアクセスに BedrockAgentCoreFullAccess AWS 管理ポリシーを使用している場合 (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時に各に有効な記述子キーを適用します。の各最上位キーは、詳細なプライマリ記述子タイプ (、、a2aAgentCardmcpServeragentSkillsDefinition、など) を表すdescriptorsようになりましたcustom。補足記述子 (、などtoolsskillMd) は、プライマリ記述子のの下にネストされます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": "<dotted.path>", "values": ["<value>"] }エントリのリストで、 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 サポートにお問い合わせください。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

トラブルシューティング

セキュリティ

包括的なレジストリ移行ガイド

序章

移行のタイムラインを教えてください。

注記

名前空間と設定の変更

重要

サービスエンドポイント

IAM とセキュリティ

注記

SDK、CLI、インフラストラクチャ

オブザーバビリティとイベント

例: IAM ポリシーの更新

注記

重要

例: SDK クライアント設定の更新

例: CLI コマンドの更新

API スキーマの変更

変更 1: レジストリエンティティの更新

変更 2: レジストリレコードの新しい必須フィールド

変更 3: レジストリレコードの再構築

変更 4: データプレーンフィルターの更新

変更 5: 新しいブラウジング APIs

変更 6: APIs構造化フィルターパラメータを採用する一覧表示

データ移行

移行アプローチの選択

ケース 1: 直接スクリプト実行による小規模な移行

ケース 2: Lambda または Glue によるマネージド移行

ケース 3: アクティブな本番ワークロードのデュアル書き込み移行

移行の検証

よくある質問

AWS エージェントレジストリの変更点

bedrock-agentcore 名前空間で Registry を引き続き使用できますか?

データは自動的に移行されますか?

どのような API スキーマの変更が含まれていますか?

データ移行にはどのくらいの時間がかかりますか?

アクティブな書き込みを含む大規模なデプロイがある場合はどうなりますか?

ヘルプはどこで入手できますか?

`bedrock-agentcore` 名前空間で Registry を引き続き使用できますか?