AI Agent と正しく分析するための環境作り

レバテックLAB 様主催「AI-Readyなデータモデリング ― メタデータ整備とロジック保守の仕組化」での登壇資料です
イベントURL：https://levtechlab.connpass.com/event/389515/

Transcript

1. AI Agent と正しく 分析するための環境作り AI-Ready なデータモデリング ― メタデータ整備とロジック保守の仕組化 Speaker Ubie株式会社 / Shunya Yoshikawa
2. 0 0 / I N T R O 自己紹介 所属 Ubie株式会社Data Engineer 最近の業務 全社データ基盤の設計・運用 AI Agent 活用に向けた整備、データプライバシー 今日お話しすること - AI AgentとModelingにおける各種使い分け - Data Engineer / Analytics Engineerは何をすべき？ - 事例は細かい内容も含みますが外観を掴んでいただければと Shunya Yoshkawa Data Engineer @yosh_yumyum 02 / 36
3. Ubie について 03 / 36
4. 04 / 36
5. 05 / 36
6. 06 / 36
7. 07 / 36
8. 08 / 36
9. 0 0 / I N T R O 今 日 の 問 い Q AI Agent にデータ分析を任せるとき、 何が本当のボトルネックか？ 09 / 36
10. 0 1 / 業 界 動 向 データ分析の現在地(dbt Labs より) AI の性能は伸び続けている一方、信頼性が課題。仕組みの整備が追いついていない dbt Labs『State of Analytics Engineering 2026』 AI 分析アウトプットの加速が、信頼・ガバナンス整備を追い越してい る AI 活用は分析アウトプットの生成 (72%) に集中、 基盤の保守・運用 (24%) は後回し 71% が「ハルシネーション結果がステークホルダーに届くこと」を最 大懸念 Semantic Layer の整備は信頼性向上に着実に寄与。精度 100%になる という結果も？ 参考 dbt Labs『State of Analytics Engineering 2026』 — getdbt.com/resources/state-of-analytics-engineering-2026 　 dbt Developer Blog, Semantic Layer vs Text-to-SQL 2026 — docs.getdbt.com/blog/semantic-layer-vs-text-to-sql-2026 10 / 36
11. 0 1 / 業 界 動 向 Text-to-SQL vs Semantic Layer AI モデルが進化しても、Semantic Layer の精度の差は Text-to-SQL を凌駕している Semantic Layer は 2023 → 2026 のベンチマークでも Text- to-SQL を上回り続けている （カバー範囲内では精度 100%） Text-to-SQL が外す時は「もっともらしい間違い」を返す、 Semantic Layer は「答えられない」と返す いつかAI modelがもっと賢くなって差も縮まるかもしれない が、ハルシネーションが生じる構造は変わらないままかもし れない。AIが賢くなるのを待つだけではいられない 参考 dbt Developer Blog, Semantic Layer vs Text-to-SQL 2026 — docs.getdbt.com/blog/semantic-layer-vs-text-to-sql-2026 11 / 36
12. 0 1 / 業 界 動 向 BI ツール（Lightdash）も AI-Ready に進化している AI を載せる → AI に信頼できるものだけ渡す → AI が基盤を自律的に整える ― 同じ進化軸を辿っている Recap ― BI 側だけでなく data stack 側のエコシステムも、AI-Ready への習熟が進んでいる 〜 2026 Agentic BI セマンティックレイヤーを土台に、 AIが「BIを作る・直す・運用する」 2026 / 04 Verified Charts & Dashboards 検証済みコンテンツでContext設計 がやりやすく 2026 / 05 Autopilot / Data Apps broken / stale contentsを自動検知 / リッチな可視化 参考 Lightdash 公式 — lightdash.com/agentic-bi / verified-content / autopilot 13 / 36
13. C H A P T E R · 0 2 Ubieの分析では AIをどう活用しているか？ 14 / 36
14. 0 2 / U B I E の 使 い 分 け Ubie における「AI × 分析」の変遷 内製からエコシステム活用へ 時期 取り組み 役割・狙い ~ 2024 社内 AI プラットフォーム★1 Slack 経由で呼べる汎用なAI基盤 2025 春 社内分析支援エージェント on 社内AI プラットフォーム SQL 生成・実行を社内プラットフォームへ統合 2025 中盤 分析自動化ツール (Pydantic AI)★2 定義済みプロダクトメトリクスからインサイト抽出 2025 後半 ~ Lightdash AI Agent / Claude Skills 活用 エコシステム成熟に伴い内製ツール・プラットフォーム からの移行 ★1 社内 AI プラットフォーム ― zenn.dev/ubie_dev/articles/6fd1dd202c0e07 ★2 Pydantic AI で構築した分析自動化ツール ― zenn.dev/ubie_dev/articles/64cf285988ebe8 15 / 36
15. 0 2 / U B I E の 使 い 分 け Claude Skillの活用― 二つの戦略へ 成熟プロダクト / 領域 Semantic Layerを選ぶClaude Skill 成熟度が高くデータ信頼性も求められる事業を念頭に。 共通指標層・メタデータ・ガバナンスを土台に据える。 - 開発時間は少しかかるが、安定かつ信頼性して使える共通基盤に - Claude Skills/Plugins にナレッジを寄せるだけでなく、dbt/Lightdash Semantic Layerへ移行も PoC プロダクト / 領域 Text-to-SQLなClaude Skill 仮説検証フェーズで1日単位で目まぐるしく変わる事業を念頭に。 全社配布のClaude Skill でナレッジを素早く伝達・素早く分析サイクルを。 - 事業が育ちステークホルダーも増え要求が高まれば、徐々に Semantic Layer 側 へ寄せていく - メタデータのハードコードなど負債も一時的に許容 UbieではClaudeが全社員に配布されている。分析の入り口としてフェーズにあったデータ整備・Agent開発のenablingを 16 / 36
16. C H A P T E R · 0 3 実際にどう基盤整備をしてきたか？ 17 / 36
17. 0 3 / S E M A N T I C L A Y E R × D R L 出発点 ― 認識を合わせるところから始めた データ基盤の役割が変わる 従来 人間が分析する場 ・人間が解釈できる品質、わからないことはData OwnerかGit blame で人づてに聞くことも ・メタデータやメトリクス定義は各種ドキュメントに分散、コンテキ ストを都度人が与えてAIが探しに行く ・利用はしているが、活用しきれていないデータ/dbt modelの散在 → これから AI が自律的に活用する場 ・AI が解釈できる品質、AIがアクセスできないなら無いのと同等 ・メタデータやメトリクス定義は基盤に統合 or Skillsに集約など、シ ステム境界を人間が設計し、AIが自律して探しやすく ・AI Readableの上で、不要なデータはノイズ。壊しやすく安全な modelが載せられる基盤を 既存基盤との主なギャップ ― 信頼できるメトリクス定義の散在 / メタデータ不足 / 利用状況が不明なモデルの蓄積。 このギャップを埋める活動として、プロジェクトを発足した。 18 / 36
18. 0 3 / S E M A N T I C L A Y E R × D R L 前 提 前提 ― データアクセスとプライバシーは厳密に管理した上で Secure by Design な基盤 AI Agent 活用 本編 上層 データ信頼性 / モデリン グ 本編 中層 アクセス・プライバシー 管理 本スライドの内容（下層 = 土台） ↑ 今日の話は中層・上層 AI→賢く超ハードワークな新入社員によって、セキュリティリスクの発見速度・リスクも増幅。運用ではなくデザインレベルでカバーを 機密度に応じてデータを分類し、取扱範囲・アクセス権限を段階的に分離 データ種別によって、用途・参照範囲・参照可能期間を明示的に管理 AI Agent からのアクセスも、人と同じアクセス制御の枠内に組み込む 利用ログを残し、誰がどのデータを参照したかを追跡可能にする 機密度の異なる領域は、別パイプライン・別権限で扱う 19 / 36
19. 0 3 / S E M A N T I C L A Y E R × D R L AI Agent との対話で、データ整備を検証する 共通指標層を整備しつつ、AI Agent との対話で不足箇所を炙り出す ― 社内に複数の特化型 Agent が生まれている モ デ リ ン グ ― 3 層 責 務 LAYER 1 Staging(interface層) 開発者向けのinterface。アプリケーション都合のmodelingを吸収し透過的にデータを使えるよう 正規化、renameなどが責務 LAYER 2 共通指標層(data component層) ドメイン単位の fact / dimension に指標ロジックを集約 LAYER 3 Mart(data mart層) 分析利用者向けのinterface。componentの組み立て(JOIN)が責務になるように Lightdash AI Agentsと の 対 話 で 活 用 し つ つ 整 備 を 検 証 STEP 1 AI Agent に問い合わせる 「ある機能の組織別利用数推移を集計してください」など STEP 2 不足箇所を炙り出す 「どのカラム / モデルでは判断できない」=整備不足のシグナル STEP 3 改善 → 再検証 表記揺れ吸収 / ai_hint 付与 / 未定義指標の追加 社内に複数の特化型 AI Agent が生まれ、それぞれの業務領域で利用されている。 参考 Ubie テックブログ, 2025/12/15 — zenn.dev/ubie_dev/articles/62844730189eb1 20 / 36
20. 0 3 / S E M A N T I C L A Y E R × D R L Lightdash AI Agents の最新ベスプラ 公式ドキュメントが推奨する 5 軸のベスプラ ― Lightdashに限らず、Agent設計Modelingの参考に 軸 内容 特化型で設計 汎用 1 体ではなく、ドメイン領域ごとに専用 Agent データを丁寧にドキュメント化 名前 / 説明 / 例題 / AI hints をモデル・ディメンション・メトリ クス各レベルで Verified Answers 良いチャート・ダッシュボードを「verified」と印付け、Agent に学ばせる Evaluations thumbs-downでフィードバックを蓄積、回帰テスト的に自動実 行 効果的な instructions 業界用語 / 伝え方 / 業務制約 / 分析プリファレンスなど横断なド メイン知識を Agent に教える Ubie の 取 り 組 み と の 接 続 「特化型で設計」 社内に複数 Agent が生まれている流れと整合 「ドキュメント化 + AI hints」 メタデータ自動生成と接続 「Verified / Evaluations」 今後の方向性として位置付け可能 参考 Lightdash Docs, Best practices for AI agents — docs.lightdash.com/guides/ai-agents/best-practices 21 / 36
21. 0 3 / S E M A N T I C L A Y E R × D R L 整えてみて分かった難題 全てを整える続けるのは難しい モデリングガイドライン整備、活用事例の創出、不要モデルの片付けをする中、整えるだけでは届かない領域が見えてきた: 01 組織構造上、規律の徹底度にばらつきが 出る 事業の変化・チーミングの変化が激しく、ガイド ラインを敷いても完全には解消されない。中央のル ールが、各チームに同じ濃度で浸透しきらない。 02 全データを同じ濃度で品質づけしようと すると、持続不能 リソース有限な中、 すべてのテーブルに同じ投資をかけると結局どこも 届かない。 「全部を高品質に」が目的になることはない AIで全部なんとかする、もまだ遠い 03 データごとの品質・信頼性への要求が明 確でない 基盤的な「十分」の基準と、運用での「必要」の 基準のすり合わせ不足。 整備の到達点と実務での要求のミスマッチ。 → データに濃淡をつけて対応していく必要がありそう 22 / 36
22. 0 3 / S E M A N T I C L A Y E R × D R L データに等級を付け、Tier1 から守る 全てを分類するのではなく、AI が一番触る上位（Tier1）に絞って守る アセスメント結果 → 濃淡をつけた品質コントロールが最優先 HOW：データ信頼性レベル (DRL) ― 最上位を Tier1 と定義 TIER 1 最上位 TIER 2 / 3 … ベストエフォートで整備。定期的にtierの見直し 未分類（探索 / 一時利用で一定期間後に削除） 活用要件をもとにテーブルごとに信頼性要求の等級を付け、運 用ルールを等級に紐付ける Special Thanks: データアセスメントは株式会社10X吉田さん (@syou6162)さんにアドバイザーとして参加いただいていま す。 23 / 36
23. 0 3 / S E M A N T I C L A Y E R × D R L ルール・タグ・自動チェック で Tier1 を動かす ルール・タグ・自動チェック層がセットで動き、データ変更を即座に検知 → 必要に応じて人間にエスカレする 01 参照制限 レイヤ違反、モデリングルールに沿わない参照を防御 02 専用 CI / CD 品質定義。data test / 制約 / 鮮度を強制 03 自動チェック → 人間エスカレ 影響を自動検知、品質をチェックして必要時に人間へ 実 装 ― dbt タ グ + selectors # models/marts/finance/revenue.sql {{ config( materialized='table', tags=['tier1'], ) }} # selector で Tier1 のみ実行 $ dbt build --select tag:tier1 PR上 で の 自 動 チ ェ ッ ク → エ ス カ レ STEP 1 PR 作成 dbt モデル変更 STEP 2 影響範囲解析 downstream を再帰展開 STEP 3 Tier1 影響 + 品質チェック タグ照合 / 品質を自動検査 STEP 4 人間にエスカレ 必要時のみ。マージブロック → Data Contract的に事前定義したいが、Devin Playbook をベースにフ ローを自動化 24 / 36
24. 0 3 / S E M A N T I C L A Y E R × D R L PR レビューを AI Agent に任せる ― Devin Playbook 自動化を任せながらも、信頼性が必要な領域は AI Agent 側でガードする 背 景 Tier1データが依存先にあるような変更を、壊れる前に検知したい 課 題 Tier1データが依存先にあるような変更が、クエリの問題かデータの 問題か、どのくらい重大かわからない 解 決 Playbook に Tier1 タグの認識ルールを記述し リスクと重要度をコメ ントしてレビュアーに伝える。 dbtコードベースを読むだけでなく、 - "tags:tier1" で絞ったdbt lsコマンドの結果 - Application側のRepositoryの実装や、App DBの定義スクリプト も読ませ、精度を高める 25 / 36
25. 0 3 / S E M A N T I C L A Y E R × D R L BI 層の棚卸しを AI Agent に任せる ― Lightdash Autopilot データ層と同じ思想を BI 層にも適用 ― 壊れ・古さ・修正を AI Agent が担う Autopilot が や っ て い る こ と Ubie で の 活 用 壊れたチャート / 古いチャートの自動検出 stale 検知（一定期間アクセスなし） スキーマ変更への修正提案 未使用ダッシュボードの棚卸し カラムリネームなど追従提案を確認 → 適用 BI 側でも「触らせるもの / 触らせないもの」を分離 参考 Lightdash Autopilot 公式 — docs.lightdash.com/guides/ai-agents/autopilot 26 / 36
26. 0 3 / S E M A N T I C L A Y E R × D R L 進捗を継続的に可視化する データアセスメントを一回やって完成、ではない。変わりゆくボトルネックを解消し続ける 現 状 ✓ Data Reliablity Levelの定義とTier1ガードレール ✓ 品質影響検知・棚卸し自動化の開始 ✓ AI Agent設計プラクティスの創出 道 半 ば … dbt modelとMaster Data Managementの境界分割 … Tier定義対象拡大（複数ドメイン / 横断指標） … Semantic Layerの拡大 27 / 36
27. C H A P T E R · 0 4 AI Agent(Claude)をどう使うか？ 28 / 36
28. 0 4 / C L A U D E S K I L L の 応 用 分析エージェントの組み方 ― 3 層を意識して、3 段で実装する SKILL.md / references / agent を組み合わせて、データ・分析・文脈の 3 層を扱う 分 析 エ ー ジ ェ ン ト に 必 要 な 3 層 データ層 テーブル粒度 / 指標定義 / JOIN ロジック ― 「何が起きたか」を正確に把握させる 分析層 セグメント分析 / 時系列 / 異常検知の作法 ― 探索の手順とガードレールを与える 文脈層 プロダクト変更 / 施策履歴 / 外部環境 ― 「なぜ」に答えるためにデータの外側を渡す 文脈層が無いと "もっともらしい嘘" が出る。 3 段 で 実 装 す る （ Plugin の 構 造 ） analytics-plugin/ ├── skills/ │ ├── entry-point/SKILL.md # ルーター（分析しない） │ └── specialized-X/SKILL.md # 特化スキル（クエリ群・参照） ├── agents/ │ └── investigator-X.md # 調査オーケストレーター └── .claude-plugin/plugin.json Entry Point Skill ― 依頼を解釈し、適切な Agent を起動。自分では分析しない Agent ― 仮説駆動の調査主体。SQL を組み立て、結果を解釈して次を決める Specialized Skill ― ドメイン知識を references として持つ 仮 説 駆 動 の 調 査 ル ー ル （ Agent に 必 ず 入 れ る ） 1. 事実確認 ― まず数字を見る。解釈しない 2. 仮説の発散 ― 最低 3 つの仮説を立てる。1 つに飛びつかない 3. 体系的検証 ― 仮説を 1 つずつ検証する 4. 反復 ― 新事実が出たら仮説を再生成して繰り返す 「3 層 × 3 段 × 仮説駆動」が、もっともらしい嘘を防ぐ最小構成 参考 note 記事 (2026/4) "Claude Code で分析エージェントを作って 3 か月運用した話" — note.com/guchey/n/n9eb66dd5d470 / Anthropic Engineering Blog (2025/10) "Equipping agents for the real world with Agent Skills" 29 / 36
29. 0 4 / C L A U D E S K I L L の 応 用 事 例 1 · POC 事例 1 ― PoC 業務での Skill（まずは 1 スキルで網羅） 業務理解が固まる前は、1 つの SKILL.md にパターンを網羅的に詰めて素早く回す。立ち上げ期のプロダクト利用ログ分析で使っている。 Entry Point も Agent も無い 1 ファイル構成 ― 仮説検証フェーズに合っているが、依頼の型が固まってきたら次の構成に進化させる。 分 析 要 件 の カ タ ロ グ （ パ タ ー ン 網 羅 型 ） カテゴリ 具体例 📊 利用頻度分析 顧客別アクティブ率、機能別利用数、月次／週次トレンド 👥 ユーザー内訳 役割・属性別の使われ方、ヘビーユーザー特定 📈 導入後トレンド 導入 N ヶ月後の継続率、機能浸透の推移 ⚠️ 離脱検知 急に使わなくなった人の特定、利用ドロップ 使 い 方 （ 聞 き 方 → 出 て く る も の ） 聞き方の例 出てくるもの 「◦◦ の直近 6 ヶ月の利用レポートを作って」 機能別 / UU / 月次トレンド / 属性別 「機能 X、リリース後 1 ヶ月でどれくらい使われた？」 週次トレンド、継続率、属性別浸透 会話で深掘り → 「Notion にまとめて」で共有可能なレポート化までできる。 構成 ― 1 ファイル analytics-plugin/ └── skills/ └── product-analytics/ ├── SKILL.md # 分析パターンを網羅的に列挙 └── references/ └── tables.md # テーブルカタログ 30 / 36
30. 0 4 / C L A U D E S K I L L の 応 用 事 例 2 · 成 熟 業 務 事例 2 ― 成熟業務での Skill（役割で分業する） 業務の型が安定したら、Skill を役割で分業させ、references を用途別に階層化する。依頼タイプの自動分類 → クエリ実行 → 返答文生成までを 1 つの Plugin でつなぐ。 最初はモノリスな query-patterns.md だったが、500 行ルールに当たってリファクタ。Entry Point + Agent + Specialized Skill 構造の実例。 依 頼 パ タ ー ン 型 ― 4 タ イ プ に 自 動 分 類 パターン 比率 内容 A. シミュレーション / 提案前確認 ≈ 40% 「この条件で何件取れるか」 「対象セグメントの割合は」 B. データ抽出 ≈ 27% 「条件付きで対象を全件出して」 C. データ品質確認 ≈ 17% 「BQ が更新されていないだけ？」など D. 既存ダッシュボード誘導 ≈ 13% AS-IS ダッシュボードの案内だけで完結 使 い 方 （ フ ェ ー ズ 構 成 ） # Phase 0 依頼パース (Slack スレッド読み取り) ↓ # Phase 1 タイプ分類 (A / B / C / D) ↓ # Phase 2A ダッシュボード誘導 ← AS-IS で完結 # Phase 2B シミュレーション ← 製品タイプで分岐 # Phase 2C ローデータ抽出 ← 製品タイプで分岐 # Phase 2D データ品質確認 ← 3 サブパターン ↓ # Phase 3 Slack 返答文生成 ス キ ル 分 業 + 参 照 ド キ ュ メ ン ト の 階 層 ルックアップ系（2 種） 名称 → 内部 ID への正規化 / マスタテーブル KPI トレンド 月次推移 + ブレイクダウン / セッション粒度 設問回答集計 設問の回答内訳 / セッション粒度 _shared / bq-config 全スキルが depends（BQ 実行プロジェクト統一） ← composable_with ― KPI トレンドがルックアップを呼び出す references/ ├── _query-patterns-common.md # 共通テーブル・JOIN キー・パターン 0 ├── query-patterns-headline.md # ヘッドライン KPI のベースクエリ └── query-patterns-breakdown.md # ブレイクダウン (A1 / A2 …) 31 / 36
31. 0 4 / C L A U D E S K I L L の 応 用 別 事 例 別チームの分析エージェントも、同じ 3 段構造で組まれている Ubie 社内では、PdM チームでも別の分析エージェントが運用されている。データ分析を日々のスクラム活動Agentに組み込み、原因特定からレポート出力まで完遂するエージェント プ ロ ジ ェ ク ト 構 造 （ 3 段 実 装 の 実 例 ） kpi-plugin/ ├── skills/ │ ├── kpi/SKILL.md # Entry Point: ルーター │ ├── kpi-product-a/SKILL.md # Specialized Skill │ └── kpi-release/SKILL.md # Specialized Skill ├── agents/ │ ├── kpi-type-a.md # 仮説駆動の調査 Agent │ └── kpi-type-b.md └── .claude-plugin/plugin.json 文 脈 層 の 永 続 化 project-root/ └── memory.md # Slack / JIRA / Notion から定期収集 # した事業コンテキスト # （cron で更新、Agent が分析時に参照） Specialized Skill 内 の references（ 4 カ テ ゴ リ ） ファイル 内容 table-knowledge.md dbt のテーブル定義、JOIN キー、注意点 institutional-context.md ビジネス知識（指標定義、ベンチマーク） learned-corrections.md 過去の失敗パターンと教訓 queries.md パラメータ化された SQL テンプレ データ・分析だけでは "もっともらしい嘘" が出る。文脈（プロダクト変更・施策履歴・外部環境）を memory.md に 補助的に組み込ませることもある 参考 note 記事 (2026/4) "Claude Code で分析エージェントを作って 3 か月運用した話" — note.com/guchey/n/n9eb66dd5d470 32 / 36
32. 0 4 / C L A U D E S K I L L の 応 用 AI Agent に必要な3装備 「車の運転」のメタファで整理すると、MCP(tools) / Skills / References はそれぞれ別の役割を担う EQUIPMENT 01 MCP(tools/plugins) ≒ 車のキー 外部ツール・データへの接続を開く。鍵がないと そもそも動かないが、なんでも開けていいわけで はない EQUIPMENT 02 Skills / Plugins ≒ 運転の仕方 事故を起こさない使い方・作法。再現可能な手順 とガードレールを与える。 EQUIPMENT 03 References ≒ 地図 / カーナビ 何を参照すべきかのコンテキスト。テーブル / 指 標 / 業務ルールがここに集まる。 これらが揃って初めて AI Agent が「自律的に・安全に」分析を回せる 参考 Anthropic Engineering Blog, Equipping agents for the real world with Agent Skills — www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills / dbt Labs, dbt-agent-skills — github.com/dbt-labs/dbt-agent-skills / Altimate Skills 紹介・検証（rmoff 含む） — www.altimate.ai/teaching-claude-code-the-art-of- data-engineering-introducing-altimate-skills 33 / 36
33. C H A P T E R · 0 5 Data Engineer / Analytics Engineer は何をすべきか？ 34 / 36
34. 0 5 / 結 論 データエンジニア / アナリティクスエンジニアがすべきこと = 分析に関わるシステムとその境界をデザインし続ける 01 AI Agent が参照する Semantic Layer を整える / Trusted な Dashboard ヒント：Semantics Layer / メタデータ整備 / text to SQL / application 開発への越境 02 データのtierとステークホルダー・影響範囲で守るべき信頼性要件を維持し続ける ヒント：Data Realiablityの設計 / 要求品質の定義 / Devin Playbookなど違反時の自動化 / Autopilotでの自動棚卸し 03 DE / AE 自身が分析を回し、ユーザー体験を基盤に戻す ヒント：ダッシュボード作成、SQL を書く、AI Agent から問い合わせる ― そこで見えた不便を Semantic Layer 改善に折り返す 35 / 36
35. 0 5 / 結 論 伏 線 回 収 ” “That’s where discipline in modeling, validation, and ownership becomes a requirement, not a best practice.” modeling, validation, ownershipがmustな時代へ そのデザインをし続けるのがデータエンジニア / アナリティクスエンジニアの仕事 参考 https://www.getdbt.com/blog/new-dbt-labs-report-finds-ai-driven-acceleration-is-outpacing-trust-and-governance 36 / 36
36. A P P E N D I X 付録
37. R E F E R E N C E S 参考文献 dbt Labs『State of Analytics Engineering 2026』 getdbt.com/resources/state-of-analytics-engineering-2026 dbt Labs Press Release (2026/4/14) getdbt.com/blog/new-dbt-labs-report-finds-ai-driven-acceleration-is-outpacing-trust-and- governance dbt Developer Blog (2026/4/7) — Semantic Layer vs Text-to-SQL 2026 Benchmark docs.getdbt.com/blog/semantic-layer-vs-text-to-sql-2026 Lightdash 公式 — Agentic BI / Verified Content / Pre-aggregates / Autopilot / Best Practices lightdash.com/agentic-bi docs.lightdash.com/guides/verified-content docs.lightdash.com/references/pre-aggregates/overview docs.lightdash.com/guides/ai-agents/autopilot docs.lightdash.com/guides/ai-agents/best-practices Ubie テックブログ — Lightdash AI Agents で始めるデータ整備 zenn.dev/ubie_dev/articles/62844730189eb1 Anthropic Engineering — Equipping agents for the real world with Agent Skills anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills github.com/anthropics/skills Altimate Skills / AltimateAI data-engineering-skills altimate.ai/teaching-claude-code-the-art-of-data-engineering-introducing-altimate-skills github.com/AltimateAI/data-engineering-skills DMBOK アセスメント先行事例 tech-blog.monotaro.com/entry/2022/07/27/090000 product.10x.co.jp/entry/2024/04/05/064408 note 記事 (2026/4) — Claude Code で分析エージェントを作って 3 か月運用した話 note.com/guchey/n/n9eb66dd5d470