Codexに検索改善を任せる前に決めること

3行まとめ

Query

評価。

Zero

空結果。

Synonym

同義語。

A/B

比較。

検索改善は、好みではなくqueryごとの結果で判断します。

• Codexに検索改善を任せる時は、synonymやrankingを触る前に、守るquery set、baseline、zero result、no click、評価指標、rollbackを決めます。
• 検索改善は、1つのqueryで上位が良く見えるかではなく、重要query、long tail、空結果、誤ヒットをまとめて見ます。
• analyticsやA/B testで確認できる形にし、synonym、ranking rule、boost、filter変更を1つずつ切り分けます。

検索改善は、AIに頼みたくなる作業です。検索ログを見て、同義語を足し、rankingを調整し、zero resultを減らし、商品や記事を見つけやすくする。Codexに任せれば、設定JSONや管理APIの差分は作れます。

ただ、検索は一部だけ良くしても全体が壊れます。あるqueryで1位が良くなっても、別の重要queryで悪くなることがあります。広すぎるsynonymは誤ヒットを増やします。ranking ruleを変えると、カテゴリや在庫や新着順の見え方も変わります。

この記事では、Codexに検索改善を任せる前に決めることを整理します。実装対象はAlgolia、Meilisearch、Elasticsearch、自前検索など何でも構いません。ここでは、AIへ渡す変更条件とreview観点へ絞ります。

この記事でわかること

Intent

意図。

Ranking

順位。

Click

反応。

Rollback

戻す。

検索結果は一部だけ良くしても、別queryを壊すことがあります。

• 検索改善をCodexへ頼む前に決める6項目
• query setを作って改善前後を比較する方法
• zero resultとno clickを分ける理由
• synonymとranking ruleを同時に動かさない考え方
• analyticsとA/B testで確認する観点
• rollbackとmonitoringを先に決める方法
• Codexへそのまま渡せる依頼packet
• reviewで止めるべき検索変更

検索providerによって設定名や評価方法は変わります。AlgoliaのDocsではrelevance、analytics、A/B testingの考え方が説明されています。MeilisearchのDocsではranking rules、typo tolerance、ranking scoreの考え方が説明されています。導入時は利用中のprovider公式Docsを確認してください。

前提知識

項目	内容	見方
Algolia		relevance。
Analytics		行動。
Meilisearch		ranking。
Typo		表記揺れ。

検索品質はmatching、ranking、analyticsを合わせて見ます。

検索改善は、好みではなく評価で見ます。

「この結果のほうが良さそう」だけでは、reviewが属人的になります。検索query、期待する上位、許容する結果、壊したくないquery、計測指標を並べます。

検索改善は好みではなく評価で見る

検索結果には、matching、ranking、filter、synonym、typo tolerance、facets、personalization、business ruleなどが絡みます。どれを変えたのか分からないと、改善した理由も悪化した理由も分かりません。

まず守るqueryを決める

すべてのqueryを同時に完璧にはできません。重要query、売上やCVに近いquery、supportで多いquery、zero result query、長いtail queryを選び、評価setを作ります。

変更前に決める6項目

項目	内容	見方
Goal		目的。
Queries		評価。
Baseline		現状。
Change		変更。
Metrics		指標。
Rollback		戻す。

目的と評価queryがない検索改善は、見た目の印象で進みます。

Codexへ頼む前に、6項目を決めます。

項目	決めること	曖昧なまま起きること
goal	何を改善するか	変更が広がる
queries	評価query	1件だけ良くなる
baseline	現在の順位と指標	改善を証明できない
change	synonym、ranking、filterなど	原因が分からない
metrics	CTR、conversion、zero rate	体感で判断する
rollback	戻す条件	悪化時に迷う

Codexは設定変更やテストを作れますが、事業上重要なqueryや、壊してはいけない検索体験は知りません。

変更を1種類に絞る

最初は、synonymだけ、rankingだけ、filterだけ、typo toleranceだけのように絞ります。同時に変えると、何が効いたのか分かりません。

baselineを残す

変更前のtop results、zero result率、click、conversion、query countを残します。手元のfixtureでも良いので、同じqueryで比較できる形にします。

reviewで見ること

reviewでは、改善したqueryだけでなく、悪化したquery、表示されなくなった重要item、誤ヒットが増えたquery、zero resultが増えたqueryを見ます。

query setを作る

項目	内容	見方
Head		多い。
Tail		少ない。
Zero		空。
No click		無反応。
Critical		重要。

query setがあると、改善前後を同じ条件で比べられます。

query setは、検索改善のテストケースです。

種類	例	見ること
head query	よく検索される語	上位の安定
tail query	少数だが重要な語	取りこぼし
zero result	結果なし	synonymやindex不足
no click	結果あり無反応	上位違い
critical	売上やsupportに近い語	悪化防止

Codexへは、このquery setを渡します。検索ログから候補を出させてもよいですが、最終的に採用するqueryは人間が確認します。

期待結果を書く

queryごとに、上位に出てほしいitem、出てほしくないitem、許容順位を書きます。完全一致だけでなく、カテゴリ、在庫、公開状態、地域、権限も見ます。

long tailも入れる

head queryだけで評価すると、よくある検索だけ良くなります。typo、表記揺れ、複合語、略称、古い商品名、ユーザーが使う自然語も入れます。

zero resultとno clickを分ける

Zero

出ない。

Bad top

上位違い。

No click

選ばれない。

Refine

絞れない。

結果がない問題と、結果はあるが選ばれない問題を分けます。

zero resultは、結果が出ない問題です。no clickは、結果は出ているが選ばれない問題です。原因が違います。

zero resultは、index不足、synonym不足、typo tolerance、filter条件、権限、公開状態が原因かもしれません。no clickは、上位結果、title、thumbnail、snippet、価格、在庫、CTAが原因かもしれません。

zero resultで見ること

• queryの表記揺れ
• synonym候補
• indexに対象itemがあるか
• filterで落ちていないか
• typo toleranceが効いているか

no clickで見ること

• top resultが意図と合うか
• snippetやtitleが分かりやすいか
• facetやsortが必要か
• 古いitemや在庫なしが上位に来ていないか

注意点

zero resultを減らすためにsynonymを広げすぎると、誤ヒットが増えます。結果数だけでなく、上位の質を見ます。

synonymとrankingを別変更にする

1. 1Baseline

   現状。

2. 2Synonym

   同義語。

3. 3Ranking

   順位。

4. 4Rules

   例外。

5. 5Verify

   確認。

synonymとrankingを同時に動かすと、何が効いたか分からなくなります。

synonymとrankingは別の変更です。

synonymは、ユーザーの言葉とデータ内の言葉をつなぐものです。rankingは、hitした候補の順番を決めるものです。AlgoliaのDocsではrelevanceやranking criteria、analyticsを使った改善が説明されています。MeilisearchのDocsではranking rulesが順番に適用される考え方が説明されています。

synonymは狭く始める

同義語は狭く始めます。双方向にするか、一方向にするかも決めます。たとえば「AI agent」と「coding assistant」は近いですが、すべての文脈で同じとは限りません。

rankingは説明できる形にする

ranking ruleやboostを変える時は、なぜ上げるのかを説明します。人気、在庫、鮮度、権限、契約、カテゴリ優先など、事業ルールを明確にします。

評価基準

変更後に、どのqueryで、どのitemが、なぜ上がったかを説明できるならreviewしやすい状態です。

analyticsとA/B testで確認する

1. Baseline

   現状。

2. Variant

   変更。

3. Traffic

   割当。

4. Measure

   測定。

5. Decide

   判断。

検索改善は、queryごとの体感とanalyticsの両方で見ます。

検索改善は、analyticsで見ます。

AlgoliaのDocsでは、search analyticsやA/B testingを使ってrelevance tuningをdata-drivenにする考え方が説明されています。A/B testは、rankingやsynonym変更を全ユーザーへ出す前に比較する方法です。

指標を決める

検索では、CTR、conversion、add-to-cart、zero result rate、no result recovery、refinement rate、exit rate、time to clickなどを見ます。記事検索なら、click、滞在、次の行動、検索後離脱などです。

A/B testの単位を決める

A/B testは、変更範囲を絞ります。rankingだけ、synonymだけ、UIだけ、index設定だけのように分けます。traffic割合、期間、成功条件、停止条件を決めます。

条件

小さなtrafficで始め、critical queryが悪化したら停止できるようにします。Codexにはtest結果を読むためのqueryやdashboardも作らせます。

rollbackとmonitoringを決める

項目	内容	見方
Drop		低下。
Zero		増加。
CTR		低下。
Critical		悪化。
Owner		判断。

検索変更は即時反映されやすいため、戻す条件を先に決めます。

検索変更は即時反映されることがあります。戻す条件を先に決めます。

条件	対応
critical query悪化	即rollback
zero result増加	変更停止
CTR低下	A/B停止候補
誤ヒット増加	synonymを狭める
support問い合わせ増加	owner確認

rollback対象を分ける

synonym、ranking rule、index設定、frontend表示、analytics eventは別々に戻せるようにします。まとめて変更すると、戻す時も大きくなります。

monitoringを置く

変更後は、query別の変化を見ます。全体CTRが同じでも、重要queryが悪化していることがあります。

Codexへ渡す依頼packet

項目	内容	見方
Goal		目的。
Queries		評価。
Allowed		許可。
Tests		確認。
Owner		担当。

packet化すると、Codexの検索変更を印象ではなく証拠でreviewできます。

Codexへは、次のようなpacketで渡します。

目的:
  docs検索で「MCP 認証」「tool approval」などのqueryのzero resultを減らす。

評価query:
  head query 10件、tail query 20件、zero result query 20件、critical query 10件。

変更範囲:
  synonym候補の提案とfixture更新まで。
  ranking ruleやindex設定は変更しない。

禁止:
  本番indexへ直接反映しない。
  broad synonymを追加しない。
  analytics event名を変えない。

baseline:
  変更前top 5、zero result、click有無を保存する。

test:
  query setで変更前後を比較する。
  悪化queryを一覧にする。

approval:
  search ownerがsynonymを承認してから反映する。

このpacketがあると、Codexは検索改善を「設定を触る作業」ではなく「評価しながら変える作業」として扱いやすくなります。

よくある失敗

One query

一点。

Too broad

広すぎ。

No base

現状なし。

No rollback

戻せない。

検索改善の事故は、少数queryの成功を全体改善と見なす時に起きます。

1つのqueryだけ見て成功にする

検索改善は、1つのqueryで良く見えても、別queryで悪化することがあります。query setで見ます。

synonymを広げすぎる

広すぎるsynonymは誤ヒットを増やします。片方向か双方向か、対象カテゴリを限定するかを決めます。

analyticsなしでrankingを変える

ranking変更は影響が広いです。baselineとmonitoringなしで触ると、良くなったか分かりません。

zero resultだけを追う

zero resultが減っても、意味のない結果が出るなら改善ではありません。上位結果とclickも見ます。

rollback手順がない

検索設定は管理画面から手で直されがちです。変更履歴、owner、rollback手順を残します。

FAQ

項目	内容	見方
Synonym?		意図。
Ranking?		順位。
A/B?		比較。
AI?		下書き。

迷ったら、その変更で守りたいqueryと壊したくないqueryを並べます。

Codexにsynonym候補を出させてもよいですか

よいですが、採用は人間がreviewします。検索ログ、商品名、ユーザー語彙、support問い合わせを根拠にし、広すぎる候補は避けます。

ranking ruleはAIに任せてよいですか

候補作成は任せられます。実反映は、query set、analytics、A/B test、owner承認を通します。

A/B testは必須ですか

影響が大きい変更では強く推奨です。小さなsynonym追加でも、critical queryがある場合は段階反映やmonitoringを入れます。

zero resultをゼロにすべきですか

いいえ。意味のない結果を出すより、適切な空状態や絞り込み解除を出すほうが良い場合があります。

AIで検索品質を自動評価できますか

補助には使えます。ただし、最終判断はquery set、実ユーザー行動、owner reviewで行います。AI評価だけで本番rankingを変えないほうが安全です。

次に読むなら

参照した主な情報源

• Algolia Docs: Defining relevance
• Algolia Docs: Search analytics
• Algolia Docs: What is A/B testing
• Meilisearch Docs: Built-in ranking rules
• Meilisearch Docs: Typo tolerance vs fuzzy search

更新履歴

1. 2026.06.01

   初版。

検索providerの機能は変わるため、導入時に公式Docsを確認します。

• 2026.06.01: 初版公開。Codexへ検索改善を任せる前のquery set、zero result、synonym、ranking、A/B testを整理しました。