AIエージェント時代のデータマート ― 静的マートの限界と、目的に応じた特徴量の自動生成

AIエージェントの時代には、データマートの作り方を見直す必要があります。分析の目的ごとに必要な属性を、1つの静的なマートに足し続けるやり方では、エージェントが分析を進めるスピードに追いつけないからです。

dotDataは、分析の目的に関係するデータ上のパターンである「特徴量」を、AIエージェントに定量的な根拠を与えるデータとして捉え直しています。特徴量は目的によって変わります。そのため、全社で共有する標準的なデータと、目的に応じて特徴量を自動生成する仕組みを分けて設計することが重要になります。

本記事では、次の内容を解説します。

• AIエージェントに必要な3つの知識
• AIエージェントの時代における特徴量の役割
• 静的なデータマートが抱える限界
• 目的に応じて特徴量を自動生成するアーキテクチャ
• LLMに直接分析させる場合との違い

AIエージェントに必要な3つの知識

AIエージェントが自社の分析で精度を出すには、3種類の知識をそろえる必要があります。

• 世界知識：LLM（大規模言語モデル）そのものが持つ、世の中の幅広い知識です。モデルは提供各社で特徴が異なります。最新のモデルを使い分けられる状態にしておくことが、世界知識へのアクセスを確保することにつながります。
• ドメイン知識：業務に関する知識です。多くは文書などの非構造データとして存在します。RAG（検索拡張生成）などを使って、エージェントがアクセスできる形にしておきます。
• データからの知識：データの中には、世界知識にも業務の知見にもないパターンが埋もれています。ある目的に対して、データのどこにパターンがあるのかを見つける必要があります。dotDataは、このパターンを「特徴量」と呼んでいます。

データ分析の分野では、何十年にもわたって「データドリブン」が重視されてきました。データの中に、人の経験や知識だけでは得られない知見があるからです。AIエージェントの時代でも、この点は変わりません。

AI-Ready Dataとはでは、データに意味（定義と文脈）を与える考え方を解説しました。本記事では、3つの知識のうち、データからの知識を扱います。

特徴量の再定義：AIエージェントに定量的な根拠を与えるデータ

特徴量の役割は、機械学習モデルやBIの入力となる変数から、AIエージェントに定量的な根拠を与えるデータへと広がりつつあります。特徴量が重要なのは、分析の答えが生のデータそのものではなく、目的に関係するパターンの中にあるからです。同じ顧客データでも、どのパターンを取り出すかによって、予測の精度も、打つべき施策も変わります。dotDataは、2018年にNECからのスピンアウトとして創業して以来、この特徴量の設計を自動化する技術に取り組んできました。特徴量エンジニアリングの基本は、解説：機械学習のための特徴量設計で紹介しています。

目的に関係するデータ上のパターン

dotDataは、特徴量を「分析の目的に関係するデータ上のパターン」と捉えています。

• 金融の例：銀行がローン商品の販売を伸ばしたい場合、顧客の属性、オンラインバンキングの利用状況、運用している金融商品、コールセンターへの問い合わせ内容などから、ローンを利用しそうな顧客の特徴が見えてきます。
• 製造の例：製品の設計や製造工程で、どのような条件がそろうと不良が増えるのか、という関係が特徴量にあたります。この関係が分かれば、設計や工場の運用を改善して不良を減らせます。

データの種類ごとの特徴量の例

特徴量は、元になるデータの種類によって作り方が変わります。代表的な例は次のとおりです（いずれも説明のための例です）。

データの種類	特徴量の例	詳しい解説
カテゴリ変数（商品カテゴリ、地域など）	カテゴリごとの出現頻度、購買に占めるカテゴリ別の比率	カテゴリ属性に対する特徴量設計
日付・時刻	曜日別の利用比率、前回購入からの経過日数	時系列モデルの手法と時間データの特徴量設計
時系列・トランザクション	直近30日の購買回数、過去90日の利用額の移動平均、利用回数の増減	時系列データの特徴量設計 – パート2
テキスト（問い合わせ履歴、レビューなど）	問い合わせ内容の意味を表すラベル、話題ごとの出現件数	dotData TextSense

時系列やトランザクションのデータでは、「どの期間で」「どう集計するか」の組み合わせで候補が大きく増えます。この組み合わせを人手で網羅するのは難しく、自動生成が効果を発揮しやすい領域です。

これまでとこれからの特徴量

これまで特徴量は、主に機械学習モデルの予測精度を高めるための説明変数や、BIの入力として使われてきました。AIエージェントの時代には、新しい役割が加わります。エージェントの分析・仮説・アクションに定量的な根拠を与え、その精度を高めるデータとしての役割です。dotDataは、特徴量を定量側のAI-Ready Dataと位置づけています。

AI-Ready Dataとはで紹介した3層構造（土台／セマンティック／コンテキスト）は、特徴量にもそのまま当てはまります。ここでは、目的を「解約予測」、特徴量を「直近30日のログイン回数」とした例で説明します（数値はすべて説明のための例です）。

層	特徴量での中身	例：解約予測と「直近30日のログイン回数」
③コンテキスト（意味＝文脈）	目的別の統計、リフト（その特徴を持つ顧客で、目的の事象が全体の平均の何倍起きやすいか）、説明文。その目的に、どの特徴量がどれだけ効くか	解約予測という目的では、「直近30日のログイン回数が少ない顧客は解約しやすい」
②セマンティック（意味＝定義）	特徴量パイプライン、クエリ定義。生データから特徴量を同じ定義で生成・再現する	ログイン履歴を、顧客ごとに過去30日分集計する。誰が算出しても同じ値になり、毎月の新しいデータにも同じ定義で再生成できる
①土台（BI-Ready Data）	特徴量テーブル。目的に合わせて集約・整理した「顧客×特徴量」の表	顧客C001はログイン3回、顧客C002は27回

この表で重要なのは、③コンテキストの中身が目的によって変わる点です。同じ「ログイン回数」でも、解約予測では、ログイン回数が減った顧客が注目すべき対象になります。一方、ある商品の購買予測では、ログイン回数が増えた顧客が、購入しそうな顧客として注目されるかもしれません。特徴量の意味は、目的、つまりコンテキストによって決まります。

なお、この表の③は事前に計算しておく統計ですが、エージェントが問いに応じて、目的に合う統計と説明を実行時に受け取るという意味で、コンテキスト層にあたります。

従来のアプローチ：横に長い統合マートを全社で共有する

BIや機械学習の時代には、データマートや特徴量ストア（フィーチャーストア）を先に作り、全社で共有するのが定石でした（特徴量ストアについてはDatabricksの特徴量ストアとAutoMLの記事で解説しています）。

販売、顧客、商品、キャンペーン、在庫などのデータを結合し、横に長い統合分析テーブルを作ります。日本では「大福帳」と呼ばれることもある形式です。このテーブルを最初に整備しておき、さまざまな分析テーマで使い回します。データマートを含むデータ基盤の構成については、データ活用基盤とは？で解説しています。

このアプローチには合理性があります。

• 定義の統一：全社で同じ定義の属性を使える
• 再利用：一度作った属性を、ほかの分析でも使える
• 正確性：重要な指標や定常的なレポートを、確定した定義で安定して提供できる

特に、重要な指標や定常レポートを支えるマートの役割は、AIエージェントの時代になっても変わりません。問題が生じるのは、分析テーマが増えるたびに、そのテーマのための属性（列）をマートに足していく運用です。

静的なマートが負債になる悪循環

分析のテーマが増えるほど、属性を足し続ける静的なマートは、システムと組織の負債になっていきます。たとえば、dotDataが支援している欧州の通信事業者では、10年以上かけてマートが数万列に膨らみ、パイプラインの修正と再計算の負担が大きくなっていました。この章では、負債が生まれる理由を、分析スピードの変化と、悪循環を生む4つの要素に分けて説明します。データマートを含むデータ基盤の基本的な構成は、データ活用基盤とは？で解説しています。

分析のスピードが上がると、テーマが増え続ける

AIによって、分析のスピードは大きく上がります。dotDataは、その変化を次のようなイメージで捉えています（実測値ではなく、加速の方向を示すイメージです）。かつて数カ月かかっていた分析が、自動化ツールによって1カ月に、AIの支援によって1週間に、エージェントによって1日に、と短くなっていけば、取り組める分析テーマは次々に増えていきます。テーマが増えるたびに属性を足していけば、マートは横に伸び続けます。

静的マートの悪循環を生む4つの要素

前述の通信事業者のように列が数万に達すると、次のような悪循環が生まれます。

1. メンテナンスコストの増大：データパイプラインが頻繁に壊れ、そのたびに修正が必要になります。数万列のマートを再計算するコストも大きくなります。
2. 鮮度の劣化：人は列を足すのは得意でも、捨てるのは苦手です。有効かどうか分からなくなった列が、大量に残り続けます。古い列を選別するのは大変ですが、選別しなければ、ビジネス部門に新鮮な情報を届けられません。
3. リソースのボトルネック：新しいテーマのたびに、データチームに属性追加の依頼が集中します。データチームは依頼をこなす受託者のようになり、新しいテーマに着手するまで数カ月待ち、という状況が生まれます。
4. 野良マートの乱立：待てない業務部門は、ガバナンスの外で独自にデータを加工し始めます。いわゆる「野良マート」が乱立し、データの品質が下がり、メンテナンスの負担がさらに増えます。

この悪循環は、1に戻って繰り返されます。AIエージェントの時代に分析のサイクルが速くなれば、このアプローチのままでは、データの側がボトルネックになります。エージェントがどれほど賢くても、必要なデータが用意できなければ、分析は進みません。

なぜ「全テーマ共通の理想のマート」は作れないのか

特徴量は目的によって変わるため、すべての分析テーマで共有できる理想のマートは存在しません。

先ほどのログイン回数の例のように、同じデータでも、目的によって注目すべきパターンは違います。必要な属性そのものも、目的ごとに異なります。

• 高単価商品のターゲティングでは、消費の余力や購買の広がりを表す属性が必要です。
• ブランドからの離反の予兆検知では、配送の速さへのこだわりや、ブランドの乗り換え傾向を表す属性が必要です。
• クーポン施策の最適化では、まとめ買いの傾向や、クーポンへの反応の速さを表す属性が必要です。

1つの共有マートで、これらすべての目的に応えようとすると、目的の数だけ列が増えていきます。どの目的にも通用するデータを事前に用意しておくことはできない、という考え方はAI-Ready Dataとはでも紹介しました。dotDataは、特徴量のような定量的なデータも、同じように目的に依存すると考えています。

ここから導かれるのは、全社で共有すべき本質的な属性と、目的ごとに必要な属性を分けて扱う、という考え方です。前者は共有し、後者は目的に応じて自動で生成します。

目的に応じて特徴量を自動生成するアーキテクチャ

dotDataは、共有する標準データと、目的ごとに生成する特徴量を分け、目的変数を起点に特徴量を自動生成するアーキテクチャを提案しています。目的変数とは、分析の目的をデータで表したもの（例：解約したかどうか、成約したかどうか）です。

共有する部分：軽い標準データ

全社で共有するのは、作り込んだ巨大なマートではありません。次のような軽い標準データです。

• 領域ごとの標準テーブルセット：販売、顧客、商品など、領域ごとに整えたテーブル群（データセット）
• ER定義：テーブル同士の関係
• 基本属性：多くの分析で共通して使う本質的な属性
• 分析単位：顧客ID、製品ID、店舗IDなど、何を単位に分析するか

標準データは、新しく作り込む必要はありません。DatabricksやSnowflakeなどのデータ基盤上で、すでに整備されているテーブルを起点にできます。dotData Feature Factoryは、こうした複数のテーブルとテーブル同士の関係を入力にして、特徴量を生成します。

目的ごとに生成する部分：目的変数から特徴量を自動生成

分析テーマごとに、目的変数を標準データに接続すると、その目的に合った特徴量が自動で生成されます。流れは次の4ステップです。

1. 標準データと目的変数をつなぐ：分析テーマごとに、目的変数を標準データに接続します。
2. 特徴量を自動で抽出する：目的変数との関係が強いパターンを、複数のテーブルを横断して網羅的に探索し、新しい特徴量として生成します（特徴量自動設計）。
3. 定量的なコンテキストを付ける：抽出した特徴量に、ビジネス上の意味（説明文や統計情報）を付与します。
4. コンテキストレポートを作る：特徴量、LLM、業務の文脈を組み合わせて、分析結果の解釈や施策の案をまとめます。

ステップ1と2は、特徴量自動設計による自動化です。ステップ3と4は、特徴量とLLMを組み合わせた意味づけです。生成された特徴量は、統計的な裏付けのある事実として、LLMやエージェントに渡されます。

特徴量を自動生成する主な方法

特徴量を自動生成する方法には、主に次のようなものがあります。

• テンプレートによる生成：「直近30日」「直近90日」などの時間窓と、件数・合計・平均などの集計関数を組み合わせて、候補を機械的に作ります（数値は例です）。
• テーブルの関係に沿った探索：テーブル同士の関係（ER）をたどって、関連するデータを集計した特徴量を作ります。
• LLMによる発想の支援：LLMに業務の説明とテーブルの構成を渡し、特徴量の候補を挙げさせます。発想を広げるのに役立ちますが、計算の正確さと網羅性は別に確かめる必要があります。
• 網羅的な探索と統計的な評価：dotDataの特徴量自動設計は、複数のテーブルから数百〜数千のパターンを探索し、目的変数との関係の強さで評価して選びます。

手作業の特徴量エンジニアリングとの違い

従来の特徴量エンジニアリングは、分析者の手作業によるプロセスでした。分析者が経験と知識をもとに仮説を立て、PythonやSQLでデータの抽出・集計・変換の処理を書いて特徴量を作成し、機械学習モデルで効果をテストします。この作業には時間がかかるため、1つのテーマで検証できる仮説の数には限りがありました。目的に応じた特徴量の自動生成は、このプロセスの考え方を次のように変えます。

観点	手作業の特徴量エンジニアリング	目的に応じた特徴量の自動生成
仮説の出し方	分析者の経験と知識に基づいて、候補を選ぶ	アルゴリズムが複数のテーブルを横断して、パターンを網羅的に探索する
作業のプロセス	特徴量ごとに、抽出・集計・変換の処理を書き、モデルでテストする	目的変数を与えると、特徴量の生成から評価までを自動で行う
テーマが増えたとき	分析者の作業時間が、テーマの数に比例して増える	目的変数を差し替えて、同じ手順を繰り返せる
再現性	担当者ごとのコードに依存しやすい	特徴量パイプラインとして、同じ定義で再生成できる

人の経験と知識が不要になるわけではありません。どの目的変数を設定するか、生成された特徴量をどう解釈して施策につなげるかは、引き続き人が判断します。自動生成は、仮説の候補を広げ、作業の効率を高めるための手法です。

コストをテーマの数から切り離す

このアーキテクチャでdotDataが目指すのは、データチームの工数を、分析テーマの数から切り離すことです。従来のアプローチでは、テーマが増えるほど、属性の追加と保守の工数が増えていきました。目的に応じて特徴量を自動生成する仕組みでは、テーマごとに人手で属性を追加・保守する負担が減り、保守の中心は共有する標準データに移ると、dotDataは考えています。属性を設計し、試し、評価するサイクルも短くなり、分析のPDCAを速く回せるようになります。

目的変数を差し替えるだけで、分析テーマを広げる

目的変数を差し替えると、生成される特徴量とレポートが変わります。そのため、1つの仕組みで多くの分析テーマに対応できます。dotDataは、2026年7月1日のウェビナー「AI Agentの新トレンド〜精度を決める『AI-Ready Data』〜」で、ローンの不履行リスクを目的変数にしたデモを通じて、この使い方を紹介しました。以下では、小売と金融の2つの例で説明します。

小売の例：目的変数ごとに生成される属性

次の表は、小売の分析を想定した例です（いずれも説明のための例です）。

目的変数の例	生成される属性のイメージ	活用シーン
新商品の購買	早期に購入する層、慎重に購入する層、価格に敏感な層	ターゲティングの高度化
クーポン施策への反応	週末にまとめ買いする層、配布後すぐに反応する層	クーポン配布の最適化
ブランドからの離反	配送の速さを重視する層、ブランドを乗り換えやすい層	離反の予兆の早期検知
高単価カテゴリの購買	消費の余力があり購買の幅を広げている層、上質志向の層	クロスセル・アップセル

金融の例：与信の分析を別のテーマに切り替える

金融の与信を例にとります。ローンの不履行リスクを目的変数にすると、リスクの高い顧客と低い顧客の特徴が抽出されます。そこに業務の文脈を与えると、地域のリスクに応じた与信、返済の余力という観点での審査、生活基盤の異なる顧客層ごとの施策といった解釈や提案が導かれます。

ここで目的変数を、別のローン商品の不履行リスクに差し替えれば、同じ仕組みで別の商品の分析ができます。新規のローン申込みのように、まったく異なるテーマに切り替えることもできます。目的変数を差し替えるだけで、特徴量が変わり、レポートの内容も変わります。

この仕組みは、AIが人の分析を支える「AI拡張型」の分析にも、分析そのものをAIエージェントに任せる「エージェント駆動型」の分析にも、基盤になります（3つの段階についてはAIエージェントを活用したデータ分析の現在地で解説しています）。

LLMに直接分析させる場合との違い

「LLMに直接データを渡して分析させればよいのではないか」という疑問もよく聞かれます。dotDataの考えは、統計的に確定させるべき部分を先に特徴量として出し、それをLLMに渡すほうが、分析の精度が上がるというものです。違いは2つあります。

網羅性の違い

LLMに解約の分析を任せると、LLMはデータの項目を見て推論し、人の勘のように、5個から10個程度の要因を選んで計算します。dotDataの特徴量自動設計のアルゴリズムは、複数のテーブルから、目的ごとに数百から数千のパターンを統計的に探索し、その中から目的との関係が強いものを選びます。探索の網羅性が違うため、見つかる要因の質も変わります。

計算の正確性の違い

アクセスログのような縦に長いトランザクションデータは、そのままではLLMに入力できません。そのため、LLMにデータを集計・変換するクエリを書かせることになりますが、加工が複雑になるほど誤りが入り込みやすくなります。特徴量パイプラインは、定義に従って同じ計算を再現するため、計算の正確性を保てます。

網羅的に探索され、正確に計算された特徴量をLLMに渡すことで、エージェントにコンテキストを与えて精度を高めるのと同様の効果を、定量の側で得られると、dotDataは考えています。

dotDataのアプローチ

dotDataは、特徴量自動設計の技術を核に、AIエージェントのための定量的なデータを、目的ごとに生成することに取り組んでいます。

• 特徴量自動設計（Automated Feature Engineering）：目的変数を与えると、複数のテーブルを横断して特徴量のパターンを網羅的に探索し、目的との関係が強い特徴量を見つけます。
• dotData Feature Factory：特徴量を、再現可能な特徴量パイプラインとして管理し、さまざまなデータアプリケーションで活用できるようにします。
• dotData Insight：特徴量と生成AIを組み合わせ、ビジネスの課題に対する分析とレポートを提供します。

2026年12月9日（水）12:00〜13:00には、dotData CEOの藤巻が登壇するウェビナー「AI Agentの価値は、データで決まる 〜北米で起きているデータ基盤の再定義〜」を開催します。AIエージェントの時代にデータ基盤をどう考えるべきかを、北米の動向を交えてお話しします。詳細・お申し込みはウェビナーのページをご覧ください。

まとめ

• 特徴量は、AIエージェントに定量的な根拠を与えるデータです。その意味は、分析の目的によって決まります。
• 重要な指標や定常レポートのためのマートは、引き続き必要です。一方で、目的別の属性を静的なマートに足し続けるやり方は、テーマが増えるほど負債になります。
• 共有する標準データと、目的に応じて特徴量を自動生成する仕組みを分けることで、エージェントの分析のスピードに追随できるようになります。

dotDataは、dotData Feature FactoryとdotData Insightを通じて、この考え方の実装に取り組んでいます。2026年12月9日のウェビナー「AI Agentの価値は、データで決まる」では、AIエージェントの時代のデータ基盤について解説します。

AIエージェントによるデータ分析の全体像はAIエージェントを活用したデータ分析の現在地で、データの意味を整える考え方はAI-Ready Dataとはで解説しています。

データマートと特徴量の自動生成に関するよくある質問