部品を種類別に並べた商品見本の棚
部品を種類別に並べた商品見本の棚
この記事の内容
  1. 最初の検索対象を一つの商品群に絞る
  2. 商品IDと表示用の型番を分けて保存する
  3. 型番の一致を説明文の検索より優先する
  4. 条件を変えたら先頭のページへ戻す
  5. 似た型番を含む五商品で照合する
  6. 在庫数と販売可否を別の情報として表示する
  7. 費用は検索回数と更新の量で見積もる
  8. 検索の失敗を商品整理へ戻す

最初の検索対象を一つの商品群に絞る

最初は同じ店舗で扱う金具のカタログを例にし、商品名、型番、用途、寸法、カテゴリから探せる画面を作ります。価格比較や発注、顧客別の掛率まで同時に追加すると、検索結果を何で照合すべきか曖昧になります。初回は商品を見つけて詳細を確認するところまでを完成範囲とします。

AIには架空の商品五件と、型番を知る人、用途から探す人の二つの操作例を渡します。商品名が似ていても寸法違いを見分けられることを完成条件にし、大きな画像だけで差を表現しないよう指示します。見つからない場合に問い合わせへ進める導線も用意します。

商品IDと表示用の型番を分けて保存する

productsには内部の商品ID、表示用型番、正規化した検索用型番、商品名、カテゴリID、公開状態を持たせます。寸法や材質は自由文だけにせず、絞り込みたい項目を決めて別の値として保存します。同じ商品を名称変更しても、関連画像や問い合わせ履歴を別の商品へ移さないよう内部IDは維持します。

Replitのデータベースは商品情報を保存する選択肢です。最初から全件をブラウザーへ送り込まず、公開済みの商品と必要な列を取得する処理にします。下書きの仕入価格や社内備考は、画面から隠すだけでなく公開検索の応答から除きます。

型番の一致を説明文の検索より優先する

型番の完全一致と、商品名・説明文の検索を別の経路にします。ハイフンや空白、大文字・小文字を同じとみなす範囲を決め、先頭ゼロを消したり、寸法を表す記号を不用意に削除したりしません。入力値そのものと、検索に使った変換後の値を区別して扱います。

PostgreSQLには全文検索の機能がありますが、それだけで日本語の商品名や特殊な型番が期待どおり見つかるとは限りません。まず型番と部分一致の小さな例で仕様を確かめ、必要な言語設定や検索方式を選びます。類似候補を出すときは完全一致の結果と分けて表示します。

部品を種類別に並べた商品見本の棚
部品を種類別に並べた商品見本の棚

条件を変えたら先頭のページへ戻す

カテゴリ、材質、寸法の条件は検索語と同じ場所で確認できるようにし、絞り込み後の件数を表示します。条件を変更した際はページ番号を先頭へ戻します。前の条件で三ページ目を開いていたために、新しい条件の結果が空に見える状態を避けるためです。

一覧の並び順には商品IDなどの安定した基準を加えます。同じ商品名が並んでも次のページへ移動したときに重複や抜けが起きないよう、件数と取得範囲を確認します。戻る操作で条件を復元したい場合は、安全に扱える検索条件をURLへ反映し、長すぎる入力には上限を設けます。

似た型番を含む五商品で照合する

架空の例として型番AB-010、AB-010L、AB-011と、名前は似ている別カテゴリの商品二件を登録します。AB-010の完全一致では一件、ABを含む検索では複数件が出る条件を用意します。続いてカテゴリを絞り、型番が似ているだけの別商品を誤って選ばないか確認します。

結果がゼロ件の場合、すべての条件を解除する操作と、一つずつ条件を見直す操作を用意します。検索が成功したように見せるために無関係な商品を表示しません。商品詳細から一覧へ戻った際に、検索語と選択した条件が保たれることも、この練習データで照合します。

似た型番を見分ける確認例
似た型番を見分ける確認例
練習条件期待する結果確認する記録
AB-010を完全一致で検索AB-010だけが出る表示型番と内部商品ID
ABを含む商品を検索複数候補を仕様付きで表示型番・寸法・カテゴリ
カテゴリを変える先頭ページへ戻る条件と取得件数
在庫の取得が失敗不明と最終更新時刻を示す在庫同期の最終成功時刻

型番は架空の練習例です。在庫不明をゼロや販売可能と同一視しません。

在庫数と販売可否を別の情報として表示する

在庫数の更新が遅れる構成では、検索結果だけで購入や確保が完了したように表示しません。在庫の確認時刻、取り寄せの可否、販売停止の状態を分け、未取得の値をゼロとして扱わないようにします。在庫ゼロと在庫不明では、問い合わせの必要性や次の操作が違います。

更新処理が失敗した場合は、最終成功時刻を残して古い情報であることを判断できるようにします。商品名や仕様の更新と在庫の同期を別にしておくと、在庫側の障害でカタログ全体を更新できなくなる事態を避けやすくなります。公開停止した商品は直接URLからの表示も確認します。

費用は検索回数と更新の量で見積もる

Replitで試作や修正を進める利用量と、公開後のデータベース、サーバー、画像配信にかかる費用は別に記録します。商品点数だけでなく、検索回数、詳細表示、在庫更新、画像の容量を運用量として見ます。一文字入力するたびに全件検索を送る必要があるかも見直します。

先に五件の例で正しさを固め、次に想定する件数で応答時間を測ってから索引や取得方法を調整します。遅さを理由に全商品を公開データとして一括配信する前に、どの問い合わせが重いかを確認します。実際の請求条件と保存枠は現在の公式案内で照合します。

検索の失敗を商品整理へ戻す

公開後は個人情報を含まない範囲でゼロ件の傾向や検索エラーを集計し、商品名の別表記が足りないのか、カテゴリ分けが難しいのかを見直します。入力された検索語をすべて永久保存する運用ではなく、改善に必要な粒度と保持期間を決めます。削除した商品の型番が繰り返し検索される場合は、代替品の案内を編集で判断します。

修正した検索規則は練習データへ追加し、完全一致、絞り込み、ページ移動、公開停止をまとめて再確認します。検索結果の順位を変えた場合も、商品そのものの仕様や在庫値が書き換わっていないかを照合し、担当者が変更理由を追える記録を残します。

参照した公式情報

料金・提供条件・対応範囲は変更されることがあります。契約前に、下記の公式ページでご確認ください。

比較方針を読む広告について