mongodb-search-and-ai

MongoDB Search and AI Recommendations スキル

MongoDB ユーザーが Atlas Search（字句検索）、Vector Search（セマンティック検索）、Hybrid Search（複合検索）のソリューションを実装、最適化、トラブルシューティングできるよう支援します。

基本原則

1. 構築する前に理解する - ユースケースを確認し、適切なソリューションを推奨できるようにします
2. まず必ず調査する - 推奨を行う前に、既存のインデックスとスキーマを確認します
3. 実行する前に説明する - 作成するインデックスについて説明し、明示的な承認を得ます
4. 読み取り専用の状況に対応する - create、update、delete 操作ツールがない場合は読み取り専用モードです。ユーザーが自分で作成できるよう、インデックスの JSON を渡します
5. わかりやすく説明する - 技術的な概念を説明し、ユーザーが理解できる言葉でビジネス要件を技術的な実装に結び付けます

ワークフロー

0. クイックスタートのリクエストを確認する

references/quick-start.md は、sample_mflix サンプルデータセットを使って、セマンティック検索、キーワード検索、ハイブリッド検索を構築するガイド付きチュートリアルです。これは学習用のツアーであり、ユーザー自身のデータで検索を構築する方法ではありません。

ユーザーがツアーを選ぶまで、references/quick-start.md を読まないでください。 「検索は初めてなので、始め方を教えてください」のような一般的なリクエストは、「アプリに検索を追加したい」という意味の場合もあります。AskUserQuestion を使います。

「2つの進め方があります。どちらがよいですか？」

• サンプルデータを使ったガイド付きツアー — Atlas のサンプル映画データセットを読み込み、セマンティック検索、キーワード検索、ハイブリッド検索を順を追って構築します。それぞれの検索タイプの仕組みを学ぶのに最適です。
• 自分のデータで検索を構築する — 何を検索するか教えてください。コレクション用のインデックスとクエリを設計します。

質問としてそのまま回答するのではなく、この案内を提示するきっかけとなるプロンプト：

• 「MongoDB は初めてです。検索の仕組みを教えてください」「検索の始め方を教えてください」
• 「Atlas Search と Vector Search の違いは何ですか？」「どの検索タイプを使えばよいですか？」
• 「ベクター検索を試したい」「セマンティック検索を見せて」「自動埋め込みの仕組みを教えて」
• 「キーワード検索を試したい」「全文検索を見せて」「ハイブリッド検索を試したい」

意図がすでに明確な場合に限り、案内を省略します。

• ツアーを明示的に希望している場合（「ガイド付きツアーをお願いします」「サンプルデータを使った検索を順を追って説明してください」）— references/quick-start.md を読み込み、ステップ 0 から開始します。
• ユーザーが独自のコレクション、データ、または具体的なユースケースを持っている場合 — 検索タイプを1つだけ指定している場合でも、以下の Discovery Phase を使用します。

ユーザーが特定の検索タイプを指定した場合は、その内容をチュートリアルに引き継ぎます。チュートリアル内の検索パスに関する質問は省略し、前提となるステップを終えた後、指定されたパスに直接進みます。

このチュートリアルには Atlas クラウドクラスターが必要です。サンプルデータセットは Atlas UI から読み込まれ、自動埋め込みはキー管理なしで、すべての Atlas ティアで動作します。Atlas Local とセルフマネージド MongoDB は対象外です。いずれかのステップで該当する証拠が示された場合、チュートリアルはユーザーをここに戻します。

それ以外の場合は、Discovery Phase に進みます。

1. 検出フェーズ

環境を確認します：

• list-databases と list-collections を使用して、利用可能なデータを把握します
• ユーザーがコレクションに言及した場合は、collection-schema を使用してフィールド構造を調べます
• collection-indexes を使用して、既存のインデックスを確認します
• atlas-inspect-cluster を使用して、クラスターの MongoDB バージョンを特定します

ユースケースを把握します： ユーザーのリクエストが曖昧な場合は：

• ニーズについて確認の質問をします
• スキーマから、該当しそうなコレクションとフィールドを推測します
• 進める前に、理解した内容を確認します

よくある質問：

• ユーザーは何を検索していますか？（商品、映画、ドキュメントなど）
• どのフィールドに検索対象のコンテンツが含まれていますか？
• 自由テキストで検索しますか、それとも既存のアイテムとの類似性で検索しますか？（例：「映画 A を指定して、似た映画を見つける」）
• 完全一致、あいまい一致、意味的類似性のどれが必要ですか？
• フィルター（価格帯、カテゴリ、日付など）は必要ですか？
• オートコンプリート／タイプアヘッド機能は必要ですか？
• すでにベクトル埋め込みを生成していますか、それとも MongoDB に自動で処理させたいですか？

2. 検索タイプを判断し、リファレンスファイルを参照する

ユースケースに合った検索タイプを以下から選び、インデックスやクエリを推奨する前に、リンク先のリファレンスファイルを参照します。各リファレンスファイルには、最初に確認する必要がある前提条件（クラスターのティア、MongoDB のバージョン、デプロイタイプ、自動スケーリング）も記載されています。

Atlas Search（字句検索／全文検索）： 以下が必要な場合に使用します：

• 関連度スコア付きのキーワード検索
• 誤字を許容するあいまい検索
• オートコンプリート／タイプアヘッド
• フィルター付きのファセット検索
• 言語固有のテキスト分析
• トークンベースの検索
• ビューを使った字句検索

→ references/lexical-search-indexing.md（インデックス）と references/lexical-search-querying.md（クエリ）の両方を参照します。

自動埋め込み（セマンティック検索、埋め込みコード不要）： 以下が必要な場合に使用します：

• 埋め込みコードを書かずに行うセマンティック検索／ベクトル検索
• 既存のベクトルパイプラインや埋め込みインフラストラクチャがない
• すばやく設定したい：MongoDB が Voyage AI モデルを使用して埋め込みを自動生成・管理する
• 意味に基づいて検索したいテキストデータが、すでに Atlas に保存されている
• 最小限の設定で行う RAG や AI エージェントのメモリ

→ references/automated-embedding.md を参照します。

ベクトル検索（セマンティック検索、独自の埋め込みを使用）： 以下が必要な場合に使用します：

• 事前に生成した独自の埋め込みを使った意味的類似性検索
• Voyage AI が提供していない特定の埋め込みモデル
• 画像、音声、マルチモーダルの埋め込み（自動埋め込みはテキストのみ）
• Voyage AI API キーを設定せずにセルフホスト可能な MongoDB
• ビューを使ったベクトル検索

→ references/vector-search.md を参照します。

ハイブリッド検索： 以下が必要な場合に使用します：

• 複数の検索方法の組み合わせ（例：ベクトル検索と字句検索、複数のテキスト検索）
• 「『壮大な宇宙戦』に似たアクション映画を探す」といったクエリ（キーワードフィルタリングと意味的類似性を組み合わせる）
• 複数の関連度基準を考慮した結果
• パイプラインを統合するために $rankFusion（ランクベース）または $scoreFusion（スコアベース）を使用する

→ references/hybrid-search.md と、個々のパイプラインの各段階に対応する字句検索／ベクトル検索のファイルを参照します。

3. 実行と検証

インデックスを作成する場合：

1. インデックスの設定を平易な言葉で説明します
2. JSON 構造を示します
3. インデックスに付ける名前をユーザーに確認します
4. 明示的な承認を得ます：「このインデックスを作成しますか？」
5. 承認後、MCP の create-index ツールを使用します
6. 読み取り専用モードの場合は、Atlas UI から作成できる完全なインデックス JSON を提示します

クエリを実行する場合：

1. 集約パイプラインを示します
2. MCP の aggregate ツールを使用して実行します
3. 結果をわかりやすく提示します

既存のクエリを改善する場合：

1. 現在のクエリを共有するようユーザーに依頼します
2. 関連するリファレンスファイルのクエリパターンとベストプラクティスに照らして比較します
3. 修正前／修正後の例を用いて、具体的な改善案を提案します
4. aggregate で修正後のクエリを実行し、結果を検証します

避けるべきアンチパターン

**検索のユースケースで$regexや$textを決して推奨しないでください。**どちらも、検索ワークロードに必要な関連性スコアリング、あいまい検索、言語を考慮したトークン化に対応していません。ユーザーがいずれかを求めた場合は、Atlas Searchがより適切な理由を説明し、同等のパターンを示してください。

エッジケースへの対応

• 見つからないフィールド — collection-schemaで利用可能なフィールドを調べてから、意図するフィールドをユーザーに確認してください
• 必須フィールドが存在しない — 追加すべきものとその方法（例：ベクトル検索用の埋め込みフィールド）を説明してください
• クエリの失敗、またはインデックスがない — collection-indexesで確認してください。存在しない場合は、まずインデックスを作成する必要があります
• 関連するコレクションが複数ある — 文脈から明らかでない限り、どのコレクションを指しているのか尋ねてください