コマースエージェントの設計解剖：Anthropicの実務ガイドを読む

AI利用の明示
本記事の構成と本文は、OpenAIのコーディングエージェント「Codex」が作成しました。導入判断に使う際は原典と自社の要件も確認してください。

AnthropicのAli ShazalとMatthew Koenが2026年9月2日に公開した「A guide to the anatomy of effective commerce agents」は、オンラインでの購入・販売を助けるエージェントを、構成、速度と費用、本番運用の3面から整理した実務ガイドです。価値は、エージェントの品質をモデル選択だけで説明せず、既存業務システムへの接続、権限の境界、UI、評価までを一つの設計として示した点にあります。

対象は、商品検索やカート作成を助けるshopping agentと、売上分析、在庫、価格、キャンペーンを扱うmerchant agentです。記事はAnthropicが顧客企業との導入経験から得た知見を述べていますが、比較の詳細な評価条件は公開されていません。以下では設計指針として読み、実測値を一般的な効果として扱わないようにします。

中心は「一つの会話を保つエージェント」

原典の基本形は、一つのモデルによるagent loopに、業務別のスキルと既存システムを呼ぶツールを接続するものです。買い物の会話は「候補を比較する→在庫を確認する→返品条件を聞く→カートを直す」のように複数領域をまたぎます。領域ごとにサブエージェントへ引き継ぐと、好み、カート、直前に見せた商品などの文脈を毎回渡す必要があり、情報欠落、トークン消費、遅延が増えます。

Anthropicは複数の企業導入で、単一エージェント＋スキルが巨大な単一プロンプトや領域別サブエージェントより品質で優れ、多くの場合費用や遅延も低かったと報告しています。ただし比較タスク、サンプル数、品質指標の内訳は示されていません。これは「サブエージェントは常に不要」という実証ではありません。原典も、深い調査のように独立した作業領域が必要なタスクや、独自の規制・権限を持つ専用エージェントへの会話引き継ぎを例外に挙げています。

利用者との会話と状態
       ↓
   一つのagent loop
    ├─ よく使う共通規則・検索手順：system prompt
    ├─ 低頻度の業務手順：skill
    └─ 検索・在庫・カート・価格など：既存systemを呼ぶtool
       ↓
   検証済みのUIと承認画面

プロンプトとスキルの境界は利用頻度で決める

スキルを読むには追加のモデルの応答が必要です。そのため原典は、トラフィックの約3分の1以上で必要な指示はシステムプロンプト、それ以外はスキルを出発点として勧めています。これは固定の最適値ではなく、実際の利用分布と評価で調整するための目安です。商品検索は多くの買い物で使うためプロンプト側に置き、返品対応や長期的な購入計画はスキルへ分ける、といった設計です。

安全・法務上の必須規則、ブランド制約、アレルギーのような重要な利用者情報は、頻度だけでスキルへ追い出しません。ページ遷移などから次のスキルを予測できるなら、初回モデル呼び出し前にharness側で読み込む方法も示されています。

ツールは既存の業務logicを呼び、表示は型付きで渡す

エージェント用ツールに検索順位、価格計算、配送可否を再実装すると、長年調整してきた業務logicと結果がずれます。原典のsearch_productsは、既存検索システムがランキングした結果を返します。モデルが判断するのは、利用者の目的に合う候補、表示件数、説明の仕方です。ツールの応答はモデルが判断に使うフィールドへ絞り、不要な画像URLなどを大量に文脈へ入れないようにします。

商品carousel、旅程、比較表も自由文をクライアントで解析するのではなく、present_productsなどの表示用ツールとして定義します。モデルが型付き引数を出し、サーバーが検証・補完してUI eventを発行します。ツール呼び出しは会話履歴に残るので、「左から3番目の商品」と後で言われたとき、表示順を再参照できます。そのためツール引数の順序と実際の画面配置を一致させる必要があります。

この方式にはトレードオフもあります。サーバーが各引数を検証する間、細かい単位での表示更新は遅れます。原典は検証を省いて早くストリームする設定にも触れますが、その場合はschema保証が弱まります。表示の速さと不正なUI dataの拒否を、実際の失敗率で比較するべきです。

速度と費用は「完了したタスク」で測る

一回の応答だけを速くしても、エージェントが追加のツール呼び出しを重ねれば全体は遅くなります。原典は完了までの時間を、各モデルの応答の生成時間とツール処理時間の総和として考え、turn数、ツール速度、トークン生成速度の3点を調整します。商品ページから起動したならその商品の情報を先に渡し、独立した検索は同じturnで並列化する。複数のbackend呼び出しをツール内で継ぎ足し続ける場合は、業務システム側に一つの適切なエンドポイントを用意する。これらはモデルの判断力を削らずに待ち時間を減らす設計です。

体感速度には、UI部品の段階的表示や「近くのホテルを探しています」のような短い進捗表示が役立ちます。原典では、通常のcommerce応答を約500〜700出力トークンとし、ストリームがなければ読み込み表示が5秒以上続き得ると説明しています。ここで改善するのは主に最初に画面が動くまでの時間であり、タスクの総処理時間とは区別します。

費用面では、繰り返されるプロンプト前半をキャッシュできるよう、文脈を更新頻度順に置きます。

順序	内容	例
Global	セッション間で共通	共通プロンプト、ツール定義
セッション	同じ利用者の会話内で安定	利用者情報、会話履歴
Volatile	turnごとに変わる	現在時刻、表示中のページ

時刻を共通プロンプトの先頭へ置くと、prefix型キャッシュが毎回切れます。Anthropicは優れた導入例でcache hit率が90〜99%、約10万トークンではキャッシュ読取が約1.5〜2倍速いと述べています。ただし公開された測定条件やトラフィック分布はなく、自社でもこの率に達する保証はありません。費用比較はモデル呼び出し単価ではなく、完了タスクあたりの費用、品質、p50/p99遅延で行うべきだという指摘が重要です。

長期メモリは保存・抽出・読込を分ける

利用者の靴のサイズや店舗の担当者が毎週見る指標は、セッションをまたいで使いたい情報です。原典は、メモリをモデル内部の曖昧な「記憶」ではなく、出所セッションを持つ型付きレコードとして既存データベースに保存する構成を示します。販売側では共有アカウントではなく担当者ごとに記録し、読むときもその人の権限で絞ります。

書き込みは会話の途中でエージェントに保存ツールを呼ばせず、turn後に別の抽出処理で非同期に行います。抽出対象を利用者とassistantの発言に限り、商品説明やレビューに書かれた内容を利用者の事実として覚えないようにします。Anthropicは自社のcommerce memory 評価で、この方式が事実の再現率を13%高めたと報告していますが、比較対象、件数、絶対値は公開していません。

読込は、常に必要な少数の事実、リクエストに応じた事前取得、残りを引くlookup toolの3層です。保存してよい情報の種類、訂正・削除、保持期間も設計に含めます。特にアレルギーのような情報は有用性と個人情報保護の両方に関わるため、保存可否をプロンプト任せにせず書き込み経路で検証します。

最も重要な境界は「提案」と「適用」の間

購入、返金、値下げ、キャンペーン開始は金銭や事業状態を変えます。原典の設計では、モデルが実行を決定するツールを直接持ちません。購買側ではcheckoutがカートと注文ボタンを表示し、決済はhost側が処理します。販売側の変更は一度stagingされ、サーバー発行のIDを使い、人または既存の承認方針を経たapply_changeだけが反映します。適用時には最新の上限を再確認します。

さらに次の条件をharnessのコードで強制します。

書き込みや商品表示に使えるIDは、そのセッションでサーバーがエージェントへ返したものだけにします。購入数や値引き率の上限は各リクエストではなく、変更後の状態に対して確認し、同一セッションの並列書き込みを直列化します。

商品説明、レビュー、販売者メッセージなどを信頼できないデータとして整形・区切り、会話やツール呼び出しを偽装する文を指示として実行しません。手数料や規制上の開示文は承認済みの文面をサーバーから供給し、モデルに言い換えさせない。

この仕組みの要点は、モデルの意図を推測して危険を止めることではなく、権限のない状態変更がAPI上できないようにすることです。ただし、商品IDの出所検証や文字列の整形だけで、すべてのプロンプトインジェクションや業務上の誤判断が消えるわけではありません。後段の評価と運用監視が必要です。

Evalは会話の筋書きより最終状態を見る

原典は、長い模擬会話だけで品質を測るのではなく、会話履歴、ツール結果、カートなどを含むsnapshotから再開する評価を勧めます。採点対象は、最後の表示と書き込み後の状態です。内部で通った手順を細かく固定すると、正しい別経路まで不合格になりやすいためです。模擬利用者との対話は未発見の事例を探す用途に使い、見つけた失敗を再現可能なsnapshotへ移します。

特に用意したいのは、価格・在庫の根拠確認、過去の表示への参照、長く矛盾した履歴、商品説明に仕込まれた指示、上限超過、タイムアウト、空の検索結果です。「応じるべき依頼」と「断るべき依頼」、「すぐ実行する依頼」と「確認が必要な依頼」を対にします。値下げと在庫見通しを同時に聞くような領域横断の依頼も、片方だけ答えて成功と判定しないようにします。

Anthropicは業務担当者や法務・顧客対応担当者とともに、利用者の操作の流れごとに50〜100件を出発点として作ることを勧めています。これは統計的に十分な件数の証明ではありません。利用頻度の高い事例と全安全事例をCIに含め、変更したスキルやツールの周辺事例を追加し、全件の評価は夜間やリリース前に実行する、という運用までが提案されています。

実装を始めるなら

Anthropicはshopping agentとmerchant agentの参照実装を公開しています。retail、travel、telecom、entertainmentの例があり、READMEではPython 3.11以上とNode 22をデモの前提としています。ただし架空企業のサンプルで、認証や実際の決済・業務規則は導入側の責任です。デモをそのまま本番システムへつなぐための完成品ではありません。

自社向けに進めるなら、まず購買側の「検索→比較→カート案」など、一つの流れを読み取り中心で実装します。既存APIをツール化し、商品IDの出所、型付き表示、価格・在庫の根拠を検証します。次に、失敗・矛盾・複数領域のsnapshot 評価を作り、品質と完了タスクあたりの遅延・費用を測ります。その後にメモリと販売側のstaged changeを加え、適用経路で権限、上限、承認を検証します。これは原典をもとにした段階的な導入案で、Anthropicが公開した実験手順ではありません。

原典の知見には適用範囲があります。単一エージェント優位、cache hit率、メモリ改善の数値はAnthropicの導入・内部評価に基づき、詳細な比較条件や独立した再現結果は示されていません。また、モデルやAPIの設定、費用、遅延は更新されます。自社のカタログ規模、会話の複雑さ、地域ごとの個人情報要件、承認手順を入れた評価で判断する必要があります。

まとめ

このガイドで中心となるのは、一つの会話を保つエージェントにスキルと既存システムのツールを与え、表示・メモリ・変更適用をharness側の明示的な契約にすることです。速さはturn全体と体感表示の両方で、費用は完了タスク単位で、安全性は変更後の状態と承認経路で測ります。モデルを交換しやすい設計にするには、プロンプトを整えるだけでなく、業務上の正しさを検証できる評価を先に持つことが欠かせません。

参照

Ali Shazal, Matthew Koen, A guide to the anatomy of effective commerce agents, Anthropic, 2026-09-02.
Anthropic, commerce-agents reference implementation, GitHub. 本記事ではREADMEに記載された構成とdemoの前提を参照。