AI時代の構造化データの置き方｜情シスのためのガバナンスとPoC評価

2026年6月25日2026年6月26日

こんにちは。株式会社ノーコードソリューションズです。生成AIのPoC（概念実証）は動いたのに、本番にはなかなか乗らない。社内AIやDifyのナレッジは作ったけれど、効果が測れない。情シス・DX推進の現場で、こうした手詰まりは珍しくありません。実際、調査会社Gartnerは「生成AIプロジェクトの少なくとも30%が2025年末までにPoC後に放棄される」と予測しています。原因の多くは、モデルの賢さではなくデータの扱い方にあります。本記事では、AI時代の構造化データを「置き方・守り方・回し方」の3つに分けて、海外論文や公的ガイドラインなど一次資料の根拠つきで体系化します。読み終えたとき、自社のデータパイプラインを点検し、次の一手を言語化できる状態を目指します。

想定読者：中堅〜大企業の情シス／DX推進の実務者（CRMやデータ基盤、社内AI・Difyの導入設計や意思決定に関わる方）。

なぜ「データの置き方」でAIの成否が決まるのか？

結論から言えば、生成AIの成否を分けるのはモデルの性能ではなく、データをどこに、どんな品質で、どんな統制のもとに置くかです。MITが2025年に公表した調査「The State of AI in Business 2025」でも、成果（損益への測定可能な貢献）にたどり着いた生成AIパイロットはごく一部にとどまり、原因はモデル品質ではなく業務フローへの組み込みやデータの扱いの差にあると報告されています。

本記事は、AI時代のデータ活用でつまずきやすい点を「置き方・守り方・回し方」の3つの原則に整理します。データを構造化して置き、ガバナンスで守り、評価しながら運用に乗せて回し続ける。この3つを一つの基盤として設計してはじめて、PoCは本番に乗ります。全体像は次の図のとおりです。

図1：本記事の枠組み。AIデータ基盤を「置き方・守り方・回し方」の3原則で捉え、継続的に評価・改善します。

それぞれの原則には、実務で必ず引っかかる論点があります。本記事は、それを次の3部で整理します。

置き方：AIが使える形でデータをどこへ置くか（データレイク／Lakehouse／Medallion）
守り方：ガバナンスをデータ層に埋め込む（機密度分類・匿名化・アクセス制御・来歴管理）
回し方：PoCを運用に乗せて評価し続ける（人手レビューの設計・RAG評価指標・継続運用）

【基礎知識】構造化データとは？AIにとってなぜ重要か

本題に入る前に、土台となる「構造化データ」を整理します。データは、形の整い方によって次の3つに分けられます。AI活用でつまずく原因の多くは、扱いやすい形（構造化データ）に整える工程が抜けていることにあります。

種類	例	AIでの扱いやすさ
構造化データ	行と列のテーブル（CRMの顧客情報、契約、売上）。RDBやスプレッドシート	そのまま検索・集計・権限制御しやすい
半構造化データ	タグや階層を持つ形式（JSON、XML、ログ、メール）	スキーマは緩いが構造の手がかりがあり、整形で構造化に寄せられる
非構造化データ	決まった形がない（問い合わせ音声、帳票・図面、PDF、議事録）	そのままではAIが扱いにくく、抽出・変換が必要。企業データの大半を占める

なぜAIにとって構造化データが重要なのでしょうか。理由は明快で、構造化されていれば検索でヒットしやすく、参照精度が上がり、列単位でアクセス権限を制御でき、評価のKPIも取りやすいからです。逆に、非構造化のまま放り込むと、検索が当たらず、ハルシネーション（誤回答）も増えます。後述するRAGの参照ヒット率や正答率は、元データがどれだけ構造化されているかに大きく左右されます。

非構造化データを構造化する「橋渡し」とは？

実務で本当に難しいのは、問い合わせ音声・帳票・PDF・議事録といった非構造化データを、AIが使える構造化データへ変換する「橋渡し」です。ここはAIの抽出・変換が活躍する工程です。音声は文字起こしし、帳票やPDFはVLM（画像も理解できるAI）でJSON化し、あらかじめ決めたスキーマ（項目の型）に沿った構造化データへ整えます。整えたデータは、後述するMedallionのSilver層へ流していきます。

図2：非構造化データ（音声・帳票・PDF）をAIで抽出・変換し、スキーマに沿った構造化データへ整える「橋渡し」。

【置き方】AIが使える形でデータをどこへ置くか？

最初の論点は「置き方」です。AI活用の土台となるデータ基盤をどう設計するか。ここを誤ると、後段の守り方も回し方も成立しません。

二層型（データレイク＋DWH）の限界とは？

多くの企業は、生データを貯める「データレイク」と、整形済みデータを分析する「データウェアハウス（DWH）」を組み合わせた二層型を採用してきました。しかしこの構成には、いくつかの構造的な弱点があります。Databricksらが2021年のデータベース研究会議CIDRで発表した論文「Lakehouse」は、二層型が抱える課題を次の4点に整理しています。

課題	二層型（データレイク＋DWH）で起きること
信頼性	レイクとDWHの二重管理で、整合性の崩れや連携の失敗が起きやすい
データ鮮度	レイクからDWHへの転送に時間がかかり、分析が古いデータになる
高度分析（ML）対応	機械学習が直接読みにくく、AI活用との相性が悪い
TCO（総保有コスト）	同じデータを二重に持つコストと、独自形式によるベンダーロックイン

Lakehouseという選択肢｜オブジェクトストレージの上に「メタデータ層」を載せる

同論文が提唱するのが「Lakehouse」です。これは、S3のような低コストのオブジェクトストレージ上に、Parquetなどのオープン形式でデータを置き、その上にトランザクショナルなメタデータ層を載せる設計です。これにより、ACIDトランザクション、データのバージョニング、監査、インデックス、クエリ最適化といった分析データベースの機能を、オープンな形式を保ったまま実現します。後述する「守り方」で重要になりますが、このメタデータ層こそがアクセス制御や監査ログを実装する自然な場所になります。

Medallion（Bronze／Silver／Gold）で品質を段階的に上げる

データを「置く」ときの整理方法として広く使われるのが、Databricksが定義するMedallionアーキテクチャです。データが各層を流れる過程で、構造と品質を段階的に高めていきます。

入力データを原本のまま保持します。加工せず忠実に残すことで「単一の真実」となり、後でいつでも作り直せます。問い合わせ音声や帳票など、不定期に発生するデータも、まずここへそのまま置きます。

スキーマの強制、欠損・null処理、重複排除、品質検査を行い、データを検証・クレンジングします。複数システムにまたがる顧客情報の名寄せ（顧客IDをキーにした統合）も、この層の役割です。

BI・レポート・ダッシュボード・機械学習向けに集約し、用途に最適化します。社内AIの全文検索DBやDifyナレッジへ配るのも、この層を起点にするのが基本です。

図3：Medallionアーキテクチャ。原本（Bronze）を起点に、整形（Silver）・活用（Gold）へと品質を段階的に高めます。

三層を最初から全て作り込むべき？｜段階導入の指針

「データレイク（S3）＋DWH＋CRM」の三層をPoC段階でいきなり全て作り込むと、三重投資になりかねません。現実的な進め方は、まずBronze（原本保持）の1層から始め、既存CRMやパッケージ製品の活用を再検証することです。需要が確認できてからSilver・Goldを足し、用途別の配信先を増やしていけば、投資を需要に追従させられます。

補足：出典の立場に注意

LakehouseとMedallionの定義は、提唱元であるDatabricksの一次資料に基づきます。設計思想としては有用ですが、提唱側は商用の立場でもあるため、「自社にとって三層が過剰かどうか」は、自社のデータ量・用途・運用体制に照らして中立に判断してください。

【守り方】ガバナンスをデータ層に埋め込む

置き方が決まったら、次は「守り方」です。AIに渡すデータには、顧客情報や問い合わせ音声、労務・経理・法務など、機微な情報が含まれます。守り方は後付けではなく、データ層そのものに埋め込むのが鉄則です。

機密度分類ゲート｜外部AIに出す前に仕分ける

最も多い落とし穴が、顧客情報や問い合わせ音声を無選別のまま外部AIへ送ってしまうことです。対策は、保管層（データレイク）に入る手前で「分類 → 匿名化（マスキング） → 送信可否の判定」というゲートを設けることです。米国標準のNIST SP 800-122は、個人情報（PII）を機密度の影響レベルでlow／moderate／high の3段階に分類し、レベルに応じた保護措置を決めることを推奨しています。この分類を、外部AIへ送るかどうかの判定基準にそのまま使えます。

Difyのようなツールでナレッジを作る場合も、登録前にこの分類ゲートを通します。たとえば、入力テキストをまず分類するノードを置き、レベルに応じて処理を分岐させる設計が有効です。

// 機密度分類ゲートのプロンプト例（外部AI送信前の判定）あなたは情報ガバナンスの担当者です。以下のテキストの機密度を判定してください。 ## 判定基準（NIST SP 800-122 を参考にした3段階） – low : 公開済み・一般情報。マスキング不要 – moderate : 社内限定。氏名・連絡先等はマスキングのうえ送信可 – high : 顧客の個人情報・音声データなど。外部送信は不可 ## 入力 {{input_text}} ## 出力（JSONのみ） { “level”: “low | moderate | high”, “reason”: “判定理由”, “send_external_ok”: true or false }

図4：機密度分類ゲート。外部AIへ送る手前で3段階に仕分け、highは外部に出さない設計にします。

注意：マスキングと匿名化は別物です

「マスキングしているから安全」とは限りません。NIST SP 800-188は、単に値を隠すマスキングツールと、真の匿名化（de-identification）を明確に区別しています。匿名化には、データの加工に加えて再識別リスクの計算が必要だからです。氏名を伏せても、属性の組み合わせから個人が特定され得ます。外部AIへ渡す前提なら、マスキングの定義と再識別リスクを必ずセットで検討してください。

アクセス制御と監査ログ｜「誰が何を見たか」を残す

部門ごとの権限がなく、誰がどのデータを閲覧・操作したかのログも残っていない。これは監査で必ず問題になります。前述のLakehouseのメタデータ層は、ここでも役立ちます。アクセス可否を検証してから生データの読み取り資格情報を発行し、全アクセスを確実にログ化する実装場所として自然だからです。原則として、正系DB以降は権限を集約し、全操作を監査ログに記録します。

国内の根拠もあります。総務省・経済産業省の「AI事業者ガイドライン（第1.1版）」は、検証可能性を確保するため、合理的な範囲でAIの入出力・推論過程・判断根拠などのログを記録・保存することを求めています。さらに、世界初のAIマネジメントシステム認証規格ISO/IEC 42001:2023は、附属書AのA.7「Data for AI systems」で、データ品質（A.7.4）、データ来歴（A.7.5）、データ準備（A.7.6）の管理を要求しています。これらは「監査ログを残す」設計の公的な裏付けになります。

書き戻し汚染を防ぐ｜AI生成物を正系に混ぜない

見落とされがちですが、最も危険なのが「書き戻し汚染」です。AIが生成した要約やラベルを、人手の確認を経ずにCRMの正系データへ書き戻すと、人間由来の正データとAI生成物が混在していきます。この危うさには、研究上の裏付けがあります。2024年にNatureに掲載されたShumailovらの論文は、AI生成物を無選別に学習へ使うとモデルに不可逆的な欠陥が生じる「model collapse（モデル崩壊）」を報告しました。初期には分布の裾（稀な事象）が失われ、後期には分散の小さい偏った分布に収束していきます。論文の結論は明快で、「元の（人間が生成した）データへのアクセスを保ち続けることが不可欠」というものです。

これはデータ基盤の運用に、そのまま教訓として効きます。対策は次の通りです。

出所フラグ（provenance）：すべてのレコードに「人間由来か／AI生成か」を必ず付与する
来歴管理（lineage）：どのデータから、どの処理を経て生成されたかを追跡できるようにする
人手承認：AI生成物は、人が判定・承認したものだけを正系へ書き戻す

なお、Natureの論文が直接検証したのは「再帰的にAI生成データで学習する」状況であり、CRMへの書き戻しそのものを実験したわけではありません。ここは妥当な類推として扱うのが誠実な姿勢ですが、出所フラグと来歴管理、人手承認という対策の方向性は、ISO/IEC 42001やNIST AI RMFが求める来歴・透明性とも一致します。

自社のデータパイプラインに、分類ゲートや来歴管理をどう組み込むか迷っていませんか？

弊社は、Difyや社内AIを前提としたAIデータ基盤の設計・実装を支援しています。現行のCRM・データレイク構成を踏まえた現実的なロードマップをご提案します。

無料で相談する

【回し方】PoCを運用に乗せて評価し続ける

最後は「回し方」です。冒頭のGartnerの予測どおり、PoCの多くは本番に至りません。理由はデータ品質の低さ、リスク統制の不足、コストの増大、そしてビジネス価値が測れないことです。ここを越えるには、評価と運用の仕組みをあらかじめ設計しておく必要があります。

人手レビューを「自動・抜取・全件」の3段階に振り分ける

「人が判定したものだけ正系へ」は正しい方針ですが、全件を人手で見ると運用が量に潰れます。現実解は、リスクと機密度に応じて自動・抜取・全件の3段階に振り分けることです。低リスクは自動承認、中リスクは抜き取り監査、高リスクは全件レビュー。この振り分け自体に、AIによる自動評価（LLM-as-a-judge）を組み込めます。

ただし、自動評価には限界があります。GPT-4のような強力な審査モデルは人間の選好と80%超で一致するという報告がある一方で、提示位置で回答を優遇する「位置バイアス」、長い回答を好む「冗長性バイアス」、自分の系統の出力を高く評価する「自己強化バイアス」が実証されています。「スコアラーで全部代替できる」という発想は研究上も否定されており、複数モデルの多数決＋人手の抜き取り監査を併用するのが堅実です。

図5：人手レビューを自動・抜取・全件の3段階に振り分け、評価KPIで継続的に改善します。

何を測るか｜RAG評価の3指標で「正答率・参照ヒット率」を可視化する

Difyのナレッジや社内AIで「効果が測れない」のは、指標を決めていないからです。RAG（検索拡張生成）の品質評価には、RAGAS（arXiv:2309.15217、EACL 2024採録）という確立されたフレームワークがあります。正解データに頼らずに、RAGの品質を3つの次元へ分解して測ります。

RAGASの指標	何を測るか	現場のKPIでいうと
Faithfulness（忠実性）	回答の主張が、検索した文脈から推論できる割合（F=支持される主張数÷全主張数）	正答率（ハルシネーション抑制）
Context Precision（文脈精度）	検索結果が、関連するチャンクを上位に出せているか	参照ヒット率
Answer Relevance（回答関連性）	回答が質問にきちんと答えているか（逆生成した質問との類似度）	回答の的確さ

これに、検索品質の古典指標であるRecall@k（上位k件に正解を拾えた割合）やMRR（最初の正解の順位）を補えば、「参照ヒット率」を多面的に追えます。加えて、利用者からの低評価（サムダウン）の収集を運用に組み込み、低評価が付いた問い合わせを優先的に改善のループへ回します。Faithfulnessで正答率、Context Precisionで参照ヒット率、低評価収集で現場の不満、という3点セットが、Difyの効果検証KPIの最小構成です。

回し続ける仕組み｜アジャイル・ガバナンスとPDCA

評価は一度きりでは意味がありません。NIST AI RMFは、AIシステムを導入前と運用中に定期的にテストし、その測定結果をリスク管理へ供給する「ライフサイクル全体の継続評価」を求めています。国内のAI事業者ガイドラインも、「リスク分析 → ゴール設定 → システムデザイン → 運用 → 評価」を素早く回すアジャイル・ガバナンスを重視し、運用開始後も継続的にモニタリング・改善し、外部環境の変化に応じてゴールを見直すことを促しています。ISO/IEC 42001のPDCAも同じ思想です。PoCを「終わり」ではなく「最初の1周」と位置づけ、KPIを使って回し続ける。これが本番移行を分ける最後の鍵です。

まとめ｜置き方・守り方・回し方の3つのチェックリスト

AI時代の構造化データは、次の3つの観点で点検すると、PoCで終わらせない基盤に近づきます。

【置き方】

二層型の限界（信頼性・鮮度・ML対応・TCO）を理解しているか
原本（Bronze）を忠実に保持し、Silver・Goldへ段階的に品質を上げているか
三層を最初から全て作り込まず、1層＋既存システム活用から段階導入できているか

【守り方】

外部AIへ送る前に「分類 → 匿名化 → 送信可否」のゲートがあるか（low／moderate／high）
マスキングと匿名化を区別し、再識別リスクまで検討しているか
正系DB以降で権限を集約し、全操作を監査ログ化しているか
AI生成物に出所フラグを付け、人手承認を経たものだけ正系へ書き戻しているか

【回し方】

人手レビューを自動・抜取・全件の3段階に振り分けているか
正答率（Faithfulness）・参照ヒット率（Context Precision）・低評価収集を測っているか
PoCを1周目と捉え、PDCAで継続的に評価・改善する体制があるか

よくある質問（FAQ）

Q.小規模な組織でもLakehouseは必要ですか？

A.必須ではありません。重要なのは「原本を忠実に1か所へ置く」という考え方です。まずはオブジェクトストレージにBronze層を作り、需要が見えてから整形・配信の層を足すのが現実的です。最初から三層をフルに作り込む必要はありません。

Q.既存のCRMやパッケージ製品は捨てるべきですか？

A.いいえ。既存CRMを正系の入力源として活かしつつ、AI活用に必要な部分だけをデータ基盤へ連携するのが定石です。顧客IDをキーにした名寄せなど、既存資産を再利用する設計から始めると投資を抑えられます。

Q.ChatGPTやDifyに社内データを入れて大丈夫ですか？

A.無選別で入れるのは危険です。送信前に機密度を low／moderate／high で分類し、high は外部送信不可、moderate はマスキングのうえ送信、と判定するゲートを設けてください。マスキングと真の匿名化は別物である点（NIST SP 800-188）にも注意が必要です。

Q.AIが作った要約をデータベースに保存してもいいですか？

A.保存自体は問題ありませんが、人間由来の正データと混ぜないことが重要です。出所フラグ（人間／AI生成）を付け、来歴を追跡できるようにし、人手承認を経たものだけを正系へ反映します。AI生成物を無選別に取り込むと品質劣化（model collapse）のリスクがあります。

Q.PoCをいつ本番へ移行判断すべきですか？

A.「動いたか」ではなく「測れているか」で判断します。正答率・参照ヒット率・低評価率といったKPIを定義し、目標値に対する達成と、継続改善できる運用体制（人手レビューの3段階・監査ログ）が揃っているかを基準にしてください。指標がないままの横展開は、放棄される30%への近道です。

AIデータ基盤の設計・実装はノーコードソリューションズへ

本記事では、AI時代の構造化データを「置き方・守り方・回し方」の3部で整理しました。データの置き場所、機密度分類と来歴管理、そしてRAG評価と継続運用。これらは個別の技術ではなく、ひとつの基盤として設計してはじめて、PoCが本番に乗ります。

弊社ノーコードソリューションズは、DifyをはじめとするAIツールの実装と、それを支えるデータ基盤・ガバナンス設計の受託開発を行っています。「PoCは動いたが本番に踏み切れない」「社内AIの効果を測りたい」「機密データの扱いを整理したい」といったご相談を承っています。貴社の現行構成を踏まえた、現実的なロードマップをご提案します。

お問い合わせはこちら他のテックブログを読む

参考文献・一次資料

Armbrust, Ghodsi, Xin, Zaharia. 「Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics」CIDR 2021. 論文ページ
Databricks「What is the medallion lakehouse architecture?」公式ドキュメント
NIST「AI Risk Management Framework (AI RMF 1.0)」NIST AI 100-1, 2023. PDF
NIST SP 800-122「Guide to Protecting the Confidentiality of PII」NIST CSRC
NIST SP 800-188「De-Identifying Government Datasets」NIST CSRC
総務省・経済産業省「AI事業者ガイドライン（第1.1版）」2025. PDF
EU AI Act 第10条（Data and data governance）. 条文
ISO/IEC 42001:2023「Artificial intelligence — Management system」ISO公式
Es, James, Espinosa-Anke, Schockaert.「RAGAS: Automated Evaluation of Retrieval Augmented Generation」arXiv:2309.15217, EACL 2024. arXiv
Yu et al.「Evaluation of Retrieval-Augmented Generation: A Survey」arXiv:2405.07437. arXiv
Zheng et al.「Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena」arXiv:2306.05685. arXiv
Shumailov et al.「AI models collapse when trained on recursively generated data」Nature, 2024 (doi:10.1038/s41586-024-07566-y). Nature
Gartner「Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept by End of 2025」2024-07-29. プレスリリース
MIT NANDA「The State of AI in Business 2025」（95%という数字は52件のインタビュー中心・PoC後6か月という評価窓に基づく定性的な数字で、解釈には留保が必要）