AI Readyかどうかは、ツール名ではなく運用可能性で診断する
「BigQueryを使っている」「データカタログを導入した」だけでは、AI Readyとは判定できません。 AIが業務データを使うには、品質、意味、権限、鮮度、評価、変更管理が一続きで機能する必要があります。 AI Readyの構造そのものを知りたい場合は、先になぜAI Readyなデータ基盤が必要なのかを参照してください。必要な構成要素と実装の全体像はAI Readyなデータ基盤の構成要素と実装手順にまとめています。本記事は定義の解説ではなく、現状を採点して次の作業を決めるための実務用チェックリストです。
採点ルール
- 0点：未実施、担当者が分からない、口頭説明しかない
- 1点：一部で実施しているが、対象・証拠・運用責任のいずれかが欠ける
- 2点：重要データを対象に実装され、証拠を提示でき、継続運用されている
30項目で満点は60点です。担当者の自己評価だけで決めず、業務責任者、データ担当、セキュリティ担当、AIの利用責任者が同じ表を採点してください。 「導入予定」「担当者は分かっている」は証拠にならないため、実装前なら0点とします。
AI Readyデータ診断チェックリスト30項目
最初から全社の全データを採点する必要はありません。まずAIに使わせたい1つの業務判断を選び、そこに必要なデータだけを対象にします。
A. データ品質
- 01主要テーブルの主キーについて、NULL・重複を検知する自動テストがある0 / 1 / 2
- 02金額、件数、日付、ステータスなどに許容範囲・値域のルールがある0 / 1 / 2
- 03ソース件数と取込後件数を照合し、欠落や二重取込を検知できる0 / 1 / 2
- 04重要なテーブル間の参照整合性をテストしている0 / 1 / 2
- 05品質違反を記録し、影響範囲・担当者・復旧状況を追跡できる0 / 1 / 2
B. 意味・業務コンテキスト
- 06主要KPIに業務定義、計算式、対象期間、除外条件、単位がある0 / 1 / 2
- 07各KPIとデータ項目に、定義を承認する業務オーナーがいる0 / 1 / 2
- 08顧客・注文・契約など主要テーブルの粒度と結合キーが明記されている0 / 1 / 2
- 09同義語・略語・部署固有語と正式な業務用語の対応表がある0 / 1 / 2
- 10定義変更がバージョン管理され、SQL・BI・AI向け説明へ同時に反映される0 / 1 / 2
C. 権限・セキュリティ
- 11データを公開・社内・機密・要配慮などに分類している0 / 1 / 2
- 12人とサービスアカウントに最小権限を付与し、共有アカウントを避けている0 / 1 / 2
- 13行・列・ビュー単位で、利用目的に応じたアクセス範囲を制御できる0 / 1 / 2
- 14個人情報や機密情報をAIへ渡す可否とマスキング方針が明文化されている0 / 1 / 2
- 15権限変更とデータアクセスの監査ログを保存し、定期レビューしている0 / 1 / 2
D. 鮮度・可用性
- 16主要データごとに必要な更新頻度と利用可能になる期限を定めている0 / 1 / 2
- 17更新日時、対象期間、タイムゾーンを利用者が確認できる0 / 1 / 2
- 18取込遅延・停止・レコード急減を自動検知している0 / 1 / 2
- 19アラートの通知先、一次対応者、復旧目標、エスカレーション先がある0 / 1 / 2
- 20再実行とバックフィルの手順があり、重複を起こさず復旧できる0 / 1 / 2
E. AI評価・ガードレール
- 21実際の業務質問と期待する根拠を組にした評価ケースがある0 / 1 / 2
- 22生成SQL、参照テーブル、計算前提を回答と一緒に記録できる0 / 1 / 2
- 23権限外・定義不明・データ不足の質問に、推測せず拒否または確認できる0 / 1 / 2
- 24スキーマ、定義、モデル、プロンプト変更時に回帰評価を実行する0 / 1 / 2
- 25誤回答を再現し、評価ケースとルールへ追加する改善ループがある0 / 1 / 2
F. 運用・変更管理
- 26取込・変換・テスト・権限定義をコードまたは再現可能な設定で管理している0 / 1 / 2
- 27本番変更にレビュー、テスト、承認、ロールバックの手順がある0 / 1 / 2
- 28データ契約や変更通知により、上流変更を利用者より先に検知できる0 / 1 / 2
- 29障害対応、定義変更、権限申請、コスト超過のRunbookがある0 / 1 / 2
- 30品質・鮮度・利用・AI評価・コストを定期的に確認する責任者と会議体がある0 / 1 / 2
合計点だけで「AIを入れてよい」と判断しない
合計点は改善の優先順位を話し合うための目安です。次のように読みます。
| 合計 | 状態 | 次の判断 |
|---|---|---|
| 0〜20 | 再現性のある基盤運用が未整備 | AI接続より、対象業務・品質・権限の基礎を優先 |
| 21〜40 | 部分的に利用可能だが、人の補完に依存 | 対象を限定したPoCと不足領域の改善を並行 |
| 41〜50 | 限定業務なら運用候補 | 評価ゲートと監視を付けて段階公開 |
| 51〜60 | 重要領域の統制が揃っている | 利用範囲を広げながら、変更時の回帰を継続 |
ただし、権限・セキュリティまたはAI評価・ガードレールに0点が1つでもある場合は、合計点が高くても本番公開を止めます。 機密データの漏えいと、根拠のない回答は、他領域の成熟度では相殺できないためです。
各項目に「証拠URL」を1つ付ける
診断表には点数だけでなく、次の列を追加します。
- 対象：どのデータセット、KPI、AIユースケースを評価したか
- 証拠：テスト結果、定義書、IAMポリシー、監視画面、Runbookへのリンク
- オーナー：改善を承認する人と、実装する人
- 期限：次の判定日。実装予定日ではなく、証拠を再確認する日
これにより、診断が一度きりのアンケートではなく、監査可能な改善バックログになります。 業務定義と物理データの結び付け方は統合オントロジーの設計も参考にしてください。
診断後の90日改善計画
1〜30日：対象と責任を固定する
- AIで支援したい業務判断を1つ選び、利用者、入力、期待する回答、利用禁止データを定義する
- 必要なソース、テーブル、KPI、権限、更新時刻を棚卸しする
- 30項目を証拠付きで採点し、各領域のオーナーを決める
- 実際の質問、正しい定義、参照すべきデータを評価ケースとして保存する
終了条件：対象業務、データ境界、責任者、現状点、改善バックログが合意されている。
31〜60日：品質・意味・権限をコード化する
- 重要キー、NULL、重複、値域、参照整合性、ソース照合のテストを実装する
- KPI定義、粒度、除外条件、同義語、業務オーナーを同じ変更フローで管理する
- 最小権限、マスキング、監査ログ、AIへ渡してよい項目を実装する
- 鮮度監視と通知を設定し、失敗時の再実行を確認する
終了条件：重要な0点項目が解消され、変更をテスト環境で再現できる。
61〜90日：評価ゲート付きで限定公開する
- 評価ケースをCIまたはリリース手順に組み込み、変更前後の差分を確認する
- 根拠、生成SQL、参照データ、拒否理由をログとして残す
- 少人数へ公開し、誤回答・定義不足・権限違反を評価ケースへ戻す
- 品質、鮮度、評価、利用、コストを定期レビューし、次の対象業務を判断する
終了条件：公開・停止を判断する責任者と基準があり、障害や誤回答を再現して改善できる。
判断基準にした一次情報
- Google Cloud: Auto data quality overview — 鮮度、完全性、妥当性、整合性、正確性、一意性といった品質ディメンション
- Google Cloud: Use IAM securely — 最小権限、サービスアカウント、権限管理
- Microsoft Cloud Adoption Framework: Data processing standards for AI and analytics — 取込・変換・公開を一貫した標準で管理する考え方
- dbt Developer Hub: Source freshness — ソース更新時刻の基準と鮮度監視
- NIST: AI Risk Management Framework — AIリスクを継続的に把握・測定・管理する枠組み
まとめ：診断の目的は点数ではなく、次の変更を決めること
- 30項目を0・1・2点で評価し、必ず証拠とオーナーを付ける
- 合計点が高くても、権限またはAI評価に0点があれば本番公開しない
- 90日で対象固定、基礎統制の実装、評価付き限定公開まで進める
- 診断は四半期ごと、またはデータ・モデル・権限の大きな変更時に再実施する