Upgrade to Pro — share decks privately, control downloads, hide ads and more …

組織全員で向き合うAI Readyなデータ利活用

Avatar for harry harry
October 28, 2025

組織全員で向き合うAI Readyなデータ利活用

2025-10-29
大規模データ×AI活用の現在地
〜 Online Conference 2025 〜

https://findy.connpass.com/event/369571/

Avatar for harry

harry

October 28, 2025
Tweet

More Decks by harry

Other Decks in Technology

Transcript

  1. AI Ready とは? 多くの科学技術と同様、AI も社会に多大なる便益をもたらす一方で、その社会への影 響力が大きいがゆえに、適切な開発と社会実装が求められる。AI を有効に活用して社 会に便益もたらしつつ、ネガティブな側面を事前に回避又は低減するためには、我々 は AI

    に関わる技術自体の研究開発を進めると共に、人、社会システム、産業構造、 イノベーションシステム、ガバナンス等、あらゆる面で社会をリデザインし、AI を有 効かつ安全に利用できる社会を構築すること、すなわち 「AI-Ready な社会」 への変 革を推進する必要がある。 出典:内閣府「人間中心のAI社会原則」 (2019年3月)
  2. AI Ready なデータ利活用とは? AI を有効に活用して組織に便益もたらしつつ、ネガティブな側面を事前に回避又は低 減するために、あらゆる面で組織をリデザインし、AI を有効かつ安全に利用できる社 会を構築すること、すなわち 「AI-Ready なデータ利活用」

    への変革を推進する必要 がある。 ・ 人間によるOpsが最低限回っていなければAI活用はできない ・ 人間の能力を超越したAI活用は人間には扱えないというスタンス ・ 「なんかAIが自律してやってくれました!」に競合優位性はない ・ AIを活用するためにはガードレールがなければならない ・ 自働化やHuman In The Loopをできる体制こそが競合優位性を生む
  3. 浮かび上がってきた3つの課題 1. データのサイロ化 ・ クラシル(Snowflake)とリワード(BigQuery)で分断 ・ ユーザーの横断分析ができずビジネス機会損失に 2. SQLクエリが価値を生まない ・

    SQLを書けるのが強みな反面、同じ指標の重複クエリが量産 ・ SSoT(Single Source of Truth)がなくロジックも属人的 3. 組織がスケールしない ・ データエンジニアがボトルネックに ・ 知識が属人化し、重要なところにのみ投資
  4. 根本的な問題 アジリティ vs ガバナンスのトレードオフ アジリティ重視の場合 ・ 各チームが自由にSQLクエリを作成 → 速く動ける ・

    しかし、データ品質が担保されない ・ 同じ指標でも結果が異なる → 意思決定の信頼性が低下 ガバナンス重視の場合 ・ データエンジニアが厳格に管理 → 品質は保てる ・ しかし、すべてのリクエストを処理しきれない ・ ボトルネックが発生 → スピードが犠牲に AI活用以前に、この問題を解決する必要があった
  5. Lightdashとは? dbtネイティブなオープンソースBIツール 分析の柔軟性: ・ SQLが書ける: Redashのように自由にSQLでアドホック分析が可能 ・ セルフサービス分析: ボタンポチポチでSQL不要の分析も可能 dbtとの統合:

    ・ Write Back to dbt: 作成したクエリをdbtモデルへ自動変換 ・ dbtでセマンティクス管理: メトリクス定義をdbtで一元管理 ・ メタデータの自動読み込み: dbtのドキュメント・テストを自動反映 実現すること: ・ Redashの柔軟性 + dbtの品質管理 = データライフサイクルの高速化
  6. 解決策その2 Tier定義による段階的なデータガバナンス Tier 用途 責任者 品質要件 メタデータ TTL AI Tier

    1 監査・公表 DE 全テスト 完全 永続 ✓ Tier 2 経営KPI DO 全テスト 完全 永続 ✓ Tier 3 部門KPI DO, Dev 基本テスト 完全 永続 ✓ Tier 4 アドホック DO, Dev dbt化 最低限 90日 ✗ Tier 5 個人試行 DO, Dev SQL 不要 30日 ✗ 補足: DE=データエンジニア、DO=データオーナー、Dev=開発者
  7. Tierの昇格プロセス Lightdashでデータライフサイクルを回すことで品質が向上 Tier 5 (個人試行) ← LightdashでSQLを自由に書いて探索 ↓ 有用性が確認されたら Tier

    4 (アドホック分析) ← Write Back to dbtでdbtモデル化 ↓ 継続的に使われる、重要度が上がる、セマンティクスを育てる、不要なものは削除 Tier 3 (部門意思決定) ← テスト追加、メタデータ整備 ← AI利用可能! ↓ 全社的に重要 Tier 2 (経営KPI) ← データオーナーが管理 ↓ 外部公表が必要 Tier 1 (監査・外部公表) ← データエンジニアが厳格管理 Lightdashの役割: 探索→資産化のサイクルを自動化し、メタデータ・品質向上を促進
  8. 今後の展望 ・ DataOpsのAI活用の切り分け ・ データ製品が自律化してきているDataOpsの工数も下がる可能性 ・ Semanticsの管理 ・ Open Semantic

    InterchangeなどでDataOpsの工数も下がる可能性 ・ 組織へのSnowflake Intelligenceの本格導入 ・ 今の取り込みだけで考えると分析に関するポジティブなBreaking Changesが起き る期待感