「検索」で顧客を門前払いしていませんか？ BigTechで特色ある「あいまい検索」をGoogleのような、airbnbのような、それぞれのUX戦略を紐解いてきます。脱・SQL宣言

あなたのサイトの検索機能がこれなら、それは「接客拒否」をしているのと同じです。
Googleで検索する時、多少のスペルミスをしても「もしかして：〇〇」と正しい結果を出してくれます。
Airbnbで宿を探す時、選んでいる最中から候補地がサクサク出てきます。

ユーザーはこの体験に慣れきっています。
それなのに、自社のシステムだけが「完全一致しないと表示しない」という昭和のSQL検索を続けていれば、顧客は黙って去っていきます。

本記事では、データベース（SQL）での検索を卒業し、Algolia や Elasticsearch (OpenSearch) を導入して、「タイプミスすら許容する、シリコンバレー標準の検索体験」を構築する手法を解説します。

---

第1章：なぜ SQL の LIKE 検索はダメなのか？

多くのエンジニアは、手っ取り早いからとデータベース（PostgreSQLやMySQL）の標準機能で検索を作ります。
しかし、これには致命的な欠陥があります。

1. 「あいまいさ」に弱い (Typos)

• SQL: iPhone を ipone と打つと、1文字違うだけでヒットしません。コンピュータは融通が利かないからです。
• モダン検索: 「人間の記憶は曖昧である」という前提で作られています。1〜2文字の間違いなら「これですよね？」とiPhoneを表示します。

2. 「重さ」と「遅さ」 (Performance)

• SQL: データが10万件を超えると、文字検索（全文検索）は急激に重くなります。検索のたびにDB全体を走査し、CPUを食いつぶすからです。
• モダン検索: 検索専用エンジンは、あらかじめ「索引（インデックス）」を作っているため、数百万件あっても 0.01秒 で結果を返します。

---

第2章：実装の裏側（マネジメント層向け解説）

では、Airbnbのような検索は、裏側でどのような処理を行っているのでしょうか？
単にツールを入れるだけでなく、エンジニアは以下のような「ロジックの組み立て」を行っています。

Step 1. データの「即時同期」パイプライン

検索エンジンは、データベースとは別の場所にあります。 そのため、商品データが更新されたら、瞬時に検索エンジン側にもコピーする必要があります。

【実装イメージ】

1. 管理画面で商品価格を「1,000円」から「900円」に変更する。
2. 保存した瞬間、AWS Lambda（関数） が自動起動。
3. 変更内容を Algolia API に送信し、検索用データを更新する。

この仕組み（イベント駆動）により、ユーザーは常に最新の価格で検索できます。
フィルターの中からキッチン、テレビなどを選択したときもそう。

Step 2. 「ビジネスルール」のコード化

ここが最も重要です。検索順位は「運」ではなく「設計」で決まります。 Algoliaなどのエンジンには、以下のようなランキング設定（Ranking Formula）をコードとして実装します。

JavaScript

// エンジニアが設定する「検索順位のルール」
index.setSettings({
  customRanking: [
    'desc(is_in_stock)',  // 1. 在庫があるものを最優先
    'desc(profit_margin)',// 2. 利益率が高い順
    'desc(popularity)',   // 3. 人気ランキング順
    'asc(publish_date)'   // 4. 新着順
  ],
  searchableAttributes: [
    'product_name',       // 商品名は重要度：高
    'category',           // カテゴリ名は重要度：中
    'description'         // 説明文は重要度：低
  ]
});

マネジメント層への翻訳:

「ただキーワードが一致するだけでなく、『在庫があり、かつ利益率が高く、人気がある商品』を上位に表示するようにプログラミングしています。 つまり、検索エンジンの中に優秀な営業マンの脳みそを実装しているのです。」

Step 3. 「タイポ許容度」のチューニング

「どこまでの間違いを許すか」も調整します。

• typoTolerance: 'min' : 1文字の間違いまで許す（例: aplle → apple）
• synonyms: true : 同義語を登録する（例: 「ズボン」と検索しても「パンツ」の商品を出す）

このように、エンジニアは単にデータを出すだけでなく、「ユーザーの意図を汲み取るロジック」を実装しています。

---

第3章：ビジネスへのインパクト（ROI）

「検索機能を変えるだけで、売上が上がるのか？」 答えはYESです。

1. 「0件ヒット」の撲滅
   • 検索結果が0件だった時の離脱率は極めて高いです。「あいまい検索」を入れるだけで、機会損失を最小限に抑えられます。
2. コンバージョン率 (CVR) の向上
   • 前述の「ビジネスルール（在庫あり・利益率重視）」を反映させることで、ユーザーが「欲しい」と思い、かつ「自社が売りたい」商品への到達率が劇的に上がります。
3. 業務効率化
   • 社内システムにおいて、「あのドキュメントどこだっけ？」と探している時間は完全なコストです。Google並みの検索精度があれば、社員1人あたり毎日10分の時短になります。

---

まとめ：検索窓は「コンシェルジュ」であるべき

SQLの LIKE 検索は、ただの「文字照合ロボット」です。 対して、AlgoliaやOpenSearchによる検索は、ユーザーの意図を汲み取り、ビジネスルールに従って商品を提案する「コンシェルジュ」です。

• データの即時同期
• 利益率を加味したランキング
• 同義語やタイポの吸収

これらを実装することで、あなたのサイトの検索窓は、最強のセールスマンへと生まれ変わります。
「速さ（Amazon）」
「動画（Netflix）」ときて、
次は「検索（Airbnb/Google）」の体験を取り入れましょう。

最近では、Airbnbは、UXの改善として進化させています。
フィルターも検索から選ぶという動作のみのUIへ。今まで、あいまい検索などで蓄積していったデータをもとに、UI化をすすめより、早く顧客にマッチするものへと。

このように、BigTechは、常に進化し続けているのです。
マネできるところは、マイクロサービス化して設計、導入していきましょう。

---

👇 【基盤】検索結果を「0秒」で出すために

:::info 【インフラ】Amazonはなぜ「0秒」で切り替わるのか？

検索結果が表示されるまでの「待ち時間」を極限まで削るには、フロントエンド側での「プリフェッチ」技術も有効です。

👉 記事を読む：知覚パフォーマンスと3つの実装パターン

:::

👇 【データ】DBから検索エンジンへどう同期する？

:::info 【AWS】F5不要！Uberのような「リアルタイム」同期

DBが更新された瞬間に検索エンジン側のデータも更新するには、AppSyncやEventBridgeなどのイベント駆動アーキテクチャが役立ちます。

👉 記事を読む：AWS AppSyncによるリアルタイム基盤 :::

---

👉 記事を書いた人