Claude Commerce Agents｜導入検証案件の指標と見積もり

2026-09-02の公開で確認できるClaude Commerce Agentsの範囲

2026年9月2日、Claudeの公式ブログで、買い物と商取引を支援するClaude Commerce Agentsの参照例が公開されました。発表日は記事の日付と、同日19:33ごろの公式開発者アカウントによる告知で確認できます。

公式ブログの説明では、顧客向けの買い物側は、自然な言葉で商品を探し、比べ、複数商品を組み合わせ、カートを作り、注文や返品方針の質問にも答えます。支払いそのものは既存の購入画面などに残す考え方です。公式ブログが示すのは、会話を入口にした購買体験の設計です。

もう一つは店舗運営側です。販売状況や在庫を確認し、価格・販促の案を出し、必要な変更は人が承認してから反映します。小売、旅行、通信、チケット領域の参照例が用意されているため、EC専用の話に閉じず、予約や契約内容の変更を扱う案件にも読み替えられます。

顧客向けと事業者向けを別の案件として見る

提案時に「買い物AI」と一語で括ると、画面上の会話だけが見積もり対象になりがちです。顧客向けは商品情報・在庫・カート・注文履歴・返品方針を正しく参照する仕事、事業者向けは売上・在庫・価格・販促を読み、変更案を整理する仕事です。必要なデータも承認者も違うので、最初から一つの大型案件として扱わないことが大切です。

参照リポジトリのREADMEには、掲載された会社・ブランド・商品・人物は架空で、注文、カード決済、公開中の掲載情報変更は行わないと明記されています。カートはホスト側が購入を完了し、事業者側の変更は承認待ちとして保持されます。提案の安全な初期範囲を考えるうえで重要な前提です。参照リポジトリ

35%・60%は発表の数字として位置づける

公式ブログと補足投稿で示されたのは、買い物エージェントを使う小売業者で、カート金額が最大35%大きく、購入完了に至る可能性が60%高かったという説明です。ここで重要なのは「最大」「可能性が高い」という表現であり、すべての店舗で同じ増加が出る意味ではありません。

対象企業、対象商品、利用者数、比較期間、購入完了の分母、広告や季節要因の扱いは、共有された発表だけでは判断できません。したがって35%や60%をそのまま提案書の成果欄に置かず、顧客の現状値と同じ分母で測るための仮説として使います。

「買い物できるAI」を顧客のどの業務課題から小さく試すかを決める

案件化の入口は、AIで何でも買える画面を作ることではありません。顧客がすでに困っていて、回答材料がそろい、間違えたときに人が戻せる業務を一つ選びます。ECなら商品検索と比較、旅行なら条件整理と候補提示、予約なら空き状況の案内、問い合わせ対応なら返品や配送方針の確認から始めると範囲を測りやすくなります。

注文確定、返金、顧客情報の変更、価格の公開変更は、結果が戻しにくいか影響が大きい領域です。最初の試行では、回答と候補整理からカート作成の手前までに留め、顧客が既存の確認画面で最終判断できるようにします。これなら品質の問題を見つけても、売買の完了と切り離して修正できます。

最初は「答えやすく戻しやすい」業務を選ぶ

候補を選ぶときは、正しい情報源を一つに寄せられるか、間違いを人が短時間で訂正できるか、利用前後の数字を取れるかを確認します。商品検索なら商品名・価格・在庫・配送条件が揃っているか、問い合わせ対応なら返品期限や送料の根拠が現行の案内と一致しているかを見ます。情報が古いまま会話だけ整えても、顧客の不安は減りません。

「注文まで一気に任せる」提案は目を引きますが、最初の検証単位としては広すぎます。検索、比較、在庫質問、よくある方針の回答のように、結果を確認して戻せる業務を選ぶ方が、誤案内の発見と改善点の切り出しがしやすくなります。予約案件でも、空き枠の候補提示と確定操作を分ける考え方が有効です。

初回ヒアリングで集める4つの現在値

顧客への聞き取りは、次の順で数字と責任者を確認します。

1. 商品検索からカート、購入開始までの各段階で、どこに離脱が多いかを確認する。
2. 商品・在庫・配送・返品に関する問い合わせが、月に何件あり、何分で回答されているかを確認する。
3. 価格違い、在庫違い、方針の誤案内が、どの程度見つかり、誰が修正しているかを確認する。
4. 購入確定、返金、顧客情報変更などで、最終的に承認する担当者と連絡経路を確認する。

この聞き取りで、数字が取れない箇所も価値ある発見になります。たとえば問い合わせ件数は分かっていても、質問の種類や回答にかかった時間を記録していない顧客は少なくありません。検証案件では、会話画面の提供と同時に、次回以降も比較できる記録方法を成果物へ含めます。

公式の35%・60%を自分の案件の指標へ具体的に翻訳する方法を考える

35%・60%を自分の案件に置き換えるときは、数値を大きく見せることより、比較可能な形に直すことが先です。公式の数値は発表の文脈で示された参考値であり、顧客のKPIを代行しません。まず導入前の基準期間、試行する商品群、対象画面、集計担当を決め、同じ定義で前後を並べます。

購入完了率とカート金額を同じ条件で測る

購入完了率は「購入完了数÷決済開始数×100」、平均カート金額は「カート内の商品金額合計÷カート数」と定義できます。顧客が普段使う分析の分母と違う場合は、どちらを正式値にするか開始前に決め、途中で都合よく変更しないことが重要です。

この表はあくまで定義例です。カートを作らずに商品比較だけを試す案件なら、比較後のクリック率や問い合わせ率を主指標に置きます。公式発表と同じ35%・60%を再現できるかではなく、顧客が選んだ課題に対して、導入前より良くなったかを判断できる形にすることが目的です。

比較期間と対象商品を固定する

導入前後で商品群が変わると、AIの影響と品ぞろえの影響を区別できません。最初は代表的な商品群、よくある質問、一定の価格帯などを決め、同じ期間の平日・休日を含めて比較します。季節イベント、値下げ、広告出稿、在庫切れがあった日は注記し、数値だけを切り出して評価しないようにします。

検証期間は、開始前に「対象セッション数」「監査する会話数」「人が確認する頻度」を書面で決めます。利用数が少ない場合は、率だけでなく、誤りの件数や回答時間の中央値も併記します。母数の小さい案件で数ポイントの変化を大きな成功と扱うと、次の判断を誤るためです。

売上だけでなく人の確認コストを残す

会話が増えて購入完了率が上がっても、担当者が毎回手直ししていれば、顧客の運用負担は減っていません。人が回答を確認した時間、修正した回数、担当者へ引き継いだ割合、価格・在庫・返品の誤り件数を一緒に記録します。エンジニア側も、問い合わせの分類、データ修正、再確認にかかった時間を残すと、改善費用の根拠になります。

特に誤案内率は、すべての会話を調べなくても、一定数を毎回同じ基準で監査すれば傾向を追えます。監査対象の選び方、正解とみなす資料、問題が見つかったときの停止条件を顧客と合意しておくと、結果を売上の報告だけで終わらせず、品質改善の提案へつなげられます。

エンジニアが任せる範囲と商取引で人が承認する範囲を顧客と先に決める

商取引の案件では、回答が自然でも、価格・在庫・配送・返品が一つでも古いと信頼を失います。そこで、AIに任せる範囲は「参照して整理する仕事」、人が承認する範囲は「金銭・個人情報・外部の状態を変える仕事」と先に線引きします。画面を作ってから考えるのではなく、見積もりの条件に含めるべき判断です。

情報整理と状態変更を分ける

商品候補の提示、比較表の作成、在庫や配送方針の案内、問い合わせ内容の分類は、根拠となる情報を表示しながら任せやすい領域です。一方、注文の確定、支払い、返金、顧客情報の更新、価格や在庫の公開変更、販促の開始は、必ず人の確認を挟みます。公式の参照リポジトリも、カートを購入画面へ渡し、事業者側の変更を承認後に反映する前提です。

4つの確認関門を先に置く

関門は会話の後付けの注意書きではなく、試行開始の条件として書きます。役割と確認資料を次の順でそろえると、顧客との認識がずれにくくなります。

1. 商品・価格・在庫の参照元を決め、更新時刻と表示単位を確認する。
2. 配送、返品、交換、予約変更の方針を決め、回答の根拠となるページを指定する。
3. 注文履歴や顧客情報を見てよい場面を分け、不要な情報を会話へ持ち込まない。
4. 注文・返金・公開変更を承認する担当者、取り消し方法、緊急連絡先を決める。

この4点を確認できない顧客には、まず公開カタログの検索や一般的な方針案内だけを提案します。情報の所在や承認者が未確定のまま範囲を広げると、画面の完成後に追加確認が発生し、見積もりの前提が崩れやすいためです。

顧客への説明責任を一枚にまとめる

顧客へ渡す資料には、AIが答えられる質問、根拠を示す方法、回答を止めて人へ渡す条件、最終判断をする担当者を一枚でまとめます。「購入できます」と表示するのか、「カートを準備できます」と表示するのかでも、利用者の期待は変わります。購入確定や返金を行わない試行なら、その制限を画面と説明文の両方で示します。

受託側が確認する資料、顧客側が承認する操作、問題が起きたときの連絡方法を分けて書くと、責任の所在も明確になります。これは安全性のためだけでなく、修正回数や確認時間を見積もりに含めるためにも必要です。

検証結果を見積もりと改善契約、受託案件の単価へつなげる手順を顧客と共有する

検証を無料の相談で終わらせず、成果物と判断条件を分けて提示すると、作業量に根拠が出ます。ここでいう2週間は売上を保証する期間ではなく、対象業務を限定し、仮説を測り、次の判断を出す期間です。顧客と受託側がそれぞれ何を準備するかも、開始前に書きます。

2週間の検証を組む手順

次の手順なら、対象を広げすぎず、結果を次の提案へ持ち越せます。

1. 対象を一つに絞る。商品群、利用画面、対象顧客、試行期間を決め、注文確定や返金を範囲外にする。
2. 現状値と評価基準を確定する。平均カート金額、購入完了率、問い合わせ率、誤案内率に加え、確認時間を記録する。
3. 商品情報と方針資料を点検する。代表質問を20〜30件作り、正解、根拠、回答を止める条件を顧客と確認する。
4. 小さい範囲で試す。対象商品と利用者を限定し、決めた頻度で会話を監査し、問題があれば記録して修正する。
5. 最終報告で判断を分ける。継続、対象拡大、課題の絞り直し、停止のいずれかを数字と確認事項から提案する。

見積もりを4つの成果物に分ける

日数は顧客のデータ状態や画面数で変わるため、以下は少人数チームが一つの業務を2週間試す場合の例です。日単価を8万円と仮定すると、8〜13人日は64万〜104万円が目安になります。外部サービス費、顧客側のデータ整備、法務・個人情報の確認は別枠として明記します。

見積書には、対象商品数、対象画面数、顧客が用意する資料、監査する会話数、修正回数の上限、承認会議の回数を書きます。「AIを導入する費用」とだけ書くと、商品情報の整理や回答基準の確認が後から膨らみます。作業と成果物を対応させれば、値下げではなく判断材料を納品する案件として説明できます。

結果を改善契約と単価の根拠に変える

購入完了率や平均カート金額が改善し、誤案内率と確認時間も許容範囲なら、対象商品、窓口、質問の種類を一つずつ広げます。増やすたびに同じ指標と承認関門を引き継ぐため、改善作業を月次の確認、資料更新、会話監査、次の提案に分けて継続契約へできます。

数字が伸びなかった場合も、失敗で終わりではありません。商品情報の不足、在庫更新の遅れ、顧客が求める課題とのずれ、確認待ちの長さなど、どこで詰まったかを特定します。対象を検索だけに絞る、質問の種類を減らす、情報整備を先に行うなど、次の小さな案を提示できます。

単価の根拠は、画面の数ではなく、課題整理、測定設計、誤案内の確認、承認者との調整、改善提案までを含む責任範囲です。公式発表の数字を借りて成果を約束するのではなく、顧客固有の現状値を測り、判断可能な記録を残すことが、継続案件と適正な見積もりにつながります。

出典と確認事項：公式発表を案件判断に使うときの留意点

公開範囲と35%・60%の数値は公式情報を優先し、対象企業、期間、分母、計測方法が明らかでない点は本文で留保しました。参照リポジトリに記載されたサンプルの性質と、注文・承認の境界も確認しています。

• Claude公式ブログ：Building commerce agents with Claude
• Claude Commerce Agents 参照リポジトリ
• Claude公式開発者アカウントの告知
• Claude公式開発者アカウントの補足投稿
• Claude公式アカウントの関連投稿1
• Claude公式アカウントの関連投稿2
• Claude公式開発者アカウントの関連投稿3
• Claude関連動画一覧
• 関連動画1
• 関連動画2
• 関連動画3
• 関連動画4
• 関連動画5
• 編集資料: 06_pipeline/inbox/2026-09-03_claude_accounts_diff.md