AIショッピングエージェントの作り方：ECで安全に実装する設計ガイド

Claude Commerce Agentsには、エージェントループ、スキル、ツール契約、安全ゲート、インターフェースパターンがあらかじめ用意されているため、AIショッピングエージェントの開発をすぐに始められます。ただし、本番化の要点はそこから先です。信頼できる商品カタログと接続し、すべての操作を正しい顧客にひも付け、在庫を常に最新に保ち、決済や取り消せない変更の前でモデルを確実に止める必要があります。

この本番対応に取り組む価値は、成果が数字に表れていることからも分かります。Anthropicによると、Claude上でショッピングエージェントを運用する小売企業では、カートの規模が最大35%大きくなり、購入完了率も60%高まったとされています。もちろん、すべての店舗に同じ成果を約束する数字ではありません。それでも、エージェントを単なるチャットウィジェットではなく、コンバージョンを生むプロダクトとして扱う十分な理由になります。

ブループリントが用意するのは店舗ではなく枠組みです

Claude Commerce Agentsは、二つの役割に対応するApache-2.0ライセンスのリファレンス実装です。顧客と向き合うショッピングエージェントは、検索、比較、複数商品の購入計画、カート作成、ポリシーや注文に関する回答、好みの記憶を担います。一方、店舗側で動くマーチャントエージェントは、業績分析、在庫監視、価格施策の提案、キャンペーン案の作成が可能です。

顧客向けショッピングエージェントの設計は、意図的にシンプルです。一つのモデルがループを実行し、共通ルールはシステムプロンプトに、利用頻度の低い手順は五つのスキルに置き、ツールから既存のコマースシステムを呼び出します。売り場の一つのカウンターに、訓練を受けた販売員が立っているイメージです。会話全体はその販売員が把握しますが、在庫はバックヤードの端末、本人確認は顧客システム、カート操作はレジを使わなければなりません。

同じ定義をMessages API、Claude Agent SDK、Claude Managed Agentsのいずれでも実行できるのは便利です。しかし、サンプルがそのまま本番品質になるわけではありません。Anthropic自身も、デモには認証が実装されていないと説明しています。リポジトリだけでは、注文の確定もカード決済も行われず、不正対策、購入資格、在庫、コンプライアンスに関する各社固有のルールも提供されません。

事業性の計算はデモの先から始まります

このブループリントにより、説得力のある初期版まで到達するコストは変わります。Anthropicの公開ページでは、Wixはプロンプトを受け取るプロトタイプを15分で作成できたとし、Fetchは二つのリファレンスエージェントをどちらも1時間を大きく下回る時間でローカル実行できたと報告しています。Zomatoによれば、同梱されたプラクティスによって数週間分の試行錯誤を省ける可能性があります。いずれもパートナー企業の報告であり、納期を保証するものではありません。それでも予算配分の変化は明確です。エージェントの枠組みを一から考案する工数を減らし、商品カタログの品質、権限、評価、チェックアウトまでの最終工程に多くの時間を振り向けられます。

モデル利用料も、統合作業に比べれば小さく抑えられる可能性があります。Claude Sonnet 5の料金は、新規入力100万トークン当たり$2、キャッシュヒットした入力100万トークン当たり$0.20、出力100万トークン当たり$10です。例として、入力20,000トークン、出力800トークンの1ターンを考えると、すべての入力が新規の場合、モデルコストは$0.048です。入力のうち18,000トークンがキャッシュヒットし、2,000トークンだけが新規なら、同じ計算で$0.0156になります。ここには検索、ホスティング、可観測性、サポート、モデルを取り巻く各種コマースAPIの費用は含まれません。

Anthropicによれば、特に成果の高いコマース導入事例では、キャッシュヒット率が90%〜99%に達しています。だからこそ、本番予算の本質は「LLMを購入すること」ではありません。「完了した購買タスクの一件一件を、正確かつ高速で、出所を追跡でき、安全なものにすること」です。

AIショッピングエージェントを本番運用へ進める実装手順

実装の順番は、収益とリスクに沿って決めるのが合理的です。まず購買タスクを絞り、次にデータと本人情報を接続し、その後で操作権限を与え、最後に速度を最適化します。在庫が古いままでは、どれほど会話が洗練されていても店舗としては機能しません。

1. 購買タスクと成功指標を一つずつ決める

「商品カタログについて何でも答える」ことから始めてはいけません。たとえば、顧客に合うマットレスのサイズ選びを支援する、予算内で三つの商品からなるキャンプ用品一式を組む、欠品商品の代わりに在庫のある商品を探す、といった具体的なタスクを選びます。

成功は、感じのよい返答ではなく、タスクが完了したかどうかで定義します。根拠のある商品選定、提案の受諾、カートへの追加、チェックアウトへの引き継ぎ、サポートチケットを発生させない自己完結、支援を受けた注文の返品率などが有効な指標です。カートの規模と購入完了率は、レイテンシーやモデルコストと並べて確認します。誤ったバリエーションを勧めるなら、いくら安い回答でも高くつきます。

2. 既存の検索・ランキング機能を商品カタログツールの背後に置く

モデルそのものを検索エンジンにしてはいけません。Anthropicのパターンでは、search_productsがランキング済みの結果を返します。そのうえでClaudeが、返された商品のうち顧客の条件を満たすものはどれか、何件を見せるべきかを判断します。

商品カタログは、単品商品、商品ファミリー、購入可能なバリエーションという三つの形に整理します。シャツの商品ファミリーにはサイズや色の選択肢を持たせられますが、現在価格と在庫を持つのは各バリエーションです。検索結果ではファミリーを返しても構いませんが、カートへ書き込む際には正確なバリエーションを指定しなければなりません。この区別があれば、Mサイズの青が在庫にあるか分からないまま、流暢なエージェントが「青いシャツ」を追加する事態を防げます。

返すフィールドは、モデルの判断に必要なものだけに絞ります。通常は、商品ID、名称、価格、在庫状況、オプション値、重要な属性、参照元のタイムスタンプが必要です。検索結果ごとに画像URLや長い販促文を繰り返しても、判断の質は上がらず、コンテキストだけを消費します。

すでに検索サービスやレコメンドサービスがあるなら、ビジネスロジックはそこに残します。ない場合は、プロンプトを調整する前に検索・取得の仕組みを直すべきです。属性の欠落、SKUの重複、顧客の条件を無視するランキングは、商品カタログツールを導入しても救えません。

3. モデルにツールを見せる前に本人情報をひも付ける

認証はホストアプリケーションの責務です。ホスト側で顧客をサインインさせ、顧客またはゲストとしての主体を確定し、セッションを開始します。バックエンドのメソッドは、サーバー側のセッション状態からその本人情報を読み取ります。顧客IDをツール引数としてモデルに渡したり、店舗への接続に使う認証情報をモデルへ見せたりしてはいけません。

ゲストも、権限が少ないだけの正規の主体として扱います。ゲストが注文履歴や保存済み住所を求めたら、バックエンドはサインインが必要だと返すべきです。匿名のまま始めた会話の途中で本人情報を書き換えるのではなく、サインイン後に新しい認証済みセッションを開始します。

デモでは見落としやすい分離ですが、後付けには大きなコストがかかります。「エージェントが注文ツールを呼んだ」と、「認証済みのこの顧客に、この注文を読む権限があった」との違いを生む設計です。

4. 操作の瞬間に在庫を正として再確認する

検索結果はエージェントの判断材料になりますが、事実を決めるのはバックエンドです。カート操作の内部で、在庫、購入資格、価格、購入上限、出荷締切、プロモーションルールを再確認します。読み取りと書き込みの間に在庫がなくなった場合も明確に応答できるよう、処理はアトミックに行います。

指定されたバリエーションが在庫切れなら、利用できないIDと、有効な同一ファミリー内の代替バリエーションを返します。エージェントに違いを説明させ、顧客自身に選んでもらいます。別商品へ黙って差し替えてはいけません。マーケットプレイス、アカウント別価格、旅行日程、店舗別受け取りに対応する場合は、回答を算出するバックエンドに必要なコンテキストを渡します。

5. すべてのツールを権限付きAPIとして扱う

リファレンス実装では、デプロイ設定からモデルに見せるツール一覧を組み立てます。導入していないシステムは無効にし、残りのツール名だけを許可リストに登録します。リストにない呼び出しは、コードで拒否します。

さらに、出所を確認するゲートを設けます。カートへの書き込みで受け付けるのは、そのセッション内でサーバーが返した商品ID、またはすでに同じカートに存在する商品IDだけにします。これにより、捏造されたID、別アカウントから貼り付けられたID、商品コンテンツに埋め込まれた命令を遮断できます。画面表示にも同じ原則を適用します。エージェントは返されたIDを選べますが、商品カードの内容はサーバーが自らのレコードから補完します。

商品情報、レビュー、ポリシー、出品者メッセージ、記憶した事実は、いずれも信頼できないデータとして扱います。Anthropicのランタイムでは、第三者のテキストをClaudeが読む前にサニタイズし、境界を設けています。プロンプト上のルールも役立ちますが、権限、数量上限、保護対象フィールド、書き込みの直列化は必ずコードで実装しなければなりません。

ランタイムやゲートウェイをさらに細かく制御する必要がある場合は、マネージドエージェントツールのガイドで、ツールを利用するエージェントを支えるインフラの選択肢を解説しています。

6. エージェントの権限はチェックアウトの手前で終わらせる

Claude Commerce Agentsは明確な境界を設けています。モデルはカートを作成して表示できますが、注文の確定やカードへの請求はできません。モデル呼び出しの後でホストがチェックアウト先を渡すため、そのURLがモデルのコンテキストに入ることもありません。

引き継ぎ方法は、次のいずれかを選びます。

1. 自社アプリケーション内でチェックアウトを開く。
2. コマースプラットフォームがホストするチェックアウトURLを開く。
3. マーケットプレイスでは、必要に応じて出品者ごとに一つのチェックアウトリンクを表示する。

この境界は機能不足ではなく、優れたプロダクト設計です。顧客は、決済とコンプライアンスをすでに担っているシステム上で、数量、住所、配送、割引、合計金額を確認できます。

エージェントだけで処理すべきでない曖昧な状況には、有人サポートへの別の引き継ぎ経路を用意します。どの意図で引き継ぐのか、どのキューが受けるのか、どの会話要約を渡すのか、担当者が何を承認できるのかを定義してください。「担当者と話す」は単なる予備の一文ではなく、本人情報とサービスレベルのルールを伴うワークフローです。

7. 型付きツールを通じてコマースUIを描画する

商品グリッド、比較表、プラン、カート、注文カードは、型付きの表示ツールとして実装します。Claudeが構造化された引数でコンポーネントを呼び出し、サーバーが検証して情報を補い、クライアントが描画します。

こうすることで、画面に表示したインターフェースも会話履歴の一部になります。顧客が「二つ目の商品」と言ったときも、順序付きの商品リストがメッセージ内に残っています。また、壊れやすい独自マークアップをモデルに生成させずに済みます。周辺の会話UIも必要なら、チャットボット構築ガイドで、より広いインターフェース設計の判断を確認できます。

8. タスク全体でレイテンシー予算を組む

完了までの時間は、モデルの各ターンとツール処理時間の合計として測ります。ターン数を減らすこと、ツールを高速化すること、トークンの表示を速めることのすべてが重要です。

最初のモデル呼び出しより前に、そのページで使う可能性の高いコンテキストを読み込みます。独立した商品カタログやポリシーの読み取りは並列に実行します。各ツールは引数のストリーミングが終わり次第呼び出し、商品カードも必要なフィールドが届いたところから順次表示します。時間のかかる検索中は、簡潔な進捗メッセージを見せます。

Anthropicによると、画面表示を伴うコマース回答は500〜700出力トークンになることが多く、段階的な表示がなければ、何も表示されないまま5秒以上待たせる可能性があります。また、ツールを即時実行することで、実測で数秒かかっていたツール間の空白を数百ミリ秒まで短縮できたとも報告しています。モデルの性能を下げる前に、この部分を整備してください。能力の低いモデルはターン数が増え、完了タスク当たりのコストがかえって高くなることがあります。

9. プロダクト要件を評価ケースに変える

評価ケースとは、既知の状態からエージェントがどう動くかを繰り返し検証するテストです。重要なメッセージ、商品カタログのレコード、カート、ユーザー情報、障害を用意し、最終状態と表示された回答を採点します。

対象は、主要な買い物リクエスト、コンテキスト依存のやり取り、安全性とブランド、インターフェースの挙動、二つの機能をまたぐメッセージという五つのグループです。肯定ケースごとに、否定ケースも一つ作ります。在庫のあるバリエーションを勧めるべきケースだけでなく、有効なバリエーションがすべて欠品しているケースも試します。商品情報に仕込まれた敵対的な文章、別ユーザーの注文ID、タイムアウト、検索結果ゼロ、カートへの重複追加、検索からカート投入までの間に価格が変わる状況もテスト対象です。

Anthropicは、ユーザーフローごとに50〜100件のケースから始めることを推奨しています。プロダクト、法務、カスタマーケア、マーチャンダイジングの各チームと共同で作成し、実際のインシデントは恒久的な回帰テストに変えます。根拠に基づく正確性、タスク完了率、安全性の合格率、p50とp99のレイテンシー、キャッシュヒット率、完了タスク当たりのコストを基準に、カナリアリリースを判定します。

効果を得やすい順に見る、ECの七つのユースケース

特に大きな効果を期待できるのは、顧客に具体的な制約があり、商品カタログに意味のある選択肢が存在する店舗です。一般的なFAQボットは、このアーキテクチャの活用法としては最も弱い部類に入ります。

1. 比較検討が必要な商品のアドバイザー

対象: 比較を必要とするマットレス、家電、アウトドア用品、電子機器などを扱う店舗。

流れ: 顧客が目的、予算、寸法、好みを伝えます。エージェントはランキング済みの商品カタログを検索し、有力候補の詳細を取得して構造化された比較を提示します。正確なバリエーションを確認したうえで、カートを準備します。

収益につながる理由: 購入セッションの中で意思決定を支援できるからです。顧客が離脱する前に迷いを解消できるため、Anthropicが報告したカート規模と購入完了率の向上に最も近いユースケースです。

2. 目的別セット商品の提案

対象: キャンプ用品、ホームオフィス機器、スキンケア一式、初めてのキッチン用品など、組み合わせて使う商品を販売する店舗。

流れ: エージェントが一つの目的を複数の商品要件に分け、独立した検索を並列で実行します。合計予算を確認し、妥協点を説明して、承認されたバリエーションを一つのカートに追加します。

収益につながる理由: もう一点の商品を宣伝するのではなく、目的全体を満たすことでカート全体を大きくできます。顧客は複数のカテゴリーページを開き、自力で互換性を照合する手間からも解放されます。

3. バリエーションと適合性の案内

対象: アパレル、化粧品、家具、構成可能な商品など、返品リスクの高い商材を扱う店舗。

流れ: 顧客がフィット感、色合い、設置スペース、互換性などの条件を伝えます。エージェントは商品ファミリーの選択肢を読み、正確なバリエーションの在庫を確認し、有効な組み合わせだけを提示します。バリエーションが未確定の商品ファミリーは、カートに追加しません。

収益につながる理由: 価値があるのは会話量の増加ではなく、選択ミスの減少です。チェックアウト時に有効なバリエーションが決まっていれば、顧客を止めることなく、回避できるキャンセルや返品を減らせます。

4. 商品発見から購入後サポートまでの一貫対応

対象: 注文状況、返品、保証、ポリシーに関する問い合わせがサポート窓口に繰り返し届く店舗。

流れ: 同じ会話の中で、商品探しから、サインイン済みの注文照会やポリシー検索へ移ります。エージェントは顧客本人のレコードを読み、状況を表示し、例外案件はコンテキストを添えて担当者へ引き継ぎます。

収益につながる理由: 一つの窓口で、コンバージョン向上と問い合わせの自己完結を両立できます。顧客は商品、注文、ポリシーの情報を別のボットにもう一度説明する必要がありません。

5. アカウント情報を反映するB2B購買アシスタント

対象: 契約価格、購入資格、承認済み商品群を持つ流通企業やサブスクリプション事業者。

流れ: ホストが購入担当者のアカウントと役割をセッションにひも付けます。バックエンドツールは、そのアカウントの価格、購入可能な商品、配送・受取方法だけを返します。エージェントは、消費者向けチェックアウトで済むかのように振る舞わず、見積もりまたは発注への引き継ぎを組み立てます。

収益につながる理由: 権限を守りながら、ルールの多い購買プロセスを短縮できます。モデルは選択肢を説明しますが、最終的な決定権はアカウントシステムに残ります。

6. マーケットプレイスのカート調整

対象: 一つの依頼に複数の出品者が応えられるマーケットプレイス。

流れ: 出品者を検索条件の一つにします。エージェントがオファーを比較し、カート内の商品を出品者別にまとめます。必要な場合は、ホストが出品者ごとに別々のチェックアウトリンクを表示します。

収益につながる理由: 決済と配送を異なる事業者が担うという商取引上の実態を隠さず、分断された購入体験を一つの計画的な会話にまとめられます。

7. 在庫・販促を支援するマーチャント向けコパイロット

対象: 多数のSKUについて、販売、在庫、価格、キャンペーンを管理するマーチャンダイジングチーム。

流れ: マーチャントエージェントが業績と在庫アラートを読み、補充や販促を提案して、変更を適用前の状態まで準備します。実際に反映する前に、正式な運用画面で担当者の承認を待ちます。

収益につながる理由: 既存の作成者・承認者による統制を維持しながら、分析と準備にかかる時間を短縮できます。価格、予算、公開中の商品情報に対する権限は、人間が持ち続けます。

構築する価値がある三つのプロダクト

1. 業種特化型ショッピングエージェント導入キット

アウトドア用品、家具、美容など、比較検討が必要な一つのカテゴリーに絞って本番対応パッケージを作り、汎用チャットウィジェットでは物足りなくなった店舗へ提供します。

価格帯の参考になるサービスはすでにあります。Bramblesのショッピングアシスタントプランは、月間10,000〜500,000セッションに対して月額$29〜$499です。Ryeの料金は、エージェント型コマース基盤が月額$149で、商品取得1回当たり$0.02、注文確定1件当たり$0.05が加算されます。これらの数字から、店舗が支払うサブスクリプション費用と、従量制インフラ費用の両方が見えてきます。

販売可能な最小構成は、一つのコマースプラットフォームと一つの商品カテゴリーに対応します。商品ファミリーとバリエーションを対応付け、ゲストとサインイン済みユーザーのセッションをひも付け、検索と商品詳細を実装します。さらに、カート作成、ホスト型チェックアウトへの引き継ぎ、二つまたは三つの型付きUIコンポーネントのストリーミング、カテゴリー固有の評価パック、有人対応への経路までを含めます。

課題は価格競争です。プラットフォーム本体や安価なアプリストアのアシスタントでも、一般的な商品Q&Aには対応できます。差別化の核にすべきなのは、カテゴリー固有のロジック、信頼できる商品カタログのマッピング、コンバージョンの帰属分析、その業種で実際に起きた失敗から作るテストケースです。

三つの中では、これが最も有望です。 店舗の売上に最も近いうえ、ブループリントが汎用的な足場を十分に提供しているため、小規模なチームでも顧客が対価を払うカテゴリー固有の作業へ集中できます。

2. エージェント向け商品カタログ診断とバリエーションQA

ショッピングエージェントを顧客に公開する前に、その商品カタログがエージェントの問い合わせへ安全に答えられるかを検査するサービスを構築します。

この課題を支えるインフラには、すでに相応の市場があります。Channel3によると同社の商品データ基盤は、25,000の小売企業にまたがる1億点の商品をカバーし、1秒未満で応答します。Ryeの商品取得料金は1回当たり$0.02です。GoogleのAI Commerce Search料金は、1,000クエリ当たり$2.50です。構造化され、最新に保たれた検索・取得機能は、すでに予算項目になっています。

MVPでは、一つの商品フィードを取り込み、商品ファミリーとバリエーションの関係を構築し、必須属性を確認し、価格と在庫のタイムスタンプを比較します。さらに、実際の買い物で使われる条件のライブラリを実行し、回答の欠落や矛盾をSKU単位で報告します。同じ問い合わせに対して、カート操作時に在庫切れのバリエーションが明示的な復旧経路なしで返されることがないかを確認する再実行テストも加えます。

課題は、プラットフォーム側の優位性です。Shopifyをはじめとするコマースプラットフォームは、正となる商品フィードを所有しており、基本的な検証機能を取り込めます。このプロダクトには、プラットフォームをまたぐ正規化、失われた購買タスクに基づく問題の優先順位付け、修正によって誤った提案が減ったことの証明が必要です。

3. コマース特化型の評価・リリースゲート

プロンプト、モデル、ツール、商品カタログの変更を安全に公開できるか判定するテスト層を構築します。

エージェント評価には、すでに予算が付いています。Langfuseによると、同社のプラットフォームは50,000社を超える企業に利用されています。本番向けプランは月額$29と$199、Enterpriseは$2,499からです。Anthropicは、コマースの各フローに50〜100件の評価ケースを推奨しています。足りないのは、別のトレースビューアではありません。継続的に整備されたコマース状態のライブラリ、汚染された商品カタログのフィクスチャ、カートの不変条件、リリースポリシーです。

MVPでは会話ログを取り込み、インシデントをスナップショット型のテストケースに変えます。商品IDの出所、価格の根拠、バリエーション選択、数量上限、チェックアウト境界、本人情報の漏えい、タイムアウトからの復旧、引き継ぎ品質について、決定論的な採点機能を提供します。モデルとプロンプトは、タスク完了率、p99レイテンシー、完了タスク当たりのコストで比較できるようにします。

課題は、横断型ツール市場の競争が激しいことです。参入障壁になるのは、コマース固有のフィクスチャ、採点精度、プラットフォーム連携、ベンチマークデータでなければなりません。汎用的な可観測性だけでは、模倣されるか既存製品に組み込まれます。

Claude Commerce Agentsだけでは解決できないこと

率直に言えば、このブループリントが店舗との統合以上に解決してくれるのは、エージェントの構造です。本格的な出発点にはなりますが、ホスト型のショッピング製品ではありません。

• 顧客認証やスタッフの権限管理は行いません。ホストとゲートウェイの責務です。
• 商品カタログの品質不足、不適切なランキング、在庫反映の遅れは修復しません。引き続きコマースシステム側が担います。
• 注文確定、決済情報の保持、カードへの請求、不正対策ポリシーの決定は行いません。
• 有人対応への引き継ぎルール、サービスキュー、承認する役割は決めてくれません。
• Anthropicが報告したコンバージョン向上を、あらゆる商品カタログで再現できるようにはしません。自社での対照測定が必要です。
• 記憶機能に関するプライバシー判断も不要にはなりません。保存する好みについて、受け入れるデータの種類、保持期間、アクセス、訂正、削除を定める必要があります。

絞り込みだけで購入が一度のクリックで完了する小規模な商品カタログには、この仕組みを構築すべきではありません。価格や在庫が古い状態でも公開すべきではありません。プロンプトが慎重に見えるという理由だけで、書き込み権限を与えてはいけません。会話によって本当に複雑な購買タスクを解決でき、現在の権限付き情報を自社システムから供給できるときにこそ、エージェントを導入する意味があります。

月曜日に着手すること

来週、売上につながるフローを一つ選びます。サイト内検索、営業チャット、サポートの会話ログから実例を50件集めてください。まずは商品カタログ検索と商品詳細だけを接続し、それ以外のツールはすべて利用不可を返すようにします。エージェントが根拠のある在庫中のバリエーションを選べるか、顧客がその提案を受け入れるかを測定します。読み取り経路がテストケースに合格してから、カートとチェックアウトを追加します。この順序なら、Claude Commerce Agentsを印象的なデモから、統制されたコマースのリリースへ変えられます。

AIショッピングアシスタントはどのように動きますか？

一つのClaudeエージェントが会話全体を保持し、商品カタログ検索、商品詳細、カート、ポリシー、注文、記憶、画面表示のための型付きツールを呼び出します。バックエンドは顧客を認証し、価格と在庫のルールを適用して、構造化された事実を返します。モデルはその事実を基に判断しますが、自らが正となる情報源になるわけではありません。

商品カタログはどのように接続しますか？

ブループリントのストアフロント向けバックエンドを、既存の検索・商品サービスに接続して実装します。検索からはランキング済みの商品ファミリー、商品詳細からは購入可能な正確なバリエーションを返し、価格と在庫状況は正となる自社システムから最新情報を返します。認証情報と顧客の本人情報はサーバー側に保持します。

Sidekickではユーザー権限をどのように扱いますか？

自社のショッピングエージェントやマーチャントエージェントでは、Sidekick固有の実装ではなく、基礎となる原則を取り入れます。エージェントのターンを始める前にユーザーと役割を確定し、許可されたツールだけを公開します。認証情報はサーバー側に置き、各バックエンドメソッドでも認可を再確認し、機密性の高いマーチャント操作にはホスト側で実際の承認を求めます。

Claudeなどを使って自社で構築できますか？

はい。オープンソースのリポジトリには、実行可能なサンプルと、自社バックエンドに合わせた足場を生成できるClaude Codeプラグインが含まれています。ただし、自社構築で残る作業は少なくありません。認証、商品カタログのマッピング、リアルタイム在庫、カートとチェックアウトの統合、権限、有人対応への引き継ぎ、監視、評価が必要です。

自社の商品カタログと運用ルールに合わせた構築をご希望なら、AIエージェント開発サービスをご覧ください。