AI Readyなデータとは何か。導入前に整える5つの条件

AIに何を答えてほしいかを先に決める

「地域の観光データをAIで分析したい」だけでは、整備すべきデータを決められません。まず、誰がどの判断に使うかを一つに絞ります。例えば「月次の会議で、前月と比べて宿泊の状況がどう変わったか確認する」という用途です。

この場合に必要なのは、宿泊の指標、対象期間、集計範囲、速報・確報の区別です。口コミの要約であれば、別の準備が必要になります。文章の意味に加え、収集した期間、対象の偏り、引用してよい範囲も確認します。

すべてを表に変換することや、最初から大きなDWHを作ることが目的ではありません。PDFや文章でも、用途に合った取り出し方と出典確認ができれば候補になります。データの置き場所から検討したい場合は、DWHの役割と導入の判断基準も参考にしてください。

Metabase、Cortex AI、NotebookLMなどの製品を選ぶ前に、必要な集計と利用範囲を明確にします。製品名だけで構成を固定せず、実際に利用するプラン・機能・接続方法が要件に合うかを確認してください。

導入前に確認する5つの条件

次の表は、本記事で提案する確認項目です。業界共通の認証や、すべてのAIに対する性能保証ではありません。用途ごとに許容できる状態を決めます。

条件	確認する問い	確認の手がかり
意味と形式	1行は何を表し、値の単位と対象期間は何か	データ辞書、指標の定義、対象範囲
品質	欠損・重複・外れ値をどう扱うか	検査結果、除外ルール、修正履歴
出典と加工履歴	元資料から数字を再計算できるか	原典のURLまたは管理ID、取得日、集計方法
利用権限	誰が参照し、どの環境へ渡してよいか	データ管理者、利用条件、共有範囲
鮮度と運用	いつ時点の情報で、更新が止まったら誰が気づくか	対象年月、最終取得日時、更新担当者、通知先

品質管理の方法として、dbtは欠損、値の一意性、許容値、参照関係を確認するデータテストを用意しています。テストが通ることは、設定した条件を満たすという意味です。業務上の定義そのものが正しいかは、別に確認します。¹

また、データの取得が古くなっていないかを検知するには、更新予定に合わせた基準が必要です。dbtのsource freshnessはその確認手段の一つですが、設定・実行する運用が必要です。²

宿泊データで考える具体例

以下は説明用に作成した架空のデータです。実在する地域や顧客の実績ではありません。

month,area_id,metric,value,unit,status,source_ref
2026-09,demo-area,guest_nights,1200,person_nights,final,example-report-09
2026-09,demo-area,guest_arrivals,900,persons,final,example-report-09
2026-10,demo-area,guest_nights,,person_nights,pending,example-report-10

この表をそのまま渡して「観光客は増えましたか」と聞くと、答えに必要な前提が不足します。確認すべき点は次の3つです。

延べ宿泊者数と実人数を足さない。 この例の guest_nights は延べ宿泊者数、guest_arrivals は宿泊者の実人数として定義しています。単位が異なるので、1,200と900を足して「観光客2,100人」とは言えません。
未回答をゼロにしない。 10月の空欄は集計待ちです。ゼロとして扱うと、宿泊がなくなったように見えてしまいます。「比較に必要なデータが未確定」と表示します。
宿泊者を地域全体の来訪者と言い換えない。 日帰り客を含むか、同じ人の再訪をどう数えるかは、別の指標定義が必要です。

データ辞書には、少なくとも「指標名・単位・対象範囲・欠損の意味・集計方法」を残します。ファイル名やカラム名だけで意味が伝わる前提にしないことが、誤った説明を減らす第一歩です。

この例から何を回答できるか

回答できるのは「この架空データでは、9月の延べ宿泊者数は1,200人泊。10月は未確定なので増減は判断できない」という範囲です。理由や原因まで推測して埋める必要はありません。

逆に「10月は観光需要が減った」「施策によって宿泊が増えた」は、この表だけでは裏付けられません。出典のある数値と、追加検証が必要な仮説を分けて提示します。

集計とAIの役割を分ける

導入時には、次の処理を切り分けると検証しやすくなります。

段階	実施すること	残すもの
収集	利用してよいデータを対象期間とともに取得	原典、取得日時、利用条件
整備	指標の定義、欠損、重複、確定状態を確認	データ辞書、テスト結果
集計	SQLや集計ルールで数値を確定	集計コード、対象データの版
AIの利用	確定した数値と定義を渡し、説明の下書きを作る	使用した資料、モデル、実行日時、出力
確認	数値・出典・権限・説明の飛躍を人が点検	修正箇所、承認者、利用範囲

BigQueryやSnowflake、dbt、BIツールはこの流れの選択肢です。小さなデータなら、管理されたCSVと集計スクリプトから始められる場合もあります。技術選定はBigQueryとSnowflakeの比較、定義とテストの管理は観光データとdbtで詳しく扱っています。

ファイルを読み込むAIサービスでは、対応形式や同期方法を、その時点の公式ドキュメントで確認します。JSONを出力できることと、そのJSONを直接読み込めることは別です。読み込んだ情報が自動更新されるか、更新後の版を回答が参照しているかも確認してください。³

クローズドな情報の境界を保つ

組織内で利用できるデータでも、外部AIへの送信や一般公開が許されているとは限りません。利用前に、データ管理者と、参照者・利用環境・送信先・保存範囲を確認します。公開統計と顧客の非公開データが混ざる場合は、扱いを分けられるようにしておきます。

クローズドな環境での利用でも、必要のない個人情報まで渡す理由にはなりません。集計済みデータで目的を達成できるか、閲覧権限が必要な範囲に絞られているかを確認します。

同じ考え方は、将来より高度なAIを使う場合にも役立ちます。モデルの能力に依存せず、指標の定義、原典、更新履歴、利用条件を追跡できるようにすることです。これは将来の超知能との互換性や、誤りのない回答を保証するものではありません。

小さく試すときの成功判定

最初の試行では、会議で実際に使う質問を固定します。例えば「前月比を計算できるか」「未確定の値を区別できるか」「どの資料から判断したか説明できるか」です。

進めてよい状態: 同じデータの版と集計方法から同じ数値を再現でき、回答の根拠へ戻れる。
整備を先に行う状態: 指標の定義や対象期間が曖昧で、回答の正しさを判定できない。
利用を止めて確認する状態: 閲覧権限を越えた回答が出る、非公開情報が想定外の送信先へ渡る、未確定値を確定値として説明する。

正解率だけでなく、手直しが必要だった点、出典を辿れなかった点、確認にかかった時間を残します。データを整えればすべて解決するわけではありません。モデルや検索方法、質問の設計も含め、変更前後を同じ問いで確かめます。

必要な整備範囲を相談したい場合は、データ基盤構築とAI導入支援をご覧ください。

更新履歴

2026-10-20: 確認項目を用途別に整理し、架空の宿泊データ、回答できる範囲、公開・非公開情報の境界、試行の判断基準を追加しました。割合による一般化と、特定ツールの組み合わせを最短経路とする説明を見直しました。

dbt Labs「Add data tests to your DAG」（確認日: 2026-10-20）。標準データテストの種類と役割。 ↩
dbt Labs「Source freshness」（確認日: 2026-10-20）。データソースの鮮度確認と実行。 ↩
Google「Add or discover new sources for your notebook」（確認日: 2026-10-20）。読み込み可能な形式とソースの更新方法。対応状況はサービス側で変わるため、利用時に確認してください。 ↩