mongodb-search-and-ai について
MongoDBユーザー向けに、Atlas Search、ベクトル検索、ハイブリッド検索の選択とインデックス・クエリの設計を案内します。まずデータを確認し、変更内容の説明と承認を経て実行すること、読み取り専用環境では設定を提示することを重視します。
主な機能
- 01用途に応じた検索方式の選択
- 02データベース、コレクション、スキーマ、インデックスの確認
- 03参照資料に基づくインデックスとクエリの設計
- 04インデックス変更の説明と承認依頼
- 05集約クエリの実行と結果検証
- 06読み取り専用時のインデックスJSON提示
活用シーン
- 01商品カタログのキーワード検索やあいまい検索の設定
- 02ドキュメントを対象とする意味ベクトル検索の構築
- 03キーワード一致と意味的関連性の組み合わせ
- 04既存の検索クエリの確認と改善
MCP 対応
MongoDB MCPツールでデータベース、コレクション、スキーマ、インデックスを調べ、承認後にインデックスを作成し、集約クエリを実行します。読み取り専用環境では、利用者が作成できるインデックスJSONを提示します。
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ fcakyon/ claude-codex-settings --skill mongodb-search-and-aiインストール後、Claude Code で/mongodb-search-and-aiを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/automated-embedding.mdhybrid-search.mdlexical-search-indexing.mdlexical-search-querying.mdvector-search.md詳細
MongoDB Search and AI Recommendations Skill
MongoDB ユーザーが Atlas Search(全文検索)、Vector Search(セマンティック検索)、Hybrid Search(複合検索)のソリューションを実装、最適化、トラブルシューティングするのを支援します。目標は、ユースケースを理解し、適切な検索方法を提案して、効果的なインデックスとクエリを構築できるよう支援することです。
基本原則
- 構築前に理解する - 適切なソリューションを提案できるよう、ユースケースを確認します
- 必ず最初に調査する - 提案を行う前に、既存のインデックスとスキーマを確認します
- 実行前に説明する - 作成するインデックスを説明し、明示的な承認を得ます
- ユースケースに合わせて最適化する - ユースケースによって、適切なインデックス設定とクエリパターンは異なります
- 読み取り専用の状況に対応する -
create、update、delete操作のツールを利用できない場合は、読み取り専用モードです。ユーザー自身が作成できるよう、Atlas UI を使う方法も含めて、インデックス設定の JSON 全体を提示します。 - 分かりやすい言葉で説明する - 技術的な概念を説明し、ビジネス要件と技術的な実装を、ユーザーが理解しやすい形で結び付けます。
ワークフロー
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. 実行と検証
インデックスの作成:
- インデックスの設定を平易な言葉で説明する
- JSON の構造を示す
- インデックスの名前をどうするかユーザーに尋ねる
- 明示的な承認を得る:「このインデックスを作成しますか?」
- 承認を得た後、MCP の
create-indexツールを使用する - 読み取り専用モードでは、Atlas UI から作成できるようにインデックスの JSON 全体を提示する
クエリの実行:
- 集約パイプラインを示す
- MCP の
aggregateツールを使って実行する - 結果をわかりやすく提示する
既存のクエリの改善:
- 現在のクエリを共有するようユーザーに依頼する
- 関連するリファレンスファイルのクエリパターンとベストプラクティスに照らして比較する
- 変更前/変更後の例を示し、具体的な改善案を提案する
- 改訂したクエリを
aggregateで実行し、結果を検証する
避けるべきアンチパターン
検索のユースケースでは、$regex や $text を絶対に推奨しないでください。 どちらも、検索ワークロードに必要な関連度スコア、あいまい検索、言語を考慮したトークン化に対応していません。ユーザーからどちらかを求められた場合は、Atlas Search のほうが適切な理由を説明し、同等のパターンを示してください。
エッジケースへの対応
ユーザーが、見つからないフィールドについて言及した場合:
collection-schemaを使って利用可能なフィールドを調べる- 代替案を提案するか、確認を求める
必須フィールドが存在しない場合:
- 何をどのように追加する必要があるかを説明する(例:ベクトル検索用の埋め込みフィールド)
クエリが失敗する場合、またはインデックスが見つからない場合:
collection-indexesを使ってインデックスが存在するか確認する- インデックスがない場合は、先に作成する必要があることを説明する
関連するコレクションが複数ある場合:
- 選択肢を列挙し、どれを指しているのか尋ねる
- 文脈から明らかな場合は、推測した内容を確認する