BtoB ECの問い合わせ削減｜FAQ設計の5手順

◆監修・編集責任者　小園 将隆　2026年8月18日

B2B EC-COLUMN

問い合わせ削減とは自分で到達できる状態をつくる設計

BtoB ECの問い合わせ削減とは、問い合わせ窓口を閉じることではありません。取引先が知りたいこと――納期・在庫・自社の価格・過去の注文・使い方――に、画面とFAQだけで自分でたどり着ける状態をつくる設計です。

結論―問い合わせは注文が不明瞭であることの結果

中小企業庁委託の報告書は、表12「鉄鋼業界における主な課題」で、電話・FAX受注の事象について次のように記しています^*2。「書き間違いや聞き間違い等による誤発注及び不明瞭な注文内容の再確認が都度発生し、コストがかかっている」。つまり問い合わせの多くは、注文そのものが不明瞭であることの結果です。

1件あたりのコストは十数分単位で発生する

問い合わせが来る理由は「よくある質問だから」ではなく、注文の設計に不備があるからです。同報告書の表12には、鉄鋼業界の事象として「多岐にわたる需要家から月に数百から数千件の電話・FAXでの注文を受けている」との記述があります^*2。量そのものが多いことも背景にあり、ここで直視すべきは1件あたりのコストです。

鉄鋼業界のヒアリングまとめには「問合せがあると、ミルシートを探す手間は1件15-20分程度必要。」という記述があります^*2。ミルシート（鋼材検査証明書、鋼材の成分・強度などを保証する書類）の照会に限った射程の数値です。

書類を探す手間そのものが1件あたり十数分単位で発生することを、公的資料から確認できる例といえます。

別の調査では、注文への回答（注文回答）プロセスの工数が6分30秒から1分50秒へ、率にして72%削減されたことが報告されています^*3。プロセス全体（注文から支払通知までの6プロセス）の工数計も38分30秒から9分06秒へ、76%削減されました^*3。いずれも流通（VC）業界を対象とした実証の値で、現状値はヒアリング、実証値はログデータにもとづく比較です^*3。いずれも注文回答というプロセスそのものの工数であり、「問い合わせ対応の工数が72%減る」という意味には読み替えられません。

電子受発注の対応率は受注側で48.5%

電子受発注への対応も進んでいます。2021年時点で、受注側の48.5%が電子受発注に対応しています^*1。デジタル化のメリットとして「作業効率向上」「人的ミスの軽減」「取引記録の検索性の向上」が挙げられています^*1。

裏を返せば、電子化が済んでいないままの受注は、こうしたコストを抱えたままになりやすいということです。

受発注のデジタル化そのものをどこから進めるかは、BtoB EC導入の進め方 で全体像を整理しています。

本記事で扱う手順を、着手すべき順に5点でまとめます。

手順1 問い合わせを棚卸しして型に分ける

1か月ぶんの問い合わせを6つの型に振り分ける

手順1は、いま来ている問い合わせを型に分けることです。電話・FAX受注 が主なチャネルであるほど、この棚卸しをせずに「よくある質問」を並べる進め方になりがちです。まず1か月ぶんの問い合わせ記録を、次の型に振り分けます。

型①は納期・出荷の問い合わせです。同報告書には「納期について、発注したものは予定通りの納期が対応できない場合がある(欠品)。納期回答が来ないと発注が成立しない。」との記述があり^*2、「人力で確認を取らないとわからないため、納期確認の円滑化されることが理想である。」と続きます^*2。

納期回答の速さには差があるとの指摘もあります^*2。「メーカー家電業界では在庫管理などをシステム化できているため、すぐに回答をもらえるが、ベンチャーや特化型メーカーの場合は、納期回答が遅い。」

型②は在庫の問い合わせです。ある事業者の回答として「受注について、現在は、電話かFAXでの注文がほとんどで、リアルタイムでの対応は在庫問合せ回答程度。」との記述があります^*2。在庫の有無だけは即答できていても、それ以外は電話中心のままという実態がうかがえます。

型③は価格・取引条件の問い合わせです。「うちの掛率だといくらか」「今回の数量だと単価はどうなるか」という取引先ごとの照会で、答えは取引先によって異なります。見積の進捗確認 もこの型に近い性質を持ちます。

型④は商品の特定に関わる問い合わせです。型番・入数・後継品が分からず電話になるケースで、原因の多くは商品マスタ側にあります。マスタの整備そのものは別テーマのため、本記事では画面での見せ方に限って扱います。

型⑤は過去の取引の照会、型⑥は使い方が分からないという問い合わせです。後者は軽視されがちですが、同報告書の表21「デジタル化に必要な支援」の第1項目は、実業務にあたる従業員が分からないことに直面したときの問合せ先を設置することです^*2。

理由は次のように記されています^*2。「受発注システムの利用時に不明点があった際に問合せ先がないと継続して利用してもらえず、これまでのやり方に戻ってしまう。」

標準EDI（Electronic Data Interchange、電子データ交換の国際規格）の非利用理由を問うアンケートもあります^*2。選択肢の一つに「標準EDIの使い方がわからない」が置かれており、使い方の分からなさは設問として想定されるほど一般的な論点だといえます。

件数の多い型から手当てする

棚卸しに専用ツールは要りません。1か月ぶんの問い合わせを、電話・メールの記録から上の6つの型に振り分けるだけで十分です。件数の多い型から手当てすれば、労力に対する効果が大きくなります。

ここまでで難しいのは、型ごとに「答える場所」を正しく割り当てることです。全取引先で共通しない答え（納期・在庫・自社の価格）を一般的なFAQに書いても、1件も減りません。この見極めを誤ると、次に述べる手順2・3の設計そのものが崩れます。

可視化した棚卸しの結果を自社の商流に照らして確かめるには、無料相談で要件を整理するのが近道です。

手順2 FAQに書かず、画面で答える

手順2は、FAQに書いても減らない問い合わせを、画面側の設計で吸収することです。「うちの納期は」「うちの在庫は」「うちの価格はいくらか」は、取引先ごとに答えが違うため、FAQのような一般解では答えられません。これは本記事の中核となる区別です。

注文回答を漏れなく返す

実務上重要なのは注文回答を漏れなく返すことです。中小企業庁委託の実証調査事業報告書は、取引プロセスの一つとして取引プロセスの一つである「注文回答」を、受注事業者から発注事業者に対して注文への回答を返す業務と定義しています。VC（Voluntary Chain、任意連鎖店）業界では、注文を受けたVC本部が問屋へ問い合わせる必要があるとも記されています^*3。つまり注文回答が遅れると、その先に問い合わせが発生しやすくなります。

同調査では、この注文回答プロセスの工数が流通（VC）業界の実証で6分30秒から1分50秒へ、72%削減されたと報告されています^*3。基幹システムとの連携 によって注文確定や納入日を通知する仕組みは、産業データ連携基盤の基本機能の候補としても挙げられています^*2。

在庫・納期・価格は注文前の画面に出す

在庫・納期・価格は、注文前の画面に表示することで問い合わせそのものを未然に減らせます。在庫連携の方式、取引先別価格の実現方式、数量割引の設定方法 は、それぞれ専門の設計が必要な領域のため詳細は別記事に譲りますが、狙いは共通しています。取引先が問い合わせる前に、画面で答えを見せることです。

過去の注文は取引先が自分で引ける状態にする

過去の注文を取引先が自分で引ける状態にすることも欠かせません。国税庁の電子帳簿保存法一問一答（問48）は、電子取引データを保存する事業者に対して、検索機能の確保として次の3要件を求めています^*7。これは保存義務者である自社に課される要件であり、取引先向け画面の法令要件ではありませんが、同じ検索軸を画面に用意しておけば、照会への個別対応そのものを減らせます。

なお同問一答では、税務職員のダウンロードの求めに応じられるようにしている場合は(2)(3)の要件が不要となるなどの緩和も示されています^*7。自社に必要な水準は税理士等に確認してください。

商品が探せないことも電話の原因になります。型番・入数・後継品を検索しやすくする 商品マスタの整備 は、別の専門テーマとして扱われるべき範囲が広く、本記事では画面の見せ方の要点にとどめます。

手順3 FAQで答える ― 何を、何問、どう書くか

FAQに向くのは答えが全取引先で同じものだけ

FAQに向くのは「答えが全取引先で同じもの」だけです。送料の計算方法、締め時間、支払方法、返品の可否、登録手続き、障害時の連絡先は、取引先によって答えが変わらないため、FAQの一般解で答えられます。

問いは取引先の言葉で立てる

問いは1問1答で、結論から書きます。ここで重要なのは、問いを取引先の言葉で立てることです。社内で使う用語のまま問いを立てると、取引先はその言葉で検索しません。

「与信枠の変更手続きは」ではなく「支払サイトを変更したい」のように、相手側の表現に合わせます。

問数は、棚卸しの上位で全体の大半を占めるものから優先します。網羅を目指す必要はありません。数を増やすほど、後述する更新の手間が増え、結果として更新が止まりやすくなります。

例外と個別条件は書かない

FAQに書いてはいけないこともあります。社内の運用ルール・例外処理・個別取引先の条件は、FAQという公開の性質になじみません。ここでは「例外は書かない」という設計原則にとどめ、個々の例外処理の中身には立ち入りません。

関連する前提として、ログイン・認証まわりの設計は BtoB ECのセキュリティ対策、請求書の登録番号に関する問い合わせは インボイス制度対応 で扱っています。

ログイン前とログイン後で置き場所を分ける

もう一つの分け方が、ログイン前とログイン後です。誰でも見てよい情報（送料・締め時間・登録手続き）はログイン前のFAQに置き、取引先ごとに変わる情報は画面側のログイン後の領域で扱います。この線引きが曖昧だと、公開FAQに書けない情報まで一般公開のページに書いてしまうリスクが生じます。

手順4 たどり着ける導線にする

困る場所に1問を置く

手順4は、作ったFAQに実際にたどり着けるようにすることです。困る場所にFAQを置くことが重要で、一覧のFAQページよりも、注文画面・商品ページ・注文完了メールの中に置かれた1問のほうが効きます。取引先は困った瞬間にその場で答えを探すため、離れた場所にある一覧ページまでは移動しないことが多いためです。

検索できるようにすることも欠かせません。取引先の言葉での検索に対応し、同じ意味の異なる言い回し（例えば「支払サイト」と「締め払い」）を吸収できるようにします。

FAQのリッチリザルトは2026年5月7日で終了した

ここで正確に整理しておくべきことがあります。「FAQを作れば検索結果に出る」という前提は、もはや成り立ちません。Google検索セントラルの変更履歴には、2026年5月8日付で「よくある質問のリッチリザルト機能をサポート終了しました」との記載があります^*4。理由として「この機能は、2026年5月7日をもってGoogle検索に表示されなくなるためです。」と明記されています^*4。

さらに2026年6月15日には「よくある質問のリッチリザルト機能に関するドキュメントを削除しました」との記載が追加されました^*4。理由は「2026年5月の変更履歴のエントリで発表されたとおり、よくある質問のリッチリザルト機能はGoogle検索の検索結果に表示されなくなったためです。」とされています^*4。今後の扱いについて公式に予測できる材料はなく、本記事もこの変更履歴に記載された事実の提示にとどめます。

FAQPageという型自体は語彙として存続している

一方で、FAQPageという型自体は語彙として存続しています。schema.org(構造化データの語彙を定める標準。W3C(World Wide Web Consortium)コミュニティに由来する)に、その定義が掲載されています^*5。定義は「A FAQPage is a WebPage presenting one or more ‘Frequently asked questions’」です^*5。

階層はThing > CreativeWork > WebPage > FAQPageとされています^*5。つまり構造化データを付けること自体が無意味になったわけではありません。成り立たなくなったのは「検索結果のリッチリザルトを狙う目的」だけです。

そもそもBtoB ECのFAQの多くは会員向けであり、検索結果に出ないことも珍しくありません。ログイン後にしか見えないFAQは、検索エンジンにインデックスされる前提を持たないためです。

この2つの事情を踏まえると、FAQの目的は集客ではなく、取引先の自己解決に置き直す必要があります。この目的の置き直しは、現時点のSERP(検索結果ページ)でBtoB EC系の記事があまり触れていない論点です。

手順5 更新と、残す受け口を決める

問い合わせ先は残す

手順5は、FAQを作った後の運用を決めることです。まず前提として、問い合わせ先は残さなければなりません。表21「デジタル化に必要な支援」の項目とその理由として、「問合せ先がないと継続して利用してもらえず、これまでのやり方に戻ってしまう。」と記されています^*2。

問い合わせを減らすことと、受け口を潰すことは別問題です。受け口を潰すと、取引先はECの利用そのものをやめ、電話・FAXへ戻ってしまいます。

更新の担当と周期を決める

更新の担当と周期も決めておく必要があります。新しい問い合わせが来たら、その都度FAQに1問足すという運用を回せるかどうかが、FAQの実効性を左右するでしょう。担当が曖昧なまま公開すると、FAQは初回公開時点の内容で止まりやすくなります。

FAQだけで足りない層には、別の手当てが必要です。取引先への教え方・マニュアルの作り方 は別テーマとして扱うべき範囲が広く、本記事では踏み込みません。問い合わせ窓口を誰が持つかという体制の設計 も同様です。

なお、ここまで述べてきたのはすべて取引先向けの設計であり、自社の従業員側の定着 とは別の論点です。

チャットボット・生成AIは順序が後になる

チャットボットや生成AIをいつ導入するかという疑問も多く寄せられます。総務省の令和7年版情報通信白書は、日本・米国・ドイツ・英国の4か国の企業を対象とした調査をもとに、生成AIの活用方針について「積極的に活用する方針」「活用する領域を限定して利用する方針」と回答した企業の比率が、日本では2024年度調査で49.7%（2023年度調査は42.7%）だったと報告しています^*6。何らかの業務で生成AIを利用していると回答した割合は、日本で55.2%とされています^*6。

ただしこの55.2%は「何らかの業務での利用」であり、顧客対応・問い合わせ対応に限った利用率ではありません。中小企業では「方針を明確に定めていない」が約半数を占めています^*6。方針の整備自体がこれからという企業も少なくありません。

この実態を踏まえると、チャットボットを先に入れれば解決するわけではないと分かります。答えの元になるFAQと画面の情報が整っていなければ、AIも正しく答えられないからです。

導入の順序としては、まず手順1〜4でFAQと画面を整えます。その後にチャットボット・生成AIの活用を検討するのが妥当です。

減ったかどうかを確かめる、つまずきやすい点

型ごとの件数をひと月ごとに数える

効果を確かめる方法は、詳しい指標設計に立ち入らず最小限にとどめます。型ごとの問い合わせ件数を、棚卸しと同じ区分でひと月ごとに数え、増減を追うだけで十分な手がかりが得られるでしょう。指標の精緻な設計自体は、本記事の範囲を超えます。

つまずきやすい4点

つまずきやすい点は4つあります。第一に、画面で答えるべきものをFAQに書いてしまうことです。取引先ごとに異なる納期・在庫・価格をFAQに載せても、個別の答えにはならず、結局は問い合わせが続きます。

第二に、網羅を目指して100問規模のFAQを作り、更新が止まることです。問数が多いほど、更新担当への負荷が増えます。

第三に、問い合わせ先そのものを消してしまうことです。受け口をなくすと、取引先はECの利用を続けられなくなり、電話・FAXでの旧来のやり方に戻ってしまいます^*2。

第四に、FAQをSEO目的で作ることです。よくある質問のリッチリザルトは2026年5月7日をもって検索結果に表示されなくなっており^*4、集客を主目的にFAQを設計する前提はすでに成り立ちません。

この4点はいずれも、手順1〜5のどこかを飛ばしたときに起こりやすいものです。棚卸しをせずに型を分けない、画面対応を後回しにする、更新体制を決めずに公開する――順序を守ることが、つまずきを避ける最も確実な方法です。

まとめ　BtoB EC問い合わせ削減の5つの判断軸

本記事では、BtoB ECの問い合わせ削減を、窓口を閉じることではなく取引先が自分で到達できる状態をつくる設計として整理しました。要点は5つに集約できます。第一に、問い合わせを型に分けて棚卸しすることです。第二に、取引先ごとに答えが変わるもの(納期・在庫・価格・過去の注文)は画面で答える必要があります。

第三に、全取引先で答えが同じものだけをFAQに書くことです。第四に、困る場所に導線を置き、FAQを検索結果獲得の手段とは位置づけません。第五に、問い合わせ先を残したまま、更新の担当と周期を決めて運用を続けることです。

取引先の商習慣は企業ごとに異なるため、どこまでを画面で吸収できるかは個社の設計によって変わります。

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

よくある質問

FAQページを作れば問い合わせは減りますか。

FAQだけでは、取引先ごとに答えが異なる問い合わせ(納期・在庫・自社の価格)は減りません。中小企業庁委託の報告書が示すとおり、これらは取引先ごとに答えが変わるため^*2、まず画面で答え、全取引先に共通する答えだけをFAQで扱う切り分けが必要です。

FAQは何問くらい用意すればよいですか。

網羅を目指す必要はありません。1か月ぶんの問い合わせを型に振り分け、件数の多いものから優先して問いを立てるのが現実的です。問数を増やしすぎると更新の負荷が増え、結果として更新が止まりやすくなります。

FAQに構造化データを付ければ検索結果に表示されますか。

表示されません。Google検索セントラルの変更履歴によると、よくある質問のリッチリザルトは2026年5月7日をもって検索結果に表示されなくなりました^*4。ただしFAQPageという型自体はschema.orgの語彙として存続しており^*5、構造化データを付けること自体が無意味になったわけではありません。付ける目的を「リッチリザルト獲得」から「可視構造の機械可読化」に置き直す必要があります。

チャットボットや生成AIを導入すれば人手の対応は不要になりますか。

不要にはなりません。総務省の調査では、何らかの業務で生成AIを利用していると回答した割合は日本で55.2%です^*6。ただしこれは顧客対応に限った利用率ではなく、中小企業では活用方針を明確に定めていない企業が約半数を占めます^*6。答えの元になるFAQと画面の情報が整っていなければ生成AIも正しく答えられないため、まずFAQと画面を整える順序が前提になります。

取引先から「前回の注文の控えがほしい」と言われます。どう備えればよいですか。

取引先が自分で過去の注文を検索できる画面を用意することが備えになります。国税庁の電子帳簿保存法一問一答は、電子取引データの検索機能について3要件を挙げています^*7。取引年月日・取引金額・取引先での条件設定、範囲指定、複数条件の組み合わせの3つです^*7。中小企業庁も受発注のデジタル化のメリットとして取引記録の検索性の向上を挙げています^*1。照会への個別対応ではなく、取引先が自分で引ける状態を目指す設計が妥当です。

1. *1　出典：中小企業庁「中小企業の受発注デジタル化」
2. *2　出典：中小企業庁委託（EYストラテジー・アンド・コンサルティング株式会社）「受発注のデジタル化に関する推進方策 報告書」（2022年3月31日）
3. *3　出典：中小企業庁委託（EYストラテジー・アンド・コンサルティング株式会社）「電子受発注システム普及促進に向けた実証調査事業 報告書」（2023年3月31日）
4. *4　出典：Google「Google 検索ドキュメントの最新情報（変更履歴）」
5. *5　出典：Schema.org「FAQPage」
6. *6　出典：総務省「令和7年版 情報通信白書」（2025年7月公表）
7. *7　出典：国税庁「電子帳簿保存法一問一答【電子取引関係】」（令和7年6月）