AI

AWS Agent Registryとは：MCPとエージェントの社内カタログを作る手順と料金

AWS Agent Registryとは：MCPとエージェントの社内カタログを作る手順と料金

AWS Agent Registryは、社内で作ったAIエージェント・MCPサーバー・スキルを1か所に登録し、承認を通ったものだけを人とエージェントが検索できるようにするAWSのカタログサービスです。2026年4月にプレビューとして公開され、8月31日に一般提供（GA）になりました。この記事では、GA時点の公式ドキュメントをもとに、仕組みとレコードの種類、AWS CLIでの登録から承認・検索までの手順、Claude CodeやKiroからMCPエンドポイントへつなぐ設定、料金の試算を整理します。プレビュー版を使っていた場合に10月30日までに必要な名前空間の移行と、導入を見送るべき組織の条件も扱います。

まとめ：AWS Agent Registryを入れる組織と見送る組織の判断を先出し

複数のチームがMCPサーバーやエージェントを別々に作り始めた組織なら、AWS Agent Registryを入れる価値があります。同じ機能の作り直しを防ぎ、セキュリティ審査を通したものだけを検索結果に出せるためです。AgentCore RuntimeやGatewayで動かしているものは、AWS Organizationsの設定で自動的に台帳へ載ります。

料金は、月5,000レコードと検索100万回までが無料です。数百件規模の社内カタログなら、検索回数が多くても月数十ドルに収まる計算になります。

プレビュー版で作ったレジストリは、2026年10月30日に旧名前空間ごと読み書きできなくなります。データは自動では移らず、移行ツールを利用者側で実行する作業が必須です。一方、MCPサーバーが数本でチームも1つなら、Gitの一覧ファイルで足ります。

AWS Agent Registryの仕組みとレジストリ・レコード・承認状態の全体像

AWS Agent Registryの公式ドキュメントは、このサービスを「組織全体のリソースを整理・選別・発見するための集中カタログを提供するフルマネージドの発見サービス」と定義しています。構成要素はレジストリとレジストリレコードの2つだけです。レジストリはカタログの単位で、名前・認可方式・承認設定を持ちます。全社で1つにまとめても、本番と検証、部署ごとに分けてもかまいません。AgentCoreの他の部品（Runtime・Gateway・Identityなど）との関係はAmazon Bedrock AgentCore APIの使い方｜SDK・CLIでAIエージェントを本番デプロイで整理しています。

MCP・AGENT・SKILL・CUSTOMの4種類のレコードと登録できる記述子

レコードは登録するもの1件を表し、recordTypeで種類を決めます。種類ごとに使える記述子（descriptor）が決まっていて、1レコードに入れられる主記述子は1つだけです。

recordType 登録するもの URLからの自動同期
MCP MCPサーバーとそのツール 対応
AGENT A2Aエージェント 対応
SKILL Markdownのスキル定義 非対応
CUSTOM 任意のJSONで書くもの 非対応（手入力）

使える主記述子は、MCPがmcpServerかcustom、AGENTがa2aAgentCard・mcpServer・customのいずれか、SKILLがagentSkillsDefinitionかcustom、CUSTOMはcustomのみです。MCPサーバーの記述子は、公式MCP Registryと同じserver.json形式で書き、スキーマ版（例：2025-12-11）に対して検証されます。A2Aのエージェントカードはスキーマ版0.3です。標準のMCPやA2Aに沿わない社内APIは、CUSTOMで登録します。MCPそのものの仕組みはMCPとは？AIと外部ツールをつなぐ標準規格とMCPサーバーの仕組み、A2AはA2A（Agent2Agent）プロトコルとは？v1.0の仕組み・MCPとの違いで扱っています。

DRAFTからAPPROVEDまでの承認ワークフローと検索に出る条件

作成したレコードはDRAFTから始まり、承認申請でPENDING_APPROVAL、承認でAPPROVEDになります。検索や一覧に出るのはAPPROVEDだけです。却下ならREJECTED、使わなくなればDEPRECATEDへ移します。承認済みのレコードを更新すると、DRAFTへ戻ります。

承認の判断ロジックは組み込まれていません。代わりに、状態が変わるたびにAmazon EventBridgeへイベントが出るので、脆弱性スキャンや重複チェックを自前のワークフローでつなぎます。レジストリ作成時に自動承認（APPROVE_ALL）を指定すると、申請した時点でAPPROVEDになります。指定しなければ手動承認です。

東京を含む5リージョンと2026年8月GAで追加された自動検出・RAM共有

2026年8月31日のGA発表によると、提供リージョンは東京・シドニー・アイルランド・バージニア北部・オレゴンの5つです。国内の業務データを扱う案件でも、レジストリを東京に置けます。

GAで増えた機能のうち、運用への影響が大きいのは2つです。1つはAWS Organizationsとの連携による自動検出で、メンバーアカウントのAgentCore RuntimeとGatewayが、アカウントごとの設定なしで中央のレジストリに載ります。もう1つはAWS RAMによるアカウント間共有で、選択できる権限はReadOnly・Consumer・Publisher・Adminの4つです。CloudFormation・Terraform・CDKでの管理と、KMSのカスタマー管理キーによる暗号化もGA時点で使えます。

AWS CLIでレジストリ作成からレコード登録・承認・検索まで試す手順

ここでは公式の入門ガイドの流れを、東京リージョン向けに書き直して並べます。コマンドは新しいagent-registry名前空間のものです。旧来のbedrock-agentcore-controlで書かれた記事の手順は、2026年8月6日以降に初めて使う人には動きません。

agent-registry-controlでレジストリとMCPサーバーのレコードを作る

管理系の操作はagent-registry-control、検索系はagent-registryと、CLIの名前空間が2つに分かれています。まずレジストリを作り、状態がREADYになってからレコードを登録します。

# 前提: AWS CLI を最新版に更新し、agent-registry-control:* 相当の権限を持つプロファイルで実行する
export AWS_REGION=ap-northeast-1

# 1. レジストリを作成（入門ガイドと同じIAM認可・手動承認の構成。JWTにする場合は作成時に指定する）
aws agent-registry-control create-registry \
  --name "corp-agent-catalog" \
  --description "社内のMCPサーバーとエージェントの台帳"

# 2. 返ってきた registryId を控え、status が READY になるまで待つ
aws agent-registry-control get-registry --registry-id <registryId>

# 3. MCPサーバーのレコードを登録（server.json 形式の記述子を data に文字列で渡す）
aws agent-registry-control create-registry-record \
  --registry-id <registryId> \
  --name "invoice-mcp-server" \
  --display-name "請求書検索MCPサーバー" \
  --record-type MCP \
  --descriptors '{"mcpServer": {"data": "{\"name\": \"io.example/invoice-mcp\", \"description\": \"請求書を取引先名と期間で検索する\", \"version\": \"1.0.0\"}", "dataSchemaVersion": "2025-12-11"}}' \
  --record-version "1.0"

レジストリ名は英数字で始まる64文字以内、レコード名は255文字以内です。同じレジストリ内では、レコード名とバージョンの組み合わせが一意でなければなりません。説明文（description）は1〜4,096文字で、検索の精度はここの書き方で変わります。「請求書を取引先名と期間で検索する」のように、利用者が打ちそうな言葉で書いておくと見つかりやすくなります。

承認してagent-registryの検索APIとboto3から承認済みレコードを引く

レコードがDRAFTになったら、承認申請と承認を行い、検索で引けることを確かめます。

# 4. 承認申請（自動承認なら、この時点で APPROVED になる）
aws agent-registry-control submit-registry-record-for-approval \
  --registry-id <registryId> --record-id <recordId>

# 5. キュレーターが承認する（理由は監査用に残る）
aws agent-registry-control update-registry-record-status \
  --registry-id <registryId> --record-id <recordId> \
  --status APPROVED --status-reason "セキュリティ審査済み"

# 6. 自然文で検索（意味検索とキーワード検索のハイブリッド）
aws agent-registry search-discoverable-registry-records \
  --search-query "取引先ごとの請求書を探したい" \
  --registry-ids "<registryId>"

アプリやエージェントから引くときは、boto3のagent-registryクライアントを使います。

import boto3

client = boto3.client("agent-registry", region_name="ap-northeast-1")

# 承認済みレコードだけが対象。registryIds にはレジストリのARNを渡す
res = client.search_discoverable_registry_records(
    registryIds=["arn:aws:agent-registry:ap-northeast-1:123456789012:registry/<registryId>"],
    searchQuery="取引先ごとの請求書を探したい",
    maxResults=10,
)
for r in res["registryRecords"]:
    print(r["displayName"], r["recordType"], r["recordVersion"], r["recordId"])

# 記述子の中身まで要る場合は、1回で最大100件をまとめて取得する
detail = client.batch_get_discoverable_registry_record(
    entries=[{"registryId": "<registryId>", "recordIds": [r["recordId"] for r in res["registryRecords"]]}]
)
for err in detail["errors"]:
    print("取得失敗:", err["recordId"], err["errorCode"])

一括取得はHTTP 200のまま一部だけ失敗することがあり、失敗分はerrorsにRESOURCE_NOT_FOUNDやACCESS_DENIEDとして返ります。戻り値の確認を省くと、権限不足のレコードが黙って抜け落ちます。

Claude CodeやKiroからレジストリのMCPエンドポイントへ接続する設定

各レジストリは、MCP仕様2025-11-25に沿ったエンドポイントを持ちます。URLはhttps://agent-registry.<region>.api.aws/registry/<registryId>/mcpの形です。MCPエンドポイントのページによると、公開されるツールは検索・一覧・一括取得の3つで、検索ツールのmaxResultsは1〜20件です。開発者はIDEのエージェントに「社内に請求書のMCPサーバーはあるか」と聞くだけで、承認済みの候補を受け取れます。

IAM認可のレジストリはmcp-proxy-for-aws経由でSigV4署名して接続

IAM認可のレジストリは、リクエストにSigV4署名が要ります。MCPクライアントは署名できないため、AWS公式のmcp-proxy-for-awsを間に挟みます。Kiroのmcp.jsonなら次の形です。

{
  "mcpServers": {
    "corp-agent-catalog": {
      "type": "stdio",
      "command": "uvx",
      "args": [
        "mcp-proxy-for-aws@latest",
        "https://agent-registry.ap-northeast-1.api.aws/registry/<registryId>/mcp",
        "--service", "agent-registry",
        "--region", "ap-northeast-1",
        "--profile", "my-profile"
      ]
    }
  }
}

呼び出す側のIAMには、agent-registry:InvokeRegistryMcpと検索アクションの2つの権限が必要です。前者だけだと、初期化とツール一覧は通るのに検索だけが拒否されます。AWS側のMCPサーバーを同じプロキシでつなぐ例はAWS MCP Serverとは？GA版の接続手順と全ツール・権限設計にあります。

JWT認可のレジストリはDCRかクライアントID登録でOAuth接続

社内の利用者をIdP（Cognito、Entra IDなど）で管理しているなら、作成するのはJWT認可のレジストリです。MCPクライアントが動的クライアント登録（DCR）に対応していれば、レジストリ側にallowedAudienceとしてMCPエンドポイントのURLを登録し、クライアントにはURLだけを書けば接続できます。DCRが使えないIdPでは、事前に作ったクライアントIDをallowedClientsに登録し、Claude Codeの設定にoauth.clientIdとコールバックポートを書きます。

作成後に変えられない設定が3つあります。認可方式（IAMかJWTか）、IdPのディスカバリURL、そして1つのレジストリでIAMとJWTを同時に使えないという制約です。また、JWT認可のレジストリはAWS CLIやSDKで検索できず、コンソールの検索画面も使えません。運用者がCLIで中身を確かめたいなら、管理用にIAM認可のレジストリを別に立てる設計にします。

プレビュー利用者が10月30日までに済ませるagent-registry名前空間への移行

プレビュー版はbedrock-agentcore名前空間の一部でしたが、2026年8月6日に独立したagent-registry名前空間へ移りました。公式の移行ガイドでは、旧名前空間は2026年10月30日に停止し、残ったデータへの読み書きもできなくなると明記されています。自動移行はありません。

エンドポイント・IAMアクション・ARN・EventBridgeソースの置換対象一覧

書き換えの対象はコードだけではありません。IAMポリシー、SCP、監視の設定まで及びます。リポジトリやIaCのテンプレートを検索するときの置換表として、旧値と新値を並べます。

# 対象                   旧（プレビュー）                                   新（GA）
データプレーン           bedrock-agentcore.{region}.amazonaws.com           agent-registry.{region}.api.aws
コントロールプレーン     bedrock-agentcore-control.{region}.amazonaws.com   agent-registry-control.{region}.api.aws
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}
EventBridgeソース        aws.bedrock-agentcore                              aws.agent-registry
CloudWatch名前空間       AWS/BedrockAgentCore                               AWS/AgentRegistry
Service Quotasコード     bedrock-agentcore                                  agent-registry
CLI                      aws bedrock-agentcore(-control)                    aws agent-registry(-control)

ARNの行だけは長いため、上段に旧値、下段に新値を置いています。Service Quotasで上限緩和を申請していた場合は、新しいコードで申請し直しになります。

見落としやすいのは3点です。管理ポリシーのBedrockAgentCoreFullAccessには新アクションが追加されないため、AgentRegistryFullAccessへ差し替えます。URL同期でOAuthやIAMの認証情報を使っているレコードは、bedrock-agentcore:CreateWorkloadIdentityなどIdentity側の権限を引き続き残す必要がある構成です。IAMロールで同期しているレコードは、ロールの信頼ポリシーのプリンシパルをagent-registry.amazonaws.comへ変えてから移行します。変えないまま移すと、レコードがCREATE_FAILEDで止まります。

APIスキーマの記述子型変更と書き込み停止可否による移行ツールの選定

名前空間だけでなく、APIの形も後方互換なしで変わりました。descriptorTypeは廃止されてrecordType（AGENT・MCP・SKILL・CUSTOM）に、inlineContentはdataに、schemaVersionとprotocolVersionはdataSchemaVersionにまとまりました。旧nameはdisplayNameになり、新しいnameは重複防止のキーとして必須です。自動承認の真偽値も、autoApprovalRulesの配列に置き換わりました。

データの移し替えには、AWSがagentcore-samplesで公開している移行ツールを使います。レコードが数百件までで書き込みを止められるなら、端末かCloudShellから1回流す方法で足ります。公式ガイドの目安は100件未満で数分です。本番で書き込みが続いているなら、CDKでAWS Glueのジョブを立て、全件移行のあと切り替え直前に差分だけを流します。移行後は件数を突き合わせ、記述子の変換を数件抜き出して目で確認します。

レコード数と検索回数で決まるAWS Agent Registry料金の試算と無料枠

AgentCoreの料金ページによると、課金はレコード数とAPIの呼び出し回数の2系統です。最低料金や事前の契約はありません。

月5,000レコード・検索100万回まで無料となる3つの課金軸の単価

課金軸 毎月の無料枠 超過分の単価
レコード 5,000レコード 1,000レコードあたり0.400ドル
検索API 100万回 1,000回あたり0.020ドル
一覧・取得API 合計200万回 1,000回あたり0.004ドル

レコードは、その時点でレジストリに残っている件数だけが数えられます。登録後に削除したものは含まれません。注意が要るのは、AWS Agent Registryをエンドユーザーへ再販する事業者には無料枠が適用されない点です。自社サービスにレジストリを組み込んで顧客へ提供する設計なら、1件目のレコードから課金されます。

500レコード・月300万回検索の社内カタログで月額を計算した結果

社内エージェントが検索のたびにレジストリを呼ぶ構成を想定し、料金ページの単価で計算しました。

# 料金ページの単価（2026年10月10日確認）で月額を出す
RECORDS, SEARCHES, LIST_GET = 500, 3_000_000, 1_000_000

def over(n, free, per_1000_usd):
    return max(n - free, 0) / 1000 * per_1000_usd

total = (over(RECORDS, 5_000, 0.400)
         + over(SEARCHES, 1_000_000, 0.020)
         + over(LIST_GET, 2_000_000, 0.004))
print(f"月額 ${total:,.2f}")  # 月額 $40.00

結果は月40ドルで、すべて検索の超過分です。500件ではレコード課金は発生しません。費用を左右するのは件数ではなく検索回数なので、エージェントが同じ質問で何度も検索しないよう、セッション内で結果を使い回す実装にしておくと請求は無料枠の内側に寄せられます。

AWS Agent Registryを導入する組織と見送る組織の線引きと失敗パターン

機能と料金を踏まえて、判断を言い切ります。

MCPサーバーとエージェントが3チーム以上に散る組織は導入対象

次の条件のうち2つ以上に当てはまれば導入します。MCPサーバーやエージェントを作るチームが3つ以上ある。AWSアカウントがOrganizationsで複数に分かれている。外部のMCPサーバーを使う前に、セキュリティ部門の審査を通す決まりがある。この状態で台帳がないと、同じ社内APIのMCPサーバーが部署ごとに作られ、どれが審査済みかを誰も答えられなくなります。

AgentCore RuntimeとGatewayで動かしているなら、自動検出が使える点でAWS Agent Registryが有利です。利用者の入口がMicrosoft 365で、Entra IDでエージェントを管理したいなら、Microsoft Agent 365でエージェントを登録する手順と比べてから決めます。

チーム1つ・MCPサーバー数本の段階ではGitの一覧で足りる理由

作り手が1チームで、MCPサーバーが5本程度なら導入しません。リポジトリにserver.jsonを並べてプルリクエストで審査すれば、承認の記録も残ります。AWS Agent Registryの強みは「他チームが作ったものを探せる」ことなので、探す相手がいない段階では管理の手間だけが増えます。

導入後に起こりやすい失敗は、検証を急いで自動承認を全レジストリに付けたまま本番へ持ち込む形です。これでは審査済みかどうかの区別が消え、台帳を置いた意味がなくなります。本番のレジストリは手動承認で作り、自動承認の使用範囲は開発用に限定する方針です。どの単位でレジストリを分け、承認フローを誰が持つかを決めかねている段階なら、AIエージェント開発の相談窓口で既存のエージェントとMCPサーバーの棚卸しから一緒に整理できます。

AWS Agent Registryの料金・東京対応・移行でよくある質問

AWS Agent Registryを検討する段階で出やすい質問に、2026年10月時点の公式情報で答えます。

AWS Agent RegistryとAgentCore Gatewayの違いは何ですか？

役割が違います。AgentCore Gatewayは、既存のAPIやLambda関数をMCPのツールに変換し、エージェントからの呼び出しを中継する実行側の部品です。AWS Agent Registryは、どんなツールやエージェントがあるかを登録して検索させるカタログで、呼び出しの中継はしません。両方を使う場合、Gatewayで公開したツールをRegistryに登録し、エージェントはRegistryで探してGatewayを呼ぶ流れになります。GAで、Gateway上のツールを自動で台帳に載せる機能も入りました。

AWS Agent Registryは東京リージョンで使えますか？

使えます。2026年8月31日のGA発表では、提供リージョンは東京（ap-northeast-1）・シドニー・アイルランド・バージニア北部・オレゴンの5つです。MCPエンドポイントのURLはagent-registry.ap-northeast-1.api.awsで始まります。閉域網から使う場合は、コントロールプレーンとデータプレーンの2つのVPCエンドポイント（PrivateLink）を作ります。

公式のMCP Registryとは何が違いますか？

公式のMCP Registry（registry.modelcontextprotocol.io）は、公開されているMCPサーバーを誰でも探せる共有の目録です。AWS Agent Registryは、組織の中だけで使う非公開の目録で、承認を通ったものだけを見せる点が違います。記述子はどちらもserver.json形式なので、公開版に載せたものと同じ定義を社内側にも登録できます。

AWS Agent Registryは無料で試せますか？

試せます。毎月5,000レコード、検索100万回、一覧・取得200万回までは無料枠に収まります。入門ガイドの手順で、レジストリ1つとレコード数件を作って検索する程度なら、料金は発生しません。ただし、レジストリを顧客へ再販する事業者には無料枠がなく、1件目から課金されます。

プレビュー版のbedrock-agentcore名前空間で作ったレジストリはどうなりますか？

2026年10月30日に旧名前空間が停止し、残っているレジストリとレコードは読み書きできなくなります。自動では移らないため、agentcore-samplesの移行ツールで新名前空間へ移し、コード・IAMポリシー・EventBridgeルールを書き換えてください。2026年8月6日時点でレジストリを持っていなかったアカウントは、旧名前空間をそもそも使えません。

関連記事

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

この記事に関連するサービス

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.10.09　テックブログ IDCFクラウド（IDCフロンティア）不正アクセス・ランサムウェア：影響先・復旧・データは戻るか
  2. 2026.10.09　テックブログ ニッスイのサイバー攻撃で日水物流の入出荷停止｜委託先クラウド障害に荷主が備える手順
  3. 2026.10.09　テックブログ 京王電鉄のランサムウェア被害とグループ共通基盤：決済・ポイント・予約が止まった範囲と遮断の初動
  4. 2026.10.09　テックブログ スタディサプリの不正アクセスとメールアドレス3,687件｜アカウント列挙を防ぐ実装
  5. 2026.10.08　コラム 雇用保険の適用拡大：2028年10月の週10時間以上への変更と、勤怠・労務システムで直す判定ロジック

RELATED POSTS 関連記事

一覧へ戻る

目次