db-engine-selection

db-engine-selection (M0) — スコアリングせずに推奨する

M0 は 設計時／/claude-db:start に実行されます。この時点ではスキーマがまだなく、説明されたワークロードしかない場合があります。「どのデータベースを使うべきか？」に答えるものです。スコアリング対象のモジュールではありません。指摘事項は出力せず、軸も重大度もなく、score.mjs や2種類のスコアに含まれることもありません。出力は、以下に示す独立した推奨契約です。references/engine-selection-tree.md の判断ツリーをたどります。

収集する入力

ユーザーの説明（または references/detection-signals.md による検出済みスタック）から、以下を収集します。

• アクセスパターン — キーによる単一レコードの検索、範囲スキャン、複雑な複数エンティティの結合、全文検索／セマンティック検索、時系列分析、グラフ探索、大量の読み取り／書き込み。
• 一貫性と整合性の要件 — 強整合性／トランザクション型か、結果整合性か。複数行にまたがる不変条件。DB による参照整合性の強制が必要かどうか。
• 規模とデータの形状 — 想定されるデータ量、書き込み速度、読み書き比率、カーディナリティ、追記専用／時系列データかどうか、ベクトル／埋め込みのワークロード。
• 運用性とチーム — マネージドかセルフホストか、サーバーレス／エッジ、既存の専門知識、プラットフォームの制約（M21 db-platform-fit と照合）。

判断方法（ツリーの概要。詳細なツリーはリファレンスを参照）

1. トランザクション型、複数エンティティ、整合性を重視するワークロードでは、デフォルトでリレーショナルを選びます（安全なデフォルトは Postgres。エコシステム上の要件がある場合は MySQL/MariaDB）。
2. データが集約指向で、1つのアクセスパターンで読み取られ、結合より埋め込みが適しており、チームがアプリケーション側で整合性を強制することを受け入れる場合は、ドキュメント型（Mongo/Firestore）を選びます。
3. 既知のキーによる単一レコードへのアクセス、キャッシュ、セッション、高スループットの単純な操作には、キーバリュー型（Redis/DynamoDB）を選びます。
4. 大規模で書き込み中心、クエリごとのテーブルを使い、パーティションを優先するワークロードには、ワイドカラム型（Cassandra/Scylla）を選びます。
5. セマンティック検索／RAG にはベクトル型（pgvector/Qdrant など）を選びます。多くの場合、プライマリストアの代わりではなく、併用します。
6. 追記専用のメトリクス／イベントに対する時系列分析には、時系列型（Timescale/ClickHouse/Influx）を選びます。
7. 探索の深さや関係性のクエリが中核的なワークロードであり、後付けではない場合は、グラフ型（Neo4j）を選びます。 複数のデータベースを組み合わせる選択も有効です。それぞれのストアと役割を明記してください。1つのエンジンでワークロードを十分にカバーできる場合は、2つ目のエンジンを追加する前に、「Postgres + 拡張機能」（pgvector、JSONB、パーティショニング、FTS）を優先してください。

推奨契約（M0 が出力するもの — 指摘事項ではありません）

/claude-db:start が表示する、次のフィールドを持つ構造化された推奨オブジェクトです。

• recommended — { paradigm, engine, platform? }。
• rationale — 判断ツリーの分岐に関連付けた、根拠となるアクセスパターン／一貫性／規模の情報。
• runner_up — { paradigm, engine } と、推奨案を選ぶことによる明示的なトレードオフ（何を手放すか）。
• assumptions — 想定したワークロードの情報。不明な事実はここに記載し、作り上げないでください。
• confidence — established | directional | speculative（説明のみを入力とする場合は、最大でも directional）。重要な事実が不足している場合は speculative です。
• caveats — ロックイン、運用性、プラットフォームに関する注記（正確な価格／制限については M21／ベンダーのページを参照）。 このオブジェクトはガイダンスとして表示されます。schema/finding.schema.json に準拠せず、audit-report.schema.json にも含まれません。

検証／誠実さ

• 選択の根拠として、ベンチマーク、レイテンシー、スループット、価格、行数の上限を決して捏造しないでください。 文書化された特性（一貫性モデル、FK のサポート、インデックスの種類、運用性、ロックイン）で比較し、 規模は高｜中｜低で示してください。ベンダーのページを引用する場合は、WebFetch を使い、引用のみで示してください。
• 常に次点候補とトレードオフを明記してください。代替案のない推奨は危険信号です。
• ワークロードの仕様が不足している場合は、その旨を伝えて質問するか（または confidence: speculative と記載し）、根拠なく選択を 強行しないでください。
• M0 はスコアを生成せず、何かに上限を設けることも決してありません。その性質上、あくまで参考情報を示すものです。既存の スキーマがある場合、正確性の判断はスコアを付与するモジュール（M1..M22）と監査担当者に委ねてください。