Claude

Claude のコマースエージェント・ブループリント — 参照実装が GitHub で公開、Shopify や Visa も名を連ねる

Anthropic が、Claude 上でコマースエージェントを構築するためのブループリントを公開した。実装一式は GitHub の anthropics/commerce-agents で公開され、小売・旅行・通信・チケットの業種別デモが付く。ショッピングエージェントはカタログ検索、複数商品の組み立て、カート構築とチェックアウト連携、注文追跡や返品対応までを担い、操作的なアップセルを防ぐガードレールが組み込まれている。マーチャントエージェントは売上分析、在庫アラート、価格・プロモーション提案を行い、提案された変更には人間の承認を挟む。デプロイ先は Messages API、Agent SDK、Managed Agents(ベータ)、Amazon Bedrock、Microsoft Foundry、Google Cloud Vertex AI。パートナーとして Shopify、Priceline、Accenture、Mastercard、Visa が挙がる。導入顧客ではカートが最大35%大きく、購入完了率が60%高くなったとしている。価格は非公表。

ニュース原文を読む ↗

要約

2026-09-02、Anthropic が Claude でコマースエージェントを構築するためのブループリントを公開しました。

特徴は、これがドキュメントではなく実装だという点です。 一式が GitHub の anthropics/commerce-agents で公開されており、小売・旅行・通信・チケットの業種別デモが動く形で用意されています。同日、設計思想を解説する記事「A guide to the anatomy of effective commerce agents」も併せて公開されました。

成果として挙げられている数字は、Claude を使った買い物エージェントの導入顧客で、カートが最大35%大きくなり、購入完了率が60%高くなったというものです。

構成は2つのエージェントに分かれます。

ショッピングエージェント——買い物客に向く側です。カタログ検索と複数商品の組み立て、顧客の好みに応じたパーソナライズ、会話の中での商品表示と比較、カート構築とチェックアウト連携。さらに、注文追跡・返品・返金ポリシーといったカスタマーサービスまで含みます。

ここに一つ、設計上の主張が入っています。 操作的なアップセル(manipulative upsell patterns)を防ぐガードレールが組み込まれていると明記されています。売上を最大化する方向へ素直に最適化しない、という選択が既定に埋め込まれているということです。

マーチャントエージェント——事業者に向く側です。売上分析、在庫の追跡とアラート、価格・プロモーションの提案、マーケティング施策のドラフト作成。

こちらにも設計上の主張があります。 提案された変更には人間による承認(human-in-the-loop)を挟む。 価格を提案はするが、勝手には変えない、という構造です。

デプロイ先は広く取られています。 Claude Messages API、Claude Agent SDK、Claude Managed Agents(ベータ)、Amazon Bedrock、Microsoft Foundry、Google Cloud Vertex AI。 カスタマイズ用の Claude Code プラグインも含まれます。

パートナーの顔ぶれが、この発表の重さを示しています。 Shopify、Priceline、Accenture、Mastercard、Visa。 さらに Intuit、Klaviyo、Wix、Zomato、Fetch、Square からも支持が示されています。EC プラットフォームと決済ネットワークの双方が並んでいる点が、単なる技術デモとの違いです。

価格は公表されていません。 営業への問い合わせに案内されています。

何が変わったか

  • コマースエージェントの参照実装が GitHub(anthropics/commerce-agents)で公開。小売・旅行・通信・チケットの業種別デモ付き
  • ショッピングエージェント: カタログ検索、複数商品の組み立て、パーソナライズ、会話内での商品表示・比較、カート構築とチェックアウト連携、注文追跡・返品・返金対応
  • 操作的なアップセルを防ぐガードレールが既定で組み込まれている
  • マーチャントエージェント: 売上分析、在庫追跡とアラート、価格・プロモーション提案、マーケティング施策のドラフト
  • 提案された変更には人間の承認を挟む設計
  • デプロイ先: Messages API / Agent SDK / Managed Agents(ベータ)/ Amazon Bedrock / Microsoft Foundry / Google Cloud Vertex AI。Claude Code プラグインも同梱
  • パートナー: Shopify、Priceline、Accenture、Mastercard、Visa(ほか Intuit、Klaviyo、Wix、Zomato、Fetch、Square)
  • 導入実績として カート最大35%増、購入完了率60%向上
  • 価格は非公表(営業問い合わせ)

業務インパクト(一般企業向け)

EC を持っている企業にとって、これは「作るかどうか」の判断材料が一段揃った、という意味を持ちます。

これまで、コマースエージェントの構築は見積もりが立ちにくい領域でした。 カタログ検索、在庫連携、カート、決済、返品対応——どこまで作れば使い物になるかが、やってみないと分からない。 その不確実性が、そのまま見積もりの幅になっていました。

参照実装が公開されると、ここが変わります。 「何が必要か」のリストが、動くコードとして手元に来る。 自社に足りない部分だけを見積もればよくなります。ゼロからの設計ではなく、差分の設計になる——これが実務上のいちばん大きな変化です。

ただし、流用の仕方には注意が要ります。

この実装には、二つの「あえてそうしている」設計が入っています。 アップセルの抑制と、事業者側変更への人間承認です。

どちらも、素直に最適化すれば入らないものです。 売上を最大化するなら、アップセルは強く出した方がよい。運用を効率化するなら、価格変更は自動で反映した方が速い。それを、意図して止めてある。

理由を理解しないまま外すと、目先の数字は上がって、後で問題になります。

アップセルの抑制については、示されている数字自体が答えになっています。 カート35%増、購入完了率60%向上——購入完了率が上がっている点が重要です。押し売りをすると、カートは大きくなっても完了率は下がります。両方が上がっているということは、押していないということです。

人間承認については、リスクの非対称性の問題です。 価格やプロモーションの誤りは、気づいたときには既に売れています。 ロールバックできません。承認を挟むコストは毎回発生しますが、事故のコストは一度で回収不能——この形をしたリスクには、承認を挟むのが定石です。

パートナーの顔ぶれからは、別のことが読めます。

Shopify と Visa / Mastercard が同じ発表に並んでいる。 これは、エージェント経由の購買が、決済側の想定に入り始めていることを示します。

エージェントが代理で決済する取引は、従来の不正検知の前提と噛み合いません。 人間の操作パターンを前提にした検知は、エージェントを不正と見なしうる。決済ネットワークが最初から関与しているのは、その調整が必要だからです。

自社が EC を持っているなら、確認すべきことが一つあります。 決済代行やカート側が、エージェント経由の取引をどう扱う方針か。 現時点で明確な答えがない事業者も多いはずですが、質問しておくこと自体に意味があります。 後から「うちは対応していません」と言われる方が高くつきます。

価格が非公表である点は、率直に不便です。 参照実装は無料で読めますが、Claude の利用料は使ってみないと分かりません。 会話型の商品探索はトークンを多く消費します。PoC の段階で、1セッションあたりの実コストを必ず測ってください。 転換率が上がっても、1件あたりの推論コストがマージンを食えば、意味がありません。

副業・個人活用視点

個人や小規模で EC 支援をしている人にとって、この公開は正直なところ好機です。

理由は、参照実装が「読める」からです。

EC のエージェント構築は、これまで大手の案件でした。 設計から作るには規模が要る。しかし参照実装があると、「読んで、理解して、小さく当てる」ができるようになります。

具体的に何ができるか。

まず、業種別デモを実際に動かして中身を読むこと。 小売・旅行・通信・チケットの4つが用意されています。このうち一つでも、構造を人に説明できる状態になれば、それは提案の武器になります。

次に、部分適用の提案。 フルのショッピングエージェントを入れる必要はありません。カタログ検索だけ、返品ポリシーの応答だけ、在庫アラートだけ——参照実装から一部を切り出して当てるのは、小規模案件として現実的です。

「Anthropic の参照実装をベースにしています」と言えること自体に価値があります。 ゼロから作った独自実装より、出所が説明できる方が、クライアントは安心します。

マーチャントエージェント側は、さらに小さく始められます。

売上分析、在庫アラート、価格提案。 これらは表に出ないので、失敗しても顧客に見えません。 エージェントを初めて入れる先としては、リスクが低い。社内向けから始めて、実績ができてから顧客接点へ広げる——この順序は、提案として通しやすいはずです。

一方で、正直に見ておくべき制約もあります。

価格が非公表で、実コストが読めない。 個人で提案するとき、「いくらかかりますか」に答えられないのは弱い。 PoC でトークン消費を実測してから、月額の目安を出す——この工程を見積もりに入れておかないと、後で自分が被ります。

そして、決済まわりは軽く扱わないこと。 カート構築とチェックアウト連携は、参照実装があっても責任範囲が重い部分です。 金額が絡む処理で、エージェントの判断が入るところは、必ず人間の確認を通す設計を維持してください。 参照実装がそうしているのには理由があります。

最後に、学習素材としての価値を強調しておきます。

「実務で使われるエージェントがどう設計されているか」を読める機会は、そう多くありません。 論文でもチュートリアルでもなく、Shopify や Visa が名を連ねる文脈で公開された実装です。

ガードレールがどこに置かれているか。人間の承認をどこで挟んでいるか。何を自動化して、何をあえて自動化していないか。 この線の引き方こそが、エージェント設計でいちばん学びにくい部分です。無料で読めるうちに、時間を取って読む価値があります。

claude エージェント ec コマース agent-sdk 参照実装