BtoB ECの検索サジェスト改善｜6つの設計手順

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

B2B EC-COLUMN

検索サジェストの改善は「候補の元データ」と「運用サイクル」で決まる

BtoB ECの検索サジェスト改善とは、取引先が検索窓に入力し始めた時点で目的の商品へ到達できるよう、候補として出す元データと操作性を設計し、検索ログで月次に育てていく取り組みです。

ここで最初に区別しておきたいのは、サジェスト＝入力途中に出す候補の設計と、型番そのものを正しく照合する精度設計は別の工程だという点です。商品マスタの識別子の持ち方や正規化ルール、N-gramと形態素解析の使い分けは、商品検索の型番対応を扱う別記事で扱う前段の話であり、本記事では扱いません。

サジェストを付けても取引先の「探せない」という声が減らない場合、この3層のどこが欠けているかで原因が分かれます。第一に、何が検索され何が0件になっているかを測っていません。第二に、候補として出す元データが用意できていません。第三に、候補を選ぶ操作がマウス前提になっていて、キーボードだけで発注する担当者が使えません。

本記事は、この3つの原因を順番に解く6つの手順で構成します。手順1で現状を測り、手順2で候補の元データを決め、手順3で作り方を選び、手順4で表記ゆれと0件に備え、手順5でUIの操作性を整え、手順6で検索ログを月次サイクルに乗せます。

手順1：GA4のview_search_resultsでいま何が検索され何が0件かを測る

サイト内検索はGA4のview_search_resultsイベントで取得できる

Google アナリティクス4（GA4。Googleが提供するアクセス解析の現行バージョン）の拡張計測機能では、サイト内検索の利用はview_search_resultsというイベントとして自動的に取得できます^*2。候補データを作る前に、まずこの計測が動いているかを確認することが出発点になります。

既定の検出パラメータはq・s・search・query・keywordの5種

このイベントは、URLのクエリパラメータにq・s・search・query・keywordのいずれかが含まれていることを既定の検出条件としています^*2。検索語そのものはsearch_termというパラメータで収集され、同一セッション内で値が1件だけのときに限りunique_search_termも送られます^*2。まず確認すべきなのは、自社サイトの検索窓のURLがこの5種のいずれかに当たるかどうかです。

最初に見る4つの数字は検索利用率・0件率・検索後離脱率・検索経由受注比率

計測が動いていることを確認したら、次に見るべき数字は4つです。検索窓を使った人の割合、検索した結果が0件になった割合、検索後にそのまま離脱した割合、検索を経由して受注に至った割合です。この4つを継続して見る仕組みがないまま候補を増やしても、改善したかどうかを判定できません。KPI設計全体は、効果測定の指標を扱う別記事で整理しています。

何が検索され何が0件かを知らないまま候補を用意すると、取引先が実際に打つ語と候補がずれたまま運用が固定化するおそれがあります。無料相談で要件を整理すると、自社の検索ログをどう見ればよいかを一緒に確認できます。

手順2：サジェストに出す候補はキーワード・商品・カテゴリ・発注履歴の4種から選ぶ

候補はキーワード・商品・カテゴリ・発注履歴の4種類に分かれる

サジェストの候補として出せるものは、大きく4種類に分かれます。入力途中の語を補うキーワード候補、商品そのものを直接出す候補、絞り込みに使うカテゴリ候補、そして取引先ごとの過去の発注履歴です。取引先の担当者は、初めて商品を探すのではなく過去に発注した品を思い出しながら入力する場面が多く、実務に合うのは、型番や通称の断片から候補が出る設計です。

BtoBは取引先ごとに出し分けが必要になる

BtoCのサイトと違い、BtoB ECでは取引先ごとに取り扱う商品や社内での呼び名、価格が異なります。全取引先に同じ候補を出すと、実際には買えない商品や見えるべきでない価格が候補に混ざる可能性があります。価格を候補に含める場合の前提は取引先別の価格設定を扱う別記事、発注履歴からの再注文導線は発注履歴と定番品登録を扱う別記事でそれぞれ整理しています。

サムネイル表示にはマスタ側の整備が前提になる

候補にサムネイルを出すかどうかも、この段階で決めておく項目です。候補の品質はもともと商品マスタの品名・カテゴリの整い方に依存するため、商品マスタの整備を扱う別記事の内容が前提になります。画像を出す場合は、商品画像の整備・運用を扱う別記事の状況も条件になります。

手順3：候補の作り方はElasticsearchのsuggesterから選ぶ

suggesterはterm・phrase・completion・contextの4種、completionがsearch-as-you-typeを担う

候補をシステム的にどう生成するかは、Elasticsearch（オープンソースの検索エンジン。全文検索を高速に行う基盤ソフトウェア）の公式リファレンスで4種類のsuggester（候補生成の仕組み）として定義されています^*4。termは語の編集距離に基づく候補、phraseはフレーズ全体の補正、completionは入力に応じたauto-complete（自動補完）とsearch-as-you-type（打鍵ごとの候補表示）を担い、contextはカテゴリや地理情報で候補を絞り込みます^*4。サジェストの実装で主に使うのはcompletionです。

search_as_you_typeフィールドは._2gram・._3gram・._index_prefixを自動生成する

Elasticsearchのsearch_as_you_typeというフィールド型を使うと、入力の断片から一致を取るためのサブフィールドが自動的に作られます。具体的には2語のまとまりを扱う._2gram、3語のまとまりを扱う._3gram、先頭からの部分一致を扱う._index_prefixの3つです^*5。生成する語のまとまりの上限はmax_shingle_sizeという設定で決まり、既定値は3、指定できる範囲は2から4です^*5。値を大きくすると連続した語句の一致は向上しますが、インデックスの容量も増えます。

context suggesterはカテゴリと地理情報で候補を絞り込める

取引先ごとの出し分けを実装に落とす足がかりになるのがcontext suggesterです。categoryとgeoという2種類のコンテキストで、候補の絞り込みや優先度づけができます^*4。取扱商品が取引先ごとに違うという手順2の課題は、この仕組みで実装に反映可能です。

サジェストは入力するたびにサーバーへ通信する仕組みのため、応答速度が要件として求められます。応答速度の考え方は表示速度の改善手順を扱う別記事で整理しています。

手順4：同義語辞書とlenient設定で表記ゆれと0件に備える

同義語はSolr形式の辞書として運用で育てるもの

表記ゆれへの対応は「AI辞書」という一語で説明されがちですが、実体はElasticsearchのsynonymトークンフィルタという仕組みです^*6。同義語をひとまとまりとして扱うexpandというパラメータは既定でtrueになっており、Solr形式で「ipod, i-pod, i pod」のように等価な語を並べるか、「personal computer => pc」のように一方向の言い換えを明示できます^*6。型番の旧番号や社内での通称も、この辞書に足していくことで候補に反映されます。

lenientは不正なルールだけを無視して有効なルールを通す仕組み

lenientというパラメータをtrueにすると、辞書の中に書式の誤ったルールが混ざっていても、そのルールだけを無視して残りの有効なルールは適用されます^*6。辞書ファイルの場所はsynonyms_pathで指定し、設定ディレクトリからの相対パスで管理します^*6。つまり同義語辞書は一度作って終わりではなく、運用の中で追記していく前提の仕組みです。

0件を出さない設計は絞り込みへ逃がすことと代替候補の提示

候補が尽きて0件になりそうな場面では、候補をゼロにせず、カテゴリ絞り込みや人気商品への切り替えを提示する設計が求められます。型番そのものの正規化ルールや辞書の中身の設計は、商品検索の型番対応を扱う別記事の領域であり、本記事ではこれ以上踏み込みません。

手順5：W3CのComboboxパターンでキーボードだけで選べるUIにする

入力補完付き検索窓はW3C ARIA APGのComboboxパターンそのもの

候補の元データと作り方が決まっても、選べなければ意味がありません。入力補完付きの検索窓は、World Wide Web Consortium（W3C。Webの技術標準を策定する国際標準化団体）が公開するARIA Authoring Practices Guide（APG。アクセシブルなUI部品の実装指針）の中で、Comboboxパターンとして定義されています^*3。これは入力欄と、候補を表示するポップアップの組み合わせを指します^*3。

role=”combobox”とaria属性で読み上げと状態を伝える

この仕様が定めるロールと属性を翻訳すると、次のようになります。role="combobox"は「これは候補を選べる入力欄だ」と伝える役割、aria-expandedは候補が開いているか閉じているかを示す状態、aria-controlsは入力欄と候補一覧のポップアップを結びつける役割、aria-activedescendantは候補の中で今どれにフォーカスが当たっているかを伝える役割です^*3。aria-autocompleteはnone・list・bothのいずれかを指定し、入力に応じて候補を出すか、候補に沿ってインライン補完まで行うかを切り分けます^*3。

下矢印・Escape・Enter・Alt+下矢印のキーボード操作要件

キーボード操作の要件も定義されています。下矢印キーで候補一覧を開いてフォーカスを移し、Escapeキーで候補を閉じ、Enterキーで候補を確定します^*3。Alt+下矢印はフォーカスを移さずに候補だけを表示するオプションの操作です^*3。マウスに手を移さず伝票を片手に持ったまま入力する現場では、この操作性が実務上の要件になります。スマホでの入力については現場でのスマートフォン利用を扱う別記事で整理しています。

手順6：検索ログを月次サイクルで回し候補と辞書を育てる

0件語の抽出から効果測定までの月次ループ

手順1から5で仕組みを整えたら、最後に運用サイクルへ乗せます。検索ログから0件だった語を抽出し、同義語辞書へ反映し、候補の並びを見直し、効果を測定してまた検索ログに戻るという流れです。

辞書を更新する責任者を決めないと運用は止まる

同義語辞書は自動で育つものではありません。誰が0件語を確認し、誰が辞書へ反映し、いつのタイミングで反映するかを決めておかなければ、辞書はすぐに更新されなくなります。担当者と反映のタイミングを最初に決めておくことが、サイクルを継続させる条件になります。

サジェスト改善は稼働後の改善サイクルに組み込んで継続させる

このサイクルは単独の取り組みではなく、稼働後の改善サイクル全体の一部として位置づけられます。改善サイクルの全体設計は導入後の改善サイクルを扱う別記事で整理しています。また、探しても見つからずに問い合わせが来る場合の受け皿としてはFAQ設計による問い合わせ削減を扱う別記事もあわせて検討するとよいでしょう。

UI・UXのデザイン・スキルを実施している日本企業は20.8%にとどまる

デザイン・スキルを実施している日本企業は20.8%、米国企業は約55〜70%

総務省『令和7年版情報通信白書』の図表Ⅱ-1-11-21「領域別デジタル人材の実装状況」によると、UI・UXに関わるデザイン・スキルについて「実施している」と回答した日本企業は20.8%でした^*1。同じ図表で、米国企業の同項目は約55%から70%とされています^*1。これは企業が持つデジタル人材のスキル領域を尋ねた設問であり、UI/UX改善の施策実施率そのものではありません。同白書には母集団やサンプル数の記載がないため、比率としての傾向を示す数値として扱います。

実装が遅れている理由の1位は人材不足48.7%、片手間で回せる運用設計が要件になる

同白書の図表Ⅱ-1-11-20「デジタル化に関して認識していることが、実装が遅れている理由としての認識度（企業）」では、日本企業が最も多く挙げた理由は「人材不足」で、その割合は48.7%でした^*1。この数値は、サジェスト改善を含むUI/UX設計が後回しになりやすい状況を示すものと言えます。だからこそ本記事は、一度大掛かりに作り込む設計ではなく、測る・直すの1周を小さくして片手間でも回せる運用に落とすことが本記事の軸です。

内製に必要な知識と工数、外部パートナーとの違い

手順1から6を内製で実行するには、GA4での計測設定、Elasticsearchのsuggester設定、W3C準拠のUI実装、同義語辞書の運用という、担当領域の異なる知識が同時に必要です。これらを1人の担当者が兼務すると、辞書の更新が後回しになり、候補の質がそのまま下がっていくおそれがあります。取引先ごとの出し分けをどこまでやるか、辞書を誰が更新するかは、貴社の商習慣に応じて判断が変わる項目です。この部分だけを外部パートナーと一緒に決めるという進め方もあります。

測らない・データ不足・マウス依存・辞書放置・型番混同の5つの落とし穴

測る・出す・育てるの3つの判断軸でサジェスト改善を進める

本稿では、BtoB ECの検索サジェスト改善を6つの手順として整理しました。要点を3つに集約すると、第一に、GA4の公式仕様で何が検索され何が0件かを測ること^*2です。第二に、候補の元データと作り方をElasticsearchの仕様に沿って決めること^{*4, *5, *6}です。第三に、W3CのComboboxパターンで操作性を整え^*3、検索ログを月次サイクルで育て続けることです。取引先ごとの出し分けと辞書の運用体制は、貴社の商習慣に当てはめて判断する項目として残ります。

---

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

本記事で扱った検索サジェストの前提となる、BtoB EC導入全体の進め方は、導入の進め方を扱う別記事で解説しています。

よくある質問

サジェストは候補を何件くらい出すのが妥当ですか。

件数を一律の数値で決めるのではなく、画面のスクロールなしで見える範囲に収まる件数を起点にし、検索ログで0件率や選択率を見ながら調整する進め方が妥当です。候補が多すぎると選ぶ操作自体が負担になるため、まず現状の0件率をGA4のサイト内検索イベントで測ることから始めます^*2。

サジェストにサムネイルや価格を出したほうがよいですか。

サムネイルを出す場合は商品マスタの品名・カテゴリと画像の整備が前提になります。価格を出す場合は取引先ごとに価格が異なる可能性があるため、取引先別の価格設定を扱う別記事の出し分け設計を先に確認する必要があります。

検索されている語や0件だった語は、どうやって把握できますか。

GA4の拡張計測機能を使うと、サイト内検索の利用はview_search_resultsイベントとして自動的に取得できます^*2。検索語はsearch_termパラメータで収集されるため、この値を集計すれば0件だった語を洗い出せます。

取引先ごとに違う商品や呼び名にも対応できますか。

対応できます。Elasticsearchのcontext suggesterはcategoryとgeoという2種類のコンテキストで候補を絞り込める仕組みを持っています^*4。呼び名の違いはsynonymフィルタの同義語辞書に反映することで対応します^*6。

サジェストを入れれば型番で検索できない問題も解決しますか。

解決しません。型番で検索できない原因は、入力補完の有無ではなく型番の照合方式（正規化ルールやN-gramの設計）にあります。この領域は商品検索の型番対応を扱う別記事で整理しています。

1. *1　出典：総務省「令和7年版情報通信白書（図表Ⅱ-1-11-20・Ⅱ-1-11-21）」（令和7年版）
2. *2　出典：Google「アナリティクス ヘルプ 拡張計測機能」（現行版）
3. *3　出典：World Wide Web Consortium「ARIA Authoring Practices Guide Combobox Pattern」（現行版）
4. *4　出典：Elastic「Elasticsearch Guide Suggesters」（現行リファレンス）
5. *5　出典：Elastic「Elasticsearch Guide search_as_you_type」（現行リファレンス）
6. *6　出典：Elastic「Elasticsearch Guide synonym token filter」（現行リファレンス）