旅行購入者が求めるスピードで、リアルタイムの在庫検索を実現します。
エンジニアリング課題
旅行業界において、検索応答に2秒かかることは、単なるユーザー体験の問題ではありません。収益に直結する課題です。応答速度が1秒遅れるごとに、コンバージョン率は明確な数値で低下します。特に、セッション離脱率が高く、競合サイトへの切り替えが容易な旅行業界では、この損失は急速に拡大します。この問題は、サービス開始時ではなく、規模が拡大するにつれて顕在化します。10万件のリスティングでは適切に機能していたプラットフォームも、100万件に達すると負荷がかかり始め、初期段階では許容できたアーキテクチャ上の決定が、成長の天井を定める制約となってしまうのです。
ここでは、2つの障害モードが同時に発生します。一つは、ユーザーに届くまでに情報が古くなり、30秒前に予約済みとなった在庫を表示してしまう空き状況応答です。もう一つは、利用可能な結果ではなく、全カタログに対してファセットフィルターが適用され、購入者を「行き止まり」に導いてしまう問題です。これらはいずれもデータ品質の問題ではなく、アーキテクチャの問題です。
検索アーキテクチャ
本番環境レベルの旅行検索の基盤は、インデックスを追加したリレーショナルデータベースではなく、専用の検索エンジンです。ElasticsearchやOpenSearchが標準的な選択肢ですが、どの製品を選ぶかよりも、その上に構築されるインデックス設計の方が重要です。旅行在庫の場合、適切に設計されたインデックスは、場所、日付範囲、収容人数、料金体系、アメニティセット、評価、空き状況期間をカバーする多属性ドキュメントを、プラットフォーム固有のクエリパターンをサポートする構造でエンコードします。優れたインデックス設計と平凡な設計との違いは、100万件のリスティングで顕在化し、1500万件では決定的な差となります。フィールド選択、アナライザー設定、シャード戦略が、ピーク負荷時における500ミリ秒未満のP99レイテンシー達成の可否を決定します。
物件の重複排除とレコードマッチング
旅行検索において最も過小評価されがちなエンジニアリング課題の一つが、重複排除です。これは、同じホテル、ヴィラ、または物件が、異なるサプライヤーから異なる識別子、異なる名称、異なるデータモデルで提供されるため、検索結果に複数回表示されてしまう問題です。
一つの物件が、OTAチャネルマネージャー、ホテル直販API、GDSフィード、ベッドバンクなど、複数の経路からプラットフォームの在庫に登録されることがあります。それぞれが異なる物件ID、わずかに異なる住所、そして完全に一致しない可能性のある名称を持っています。重複排除レイヤーがない場合、ユーザーは同じ物件が4つの異なる価格で4回表示され、それらが同じ部屋であるという認識なしに見てしまうことになります。結果として、コンバージョン率は低下し、サプライヤーからの信頼も失われます。プラットフォームは信頼性に欠けるものと見なされてしまうでしょう。
この問題を解決するための業界標準はGIATAです。GIATAはドイツの企業で、世界中の75万件以上のホテル物件をカバーするマスター物件データベースを維持しており、各物件には流通チャネル全体で永続する一意のGIATA IDが割り当てられています。流入するサプライヤー在庫をGIATA IDにマッピングすることで、プラットフォームは異なるフィードからの同じ物件を単一の正規レコードに統合し、重複を表示する代わりに、そのレコードに対して複数のサプライヤー価格を表示できるようになります。Gradionは、GIATAとの連携および、流入する在庫をクリーンな物件グラフに正規化する重複排除パイプラインを構築します。これには、正規レコードの作成、複数のソースからの属性マージ、サプライヤー間で部屋数やアメニティデータが異なる場合の競合解決、そしてマスターレコードが変更された際の下流インデックス更新伝播が含まれます。
ライセンス費用、または在庫タイプ(賃貸物件、プライベートヴィラ、アクティビティ会場など)がデータベースで十分にカバーされていないといった理由でGIATAを利用できないプラットフォーム向けに、Gradionは確率的マッチングパイプラインを構築します。これは、名称の類似性、地理座標の近接性、属性の重複を利用して重複候補をクラスタリングし、信頼度スコアリングレイヤーと、信頼度の低いマッチングに対する手動レビューキューを備えています。エンジニアリング上の課題は「再現率」です。ほとんどの場合、重複を見逃すことは誤検知よりも悪影響を及ぼします。なぜなら、ユーザーがそれを見つけ、プラットフォームへの信頼を低下させるからです。
リアルタイム空き状況
旅行業界の在庫状況は常に変動します。予約の同時発生、保留期間の満了、パートナーフィードの非同期更新など、その変化は多岐にわたります。アーキテクチャ上の課題は、リアルタイムな状態を反映することの是非ではなく、遅延の大きい外部システムへの同期呼び出しを伴わずに、いかにこれを実現するかという点にあります。
大規模プラットフォームにおける現実的な解決策は、ハイブリッド型アプローチです。検索レイヤーは、予約、キャンセル、保留期間満了といったイベントストリームを通じて更新される可用性インデックスを基盤とし、一方、チェックアウトプロセスでは予約確定前にリアルタイムの在庫確認を行います。HomeToGoは、100を超えるパートナーAPIと25の市場にわたる1,500万件以上のリスティングで可用性を調整しています。ここでのエンジニアリング課題は、更新頻度、データ形式、信頼性特性がそれぞれ異なる多様なソースからの状態を、検索クエリが信頼できる一貫した内部モデルへと同期させることです。このデータを正規化する統合レイヤーは、検索エンジン本体と同等のエンジニアリング工数を要する重要な要素です。
キャッシュ戦略
旅行検索の応答に含まれるすべての情報が、同じ揮発性を持つわけではありません。静的属性、アメニティリスト、位置情報、過去の価格パターンなどは、適切なTTL(Time-to-Live)を設定してキャッシュ可能です。しかし、リアルタイムの可用性にはこれが適用できません。この境界設定を誤ると、双方に問題が生じます。過度なキャッシュは、利用できない在庫を表示してユーザーの信頼を損ないます。一方、キャッシュ不足は検索の応答速度を低下させます。予約イベント発生時のキャッシュ無効化は、保留中または確定済みのすべての在庫に対して必須です。キャッシュに何を保持し、どのTTLを設定し、何が無効化をトリガーするかという設計は、単なる詳細ではなく、システム全体の正確性を担保する上で不可欠な制約となります。
ファセット検索とフィルタリング
クエリ時に利用可能な在庫を正確に反映するファセットフィルターは、ユーザーが実際に予約可能な件数を示すために、全カタログではなく、フィルターされた結果セット全体での集計を必要とします。これをフルテーブルスキャンなしで実現するには、検索エンジンの集計機能を慎重に活用するか、カウント精度よりも速度が優先される場合には近似手法を適用します。フィルターの適用に応じて値の範囲やカウントが更新される動的ファセットは、クエリ構築と応答速度にさらなる要求を課します。専門的なフィルタリング要件は、コンテンツレイヤーへの追加投資を不可欠とします。例えば、イスラム教徒向けの旅行プラットフォームでは、ハラール認証、礼拝施設、アルコールポリシーといった属性をフィルター可能にする必要があります。これは、これらの属性が信頼性の高いフィルターオプションとして提供される前に、在庫データ内で一貫して存在し、かつ検証されていることを意味します。Gradionは、専門的なフィルタリングを単に技術的に実装するだけでなく、その信頼性を確保するためのコンテンツエンリッチメントパイプラインを構築しています。
関連性ランキングとGDS統合
旅行検索のランキングにおいて、キーワードの関連性はあくまで最低限の基準であり、最終的な目標ではありません。多信号ランキングでは、価格競争力、可用性の確実性、物件や市場セグメントごとの過去のコンバージョン率、そしてユーザーの意図する地理的近接性など、複数の要素を統合します。さらに、予約コンバージョンデータで学習された機械学習による再ランキングは、規模の拡大とともに精度が向上するパーソナライゼーションレイヤーを追加します。グローバル流通システム(GDS)から在庫を調達するプラットフォームの場合、可用性パイプラインは、Amadeus、Sabre、TravelportといったGDSフィードに加え、直接チャネルマネージャーAPIにも接続します。各ソースは独自のデータモデル、更新頻度、信頼性プロファイルを持つため、一貫した内部可用性モデルへの正規化は、整合性の取れた検索結果を提供するための必須要件です。ソーススキーマの進化に伴い、多くの統合において正確性の問題が時間とともに蓄積されやすいのが、このマッピングレイヤーです。
地理空間検索
旅行関連の検索において、位置情報は主要な軸となります。OpenSearchやElasticsearchは、地図表示検索用のバウンディングボックスクエリ、近接フィルタリング用の半径クエリ、目的地エリア検索用のポリゴンクエリなど、ネイティブな地理空間クエリをサポートしています。宿泊施設やアクティビティのプラットフォームでは、地理空間フィルタリングと空室状況・属性フィルタを単一クエリで組み合わせることが一般的です。これを適切に実装することで、クエリ遅延への影響を最小限に抑え、高いパフォーマンスを維持できます。
本番環境での実証
KAYAKは、60の市場で年間20億件以上の消費者クエリを処理する、世界最大の旅行検索プラットフォームです。Gradion(NFQが代表)は、10年以上にわたりKAYAKの製品開発に深く関わり、高性能エンジニアリングチームを構築・運用しました。このチームは、KAYAKの規模に対応するコア検索および空室状況インフラストラクチャを担当しました。具体的には、複数サプライヤーの集約、多様なフィードソースからのリアルタイム空室状況の正規化、年間数十億件のクエリに対する関連性ランキング、そして航空券・宿泊施設のメタ検索に不可欠な低遅延化技術の実現です。2018年には、KAYAKがこれらのエンジニア約40名をKAYAKリトアニアに直接アクイハイヤーしました。これは、当社のチームが外部ベンダーではなく、KAYAK社内のエンジニアリング基準で業務を遂行していたことの明確な証拠です。
HomeToGoは、1,500万件以上のリスティング、60,000社を超える信頼できるパートナー、25カ国での事業展開を誇る世界最大のバケーションレンタルマーケットプレイスです。Gradion(NFQが代表)は、4つの拠点に最大150名のエンジニアチームを提供しました。このチームは、100以上のパートナーAPIを統合した統一空室状況モデルを持つシステムにおいて、1日あたり50回以上の本番環境へのデプロイ、100件以上の同時A/Bテスト、そして99.99%の稼働率を実現しました。多様なソースから1,500万件のリスティングを集約する際の重複排除と正規化の課題は、大規模な物件マッチングに求められる要件を明確に示しています。
roadsurfer: 20日間でプラットフォームを全面再構築し、8言語、7通貨に対応。ローンチ後1年以内に予約数と収益を倍増させました。
CTA
貴社の在庫規模、クエリパターン、現在のパフォーマンス制約についてお聞かせください。それに基づき、最適な検索アーキテクチャを策定いたします。
年間20億件のクエリ、60市場
KAYAKは60市場で年間20億件を超える消費者クエリを処理しています。Gradionは10年以上にわたり、KAYAKに常駐する高性能エンジニアリングチームを運営し、その成長を支えました。