商品を探して比較し、カートに入れて、返品の相談にも答える。そんな買い物用のAIエージェントを作ろうとすると、どの会社も似たような土台を一から組み直すことになります。Anthropicはその土台をコードとして公開しました。リポジトリ anthropics/commerce-agents には、消費者向けと店舗運営者向けの2種類のエージェントが入っており、ライセンスはApache 2.0です。

2種類のエージェントと4つの業種

公開された設計図には、性格の異なるエージェントが2つ含まれます。

1つは買い物客向けのエージェントです。小売事業者のアプリやサイトの中で動き、カタログを検索し、複数商品の注文をまとめて扱い、選択肢を比較し、カートを組み立てます。注文状況や返品の質問も、会話の流れを切らずに同じ場で答えます。導入する側は、自社のカタログやカート、注文、ポリシーの各システムに合わせて StorefrontBackend を実装する形になります。

もう1つは店舗運営者向けのエージェントです。売上の伸び悩みの理由を尋ねたり、在庫の警告を受け取ったり、価格や販促の見直し案を出させたり、キャンペーンの原稿を書かせたりできます。こちらは MerchantBackend が接続点になります。

そのうえで、小売、旅行、通信、娯楽の4業種について、そのまま動かせる実装例が同梱されています。Python 3.11以降とNode 22、それにAPIキーがあればローカルで起動でき、Claude APIのほかAmazon Bedrock、Microsoft Foundry、Google Cloud Vertex AIでも同じコードが動く設計です。Claude Code向けのプラグイン commerce-builder も用意され、新規エージェントの雛形生成と既存エージェントの点検をコマンドで実行できます。

サブエージェントに分けない、という判断

技術的にいちばん議論を呼びそうなのは、構成の選び方です。Anthropicは、意図を振り分けるルーターを置いたり、領域ごとにサブエージェントを立てたりする作りに反対の立場を取りました。

理由は単純で、買い物の会話は分割しにくいからです。カートの中身、客の好み、これまでのやり取りは親エージェントが抱えており、別のエージェントに引き渡すたびに情報が落ちます。引き渡しはトークンを何倍にも膨らませ、応答に数秒を上乗せします。そもそも領域も重なり合っていて、返品の相談ひとつ取っても注文履歴とカートとカタログを同時に見る必要があります。

代わりに採用されたのが、エージェントスキルです。スキルの指示文は、既に会話履歴を持っているエージェントの中に読み込まれるため、引き渡しの損失なしに機能を分けられます。同社が複数の企業導入で比較したところ、スキル付きの単一エージェントは、巨大な単一プロンプト方式にもサブエージェント方式にも品質で勝り、費用と待ち時間でも有利だったとしています。サブエージェントの出番は、深いリサーチのように独立性の高い作業に限られるという整理です。

システムプロンプトに書くかスキルに切り出すかの線引きは、登場頻度で決めます。全体の3分の1以上の会話に関わる内容はプロンプト側、それ以外はスキル側。安全に関わる規則、ブランドの制約、利用者の重要な属性は、頻度にかかわらず常にプロンプトに置きます。

画面部品をツールとして扱う

買い物の応答は、文章よりも画面部品で返す場面が多くなります。商品カード、旅程表、料金プランの比較表といった具合です。

この設計図では、そうした部品を独自タグではなくツールとして定義しています。present_products や present_itinerary のようなツールを呼び出させ、引数はサーバー側で型検証してから画面に渡します。ツール呼び出しは会話履歴にそのまま残るので、履歴を読み直すのに専用の解析処理が要りません。利用者が「最初のホテルにして」と言ったときに、直前の提示内容から特定できるのも同じ理由です。

待ち時間とコストの詰め方

体感速度への配慮も具体的です。1回の応答は出力500から700トークン規模になり、そのまま待たせると読み込み表示が5秒近く続きます。設計図では部品を組み上がった順に流し込み、進行状況を平易な言葉で表示することで、実際の処理時間とは別に体感の待ち時間を短くします。引数が届いた分からツール呼び出しを実行する方式では、数秒単位の空白が数百ミリ秒まで縮んだとされています。

費用面の主役はプロンプトキャッシュです。キャッシュは先頭一致で効くため、要求は変化しない情報から順に並べます。システムプロンプトの冒頭に時刻を入れるような書き方は、毎回キャッシュを壊してしまうので避けます。キャッシュ済みの読み出しは通常のトークンの10分の1の費用で済み、書き込み時は1.25倍程度の割増がかかります。うまく組んだ導入例では、命中率が90から99パーセントに達するとされています。記憶の抽出処理も会話の中では行わず別プロセスに逃がしており、会話中に保存する方式より事実の想起率が13パーセント高かったと報告されています。

金銭の移動、書き込み、識別子の扱いはコード側で必ず関門を通す作りです。モデルは提案するだけで、実行の可否はプログラムが決めます。

まとめ

公開された設計図は、買い物エージェントを作るときに誰もが直面する構成の悩みに、Anthropicなりの答えを出したものです。サブエージェントに分けずスキルで機能を足す、画面部品はツールとして型付けする、金銭に触れる操作はコードで止める。年末商戦を前にした発表という背景はありますが、Apache 2.0で公開されている以上、買い物以外の対話型エージェントを設計する人にとっても読む価値のある内容になっています。