BtoB ECの商品検索と型番対応｜精度を上げる7つの設計

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

B2B EC-COLUMN

型番検索は「マスタ側」と「検索側」の二層で決まる

BtoB ECの型番検索は、①商品マスタ側で「何を識別子として持つか」を決める層と、②検索エンジン側で「入力された文字列をどう照合するか」を決める層の二層で精度が決まります^*1。

BtoB ECの商品検索における型番対応とは何か

BtoB ECの商品検索における型番対応とは、取引先が手元の伝票や図面に書かれた型番をそのまま入力しても、目的の商品にたどり着ける状態をつくる設計です。具体的には、商品マスタ側で持つ識別子（自社型番・メーカー型番・取引先品番・GTIN）と、検索エンジン側の照合方式（正規化・部分一致・同義語）を対にして決めます。片方だけを整えても、精度は上がりません。

取引先が商品を探せない、あるいは要件定義の段階で検索仕様をどう書けばよいか分からない、という状況は珍しくありません。型番の取り違えによる誤発注は業務上のリスクにつながるため、受注ミスの削減策とあわせて検討する事業者もいます。本記事は「検索させる側の設計」に絞って扱います。

「型番を入れても出ない」原因はマスタ・正規化・照合方式・辞書の4つに分かれる

検索できない原因は、大きく4つに切り分けられます。第一に商品マスタ側で型番の正本が定まっていないこと、第二に表記ゆれを吸収する正規化ルールが無いことです。第三に部分一致の照合方式が入力実態に合っていないこと、第四に同義語・旧型番の辞書が育っていないことが続きます。まず整った商品マスタが前提になるため、マスタ整備そのものの手順は別途扱っています。本記事は「整ったマスタを、どう検索にかけるか」に限定します。

本記事で示す7つの手順

次章から、型番の正本を決める手順1から、検索の品質を測って直す手順7まで、順を追って整理します。各手順は独立していますが、後段の手順は前段の決定を前提にするため、上から順に検討することを推奨します。

手順1：自社型番・メーカー型番・取引先品番・GTINで「正本」を決める

GTIN（JANコード）は「どの事業者の、どの商品か」を表す国際標準の商品識別コード

GTIN（Global Trade Item Number、国際取引商品番号）とは、どの事業者の、どの商品かを表す国際標準の商品識別コードです^*2。日本国内では一般財団法人流通システム開発センター（GS1 Japan）が運用しています^*2。日本国内ではJANコードという呼び方が一般的ですが、GTINはその国際的な総称にあたります^*1。

自社型番だけで検索キーを構成すると、取引先が持つ図面や伝票の表記と一致しないことがあります。GTINのような標準コードを併せ持つことで、取引先側の識別と自社側の識別を橋渡しできます。

GTINは4種類、桁数は13・8・12・14桁でGS1事業者コードは「45」「49」始まり

GTINにはGTIN-13（JAN標準タイプ）、GTIN-8（JAN短縮タイプ）、GTIN-12（U.P.C.）、GTIN-14（集合包装用商品コード）の4種類があります^*1。

GTINを発行するGS1事業者コードは、「45」または「49」で始まる9桁・10桁・7桁のいずれかで貸与されます^*2。標準タイプは13桁、短縮タイプは8桁で構成され、事業者コード・商品アイテムコード・チェックデジットの組み合わせで成り立っています^*2。この体系を把握しておくと、既存の商品マスタにどのコードが入っているかを棚卸しする際の判断基準になります。

取引先ごとに呼び名が違う型番は別項目で持つ

BtoBで避けて通れないのが、同じ商品でも取引先ごとに呼び名が異なるという事情です。取引先の発注書には、自社の型番ではなく取引先内部の品番が書かれていることがあります。この取引先品番は自社型番・メーカー型番とは別の項目として持ち、検索キーに含める設計が必要です。本記事では検索キーへの反映方法に絞って次章で説明します。

手順2：検索キーに入れる項目と入れない項目を切り分ける

検索キーに入れる項目は型番・品名・メーカー名・規格

検索キーに含める項目は、自社型番・メーカー型番・取引先品番・品名・メーカー名・規格が基本です。これらは変化の少ない静的な項目であり、インデックスの更新頻度を抑えながら検索精度を保てます。

価格と在庫数は検索キーに入れない

価格や在庫数のような変動値をインデックスに載せると、更新のたびに再インデックスが必要になり、検索基盤の負荷が増します。価格を検索キーにしないという設計判断は、取引先別価格を扱う場合ほど重要になります。在庫数も同様に検索キーから外し、在庫連携の仕組み側で扱います。

この切り分けを誤ると、検索結果と実際の在庫・価格表示がずれて見えることがあり、問い合わせ対応の工数が増える一因になります。検索キーの設計段階で「動く値は載せない」という原則を明文化しておくことが、後工程の手戻りを防ぎます。

検索インデックスの更新頻度を差分か全件かで決める

検索キーに使うマスタ項目を基幹システムからどう検索インデックスへ供給するかも、あわせて決める必要があります。差分更新にするか全件再構築にするかは、基幹システムとの連携方式に依存します。本記事では「検索インデックスへの供給頻度を要件として明記する」という論点に留めます。

自社の数字で更新頻度やコストの妥当性を確かめたい場合は、無料相談で要件を整理するのが近道です。

手順3：表記ゆれを吸収する正規化ルールを決める

長音符号の省略は文化庁の基準でも認められた慣用

表記ゆれは、現場の入力が乱れているために起きるとは限りません。文化庁「外来語の表記」留意事項その2は、長音を原則として長音符号「ー」で書くと定めています^*3。そのうえで注3は、「英語の語末の‐er，‐or，‐arなどに当たるものは，原則としてア列の長音とし長音符号「ー」を用いて書き表す。ただし，慣用に応じて「ー」を省くことができる」としています^*3。用例として「エレベーター」と「エレベータ」、「コンピューターー」と「コンピューター」の両方が挙げられており、どちらも国語表記の基準として正しい表記です^*3。

つまり長音符号の有無は、現場のだらしなさではなく、国語表記の基準そのものが両方を許容している問題です。システム側で吸収するしかない、という前提に立って正規化ルールを設計します。

全角半角・大文字小文字・記号の正規化ルールを表で決める

正規化（表記ゆれを共通の形に揃える処理）の対象は、全角英数字、半角カナ、アルファベットの大文字小文字、ハイフンやスペースなどの記号、そして長音符号です。それぞれの決め方と根拠を、要件定義書に転記できる形で一覧にします。

正規化は登録時と検索時に同じルールを掛ける

正規化ルールを決めても、登録時にしか適用していないケースがあります。登録されたデータが正規化済みでも、検索時の入力文字列が正規化されていなければ一致しません。登録時と検索時の双方に同じ正規化を掛けることが前提になります。この片側適用の見落としは、表記ゆれ対策の中でも実装段階で最も起こりやすい失敗です。

手順4：型番はN-gram、品名は形態素解析で部分一致に対応する

kuromojiのsearchモードは複合語を分解しつつ元の複合語も残す

形態素解析（文章を意味のある最小単位の語に分割する技術）は、日本語の品名検索でよく使われます。Elasticsearchの日本語形態素解析プラグインkuromojiには、search・normal・extendedの3つのモードがあります^*4。searchモードは長い名詞を分解しつつ、元の複合語も同義語として含める設計です^*4。公式ドキュメントの例では「関西国際空港」という入力が「関西」「関西国際空港」「国際」「空港」に分割され、いずれの語でも検索がヒットするようになります^*4。

N-gramはmin_gram1・max_gram2が既定で、トライグラムが推奨される

N-gram（文字列を指定した長さで機械的に分割するトークナイズ手法）は、型番のような記号混じりの文字列に向いています。Elasticsearchのn-gramトークナイザは、最小文字数（min_gram）の既定値が1、上限文字数（max_gram）の既定値が2です^*6。公式ドキュメントは「トライグラム（3文字）から始めるのがよい」としたうえで、「文字数が短いほどヒットする文書は増えるが、一致の質は下がる」と明記しています^*6。

型番と品名で照合方式を使い分けて両方のフィールドに投げる

型番は記号を含む部分一致が必要になるため、N-gram側の処理が向いています。品名は自然な日本語の文として入力されることが多いため、形態素解析側が向いています。実装上は、型番用のフィールドと品名用のフィールドを分けて持ち、入力された検索語を両方のフィールドに投げて照合する構成が現実的です。

形態素解析とN-gramの設定は、検索エンジンの内部仕様に踏み込む領域です。既定値のまま導入すると型番が意図どおりに分割されないことがあるため、自社のマスタに実在する型番で結果を確かめながら調整する工程を、あらかじめ要件に組み込んでおきます。

手順5：同義語と旧型番の辞書を運用で育てる

synonym_graphは複数語の同義語を検索時に正しく扱う

同義語辞書（表記や呼び方が異なる語を同じ意味として扱うための対応表）は、旧型番や現場の通称を拾うために欠かせません。Elasticsearchのsynonym_graphトークンフィルタは、複数語からなる同義語を解析の過程で正しく扱うために設計されています^*5。公式ドキュメントは、このフィルタを「search analyzer の一部としてのみ使うよう設計されている」と明記しています^*5。インデックス時に同義語を反映したい場合は別のトークンフィルタを使う必要があり、この使い分けを誤ると意図した挙動になりません。

辞書に入れるもの：旧型番・略称・現場の通称・メーカー表記違い

辞書に登録する対象は、旧型番から現行型番への対応、社内の略称、現場で使われる通称、メーカー名の表記違い、シリーズ名などです。これらはマスタの正規項目としては持ちにくい情報であり、辞書という別の仕組みで補うのが現実的です。

辞書更新の責任者と反映タイミングを決める

辞書は作って終わりにすると精度が徐々に落ちていきます。誰が更新の責任者になるか、どのタイミングで辞書へ反映するかを決めておく必要があります。synonym_graphのlenientパラメータは、同義語ルールの解析エラーを無視するかどうかを制御する設定です^*5。運用中に不正な行が混入しても、インデックス全体を止めない配慮に使えます。

手順6：型番を知らない担当者のための導線をつくる

カテゴリ・メーカー・規格での絞り込みを用意する

取引先の担当者が新任である場合や、型番を手元に持たない事務担当者が発注する場合もあります。型番の入力を前提にしない導線として、カテゴリ・メーカー・規格・サイズ・入数といった属性での絞り込みを用意します。

サジェストと0件時の代替候補提示で離脱を防ぐ

入力途中で候補を提示するサジェスト機能や、検索結果が0件だったときに関連候補を代替表示する仕組みは、型番を知らない担当者の離脱を防ぐ効果があります。本記事では検索で解決する経路を扱います。

発注履歴とお気に入りは検索させない解決策になる

過去の発注履歴やお気に入り登録からの再注文は、そもそも検索させないという発想の解決策です。継続的に同じ商品を発注する取引先が多い場合、この導線だけで問い合わせの多くを吸収できることがあります。

手順7：0件率と応答時間を指標に検索の品質を測る

0件率・検索後離脱率・検索経由受注比率を測る

応答時間はIPA非機能要求グレードの枠組みで段階的に決める

検索の応答時間は、感覚で「速くしてほしい」と伝えるのではなく、非機能要件として明文化する対象です。独立行政法人情報処理推進機構（IPA）が公開する非機能要求グレード（2018年版・最終更新2023年8月17日）は、性能・拡張性などの非機能要件を発注側と開発側で合意するための枠組みです^*7。開発するシステムに近いモデルシステムを選び、重要項目の優先度を設定したうえで、段階的に要求レベルを確認していきます^*7。応答時間の具体的な秒数を決める場合も、この枠組みに沿って要求レベルを合意してからベンダーに伝える進め方が現実的です。

非機能要件を明文化しないまま検索エンジンを発注すると、体感速度への評価が発注側とベンダー側で食い違い、検収の段階でやり直しが発生するおそれがあります。応答時間の要件を書かずに発注しないことは、つまずきやすい落とし穴の一つでもあります（後述）。

0件だったキーワードを毎月同義語辞書へ反映する

0件で終わった検索キーワードを定期的に洗い出し、同義語辞書や正規化ルールへ反映するサイクルを運用に組み込みます。月次で見直す運用にすれば、辞書は使うほど精度が上がっていきます。

型番検索の設計でつまずきやすい5つの落とし穴

ここまでの手順を踏まえたうえで、実装段階で起こりやすい5つのつまずきを整理します。

1. 商品マスタが整っていないまま検索エンジンだけを入れ替えてしまう（マスタ整備は適切な準備を先に確認します）。
2. 正規化を検索時にしか掛けておらず、登録データ側が正規化されていない。
3. 型番のフィールドに形態素解析だけを掛けてしまい、記号の位置で語が切れて一致しなくなる。
4. 同義語辞書を作った時点で満足し、その後の運用（更新・0件語の反映）が止まる。
5. 応答時間の要件を書かずに発注し、体感速度をめぐって発注側とベンダー側で認識が食い違う。

いずれも、専門的な設定知識と運用体制の両方が必要な領域です。内製で完結させる場合は、データベースの正規化・検索エンジンのアナライザ設定・表記基準の確認まで、幅広い知識を組み合わせる必要があります。外部の専門パートナーに相談すれば、これらの決め事を要件定義書に落とし込む工程を短縮できます。

まとめ：型番検索の精度を決める3つの判断軸

本稿では、BtoB ECの型番検索を精度よく機能させるための設計を7つの手順で整理しました。要点を3つに集約すると次の通りです。第一に、自社型番・メーカー型番・取引先品番・GTINのどれを検索キーの正本にするかを決めることです。第二に、正規化・部分一致・同義語という検索エンジン側の照合方式を、公式ドキュメントの仕様に基づいて選ぶことです。第三に、0件率や応答時間を指標として運用に組み込み、辞書と設定を継続的に育てていくことです。

---

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

よくある質問

型番検索に対応するには、まず何から手を付ければよいですか。

まず商品マスタ側で「型番の正本」を、自社型番・メーカー型番・取引先品番・GTINのどれにするかを決めることから始めます。マスタが未整備の場合は、検索エンジン側の設定に着手する前に適切な準備を済ませてください。

JANコード（GTIN）は持たせる必要がありますか。

必須ではありません。ただしGTINは「どの事業者の、どの商品か」を表す国際標準の商品識別コードであるため^*2、複数拠点や取引先とのデータ連携を見据える場合は保持しておくと橋渡しに使えます。

全角と半角のどちらで登録すればよいですか。

登録時と検索時に同じ正規化ルールを掛けることが前提であれば、どちらの表記で登録しても構いません。重要なのは表記の統一ではなく、登録側・検索側の両方に同一の正規化処理を適用することです。

旧型番で検索されたときに現行品を表示できますか。

同義語辞書に旧型番と現行型番の対応を登録すれば表示できます。Elasticsearchのsynonym_graphトークンフィルタは、複数語からなる同義語を検索時に正しく扱うよう設計されています^*5。

検索がうまくいっているかは、どの指標で判断すればよいですか。

0件率・検索後離脱率・検索経由受注比率の3つを継続的に測定します。0件率は辞書や正規化ルールの不足箇所を最も直接的に示す指標です。

1. *1　出典：一般財団法人流通システム開発センター（GS1 Japan）「GTINとは」（現行版）
2. *2　出典：一般財団法人流通システム開発センター（GS1 Japan）「GS1事業者コード・GTIN（JANコード）とは」（現行版）
3. *3　出典：文化庁「外来語の表記　留意事項その2（細則的な事項）」
4. *4　出典：Elastic「kuromoji_tokenizer（Elasticsearch公式リファレンス）」（現行版）
5. *5　出典：Elastic「synonym_graph token filter（Elasticsearch公式リファレンス）」（現行版）
6. *6　出典：Elastic「N-gram tokenizer（Elasticsearch公式リファレンス）」（現行版）
7. *7　出典：独立行政法人情報処理推進機構（IPA）「非機能要求グレード」（2018年版・最終更新2023年8月17日）