Anthropic、Apache-2.0 ライセンスのショッピング・マーチャントエージェント用ブループリントを公開

ショッピングアシスタントやエージェントを開発する多くのチームは、同じ土台を毎回作り直しています。具体的には、エージェントのループ、カタログ上のツール層、承認ゲート、評価スイートの4つです。しかし今、Anthropic がその土台をコードとして公開しました。今週、同社は「anthropics/commerce-agents」というリポジトリを公開し、ショッピングエージェントとマーチャントエージェントを含む参照用ブループリントを提供しています。さらに、小売・旅行・通信・エンターテインメントの4つの実稼働可能な垂直領域も含まれています。

このリリースには、製品発表記事と「効果的なコマースエージェントの解剖学ガイド」と題されたエンジニアリングの深掘り記事という2 つの解説文が添えられています。

実際にデプロイ可能でしょうか？はい可能です。リポジトリは Apache 2.0 ライセンスで、Python 3.11 以上と Node 22 を使用してローカル環境で動作します。また、ANTHROPIC_API_KEY の設定が必要ですが、ランタイムは任意の Anthropic クライアントを受け付けるため、同じコードを Claude API、Amazon Bedrock、Microsoft Foundry、Google Cloud Vertex AI のいずれにも展開できます。

2 つのエージェントについて

ショッピングエージェントは、マーチャント自身のアプリ内に組み込まれます。カタログ検索や複数アイテムへの対応、選択肢の比較、カート作成、注文・返品に関する問い合わせへの回答など、一貫した会話内でこれらを実行します。その機能は「検索と発見」「購入調査」「計画と目標設定」「カスタマーケア」「記憶によるパーソナライズ」の 5 つに分類されます。デプロイ時には、カタログ、カート、注文、ポリシーシステムを扱う StorefrontBackend を実装する必要があります。

マーチャントエージェントは店舗スタッフをサポートします。販売実績に関する質問への回答、在庫アラートの通知、価格設定やプロモーションの推奨、キャンペーン案の作成などが可能です。その機能には、パフォーマンス分析、カタログ一覧表示、在庫管理、価格・プロモーション管理、マーケティングキャンペーンの各スキルが含まれており、これらは MerchantBackend 上で動作します。

両方のエージェントは、1 つのプロンプト定義、スキル定義、ツール契約、およびゲート設定から、3 つの方法で実行可能です。それは Messages API、Claude Agent SDK、そして Claude Managed Agents（ベータ版）です。また、Commerce Builder という Claude Code プラグインにより、新しいエージェントの構築（/scaffold-commerce-agent）や既存エージェントのレビュー（/review-commerce-agent）が容易になります。

サブエージェントではなくスキルで構成する

このアーキテクチャにおける主張は、最も汎用性が高い部分です。Anthropic は、意図をルーティングする仕組みや、ドメインごとに 1 つずつ用意されるサブエージェントという設計に反対しています。商取引のセッションは、密結合された 1 つの対話として扱うべきであり、ハンドオフ（引き継ぎ）のたびに状態が失われるリスクがあります。オーケストレーターがカート、ユーザー設定、履歴を保持していても、各ハンドオフにはトークンコストが数倍に膨らみ、レイテンシも数秒追加される可能性があります。また、ドメイン同士は重複する部分が多く、返品フローでは注文履歴、カート、カタログのすべてを同時に扱う必要があります。

エージェントスキルを使用すれば、同じモジュール性を維持しながら、そのようなコストを負担せずに済みます。なぜなら、スキル指示はすでに履歴を保持しているエージェントに直接読み込まれるからです。複数の企業導入事例において、Anthropic は、スキルを持つ単一エージェントが、「1 つの巨大なプロンプト」設計や「サブエージェント」設計よりも品質面で優れていると報告しています。しかも、コストとレイテンシの観点でも有利なケースが多いのです。ただし、深い調査など、狭く独立したタスクについては、依然としてサブエージェントが適した場面もあります。

プロンプトとスキルの使い分けは、利用頻度によって決定されます。システムプロンプトに割り当てられるトラフィックは約 3 割以上で、残りがスキルに充てられます。安全性に関するルール、ブランドの制約、重要なユーザー情報はすべてプロンプト内に記述します。

UI コンポーネントはツールとして機能します

コマース（EC）関連の応答は文章ではなく、UI コンポーネントとして提供されます。モデルに対してカスタムタグを出力させるためのプロンプトを組むのではなく、各コンポーネントをツールとして定義します。具体的には present_products、present_itinerary、present_plan_comparison といったツールを用意し、サーバー側で型チェックされた引数を受け取ってからクライアントがレンダリングするように設計されています。

これらの呼び出しはメッセージ配列にネイティブに含まれるため、履歴の再読み込み時にカスタムパーサーを必要としません。また、エージェントは直前のプレゼンテーション呼び出しから「最初のホテル」のような情報を正確に特定できます。トークンレベルでのストリーミング処理では、eager_input_streaming: true を設定することでサーバー側のバッファリングをスキップし、スキーマの保証を維持したまま高速化を実現します。

解説：5 つの意思決定とインタラクティブ性

レイテンシ、キャッシュ、メモリ管理

レンダリングされた応答は 500〜700 トークン程度になります。ストリーミング処理を行わない場合、これは約 5 秒間のローディングスピナー表示を意味します。Anthropic は、エンドツーエンドのレイテンシとユーザーが感じる待ち時間（知覚されるレイテンシ）を明確に区別しています。コンポーネントが形成され次第ストリーミングで配信し、同時に平易な言葉による進行状況を表示することで、待ち時間のストレスを軽減します。

ツール呼び出しを即座に実行する「eager tool dispatch」は、引数のストリーミング完了と同時に各呼び出しを実行する仕組みです。これは Agent SDK のデフォルト動作であり、複数の秒単位の遅延を数百ミリ秒レベルまで短縮できることが報告されています。

コスト削減の鍵となるのはプロンプトキャッシングです。リクエストは「グローバル→セッション→揮発性」の順に処理されます。これはキャッシュがプレフィックスベースであること、そしてシステムプロンプトの先頭にタイムスタンプを配置すると毎回キャッシュが無効化されるためです。

キャッシュされた読み取りコストは新規トークンの 10 分の 1 ですが、書き込みには約 1.25 倍のプレミアムがかかります。最適なデプロイメントではヒット率が 90〜99% に達します。メモリの抽出プロセスは別プロセスで非同期に実行され、Anthropic の測定によると、その場で保存するツールと比較して事実の想起率が 13% 向上しました。

キーポイント

• ショッピングおよびマーチャントエージェント向け Apache 2.0 ブループリント。4 つの業界（小売、旅行、通信、エンターテインメント）に対応し、Claude Code プラグインも用意されています。
• Anthropic のデプロイメントでは、1 つのエージェントループにスキルを追加する構成が、サブエージェントや単一プロンプトによる設計よりも優れた結果を示しました。

• UI コンポーネントは型付きツールとして提供されるため、履歴はネイティブなまま保たれ、レイアウトの解決も容易になります。

• プロンプトキャッシングでは 90〜99% のヒット率を目標とし、揮発性のデータは最後（先頭ではなく）に配置します。

• お金、書き込み操作、ID 関連の処理はコード上でゲート制御されます。モデルが提案し、ハネス（枠組み）が適用する仕組みです。

Anthropic が「Claude コマースエージェント」を公開しました。小売、旅行、通信、エンターテインメント分野にわたるショッピングおよび販売者エージェントのための Apache-2.0 ライセンスの設計図です。

この発表は MarkTechPost で最初に紹介されました。