AIエージェントの時代には、データマートの作り方を見直す必要があります。分析の目的ごとに必要な属性を、1つの静的なマートに足し続けるやり方では、エージェントが分析を進めるスピードに追いつけないからです。 dotDataは、分析の目的に関係するデータ上のパターンである「特徴量」を、AIエージェントに定量的な根拠を与えるデータとして捉え直しています。特徴量は目的によって変わります。そのため、全社で共有する標準的なデータと、目的に応じて特徴量を自動生成する仕組みを分けて設計することが重要になります。 本記事では、次の内容を解説します。 AIエージェントに必要な3つの知識 AIエージェントの時代における特徴量の役割 静的なデータマートが抱える限界 目的に応じて特徴量を自動生成するアーキテクチャ LLMに直接分析させる場合との違い AIエージェントに必要な3つの知識 AIエージェントが自社の分析で精度を出すには、3種類の知識をそろえる必要があります。 図：AI時代のデータ活用に求められる3つの知識（図中の「データ知識」は本文の「データからの知識」にあたります）（出典：dotData Webinar資料「AI Agentの新トレンド〜精度を決める『AI-Ready Data』〜」（2026年7月）より） 世界知識 ：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と位置づけています。 図：特徴量の再定義：エージェントのための定量的なデータ（出典：dotData Webinar資料「AI Agentの価値は、データで決まる」（2026年12月）より） AI-Ready Dataとは で紹介した3層構造（土台／セマンティック／コンテキスト）は、特徴量にもそのまま当てはまります。ここでは、目的を「解約予測」、特徴量を「直近30日のログイン回数」とした例で説明します（数値はすべて説明のための例です）。 層 特徴量での中身 例：解約予測と「直近30日のログイン回数」 ③コンテキスト（意味＝文脈） 目的別の統計、リフト（その特徴を持つ顧客で、目的の事象が全体の平均の何倍起きやすいか）、説明文。その目的に、どの特徴量がどれだけ効くか 解約予測という目的では、「直近30日のログイン回数が少ない顧客は解約しやすい」 ②セマンティック（意味＝定義） 特徴量パイプライン、クエリ定義。生データから特徴量を同じ定義で生成・再現する ログイン履歴を、顧客ごとに過去30日分集計する。誰が算出しても同じ値になり、毎月の新しいデータにも同じ定義で再生成できる ①土台（BI-Ready Data） 特徴量テーブル。目的に合わせて集約・整理した「顧客×特徴量」の表 顧客C001はログイン3回、顧客C002は27回 この表で重要なのは、③コンテキストの中身が目的によって変わる点です。同じ「ログイン回数」でも、解約予測では、ログイン回数が減った顧客が注目すべき対象になります。一方、ある商品の購買予測では、ログイン回数が増えた顧客が、購入しそうな顧客として注目されるかもしれません。特徴量の意味は、目的、つまりコンテキストによって決まります。 なお、この表の③は事前に計算しておく統計ですが、エージェントが問いに応じて、目的に合う統計と説明を実行時に受け取るという意味で、コンテキスト層にあたります。 従来のアプローチ：横に長い統合マートを全社で共有する BIや機械学習の時代には、データマートや特徴量ストア（フィーチャーストア）を先に作り、全社で共有するのが定石でした（特徴量ストアについては Databricksの特徴量ストアとAutoMLの記事 で解説しています）。 販売、顧客、商品、キャンペーン、在庫などのデータを結合し、横に長い統合分析テーブルを作ります。日本では「大福帳」と呼ばれることもある形式です。このテーブルを最初に整備しておき、さまざまな分析テーマで使い回します。データマートを含むデータ基盤の構成については、 データ活用基盤とは？ で解説しています。 このアプローチには合理性があります。 定義の統一 ：全社で同じ定義の属性を使える 再利用 ：一度作った属性を、ほかの分析でも使える 正確性 ：重要な指標や定常的なレポートを、確定した定義で安定して提供できる 特に、重要な指標や定常レポートを支えるマートの役割は、AIエージェントの時代になっても変わりません。問題が生じるのは、分析テーマが増えるたびに、そのテーマのための属性（列）をマートに足していく運用です。 静的なマートが負債になる悪循環 分析のテーマが増えるほど、属性を足し続ける静的なマートは、システムと組織の負債になっていきます。たとえば、dotDataが支援している欧州の通信事業者では、10年以上かけてマートが数万列に膨らみ、パイプラインの修正と再計算の負担が大きくなっていました。この章では、負債が生まれる理由を、分析スピードの変化と、悪循環を生む4つの要素に分けて説明します。データマートを含むデータ基盤の基本的な構成は、 データ活用基盤とは？ で解説しています。 図：レガシーアプローチの限界：静的マートという「負債」（出典：dotData Webinar資料「AI Agentの新トレンド〜精度を決める『AI-Ready Data』〜」（2026年7月）より） 分析のスピードが上がると、テーマが増え続ける AIによって、分析のスピードは大きく上がります。dotDataは、その変化を次のようなイメージで捉えています（実測値ではなく、加速の方向を示すイメージです）。かつて数カ月かかっていた分析が、自動化ツールによって1カ月に、AIの支援によって1週間に、エージェントによって1日に、と短くなっていけば、取り組める分析テーマは次々に増えていきます。テーマが増えるたびに属性を足していけば、マートは横に伸び続けます。 静的マートの悪循環を生む4つの要素 前述の通信事業者のように列が数万に達すると、次のような悪循環が生まれます。 メンテナンスコストの増大 ：データパイプラインが頻繁に壊れ、そのたびに修正が必要になります。数万列のマートを再計算するコストも大きくなります。 鮮度の劣化 ：人は列を足すのは得意でも、捨てるのは苦手です。有効かどうか分からなくなった列が、大量に残り続けます。古い列を選別するのは大変ですが、選別しなければ、ビジネス部門に新鮮な情報を届けられません。 リソースのボトルネック ：新しいテーマのたびに、データチームに属性追加の依頼が集中します。データチームは依頼をこなす受託者のようになり、新しいテーマに着手するまで数カ月待ち、という状況が生まれます。 野良マートの乱立 ：待てない業務部門は、ガバナンスの外で独自にデータを加工し始めます。いわゆる「野良マート」が乱立し、データの品質が下がり、メンテナンスの負担がさらに増えます。 この悪循環は、1に戻って繰り返されます。AIエージェントの時代に分析のサイクルが速くなれば、このアプローチのままでは、データの側がボトルネックになります。エージェントがどれほど賢くても、必要なデータが用意できなければ、分析は進みません。 なぜ「全テーマ共通の理想のマート」は作れないのか 特徴量は目的によって変わるため、すべての分析テーマで共有できる理想のマートは存在しません。 先ほどのログイン回数の例のように、同じデータでも、目的によって注目すべきパターンは違います。必要な属性そのものも、目的ごとに異なります。 高単価商品のターゲティング では、消費の余力や購買の広がりを表す属性が必要です。 ブランドからの離反の予兆検知 では、配送の速さへのこだわりや、ブランドの乗り換え傾向を表す属性が必要です。 クーポン施策の最適化 では、まとめ買いの傾向や、クーポンへの反応の速さを表す属性が必要です。 1つの共有マートで、これらすべての目的に応えようとすると、目的の数だけ列が増えていきます。どの目的にも通用するデータを事前に用意しておくことはできない、という考え方は AI-Ready Dataとは でも紹介しました。dotDataは、特徴量のような定量的なデータも、同じように目的に依存すると考えています。 ここから導かれるのは、全社で共有すべき本質的な属性と、目的ごとに必要な属性を分けて扱う、という考え方です。前者は共有し、後者は目的に応じて自動で生成します。 目的に応じて特徴量を自動生成するアーキテクチャ dotDataは、共有する標準データと、目的ごとに生成する特徴量を分け、目的変数を起点に特徴量を自動生成するアーキテクチャを提案しています。目的変数とは、分析の目的をデータで表したもの（例：解約したかどうか、成約したかどうか）です。 図：目的に応じて特徴量を自動生成するアーキテクチャ（出典：dotData Webinar資料「AI Agentの新トレンド〜精度を決める『AI-Ready Data』〜」（2026年7月）より） 共有する部分：軽い標準データ 全社で共有するのは、作り込んだ巨大なマートではありません。次のような軽い標準データです。 領域ごとの標準テーブルセット ：販売、顧客、商品など、領域ごとに整えたテーブル群（データセット） ER定義 ：テーブル同士の関係 基本属性 ：多くの分析で共通して使う本質的な属性 分析単位 ：顧客ID、製品ID、店舗IDなど、何を単位に分析するか 標準データは、新しく作り込む必要はありません。DatabricksやSnowflakeなどのデータ基盤上で、すでに整備されているテーブルを起点にできます。 dotData Feature Factory は、こうした複数のテーブルとテーブル同士の関係を入力にして、特徴量を生成します。 目的ごとに生成する部分：目的変数から特徴量を自動生成 分析テーマごとに、目的変数を標準データに接続すると、その目的に合った特徴量が自動で生成されます。流れは次の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つの例で説明します。 図：目的変数を切り替えるだけで多目的に展開する（出典：dotData Webinar資料「AI Agentの新トレンド〜精度を決める『AI-Ready Data』〜」（2026年7月）より、一部改変） 小売の例：目的変数ごとに生成される属性 次の表は、小売の分析を想定した例です（いずれも説明のための例です）。 目的変数の例 生成される属性のイメージ 活用シーン 新商品の購買 早期に購入する層、慎重に購入する層、価格に敏感な層 ターゲティングの高度化 クーポン施策への反応 週末にまとめ買いする層、配布後すぐに反応する層 クーポン配布の最適化 ブランドからの離反 配送の速さを重視する層、ブランドを乗り換えやすい層 離反の予兆の早期検知 高単価カテゴリの購買 消費の余力があり購買の幅を広げている層、上質志向の層 クロスセル・アップセル 金融の例：与信の分析を別のテーマに切り替える 金融の与信を例にとります。ローンの不履行リスクを目的変数にすると、リスクの高い顧客と低い顧客の特徴が抽出されます。そこに業務の文脈を与えると、地域のリスクに応じた与信、返済の余力という観点での審査、生活基盤の異なる顧客層ごとの施策といった解釈や提案が導かれます。 ここで目的変数を、別のローン商品の不履行リスクに差し替えれば、同じ仕組みで別の商品の分析ができます。新規のローン申込みのように、まったく異なるテーマに切り替えることもできます。目的変数を差し替えるだけで、特徴量が変わり、レポートの内容も変わります。 この仕組みは、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とは で解説しています。 The post AIエージェント時代のデータマート ― 静的マートの限界と、目的に応じた特徴量の自動生成 appeared first on dotData .

AI-Ready Data（AI-Readyデータ、AI Ready Dataとも表記）とは、特定の用途に対して、AIが正しく使える状態にあるデータのことです。調査会社のGartnerは、AI-Readyなデータを「そのユースケースを代表するデータ」と位置づけ、一度整えれば終わりではなく、用途ごとに継続的に整え続ける実践だとしています。 生成AIやAIエージェントの活用が広がるなかで、「データはきれいに整備されているのに、エージェントが正しく答えない」という声を、dotDataは企業との議論の中で多く聞くようになりました。dotDataは、その原因がデータの「意味」の不足にあると考えています。BIのために整えたデータ（BI-Ready Data）はAI-Ready Dataの土台ですが、それだけでは足りません。データの上に、意味を「定義」として固定するセマンティック層と、問いごとに「文脈」を渡すコンテキスト層を重ねることが欠かせません。 本記事では、次の内容を紹介します。 AI-Ready Dataの定義と条件 ：Gartnerの説明と、「高品質なデータ」との違い AI-Ready Dataが重要な理由とリスク ：きれいなデータでもエージェントが誤答するのはなぜか AI-Ready Dataの3層構造 ：土台、セマンティック、コンテキストの役割 構造化データと非構造化データ ：どちらにも「意味の層」が欠かせない理由 業界の動向と導入の進め方 ：意味の層をどう作り、どう維持するか AI-Ready Dataとは：「用途に対してReady」という考え方 AI-Ready Dataとは、特定の用途に対して「AIが正しく使える」状態にあるデータを指す概念で、データそのものの品質だけを指すものではありません。AI-Readyかどうかは、データ単体ではなく、そのデータをどう使うかによって決まります。 AI-Readyとは、どのような状態か AI-Readyな状態とは、AIに任せる用途が決まり、その用途に合ったデータと、データの意味がそろっている状態です。Gartnerの説明とdotDataの整理を合わせると、次の5つが満たされた状況だといえます。 用途が決まっている ：AIに任せる業務と、答えるべき問いがはっきりしている 用途を代表するデータがある ：その用途で起こりうるパターンを、エラーや外れ値も含めて表すデータがそろっている（Gartner） 意味が定義されている ：指標の計算方法や業務用語の意味が、AIの参照できる形で定義されている（dotData） 問いごとに文脈を渡せる ：誰に向けた分析か、どの社内文書を前提にするかといった文脈を、実行時に渡せる（dotData） 継続的に確認されている ：用途への適合性が、一度きりではなく継続的に確認・更新されている（Gartner） AIにおけるデータセットとは AIにおけるデータセットとは、AIが学習・評価・実行のために使う、目的に沿って集めたデータのまとまりです。機械学習では、モデルを作るための学習用データと、精度を確かめるための評価用データを分けて用意します。生成AIやエージェントでは、モデル自体はすでに学習済みのことが多く、AI-Ready Dataとして整える対象の中心は、エージェントが実行時に参照するデータになります。具体的には、データベースのテーブル、社内文書、指標の定義などです。 AI-Ready Dataに必要な条件は何か Gartnerの説明に沿うと、AI-Ready Dataに必要な条件は、用途への整合、代表性、適格性の確認、統制、そしてそれらを支えるメタデータと継続的な実践です。Gartnerは2025年2月の発表で、次のように述べています（ Gartner, 2025年2月26日 ）。 “The data must be representative of the use case, of every pattern, errors, outliers and unexpected emergence that is needed to train or run the AI model for the specific use.” （データは、そのユースケースを代表していなければならない。つまり、特定の用途に向けてAIモデルを学習・実行するのに必要なあらゆるパターン、エラー、外れ値、予期せぬ事象までを含んでいなければならない） 同じ発表では、AI-Readyなデータを「メタデータを活用できることを前提に、データを用途に整合させ（align）、適格性を確認し（qualify）、統制する（govern）プロセスであり実践」と説明しています。Gartnerの説明を条件として整理すると、次のとおりです。 条件 内容 用途への整合（align） AI-Readyかどうかは、データがどう使われるかで決まる。まず用途にデータを合わせる 代表性 その用途に必要なパターンを、エラーや外れ値も含めて表している 適格性の確認（qualify） そのデータが用途に適しているかを確かめる 統制（govern） 用途ごとに、データの扱いのルールを決めて運用する メタデータの活用 整合・確認・統制を行うための前提として、メタデータが使える 継続的な実践 一度整えれば終わりではなく、用途ごとに整合・確認・統制を続ける dotDataは、これらに加えて、データの「意味」を整えることを、エージェントの時代に特に欠かせない条件だと考えています。指標や用語の定義（セマンティック）と、問いごとの文脈（コンテキスト）です。この「意味の層」については、後の章で詳しく説明します。 「汎用のAI-Ready Data」は存在しない AI-Readyかどうかは用途ごとに決まるため、どの用途にも通用する「汎用のAI-Ready Data」はありません。Gartnerも、「データを一般的に、あるいは事前にAI-Readyにする方法はない。AIへの準備ができているかどうかは、そのデータがどう使われるかによって決まる」と述べています（ Gartner ）。 ガートナージャパンも2026年5月の発表で、社内データを一元管理し、全体にガバナンスをかけ、メタデータを付与すればAI-Readyになる、という考え方を誤りとして挙げています。そのうえで、現場の課題（ユースケース）を起点に、適合性を証明できるデータは何かを考えるべきだとしています（ ガートナージャパン ）。 高品質なデータが、AI-Readyとは限らない 従来の基準で高品質とされるデータでも、AI-Readyであるとは限りません。Gartnerは、「従来のデータ品質基準で『高品質』とされるデータが、そのままAI-Readyなデータであるとは限らない」と指摘しています（ Gartner ）。 Gartnerがこう指摘する理由は、代表性にあります。分析では、人の期待に沿うように外れ値を取り除き、データをクレンジングするのが一般的です。しかしAIには、その用途で起こりうるエラーや外れ値まで含めた、代表性のあるデータが欠かせません。BIのためにきれいに整えた結果、AIに欠かせない代表性が失われることもあるのです。 dotDataは、これとは別の観点からも、「BI-Ready Data（BIのために整えたデータ）はAI-Ready Dataと同じではない」と考えています。それが、データの「意味」です。BIでは、データの意味は画面を見る人が補って解釈します。エージェントの場合は、エージェント自身がデータの意味を正しく理解できなければ、正しい答えを出せません。次の章では、この「意味」がなぜ重要なのかを、具体例で見ていきます。 AI-Ready Dataが重要な理由とリスク：「きれいなデータ」でもAIエージェントは誤答する データの品質とは別に、言葉や数値の「意味」がずれていると、エージェントは正しい計算から誤った答えを出してしまいます。データ整備をBIのための水準にとどめていると、このずれは防げません。 AI-Ready Dataがないと、どのようなリスクがあるか AI-Ready Dataが整っていないまま生成AIやエージェントを使うと、主に次のリスクがあります。 誤答が意思決定に使われる ：もっともらしい誤りに気づかないまま、その答えが経営や現場の判断に使われる AIプロジェクトが価値を出せずに止まる ：PoC（概念実証）ではうまく見えても、本番の運用で精度が出ず、プロジェクトが放棄される AI活用が組織に定着しない ：利用者がエージェントの答えを信頼できなくなり、結局は人が手作業で確かめ直すことになる Gartnerは、AI-Readyなデータに支えられていないAIプロジェクトの60%が、2026年までに放棄されると予測しています。同社の調査では、63%の組織が「AIに適したデータ管理の実践を持っていない、または持っているか分からない」と回答しました（ Gartner, 2025年2月26日 ）。 誤答はどのように起きるか：「解約」の例 企業の業務部門には、「来月解約しそうな顧客はどこか」「商品Aの売上が下がったのはなぜか」といった問いがあります。こうした問いを、BIツールを操作せずに自然言語で尋ね、答えを得たいというニーズは多くの企業にあります。生成AIの中核であるLLM（大規模言語モデル）とエージェントを使ってプロトタイプを作ると、それらしい答えがすぐに返ってくるため、実現できそうに見えます。しかし本番の運用では、うまくいかないケースが少なくありません。 その原因の1つが、言葉の定義のずれです。「解約」を例に考えてみます。 ハードな解約 ：顧客が解約手続きをして、サービスの利用を終える ソフトチャーン ：解約手続きはしていないが、利用率が半分以下に落ちるなど、実質的に離れていく 製品・サービスごとの違い ：同じ会社の中でも、製品やサービスによって解約の定義が異なる Aさんはハードな解約を、Bさんはソフトチャーンを思い浮かべて質問しているかもしれません。さらに、エージェントも学習した知識から、独自の「解約」の定義を持っています。全員が「解約」という同じ言葉を使いながら、違う定義のまま分析が進むと、エージェントの答えはもっともらしく見えても、問いとは食い違います。利用者から見ると、ハルシネーション（AIがもっともらしい誤りを生成すること）のように見える誤りです。 この問題は、データをどれだけきれいにクレンジングしても解決しません。顧客データが正しく整備されていても、「解約」の意味が共有されていなければ、正しい答えは得られないからです。エージェントの時代に問われるデータの質とは、データの量や正確さだけでなく、こうした「意味の土台」が整っているかどうかです。 事例：セマンティックレイヤーで指標を統一したiFood iFoodは、セマンティックレイヤーで指標を標準化し、数字を突き合わせる作業の負荷を減らすとともに、AIアシスタントの精度を高めました。iFoodはラテンアメリカでフードデリバリーのサービスを展開する企業で、この事例はDatabricksが2026年4月に公表したものです。 図：事例：セマンティックレイヤーで「正しい数字」が返るiFood（出典：dotData Webinar資料「AI Agentの新トレンド〜精度を決める『AI-Ready Data』〜」（2026年7月）より） 課題 ：指標の数字を突き合わせる作業に、大きな負荷がかかっていました。 取り組み ：Databricksのメトリックビュー（Metric Views）を使って指標を標準化し、AIアシスタントのGenieも、その一貫した事前集計データを使うようにしました。 成果 ：iFoodのPedro Alves氏は、「メトリックビューによって指標が標準化され、数字の突き合わせにかかる業務の負荷が大幅に減った。クエリは大幅に速くなり、ケースによっては最大10倍になった。ダッシュボードも作りやすくなった。一貫した事前集計データのおかげで、Genieの精度にも目に見える改善があった」とコメントしています（ Databricks ）。 ドイツのファッションEC企業Zalandoも、同じ考え方を取っています。Zalandoによると、ユーザーが「NMV（純商品価値）」を尋ねると、Genieは生のテーブルから計算しようとせず、メトリックビューに登録された管理済みの指標として認識し、定義済みのロジックを参照します（ Databricks ）。 どちらの例でも、ポイントはモデルではありません。指標の定義を一元化し、人とAIが同じ定義を使えるようにしたことです。 AI-Ready Dataの3層構造：ビジネスの意味をAIに伝える仕組み AI-Ready Dataの3層構造とは、BI-Ready Dataの土台の上に、意味を「定義」として固定するセマンティック層と、問いごとに「文脈」を渡すコンテキスト層を重ねる、dotDataの整理です。セマンティックもコンテキストも、どちらもデータの「意味」を扱います。違いは、事前に固定する「定義」か、問いごとに渡す「文脈」かです。そして両者の土台に、BI-Ready Dataがあります。 図：AI-Ready Dataの3層構造（出典：dotData Webinar資料「AI Agentの価値は、データで決まる」（2026年12月）より） 層 扱う意味 性質 役割 代表的な実装例 ③コンテキスト 意味＝文脈 動的。実行時に渡す その問いに関係する文脈を、エージェントに渡す プロンプト、会話履歴、RAG、コンテキストグラフ ②セマンティック 意味＝定義 安定。事前に定義する 数値の定義も、言葉の定義も、事前に固定する メトリクス定義、ビジネス用語集、オントロジー ①土台 ― ― 正しく、整ったデータをそろえる（BI-Ready Data） データウェアハウス、データマート、データカタログ ①土台：ウェアハウス・マート（BI-Ready Data） 1層目は、正しく整ったデータをそろえる層です。データの構造化、名寄せ、データカタログの整備（Databricks Unity Catalog、Snowflake Horizon Catalogなど）、段階ごとにデータの品質を定義するメダリオンアーキテクチャ（Bronze、Silver、Gold）などが含まれます。 これらは、企業活動のデジタル化とともに、データウェアハウスの時代から取り組まれてきたことです。AIの時代になっても不要にはなりません。AI-Ready Dataの前提条件として、引き続き欠かせない層です。 ②セマンティックレイヤー：意味＝定義（安定・事前定義） セマンティックレイヤーとは、指標の計算方法や業務用語の意味を、AIやBIツールが参照できる形で事前に定義しておく層です。数値の定義も言葉の定義も、ここで固定します。定義には、定量的なものと定性的なものがあります。 定量的な定義（指標・計算） の代表は、メトリクス定義です。Databricksのメトリックビュー（Metric Views）やSnowflakeのセマンティックビュー（Semantic Views）がこれにあたります。 たとえば「売上高」を定義する場合、次の3つを決めておきます。 measure（計算式） ：数量×単価の合計。返品を除くなど、社内のルールも含めて定義する dimension（区分軸） ：期間、地域、店舗、商品、顧客など、集計の切り口 join（結合経路） ：受注、明細、商品、顧客、店舗のテーブルを正しくつなぐ手順 この定義をエージェントが参照できれば、「先月の地域別の売上は？」と聞かれても、エージェントは計算方法を推測しません。定義に従って、該当する区分軸と結合経路をたどり、正しいクエリを組み立てます。誰がどの切り口で尋ねても、同じ「売上高」が返ってきます。先ほどの「解約」の例でいえば、ハードな解約とソフトチャーンを、それぞれ別の名前の指標として定義しておきます。そうすれば、エージェントはAさんとBさんがどちらを指しているのかを区別でき、どちらか曖昧な場合は聞き返すこともできます。 定性的な定義（用語・概念・仕事の流れ） には、ビジネス用語集（Microsoft Purview、Collibraなど）や、オントロジーがあります。オントロジーとは、業務の概念と、概念どうしの関係やルールを、機械が理解できる形で記述したものです。Microsoft Fabric IQやPalantirは、オントロジーを中核に据えています。Databricksも、テーブルやクエリなどから業務のノウハウを自動で抽出する「Genie Ontology」を発表しました（Databricks自身は、これを自動のコンテキスト層と説明しています）。 さらに、こうした定義を製品の垣根を越えて共有するための標準化も進んでいます。Snowflakeなどが2025年9月に立ち上げたOpen Semantic Interchange（OSI）は、2026年1月に仕様が確定し、Databricksも参加しました（ Snowflake ）。Snowflakeによると、2026年6月時点で54社が参加しています（ Snowflake ）。その後、Apache Software Foundationのもとで「Apache Ossie（Incubating）」に名称を変えています（ Snowflake ）。 メタデータとの違いは、説明か、実行できる定義か、という点にあります。テーブルや列の説明（メタデータ）は、これまで主に人が読むためのものでした。いまはエージェントもこれを読み、データの意味を理解する手がかりにしています。セマンティックレイヤーはさらに一歩進み、計算式・区分軸・結合経路のように、エージェントが計算や判断のときにそのまま実行できる形で定義を持ちます。dotDataは、これを「能動的な定義」と呼んでいます。 ③コンテキスト：意味＝文脈（動的・実行時） コンテキスト層は、その問いに関係する文脈を、エージェントのコンテキストウィンドウ（一度に処理できる入力の範囲）に渡す層です。文脈は問いごと、実行ごとに変わります。 プロンプト ：エージェントへの指示、ルール、前提条件 会話履歴 ：いま進めているタスクの文脈と意図 RAG（検索拡張生成） ：社内文書、仕様書、議事録などから、問いに関係する情報を検索して渡す コンテキストグラフ ：過去の判断と、その理由や関連する人・データのつながりを記録し、エージェントが後から参照できるようにしたもの たとえば、同じ製品Aの解約分析でも、誰に向けた分析かによって、まとめるべき内容は変わります。製品を販売する営業部門には顧客ごとの対応策、製品を作る製品部門には機能や品質との関係、経営層には事業全体への影響、解約しそうな顧客を担当する営業担当者には具体的な次の一手が役立ちます。データも分析も同じでも、文脈が違えば、提供すべき内容は違ってきます。 Anthropicは、エージェントに何をコンテキストとして渡すかを設計する考え方を「コンテキストエンジニアリング」と呼んでいます。同社は、コンテキストを「足すほど効果が逓減する有限の資源」として扱うべきだとし、コンテキストウィンドウ内のトークンが増えるほど、モデルがその中の情報を正確に思い出す力は落ちると説明しています（ Anthropic, 2025年9月 ）。問いに関係する文脈を、ちょうどよい分量で渡す設計が重要になります。 構造化データと非構造化データ：どちらのAI-Ready Dataにも「意味の層」が欠かせない 構造化データにも非構造化データにも、意味の層が欠かせません。AI-Readyかどうかは、構造データか非構造データかとは別の軸で決まるためです。dotDataが企業と議論するなかでは、「ドキュメントなどの非構造データをRAGで扱えるように整備すれば、AI-Readyになる」という考え方をよく聞きますが、RAGの整備だけでは足りません。 図：構造化データと非構造化データ：どちらも「意味の層」が必要（出典：dotData Webinar資料「AI Agentの価値は、データで決まる」（2026年12月）より） 観点 構造データ 非構造データ AIに期待されること 正しく「計算」する 正しく「理解」する 意味の層がない場合の問題 列名やコードの裏にある社内固有の定義を知らないと、もっともらしい誤った数字が出る 社内の手順や用語を知らないと、一般論の浅い推論にとどまる 定義（セマンティック）の役割 指標の意味と計算方法を定義し、エージェントはそれを理解したうえでクエリを書く 社内の手順や用語を定義し、文書を自社のこととして読ませる 文脈（コンテキスト）の役割 問いの条件（期間、対象、比較軸）を確定させる 問いに関係する文脈（時点、対象、意味）を渡し、理解と推論を深める 正しさの担保 正解があるため、検証済みの問いと答えで確かめられる 正解が1つではないため、判断の根拠を残し、原文にたどれるようにする 構造データでも非構造データでも、共通するのは「生データに意味の層を被せ、エージェントにその場で推測させない」という考え方です。RAGは、非構造データを扱うための有効な手段ですが、意味の層の一部（コンテキストを渡す手段）にすぎません。用語や手順の定義が整っていなければ、検索で取り出した文書を正しく解釈することはできません。 業界は「意味の層」へ：データ基盤は定義を、AIベンダーは文脈を いま、データ基盤ベンダーは「定義」を、AIベンダーは「文脈」を、それぞれ戦略の中核に据え始めています。データ基盤ベンダーの動きは、dotDataのブログ「 Snowflake Summit 2025 レポート 」や、DatabricksとSnowflakeのガバナンス機能を比較した「 攻めと守りを両立する次世代データガバナンス 」でも紹介しています。 図：北米は「意味の層」へ。次の論点は整備コストとROI（出典：dotData Webinar資料「AI Agentの価値は、データで決まる」（2026年12月）より） データ基盤ベンダー：定義を基盤のサービスに組み込む データ基盤ベンダーは、指標や用語の定義を、データ基盤のサービスそのものに組み込み始めています。 Snowflake ：業務の概念と一貫した定義をデータベース内に持つセマンティックビューを提供しています（ Snowflake Docs ）。定義の標準化を目指すOSIも主導しています。 Databricks ：2026年4月に、指標の定義を管理するUnity Catalog Business Semanticsの一般提供を開始しました。メトリックビューの中核の実装は、Apache Sparkのオープンソースとして公開する予定です。Databricksは「Genieはもう指標をハルシネーションしない。単一の信頼できる情報源から指標を導く」と説明しています（ Databricks ）。 Microsoft ：Fabric IQについて、「分析・リアルタイム・業務の全データに基づくが、データだけでは十分ではない」と説明しています。オントロジーによって、人、アプリケーション、エージェントが同じ語彙と文脈を共有できるようにしています（ Microsoft Learn ）。 AIベンダー：文脈を中核に据える AIベンダーは、社内データへの接続と、モデルに渡す文脈の設計を、精度向上の中核に据えています。 OpenAI ：2025年10月に、ChatGPTの「company knowledge」を発表しました。Slack、SharePoint、Google Drive、GitHubなどの社内ツールを横断して情報を探し、出典付きで回答します（ OpenAI ）。 Anthropic ：前述のとおり、コンテキストエンジニアリングという考え方を提唱しています。 Google Cloud ：「グラウンディングされた生成AIアプリの品質は、自社のデータを取得する能力以上にはならない」と述べています（ Google Cloud, 2024年12月 ）。 意味の層の効果を示すデータ 意味の層を整えると精度が上がることを示すデータが、各ベンダーから報告されています。いずれもベンダー自身による検証です。 Snowflake ：Text-to-SQL（自然言語の質問をSQLに変換する技術）のベンチマーク（BIRD-SQLの4データセット）で、セマンティックモデルを与えると、正答率が平均57%から78%へ、約20ポイント向上しました（生成モデルはClaude 3.5 Sonnet）（ Snowflake, 2025年3月 ）。 Google ：社内テストで、Lookerのセマンティックレイヤーを使うと、生成AIによる自然言語クエリのデータ誤りが最大で3分の2減ったとしています（ Google Cloud, 2025年5月 ）。 Databricks ：28問の社内評価で、テーブルやクエリなどから業務のノウハウを自動で抽出するGenie Ontologyを使ったGenieの一発正答率は84.5%、最も成績の良い汎用コーディングエージェントは52.4%でした（ Databricks, 2026年6月 ）。 オントロジーの再評価と、この1年の変化 オントロジーは、LLMで下書きを作れるようになったことで、改めて注目されています。オントロジー自体は新しい考え方ではありません。かつてはすべてを人手で記述する必要があり、保守が追いつかずに使いこなせないことが多くありました。いまはLLMにオントロジーの下書きを作らせ、人が確認する進め方が取れるようになりました。 dotDataは、こうした業界の変化をカンファレンスの現場でも見てきました。1年ほど前は、セマンティックやコンテキストが重要だと言われ始めたものの、まだ「1つのクエリがうまくいくかどうか」という雰囲気でした。今年は、1年間取り組んだ結果として、分析の工数が減った、自然言語クエリの誤りが減ったといった成果の発表が目立つようになっています。 AI-Ready Dataの「意味の層」をどう構築し、どう維持するか 意味の層は、LLMで下書きして人が検証し、実行中にも人が文脈を補いながら、継続的に更新して構築・維持します。意味の層を整えた先には、エージェントによる分析という大きな可能性があります。ただし、意味の層は作り込むほど重くなります。次の論点は、いかに低コストで、継続的に整備するかです。 整備と維持の課題 意味の層の整備と維持には、主に3つの課題があります。 人手による定義のコスト ：BIのためのデータの整備だけでも、企業は大きなコストをかけてきました。AI-Readyにするには、さらにその上に意味の層を作らなければなりません。 本番運用での保守 ：意味の層は、エージェントが日々の判断に使う本番のインフラになります。変更の管理や品質の監視も欠かせません。 定義の陳腐化 ：ビジネスの文脈は日々変わります。安定している定義もあれば、すぐに古くなる定義もあります。 Gartnerは、エージェント型AIプロジェクトの40%超が、コストの高騰、ビジネス価値の不明確さ、リスク管理の不備によって、2027年末までに中止されると予測しています（ Gartner, 2025年6月 ）。Gartnerが挙げる理由にデータは含まれていません。ただ、意味の層の整備も同じように、どれだけのコストをかけ、どれだけの価値を得るのか、ROIが問われる段階に入りつつあると、dotDataは考えています。 実務でのアプローチ 実務では、次のようなアプローチで、意味の層を作る負担を抑えながら精度を保ちます。 LLMで下書きし、人が検証する ：カラム名やテーブル名がある程度整っていれば、LLMにテーブルの説明やオントロジーの下書きを作らせることができます。7-Elevenは、社内のデータ辞書をエージェントを使ってUnity Catalogのテーブル・列のコメントへ移し、初回の移行を数カ月ではなく数日で終えました。列の定義がないと、Genieが独自の列の意味を取り違えてしまうためです（ Databricks, 2025年9月 ）。 ドメインの深い知見は人が定義する ：業界や業務の深い知見が問われる領域や、入力データが十分に整っていない領域では、LLMの推論だけに頼れません。1回ごとの推論の精度が高くても、推論を何度も重ねると、全体の精度はすぐに下がってしまうためです。 実行中に人が文脈を補う ：Human-in-the-Loop（人が途中で確認・修正する仕組み）によって、エージェントの分析の途中で人が文脈を与え、誤差の蓄積を抑えます。 エージェント自身が文脈を取りにいく ：プロジェクトのフォルダやチケット管理システムと連携し、いま取り組んでいる分析の背景をエージェントが自ら把握する方法も試されています。 長い入力を扱えるモデルを活かす ：モデルが一度に扱える入力（コンテキスト）が長くなり、以前はRAGで検索して渡していた情報を、まとめて直接渡す選択肢も広がっています。ただし、前述のとおり、渡す量が増えるほどモデルが情報を正確に思い出す力は落ちます。何をまとめて渡し、何を検索に任せるかの設計は、引き続き欠かせません。 AI-Ready Dataの導入の進め方：企業がAI活用の価値を引き出す5つのステップ AI-Ready Dataは、AIで解決したい業務を起点に、5つのステップで段階的に整備します。全社のデータを一度にAIのために整える取り組みではありません。生成AIやエージェントで解決したい課題を起点に、そこで使うデータと意味の層を段階的に構築していく取り組みです。dotDataは、企業が導入を進める手順を、次の5つのステップで整理しています。 ステップ1：AIに任せる業務（ユースケース）を決める 最初に、エージェントに任せたい仕事と、そこで答えるべき問いを決めます。ガートナージャパンも日本企業に向けた指針の中で、AIで解決する現場の課題を特定し、そのAIに使うデータを見極め、データ品質を評価して必要なら改善し、足りなければ補う、というプロセスをAIごとに繰り返すことが重要だとしています（ ガートナージャパン, 2026年5月20日 ）。用途が決まらなければ、どのデータがAI-Readyかは判断できません。 ステップ2：土台となるデータをそろえる 対象の業務で使うデータが構造化・名寄せされ、データカタログで所在がわかる状態にあるかを確認します。構造化データだけでなく、社内文書などの非構造データも対象です。ここでは、BIのために構築してきたデータ基盤を活かせます。あわせて、外れ値やエラーを取り除きすぎて、用途に欠かせない代表性を失っていないかも確認します。 ステップ3：重要な指標と用語を定義する 部門によって解釈が分かれやすい指標（売上、解約、成約など）を、計算式・区分軸・結合経路まで含めて定義します。社内用語や仕事の流れも、用語集やオントロジーとして記述します。熟練者の暗黙知やノウハウになっている判断基準を、エージェントが参照できる定義として書き出すことも、このステップの重要な作業です。 ステップ4：問いごとに渡す文脈を設計する 同じデータでも、誰に向けた分析かによって、まとめるべき内容は変わります。エージェントに渡す指示・前提・参照する文書の範囲を、問いの種類ごとに設計します。前述のとおり、渡す情報が多すぎると精度が落ちるため、問いに関係する文脈に絞ることが大切です。 ステップ5：運用の体制をつくり、定義を更新し続ける 意味の層は、一度作れば終わりではありません。定義の変更を誰が担うのか、誤答に気づいたときに定義をどう直すのかを決め、運用の組織と体制を整えます。データエンジニアやアナリストだけでなく、業務部門でAI活用を推進する担当者も定義づくりに関わると、現場の変化に合わせて定義を更新しやすくなります。意味の定義を担う人材を、データ部門と業務部門の両方に置くことが、AI-Ready Dataを維持する鍵になります。 dotDataの見方：データからの知識（特徴量）もAI-Ready Dataになる AI-Ready Dataには、定義と文脈に加えて、データから得られる定量的な知識も欠かせないと、dotDataは考えています。 エージェントが自社の分析で精度を出すには、3種類の知識をそろえることが重要です。LLMが持つ「世界知識」、文書などに書かれた仕事の知見である「ドメイン知識」、そして自社のデータの中にしかない「データからの知識」です。dotDataは、この3つ目を、分析の目的に関係するデータ上のパターン、つまり「特徴量」として捉えています。 特徴量は、これまで主に機械学習モデルの入力として使われてきました。目的に対する定量的な意味を持つため、それ自体がエージェントのためのAI-Ready Dataにもなります。AIを活用した分析で精度の高い答えを得るには、この定量的な根拠が役立ちます。特徴量を目的ごとにどう生成し、エージェントに渡すのかは、 AIエージェント時代のデータマート で解説します。dotDataの製品については、 dotData Feature Factory と dotData Insight をご覧ください。 まとめ AI-Ready Dataは、用途ごとに「AIが正しく使える」状態を指します。BIのために整えたデータ（BI-Ready Data）は土台ですが、それだけではエージェントは正しく動きません。 dotDataは、AI-Ready Dataを3層で整理しています。土台のBI-Ready Dataの上に、意味を事前に「定義」として固定するセマンティック層と、問いごとに「文脈」を渡すコンテキスト層を重ねます。この考え方は、構造データにも非構造データにも共通します。 業界は意味の層の整備に向かっています。次の論点は、意味の層をいかに低コストで、継続的に整備するかです。 AIエージェントによるデータ分析の全体像は AIエージェントを活用したデータ分析の現在地 で解説しています。データ活用の土台となるガバナンスについては データガバナンスとは？ を、AI時代のガバナンスの全体像は AI時代のデータ活用の鍵を握る「統合データガバナンス」とは？ をご覧ください。 The post AI-Ready Dataとは？ AI時代に求められるデータ整備 ― BI-Ready Dataとの違いと、AIエージェントの精度を決める3層構造 appeared first on dotData .

リクルートのデータ推進室にて、飲食領域のデータサイエンティストを統括するグループのマネジャー（取材当時。2026年10月