概要LLMをデータ基盤につなぐとき、いちばん大事なのは何でしょうか。

モデルの精度でしょうか。 チャットUIの使いやすさでしょうか。 それとも可視化の美しさでしょうか。

どれも大切ですが、土台としてもっと重要なのは、AIに見せるためのデータ構造を分けることです。

今回のPoCで見えたベストプラクティスは、とてもシンプルでした。

  • raw：原本とPIIを保持する

  • meta/core：整形・履歴を持つ

  • mart：AIやBIに渡す指標を固定する

  • ＋1：AI専用の公開View層を作る

この記事では、この「3層＋1」の考え方を、BigQuery × LLM 活用の観点から整理します。

なぜ「3層だけ」では足りないのか

従来の分析基盤では、ざっくり次の3層で十分なことが多くありました。

  • raw

  • core / meta

  • mart

しかし、LLMや会話型BIをつなぐと事情が変わります。

なぜなら、mart は人間の分析者向けに作られていても、AIにそのまま見せてよいとは限らないからです。

  • 列が多すぎる

  • 意味の近い指標が混在している

  • 自由記述列が残っている

  • 一部に再同定リスクがある

  • コストの高い明細粒度が混在している

そのため、mart の上にもう1枚、AI参照専用の公開面が必要になります。

資料でも、Looker / MCP / DEV は mart を直接見ず、用途別の公開Viewを参照する構成が示されていました。

3層＋1の全体像

この構成は、PoCの実データ構成ともほぼ一致しています。raw にPIIがあり、secure_identity に source_customer_id ↔ person_id の対応表を置き、meta以降は person_id で分析、最終的に Looker 用と MCP 用の serving dataset を分けています。

Layer1: raw

raw は原本保管の層です。 氏名、住所、電話番号、メールアドレスのようなPIIを保持するのはここだけにします。

ポイントは、AIやBIに見せる前提で作らないことです。

raw の役割は、あくまで原本の受け皿です。 取り込み品質、欠損補完、履歴保持、監査可能性を優先します。

AIから触れさせないことが大前提です。

Layer2: meta / core

ここは整形や履歴管理の層です。 ソースの粒度差を吸収し、分析で使いやすい形に整えていきます。

PoC資料でも、meta 層には顧客ディメンションや来店ステージングのような中間整形テーブルが置かれていました。PIIはここでは扱わず、person_id や性別、年代帯、都道府県、来店情報など、分析可能な属性に寄せています。

ここでの役割は、分析の土台を整えることです。 ただし、まだAIに直接見せる層ではありません。

Layer3: mart

mart は、AIにもBIにも渡せるように、指標を固定していく層です。

資料では、kpi_daily_store、kpi_daily_treatment、kpi_daily_segment、customer_summary など、指標のまとまったテーブルが想定されています。

ここで大切なのは、LLMが誤解しにくい形にすることです。 具体的には、資料でも以下がタスクとして整理されています。

  • KPI テーブルを 1〜2本に固定する

  • 粒度を日次/週次などで揃える

  • description に定義や単位を埋める

  • パーティション/クラスタでスキャン量を抑える

つまり、mart は「人間が便利に使える表」ではなく、AIが安全に誤読しにくい表に寄せていく必要があります。

＋1: AI/BI serving

ここが、AI時代に追加すべきレイヤです。

資料では、looker_serving、mcp_serving_bi、mcp_serving_dev のように、用途別の公開View層が切られていました。BI用とDEV用でdatasetを分ける構成まで含まれています。

この層の役割は明確です。

  • AIに見せてよい列だけを出す

  • AIに見せてよい行だけを出す

  • 用途別に公開面を変える

  • mart直結を避ける

  • コスト爆発しにくい集計面を作る

言い換えると、AI用のDMZ です。

この1層を置くだけで、会話型分析の安全性と運用性が大きく上がります。

擬似ID設計がカギになる

3層＋1を成立させるうえで、最重要の技術要素のひとつが擬似IDです。

資料では基本ルールとして、

  • AI参照領域には PII を入れない

  • 結合キーは person_id に統一

  • source 側のIDはAI参照領域から排除

  • 再同定時のみ隔離領域の対応表を使う

という整理でした。さらに、person_id の作り方として、UUID方式と HMAC による決定的ID方式が整理されています。

これは、AIに「考えさせる自由」を与えながらも、本人特定に近い経路を断つための重要な設計です。

3層＋1があると何が変わるか

1. 会話型分析を安全に始めやすい

AIに raw や id_map を見せなくてよいので、PoCのハードルが下がります。 実際にPoCでも、MCPからは公開Viewだけを参照し、自然言語 → SQL → 結果表 → グラフまで動作確認ができています。

2. Looker と MCP を両立しやすい

同じ mart を土台にしつつ、Looker用とMCP用で公開面を分けられます。 PoCでも、Looker と MCP の両方で同等集計を返せることが確認されていました。

3. 運用ガードレールを置きやすい

AI参照先を 1 dataset に絞れるので、IAM、監査、bytes上限、返却上限などをまとめて考えやすくなります。資料でも、PIIなし前提のガードレールとして、参照先限定、ログ保存、上限制御が整理されています。

BigQueryで実際に何を整備すべきか

3層＋1を作るうえで、BigQuery側の実務タスクは次の通りです。

  • raw のPII列を棚卸しする

  • source ID と person_id の変換方式を決める

  • meta/core で person_id ベースの整形に寄せる

  • mart のKPIテーブルを固定する

  • mcp_serving / looker_serving の View を作る

  • 列説明、単位、定義を埋める

  • 監査ログとコスト制御を整える

資料の工数感では、共通のデータ基盤整備だけでもおおむね 9〜25 人日規模です。

つまり、3層＋1は「構成図をきれいにする話」ではなく、AI活用を本番に持ち込むための現実的な整備項目です。

どこから始めるべきか

最初から全部やる必要はありません。 小さく始めるなら、次の順がよいと思います。

  • まずは mart を 1〜2本に固定する

  • 次に mcp_serving_bi のようなAI参照Viewを作る

  • person_id と id_map を分離する

  • Claude Code や Looker Studio Pro でPoCする

  • 本番化時に自社UIやMCP運用を拡張する

資料でも、Looker×Gemini、Claude×MCP、自社UI×MCP の3案が示されており、小さく始めて段階的に運用へ広げる考え方が取られていました。

まとめ

AI対応型データ基盤では、従来の3層構造だけでは足りません。

raw、meta、mart に加えて、 AI/BIに見せるための公開View層を置く。

この「3層＋1」があることで、

  • PIIを隔離できる

  • 擬似IDで安全に分析できる

  • 会話型分析を始めやすい

  • Looker と MCP を両立できる

  • 運用ガードレールを置きやすい

というメリットが得られます。

LLM時代のデータ基盤は、ただ賢いAIをつなぐ基盤ではありません。 AIが安全に触れられる面を設計する基盤です。

BigQuery でLLM活用を進めるなら、まずは3層＋1で考えてみるのがおすすめです。