過去1年間、Amazon Quickの構築に伴い、私たちのエージェントは質問に答えることから、会議のスケジュール設定、調査の実行、レポートの生成といったアクションを実行するようになりました。システムが進化するにつれ、1つの問題が繰り返し浮上しました。エージェント作業を構成するプリミティブに関する共通定義が存在しなかったのです。同じようないくつかのアイデア—作業を行う主体、それを開始する信号、パッケージ化された手順、教訓を先へ運ぶ記憶—が異なる名前で繰り返し再構築されていました。この繰り返しは製品設計に漏れ出し、ユーザーにも影響を与えました。
例えば、ユーザーが「Slackチャネルを監視して毎日ダイジェストを送って」と言ったとします。これは新しいエージェントなのか、既存のエージェントへのスケジュール指示なのか、ワークフローなのか、スキルなのか。これらは異なる問いですが、共通の語彙がなければ1つの混乱した選択に collapse してしまいます。
本記事では、私たちが最終的に収束した分類体系を共有します。エージェント作業を「いつ」「何を」「誰が」「どのように」という4つの平易な問いに分解することで見出された、1セットのプリミティブです。フレームワークの大部分は設計上エンドユーザーには見えませんが、共通の語彙はその下で構築する誰にとってもシステムを推論しやすくします。
フレームワークの概要
トリガーが作業を開始しタスクを運び（いつと何を）、エージェントがそれを引き受け（誰が）、そのケイパビリティ（ツール、スキル、ワークフロー）を使ってタスクを実行します（どのように）。学習はセッションランタイムからフィードバックされます。これはシリーズの最初の記事であり、今後の記事ではエージェントオペレーティングシステム、バックグラウンド学習、プロアクティブフィードなどについて説明します。
トリガー：作業が始まるきっかけ
トリガーは作業を完了するための起動メカニズムですが、指示も運びます。人間のメッセージは起動の瞬間であり、何をするかの記述でもあります。つまり、タスクの「いつ」と「何を」の両方です。トリガーは4種類あります。
- 人間主導：人が会話を開き、エージェントに何かを依頼する。対話型、同期、会話的。
- エージェント委任：あるエージェントがタスクの途中で別のエージェントを呼び出し、サブ問題を処理する。プログラム的、構成可能、再帰的かもしれない。
- スケジュール：時間ベースの起動。例：「毎週月曜日午前9時に財務調査を実行する」。決定論的で、同じ常設指示が実行ごとに適用される。
- イベント駆動：外部システムからの信号。例：新規メール、Slackでのメンション、ファイル変更、Webhook。
トリガーのタイプは実行を条件づけます。スケジュールされたバックグラウンドタスクは保守的（例えば不確実なら何もしない）であり得る一方、人間主導のタスクは応答的（例えば停止するのではなく尋ねる）でしょう。
エージェント
私たちはエージェントを永続的で学習する主体と定義します。それは任意の実行における「誰」であり、学習が蓄積されるアンカーです。同じ入力を与えられた2つのエージェントは異なる結果を出せます。異なる指示、ケイパビリティ、履歴を運ぶからです。エージェントは従う指示そのものではなく、指示を解釈する実体です。エージェントは3つで構成されます。
- 指示：ペルソナ、役割、コンテキストファイル、運用原則を定義する常設のガイダンス。財務エージェントが一般アシスタントと異なるのは主にこれによる。
- ケイパビリティ：利用可能なツール、スキル、ワークフロー、サブエージェント。動的に更新される。チャートライブラリはあるセッションで追加され、次のセッションで削除できる。
- 学習コンテキスト：使用を通じて蓄積される記憶。ツールに有効なクエリ、ユーザーが好むフォーマット、気にするエッジケース。これが、誰も指示を変えずに10回目の実行が1回目より優れる理由である。
他のすべては外在的です。エージェントの基盤となる大規模言語モデル（LLM）は交換可能なモデルパラメータであり、会話履歴はセッションごとの状態であり、トリガーはプラットフォームに属します。
この定義の帰結として、「Slackを監視して毎朝ダイジェストを送るエージェントが欲しい」というユーザーリクエストは、通常、新しいエージェントやワークフローではなく、既存のエージェントに追加されたトリガーです。この枠組みにより、チャット、スケジュール、「自律」エージェントを1つのアクターに統合でき、会話し、スケジュールでき、自身の過去の作業を編成・検査できます。
ケイパビリティ
ケイパビリティはエージェントが行動する方法であり、完全に自律的なものから完全に決定論的なものまでのスペクトラムに及びます。その軸は実質的に信頼の契約です。エージェントがどれだけの自由度を保つか、ユーザーがどれだけ事前に固定するか。
- ツールは型付きスキーマを持つ原子的操作です。メール送信、データベース照会、ファイル読み取り。ローカル関数、Model Context Protocol（MCP）サーバー、プロトコル境界の向こうの別のエージェントのいずれであっても、呼び出し側は同じインターフェースを見ます。名前、説明、パラメータ、結果。
- スキルは判断の余地を残す構造化されたガイダンスです。リソース（テンプレート、スクリプト、例）とともにバンドルされた指示で、厳格な順序ではなくアプローチを記述します。プログレッシブディスクロージャーを通じてロードされるため、エージェントは関連するまで名前と短い説明だけを見て、その後完全な指示を読み込みます。したがって、スキルは一定のコストなしに任意の深さの専門知識をバンドルできます。
- ワークフローは決定論的な調整です。宣言されたステップ、制御フロー、分岐、エラー処理を固定順序で実行し、決定ロジックはモデル推論ではなくコード内にあります。購入承認ルートを考えてみましょう。予算チェック、マネージャーの承認、そして財務。各ステップは記録されます。ルートは固定ですが、ステップ内の判断は依然としてエージェントのものです。
スキルとワークフローがモデルの進歩に耐える理由
自然な疑問が生じます。モデルが進歩し続けるなら、スキルとワークフローは不要になるのではないか？そうは考えません。それぞれがモデル能力とは独立に価値を持つからです。スキルは組織の専門知識を捕捉、バージョン管理、共有する単位であり、ワークフローは監査可能性、ステップごとの可視性、決定論的なマルチサービス調整を提供します。また固定でもありません。よく理解されたスキルはワークフローに引き締められ（結晶化）、エッジケースに頻繁に遭遇するワークフローはスキルに緩和できます（溶解）。Quickでは、これは継続的学習フレームワークを通じて行われ、将来の記事で説明します。
実践における意味
「Slackチャネルを監視して毎日ダイジェストを送る」に戻りましょう。これらのプリミティブは構成可能であるため、同じリクエストをいくつかの有効な方法で満たせます。
- 一行の指示を持つスケジュールタスク。残りはエージェントに任せる。
- 明示的なフォーマットルールとチャネル優先順位を備えたスキルに支えられた同じタスク。
- 決定論的なステップとエラー処理を持つワークフローを呼び出す同じタスク。
3つすべてがスケジュールで毎日ダイジェストを生成します。違いは信頼の契約です。エージェントを信頼するユーザーは最初のものを望み、一貫性のなさに傷ついたユーザーは2番目を、コンプライアンスに敏感なプロセスを実行するユーザーは3番目を望みます。
学習は時間とともにその軌道を変えます。一文で始まるタスク（「緊急の項目がないかメールをチェックして」）は、ドメインに縛られた学習を蓄積します。有効なクエリ、好まれるフォーマット、どの送信者が重要か。10回目の実行は著しく良くなり、誰も手作業でそれをエンコードしません。正しい設計は、ユーザーの信頼要件を満たす最も単純なオプションであり、必要に応じて自律学習を通じて段階的に進化するパスを備えます。
結論
このエージェントプリミティブ分類体系の価値は、4つの平易な問い—いつ、何を、誰が、どのように—が、一行のチャットリクエストからスケジュールされたコンプライアンスグレードのプロセスまで、あらゆるエージェント作業を位置づけるのに十分であることです。1つの語彙を共有することで、構築者はシステムを推論でき、製品は複雑さを隠せます。何より、ユーザーはそれを学ぶ必要がありません。欲しいものを言えば、システムが適切なプリミティブを組み立てて仕事をこなします。
シリーズ次回：これらのプリミティブの上に構築され、Amazon Quickを動かすエージェントオペレーティングシステム。