検索の精度は移管で静かに劣化する

2026年9月11日(金)

サイト内検索のシノニム辞書・形態素解析のユーザー辞書・ランキングの重み付け・除外ルールは、何年もの運用で1行ずつ育てられた事業資産でありながら、コードにも仕様書にも残らず管理画面の中だけに存在することが多い。移管でインデックスを張り直すとデータは全件揃うのに検索結果の質だけが巻き戻り、エラーもアラートも出ないためCVRが落ちる数週間後まで発覚しない。買い手は辞書と設定の現物をファイルとして要求し、それがリポジトリで管理されているかを確認する必要がある。

「検索順位が落ちた」という話ではありません。この記事で扱うのは、サイトの中に置かれている、あの小さな検索窓のほうです。Googleの検索結果ではなく、自社サイトの内側でユーザーが叩く検索。ECなら商品検索、SaaSならアプリ内検索、メディアなら記事検索。あれの話です。

M&Aの移管作業で、この検索窓が静かに劣化する事故が繰り返し起きています。厄介なのは「壊れる」という言葉が正確ではないことで、検索は移管後もちゃんと動きます。クエリを投げれば結果は返る。エラーも出ない。レスポンスタイムはむしろ速くなっていることさえあります（後述しますが、これにはちゃんとした理由があります）。監視は全部グリーンです。

ただ、返ってくる結果の質だけが、数年前に巻き戻っている。

この記事では、なぜインデックスを張り直すだけで検索の精度が劣化するのか、その劣化がなぜ誰にも気づかれないまま数週間走り続けるのか、そして買い手が引き渡しの現場で何を現物として要求すべきかを、順に整理していきます。

検索は「データ」ではなく「チューニング」でできている

まず、検索エンジンというものをM&Aの目線で分解しておきます。

Elasticsearch でも Algolia でも Meilisearch でも、サイト内検索の実体は大きく2つの層に分かれています。ひとつはデータ。商品名、説明文、価格、カテゴリ、記事本文。これらは元をたどれば全部データベースの中にあります。もうひとつがチューニングです。そのデータをどう分解し、どう索引を張り、どの語とどの語を同じ意味とみなし、何を上に出し、何を隠すか。

移管で引き継がれるのは、ほぼ確実に前者だけです。

データベースは丸ごとダンプして渡せます。コードはリポジトリごと渡せます。では、チューニングはどこにあるのか。ここが本題で、チューニングの実体は管理画面の中にしかないことが非常に多い。SaaS型の検索なら向こうのダッシュボード、自前の Elasticsearch ならインデックスの設定として本番クラスタの中。どちらにせよ、リポジトリを grep しても出てきません。

買い手のエンジニアがリポジトリを開いて目にするのは、だいたいこういう1行です。

const results = await searchClient.search(query);

これだけです。この1行の向こう側に何年分の調整が積み上がっているのかは、コードのどこにも書かれていません。

シノニム辞書は、苦情が来るたびに1行ずつ足してきたもの

チューニングの中で、最も価値が高く、最も失われやすいのがシノニム（同義語）辞書です。

アパレルのECを想像してください。ユーザーは「ワイシャツ」で検索します。「Yシャツ」でも検索します。「カッターシャツ」でも来ます。商品データベースに登録されている正式名称は「ドレスシャツ」かもしれません。この4語を結びつけているのは商品データではありません。シノニム辞書です。

そして、この辞書がどうやって作られたかを考えてみてください。最初から全部書けた人はいません。「カッターシャツで検索したら0件だった」という問い合わせが来て、担当者が1行足した。ゼロ件ヒットのクエリログを月次で眺めて、件数の多かった語を1行足した。新しいカテゴリを増やしたときに、想定される呼び方を1行足した。その積み重ねが、数年かけて数百行、数千行になっている。

これは設定ファイルの見た目をしていますが、正体はユーザーの語彙を数年かけて記録した事業資産です。競合が金を出しても買えない類のもので、しかもExcelにもNotionにも仕様書にも残っていない。管理画面の中にだけ、ひっそりと存在しています。

日本語の検索は、辞書を失うと単語の切れ目から壊れる

日本語のサイトには、もう一段の罠があります。

日本語には単語の区切りにスペースがありません。だから検索エンジンは、文章を単語に分解する処理（形態素解析）を必ず通します。Elasticsearch なら kuromoji がその役目を担っています。

問題は、標準の辞書が知っているのは一般名詞までだということです。あなたの事業の固有名詞は知りません。自社ブランド名、独自の商品シリーズ名、業界の専門用語。これらは標準辞書に載っていないので、解析器は容赦なく分解します。

だから運用の中でユーザー辞書を育てます。「この語はこれ以上分解しないでくれ」「この語はこう読む」という指示を、固有名詞が増えるたびに追加していく。これも数年分の蓄積になります。

このユーザー辞書を持たないままインデックスを張り直すと、何が起きるか。ブランド名が意味不明な位置で真っ二つになります。ユーザーが自社ブランド名で検索しているのに、まったく関係のない商品が上位に並ぶ。一番買う気のあるユーザーが、一番ひどい検索体験をするという、笑えない状態が完成します。

さらに厄介なのは、Elasticsearch では analyzer 周りの設定にインデックス作成時にしか指定できない項目があることです。つまり「あとで直せばいい」が通用しない。mapping を保存せずにインデックスを消してしまった時点で、設計のほうが失われています。手元に残っているのはデータだけで、そのデータをどう読むかという知識が消えている。

移管の翌日、すべての監視がグリーンのまま質だけが落ちる

ここまでを踏まえて、移管当日に何が起きるかを追ってみます。

新しいアカウントを作り、新しいインデックスを作り、データベースから全件を流し込む。データは1件残らず入っています。件数を数えれば旧環境と完全に一致します。検索窓に文字を打てば、ちゃんと結果が返ってきます。

ここが、この事故の一番いやらしいところです。検証できる項目が、全部パスしてしまう。

ドキュメント件数: 旧環境と一致
検索APIの疎通: 正常
エラーレート: 0%
レスポンスタイム: 改善

最後の項目は皮肉です。シノニム展開もユーザー辞書もランキングの再計算も無くなったのだから、検索は速くなって当たり前なのです。チューニングを全部失った検索エンジンは、健康診断の数値だけは過去最高になる。

引き渡しのチェックリストに「検索が動くこと」と書いてあれば、それは間違いなくチェックが付きます。動いていますから。誰も嘘をついていない。それでも、返ってくる結果の質だけが、辞書を書き始める前の日まで巻き戻っています。

アラートは鳴りません。鳴らす対象がないからです。検索の精度を監視している事業は、控えめに言ってもほとんど存在しません。

気づくのは数週間後、しかも外部要因のせいにされる

では、いつ気づくのか。

順序はだいたい決まっています。まずCVRが下がります。ただし劇的にではなく、数パーセント。日次で見ればノイズに埋もれる程度です。週次で見て「ちょっと悪いですね」と言われ、月次で見て初めて「これは下がっている」と認識される。

ここまでで、早くて3週間、普通は1ヶ月半かかります。

そしてその1ヶ月半の間に、他の変数が山ほど動いています。季節性、広告の出稿量、競合のセール、価格改定、そしてGoogleのコアアップデート。ここで多くのチームが最初に疑うのは外部要因のほうです。順位を確認し、アナリティクスを掘り、広告代理店に連絡する。サイト内検索の結果が劣化しているという仮説は、候補リストの最後の最後まで出てきません。

（念のため繰り返しますが、この記事はコアアップデートの話ではありません。ただ、移管直後の売上低下がコアアップデートのせいにされて、本当の原因が数ヶ月放置されるという構図は、実際に起きています。外部要因は便利なので、みんなそこで探すのをやめてしまうのです。）

そして時間が経つほど、切り分けは難しくなります。移管の直後なら「移管で何か変わったのでは」という仮説がまだ立ちますが、2ヶ月も経つと移管は「もう終わったこと」として記憶の後ろに下がっている。旧環境はとっくに解約されていて、比較対象そのものが消えている。正解を持っていた環境を自分の手で消してから、正解を探し始めることになります。

これは引き渡し後の事故の典型的な形です。落ちるならその場で派手に落ちてくれたほうが、まだ親切なのです。

検索の劣化は、必ず別の指標の顔をして現れる

「検索の精度が少し落ちたくらいで」と思われるかもしれないので、検索窓が事業のどこに刺さっているかを確認しておきます。

ECにおいて、検索窓を使うユーザーは買う気が決まっているユーザーです。カテゴリを回遊している人は「見ている」人ですが、検索窓に商品名を打ち込む人は「買いに来た」人です。この層に0件ヒットを返すというのは、レジまで来た客に「その商品は置いていません」と言うのと同じことをしています（倉庫にはちゃんとあるのに、です）。

SaaSでも構造は同じです。アプリ内検索が効かなくなると、ユーザーは自力で目的にたどり着けなくなり、サポートへの問い合わせが増えます。問い合わせが増えたことは可視化されますが、それが検索の劣化に起因していると誰も繋げない。そのままオンボーディングの完了率が落ち、最終的に解約率へ効いてきます。

メディアなら回遊率とPV。ヘルプセンターなら自己解決率。どの業態でも、検索は「事業の一番深いところにある導線」であり、劣化は必ず金額として出ます。ただし、検索という名前を名乗らずに出てきます。だから発見が遅れます。

買い手が要求すべきは、説明ではなく現物

ここからが実務です。買い手がやるべきことは単純で、説明を聞かず、現物を出させる。これに尽きます。

「検索のチューニングはしていますか」と質問すると、返ってくる答えは「はい」か「特に何も」の2択で、どちらも情報量がゼロです。売り手に悪意はなく、本人も何がチューニングにあたるのかを把握していないだけ、というケースが大半です。

だから、技術的DDでは次の現物をファイルとして要求します。

インデックスの mapping / settings 一式（analyzer・tokenizer・filter の定義を含む）
シノニム辞書の全件
形態素解析用のユーザー辞書の全件
ランキングの重み付け設定と、その意図のメモ
除外ルールの全件と、各ルールが入った理由
直近1年のゼロ件ヒットクエリログ

そして、本当に聞くべき質問はこの1つです。

「これらは、リポジトリに入っていますか」

この質問の答えが、資産の引き継ぎ可能性をほぼ決めます。設定がコードとして管理され、インデックスの再構築がスクリプト一発で再現できるなら、移管のリスクはほとんど消えます。逆に「管理画面を見ながら手で設定しました」なら、それは引き継げる保証がどこにもない資産です。人間が手で写す作業には、必ず漏れが混ざります。

検証方法も具体的に決めておきます。ステージング環境でゼロからインデックスを再構築し、上位クエリ100件について、旧環境と新環境の検索結果の上位10件を機械的に突き合わせる。一致率が出れば、劣化は移管前に数値として見えます。「なんとなく大丈夫そう」を、比較可能な数字に変える作業です。

この比較のもとになるクエリ集合は、実質的に検索品質の評価データセットにあたります。事業として本来持っておくべきもので、持っていない事業は「自分の検索が良いか悪いか」を判定する手段そのものを持っていません。

あわせて、インデックスの再構築や差分更新が定期処理の設定としてどこかで回っていないかも確認します。これが移管で止まると、検索結果が移管の日付で凍りつき、新商品が永久に検索に出てこないという別の事故が始まります。データは入っている、検索も動いている、ただ先月以降の商品だけがこの世に存在しない。これもまた、エラーを出しません。

売り手は、辞書をリポジトリに入れるだけで値段の付くものに変えられる

売り手側の対処は、拍子抜けするほど簡単です。エクスポートして、リポジトリに入れる。それだけです。

ほとんどの検索エンジンは、APIで設定を吐き出せます。シノニムも、ユーザー辞書も、ランキング設定も、JSONで取れます。それをコミットして、インデックス再構築のスクリプトを1本書いておく。半日あれば終わります。

この半日をやったかどうかで、何が変わるか。

やっていない場合、その数年分のチューニングは査定の対象にすらなりません。買い手から見て「引き継げるか分からないもの」に値段は付きません。存在を主張しても、証明する手段がないからです。

やってある場合、それはファイルとして提示できる資産になります。「シノニム1,800行、ユーザー辞書400語、これが数年分のユーザーの語彙です」と現物を出せる。買い手のエンジニアには、その意味が即座に伝わります。分かる人には、重みがそのまま伝わるのです。

同じものが、片方では空気で、もう片方では資産です。その差は、エクスポートしてコミットしたかどうかだけです。

静かに壊れるものほど、先に確認する

移管で派手に落ちるものは、実はそれほど怖くありません。サイトが落ちれば全員が気づきますし、その日のうちに直します。誰も損をしないとは言いませんが、少なくとも問題が問題として認識されます。

本当に怖いのは、正常に動いているように見えるまま、質だけが落ちるものです。検索はその代表格で、しかも事業の収益導線の一番深いところに埋まっている。監視も届かない。アラートも鳴らない。チェックリストは全部グリーンで通過する。

数年かけて、ゼロ件ヒットのログを眺めながら1行ずつ辞書を足してきた人がいます。その作業に名前は付いていないし、KPIにもなっていない。それでも、その積み重ねがユーザーの「探して、見つかる」を支えていました。移管のチェックリストの「検索: OK」というたった1行の裏で、その仕事が丸ごと消えることがあります。

売り手にとっては、自分が育てたものが値段も付かないまま消えるということです。買い手にとっては、買ったはずのものが手元にないということです。どちらにとっても損しかない。

そして、それを防ぐために必要なのは、辞書をエクスポートしてコミットするという、たったそれだけの作業です。数年分の仕事が、その半日をやらなかったというだけの理由で空気になる。あまりにもったいない話だと思いませんか。