Amazon Quick Suiteは、AWSが2025年10月に発表した業務向けのAIエージェント基盤で、現在は「Amazon Quick」の名称で提供されています。BIのQuickSightを中に含みつつ、社内文書を読ませたチャットエージェント、業務フローの自動化、調査レポートの作成までを1つのサービスで扱える仕組みです。この記事では、2026年10月時点の公式ドキュメントとAWS CLIリファレンスをもとに、Quick Suiteの構成と東京リージョンでの可否を確かめたうえで、スペース・チャットエージェント・Quick FlowsをCLIで組み立てる手順と、自社のMCPサーバーをつなぐときの制約を解説します。
まとめ：Quick Suiteは東京で使えるAIエージェント基盤でCLIから構築できる
先に要点を置きます。
- Quick Suiteは改称を経て「Amazon Quick」になり、Quick Sight・Quick Flows・Quick Automate・Quick Index・Quick Research・Appsを含む
- 東京リージョン（ap-northeast-1）はエージェント機能の対象で、推論は東京と大阪の範囲で処理される
- スペース・チャットエージェント・フロー・アクションコネクタ・ナレッジベースは、AWS CLIの
quicksight名前空間から作成と更新ができる - 自社のMCPサーバーはリモート接続のみで、1操作5分・1接続100ツールが上限になる
料金はサブスク区分と固定費の組み合わせで決まるため、Amazon Quick（旧Quick Suite）の料金を全プラン比較｜250ドルの固定費・エージェント時間・SSOの条件で扱っています。BI部分の仕組みはAmazon QuickSightとは｜Amazon Quick改称後の機能・SPICE・料金と実装手順を参照してください。本記事はエージェント側の構築に絞ります。
Quick Suiteの改称とQuick Sight・Flows・Indexの構成
Quick SuiteからAmazon Quickへと名称が二転しているため、検索で見つかる記事の表記がばらばらです。まず呼び名と中身の対応を揃えます。
QuickSightからQuick Suite・Amazon Quickへの改称とAPI
2025年10月の発表時は「Amazon Quick Suite」で、その後「Suite」が外れて「Amazon Quick」になりました。Amazon Quickの概要ドキュメントには、QuickSightはQuick内の機能「Amazon Quick Sight」として続き、既存のAPI・SDK・連携は変更なしで動くと書かれています。CLIのコマンドもaws quicksightのままで、新しいエージェント機能もこの名前空間に追加されました。
6つの機能の役割と、エージェントが参照するスペースとナレッジベースの関係
| 機能 | 役割 |
|---|---|
| Quick Sight | ダッシュボードとBI |
| Quick Flows | 定型作業の自動化 |
| Quick Automate | 業務プロセスの自動化 |
| Quick Index | 社内文書の索引化 |
| Quick Research | 引用付きの調査レポート |
| Apps | 自然言語でのWebアプリ作成 |
Quick Flowsは自然言語で組んだワークフローを繰り返し実行する機能で、Quick AutomateはAIエージェントが判断を挟みながら複数アプリにまたがる処理を進める機能です。実装で押さえる単位は「スペース」です。スペースはダッシュボード・データセット・トピック・ナレッジベース・アクションコネクタを束ねる入れ物で、チャットエージェントはスペースを通じて社内の情報と操作にアクセスします。設計の順番は、データとナレッジベースを用意し、スペースにまとめ、エージェントへ渡す流れになります。
検証環境を用意する：東京リージョンのエージェント機能とEnterprise要件
コマンドを打つ前に、リージョンとサブスクの条件を確かめます。ここを外すと、APIは通ってもエージェントが動きません。
Agentic Featuresが有効なリージョンと日本の推論リージョン
リージョン一覧では、Quick自体は26リージョンで提供されている一方、エージェント機能（Agentic Features）が「Yes」なのは米国東部（バージニア北部）・米国西部（オレゴン）・シドニー・東京・フランクフルト・アイルランド・ロンドンとGovCloud（US-West）に限られます。ソウルやシンガポールはBIのみです。
東京で作った場合、推論は日本の地理的範囲（東京・大阪）で処理され、チャットやエージェントのWeb検索も東京で処理されると記載されています。社内規程で「データを国外に出さない」条件がある案件では、この表を根拠資料として残しておくと説明が楽になります。なお、推論先リージョンはQuick側が管理し、SCPやIAMの推論プロファイル権限では制御できません。
サブスクの入口が2つある点と、APIで扱えるのはAWSアカウント側だけという前提
Quickの始め方は、メールやGoogleアカウントで登録する個人向けの入口と、AWSマネジメントコンソールから組織として作る入口の2つです。CLIやSDKは--aws-account-idを必須引数に取るため、本記事の手順は後者で作ったサブスクが対象です。また、アカウント構成のドキュメントのとおり、1つのサブスクで複数リージョンを使えますが、スペースやエージェントは作ったリージョンに置かれます。東京で作るなら、CLIの既定リージョンを先に固定します。
export ACCOUNT_ID=123456789012
export AWS_REGION=ap-northeast-1
aws --version
aws quicksight list-spaces --aws-account-id "$ACCOUNT_ID"list-spacesが「Invalid choice」で失敗する場合は、CLIが古くエージェント系コマンドを持っていません。2026年10月時点のリファレンスはAWS CLI 2.37系で、スペース関連のコマンドは2026年6月の追加分です。
AWS CLIでスペースを作成しダッシュボードとナレッジベースを登録する
ここからは、営業部門向けに「受注ダッシュボード」と「提案書の文書群」をまとめたスペースを作る例で進めます。
create-spaceの必須引数とspaceArnを変数に受ける書き方
create-spaceの必須引数は、アカウントID・スペースID・表示名の3つです。スペースIDはリージョンとアカウントの中で一意にし、英数字と-_=.+だけが使えます。後でエージェントに渡すため、出力のspaceArnを変数に受けておきます。
SPACE_ARN=$(aws quicksight create-space \
--aws-account-id "$ACCOUNT_ID" \
--space-id sales-knowledge \
--name "営業ナレッジ" \
--description "受注ダッシュボードと提案書をまとめたスペース" \
--query spaceArn --output text)
echo "$SPACE_ARN"update-space-resourcesで5種類のリソースを追加し失敗分を確かめる
スペースに入れるリソースはupdate-space-resourcesで追加します。指定できる種類はTOPIC・DASHBOARD・KNOWLEDGE_BASE・ACTION_CONNECTOR・DATA_SETの5つです。ナレッジベースのARNは、create-knowledge-baseの出力KnowledgeBaseArnから控えておきます。
DASHBOARD_ARN=$(aws quicksight describe-dashboard \
--aws-account-id "$ACCOUNT_ID" --dashboard-id sales-dashboard \
--query Dashboard.Arn --output text)
KB_ARN="（create-knowledge-baseの出力KnowledgeBaseArn）"
cat > add-resources.json <<EOF
[
{"ResourceType": "DASHBOARD", "ResourceDetails": {"resourceArn": "$DASHBOARD_ARN"}},
{"ResourceType": "KNOWLEDGE_BASE", "ResourceDetails": {"resourceArn": "$KB_ARN"}}
]
EOF
aws quicksight update-space-resources \
--aws-account-id "$ACCOUNT_ID" \
--space-id sales-knowledge \
--add-resources file://add-resources.json \
--query FailedResourceOperationsこのAPIは一部のリソースが失敗しても全体としては成功を返し、失敗分をFailedResourceOperationsにErrorMessage付きで並べます。終了コードだけで判定すると、ナレッジベースが入っていないスペースのまま次へ進んでしまうため、最後の--queryで空配列になったことを必ず見ます。
ナレッジベースの接続元：S3・Webクローラーと外部ストレージの種別
ナレッジベースに接続するデータソースは、S3・Webクローラー・Drive・OneDrive・SharePointです。
create-knowledge-baseのテンプレート種別はS3V2・WEBCRAWLERV3・GOOGLEDRIVEV3・ONEDRIVEV3・SHAREPOINTV3です。設定の入れ子が深いので、--generate-cli-skeleton inputで雛形を出してから埋めるほうが早く確実です。Index容量はリージョンごとに割り当てられ、ホームリージョン以外で確保した分は超過扱いで請求されるため、ナレッジベースはホームリージョンに置く前提で設計しておきます。
AWS CLIでチャットエージェントを作りスペースとアクションを接続する
スペースができたら、それを参照するチャットエージェントを作ります。
create-agentでスペース・開始プロンプト・人格設定を一度に渡す
create-agentでは、スペースとアクションコネクタをそれぞれ最大10件、開始プロンプトを最大3件（各100字まで）指定できます。名前は50字までです。回答の口調や根拠の示し方は--custom-prompt-inputのNewPromptに書きます。
aws quicksight create-agent \
--aws-account-id "$ACCOUNT_ID" \
--agent-id sales-assistant \
--name "営業アシスタント" \
--spaces "$SPACE_ARN" \
--starter-prompts "今月の受注見込みを要約して" "A社向けの過去提案を探して" \
--welcome-message "受注ダッシュボードと提案書をもとに回答します。" \
--agent-lifecycle PREVIEW \
--custom-prompt-input '{"NewPrompt":{"Identity":"あなたは営業部門のアシスタントです","Tone":"簡潔で丁寧な口調","CustomInstructions":"回答の根拠にしたダッシュボード名か文書名を必ず添える"}}' \
--query '[AgentId,AgentStatus]'作成直後のAgentStatusはCREATINGで、ACTIVEになってから会話できます。スクリプトに組み込むときはdescribe-agentで状態を見てから次の処理へ進めます。
update-agentにライフサイクル引数が無く、名前が毎回必須になる点
実装で詰まりやすいのが更新です。2026年10月時点のupdate-agentのリファレンスには--agent-lifecycleが無く、PREVIEWとPUBLISHEDの切り替えは作成時の引数でしか指定できません。また--nameは更新のたびに必須です。スペースの付け外しは、--spaces-to-addと--spaces-to-removeの差分指定になります。IaC化するなら、エージェントは「検証用をPREVIEWで作り、確定したらPUBLISHEDで作り直す」運用にしておくと状態がぶれません。
既存権限を写すupdate-agent-permissionsでの利用者公開
作っただけでは作成者しか使えません。update-agent-permissionsで、ユーザーやグループのARNに対してActionsを付与します。付与する権限名を推測で書くと過不足が出るので、コンソールで共有したエージェントをdescribe-agent-permissionsで読み、そのPermissions配列を雛形に使うのが確実です。1回の呼び出しで付与できるのは最大100件です。
Quick FlowsをDescribeFlowで取得して別アカウントへ複製する手順
Quick Flowsは画面上で自然言語から組み立てるのが基本ですが、検証アカウントで作ったフローを本番へ移すときはAPIが役立ちます。
FlowDefinitionは内部形式なので手書きせず取得した定義を使う
create-flowの--flow-definitionは「Quick Flowの内部形式で、形式は変わる可能性がある」と明記され、describe-flowから取得した定義を元にするよう案内されています。したがって、定義を一から手で書くのではなく、画面で作ったフローを取り出して流し込む使い方になります。
aws quicksight describe-flow \
--aws-account-id "$SRC_ACCOUNT_ID" \
--flow-id "$FLOW_ID" \
--publish-state PUBLISHED \
--query Flow.FlowDefinition > flow-definition.json
aws quicksight create-flow \
--aws-account-id "$DST_ACCOUNT_ID" \
--name "週次の受注レポート配信" \
--flow-definition file://flow-definition.json \
--client-token weekly-order-report-v1 \
--profile prodclient-tokenでの重複防止とpermissionsでの権限同時付与
create-flowはClientTokenによる冪等性を持ち、同じトークンで再実行しても重複作成されません。CIから流す場合はフロー名と版を含めたトークンにしておきます。--permissionsを省くと権限なしで作られるため、所有者と利用者のプリンシパルを同時に渡します。フロー内でつないでいるアクションコネクタは複製先アカウントに別途作る必要があり、定義だけ移しても認証情報は付いてきません。
自社のMCPサーバーをQuickにつなぐ：Streamable HTTPと5分の制限
社内の基幹システムや独自APIをエージェントから操作させるには、アクションコネクタかMCP連携を使います。create-action-connectorにはSalesforce・Jira Cloud・Slack・Microsoft Teams・SAPの各APIなど組み込みの種別が並び、汎用のGENERIC_HTTPもあります。既製品が無い自社システムはMCPサーバーを立てるのが素直です。MCPの全体像はMCP（Model Context Protocol）とは？AIと外部ツールをつなぐ標準規格の仕組みをわかりやすく解説で解説しています。
Quick側の前提：リモート接続のみ・Enterprise・VPC経由も可
MCP連携のドキュメントの前提と制約を、実装に効く順に並べます。
- Amazon Quick Enterpriseのサブスクが必要
- リモートサーバーのみ対応で、ローカルのstdio接続は不可。SSEよりHTTPストリーミングを推奨
- 1操作のタイムアウトは5分固定で、超えるとHTTP 424で失敗する
- 1接続で登録されるツールは先頭100個まで
- 独自のHTTPヘッダーは送れず、送られるのは標準のシステムヘッダーだけ
- 自作コネクタはツールを増やしても自動同期されず、画面の「Sync」で再認可が要る
公開されていないMCPサーバーは、QuickのVPC接続経由でつなげます。ただしQuickはVPC既定のDNSリゾルバーを使わないため、VPC接続にRoute 53 Resolverのインバウンドエンドポイントを設定しないと名前解決で失敗します。トランスポートの違いはStreamable HTTPとは？MCPのトランスポートとSSEの違い、2026-07-28仕様の変更点が詳しいです。
FastMCPで最小のMCPサーバーを立ててinputSchemaを確かめる
PythonならFastMCPとは｜PythonでMCPサーバーを最速構築するフレームワークの使い方【2026年版】で紹介したFastMCPが手早く書けます。在庫数を返すツールを1つだけ持つサーバーの例です。
# server.py（pip install fastmcp）
from fastmcp import FastMCP
mcp = FastMCP("inventory")
@mcp.tool()
def get_stock(sku: str, warehouse: str = "tokyo") -> dict:
"""SKUと倉庫コードを受け取り、在庫数を返す"""
stock = {"A-100": 42, "B-200": 0}
return {"sku": sku, "warehouse": warehouse, "qty": stock.get(sku, 0)}
if __name__ == "__main__":
mcp.run(transport="http", host="0.0.0.0", port=8000)Quickへ登録する前に、ツール定義を自分で読み出して確認します。
# check_tools.py
import asyncio
from fastmcp import Client
async def main():
async with Client("http://localhost:8000/mcp") as client:
for tool in await client.list_tools():
print(tool.name, tool.inputSchema)
asyncio.run(main())Creation failedの典型はJSON SchemaのDraft 3記法
Quickは公開時に各ツールのinputSchemaをJSON Schema Draft 7以降として検証します。ドキュメントのトラブルシュートには、探索は通るのに公開で「Creation failed」になる原因として、プロパティの中に"required": trueと書くDraft 3記法が挙がっています。正しい記述形式は、requiredをルート直下の配列として指定する形です。
{
"type": "object",
"properties": {
"sku": {"type": "string", "description": "商品コード"}
},
"required": ["sku"]
}この失敗は2〜5分ほど待たされてから返ってきます。ネットワークの問題と取り違えやすいので、上のcheck_tools.pyの出力でrequiredが配列になっているかを先に見ておくと切り分けが早くなります。
Quick Suiteを採用すべき条件とBedrockで自作すべき場面の線引き
Quickは「社内の人が使うAIアシスタント」を短期間で用意するのに向く一方、作り込みの自由度には上限があります。
Quickを選ぶ条件：QuickSight資産があり、利用者が社内の非エンジニア
すでにQuickSightのダッシュボードやデータセットがあり、それを営業や管理部門に自然言語で引かせたいなら、Quickは第一候補です。スペースに既存資産を入れるだけでエージェントの根拠にでき、認証もIAM Identity Centerなど既存の仕組みに乗ります。Slack・Teams・Microsoft 365・Chromeから呼べるため、利用者に新しい画面を覚えさせずに済みます。
見送る場面：顧客向け機能への組み込み、5分を超える処理、細かな推論制御
自社サービスの利用者向けにAI機能を組み込む場合や、推論モデルとリージョンを自分で選びたい場合は、Amazon Bedrockで自作するほうが筋が通ります。MCP連携の5分タイムアウトに収まらない長いバッチ処理や、独自ヘッダーでの認証が必須の社内APIも、Quick単体では扱えません。この場合は、処理を非同期化してジョブIDを返すMCPツールに分けるか、Bedrock側にエージェントを置いてQuickからは結果だけを参照させる構成にします。
どちらで作るか、既存のQuickSight資産とどうつなぐかの判断は、要件と社内規程で結論が変わります。一創では、Quickのスペース設計やMCPサーバーの実装からBedrockでの自作まで、生成AI開発・AI受託開発として要件整理の段階からご相談を受けています。
よくある質問
Quick Suiteについて検索されている質問に、公式ドキュメントの記載をもとに答えます。
Quick SuiteとQuickSightは何が違いますか？
QuickSightはダッシュボードを作るBIサービスで、現在はAmazon Quickの中の「Quick Sight」という機能です。Quick Suite（現Amazon Quick）はその外側に、チャットエージェント・Quick Flows・Quick Automate・Quick Index・Quick Researchを加えた全体を指します。既存のQuickSightのダッシュボードやAPIは移行なしで使い続けられます。
Quick Suiteは東京リージョンで使えますか？
使えます。2026年10月時点のリージョン一覧で、東京はエージェント機能が有効なリージョンに入っており、推論は東京と大阪の範囲で処理されます。ソウルやシンガポールなどはBI機能のみで、エージェント機能は使えません。
Quick Suiteの料金はいくらですか？
ユーザーごとのサブスク料金に、条件付きのアカウント固定費とエージェント実行の従量分が加わる構造です。プランごとの金額と固定費が発生する条件は、Amazon Quickの料金を全プラン比較した記事にまとめています。BIだけを使う場合の料金計算はQuickSightの料金を実額で計算する記事を見てください。
Quick ResearchやQuick AutomateもAPIで操作できますか？
2026年10月時点のAWS CLIリファレンスで、Quick Researchを操作するコマンドは見当たりません。Quick Automateはstart-automation-jobとdescribe-automation-jobによるジョブの開始と状態確認だけで、プロジェクトの作成はできません。APIで構成管理できるのは、スペース・チャットエージェント・フロー・アクションコネクタ・ナレッジベースです。
ローカルで動かしているMCPサーバーをつなげますか？
stdioで動くローカルのMCPサーバーは接続できません。HTTPで到達できるリモートサーバーが必要です。社内ネットワークにあるサーバーは、QuickのVPC接続を使えばインターネットに公開せずにつなげます。
関連記事
- Amazon Quick（旧Quick Suite）の料金を全プラン比較｜250ドルの固定費・エージェント時間・SSOの条件：Quickのサブスク区分と固定費の条件。
- Amazon QuickSightとは｜Amazon Quick改称後の機能・SPICE・料金と実装手順：BI部分の定義とSPICE・埋め込みの実装。
- QuickSightでできることと使い方｜ダッシュボード作成手順と機能ごとの利用条件【2026年10月】：スペースに入れるダッシュボードの作り方。
- QuickSightの料金を実額で計算する｜4ロールの月額・250ドル固定費・SPICE課金の見積もり手順：BIロールとSPICEの料金計算。
- MCP（Model Context Protocol）とは？AIと外部ツールをつなぐ標準規格の仕組みをわかりやすく解説：Quickへつなぐ前に押さえるMCPの基本。
- FastMCPとは｜PythonでMCPサーバーを最速構築するフレームワークの使い方【2026年版】：MCPサーバーの実装手順。
