LLM時代にデータエンジニアの役割はどう変わるか？

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Copyright stable, inc. All rights reserved.  自己紹介  2 宮﨑一輝（ ikki）  stable株式会社代表取締役 & データエンジニア  - 略歴  - コンサル → データアナリスト → データエンジニア  - 2023年にstable株式会社を創業  - 得意領域   - dbtを用いたデータモデリング   - データ分析  - そ他  - 犬2匹を飼っています🐶 

Slide 3

Slide 3 text

Copyright stable, inc. All rights reserved.  会社概要 3  わたしたちデータエンジニアリング領域クライアントワークを中心に、   「企業データ活用成功」を支援する会社です。  会社名  stable株式会社  設立  2023年9月  所在地  〒151-0051 東京都渋谷区千駄ケ谷  5丁目15−5 DSビル703  代表取締役   宮﨑一輝  従業員数  正社員3名、業務委託 12名（2025年9月時点） 

Slide 4

Slide 4 text

Copyright stable, inc. All rights reserved.  データ基盤整備プロ知見やリソースを、 1ヶ月単位で提供しています。   stable 提供サービス  4  プロ知見・リソースがすぐに得られる   - 多数案件を経験するプロ知見を得られる   - 実装まで行うで、社内にリソースがなくても OK      1ヶ月ごと月額制で柔軟な支援体制   - 見積もりが発生せず、すぐプロジェクトを開始できる   - 1ヶ月ごとにコミット量調整が可能  

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Copyright stable, inc. All rights reserved.  🎯概要  - 事業部側、分析したい事がある場合、データチームに分析依頼を投げる   - データチーム分析を行い、   分析結果を事業部側にレポートする   ⚠懸念  - データチームが分析結果を返すまで   リードタイムが発生する   - 事業部側が持つコンテキストが、データチームへ依頼際に失われやすい   データチーム体制 / 依頼型  7 「依頼型」、データチームが各事業部データ集計依頼に応えるという体制。   事業部側にデータ抽出スキルがない場合、必然的にこ体制になりやすい。   データチーム   営業  マーケ  開発  分析結果   依頼  「依頼型」 

Slide 8

Slide 8 text

Copyright stable, inc. All rights reserved.  データチーム体制 / 派遣型  8 「派遣型」、データチームメンバーが各事業部内部に深く入り込み、   分析を行う体制。   データチーム   営業  マーケ  開発  「派遣型」  派遣  各事業部内で分析  🎯概要  - 各事業部内分析ニーズ、各事業部に   派遣されたデータ人材が解決する   - 事業部コンテキストを汲み取りやすく、リードタイムも短くなりやすい   ⚠懸念  - データ人材が複数人いる必要がある   - 各事業部でナレッジがサイロ化し、   横断的な取り組みがしづらい  

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Copyright stable, inc. All rights reserved.  データチーム体制 / 教育型  10 「教育型」、 SQLやExcelでデータ分析をするスキルを、事業部側非データ   人材に教えることで、依頼を投げずとも自律的に分析が回るようにする体制。   データチーム　　  営業  マーケ  開発  「教育型」  教育  各事業部内で分析  🎯概要  - データチームが主体となって、事業部側非データ人材にSQLなどスキルを教える   - 事業部側メンバーが自律的に分析を行う   ⚠懸念  - データ分析を教えるが大変   - 非データ人材が分析をすることで、   集計ミスや品質問題が起きやすい  

Slide 11

Slide 11 text

Copyright stable, inc. All rights reserved.  データチーム体制 / 増員型  11 データチーム人数がボトルネックなであれ、「増員型」で単純に増員   したいところだが、それが出来たら苦労しない ...  データチーム   営業  マーケ  開発  「増員型」  🎯概要  - 結局、データ人材人数がボトルネックになっている  - で、単純に増員すれいいで   ⚠懸念  - それが出来たら苦労しない ... 

Slide 12

Slide 12 text

Copyright stable, inc. All rights reserved.  各体制比較  12 これまで紹介してきた体制、それぞれ何らか問題を抱えており、   データ活用を推進するハードルとなっていた。   「依頼型」   「派遣型」   「教育型」   「増員型」   精度  非データ人材ためミスが起きやすい   実現難易度・コスト   採用コスト・   採用難易度高い   分析リードタイム   事業部側が   自身で分析を行える   データ人材が   事業部側として活動   データチームリソース   依頼制限や   納期調整一定可能   教える労力が大きい   派遣できるだけ   人がいない   事業部コンテキスト   事業部側が   自身で分析を行える   人が増えれ、事業側に入り込みやすい   データ人材が   事業部側として活動   依頼ベースで   限界がある   教えるが難しい  

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Copyright stable, inc. All rights reserved.  データチーム体制 / AIによるデータ民主化型   16 「AIによるデータ民主化型」が実現すると、 AIエージェントが事業部側   分析ニーズに応えてくれるため、前述したような課題が解決するで。   データチーム　　  営業  マーケ  開発  「AIによるデータ民主化型」   AIエージェント   メンテナンス   自然言語で問い合わせ  🎯概要  - データチーム代わりに、事業部側依頼に応えてくれるAIエージェントを用意する   - 事業部側 24時間、AIエージェントから  高速なレスポンスを受け取ることができる   ⚠懸念  - 本当に分析結果が正しいか？  

Slide 17

Slide 17 text

Copyright stable, inc. All rights reserved.  各体制比較・改  17 AIエージェント活用が上手くいくと、データチームリソースに余裕ができ、   事業部側も高速、かつ、コンテキストを汲んだ分析結果を得られる可能性。   分析リードタイム   事業部コンテキスト   精度  データチームリソース   依頼型  派遣型  教育型  増員型  事業部側が   自身で分析を行える   事業部側が   自身で分析を行える   非データ人材ためミスが起きやすい   依頼制限や   納期調整一定可能   教える労力が大きい   実現難易度・コスト   採用コスト・   採用難易度高い   人が増えれ、事業側に入り込みやすい   データ人材が   事業部側として活動   派遣できるだけ   人がいない   データ人材が   事業部側として活動   依頼ベースで   限界がある   AI  エージェント型   実現可能性高い   ・コストも安価   事業部側がコンテキストを渡せる   高速なレスポンス   勝手に分析してくれる   （初期実装も少ない）   ?  教えるが難しい  

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Copyright stable, inc. All rights reserved.  AI時代にやること  21 AIエージェントデータ基盤データを参照して分析を行う。したがって、   そデータ基盤を整備するデータエンジニア仕事として残るだろう。   データ基盤   データを参照   データチーム　　  営業  マーケ  開発  AIエージェント   メンテナンス   AIが使いやすい   データ基盤を整備する必要がある  

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Copyright stable, inc. All rights reserved.  こんな場合を考えてみよう   25 とあるサブスクサービスデータについて考えてみましょう。   サブスクテーブル   ● あるサブスクサービスを登録したデータが入っている   ● 注意）プランを変更した場合も、 1レコードが追加され、   古いレコード終了扱いになる   プラン変更を除く、   サブスク登録者数を集計したい  

Slide 26

Slide 26 text

Copyright stable, inc. All rights reserved.  プロンプトで指示する場合 ...  26 最初から的確な指示を出す難しい。ラリーを重て要件を固めていく。   ● あるサブスクサービスを登録したデータが入っている   ● 注意）プランを変更した場合も、 1レコードが追加され、古いレコード終了扱いになる   プロンプト   ● 「サブスク登録数を計算して！」   ● 「あ、そうじゃなくて、プラン変更も含まれてるから、 typeカラムでプラン変更を判定して、新規登録だけを集計してほしい」  AI  何ラリーかを経て、   いい感じに理解して   集計を行う   サブスク   テーブル  

Slide 27

Slide 27 text

Copyright stable, inc. All rights reserved.  メタデータで頑張る場合 ...  27 複雑な仕様をメタデータで記述する場合、 AIにいい感じに理解してもらう必要がある。  ● あるサブスクサービスを登録したデータが入っている   ● 注意）プランを変更した場合も、 1レコードが追加され、古いレコード終了扱いになる   メタデータ   ● type → 「1: 新規登録、 2: プラン変更」ように、   typeカラムにそれぞれが何を表しているかを記述する  ● さらに、「プラン変更が含まれるため、新規登録だけを集計したい場合、 type=1 を指定する」ような  補足が必要かも   AI  いい感じに理解して   集計を行う   サブスク   テーブル  

Slide 28

Slide 28 text

Copyright stable, inc. All rights reserved.  データモデリングをちゃんとやる場合 ...  28 適切なデータモデリングで表現しておけ、解釈余地が入りにくい。   新規登録   テーブル   プラン変更   テーブル   ● あるサブスクサービスを登録したデータが入っている   ● プラン変更レコード除外されており、   新規登録レコードみが入っている   ● プラン変更時レコードみが入っている   AI  普通に使え OK 

Slide 29

Slide 29 text

Copyright stable, inc. All rights reserved.  Text2SQLに必要なも   29 メタデータやプロンプトチューニング必要であるも、しっかりとしたデータモデリングがベースにあるかどうか差大きいで。   データモデリング  メタデータ  プロンプト  データモデリング  メタデータ  しっかりしたデータモデリングがベースになっていると、結果が安定するで   プロンプト  メタデータとプロンプトで、   安定した回答を得ることが難しい？  