メルマガ登録
-
テーマから探す
-
技術から探す
-
業界・事例から探す
-
関連トレンドから探す
テーマから探す
技術から探す
業界・事例から探す
関連トレンドから探す
「AIツールの導入を進めたいが、メンバーの役割がどう変わるのか見通せず、適切な方針を示せていない」「どの業務からAI Agent活用を始めればよいか判断できない」──こうした悩みを抱えるマネージャー・組織長は多いのではないでしょうか。
AI Agentの急速な進化により、データエンジニア（DE）とデータサイエンティスト（DS）の業務も大きく変わろうとしています。特にDatabricksのGenie Codeに代表されるAI Agentは、コード補完を超えた自律的なタスク実行を実現し、チームの仕事の仕方そのものを変えようとしています。
組織長が直面している最大の課題は、「どの業務が自動化され、どの部分に人間の価値が残るのか」を見極め、メンバーを適切に導くことです。
Databricksのレポートを紐解き、データ活用に深く関わるDE・DS業務を例にこれからの役割を提示します。
こんな方にオススメ！
この記事で得られること
「AIツールの導入を進めたいが、メンバーの役割がどう変わるのか見通せず、適切な方針を示せていない」「どの業務から自動化に手をつければよいか判断できない」──こうした悩みを抱えるDE・DSチームのマネージャー・組織長は多いのではないでしょうか。
AI Agentの急速な進化により、従来のDE・DS業務は大きく変わろうとしています。特にDatabricksのGenie Codeに代表されるAIエージェントは、コード補完を超えた自律的なタスク実行を実現し、チームの仕事の仕方そのものを変えようとしています。
組織長が直面している最大の課題は、「どの業務が自動化され、どの部分に人間の価値が残るのか」を見極め、メンバーを適切に導くことです。
従来のAIアシスタントは、ユーザーがSQLクエリの生成やコード説明を依頼すると結果を返し、次の指示を待つ「Q&A型」の動作でした。
一方、Genie Codeのような現行のAIエージェントは「タスク委譲型」です。「不正検知パイプラインをMedallion Architectureで構築して」といった高レベルの指示を受けると、自動でステップを分解し、テーブル発見・コード生成・実行・検証まで自律的に完遂します。Unity Catalogに深く統合されており、テーブルのセマンティクス・リネージ・アクセスポリシーをコンテキストとして理解した上で動作するのが特徴です。
| 業務カテゴリ | エージェントが担う具体的な処理 |
|---|---|
| パイプライン構築 | 自然言語指示から、Bronze/Silver/Goldの完全なMedallion Architectureを自律生成・テスト・実行（公式デモで確認済み） |
| ジョブ定義・オーケストレーション | タスク・依存関係・スケジュールを含むLakeflow Jobsを自然言語から構成。変更・デバッグも自然言語で対応 |
| 障害対応 | パイプライン・ジョブ失敗時にエラーを分析し、関連ファイル全体の修正をdiff付きで提案。スキーマ不整合の根本原因特定から検証・解決策提案まで自律実行 |
| 業務カテゴリ | エージェントが担う具体的な処理 |
|---|---|
| データクレンジング・前処理 | 欠損値補完・外れ値除去などのルーティン処理を自動化。Unity Catalogのコンテキストを活用してデータ品質問題を自動検出・処理 |
| 統計分析・可視化 | EDAにおける基本統計量算出・分布可視化・相関分析を自動生成。適切なグラフタイプ選択やインサイト抽出を支援 |
| SQLクエリ生成 | 定期レポートや標準的な分析で使用するクエリを自動生成。複雑な集計・JOINロジックも自然言語指示で実装 |
定型的な実装・障害対応・品質チェックの多くをAIが担う分、人間は「何を・なぜ作るか」のビジネス判断と設計に集中するようになります。
DE（データエンジニア）の業務は、バイブコーディング（AI Agentへの自然言語指示）の普及により、定型的なパイプライン実装・障害対応・品質チェックの多くが自動化されます。一方で、「何を・なぜ作るか」のビジネス判断と設計は、引き続きヒトに残る核心的な責務です。
| カテゴリ | Before：現在の主要業務 | After：AI導入後にヒトが専念する責務 |
|---|---|---|
| パイプライン開発・保守 | • ソースシステムからのデータ取り込み設計（API連携、CDC、ファイル連携）• ETL/ELTジョブの開発（Spark/SQL/Python） • スケジューリングと依存関係管理 | • Medallion各層でどの変換ロジックを適用するかの設計判断（例: 返品を売上に含めるか）• ネスト構造のフラット化方針• ジョブ設計のビジネス要件判断（いつ実行・何に依存・どの頻度） • コスト vs. 鮮度のトレードオフ判断 |
| 障害対応・トラブルシューティング | • パイプライン失敗のアラート対応• データ遅延・欠損の原因調査• 上流システム変更（カラム追加・削除、型変更）への緊急対応• リトライ・バックフィル実行 | • 上流仕様変更が「意図的か、バグか」の判断（ビジネスプロセス変更の文脈理解） • ループ検出と強制停止の判断 |
| データ品質管理 | • データバリデーションルールの定義と実装（dbt tests、Lakeflow expectations）• 異常値検知ルールの調整• データリネージの維持• SLA管理 | • バリデーションルールのビジネス要件定義（「何が正しいデータか」の判断基準策定） • リネージ上の上流変更がビジネスに与える影響の判断 |
| インフラ・性能管理 | • クエリ性能のチューニング（パーティショニング、Z-ordering、キャッシュ戦略）• コスト最適化（クラスタサイジング、Spot/Reserved、ストレージ階層管理） | • コスト vs. パフォーマンスのトレードオフ判断 • ビジネス要件に基づくSLA・可用性要件の設計 |
| 権限・ガバナンス管理 | • Unity Catalog/IAMでのテーブル・スキーマ・ボリュームの権限設定• PIIマスキングルールの実装• 監査ログの確認• 新規ユーザー・チームへのアクセス権付与 | • ガバナンスポリシーの設計と承認判断• PIIデータの取り扱い方針の決定 • コンプライアンス要件の解釈と適用 |
| コミュニケーション・要件定義 | • DS/DAからのデータ要件のヒアリング• 問い合わせ対応（「このデータどこにありますか」「この数字なぜ変わりましたか」等）• ドキュメンテーション | • 発見されたデータのビジネス妥当性判断 • ビジネス要件の技術的翻訳と優先度判断 |
DS（データサイエンティスト）の業務でも同様に、データ準備・モデル開発のルーティン作業はAIが代替します。ヒトに残る価値は、「何を予測すべきか」「その結果をどうビジネスに活かすか」を判断するドメイン固有の知識と洞察力です。
| カテゴリ | Before：現在の主要業務 | After：AI導入後にヒトが専念する業務 |
|---|---|---|
| データ準備・探索（EDA） | • SQLクエリでのデータ抽出• Notebookでの分布確認・欠損値分析・相関分析• 特徴量候補の探索・可視化• 「このデータ使えるか？」の判断 | • 因果 vs. 相関の判断（統計的相関があっても疑似相関の可能性、季節性 vs. 構造変化の判断はドメイン知識）• データリーケージ検証 • 「このデータは将来も利用可能か」の判断（例: リリース後にしか得られない特徴量の識別） |
| モデル開発・実験 | • 特徴量エンジニアリング• モデル選択・学習・チューニング• ハイパーパラメーターチューニング（Grid/Bayesian）• MLflow実験管理• ベースラインとの比較評価 | • 「何を予測すべきか」の問題設定（ビジネス課題→データ課題への翻訳）• 精度の十分性判断（「精度85%は十分か」=失敗コスト vs. 成功利益のROI計算）• 解釈可能性の要否判断（規制環境ではブラックボックス不可） • 推論速度・コスト要件の判断 |
| モデル運用・監視 | • 本番モデルの精度モニタリング（ドリフト検知）• 再学習パイプラインの運用• 推論レイテンシ・コスト管理• 障害時のロールバック対応 | • 「何が正しいか」のPass/Fail基準設計（Agent品質分析）• どのスコアラーを追加すべきかの判断 • 評価データセットの初期構築（ドメイン固有Q&A＝「正解」の定義） |
| ステークホルダーコミュニケーション | • 分析結果のプレゼンテーション（「この数字は何を意味するのか」の翻訳）• 経営層・事業部への示唆出し• ビジネス要件のヒアリング | • ビジネスKPIの設計（「何を見るべきか」の判断）• 可視化の解釈と意思決定への接続 • ビジネス価値としてのデータ活用戦略立案 |
バイブコーディングの普及により、DE・DS双方に従来存在しなかった新たな業務が生まれています。それは、AIに「何を・どのように指示するか」を設計し、その出力品質を管理・評価する役割です。
| 新たな責務・業務 | 具体的に何をやるか | 求められる専門知識 |
|---|---|---|
| コンテキスト エンジニアリング | • UCメタデータ品質基準策定（命名規約、カラム記述、PK/FK）• SQL Expression定義（Measure/Filter/Dimensionでビジネス用語をSQL化）• Entity Matchingや Join Relationships定義• Benchmark設計（500問、言い換え2-4パターン）• Example SQL作成・検証 | • ドメイン知識 × SQLモデリング• セマンティックモデル設計• ビジネス用語体系の構造化 • データオントロジー設計 |
| エージェント 評価設計 | • Pass/Fail基準設計（ドメイン固有ガイドラインルールを自然言語で定義）• 評価データセット構築（ドメイン固有Q&A：「正解」の定義）• Custom Scorer実装（例: 生成SQLのテストDB実行検証）• 本番トレースの体系的エラー分析と改善優先順位付け | • LLM-as-a-Judge設計• 非決定的出力の品質定量化• ドメイン固有の「正解」定義能力 • MLflow 3 GenAI Evaluation |
| Agent Skills / Custom Instructions設計 | • Custom Instructions: コード規約・禁止事項等の永続ルール設計• Agent Skills: ドメイン固有ベストプラクティス（PIIマスキング、予測ロジック、会計規則等）をMarkdownで定義し関連時に自動ロード• スキル粒度設計• MCP連携設計（外部ツール接続とポリシー策定） | • 暗黙知の構造化・文書化• テクニカルライティング• ツール設計（入出力スキーマ） • MCP/API設計 |
| エージェント出力の ビジネスレビュー | • 生成コードのビジネスロジック検証（diff承認/却下判断）• 非決定的出力のTrusted Assets設計（検証済みクエリパターン整備）• 無限ループ検出と強制停止の判断基準策定• コンテキスト分離・アクション確認ポリシー設計 | • ビジネスロジックの深い理解• コードレビュー→出力レビューの質的転換• リスク判断（不可逆操作の識別） • エージェント行動の監査設計 |
| エージェント コスト最適化 | • モデルルーティング設計（frontier vs. 軽量モデルの使い分け）• トークンバジェット設計（コンテキストウィンドウの経済的利用）• AI Gatewayによるレート制限・コスト上限設定• コスト/品質のパレート分析と継続モニタリング | • LLMコスト構造の理解（トークン課金、推論レイテンシ） • FinOps |
AI時代におけるDE・DSの役割変化は、技術的実装から戦略的判断・設計業務への移行として整理できます。
変革を成功させる最重要要因は、技術変化を脅威ではなく機会として捉え、メンバーと共に新しい価値創出の方法を探求し続ける姿勢です。
A1: 人員削減ではなく、より高付加価値業務への移行による組織価値向上の観点で捉えることが重要です。定型作業の自動化により生まれたリソースを、戦略的な設計・判断業務や新しい価値創出領域に振り向けることで、組織全体の生産性と市場価値を向上させることができます。
A2: 従来の技術スキルは無駄になりません。むしろ、技術的基盤知識があることで、AI生成されたコードやソリューションの適切性を判断し、ビジネス要件に合わせてカスタマイズする能力が向上します。技術理解を土台として、戦略的思考や設計判断といったより高次の能力に発展させることが、AI時代のデータプロフェッショナルに求められる姿です。
あなたにオススメの記事
2023.12.01
生成AI（ジェネレーティブAI）とは？ChatGPTとの違いや仕組み・種類・活用事例
2023.09.21
DX（デジタルトランスフォーメーション）とは？今さら聞けない意味・定義を分かりやすく解説【2024年最新】
2023.11.24
【現役社員が解説】データサイエンティストとは？仕事内容やAI・DX時代に必要なスキル
2023.09.08
DX事例26選：6つの業界別に紹介～有名企業はどんなDXをやっている？～【2024年最新版】
2023.08.23
LLM(大規模言語モデル)とは？生成AIとの違いや活用事例・課題
2024.03.22
生成AIの評価指標・ベンチマークとそれらに関連する問題点や限界を解説
