![[アップデート] Amazon Quick がコネクタのツール単位の有効化と MCP sync をサポートしたので試してみました](https://images.ctfassets.net/ct0aopd36mqt/2x7muHjvW69fxuVNSKWZHp/b37e05a972fc8125e9214abd764928fa/amazon-quick.png?w=3840&fm=webp)
[アップデート] Amazon Quick がコネクタのツール単位の有効化と MCP sync をサポートしたので試してみました
クラウド事業統括本部の石川です。Amazon Quick のコネクタで、ツール単位の有効化・無効化と実行時の承認設定、そして外部 MCP サーバーの変更に追随する MCP sync がサポートされましたので、実際に試してみました。
Amazon Quick のコネクタは、Outlook、Slack、Salesforce、Jira といった外部サービスや自社で用意した MCP サーバーのツールを、チャットエージェント、アプリ、フロー、ディープリサーチ（研究）といった Quick 上のワークフローから利用できるようにする仕組みです。
今回のアップデートで追加されたのは次の3点です。
- コネクタが持つツールを個別に有効化・無効化し、承認したツールだけをエンドユーザーに公開できる
- **ツールごとに、実行前の承認（consent）**を必須にするか、エンドユーザーの判断に委ねるかを選べる
- MCP sync により、外部 MCP サーバー側でのツール追加や説明文の更新にコネクタを追随させられる
コネクタが増えるほど、そこにぶら下がるツールの数も増えていきます。MCP サーバーを1つ接続するだけで十数個のツールが一度に登録されることもあり、そのすべてを無条件にエンドユーザーへ公開してよいかは別の判断が必要です。今回の機能は、そこに管理者側の制御を入れるためのものと位置づけられます。
なお、MCP 統合を利用するには Quick の Enterprise サブスクリプションが必要です。対応しているのはリモート MCP サーバーのみで、ローカルの stdio 接続はサポートされていません。トランスポートは Server-Sent Events（SSE）よりも HTTP streaming が推奨されています。
ツール設定と MCP sync とは
MCP（Model Context Protocol）は、AI アプリケーションが外部ツールやデータソースと通信する方法を定めたオープンな標準です。MCP サーバーは自身が提供するツールの一覧を公開し、クライアントはそれを呼び出してデータベースへの問い合わせや API 呼び出しなどを実行します。
Amazon Quick では、MCP サーバーが公開するツールが「アクション」として登録されます。公式ドキュメントには、接続時にツールが検出・登録されたあと、各ツールはレビューして有効化するアクションとして一覧表示され、自動的に利用可能にはならないと記載されています。今回のアップデートは、このレビューと有効化の部分を、より細かく制御できるようにしたものと理解できます。
やってみた
前提条件
- Amazon Quick（Enterprise エディション）
- AWS CLI v2（今回は aws-cli/2.36.35、botocore 1.43.65）
- 検証環境: identity region は ap-northeast-1
接続先の MCP サーバーには、認証不要で利用できる AWS Knowledge MCP Server を使用しました。
https://knowledge-mcp.global.api.aws/mcp
検証前のコネクタ数を確認する
まず、検証前のアクションコネクタ数を CLI で確認しておきます。Quick のアクションコネクタは quicksight の API 名前空間で操作します。
% aws quicksight list-action-connectors \
--aws-account-id 123456789012 \
--region ap-northeast-1 \
--query 'length(ActionConnectorSummaries)'
18
MCP コネクタを作成する
Quick のコンソールで、左サイドバーの「さらに詳しく」から「コネクタ」を開きます。
「Create for your team」タブに切り替え、「Model Context Protocol」を選択します。
ここで最初の変化に気づきます。ウィザードが接続、認証、Manage Write Permissions、Manage Read Permissions、Publish の5ステップ構成になっていました。
公式ドキュメントに記載されている手順では、認証設定のあとは統合内容のレビューと共有設定に進む流れですが、実際の画面には権限管理のステップが2つ挟まっています。今回追加されたツール設定は、このステップに集約されていました。
ステップ1では名前、説明、MCP サーバーエンドポイント、接続タイプを入力します。２つ注意点があります。１つ目は、説明（Description）が必須項目だったことです。画面上のラベルは「+ Add Description」で、公式ドキュメントでも Optional と記載されていますが、空のまま次へ進もうとすると Description is required. と表示されて先に進めませんでした。
2つ目、説明に使用できる文字が制限されている点です。丸括弧を含む説明文を入力したところ、以下のバリデーションエラーが返されました。
Description can only contain letters, numbers, spaces, and the characters _ . , ! ? -
括弧を外した説明文に書き換えることで通過しました。
また、接続タイプの下に「Auth connection type」という項目があり、リソースサーバーへの接続経路とは別に、認証サーバーへの接続経路を指定できるようになっていました。
ステップ2の認証では、ユーザー認証とサービス認証のいずれかを選びます。AWS Knowledge MCP Server は認証不要のため認証なしを選択したいところですが、ユーザー認証を選ぶと Auth configuration の選択肢は「カスタムユーザーベースの OAuth」と「Custom headers」の2つだけで、認証なしに相当する選択肢がありません。
サービス認証に切り替えると、Auth configuration に**「なし」**が現れます。今回はこちらを選択しました。
ツールごとのアクセスレベルを設定する
「作成して続行」を押すと MCP サーバーからのツール検出が始まります。画面には数分かかる場合があると表示されますが、今回は10秒足らずで完了しました。
検出が終わるとステップ3の Manage Write Permissions に進みます。ここには「Write-operation access level defaults」として、書き込み系ツールの既定の扱いを決める2つの選択肢がありました。
- Let users choose: ユーザーが初回利用時に自分で設定する
- Always ask: 毎回、実行前にユーザーの承認を求める
AWS Knowledge MCP Server は読み取り専用のため、Write Operations は0件でした。
続くステップ4の Manage Read Permissions では、読み取り系ツールとして5件が検出されていました。
| アクション | 説明 |
|---|---|
| aws___get_regional_availability | AWS resource availability per region |
| aws___list_regions | Retrieve a list of all AWS regions |
| aws___read_documentation | Fetch full AWS doc pages as markdown |
| aws___retrieve_skill | Retrieve an AWS skill (workflows, references) |
| aws___search_documentation | AWS docs search |
そして、ツールごとにドロップダウンが用意されています。選択肢は Let users choose、Always ask、Disabled の3つでした。
つまり、What's New で言及されている「ツールの個別な有効化・無効化」と「承認の要否設定」は、別々の設定項目ではなく、ツール単位の1つのドロップダウンに統合されています。
今回は挙動を確かめるため、以下のように設定しました。
aws___get_regional_availabilityを Disabledaws___list_regionsを Always ask- 残り3件は Let users choose のまま
設定を変更したツールには「Updated」バッジが付き、Disabled にしたツールは行全体がグレーアウトします。
ステップ5の Publish では共有範囲を指定します。組織全体への共有トグルはオフのまま、特定グループも指定せずにプライベートのまま Publish しました。
作成したコネクタを CLI で確認する
Publish 後、CLI からコネクタを確認します。
% aws quicksight list-action-connectors \
--aws-account-id 123456789012 \
--region ap-northeast-1 \
--query "ActionConnectorSummaries[?Name=='blog-verify-tool-settings']" \
--output json
[
{
"Arn": "arn:aws:quicksight:ap-northeast-1:123456789012:action-connector/7aaa19a8-7740-4aa0-bf18-f2a01cd5d6c6",
"ActionConnectorId": "7aaa19a8-7740-4aa0-bf18-f2a01cd5d6c6",
"Type": "MODEL_CONTEXT_PROTOCOL",
"Name": "blog-verify-tool-settings",
"CreatedTime": "2026-09-03T19:21:45.758000+09:00",
"LastUpdatedTime": "2026-09-03T19:24:19.513000+09:00",
"Status": "CREATION_SUCCESSFUL"
}
]
コンソールから作成したコネクタは identity region（今回は ap-northeast-1）なので、ap-northeast-1を指定しています。
Type が MODEL_CONTEXT_PROTOCOL として返ってきています。なお、この値は検証時点の botocore 1.43.65 が持つ ActionConnectorType の enum には含まれていませんでした。API 側が先行している状態で、CLI での参照には支障ありませんでした。
次に、詳細を取得します。
% aws quicksight describe-action-connector \
--aws-account-id 123456789012 \
--action-connector-id 7aaa19a8-7740-4aa0-bf18-f2a01cd5d6c6 \
--region ap-northeast-1 \
--output json
{
"Status": 200,
"ActionConnector": {
"Arn": "arn:aws:quicksight:ap-northeast-1:123456789012:action-connector/7aaa19a8-7740-4aa0-bf18-f2a01cd5d6c6",
"ActionConnectorId": "7aaa19a8-7740-4aa0-bf18-f2a01cd5d6c6",
"Type": "MODEL_CONTEXT_PROTOCOL",
"Name": "blog-verify-tool-settings",
"CreatedTime": "2026-09-03T19:21:45.758000+09:00",
"LastUpdatedTime": "2026-09-03T19:24:19.513000+09:00",
"Status": "CREATION_SUCCESSFUL",
"Description": "Blog verification connector for tool settings and MCP sync using AWS Knowledge MCP",
"AuthenticationConfig": {
"AuthenticationType": "NONE",
"AuthenticationMetadata": {
"NoneConnectionMetadata": {
"BaseEndpoint": "https://knowledge-mcp.global.api.aws/mcp"
}
}
},
"EnabledActions": [
"4a887df9-ea40-4d12-b97c-c733e3996793",
"798fed48-56fc-44de-8af8-ef9d1840860c",
"9d9f57cd-e6bc-452e-9ef7-6ee9590c7c03",
"bdf3b3dc-90a6-4a73-a54a-0aba9c42844d"
]
}
}
検出されたツールは5件でしたが、EnabledActions は4件です。Disabled にした aws___get_regional_availability が除外されていることが確認できました。
一方で、Always ask に設定した aws___list_regions は EnabledActions に含まれたままです。つまり EnabledActions は「有効か無効か」だけを表しており、承認の要否は現時点の API レスポンスからは判別できません。
コンソールのコネクタ詳細画面も、この結果と一致していました。Enabled tools に4件、Disabled tools に1件が分けて表示されます。
MCP sync を実行する
コネクタ詳細画面の右上に Sync ボタンが追加されています。押すと確認ダイアログが表示されました。
実行すると、ボタンが「Sync in progress」に変わり、左側の接続情報に Sync status という項目が追加されて Sync in progress と表示されます。
10秒ほどで Synced に変わりました。
注目したのは、Sync 後もツールの有効・無効設定が保持されていた点です。Enabled tools は4件、Disabled tools は1件のままで、無効化したツールが sync によって再び有効化されることはありませんでした。管理者が意図的に閉じたツールが、サーバー側の更新をきっかけに勝手に開くことはない、という挙動です。
Sync の実行前後で CLI からも状態を取得しましたが、Status、EnabledActions、LastUpdatedTime のいずれにも変化はありませんでした。
% aws quicksight describe-action-connector \
--aws-account-id 123456789012 \
--action-connector-id 7aaa19a8-7740-4aa0-bf18-f2a01cd5d6c6 \
--region ap-northeast-1 \
--query 'ActionConnector.{Status:Status,LastUpdated:LastUpdatedTime,Enabled:length(EnabledActions)}' \
--output json
{
"Status": "CREATION_SUCCESSFUL",
"LastUpdated": "2026-09-03T19:24:19.513000+09:00",
"Enabled": 4
}
今回は接続先が AWS Knowledge MCP Server で、こちら側からツールを追加・変更できないため、サーバー側の変更を sync が拾う様子までは確認できていません。Sync status という状態表示が API に露出していない点も含め、この機能の全容を確かめるには自前の MCP サーバーを用意する必要がありそうです。
ツール設定を後から変更する
コネクタ詳細画面の右上のメニューから「編集」を選ぶと、ステップが4つになったウィザードが開きます（Publish がなくなり、代わりに更新ボタンになります）。
ここで確認できたのは、編集で変更できる範囲が限られていることです。名前、説明、MCP サーバーエンドポイント、接続タイプはいずれもグレーアウトしており、画面にも「作成後は名前を変更できません」「作成後は説明を変更できません」と明記されています。編集できるのは認証設定とツール権限だけでした。
Manage Read Permissions のステップまで進めると、気になる挙動がありました。Disabled にした aws___get_regional_availability は Disabled のまま表示されている一方で、Always ask に設定したはずの aws___list_regions が Let users choose に戻って表示されています。
有効・無効の状態は保持されているものの、承認の要否は編集画面に読み戻されていません。これが保存自体されていないのか、画面が読み込んでいないだけなのかは、承認設定を確認する手段が他にないため切り分けられませんでした。いずれにしても、この画面でそのまま更新すれば Let users choose として保存されることになるため、承認を必須にしたツールがある場合は編集のたびに設定し直す必要があります。
続けて、逆方向の変更を行います。
aws___get_regional_availabilityを Disabled から Let users choose に戻すaws___search_documentationを Let users choose から Disabled に変更する
更新ボタンを押すと、確認ダイアログが表示されました。
Disable selected tools?
Existing Quick agents and services that use these tools may stop working.
ツールの無効化が、そのツールを使っている既存のエージェントやサービスに影響することを警告するものです。実際に無効化する前には、コネクタ詳細画面の「使用状況」タブで、どのエージェントやユーザーがそのコネクタを使っているかを確認しておくのが安全です。
更新後、CLI で差分を取ります。
$ aws quicksight describe-action-connector \
--aws-account-id 123456789012 \
--action-connector-id 7aaa19a8-7740-4aa0-bf18-f2a01cd5d6c6 \
--region ap-northeast-1 \
--query 'ActionConnector.EnabledActions' \
--output json
[
"37d3e56f-5044-4970-a19b-a04f2723b28c",
"798fed48-56fc-44de-8af8-ef9d1840860c",
"9d9f57cd-e6bc-452e-9ef7-6ee9590c7c03",
"bdf3b3dc-90a6-4a73-a54a-0aba9c42844d"
]
件数は4件のままですが、中身が入れ替わっています。無効化した aws___search_documentation の 4a887df9-ea40-4d12-b97c-c733e3996793 が消え、代わりに再度有効化した aws___get_regional_availability として 37d3e56f-5044-4970-a19b-a04f2723b28c が追加されました。LastUpdatedTime も 19:24:19 から 19:30:00 に更新されています。
コンソール側の表示も入れ替わっています。
ここで気をつけたいのは、再度有効化したツールに払い出された ActionId が、無効化する前とは異なる値になっている点です。ActionId を固定の識別子として扱う運用は避けたほうがよさそうです。
テストアクション API でツールを実行してみる
コネクタ詳細画面の Enabled tools セクションには「テストアクション API」というボタンがあります。登録されたアクションを個別に実行して、接続が正しく機能しているかを確認するための機能です。
この画面でアクションを選ぶと、そのスキーマが表示されます。再度有効化した aws___get_regional_availability を選ぶと、id として 37d3e56f-5044-4970-a19b-a04f2723b28c が表示されました。CLI の EnabledActions に新しく現れた UUID と一致しており、ここでツール名と ID を突き合わせられます。
アクションのドロップダウンに並ぶのは Enabled tools の4件だけで、無効化した aws___search_documentation は選択肢に現れませんでした。
method が read になっている点にも触れておきます。Manage Read Permissions と Manage Write Permissions のどちらに分類されるかは、この値で決まっていると考えられます。
ダメ元で aws___list_regions を Submit してみたところ、以下のエラーが返されました。
{
"InvokeActionError": {
"requestError": {
"mcpInvokeActionError": {
"content": [
{
"textContent": {
"text": "Primary CALL_TOOL operation failed for endpoint: https://knowledge-mcp.global.api.aws/mcp. Error: MCP session with server terminated"
}
}
]
}
}
},
"InvokeActionResponseMetadata": {
"ExternalLatency": 766
},
"InvokeActionStatus": "ERROR",
"RequestId": "4eb89679-5343-46f2-9938-5d3c1828c37e"
}
Quick 側の問題かどうかを切り分けるため、MCP サーバーへ直接リクエストを送って確認します。
curl -s -D - -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":"verify","version":"1.0"}}}'
HTTP/2 200
content-type: application/json
mcp-session-id: 0a4ae2ce-a7b4-44ca-bc35-b8c8af31478d
{"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2025-03-26","capabilities":{"tools":{"listChanged":false}},"serverInfo":{"name":"AWSKnowledgeMCP","version":"1.0.0"}}}
初期化は成功し、セッション ID も払い出されます。同じセッションで tools/list を実行すると、こちらも5件のツール一覧が問題なく返ってきました。
ところが tools/call だけは、セッション ID の有無やツールの種類、MCP-Protocol-Version ヘッダーの有無を変えても、一貫して以下が返ります。
{"success":false,"error":"Http operation is not supported for gateway protocol type MCP"}
JSON-RPC の形式ですらないエラーが返っており、これは MCP サーバー側の応答です。Quick が返した「MCP session with server terminated」は、この想定外の応答を受けてセッション異常と判断した結果と考えられます。つまり今回のテスト実行の失敗は、接続先の MCP サーバー側の事情によるもので、ツール設定や MCP sync の機能そのものの問題ではありません。
ツールの検出（tools/list）は成功していたため、コネクタ作成とツール設定の検証には影響しませんでした。
考察
今回の検証で確認できたことを整理します。
ツールの有効・無効は API から確認できる
DescribeActionConnector の EnabledActions を見れば、そのコネクタで実際に使えるツールが分かります。ツール数が多いコネクタを棚卸しする場面や、意図しないツールが有効になっていないかを定期的に点検する用途では、この値を起点にできます。
承認の要否は確認する手段がない
Always ask と Let users choose の区別は EnabledActions に現れません。それだけでなく、編集画面を開き直しても Always ask は Let users choose として表示されました。承認を必須にしたつもりのツールが本当にその設定になっているかを、管理者が後から確かめる手段が現時点では見当たりません。ガバナンス設定として使うのであれば、この点は今後の改善を待ちたいところです。
ツール設定と MCP sync は現時点でコンソール専用
CreateActionConnector と UpdateActionConnector の入力パラメータを確認しましたが、ツール設定や MCP sync に相当するものはありませんでした。コネクタの作成そのものは CLI や SDK から可能ですが、どのツールを開くかという最も運用に関わる部分は、現時点ではコンソール操作が前提になります。複数アカウントへ同じ設定を展開したい場合は、しばらく手作業が必要です。
ActionId は不変ではない
無効化したツールを再度有効化すると、別の ActionId が払い出されました。EnabledActions の値を構成管理の対象として保存し、差分を検知するような仕組みを作る場合、ID の変化を「ツールが入れ替わった」と誤検知しないよう注意が必要です。ツール名との対応は、テストアクション API の画面か、MCP サーバー側の tools/list から確認できます。
Sync はツールの有効・無効を上書きしない
管理者が閉じたツールが sync で勝手に開くことはありませんでした。MCP サーバー側の更新に追随しつつ、管理者の判断は維持されるという設計です。ただし、サーバー側に新しいツールが追加された場合にそれがどう扱われるか（既定で無効なのか、defaults に従うのか）までは、今回の環境では確認できていません。
ドキュメントはまだ追随していない
検証時点では、公式ドキュメントの統合ワークフローや MCP 統合のページに、今回追加されたツール設定や MCP sync に関する記述は見当たりませんでした。ウィザードのステップ数も含めて、実際の画面が先行している状態です。
今後に期待したい点としては、ツール設定と MCP sync の API・CLI 対応、承認設定の参照手段、そして MCP sync のスケジュール実行あたりが挙げられます。
最後に
MCP サーバーを1つ接続すれば、そのサーバーが持つツールがまとめて登録されます。便利な一方で、外部サービスに対して書き込みを行うツールまで含まれている場合、そのすべてを無条件にエンドユーザーへ公開してよいかは別の判断になります。今回のツール設定は、その判断をツール単位で行えるようにするものです。
読み取りと書き込みでステップが分かれているのも、実務的だと感じました。読み取りは Let users choose、書き込みは Always ask といった具合に、リスクに応じた既定値を分けて設定できます。
MCP sync については、管理者が設定したツールの有効・無効が維持されることを確認できました。外部の MCP サーバーは自分たちの管理外で更新されていくものなので、追随の仕組みがありつつ、こちらの判断が勝手に覆らないという挙動は安心して使えます。一方で、承認の要否については後から確認する手段がなく、編集操作のたびに設定し直しが必要になる可能性がある点は、運用に組み込む前に把握しておきたいところです。
コネクタごとのアクセス制御という観点では、カスタム権限でコネクタに対する「Create and Update action」「Share action」「Use action」の3種類を制限することもできます。ツール単位の設定と組み合わせて、誰がどのツールをどう使えるかを設計していくことになりそうです。
MCP サーバーを Quick に接続して運用している方は、まず既存コネクタの Enabled tools を一度確認してみることをおすすめします。この記事がどなたかのお役に立てば幸いです。
