3行まとめ
EC2、Fargate、AWS AgentCoreなどに置いたMCP serverを、VPC connection経由でQuickへつなぐ選択肢が増えました。
MCP integrationはserver toolsをQuick内のactionsとして使う仕組みで、社内文書を索引化するKnowledge baseとは目的が違います。
東京リージョン、Enterprise subscription、subnet、security group、DNS、OAuth endpoint、60秒timeout、料金をまとめて確認します。
判断の起点は「社内APIやtoolを実行させたいのか」「社内文書を検索させたいのか」を分けることです。
- AWSは2026年6月1日、Amazon QuickでMCP接続のVPC connectivity対応を発表しました。企業はEC2、AWS Fargate、AWS AgentCoreなどの私有ネットワーク上に置いたMCPサーバーを、公開インターネットへ直接出さずにQuickへつなげるようになった、という位置づけです。
- ただし、MCP integrationは社内文書を索引化するKnowledge baseではなく、MCP server toolsをQuick内のactionとして使う仕組みです。公式ドキュメントにはKnowledge baseのVPC非対応注記もあるため、対象機能を分けて読まないと判断を誤ります。
- 日本で試す場合は、Quick Enterprise subscription、VPC connection、subnet、security group、DNS resolver endpoints、OAuth endpointの公開要件、60秒timeout、東京リージョンとcross-Region inference、料金ページをまとめて確認する必要があります。
AWS News BlogのWeekly Roundupでもこの更新が取り上げられました。需要シグナルとしては、Amazon Quick本体の東京リージョン提供、デスクトップAIアシスタント化、MCPを使った社内ツール連携への関心が重なっています。この記事では反応そのものではなく、公式一次情報から「企業が社内MCPサーバーをQuickへつなぐ前に見る表」を作ることに絞ります。
Amazon Watch JapanはAmazonおよび関係会社とは非提携です。この記事は投資助言ではなく、公開されているAWS公式情報を利用者・導入担当者目線で整理したものです。
Amazon QuickのMCP向けVPC接続で何ができるようになったのか
- 1MCP serverを私有ネットワークに置く
社内API、独自ツール、専用データソースをMCP serverとしてEC2、Fargate、AWS AgentCoreなどで動かします。
- 2VPC connectionを選ぶ
MCP connector作成時にVPC connectionとMCP server URLを指定し、公開インターネットへ直接出さない構成を取りやすくします。
- 3toolsをactionsとして使う
Quick内の会話から、MCP serverが公開するtoolsをAI assistantのactionsとして呼び出せるようになります。
- 4権限と監査を設計する
readonlyとwriteを分け、tool description、失敗時の戻し方、操作ログを導入前に決めます。
社内ツールをQuickへ渡しやすくなる一方、どのtoolを公開するかはMCP server側の設計に依存します。
AWSの発表を実務目線で読むと、変化はかなり明確です。これまでAmazon QuickのMCP supportは、公開インターネットから到達できるthird-party hosted serversに限られていました。今回の更新で、企業が自社のVPCや私有ネットワーク内に置いたMCP serversをQuickへつなぐ選択肢が増えました。
公式発表では、MCP serversをAmazon EC2、AWS Fargate、AWS AgentCore、またはprivate network内の他のcompute上で動かし、MCP connector作成時にVPC connectionとMCP server URLを指定すると説明されています。接続後は、チームがQuick内の自然言語会話からprivate MCP serversを使えるようになります。
2026年6月1日の発表で確認できること
確認できる主な事実は3つです。
| 確認項目 | 公式情報で確認できること | 導入前の見方 |
|---|---|---|
| 対象 | privately hosted Model Context Protocol servers | 社内API、独自ツール、専用データソースをMCP server化する話 |
| 接続経路 | Amazon VPC経由 | 公開インターネットへMCP serverを直接出さない構成を取りやすい |
| 実行環境 | EC2、Fargate、AWS AgentCore、その他private network内のcompute | 既存運用基盤に合わせてMCP serverの置き場所を決める |
| 利用者体験 | Quick内の自然言語でprivate MCP serversを使う | AI assistantがactionを呼び出す前提で権限と監査を見る |
| 提供範囲 | Amazon Quickが利用可能なAWS Regions | 東京リージョンを含むかはQuickのリージョン表で確認する |
この更新は、単に「QuickがVPCに対応した」というより、社内に閉じたMCP server toolsをQuickのAI assistantへ渡しやすくなった、というニュースです。社内のチケット管理、運用API、在庫照会、申請ワークフロー、独自の調査ツールをMCP serverとして用意している企業にとって、公開URLだけが入口になる状態より試しやすくなります。
根拠
AWS What's Newは、今回の更新を「Amazon Quick now supports VPC connectivity for MCP connections」として2026年6月1日に掲載しました。AWS Weekly Roundupの2026年6月8日版でも、private MCP serversをVPC経由でQuickへ接続し、proprietary applicationsやinternal toolsへ安全にアクセスできる更新として取り上げられています。
社内ツールをAIアシスタントにつなぐ時の意味
MCPは、AI applicationsがexternal toolsやdata sourcesと通信するためのopen standardです。Amazon QuickのMCP integrationでは、MCP serverが公開するtoolsがQuick内のactionsとして登録されます。たとえば、MCP serverがプロジェクト管理システムのissue検索やticket作成を提供していれば、Quickの会話中にAI assistantがそのactionを呼び出せます。
ここで大切なのは、Quickが勝手に社内ツールを理解してくれるわけではないことです。MCP server側でどのtoolを公開するか、tool descriptionをどう書くか、read-onlyとwriteをどう分けるか、失敗時にどう戻すかを設計する必要があります。
上振れ
うまく設計できれば、問い合わせ、障害調査、社内申請、在庫確認、手順の初動が短くなります。利用者は「この案件の関連issueを探して」「このテンプレートで申請を作って」「この環境の状態を確認して」のように自然言語で始められます。
下振れ
一方で、tool設計が粗いと危険です。更新系actionが広すぎる、承認なしで書き換えられる、ログが残らない、60秒timeoutに収まらない、失敗時のrollbackがない。こうした状態でQuickから呼べるようにすると、便利さより先に運用リスクが大きくなります。
Public networkで足りる場合とVPC connectionが必要な場合
すべてのMCP serverにVPC connectionが必要なわけではありません。公開インターネット上に置けるSaaS型MCP serverで、認証、IP制限、監査、可用性を満たせるならPublic network接続で足りる場合があります。
VPC connectionを検討すべきなのは、次のようなケースです。
| 判断軸 | Public networkで足りる可能性 | VPC connectionを見たいケース |
|---|---|---|
| サーバーの置き場所 | SaaS側が管理するMCP server | 自社VPC、社内API、オンプレミス接続先 |
| データ分類 | 公開APIや低リスク情報 | proprietary applications、内部業務データ |
| 到達性 | HTTPS公開URLでよい | private hostname、PrivateLink、VPN、Direct Connectを使う |
| 認証 | 標準OAuthで完結する | 社内IdP、service account、独自認可が絡む |
| 監査 | SaaS側ログで足りる | AWS側、MCP server側、Quick側のログ突合が必要 |
| 運用責任 | 外部サービス側が多く担う | 自社のネットワーク、IAM、DNS、セキュリティが担う |
最初の問いは「VPCを使えるか」ではありません。「Quickにどのactionを実行させるのか」「そのactionはどのネットワーク境界の中に置くべきか」です。
MCP integrationはKnowledge baseではなくAction connectorとして読む
今回の発表はMCP connections、つまりaction connector側のVPC対応として読むのが安全です。
今回もっとも混乱しやすいのは、MCP integration、Action connector、Data access integration、Knowledge baseの違いです。名称が似ていても、導入判断はかなり変わります。
MCP server toolsはQuick内のactionsになる
Amazon QuickのMCP integrationは、MCP server toolsをactionsとして登録する仕組みです。QuickのAI assistantは、会話の中でそれらのactionsを呼び出せます。公式ドキュメントは、PKCE S256やResource Indicatorsを使ってaccess tokenを特定のMCP serverに結び付けることも説明しています。
本文で見るべきポイントは、MCPが「実行」の入口であることです。ticketを作る、statusを更新する、APIを呼ぶ、データベースに問い合わせる。こうした動作をQuickに渡すなら、MCP integrationの話になります。
根拠
Amazon Quick User GuideのMCP integrationページは、MCP server toolsがAmazon Quickのactionsとして登録されると説明しています。MCP server endpoint、認証情報、Amazon Quick Enterprise subscriptionが事前条件として示されている点も、企業向けの管理対象として読むべきところです。
Data access integrationとKnowledge baseは索引化・参照の話
Data access integrationsは、外部データソースへの安全な接続を作り、Knowledge baseを作るための基礎になる仕組みです。公式ドキュメントは、data access integration単体ではanalysisやAI agentsに使えず、Knowledge baseを作る必要があると説明しています。
つまり、目的が「社内文書を読ませたい」「ConfluenceやSharePointやS3の文書を検索させたい」なら、まずData access integrationとKnowledge baseの文脈で見ます。目的が「社内APIを実行させたい」「ticketを作らせたい」「運用toolを呼び出させたい」なら、MCP/action connectorの文脈です。
注意点
公式ドキュメントには、Knowledge basesはVPC connectivityをサポートせず、データソースはpublic internetから到達できる必要がある、という注記があります。一方で、Action connectorsはVPC内のresource serversに対するVPC connectivityをサポートします。ただしauthentication serversはpublicly accessibleである必要があります。
ここを混ぜると、「MCPのVPC接続は非対応なのか」と誤読しやすくなります。今回の発表はMCP connections、つまりaction connector側のVPC対応です。Knowledge baseのVPC非対応注記とは対象が違います。
読者が選ぶべき入口
| やりたいこと | 見るべき入口 | VPCの見方 | 主な注意点 |
|---|---|---|---|
| 社内APIを呼び出す | MCP integration / Action connector | resource server側にVPC connectivityを使える | OAuth endpointsは公開到達が必要 |
| ticketや申請を作る | MCP integration / Action connector | 書き込みactionの権限を絞る | 承認、監査、rollbackが必要 |
| 社内文書を検索する | Data access integration / Knowledge base | Knowledge baseはVPC connectivity非対応 | データソースはpublic internet到達が必要 |
| BIやdashboardを扱う | Amazon Quick Sight系機能 | QuickのVPC connection手順を確認 | Quick Sight表記とQuick表記の混在に注意 |
| AI agentに業務を任せる | Quick actions、Flows、AgentCoreなど | action単位で境界を設計 | 実行権限と監査の責任が増える |
Quickを導入する側では、まず目的を「実行」「検索」「分析」に分けてください。MCP VPC対応は、あくまで実行系actionを私有ネットワーク内のMCP serverにつなぎやすくする更新です。
VPC connectionを作る前に見るネットワークチェック
VPC IDは作成後に変更できないため、検証用の接続を本番相当に流用しない前提で設計します。
VPC connectionは、AWS管理者とネットワーク担当を巻き込む作業です。Quickの画面から作れるとしても、裏側ではIAM role、elastic network interfaces、subnet、security group、DNS、route table、NACLが関係します。
Quick側のVPC connectionはEnterprise管理者の作業
Amazon QuickのVPC connection作成手順は、Quick Enterprise editionを前提に、Amazon Quick adminまたはsystem administrator向けに説明されています。管理者には、VPC connectionsの作成、更新、削除、表示の権限や、subnet、VPC、security groupを参照するEC2権限、execution roleへのiam:PassRoleが必要です。
また、VPC connection用のexecution roleは、Amazon QuickがVPC connectionを設定するために使います。最低限、EC2のnetwork interfaceを作成、変更、削除し、subnetやsecurity groupを参照できる権限が必要です。
条件
VPC IDは作成後に変更できないと説明されています。検証用に急いで作ったVPC connectionを、そのまま本番相当に流用するのは避けたいところです。少なくとも2つのAvailability Zonesからsubnetを選ぶ手順もあるため、単一AZだけの簡易構成で判断しないほうがよいです。
通信経路はQuickのelastic network interfacesから始まる
VPC connectionを作ると、Amazon Quickは対象VPC内にelastic network interfacesを追加します。そのnetwork interfacesが、VPC内のMCP serverや内部リソースと通信する入口になります。Route tables、network ACLs、subnets、security groupsは、通常のVPC内通信と同じように効きます。
接続前に、少なくとも次を確認します。
| 項目 | 確認する人 | 見ること |
|---|---|---|
| VPC ID | AWS管理者 | 本当にMCP serverへ到達するVPCか |
| Subnet | ネットワーク担当 | 2つ以上のAZ、route table、NACL |
| Security group | セキュリティ担当 | Quick側ENIからMCP server portへ到達できるか |
| MCP server URL | 開発チーム | HTTPS、hostname、path、port |
| TLS証明書 | 開発チーム | Quickから検証できる証明書か |
| DNS resolver endpoints | ネットワーク担当 | private hostnameやオンプレミスDNSを解決できるか |
| ログ | 運用担当 | Quick、MCP server、VPC Flow Logs、CloudTrailをどう突合するか |
確認項目
最初の疎通は、いきなり更新系toolで試さないほうがよいです。health check、tool list、read-only query、認証付きread-only query、少人数共有、write actionの順で広げると、原因切り分けがしやすくなります。
DNS resolver endpointsを見落とさない
private hostnameやRoute 53 private hosted zone、オンプレミスDNSを使う場合、DNSが詰まりやすいです。VPC connection作成手順では、private DNS serversで解決が必要な場合にRoute 53 Resolver inbound endpointsのIP addressesを入力する説明があります。
MCP integration側でも、VPC connectionがdropdownに出るだけでは十分ではありません。QuickがMCP serverのhostnameを解決できなければ、connector作成時点で失敗します。PrivateLink、VPC peering、Transit Gateway、VPN、Direct Connectを絡めるほど、名前解決はネットワーク経路と同じくらい重要になります。
注意点
「VPC内からなら名前解決できる」は、Quickからも解決できるという意味ではありません。Quickが使うVPC connection、subnet、resolver endpoints、security groupの視点で確認します。
作成直後に選べても、利用可能とは限らない
VPC connectionは、作成直後にUNAVAILABLEとなり、バックエンド設定が終わるとAVAILABLEになる場合があります。QuickのMCP integrationでVPC connectionを選べたとしても、状態がAVAILABLEになる前に作成を進めると失敗する可能性があります。
評価基準
PoCでは、次の順で確認します。
- VPC connectionが
AVAILABLEである。 - MCP serverのhostnameを解決できる。
- TLS handshakeが通る。
- 認証なしまたはservice authenticationの最小接続が通る。
- OAuthが必要ならauthorization endpoint、token endpoint、redirect URLを確認する。
- 60秒以内に終わるread-only toolを呼び出す。
- 失敗時にMCP server側、Quick側、ネットワーク側のどこへログが出るか確認する。
認証と権限はどこまで公開が必要か
- 1OAuth discoveryを確認する
Protected Resource Metadataでauthorization server情報を発見できるかを確認します。
- 2DCR対応を確認する
Dynamic Client Registrationに対応していれば自動登録、非対応ならclient IDやclient secretを手動で用意します。
- 3認証方式を選ぶ
User authentication、Service authentication、No authenticationのどれを使うかをtoolのリスクで分けます。
- 4OAuth endpointsの到達性を見る
resource serverをVPC内に置けても、authentication serversはpublicly accessibleである必要があります。
- 5制約を運用へ落とす
60秒timeout、custom HTTP headers非対応、tool listの静的登録、retryなしの失敗を前提に設計します。
「MCP serverを公開しない」と「認証エンドポイントもすべて非公開にできる」は別の確認事項です。
VPC connectionができても、認証設計は別問題です。特にOAuthを使う場合、MCP server本体をprivate networkに置けても、authorization serverやtoken endpointをどう扱うかが導入の詰まりどころになります。
MCP server認証はOAuth discoveryとDCRを前提に読む
Amazon QuickはMCP serverへ接続する際、OAuth 2.0 Protected Resource Metadataでauthorization server情報を発見すると説明されています。Dynamic Client Registrationに対応しているauthorization serverなら、Quickが自動登録できます。対応していない場合は、client ID、client secret、token URL、authorization URL、redirect URLなどを手動で用意します。
認証方法は大きく3つです。
| 認証方法 | 使いどころ | 導入前に用意するもの |
|---|---|---|
| User authentication (OAuth) | ユーザー単位の権限でtoolを使わせたい | client ID、client secret、authorization URL、token URL、redirect URL |
| Service authentication | チームやサービス単位で同じ権限を使う | service client ID、client secret、token URL |
| No authentication | 認証不要の検証用や低リスクtool | 本当に認証不要でよい理由とネットワーク制限 |
根拠
User Guideは、DCRがある場合の自動登録と、DCRがない場合に手動でcredentialを用意する流れを説明しています。導入前に見るべきなのは、OAuth用語の細部よりも、誰がclientを登録し、redirect URLを許可し、scopeを管理し、失効時の運用を持つかです。
私有MCPサーバーでもOAuth endpointsは公開到達が必要
Data access integrationsの公式ドキュメントは、Action connectorsはVPC内のresource servers向けにVPC connectivityをサポートする一方で、authentication serversはpublicly accessibleである必要があると説明しています。
これは実務上かなり重要です。MCP server本体をVPC内に置いても、OAuth providerまで完全にprivate network内へ閉じられるとは限りません。社内IdPが外部から到達できない、token endpointを公開できない、redirect URLの登録を厳格に制限している。そういう組織では、VPC接続より先に認証設計が課題になります。
注意点
「社内MCPサーバーをインターネットへ公開しなくてよい」と、「認証エンドポイントも全部非公開にできる」は別です。記事タイトルの便利さだけを見てPoCに入ると、認証レビューで止まる可能性があります。
Tool list、timeout、headersの制約を運用に落とす
MCP integrationには制限があります。公式ドキュメントでは、MCP operationsの固定60秒timeout、custom HTTP headers非対応、tool listが初回登録後に静的であること、server-side tool changesを反映するにはintegrationの削除と再作成が必要なこと、server connectivity issuesではretryなしで即時失敗することなどが示されています。
確認項目
| 制限 | 影響 | 設計で見ること |
|---|---|---|
| 60秒timeout | 長い処理は失敗しやすい | 非同期job化、status確認tool、結果取得toolに分ける |
| custom HTTP headers非対応 | 独自header認証に頼れない | OAuthやservice authenticationへ寄せる |
| tool listが静的 | server側でtoolを追加しても自動反映されない | 変更時のintegration再作成手順を決める |
| retryなし | 一時的なserver failureで失敗する | MCP server側の冪等性、再実行方法、ログIDを整える |
| step-up authorization非対応 | 後から追加scopeを求められない | 初期scope設計と再認可手順を決める |
AI assistantから呼ばれるtoolは、人間がCLIで実行するtoolよりも説明と制約が重要です。tool名、説明、入力schema、失敗時のmessage、監査IDを丁寧に作るほど、Quick側で誤った使われ方を減らせます。
日本導入で確認するリージョン、料金、プラン
サービス提供リージョンだけでは、認証エンドポイントの場所、ログ保存、社内規程上の扱いまでは決まりません。
Amazon Quickは2026年3月25日にAsia Pacific (Tokyo) regionで利用可能になったと発表されています。今回のMCP向けVPC supportは、Amazon Quickが利用可能なAWS Regionsで利用可能と説明されています。日本の読者にとっては、東京リージョン、Amazon Q in Quick、cross-Region inference、料金、契約条件を分けて読む必要があります。
東京リージョン提供とMCP VPC対応の読み方
東京リージョン発表では、Amazon Quickがap-northeast-1で利用可能になり、日本のdata sovereignty要件に対応しやすくなると説明されています。また、QuickのRegionsページではAsia Pacific (Tokyo)がAmazon Quickのsupported Regionsに含まれています。
ただし、リージョン表は一枚で読み切れません。Amazon Quick本体の利用可能リージョン、Amazon Q in Quickの対応、cross-Region inference、web searchの処理リージョンが分かれて記載されています。日本で使う場合は、入力promptやoutputがどのgeography内で処理されるか、CloudTrailやCloudWatchでinference regionが見えるか、社内規程でどう扱うかを別に確認します。
条件
Quick東京リージョンの提供は、日本導入の追い風です。それでも、社内MCPサーバーが東京VPCにあるか、認証エンドポイントがどこにあるか、MCP server logsとQuick側の操作ログをどう保存するかは、サービス提供リージョンだけでは決まりません。
MCP integrationにはQuick Enterprise subscriptionが必要
MCP integrationのUser Guideは、事前条件としてAmazon Quick Enterprise subscriptionを挙げています。個人向けのFree/Plusやデスクトップアプリの話と混同しないほうがよいです。
Quick本体の料金やローカル保存、フォルダ権限、デスクトップアプリの扱いは、公開済みの<a href="https://amzn-watch.blog.mo-gmo.com/amzn-32-amazon-quick-desktop-ai-assistant/" rel="noopener">Amazon Quickデスクトップアプリの記事</a>で整理しています。今回の記事では、企業向けMCP接続に必要な契約、管理者権限、VPC connectionを中心に見ます。
注意点
「Quickを無料で試せる」と「MCP integrationを社内VPCへつなげる」は同じではありません。PoCを始める前に、契約形態、管理者、請求責任者、検証ユーザー数、trial終了日を決めてください。
料金はQuick本体、インフラ費、追加機能を分ける
Amazon Quick pricingページには、Free/Plus、Professional/Enterprise、30日trial、infrastructure fee、BI機能の追加費用が示されています。2026年6月13日時点では、Professional/Enterprise向けに月250ドル/accountのinfrastructure feeが説明され、30日trialでは最大25 usersのsubscription feeと250ドルのinfrastructure feeが免除される旨が掲載されています。
MCP VPC接続を試す場合は、Quick本体のsubscriptionだけではなく、周辺費用も見ます。
| 費用・工数 | 見ること |
|---|---|
| Quick subscription | Professional/Enterprise、trial条件、ユーザー数 |
| Infrastructure fee | account単位の費用、trial後の扱い |
| MCP server実行費 | EC2、Fargate、AgentCore、ALB/NLB、CloudWatch Logs |
| VPC関連費 | PrivateLink、NAT、Resolver endpoints、VPN、Direct Connectが関係する場合 |
| 運用工数 | セキュリティレビュー、IdP設定、tool変更時の再作成、監査ログ確認 |
| 失敗時対応 | rollback、再実行、権限取り消し、利用者への通知 |
評価基準
PoCでは、ユーザー数とtool数を絞るほど費用とリスクを説明しやすくなります。最初から全社の社内APIをMCP化するのではなく、1チーム、1つのread-only MCP server、1つのVPC connection、明確なログ保管から始めるのが現実的です。
ドキュメント内のVPC非対応注記をどう読み分けるか
- What's New
2026年6月1日の発表で、Amazon QuickがMCP connections向けVPC connectivityに対応したことを確認します。
- Weekly Roundup
2026年6月8日版で、private MCP serversをVPC経由でQuickへ接続する更新として取り上げられています。
- Data access integrations
Knowledge basesはVPC connectivity非対応、Action connectorsはVPC内resource servers向けにVPC connectivity対応と分けて読みます。
- MCP integrationページ
残っている非対応注記は、公開前や導入前にAWSコンソール、User Guide、AWS Supportまたは担当者で再確認します。
- VPC connection手順
Quick Sight表記や権限名を含め、実際のAWSコンソールと公式ドキュメントで同じ日に確認します。
公式資料同士に表記差があるときは、MCP/action connectorとKnowledge baseを分け、導入日に同じ条件で確認します。
Amazon Quickの公式ドキュメントには、今回の記事で扱ううえで注意したい表記があります。MCP integrationページには、古い可能性のある「VPC connectivity are not supported」という注記が見えます。一方で、2026年6月1日のWhat's NewはMCP connectionsのVPC connectivity対応を明確に発表しています。Data access integrationsページでは、Knowledge basesはVPC connectivity非対応、Action connectorsはVPC内resource serversへのVPC connectivity対応と整理されています。
こういう状態では、発表だけを見ても、ドキュメントの一文だけを見ても危険です。対象機能を分けて、公開直前に同じ日付で確認する必要があります。
非対応注記はKnowledge base側の話として扱う
まず確実に分けたいのは、Knowledge baseとAction connectorです。Data access integrationsページは、Knowledge basesはpublic internetから到達できるdata sourceが必要で、VPC connectivityをサポートしないと説明しています。同じページで、Action connectorsはVPC内resource serversへのVPC connectivityをサポートし、authentication serversはpublic accessibleである必要があるとも説明しています。
今回のMCP向けVPC接続は、Action connector側の話です。社内文書をKnowledge base化したい読者は、今回の発表をそのまま「Knowledge baseもVPC内データソースを読めるようになった」と解釈しないでください。
根拠
AWS What's New、AWS Weekly Roundup、MCP integration、Data access integrations、VPC connection手順のページを横断すると、MCP/action connectorとKnowledge baseを分けて読むのが安全です。
MCP integrationページの注記は公開前に再確認する
2026年6月13日に確認したMCP integrationページには、local stdio connectionsとVPC connectivityはnot supportedという注記が残っています。これは2026年6月1日のWhat's Newと緊張関係があります。新機能発表直後にドキュメント更新が追いついていない可能性もありますが、読者側で本番導入前にAWSコンソール、User Guide、AWS Supportまたは担当者確認を入れるべき箇所です。
この記事では、What's NewとWeekly Roundupで確認できる新発表を採用しつつ、User Guide内の注記を「公開前・導入前の再確認点」として扱います。断定的に「すべてのMCP構成でVPCが使える」とは書きません。
注意点
公式資料同士に表記差があるときは、記事側で都合よく片方を消さないほうがよいです。読者が実際に導入する時は、対象リージョン、契約プラン、consoleで表示されるMCP connector作成画面、VPC connectionの選択肢、認証方式を同じ日に確認してください。
Quick Sightという表記に引っ張られすぎない
VPC connection関連ドキュメントには、Amazon Quick Sightの表記が残っています。Amazon QuickがQuick Sightを含む形で拡張されているため、用語が混ざって見える箇所があります。
本文では、Quick Enterpriseで使うVPC connection手順として扱います。ただし、UI名や権限名、quicksight:* permissionの表記は、実際のAWSコンソールと公式ドキュメントで再確認する前提です。
確認項目
公開後も追うべき項目は次の通りです。
| 確認するページ | 見ること |
|---|---|
| What's New | MCP VPC対応の提供範囲、更新日 |
| MCP integration User Guide | VPC connection選択、認証、制限 |
| Data access integrations | Action connectorとKnowledge baseの違い |
| VPC connection guide | IAM、subnet、security group、DNS |
| Pricing | trial、subscription、infrastructure fee |
| Regions | 東京リージョン、Q in Quick、cross-Region inference |
導入前チェックリスト
Quick Enterprise subscription、VPC内MCP server、readonly tool、公開到達可能なOAuth endpoints、作成権限、ログ責任者がそろっている状態です。
複数VPC、複数アカウント、オンプレミス、private IdP、書き込みや削除を伴うtoolがある場合は先に設計レビューを行います。
status確認、検索、一覧取得のようなreadonly toolから始め、非本番データと少人数で価値を確認します。
timeout、認証失敗、権限過多、ログ不足、ドキュメント表記差が出た場合に、誰が判断して止めるかを決めます。
最初の評価基準は、短いtimeoutと明確なログの中で、readonly toolだけでも業務価値が見えるかどうかです。
最後に、今回の更新をすぐ試すべきケース、設計してからPoCすべきケース、今は待ったほうがよいケースに分けます。
すぐPoCしやすいケース
すぐ小さく試しやすいのは、次の条件がそろっている場合です。
| 条件 | 理由 |
|---|---|
| Quick Enterprise subscriptionがある | MCP integrationの前提を満たしやすい |
| MCP serverがVPC内で稼働済み | 新規にネットワークを作る範囲が小さい |
| read-only toolから始められる | 誤操作の影響を抑えやすい |
| OAuth endpointsを公開到達可能にできる | 認証で詰まりにくい |
| VPC connection作成権限がある | PoCを自走しやすい |
| ログと責任者が決まっている | 失敗時の切り分けがしやすい |
評価基準
最初のtoolは、status確認、検索、一覧取得のようなread-onlyにします。非本番データ、少人数、明確な利用ログ、短いtimeoutで価値が出るかを見るのがよいです。
設計してからPoCすべきケース
次の条件がある場合は、ネットワークを先に通すより、設計レビューを挟むほうが安全です。
- MCP serverが複数VPC、複数アカウント、オンプレミスへまたがる。
- 社内IdPがprivate network内に閉じていて、OAuth endpointsを公開できない。
- toolが書き込み、削除、承認、金銭、顧客情報に触れる。
- 処理が60秒を超えやすい。
- tool追加や変更のたびにintegration再作成が必要な運用をまだ決めていない。
- ログ、監査、利用者教育、緊急停止手順がない。
注意点
VPC connectionは、セキュリティ設計の代わりではありません。ネットワーク境界を作れても、AI assistantに実行させるactionの権限が広すぎればリスクは残ります。
今は待った方がよいケース
次の目的なら、今回の発表だけで進めるのは早いです。
| 待つべき理由 | 何を確認するか |
|---|---|
| Knowledge baseのVPC接続を期待している | 公式にはKnowledge basesはVPC connectivity非対応と説明されている |
| 個人向けQuickで社内MCPを使いたい | MCP integrationはEnterprise subscription前提 |
| 認証サーバーを公開できない | OAuth endpointsの公開到達要件を確認する |
| 長時間処理が中心 | 60秒timeoutを避ける非同期設計が必要 |
| 料金・リージョン承認が未完了 | Pricing、Regions、data residency、契約を確認する |
確認項目
最終的には、次の5問に答えられる状態でPoCに入るのが理想です。
- Quickに実行させるactionは何か。
- そのactionはread-onlyか、writeを含むか。
- MCP server本体と認証サーバーは、それぞれどこから到達できる必要があるか。
- 失敗、誤実行、timeout、tool変更時に誰が対応するか。
- 料金、リージョン、ログ、データ所在地を誰が承認したか。
次に読むなら
参照した主な情報源
- AWS What's New, "Amazon Quick now supports VPC connectivity for MCP connections", 2026年6月13日確認
https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-quick-vpc-mcp/
- AWS News Blog, "AWS Weekly Roundup: BYOM for Amazon RDS for SQL Server, AWS IoT Device SDK for Swift, and more (June 8, 2026)", 2026年6月13日確認
https://aws.amazon.com/blogs/aws/aws-weekly-roundup-byom-for-amazon-rds-for-sql-server-aws-iot-device-sdk-for-swift-and-more-june-8-2026/
- Amazon Quick User Guide, "Model Context Protocol (MCP) integration", 2026年6月13日確認
https://docs.aws.amazon.com/quick/latest/userguide/mcp-integration.html
- Amazon Quick User Guide, "Data access integrations", 2026年6月13日確認
https://docs.aws.amazon.com/quick/latest/userguide/data-access-integrations.html
- Amazon Quick User Guide, "Configuring the VPC connection in the Amazon Quick console", 2026年6月13日確認
https://docs.aws.amazon.com/quick/latest/userguide/vpc-creating-a-connection-in-quicksight-console.html
- Amazon Quick User Guide, "Configuring VPC connections in Amazon Quick Sight", 2026年6月13日確認
https://docs.aws.amazon.com/quick/latest/userguide/working-with-aws-vpc.html
- Amazon Quick pricing, 2026年6月13日確認
https://aws.amazon.com/quick/pricing/
- Amazon Quick User Guide, "AWS Regions, websites, IP address ranges, and endpoints", 2026年6月13日確認
https://docs.aws.amazon.com/quick/latest/userguide/regions.html
- AWS What's New, "Amazon Quick Now Available in the AWS Tokyo Region", 2026年6月13日確認
https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-quick-now-available-in-the-aws-tokyo-region/
更新履歴
- 2026年6月13日 JST: AWS What's New、AWS Weekly Roundup、Amazon Quick User Guide、Pricing、Regionsを確認し、MCP向けVPC接続、Action connectorとKnowledge baseの違い、日本導入時の確認点を整理しました。