データ基盤アーキテクチャの変遷：DWHからAIエージェントまで

データを貯めて処理する基盤の歴史

データウェアハウスの成立

データを分析のために貯める発想が形になったのは1990年前後です。
業務システムの中に埋もれて取り出せなかったデータを、分析専用の場所に集めてから使うという考え方を、2人の人物が逆の方向から体系化しました。

当時のデータウェアハウスの特徴は、次のとおりです。

• スキーマを先に決める（Schema-on-Write）。何を意味する列かを、データを入れる前に固める

• テラデータのような専用機に、数億円をかけて構築する

• 読み手は人間。経営会議の月次レポートを人が見て解釈する

• 硬く、高価で、変更に弱い

「意味づけされたデータだけが分析に使える」という前提は、この時点で完成していました。貯める前に、徹底して意味づけしておく時代でした。

データレイクとHadoop、そしてデータスワンプ（沼）化

2000年代後半、Webのログやクリックストリームが爆発的に増え、高価な専用機では受け止めきれなくなりました。

• 2006年：Hadoopがプロジェクトとして独立。GoogleのGFSとMapReduceの論文を下敷きに、安価な汎用サーバーを束ねた分散処理

• 2010年：ペンタホのジェームズ・ディクソンが、この上の置き場を「データレイク」と命名

• 思想の転換：Schema-on-Read。スキーマを後回しにし、生のまま貯めて、読むときに意味を与える

柔軟で安いこの方式は、裏目に出ました。

• 利点：形式を問わず、安く、柔軟に、とりあえず全部貯められる

• 欠点：誰が、いつ、どんな意味のデータを入れたか分からなくなる。カタログもガバナンスもないまま貯め続け、探すことも信じることもできない「沼」になる

意味づけを後回しにしたデータは、結局使えませんでした。
データスワンプと呼ばれるこの状態が、それを示しています。

クラウドDWHとELTへの転換

2010年代、舞台がクラウドに移りました。

• Amazon Redshift：2012年発表、2013年一般提供

• Google BigQuery：2010年発表、2012年に一般提供

• Snowflake：2012年創業、2015年に一般提供。ストレージとコンピュートを分離

Snowflakeの分離が転換を生みました。
データを貯める場所と計算する能力が一体で、分析を増やすには両方を一緒に拡張するしかなかった構造を切り離し、貯めるだけなら安く、計算が要るときだけ能力を足せるようにしています。変換の順序も変わりました。

• 従来（ETL）：変換して意味づけしてから倉庫に入れる

• 以後（ELT）：先に生のまま入れて、倉庫の中で変換する

私自身が実際に手を動かしてきたのは、このクラウドDWH以降の景色です。
貯めるコストがほとんど気にならなくなり、価値の重心は「どう貯めるか」から「貯めたものをどう意味づけするか」へ移りました。

モダンデータスタックとレイクハウス

変換を担ったのがdbtです。
2016年に出発したチームが、SQLで変換ロジックを定義しバージョン管理する道具として広めました。
役割ごとに道具を組み合わせる構成が、2018年頃からモダンデータスタックと呼ばれています。

• 取り込み：Fivetran、Airbyte

• 変換：dbt

• 格納：Snowflake、BigQuery

• 可視化：Looker、Tableau

道具が増えるほど、つなぎ目のコストと複雑さが膨らみました。
2023年頃からは、ツールが多すぎて全体を把握できない、コストが読めないという揺り戻しが起きています。
同じ時期、レイクハウスという統合も進みました。
Databricksが2020年から2021年に示した、安く柔軟なデータレイクと高品質なデータウェアハウスを1つにまとめる考え方です。

• テーブルフォーマット：Delta Lake（2019年）、Apache Iceberg、Apache Hudi。レイクの上にトランザクションと品質管理を持ち込む

• メダリオン：Bronze（生データ）、Silver（整形・統合）、Gold（ビジネス集計）と段階的に精錬する設計

• データメッシュ：ザマク・デガーニが2019年に提唱。データの持ち主を中央から各ドメインへ移す、組織の考え方

この基盤の変遷は、中央集権と分散、高品質と低コストの間を、振り子のように往復してきました。

データを意味づけする層の歴史

セマンティックレイヤーの系譜

構造化データの意味づけは、新しい話ではありません。

• 1991年：ビジネスオブジェクツが「ユニバース」を発表。テーブル名や列名を「売上金額」「顧客ID」に置き換え、SQLを書けない業務ユーザーでも扱えるようにした

• 2012年：LookerがLookMLを導入。意味づけをコードで管理する

• 2019年：Cubeが登場。BI製品に依存しない独立した層になる

• 2022年から2024年：dbtがセマンティックレイヤーをプレビューから一般提供へ

狙いは一貫しています。
「売上」の定義が部署ごとにバラつく事態を防ぎ、組織で1つの意味に揃えることです。
ただしこの系譜が扱えるのは、構造化データ、つまり表と指標の世界に限られていました。

AIエージェント時代の意味づけ

構造が変わったのは、読み手が変わったからです。
これまで意味づけされたデータの読み手は人間でした。
人間は雑なデータでも、文脈や常識で足りない意味を補って解釈できます。
AIエージェントが自律的にデータを読み、判断まで踏み込むようになると、この補完が効かなくなります。
AIは渡された意味以上のことを勝手に埋めないため、意味づけに求められる水準が一段跳ね上がりました。

対象も非構造化データへ広がりました。
文書、議事録、問い合わせ履歴、契約書、音声など、企業が持つデータの大半は非構造化のものです。
その意味づけは、構造化データのセマンティックレイヤーとは別の系譜から来ています。

• RAG：2020年、メタのパトリック・ルイスらが提示。外部の知識を検索して生成に足す

• ベクトルデータベース：Weaviate、Pineconeなど。意味の近さで検索する

• 知識グラフとオントロジー：1970年代の知識表現研究にさかのぼり、RDF（1999年）やOWL（2004年）として標準化。概念と関係を構造で表す

• GraphRAG：2024年、マイクロソフトが提示。検索にグラフの構造を持ち込む

構造化と非構造化では、意味づけの技術は起源から異なります。
整えた意味をAIに渡す標準も、まだ定まっていません。

• MCP：2024年、Anthropic

• OSI：2025年、Snowflakeが主導

• OKF：2026年、Google

文脈を供給する標準が、乱立している段階です。

この歴史をどう読むか

技術は振り子のように往復してきましたが、その裏では、データを誰に向けて、どこまで意味づけするかの重心が、一貫して動いてきました。

データウェアハウスの時代、意味づけの相手は人間で、対象は構造化データでした。
読み手はAIエージェントへ移り、対象は非構造化データまで広がっています。
意味づけの負担は、貯める側から使う側へ、人間からAIへと移りながら、増え続けています。

増え続けた意味づけを1枚で束ねる最上位の層は、まだ存在しません。
「コンテキストレイヤー」という言葉がここ1、2年で使われ始めましたが、定義は論者ごとにバラバラで、標準と呼べるものはありません。
名前が先行しているだけで、実体はまだ固まっていない段階です。

現実の企業は、もっと手前にいます。

• 大半の組織：そもそも非構造化データを意味づけしてAIに使わせる段階に到達していない

• 一部の組織：そこまで到達したが、頭打ちにぶつかっている

頭打ちの中身は共通しています。
社内の議事録やドキュメントを集約し、ある程度の意味づけをして、AIに聞けば答えが返るところまでは到達しました。
しかしそこから先に進めず、できあがったのは議事録に対する高度な検索システムでした。
AIが目的を持って分析し、判断やアクションまで踏み込む段階には届いていません。

検索で止まるのは、誰の、何のためかを定義せず、汎用的に意味づけしたからです。必要な意味づけは目的によって変わるため、同じ1つの契約書でも、部門によって抽出すべき項目や粒度が異なります。

抽出すべき項目も、分ける粒度も、付けるべき文脈も、三者で異なります。
問い合わせログも同じです。同じ顧客の「わかりにくい」という一言も、利用開始30日の顧客か、2年使い続けた顧客かという文脈が付いて初めて意味が変わります。素のテキストには、その意味はありません。
汎用的に一度だけ意味づけしたデータは、どの目的にも中途半端にしか応えられません。

順序は逆になります。

1. 目的を定義する。誰が、何の判断に、どのAIを使うのか

2. その目的に必要なデータを特定する

3. その目的にAIが応えるために必要な意味づけを、粒度も、抽出する項目も、文脈も、目的から逆算して設計する

この逆算を欠いたまま、とにかく集めて意味づけしようとすれば、かつてデータレイクが沼になったことを、今度は非構造化データで繰り返すことになります。

データ基盤の技術は、これからも新しい形を生み出します。
しかし、どんな技術が来ても、意味づけの負担は減らず、むしろ増え続けます。

この変化は、求められるスキルも動かします。
データを貯めて処理する技術は、これからも土台として必要です。
その上で価値の中心になるのは、目的を定義し、それに必要な意味づけを設計する力です。どのデータを、どの系統で、どこまで意味づけするかを決めるには、技術だけでなく、業務とデータの両方を理解して結びつける力が要ります。

次に来る技術を使い切れるかどうかは、その力を持つ人をどれだけ育て、配置できるかで決まります。