# PRD: 検索速度改善（検索インフラ刷新）

**ステータス:** 初稿（要レビュー）
**作成日:** 2026-08-20
**対象範囲:** 検索機能（インデックス基盤・検索ロジック）

## 1. 背景・課題

### 課題
ユーザーから「検索が遅い」という声が継続的に寄せられている。実測では検索結果表示まで3秒以上かかっており、特にモバイル利用者からの不満が多い。速度の遅さがユーザーの離脱につながっている可能性が高い。

### 技術的背景
エンジニアチームとの定例（議事録より）で以下が共有されている。

- 現行の検索実装はDB全文検索、具体的には `LIKE` 句のみに依存している
- 検索用インデックスが最適化されていない
- 検索対象は**タイトルとタグのみ**で、本文は検索対象外

### 課題のつながり
「本文非対応・LIKE句のみ」という実装上の制約が「インデックス未最適化」という技術的負債を生み、それが「検索3秒以上」という体感速度の悪さに直結し、結果として「離脱率上昇（特にモバイル）」というビジネス影響に波及している、という一連の因果関係として整理できる。

> 上記は入力メモ・議事録・仕様からの整理であり、離脱率とのCV相関、実際のユーザー数・検索頻度、モバイル比率の具体値は未確認（後述の確認質問を参照）。

## 2. 目的（Why）

検索体験（速度・網羅性）を改善し、検索起因の離脱を減らす。

## 3. 対象ユーザー

- サイト内検索を利用する全ユーザー（特にモバイル利用者は不満の声が多く優先度が高い）

> 未確認: 検索機能を使うユーザーセグメント（新規/既存、特定ページ経由など）の詳細は入力情報になし。

## 4. スコープ（今回やること）

| # | 項目 | 内容 |
|---|---|---|
| 1 | 検索インデックスの見直し | 現行のインデックス未最適化状態を解消する（全文検索エンジン導入 or DBインデックス最適化は要検討、後述） |
| 2 | 検索方式の刷新 | `LIKE` 句依存からの脱却を検討する |
| 3 | 検索速度の改善 | 検索結果表示までの応答時間を短縮する |

## 5. 非スコープ（今回やらないこと）

| # | 項目 | 理由 |
|---|---|---|
| 1 | 本文の検索対象化 | メモ・議事録に言及はあるが、要件・優先度・工数の合意が未確認のため今回のスコープには含めない。別途スコープ判断が必要 |
| 2 | 検索UI/UXの変更（検索結果画面のデザイン、フィルタ機能追加等） | 入力情報に言及なし。速度改善が主目的のため |
| 3 | 検索キーワードのサジェスト・オートコンプリート機能 | 入力情報に言及なし |
| 4 | 多言語検索対応 | 入力情報に言及なし |

> 非スコープは「入力情報に無いから除外」という機械的な整理であり、PMの意思決定ではない。関係者確認の上で確定させること。

## 6. 成功指標（案）

具体的な数値目標は入力情報に含まれていないため、指標の「型」のみを提示する。目標値は関係者との合意が必要。

| 指標 | 現状（把握している範囲） | 目標（要合意） |
|---|---|---|
| 検索結果表示までの応答時間 | 3秒以上 | 未確定（例: 1秒以内など） |
| 検索起因の離脱率 | 「高い」との定性情報のみ、数値未確認 | 未確定 |
| モバイル利用者の検索完了率 | 不満の声が多いとの定性情報のみ | 未確定 |

> 目標値を仮に置くと事実と推測が混同されるため、あえて空欄にしている。次アクションで実測を提案する。

## 7. 未決事項

1. **本文検索の要否とスコープ**: メモには「検索対象はタイトルとタグのみ、本文は非対応」とあるが、本文検索を今回一緒にやるか、速度改善後の別フェーズにするかが未確定
2. **技術的アプローチ**: DBインデックス最適化（LIKE句のまま）で十分なのか、Elasticsearch/Meilisearch等の全文検索エンジン導入まで踏み込むのか、エンジニアチームとの技術検討が必要
3. **成功指標の目標値**: 「3秒以上」を何秒まで縮めるかの具体的な目標値、離脱率の現状数値と目標値
4. **優先度・リリース時期**: 他の開発タスクとの優先順位、リリース希望時期
5. **影響範囲**: 検索対象データ量、現在のトラフィック規模（検索基盤選定の判断材料として必要）

## 8. リスク一覧

| リスク | 影響度 | 内容 |
|---|---|---|
| 技術選定の手戻り | 中〜高 | インデックス最適化のみで済むのか、検索エンジン導入が必要なのかの見極めを誤ると、実装後にやり直しが発生する |
| 本文検索の後追い拡張コスト | 中 | 今回スコープを「タイトル・タグのみ」の高速化に限定した場合、後で本文検索を追加する際に再設計が必要になる可能性がある |
| 効果測定不能 | 中 | 現状の応答時間・離脱率の実測値がないまま着手すると、改善効果を定量的に示せない |
| モバイル固有要因の見落とし | 低〜中 | 「モバイルからの不満が多い」原因が検索処理自体でなく、モバイル回線・フロント描画等の別要因である可能性が未検証 |

---

## Review Questions

**PMが確認すべき前提**
- 「検索が遅い」の実測値（現状の平均応答時間、p95等）はあるか。それとも定性的な声のみか
- 離脱率の現状数値と、検索起因と特定できている根拠（analytics上の計測方法）はあるか

**関係者（エンジニアチーム）に聞くべきこと**
- インデックス最適化のみで目標速度（例: 1秒以内）に到達可能か、全文検索エンジン導入が必須か
- 導入する場合の想定工数・インフラコスト・運用負荷
- 本文検索を同時に対応する場合、データ量・インデックスサイズへの影響はどの程度か

**実装・調査・計測で詰まりそうな点**
- 現行DBの検索対象データ量（レコード数）が不明なため、LIKE句のボトルネックがデータ量起因かクエリ設計起因か切り分けが必要
- モバイルでの「遅さ」がAPI応答時間なのか、フロントエンドのレンダリングなのかの切り分け計測が必要

## Next Actions

**今日できる次の一手**
- 検索APIの応答時間を実測し、現状の数値（平均・p95）をログまたはAPMツールから取得する
- 検索起因の離脱率をanalyticsツールで確認し、成功指標の目標値設定の土台を作る

**追加で集める資料**
- 現行の検索対象テーブルの件数・データ量
- 過去のエンジニア定例議事録で技術的負債について言及された全文（今回抜粋以外の部分）
- 検索機能の利用ログ（検索クエリ数、モバイル/PC比率）

**次回AIに依頼するとよい作業**
- 実測データが揃った後、本PRDの「成功指標」セクションへ具体的な目標値を反映する更新作業
- エンジニアチームとの技術選定議論の結果を踏まえた「非機能要件（NFR）」のドラフト作成
- 本文検索を別フェーズとする場合の、フェーズ2 PRDの骨子作成