AWS Quick のスキルとエージェントの仕組み

本記事は 2026 年 11 月 9 日 に公開された「How skills and agents work in AWS Quick」を翻訳したものです。

AI エージェントを利用していて、同じ作業の進め方を何度も説明したことはないでしょうか。週次の状況報告の作り方、リリースノートの書き方、プロジェクトの管理方法、チケットの作成方法などです。こうした繰り返しの作業は、AWS Quick のエージェントとスキルにまとめておけます。Quick は、作業の自動化、データ分析、Web アプリケーションの構築、調査を AI で行えるサービスです。自然言語で指示すると、Quick は AI エージェントを利用し、接続済みのデータソースやアプリケーションに対してリクエストを処理します。

本記事では、Quick でエージェント、スキル、データがどう組み合わさるのか、そしてチームで利用できるスキルの作り方と共有方法を説明します。あわせて、公式カタログとカスタムエージェントを利用してスキルを活用する方法も紹介します。

基本的な概念

このセクションでは、エージェント、スキル、データとの関係から Quick を理解するための基本的な概念を説明します。

図 1: Quick エージェントが指示に従い、タスクに必要なスキルを読み込み、コネクタを通じて操作を行い、データに基づいて回答する仕組み

図 1 の中心にあるのがエージェントです。エージェントは指示に従い、タスクに必要なスキルを読み込み、コネクタを通じて操作を行います。回答の根拠には、スペース、ナレッジベース、データセット、ダッシュボードといったデータを利用します。

エージェント

Quick のエージェントは、独自の指示、ナレッジソース (スペース)、コネクタを持つ、設定可能な AI です。これらを利用して質問に答えたり、作業を代わりに進めたりします。エージェントとはチャットで対話できるほか、ルーチンで自動的に実行させることもできます。エージェントがアクセスできるのは、ユーザー自身がアクセスできるリソースとサービスのみです。各エージェントに何を許可するかもユーザーが決めます。

デフォルトエージェントの「Quick」は、すべてのユーザーが利用できる組み込みのエージェントです。範囲が固定されていないため、会話ごとに、スペース、ナレッジベース、ダッシュボード、コネクタ、スキルなど、ユーザーがアクセスできるリソースを利用して動作します。リクエストにどのデータやツールが必要かを事前に決めなくてよいので、ほとんどの作業は Quick から開始できます。

カスタムエージェントは、自分やチームのメンバーが特定の仕事向けに設定するエージェントです。たとえば、人事 (HR) チームのスペースをもとに新入社員の質問に答える HR オンボーディングアシスタントがあります。カスタムエージェントには専用の指示を与え、ユースケースに必要なスペース、コネクタ、スキルのみを利用するよう制限します。テストして公開すると、同じ Quick アカウント内の他のユーザーやグループと共有できます。作成手順は「Build AI-powered employee onboarding agents with AWS Quick」を参照してください。

データ

エージェントは、Quick に接続したデータに基づいて回答します。スペースは、エージェントが情報源として利用するドキュメントと Quick リソースを選んでまとめたものです。自分用、チーム用、組織内の別のグループ用に作成できます。スペースにはファイルやフォルダをアップロードできるほか、ダッシュボード、ナレッジベース、アクションコネクタ、データセットなどのアセットも追加できます。Quick との会話を開始するときにスペースを添付すると、その会話で Quick が利用するデータを絞り込めます。エージェントにスペースを追加すると、スペースはエージェントの設定の一部になり、リクエストに必要なときにエージェントが参照します。

ナレッジベースは、データソースから集めたドキュメントやコンテンツを整理してインデックス化したもので、検索と質問への回答に最適化されています。Quick は、Google Drive、Microsoft OneDrive、Confluence、Microsoft SharePoint、Amazon Simple Storage Service (Amazon S3)、Web クローラー、Amazon Bedrock Managed Knowledge Bases などのソースからナレッジベースを同期し、同期スケジュールに沿って最新の状態に保ちます。

データセットとダッシュボードは、Quick のビジネスインテリジェンス機能である AWS Quick Sight で作成します。Quick Sight は、AWS マネジメントコンソールからプロビジョニングしたアカウントで利用できます。データセットは、分析やダッシュボードですぐに利用できるよう準備したデータの集まりです。ダッシュボードは、分析を公開したもので、他の Quick ユーザーと共有できます。データセットを利用すると、データベースのテーブルなどの構造化データに意味を説明する豊富なメタデータを付けられるため、複雑な分析も自然言語で行えます。

最後に、コネクタは Quick を外部のアプリケーションやネイティブツールにつなぎ、エージェントがデータを読み取ったりユーザーの代わりに操作したりできるようにします。クラウドコネクタは、Microsoft Outlook、Slack、Jira、Asana、Salesforce などのサービスや、リモートでホストされている Model Context Protocol (MCP) サーバーに Quick を接続します。クラウドコネクタは、Quick を利用するすべてのデバイスで利用できます。ローカルコネクタは、自分でホストする MCP サーバーなど、自分のマシン上で動くコネクタです。そのため、ツールを利用できるのはそのマシンが起動していて接続されているときのみです。コネクタの種類の一覧は、Quick ユーザーガイドの「Connectors」と「Integration-specific guides」を参照してください。

こうした仕組みを組み合わせると、データ、ドキュメント、アプリケーションを自然言語で扱えるようになり、接続したソースに対して質問したり操作したりできます。

スキル

スキルは、特定のタスクのやり方をエージェントに教える、再利用可能な指示のセットです。スキルは、Quick のエージェントの振る舞いと作業の進め方の土台でもあります。Quick のエージェントは、他のエージェントと同じく、推論と行動 (ReAct) パターンに従うハーネス (マネージドなエージェントループ) の中で動きます。Quick にプロンプトを入力すると、エージェントは利用できるツールと指示を活用して目的を達成し、回答を返します。Strands Agents SDK などのエージェントフレームワークも、同じモデル駆動のループをもとに作られています。

Quick がデフォルトでできることの多くは、システムスキルによるものです。たとえば、Quick に Word 文書、PowerPoint のプレゼンテーション、Excel のスプレッドシート、PDF の作成を頼むと、システムスキルが同梱のスクリプトを利用し、コードでドキュメントを作成・編集します。ほかにも、Web の閲覧、コードの実行、ディープリサーチ、音声や動画の文字起こし、画像の生成を行うシステムスキルがあります。AWS Quick Flows の作成、ルーチンのスケジュール設定、Kiro などのコーディングエージェントへの作業の引き渡し、メモリとナレッジグラフの管理、To-Do の管理など、Quick 自体を管理するシステムスキルもあります。Quick の中でシステムスキルのオン・オフは切り替えられますが、編集、複製、エクスポート、公開、共有、削除はできません。

Quick の機能とツールを組み合わせることで、スキルでさまざまな作業を実行できます。たとえば、テンプレートから週次の状況報告を作るなど、成果物を作るスキルがあります。その週の Jira の更新を集めて要約を Slack に投稿するなど、複数のコネクタをまたいでワークフローを自動化するスキルもあります。Python スクリプトで計算し、結果を JavaScript でグラフにするスキルも作れます。

スキルとは

Quick のスキルは、Anthropic が開発してオープンスタンダードとして公開した Agent Skills 仕様に準拠しています。2026 年 4 月にプレビューとして登場し、2026 年 9 月に一般提供が始まったデスクトップ版 Quick も、この仕様を採用しています。

スキルは、ルートに Markdown ファイル SKILL.md を置いたフォルダです。指示の中で利用するスクリプトや参考ファイルも、必要に応じて入れられます。ファイルのフロントマター (2 本の --- 行で囲まれた属性) には、名前、説明、その他スキルに関係するメタデータを書きます。以下は、release-notes-generator というスキルを短くした例です。

---
name: release-notes-generator
description: "Generates human-readable release notes from merged pull requests, commits, or changelogs ... Use when asked to 'generate release notes', 'write changelog', ..."
---

スキルが呼び出されるかどうかは、説明と名前で大きく決まります。Quick はスキルをエージェントのプロンプトに読み込むときに段階的開示 (progressive disclosure) を利用します。エージェントは、リクエストがそのスキルを必要とするまで、各スキルの名前と説明のみを読みます。必要になった時点で、スキルの指示全体を読み込みます (詳しくは「How agents load skills」を参照)。そのため、「バージョン 2.3 のリリースノートを作って」のような特定のフレーズを入力すると、スキルが呼び出されやすくなります。仕様では name を 64 文字、description を 1,024 文字までに制限しており、スキル内の指示は 5,000 トークン未満を推奨しています。

図 2: release-notes-generator スキルのフォルダ。必須の SKILL.md ファイルと、任意の scripts フォルダ、references フォルダがある

Quick でスキルを作成して共有する

スキルは、チャット、ファイル (.md または .zip)、ルートに SKILL.md ファイルがあるフォルダのいずれかから作成できます。本記事ではチャットから作る方法を扱います。まず、チャットで Quick にタスクを説明します。たとえば、次のテンプレートから開始できます (<> で囲んだ部分を自分の要件に置き換えてください)。

Every <specify your cadence e.g. every day, on monday, or none at all>, I have to grab data from the following sources:
- <List your sources and how you want to query them>
...

And do <describe how you want to transform the data and the exact sequence of steps>. 

Once I am finished, I have to create a report <describe your report format or provide an example> and send to the following stakeholders <describe your recipients> using the following connector <describe your connector>.

Create a skill from this requirement, and help me come up with testing scenarios to test the skill. 

自分のスキル作りを開始するのに必要なのはこれだけです。以前にタスクを実行するために行った複数ターンの会話をもとに、Quick にスキルを作ってもらうこともできます。最終的な結果に納得したら、スキルを公開して共有します。

1. Customize を選択し、Skills を選択します。
2. 下書きのスキルを見つけて、詳細パネルを開きます。
3. Publish を選択します。
4. Share を選択し、共有する相手のユーザーまたはグループを選択します。

公開と共有は別の手順です。公開しただけでは、誰もスキルにアクセスできません。共有された人は、Shared with me の Add to Quick からスキルを追加します。追加したスキルは、作成者が再公開するたびに同期されます。最新の手順は、Quick ユーザーガイドの「Draft and published versions」と「Sharing your skills」を参照してください。

ベストプラクティスでスキルを改善する

簡単な説明や会話から作ったスキルでも、自分の環境では安定して動くかもしれません。しかし、チームで共有する本番用のスキルを作るときは、考慮すべき点がたくさんあります。スキルはコードと似ており、ソフトウェアエンジニアリングのベストプラクティスの多くは、ナレッジワーカーがスキルを作る場合にも役立ちます。

• 「自分のマシンでは動く」は、ソフトウェアエンジニアの間でよく聞く言葉です。作った本人の環境では動くのに、他の人がインストールしたり利用したりすると動作しないソフトウェアを指します。スキルを作るときは、環境を考慮する必要があります。スキルの指示では、エージェントを利用してデータソースを照会したり、コネクタやツールを呼び出したりできるからです。ソフトウェアエンジニアは通常、ソフトウェアを利用するための前提条件を文書化して、環境の違いによる問題を回避します。たとえば、スキルのみを単体で共有する場合は、こうした要件を記した README をスキルに添えるとよいでしょう。スキルを利用するエージェントを共有する場合は、エージェントが接続するソースもあわせて共有してください。共有しないと、共有された人は自分がすでにアクセスできるソースからしか回答を得られません。
• 失敗に備えます。エージェントは、サードパーティやファーストパーティのサービスに依存する接続済みのソースを利用します。エンジニアはコードを書くとき、ソフトウェアの一部が失敗したらどうするかを理解しておく必要があります。こうした状況をスキルの指示に盛り込んでおけば、エージェントは具体的な指示に沿って対応できます。エージェントは目的に向かって動き、ステップが失敗した場合は再試行したり別の方法を試したりできるので、スキルの作成者に、連携先のサービスに関する詳細な知識は求められません。ただし、失敗がタスクや業務プロセスに影響する場合にどうするかは書いておく必要があります。次のスニペットは、失敗すると影響が出かねないスキル内のワークフローの一部です。

[Agent] Send the report to {{recipient}} over email.

メールの送信に失敗したら、エージェントはどうすべきでしょうか。その場合の対応を指示に加えるとよいでしょう。

[Agent] Send the report to {{recipient}} over email.
Validate: The report appears in your Sent folder.
If fails: Stop, and tell the user that the report wasn't sent and why, so they can send it themselves.

人の確認なしにスケジュールでエージェントを実行する場合は、失敗時の対応がさらに重要になります。

• 変更のたびにテストします。ソフトウェアエンジニアは、単体テストや結合テストなど、さまざまな種類のテストを書いてソフトウェアを検証し、変更のたびに実行します。スキルでも同じように、さまざまな状況のテストケースを自分で作り、変更に合わせて新しいテストを追加していくことが重要です。方法はいくつかありますが、スキルを利用する人が実際に利用する環境でテストするのが最善です。

本番用のスキルを作るときに考慮すべき点は、ほかにもたくさんあります。

• 変更ごとにリリースノートを付ける。
• /Users/me/notes や #my-team のように変わる可能性がある値は手順にハードコードせず、各自が指定する入力として宣言する。
• スキルを変更した日付を、人が読める形で記録する。
• 各参考ファイルの出典を記録し、元の情報が変わったらスキルの指示も更新できるようにする。
• チェックサム (スキルのファイルの指紋) を保存し、確認済みのバージョンとコピーの違いが分かるようにする。
• リンターがレビュー前にコードの誤りを見つけるように、変更のたびに構造をチェックする。
• スキルを一貫した方法で作り、チームが変更を提案しやすく、レビューしやすくする。

ここまでの点をすべて考慮するのは、どのユーザーにとっても大変です。そこで Quick 公式カタログでは、こうしたベストプラクティスを踏まえて作ったスキルなどのリソースを用意しています。

AWS Quick 公式カタログ

公式カタログは、エージェント用リソースを集めたものです。そのままインストールして利用することも、出発点にして自分の仕事に合わせて変えることもできます。カタログによると、掲載されているリソースはすべて、公開前に品質、セキュリティなどの観点でテストとスキャンを受けています。スキルは、日常の生産性向上のほか、営業、マーケティング、人事、法務、プロジェクト管理、カスタマーサクセス、ソフトウェアエンジニアリングなどのチームの仕事に対応しています。金融、ヘルスケア・ライフサイエンス、エネルギー・公益事業、ホスピタリティ、サプライチェーン・物流などの業界向けのスキルもあります。

カタログには、こうしたエンジニアリングのベストプラクティスを代わりに適用してくれる、構築済みの Skill Architect スキルがあります。詳しくは「Build skills with software engineering practices in AWS Quick」を参照してください。インストールするには、Customize、Skills、Browse all、Official の順に選択します。検索ボックスに skill architect と入力し、Install を選択します。最新の手順は「Install skills in AWS Quick on desktop」を参照してください。

スキルをエージェントにつなぐ

エージェントを作成するときは、名前、説明、指示を設定し、参照するスペース、利用できるコネクタ、読み込めるスキルを選択します。詳しくは、Quick ユーザーガイドの「Agent configuration」を参照してください。エージェントは、新入社員の質問に答える、週次の状況報告を準備するといった特定のユースケースに絞り、そのユースケースに必要なスペース、スキル、コネクタのみに範囲を限定したときに最もよく機能します。デフォルトでは、エージェントはユーザーのすべてのスキルを利用できます。特定のスキルを追加すると、エージェントはそのスキルのみを利用するようになります。デフォルトのままだと、エージェントを共有したときに問題になります。エージェントは利用する人の権限で動作するからです。同じリクエストでも人によって利用できるデータやスキルが異なり、自分しかアクセスできないソースが必要な場合は不完全な回答になることがあります。

エージェント、スキル、スペースを組み合わせて利用してみたい場合は、ワークショップの personal agent architect モジュールをお試しください。

まとめ

本記事では、Quick でエージェントがスキルとデータをどう利用するのか、そしてチームで利用できるスキルの作り方と共有方法を紹介しました。あわせて、公式カタログとカスタムエージェントを利用してスキルを活用する方法も取り上げました。

Quick についてさらに学んだり、イベントを探したり、成功事例を共有したりするには、AWS Quick Community をご覧ください。Quick Community には、学習教材、機能の発表、イベント、他のユーザーの事例があります。Q&A フォーラムで質問することもできます。

本記事のトピックを扱った録画セッションは、「Encode Your Enterprise with Agents & Skills on AWS Quick」でご覧いただけます。セッションでは、スキルの構造と読み込み方、エージェント・スペース・コネクタとスキルの連携、共有するスキルを作るときのベストプラクティスを扱います。最後に、公式カタログと Skill Architect スキルのデモがあります。

Quick に日々携わるスペシャリストが作成した、その他のリソースも紹介します。

• A Complete Guide to AWS Quick: The Agentic AI Business Workspace
• AWS Quick: End-to-End Business Use Cases with Rich Integrations
• AWS Quick Administration Workshop
• Deep dive into AWS Quick Sight
• AWS Quick Knowledge Hub – Official Code Samples and Solutions
• Quick に関する AWS ブログ記事

著者について

翻訳は Solutions Architect の 守田 凜々佳 が担当しました。