BtoB ECの検索条件保存機能とは？設計要件と運用ルール

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

B2B EC-COLUMN

BtoB ECの検索条件保存機能とは、条件の組み合わせに名前を付けて再利用できる機能である

BtoB ECの検索条件保存機能とは、購買担当者が指定した絞り込み条件の組み合わせに名前を付けて保存する機能です。次回以降は呼び出すだけで同じ検索結果を再現できます。2024年のBtoB-EC市場規模は514.4兆円、EC化率は43.1%に達し、繰り返し検索の効率化ニーズが高まっています^*1。

商品そのものを登録する「お気に入り商品」や「定番商品リスト」とは異なり、保存する対象は条件そのものです。そのため商品が入れ替わっても、同じ観点で探し直せます。

「検索履歴」「お気に入り商品」「定番商品リスト」との違い

検索履歴は入力した検索語句そのものの記録で、名前を付けて呼び出す仕組みではありません。お気に入り商品と定番商品リストは、個別の商品を登録する機能であり、商品が廃番になれば登録自体が意味を失います。

検索条件保存は、絞り込みの「観点」を保存する点でこれらと異なります。次の表に主な違いをまとめました。

保存できる条件の範囲は商品マスタの属性設計で決まる

保存できる条件は、システムが検索インデックスとして持つ属性の範囲で決まります。具体的には、カテゴリ、型番の部分一致、規格値の範囲、在庫状態、納期、発注単位などが対象になります。

どこまで保存できるかは商品マスタの属性設計に依存します。マスタに規格値や単位の項目がなければ、その軸で条件を保存すること自体ができません。

BtoBで重要になる理由は、同じ条件の検索が繰り返されるためである

BtoCの購買は都度探索型が中心ですが、BtoBの発注担当者は決まった仕入先・規格・カテゴリの範囲で毎回同じ絞り込みをする傾向があります。取引先ごとに扱う商品群がある程度固定されているためです。

そのため検索条件保存は、単なる利便性向上ではなく、発注担当者が毎回同じ操作を繰り返す業務そのものを短縮する機能として位置づけられます。

保存機能の設計原則は「一度入力させた情報を再入力させない」ことである

W3C WCAG 2.2 達成基準3.3.7「冗長な入力」（レベルA）が求めること

WCAGはWeb Content Accessibility Guidelines（Webコンテンツのアクセシビリティ指針）の略称です。策定主体はWorld Wide Web Consortium（W3C）で、2.2は2024年12月に勧告された最新版です。

達成基準3.3.7「冗長な入力」はレベルAの基準です。同一プロセス内で一度入力・提供された情報は、自動入力するか選択可能な形で提示することを求めています^*2。

この基準は認証フォームや購入手続きを主な想定範囲としていますが、検索という一連の操作プロセスにも同じ考え方が当てはまります。

検索結果ページでの検索語の前埋めは、W3C解説書が挙げる実装例

W3Cが公開する解説書「Understanding SC 3.3.7」は、規範文そのものではなく実装の理解を助ける補足資料です。この解説書は実装例として、検索結果ページで前回入力した検索語を入力欄にあらかじめ表示する挙動を挙げています^*3。

検索条件保存機能は、この考え方を条件の組み合わせ単位に拡張したものと整理できます。認知的な負担や記憶の負担を軽減できる点は、解説書が示す便益と共通しています。

国内規格ではJIS X 8341-3:2016が対応する位置づけ（規格の版と対応国際規格の違いに注意）

国内の対応規格であるJIS（日本産業規格）X 8341-3:2016は、対応国際規格をISO/IEC 40500:2012とする現行有効な規格です^*4。ISO/IEC 40500:2012はWCAG 2.0に相当するため、達成基準3.3.7を含んでいません。

したがって「JIS X 8341-3が検索条件の保存を義務付けている」と読むのは誤りです。3.3.7はWCAG 2.2の新規基準であり、あくまで設計原則として援用する位置づけになります。

同じ2.2には、ページ到達手段の複数化を求める達成基準2.4.5や、認証の負担を軽減する3.3.8もレベルAAとして含まれています。これらは検索とカテゴリを併存させる設計判断の参考になります^*5。

効果は「効率」の指標で測る

JIS Z 8521:2020のユーザビリティ定義（効果・効率・満足）

JIS Z 8521:2020「人間工学―人とシステムとのインタラクション―ユーザビリティの定義及び概念」は、1999年3月に制定された規格の改正版です。2020年2月20日に改正され、2024年10月21日の確認を経て現行も有効な規格です^*6。この規格はユーザビリティを「特定のユーザが特定の利用状況において、システム、製品又はサービスを利用する際に」と前置きしたうえで定義しています。定義の結語は「効果、効率及び満足を伴って特定の目標を達成する度合い」です^*7。

保存機能の効果を語るとき「便利になった」という感想だけで終わらせず、この3要素に沿って評価すると、次期の改修可否を判断できる材料が残ります。

効率の下位構成要素は所要時間・消費された労力などである

規格案の作成に携わった委員による解説（日本人間工学会大会講演集）では、効率の下位構成要素として所要時間・消費された労力・消費された資金・消費された資材が示されています^*7。検索条件保存機能に当てはめると、条件設定にかかる操作数や時間が該当します。

同解説は、効果・効率・満足のすべての構成要素の測定が必要であると述べており、効率だけを見て評価を完結させない点に注意が必要です^*7。

KPI候補は操作数・所要時間・保存条件経由の注文比率である

効率の観点で測るKPI候補としては、条件設定までの操作数、検索から明細追加までの所要時間、保存条件経由の注文比率が挙げられます。これらは公開後に自社のログから実測する指標であり、本記事の時点で具体的な数値を示す一次情報はありません。

効果・満足の側面も含めて計測設計を先に決めておくと、リリース後の効果検証がしやすくなります。

設計で決める7項目

検索条件保存機能を要件定義書に落とし込む際は、以下の7項目をあらかじめ決めておく必要があります。項目名だけを機能一覧に書いても、実装段階で判断が止まりやすいため、決め方の要点も併せて整理しました。

7項目を自社の数字で確かめるには、無料相談で要件を整理するのが近道です。

保存した条件は陳腐化する。更新時の挙動を先に決めるべきである

商品改廃・カテゴリ再編で保存条件が0件を返す

保存条件は登録した時点の商品構成を前提にしています。商品が廃番になったり、カテゴリが再編されたりすると、保存条件を呼び出しても該当商品が0件になる場合があります。

この挙動を放置すると、担当者は保存機能自体を信用しなくなり、使われなくなります。0件表示への対応を後回しにすると、問い合わせ対応の手戻りにつながりかねません。

取引先別価格・単価マスタの有効期間との整合

単価帯を含む条件を保存できる場合、取引先別価格や単価マスタの有効期間との整合も論点になります。単価改定後に古い価格帯を指したままの保存条件が残ると、実際の販売価格と表示価格がずれる可能性があります。

単価マスタの有効期間管理と検索条件保存の更新タイミングは、別々の担当が設計しがちな領域です。設計段階で両者の整合を確認しておく必要があります。

0件時・条件不整合時の代替提示と通知の設計

更新時の挙動としては、条件に該当する商品が0件になった場合の代替商品の提示、保存条件が古くなっている可能性を知らせる通知の2つを検討します。いずれも公開前に仕様として確定させておく項目です。

この設計を内製だけで完結させるには、商品マスタ・カテゴリ構成・単価マスタの3つを横断して把握する必要があります。自社のマスタ構造を把握したパートナーに相談すれば、前提整理を含めて要件定義の手戻りを抑えられます。

保存データはアカウントに紐づく個人データとして扱う

個人情報保護法 第23条（安全管理措置）が求めること

検索条件保存機能は特定のアカウントに紐づくため、保存された条件も個人データの取扱いに含まれます。個人情報の保護に関する法律第23条は安全管理措置を定めた条文です。条文では「個人データの漏えい、滅失又は毀損の防止その他の個人データの安全管理のために必要かつ適切な措置を講じなければならない」とされています^*8。

保存条件そのものは機微な情報ではありませんが、アカウントと紐づく以上、この安全管理措置の対象から外れません。

SaaSで実装する場合は第25条（委託先の監督）が適用される

検索条件保存をSaaS型のECパッケージで実装する場合、データの取扱いを外部事業者に委託する形になります。同法第25条は、委託する場合に「委託を受けた者に対する必要かつ適切な監督を行わなければならない」と定めています^*8。

委託先の選定時には、安全管理の水準を確認する体制が必要になります。従業者の監督を定めた第24条も含め、社内規程と委託先評価の両方に関わる条文です^*8。

通則編ガイドラインは安全管理措置を7項目で示している

個人情報保護委員会の「個人情報の保護に関する法律についてのガイドライン（通則編）」は、別添「講ずべき安全管理措置の内容」で計7項目を示しています^*9。内訳は、基本方針の策定、個人データの取扱いに係る規律の整備、組織的・人的・物理的・技術的の4つの安全管理措置、外的環境の把握です。検索条件保存機能のアクセス権限設計は、このうち技術的安全管理措置に該当する領域です。

具体的な運用は自社の個人データの取扱い状況によって異なります。判断が必要な場面では、顧問弁護士や同ガイドラインの記載を確認しながら進めることをお勧めします。

検索条件保存機能の設計は5ステップで進める

ステップ1〜2：検索ログの棚卸しから保存単位の決定へ

ステップ1の成果物は「繰り返し条件の一覧」です。既存の検索ログやアクセスログから、同一担当者が月内に3回以上使った条件の組み合わせを抽出し、頻度順に並べます。ログが無い場合は、営業担当への聞き取りと問い合わせ履歴で代替し、件数ではなく担当者名つきの実例として残します。

ステップ2の成果物は「保存単位の定義書」です。ここで決めるのは前掲7項目のうち保存単位のみで、担当は業務部門です。案件・現場・得意先のどれを採るかは、ステップ1で並べた条件が何を軸に繰り返されていたかで決まります。この2工程は情報システム部門に渡す前に業務部門側で閉じておく工程です。

ステップ3〜4：共有範囲と権限の設計から陳腐化ルールの決定へ

ステップ3の成果物は「権限マトリクス」です。この工程では、役割（発注担当・承認者・拠点管理者）と操作（閲覧・編集・削除）を表で突き合わせます。そのうえで、既存のアカウント権限体系に載るかどうかを確認します。載らない場合は権限体系の改修が別途必要になります。

ステップ4の成果物は「陳腐化イベント一覧と対応表」です。商品改廃・カテゴリ再編・単価改定の3イベントについて、発生頻度、検知の担当、0件時と価格ずれ時の画面挙動を1行ずつ埋めます。ここで単価マスタの管理担当と検索側の設計担当が同席することが、この工程を後回しにしないための条件です。

ステップ5：効率指標の計測設計とリリース後の見直し

ステップ5の成果物は「計測仕様」です。ステップ2〜4で決めた仕様に対し、どのイベントをいつ記録するかをリリース前に確定させます。ログ設計は後付けができないため、この工程だけは開発着手前に完了させる必要があります。

5工程を通すと、商品マスタと単価マスタの属性設計、UI/UX設計、個人情報保護法の実務知識が同時に必要になることが分かります。マスタ構造の理解を前提とした設計であるため、担当領域をまたいだ調整が発生しやすい点に留意してください。

まとめ

本稿では、BtoB ECの検索条件保存機能について、定義から設計要件、運用ルールまでを整理しました。要点は3つに集約できます。第一に、保存単位は案件・現場・得意先といった業務の単位と合わせる必要があります。第二に、効果はJIS Z 8521:2020が示す効果・効率・満足の枠組みで測定します^*7。第三に、保存条件は陳腐化するため、公開前に0件時の挙動と通知の設計を決めておくことが欠かせません。加えて、保存条件はアカウントに紐づく個人データです。安全管理措置（個人情報保護法第23条）と、SaaSで実装する場合の委託先の監督（同第25条）を設計時の前提に含めておく必要があります^*8。

---

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

よくある質問

検索条件の保存件数に上限を設けるべきですか。

上限を設けることをお勧めします。上限が無いと保存条件が増え続け、呼び出し導線の一覧が探しにくくなります。目安の件数は業務の頻度に応じて個別に検討してください。

保存した条件を他の担当者と共有させても問題ありませんか。

共有自体に問題はありませんが、編集・削除の権限を誰に与えるかを事前に決めておく必要があります。個人保存と組織共有を両立させる設計が実務上求められます。

商品が廃番になった場合、保存条件はどう扱うべきですか。

条件に該当する商品が0件になった場合の代替提示や、保存条件が古くなっている可能性を知らせる通知を設計しておくべきです。放置すると機能自体が使われなくなります。

検索条件の保存はアクセシビリティ要件に関係しますか。

関係します。WCAG 2.2の達成基準3.3.7は、同一プロセス内で一度入力した情報の再入力を求めないことを定めています^*2。検索条件を保存して再入力を避ける設計は、この考え方に沿っています。ただし同基準はセッションをまたぐ条件保存そのものを義務付けるものではありません。

1. *1　出典：経済産業省「令和6年度電子商取引に関する市場調査」（2025年8月26日公表）
2. *2　出典：World Wide Web Consortium（W3C）「Web Content Accessibility Guidelines (WCAG) 2.2　達成基準3.3.7 Redundant Entry」（2024年12月）
3. *3　出典：World Wide Web Consortium（W3C）「Understanding SC 3.3.7: Redundant Entry」
4. *4　出典：日本規格協会（JSA）「JIS X 8341-3:2016 高齢者・障害者等配慮設計指針―情報通信における機器，ソフトウェア及びサービス―第3部：ウェブコンテンツ」（2016年3月22日）
5. *5　出典：World Wide Web Consortium（W3C）「Web Content Accessibility Guidelines (WCAG) 2.2　達成基準2.4.5 Multiple Ways・3.3.8 Accessible Authentication (Minimum)」（2024年12月）
6. *6　出典：日本規格協会（JSA）「JIS Z 8521:2020 人間工学―人とシステムとのインタラクション―ユーザビリティの定義及び概念」（2020年2月20日）
7. *7　出典：日本人間工学会　小林大二「JIS Z 8521:2020 ユーザビリティの定義及び概念―改訂のポイント―」日本人間工学会大会講演集57巻Supplement
8. *8　出典：e-Gov法令検索（デジタル庁）「個人情報の保護に関する法律」第23条・第24条・第25条
9. *9　出典：個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」（平成28年11月　令和8年6月一部改正）