サイトアイコン 協栄情報ブログ

AWS PartnerEquip: Live – Tokyo 2026 参加レポート

Kuroda

Amazon Quick で「集計する時間」を「考える時間」に変える

〜 BI × 生成 AI の新しいかたち。社内ナレッジと AI エージェント、そして Quick on Desktop ハンズオン 〜

図 1：本記事のサマリー（5 つのポイントと、この記事を読んでわかること）

はじめに

クラウド事業本部の黒田です。大変ご無沙汰しております。

2026 年 10 月 27 日、日本で初めて開催された AWS パートナー向けイベント 「AWS PartnerEquip: Live – Tokyo 2026」 に参加してきました。午前は Amazon Quick をテーマにした講演が 3 本、午後は「Quick on Desktop で『集計する時間』を『考える時間』に変えよう」というハンズオンです。会場の雰囲気や食事については、同じく参加した齊藤の【食事編】参加レポートもあわせてどうぞ。

毎月、複数の請求先向けに Cost Explorer や請求書 PDF から数字を拾って Excel にまとめている身としては、「集計する時間を減らす」はそのまま自分の課題でした。本記事では、講演で語られた 「なぜ今 AI エージェントなのか」 という背景から、Amazon Quick の全体像、Quick on Desktop の仕組み、そして ハンズオンで実際に送ったプロンプトと返ってきた結果 までを整理します。

この記事の読み方

各章の先頭にラベルを付けています。興味のあるところから読んでください。

ラベル 想定読者 扱う内容
🏢 ビジネス現場向け 業務部門、情シス・企画 AI エージェントで何が変わるか、導入で失敗しない考え方、セキュリティ。技術的な前提知識は不要
🔧 エンジニア向け インフラ・アプリ開発者 Knowledge Graph と Memory の仕組み、Kiro CLI との ACP 接続、MCP との使い分け
🧪 ハンズオン体験記 どちらの読者も 当日送ったプロンプトと結果を Scene ごとに追いかける

当日のセッション構成

時間帯 内容 本記事の章
午前 1 Amazon Quick で始める社内ナレッジを活用した AI エージェント 第 1 章・第 2 章
午前 2 Amazon Quick on Desktop と Kiro の連携（ACP） 第 3 章
午前 3 パートナー向け：Amazon Quick のアーキテクチャとビジネス機会 第 5 章
午後 ハンズオン：Quick on Desktop ワークショップ（準備 30 分 + 初級編 55 分 + 中級・上級編） 第 4 章

本記事の前提
ワークショップで使ったデータは、会社名・人名・数字を含めてすべて架空のものです。本文中の図は筆者が作成したまとめ図です。講演スライドの内容は筆者の理解で要約しています。記載内容は 2026 年 10 月 27 日時点の情報です。

第 1 章　なぜ今、社内ナレッジ × AI エージェントなのか

🏢 ビジネス現場向け

AI は仕事の仕方を根本的に変える

最初のセッションは、Harvard Business Review の調査を引用した 3 つの数字から始まりました。

生成 AI のユースケースの広がりも整理されていました。

時期 中心となるユースケース 位置づけ
2022〜2023 年 文章の要約、翻訳、メール作成 単発の文章処理
2024 年 RAG、レポート作成、データ分析、コーディング 社内文書・データとの接続
2025 年以降 自律的なソフトウェア開発、複数システムを横断した業務処理 AI エージェントが本番業務を担う段階

「コンテキストの壁」

ここが講演の核心でした。多くの企業が社内規定・契約書・議事録を RAG で検索できるようにしましたが、それは 「人間がチャットで打ち込んだ情報」を起点に文書を探す仕組み にとどまっています。実際の業務に必要な CRM、メール、カレンダー、ファイルシステム、社内システム、git、IDE といったツールとは統合されていない。RAG から AI エージェントへ進むには、より広範なシステム統合でこの壁を越える必要がある、というメッセージです。

AI エージェントを上手く使っている組織の 3 条件

  1. 信頼できる全社 AI エージェント基盤 — ガバナンス、コンプライアンス、セキュリティ、野良ツールの排除、ログ・メトリクスの保護、ガードレールが整った基盤を管理者が用意し、ユーザーはその上で使う
  2. 充実した連携ツール — ERP、SaaS、ナレッジベース（SharePoint、Google Drive 等）、業務ツール（Outlook、Slack）がエージェントの「手足」として使える状態
  3. スキルとエージェントを横展開する仕組み — パワーユーザーがユースケースを量産し、共有基盤を通じてフォロワーが恩恵を受ける

従業員が求める AI と、企業が求める AI

従業員は「自分のコンテキストを正しく理解し、面倒な作業を肩代わりしてくれるツール」を求め、企業は「統合されたセキュアなプラットフォーム」「自社の管理下で統制されたデータ」「ガバナンス・アクセス制御がビルトインされた環境」を求めています。この 2 つが噛み合わないと、アプリケーションやコンテキストの切り替えで ひと月あたり 40 時間以上 が失われ、サイロ化されたデータをアクションに繋げられない状態が続きます。

AWS の AI オファリングの中での位置づけも明快でした。

サービス 役割
Amazon Bedrock AI モデルが「居る」場所
Bedrock AgentCore エージェントが「動く」場所
Kiro エージェントを「作る」場所
Amazon Quick ビジネスユーザーが「働く」場所

第 2 章　Amazon Quick の全体像

🏢 ビジネス現場向け

図 2：第 2 章のまとめ（Amazon Quick の全体像と 6 つの主要機能、「とりあえず全部繋げる」は失敗する）

Amazon Quick とは

Amazon Quick は、2026 年 3 月 26 日に東京リージョンで Quick 機能がローンチされた、エンタープライズ向けの統合 AI スイートです。講演では「エンタープライズデータのすべてを活用し、適切な回答を素早く提供し、アクションへの変換を手助けする Agentic AI」と説明されていました。従来の Amazon QuickSight（BI）は Quick Sight として引き継がれています。

機能 役割 ユースケース例
Quick Chat Agent 業務を自動化する AI エージェント 商談準備の自動化、会議要約、社内ツール QA
Quick Flow 手順・判断・実行を組み合わせたワークフロー構築 見積もり承認、与信確認、問い合わせ分類
Quick Sight 構造化データの可視化・BI 案件進捗の可視化、KPI 監視、QA 傾向分析
Quick Apps ノーコードで業務アプリを作成 営業日報、予算申請受付、IT 資産台帳
Quick Research 複数ソースを横断した深い分析 競合分析、市場分析、障害原因調査
Quick Spaces 目的別のデータ整理・集積場所 営業 Space、経理 Space、情シス Space

「とりあえず全部繋げる」と失敗する

業務部門の方にぜひ読んでいただきたい部分です。会計・財務担当の例では、必要なデータは ERP の仕訳、SaaS の請求書、担当者 PC の Excel、社内ポータルの申請手順、チャットの全社アナウンス、人事・給与システム…と散らばっています。「全部つなげば解決する」と思いたくなりますが、講演はそれを 典型的な失敗パターン として挙げていました。

  1. データはある — ファイル、FAQ、チケット、議事録、BI が散在
  2. 整理は不十分 — 粒度、鮮度、権限、用語が揃っていない
  3. 全部繋げて RAG 化 — 検索対象を広げれば答えが出る、という前提で実装
  4. 期待値と品質がズレる — 回答根拠、責任範囲、更新運用が曖昧なまま利用開始

結果は「正しい出力が得られない、回答が信用されない、利用者が定着しない、保守負荷だけは残る」。目的・対象業務・利用者・成功条件が曖昧なまま実装先行になる、というのは社内の AI 活用プロジェクトでも思い当たるところがあります。

成功のポイントは 「AI エージェントに適切なコンテキストを与える、信頼できるナレッジ範囲を定め、ユーザーが自ら進化させるデータ基盤を構築すること」 とまとめられていました。

Spaces：必要なデータを「必要な場所」に集める

その答えが Spaces です。ファイルのアップロード、BI ダッシュボード、ナレッジベース（S3、Google Drive、SharePoint 等）、アクション（Outlook、Slack、Jira 等）、構造化データセットを一つの Space に集めます。接続先には MCP、S3、Asana、Confluence、Jira、BambooHR、OneDrive、Teams、OpenAPI、PagerDuty、REST API、Salesforce、SAP、ServiceNow、Slack、Smartsheet、Web クローラー、Zendesk などが並んでいました。

会計・財務の例では「例外的な経費精算メモは .txt でアップロード」「経費精算フローは SharePoint から連携」「重要なアップデートは Slack から取得」と、必要なデータを選んで Space に集積 する使い方が示され、その Space をコンテキストに Chat Agent（決算整理仕訳）、Flow（月次決算生成、旅費精算）、Research（「インボイス／電帳法対応の運用ギャップを調査して」）が動く構図です。

Chat Agent：自然言語でエージェントを定義する

Chat Agent の特徴は、ツール利用と推論を繰り返す エージェンティック AI、Space と接続する データセットとの接続、外部システムと連携する 多様なアクション の 3 つです。

作り方が印象的でした。

「AWS 技術専門のリサーチエージェントを作成したい。AWS 公式ドキュメントとインターネット検索を駆使して、技術的な質問に対して徹底的な調査を行い、正確で実用的な回答を提供します。技術調査の結果は Slack を用いて指定した先に送付するようにしたい」

これだけで、システムプロンプト（アイデンティティ、指示、トーン、回答フォーマット、長さ）が自動生成され、さらに裏側で接続するデータソース（aws_knowledge、Amazon Builder Knowledge）とアクション（AWS Knowledge MCP Server、AWS Documentation、AWS Slack）まで 自動で選定 されていました。「AWS の専門知識が必要だな、Slack を呼び出せる API も必要だな」という判断を AI が行っているわけです。

資料のアウトプットと対話的なデータ分析

Quick は会話の中から Word、Excel、PowerPoint、PDF を直接出力できます。生成前に構成案を提示して修正指示を重ねる 協調編集 と、既存テンプレートのレイアウト・ブランドカラーを保持したまま生成する テンプレート準拠 が特徴です。

データ分析はチャット UI にグラフ描画機能が内蔵され、コード実行ツールと数値解析ツールが統合されているため、相関係数の棒グラフやレーダーチャートのような分析結果を正確に出せます。この機能は BI（QuickSight 相当）ではなくチャットエージェント側の機能で、生成 AI 機能を利用可能なプランでの契約が必要とのことです。

Flow と BI

Flow は条件分岐・繰り返しに加え、ブラウザ・メールクライアント・グループウェア操作を含むワークフローを自然言語で指示し、ノーコードで自動化します。営業レポート作成・送信フローでは、上司に Slack で送る前に「Review required」で 人の承認 を挟んでいました。

BI は従来の QuickSight の使用感そのままに AI 機能が充実し、Redshift、S3、Athena から SPICE に取り込み、ダッシュボード・ストーリー・シナリオ分析・トピックへ展開します。「ホテルチェーンの顧客アンケートダッシュボードを作って。月別の回答数推移、店舗別と都道府県別の総合満足度、目的別の傾向を見せて」と日本語で指示するだけで、フィルター・ドリルダウン・計算フィールド込みのダッシュボードが数分で生成されます。出力が ネイティブな QuickSight 分析オブジェクト なので、ポイント＆クリック編集、CI/CD、埋め込みなど既存ワークフローにそのまま統合できる点は実務上重要です。

Space を横断したインサイトの抽出

営業・経理・情シスと担当者ごとに作られた Space を横断して Quick Research が分析し、競合分析、市場分析、障害原因調査といった意思決定に必要なインサイトを抽出する――これが「真に社内ナレッジを活用する」姿として示されていました。

第 3 章　Quick on Desktop の仕組み

🔧 エンジニア向け

ネイティブデスクトップアプリとしての Quick

Amazon Quick on Desktop は、Quick と同じ AI をデスクトップアプリから利用し、ローカル PC 環境の操作を自動化しつつ、データとプライバシーを保護するものです。

Knowledge Graph と Memory

Knowledge Graph は、登録したフォルダのファイルからエンティティ（Organization、Person、Project、Decision、Action 等）を抜き出し、人・案件・会議・文書の関係性をグラフとして保持する「業務コンテキストの自動構造化」です。

Memory は、役割・好み・利用情報源・業務手順を保持する「ユーザーの働き方の記憶」です。fact と preference に分かれて保存され、「Always respond in Japanese. User explicitly requested this.」のような項目が参照回数付きで一覧されます。各項目は My context 画面から Boost / Edit / Forget ができます。

ハンズオンでは月次報告 76 ファイルを登録すると 5 分ほどで Knowledge Graph が見え、Memory に伝えた「結論・根拠・リスクの順で書き、最後に表を 1 つ付ける」という好みが別の会話でも効いていました（第 4 章）。

セキュリティのポイント

エンジニアとして一番気になるところです。Quick on Desktop については 5 点が示されていました（2026 年 7 月 22 日時点の注記あり）。

観点 説明
学習利用 お客様のデータを基盤モデルの学習に利用しない
コード実行 サンドボックス環境で実行、許可フォルダのみアクセス
アクセス制御 フォルダ単位で制御（例：/user/iseda/projectA は許可、/user/iseda/customerA は不許可）
推論リージョン 国内リージョン（東京・大阪）で推論を実行
暗号化 通信は TLS 1.2 以上、保存データも暗号化

Quick 全体でも、データを LLM の学習に利用しないこと、保管中・転送中の常時暗号化、AWS PrivateLink によりインターネットに通信を出さず AWS インフラ内で完結できることが示されていました。ただし閉域利用については 「アプリケーションの描画に必要な一部の情報はインターネット経由で取得される」 という注記（2026 年 7 月 28 日時点）があるため、閉域要件のある案件では個別確認が必要です。

Quick が計画し、Kiro が作る：ACP による接続

2 本目のセッションは、Quick on Desktop からコーディングエージェント Kiro を駆動する話でした。なぜ Quick から駆動するのか、理由は 4 つです。

  1. コンテキストを把握している — リポジトリ、チケット、Slack、ドキュメント、直前の調査と仕様を Quick が保持
  2. 何を作るかが大事 — 難しいのはコードを打つことではなく、何を作るべきかを見極めること
  3. ひとつの画面でできる — 調査 → 計画 → 仕様 → ビルド → デプロイをひとつの会話で
  4. 既存のガバナンスを活かせる — Quick はローカルで動作し、既存 IAM を通じて Kiro を駆動。新たに審査すべきアクセス権は不要

コーディングエージェントでビルドは高速化したが、何を作るかの判断は依然手作業で ボトルネックは上流へ移った。そこで Quick が AI-DLC（Discover → Decide → Design → Prototype）で計画・仕様化し、ビルド可能な仕様を ACP 経由で Kiro へ渡す。「数週間の上流作業が数時間に」がスライドの主張でした。

ACP と MCP の違い

プロトコル 何を与えるか 向き Quick での例
MCP（Model Context Protocol） エージェントに「ツール」を与える エージェント → データ／サービス AWS MCP Server、社内 CRM の MCP サーバー
ACP（Agent Client Protocol） ホストに「駆動するエージェント」を与える ホスト → エージェント Quick（ホスト）→ Kiro CLI

両者は重ねて使えます。デモでは Quick が MCP で AWS MCP Server に接続し、同時に ACP で Kiro を駆動していました。

Kiro CLI の動作の仕組み

Kiro は IDE だけでなくターミナルでも動作し、同じエージェント・ステアリングファイル・コンテキストを使います。Quick は Kiro CLI を サブプロセスとして起動し、stdio 上の JSON-RPC で通信、進捗をストリーム表示し、編集前に許可を求めます。

$ kiro-cli acp

# エージェント定義の置き場所
~/.kiro/agents

ハンズオン上級編では、Quick on Desktop の Customize → Connectors → Create → Coding agent → Configure a custom ACP agent で次の値を設定しました。Test connection を押すと「Allow ACP agent "Kiro"?」の許可が出て、Kiro CLI Agent からの返事が表示されれば接続完了です。

項目 値
NAME Kiro
COMMAND C:\Program Files\Kiro-Cli\kiro-cli.exe
ARGUMENTS acp

作る前に見る：インタラクティブなモックアップ

Quick はコードを一行も書く前に、アプリ内でインタラクティブな HTML モックアップを生成します。設計の問題を修正が安いうち（デプロイ済みアプリではなくモックアップの段階）で見つけられ、モックアップは Quick が Kiro へ渡す仕様の一部になります。「まずモックアップを承認し、それからビルド。Kiro が一行書く前に設計は固まっている」という一文は、要件定義で手戻りを繰り返してきた身としては納得感がありました。

第 4 章　ハンズオン体験記：Quick on Desktop ワークショップ

🧪 ハンズオン体験記

図 3：第 4 章のまとめ（ハンズオンの概要・流れと、分かったこと）

ワークショップの構成と環境

午後のハンズオンは AWS Workshop Studio のイベントとして提供され、ブラウザの中で動く Windows デスクトップ環境に Quick on Desktop があらかじめ入っています。手元の PC には何もインストールせずに試せます。

ストーリーは「あなたは AnyCompany 事業企画部の部長、田中美咲さん。毎月 5 名の部下から月次報告を集めて、上司の鈴木取締役向けに経営会議のサマリを作っている」というものです。

Scene テーマ 使う機能 目安
1 社内の Project 動向を AI でキャッチアップ Knowledge Graph、Memory 15 分
2 報告書の山を一瞬で読み切る ローカルファイルの処理、グラフ 7 分
3 さっきの話の続きを再開 Memory 5 分
4 提出前に AI で手戻りを防ぐ Skill、資料の作成 20 分
5 繰り返しの集計を自動で回す Scheduled Task 5 分
6 情報が向こうから来る Feed 3 分

図 4：ハンズオンの全体像（Quick on Desktop にアクセスし、プロンプトを入力し、AI エージェントが情報を検索・分析し、結果を確認する流れ）

準備で少しつまずいたところ

2 つの「画面」の行き来で最初は戸惑いました。手元の PC のブラウザでは手順書とダッシュボード、ブラウザのタブの中の Windows で Quick on Desktop を使います。プロンプトは手元でコピーし、デスクトップ環境のタブを一度クリックしてから貼り付け（Mac でも中は Windows なので Control + V）。デスクトップ環境のタブが裏に回ると画面更新が止まるので、前に出しておく必要がありました。

もう 1 つ、定期実行のタイムゾーンはアカウント設定から取るため、準備段階で Tokyo, Japan (UTC+09:00) に変える手順があります。飛ばすと Scene 5 で実行時刻が 9 時間ずれます。

Scene 1：社内の Project 動向を AI でキャッチアップ

何も情報を入れていない状態で送ります。

うちの部門で今動いている主要プロジェクトを教えて

当然「あなたの仕事の世界を知らないので答えられません。ツールをつなぐか、自分で情報を教えてください」という趣旨の返事。この答えを覚えておいて、あとで見比べます。次に Memory に自分のことを覚えさせます。

私のことを覚えておいて。
・私は AnyCompany 事業企画部の部長、田中美咲です。
・上司は鈴木健太取締役で、毎月の経営会議で部の状況を報告しています。
・経営会議向けの報告は、結論、根拠、リスクの順に書き、最後に表を 1 つ付けるのが好みです。
・回答はいつも日本語で書いてください。

「覚えました」に続けて、伝えた 4 つが箇条書きで返ってきます。

月次報告を Knowledge に登録する

部下 5 名分の月次報告（weekly-reports.zip、01_sato〜05_kobayashi、合計 76 ファイルの Markdown と CSV）を展開し、Customize → Knowledge → Add folder で指定します。このとき 2 つのスイッチを両方オンにするのがポイントです。

片方でもオフだと Knowledge Graph ができず、後の手順が成り立ちません。登録すると「Syncing」になり、2 分で 78%、4 分で 99%、5 分ほどで Knowledge Graph が見えるようになります（全取り込み完了は 15 分ほど）。

My context → Knowledge graph を開くと、人やプロジェクトの点が線でつながった図が表示されます。月次報告の Markdown を読ませただけで「佐藤翔太」「システム移行 Phase2」「ERP 統合」といったエンティティが自動で抜き出され、関係が結ばれているのは少し驚きました。

もう一度聞いてみる

新しいチャットで最初と同じプロンプトを送ると、今度は「ヴァンテージポイント案件（8,500 万円）」「システム移行 Phase2（ERP 統合）」のように、根拠のファイル名付き でプロジェクトが返ってきました。しかも答えが「結論」から始まっており、Memory に伝えた好みも効いています。フォルダを指定して質問したわけではなく、Knowledge Graph を使って「あなたの部門の事情」を踏まえて答えている点が、単なるファイル検索との違いです。

Scene 2：報告書の山を一瞬で読み切る

weekly-reports フォルダの全体構成を教えて。各メンバーのファイル数と種類を一覧にして。

5 名分のフォルダ構成と「合計 76 ファイル」がツリーと表で返ります。続けて同じチャットで：

全メンバーの月次報告を横断的に読んで、チーム全体の状況サマリを教えて。
誰が何を担当していて、それぞれの達成状況はどうなっている？

5 名の担当と達成状況（目標比 107%、113% など）が表で返ってきました。手順書には「自分で全部読むと 1 時間はかかる量」とありましたが、数十秒で表になります。さらに「各プロジェクトの達成状況をグラフで示して」と送ると、チャット内に棒グラフが描画されます。

業務で使うなら
手順書には「数字が元のファイルと合っているか、1 つだけ見比べてみてください」とあります。生成 AI の出力は毎回少しずつ変わるので、業務では「1 つだけ」ではなく、根拠との突き合わせは人の仕事として残ります。Cost Explorer の数字を扱う立場からは、ここは外せません。

Scene 3：さっきの話の続きを再開

My context → Memories には Scene 1 で伝えた内容が Profile（事実）と Preference（好み）として並んでいます。新しいチャットで、好みには一切触れずに送ります。

最新の月次報告をもとに、チームの状況を鈴木さんへの報告用にまとめて

「鈴木さん」だけで鈴木健太取締役だと分かったうえで「どの報告をもとにまとめますか？」と聞き返し、「チーム全員の最新月次を集約」を選ぶと、「鈴木取締役への報告用に、結論 → 根拠 → リスク → 表の構成でまとめます」と始まり、最後に表の付いた回答が返ってきました。毎月同じ形式で資料を作る業務にはそのまま効きます。

Scene 4：提出前に AI で手戻りを防ぐ（Skill と PowerPoint）

一番時間をかけた Scene です。Skill は AI の振る舞いを決める指示を書いたファイルで、日本語の文章で書け、プログラミングは要りません。思考の型、分析の手順、レポートの書式など、繰り返し使いたいものを Skill にすると、誰が頼んでも同じ品質で答えます。

教材（ACME-Software.zip）に入っている critical_thinking Skill の中身は SKILL.md という 1 つの Markdown で、「正しい問いを立て、正しい構造で整理し、正しい順序で実行する」「問題を解くのではなく、問題の構造を変える」といった思考原則が書かれています。Customize → Skills → Create → From folder で登録し、Try it でこの Skill を使うチャットを開きます。

weekly-reports フォルダの全メンバーの月次報告を読んで、チーム全体の状況をこのスキルで整理してくれる？

Skill が「あなたの立場は？」「今回のアウトプットの目的は？」と聞き返し、チームのマネージャーを選ぶと、前提を疑う問いや見落とし・矛盾の指摘が返ってきました。「高橋のタスク消化率 95% の実質は、Phase3 の 16 タスクが担当者未定のまま含まれている可能性がある」のように、報告書の数字をそのまま信じない視点 が入っています。

同じチャットで「経営会議向け資料を作成して」→ 1〜2 分で好みどおりの Markdown 文書が右タブに表示。続けて「PowerPoint 資料を作成して」→ スライド構成案（Slide Outline）を確認して Approve & Build。途中で日本語フォントを github.com から取得する許可などを 2〜3 回求められるので This chat で進めます。約 10 分で、濃紺とゴールドの 5 枚ほどのスライド（タイトル・結論・根拠・リスク・表）ができました。そのまま提出できる品質ではないにしても、たたき台としては十分です。

Scene 5・6：定期実行と Feed

チャットでうまくいった頼み方を、そのまま定期実行に回します。

毎週月曜の 10 時に weekly-reports フォルダの最新ファイルを読んで進捗を確認し、結果はフィードに流して。

「Creating schedule」の許可カードで Time zone が Asia/Tokyo になっていることを確認して Allow once。登録した定期実行は Mission control → Routines から見られます。Repeats に「At 01:00 AM, only on Monday」と出ますが、これは UTC 表示で日本時間の月曜 10 時です。

テスト実行は 1〜数分で完了し、Feed → Activity に「田中部長チーム 週次進捗サマリー（5 名分）」というカードが Important の印付きで届きます。その下には Knowledge Graph の取り込み完了通知（74 ファイル処理、失敗 0 件）も。カードの Chat から続けて質問できます。AI の作業を「あとで見る」ことにして、その間はほかの仕事に集中できるのが Feed の狙いです。

注意点
PC のフォルダを読む定期実行は、その時刻に PC と Quick on Desktop が起動している必要 があります。業務で使うなら常時起動環境を用意するか、クラウド側データソースに切り替える設計が要ります。

中級編・上級編：ブラウザ操作、MCP、Kiro 連携

中級編 1：AI にブラウザを操作させて会議室を予約する
模擬の会議室予約サイトの URL を渡し、「鈴木取締役と来週水曜の午後に 30 分の 1on1 をセットしたい。空いている会議室を予約して」と頼むと、Quick on Desktop が Edge を自分で起動して予定表を確認し、空き枠を見つけて予約フォームを埋めるところまでやってくれました。操作のたびに許可を求められ（4〜5 回）、予約確定の前には「これは取り消せない操作なので承認が必要です」と止まります。この 「止まって確認する」設計 は、業務で使うなら安心材料です。

中級編 2：社内 CRM に AI から直接聞く
Customize → Connectors → Create → Local connector から MCP サーバーの設定 JSON を貼り付けて社内 CRM（模擬）に接続し、「crm mcp を使って、来期に更新を迎える案件の一覧を教えて。金額が大きい順で」と聞きます。10 件の案件が金額順の表で返り、「高リスク案件が 3 件、早めの対応が必要そう」という気になるポイントまで添えられていました。

上級編：Kiro CLI × causal-learn で因果構造を発見する
第 3 章の ACP 接続の実践です。Quick on Desktop から Kiro CLI を呼び出し、CRM の商談データに causal-learn の PC アルゴリズムで因果グラフ（DAG）を描かせます。データが 10 件しかないので統計的に有意な因果関係までは出ませんでしたが、「連絡の途絶え（接触からの日数）」と「商談ステージの停滞」が失注に強く相関しているという傾向が示され、非技術者向けの 3 行サマリーとグラフ 1 枚にまとめるところまで一連で動きました（完了まで 20 分ほど）。

会場の様子

会場は多くのパートナー企業で埋め尽くされ、熱気のある雰囲気でした。午前の大規模なステージ講演に続き、午後は各自のノート PC で実際にプロンプトを入力しながら進めました。

図 5：会場の様子・登壇・ハンズオン体験のまとめ

第 5 章　パートナーとして、業務担当として考えたこと

🏢 ビジネス現場向け

パートナーのビジネス機会

3 本目のセッションは「Amazon Quick は、パートナーのソリューションや知見と組み合わせて、お客様の AI 活用を形にし、その成果に伴走し続けるためのプラットフォーム」という位置づけでした。

機会 内容 協栄情報で考えられる例
MCP Servers お客様独自アプリや自社ソリューションの API を MCP でラップして提供 請求代行サービスの利用明細を MCP 経由で Quick から参照
カスタムエージェント 業界・業務知識をもとにエージェントを開発し、顧客横断で展開・運用 AWS コスト最適化の診断エージェント、Well-Architected レビュー支援
スキル・オートメーション 業種・ユースケース特化のスキルやワークフローを開発・運用 入札書類レビューの Skill、月次請求チェックの Flow

自社で Quick を使ってみる 「Customer Zero」 から始め、30 日で基盤づくり、90 日で市場参入、6 ヶ月で再現性を作る、というロードマップ例も示されました。まず自分たちの業務で使い倒してからお客様に提案する順番は、請求代行のような定型業務を持つ当社にとっても現実的だと感じました。

自分の業務に置き換えると

ワークショップ最後の「6 つの機能のうち、あなたの業務に近いものは？」という Thinking Time で考えた候補です。

業務 使えそうな機能 想定する使い方 先に確認すること
月次の請求業務 Knowledge Graph、Memory 請求先ごとの手順書と過去の請求書フォルダを登録し「今月の〇〇向け請求で注意すべき点は？」と聞く 請求書・顧客データは社外秘。Knowledge Graph の保存場所と処理場所（国内リージョン推論、フォルダ単位アクセス制御）を確認してから実データを入れる
入札対応の意見書・提案書 Memory、Skill 「結論 → 根拠 → リスク」の構成を Memory に、社内レビュー観点を Skill にしてドラフト品質を揃える Skill は日本語 Markdown 1 枚で書けるので、まずレビューチェックリストの Skill 化から
AWS 最新情報のまとめ 定期実行、Feed 週次で情報を集めて社内に流す 定期実行は PC 起動が前提。常時起動環境か、クラウド側データソースへの切り替えが必要

注意事項と実運用のポイント

図 6：注意事項と実運用のポイント（やってはいけないこと、運用を支える仕組み）

まとめ

図 7：今日から始めるために（この記事でわかったことと、次のアクション）!
Amazon Quick が目指しているのは「RAG で文書を検索できるようにする」ことの先――業務ツールと統合されたコンテキストの上で AI エージェントが動き、資料を作り、定期実行で結果を届け、必要ならコーディングエージェントまで駆動する、という一連の流れだと理解しました。

読者 持ち帰りポイント 章
ビジネス現場の方 「とりあえず全部繋げると失敗する」こと、Space に必要なデータを選んで集めること 第 2 章
エンジニアの方 Knowledge Graph と Memory の仕組み、ACP と MCP の使い分け、セキュリティ（国内リージョン推論、フォルダ単位アクセス制御、PrivateLink） 第 3 章
これから試す方 Knowledge 登録時の 2 つのスイッチ、タイムゾーン設定、出力は必ず元データと突き合わせること 第 4 章

個々の機能は他の AI ツールにもあるものですが、「ローカルのフォルダを読ませて関係図を作り、好みを覚えさせ、思考の型を Skill にして、定期実行で回し、結果を Feed で受け取る」という一連の流れが、インストールなしの環境で 1 時間ほどで体験できたのは良い機会でした。

手順書は非常に丁寧で、「うまくいかないとき」の対処が各ステップ直下に書かれていたため、ほとんど迷わず進められました。「画像と文面が違っても、同じ方向の答えが出ていれば次へ進んでかまいません」と最初に書いてあったのも、気持ちの面で助かりました。

今後機会があれば、社外秘データの取り扱い条件を確認したうえで、請求業務の手順書を Knowledge に登録して試してみたいと思います。協栄情報では、AWS の請求代行・再販から構築・運用支援まで一貫して対応しています。Amazon Quick を含む生成 AI 活用のご相談も、お問い合わせフォームからお気軽にどうぞ。

モバイルバージョンを終了