概要 ― AI時代の前提となるデータ整備 ― 生成AI時代のアーキテクチャ超入門

本記事について

当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「データアーキテクチャ」カテゴリ第1弾として、データアーキテクチャの全体像について解説する記事です。

「うちのデータを AI に学習させたい」が経営層の標準要望となった2026年、データをシステム横断で扱える形に整えているかがAI活用の前提条件として再評価されています。本記事ではOLTP/OLAPの分離、データの流れ、各データストアの選択肢、データアーキテクチャの巧拙がAI活用の上限を決める構造を俯瞰します。

このカテゴリの他の記事

データアーキテクチャが扱うもの

かつては「業務DB＝データアーキテクチャ」と同義で語られる時代もありましたが、現代は分析・機械学習・AI活用が当たり前になり、業務系（OLTP）と分析系（OLAP）の分離や、ストリーミング処理・データレイクといった概念が加わって、独立した設計領域として確立しています。

データはデジタル経済のガソリン。データ戦略の巧拙が、そのままビジネスの競争力を決める時代です。

なぜ独立したアーキテクチャとして扱うか

① 業務系と分析系で要求が根本的に違う

業務系は1件のトランザクションを速く・安全に、分析系は大量データを集計・分析。同じDBで両立させると両方の性能が落ちるため、構造を分けるのが主流です。

② データは組織を横断する

顧客データ・商品データは複数システムから参照されます。システムごとにバラバラの形で持つと、データが分断され、全社的な分析が不可能になります。

③ データの価値は蓄積で決まる

アプリケーションは作り直せますが、過去データは二度と手に入らない。最初の設計が雑だと、5年後にデータ活用したくても使えるデータが無い状態になります。

主要なデータの分類

分類	特徴	代表的な保存先
業務データ（OLTP）	取引・注文・顧客情報など、日々の業務で発生	RDB（PostgreSQL・MySQL）
分析データ（OLAP）	業務データを集計・分析用に加工したもの	DWH（Data Warehouse、Snowflake・BigQuery）
非構造化データ	画像・動画・ログ・文書など	オブジェクトストレージ（S3等）
イベントデータ	クリック・閲覧・センサー値などの時系列	ストリーミング基盤（Kafka等）

データ種別ごとに最適な保存先・処理方法が違うため、1つのDBで全て賄おうとすると破綻します。

データの流れ（典型的な構造）

業務システムから発生したデータが、分析基盤を経由して BI（Business Intelligence）ツール・機械学習に辿り着くまでの流れは、おおよそ次のパターンに収束しています。

flowchart LR
    OP["業務システム<br/>(OLTP)"] -->|生データ| DL["データレイク<br/>(S3 等)"]
    DL -->|ETL/ELT| DWH["データウェアハウス<br/>(BigQuery / Snowflake)"]
    DWH --> BI["BIツール<br/>(Looker / Tableau)"]
    DWH --> ML["機械学習基盤"]
    DWH --> AI["AIエージェント"]
    classDef op fill:#dbeafe,stroke:#2563eb;
    classDef store fill:#fef3c7,stroke:#d97706;
    classDef use fill:#fae8ff,stroke:#a21caf;
    class OP op;
    class DL,DWH store;
    class BI,ML,AI use;

データレイクは「生データをとりあえず貯める場所」、DWHは「分析しやすい形に整えたDB」、ETL/ELT（Extract/Transform/Load、抽出・変換・ロードの略）は「移動と変換の仕組み」、と覚えるのが最初の一歩です。

データストアの選択肢

種類	得意なこと	代表例
RDB（関係DB）	ACID整合性・複雑なJOIN	PostgreSQL・MySQL
KVS（Key-Value）	超高速な単一キー参照	Redis・DynamoDB
ドキュメントDB	JSON的な柔軟なスキーマ	MongoDB・Firestore
列指向DB（OLAP）	大量データの集計・分析	BigQuery・Snowflake
時系列DB	センサー・メトリクスの蓄積	InfluxDB・TimescaleDB
グラフDB	関係性の探索	Neo4j
ベクトルDB	類似検索・AI埋め込み検索	Pinecone・pgvector

決めるべきこと — あなたのプロジェクトでの答えは？

以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。

データストア・検索・キャッシュ

項目	選択肢の例
業務DB	PostgreSQL・MySQL・SQL Server
分析DWH	Snowflake・BigQuery・Redshift
データレイク	S3・ADLS・GCS
キャッシュ	Redis・Memcached
検索エンジン	Elasticsearch・OpenSearch
ベクトルDB	pgvector・Pinecone・Weaviate

データ連携・ガバナンス

項目	選択肢の例
ETL/ELTツール	dbt・Airflow・Dataflow
ストリーミング基盤	Kafka・Kinesis・Pub/Sub
データモデリング	スター / 第3正規形 / Data Vault
マスタ管理	集中MDM（Master Data Management）/ 分散SoR（System of Record）
データカタログ	DataHub・Glue・Collibra
アクセス権限	IAM（Identity & Access Management）/ Row-Level Security

筆者メモ — 「貯めたはずが使えなかった」事例

ある現場では、イベントログを「とりあえずJSONで貯めておいて後で分析しよう」と数年分蓄積していたものの、いざ使う段になると「フィールド名がバージョンごとに別物、タイムゾーンが端末依存でバラバラ、キー欠損の行が大量」にあり、ほぼ全てのレコードが再加工不能だった、という話がよく聞かれます。貯めること自体は成功しているのに、使える状態で貯めていなかったという典型パターンです。

別の事例では、業務DBと分析を同じPostgreSQLで動かしていたところ、夜間バッチの集計クエリが走るたびに日中の注文処理が遅延するという現象が発生。最終的に「DWHを後付け」する羽目になり、ETLの整備とダブルメンテ期間で半年を費やした、という話もあります。OLTPとOLAPを最初から分離していれば起きなかった工数です。

筆者も過去、PostgreSQL単一でBIダッシュボードも日次集計も走らせていて、月次バッチの日にサービス全体が重くなる現象を目撃した経験があります。いずれも「データの性格に合わない道具・構造で貯めてしまった」ことが根本原因。設計段階の判断が5年後の活用余地を決めるという事実を、外から見ても分かる形で突きつけた事例です。

データはアプリと違って作り直せない。5年後の資産として設計します。

データ量×用途の選定段階表

※ 2026年4月時点の業界相場値です。テクノロジー・人材市場の変化で陳腐化するため、定期的にアップデートが必要です。

データアーキテクチャはデータ量と鮮度要件で最適解が決まります。結論を先に言うと、1TBまではPostgreSQL単体で十分、10TBを超えたらDWHを分離、100TB超の領域で初めてレイクハウスとストリーミングが現実解になります。以下が業界標準の段階表です。

データ量	用途	推奨DB	鮮度要件	月額コスト目安
〜100GB	業務CRUD	PostgreSQL 単体	即時	数千円
〜1TB	業務 + 分析	PostgreSQL + リードレプリカ	日次OK	数万円
〜10TB	業務 + BI	Aurora + BigQuery / Snowflake	時間次	数十万円
〜100TB	データ分析中心	DWH（Snowflake）+ S3	分次〜秒次	数十万〜数百万
100TB〜	ML + ストリーミング	レイクハウス + Kafka + Flink	リアルタイム	数百万〜

「リアルタイムストリーミングは運用コスト10倍」が経験則です。業務要件の9割は日次バッチで足ります。「リアルタイム」と言われたらまず疑うのが実務の定石で、マイクロバッチ（15分サイクル）で足りるケースが多いです。

データアーキテクチャは規模と鮮度で段階的に進化。最初からリアルタイムを目指すのは過剰投資です。

データアーキテクチャ全体の鬼門

各論記事で触れた禁じ手のうち、データアーキテクチャレベルで押さえるべき核心を整理します。

禁じ手	なぜダメか
業務DBで分析クエリを実行	業務側性能劣化、顧客体感が落ちる。OLTP/OLAP分離必須
スキーマレスで雑にJSON格納	5年後にAI活用不能、型を最初から明示
UUID v4を主キーに大量挿入	インデックス局所性悪化、UUID v7（2024年RFC化）へ
外部キー制約を性能のために全削除	整合性破壊、孤立データ蓄積
バイナリ（画像・動画）をDB本体に格納	S3 + URL参照が鉄則、DB肥大化の定番
「いつか使う」で雑にS3に貯める	カタログなし沼化、加工コストが新規設計より高い
MDMを一気にCentralizedで目指す	既存基幹系停止の大工事、Coexistenceで段階統合
個人情報をマスキングせず分析DBへ	Meta 2023年 €1.2B 制裁金のパターン
ペタバイト級のストリーミングを専任SREなしで運用	2020年 AWS Kinesis事件のようにSPOFに
データカタログなしで運用	「このデータどこ？」で分析速度が1/10

データはアプリと違って作り直せない。5年後の資産として設計します。

AI時代の視点

AI駆動開発（バイブコーディング）とAI活用（RAG・エージェント）が前提になると、データアーキテクチャはAIに食わせやすい形で設計する重要性が跳ね上がります。AIモデルは整った構造化データと意味のあるメタデータを読んで精度が決まるため、データの整理度合い＝AI活用の上限になります。

AI時代に有利	AI時代に不利
スキーマ定義・型が明示されたDB	スキーマレスで雑なJSON格納
データカタログ・メタデータ整備	ドキュメントなし・属人化
ベクトルDB・RAG（Retrieval-Augmented Generation）前提の設計	古典的なRDBのみ
履歴保持・時系列追跡	上書き更新のみ

AIエージェントがデータを操作する時代になると、SQLで叩ける構造化データ・自然言語で理解できる命名・明確な権限制御が、人間の設計者向け以上に重要になります。

データアーキテクチャの巧拙が、そのままAI活用の上限になる時代です。

よくある勘違い

• 1つのDBで全部やれば楽 → 業務系（OLTP）と分析系（OLAP）を同じDBで回すと、両方の性能が落ち、気づいた時には両方の作り直しになります。最初から分離するのが合理的です
• スキーマレスで柔軟にすれば将来に対応しやすい → スキーマレスは便利に見えて、データ品質が制御できず、AI時代は「AIに読ませられない資産」になります。型定義を最初から明示するのが標準装備です
• データは取っておけば後で使える → 雑に貯めたデータは、後から「使えるデータが無い」状態を生みます。「何を・どの型で・どの粒度で」貯めるかを最初に決めないと、量があっても価値ゼロになります
• 分析は後から考えればいい → 業務系から分析系へのデータ流通（ETL/ELT）は、後付けで作ると既存DBへの負荷と手戻りが発生します。データレイク + DWHの構成を最初に決めるのが定石です

最終的な判断の仕方

データアーキテクチャの核心はアプリは作り直せるが、過去データは二度と手に入らないという非対称性を意識することです。5年後にデータ活用を始めようとした時に「使えるデータが無い」状態を避けるため、スキーマ定義・履歴保持・メタデータ整備を最初から組み込みます。業務系（OLTP）と分析系（OLAP）を早い段階で分離し、それぞれに最適な道具を選ぶのが合理的な出発点になります。

決定的な軸はAI活用の上限はデータの整理度合いで決まることです。AIエージェントがSQLで叩き、RAGでベクトル検索する時代、スキーマレスで雑に格納されたJSONは事実上使えない資産になります。型定義・データカタログ・ベクトルDB対応は贅沢品ではなく、AI時代の標準装備として設計に組み込む判断が求められます。

選定の優先順位

1. 業務系と分析系を分離 — 同じDBで両立させず、OLTPとOLAPの道具を分ける
2. スキーマと型を最初から明示 — スキーマレスで逃げず、将来のAI/分析活用の基盤にする
3. データ種別に合わせて道具を選ぶ — RDB / ベクトルDB / オブジェクトストレージを使い分け
4. メタデータとカタログを整備 — 人間にもAIにも読める形で管理する

「データアーキテクチャは5年後の資産」今日の整理が、将来のAI活用余地を決めます。

まとめ

本記事はデータアーキテクチャの全体像について、OLTPとOLAPの分離・データ種別ごとの保存先・データ量と鮮度の段階表・AI時代の標準装備まで含めて解説しました。如何だったでしょうか。

業務系と分析系を分離し、スキーマと型を明示し、データ種別に合った道具を使い分け、5年後の資産として設計する。これが2026年のデータアーキテクチャの現実解です。

次回はデータストア選定（RDB・KVS・列指向DB・ベクトルDB等の使い分け）について解説します。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

それでは次の記事も閲覧いただけると幸いです。