ECの問い合わせ対応にAIを入れる：どこまで任せて、どこから人か

問い合わせ対応は、種類ではなく工程で線を引く。要約・分類・記録はAIに任せてよい。文面の下書きもAIでよいが、送信は人が押す。返金・交換・納期の約束と、注文データとの照合だけは、AIに判断させてはいけない。

• 単位は「1件」ではなく「工程」。1件の問い合わせを8工程に割ると、任せてよい／下書きまで／触らせない、の3つに分かれる
• 事故の原因は文章力ではなく、AIがその注文の実データを見ていないこと。見ていない事実を自然な文体で埋めるから、読んだ人が気づけない
• 判定は2問だけ。「客に届くか」「約束を含むか」。両方YESなら人が決める

事故るのは「1件まるごと任せる」から

「問い合わせ対応にAIを入れたら誤答が出た」という話を分解していくと、たいていの場合、原因はAIの精度ではない。問い合わせ本文をそのまま貼り付けて「返信文を書いて」と頼んだ、という渡し方のほうにある。1件の問い合わせを丸ごと1つの作業として扱うと、その中に「AIが得意な工程」と「AIが構造的にできない工程」が混ざったまま渡ることになる。混ざったものを渡せば、できない部分だけが黙って埋められて返ってくる。

ここでいう「構造的にできない」は、能力の話ではない。単純に、AIは目の前の注文を見ていない。「まだ届きません」という一文だけを渡されたとき、AIの手元にあるのはその一文だけで、受注データにある出荷日も、配送伝票の追跡番号も、その注文が今どのステータスにあるかも、何ひとつ渡っていない。それでも文章としては完成させなければならないので、それらしい配送状況が書かれる。「本日発送手配を進めております」「明後日にはお届けできる見込みです」——文体は整っていて、店舗の口調にも合っている。だから読み返した担当者も違和感を持たない。ここが最も厄介なところで、誤答が誤答に見えない。

そして、この種の誤答は送信した瞬間には表面化しない。実害として戻ってくるまでに時間差があり、しかも4つの経路に分かれて戻ってくる。

• 再問い合わせ — 案内した日に届かず、客がもう一度書いてくる。1件だったものが2件、3件になる。効率化のつもりで着信件数を増やしている状態になる
• 低評価レビュー — モールに投稿されたレビューは公開され、基本的に消えない。商品ページに残り続け、CVRに効いてくる
• 返金・返品送料の負担 — 「無料で交換いたします」と書いてしまえば、その時点で規定より不利な条件を店が背負う。後から「規定ではお客様負担です」とは言いにくい
• モールからの指摘 — 規約に沿わない回答が、店舗の対応記録として残る

この4つを並べると、「AIは危ないから使わない」という結論に行きたくなる。だがそれは診断としては雑だ。上の4つはいずれも、照合と約束という2つの工程を人が押さえていれば起きない。逆に言えば、要約も分類も記録も、この4つの経路とは無関係のところにある。危ないのはAIそのものではなく、工程を指定しないまま1件を投げていることのほうだ。

だから最初にやることは、ツールの選定でもプロンプトの改良でもない。1件の問い合わせが自店でどんな工程を通っているのかを、いったん書き出すことになる。

問い合わせ対応を8つの工程に割る

1件の問い合わせは、着信してから記録されるまでに、少なくとも8つの工程を通る。普段は1人が連続してやるので1つの作業に見えるが、割ってみると参照するデータの置き場所が工程ごとに違うことがわかる。ここが分岐点になる。以下、各工程に「客に届くか」「約束を含むか」と、A（任せてよい）／B（下書きまで）／C（人が決める）の区分を添える。

• ①受信・一次受け — 客に届かない。約束なし。ただし入口が複数ある。モールの問い合わせ欄、自社カートのメールとチャット、電話。統合されていないので、まずここで散っている。区分としてはAだが、これは工程というよりチャネル統合の設計になる
• ②読み取り・要約 — 客に届かない。約束なし。入力が問い合わせ本文だけで完結し、外部データを必要としない数少ない工程。だからAI適性が最も高い。区分 A
• ③分類・優先度付け — 客に届かない。約束なし。配送状況／返品・交換／仕様の質問／キャンセル／クレーム、といったタグを付ける。これも本文だけで判断できる。区分 A
• ④事実の照合 — 客に届かない工程だが、ここでの誤りが全部下流に流れる。注文番号から受注データを引き、配送伝票の追跡番号を見て、在庫を見て、返品規定の該当箇所を確認する。AIはこれらの画面を見ていない。区分 C
• ⑤回答方針の決定 — 返金するのか、交換するのか、再送するのか、お断りするのか。いつまでにやるのか。これは文章力ではなく権限の問題で、店として何を負担するかを決める工程。区分 C
• ⑥文面の作成 — 客に届く。ただし④と⑤が確定していれば、この工程は「決まったことを書き写す」作業に落ちる。落ちてさえいればAIが最も貢献する。区分 B
• ⑦送信 — 客に届く。そして取り消せない。区分 C
• ⑧記録・タグ付け・還流 — 客に届かない。対応履歴として残し、テンプレやFAQ、商品ページの改善材料に回す。区分 A

この並びで見ると、AとCが交互に来ていることに気づく。②③がAで、④⑤がCで、⑥がBで、⑦がCで、⑧がまたA。1件を丸ごと投げるというのは、この交互の列を1本の紐にまとめて渡すことにほかならない。工程が混ざったままだと、Aの部分の速さとCの部分の危うさが同じ袋に入る。速さだけを取り出せない。

チャネルが変わっても、この8工程は変わらない。呼び名だけが変わる。楽天市場では、注文前は商品ページの「ショップへ相談」や「商品についてのお問い合わせ」から、注文後は購入履歴の「問い合わせ」から入るというように入口自体が注文の前後で分かれている。つまり同じ客の同じ案件でも、店舗側には別スレッドとして着信しうる。②要約と③分類の前に「これは既存案件の続きか」を人が判断する場面が生まれるということだ。Shopifyなら会話はShopify Inboxに溜まり、定型文はquick replies、自動応答はInbox agentという名前が付いている（Shopify Help Center）。名前が違っても、④の照合と⑤の方針決定が消えるわけではない。電話なら工程①がメモになるだけで、あとは同じ列を通る。

ここで見落とされやすいのは、④の照合先がCS側のデータではないことだ。受注データも在庫も出荷ステータスも、受発注・在庫管理の側で作られている。問い合わせ対応の精度は、実は上流のデータ整備の精度に乗っている。「注文番号を聞いてから調べるのに5分かかる」なら、それはCSの問題ではなく上流の問題だ。上流をどこまで自動化できるかは受注処理と在庫管理をどこまで自動化できるかを整理した記事で扱っているので、④が毎回詰まるならそちらが先になる。

判定は2問だけ ——「客に届くか」「約束を含むか」

8工程は自店の運用に合わせて9つにも7つにもなる。SNSのDMやレビューへの返信のように、そもそも上の列に入っていない場面も出てくる。だから覚えるのは工程表ではなく、判定のほうにする。問いは2つだけだ。

• 問1: その作業の結果は、客に届くか — 届かず、かつ問2もNOならA。社内で完結する工程は、間違えても書き直せる。ただし④の照合のように、社内工程でも台帳に正解があるものは問2でCになる
• 問2: 約束を含むか — 返金する・交換する・再送する・いつまでにやる、が入るならC。台帳に正解がある（受注データや返品規定に照らして答えが一意に決まる）場合もC

問1がYESで問2がNOならB、つまり下書きまではAIでよいが、送信は人が押す。問1がNOでも問2がYESならCで、④の照合と⑤の方針決定がこれにあたる（送信そのものは、区分がAでもBでも人が押す工程として⑦に残る）。この判定は3秒で終わる。問題は、境界に見える場面で迷うことのほうだ。実務でよく詰まる3つを、判定つきで置いておく。

(a)「入荷予定はいつですか」に答える。 在庫データを見れば書けそうな情報に見える。だが「今月下旬に入荷予定です」と書いた瞬間、それは約束になる。入荷が遅れたとき、客は「下旬と言われた」を根拠に交渉する。判定はC。AIに書かせてよいのは「入荷が確定次第ご連絡いたします」という日付を含まない形までで、日付を入れるかどうかは仕入れの確度を知っている人が決める。在庫データに「入荷予定日」という列があること自体は、その日付を客に言ってよい理由にならない。

(b) 返品規定・利用規約の内容を要約して返す。 見た目は単なる文章要約で、約束もしていない。しかしこれは台帳に正解がある類だ。要約の過程で「未開封に限り」「送料は購入者のご負担」といった条件がひとつ落ちると、落ちた状態が店の公式回答として客の受信箱に残る。判定はC（人が決め、AIは清書のみ）。渡し方も変わる。「返品規定を要約して」ではなく、該当する条文をそのまま本文に貼って「この範囲で説明せよ」と参照させる形にする。

(c) お詫びの一文だけを添える。 「このたびはご不便をおかけし申し訳ございません」。客に届くが、約束は含まない。判定はB。ただし放っておくとAIは続けて「早急に代替品を手配いたします」まで書く。謝罪と補償は別の工程であり、補償は⑤で決めることだ。したがって「補償・返金・交換に触れない」という条件は、書かせた後に消すのではなく生成前に渡しておく。ここが分かれ目になる。

3つとも共通しているのは、AIに何をさせているかの違いだ。生成させると参照させるは、同じ「文章を書かせる」でも別物になる。

• 生成させる — 「配送状況を案内する文面を書いて」。AIの仕事は空欄を埋めることなので、日付も業者名も、それらしいものが入る
• 参照させる — 受注データの該当行（注文番号・出荷日・追跡番号・配送業者）を本文に貼り、「この情報だけを使って書け。ここに無い情報は『確認のうえご連絡いたします』とせよ」と渡す。作業が書き写しに落ちるので、捏造の余地が構造的に消える

参照させる形に持っていくには、貼るデータを人が引いてくる必要がある。つまり④の照合は消えない。ここを飛ばして「AIに全部見せれば解決する」と考えると、次は見せてよいデータの範囲という別の問題になる（後述）。

なお、この2問の判定は問い合わせ対応に固有のものではない。商品ページの原稿でも同じ切り方ができる。ただし決定的に違うのは台帳の性質で、商品ページが参照するのは商品マスタという静的なデータであるのに対し、問い合わせが参照するのは受注データ・配送伝票・返品規定という1件ごとに違い、時間が経つと正解が反転するデータだ。「昨日注文したのですがキャンセルしたい」への正解が出荷ステータス次第で変わるのがその例になる。静的な台帳側の線引きは商品ページ制作でAIに任せられる範囲を整理した記事にまとめてある。

A／B／C 別の回し方

区分が付いたら、それぞれ渡し方が変わる。同じ「AIを使う」でも、Aは仕組みに載せる話、Bは渡す材料の話、Cは順番の話になる。

A（②③⑧）— 社内工程なので、ここから始める

要約・分類・記録は客に届かない。誤りが出ても書き直せばよく、実害の4経路のどれにも乗らない。だから初手はここになる。具体的には、着信した問い合わせ本文を要約させ、自店のタグを付けさせ、対応後に履歴として残す形にする。

ここで唯一設計が要るのはタグの粒度だ。一般的な分類名をそのまま使うと、あとで数えたときに何も決まらない。「返品・交換」で1つにまとめると、サイズ違いによる交換と初期不良による返品が同じ箱に入り、商品ページを直すべきか検品を直すべきかが分からなくなる。粒度は「そのタグで数えたら次に何をするか決まるか」で決める。数え方そのものの設計は集計側の領分なので、ここでは「タグは自店の対応手順に合わせて切る」までにしておく。

B（⑥）— 下書きに渡す最小セットを決める

文面の作成をAIに渡すとき、渡すものは4つに固定できる。

• 照合済みの事実 — ④で人が引いてきた受注データの該当行。注文番号・出荷ステータス・追跡番号など、確認済みのものだけ
• 回答方針 — ⑤で決めたこと。「交換で対応、返送料は当店負担、集荷は依頼済み」のように、負担する内容まで確定させた状態で渡す
• トーン — 既存の返信文を2〜3通そのまま貼るのが早い。「丁寧に」と書くより文体が揃う
• 禁止表現 — 「日付を書かない」「補償に触れない」「規定にない条件を作らない」。これを生成前に渡す

禁止表現を後から消すやり方は、人が全文を読み直せることを前提にしている。疲れているときの読み直しは必ず飛ぶ。生成前に渡しておけば、そもそも出てこない。この4つが揃っていれば、人が直すのは事実ではなく語順と長さになる。逆に言えば、下書きを受け取って事実を直しているうちは、④か⑤が終わっていない状態でBに入っている。

C（④⑤⑦）— 決めてから書かせる。送信は人

Cの工程には「AIの使い方」がほとんどない。④は自店の管理画面を見る作業で、⑤は権限の行使、⑦はボタンを押す行為だ。ここでAIに期待できるのは、④で引いたデータを整形することくらいで、判断そのものは移せない。

順番だけは変えられる。多くの現場は「とりあえず文面を書いてから、内容が正しいか考える」順になっている。これを方針を決めてから書かせる順に入れ替えるだけで、Bの手戻りが減る。クレーム対応でも同じで、謝罪の文面をどう工夫するかより先に、何をどこまで負担するかを決める。文面はそのあとの工程になる。

自動送信を検討するなら、条件はひとつ。先に取り消し手順を決めておくことだ。誤って送信した場合に、誰がいつ気づき、どう訂正の連絡を入れ、記録をどう残すか。これが決まっていない自動送信は、⑦を人から外したのではなく、取り消せない工程を無人にしただけになる。

ここまでを自分の担当業務に当てはめると、少し落ち着かない感覚が出てくるかもしれない。Aに区分した工程は、いずれ仕組み側に寄っていく可能性が高いからだ。ただしそれは、問い合わせを工程に割ったのと同じ要領で自分の仕事を割ってみれば、学ぶべきものが具体的に決まる、という話でもある。④と⑤——照合と判断の側に軸足を移すために何を身につけるかは、EC担当者が身につけるべきAIスキルを整理した記事で扱っている。

AIに渡す前に、消すもの・決めておくもの

問い合わせ本文には、こちらが求めていなくても個人の情報が入ってくる。氏名、住所、電話番号、メールアドレス、注文番号。「先週そちらで買った○○ですが、△△町の自宅に届いていません」という一文には、この時点で3つ入っている。これをそのまま外部のAIサービスに貼るかどうかは、精度の話とは別の判断になる。

ここで起きやすいのが、伏せると照合できなくなるというトレードオフだ。個人情報を全部消してから渡せば安全だが、注文番号まで消すと④の照合ができず、AIは再び「見ていない事実」を書く状態に戻る。だから消す項目は一律に決めず、工程ごとに決める。②の要約と③の分類には、氏名も住所も要らない。本文だけで足りる。④の照合は自店の管理画面でやる作業なので、そもそも外部に出す必要がない。⑥の文面作成には、宛名と注文番号のような、返信に必要な最小限だけが要る。この切り分けをしておくと、「伏せるか、精度か」の二択に見えていたものが二択でなくなる。

順番も間違えやすい。「このAIサービスは安全か」から入る人が多いが、先に見るのは自社の側だ。顧客の情報を社外のサービスに預けることについて、社内規程やプライバシーポリシー、委託先との取り決めが何と書いてあるかを確認する。そのうえで、使うサービスの契約プランと設定を見る。

公的な情報としては、通信販売の広告表示のうち返品に関する事項は省略が認められない項目として整理されているほか、表示の適正に関する所管官庁の解説、個人データの取り扱いに関するガイドライン、および生成AIサービスの利用に関する注意喚起が公表されている。自社の運用に何がどう当てはまるかは個別の判断になるため、公開時点の原文を確認したい。

入力データが学習に使われるかどうかは、サービスごと、さらに契約プランごとに扱いが違い、設定名も違う。たとえばAnthropicは商用製品について、既定では入力・出力をモデルの学習に使わないとしたうえで、利用者が明示的にフィードバック（thumbs up/down）を送った場合を例外として挙げ、組織の管理者が Organization settings > Data and Privacy の「Rate chats」設定から無効化できると説明している（Anthropic Privacy Center）。ここで見るべきは可否そのものではなく、「既定」と「例外」と「管理者が変えられる場所」の3点セットになっているという構造だ。他のサービスでも見る場所は同じで、名前が違うだけになる。仕様は変わるので、導入時点の公式ページで確認するのが前提になる。

事故の型4つと、送信前チェック

ここまでの線引きを守らなかったときに何が起きるかは、だいたい4つの型に収まる。どれも「AIが嘘をついた」のではなく、渡していない情報を自然な文体で埋めた結果として起きる。

型1: 配送状況・在庫の捏造。 最も多い型で、注文番号を渡さないまま「配送状況を案内する文面」を書かせると起きる。対策はプロンプトの改良ではなく、送信前に受注データと突き合わせる項目を先に決めておくこと。

型2: 別注文の情報混入。 同じ客から複数の問い合わせが来ているとき、あるいは前の対応履歴を一緒に渡したときに起きる。前述のとおり、楽天市場では注文前と注文後で入口が分かれるため、同じ案件が別スレッドになることもある。対策は、渡す本文にその案件の注文番号を必ず含めること。番号が書かれていない問い合わせは、まず番号を特定する工程が先に立つ。

型3: 古い条件の残存。 送料の無料ライン、返品を受け付ける期間、終了したキャンペーンの記載。これらをAIに書かせると、どこかで見た一般的な条件が混じる。対策は、固定文言をテンプレート側に置いてAIに書かせないこと。Shopifyのquick repliesのような定型文の置き場が用意されているなら、条件はそこに一元化する。掲載している条件と回答文が食い違うと、単なるミスでは済まなくなる。

型4: 言っていない約束。 「返品送料は当店で負担いたします」「本日中に再送手配いたします」。⑤を決めずに⑥へ入ると必ず出る。対策は順番で、方針を決めてから書かせる。

送信前チェックは「全文を読み直す」にしてはいけない。読み直しは疲労に弱く、件数が増えた日ほど飛ばされる。代わりに、照合する項目を先に決め打つ。たとえば次のような形になる。

• 本文中の注文番号が、いま開いている受注データと一致しているか
• 出荷ステータスと、文面に書かれた状態が矛盾していないか
• 追跡番号を書いているなら、それが配送伝票の番号と一致しているか
• 返品・交換の可否が、規定の条件と一致しているか
• 金額が入っているなら、受注データの金額と一致しているか
• 日付が入っていないか（入れる場合は、誰が確度を確認したか）

項目数は自店で決めてよいが、増やしすぎると読み直しと同じになる。「これを見なかったせいで過去に困った」ものだけを残すと、たいてい5つ前後に落ち着く。チェックの対象が文章ではなく項目になっているのが要点で、そうすると担当が代わっても同じ精度で回る。

対応履歴を、次の問い合わせを減らす材料に変える

工程⑧の記録は、片付けの作業に見えて、実際には唯一「次の件数を減らせる」工程だ。返信を速く書くのは1件を短くする改善だが、記録の還流はそもそも来る件数に効く。ここがAで、AIに任せてよい側にあるのは都合がいい。

還流先は3つある。ひとつはテンプレート。同じ回答を3回書いたら定型文にする、という単純な基準で足りる。ふたつめはFAQ。ただしFAQに追加すれば減るとは限らず、客が見る場所に置けているかが別の問題として残る。3つめが商品ページで、実はここが一番効く。

「これ、○○には使えますか」という質問が繰り返し来るとき、原因は返信文の出来ではない。商品ページに書いていないから聞かれている。つまり答えは商品マスタの中になく、書き足されていない情報が問い合わせという形で店に戻ってきている。同じ質問が続いているなら、返信を速くするより、その一文を商品ページに追記するほうが件数に効く。サイズ違いによる交換が続くなら、サイズ表記や実寸の書き方を疑う。これらは全部、⑧のタグを数えないと見えてこない。

数えるときは、単位を先に決めておく。件数なのか、対応にかかった時間なのか、同一顧客からの再問い合わせを1件と数えるのか2件と数えるのか。ここを決めずに集計すると、後から「先月より減った」が何を意味するのか分からなくなる。特に再問い合わせの数え方は、誤答の影響を測る唯一の手がかりになるので、最初に決めておきたい。集計した数字を、商品ページの修正や体制の見直しといった社内の意思決定に載せるところまでは、ECのデータを社内提案に変える手順を参照してほしい。数えただけでは何も動かない。

この還流が回り始めると、AIの入れどころが変わってくる。最初は②要約と③分類、つまり1件を速く捌くために入れる。回り出すと、⑧に溜まった履歴をまとめて読ませ、「この1か月で繰り返し出ている論点」を抽出させる使い方になる。これも社内で完結する工程なので、区分はAのままだ。客に届かない側だけで、件数の構造が見えてくる。

よくある質問

AIに自動送信させてもいいですか

約束を含まない工程に限れば検討の余地はあるが、条件がひとつ付く。先に取り消し手順を決めておくことだ。誤送信に誰がいつ気づき、どう訂正するか、記録をどう残すかが決まっていない状態での自動送信は、取り消せない工程を無人にしただけになる。受付完了の通知のような、事実の確認だけで済むものから検討するのが順当になる。

問い合わせ本文をそのままAIに貼ってもいいですか

可否を一律に決められる問題ではなく、先に見るのは自社の側になる。社内規程やプライバシーポリシー、委託先との取り決めを確認したうえで、使うサービスの契約プランと設定を公開時点で確認する。そのうえで、工程ごとに伏せる項目を決めておく。②要約と③分類には氏名も住所も要らない、という切り分けだけでも、外に出る情報はかなり減る。

チャットボットを入れれば問い合わせは減りますか

減るのは①受信と②要約の負荷で、④照合と⑤方針決定は残る。定型的な案内で解決する件は入口で吸収できるが、「私の注文はどうなっていますか」は結局、受注データを見ないと答えが出ない。したがって「件数が減るか」ではなく「どの工程の負荷が減るか」で見るほうが、導入後のズレが小さい。

モールでも同じ考え方でいいですか

8工程そのものは同じで、変わるのは工程①の入口と、守るべき規約のほうになる。返信に関するルールや、外部ツール・AIの利用可否は各モールの規約とヘルプに定められているため、自社アカウントの管理画面から公開時点で確認したい。日数や可否をこの記事の記述で判断しないでほしい。

まず何から始めればいいですか

②要約と③分類から。理由は単純で、客に届かないからだ。間違えても書き直せる工程で運用の感覚をつかんでから、⑥の下書きに進む。逆に、最初から返信文の自動生成に手を付けると、④と⑤が整理されていない状態で客に届く工程を触ることになり、事故の4型に直行する。

AIが進化したら、CS担当は要らなくなりますか

⑤の回答方針の決定は、精度の問題ではなく権限の問題になる。返金するか、送料をどちらが負担するか、規定の例外を認めるかは、店として何を負担するかの意思決定であり、正確に書けるかどうかとは別の軸にある。したがって「AIが十分賢くなったら任せられる」という種類の工程ではない。一方でAに区分した工程は仕組み側に寄っていくため、担当者の時間配分は④と⑤に寄っていくことになる。

あわせて読みたい：氏名や住所を含む受注データの扱いは、ネットショップの受注処理をAIで効率化する：氏名と住所を渡さずに速くする手順で扱っています。

あわせて読みたい：状況ごとの返信テンプレを整え直す実務手順は問い合わせ返信テンプレを、AIで作り直すで扱っています。