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

本記事について

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

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

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

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

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

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

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

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

もしデータアーキテクチャがなければ、データがシステムごとにバラバラに閉じ込められ、全社横断の分析もAI活用も不可能になります。

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

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

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

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

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

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

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

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

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

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

主要なデータの分類

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

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

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

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

データストアの選択肢

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

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

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

データ連携・ガバナンス

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

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

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

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

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

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

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

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

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

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

このカテゴリの知識構造

このカテゴリは全7記事で構成されています。保存→構造→移動→統治の順に、データの扱い方を段階的に学ぶ構造です。

保存でまずデータの置き場（RDB・KVS・列指向・ベクトルDB等）を選びます。ここを間違えると、後段の全てに影響が出ます。

構造では、保存先が決まった上でテーブル設計（正規化やスター型等）と、業務系と分析系の基盤分離（DWH・データレイク）を設計します。

移動は、構造化されたデータを業務DB → 分析基盤へどう運ぶかの設計です。多くのプロジェクトではバッチ（ETL/ELT）で十分ですが、リアルタイム性が求められる場合にストリーミングが登場します。

統治のデータガバナンスは全体を横断するテーマで、カタログ整備・品質管理・アクセス権限の設計を扱います。AI時代にはメタデータの整備がAI活用の前提条件になるため、後回しにせず早期に着手する価値があります。

やってはいけないこと

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

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

AI判断軸

選定の優先順位

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

ベクトルDBとRAGがデータアーキテクチャの新しい層になった

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

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

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

まとめ

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

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

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

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

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

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