クラシル｜社内の7割が使うデータ基盤を、データチーム2人で回すためにやったこと¶

作成日: 2026-08-08 出典 / きっかけ: KOH（吉川昂太）/ クラシル株式会社、SpeakerDeck（2026-08-07 登壇）関連: 意味層_enforced_cube_dbt_looker_整理 / 10x_data_contracts_データマネジメント_整理 / タイミー_dre_looker_adk_社内aiエージェント_整理 / メルカリ_socrates_データ基盤とマルチエージェント_整理 / ミラティブ_ashura_分析民主化aiエージェント基盤_整理 / aiエージェント時代のデータ基盤論争_意味層は要るか_整理

0. 要点（3行）¶

人を増やさず「所有権を配る」: データエンジニア2人で社内7割が使う基盤を回す解は、中央集権をやめ Data Owner モデル（意思決定する人＝そのデータの持ち主）で dbt モデルを利用者自身に作らせたこと。
効かせる要は「Tier で信頼度を階層化」: Tier1-2＝厳格管理のコア指標、Tier3＝自由なアドホック。ただし野放しの Tier3 はカオス（アドホックの連鎖参照）を生んだので、基準を満たしたものだけ Tier3 ssot_verified に昇格させ、AI が参照してよいのはそこだけにした。
核心の教訓: 「AI-Ready でも、モデル/メタデータをきちんと整備して正しく SSoT にしていくのが近道」。AI エージェント（Claude＋MCP）は魔法ではなく、下地の意味整備があって初めて効く。cf. aiエージェント時代のデータ基盤論争_意味層は要るか_整理

1. 課題 — 2人 vs 社内7割¶

利用者（∝依頼数）が多く、データエンジニアが足りない、という典型構造。「利用者(∝依頼数)が多く、それに対してデータエンジニアが足りない」。
社内の約7割が使う基盤を、データエンジニア2名で運用し続ける必要がある。
素直に人を増やす／全依頼を中央チームが捌く、はスケールしない → 運用モデルそのものを変えた。

※ 「7割」「2人」は登壇者の自社事例としての数値。

2. 中核 — 3本柱¶

2-1. Data Owner モデル（所有権を業務側へ配る）¶

全作業を中央集権化せず、業務ステークホルダ（主に PdM）にデータ所有権を割り当てる。
「意思決定する人が、そのデータの持ち主になる」。Data Owner がデータ品質・ビジネスメタデータ・ガバナンスに責任を持つ。
社内の SQL 利用者・認可された開発者が dbt モデルを自分で作る（セルフサービス化）。

2-2. Tier システム（信頼度で階層化）¶

モデルを重要度で分類し、信頼できるものとアドホックを混ぜない。

Tier	位置づけ	扱い
Tier 1-2	コア指標	厳格に管理
Tier 3	アドホック	柔軟。ただし野放しにすると危険
Tier 3 `ssot_verified`	基準を満たしたアドホック	AI が参照してよいのはここだけ

制約なしの Tier3 は「カオスが生まれた」— アドホックがアドホックを参照する連鎖などのアンチパターン。
対策として Tier3 ssot_verified（特定基準クリアで昇格）を新設し、AI エージェントの参照対象をそこに限定。信頼できる SSoT だけを AI に見せる。

2-3. AI エージェント＋評価（Claude＋MCP）¶

エージェントが利用者に適切なモデルを先回りで提案し、用語を統一、アドホックな選択を監視。
2種類の評価を回す:
モデル選択の正確性（正しいモデルを選べているか）
クエリロジックの正しさ（SQL の中身が正しいか）
👍/👎 フィードバックを全利用者から収集（感情スコア＋自由記述の説明文の両方）。改善ループの燃料にする。

利用者の質問
   ▼
AIエージェント（Claude + MCP）
   ├─ 適切なモデルを先回り提案（参照は Tier3 ssot_verified 以上に限定）
   ├─ 用語を統一・アドホック選択を監視
   ▼
回答 → 👍/👎＋自由記述 で評価収集
   └─ ①モデル選択精度 ②クエリロジック正しさ を継続評価 → 改善ループ

3. 技術スタック¶

レイヤ	採用
変換（Transform）	dbt
DWH	Snowflake
BI / 可視化	Lightdash（dbt 連携の OSS BI）
AI エージェント	Claude
ツール接続	MCP（Model Context Protocol）

4. 成果と残課題¶

うまくいっていること - 「2名しかいないデータチームでも運用し続けられている」。 - 高いアジリティを維持。

残る課題 - チーム間で採用度合いにムラがある。 - 似たモデルの重複が起こりうる。 - どのモデル/指標を使うべきか利用者が混乱しうる。

5. 核心的教訓¶

AI-Ready でも、モデルやメタデータの整備をきちんとして、正しく SSoT にしていくことが近道！

AI エージェント導入は「整備をサボる免罪符」ではない。むしろ AI に正しく参照させるための SSoT 整備（Tier 昇格基準） が本体。
所有権の分散（Data Owner）× 信頼度の階層化（Tier）× AI の参照範囲限定、の3点セットで「少人数運用」と「品質」を両立させている。

6. まとめ — この事例から持ち帰る手（＋他社比較）¶

状況	借りる手
データエンジニアが依頼数に対して不足	中央集権をやめ Data Owner（意思決定者＝所有者）へ dbt を委譲
セルフサービスでアドホックが乱立・カオス化	Tier で信頼度を階層化し、基準クリアのみ `ssot_verified` に昇格
AI エージェントに社内データを触らせたい	参照対象を検証済み SSoT に限定＋モデル選択/クエリロジックの2軸評価＋👍👎ループ
「AI 入れれば整備は要らない」と思いがち	逆。メタデータ/SSoT 整備こそ近道

他社事例との位置づけ: 「分析民主化＋AI エージェント」は各社が模索中。ミラティブ Ashura（ミラティブ_ashura_分析民主化aiエージェント基盤_整理）、メルカリ Socrates（メルカリ_socrates_データ基盤とマルチエージェント_整理）、タイミー DRE（タイミー_dre_looker_adk_社内aiエージェント_整理）が近い。クラシルの固有性は 「Tier×AI参照範囲の連動」と「2人運用」という制約下での割り切り。意味層/契約の議論は意味層_enforced_cube_dbt_looker_整理 / 10x_data_contracts_データマネジメント_整理と接続する。

一言で: 「人を増やす」でも「AI に丸投げ」でもなく、所有権を配り・信頼度を階層化し・AI の参照を検証済み SSoT に絞る。少人数でスケールさせる型として筋がよい。

参考リンク¶

原典（SpeakerDeck, KOH/吉川昂太, クラシル, 2026-08-07） — https://speakerdeck.com/koh_yoshi/she-nei-no7ge-gashi-udetaji-pan-wo-detatimu2ren-dehui-sutameniyatutakoto
Lightdash（dbt 連携の OSS BI） — https://www.lightdash.com/
dbt — https://www.getdbt.com/ / Snowflake — https://www.snowflake.com/

作成: 2026-08-08 ／最終更新: 2026-08-08