AIでFAQの下書きを作るだけでは問い合わせは減らない。過去の問い合わせログを分類してからAIに下書きさせ、人がレビューして「実際に聞かれた質問」だけを載せ、公開後も更新し続けて初めて件数が落ちる。作って終わりにすると、閲覧はされても件数は動かない。
- AIにゼロからFAQを書かせると「聞かれてもいない想定問答」が並ぶ。起点は過去の問い合わせログの分類であって、文章生成ではない
- 効果は「FAQページのPV」ではなく「同じカテゴリの問い合わせ件数の前後比較」で見る。指標を取り違えると、効いていないものを効いていると誤判定する
- FAQで吸収できるのは定型の質問だけ。個別事情が絡む問い合わせは減らず、そこはCS担当の判断が残る領域になる
「FAQは作った。それで、問い合わせは減ったのか」
きっかけはたいてい同じだ。CS対応の残業が続き、上長が「FAQを充実させれば減るんじゃないか」と言う。担当者はその週のうちに着手する。ヘルプページのテンプレートを開き、質問を30個ほど並べ、回答を書き、公開する。ここまでは早い。生成AIを使えば、下書きは半日で埋まる。
問題はその2か月後だ。上長が「あれ、効いてる？」と聞く。担当者はGA4を開いてFAQページのセッション数を見る。数字は伸びている。伸びてはいるが、それが何を意味するのかを説明できない。同じ週の受信箱には、配送予定日の問い合わせが前月と同じように並んでいる。
この状態は珍しくない。FAQは存在している。閲覧もされている。それでもCS担当の1日の作業量は、着手前と変わっていない。
問い合わせの入り口を数えてみると、EC事業者の場合はたいてい4つ以上ある。自社サイトの問い合わせフォーム、代表メールアドレス、楽天市場ならRMSのR-Messe、Amazonならセラーセントラルの購入者からのメッセージ、Shopify運用ならShopify Inbox、加えて電話。チャットボットを入れていればそのログもある。窓口ごとに担当が違い、返信の控えが残る場所も違う。この時点で「よく来る質問は何か」を、件数で言える人が社内にいない。
だからFAQの質問リストは、記憶で作られる。CS担当が「よく来る気がするもの」を挙げ、商品部が「聞かれそうなこと」を足し、上長が「これも入れておこう」と言う。会議で決まった30問には、誰かの実感は入っているが、件数は入っていない。
そのリストを生成AIに渡すと、回答は整った文章で返ってくる。日本語は自然で、敬体も揃っている。読んで違和感がないので、そのまま公開される。公開されたFAQを読んで違和感がないことと、それが問い合わせを吸収することは、別の話だ。
実際に何が起きているかは、受信箱を1週間ぶん眺めれば見当がつく。届いているのは「注文した商品がまだ届かない」「サイズを間違えたので交換したい」「クーポンが適用されていない」といった、注文番号や個別の事情が絡んだ質問である。一方、公開したFAQの1問目は「支払い方法には何がありますか」だったりする。決済画面を見れば分かる情報が、いちばん目立つ位置に置かれている。
ここで担当者が取りがちな手が2つある。ひとつはFAQの数を増やすこと。30問を80問にする。もうひとつは文章を直すこと。表現がかたい、説明が長い、と社内で言われるので書き直す。どちらも作業としては真っ当に見えるが、件数には効きにくい。載せる質問を決めた工程に、まだ触っていないからだ。
80問に増やしたFAQは、別の副作用も生む。目次が長くなり、顧客は探すのをやめて問い合わせフォームを開く。「探しましたが分かりませんでした」と本文に書かれた問い合わせが増えたなら、それはFAQが増えたことの結果である可能性がある。件数は減らず、一次対応の手間だけが増える。
FAQを作った週の担当者は、手順としては何も飛ばしていない。テンプレートを開き、質問を並べ、AIに下書きを作らせ、レビューして公開した。抜けているのは、その手前にあるはずだった1工程だけである。
これは文章の問題ではない。載っているのが「想定問答」だからだ
この記事では、社内の想像で作られた質問リストを「想定問答」と呼ぶ。展示会の受付やIR説明会の準備で作る、あの想定問答集と同じものだ。聞かれるかもしれないことを、聞かれる前に用意しておく。備えとしては正しい。だがFAQの目的が「問い合わせ件数を減らすこと」なら、想定問答は目的に対して外れている。
減らしたいのは、実際に届いている問い合わせである。想定問答が答えているのは、届くかもしれない問い合わせだ。この2つは重ならない。重ならないから、公開しても件数が動かない。
生成AIは、この構造をむしろ加速させる。「ECサイトのFAQを30問作って」と入力すれば、支払い方法、配送日数、返品条件、会員登録、ポイント、キャンセルといった一般的な項目が、整った文章で即座に並ぶ。参照されているのは世の中のFAQページ全般であって、自社の受信箱ではない。AIは、よくあるFAQを作るのがうまい。自社によく来る問い合わせを減らすFAQを作るのがうまいわけではない。
ここを取り違えると、改善の方向がずれる。「AIの出力の質が低いのだろう」と考えてプロンプトを凝りはじめる。役割を与え、トーンを指定し、文字数を制限する。出てくる文章はたしかに良くなる。それでも件数は動かない。入力に自社の問い合わせが1件も入っていない以上、出力が自社の問い合わせに当たる理由がないからだ。
想定問答には、もうひとつ固有の弱点がある。質問文が社内語になることだ。社内で「配送日時指定」と呼んでいるものを、顧客は「時間の指定」「届く時間」と書いて検索する。「返品」と「交換」を規程上は明確に分けていても、顧客は両方を「返品」と書いて送ってくる。想定問答は社内の会議で作られるので、質問の見出しまで社内語で書かれる。FAQ内の検索窓に入れられた言葉と一致しない。
ログ起点に切り替えると、ここは自動的に直る。顧客が実際に書いた文面が手元にあるので、質問文を顧客の言葉で書けるようになる。翻訳の作業であって、文章力の作業ではない。
想定問答を全部捨てろという話ではない。新商品や新しい決済手段を出すときは、ログが存在しないので想像で書くしかない。分けて扱えばいい。既存の問い合わせを減らす目的のFAQはログから作り、まだ起きていないことへの備えは想定問答として作る。混ぜて1本のリストにするから、どちらの目的も達成できない状態になる。
担当者は公開済みのFAQ一覧を開き、1問ずつ「これは先月、何件来たか」と自問することになる。答えられる行と、答えられない行に分かれる。答えられない行が大半なら、そのFAQは件数のために作られていない。
そのまま使える：問い合わせログからFAQ下書きを作る7ステップ
ここから先は、この記事の前半を読んでいなくても単体で使える手順として書く。角かっこ [ ] の中を自分の店の内容に置き換えれば、そのまま使える。初回は集計を含めて半日から1日かかる。2周目以降は月[ ]分で回る想定で、最初に回したときの実時間を測って埋めておくと、翌月から社内で工数を説明できる。
ステップ1：ログを1か所に集める
対象期間を決める。繁忙期の偏りを避けたいので、直近3か月か、セール月を含む直近6か月のどちらかにする。窓口ごとに書き出す。フォームの受信メール、代表メール、R-Messe、セラーセントラルの購入者メッセージ、チャットの会話ログ、電話の対応メモ。ヘルプデスクツールを入れていればチケットのCSVを書き出せば済むが、そうでなければここは手作業になりやすい。
表計算シートに1件1行で貼る。必要な列は5つだけでいい。
受付日／窓口（フォーム・メール・R-Messe・電話・チャット）本文（顧客が書いた原文。要約しない）大分類（後で埋める）／小分類（後で埋める）注文に紐づくか（はい／いいえ。ここが「FAQで吸収できるか」の分かれ目になる）
要約して貼らないことが大事だ。要約した瞬間に、顧客が使った言葉が消える。消えた言葉は、FAQの見出しにも検索窓にも戻ってこない。
ステップ2：AIに渡す前にマスキングする
本文には氏名、住所、電話番号、メールアドレス、注文番号が混ざっている。外部の生成AIサービスに投入する前に、この5種類を置換する。表計算の置換機能と正規表現で機械的に落とせるものが多いが、本文中に手打ちされた住所は残りやすいので、目視の確認工程を1回入れる。
置換の書式は決め打ちでいい。[氏名] [住所] [電話] [メール] [注文番号]。置換後の文面が読めれば分類には十分である。
あわせて、社内で確認しておく項目が2つある。顧客情報を外部サービスに送信することが自社のプライバシーポリシーと委託契約の範囲に収まるか、そして利用する生成AIサービスの入力データの取り扱い設定がどうなっているか。ここは事業者ごとに条件が違うので、一般論で判断せず、自社の規程と各サービスの利用条件を確認したうえで進めたい。マスキングは、その確認を省くための代替手段ではない。
ステップ3：分類する。ここがこの手順の本体である
大分類は10個以内に抑える。多くのEC事業者なら、次の枠でだいたい収まる。
- 配送（未着・遅延・日時変更・追跡）／注文（変更・キャンセル・重複）
- 返品交換（不良・イメージ違い・サイズ）／商品（在庫・仕様・入荷予定）
- 決済（エラー・領収書・分割）／会員（ログイン・退会・パスワード）
- 販促（クーポン・ポイント・キャンペーン条件）／その他
小分類は、大分類の中で「同じ回答文で答えられるか」を基準に割る。「いつ届くか」と「届かないので調べてほしい」は、どちらも配送だが回答が違う。前者はFAQで吸収できる。後者は注文番号を見ないと答えられない。
分類そのものをAIに手伝わせてもいい。マスキング済みの本文を100件ずつ渡し、次のように指示する。
- 「以下は[自社の業種]のECサイトに届いた問い合わせ本文です。内容ごとに分類し、各分類に含まれる件数と、代表的な原文を3件そのまま抜き出してください」
- 「分類名は、社内用語ではなく、顧客が実際に使っている言葉を優先してください」
- 「注文番号や個別の状況を確認しないと回答できないものは、別枠に分けてください」
分類が終わったら、件数の多い順に並べ替える。ここで初めて、社内の全員が同じ数字を見ることになる。上位10件で全体の何割を占めるかを出す。この割合が、FAQで狙える上限の目安になる。
ステップ4：FAQにする候補を選ぶ
選定の条件は3つ。件数が多いこと。注文に紐づかないこと。回答が1つに定まること。3つとも満たす小分類だけをFAQ候補に入れる。件数が多くても、注文番号を見ないと答えられないものは外す。ここを混ぜると、FAQを読んだ顧客が結局問い合わせてくるので、件数が動かない。
ステップ5：AIに下書きを作らせる
候補ごとに、その小分類の原文を5〜10件添えて渡す。下書き用の指示は次の形にする。
- 「あなたは[自社の業種]のECサイトのカスタマーサポート担当です」
- 「以下は、同じ内容で届いた問い合わせの原文です。これに対するFAQの質問文と回答文を作成してください」
- 「質問文は、原文で顧客が使っている言葉を優先して1文で書いてください」
- 「回答は、①結論 ②理由または手順 ③それでも解決しない場合の導線、の順で、[300]字以内」
- 「原文から読み取れない社内規程・日数・金額は書かず、
【要確認】と書いて空欄にしてください」 - 「前提条件：[返品期限] [送料負担のルール] [営業日の定義]」
最後の2行が要になる。日数や金額をAIに埋めさせると、それらしい数字が入る。「商品到着後7日以内」「返送料はお客様負担」といった、一般的で、自社の規程とは限らない文言が入る。【要確認】で空欄にさせておけば、埋める作業が発生するので、誰も気づかないまま公開される事故を防げる。
ステップ6：人がレビューする。見るのは3点だけ
全文を読み直すのではなく、次の3点に絞る。
- 数字と条件：日数・金額・期限・対象範囲が、現行の利用規約と返品ポリシーの記載と一致しているか。
【要確認】が残っていないか - 約束の度合い：「必ず」「すぐに」「翌日には」といった、運用で守り切れない表現が混ざっていないか。配送日数のように自社で制御できないものは、断定を避けた書き方に直す
- 解決しない場合の導線：最後に、問い合わせ窓口への行き先と、そのとき伝えてほしい情報（注文番号など）が書かれているか
3点目を軽視すると、FAQを読んだうえで問い合わせてくる顧客が、注文番号を書かずに送ってくる。CSは確認の返信を1往復増やすことになる。件数は減っていても、対応時間が減らない状態はここで生まれる。
ステップ7：公開して、翌月の棚卸し予定を先に入れる
公開時に決めておくのは、カテゴリの並び順と検索窓の有無、そして「この記事は役に立ちましたか」の設置有無。並び順は件数の多い順にする。五十音順やカテゴリの体裁を優先すると、いちばん来る質問が下に沈む。
そして公開した日に、翌月の棚卸しの予定をカレンダーに入れる。入れなければ、ここで手順は終わる。終わったFAQがどうなるかは、記事の後半で書く。
なぜログ起点だと件数が動くのか
手順を並べただけでは、なぜ順番が重要なのかが伝わりにくい。理由は3つに分解できる。
件数の分布が、優先順位を決めてくれるから
分類して並べ替えると、問い合わせは上位に偏る。上位いくつかの小分類が全体の相当部分を占め、下位には1件ずつの質問が長く尾を引く。この形が見えると、80問を作る意味がないことが分かる。上位から順に潰したほうが、同じ工数で件数に効く。逆に想定問答は、この分布を持たないまま作られるので、全部を同じ重みで並べてしまう。
顧客の言葉が、そのまま検索語になるから
ログには顧客が書いた表現が残っている。「まだ届かない」「間違えて注文した」「サイズが合わなかった」。これをそのまま質問文にすると、FAQ内の検索窓でヒットする。ここは社内で言い換えないほうがいい。整えるほど当たらなくなるという、文章の仕事とは逆向きの性質がここにはある。
「注文に紐づくか」で切ると、FAQの守備範囲が確定するから
ステップ1で入れた注文に紐づくかの列が、ここで効く。「いいえ」の側は、FAQで吸収できる可能性がある。「はい」の側は、どれだけ丁寧なFAQを書いても顧客は問い合わせてくる。自分の注文がどうなっているかは、ページを読んでも分からないからだ。
この線を最初に引いておくと、効果の見積もりが現実的になる。全問い合わせの何割が「いいえ」なのかが分かっていれば、FAQで狙える上限もそこまでだと社内で説明できる。上限を共有しないまま着手すると、半年後に「思ったより減らなかった」という評価だけが残る。
効果測定は「PVが伸びた」で判定しない
ここで最初の場面に戻る。GA4を開いてFAQページのセッション数を見た担当者は、なぜ説明に詰まったのか。見ていた数字が、減らしたいものと別だったからだ。閲覧されたかどうかは、問い合わせが起きなかったことの証明にならない。むしろ、読んだうえで問い合わせている顧客が増えているとき、PVは伸びる。
FAQ運用の解説で共通して挙がる指標は、おおむね4つに整理できる。
- 閲覧数（PV・セッション）：FAQに人が到達しているか。到達がゼロなら他の指標を見る意味がない、という前提確認の指標
- 自己解決率：FAQを見た人のうち、問い合わせに至らなかった割合。「役に立ちましたか」の回答や、FAQ閲覧後にフォームへ遷移した比率で近似する
- 0件ヒット率：FAQ内の検索窓で、結果が0件だった検索の割合。載せていない質問が何かを教えてくれる、いちばん更新に直結する指標
- 問い合わせ件数（カテゴリ別・前後比較）：本来の目的。ここだけが「減ったか」に答える
件数の前後比較には、そろえるべき条件が3つある。ひとつ目は期間の長さと営業日数。ふたつ目はセールの有無で、お買い物マラソンやスーパーSALEを挟んだ月は注文数が動くので、そのまま比べられない。3つ目が分母で、件数そのものではなく「注文100件あたりの問い合わせ件数」に直すと、売上の増減に引きずられなくなる。
そして、比べるのは全体件数ではなくカテゴリ別にする。FAQに載せたのは特定の小分類だけなので、効いたかどうかもその小分類でしか判定できない。全体で見ると、配送遅延のような外部要因の増減に埋もれる。
ここで、ツールベンダーが公開している削減率の掲示にも触れておく。一例として、Helpfeelは自社サイトで問い合わせ削減実績70%と掲示している（2026年8月時点）。ただしこうした数字はベンダー側の自己申告値で、何を「問い合わせ」と数えたのか、比較した期間はいつといつなのか、算出条件が開示されていないケースが多い。うまくいった導入先だけが事例として公開されるという偏りもある。社内で目標値を置くときの参考にはなるが、自社で再現できる数字として引用するのは避けたい。数字を出す必要があるなら、自社のカテゴリ別・分母つきの前後比較を作ったほうが早いし、説明もできる。
正直な前提：FAQでは減らない問い合わせと、構造化データの現在地
ここまでの手順を全部やっても、減らないものがある。先に開示しておく。
ひとつは、個別事情が絡むものだ。注文した商品が届かない、届いたが破損していた、決済が二重に走っているように見える。これらは注文番号を見て、出荷指示と伝票番号を追わないと答えが出ない。FAQに書けるのは「確認しますので注文番号を添えてご連絡ください」までで、問い合わせは発生する。
もうひとつは、交渉が目的のものだ。返品期限を過ぎた返品、規約上は対象外のケース、料金の減額要求。答えはFAQに書いてある。書いてあるのを読んだうえで、例外として認めてほしくて連絡してくる。ここでFAQを厚くしても件数は動かない。動くのは、対応の判断を誰がどこまでできるか、という運用の側だ。
3つ目に、SEO目的の期待も外しておく。FAQPage構造化データを実装すれば検索結果で目立つ、という前提は、いまはもう成り立たない。Googleは2023年8月にFAQリッチリザルトの表示対象を政府・医療系サイト等に限定し、2026年5月7日をもって表示自体を終了した（Google検索セントラル／2026年8月確認）。SEO目的での実装理由は現時点で無い。この領域は仕様変更が続いてきた経緯があるので、実装を判断する前にGoogle検索セントラルの現行ドキュメントを直接確認したい。AI検索での引用についても、Q&A形式が読み取られやすいとする解説はあるものの、構造化データ単独の効果を示す一次データは確認できなかった。
この3つを開示したうえで、結論は変わらない。問い合わせ件数を動かすのはログの分類であって、文章の質でも、構造化データでもない。そして減らせる部分と減らせない部分を先に切り分けておくことが、この施策を社内で続けられるかどうかを決める。
止まるのは更新のところだ。月次の棚卸しを誰が回すか
この施策が失敗する場所は、ほぼ1か所に集中している。公開の翌々月だ。
初月は動く。分類も、下書きも、レビューも、着手した本人が覚えている。翌月も何とか回る。3か月目にセールが入り、出荷が滞り、CSの一次対応で手一杯になる。棚卸しの予定は後ろにずれる。ずれた予定は、そのまま消える。半年後、担当者が久しぶりにFAQの管理画面を開くと、最終更新日が半年前で止まっている。
この間もログは溜まり続けている。新しく始めた定期便の質問、変更した送料無料ラインの質問、追加した決済手段の質問。どれもFAQには載っていない。載っていないから顧客は問い合わせる。そして「FAQを作ったのに減らない」という評価だけが、次の期の会議に残る。
止めないための仕掛けは、大がかりである必要はない。月次でやることは3つに絞れる。先月の問い合わせを既存の大分類に振り分ける。0件ヒット率の検索語を上から10件見る。新しく上位に来た小分類を1つだけFAQに足す。1問追加するだけでいい。毎月1問足すことと、半年に1回30問を作り直すことでは、前者のほうが件数に効くし、続く。
そして、この月次作業を「誰の仕事か」として明文化する。担当者名ではなく役割として書き、引き継ぎ資料に入れておく。属人化して止まるのは、本人のやる気の問題ではなく、業務として登録されていないからだ。登録されていない作業は、忙しくなった瞬間に真っ先に消える。
ここには、もう少し先の話も混ざっている。FAQを作って終わりにできる担当者と、ログを見て次の更新点を拾い続けられる担当者では、同じ「問い合わせ対応」という仕事でも、社内での説明のされ方が変わってくる。前者は「FAQを作った人」で、後者は「問い合わせが何で構成されているかを説明できる人」だ。この差が社外の市場でどう扱われるのかという論点は、この記事の範囲を超えるので別に分けてある。EC担当者の市場価値は、何で決まっているのかを、経験の棚卸しの話として読んでもらえればいい。
今日からできることを1つだけ挙げるなら、先月の問い合わせを50件だけ書き出して、分類の列を手で埋めてみることだ。50件でも分布は見える。そして、その上位3件が今のFAQに載っているかを確かめる。載っていなければ、増やすべきは文章量ではない。
よくある質問
問い合わせログが1か所にまとまっていない場合、何から手をつけるか
全窓口をそろえるより先に、いちばん件数の多い窓口1つだけで回してみるほうが早い。自社サイトのフォームでもR-Messeでもいい。分類してみると、上位に来る内容は窓口が違ってもある程度共通していることが多い。全チャネルの統合は、効果が確認できてから着手しても遅くない。
FAQは何問くらい用意すればよいか
問数を目標にしないほうがいい。判断基準は、分類したときの上位から順に何割まで潰せているか、である。上位10件で件数の大半を占めるなら、まずその10問を精度高く書くほうが、80問並べるより効く。問数が増えるほど探す手間も増えるという副作用もある。
チャットボットを入れればFAQは不要になるか
置き換えの関係ではない。チャットボットが回答として返すのは、多くの場合FAQとして整備した内容そのものである。元になる質問と回答が「想定問答」のままなら、ボットに載せ替えても当たらない。ログの分類はどちらの形式でも先に必要になる。
AIが作った回答をそのまま公開してはいけないのか
数字と条件を含む文は、確認の工程を通したほうがいい。返品期限、送料、営業日の数え方、キャンセル可能なタイミング。これらは自社の規約側が正本で、生成された文章はその写しにすぎない。文章表現の部分と、規約に紐づく数値の部分を分けて、後者だけ人が突き合わせる形にすると工数が抑えられる。
効果が出るまでどのくらいかかるか
一律の期間は出せない。判断材料になるのは、比較する期間の営業日数がそろっているか、セールを挟んでいないか、注文件数あたりに直しているか、の3点である。少なくとも1か月ぶんの前後比較が必要で、季節性の強い商材ならもう1周ぶん見たほうがいい。単月の増減だけで打ち切らないほうがいい領域である。
FAQを更新した記録は残しておくべきか
残しておいたほうがいい。いつ、どの質問を追加し、その月の該当カテゴリの件数がどう動いたか。この記録があると、次の期の予算や工数の相談で使える材料になる。無ければ「感覚では減った気がする」という報告しかできず、施策そのものが続かなくなる。
コメント