11月7日、AWSが「Taxonomy of agentic primitives in Amazon Q」と題した記事を公開した。この記事では、Amazon QにおけるAIエージェントの基本構成要素（プリミティブ）を4つの問いで分類する体系について詳しく紹介されている。
AIエージェントの設計が複雑化する中で、チームをまたいで「エージェント」「スキル」「ワークフロー」といった言葉の定義が揺れることは珍しくない。AWSがAmazon Qの開発を通じて直面したのもこの問題だった。同一の概念が別の名前で何度も再実装されるという非効率を解消するために収束した分類体系がこの記事の主題である。
なお、Amazon QはAWSが提供するエンタープライズ向け生成AIアシスタントの総称で、Amazon Q Business（業務向け）とAmazon Q Developer（開発者向け）などのサービス群を含む。本記事の元タイトルは「Amazon Quick」と記載されているが、文脈およびAWS公式の製品体系から「Amazon Q」を指すものと解釈される（※編集部の考察）。AIエージェントの実行基盤としてはAmazon Bedrock Agentsとも密接に関連する領域だ。
4つの問いで分解する
フレームワークの骨格はシンプルだ。エージェント的な作業を「When（いつ）」「What（何を）」「Who（誰が）」「How（どうやって）」の4問に分解し、それぞれにプリミティブを対応させる。
| 問い | プリミティブ |
|---|---|
| When / What | トリガー |
| Who | エージェント |
| How | ケイパビリティ（ツール・スキル・ワークフロー） |
トリガー：作業の起点を明確にする
トリガーは作業の起動メカニズムであるとともに、「何をするか」の指示も兼ねる。種類は4つ：
- Human-initiated：人間がチャットを開いて指示する。同期的・会話的。
- Agent-delegated：あるエージェントが処理中に別エージェントをサブタスクとして呼び出す。再帰的な構成が可能。
- Scheduled：「毎週月曜9時に財務調査を実行」のような時間ベース。同じ指示が繰り返し適用される。
- Event-driven：メール受信、Slackのメンション、ファイル変更、Webhookなど外部システムからのシグナル。
トリガーの種類が実行の振る舞いを変える点も重要だ。スケジュール実行のバックグラウンドタスクなら「不確かな場合は何もしない」という保守的な動作が適切で、Human-initiatedなら「止まらず聞き返す」という応答的な動作が求められる。
エージェント：学習する永続的なアクター
記事の定義によれば、エージェントとは「永続的かつ学習するアクター」だ。エージェントは3つの要素で構成される：
- Instructions（指示）：ペルソナ、役割、コンテキストファイル、動作原則。Finance AgentとGeneral Assistantの振る舞いの違いはほぼここで決まる。
- Capabilities（ケイパビリティ）：利用可能なツール、スキル、ワークフロー、サブエージェント。セッションをまたいで動的に追加・削除できる。
- Learned context（学習済みコンテキスト）：使用を通じて蓄積するメモリ。あるツールで有効なクエリ、ユーザーが好むフォーマット、気にしているエッジケース。指示を誰も変えなくても、10回目の実行は1回目より良くなる。
この定義から重要な示唆が生まれる。「Slackを監視して毎朝ダイジェストを送って」というリクエストは、新しいエージェントではなく既存エージェントへのスケジュールトリガーの追加として扱うのが正しい。これによりチャット・スケジュール・自律型の「エージェント」を1つのアクターに統合できる。
ケイパビリティ：確信度の契約
ケイパビリティは「完全にエージェント任せ」から「完全に決定論的」まで連続したスペクトラムを持つ。この軸は「エージェントにどれだけの裁量を持たせるか」という確信度の契約として捉えられる。
ツールは型付きスキーマを持つ原子的操作だ。メール送信、DBクエリ、ファイル読み込みなど。ローカル関数、MCP（Model Context Protocol）サーバー、プロトコル境界の向こうにいる別エージェントのいずれであっても、呼び出し元からは「名前・説明・パラメータ・結果」という同一インターフェースに見える。
スキルは判断の余地を持つ構造化ガイダンスだ。厳密な手順ではなくアプローチを記述した指示とリソース（テンプレート、スクリプト、サンプル）をバンドルする。Progressive Disclosureで読み込まれる——エージェントは関連性が高まるまで名前と短い説明しか見ず、必要になったとき初めて全文を読む。これにより、常時コストをかけずに深い専門知識を格納できる。
ワークフローは決定論的な協調だ。宣言されたステップ、制御フロー、分岐、エラーハンドリングが固定順序で実行される。購買承認フローを例に挙げると、予算確認→上長承認→経理、各ステップが記録される。ルートは固定だが、各ステップ内の判断はエージェントが担う。
「モデルが改善すればスキルもワークフローも不要になるのでは？」
自然な疑問だが、記事はこれを否定する。スキルは機関知識のキャプチャ・バージョン管理・共有の単位であり、ワークフローは監査可能性・ステップ単位の可視性・決定論的なマルチサービス協調を提供する。モデル性能とは独立した価値だ。
さらに、両者の間には移行がある。よく理解されたスキルはワークフローに結晶化（crystallization）でき、エッジケースが頻発するワークフローはスキルに溶解（dissolution）できる。このプロセスは継続的学習フレームワークを通じて行われるという（詳細は今後の記事で公開予定）。
実践上の意味：同じ要求を3通りで実装できる
「Slackを監視して毎日ダイジェストを送る」という同一の要求を、このプリミティブを使って次の3通りで実装できる：
- 1行の指示を持つスケジュールタスク——残りはエージェント任せ
- 明示的なフォーマットルールとチャンネル優先度を持つスキルで補強したもの
- 決定論的なステップとエラーハンドリングを持つワークフローで実行するもの
いずれも毎日ダイジェストを届ける。違いは確信度の契約だ。エージェントを信頼するユーザーには1番目、過去に一貫性で痛い目を見たユーザーには2番目、コンプライアンスが求められるプロセスには3番目が適切になる。
Amazon Qはこの分類体系を基盤とした「エージェントOS」をその上に構築しており、次回の記事ではその詳細が公開される予定だ。
詳細はTaxonomy of agentic primitives in Amazon Qを参照していただきたい。
