AI活用のデータカタログ構築手順｜検索・権限・品質をつなぐ

AI活用のデータカタログ構築手順は、資産を登録するだけでなく、検索、意味・品質・権限の確認、利用申請または見送りまでを一つの導線にすることです。保管場所だけを一覧にしても、AIへ利用できる理由や責任者は判断できません。

本記事は、社内データをAI開発やRAGへ提供するデータ基盤担当、データスチュワード、情報システム部門、業務データオーナーを対象にします。完成時の成果は、代表30資産を検索でき、許可・拒否テストを通し、利用申請の責任者と期限が表示される最小カタログです。

AI活用のデータカタログ構築は一つの利用場面と30資産から始める

最初の完成形は、全社データを網羅した巨大な辞書ではありません。例えば「営業企画担当が、需要予測へ利用できる国内販売データを探す」という一つの場面を選びます。利用者はキーワードと業務用語で検索し、対象期間、粒度、所有者、品質、利用条件、申請先を確認し、アクセス申請を送れる状態を目指します。検索結果から実データへ直接アクセスさせる必要はありません。

W3CのData Catalog Vocabulary Version 3は、Web上のカタログでデータセットやデータサービスを標準的に記述し、発見性と相互運用性を高めるRDF語彙です。2024年8月22日のW3C Recommendationが最新公表版で、版管理、データセット系列、チェックサムなども扱います。本記事は内部カタログの設計参考として用い、RDF採用やDCAT準拠を企業へ義務付けるものではありません^[1]。

NIST AMS 100-65は、データ発見をデータカタログなどのメタデータ管理システムの中核機能とし、複数の保存先を索引してメタデータを同期する流れを説明しています。さらに、データ検索とキュレーションを、利用者が必要なデータを見つけ、理解し、アクセスしやすくする機能として分けています^[6]。同資料は製造業の統合を対象とするNIST報告書であり、本記事では製品要件ではなく、検索・同期・説明を別工程として検証する根拠に限定して使います。

前提として、対象業務の責任者、データオーナー、最小限のID管理、検索画面または検索API、メタデータ保存先、申請受付手段が必要です。製品選定は後でも構いません。まずスプレッドシートや既存DBで項目定義と運用を試し、30資産で更新責任が回るかを確認します。ツールを入れても所有者と更新期限が空欄なら、検索できる不明データが増えるだけです。

カタログの受入条件は登録件数ではなく、利用者が目的に合う資産を見つけ、使える理由または使えない理由を確認し、正しい承認者へ到達できることです。

データセット、文書群、API、モデル用資産を別単位で登録する

登録単位は物理ファイルと一致させません。日次で増える販売明細100ファイルは、一つの論理データセットとして説明できます。一方、同じストレージに置かれていても、顧客台帳と問い合わせ履歴は目的、権限、保持が違うため分けます。対象資産IDは保管場所が変わっても維持し、物理的な配布物やAPIエンドポイントを別の「提供形態」として関連付けます。

初期30資産は、利用頻度だけで選びません。問い合わせが多い資産15件、品質問題が多い資産5件、機密性が高い資産5件、外部契約を伴う資産5件のように、運用課題を含む構成にします。簡単な資産だけで試すと、権限や失効の設計が本番で初めて壊れます。構成比は想定例なので、自社の利用量とリスクへ合わせます。

対象外の判断も記録します。保管場所も所有者も不明なファイル群は、いったん「調査対象」として隔離し、利用可能なデータセットとして検索結果へ出しません。廃止予定、法的保全中、利用権未確認、品質測定不能などの状態を用意すると、利用者は見つからない理由ではなく、利用できない理由と問い合わせ先を把握できます。

発見、理解、判断、申請に必要なメタデータを設計する

必須項目は、検索精度を上げる説明項目と、利用可否を決める統制項目に分けます。タイトルと概要だけを必須にすると発見はできても判断できません。逆に統制項目を増やしすぎると登録が止まります。初期版では20〜25項目に絞り、自動取得できる保存場所、スキーマ、更新時刻と、人が承認する業務定義、利用目的、機密区分を区別します。

DCAT 3の考え方を借りる場合、論理データセットと配布形態を分け、版と系列を関連付けます。社内の「販売実績」をデータセット、CSV、テーブル、APIを配布形態として持てば、内容説明を重複させず、形式ごとのアクセス条件を示せます。ただし社内項目を無理に標準語彙へ押し込まず、対応表を作り、独自項目の意味と値域を文書化します。

来歴にはW3C PROV-OのEntity、Activity、Agentという考え方を参考にできます。PROV-Oは異なるシステム間で来歴情報を表現・交換するためのW3C Recommendationで、2013年4月30日版が公開されています^[3]。内部実装では、入力資産、変換処理、実行主体を最低限分け、結果から処理と元資産へ戻れるようにします。

品質表示とアクセス許可を分離して誤利用を防ぐ

カタログ掲載は利用許可を意味しません。存在だけ公開できる機密資産、概要まで見せられるが項目名は制限する資産、申請後にサンプルだけ提供する資産があります。検索インデックスへ載せるメタデータと、実データの配布権限を別レイヤーにし、検索結果には「利用可」「申請要」「条件付き」「停止中」「対象外」の状態を表示します。

品質情報は単一の星評価にせず、指標名、式、値、母数、測定日、用途、既知の欠点を示します。W3C Data Quality Vocabularyは、品質測定、指標、次元、方針、注釈などを表現するWorking Group Noteです。2016年12月15日版を参照しつつ、標準が自社の合格値を決めるわけではない点を守ります^[2]。合格線は業務責任者とデータオーナーが用途別に承認します。

権限方針を機械可読にする際は、W3C ODRL Information Model 2.2のPermission、Prohibition、Duty、Asset、Party、Action、Constraintという構造が参考になります。ODRL 2.2は2018年2月15日のW3C Recommendationです^[4]。ただしポリシー記述だけで実際のアクセス制御は完了しません。ID基盤のロール、申請承認、期限切れ、拒否テストと結び付けます。

登録者、所有者、品質責任者、基盤運用者を分ける

カタログはメタデータ入力担当だけでは維持できません。正式名称と業務定義を承認するデータオーナー、日々の説明と品質課題を直すスチュワード、技術メタデータを自動収集する基盤担当、利用判断を行う業務責任者、契約・プライバシーを確認する専門担当が必要です。カタログプロダクトオーナーは検索体験と運用KPIを持ちます。

担当者名だけでなく組織IDと代理経路を登録します。人事異動で承認が止まるのを防ぐため、退職・異動イベントをID管理から受け取り、未処理申請を代理者へ再割当します。所有者不在が10営業日続いた資産は利用可表示を外し、新規申請を保留します。技術的にアクセスできても、責任主体がないデータをAIへ投入しません。

月次会議では登録件数より、検索失敗、承認滞留、期限切れ、権限拒否、利用後の品質問題を見ます。課題は資産単位で担当と期限を付け、同じ原因が複数資産に出る場合はメタデータ項目や連携処理を直します。運用会議の目的は空欄を責めることではなく、利用判断を妨げる構造的な欠落を減らすことです。

8週間で最小カタログを構築する手順

期間は想定例です。既存のID基盤やメタデータ管理がある組織は短縮でき、権利確認が複雑なら延長します。順序は、検索画面より先に利用場面と受入条件を定めることが重要です。各手順に確認方法と戻り先を持たせ、登録件数だけで完了にしません。

1. 第1週・利用場面を選ぶ。 利用者5名へ探索課題を聞き、検索から申請までの目標時間と必要な判断情報を決めます。確認は同じ質問に現在何分かかるかの基準値です。
2. 第1〜2週・30資産を抽出する。 頻用、問題、高機密、外部契約を混ぜ、資産ID、所有者候補、保管場所を仮登録します。所有者不明は利用可にしません。
3. 第2週・必須項目を承認する。 発見、理解、品質、権利、来歴、申請の項目を定義し、値域と入力責任をデータ辞書へ記載します。
4. 第3週・自動収集を接続する。 スキーマ、更新時刻、行数、保存場所、ジョブ情報を取得し、秘密値や実データ本文を不用意に複製しないよう確認します。
5. 第3〜4週・人の説明を補う。 スチュワードが概要、粒度、業務用語、既知の欠点を入力し、オーナーが用途と公開範囲を承認します。
6. 第5週・品質と権限を結ぶ。 測定式、母数、測定日、状態、申請先を登録し、許可利用者と拒否利用者でアクセス経路を試します。
7. 第6週・検索と申請を実装する。 業務語、別名、項目名で検索し、結果比較、詳細確認、申請、承認、期限付き付与までを一つの導線にします。
8. 第7〜8週・受入試験と改善を行う。 固定した10課題を利用者5名が解き、成功率、時間、誤申請、説明不足を測り、重大不備を解消して公開判定を行います。

最小カタログ受入記録
対象: 営業企画向け30資産
利用者: 5名 / 固定探索課題: 10問
検索成功: 46件 ÷ 50試行 = 92%
中央値: 6分40秒 → 2分15秒
権限拒否試験: 12件中12件成功
申請先不明: 0件
期限切れ品質表示: 2件を停止中へ変更
判定: 条件付き公開 / 未解決: 外部データ2件の費用表示

公開後に対象を増やすときは、同じ手順を資産群ごとに繰り返します。自動収集できる項目が増えても、人が承認すべき意味と利用条件を自動確定しません。新しいコネクタはテスト資産で差分を確認し、資産ID、版、所有者、機密区分を誤って上書きしないことを確かめてから本番へ入れます。

入力規則と利用者タスクの二層で動作確認する

検証は、メタデータが形式規則を満たすかと、利用者が正しい判断をできるかの二層で行います。必須項目が埋まっていても、概要が「売上データです」だけなら探索には役立ちません。機械検査で欠損、型、値域、参照整合、期限を確認し、人の受入で検索語、比較、権限理解、申請経路を確認します。

RDFでカタログを実装する場合、W3C Shapes Constraint LanguageはRDFグラフの内容を条件として記述・検証する言語です。SHACLは2017年7月20日のW3C Recommendationで、検証結果をValidation Reportとして表現します^[5]。RDFを使わない実装でも、同じ発想でJSON Schema、DB制約、アプリ検証を用い、規則と結果を版管理できます。

エラーは利用者向けと運用者向けを分けます。「アクセスできません」だけでは利用者が次へ進めません。利用者には状態、理由の範囲、申請先、再判定予定を示し、運用ログには資産ID、規則ID、入力値、検知時刻、影響導線を残します。ただし機密資産の存在自体を見せない設計では、拒否理由の表示が情報漏えいにならないよう調整します。

検索結果を比較し利用申請または見送りまで進める

利用者の標準フローは、検索、絞り込み、候補比較、詳細確認、申請、承認、利用開始、終了の八段階です。検索結果では名称だけでなく、対象期間、粒度、状態、品質測定日、所有者、利用費用を並べます。二つの似た資産を比較できないと、利用者は名前が分かりやすい方を選び、後で粒度や権限の違いに気付きます。

つまずきやすい三つの例

第一は、検索語が部門用語と一致しないことです。「売上」と「受注実績」を別名として結び、結果ゼロの検索語を週次でスチュワードへ返します。第二は、品質値が高い資産を無条件に推奨することです。品質は用途別なので、検索利用者が選んだ目的と測定用途が違えば警告します。第三は、承認されたのに利用環境へ権限が反映されないことです。承認IDと権限付与ログを結び、付与後に利用者本人が読み取りテストを行います。

見送りもフローの正常な出口です。目的に合う粒度がない、権利条件が合わない、費用が便益を超える、更新が間に合わない場合は、却下理由と代替資産を表示します。利用者が同じ不適合資産へ何度も申請するなら、説明不足か代替データ不足です。却下件数を担当者の負担として扱うだけでなく、データ投資の需要信号として集計します。

構築費と探索・承認の削減効果を同じ母数で測る

費用には製品ライセンス、クラウド、連携開発だけでなく、資産棚卸し、説明作成、所有者確認、品質測定、権限設計、利用者テスト、教育、月次運用を含めます。自動収集率が高くても、業務定義と利用条件の維持には人の工数が残ります。初期30資産の一件当たり費用と、追加100資産の限界費用を分けて記録します。

初期構築費 =
  設計費 + 製品・基盤費 + 連携開発費 + 30資産整備費
  + 権限実装費 + 受入試験費 + 教育費
月次運用費 =
  基盤費 + メタデータ更新費 + 品質測定費
  + 申請対応費 + 問題是正費
月間削減便益 =
  （導入前探索時間 - 導入後探索時間）× 月間探索件数 × 時間単価
  + 承認短縮便益 + 重複データ作成の回避額
12か月ROI = （12か月便益 - 初期構築費 - 12か月運用費）
             ÷（初期構築費 + 12か月運用費）× 100

想定例として、設計180万円、製品・基盤120万円、連携開発300万円、30資産整備150万円、権限実装180万円、受入試験90万円、教育30万円なら初期構築費は1,050万円です。月次運用費を45万円とします。探索が一件40分から12分へ減り、月300件、時間単価4,000円なら探索削減便益は月56万円です。これだけでは初年度投資を回収できないため、承認短縮や重複作成回避も実測します。

仮に承認短縮が月35万円、重複作成回避が月60万円なら、月間便益は151万円です。12か月便益1,812万円から初期1,050万円と運用540万円を引くと純便益222万円、ROIは約14.0%です。すべて計画値なので、公開後は検索ログ、申請時刻、利用者調査、廃止した重複データの実績で置き換えます。

採否評価は、探索・判断35点、権限・監査25点、更新運用20点、費用20点の100点とし、80点以上を拡張候補にできます。ただし権限拒否失敗、所有者不在、期限切れ資産の利用継続は得点に関係なく拡張停止です。登録件数目標だけを達成しても、利用開始完了率や誤申請率が悪化するなら、対象拡大より導線改善を優先します。

版、所有者、品質期限、権限を監視して停止を伝播する

日常運用では、ソース変更、所有者異動、品質期限、許可期限、利用実績、停止予定を監視します。技術メタデータは日次または取込時に更新し、業務説明は四半期、品質値は用途ごとの期限、権限は人事異動と申請期限に連動させます。更新できない項目は前回値を無言で残さず、「期限切れ」と表示します。

停止はカタログ表示だけで終わらせません。検索API、申請受付、データ配布、既存の期限付き権限、RAG索引、学習パイプラインへ状態変更を伝播します。直ちに止める範囲と、調査のため読み取り専用で保全する範囲を分けます。依存先一覧がない場合は、停止状態を付けても既存AIが古いデータを使い続けるため、公開前に最低限の利用登録を必須にします。

四半期レビューでは、利用可資産のうち期限内品質値がある割合、所有者が有効な割合、拒否テスト成功率、停止伝播時間を確認します。二四半期連続で必須メタデータ充足率が90%未満、または重大停止が配布先へ24時間以内に反映されない場合は、新規資産追加を止め、運用是正へ人員を移します。

カタログ構築が向かないケースと次に取る行動を決める

データカタログは、所有者不明や用途不明を自動で解決する装置ではありません。全社のデータ責任を決める意思がない、検索対象の保管場所へ接続できない、ID管理がなく利用者を識別できない、利用申請を承認する組織がない場合は、製品導入を先行させないでください。まず一部門で所有者、申請、失効の運用を成立させます。

本手順が向かないケース：個人のファイル探索だけを改善したい小規模チーム、全資産が同じ公開情報で権限差がない一時プロジェクト、または法的保全中でメタデータ公開自体を制限される調査です。前二者は共有フォルダーの命名・検索改善、後者は専門部署の証拠保全手続が先です。

ナレッジ検索の回答精度だけが課題なら、文書の重複、版、分割、引用を扱うRAG品質管理が直接的です。用語の揺れが中心ならマスターデータや語彙管理、結果の由来が追えないならデータリネージュを優先します。カタログはこれらを置き換えるのではなく、利用者が適切な資産と管理情報へ到達する入口です。

着手時は、利用者5名、固定探索課題10問、対象30資産、六つの必須項目群、五つの表示状態を一枚にします。8週間後に検索成功率90%、権限拒否100%、申請先不明0件を満たせなければ対象拡大を行いません。失敗した課題を、説明不足、検索不足、品質不足、権限不足、責任不在へ分類し、原因に対応する工程へ戻します。

参考文献・一次情報

1. W3C公式仕様「Data Catalog Vocabulary (DCAT) – Version 3」（W3C Recommendation、2024年8月22日、参照日2026年7月30日）
2. W3C「Data on the Web Best Practices: Data Quality Vocabulary」（W3C Working Group Note、2016年12月15日、参照日2026年7月30日）
3. W3C「PROV-O: The PROV Ontology」（W3C Recommendation、2013年4月30日、参照日2026年7月30日）
4. W3C「ODRL Information Model 2.2」（W3C Recommendation、2018年2月15日、参照日2026年7月30日）
5. W3C「Shapes Constraint Language (SHACL)」（W3C Recommendation、2017年7月20日、参照日2026年7月30日）
6. Yan Lu et al.「Metadata Modeling for Manufacturing Enterprise Integration」（NIST AMS 100-65、NIST編集審査承認2024年12月16日、2025年1月公開、2026年7月31日参照）。データカタログ構築手順で、検索・権限・品質を個別の管理機能として設計する際に使用。