はじめに
「〜¥25,000」「¥25,001〜¥50,000」のような価格帯フィルターは、どのECサイトにもある定番の機能です。それだけに簡単に作れそうに見えるのですが、運用を始めると「画面では選べるのに絞り込むとエラーになる」「価格帯を変えたいのに、直す場所が多くて手を付けられない」といった問題が起きがちです。
この記事では、価格帯の定義を1か所にまとめるSSOT（Single Source of Truth。信頼できる情報源を1つに絞る考え方）で、管理しやすく壊れにくい価格帯フィルターを作った方法を解説します。
価格帯フィルターで起きやすい3つの問題
定義が複数の場所に散らばる
価格帯フィルターは、画面に選択肢を表示する部分と、選ばれた条件で商品を絞り込む部分の、少なくとも2か所で「どの価格帯があるか」を知っている必要があります。それぞれの場所で別々に価格帯を定義してしまうと、片方だけ直して片方を直し忘れる、という不整合がいつか必ず起きます。画面では選べるのに検索するとエラーになる、という症状の原因はたいていこれです。
変更のたびに複数箇所を直すことになる
「¥25,000区切りを¥30,000区切りに変えたい」となったとき、定義が散らばっていると、画面表示・絞り込み処理・URLの解釈といった関係箇所をすべて探して直すことになります。修正の手間が大きいだけでなく、直し漏れのリスクも修正のたびに付いて回ります。変更したいのに気軽に変更できない状態、というのが正直なところでした。
保存されたURLが動かなくなる
絞り込み条件はURLに含まれるため、ユーザーがその状態をブックマークしていることがあります。フィルターの作りを変えたときに古いURLの形式を切り捨ててしまうと、保存していたページを開いても絞り込みが効かなくなってしまう。機能改善のつもりの変更が、既存ユーザーには「壊れた」と映る事態です。
解決策 — 価格帯の定義を1つのファイルに集約する
すべての処理が同じ定義を参照する
採用したのは、価格帯の定義（いくつからいくつまでを、どんなラベルで見せるか）を1つのファイルに集約し、画面表示も絞り込み処理もURLの解釈も、すべてその1か所を参照する構成です。定義がただ1つなので、参照する側同士で食い違いようがありません。SSOTという考え方をフィルターに適用した形です。
価格帯は購買行動に合わせて決める
定義ファイルに置いた価格帯は、次の5段階です。
表のとおり、各価格帯にはrange_1のようなIDを付け、金額の範囲と表示ラベルをセットで持たせています。区切りの金額は、扱う商品の価格分布とユーザーの予算感に合わせて決めました。
絞り込みが動く流れ
ユーザーが価格帯を選んでから商品が表示されるまでは、次の流れです。
図を一言でまとめると、「URLに載るのは価格帯のIDだけで、その意味はすべて定義ファイルに聞きに行く」という流れです。
一元管理で何がラクになったか
変更が1ファイルの修正で完結する
価格帯を変えたいときは、定義ファイルを1つ修正するだけ。画面の選択肢も絞り込み処理もURLの解釈も、すべて同じ定義を見ているので、自動的に新しい価格帯で動き始めます。直し漏れの心配がなくなったことで、「試しに区切りを変えてみる」といった調整も気軽にできるようになりました。
「選べるのにエラーになる」が起きない
定義が1か所にしかないため、画面とサーバー処理で価格帯の認識がずれることが構造的に起きません。不具合を修正したのではなく、不具合が起きようのない構造にした、という点がSSOTの効き方です。
古いURLも動き続ける
以前の形式（例: 0-25000）で保存されたURLは、開かれたときに新しいID形式（例: range_1）へ自動変換して処理します。この変換も定義ファイルを参照して動くので、価格帯を今後変更しても変換ルールが置き去りになりません。ブックマークしてくれていたユーザーの環境を壊さずに、内部の作りだけを新しくできました。
図を一言でまとめると、「古い書き方のURLが来ても、入り口で今の書き方に翻訳してから通常の処理に乗せる」仕組みです。
まとめ
価格帯フィルターの信頼性は、価格帯そのものの決め方よりも「定義をどこで管理するか」で決まります。定義を1つのファイルに集約したことで、変更は1か所、不整合は構造的に起きない、古いURLも動き続ける、という状態を実現できました。定番機能ほど、こうした管理のしやすさを最初に設計しておくと後がラクになります。