@tony_starkposted at 2026-06-08

AI時代、分析用DBと業務用DBの境界はなくなっていくと思いますか？

Q&A

最近、AI/LLM向けのデータ基盤を考える機会が増えてきました。ベクトル検索やRAG、リアルタイム分析などの要件が増え、ClickHouseのような分析特化型DBが「AIスタックの基盤」として注目されているのを感じます。

そこで気になっているのが、従来の「業務用DB（OLTP）」と「分析用DB（OLAP）」の使い分けが、これからどうなっていくのかという点です。

これまでは、

というように、役割で明確に分けるのが定石でした。

しかしAIの普及で、

といった「境界をまたぐ要件」が増えている気がしています。

そこで質問です。

設計思想の話でも、実際の構成事例でも構いません。みなさんの考えや経験をぜひ聞かせてください！

3 likes

2Answer

個人的には、「完全に統合される」というより、物理的には近づくが、設計上の役割分担は残ると思っています。

今のところ自分なら、基本は次のように分けます。

AI要件が入って変わった点は、「後で分析基盤に流す」だけではなく、アプリのデータをリアルタイムにAIへ渡す前提で設計するようになったことです。

例えば、

のような構成が現実的だと思います。

一方で、すべてを1つのDBに寄せすぎると、トランザクション性能、スキーマ変更、分析クエリの負荷、ベクトル検索のチューニングがぶつかりやすくなります。

なので将来的には、

「DBが1つになる」
というより、

「OLTP / OLAP / Vector / Search の境界を意識せず扱えるレイヤーが増える」

方向に進むのではないでしょうか。

アプリ開発者から見ると統合されて見えるけれど、内部では用途ごとに最適化されたエンジンが分担している、という形が一番自然だと思います。

2Like

業務用DBをそのままタイムラグなく分析に利用する需要は高まっています。その意味で業務データと分析データの境界線は溶けてなくなりつつあります（但し、個人情報のマスキングなどは残ります）。

一方で業務用DBと分析用DBは役割やアクセス者が異なります。同じ箱に閉じ込めることは危険な火遊びになりかねません。前者の高スループットOLTPも後者のクエリエンジンも各々専用に最適化することに優位性があります。

両者の架け橋にはCDC: Change Data Captureが有効です。業務DBの更新ログをほぼリアルタイムで分析DBへ反映します。データは同期され、お互いの領域を侵しません。

AIやベクトル検索についてはBigQueryやSnowflakeなどの分析DWHがベクトル検索やLLMの呼び出しをサポートしています。「データをAIモデル側に持っていく」のではなく、「データがある場所（DWH）でAIを動かす」構成が可能です。

1Like