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

本記事について

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

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

このカテゴリの全記事一覧・各記事で学べるポイントは以下のページにまとめています。

データアーキテクチャ 記事一覧 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-index-data/

本記事のテーマについてさらに詳しく知りたい方は『データ視覚化のデザイン』・『システム設計のセオリーと実践方法がこれ1冊でしっかりわかる教科書』も参考にしてみてください。

そもそもデータアーキテクチャとは何か

会社の金庫と帳簿を想像してください。現金（業務データ）を安全に保管し、帳簿（分析データ）で経営状況を把握する──この2つは同じ「お金」を扱っていても、保管方法も使い方も全く違います。両者を混ぜると、日常の出し入れも決算もどちらも遅くなります。

データアーキテクチャは、データをどこに・どの形式で・どう流して保管するかを設計する領域です。業務系（OLTP）と分析系（OLAP）の分離、データストアの選定、データの流れの設計を含みます。

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

理由は3つあります。第一に、業務系と分析系で要求が根本的に違うこと。業務系は「1件のトランザクションを速く・安全に」、分析系は「大量データを集計・分析」で、同じDBで両立させると両方の性能が落ちます。第二に、データは組織を横断すること。顧客データ・商品データをシステムごとにバラバラの形で持つと、全社的な分析が不可能になります。第三に、データの価値は蓄積で決まること。アプリケーションは作り直せますが、過去データは二度と手に入りません。最初の設計が雑だと、5年後にデータ活用したくても使えるデータが無い状態になります。

主要なデータの分類と流れ

データ種別ごとに最適な保存先が違うため、1つのDBで全て賄おうとすると破綻します。典型的な流れは「業務システム → データレイク（生データをとりあえず貯める場所）→ ETL/ELT（移動と変換）→ DWH（分析しやすい形に整えたDB）→ BI・機械学習」で、この構造を覚えるのが最初の一歩です。データストアの個別選定（RDB・KVS・列指向・時系列・グラフ・ベクトルDB）は次回の記事で深掘りします。

どう選べばいいのか ― データ量×鮮度の段階表

※ 2026年4月時点の業界相場値です。

データアーキテクチャはデータ量と鮮度要件で最適解が決まります。

結論を先に言うと、1TBまではPostgreSQL単体で十分、10TBを超えたらDWHを分離、100TB超の領域で初めてレイクハウスとストリーミングが現実解になります。そして「リアルタイムストリーミングは運用コスト10倍」が経験則です。業務要件の9割は日次バッチで足り、「リアルタイム」と言われたらまず疑うのが実務の定石です。

このカテゴリの知識構造

このカテゴリは全7記事で、保存 → 構造 → 移動 → 統治の順に段階的に学ぶ構造です。

保存でまずデータの置き場（データストア選定）を選びます。構造では、テーブル設計（データモデリング）と業務系・分析系の基盤分離（データ基盤）を設計します。移動は業務DB→分析基盤への運び方（ETL/ELT・ストリーミング）です。統治のデータガバナンスは全体を横断するテーマで、AI時代にはメタデータの整備がAI活用の前提条件になるため、後回しにせず早期に着手する価値があります。

AI判断軸 ― データ整理度合いがAI活用の上限を決める

ベクトルDBとRAGが新しい層になった

LLMを活用するプロダクトでは、社内ドキュメントや過去のQ&Aをベクトル化して検索し、LLMの回答精度を上げるRAGパイプラインが標準構成になりつつあります。これに伴い、従来のRDB+オブジェクトストレージに加えて、ベクトルDB（pgvector・Pinecone等）がデータアーキテクチャの第三の層として定着しています。

スキーマ明示がText-to-SQLの前提条件

AIに「先月の売上トップ10を出して」と自然言語で質問してSQLを生成させるには、テーブルのスキーマ・カラムの意味・テーブル間の関係がメタデータとして明示されている必要があります。スキーマレスのJSON格納や命名が不明瞭なテーブルでは、AIが正確なSQLを生成できません。データカタログとメタデータの整備は、人間のためだけでなく「AIへの辞書」として機能します。

やってはいけないこと

各論記事で詳しく触れる禁じ手のうち、全体レベルで押さえるべき核心を6つに絞ります。

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

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

別の事例では、業務DBと分析を同じPostgreSQLで動かしていたところ、夜間バッチの集計クエリが走るたびに日中の注文処理が遅延する現象が発生し、最終的にDWHを後付けする羽目になってETLの整備とダブルメンテで半年を費やしました。いずれも「データの性格に合わない道具・構造で貯めてしまった」ことが根本原因で、設計段階の判断が5年後の活用余地を決めます。

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

以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。それぞれの詳細は配下の各論記事で扱います。

• 業務DB（PostgreSQL / MySQL等）と分析DWH（BigQuery / Snowflake等）
• データレイク（S3等）の要否
• ETL / ELTツールとストリーミング基盤の要否
• データモデリング方式（3NF / スター型）
• ベクトルDB（pgvector / Pinecone）の要否
• データカタログとアクセス権限の管理方法

まとめ

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

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

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

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

本記事で扱った内容の詳細は AWS データ分析サービス も合わせて参考にしてください。

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