LLMは製品ニーズからどのようにデータベースを選ぶか — そして失敗する理由

なぜ人々はLLMにデータベース選定を頼むのか

チームがLLMにデータベースを推奨させるのは、メールの下書きや仕様の要約を頼むのと同じ理由です：白紙から始めるより速いからです。PostgreSQL、DynamoDB、MongoDB、Elasticsearch、Redis、ClickHouse など多数の選択肢を前にすると、LLMは短時間で候補を絞り、トレードオフを整理し、議論のための「十分に良い」出発点を提示できます。

上手に使えば、それはまたあなたが曖昧にしたままにしがちな要件を明確に言語化させる力にもなります。

「製品ニーズから推測する」とは実際に何を意味するか

平たく言えば、製品（「リスティングとチャットを持つマーケットプレイス」）、データ（「ユーザー、注文、メッセージ」）、制約（「1Mユーザーまでスケール、検索は高速、運用工数は低く」）を説明します。LLMはそれらを一般的なアーキテクチャパターンに紐づけます：

• 関係データ → SQL
• 柔軟なスキーマ → ドキュメントストア
• 分析 → 列指向のデータウェアハウス
• キャッシュ → キー・バリューストア
• 全文検索 → サーチエンジン

これらのマッピングは、何もない状態で始めるよりは早い段階で実際に役立ちます。

アドバイスと最終アーキテクチャ判断の違い

LLMの推奨は仮説として扱うのが最適です。LLMは次のことに役立ちます：

• 解くべき主要な問いを名指しする
• 明らかなミスマッチを早期に特定する
• チームと洗練するための意思決定メモを下書きする

しかし、実際のトラフィックの形状、データ成長、チームのスキル、ベンダー制約、運用許容度は慎重なインプットなしにはわかりませんし、LLMは本番テストを実行もしません。

何がうまくいかないか（リスクを下げる方法）

LLMは予測可能な失敗をしがちです：流行の経験則に頼る、欠落した詳細を推測する、トランザクションや整合性ニーズを見落とす、ベンチマークなしに性能を仮定する、コストや運用負荷を過小評価する、などです。

この記事の残りはそうした失敗モードを分解し、最後にスタックを確定する前に推奨を検証する実践的なチェックリストで締めます。

LLMは要件をどのようにデータベース選定に変換するか

「データベースを推奨して」と頼むとき、LLMはエンジニアのようにデータベースを評価するわけではありません。プロンプトを推論された要件に変換し、それを過去に見たパターンと照合して、決定のように読める答えを生成します。

入力として扱うもの

入力はあなたが明示する詳細（トラフィック、データサイズ、整合性要件）だけではありません。モデルはさらに：

• プロンプトの言い回しや構造（何を強調し、何を省いているか）
• 製品説明（「チャット」「分析」「決済」「IoT」などを典型的なアーキテクチャにマッピング）
• 明示された制約（クラウドプロバイダ、予算、チームスキル、納期）
• 学習データからの「過去のパターン」（一般的なスタック、人気のブログ助言、頻繁に組み合わされる例）

多くのプロンプトが不完全であるため、モデルは暗黙の仮定でギャップを埋めることが多く、それが正しい場合もあれば誤る場合もあります。

生成される出力の層

ほとんどの応答は三つの層に落ち着きます：

1. カテゴリ選択（SQL vs NoSQL；リレーショナル vs ドキュメント vs キー・バリュー）
2. 特定のエンジン（PostgreSQL、MySQL、DynamoDB、MongoDB、BigQuery、Redis）
3. 「ベストプラクティス」の束（インデックス、キャッシュ、リードレプリカ、シャーディング、イベントソーシング）

結果は明確な推奨のように感じられますが、多くの場合は従来の選択肢の構造化された要約に過ぎません。

なぜ確信的に聞こえるのに確実ではないのか

LLMは例から一般化します；あなたのワークロードを実行したり、スキーマを精査したり、クエリをベンチマークしたりはしません。学習データが「高スケール」＝「NoSQL」と強く結びつけていれば、その答えが出る可能性がありますが、実はチューニングされたSQLで十分な場合もあります。

自信のある表現は測定ではなく文体です。モデルが前提（「主に追加書き込みで、最終的整合性で問題ないと仮定します」など）を明示していない限り、確実性は欠落した入力と未検証の性能主張を隠していることがあります。

「製品ニーズ」に実際に含まれるもの

「製品ニーズに基づいてデータベースを選ぶ」と言うとき、多くの人は「ユーザーと注文を保存する」以上の意味を含んでいます。良いデータベース選択は、製品が何をするか、負荷時にどう振る舞うべきか、そしてチームが現実的に運用できるかを反映します。

機能的ニーズ（何を作るか）

製品の形状から始めてください：コアエンティティ、その関係、どのクエリが実際のワークフローを支えているか。

多数の属性でのアドホックなフィルタやレポートが必要か？結合が頻繁か？単一IDでの読み取りが中心か、時間範囲のスキャンが中心か？これらがSQLテーブル、ドキュメントモデル、ワイドカラムパターン、検索インデックスのどれに合うかを決めます。

非機能的ニーズ（どう振る舞うべきか）

データベースは機能ではなく制約によっても選ばれます：

• 重要なユーザー操作のレイテンシ目標（p95/p99）
• 可用性と復旧要件（許容されるダウンタイムは？）
• 読み取り/書き込み比率とピークトラフィックのパターン
• 6〜24か月のデータ容量とトラフィックの成長率

数秒の遅延が許容されるシステムと、200ms未満で支払いを確認する必要があるシステムは全く異なります。

運用ニーズ（あなたが運用できるか）

「完璧な」データモデルでも運用に合わなければ失敗します：

• バックアップと復元テスト
• マイグレーションとスキーマ進化
• オンコール負担とスタッフ（DBA経験があるかジェネラリストか）
• ベンダー制限：マネージドサービスのクォータ、リージョン対応、メンテナンス窓

規制要件（あなたが証明しなければならないこと）

コンプライアンス要件は選択肢を素早く狭めます：

• データ保持と削除の保証
• 監査証跡（誰がいつ何を変更したか）
• アクセス制御、暗号化、職務分離

LLMは曖昧なプロンプトからこれらを推測することが多いため、明示することが有用であり、それが有益な推奨と自信過剰な誤りの差を生みます。

LLMの推論が現実から外れる場所

LLMは数個の記載されたニーズ（「リアルタイム」「スケール」「柔軟なスキーマ」）を馴染みのあるカテゴリラベル（「NoSQLを使え」「Postgresを使え」）に結びつける傾向があります。ブレインストーミングには有用ですが、モデルがデータベースの機能を製品要件と同じものとして扱い始めると推論は外れていきます。

機能 ≠ 製品ニーズ

トランザクション、JSONサポート、全文検索、シャーディングといった機能リストは具体的に聞こえますが、製品ニーズは通常アウトカムを語ります：許容されるレイテンシ、正確性ルール、監査可能性、チームスキル、移行制約、予算などです。

LLMは機能をチェックリスト的に満たしてしまっても、製品が組織的なサポートワークフローや成熟したエコシステム、使用可能なホスティングオプションを必要とすることを見落とすことがあります。

チェックリストはデータとクエリの形を見落とす

多くの推奨は「データ型を保存できるなら十分」という前提に依存します。難しいのはデータとクエリの関係です：どのようにフィルタし、結合し、ソートし、集計するか、どのボリュームで、どの更新パターンで行うか。

「ユーザーイベントを保存できる」二つのシステムでも、必要なクエリが違えば挙動は大きく変わります：

• 多次元に渡るアドホック分析
• 厳密な順序が必要なユーザー毎のタイムライン
• エンティティ間のクロス制約（在庫が0を下回らないこと）

性能は実装の詳細であり約束ではない

LLMは「データベースXは速い」と言うかもしれませんが、性能はスキーマ、インデックス、パーティション、クエリパターン、並列度に依存します。小さな変更（合成インデックスの追加や非上限スキャンの回避）が結果をひっくり返します。代表的なデータとクエリなしでは「速い」は単なる推測です。

運用適合が生の性能を上回る場合がある

二つのデータベースが技術的に要件を満たせても、より良い選択はあなたのチームが確実に運用できる方かもしれません：バックアップと復旧時間、監視、オンコール負担、ベンダーロックイン、コスト予測性、コンプライアンス。LLMはこれらの現実を明示的に与えられない限り軽視しがちです。

失敗モード1：人気の経験則からの過度な一般化

LLMはよく“NoSQLはスケールする”や“Postgresは何でもできる”といった繰り返される経験則に頼ります。これらの近道は自信があるように聞こえますが、製品の現実（何を保存し、どうクエリし、失敗時に何が起きるか）を平坦化してしまいます。

古典的な近道：「スケールのためにNoSQLを使え」

成長、高トラフィック、「ビッグデータ」を述べると、モデルがNoSQLを安全策として選ぶパターンはよくあります。しかし問題は、スケールはたいてい最初に解くべき問題ではないことが多い点です。多くのアプリは以下が原因でボトルネックになります：

• インデックス不足や非効率なクエリ
• 無制限のデータ保持
• 不適切なキャッシュ戦略
• リソースの過小割当

こうした場合、データベースを切り替えても根本原因は修正されません——単に道具が変わるだけです。

無視されがちな点：結合、トランザクション、厳密な正確性

経験則はまた、データベース適合に強く影響する要件を見落とします。LLMがドキュメントストアを推奨しても、次のような必要があるかもしれません：

• 複数ステップ更新がすべて成功または失敗すること（トランザクション）
• 残高、在庫、予約のような厳密な正確性（強整合性）
• エンティティ横断でデータを縫い合わせるレポーティング（複雑な結合）

これらはNoSQLを完全に否定するわけではありませんが、より厳格なスキーマ設計や追加のアプリロジック、LLMが示したものとは別のトレードオフを必要とすることが多いです。

なぜこの失敗が高くつくのか

提案がスローガンに基づいていると、リスクは単なる最適化ミスではなく後の高コストな再プラットフォームです。データ移行、クエリの書き換え、チームの再教育は、最もコストを負担しにくい時期に発生しがちです。

「経験則は質問を引き出すきっかけとして使い、答えとして鵜呑みにしない」ことを徹底してください。何をスケールするのか（読み取りか書き込みか、分析か）、何が正確でなければならないのか、避けられないクエリは何かを問うべきです。

失敗モード2：欠落または曖昧な入力

LLMは短い説明を自信あるデータベース選択に変えるのが得意ですが、決定を左右する欠落した制約を創り出すことはできません。入力が曖昧なとき、推奨は答えを装った推測になります。

「リアルタイム」「高トラフィック」トラップ

「リアルタイム」「高トラフィック」「スケーラブル」「エンタープライズグレード」といった語はデータベースに直結しません。「リアルタイム」がダッシュボードでの5秒以内を意味するのか、トレーディングアラートでの50ms未満を意味するのかで必要な選択は異なります。「高トラフィック」が秒間200リクエストなのか20万なのかでも違います。

数値がないと、LLMは人気のヒューリスティック（例：「スケールならNoSQL」「何でもPostgres」）に落ち着くことがあり、本当のニーズは別のところにあることがあります。

答えを変える欠落した数値

以下を提供しないと、モデルは黙って仮定してしまいます：

• 読み取り／書き込みQPS（ピークと平均）
• p95/p99のレイテンシ目標（読み取りと書き込みそれぞれ）
• 現在のデータセットサイズ、成長率、保持方針
• オブジェクトサイズ（広い行か大きなBLOBか）、インデックスのカーディナリティ

あなたが言い忘れた隠れたクエリパターン

最も致命的な欠落はしばしばクエリの形です：

• レポーティングと分析（group-by、時間バケット）
• 多数フィールドでのフィルタ/ソート
• サポートやデバッグのためのアドホッククエリ
• バックフィル、リプロセス、ユーザーXの全件取得のような検索

キー・バリューアクセスに優れるDBでも、柔軟なフィルタや信頼できるレポーティングが突然必要になれば苦戦します。

実践的なヒント：推奨前に明確化を強制する

「データベース選定」を二段階のやり取りとして扱ってください：まず制約を収集し、次に推奨する。良いプロンプト（または内部チェックリスト）は、エンジニアがデータベースを名前で挙げる前に数値と例示的なクエリを要求するべきです。

失敗モード3：データモデルのミスマッチ

LLMのよくある誤りは、製品データが本当にそのモデルに適合するかを検証せずにデータベースの“カテゴリ”を推奨することです。結果として、見た目は適合するが表現したい情報構造と闘うストアを選んでしまいます。

ミスマッチは通常リレーションシップから始まる

LLMはしばしばリレーションの深さやカーディナリティを見落とします：1対多か多対多か、ネストされた所有関係、共有エンティティ、ユーザーがそれらをどれくらい頻繁に横断するか。

ドキュメントDBは「ユーザープロファイル」に自然に思えますが、「任意のメンバーのロールが過去7日で変わったプロジェクトをすべて」や「コンプライアンス状態でフィルタした上での上位20タグ」など、エンティティ横断のクエリが頻繁であれば、単なるドキュメント取得では済みません。結合が頻繁なら、あなたは：

• アプリケーションコードで結合をシミュレートする（ラウンドトリップ増）か
• 大幅に非正規化する（ドキュメント間で重複）

のどちらかを選ぶことになります。

非正規化の隠れたコスト

重複は無料ではありません。書き込みの増幅、更新の整合性維持の困難さ、監査の複雑化、そしてどのコピーがソースオブトゥルースかという微妙なバグを生みます。LLMは非正規化を一度限りのモデリング選択のように扱いがちですが、実際は継続的な運用負担です。

サニティチェック：候補スキーマ＋キークエリ

LLMの推奨を受け入れる前に簡単な現実検査を行ってください：

1. 候補スキーマ（テーブル／コレクション／ノード）を主キーと重要な関係付きでスケッチする。
2. 製品がサポートする必須の5〜10個の「キークエリ」を書き出す（フィルタ、ソート、集計、エンティティ横断検索）。
3. このデータベースがそれらのクエリを、雄々しい非正規化や多段アプリ結合なしに自然かつ効率的に表現できるか問う。

モデルとクエリが噛み合わなければ、推奨は自信に満ちていてもノイズに過ぎません。

失敗モード4：トランザクションと整合性の盲点

LLMはしばしば「整合性」を好みの一つとして扱いがちで、製品制約として扱いません。そのため表面上は理にかなって見える（「スケールするNoSQLを使え」など）推奨が、実際のユーザーアクションで崩壊します。

原子性のギャップ：一連の更新が一緒に成功しなければならない場合

多くの製品フローは単一の書き込みではなく、複数の書き込みが全て成功するか全て失敗する必要があります。

決済は典型例です：チャージを作成し、請求書を支払済みにし、アカウント残高を減らし、監査記録を追記する。最初のステップが成功して後続が失敗すれば整合性が壊れ、ユーザーや財務が問題に気づきます。

在庫も同様です：在庫を予約し、注文を作り、可用性を更新する。トランザクションがなければスパイク時に過販売が起き得ます。

最終的整合性は「ユーザーが気にしない」と同義ではない

LLMは時に最終的整合性を「UIは後で更新されればよい」と同じように扱いますが、ビジネスアクションが乖離を許すかどうかが重要です。

予約の競合はその好例です：二人のユーザーが同じスロットを確保しようとしたとき、システムが両方を受け入れてから後で解決するなら、UXの改善にならず、カスタマーサポートや返金の問題を生みます。

欠落しがちな運用セマンティクス：冪等性、再試行、厳密に一度

トランザクションをサポートするDBであっても、その周辺ワークフローには明確なセマンティクスが必要です：

• 冪等性キー（「支払う」を二度押しても二重課金しない）
• 安全な再試行（部分失敗やタイムアウト下で安全に再試行できること）
• 厳密に一度の効果（または「少なくとも一度＋デデュープ」の明示的代替）

LLMがこれらを無視すると、通常の製品正確性を達成するために専門的な分散システム作業が必要になるアーキテクチャを推奨することがあります。

失敗モード5：テストなしの性能仮定

LLMは「速い」データベースを推薦しがちですが、速度はエンジンそのものの内在的特性ではなく、ワークロード、スキーマ、クエリ形、インデックス、ハードウェア、運用設定との相互作用です。

ワークロードの文脈なしに「速い」

何を速くする必要があるか（単一行読み取りのp99、バッチ分析、取り込みスループット、初回応答時間）を指定しなければ、LLMは人気のある選択にデフォルトします。

二つの製品がどちらも「低レイテンシ」を謳っていても、アクセスパターンは正反対かもしれません：一方はキー・バリューの参照、もう一方は多フィールドの検索＋フィルタ＋ソートです。

隠れた制約：インデックス、増幅、ホットパーティション

性能助言がずれるのはモデルが以下を無視するときです：

• インデックスの限界とトレードオフ：二次インデックスは読み取りを速くするが書き込みコストとストレージを増やす。システムによっては複合インデックスやオンラインでのインデックス変更に制約がある。
• 書き込み増幅：LSMベースのエンジンは単純な書き込みを多大なバックグラウンドコンパクションに変えることがあり、継続的取り込みでは重要になる。
• ホットパーティション：シャードやパーティション設計でも、トラフィックが狭いキー範囲に集中するとボトルネックになる（最新のテナント、今日の日付、人気アイテムなど）。

キャッシュ挙動とクエリ形

LLMはキャッシュで解決できると仮定するかもしれませんが、キャッシュは予測可能なアクセスポatternの時にだけ効果的です。大きな範囲をスキャンするクエリ、非インデックスフィールドでのソート、アドホックフィルタはキャッシュを外し、ディスク/CPUに負荷をかけます。

OFFSETページネーションとキーセットページネーションなど、クエリ形の小さな変更が性能結果を大きく変えることがあります。

小さなベンチマーク計画（推測よりはまし）

一般論に頼る代わりに、軽量で製品に即したテストを実行してください：

1. 代表的な3〜5クエリ（最悪ケースのフィルタやソートを含む）と1〜2種の書き込みパターン（定常＋バースト）を選ぶ。
2. 現実的なデータ量を使う（少なくともメモリを超える量。スキューとホットキーを含む）。
3. 読み取りと書き込みそれぞれの p50/p95/p99 レイテンシとスループットを測定する。
4. インデックスのバリエーション（インデックスなし、最小限、理想的）を試し、書き込みのオーバーヘッドを記録する。
5. 期待されるピークに近い同時性で実行し、CPU、ディスク、コンパクション、ロック/トランザクションのメトリクスを観察する。

ベンチマークがすべてを予測するわけではありませんが、LLMの性能仮定が現実に合っているかを素早く明らかにします。

失敗モード6：運用とコストの見落とし

LLMは紙上の適合（データモデル、クエリ形、スケーラビリティのバズワード）を最適化しがちで、本番で生き残るために必要な運用、障害復旧、そして実際の請求額を見落としがちです。

隠れた作業：バックアップ、復旧、マイグレーション

推奨は一貫したバックアップの取得方法、どれくらい速く復旧できるか、リージョン間のディザスタリカバリ計画に答える必要があります。LLMはこれらの詳細を飛ばすか、「組み込み」と仮定することがよくあります。

マイグレーションも盲点です。後からデータベースを切り替えるのは高価でリスクが高い（スキーマ変更、デュアルライト、バックフィル、クエリ書き換え）。製品が進化しそうなら「始めやすさ」だけでは不十分で、現実的な移行経路が必要です。

可観測性は製品の一部

チームはデータベースだけでなく、それを運用するためのツールを必要とします。

推奨がスロークエリログ、メトリクス、ダッシュボード、トレースフック、アラートを無視しているなら、ユーザー苦情が出るまで問題に気づかない恐れがあります。運用ツールはマネージドとセルフホスト、ベンダーごとに大きく異なります。

総コストは時間単価だけではない

LLMはインスタンスサイズに注目しがちですが、次の乗数要素を忘れないでください：

• ストレージ成長と保持
• IOPS/スループット料金とバースト制限
• 読み取りスケール／高可用性のためのレプリカ
• オンコール時間、インシデント対応、ベンダーサポート

チームに合わせたデータベースを選ぶ

チームが自信を持って運用できない「最適」なDBはたいてい最適ではありません。推奨はチームのスキル、サポート期待、コンプライアンス要件と整合するべきで、そうでなければ運用リスクが主要なコスト要因になります。

失敗モード7：過剰に複雑なマルチデータベース設計

LLMは時に「全てを一度に解く」ために次のようなスタックを提案します：Postgres（トランザクション） + Redis（キャッシュ） + Elasticsearch（検索） + Kafka + ClickHouse（分析） + グラフDB "念のため"。これは印象的に聞こえますが、製品初期では往々にして早すぎる設計で、価値より作業を増やします。

なぜ助言が間違うのか

マルチデータベース設計は安全策に見えます：各ツールがそれぞれの用途で「最良」です。しかし隠れたコストは、各ストアが追加するデプロイ、監視、バックアップ、マイグレーション、アクセス制御、インシデント対応と新しい障害モードです。

チームは配管のメンテナンスに時間を取られ、機能を出す時間が減ります。

ポリグロット永続化が正当化されるのはいつか

二番目（三番目）のデータベースが正当化されるのは、主要データベースがその要件を受け入れられない痛みを伴って満たす場合です。例えば：

• 検索の品質／レイテンシ要件が主要DBの範囲を超えるとき
• 分析ワークロードがトランザクション性能を著しく劣化させるとき
• スケールパターンが異なるストレージやインデックスモデルを要求するとき

具体的なクエリ、レイテンシ目標、コスト制約、運用リスクが分からないなら早計です。

ストア間の整合性と重複の罠

データが複数箇所に存在すると、次のような難しい問題が出てきます：ソースオブトゥルースはどこか？再試行や部分障害、バックフィルの間にどのように整合性を保つか？

重複データはバグも複製します——古い検索結果、食い違うユーザー数、"どのダッシュボードを見るかで違う" 会議。

実践的な決定ルール

コアのトランザクションとレポーティングに合う汎用DBから始めてください。第一DBがある要件を満たせないことが実証され、かつ同期・整合性・復旧のオーナーシップが定義できる場合にのみ目的別ストアを追加する。

複雑性ではなく脱出口を残すこと。

LLMのデータベース助言を検証するための実践チェックリスト

LLMは最初のドラフト生成に役立ちますが、仮説として扱い、以下のチェックリストで推奨を検証（あるいは棄却）してください。

1) 入力を明確化する（書き出す）

プロンプトを明確な要件に変換してください。書けないなら、モデルは推測している可能性が高いです。

• 製品のコアワークロードは何か：OLTP、分析、検索、時系列、メッセージング？
• 想定スケール：ユーザー数、書き込み/読み取り/sec、ストレージ成長、ピーク対平均比
• 非機能要件：稼働時間、マルチリージョン、コンプライアンス、予算、チームスキル

2) データとキーとなるクエリをモデリングする

実エンティティとその関係を下書きし、トップクエリとアクセスパターンを列挙する。

• 上位10件の読み取りと書き込みは何か？
• ピーク時に高速であるべきクエリはどれか？
• 何をインデックスし、結合し、集計し、検索する必要があるか？

3) 受け入れテスト（成功基準）を定義する

「速くて信頼できる」を測定可能なテストに翻訳する。

• トップクエリのレイテンシとスループット目標（p95/p99）
• 整合性とトランザクション要件（何を原子的に扱うか）
• 障害ケース：ノード喪失、ネットワーク分断、リージョンフェイルオーバー、バックアップ/リストア時間

4) 軽量なPoCを実行する

おもちゃの例ではなく現実的なデータ形状とクエリ混合を使ってください。代表データをロードし、クエリを負荷下で実行して測定する。

LLMが複数のDBを提案した場合、まずは最も単純な単一DBオプションを試し、それがなぜ不足するのかを示してから分割を正当化してください。

試行を早めたいなら、製品スライス（コアエンティティ数個＋主要エンドポイント＋重要クエリ）だけをプロトタイプする実践的なアプローチが有効です。Koder.ai のようなプラットフォームはここで役立ちます：チャットでワークフローを説明し、作業するWeb/バックエンドアプリ（一般的に React + Go + PostgreSQL）を素早く生成して、スキーマ、インデックス、クエリ形を反復できます。プランニングモード、スナップショット、ロールバックといった機能は、データモデルやマイグレーションを試すときに特に有用です。

5) 決定を文書化し「変更トリガー」を明記する

短い根拠を書いてください：なぜこのDBがワークロードに合うのか、どんなトレードオフを受け入れるのか、どのメトリクスが再評価を強いるか（例：持続的な書き込み増、未知のクエリタイプ、マルチリージョン要件、コスト閾値）。