データ基盤の本質（メタデータ＋オブジェクトストレージ）と、法務・経理 AI 化への転用¶

作成日: 2026-06-27 出典 / きっかけ: 書籍『エンジニアのためのデータ分析基盤入門（実践編）』のローカル検証環境（~/data-platform-on-local）を触りながら、Metabase で Metastore を覗く作業から派生した議論。最終的に「法務・経理の AI 化推進に、メタデータ＋GCS でデータ基盤を組めないか」という自分のビジネス課題に接続した。関連: llmops_データ基盤からの転用_整理

0. 要点（3行）¶

データ基盤の価値はストレージ（器）ではなくメタデータ層（目録・統制）で決まる。「色々なデータ」を放置すると“沼”になり、メタデータが沼を「AI が安全に使える資産」に変える。
ローカル学習で掴んだ4層（実体=オブジェクトストレージ / 目録=Metastore / 束ね=Iceberg / 実行=Spark・Trino / 窓口=Metabase）は、そのまま GCP（GCS + BigQuery/BigLake Iceberg + Dataplex）のマネージド構成に写せる。
法務・経理は構造化（仕訳・請求）と非構造化（契約書・規程）が混在し、かつ監査・機密分類・アクセス制御（lineage/DLP/列行レベル権限）が必須。だから「メタデータをいい感じに」が他領域以上に効く。進め方は1ユースケースを縦に1本通す。

1. データ基盤の心臓部 — 「実体」と「目録」は分かれている¶

ローカル基盤を分解すると、各コンポーネントが「データの何を持つか」で役割が綺麗に分かれる。

コンポーネント	持つもの	例え
MinIO（=S3 互換ストレージ）	データの実体（Parquet 等のファイル）	倉庫
Metastore（Hive Metastore）	データのありか・形（どのテーブルがどこに・列は何か）	倉庫の台帳・目録
Iceberg	複数ファイルを1つのテーブルとして束ね版管理する形式	台帳と中身をつなぐ版管理者
Spark / Trino	何も保持せず、読みに行って計算する実行エンジン	倉庫の作業員
Metabase	何も保持せず、結果を見せるだけの人間向け窓口（BIツール）	受付の表示画面

MinIO(実体) → Metastore(目録) → Spark/Trino(実行) → Metabase(人が見る窓口)
   ↑ファイル        ↑どこに何が       ↑取りに行って計算      ↑画面

本質: 実行エンジン（Spark/Trino）も窓口（Metabase）もデータを持たない。実体は常にストレージにあり、目録（Metastore）が「どこに何があるか」を一元管理する。だからエンジンを跨いでも同じテーブルが同じ名前で読める（gld_mart.user_sales は Spark でも Trino でも通じる）。
Metabase は Spark/Trino をラップ（中で処理）しているのではなく、窓口。クリック操作を SQL に翻訳してエンジンに投げ、結果を描くだけ。速さ・スケールはエンジン側で決まる（Metabase をいくら速くしても変わらない）。

2. Iceberg の役割 — 「ファイルの山」を「ちゃんとしたテーブル」にする層¶

ストレージにあるのは結局ただのファイル群。Iceberg はそこに「表としての約束事」を被せるテーブル形式。

	素のファイル（Parquet を置くだけ）	Iceberg テーブル
今このテーブルはどのファイル群？	自分でフォルダ走査	manifest が常に正解を保持
書き込み途中の読み取り	中途半端が見える危険	スナップショット単位で原子的
列追加・改名	作り直し級	スキーマ進化（メタ更新だけ）
過去の状態	不可能	タイムトラベル
1行更新・削除	ファイル丸ごと書き直し	行レベルで可能

位置づけ: 実体（ファイル）はストレージに置いたまま、その上に版管理された表の層を載せる。Git がファイルに履歴を与えるのに近い。
Parquet と Iceberg はレイヤーが違う: Parquet＝「1ファイルの中身の形式」、Iceberg＝「複数ファイルを1テーブルとして束ねて版管理する形式」。
テーブル作成時、ストレージ上には data/（実データ Parquet）と metadata/（Iceberg のスナップショット・列定義）の2種ができる。この metadata/ のおかげで複数エンジンが同じテーブルを安全に同じ見え方で読める。

CSV はどう扱うか（重要な勘所）¶

「Iceberg が CSV もいい感じに見てくれる？」→ そのままは見ない。CSV は入口（材料）、Iceberg は取り込んだ後の整った棚で役割が違う。

道A（王道）: CSV を読み込んで Iceberg(Parquet) に変換して取り込む（＝medallion の Bronze 層）。以後は版管理・スキーマ進化・タイムトラベルの恩恵。
道B（直読み）: Trino/Spark の外部テーブル機能で CSV をその場で読む。手軽だが版管理・履歴は無い。これは Iceberg ではなくエンジンの役割。
設計指針: 使い込む層ほど Iceberg、入口は素のファイルでも可。「全部 Iceberg」ではなく、価値が出る所で Iceberg に“格上げ”する。
（CSV 直読みだけなら DuckDB 1個でも足りる。Iceberg が要るのは「大規模・複数人・複数エンジン・更新と履歴」が絡む時＝そこが導入の損益分岐点）

3. BigQuery でのラッピング — ローカル基盤のマネージド版¶

自前で組んだ各層を、GCP のマネージドサービスに畳める。

ローカルで自前	BigQuery 世界での担当
MinIO（実体）	GCS
Metastore（目録）	BigQuery / BigLake metastore
Spark/Trino（実行）	BigQuery エンジン（サーバレス）
Iceberg（形式）	BigQuery tables for Apache Iceberg（BQ 管理の Iceberg）
Metabase（窓口）	Looker Studio / Metabase をそのまま流用可

ラッピングの3パターン（実体をどこに置くかで選ぶ）¶

GCS に置いたまま BQ から読むだけ（External / BigLake テーブル） — CSV/JSON/Parquet/ORC/Avro/既存 Iceberg をその場で SELECT。「CSV もいい感じに見たい」はこれなら可。
BQ がオブジェクトストレージ上に Iceberg を書いて管理（BigQuery tables for Apache Iceberg） — 実体は自分の GCS に Iceberg 形式、書き込み・更新は BQ。medallion を BQ で組むなら本命。「自前 Spark で Iceberg を書く」を BQ に肩代わりさせる進化形。
完全 BQ ネイティブ管理テーブル — 一番ラク・速いが実体が BQ 内（外部エンジンから触りにくい＝ロックイン寄り）。
選び方: 他エンジン共有・ストレージを自分で握りたい → ①②（オープンな Iceberg/GCS）。BQ に閉じて手軽さ最優先 → ③。学習・移植性なら ② が正統な進化形。
コスト構造が別物: ローカルは「コンテナのメモリ取り合い」が制約。BQ はスキャン量課金 or スロット課金。“いい感じにラップ”の代償はクエリのスキャン量＝お金。パーティション・クラスタリング設計が、ローカルで言うメモリ管理に相当する勘所。
※ BQ の Iceberg 管理テーブル・Dataplex は機能の出入りが速い領域。実装検討時に GA 状況・対応形式・制約を公式ドキュメントで裏取りすること。

4. 法務・経理 AI 化への転用 — ここが本丸¶

なぜメタデータが他領域以上に効くか¶

法務・経理の「色々なデータ」は2種類が混ざる。基盤は「テーブルの倉庫」だけでは足りない。

種類	例	AI の使い方
構造化	仕訳・総勘定元帳・請求/支払・残高（ERP/会計SW 出力）	集計・異常検知・予測（テーブル分析）
非構造化	契約書・規程・稟議・議事録・メール（PDF/Word）	RAG・要約・条項抽出（文書 AI）

両方に共通で監査・アクセス制御・出所追跡（lineage）が必須 — これが法務経理ならではの重み（金融・取引所での内部統制・機密管理の経験がそのまま効く領域）。

GCP ネイティブ構成（ローカル学習の対応版）¶

[取り込み]  会計SW/ERP/契約管理 → GCS(landing: CSV/JSON + PDF/Word)
                                  │
[構造化]    GCS + BigQuery(BigLake Iceberg)         ← medallion をマネージド化
[非構造化]  Document AI で解析 → 埋め込み → Vertex AI Vector Search  ← RAG 用
                                  │
[メタデータ/統制] ★Dataplex(Universal Catalog)★
                 - カタログ（何がどこに・誰の・いつ更新）
                 - データリネージ（この数字の出所は？＝監査対応）
                 - 機密分類（DLP / Sensitive Data Protection で個人情報・機密を自動タグ）
                 - 品質ルール
                                  │
[アクセス制御] BigLake の 列/行レベルセキュリティ ＋ IAM（経理の限定開示・法務特権）
                                  │
[AI活用]    RAG エージェント / BigQuery ML / Vertex AI（要約・抽出・異常検知）
                                  │
[窓口]      Looker Studio / Metabase

「メタデータをいい感じに」= Dataplex が GCP での答え。ローカルで触った Metastore（目録）の、統制・監査・機密分類まで含んだ上位版。

法務・経理で絶対に外せない3点¶

リネージ（出所追跡） — 「この決算数値はどの仕訳から来た？」に即答。監査・説明責任の生命線。
機密分類＋マスキング — 個人情報・未公開情報を自動検出してタグ＆列マスク。AI に渡す前に機密を制御（RAG に契約書を入れる時に特に重要）。
アクセス監査ログ — 誰がいつ何を見たか。法務特権・経理機密は「見られた事実」自体が統制対象。

5. 進め方の指針 — 沼にしない順番¶

基盤を全部作ってからAI、ではなく 「1ユースケースを縦に1本」通す。

❌ 「全社データを GCS に集める」から始める → 沼化＆頓挫の典型。
⭕️ 1つの痛点を選び、そのデータだけ landing → Iceberg/RAG → 統制 → AI まで縦に1本通す。
候補例: 「契約書から更新期限・特約を抽出して一覧化」／「請求と入金の突合自動化」。
そこで Dataplex のカタログ登録・機密分類・lineage を最初から組み込む（後付けは地獄）。これが横展開の“型”になる。

6. 次アクション（候補）¶

A) 構成のたたき台を文書化 — 法務 or 経理どちらか1領域に絞った設計メモ（採用 GCP サービス・データフロー・統制要件）。
B) アーキ図を draw.io で起こす — landing → Iceberg/RAG → Dataplex → AI の構成図。
C) grill-me で要件を詰める — 「最初の1ユースケース」「データ源」「機密/監査要件」を対話で固めてから設計。← まずここで“縦1本”を1つに絞るのを推奨（決まれば A/B が一気に具体化）。

付録: ローカル検証で得た運用知見¶

検証環境（~/data-platform-on-local）は Docker 全体が約5.8GB に約10コンテナ同居で、Metabase 等が起動時に OOM kill されやすい。SparkSQL 経由で Metastore を見るだけなら airflow一式・keycloak・spark-history を止めて RAM を空ける（詳細はプロジェクトメモリ docker-memory-constraint 参照）。
Metabase の窓口性を実体験: Metastore が空だと当然何も見えない。テーブルは Airflow パイプラインが medallion 各層に作る設計。手動確認用に Iceberg テーブルを1個作る場合、Spark Thrift の warehouse がローカル既定なので LOCATION 's3a://local-data-platform/warehouse/...' を明示しないと書込不可で失敗する。

作成: 2026-06-27 ／最終更新: 2026-06-27