ミツモア Tech blog

「ミツモア」を運営する株式会社ミツモアの技術ブログです

AI Ready Data Analysis Platform(1/n) - データ分析Agentロードマップ

生成AI データ分析 LLM AI

こんにちは、ミツモア データマネージャの古田 (@crazysrot) です

当社では「日本のGDPを増やし、明日がもっといい日になる、と思える社会に」というミッションを掲げていますが、まずは自らの生産性向上から始めるべく、日々生成AIを活用しています。

プロダクト本部全体では ChatGPT、Devin、Cursor、GitHub Copilot、Claude Code などの最新ツールを積極的に導入・活用しています（一部はすでに利用を中止）。

データグループでも、AIによるデータ分析の生産性向上に取り組んでおり、現在は主にデータ分析基盤のコーディング効率化と text2SQL 構築に注力しています。特にリリース済みのtext2SQLについてはビジネスメンバーも活用しており、良い成果が上がってきています。

今回は、データxAIのロードマップ作成とそれに向けたデータ基盤側の活動を紹介します。

データ x AI のロードマップ

企業におけるデータ活用プロセス

さて、企業にてデータの活用をするために必要なことは何があるでしょうか？

データを効果的に活用するためには、次のようなプロセスが必要です。

  • データの蓄積・収集
  • データのクレンジングと加工
  • データへのアクセス基盤構築
  • データの可視化と分析
  • データに基づく意思決定
  • 高度な分析（機械学習など）によるプロダクト強化

この一連のプロセスをAIがサポート/主体となって実施する体制を構築するためのロードマップとして、「Layer」と「Level」という2つの軸を定義しました。

AI Driven Analysis Roadmap

Layer

Cultureは、AI Copilotをビジネス部門へも解放する際、データの民主化としてどのような状態になっていることが望ましいのかを対比させるために記載

Layer Hierarchy Layer Applying AI Culture
1 🔗 データ連携ができている (Data Engineering) ・AI駆動開発による、データエンジニアリングのサポートが行えている・AI駆動開発による、データエンジニアリングの領域の開発をビジネス側も行える データ基盤リテラシーの醸成が必要
2 🔍 データにアクセスしやすい　(Easy access to data) text2SQLなどの生成AIにより、より正しい必要なデータを正しくすばやく取得できる ビジネスを数字でより正しく判断できる、データを読む力、活用する力が必要
3 📊 可視化しやすい (Support for visualization and basic analysis) Graphicalな可視化や簡単なものであったり特殊な可視化であっても裏でPythonなどが実行される環境でインタラクティブに可視化ができる仕組みが構築されている 基本的な可視化のパターンを網羅的に知識として持っている
4 🧠 意思決定に使われている (Data is being used in the company's decision-making) 事業の状態を把握した上で今後どのような意思決定をするべきか正しく判断した結果が出力される AIの考察結果が妥当かどうかを判断できる、分析力を持っている
5 🤖 AIを活用して高度な分析がしやすい (Conduct advanced analysis like Machine Learning.) 機械学習などのより高度な分析をすることができる。そのために、分析基盤と分析プラットフォームと生成AIがシームレスにつながっている 機械学習やAIを用いた分析手法について一般的な知識と正しい活用方法を理解している

Level

  • Lv.1 : データ組織内において、業務を遂行できている / Able to carry out tasks within the data Organization.
  • Lv.2 : AI Coding toolsなどのLLMサポートツールなどを用いて、データ組織内で業務の効率化が測れている / By utilizing LLM-assisted tools such as Claude Code, we have been able to improve operational efficiency within the data team.
  • Lv.3 : AI Coding toolsなどのLLMサポートツールなどを用いて、データ組織外の人間が業務の効率化を図れている / By using LLM-assisted tools such as Claude Code, people outside the data team have been able to improve the efficiency of their work.
  • Lv.4 : 汎用的なLLMサポートツールなどを用いて、データ組織外の一部の部門の人間が業務の効率化を測れている / By using general-purpose LLM-assisted tools, some departments outside the data team have been able to improve the efficiency of their operations
  • Lv.5 : 汎用的なLLMサポートツールなどを用いて、全部門の人間が業務の効率化を測れている / By using general-purpose LLM-assisted tools, all departments have been able to improve the efficiency of their operations.

それぞれにおいてアプローチは異なるが、基本的には次のような戦略を考えています

1. データ連携

データエンジニアリング領域に関しては、基本的にプロダクト開発と同じ状態を作り出せると考えているため、いわゆるAI駆動開発のいろはを適用することが第一歩だと考えています。

また、SQLのみで構成されるData Pipelineになりがちなため、DataCatalogの充実は必須です。

2. データにアクセスしやすい

text2SQLを用いて、欲しいデータを自由に抽出する仕組みを構築することで、データの取得がスムーズになる世界を目指します。

text2SQLに関してはこの別の記事にて詳細に紹介します！

3. 可視化しやすい

こちら、現状でもOpenAIが2024年の夏あたりに公開したData Analystから一定実現できていたため、それを裏で実行し、可視化する環境が構築できれば実装は楽だと考えていますが、アーキテクチャは未定です。やりたいこととしてはOpenAI Data Analystそれそのものになります。

工夫する点としては、

  • データの渡し方
  • データの定義 / description and type
  • 過去の同様のデータの加工例あたりを渡してあげると比較的スムーズに処理を行えるかなと思っています

ここで、過去の施策などの非構造化データもうまく渡してあげることができればよりリッチな可視化が行えると思っています。

4. 意思決定に使われている

ここは鬼門だと思っています。

基本的に意思決定は"総合的に鑑みて"という要素が強いと感じています。そのため

  • 競合の動向
  • 自社(プロダクト)のロードマップやミッションなどの情報
  • 自社(プロダクト)の状況
  • 自社(プロダクト)の過去の施策の結果とその考察
  • 実施中の施策や今回の施策についてのあれこれなどなどを渡してやっと意思決定をできる土俵に持っていけるのではないかと考えています。

このstep4と2,3を繰り返して意思決定する材料を分析して最終的に示唆を出す、そういうことをやりたいです。

なので、上記の会社に散りばめられている情報をいかに統合し必要な情報を渡せるのか、そういったことをどうすればいいのかを今考えてる最中です。

5. AIを活用して高度な分析がしやすい

すみません、これに関しては解像度が荒いまま定義しています。機械学習を行うなどの、いままでだとデータサイエンティストが生業としていた業務の大部分を担うような補助があると便利ですね。と考えています。

とはいえ、Google Cloud, AWS, Azure あたりでまるっとできるようになるかDatabricksさんあたりが先に到達するしそれを活用する方が良い未来になってほしいと願っています。

AI Readyなデータ基盤contextを保持するための活動

Roadmapを推し進めていくにあたり、text2SQLもそうですがデータエンジニアリング業務においてもcontextの整備を拡充していく必要があります。

他にもガードレールを敷く必要があるものやさまざまな準備が必要でした。

基本的な戦略

データ基盤GitHub Repogitory内に全ての情報を集約

DMBOK観点: 次の5項目を優先

  • データモデリングとデザイン / Data Modeling & Design
  • データセキュリティ / Data Security
  • ドキュメントとコンテンツ管理 / Document & Content Management
  • データアーキテクチャ / Data Architecture
  • データ品質 / Data Quality
    DAMA Wheel

現在地

AI Ready データ基盤のための活動としては、次のような活動を実施しています。

CLAUDE.md

  • 周辺ツールと役割、ルールなどを記載

ELT

  • Data Extract & Load
    • こちらは、過去の記事でも紹介しているように弊社ではStitchやAirbyteをELTツールとして利用しています。dbt source としてメタデータを書いておくことで、最終的なMart tableがなんのSourceデータから伝搬されて構築されたのかまで明らかになります。
    • Transformation
      • dbt docs
        • Directory構造の変更(WIP. 現在再定義中なのでまだ変更は完了していないです)
          • stg, int, mart Layerに分離するのはもちろん、Mart LayerもBusiness Definedになるように分けている
        • dbtではymlでschema情報を整備することができます。
        • 弊社では、今までschema.ymlの中に複数tableの情報を記載していたが、Cursorなどでtable情報を読み取る際に大量のコンテキストを消費してしまうため、1 table 1 ymlファイルに分割しました
      • table description
        • tableの説明。ごく稀にしか利用しないもの、各SaaSから取得したものに関しては特に記載をしていなかった過去があるため、改めて埋める努力を行いました。AIからすると、table名からしか予測できなくなるためなるべく入力するようにしました。ミツモアではtableから中身を推測できるようにtable名を長くすると言うようなことは一切していなかったため、基本類推できない場合はAIからは全部無視されていました。
        • こちらは、まだCIで入力がなければパスしないようなことまでは行っていません。リリース速度はその時点で落とすことはせずにカバレッジを計測することでカバーしています。
        • 別の記事で紹介予定ですが、タグをうまくつけることによってここは回避しています。
      • field description
        • stg, int, martそれぞれでtable/field descriptionカバレッジを可視化して％を上げる。
      • docs blockの廃止
        • ビジネス側にも編集運用を促す仕組みにするためSource Data Catalogを表で管理しておりビジネス側のメンバーもEditableな状態にしていました。以前はその表からdocs blockを自動生成し、1 markdown fileのみを更新すれば良い状態にしていました。
        • しかし、AIが探索する時を考えた場合、docs block運用をしていた場合docs_block.md, table.yml, table.sqlの3ファイルを読み込まねばなりません。その点において探索範囲が分離してしまうという点と、それぞれのファイルのマッピングを行う処理において正確性の劣化が起きてしまうためdocs_block.mdの管理を取りやめtable.yml, table.sqlの2ファイルのみを参照すれば良い形に変更しました。

dbt Exposure

  • 重要な使われ方をしているものに対して登録を行いました。
    • 弊社では、”大事なもの”のみに絞ることにしています。
    • dbt exposureでは、Tableauのようなものも連携して自動反映させることが可能になっていますが、逆にDashboardで利用されているもの全部入れてしまうと、その重要度という価値が全て失われてしまうと判断しました。なぜかというと、
      • Analytics Engineering業務の側面からの不採用理由: 何かしらの下流のtableを修正する際、上流でどのように活用されているのはとても重要です。しかし、その際Exposureが大量にひょうじされていたらどうでしょうか？弊社ではたくさんのmodelが依存関係を持っているためほぼ全てのtableに依存関係があるようなLineageのようになってしまい、逆にチェックが非効率になってしまう（ExposureでImportance rankのような分類とフィルターがかけれるようになれば別です）。
      • Data Engineering業務の側面からの不採用理由: 弊社ではRedashを採用しており、Ubieさんでいうdbt model数3000+ に該当する部分の多くは現在は(良くも悪くも)Redashに偏っています。そのため、martでない下流側のtableを多く参照されているため、極端な話ほぼ全てのtableにexposureが紐づいてしまうような傾向が起きてしまい、LLMに渡す情報としても、人間が把握したい情報としても不適切になってしまう。

Business Context

  • 自社の施策情報、過去の意思決定、競合の動向、天気などなど、通常データベース化されていない非構造化データを含む情報は、通常はどの企業も各ツールや紙や人の頭の中にしかない情報、社外にあるようなケースもあったりします。真に意思決定を行うなどのことをしようとした場合、それらに対して包括してアクセスし正しい鮮度のデータを正しくフィルターした上で取得できることが望ましいです。そうすることで、より正しい分析および考察などを行うことができるようになると考えています。が、ここについてはまだ何も考えれていません。

PII & Security

  • 弊社ではPIIの制限をある程度は行っていたのですが、Google Cloudの機能を用いていなかったため、柔軟性がなく、限界がきていました。また、text2SQLを媒体としてデータにアクセスする場合、text2SQLそれ自体とそこから作成された成果物にセンシティブデータが含まれていた場合、それは利用者≒全社員がアクセスできることになってしまいます。AI Readyを推進するため改めてアカウント管理とPII管理方法に関しての再整備を行いました。

データ分析基盤のFreshness（≠ table freshness）

  • 全ての変化に対して検知し反映を行うための仕組みづくりが主な活動です。2ヶ月後あたりに別記事書きます。
  • 数ヶ月前までにdbt testなどを大量に仕込み、大量にアラートを検知できるようにしました。それにより現在では次の検知が行えるようになっています。
    • dbt test: unique checkなど
    • primary key check: ELTの欠損がないかの確認。実際にSource DBからELTとは別の手法にてPrimary Keyのみを抽出しダブルチェックを行っています (一部Sourceに対してのみ)
    • ELT Error
    • Transformation Error: 主にdbtによるエラー
    • Source DBのSchema変更: 新しい列が追加されたらすぐにデータ基盤も変更を行い、そのデータをアナリストがすぐに利用できる状態を目指すために検知
  • 現在、これらアラート全てをClaude Codeなどに渡しPRを行ってもらう仕組みを構築中です。この仕組みが完了すれば、なにかしらの変更があった、人間はPRのapproveを行ってmargeするタスクのみが存在することになります。

Analytics Engineering

  • 基本的には大福帳(One Big Table)の拡充を進めました。
  • データ分析基板が構築され6年ほど経過し、ほとんどの基本的な可視化はもう終わっており、さらに分析する際は重箱の隅をつつくようなカスタマイズを行なったものや、より多数のデータソースを組み合わせた分析などがよくあるケースです。そのため、今さらSemantic Layerを導入するなどを行なったところでビジネス側にとっては新しい価値を産まないような状態でした。そのような環境においては、より柔軟な分析を可能にしやすくするための準備が望ましいと考え、人にもAIにも優しいOBT充実戦略を採用しました。まだ道半ばです。

まとめ

ミツモアデータグループではAIを最大限活用し、より”Analysis”で価値を出すためデータエンジニアリング〜アナリストの領域に対して主にAI Readyな環境を整えつつありませす。よりこの領域を洗練させたり、さらにその先の”Analysis”へ価値を届けていく活動を行なっていきます。

特に、内製text2SQLなどでアナリスト業務に近い領域においてWith AIな環境が整いつつあります。

次回以降の記事にてtext2SQLについて紹介をしていきます！

ミツモアで一緒に働きませんか？

ミツモアでは、データやAIを活用してデータドリブンな風土のある会社にて一緒に働く仲間を募集中です。

「技術で課題を解くことにワクワクできる人」や「仕組みで社会を良くしたい、そんなエンジニアになりたい人」、ぜひご応募をお待ちしています！

ミツモア採用ページ: https://corp.meetsmore.com/