公開2025.08.14更新2026.10.31 29 人が閲覧（直近 30 日）データ分析・BI

AI Readyとは？AI-readyデータの定義・6条件とデータ基盤のアセスメント手順

AI Ready（AI-Ready）とは、企業がAIを効果的かつ安全に使えるように、データを整理・構造化して活用できる状態にすることです。経済産業省は2026年8月12日の解説でこの意味を示しています。中心はデータですが、経団連や総務省の資料は人材・組織・ルールまで含めて使うため、言葉の範囲は資料によって違います。この記事では範囲の違いを整理したうえで、データ基盤の側で何を満たせばAI-readyと言えるのかを、6つの条件、アーキテクチャ、現在地を測るアセスメントの順に解説します。

まとめ：AI-readyデータの要点

意味：経産省の定義は「データを整理・構造化し、活用可能な状態にすること」。経団連は企業・個人・社会制度まで含めて使う。
条件：経産省の政策特集が紹介した6条件（構造・意味づけ・品質・統一されたガバナンス・継続的な改善・スケーラビリティ）が、データ基盤で実装する項目の出発点になる。
落とし穴：Gartnerはデータを「ユースケースを代表しているか」で判定する。外れ値を消して整えたデータは、きれいでもAI-readyとは限らない。
現在地の測り方：経団連「AI-Ready化ガイドライン」の5段階のうち「システムレベル・データ」の列で、自社の基盤がどの段階にあるかを判定する。
進め方：全データを一度に整えず、1つのユースケースで使うデータを棚卸しし、メダリオン構成の上で品質検査と監視をパイプラインに組み込む。

AI Readyの意味：経産省の定義と言葉の範囲の違い

「AI Ready」は、何がAIを使える状態にあるのかによって指す範囲が変わります。データだけを指すのか、企業全体の準備状態を指すのかを先に分けておくと、社内の議論がかみ合います。

経産省の定義：データを整理・構造化して活用できる状態

経済産業省のMETI Journal ONLINE「AI-Readyってなに？」（2026年8月12日）は、AI-Readyを「企業がAIを効果的かつ安全に活用するため、データを整理・構造化し、活用可能な状態にすること」と説明しています。同じ記事は、現場に蓄積された独自データは非構造で扱いにくいため、データに意味や関係性を付け、AIが理解しやすい高品質データとして管理する「AI-Ready化」が重要だとしています。企業単体ではデータの量に限界があるため、企業間・業界間で安全にデータをやり取りするデータスペースの整備にも触れています。

英語圏で使われる「AI-ready data」もこの意味に近く、この記事で扱うのもこの範囲です。読み方は「エーアイ・レディ」です。

AI-Readyな企業・社会：経団連と総務省が使う広い範囲

経団連は2019年2月19日の提言「AI活用戦略～AI-Readyな社会の実現に向けて～」で、企業・個人・社会制度と産業基盤のそれぞれをAI-Ready化する指針を示しました。企業向けには、経営・マネジメント層、専門家、従業員、システムレベルとデータの4つの観点で5段階のレベルを設けています。ここでのAI-Readyは、データに加えて人と組織の準備を含む言葉です。

総務省の令和8年版情報通信白書も、AI活用で先行する企業が整備している環境・基盤を、組織体制、技術的な環境ならびにデータの整備、人材育成などに分けて整理しています。同じ白書は、国立情報学研究所の佐藤一郎教授の「AI導入に成功するための最初のステップとして、AIに対応するデータがあるかどうか、つまり『AI-Ready』化が出来ているかどうかという点がある」という指摘を紹介し、AIエージェントではデータの精度と鮮度がより重要になるとしています。

この記事ではデータ基盤の整備を中心に扱います。経営方針の決定、人材育成、利用ルールの整備は、データの棚卸しと並行して進めます。

AI-readyデータの6条件と基盤の技術要件

経産省の政策特集「社内のデータ、AIが活用できる状態ですか？」（2026年6月29日）は、データ活用プラットフォームを提供するフライウィールの説明として、AI-Ready化で特に重要な6条件を紹介しています。経産省が定めた基準ではなく、取材先企業の整理である点に注意してください。下の表は、6条件をデータ基盤で実装する項目に置き換えたものです（右2列はこの記事の整理です）。

条件	基盤で実装するもの	確認する指標の例
1. AIが分かりやすい構造	スキーマ定義・文書の分割	スキーマ違反の件数
2. 適切な意味づけ	データカタログ・用語集	説明が付いた列の割合
3. 欠損・重複を補正した品質	取り込み時の品質検査	欠損率・重複件数
4. ガバナンスの統一管理	権限・機密区分のタグ	区分が未設定の資産数
5. 継続的な改善	品質監視・アラート	鮮度の遅延時間
6. スケーラビリティ	ストレージと計算の分離	処理時間の伸び方

同じ記事は、企業内データがAIで使われない背景として「サイロ化」「属人化」「大量の非構造化データ」の3つを挙げ、フライウィールの横山直人CEOの説明として企業内データの約8割以上が非構造化データだとしています。条件1と2は非構造化データ、条件4はサイロ化、条件2は属人化への対策にあたります。意味づけの土台になるメタデータ管理はデータカタログとは？意味・メタデータ管理の仕組みからAI時代の導入判断まで解説で、Excelの表を機械が読める形に直す手順は機械判読可能なデータとは：デジタル庁の3段階ルールと神Excelを直す手順で扱っています。

「きれい」と「ユースケースを代表している」は別の条件

GartnerはAI-ready dataの解説で、AI-readyなデータはユースケースを代表していなければならず、そこにはあらゆるパターンだけでなく誤り、外れ値、予期しない現象まで含まれるとしています（原文は「representative of the use case, of every pattern, errors, outliers and unexpected emergence」）。従来のデータ品質管理は誤りや外れ値を除く方向に働きますが、AIでは稀なケースこそ学習に必要な場合があります。不正検知のモデルなら、不正の事例を外れ値として捨てたデータで学習すると、本番で不正を捉えられません。

実務では、条件3の「補正」を、元データを書き換えて外れ値を消す作業にしないことが要点です。欠損や重複の補正は加工後の層で行い、元のデータは手を付けずに残します。この分け方は次の章のメダリオン構成でそのまま実装できます。

なお、Gartnerは2023年10月16日の発表で、AI-readyなデータの条件を「secure, enriched, fair, accurate」で、自社が定めた原則（lighthouse principles）に沿って統治されていることとも述べています。安全・文脈の付与・公平・正確・統治の5点は、上の6条件と対応付けて管理できます。ただし、公平性や組織の原則との整合が確認項目から漏れていないかを点検します。

AI-readyデータが急がれる理由：Gartnerの予測と国内調査

Gartnerは2025年2月26日のプレスリリース「Lack of AI-Ready Data Puts AI Projects at Risk」で、2026年までに、AI-readyなデータに支えられていないAIプロジェクトの60%を組織が放棄すると予測しました。同じリリースでは、2024年7月にデータ管理の責任者1,203人を対象に行った調査で、63%の組織がAI向けの適切なデータ管理の手法を持っていない、または持っているか分からないと回答しています。Gartnerは同じ発表で、AI-readyなデータの実践にはメタデータ管理、データ可観測性、データとAIのガバナンスへの継続的な投資が必要だとしています。

国内でも成果は限られています。前述の経産省の政策特集は、ガートナージャパンが2025年9月に日本国内の企業に所属する個人を対象に行った調査（回答455人）で、自社のデータ活用で「全社的に十分な成果を得ている」と回答した割合が2.4%にとどまったと紹介しています。これらの数字は、AI向けデータ管理や全社的なデータ活用に課題があることを示します。ただし、モデル選定とデータ準備のどちらが投資成果を強く左右するかを比較した結果ではありません。

AI-readyなデータ基盤のアーキテクチャ設計

AI-readyなデータは一度の整備では維持できません。データの取り込み・加工・提供の各段に、検査と監視を組み込んだ構成にします。

メダリオン構成：Bronze層に生データを残して代表性を守る

Databricksのメダリオンアーキテクチャの公式ドキュメントは、Bronze層を「生の、検証前のデータ」を元の形式のまま保持する層とし、全履歴を残すことで再処理と監査を可能にすると説明しています。データのクレンジングと検証はSilver層で行い、取り込みから直接Silver層へ書くことは推奨していません。スキーマ変更や壊れたレコードで処理が失敗するためです。

AI-readyの観点では、Bronze層が「代表性」を守る保険になります。Silver層で外れ値を除いて学習用データを作ったあとで、稀なケースが必要だと分かっても、Bronze層から作り直せます。層の設計と再処理のコードはメダリオンアーキテクチャとは：Bronze・Silver・Goldの層設計と再処理をコード付きで解説、基盤全体の構成はデータレイクハウスとは？データレイク・DWHとの違いとアーキテクチャを実装視点で解説が詳しく扱っています。

データパイプラインの品質検査と継続監視

6条件の3と5では、反復する欠損・重複・鮮度の検査を自動化し、人は異常の原因調査や検査ルールの見直しを担当します。Bronze層からSilver層へ移す処理の中で欠損率・重複・値の範囲を検査し、しきい値を超えたら後段への反映を止めます。上流の列名や型の変更による障害を防ぐには、提供側と利用側でスキーマを取り決め、変更時の互換性検査と通知を運用に組み込みます。

検査項目としきい値の決め方：データ品質のテスト方法：検査項目と閾値の決め方、dbtでの実装とAI学習データの検査
スキーマの取り決め：データ契約（Data Contract）とは？ODCSとdbtでスキーマ破壊を止める実装を解説【2026年版】
鮮度と異常の継続監視：データオブザーバビリティとは？五つの柱とデータ品質監視の導入判断【2026年8月時点】

本番に出したモデルの入力分布が学習時からずれていないかは、学習データを基準に入力データの分布を比較して監視します。データ品質監視とモデル監視の双方で扱う項目です。指標としきい値はモデルモニタリングとは？ドリフト検知の仕組み・指標・しきい値設計を実装目線で解説【2026年版】を参照してください。

RAG文書の取り込みとアクセス権限の継承

社内文書を生成AIに検索させるRAGでは、6条件の4「ガバナンスの統一管理」が文書単位で問われます。MicrosoftのAzure AI Searchのドキュメントは、文書単位のアクセス制御を、取り込みから検索の実行まで一貫して権限を適用する機能とし、RAGアプリケーションや企業内検索に欠かせないとしています。

元のファイルサーバーで閲覧を制限していた文書も、権限情報を落として検索インデックスに入れ、検索時にも閲覧権限を確認しなければ、権限のない利用者にAIの回答を通じて内容が漏れるおそれがあります。文書を取り込むときは、本文と一緒に閲覧できる利用者・グループを属性として持たせ、検索時に絞り込む設計にします。埋め込みの保存先の選び方はベクトルデータベースとグラフデータベースの違い｜比較表・ナレッジグラフとの関係・3つのDBで実測【2026年版】で比較しています。

AI-ready化アセスメント：経団連の5段階とデータ基盤の評価項目

経団連の参考資料「AI-Ready化ガイドライン」は、AI-Readyな企業への段階をレベル1から5で示しています。経営層や人材の列は人事や経営企画の判断になるため、データ基盤の担当者は「システムレベル・データ」の列から自社の位置を確かめるのが現実的です。2019年の資料で生成AI以前の整理ですが、データ基盤の成熟度の物差しとしては今も使えます。

「システムレベル・データ」列によるレベル判定

レベル	資料の記述（システムレベル・データ）
1 着手前	データの収集・取り出し・統合に年単位の時間が必要
2 初期段階	一部データが分析・活用可能な形で取得可能に
3 進行	業務系に加え分析系のデータ基盤も整備開始
4 AI-Powered化へ展開	大半の業務データがリアルタイムに近い形で分析可能
5 AI-Powered企業	リアル空間も含め全てがデータ化、リアルタイム活用

レベル1にはほかに「レガシーシステムが肥大化」「データの意味や示唆の理解も不十分」、レベル4には業務システムと分析システムが切れ目なく連携する状態が並びます。目安の一つは、AIで使いたいデータを業務システムから取り出して分析基盤に載せるまでの時間で、年単位を要するならレベル1の記述に対応します。ただし1つの項目だけで段階は決まらないため、分析基盤の整備状況や業務への適用状況も合わせて照合します。

ユースケース別のデータ棚卸しと確認用SQL

レベルが分かったら、AIで解きたいユースケースを1つ決め、そのデータだけを棚卸しします。問い合わせの自動分類を例にすると、確かめるのは欠損・重複・鮮度と、ラベルの分布です。下のSQLは、問い合わせテーブルを想定した確認用のクエリで、SQLite 3.51.0で動作を確認しています（2本目は窓関数を使うためSQLite 3.25以降、PostgreSQLやBigQueryでも同じ構文で動きます）。

-- 欠損・重複・鮮度をまとめて確認する
SELECT
  COUNT(*) AS rows_total,
  ROUND(100.0 * SUM(CASE WHEN category IS NULL THEN 1 ELSE 0 END) / COUNT(*), 1) AS category_null_pct,
  ROUND(100.0 * SUM(CASE WHEN body IS NULL OR body = '' THEN 1 ELSE 0 END) / COUNT(*), 1) AS body_empty_pct,
  COUNT(ticket_id) - COUNT(DISTINCT ticket_id) AS duplicate_ids,
  MAX(updated_at) AS last_updated
-- 最新の更新日時だけでは、未更新の古い行や取り込み遅延は判定できない
FROM support_tickets;

-- ラベルの分布：稀な分類が消えていないかを確認する
SELECT
  category,
  COUNT(*) AS n,
  ROUND(100.0 * COUNT(*) / SUM(COUNT(*)) OVER (), 2) AS pct
FROM support_tickets
GROUP BY category
ORDER BY n DESC;

列を ticket_id・category・body・updated_at とし、5行を (1, 'billing', 'a', '2026-10-01')、(2, 'billing', 'b', '2026-10-02')、(2, 'billing', 'c', '2026-10-03')、(3, NULL, '', '2026-10-04')、(4, 'fraud', 'd', '2026-10-05') とした例では、1本目は「5|20.0|20.0|1|2026-10-05」、2本目は billing 60.0%・ラベルなし 20.0%・fraud 20.0% を返しました。2本目の分類別件数は、対象業務で想定される分布と照合します。稀な分類が少ないだけでは代表性の欠如とは判断できませんが、学習・評価に必要な事例が不足していれば追加収集を検討します。あわせて、データの出所・更新頻度・機密区分がカタログに記録されているか、個人情報の利用目的と保持期間が決まっているかを確認します。

AI-ready化の失敗パターンと着手の順番

AI-ready化でつまずく進め方は、どれも「基盤を整えれば使われる」という前提から生まれます。

ユースケースを決めずに全データを整える：何を代表すべきかが決まらないため、品質のしきい値も決められません。棚卸しは1つのユースケースから始めます。
外れ値を元データごと消す：Bronze層を持たずに加工すると、稀なケースを後から取り戻せません。
整備を一度きりで終える：上流システムの変更や業務の変化により、データの鮮度や分布が要件から外れることがあります。検査と監視をパイプラインに入れない整備は、手作業のクレンジングと変わりません。
RAGの文書を権限なしで取り込む：情報漏えいの経路を作ることになり、全社展開の段階で止まります。

着手の順番は、ユースケースの決定、棚卸し、メダリオン構成と品質検査、監視の順にするのが基本です。分析基盤がまだ無いレベル1〜2の企業は、ツール選びより先に、業務システムからデータを取り出す経路を作るところから始めます。基盤の設計から運用までを外部に相談する場合は、データ基盤とモデル運用を一体で扱う支援を選ぶと、前段の整備と後段の監視がつながります。当社（株式会社一創）もデータ分析基盤構築・MLOps構築支援としてこの範囲を提供しています。