Claude Commerce Agentsは、Anthropicが2026年9月2日に無料公開した、Claudeでエージェントを作るための公式の設計図です。正式名称はcommerce-agentsで、買い物客の相手をするショッピングエージェントと、店舗運営を助けるマーチャントエージェントの参照実装が、そのまま動くコードとしてgithub.com/anthropics/commerce-agentsに置かれています。結論から言えば、これは「コマース向けのサンプル」で終わる話ではありません。統合エージェントループ、スキルによる機能分割、段階的な書き込み、3層構成のプロンプトキャッシュといった設計は、社内向けの自作エージェントにもそのまま流用できます。この記事では、編集部が公式ブログとリポジトリを実際に読んで確認した内容をもとに、何が公開されたのか、これまでのエージェント自作と何が違うのか、そしてローカルで動かす手順と自社ツールへの流用までをまとめます。
この記事の要点
- commerce-agentsは、Claudeでショッピングエージェントとマーチャントエージェントを作るための公式リファレンス実装です。小売・旅行・通信・チケットの4分野の例が含まれ、Apache License 2.0のもとでリポジトリとして無料公開されています。
- 設計の肝は「1つのモデルを1つのエージェントループで回し、機能はスキルとして差し込む」という統合型です。断片化したサブエージェントに分けず、会話の文脈を保ったまま複数の意図をさばく考え方で、コマース以外の自社エージェントにも流用できます。
- ローカルでの起動はクローンから数コマンドで完了します。段階的な書き込みとサーバー発行IDによるガードレールで、価格変更や決済のような危険な操作を安全に自動化する設計が最初から入っています。
01Claude Commerce Agentsとは|Anthropic公式のエージェント設計図
Claude Commerce Agentsは、Anthropicが公開した「Claudeで買い物・店舗運営のエージェントを作るための参照実装」です。ハーネス(エージェントを回す土台のコード)、設計パターン、ガードレール、そして小売・旅行・通信・チケットの4分野で実際に動くショッピングエージェントとマーチャントエージェントが、1つのリポジトリにまとまっています。Anthropicはこれを「blueprint(設計図)」と呼んでおり、ゼロから作らせるのではなく、動く土台を渡して各社が自社のカタログや在庫につなぎ込む、という使い方を想定しています。
公開されたのは2026年9月2日です。Anthropicは同日、エージェント設計の考え方を解説した技術記事もあわせて出しており、コードと設計思想の両方が読める形になっています。ローンチのパートナーとしてShopify、Priceline、Visa、Mastercard、Accenture、Intuit、Klaviyo、Wix、Zomato、Fetch、Squareの名前が挙がっており、参照実装というより、実務での採用を前提にした公開です。
なぜ「サンプル」でなく設計図と呼べる?
単なるデモではなく、本番で必要になる仕組みが最初から組み込まれているためです。カタログ検索・カート・チェックアウト・顧客情報への接続点、価格や商品を実在データに縛るガードレール、プロンプトキャッシュ、ツール呼び出し回数の上限といった、実運用で必ず問われる要素が参照実装に含まれています。Anthropicによれば、あるパートナーのエンジニアは「2つのコマースエージェントを1時間かからずにローカルで動かせた」と述べており、着手から動作までの距離が短いのが特徴です。
02これまでのエージェント自作との違い|差分を表で整理
いちばんの違いは、エージェントの「組み立て方の作法」が公式の推奨として示された点です。これまでClaudeでエージェントを自作する場合、ループの回し方、機能の分割、安全装置の入れ方を各自が手探りで決めていました。commerce-agentsは、そこに「統合ループ+スキル+段階的な書き込み」という型を、動くコードとして提示しています。まず全体像を差分表で示します。
| 項目 | これまでの自作 | commerce-agents | 実務での意味 |
|---|---|---|---|
| 構成 | 機能ごとにサブエージェントを分けがち | 1モデル1ループに統合し機能はスキルで差し込む | 意図をまたぐ会話で文脈が切れにくい |
| 安全装置 | プロンプトで「やらないで」と頼む | サーバー発行IDと段階的書き込みで基盤側に持つ | 決済・価格変更を人手承認まで止められる |
| キャッシュ | 構造を意識せずコストが膨らむ | 全体・セッション・可変の3層に分けて前方一致 | キャッシュが当たりやすくコストと待ちを圧縮 |
| 実装形態 | API直叩きを都度書く | Messages API/Agent SDK/Managed Agentsの3経路 | 手元検証から本番運用まで同じ設計で移せる |
| 評価 | 会話を通しで再現して手で確認 | 状態を作って最終出力だけ採点するスナップショット型 | 壊れやすい経路依存のテストを避けられる |
アウトプットにどんな差が出ると想定される?
ここは編集部が実測した数値ではなく、公式が示す仕様差から想定される範囲として書きます。統合ループは、サブエージェント間の受け渡しで起きるトークンの二重消費や文脈の欠落を避けられるため、「別の話題に切り替えても直前のカートや条件を覚えている」といった一貫性が出やすいと想定されます。プロンプトキャッシュについてAnthropicは、規模が出れば90〜99%のキャッシュヒット率と、およそ10万トークンをキャッシュした場合に1.5〜2倍のトークン処理速度が見込めると説明しています。これは公式による見積もりで、実際の値は構成やトラフィックで変わります。段階的な書き込みは、価格変更や返金のような操作を即時に実行せず、いったん提案として溜めて承認を挟むため、自動化しても事故が本番に届く前で止まる、という差がアウトプット側に出ます。
032つのエージェントの中身|ショッピングとマーチャント
参照実装は、役割の違う2種類のエージェントで構成されています。顧客に向き合うショッピングエージェントと、店舗運営者を助けるマーチャントエージェントです。ここからは、それぞれが何をできるのかを紹介します。
ショッピングエージェントができること
ショッピングエージェントは、顧客向けアプリに組み込んで会話で買い物を進めさせるエージェントです。自然な言葉での指示からカタログを検索し、複数の商品を組み合わせて提案し、会話の中で商品を並べて比較し、カートを操作します。チェックアウトにもつながり、注文の追跡や返品・返金ポリシーといった問い合わせにも答えます。顧客が話した好みを覚えて次の提案に反映する、という記憶の仕組みも入っています。想定される使い方は、小売のカート、旅行の日程、モバイル回線の変更、公演の座席予約などです。
マーチャントエージェントができること
マーチャントエージェントは、店舗運営者側の分析と意思決定を助けるエージェントです。売上の推移や在庫を分析し、品切れやキャンペーンの競合を先回りで指摘します。販売履歴をもとに価格やプロモーションの案を出し、マーケティング施策の下書きも作ります。重要なのは、提案を実行に移す前に必ず人の承認を挟む「人間参加型(human-in-the-loop)」の設計になっている点です。数字を分析させても、価格やキャンペーンを勝手に反映させない、という線引きが最初から引かれています。
| 観点 | ショッピングエージェント | マーチャントエージェント |
|---|---|---|
| 向き合う相手 | 買い物客(顧客) | 店舗運営者 |
| 主な仕事 | 検索・比較・カート・チェックアウト・問い合わせ対応 | 売上分析・在庫監視・価格/販促の提案・施策の下書き |
| スキル例 | 検索・比較・プランニング・カート・チェックアウト | 実績・出品・在庫・価格・キャンペーン |
| 安全設計 | 実在IDのみ表示・第三者コンテンツを隔離 | 提案を段階化し人の承認後に反映 |
04自作に流用できる設計|統合ループとスキルの考え方
この設計図がコマース以外にも通用する理由は、中身がほぼ「安全で速いエージェントの一般論」だからです。Anthropicの技術記事は、コマースに限らずどんな社内エージェントにも当てはまる設計として、統合ループ・スキル・ガードレール・キャッシュ・評価の5点を挙げています。順に見ていきます。
なぜサブエージェント分割でなく統合ループなのか
会話が1つの連続したセッションだからです。Anthropicは、機能ごとにサブエージェントへ受け渡す設計は、受け渡しのたびにトークンを二重に使い、遅延を増やし、ユーザーの目的についての文脈を失う、と指摘しています。1つのモデルを標準的なエージェントループで回し、状態を持ったまま複数の意図をさばくほうが、境界をまたぐ場面で品質が落ちにくい、という考え方です。この判断は、社内の問い合わせ対応や運用自動化のエージェントを設計するときにもそのまま参考になります。サブエージェントとスキルの使い分けの整理は、Claude Codeのスキルとサブエージェントの使い分けもあわせてご覧ください。
スキルとシステムプロンプトの切り分け基準
スキルは、システムプロンプトとは別に必要なときだけ読み込む「指示のかたまり」です。Anthropicは切り分けの目安として、リクエストのおよそ3分の1以上で使う中核機能はシステムプロンプトに置き、それより低頻度の機能はスキルとして必要時に読み込む、という基準を示しています。ショッピングエージェントの例では、土台の検索やカートの仕組みはプロンプト側、発見・リサーチ・パーソナライズ・顧客対応・プランニングはスキル側へ、という振り分けです。スキルの配布や管理の仕組みは、Claude Skills APIでスキルを配布する方法でも扱っています。
段階書き込みとIDゲートで安全に自動化する
危険な操作を基盤側で止める仕組みが、この設計図でいちばん流用価値が高い部分です。ポイントは3つあります。1つ目はサーバー発行IDによるアクセス制御で、そのセッションでサーバーが返したIDだけを書き込みや表示に使える仕組みです。モデルが商品IDを想像で作っても弾かれます。2つ目は段階的な書き込みで、決済・価格変更・返金といった操作は即実行せず、提案として溜めてから人やポリシーの承認を挟み、最新の上限に対して反映します。3つ目は書き込みの直列化で、並列のツール呼び出しが合算して上限を超えないよう、セッション単位で順番に処理します。これらはコマースでなくても、社内データを書き換えるエージェントを安全に自動化するときの土台になります。
3層構成でキャッシュを活かす
プロンプトを「変わらない・安定・毎回変わる」の3層に分けると、キャッシュが当たりやすくなります。Anthropicの推奨は、システムプロンプトとツール定義を先頭(全体層)、ユーザー文脈と会話履歴を次(セッション層)、現在時刻や現在ページなど毎ターン変わる情報を最後(可変層)に置き、それぞれの境界にキャッシュの区切りを打つ、という構成です。先頭に時刻のような可変データを置くと毎回キャッシュが崩れるため、上に積まないのが要点です。この並べ方はコマースに限らず、長い会話を扱う自社エージェントのコスト設計にそのまま使えます。コンテキストを軽く保つ工夫はClaude 5のコンテキストを削減した実例も参考になります。
05ローカルで動かす手順【実践:自社ツール開発】
ここからは、効率化のための自社ツール開発の視点で、実際にローカルで動かす手順を紹介します。編集部が公式リポジトリのREADMEで確認した内容をもとに、クローンから起動までをコマンドで示します。まず動かして、設計を自分のツールに移すときの土台にする、という進め方が現実的です。
前提とセットアップ
必要なのはPython 3.11以上、Node 22、そしてAnthropicのAPIキーです。次のコマンドで、クローンから依存関係のインストール、環境変数の設定までを行います。.envに自分のAPIキーを書く点だけ忘れないようにします。
git clone https://github.com/anthropics/commerce-agents.git && cd commerce-agents
python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
cp .env.example .env # ANTHROPIC_API_KEY を書き込む
(cd examples && npm ci) # フロント側の依存をインストール
ショッピングエージェントを起動する
デモ用のスクリプトで、分野を指定して一気に起動できます。小売なら次のコマンドで、APIが8000番、ストアフロントが3000番で立ち上がります。旅行・通信・エンタメの分野も用意されています。
python scripts/run_demo.py retail # API :8000 / storefront :3000
セットアップでつまずきやすい点
依存のインストールでは、Pythonの仮想環境を有効にしたか、Nodeのバージョンが22かをまず確認します。APIキーの書き込み先は.envで、.env.exampleをコピーしてから編集する順番を守ると、キーの設定漏れが起きにくくなります。
1回だけ会話を試したいときは、Agent SDK経由の入口を使うと手早く確認できます。テント2人用を予算内で探させる、といった具体的な指示をそのまま渡せます。
python shopping-agent/runtime-agent-sdk/main.py --once "2人用テントを250ドル以内で"
マーチャントエージェントと承認フロー
マーチャント側を起動すると、提案された変更をy/Nで承認する対話になります。段階的な書き込みが実際にどう動くかは、このコンソールで手を動かすといちばん分かります。分野を指定したスモークテストも用意されています。
python merchant-agent/runtime-agent-sdk/main.py # 変更提案を y/N で承認
python scripts/smoke_chat.py --vertical travel # 会話の疎通確認
リポジトリはcommerce-common(共通の設定・記憶・スキル・実行部)と、ショッピング/マーチャント各エージェントのコア・ランタイム・Managed Agents用マニフェストに分かれています。スキルは各エージェントのskills/配下にディレクトリで置かれ、1つのスキルがSKILL.mdという定義ファイルを持ちます。自社用にスキルを足すときは、このSKILL.mdの形をまねて1ディレクトリ追加する、という流れになります。MCPサーバーを自作してつなぐ土台はMCPサーバーを自作する最短ルートにまとめています。
06サイト制作・社内ツールへ流用する【実践】
この設計図は、コマースの現場だけでなく、サイト制作と社内ツール開発の両方に持ち込めます。ここでは、実務で試せる粒度に落として2つの流用先を紹介します。
ECサイト制作でストアフロントに組み込む
EC寄りのサイトを作るなら、ショッピングエージェントのストアフロント(3000番で立ち上がるフロント)を土台に、自社のカタログAPIへ接続点を差し替える形が近道です。参照実装は、カタログ・カート・チェックアウト・顧客情報への接続点があらかじめ切ってあるため、制作側は「どこに何をつなぐか」を読み解くところから始められます。UIはpresent_itineraryのような表示用のツール呼び出しとして組まれており、独自マークアップで描くのではなく、型のあるコンポーネントとして返す設計です。これにより、あとから「さっきの3つ目」と会話で参照でき、ページを再読み込みしても並びが崩れません。制作物にAI由来の崩れを持ち込まない考え方は、DESIGN.mdでAIのUI誤生成を止める方法もあわせてご覧ください。
接続点を差し替える順番
いきなり全部をつなぐより、まずカタログ検索の接続点だけを自社APIへ差し替えて表示を確認し、次にカート、最後にチェックアウトへと進めると、どこで挙動が変わったかを切り分けやすくなります。参照実装は接続点があらかじめ切り分けられているため、1か所ずつ置き換える進め方に向いています。
社内エージェントに設計を転用する
コマース色を外して、社内の運用エージェントに設計だけ移すこともできます。たとえば「社内データを分析して施策を提案するが、実行前に必ず人が承認する」ツールは、マーチャントエージェントの段階的な書き込みとそのまま同じ構造です。手順としては、まずリポジトリを動かして承認フローの挙動を体で覚え、次にツール呼び出しを自社システムのAPIに差し替え、危険な操作だけ段階化して承認を挟みます。ツールは自前でロジックを作り直すのではなく、既存システムを呼ぶだけにして、モデルには「どれを選ぶか」の判断だけ任せる、という原則もそのまま使えます。定期実行で無人運用するときの組み方は、Claude Codeの定期実行を自動化する方法が参考になります。
まず承認フローだけ移す
設計をまるごと写すのではなく、危険な書き込みを段階化して承認を挟む部分だけを先に自社ツールへ移すと、小さく試して効果を確かめられます。分析や提案の質は後から詰められますが、承認を挟む安全設計は最初に入れておくほど、あとで事故の芽を減らせます。
07料金・デプロイ・使える場所
リポジトリ自体は無料で公開されており、動かすときにかかるのはClaude APIの利用料です。commerce-agents専用の料金プランは案内されておらず、本番導入の相談はAnthropicの営業窓口へ、という案内になっています。ここでは断定できる範囲だけを表にまとめます。
| 項目 | 内容 |
|---|---|
| リポジトリ | github.com/anthropics/commerce-agents(無料公開) |
| 実装の入口 | Messages API/Claude Agent SDK/Claude Managed Agents(ベータ) |
| デプロイ先 | Claude API/Amazon Bedrock/Microsoft Foundry/Google Cloud Vertex AI |
| 対応分野の例 | 小売・旅行・通信・エンタメ(チケット) |
| 費用 | Claude APIの従量課金(専用プランの案内なし) |
Managed Agentsとしてデプロイする場合は、リポジトリに用意されたスクリプトで各エージェントを配備できます。手元のMessages APIやAgent SDKで検証した設計を、そのままマネージド環境へ移せるのが利点です。
08どんな人・チームに向いているか
まず向いているのは、Claudeで本番のエージェントをこれから設計するチームです。ループの回し方や安全装置をゼロから決める負担を、動く土台で肩代わりできます。次に、ECや予約系のサイト制作で会話型の購入体験を作りたい制作者にも土台になります。そして、コマースと関係なくても「分析はさせるが実行は人が承認する」社内ツールを作りたい人には、段階的な書き込みの設計だけでも読む価値があります。
逆に、単純な一問一答のチャットボットしか要らない場合は、この設計図は過剰です。統合ループやスキル分割は、複数の意図が絡む長い会話や、危険な書き込みを扱う場面で効果が出る設計だからです。作りたいものが1往復で終わるなら、素のMessages APIで足ります。エージェントの土台づくりを他のフレームワークと比べたいときは、MastraでAIエージェントを動かす手順もあわせて検討材料になります。
FAQよくある質問
Claude Commerce Agentsは無料で使える?
リポジトリ自体は無料で公開されています。ただし動かすにはClaude APIの利用料がかかります。commerce-agents専用の料金プランは案内されておらず、本番導入の相談はAnthropicの営業窓口へ、という形です。
コマース以外の用途にも使える?
使えます。統合ループ・スキル分割・段階的な書き込み・3層キャッシュといった設計は、コマースに限らずどんな社内エージェントにも当てはまる一般的な作法です。Anthropic自身も、これらの設計はコマースを超えて一般化できると説明しています。
プログラミングの経験がなくても動かせる?
ローカルで動かすには、Python 3.11以上とNode 22の環境を用意し、ターミナルでコマンドを打つ操作が必要です。クローンから起動までは数コマンドで済みますが、まったくの未経験からだと環境構築でつまずきやすいため、まず開発環境の準備から進めるのが安全です。
Claude Agent SDKとの関係は?
commerce-agentsは、Claude Agent SDKを実装の入口の1つとして使えます。ほかにMessages APIとClaude Managed Agents(ベータ)からも動かせます。手元で試すときはAgent SDKの入口が手早く、本番運用ではManaged Agentsへ移す、といった使い分けができます。
どこにデプロイできる?
Claude API、Amazon Bedrock、Microsoft Foundry、Google Cloud Vertex AIに対応しています。手元のMessages APIやAgent SDKで検証した構成を、同じ設計のままこれらの環境へ移せます。
09まとめ:まずクローンして1つ動かす
Claude Commerce Agentsは、コマース向けの参照実装という見た目ですが、中身は「安全で速いエージェントの作法」を動くコードで示した設計図です。統合ループで文脈を保ち、機能はスキルで差し込み、危険な書き込みは段階化して人の承認を挟み、プロンプトは3層に分けてキャッシュを活かす。この4点は、社内ツールでも制作物でもそのまま流用できます。入れるかどうかで迷うより、まずはリポジトリをクローンしてショッピングエージェントを1つ動かし、承認フローと統合ループの手触りを確かめるのが、いちばん早い判断材料になります。関連して、スキルとサブエージェントの使い分けはClaude Codeのスキルとサブエージェントの使い分け、つなぎ込みの土台はMCPサーバーを自作する最短ルートもあわせてご覧ください。
10出典
- Anthropic「Building Commerce Agents with Claude」(2つのエージェントの機能・実装の入口・デプロイ先・パートナーを編集部が確認)
- Anthropic「A guide to the anatomy of effective commerce agents」(統合ループ・スキルの切り分け・ガードレール・3層キャッシュ・評価の設計を編集部が確認)
- GitHub「anthropics/commerce-agents」README(前提環境・クローンとセットアップ・起動コマンド・ディレクトリ構成・ライセンス(Apache License 2.0)を編集部が確認)
- Digital Commerce 360「Anthropic debuts Claude features focused on agentic commerce」(公開日2026年9月2日を編集部が確認)