［開発者向け］Anthropicがコマースエージェントの設計図を公開——「サブエージェントではなくスキル」という選択

2026-09-07

はじめに

　Anthropicが2026年9月2日、ショッピングエージェントとマーチャントエージェントのリファレンス実装をまとめたブループリント「commerce agents」を公開しました。同日には設計判断を解説した技術記事も公開されています。本稿では、その中身と背後にあるエージェント設計の考え方を解説します。

参考記事

メイン記事:

タイトル: Building commerce agents with Claude
発行元: Anthropic
発行日: 2026年9月2日
URL: https://claude.com/blog/claude-for-commerce-agents

要点

Anthropicは2026年9月2日、コマースエージェントのブループリントを公開した。ショッピングエージェントとマーチャントエージェントの2種のリファレンス実装が含まれる
小売・旅行・通信・チケッティングの4分野に対応し、Messages API、Agent SDK、Claude Managed Agents（ベータ）の3つの実行形態から選べる構成である
Anthropicによれば、Claude上でエージェントを運用する小売事業者では、カート金額が最大35%大きく、購入完了率が60%高くなった例がある
設計指針としては、インテントルーターやドメイン別サブエージェントを置かず、単一のエージェントループにスキルとツールを組み合わせる構成が推奨されている
注文確定・返金・価格変更などの操作はモデルではなくハーネス側で制御し、人またはポリシーの承認を経て実行する設計が示されている

詳細解説

ブループリントに含まれるもの

　Anthropicによれば、公開されたリポジトリにはショッピングエージェントとマーチャントエージェントの動作する実装が含まれ、小売・旅行・通信・チケッティングの4分野のリファレンス実装が用意されています。Messages API、Agent SDK、Claude Managed Agents（ベータ）の3通りで動かすことができ、Claude API、Amazon Bedrock、Microsoft Foundry、Google Cloud Vertex AIといった既存の実行環境に展開できるとされています。エージェントの雛形作成やレビューを行うClaude Code用プラグインも同梱されています。

　ショッピングエージェントは、カタログ検索と複数商品の組み合わせ提案、好みの記憶、カートの構築に加えて、注文状況や返品・返金ポリシーへの回答までを同じ会話の中で扱います。マーチャントエージェントは売上分析、在庫の問題の事前検知、価格や販促の提案、キャンペーンの草案作成を担当します。Anthropicは、Claude上でエージェントを運用する小売事業者において、カート金額が最大35%大きく、購入完了率が60%高くなった例があると説明しています。

単一エージェント＋スキルという設計判断

　技術記事では、前段にインテントルーターを置かず、ドメインごとのサブエージェントも置かない構成が推奨されています。コマースの会話は複数の意図をまたぐ密結合した1つのセッションであり、カートや利用者の好み、会話履歴といった共有コンテキストを多く必要とするためです。サブエージェントへの受け渡しは状態が失われる操作であり、1回の引き継ぎでトークンが数倍になり、秒単位の遅延が加わるとされています。

　代わりに用いるのがエージェントスキルです。スキルの指示は履歴を保持したままの本体エージェントに読み込まれるため、引き継ぎのコストなしにドメインごとの分割ができると説明されています。サブエージェントへの委任をどこまで行うかは他の開発ツールでも論点になってきましたが、状態を持ち越す会話では本体側に寄せるという判断が示された形だと考えられます。ただし例外もあり、深いリサーチのように自己完結した処理は、サブエージェントをツールとして呼ぶ使い方が有効だと補足されています。

　システムプロンプトとスキルの使い分けは、頻度で決めるという指針が示されています。目安はトラフィックの3分の1以上に関わる内容をプロンプトに置き、残りをスキルに回す形です。安全性や法務上のルール、ブランド上の制約、アレルギーのような利用者の重要情報は、頻度にかかわらず常にプロンプト側に置くとされています。

UIコンポーネントをツールとして扱う

　コマースエージェントの応答は、商品カルーセルや旅程、座席表のようなUIコンポーネントが中心になります。技術記事では、モデルに独自タグを生成させてクライアント側で解析する方式ではなく、コンポーネントそのものをツールとして定義する方式が推奨されています。present_products や present_itinerary といったツールを型付きの引数で呼び出し、サーバー側で検証してからクライアントが描画する構成です。

　この方式では表示内容がメッセージ配列にツール呼び出しとして残るため、会話履歴を読み直す際に独自パーサーが不要になり、「最初のホテル」のような画面を指した指示にも直近の表示ツールの引数から応答できると説明されています。トレードオフはストリーミングの粒度です。引数がサーバー側でバッファされるぶん表示が段階的になり、ツール定義に eager_input_streaming を設定すればトークン単位で流せる一方、サーバー側のスキーマ保証は外れるとされています。体感速度と検証のどちらを優先するかの判断が必要になると考えられます。

速度とコストはキャッシュで支える

　技術記事では、タスク完了までの遅延を「ターン数を減らす」「ツールを速くする」「トークンを速くする」の3つのレバーに分解しています。商品ページから起動された場合にそのページのデータをあらかじめセッションに載せる、独立したツールを並列で呼ばせる、といった手法が挙げられています。あわせて、処理中の進捗を平易な言葉で表示するなど、体感的な待ち時間を短くする工夫も推奨されています。

　コスト面で最大の削減余地はプロンプトキャッシュだと説明されています。キャッシュされた入力トークンの読み出しは新規の10分の1のコストで、書き込みには約1.25倍の割増がかかるものの、2回目の利用で元が取れる計算です。Anthropicによれば、優れた運用ではキャッシュヒット率90〜99%が実現されており、その水準を初めから設計目標にすべきだとされています。キャッシュは先頭から一致する範囲までしか効かないため、システムプロンプトの冒頭に現在時刻や現在ページを置くと毎回キャッシュが崩れる点が、よくある失敗として挙げられています。

安全性の担保はプロンプトではなくハーネスで

　安全な振る舞いはプロンプトから始まるものの、コマースでは失敗が金銭的で取り返しがつかないため、プロンプトを強制力の置き場所にはできないと説明されています。注文確定、決済、返金、価格変更、キャンペーン開始はいずれもモデルのツール呼び出しでは完了せず、ハーネス側の操作で完了する設計になっています。マーチャント側では変更が「ステージング」され、承認された識別子に対してのみ適用され、承認時点の最新の上限で再チェックされるとされています。

　書き込みや描画は、サーバーが発行した識別子だけを受け付ける仕組みです。利用者が貼り付けた識別子やレビューに仕込まれた識別子は、バックエンドに届く前に拒否されます。また、出品情報やレビュー、販売者からのメッセージのような第三者が書いた内容は、すべてサニタイズしたうえで固定のラベルで囲んでからモデルに渡すとされています。プロンプトインジェクションを、モデルの判断ではなくコード側の境界で扱う考え方だと言えます。

本番運用でのメモリと評価

　セッションをまたぐ記憶については、モデルではなく自社のデータベースに型付きのレコードとして持つ方式が推奨されています。書き込みは会話の裏で非同期に行う設計で、Anthropicの社内評価では、この方式が事実の再現率を13%高めたと報告されています。記憶する対象を書き込み経路のバリデータで制限すること、利用者が確認・修正・削除できる導線を用意すること、保持期間を定めることといった、個人データとしての扱いも設計項目に挙げられています。

　評価については、会話全体を模擬するのではなく、状態を直接構築して1ターンだけ実行する「スナップショット」形式が推奨されています。「拒否すべき」ケースに対して「応じるべき」ケースを対にして書くことや、混乱した長い履歴から始まるケースを一定割合含めることが挙げられ、業務フローあたり50〜100件が出発点の目安とされています。評価設計まで含めて公開されている点は、実運用を前提とした内容だと考えられます。