マーケットプレイスのAIカスタマーサポート：購入者・出品者・トラストレーンの分け方

要点まとめ

マーケットプレイスでは、1つの取引に2人の顧客がいて、しばしば正反対のことを望みます。だから汎用のチャットボット1つでは形が合いません。キューを購入者レーン、出品者レーン、トラストアンドセーフティレーンに分け、それぞれに専用のナレッジと、AIに許可することのルールを持たせます。

照会業務はAIに完全に任せましょう。注文状況、返金状況、支払い状況、手数料の内訳などです。購入者と出品者の紛争では証拠の取りまとめまではAIに任せ、どちらが勝つかは人が選びます。詐欺や偽出品の通報はキューの最上位に送ります。そしてカードのチャージバックは別物として扱います。判断するのはカード発行会社で、Stripeによると回答期限は通常7〜21日、提出できるのは1回だけです。

eeselはこの考え方で動きます。既存のヘルプデスク内のAIチームメイトとして、過去のチケットから学び、注文APIと支払いAPIを呼び出し、誰かに回答する前に過去チケットでシミュレーションされます。SamCartはFreshdeskの出品者チケットに1つのeeselエージェントを、ウェブサイトのチャットに別のエージェントを使っています。RúngneはShopifyのデータから注文の質問に答え、破損の申請や紛争は人が担当しています。

なぜマーケットプレイスでは1つのチャットボットでは失敗するのか？

私はeeselのエージェントが他のシステムから読み取れるようにする連携とアクションを作っているので、週の大半は「AIは何を見る必要があり、何を変更してよいのか」という1つの問いに費やされます。単一ブランドのストアなら答えは単純です。マーケットプレイスでは2つに分かれます。問い合わせてくる人が同じ注文の購入者かもしれないし出品者かもしれず、それぞれが受け取るべき回答は違うからです。

「配達済み」になっているのに、購入者が届いていないと言う荷物を考えてみましょう。購入者は返金を求めます。出品者は支払いを求めます。1つのヘルプセンターで学習したボットは、出品者に購入者向けポリシーを伝えるか、購入者に出品者向けポリシーを伝えるかのどちらかになり、どちらも問題です。eBay自身のマネーバック保証を見ると、この1つのケースの裏にどれだけの仕組みがあるかが分かります。出品者の対応期限は3営業日、どちらの側も3〜21営業日の間にeBayへ介入を求められ、$750以上の注文には配達証明として署名確認が必要です。

私はこれを内側から見てきました。2026年5月、大手フードデリバリーのマーケットプレイスから、1つのZendeskヘルプセンター内に顧客用と飲食店用の2つのナレッジベースを分けて作りたいという依頼がありました。この依頼がこの問題のすべてを一言で表しています。私たちは長年、AIエージェントを実際のサポートキューに配置し、自信満々のボットが誤った回答をするのを見てきました。そのためeeselの導入は今では必ず、先に過去チケットでシミュレーションを行います。マーケットプレイスでは、1つの誤回答が同じ注文の両側にコストを生じさせかねません。

マーケットプレイスのチケットのうち、AIが扱えるものと人が必要なものは？

私はマーケットプレイスのチケットを1つのテストで仕分けます。それは「単一の正解がどこかのシステムにあるか？」です。あるならAIが単独で回答できます。回答が誰が正しいかの判断に依存するなら、人が決め、AIは準備を担当します。これが二面プラットフォームにおける優れたチケットルーティングの核心です。

上の4行が件数の大半を占めます。また、多くのマーケットプレイスのボットが不十分になるのもここです。注文システムではなくヘルプセンターから回答するからです。「お支払いは通常2〜3日で到着します」は、「私の支払いはどこ？」への回答になっていません。本当の回答はステータスと日付で、それは決済プロバイダーにあります。表の下半分は、ヒューマン・イン・ザ・ループのステップが恒久的に残る領域です。

購入者・出品者・トラストアンドセーフティをどうレーンに分けるか？

ほぼすべてを3つのレーンでカバーできます。購入者レーンは注文、配送、返金を扱います。出品者レーンは支払い、手数料、出品、本人確認を扱います。トラストアンドセーフティレーンは詐欺、偽出品、アカウント乗っ取りを扱い、順番を飛ばして優先されます。

各レーンには専用の3つが必要です。ナレッジセット、許可するアクションの一覧、そしてAIが引き継いだ案件を受け持つ人またはチームです。最も重要なのはナレッジの分離です。購入者向けの返金ポリシーと出品者向けの補償ポリシーは、意図的に互いに矛盾します。両方を読んだAIはそれらを混ぜてしまいます。これはマルチブランドのカスタマーサポートと同じ問題で、2つのストアの代わりに2つの顧客層があるだけです。

お使いのヘルプデスクには、おそらくすでに分離の機能がありますが、契約プランによって異なります。

Zendeskで購入者と出品者をモデル化する最も安上がりな方法は、私の見る限り、出品者ブランドに加えてユーザーセグメントを使い、出品者のレコードをチケットに関連付けたカスタムオブジェクトとして保存することです。エージェントに自分のレーンだけを見せたい場合は別の権限の問題になり、私のメモサポートエージェントのアクセス制御で扱っています。

smavaは、1つのヘルプデスク内で2つの顧客層を分けて運用している最も分かりやすい例です。smavaとFinanzcheckは1つのZendeskを共有しており、eeselは両方で月に約27,000件のチケットを処理し、ブランドごとに分けられた約820件のマクロとヘルプセンター記事から下書きを作っています。出品者レーンと購入者レーンも同じやり方です。1つのヘルプデスクに、混ざることのない2つのナレッジセットを置きます。

このチケットはどのレーンに行くのか？

レーンのロジックをクリックして試せる形にしました。チケットを選ぶと、レーン、AIに許可されていること、誰が仕上げるかが表示されます。

チケットを選ぶと、そのレーン、AIに許可されていること、誰が仕上げるかが表示されます。これはマーケットプレイスのキューを扱うときの私の出発点であり、最終的なルールはポリシーチームが決めます。

AIを注文データと支払いデータのリアルタイムにどうつなぐか？

購入者レーンと出品者レーンの照会は、AIがお使いのシステムをリアルタイムで読み取れて初めて機能します。「私の支払いはどこ？」にヘルプセンターから答えると、一般的なスケジュールしか返せません。決済APIから答えれば、「$412のお支払いは移動中で、木曜日に到着する見込みです」と返せます。後者はチケットを解決し、それこそが注文追跡サポートとWISMO自動化の目的です。

出品者レーンの成否を分けるのは支払いで、StripeのConnectドキュメントは、なぜそのチケットが自社に来るのかを説明しています。出品者が期待した資金を確認できない場合、Stripeは「利用しているプラットフォームに連絡する必要がある」と述べています。支払い設定とスケジュールを管理するのはプラットフォームだからです。つまり、支払いに関する質問はすべてStripeではなく自社のチケットです。同じページには、AIが読み上げるべき支払いステータスが挙げられています。pending（保留中）、in transit（移動中）、paid（支払い済み）、failed（失敗）、canceled（キャンセル）です。

支払い失敗は、AIがほぼ対応できるチケットの好例です。支払いが失敗すると、Stripeはその銀行口座をエラー状態にし、その口座への予定された支払いを一時停止します。プラットフォームは、出品者が自分で銀行口座情報を更新するためのリンクを生成できます。これは照会とリンクであり、AIの得意分野です。同じページには、プラットフォームが不正を理由に銀行口座をプラットフォーム全体でブロックできるとも書かれていますが、その操作は人の仕事です。

本人確認による保留も同じ仕組みです。Stripeの本人確認ドキュメントによると、必要な情報が期限までに届かない場合、Stripeは通常「支払いを無効にします」。また各要件には、出品者が対応できる分かりやすい言葉のエラーが付きます。Adyenも似た期限を設けています。本人確認の概要によると、出品者は問題を修正するのに30日の猶予があり、その後支払いが止まり、60日で決済の受付ができなくなります。未対応の要件を読み取り、出品者に何をアップロードすべきかを正確に伝えるAIは、こうしたケースのたびにやり取りを何往復も減らせます。

エンジニアリングの側から見た仕組みは次のとおりです。必要なのは4つの読み取りと、ほとんどない書き込みです。

1. 注文：ステータス、商品、追跡イベント。マーケットプレイスのデータベースまたはShopifyから取得。
2. 返金：返金済みかどうか、金額、日付。
3. 支払い：ステータス、到着日、失敗コード（出品者アカウントごと）。
4. アカウント要件：未完了の本人確認と、その期限。

Webhookでデータを最新に保ちます。StripeのConnect Webhookのページは、すべてのConnect連携がイベントを受信すべきだとしており、サポートチームが気にするのはaccount.updated、payout.failed、charge.dispute.createdです。私は、支払い失敗のWebhookで、出品者が問い合わせてくる前に出品者レーンのチケットを開くようにするのが好きです。「お支払いが失敗しました。修正するためのリンクはこちらです」という先回りの連絡は、3日後に届く戸惑いのメールよりずっと良いからです。

書き込みについて私が守るルールは単純です。お金を動かすもの、アカウントを変更するものは、人を待ちます。返金、支払いの解除、手数料の取り消し、アカウントのブロックが該当します。誰が何を承認するかのテンプレートが必要なら、私の返金承認マトリクスが一例を示しており、例外的なケースはサポート例外管理で扱っています。

購入者と出品者の紛争にAIはどう対応すべきか？

ここは利害の対立が最も鋭く、私ならAIに決して一方の味方を選ばせない領域です。双方とも自社の顧客です。AIにできるのは、判断する人をずっと速く、ずっと一貫したものにすることです。

一貫性は思われている以上に重要です。大手の宿泊マーケットプレイスでの紛争対応がどんな感じだったかを、あるホストが語っています。

"... The side you wins is the side you can say the magic words that specific agent wants to hear."

reverend_gonzo, Hacker News

結果がどの担当者に当たるかで決まるなら、双方が信頼を失います。解決策は、毎回同じ形の標準的な証拠パックを、人がケースを開く前に作っておくことです。

私の証拠パックは5つの部分で構成されます。注文記録、運送会社の追跡情報、購入者と出品者の完全なメッセージのやり取り、購入時点の出品内容のスナップショット、そして双方の返金・紛争履歴です。AIがこれらを集め、抜けを指摘し（「出品者が3営業日応答していません」）、人が判断した後で双方へのメモを下書きします。最後の部分は省きやすいのですが、省くべきではありません。敗れた側には、そのレーンの言葉で書かれた明確な説明を受ける権利があります。

タイムラインはマーケットプレイスの種類によって大きく異なるため、他社のものをそのまま写さず、自社のものを組み込んでください。物品のマーケットプレイスは追跡と配達証明に頼ります。eBayは出品者に3営業日以内の応答を求め、Etsyのケースプロセスでは、配送予定日を過ぎ、かつ出品者へのメッセージから48時間が経過すると、購入者がケースを開けます。サービスのマーケットプレイスには追跡番号がないので、マイルストーンとメッセージに頼ります。Upworkはフリーランサーに固定報酬の紛争を申し立てるまで暦日で7日を与え、FiverrのResolution Centerは48時間以内に応答がないリクエストを自動承諾します。サービスのプラットフォームを運営しているなら、証拠パックでは追跡情報の代わりに、納品されたファイルと合意した範囲を入れます。

誰が負担するかも重要で、AIの言い回しを左右します。Sharetribeでは、デフォルトで「マーケットプレイスの運営者だけが取引をキャンセルし、返金を開始できる」ことになっており、紛争中の注文は、誰も対応しなければ60日後に全額返金でキャンセルされます。このようなタイマーこそ、AIが証拠パックに表示すべきもので、何も静かに期限切れにならないようにします。

チャージバックと購入者・出品者間の紛争はどう違うのか？

チャージバックはまったく同じ注文から発生することもありますが、別のプロセスであり、判断者も異なります。購入者・出品者間の紛争では、自社のポリシーに基づいて自社が判断します。チャージバックでは購入者のカード発行会社が判断し、自社はカードネットワークの期限に従うことになります。

Stripeのルールは厳格なので、詳しく知っておく価値があります。

• 期限が短い。 Stripeの紛争対応ガイドによると、期限はカードネットワークによって通常7〜21日で、過ぎると自動的に敗訴となります。
• チャンスは1回だけ。 同じページによれば「回答を提出する機会は1回だけ」です。編集不可、リンク不可、音声・動画不可で、証拠は合計4.5MBまでです。
• サポート履歴は証拠になる。 Stripeは加盟店に、顧客とのやり取りをすべて記録しておくよう指示しています。それがケースの一部になるからです。意図していなくても、ヘルプデスクは紛争のアーカイブです。
• どちらにせよお金がかかる。 米国では、Stripeは紛争が届くと$15、異議を申し立てるとさらに$15を請求し、勝訴すれば2回目の手数料は返金されます。

損失を誰が負うかは、決済の設定によって決まります。StripeのConnect紛争ページによると、デスティネーションチャージと、チャージと送金を分ける方式では「Stripeはプラットフォームアカウントから紛争金額と手数料を引き落とし」、その後、送金を取り消して出品者から回収できます。ダイレクトチャージでは、出品者の残高から引き落とされます。Adyenのデフォルトも似ており、プラットフォームが先に支払い、そのコストを出品者に転嫁するか、支払いごとに分担できます。

したがって、チャージバックにおけるAIの役割は限定的です。charge.dispute.createdイベントを検知し、件名に期限日を入れたチケットを開き、注文、配達証明、サポートのやり取りから証拠を組み立てます。経理の担当者が確認して提出します。サポート側の詳細が必要なら、私のガイド決済紛争へのAI活用とチャージバック問い合わせがさらに詳しく扱っています。

トラストアンドセーフティレーンにはどんな統制が必要か？

詐欺や偽出品の通報は、速さと自制の両方が求められるチケットです。通報者はすぐに聞き入れられたと感じる必要があり、AIは自分の判断で誰かに警告したり罰したりしてはいけません。逆方向の失敗も同じくらい悪く、これはあるFacebookマーケットプレイスのユーザーが経験したとおりです。

"Last year, I reported a number of people, who were trying to scam me (via Messenger messages related to Marketplace listings). Not only did Facebook did not see anything wrong with the accounts and scammy messages, I was flagged for sending useless reports."

lukaslalinsky, Hacker News

このレーンに私が設定する5つの統制は次のとおりです。

1. 優先ルーティング。 通報は通常のキューを飛ばし、トラストアンドセーフティチームに届きます。ヘルプデスクのスキルベースルーティングで実現でき、AIの仕事は最初から正しくタグ付けすることです。
2. 証拠の保全。 詐欺師は編集や削除が速いので、AIは通報の時点で出品、メッセージ、アカウントの詳細を保存します。
3. 制限されたアクション。 AIは受領の連絡とタグ付けまでできます。通報されたアカウントのブロック、停止、返金、メッセージ送信はできません。これらは一度設定したら緩めないAIガードレールです。
4. なりすましへの警戒。 出品者には、自社のサポートチームを装った詐欺メッセージが届きます。ある元Etsy出品者は、「購入者やEtsyサポートを装った詐欺師からの毎日20件以上のメッセージ」と述べました。AIはパスワードや支払い情報を決して求めてはならず、返信でもそのことを伝えるべきです。
5. 異議申し立てと監査証跡。 アカウントに対するすべてのアクションを、誰が承認したかとともに記録します。出品者が停止に異議を申し立てたとき、確認する人は全履歴を1か所で見られます。

アカウント乗っ取りには専用のルールが必要です。出品者が「誰かが私の銀行口座情報を変更した」と書いてきたら、緊急として扱い、直ちに人に回します。Stripeの支払い機能では、プラットフォームが銀行口座をブロックしたり、乗っ取りを理由にアカウントを拒否したりできますが、これらはAIではなく自社チームが判断することです。引き継ぎを円滑にする一般的なパターンについては、私のメモAIエスカレーション管理をご覧ください。

私ならどう導入するか？

照会業務から始め、紛争は後にして、本番に出す前にテストします。うまくいった手順は次のとおりです。

1. 第0週：マッピングと接続。 最近のチケット300件を取り出し、3つのレーンに仕分けます。注文、返金、支払い、アカウント要件への読み取りアクセスを接続します。制限アクションの一覧を書きます。
2. 第1〜2週：シミュレーション。 各レーンについて過去チケットに対してAIを動かし、その回答を実際にチームが送ったものと比較します。採点方法は私のローンチ前テストガイドとパイロットのスコアカードで扱っています。
3. 第3〜4週：照会を本番稼働。 注文状況、返金状況、支払い状況、手数料の質問は人を介さずに送ります。それ以外は下書きのみです。
4. 第5〜8週：証拠パック。 AIが紛争とチャージバックのパックの作成を始めます。判断はすべて引き続き人が行います。
5. 継続：トラストアンドセーフティのタグ付け。 通報の優先タグ付けを有効にし、AIによるアカウント操作は永久にゼロにします。

マーケットプレイスが驚くのは、シミュレーションの段階です。典型的な例は、出品者が「返品はどうなりますか？」と尋ねたために、AIが出品者に購入者向けの返品ポリシーを伝えてしまうことです。これはナレッジ分離の問題で、実際の出品者の受信箱ではなく、過去のチケットの再生で見つけたいものです。私のAIサポートのパイロットガイドに、この計画の4週間版があります。

二面プラットフォームでは何を測定すべきか？

マーケットプレイスでは、ディフレクション率は見出しに据える数字として不適切です。ボットの返信を受けてあきらめた購入者はディフレクト済みと数えられ、黙って他で出品し始める出品者も同様です。私はすべての指標を、側ごとに2回測定します。

CSATを側ごとに分けることは、私が最も強く勧めることです。出品者はしばしば人数が少なく、生涯価値がはるかに高く、出品者レーンが静かに劣化しても、合算したスコアには現れません。定義については、私の解説CX AIの指標と繰り返しのチケットで各指標を説明しています。

出品者レーンが壊れているとき、出品者は教えてくれます。たいてい公の場で。支払い保留についての、ある小規模事業主の声です。

"We are affected by this as Etsy is currently holding about 4000 of our Euros... The worst thing about it is that we raised a support request for this, for which you have to jump through really stupid hoops, and have not even heard back from them in weeks. Not even a boilerplate response."

handmadeta, Hacker News

支払い保留は、リスク上の理由で正しい判断かもしれません。しかし何週間も沈黙するのは決して正しくありません。保留の理由を読み取り、「資金は本人確認のため保留されています。必要なものはこちらです」とだけでも当日中に返信するAIは、あの投稿が書かれずに済むチケットに変えてくれます。

eeselはマーケットプレイスのサポートチームにどう合うのか？

eeselは、すでに使っているヘルプデスクに参加するAIチームメイトで、Zendesk、Freshdesk、Gorgias、そしてHubSpotに対応しています。ヘルプセンターと過去のチケットから学び、レーンごとに専用のナレッジと指示を持つ別々のエージェントを動かせます。

私が最も力を入れているのはリアルタイムデータの部分です。eeselのNetwork Access設定により、エージェントが自社のAPIを呼び出して、注文、返金、支払いをリアルタイムで照会できます。ドメインを許可して認証ヘッダーを設定すると、認証情報は各リクエストにeeselが付与するため、AIがそれを見ることはありません。Shopifyの注文データはShopify連携で接続します。アクション権限では、各アクションを自動実行、承認を求める、オフのいずれかに設定でき、これによって返金とアカウント変更は人の背後に置かれます。

エンジニアがターミナルでの作業を好むなら、eesel CLIで同じチームメイトとワークスペースをコマンドラインから動かせます。保留中の承認を確認し、すべての実行のアクティビティログを読み、エージェントの常設の指示を編集でき、Claude Codeのようなコーディングエージェントからも操作できます。注文と支払いのシステムをすでにコードとして運用しているマーケットプレイスなら、サポートエージェントのルールを他のすべてのものの隣に置けます。

2つの顧客事例が、レーンの実際の姿を示しています。SamCartは75,000以上の事業者が販売に利用するプラットフォームで、出品者サポートにeeselを使っています。1つのエージェントがFreshdeskのチケットに返信し、別のエージェントがウェブサイトのチャットを担当し、どちらも約280件のヘルプセンター記事から回答します。エージェントは担当者がアサインされていない間だけ返信し、出品者が人を求めると、チケットに引き継ぎのタグが付き、エージェントは停止します。Rúngneは購入者側の例です。eeselは1か月に約2,100件のGorgiasチケットを処理し、注文の所在や在庫の質問にShopifyのデータから回答しました。一方、キャンセル、破損、紛失、通関の紛争は人に回っています。

正直な限界も述べます。eeselは紛争を判断したり、チャージバックへの回答を代わりに提出したりしませんし、私もそうさせたくありません。SOC 2 Type IIの監査は進行中で、観察期間は2026年10月1日に始まります。料金は料金ページにあり、100クレジットの無料プランと、月額$299から（500クレジット）のTeammateプランがあります。チケットまたはチャット1件が1クレジットです。別個のAIレイヤーとヘルプデスク内蔵のAIを比較検討しているなら、私のAIレイヤーの比較で両者を比べています。

マーケットプレイスのキューでeeselを試す

購入者と出品者が同じ定型回答を受け取っているなら、eeselは、すでに使っているヘルプデスクの中で、それぞれの側に専用のレーンを与えられます。簡単なチケットには注文と支払いのリアルタイム照会、紛争には証拠パック、お金に関する判断はすべて自社チームに残します。導入は必ず過去チケットでのシミュレーションから始まるので、他の誰よりも先に、購入者と出品者にどう回答するかを確認できます。

100クレジット付きでeeselを無料で試すか、デモを予約して購入者と出品者のチケットのサンプルをお持ちください。一緒にレーンをマッピングしましょう。