投稿者 投稿日: カテゴリー EC×AI活用
AIチャットボット EC導入とは、生成AIで接客と問い合わせ対応を自動化する仕組みのことです。
「商品ページの右下に出るチャット窓を置けば離脱が減る」と聞いて設置したものの、定型回答しか返せず結局お問い合わせフォームに流れていく。これが従来型チャットボットで多くの自社ECが踏んだ失敗でした。2026年に入り、GPT-5.5 Instantやセール商品の在庫を読みながら回答するタイプが現実的な価格で組めるようになり、設計の前提が変わっています。この記事では、自社EC・Shopifyを中心に、用途の切り分けからシナリオ設計、有人エスカレーション、効果測定までを手順として並べます。プロンプト例は連番で6本掲載します。
チャットボットがECのどこに効いて、どこで逆効果になるか
最初に押さえたいのは、AIチャットボットは万能の売上ブースターではなく、使いどころを外すと逆にCVRを下げる道具だという点です。効くのは「購入前の小さな迷いをその場で消す」場面と「夜間・休日のCS一次受け」の2つに集約されます。
購入前の迷いとは、サイズが合うか、在庫があるか、いつ届くか、定期便はいつでも解約できるか、といった質問です。これらは答えが決まっていて、回答が遅れるほど離脱率が上がります。アパレル系の単一店舗で試したケースでは、サイズ相談に即答できる導線を商品ページに置いたところ、相談を経由したセッションのカート投入率が、相談しなかったセッションより明確に高く出ました。ただしこれは「相談する人はもともと購入意欲が高い」という選択バイアスを含むため、CVRが何倍になったとは断定できません。相談経由のCVRが高いケースがある、という観測にとどめます。
カスタマーサポート分野では、外部調査でも自動化の余地が示されています。ガートナーは、2025年までに顧客サービスとサポートの相互作用の最大10%が生成AIで対応されると見込むと公表しました（出典はGartner）。あくまで全業界の予測値であり、日本のEC単体の数字ではない点に注意は必要ですが、CS一次受けに自動化の意味があるという方向性は妥当だと判断します。
逆効果になるのは、複雑な要望や感情的なクレームを最初からボットに通そうとする設計です。返品理由が「届いた商品が破損していた」というケースで、ボットが規約のリンクを淡々と返すと、顧客の不満は一段上がります。直近の支援案件で観測したのは、クレーム性の高い入口だけは最初から有人チャットへ振る設計にした店舗のほうが、解約率もレビュー炎上も低かったという傾向でした。効く場面と効かない場面を最初に線引きすることが、設計の出発点になります。
もう一つ、効きにくいのが「商材の説明そのものが難しい高単価品」です。オーダー家具やBtoB向けの業務用機材のように、仕様の摺り合わせが長く続く商談型の購買は、チャットボットの一問一答とは相性が悪い領域です。ある食品ジャンルの中規模店舗の事例では、ギフトの熨斗（のし）の細かい指定や、アレルギー成分の問い合わせのように「間違えると事故になる」質問は、最初から有人に振る運用にしていました。逆に「賞味期限はどれくらいか」「冷凍便か常温便か」といった定型の質問はボットで即答させ、人とボットの役割を質問の性質で分けていたのが奏功していました。チャットボットを入れるかどうかではなく、どの質問を入れてどの質問を外すか、という粒度で設計する姿勢が要ります。
なお自社ECとShopifyは外部スクリプトの埋め込みが自由なので導入のハードルが低い一方、楽天市場とAmazonはモール内のチャットや問い合わせ機能に独自の制約があり、外部チャットボットの自由な設置はできません（規約は変動するため要確認）。このマニュアルは自社EC・Shopifyを主対象とします。
導入手順とシナリオ設計（プロンプト6本付き）
ここがこの記事の中心です。導入は「用途決め→ツール選定→シナリオ設計→有人接続→公開→改善」の6ステップで進めます。
最初のステップは用途の優先順位づけです。すべてを一度に自動化しようとすると、シナリオが膨らんで品質が落ちます。購入前の質問対応、サイズ・在庫案内、CS一次受け、レコメンドの4用途のうち、自店で離脱が最も多い1〜2用途に絞って始めるのが定石です。Shopify Adminの「アナリティクス」で、どのページで離脱が起きているかを先に見てから決めます。
2つ目はツール選定です。実装方法は大きく3つに分かれます。1つはShopifyアプリや各社チャットボットSaaSを入れる埋め込み型で、管理画面でシナリオを組むため非エンジニアでも回せます。2つ目はノーコードのフロービルダーで、条件分岐を視覚的に作れます。3つ目はOpenAIやGoogle、AnthropicのAPIを自社サーバーから直接叩く方式で、自由度は最も高い反面、保守要員が要ります。月商規模が小さいうちはSaaS、商品マスタや在庫APIと深く連携したくなったらAPI直叩きへ移行する、という順序が現実的です。Shopifyアプリの選び方はShopify向けAIアプリの選び方に詳しくまとめています。
選定時に見落とされがちなのが、日本語の自然さとログの所有権です。海外発のSaaSは英語圏の事例が豊富でも、日本語の敬語や配送・返品まわりの言い回しが不自然になることがあります。実際に自店の商品データで数問試し、回答のトーンを確認してから契約するのが安全です。あわせて、チャットログの保存場所、ログを提供元の学習に使う設定かどうか、解約時にデータを持ち出せるかを契約前に確認します。ここを詰めずに入れてしまうと、後から個人情報の取り扱いで作り直しになります。料金体系も、月額固定か、会話数や処理テキスト量に応じた従量かでコストの伸び方がまったく違うため、自店の想定会話数を当てはめて試算してから決めます。
ツールが決まったら、設置位置も設計対象です。チャット窓を全ページの右下に常時出すか、商品ページとカート画面に限定して出すかで、起動率も雰囲気も変わります。トップページから出すと「とりあえず置いた感」が出やすく、購入前の迷いが生まれる商品詳細ページとカート離脱が起きるカート画面に絞ったほうが、会話の質は高くなる傾向があります。スマートフォンでは窓が商品画像や購入ボタンを隠さないか、表示位置を実機で必ず確認します。
3つ目以降のシナリオ設計から、プロンプトを使います。生成AIに回答そのものを丸投げするのではなく、回答のトーンと禁止事項を固定したうえで、商品情報や在庫データを変数で渡すのが安全です。以下、用途別に6本を掲載します。
応答の基本人格を決めるのが最初です。トーンがぶれると、安いプラスチック雑貨の店なのに妙にかしこまる、といったちぐはぐが起きます。
プロンプト1：チャットボットの応答基本設計（システムプロンプト）
あなたは{店舗名}のオンライン接客スタッフです。
扱う商品は{商品ジャンル}、主な客層は{客層}です。
以下のルールで顧客に回答してください。
1. 1回の回答は3文以内、ですます調、専門用語は避ける
2. 在庫・価格・配送日は、与えられた商品データ{product_data}のみを根拠にし、推測で答えない
3. データに無い質問、返品・クレーム・個人情報に関わる質問は、回答せず「担当者におつなぎします」と返して有人フラグを立てる
4. 値引き交渉・転売目的と判断される質問には応じない
5. 医薬品的な効能効果（治る、効く、痩せる等）は一切述べない
顧客の質問：{user_message}
商品データ：{product_data}
次に、購入前で最も多いサイズ・在庫・配送の質問です。ここは回答精度がそのままCVRに響くため、データの根拠を明示させます。
プロンプト2：サイズ・在庫・配送の即答（購入前対応）
顧客は商品ページ{product_url}を見ています。
以下のデータだけを使い、顧客の質問に答えてください。データに無ければ「確認しますので少々お待ちください」と返し、有人フラグを立てます。
- 在庫数：{stock}
- サイズ表：{size_chart}
- 当日出荷の締切時間：{cutoff_time}
- 配送目安：{delivery_days}
回答末尾に、関連して見られることが多い質問を1つだけ提案してください（例：返品可否、ギフト包装の有無）。
顧客の質問：{user_message}
レコメンドは押し売りにすると逆効果なので、提案は2点までに絞らせ、在庫切れ商品を出さないよう制御します。
プロンプト3：購入前のレコメンド（最大2点）
顧客の発言{user_message}から、欲しい商品の条件（価格帯・用途・好み）を読み取ってください。
以下の在庫あり商品リスト{in_stock_products}の中から、条件に合うものを最大2点だけ提案します。
- 在庫切れ商品は提案しない
- 高い順に並べ替えて高額品を勧める誘導はしない、条件適合度の高い順にする
- 各提案に「なぜ合うか」を1文添える
- 該当が無ければ正直に「条件に合う在庫が今ありません」と伝える
条件に合う商品が無いときは、入荷通知の登録を案内してください。
CS一次受けでは、FAQの整備が品質を左右します。既存の問い合わせ履歴からFAQ原稿を量産するプロンプトを置きます。
プロンプト4：問い合わせ履歴からFAQ自動生成
以下は過去の顧客からの問い合わせメール{inquiry_logs}です。
内容を分類し、頻度の高い順に質問と回答のFAQを15本作成してください。
- 質問は顧客が実際に使う言葉で（「返品できる?」など口語可）
- 回答は3文以内、{店舗名}の配送・返品ポリシー{policy_text}に厳密に従う
- 個人情報・特定顧客の事情は一般化して残さない
- ポリシーに記載が無い論点は「要確認」と印を付け、別表にまとめる
出力：FAQ本文15本＋要確認リスト
有人への切り替えは設計の生命線です。どの条件で人間に渡すかをボット自身に判定させます。
プロンプト5：有人エスカレーション判定
以下の会話履歴{conversation}を読み、有人対応に切り替えるべきか判定してください。
切り替える条件：
1. 顧客が「人を出して」「電話したい」と明示した
2. 返品・返金・破損・誤配送などトラブル性の高い話題
3. 同じ質問を2回以上繰り返し、ボットの回答で解決していない
4. 感情的な表現（怒り・不満）が強い
5. 個人情報（住所変更、注文番号での照会）が必要な手続き
判定結果（切替する/しない）と理由を1文で返し、切替する場合は引き継ぎメモ（要点3行）を作成してください。
公開後の改善では、解決できなかった会話ログから穴を見つけます。レビューと改善を回す前提のプロンプトです。
プロンプト6：未解決ログの改善点抽出（週次レビュー）
以下は直近1週間の、有人に切り替わった会話ログ{escalated_logs}です。
ボットで解決できなかった理由を分類し、シナリオ・FAQの改善案を作成してください。
- 「データ不足」「シナリオ未対応」「言い回しのミスマッチ」の3カテゴリに分類
- 各カテゴリで具体的な追記案（FAQ追加文・分岐追加）を提示
- 件数の多い順に並べ、来週優先で直すべき上位3件に印を付ける
出力：分類別の件数＋改善案＋優先3件
この6本は、システム設計・購入前対応・レコメンド・FAQ生成・有人判定・改善という導入の全工程に対応します。商品データや在庫を変数で渡す前提なので、Shopifyの商品APIやCSVと連携させると精度が安定します。レコメンドの設計思想は生成AIのEC活用事例も参考になります。
公開前に必ず通したいのが、わざと意地悪な質問を投げるテストです。在庫数を実在しない大量にして「100個買えますか」と聞く、配送日を曖昧に聞く、規約に無い特殊な返品条件を聞く、薬機法に触れそうな効能を聞く、といった質問を10〜20問用意して回答を点検します。ここで、データに無いことを断定したり、医薬品的な効能を述べたり、有人に渡すべき相談を抱え込んだりする挙動が見つかれば、プロンプトのルールを追記して塞ぎます。編集部で実際に運用しているプロンプトでは、この「想定外質問リスト」を公開前と、シナリオを更新するたびに毎回回す運用にしています。公開してから顧客で実験する形になると、低評価レビューという形で代償を払うことになるためです。
なお、ここで紹介したプロンプトはあくまで設計の出発点です。自店の商材・客層・ポリシーに合わせて、禁止事項やトーンを書き換えて使ってください。とくにプロンプト1の人格設計とプロンプト4のFAQ生成は、自店のポリシー文書をそのまま変数に流し込むと、回答の一貫性が大きく上がります。
失敗例と回避策
導入で繰り返し見る失敗は3つに整理できます。いずれも設計段階で防げるものです。
1つ目は、誤回答による信用毀損です。在庫や配送日を生成AIに自由回答させると、データに無い情報をもっともらしく作る、いわゆるハルシネーションが起きます。「明日届きます」と答えたのに翌々日着だった、という1件が低評価レビューに直結します。回避策は、在庫・価格・配送など事実は必ず商品データを根拠にさせ、データに無ければ答えさせない設計です。プロンプト1とプロンプト2で根拠データを明示的に縛っているのはこのためです。
2つ目は、有人切り替えの設計漏れです。ボットだけで完結させようと欲張ると、解決できない顧客が出口を失って離脱します。現場で繰り返し見るのは、エスカレーションの導線が無いまま深夜に複雑な相談が来て、翌朝まで放置される状況です。回避策は、プロンプト5のような判定ルールを最初から組み込み、営業時間外は「明日◯時に担当から連絡します」と着地させる設計にすることです。完全自動化より、ボットと有人のハイブリッドのほうが満足度は安定します。
3つ目は、個人情報と規約の扱いです。注文番号や住所をチャット欄に入力させて手続きを進めると、ログの保管や第三者ツールへの送信が個人情報保護法の論点になります。チャットログを学習に使う設定のSaaSもあるため、契約前にデータの取り扱いを必ず確認します。また楽天市場やAmazonでは、モール外への誘導やモール規約に反するチャット運用ができないため、これらのモール商品ページに外部チャットボットを置く前提で設計しないことが重要です（規約は変動するため要確認）。個人を特定する手続きはボットで完結させず、安全な会員ページや有人対応に渡すのが無難です。
この3つに加えて、見落とされやすい4つ目として、薬機法・景品表示法に触れる回答のリスクがあります。サプリや化粧品を扱う店舗で、顧客が「これで肌が治りますか」と聞いたときに、ボットが商品レビューの文言を拾って「効果があります」と答えてしまうと、店舗が法的な責任を負いかねません。回避策は、プロンプト1のように効能効果を述べることを明示的に禁止し、医薬品的な質問は有人に渡す設計を最初から組み込むことです。アパレルや雑貨では起きにくい論点ですが、健康・美容系の商材を扱うなら必須のガードになります。生成AIは与えられた情報を流暢にまとめるのが得意なぶん、レビューや口コミの過剰な表現をうっかり再生産する危険があるという前提で、禁止事項を厚めに書いておくのが安全です。
KPI設計と費用・工数の目安
効果測定をしないチャットボットは、改善のしようがありません。追うべきKPIは用途ごとに分けます。
購入前対応なら、チャット経由セッションのカート投入率とCVR、そしてチャット起動率（窓を開いた割合）を見ます。前述のとおりチャット利用者は購入意欲が高い側に偏るため、CVRの単純比較ではなく、A/Bテストで「チャットを出すページ／出さないページ」を分けて測るのが正確です。CS用途なら、一次解決率（ボットだけで完結した割合）、有人エスカレーション率、平均応答時間、問い合わせ削減率を追います。一次解決率は導入直後で目安として3〜5割程度から始まり、FAQと分岐を育てると上がっていく、というのが現場感覚です。これは店舗の商材や質問の複雑さで大きく振れるため、自店の初期値を基準に改善幅で評価するのが妥当です。
費用は実装方式で幅があります。生成AIのモデル利用料は、ChatGPTの有料プランが月20米ドル、Claude Proが月20米ドル、Gemini系の有料プランも月20米ドル前後という水準です（2026年6月時点、価格は変動するため要確認）。ただしこれは個人がチャット画面で使う料金で、サイトに組み込む場合はAPI従量課金になります。API課金は処理したテキスト量に応じた単価で、軽量モデル（GPT-5.5 Instant、Gemini 3.5 Flashなど）を使えば1問あたりの単価はごく小さく抑えられます。チャットボットSaaSの月額はベンダーと会話数で大きく変わるため、具体額は各社見積もりで要確認とします。
工数の目安として、SaaSの埋め込み型で用途を1つに絞れば、初期設定は数日から1〜2週間で立ち上がるケースが多いです。API直叩きで在庫連携まで作り込むと、エンジニア工数で数週間規模になります。運用は週次でプロンプト6のレビューを回す前提で、担当1人が週1〜2時間を確保できれば回ります。CRM側の顧客データと連携させたい場合はECのCRM×AI活用もあわせて検討してください。
KPIで一つ補足しておきたいのは、評価の時間軸です。導入直後はFAQも分岐も未成熟なので、一次解決率は低く出ます。ここで「効果が無い」と判断して止めてしまうのが、よくある早すぎる撤退です。少なくとも数週間はプロンプト6の週次レビューでシナリオを育て、一次解決率と問い合わせ削減率の改善幅で評価するのが妥当です。楽天/Amazonの両方を回している店舗で観測されたのは、自社ECのチャットボットで定型問い合わせを吸収できると、モール側の手動対応に人手を回す余裕が生まれ、店舗全体のCS品質が底上げされるという波及効果でした。直接のCVR改善だけでなく、こうした運用負荷の平準化も投資回収の一部として見ておくと、評価を見誤りません。
接客チャットボットから購買エージェントへ
2026年に起きている大きな変化は、チャットボットが「質問に答える窓」から「顧客に代わって動くエージェント」へ近づいていることです。
これまでのチャットボットは、顧客が能動的に質問して初めて反応する受け身の存在でした。今は、対話の中で在庫を確認し、サイズを提案し、カートに入れ、クーポンを適用するところまでをひと続きで担える土台が整いつつあります。さらにその先には、消費者側のAIエージェント（消費者が使う買い物代行AI）が店舗のチャットや商品データに直接アクセスして比較・購入する流れが見え始めています。店舗側のチャットボットは、人間の顧客だけでなく、相手側のAIにも構造化された情報を返せる設計が問われるようになります。この消費者側エージェントへの備えはAIショッピングエージェント対応のEC最適化で詳しく扱っています。
独自の見立てとして、勝ち負けを分けるのは生成AIの賢さそのものではなく、自店の商品データと在庫・配送情報をどれだけ正確に、リアルタイムで渡せるかだと考えています。どれほど高性能なモデルでも、根拠にできるデータが古ければ誤回答します。チャットボット導入の本丸は、表に見えるチャット窓ではなく、その裏側の商品マスタと在庫データの整備にあるという見方を持っておくと、投資の優先順位を外しません。LINEなどメッセージング接客との連携を考える場合は、海外の動向としてrespond.ioのメッセージング・コマースも参考になります。
もう一段先を読むと、チャットボットは購入後の体験にも染み出していきます。発送通知や配送状況の照会、定期便の周期変更、再注文の提案までを対話の中で完結させる流れが現実味を帯びています。問い合わせを減らす守りの道具から、リピートを生む攻めの接点へと役割が広がっていくということです。ここでも前提は同じで、注文データや配送ステータスを安全に、かつ正確に渡せる基盤があって初めて成立します。5,000社支援の中で何度も再現したパターンとして、表側の華やかな機能から入った店舗より、地味なデータ整備から入った店舗のほうが、結局は長く効果を出し続けています。新しいモデルが出るたびに乗り換えるのではなく、自店のデータを整え、そこに最新モデルを差し替えていける構造を作っておくことが、変化の速いこの分野での堅い戦い方だと考えます。
よくある質問
無料で始められますか
簡易なものなら無料枠から試せます。生成AIの無料プランや、無料枠のあるチャットボットSaaSで小さく検証できます。ただし在庫連携や有人切り替え、ログの安全な保管まで含めると、有料プランやAPI従量課金が前提になります。まず1用途を無料枠で試し、効果が見えてから有料へ広げるのが堅実です。
ChatGPT・Claude・Geminiのどれを選ぶべきですか
チャットボットの応答用途では、応答速度とコストのバランスが取れた軽量モデル（GPT-5.5 Instant、Gemini 3.5 Flashなど）が現実的です。FAQ原稿の一括生成やシナリオ設計のような重い文章処理には、Claude Opus 4.8など上位モデルが向きます。多くのSaaSはモデルを内部で選んでいるため、API直叩きでない限り過度に悩む必要はありません。
楽天市場やAmazonの商品ページにも設置できますか
外部チャットボットの自由な埋め込みはできません。これらのモールはモール内の問い合わせ・チャット機能に独自の制約があり、外部スクリプトの設置やモール外誘導が規約で制限されます（規約は変動するため要確認）。このマニュアルが自社EC・Shopifyを主対象としているのはこのためです。モール側は提供される範囲の機能を使うことになります。
導入の最初の一歩は何をすればよいですか
自店で最も離脱が起きているページと、最も多い問い合わせを特定することです。Shopify Adminや問い合わせメールの履歴を見て、自動化する用途を1つに絞ります。全用途を同時に始めると品質が落ちるため、効果の出やすい購入前対応かCS一次受けのどちらかから始めるのが定石です。
誤った回答で顧客に迷惑をかけないか心配です
在庫・価格・配送など事実は必ずデータを根拠にさせ、データに無い質問は答えさせず有人に渡す設計にすれば、致命的な誤回答は大きく減らせます。プロンプト1とプロンプト2のように、根拠データを明示して縛るのが基本です。公開後はプロンプト6で未解決ログを週次で点検し、穴を埋め続けます。
有人対応の担当者は何人必要ですか
導入初期は、エスカレーションされた会話だけを見れば足りるため、既存のCS担当が片手間で対応できる規模から始められます。ボットが一次解決率を上げるほど、人間が見る件数は減ります。深夜・休日は「翌営業日に連絡」と着地させる設計にすれば、24時間体制を組まなくても運用できます。
著者：齋藤竹紘（株式会社オルセル 編集長／5,000社以上のEC支援実績／書籍3冊）
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
