AIショッピングモール検索の開発前に決めるべき5つの運用方針

AIは商品一覧API、検索窓、並び替えボタンを素早く作ることができる。しかし、どの商品を見せ、どの商品を隠し、何を「おすすめ」と呼ぶのかはコードではなく運用ポリシーである。ショッピングモール検索は単純な照会機能ではなく、売り場配置、広告枠、在庫処理、顧客体験、データ収集が一か所に結合された意思決定システムだ。

ポリシーを与えないまま「商品検索機能を作って」とだけ指示すると、AIは最新登録順、商品名の部分一致、単純なページネーションのような慣れた例を任意に埋めることがある。コードは動いても、店舗運営には合わない場合がある。新着商品が品切れなのに最上段に表示され、販売終了商品がカートに入り、顧客が「りんご」と検索しても「青松ふじ」を見つけられない問題が代表的だ。

検索順位は技術機能ではなく運用ポリシーである

商品の陳列順は事業者が設計できる。ただし、画面が消費者に伝える意味と実際の順位算定方式が食い違ったり、経済的利害関係のある露出を一般的なおすすめのように見せたりすると、法的・信頼上のリスクが大きくなる。

公正取引委員会は2024年6月、クーパンとCPLBの検索順位運営および役職員による購入レビュー作成などを問題視し、暫定1,400億ウォンの課徴金を発表した。同年8月の議決書基準では課徴金は1,628億ウォンと定められた。事業者側は処分に不服を申し立てており、2026年4月の報道基準で関連取消訴訟は継続中だった。この事例の実務的な教訓は、「自社商品優遇は常に違法」という単純な命題ではない。おすすめという表示が何を意味するのか、広告・自社の利害関係を明確に示したのか、順位変更をデータと文書で説明できるのかを設計段階で検討すべきだという点である。

法律の適用はサービス構造と表示方法によって変わり得るため、実際のリリース前には関連法令と最新の執行事例を別途確認するのが安全だ。

一行プロンプトが作る「即席版」の失敗ポイント

AIは要件の空欄を埋めることはできるが、その選択が店舗の戦略と法的責任に合っているかは判断できない。したがって実装前に、少なくとも次の5つのポリシーを文書で確定しなければならない。

1. 並び替えの基本値：何を「おすすめ順」と呼ぶのか

基本の並び替えは顧客が最初に見る陳列棚だ。多くのユーザーは並び替えオプションを変更しないため、基本値は売上、在庫消化、新商品の育成、顧客満足度に直接影響する。

まず順位算定段階を分離する

検索結果は一度に混ぜて計算するより、次の順序に分けるのが安全だ。

1. 露出資格判定： 販売可能、公開可能、法的・運用上のブロック対象ではない商品のみ候補に含める。
2. 検索関連度計算： 商品名、ブランド、カテゴリ、属性、同義語が検索語とどれほど合うかを計算する。
3. オーガニック順位計算： 販売速度、コンバージョン率、評価の信頼度、配送品質のようなシグナルを組み合わせる。
4. ビジネスルール適用： 品切れ減点、新商品の探索機会、多様性制限などを適用する。
5. 広告スロット結合： 広告商品はオーガニック順位と分離して挿入し、明確に表示する。
6. 安定した同点処理： 同じスコアの場合、product_idのような固定キーで順序を決める。

おすすめスコアは文書化された公式でなければならない

次は構造を説明するための例にすぎず、すべてのショッピングモールに合う正解ではない。

organic_score =
  0.45 × query_relevance
+ 0.20 × conversion_rate_28d
+ 0.15 × sales_velocity_14d
+ 0.10 × rating_confidence
+ 0.10 × fulfillment_quality

各シグナルは同じ範囲に正規化し、期間と集計対象を明示しなければならない。単純平均の星評価は、レビュー1件の5点商品をレビュー1,000件の4.8点商品より高くしてしまう可能性があるため、レビュー数をともに反映した補正スコアを使うほうがよい。販売量だけを使うと、長く売れている商品が恒久的に有利になり得るため、直近期間の販売速度とコンバージョン率を一緒に見る。

必ず決めるべき詳細項目

• おすすめ順の目標が検索適合度、購入可能性、顧客満足、在庫効率のうち何なのか
• 各シグナルの集計期間と更新周期
• キャンセル率、返品率、配送遅延、品切れ可能性のような減点シグナル
• レビューが少ない新商品に与える探索機会と最大加点
• 同一ブランドや同一販売者が上位を過度に占有しないようにする多様性ルール
• スコア同点時に使用する固定並び替えキー
• 順位公式のバージョン、変更理由、適用時刻、承認者を残す監査記録
• A/Bテストの成功指標と中止条件

広告とオーガニックおすすめを混ぜない

広告費、自社商品かどうか、高いマージンのような経済的利害関係を反映することはできるが、これを一般的な「人気順」や「おすすめ順」と誤認させると危険だ。公正取引委員会は2025年、高額商品販売プラットフォーム事件でも、有料オプションを購入した販売者の商品が基本並び替えで優先露出される構造と関連表示を問題視した。広告商品は別の候補群とスロットで管理し、カード単位で識別可能な「広告」または「スポンサー」表示を提供するのが基本だ。管理者画面には広告露出ルールとオーガニック順位公式を分離して見せるべきだ。

2. 異常状態の商品：品切れと販売停止は別の状態である

is_sold_out一つですべての例外を処理すると、検索、詳細、カート、注文検証が互いに食い違う。少なくとも販売状態、在庫状態、公開状態、規制状態を分離しなければならない。

推奨状態モデル

品切れ商品は再入荷通知と検索需要把握に価値があるため、無条件に削除する必要はない。一方、販売終了商品は一般一覧から除外しつつ、既存のブックマークや外部リンクから入ってきた顧客に「販売が終了しました」という説明と類似商品を提供できる。詳細URLを維持するか410 Goneで終了するかは、検索流入、法的告知の必要性、代替コンテンツの価値によって決める。

検索インデックスは注文可能可否の最終権限ではない

検索インデックスには同期遅延が生じ得る。したがって検索結果で在庫があるように見えても、次の段階で再度検証しなければならない。

• カート投入時に販売状態と在庫を再検証
• 注文書進入時に価格、割引、在庫を再検証
• 決済直前に在庫予約または原子的減算
• 販売停止イベント発生時に検索インデックスから緊急削除
• インデックス遅延時間と失敗件数をモニタリング

このルールがないと、検索画面は正常なのに決済段階でだけ失敗するCS事故が繰り返される。

3. 一覧露出方式：ページネーション、もっと見る、無限スクロールのどれを使うのか

商品が数千・数万個あるなら、一度にすべて送ってはいけない。ただし「ショッピングモールは常に数字ページが正解」と断定するのも正確ではない。比較中心の検索では位置と状態の復元が重要で、カテゴリ探索では「もっと見る」が便利な場合がある。

実務的には、検索結果にはページネーションまたは「もっと見る + 復元可能なページURL」、発見型おすすめフィードには無限スクロールを優先検討できる。純粋な無限スクロールを使う場合でも、次の条件を満たす必要がある。

• 検索語、並び替え、フィルター、ページまたはカーソルをURLや復元可能な状態に保存
• 詳細ページから戻った時に以前の商品とスクロール位置を復元
• キーボード探索、スクリーンリーダー、フォーカス移動をサポート
• フッターと主要ナビゲーションリンクにアクセス可能な代替手段を提供
• 読み込み失敗と再試行UIを提供
• 各結果群にアクセス可能な固有URLまたはリンク構造を用意

オフセットとカーソルページネーション

OFFSET 5000 LIMIT 40のような深いオフセットは、データが多く更新が頻繁なほど遅くなり、重複・欠落が生じやすい。浅いページと管理者画面ではオフセットが単純だが、大規模検索には最後の結果の並び替えキーを渡すカーソル方式が安定的だ。

ORDER BY score DESC, product_id DESC
cursor = last_score + last_product_id

スコアだけをカーソルに使うと同点商品が抜ける可能性があるため、固有キーを一緒に使用する。おすすめスコアがリアルタイムで頻繁に変わるなら、検索セッション中はスナップショットバージョンやランキング基準時刻を固定するポリシーも必要だ。

4. 検索範囲と結果なし画面：顧客の表現を商品データにつなぐ

顧客は運営者が登録した正確な商品名を知らない。「りんご」を探す顧客に「青松ふじ」、「紅露」、「家庭用りんご」を見せるには、商品データと検索辞書を一緒に設計しなければならない。

検索フィールドの優先順位

韓国語検索では、分かち書きの違い、字母分離、英語・ハングルのブランド表記、数字と単位、複合名詞も考慮しなければならない。たとえば「에어팟프로2」、「에어팟 프로 2」、「AirPods Pro 2」が同じ商品群につながるように正規化ルールを置く。

推奨検索パイプライン

1. 入力長と許容文字を検証する。
2. 大文字小文字、空白、特殊文字、単位を正規化する。
3. 商品コードとの完全一致を先に確認する。
4. トークン化と形態・綴りの変形を適用する。
5. 運営者が管理する同義語とカテゴリ辞書を拡張する。
6. テキスト検索で候補を探す。
7. 必要なら意味検索を補助候補生成に使う。
8. 販売・公開・規制状態をフィルタリングする。
9. オーガニックスコアを計算し、広告を別途結合する。
10. 結果と診断情報を返す。

生成AIやベクトル検索を導入する場合でも、SKU、ブランド、モデル名のような完全一致を弱めてはいけない。ショッピング検索では、正確検索 + テキスト関連度 + 選択的な意味検索を組み合わせたハイブリッド方式が一般的に安全だ。AIがカタログにない商品、価格、在庫を作り上げて話さないように、すべての応答を実際の商品IDと現在データにつなぐ必要がある。

結果なし画面は第二の陳列棚である

検索結果がない時、空画面だけを見せてはいけない。ただし、関連のない人気商品を検索結果であるかのように混ぜてもいけない。

推奨構成は次のとおりだ。

• ユーザーが入力した検索語をそのまま見せ、一致商品がないことを明確に案内
• 誤字修正候補と同義語提案
• フィルターによって0件になった場合、削除可能なフィルターを案内
• 範囲を広げた結果を別ラベルで提示
• 関連カテゴリ、代替商品、全体人気商品を区分して露出
• 再入荷・入店リクエストまたはカスタマーセンターへの接続
• 結果のない検索イベントを管理者分析に記録

「結果なし」と「フィルター適用後なし」は別の問題だ。元の候補はあったが価格・色フィルターで0件になった場合はフィルター緩和が最も有用で、カタログ自体に商品がないなら調達データとして活用すべきだ。

5. 検索履歴：市場調査データと個人情報を一緒に管理する

結果のない検索語は、顧客が探したが購入できなかった需要を示す。人気検索語は陳列と在庫計画に役立ち、検索後のクリック・カート・購入フローは検索品質を評価する核心指標になる。

しかし「検索語と回数だけ保存すれば常に個人情報ではない」と断定することはできない。検索語自体に電話番号、注文番号、名前、健康・宗教・性生活のような敏感な内容が入ることがあり、アカウント・IP・機器情報と結合されると個人を識別または追跡する可能性が大きくなる。

推奨収集項目

ハッシュ化された会員IDも自動的に匿名情報になるわけではない。再び特定ユーザーと結び付けられるなら、仮名情報または個人情報として扱わなければならない。保管期間も一律に定めず、目的、分析周期、セキュリティリスクを基準に原文と集計データそれぞれに設定する。

管理者ダッシュボードに必要な指標

• 検索量と固有検索語数
• 結果なし比率
• 検索結果クリック率
• 検索後カート率と購入コンバージョン率
• 検索語修正率とフィルター解除率
• 品切れ商品露出比率
• 上位結果の集中度とブランド多様性
• 広告とオーガニック結果の成果を分離した指標
• 検索インデックスの鮮度およびインデックス失敗件数

低頻度の原文検索語は個人情報が含まれる可能性があるため、最小集計基準を超えた項目だけを運営者画面に露出する方法も有用だ。

実践プロンプト：ポリシーをコードに変換する方法

開発用語を多く使うより、運用ルールを明確に書くことが重要だ。次のテンプレートをサービス状況に合わせて埋め、AIに提供できる。

私たちのショッピングモールの商品検索機能を設計して実装して。

1. 露出資格
- 販売中で公開状態であり、規制ブロックがない商品のみ検索候補に含める。
- 一時品切れは表示するが、同一条件の在庫商品より後ろに送る。
- 販売終了と一時販売停止は検索・カテゴリで隠す。
- 販売終了商品の直接URLには終了案内と代替商品を見せ、購入ボタンは削除する。

2. 基本並び替え
- 検索語関連度を最も大きく反映する。
- 直近28日のコンバージョン率、直近14日の販売速度、補正評価、配送品質を反映する。
- 各重みは設定ファイルまたは管理者ポリシーで変更可能にする。
- 同点はproduct_id降順で安定的に並べ替える。
- 広告商品はオーガニックスコアに混ぜず、別スロットに入れて「広告」と表示する。

3. 一覧探索
- 一度に40個ずつ返す。
- 検索語、並び替え、フィルター、ページまたはカーソルをURLから復元できるようにする。
- 詳細ページから戻ると、一覧とスクロール位置を復元する。
- 大規模結果はカーソルページネーションを使用する。

4. 検索範囲
- SKUとモデル名の完全一致を最優先にする。
- 商品名、ブランド、カテゴリ、属性、同義語タグを検索する。
- 韓国語の分かち書きと英語・ハングルのブランド表記ゆれを処理する。
- 結果がなければ、誤字提案、フィルター緩和、関連カテゴリ、代替おすすめを区分して見せる。

5. 検索ログ
- 正規化検索語、時間区間、結果数、フィルター、集計クリック・購入指標だけを基本保存する。
- 会員IDとIPは検索分析ログに保存しない。
- メール、電話番号、注文番号の形式はマスキングする。
- 原文保管期間と集計保管期間を設定値として分離する。

6. 技術要件
- データモデル、API契約、検索インデックス、同期方式、例外処理、管理者指標を一緒に設計する。
- 実際の照会パターンに合うインデックスを提案し、実行計画の確認方法を説明する。
- 検索インデックス遅延状況でも、カートと決済段階で状態・価格・在庫を再検証する。
- 単体テスト、統合テスト、性能テスト、アクセシビリティテストのシナリオを作成する。

実装を始める前に、私が決めていないポリシーのうち結果に影響する決定があれば先に質問し、任意に決めた仮定は別リストで表示して。

最後の文は、AIを単純なコード生成器から要件検討パートナーへ変える核心的な仕掛けだ。ただし質問を受けるだけで終わらせず、確定した答えをポリシー文書とテスト条件に反映しなければならない。

実装設計：ポリシーをデータとAPIに固定する

データモデル例

products
- product_id
- sales_status
- stock_status
- visibility_status
- compliance_status
- brand_id
- category_id
- searchable_name
- search_tags
- price
- inventory_quantity
- ranking_feature_version
- updated_at

一つのフィールドに複数の意味を入れない。たとえばstatus = 1だけを置くと、販売可能、公開可能、在庫あり、規制通過のうち何を意味するのか分からない。状態遷移も表で管理し、下書きから販売中へ、販売中から終了へ移動する時に必要な検収とイベントを定義する。

API応答に含める情報

• 正規化された検索語
• 適用された並び替えとフィルター
• 結果群と次カーソル
• 結果数または概算結果数
• 品切れ・販売状態バッジ
• 広告 여부と広告表示文言
• 誤字修正・検索範囲拡大の有無
• 検索ポリシーバージョンと追跡用リクエストID

内部デバッグ情報である生スコアと事業上敏感な重みを顧客APIにそのまま露出する必要はない。その代わり、運営者がリクエストIDで順位算定経路を再現できなければならない。

インデックスは実際の照会パターンに合わせて設計する

一般的に、状態フィルターと並び替えに使う列にはB-tree系インデックスを、全文検索文書には転置インデックス系を検討する。PostgreSQLならtsvectorとGINインデックス、類似文字列検索が必要ならpg_trgmを使用できる。外部検索エンジンを使っても原則は同じだ。

CREATE INDEX idx_products_visibility
ON products (visibility_status, sales_status, compliance_status);

CREATE INDEX idx_products_search_document
ON products USING GIN (search_document);

インデックスを多く作るほど書き込みコストと保存領域も増える。予想だけで決めず、実際のクエリとデータ分布でEXPLAIN ANALYZE、スロークエリログ、負荷テストを確認する。商品数が増える時は、平均応答時間よりp95・p99遅延、タイムアウト率、インデックスの鮮度を一緒に見る。

生成AIを付ける時に追加する安全装置

• 商品の存在有無、価格、在庫、配送日はカタログAPI結果のみ使用
• モデルが作った検索語拡張は原文とともに記録し、過度な拡張を制限
• 正確なSKU・モデル名検索は意味検索より優先
• 販売停止・リコールフィルターはAI検索候補にも同一に適用
• 回答に露出した商品IDと根拠フィールドを追跡
• モデル失敗時は一般テキスト検索へフォールバック
• プロンプト注入性の文言が商品説明やレビューにあっても、システム指示として実行しないよう分離

リリース前の受け入れテスト

運用段階で繰り返すべきこと

検索は一度開発して終わる機能ではない。商品構成、季節、プロモーション、顧客表現が変わるため、次の周期を運用プロセスとして置く。

1. 毎週、結果のない検索語と急増検索語を検討する。
2. 同義語とカテゴリマッピングを承認手続きで更新する。
3. 品切れ露出率、クリック率、コンバージョン率、検索語修正率を一緒に見る。
4. 重み変更はオフライン評価と限定的なA/Bテスト後に拡大する。
5. 広告・自社商品・オーガニック結果の露出比率を別途監査する。
6. 検索ログの保管期間、アクセス権限、マスキング失敗を定期点検する。
7. 実際のトラフィックでインデックス使用率と遅いクエリを再検討する。

結論

AIは検索APIと画面を素早く作ることができるが、どの商品に顧客の前に立つ資格があるのかは決められない。実戦型ショッピングモール検索は、並び替えの基本値、商品状態、一覧探索、検索範囲と結果なし処理、検索ログを先にポリシーとして確定し、そのポリシーをデータモデル、API、インデックス、テスト、管理者指標に一貫して反映した時に完成する。

コーディングは自動化できても、陳列原則と責任は自動では生まれない。最も良いAIプロンプトは長く難しい開発用語ではなく、運営者がすでに決めたポリシーと、まだ決めていない質問を明確に区分した文書である。