連載⑦ データレディネス記事ドラフト
連載⑥（ベンダーロックイン・出口設計篇）で、「導入→定着→効果→本番化→組織→継続→出口」の一周が完成しました。第7回は新たな起点として、すべての上流に潜む問題——「データ」を扱います。
「高いモデルに変えても精度が上がらない」「RAGを入れたのに的外れな回答ばかり返ってくる」——この悩みを抱えるDX推進・情シス・経営の方は少なくありません。しかし真因を探ると、モデルの性能やプロンプトの問題ではなく、社内データそのものがAIに食べさせられる状態にないという事実にたどり着くケースが圧倒的多数です。
データがサイロ化し、鮮度が切れ、粒度がバラバラで、重複・矛盾を含み、権限設計が曖昧——この”データレディネス”の欠如を、現場・情シス・経営が切り分けられないまま「AIが使えない」と結論づけてしまう。本記事は、その診断と段取りを整理する「モデルを替える前に読む記事」です。
NOC/TACの現場ではこう言います。「監視が当てにならないのは、監視対象データが汚いから」と。Garbage in, garbage out——これをAIで再演しないための設計フレームを、技術実装の手前の組織・診断の視点でお届けします。
（1）”AIが賢くない”の9割はデータ問題——モデル／プロンプト／データの切り分け診断
AIの回答品質が低いとき、原因は大きく3つのどれかに属します。モデルの能力不足、プロンプトの設計不備、そしてデータの品質・状態の問題です。多くの現場が陥るのは、この3つを切り分けないまま「モデルを替えれば解決する」と判断してしまうミスです。
実際の優先順位は逆です。モデルを替えるのは最後の手段であり、その前に確認すべきことがあります。以下の診断フローを使って、まず原因を特定してください。
| 症状 | まず疑うべき原因 | 確認方法 |
|---|---|---|
| どんな質問にも的外れな回答が返る | プロンプト設計・コンテキスト不足 | プロンプトをシンプルにして汎用モデルで試す |
| 特定のトピックだけ精度が低い | そのトピックのデータが不足・汚染 | 対象トピックのデータソースを個別に確認 |
| 古い情報を自信満々に答える | データの鮮度切れ・更新フローの欠如 | 参照データの最終更新日を確認 |
| 矛盾した回答が混在する | データの重複・矛盾（Single Source of Truthの不在） | 同一事項に関するドキュメントの数を数える |
| 浅い・表面的な回答しか返らない | データの粒度不足・構造化の欠如 | 参照ドキュメントの記述粒度を確認 |
| 汎用モデル単体では正解を出せる | RAGに渡しているデータの問題 | 検索結果（チャンク）の中身をログで確認 |
重要な診断ステップは「汎用モデル単体テスト」です。ChatGPTやClaudeなどの汎用モデルに同じ質問を投げて正解が返るなら、モデルの能力は問題ない。つまり原因はデータかプロンプトにある。これで切り分けの起点ができます。
次に、プロンプトだけを最適化した状態でもなお回答が外れるなら、データに問題がある可能性が高い。ここで初めて「データレディネス」の診断に進みます。
（2）データレディネスを崩す6つの固着
「AIに食べさせられるデータ」の条件を満たせていない状態を、ここではデータレディネスの固着と呼びます。固着には6つの典型パターンがあり、多くの企業で複数が同時に発生しています。
固着①：データサイロ
部署ごと、システムごとにデータが孤立していて、横断的に参照できない状態です。営業部門のSFAデータ、カスタマーサポートのチケット履歴、技術部門の仕様書、経営の計画資料——これらが別々の場所に眠り、AIがアクセスできない形になっています。
RAGを構築しても、ベクトルDBに投入できるのはIT部門が把握している一部のデータだけ。「なぜAIは◯◯部門のことを知らないんだ」という現場の不満の多くは、このサイロが原因です。
固着②：鮮度切れ
ドキュメントは存在するが、内容が古い状態です。規程改訂前の社内ルール、廃番になった製品情報、組織変更前の担当者名——これらがそのままRAGのインデックスに入っていると、AIは自信を持って「嘘」をつきます。
更新フローが定義されていないドキュメントは、作成した瞬間から鮮度が劣化し始めます。「ドキュメントがある」と「有効なドキュメントがある」は別物です。
固着③：粒度不揃い
同じカテゴリのドキュメントでも、記述の細かさがバラバラな状態です。ある製品は5ページの詳細仕様書があるが、別の製品は3行のメモしかない。粒度の粗いドキュメントしかないトピックについてAIが答えると、必然的に浅い回答になります。「AIが表面的な回答しかしない」の多くは、粒度不揃いによる構造的な問題です。
固着④：重複・矛盾
同一の事実について、複数のバージョンや解釈が存在する状態です。Aという手順書が3バージョン存在し、最新版がどれか不明。あるいは、部署Xと部署Yで同一用語の定義が違う。RAGはこれらを等しくインデックスするため、矛盾した情報を同時に「根拠」として使い、一貫性のない回答を生成します。
固着⑤：非構造化・機械可読性の欠如
ホワイトボードの写真、スキャンPDF、パワーポイントのアニメーション中のテキスト、Excelのセル結合まみれの帳票——これらは人間には読めても、AIのインデキシングパイプラインでは正しく解析できません。「データがある」と「AIが読めるデータがある」は別物です。
固着⑥：権限設計の曖昧さ
「誰のどのデータをAIに見せるか」が定義されていない状態です。全社員が人事評価データを参照できるRAGを作ることは許されません。しかし、権限設計を厳密にやろうとすると工数がかかるため、「とりあえず全部入れる」か「怖いので何も入れない」という両極端に走りがちです。権限設計の不備はコンプライアンスリスクと使いづらさの両方を生みます。
（3）症状から原因へ——対応表で真因を特定する
「AIの回答がおかしい」という現象から、どの固着が原因かを逆引きする対応表です。現場からの不満報告をこの表に当てはめることで、調査の優先順位が見えてきます。
| 現場の症状・不満 | 真因の固着 | 一言で言うと |
|---|---|---|
| 「去年の情報を答えた」「廃止された制度を説明された」 | 固着②：鮮度切れ | 答えが古い＝鮮度 |
| 「概要しか答えない」「もっと詳しく聞いても同じ回答」 | 固着③：粒度不揃い | 答えが浅い＝粒度 |
| 「同じ質問に毎回違う答えが返る」「AとBで矛盾している」 | 固着④：重複・矛盾 | 答えが嘘＝矛盾データ |
| 「◯◯部門のことを全然知らない」「その情報は持っていないと言われた」 | 固着①：データサイロ | 知らない＝サイロ |
| 「文書があるのに検索でヒットしない」 | 固着⑤：非構造化 | 読めない＝機械可読性不足 |
| 「AIが機密情報を漏らした」「関係ない社員が見てはいけない情報を参照できる」 | 固着⑥：権限設計の曖昧さ | 見せすぎ＝権限不備 |
この対応表を使う際のコツは、「1つの症状＝1つの原因」とは限らないという点を意識することです。「的外れな回答」には鮮度切れと粒度不揃いが同時に絡んでいることも多い。まずは最も頻繁に報告される症状から着手し、固着を一つずつ潰していく優先順位をつけることが現実的なアプローチです。
（4）データ衛生の最小実装——Single Source of Truth・更新フロー・メタデータ付与
固着の診断ができたら、次は「どこから手をつけるか」です。完璧なデータ基盤を一度に作ろうとすると、プロジェクトは必ず止まります。ここでは、最小の工数で最大の効果を得るための3つの柱を紹介します。
柱①：Single Source of Truth（SSoT）の確立
同一の事実について、正式版が1箇所にしかない状態を作ることが最優先です。複数バージョンのドキュメントが存在する場合、「どれが正」を決め、他は廃棄または「参考履歴」として明示的にアーカイブします。
この考え方はネットワーク運用のCMDB（Configuration Management Database）と同じです。CMDBは「ネットワーク構成の正式な事実が記録されている唯一の場所」として機能します。これがないと、監視アラートが出てもどの構成が正しいか分からず、対応が混乱する。AIも同じです——SSoTがないと、何が正しいかをAIは判断できません。
実装の第一歩は「ドキュメントの棚卸し」です。主要な業務領域ごとに、関連するドキュメントを全部洗い出し、重複・矛盾しているものを特定し、正式版を1つ決める。小さな領域から始めて横展開する方が、全社一括よりも確実に進みます。
柱②：更新フローの定義
SSoTを確立しても、更新フローがなければ再び鮮度切れが起きます。ドキュメントを作成・更新するトリガー、担当者、承認フロー、タイムラインを明文化することが必要です。
現実的なアプローチは、「全ドキュメントに更新サイクルを設ける」のではなく、「変更事象が起きたときに自動的に更新フラグが立つ仕組み」を作ることです。例えば、製品仕様が変更されたらJiraチケットと連動してドキュメント更新タスクが自動生成される、人事制度が改定されたら社内規程の担当者にレビューアラートが飛ぶ、といった設計です。
柱③：メタデータ付与
AIがデータを適切に使うためには、ドキュメント本体だけでなく「そのドキュメントが何者か」を示すメタデータが必要です。最低限付与すべきメタデータは以下の5項目です。
| メタデータ項目 | 目的 | 例 |
|---|---|---|
| 最終更新日 | 鮮度フィルタリング | 2026-06-01 |
| ドキュメントオーナー | 更新責任の明確化・確認先 | 人事部・田中 |
| 有効期限・次回レビュー日 | 自動的な鮮度切れ検知 | 2026-12-31 |
| 対象業務領域・カテゴリ | 検索精度の向上・文脈付与 | 採用・中途採用プロセス |
| アクセス権限レベル | 権限設計との連動 | 人事部のみ閲覧可 |
メタデータはRAGの検索精度を劇的に向上させます。「最終更新から1年以上経過したドキュメントは検索対象から除外する」「権限レベルが’社外公開’のドキュメントのみを特定のエンドポイントで使う」といったフィルタリングが可能になります。
（5）”AIが食べられる形”への整形——組織として何を整えるか
データを構造化してチャンクに分割し、埋め込みを生成してベクトルDBに投入する——これはRAGの技術実装の話であり、チャンキング戦略やハイブリッド検索の最適化については技術実装ガイド（RAGチャンク・検索最適化篇）で詳しく扱っています。
本記事が扱うのは、その手前の組織的な準備です。技術実装をどれだけ最適化しても、入れるデータ自体が問題を抱えていれば意味がない。組織として整えるべき3つの点を挙げます。
① AIインデックス対象ドキュメントの「入口管理」
「何でもとりあえずRAGに入れる」運用は危険です。ドキュメントをRAGに投入する前に、以下のチェックを通過させるルールを設けることを推奨します。
- SSoT確認済みか（重複バージョンが廃棄されているか）
- 最終更新日が基準（例：1年）以内か
- メタデータが5項目付与されているか
- 機械可読な形式（PDF/Word/Markdown等）になっているか
- 権限レベルが付与されているか
このゲートを設けることで、「とりあえず入れた汚いデータ」がRAGを汚染することを防げます。
② 「データオーナー」の設定
ドキュメントの更新フローは、担当者が明確でなければ機能しません。業務領域ごとにデータオーナーを設定し、そのオーナーがRAG内のデータの品質・鮮度に責任を持つ体制を作ります。ITに丸投げするのではなく、業務ドメインを知っている人間が品質管理の責任を持つことが重要です。
③ 定期的なデータ衛生レビュー
四半期に1回程度、RAGのインデックスに含まれるドキュメントの健全性を棚卸しする運用を設けます。有効期限を超えたドキュメントの自動フラグアップ、アクセスされていないドキュメントの整理、新たな重複・矛盾の発見——これを定例化することで、データレディネスを維持できます。
（6）アクセス権限とデータ分類——誰のどの情報をAIに見せるか
「AIが機密情報を漏らした」というインシデントの多くは、権限設計をせずに全社データをRAGに投入したことが原因です。データをAIに渡す設計には、AIセキュリティ・データ分類の設計ガイドで扱ったアクセス制御の考え方が不可欠です。
実務上のアプローチとして、まずデータを以下の4段階に分類することを推奨します。
| 分類 | 概要 | AIへの開放レベル | 例 |
|---|---|---|---|
| 公開 | 誰でも閲覧可 | 全ユーザー対応AIに開放可 | 製品カタログ、FAQ、公式ウェブサイトコンテンツ |
| 社内一般 | 全社員閲覧可 | 社員向けAIに開放可 | 社内規程、共通業務手順書、全社向けお知らせ |
| 部門限定 | 特定部門のみ | 部門別の権限管理が必要 | 部門別予算、採用候補者情報、顧客詳細情報 |
| 機密 | 特定の役職・個人のみ | AIには原則不開放、または厳格な認証下のみ | 人事評価、役員報酬、M&A関連情報 |
この分類をメタデータの「アクセス権限レベル」と連動させ、RAGのクエリ時にユーザーのロール・所属に応じたフィルタリングをかけます。「全社員が使えるAIアシスタント」と「人事部専用AIアシスタント」は、同じRABシステムでも参照するデータストアを分けるか、権限フィルタを必ず通す設計にします。
権限設計は一度やれば終わりではなく、組織変更・人事異動・システム変更のたびに見直しが必要です。CMDBの構成変更管理と同様に、変更管理プロセスと権限設計を連動させることが長期的な安全性を担保します。
（7）データレディネス・セルフ診断チェックリスト
以下のチェックリストを、DX推進・情シス・現場責任者がそれぞれの視点で埋めることで、自社のデータレディネスの現状が見えてきます。「✗」が多い項目が、まず手をつけるべき優先課題です。
A. データの存在と可視性
| チェック項目 | 確認できたか |
|---|---|
| 社内のドキュメント・データが何処にあるか（場所の一覧）が把握できている | ○ / ✗ |
| 部署・システムをまたいでデータを横断検索できる環境がある | ○ / ✗ |
| ドキュメントの「正式版がどれか」が全社で合意されている | ○ / ✗ |
B. データの鮮度
| チェック項目 | 確認できたか |
|---|---|
| 主要なドキュメントすべてに「最終更新日」が記載されている | ○ / ✗ |
| ドキュメントの更新トリガーと担当者が明文化されている | ○ / ✗ |
| 1年以上更新されていないドキュメントを特定・整理できている | ○ / ✗ |
C. データの品質
| チェック項目 | 確認できたか |
|---|---|
| 同一事実について矛盾するドキュメントが存在しないことを確認している | ○ / ✗ |
| 主要業務領域のドキュメントが十分な粒度（手順、例外、注意事項を含む）で記述されている | ○ / ✗ |
| スキャンPDFや手書きデータ等の機械可読性の低いデータを特定している | ○ / ✗ |
D. 権限とガバナンス
| チェック項目 | 確認できたか |
|---|---|
| データを公開・社内一般・部門限定・機密の4段階以上に分類できている | ○ / ✗ |
| RAGに投入するデータの入口管理（レビューゲート）が設定されている | ○ / ✗ |
| 業務領域ごとに「データオーナー」が設定されている | ○ / ✗ |
| データ品質の定期レビュー（四半期等）が運用として定着している | ○ / ✗ |
判定の目安：「○」が10個以上——データレディネスは概ね整っており、技術実装の最適化フェーズに進める。「○」が5〜9個——部分的な固着がある。優先度の高い「✗」から段取りを立てて対処する。「○」が4個以下——データレディネスの問題がAI精度の主因である可能性が高い。モデルやツールを替える前に、まずデータ整備に集中投資する。
（8）よくある質問（Q&A）
Q1. RAGを導入すれば、データレディネスの問題は解決しますか？
解決しません。RAGはデータを検索して回答に使う「仕組み」ですが、検索対象のデータ自体が汚ければ、検索精度がいくら高くても的外れな回答が返ります。「RAGチャンク・ハイブリッド検索の最適化」はデータが整ってから効果を発揮する技術です。順番を間違えないことが重要です。
Q2. データ整備には莫大な工数がかかりそうで、どこから始めればよいか分かりません。
全社一括でやろうとするから止まります。まず「最もAIに聞かれる質問トップ10」を現場から収集し、それに答えるために必要なデータを特定することから始めてください。そのデータだけに絞ってSSoT確立・メタデータ付与・更新フロー設定を行い、小さく成功体験を作る。その後、横展開する方が確実です。
Q3. データオーナーを設定しようとしても、現場が「自分の仕事ではない」と言って動いてくれません。
これはデータガバナンスの最大の壁であり、技術ではなく組織設計の問題です。「AIの精度が上がらないのはデータオーナーが機能していないから」という因果関係を経営に説明し、KPIとして設定・評価に組み込む必要があります。情シスやDX推進が一人で抱えても解決しない問題です。経営を動かすことが先決です。
Q4. 権限設計が複雑すぎて、AIが使いづらくなる懸念があります。
正しい懸念です。権限設計は「厳しくするほど安全だが使いにくくなる」トレードオフがあります。まず「公開」と「機密」の2分類から始め、実用上問題が生じた段階で細分化するアプローチを推奨します。また、「部門横断で参照できると業務効率が上がるデータ」を経営判断として「社内一般」に昇格させることも、使いやすさと安全性のバランスを取る有効な手段です。
Q5. 非構造化データ（画像・音声・スキャンPDF等）もRAGで使えますか？
技術的には可能ですが、精度に大きな差があります。OCRや音声認識を経由した場合の誤認識率、画像内のテキストの解析精度——これらは通常のテキストデータに比べて劣ります。非構造化データはまず構造化・テキスト化するコストを見積もり、そのコストに見合う価値があるデータを優先的に整備することを推奨します。全部を一度にやろうとしないことが鉄則です。
まとめ——「モデルを替える前に、データを診る」
「AIの精度が上がらない」「的外れな回答しか返ってこない」——この問題の真因は、9割以上のケースでモデルではなくデータにあります。本記事のポイントを3つにまとめます。
1. まず切り分ける。モデル・プロンプト・データの3層で原因を切り分け、汎用モデル単体テストで「モデルの問題か否か」を最初に確認する。これをしないまま高いモデルに乗り換えても、同じ問題が繰り返されます。
2. 6つの固着から自社の問題を特定する。サイロ・鮮度切れ・粒度不揃い・重複矛盾・非構造化・権限不備——どれが最も「現場の不満」に対応しているかを症状対応表で逆引きし、優先課題を絞る。
3. SSoT・更新フロー・メタデータを最小実装で始める。完璧なデータ基盤を一度に作ろうとせず、「最もAIに聞かれる質問」を起点に小さく始めて横展開する。データオーナーの設定と定期的な衛生レビューを組織として定着させることが、長期的なAI精度の安定につながります。
次回・連載⑧は「人材・スキル不足／ツール乱立」問題を扱う予定です。「ツールは増えたが使いこなせる人間がいない」「AI担当者が1人しかおらず、その人が辞めたら終わり」という状況に対する組織設計と人材戦略を取り上げます。
免責事項：本記事は2026年6月時点の情報および一般的な実践知に基づく情報提供であり、特定の製品・サービス・構成における効果を保証するものではありません。また、法的・技術的助言ではありません。実際のデータ設計・権限管理・AI導入は、自社環境・適用法令・コンプライアンス要件に照らして検討し、必要に応じて専門家にご相談ください。
コメント