![[アップデート] Amazon Quick が AWS Agent Registry と統合し、AWS Knowledge MCP サーバーとの接続を試してみました](https://images.ctfassets.net/ct0aopd36mqt/2x7muHjvW69fxuVNSKWZHp/b37e05a972fc8125e9214abd764928fa/amazon-quick.png?w=3840&fm=webp)
[アップデート] Amazon Quick が AWS Agent Registry と統合し、AWS Knowledge MCP サーバーとの接続を試してみました
クラウド事業統括本部の石川です。AWS Agent Registry に登録した MCP サーバーを Amazon Quick から検索・利用できるようになりましたので、実際にレジストリの作成からチャットでのツール実行まで試してみました。
Amazon Quick が AWS Agent Registry との統合を発表しました。組織の AWS Agent Registry に登録されている MCP サーバーやエージェントを、Amazon Quick の画面から直接検索・参照し、数クリックで有効化できるようになりました。接続情報はレジストリから自動的に取り込まれるため、Quick 側で URL を手入力する必要はありません。有効化したリソースはチーム内で共有でき、Quick Chat、エージェント、アプリ、Amazon Quick Flows、Amazon Quick Research の各機能から利用できます。
この統合の狙いは、Amazon Bedrock AgentCore でエージェントや MCP サーバーを構築する技術チームと、Amazon Quick で日常業務を行うビジネスユーザーの間のギャップを埋めることにあります。すでに AWS Agent Registry に存在するエージェントやツールに対して、組織が個別に接続設定を作り直す必要がなくなります。
AWS Agent Registry と Amazon Quick の統合とは
AWS Agent Registry は、組織内の MCP サーバー、エージェント、エージェントスキル、カスタムリソースを一元的に登録・承認・検索できるフルマネージドのディスカバリサービスです。レジストリという単位でカタログを作り、その中にレコードとしてリソースのメタデータを登録します。登録されたレコードは承認ワークフローを通過してはじめて検索対象になります。
Amazon Quick 側から見ると、リンクしたレジストリのリモート MCP レコードが「コネクタ」ページに設定済みのカードとして現れます。そこからアクションコネクタを作成すると、他の Quick アクションコネクタと同じように扱えます。レジストリの内容が Quick にコピーされるわけではなく、コネクタページを開くたびにレジストリから読み出される仕組みです。
全体の流れは次のとおりです。
サポート範囲
公式ドキュメントでは、対応するレコードと構成が次のように整理されています。
| サポートされる | サポートされない |
|---|---|
mcpServer 記述子を使う MCP レコード |
スキルレコード、カスタムレコード |
| MCP プロトコル経由でアクセスするエージェントレコード | エージェント間 (A2A) 記述子 |
| リモートサーバー URL を公開しているリモート MCP サーバー | npx / docker / stdio などのローカル MCP エンドポイント |
前提条件
レジストリをリンクする前に、以下を満たしている必要があります。
- レジストリが Quick アカウントと同一の AWS アカウント・同一リージョンにあること(クロスアカウント・クロスリージョンは非対応)
- レジストリが AWS IAM (
AWS_IAM) 認可かつREADYステータスであること(JWT 認可のレジストリは Quick の管理コンソールに表示されません) - レジストリが
agent-registryネームスペースであること(旧bedrock-agentcoreネームスペースのレジストリは非対応) - Quick アカウントごとに接続できるレジストリは1つであること
- 管理者の IAM アイデンティティが
agent-registry:ListRegistriesを持つこと
ネームスペースについては補足が必要です。AWS Agent Registry は新しい agent-registry ネームスペースで GA しており、パブリックプレビュー時代の bedrock-agentcore ネームスペースのサポートは2026年9月17日に終了予定と公式ドキュメントに明記されています。今回の Quick 統合は新ネームスペース側のみが対象です。
やってみた
前提条件
検証環境は以下のとおりです。
- AWS リージョン:
ap-northeast-1(東京) - Amazon Quick: Enterprise エディション(既存アカウント、認証タイプは IDENTITY_POOL)、メインリージョンは
ap-northeast-1 - AWS CLI:
aws-cli/2.36.35 - 登録する MCP サーバー: AWS Knowledge MCP Server(認証不要の公開リモート MCP サーバー)
なお、登録対象の AWS Knowledge MCP Server は認証不要で、initialize を投げるだけで応答が返ります。
% curl -s -X POST "https://knowledge-mcp.global.api.aws/mcp" \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"probe","version":"1.0"}}}'
{"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2025-03-26","capabilities":{"tools":{"listChanged":false}},"serverInfo":{"name":"AWSKnowledgeMCP","version":"1.0.0"}}}
tools/list を呼ぶと、以下の5つのツールが返ってきました。この数が後の検証で効いてきます。
tool count: 5
- aws___read_documentation
- aws___search_documentation
- aws___list_regions
- aws___get_regional_availability
- aws___retrieve_skill
ステップ1: AWS Agent Registry を作成する
レジストリの作成はマネジメントコンソールから行います。AWS Agent Registry は独立したコンソールを持っており、東京リージョンでも利用できます。「レジストリを作成する」から以下を設定しました。
- 名前:
quick-agent-registry-demo - Search API 認証 / 認証タイプ: 「IAM ユーザー名を使用」
- レコード承認: 「自動承認を有効にする」を ON
- タグ:
run_id、owner

認証タイプの欄には「このレジストリの作成後に認証タイプを編集することはできません。」という注意書きが表示されます。Quick 統合の要件は AWS IAM 認可なので、ここで JWT を選ぶと後から Quick に繋げなくなります。作成時に必ず IAM を選んでおく必要があります。
コンソール側でステータスが「準備完了」に変わり、自動承認が「有効化済み」になっていることを確認できます。

ステップ2: MCP サーバーのレコードを登録する(エンドポイント同期)
レジストリ詳細画面の「レコードを作成」から登録します。レコードソースには2種類あります。
- ソース: エンドポイント URL と認証情報を指定し、レジストリが接続して詳細・ツール・メタデータを自動取得する
- 手動で定義: レコード定義、スキーマ、メタデータを手で指定する
まずは「ソース」を選びました。設定したのは以下だけです。
- タイプ: MCP、記述子: MCP サーバー
- エンドポイント:
https://knowledge-mcp.global.api.aws/mcp - 認証情報タイプ: 認証なし
「認証情報タイプ」で「IAM ロール」を選ぶとロール ARN とサービス名の入力欄が出ますが、「認証なし」を選ぶとそれらが消えて入力項目はエンドポイントのみになります。
作成すると、レコード名 AWSKnowledgeMCP が自動的に付き、サーバースキーマが取得されていました。

さらに、ツールスキーマとして5つのツールの inputSchema まで自動で取り込まれていました。エンドポイント同期の利点はここにあります。

ここで1つ注意点があります。作成直後のステータスは DRAFT で、自動承認を ON にしていても自動では公開されません。コンソールから、レコード名の右にステータスバッジ「ドラフト」が確認できます。

承認ステータスを変更する
レコードを検索できる状態にするには、ステータスを変更して承認フローに乗せます。レコード詳細画面の右上にある「更新ステータス」を開くと、現在のステータスに応じた選択肢が表示されます。ドラフトの場合は「承認用に送信」と「非推奨」の2つです。

「承認用に送信」を選ぶと、確認画面を挟まずにそのまま処理されました。レジストリの自動承認を有効にしているため、送信と同時に承認まで進み、ステータスバッジが「承認済み」に変わります。

自動承認はあくまで「送信されたレコードをレビューなしで公開する」設定であり、送信操作そのものは別途必要という理解になります。自動承認を無効にしている場合は、ここで「承認待ち」となり、キュレーターが確認して承認するまで検索対象になりません。なお、この操作はレコードの作り方(エンドポイント同期・手動定義)によらず共通です。
承認済みのレコードで同じメニューを開くと、選択肢は「拒否」と「非推奨」に変わります。現在のステータスによって選べる遷移先が切り替わる作りです。

ステップ3: 手動定義でもレコードを登録する
同期との違いを見るため、「手動で定義」でもう1つ登録しました。こちらは名前・表示名・説明・バージョンを自分で指定し、記述子の JSON を直接書きます。
- 名前:
AWSKnowledgeMCP-manual - 表示名:
AWS Knowledge MCP Server (Manual) - 説明: 日本語で記入
- レコードのバージョン:
1.0.0
JSON エディタには次のテンプレートが最初から入っています。
{
"name": "io.example/my-server",
"description": "Brief description of server functionality",
"version": "1.0.0"
}
このテンプレートには接続先を表す remotes が含まれていません。これをそのまま埋めるだけでは Quick から接続できるレコードになりませんので、remotes を自分で足す必要があります。今回は以下を入力しました。
{
"$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
"name": "io.classmethod/aws-knowledge-mcp-manual",
"description": "AWS Knowledge MCP Server (manually defined record)",
"version": "1.0.0",
"remotes": [
{
"type": "streamable-http",
"url": "https://knowledge-mcp.global.api.aws/mcp"
}
]
}
ステップ4: Amazon Quick にレジストリをリンクする
ここからは Amazon Quick の管理コンソールでの作業です。「アカウントを管理」の左ナビゲーションから「アクセス許可」→「AWS Agent Registry」を開きます。東京リージョンでもメニューが用意されていました。
ページには「Select one Agent Registry to connect your organization's custom agents and skills. Only registries in READY status that use AWS_IAM authorization can be selected.」と説明があり、条件を満たすレジストリだけが一覧に出ます。作成した quick-agent-registry-demo が表示されていたので、トグルを ON にしてリンクしました。確認ダイアログは表示されず、その場で有効になります。

このとき、次の警告が表示されました。
You are using a customer-managed role
Please make sure the role (arn:aws:iam::<ACCOUNT_ID>:role/service-role/aws-quicksight-service-role-v0)
has permission to call agent-registry:ListDiscoverableRegistryRecords,
agent-registry:SearchDiscoverableRegistryRecords, agent-registry:GetDiscoverableRegistryRecord
for the registry you connect.
公式ドキュメントによると、Quick マネージドロール(aws-quicksight-agent-registry-role-v0)を使っているアカウントでは、レジストリを有効化した時点で必要な権限が自動的に付与されます。一方、カスタマー管理のサービスロールを使っているアカウントでは、上記3つの権限を管理者が手動で追加する必要があります。今回の環境は後者に該当したため警告が出ました。
ステップ5: コネクタを作成する
Quick 本体に移動し、左ナビゲーションの「さらに詳しく」→「コネクタ」を開きます。ここで重要なのが、レジストリ由来のカードは「Available」タブではなく 「Create for your team」タブ に現れる点です。
タブを切り替えると、登録した2つのレコードがカードとして並んでいました。

AWSKnowledgeMCP(説明は「-」)AWSKnowledgeMCP-manual(説明は手動定義時に入力した日本語がそのまま表示)
同期で登録したレコードの説明が「-」になっているのは、AWS Knowledge MCP Server 自身が description を返していないためです。手動定義なら説明を自分で書けるので、業務ユーザーが選ぶ画面での分かりやすさという点では手動定義に利点があります。
AWSKnowledgeMCP のカードを開くと、5ステップのウィザードが起動しました。1つ目の「接続」ステップでは、What's New で説明されていたとおり接続情報が自動入力されています。
- Name:
AWSKnowledgeMCP - MCP server endpoint:
https://knowledge-mcp.global.api.aws/mcp(グレーアウト) - Connection type: Public network
エンドポイント欄には「This endpoint is provided by the Agent Registry and can't be edited.」と表示され、編集できません。レジストリを組織の唯一の情報源として扱い、Quick 側で勝手に接続先を書き換えられないようにするという設計意図が読み取れます。
Description まわりでつまずいた点
まず、空欄のまま「次へ」を押すと Description is required. で止まりました。同期で登録したレコードは説明が「-」だったため Quick 側に引き継がれず、必須項目が空のままウィザードが始まった形です。
そこで日本語で説明を書いたところ、今度は次のエラーが出ました。
Description can only contain letters, numbers, spaces, and the characters _ . , ! ? -
全角括弧を消しても解消せず、英数字だけの説明に書き換えたところ通過しました。
この制約は、手動定義したレコード側でより厄介な形で効いてきます。AWSKnowledgeMCP-manual のカードを開くと、レジストリに登録した日本語の説明が Description に自動入力されていました。

一見すると入力の手間が省けて便利なのですが、この状態で「次へ」を押すと、自動入力された日本語がそのままバリデーションに引っかかります。

つまり、レジストリのレコード説明を日本語で書いておくと、Quick でコネクタを作るたびに説明を英数字へ書き直す作業が発生します。日本語環境で運用する場合、レジストリ側の説明は最初から英数字で書いておくほうが手戻りがありません。
認証方法の選び方
続く「認証」ステップでは、認証方法として「ユーザー認証」と「サービス認証」が選べます。AWS Knowledge MCP Server は認証不要なので「なし」を選びたいところですが、「ユーザー認証」の Auth configuration には「なし」が存在しません(選べるのは「カスタムユーザーベースの OAuth」と「Custom headers」のみ)。「サービス認証」に切り替えると Auth configuration に「なし」が現れます。

認証不要の MCP サーバーを繋ぐ場合は、サービス認証を選ぶ必要があります。
ツールの検出
「作成して続行」を押すと Discovering tools from the MCP server. This may take a couple of minutes. と表示され、ツールの検出が始まりました。20秒後の時点ではまだ検出中で、1分ほど待つと次のステップに進んでいました。
検出結果は次のとおりでした。
- Write Operations: 0
- Read Operations: 5(
aws___get_regional_availability、aws___list_regions、aws___read_documentation、aws___retrieve_skill、aws___search_documentation)

CLI で tools/list を叩いて得た5つと完全に一致しています。AWS Knowledge MCP Server の各ツールは readOnlyHint: true を返すため、書き込み操作が0件になったものと考えられます。
最後の「Publish」ステップでは公開範囲を選びます。今回は検証目的なので組織全体への共有はせず、自分だけが使える状態で公開しました。公開後、「Available」タブで検索すると AWSKnowledgeMCP が ✓ Connected として表示されました。

ステップ6: Quick Chat から MCP ツールを呼び出す
新しいチャットを開き、入力欄の「+」→「コネクタ」を見ると、AWSKnowledgeMCP が接続済みのチェックマーク付きで並んでいました。

次の質問を投げてみます。
AWSKnowledgeMCP コネクタを使って、AWS Agent Registry で MCP サーバーのレコードを
登録する手順を AWS 公式ドキュメントから検索して教えてください。
回答の冒頭に「5 ステップを完了しました」と表示されたので展開すると、実行された処理が並んでいました。

Using aws___search_documentation in AWSKnowledgeMCP
Using aws___search_documentation in AWSKnowledgeMCP
Searching the web
Using aws___read_documentation in AWSKnowledgeMCP
Using aws___read_documentation in AWSKnowledgeMCP
レジストリ経由で登録した MCP サーバーのツールが、Quick Chat から実際に4回呼ばれています。各ステップをさらに展開すると、入力パラメータまで確認できました。

limit 5
search_phrase AWS Agent Registry MCP server register connector
topics ["general","agent_skills"]

requests [{"url":"https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/registry-get-started.html","max_length":15000},
{"url":"https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/registry.html","max_length":10000}]
search_phrase や topics、requests の配列といった引数は、いずれも AWS Knowledge MCP Server が公開しているツールスキーマどおりの形です。Quick が MCP のツール定義を正しく解釈して呼び出していることが確認できました。
一方で、回答の先頭には次の断り書きが出ていました。
AWS 公式ドキュメントの検索サービスが現在一時的に利用できない状態のため、
検索結果から得られた情報をもとにお答えします。
search_documentation が一時的にエラーを返し、ウェブ検索にフォールバックしたようです。実際、回答本文には「AWS Agent Registry は Amazon Bedrock AgentCore の機能として提供されています(現在 Preview)」という記述が含まれていました。AWS Agent Registry は既に GA しており、この記述は古い情報です。ただし引用元として提示されたソースには read_documentation が取得した公式ドキュメントのページが並んでおり、MCP 経由の取得自体は成功しています。
なお、この検証ではチャットの「ウェブ検索」がデフォルトで ON になっていました。MCP サーバーの応答だけを厳密に評価したい場合は、ウェブ検索をオフにしてから試すほうが切り分けやすいです。
考察
今回の検証で確認できたことと、実務で気をつけたい点を整理します。
まず、What's New が謳っている「接続情報がレジストリから自動入力される」という点は、そのとおりでした。コネクタ作成画面ではエンドポイントが入力済みかつ編集不可の状態で提示され、ユーザーが URL を知っている必要はありません。レジストリを組織の単一の情報源とし、そこから外れた接続先を Quick 側で作らせないという統制が効いています。管理者がレジストリでレコードを承認・非推奨にすることで、ビジネスユーザーが使えるツールの範囲をコントロールできる形です。
一方で、レジストリのリンクを解除しても、そこから作成済みのコネクタは削除されません。公式ドキュメントにも「The action connector is an independent Quick resource.」と明記されています。レジストリ側でレコードを取り下げても既存コネクタは動き続けるため、棚卸しの際はレジストリとコネクタの両方を確認する必要があります。
エンドポイント同期と手動定義の使い分けについては、次のように整理できます。
| 観点 | エンドポイント同期 | 手動で定義 |
|---|---|---|
| 名前・スキーマ | エンドポイントから自動取得 | 自分で入力 |
| ツール定義 | 自動取得される | 付かない |
remotes の指定 |
不要 | 必須(テンプレートに含まれないため要追記) |
| 説明 | MCP サーバーの description 依存 |
自由に記述できる |
| 承認までの操作 | 作成後に「承認用に送信」が必要 | 「作成して承認のために送信」で1回 |
エンドポイントに到達できるならまず同期を試し、説明文を業務ユーザー向けに整えたい場合や、エンドポイントに到達できない環境では手動定義を使う、という判断になりそうです。今回のように MCP サーバー側が description を返さないケースでは、同期したレコードの説明が「-」となり、Quick のコネクタ作成時に必須エラーで止まります。カタログとしての見え方を重視するなら、同期後にレコードを編集して説明を補うか、手動定義を選ぶのが実用的だと感じました。
ただしその説明は英数字で書く必要があります。レジストリ側の説明は Quick のコネクタ作成画面へ自動入力されますが、Quick 側のバリデーションは英数字・スペースと _ . , ! ? - しか受け付けません。日本語で書いておくと、コネクタを作るユーザーが毎回書き直す羽目になります。カタログの説明を日本語で統一したい組織にとっては悩ましい制約で、今後の改善に期待したいところです。
はまりやすい点をまとめると、以下のようになります。
- 認証タイプはレジストリ作成後に変更できません。Quick と繋ぐつもりなら作成時に必ず AWS IAM を選ぶ必要があります
- レジストリは Quick アカウントと同一アカウント・同一リージョンである必要があります。Quick の実体リージョンは
list-namespacesのCapacityRegionで確認できます - 認証不要の MCP サーバーを繋ぐ場合、「ユーザー認証」ではなく「サービス認証」を選ばないと Auth configuration に「なし」が出てきません
- コネクタの Description は必須で、日本語が使えません。レジストリ側の説明も英数字で書いておくと手戻りがありません
- 手動定義の JSON テンプレートには
remotesが含まれていないため、自分で追記する必要があります - カスタマー管理のサービスロールを使っている場合、
agent-registryの読み取り権限3つを手動で付与する必要があります
料金面では、AWS Agent Registry は従量課金かつ無料枠が用意されています。公式の料金ページによれば、毎月最初の5,000レコード、100万回の Search API 呼び出し、200万回の Get と List の合計呼び出しが無償で、レコードは削除すればネット数から差し引かれます。今回の検証はレコード2件と数十回の API 呼び出しに収まったため、追加費用は発生していません。
今後に期待したいのは、対応レコード種別の拡大です。現時点では mcpServer 記述子のリモート MCP サーバーのみが対象で、A2A 記述子・スキルレコード・カスタムレコードは Quick からは扱えません。AWS Agent Registry 自体はエージェントスキルやカスタムリソースもカタログできるため、これらが Quick 側でも扱えるようになると、レジストリを本当の意味での組織カタログとして運用しやすくなります。
最後に
AWS Agent Registry と Amazon Quick の統合を、レジストリの作成から Quick Chat でのツール実行まで一通り試しました。レジストリに MCP サーバーを1件登録しておけば、Quick 側では「Create for your team」タブからカードを選び、認証方法を指定するだけでコネクタが完成します。エンドポイントの手入力が不要で、しかも編集できないという設計は、ツールの提供元を技術チームが握りつつ、利用はビジネスユーザーに開放するという運用によく合っています。
Amazon Bedrock AgentCore で MCP サーバーやエージェントを整備している組織であれば、それらを Quick のユーザーに届ける経路として検討する価値があります。まずは AWS Knowledge MCP Server のような認証不要の公開サーバーを1件登録し、コネクタ作成からチャットでの呼び出しまで通してみると、必要な権限や設定の勘所がつかめます。
その際は、レジストリを新しい agent-registry ネームスペースで、AWS IAM 認可、Quick と同一リージョンに作ることを最初に確認しておくと手戻りがありません。旧 bedrock-agentcore ネームスペースのレジストリを運用している場合は、2026年9月17日のサポート終了に向けた移行もあわせて計画する必要があります。










