9月3日、Asif Razzaqが「Anthropic Released Claude Commerce Agents: An Apache-2.0 Blueprint for Shopping and Merchant Agents Across Retail, Travel, Telecom and Entertainment」と題した記事を公開した。AnthropicがコマースAIエージェントのリファレンス実装をApache 2.0でOSS公開したことを詳しく紹介している。複数の企業向けデプロイで計測された結果では、スキル統一型の単一エージェント設計がサブエージェント分割設計と比べてコスト・レイテンシの両面で優れており、キャッシュヒット率は**90〜99%**を目標として設計されている。
ショッピングエージェントの「足場」をそのままコードで公開
ECサイトやアプリにショッピングアシスタントを組み込む場合、エージェントループ、カタログへのツール層、承認ゲート、評価スイートといった同じ基盤を毎回作り直すケースが多い。Anthropicはその基盤をコードとして公開した。
リポジトリはanthropics/commerce-agents。ショッピングエージェントとマーチャントエージェントの2種類を軸に、小売・旅行・通信・エンターテインメントの4業種向けのサンプルが動作する形で同梱されている。ライセンスはApache 2.0。Python 3.11以上とNode 22、ANTHROPIC_API_KEYがあればローカルで動く。Claude API、Amazon Bedrock、Microsoft Azure AI Foundry、Google Cloud Vertex AIのいずれにもデプロイ可能だ。
2つのエージェントの役割
ショッピングエージェントは、マーチャントのアプリ内に組み込むエンドユーザー向けの存在だ。カタログ検索、複数商品の比較、カート構築、注文・返品対応を1つの会話の中でこなす。スキルはsearch-discovery、purchase-research、planning-goals、customer-care、memory-personalizationの5つ。実装側はカタログ・カート・注文・ポリシーのシステムをStorefrontBackendとして渡す。
マーチャントエージェントは店舗スタッフ向けで、売上パフォーマンスの照会、在庫アラート、価格・プロモーション提案、キャンペーン原稿作成などを担う。スキルはperformance-insights、catalog-listings、inventory-operations、pricing-promotions、marketing-campaignsの5つ。
両エージェントとも、Messages API、Claude Agent SDK、Claude Managed Agents（ベータ）の3つの実行形態に対応し、プロンプト・スキル・ツール定義は共通だ。
※ Claude Managed Agents（ベータ）はAnthropicが提供するエージェント実行基盤で、会話状態の管理やツール実行をAPI側が担う仕組み。通常のMessages APIと異なり、エージェントループをクライアント側で実装する必要がない。
Claude Codeプラグインcommerce-builderを使えば、/scaffold-commerce-agentで新規エージェントの雛形生成、/review-commerce-agentで既存実装のレビューもできる。
最も参考になる設計判断：サブエージェント分割より「スキル」
アーキテクチャ上の主張で最も実務に転用しやすいのが、「インテントルーターもサブエージェントもやめてスキルに統一する」という判断だ。
コマースの会話は密結合している。カート、購入履歴、カタログへのアクセスが同時に必要なケース（返品フローなど）は多く、サブエージェントへの引き継ぎのたびに状態が失われる。トークンコストも引き継ぎのたびに数倍に膨らみ、レイテンシも秒単位で増加する。
ここで登場するのがAgent Skillsという概念だ。これはAnthropicがこのブループリント内で定義する設計パターンで、特定の業務ドメイン（例：customer-careやinventory-operations）に対応したシステムプロンプトの断片・ツール定義・ガイドラインをひとまとめにしたモジュールを指す。スキルの指示は会話履歴を持つエージェント自身にロードされるため、サブエージェントへの状態引き継ぎコストが発生しない。Anthropicの複数の企業向けデプロイでは、スキルを使った単一エージェントが「大きな1プロンプト設計」「サブエージェント設計」の両方を品質面で上回り、コストとレイテンシも低い結果が出たとされる。
なお、スキルに入れるかシステムプロンプトに入れるかの基準はトラフィックの頻度で決まる。全リクエストの約3分の1以上の頻度で参照されるものはシステムプロンプトへ固定し、それ以下の頻度のものはスキルとして動的にロードする。安全ルール・ブランド制約・ユーザーの重要情報は頻度にかかわらず常にシステムプロンプトに置く。
UIコンポーネントをツールとして定義する
コマース向けの応答の多くは文章ではなくUIコンポーネントだ。このブループリントでは、カスタムタグをプロンプトで生成させるのではなく、present_products、present_itinerary、present_plan_comparisonといった各コンポーネントをツールとして定義する。引数は型付きでサーバーがバリデーションし、クライアントがレンダリングする。
この設計の利点は、ツール呼び出しがメッセージ配列にネイティブに記録されるため、履歴を再ロードするときにカスタムパーサーが不要なこと、そして「最後に表示したホテルの1件目」といった参照もエージェント自身が解決できることだ。トークンレベルのストリーミングではeager_input_streaming: trueを設定することでサーバー側のバッファリングをスキップできる。
※ **
eager_input_streaming**はClaude Agent SDKのオプションで、ツール呼び出しの引数がストリームされてくる途中の段階でも逐次的に処理を開始し、引数の受信完了を待たずにツール実行に移る挙動を制御するフラグを指す。
レイテンシとコストの実測値
レンダリング済みの応答は500〜700出力トークンに達し、ストリーミングなしでは約5秒の待ち時間になる。Anthropicはエンドツーエンドのレイテンシと体感レイテンシを分け、コンポーネントを生成しながらストリーミングし、進捗をテキストで表示する設計を採用している。Agent SDKのデフォルトである「引数のストリーミングが完了した時点で各ツール呼び出しを実行するイーガー実行」により、数秒あったギャップが数百ミリ秒に短縮されたとされる。
コスト面ではプロンプトキャッシュが主要なレバーだ。
※ プロンプトキャッシュとはAnthropicが提供するAPIの機能で、同一プレフィックスを持つシステムプロンプトをサーバー側にキャッシュし、再送不要にすることでトークンコストを削減する仕組み。詳細は公式ドキュメントを参照。
リクエストはグローバル設定→セッション→揮発データの順に並べる。プレフィックスベースのキャッシュ仕様上、システムプロンプトの先頭にタイムスタンプを置くとリクエストごとにキャッシュが破棄されるためだ。キャッシュ読み出しは通常トークンの10分の1のコスト、書き込みは約1.25倍のプレミアムがかかる。実際のデプロイでは90〜99%のヒット率を目標とする。また、メモリ抽出は別プロセスで非同期に実行する設計が推奨されており、会話のメインフローをブロックしない構成が取られている。
