marketplace-search-recsys-planning

マーケットプレイスのエンジニアリング：両面マーケットプレイスにおける検索・レコメンデーション計画のベストプラクティス

両面型の信頼ベースのマーケットプレイスにおける検索・レコメンデーションシステムの包括的な計画、設計、診断ガイドです。OpenSearch のインデックス、クエリ、ランキングのパターン、検索候補の取得に関する作業を計画する方法論、レコメンデーション専用ツールへの引き継ぎポイント、そして測定結果を継続的な意思決定につなげる計測・ダッシュボードのレイヤーを扱います。カスケードへの影響度順に並べた10カテゴリー、57のルールに加え、2つのプレイブック（新しいシステムをゼロから計画する、既存システムを診断する）と、継続的に更新する成果物の明示的な規約（決定ログ、ゴールデンセット、注意点）が含まれています。

適用するタイミング

次のような場合に、このスキルを参照してください。

• 新しいマーケットプレイスの検索候補取得プロジェクトをゼロから計画するとき
• 古く感じられる、不公平に感じられる、またはパーソナライズされていない既存の検索候補取得システムをレビューするとき
• OpenSearch のインデックスマッピング、アナライザー、クエリ DSL を設計するとき
• プロダクトの各サーフェスに使う検索候補取得のプリミティブ（検索、レコメンデーション、ハイブリッド、キュレーション）を選ぶとき
• 追跡してダッシュボードに表示する検索品質指標を決めるとき
• 毎週の検索品質レビューを実施するとき
• ランキング、カバレッジ、ゼロ件率における目立たないリグレッションを診断するとき
• 検索候補取得の問題が、実際にはパーソナライズの問題ではないかを判断するとき

このスキルは、marketplace-personalisation の前段階です。計画と検索の作業はここから始め、診断したボトルネックがインプレッションの追跡、フィードバックループのバイアス、または AWS Personalize 固有の設計にある場合は、パーソナライズのスキルに引き継いでください。

継続的に更新するコンテキスト

このスキルでは、システムは進化し続けるものとして扱います。3つの継続的に更新する成果物が、セッション、リリース、チーム変更をまたいでコンテキストを引き継ぎます。提案を行う前にこれらを読み、変更をリリースするたびに更新してください。

• gotchas.md（このスキルのフォルダー内）— 診断で得られた知見を追記していきます。各項目には日付と、チームが予想外だと感じたこと、およびその解決方法の簡潔な説明を記載します。
• 決定ログ（プロダクトのリポジトリで管理。通常は decisions/*.md）— ランキングの変更、スキーマの調整、同義語の編集について、それぞれの仮説、オフラインとオンラインのエビデンス、リリース基準、結果、ロールバック手順を記録します。ルール plan-maintain-a-decisions-log を参照してください。
• ゴールデンクエリセット（評価サイクルごとに凍結し、プロダクトのリポジトリにコミット）— オンラインテストの前にランキング変更をすべてオフライン評価する際の基準となるクエリセットです。ルール plan-version-the-golden-set を参照してください。

ルールのカテゴリー

カテゴリーは、検索候補取得のライフサイクルへのカスケード影響度順に並んでいます。インテントの誤解はアーキテクチャを損ない、誤ったアーキテクチャはインデックスを損ないます。誤ったインデックスは再インデックスするまで検索候補取得を損ない続け、下流のすべてのレイヤーが上流のエラーを引き継ぎます。

#	カテゴリー	プレフィックス	影響度
1	問題の定義とユーザーインテント	intent-	CRITICAL
2	サーフェスの分類とアーキテクチャ	arch-	CRITICAL
3	インデックス設計とマッピング	index-	HIGH
4	計画と改善の方法論	plan-	HIGH
5	クエリの理解	query-	MEDIUM-HIGH
6	検索候補取得の戦略	retrieve-	MEDIUM-HIGH
7	関連性とランキング	rank-	MEDIUM-HIGH
8	検索とレコメンダーのブレンド	blend-	MEDIUM
9	測定と実験	measure-	MEDIUM
10	計測、ダッシュボード、意思決定のトリガー	monitor-	MEDIUM

クイックリファレンス

1. 問題の整理とユーザーの意図（重要）

• intent-map-queries-to-intent-classes — 検索前に分類する
• intent-separate-known-item-from-discovery — 失敗の種類が異なれば、戦略も異なります
• intent-audit-live-query-logs-first — 想像上のデータではなく、実際のデータに基づいて設計する
• intent-distinguish-transactional-from-exploratory — 適合率と多様性
• intent-reject-one-search-for-everything — サーフェスごとに異なるクエリ形式
• intent-treat-no-search-as-first-class-choice — キュレーション済みの結果も正当な選択肢です

2. サーフェスの分類とアーキテクチャ（重要）

• arch-map-surface-to-retrieval-primitive — 信頼できる唯一の情報源となるルーティングテーブル
• arch-split-candidate-generation-from-ranking — 2 段階のパイプライン
• arch-design-zero-result-fallback — サーフェスごとにフォールバックの担当を明確にする
• arch-design-for-cold-start-from-day-one — コールドスタートは一時的な初期化ではなく、恒常的な課題です
• arch-avoid-mono-stack-retrieval — 主要な依存先を分散させる
• arch-route-surfaces-deliberately — すべてのルーティング判断を記録する

3. インデックス設計とマッピング（高）

• index-design-mappings-conservatively — 再インデックスにはコストがかかります
• index-use-keyword-and-text-as-multi-fields — 全文検索と完全一致
• index-match-index-and-query-time-analyzers — トークンを一致させる必要があります
• index-use-language-analyzers-for-language-fields — 言語に応じたステミング
• index-separate-searchable-from-display-fields — 検索するフィールドだけをインデックスする
• index-use-index-templates-for-consistency — マッピングの不整合を防ぐ
• index-stream-listing-updates-via-cdc — 鮮度を時間単位ではなく秒単位で保つ

4. 計画と改善の手法（高）

• plan-audit-before-you-build — キックオフ時に計測の実施を必須にする
• plan-build-golden-query-set-first — 最後ではなく、最初に作成する成果物
• plan-find-bottleneck-before-optimising — 制約理論
• plan-maintain-a-decisions-log — チームの変更をまたいで引き継ぐ継続的なコンテキスト
• plan-version-the-golden-set — 評価サイクルごとに固定する
• plan-handoff-to-personalisation-skill — 境界を認識する

5. クエリ理解（中〜高）

• query-normalise-before-anything-else — 最初に正規化文字列を入力します
• query-use-language-analyzers-for-stemming — 再現率が二桁向上します
• query-curate-synonyms-by-domain — シソーラスではなく、ドメインの語彙を使用します
• query-use-fuzzy-matching-for-typos — クエリの10〜15％に誤字があります
• query-classify-before-routing — シングルパスの分類器
• query-build-autocomplete-on-separate-index — レイテンシを分離します

6. 検索戦略（中〜高）

• retrieve-use-filter-clauses-for-exact-matches — フィルターキャッシュの効果
• retrieve-use-bool-structure-deliberately — must、should、filterの使い分け
• retrieve-run-expensive-signals-in-rescore — リスコアウィンドウでコストを制限します
• retrieve-combine-bm25-and-knn-via-hybrid-search — 語彙検索とセマンティック検索を組み合わせます
• retrieve-paginate-with-search-after — 深いページネーションでもコストが一定です
• retrieve-choose-embedding-model-deliberately — 再埋め込みにはコストがかかります

7. 関連性とランキング（中〜高）

• rank-tune-bm25-parameters-last — まず上流の調整箇所に取り組みます
• rank-use-function-score-for-business-signals — 名前付き関数を明示的に指定します
• rank-deploy-ltr-only-after-golden-set-exists — 教師あり学習にはラベルが必要です
• rank-apply-diversity-at-rank-time — スコアリング後に適用し、前には適用しません
• rank-normalise-scores-across-retrieval-primitives — 比較可能なスケールにします

8. 検索とレコメンダーのブレンディング（中）

• blend-use-search-alone-for-specific-intent — 精度重視のクエリ
• blend-combine-search-and-personalisation-scores — 正規化した加重和
• blend-keep-hybrid-blending-explainable — 結果を追跡可能にします
• blend-never-return-zero-results — 空でない結果へ必ずフォールバックします

9. 測定と実験（中）

• measure-define-session-success-per-surface — サーフェスごとに定義を1つ設定します
• measure-track-ndcg-mrr-zero-result-rate — 全体像を把握するための3つの指標
• measure-track-reformulation-rate-as-failure-signal — 最も低コストな失敗指標
• measure-use-click-models-for-implicit-judgments — 人による評価者を超える規模に対応します
• measure-run-interleaving-as-cheap-ab-proxy — 必要なサンプル数を10分の1に抑えます

10. 計測、ダッシュボード、意思決定のトリガー（中）

• monitor-log-every-query-with-full-context — 構造化された再生可能なイベント
• monitor-scrub-pii-from-query-logs — データウェアハウスに取り込む前に機密情報をマスキング
• monitor-build-search-health-dashboard — 閾値ライン、色分けされた領域
• monitor-alert-on-decision-triggers — エラー率ではなく品質指標
• monitor-track-ranking-stability-churn — 先行指標としてのRBO変動
• monitor-run-weekly-search-quality-review — カレンダーに基づく定例業務

計画と改善

2つのプレイブックで、ルールをエンドツーエンドのワークフローにまとめています。

• references/playbooks/planning.md — マーケットプレイスの新しい検索システムをゼロから計画します。意図の監査から最初のA/Bテストによるオンラインでの効果測定まで、各ステップに明確な終了基準を設けた9段階のワークフローです。
• references/playbooks/improving.md — 既存の検索システムを診断し、改善します。テレメトリ、インデックスの鮮度、網羅率、ベースラインとの差、コールドスタート、セグメントごとの性能低下、アルゴリズムの反復改善の順に確認する判断ツリーがあり、ボトルネックがパーソナライズに固有の場合はmarketplace-personalisationへ引き継ぐポイントも示します。

「新しい検索・レコメンダープロジェクトを設計する」または「この検索システムを改善する必要がある」というタスクでは、まずプレイブックを読んでください。実装やレビューの際に具体的な疑問が生じた場合は、個別のルールを読んでください。

使い方

• references/_sections.mdを読み、カテゴリ構成と適用順の根拠を確認します。
• gotchas.mdを読み、過去のインシデントから蓄積された診断の知見を確認します。
• 新しいシステムを計画するには、references/playbooks/planning.mdを読みます。
• 既存のシステムを診断するには、references/playbooks/improving.mdを読みます。
• 特定のタスクがルールのタイトルに該当する場合は、個別のルールファイルを読みます。
• スキルの拡張に合わせて新しいルールを作成するには、assets/templates/_template.mdを使用します。

関連スキル

• marketplace-personalisation — AWS Personalizeの実装、インプレッションのトラッキング、スキーマ設計、双方のマッチング、フィードバックループ、パーソナライズ固有の診断プレイブックを扱う関連スキルです。診断の結果、パーソナライズに固有のボトルネックが特定された場合は、このスキルに引き継いでください。

参照ファイル

ファイル	説明
references/_sections.md	カテゴリの定義と影響度による順序
references/playbooks/planning.md	新しい検索システムの計画
references/playbooks/improving.md	既存の検索システムの診断
gotchas.md	蓄積された診断の知見（随時更新）
assets/templates/_template.md	新しいルールを作成するためのテンプレート
metadata.json	バージョン、分野、参照情報