Drupalの標準検索で足りる条件と、外部サイト内検索サービスを検討する分岐点

Drupalの標準検索は、一致率のスコア順で並ぶ

なお、本記事ではDrupalコアが標準で提供する検索機能を前提として説明します。Search APIのような拡張モジュールを利用する場合は、並び順の制御に関して異なる選択肢が生じます。

Drupalでコーポレートサイトを構築した案件では、サイト内検索にDrupal側の標準的な全文検索の仕組みを採用しました。挙動としては、検索の仕組みの内部でコンテンツ一件ごとに一致率にあたるスコアが算出され、そのポイントが高い順に結果が並びます。

この仕組みの前提は、キーワードとコンテンツの一致度が高いものほど利用者にとって有用だろうという考え方です。この前提が成り立つサイトであれば、標準の仕組みがそのまま使えます。追加のサービス契約が不要で、CMSの標準機能として最初から利用できるため、公開までの期間も短く済みます。検索窓の設置や検索結果ページの表示もDrupalの標準の仕組みに沿って用意できるため、検索のために別のサービスを契約したり、運用担当者が新しい管理画面の操作を覚えたりする必要もありません。日々の運用で見る画面がCMSひとつに収まる点は、担当者の人数が限られている場合の利点になります。

一方で、次のような要望が出た場合は、標準の並び順とはズレが生じます。

• 特定の製品カテゴリを、検索結果の上位に固定して表示したい
• 検索キーワードに応じて、おすすめのページを最上位に差し込みたい
• 古い情報が上位に来ないよう、公開日の新しさを順位に反映させたい

このズレが許容できる範囲であれば、標準検索のまま進められます。許容できない場合に、外部のサイト内検索サービスを検討する段階に入ります。判断軸は検索機能の有無ではなく、並び順を誰が決めたいかという点にあります。

コンテンツ数が少なければ、標準機能で足りる

前述の案件では、標準検索をそのまま採用しています。理由は、コンテンツ数がそれほど多くなく、検索に重きを置いた要件ではなかったためです。ページ数は100〜200程度、活動内容とお知らせの一覧にはタグによる絞り込みが用意されており、利用者はそちらで目的の情報にたどり着ける構成でした。このサイトの規模では、標準の全文検索であっても検索結果の応答速度や精度に大きな問題は生じませんでした。

サイト内検索への投資判断では、コンテンツ件数と、検索以外の導線が機能しているかが材料になります。件数が限られていて、一覧の絞り込みが整理されているなら、検索は補助的な導線と位置づけ、標準機能を採用する判断も成り立ちます。その場合、検索に充てる想定だった予算は、一覧の絞り込みの作り込みやコンテンツの制作に配分できます。逆に、製品点数が多いサイトや、型番での検索が主要な入口になっているサイトでは、並び順の制御が利用者の行動に影響しやすいため、投資を検討する対象になります。

要件定義の段階では、次の3点を確認しておくと、判断材料が揃い、検討をスムーズに進められます。

• 検索対象となるコンテンツの現在の件数と、3年後の見込み
• 検索以外にどの導線が用意されているか（一覧の絞り込み、カテゴリ階層、サイトマップ）
• 検索結果の並び順について、運用側で制御したい要望があるか

一覧の絞り込みと全文検索は、別の設計項目として扱う

要件定義で混ざりやすいのが、一覧ページの絞り込みとサイト内検索です。利用者から見ればどちらも探す操作ですが、設計上は別の項目として扱う必要があります。

一覧の絞り込みは、あらかじめ用意された分類のなかから選ぶ操作です。選択肢は運用側で管理でき、結果に何が出るかも予測できます。前述の案件では、活動内容一覧とお知らせ一覧にタグによる絞り込みを用意し、この分類をDrupalのタクソノミー機能で管理していました。分類を増やす作業は管理画面で完結します。

一方、全文検索は利用者が任意のキーワードを入力する操作です。何が入力されるかは事前に決められず、結果の並び順もスコアの計算に委ねられます。運用側で調整できるのは、対象範囲の指定と、検索対象になるテキストの整備までです。具体的には、絞り込みの選択肢は管理画面から自由に増やせますが、標準の全文検索では入力されたキーワードごとに順位が変わるため、1件目に出すページを運用側で指定することはできません。

この違いを踏まえると、要件の書き方が変わります。想定される探し方が分類で表現できるなら、一覧の絞り込みを整えるほうが、投資に見合う成果を得やすくなります。型番や固有名詞のように分類で表現しきれない探し方が中心なら、全文検索の精度と並び順が論点になります。どちらの導線を主にするかを先に決めておくと、検索に配分する予算の判断材料が揃います。

検索の要件は、対象範囲・並び順・反映速度の3点で書く

サイト内検索の要件が、「サイト内検索機能を実装する」という一行で書かれていることがあります。これでは実現方法の選定に必要な情報が足りません。最低限、次の3点を書き分けておくと、標準機能で足りるかどうかを早い段階で検討できます。

1. 対象範囲：どのコンテンツを検索対象に含めるか。製品ページ、お知らせ、PDFなどの添付資料、外部サイトのコンテンツをそれぞれ含めるかどうか。ただし、ログイン認証が必要なページや動的に生成されるページはクロール対象外となるサービスが多いため、対象範囲の確定時に制約を確認しておく必要があります。
2. 並び順：既定の並び順を何にするか。一致率のスコア順で許容できるか、公開日順や指定順を必要とするか。特定キーワードに対する優先表示を運用側で設定したいか。
3. 反映速度：ページを公開してから検索結果に表示されるまで、どの程度の時間差を許容できるか。なお、Drupal標準の検索についても、検索インデックスはCronによって定期的に更新される仕組みのため、公開した瞬間に検索結果へ反映されるわけではありません。

このうち2つ目と3つ目が、実現方法の分岐に直結します。並び順を運用側で制御したい場合は外部サービスの検討対象になり、反映速度に厳しい要件がある場合は、標準機能・外部サービスのいずれであっても、インデックスやクロールの更新タイミングとの相性を確認することになります。この3点が揃っていれば、LYZONからは標準機能と外部サービスの両案を、費用と運用の違いを添えてご提示できます。

外部サービスの選定は、製品データの管理元から逆算する

外部のサイト内検索サービスを導入した別案件では、製品点数の多いBtoBサイトで、外部の検索ツールを採用しています。

この案件で特徴的なのは、検索の性能だけが選定理由ではなかった点です。製品側の情報を、同じ提供元が展開するWebカタログ検索のサービスで管理していたという前提がありました。複数のシステムを同一ベンダーで統一するという観点が、選定に影響する場合があります。

サイト内検索の選定は、検索サービスの比較表だけでは決まりません。製品情報やカタログデータをどのシステムで管理しているか、そこからCMSへどう連携しているかという上流の構成が、実質的に選択肢を絞ることがあります。検索を検討する際は、まず製品データの管理元を整理しておくと、比較の対象が現実的な範囲に収まり、選定期間の短縮にもつながります。

外部サービスの導入がスムーズに進む条件

外部サービスを導入する場合、設定作業は順番の決まった流れになります。今回採用した外部の検索ツールの場合は次のとおりです（本記事執筆時点の手順であり、最新の情報は提供元の公式ドキュメントでご確認ください）。

1. 管理画面上でアプリケーションを作成する
2. そのアプリケーションの中にサービスを作成する
3. サービスに紐づく検索データベースを作成する
4. クローラーを作成し、これらを紐づける
5. クロールの実行時間と、検索データベースを生成する時間を設定する
6. 発行されたタグをコピーし、検索窓と検索結果ページに埋め込む
7. カテゴリの設定を管理画面上で行う

このように手順が決まっているサービスは、導入の見通しが立てやすく、公開までの期間も読みやすくなります。前述の案件では、マニュアルが整理されており、不明点を問い合わせれば回答が得られる体制があったため、設定は手順に沿って進められました。外部サービスの選定では機能比較に目が向きやすいものの、ドキュメントの整備状況とサポートの応答性は、導入期間と費用の見通しに関わる評価項目です。ご検討の際は、この2点も比較の観点に加えてご確認ください。

なお、この設定手順はLYZON側で手順書として整備しています。順番の決まった作業を一度手順化しておけば、担当者が変わっても同じ手順で進められます。標準化の対象として扱いやすい領域です。

検索を外部に寄せたとき、CMS側に残る役割

外部サービスに検索を寄せると、検索結果の生成は外部サービス側が担います。一方で、CMS側には次の役割が残ります。

• クロール対象となるページを、正しく公開状態で提供すること
• ページのタイトルや説明文など、検索結果に表示される情報を整えること
• 検索窓と検索結果ページにタグを埋め込み、その状態を維持すること
• 新しいページを公開してから検索結果に反映されるまでの時間差を、運用として見込んでおくこと

最後の項目は、公開直後に検索でヒットしないというお問い合わせにつながることのある点です。クロールと検索データベースの生成は設定した時間に実行されるため、公開してすぐに検索結果へ反映されるわけではありません。クロールの設定によっては、数時間から1日程度の時間差が生じることがあります。この時間差を運用フローの前提として関係者に周知しておくと、公開後の確認作業での行き違いを減らしやすくなります。プレスリリースのように公開直後の到達が重要なページについて、トップページからの導線を別に用意しておくかどうかも、事前に手当てしておける項目です。

また、検索を外部に寄せても、製品データの整合性はCMSまたは上流のシステム側に残ります。同じ製品情報が複数の場所に存在する構成では、どちらを正としてどちらへ流すのかを、検索の導入とあわせて確認しておくことをおすすめします。