2026/06/11 データ事業本部 川中⼦凌平 データ品質とメタデータ管理で実現する 構造化‧⾮構造化データ活⽤のユースケース紹介 

⾃⼰紹介 2 名前：川中⼦凌平 (かわなごりょうへい) 所属：データ事業本部 ビジネスソリューション部 経歴：2024年4⽉ 中途⼊社 業務：データ分析基盤の構築（データエンジニア） 最近：ゴールデンレトリバーを飼い始めました https://dev.classmethod.jp/author/kawanago-ryohei/ 

今⽇お話しすること ● 近年は BI ツールだけでなくAIを利⽤したデータ分析‧活⽤も進んでいる ● AIの普及に伴って、画像やPDFなどの⾮構造化データの活⽤にも注⽬が集まっている ● しかし多くの現場において、データマネジメントの課題によって活⽤に⾏き詰まっている ● ⽀援の中で得た知⾒をもとに、現実的なデータマネジメントの実践例をご紹介 今回はデータ活⽤における頻出課題として、⼤きく2つのテーマを取り扱います。 ● 構造化データ × データ品質 ● ⾮構造化データ × メタデータ管理 3 

● 構造化データ：⾏と列で表せる、テーブル形式のデータ ○ 形式例：テーブルデータ、CSV、TSV、Parquet ○ データ例：取引データ、顧客マスタ、センサーの計測値 ● ⾮構造化データ：決まった形を持たないデータ ○ 形式例：PDF、docx、WAV、MOV、MP4、PNG、JPG ○ データ例：報告書、設計図、製品画像、設備の録⾳⾳声 ⽤語の補⾜ 4 

● 主に組織におけるデータ基盤を管理しているIT部⾨の⽅を想定対象としております ● またその周辺のデータ提供/利⽤側の⽅にも参考になれば幸いです 本資料における想定対象者 5 

構造化データ × データ品質 

● AIを利⽤した⾃然⾔語問い合わせにより、専⾨チーム以外のデータ分析機会も増えている ● しかし⽣成されるクエリが⾼精度でも、データ⾃体が低品質であれば結果は無意味 データ品質課題の例： ● ⽋損：センサーデータの取得値に⽋損値が多く、統計値を取得しても実態と乖離している ● 表記揺れ：製品名の表記揺れにより(ABC-100 / abc100)、同⼀製品が別物として集計される ● 重複：取引明細に重複レコードがあり、売上の集計が実態以上に膨らむ 課題：AIによるデータ分析でぶつかるデータ品質の壁 7 

⽣成AI活⽤におけるデータ品質の課題 ● PwC Japanの調査では、⽣成AIの効果が期待を下回った理由で「データ品質」で32% ● 実態は、そもそもデータ品質の課題に気づいていない層も多く存在すると推測される 8 https://www.pwc.com/jp/ja/knowledge/thoughtleadership/2025/assets/pdf/generative-ai-survey2025.pdf 

● データの⼊⼒時 ○ Excelなどの資料‧WebアプリUIでの⼈間による⼊⼒ミス、センサーの⽋測 ● データの収集‧加⼯時 ○ 複数ソース間でデータ定義の⼀貫性がなく、結合時に重複や⽋損が発⽣ ● 業務プロセスの変更時 ○ ソースシステム側のカラム名やデータ型の変更により基盤側との不整合が発⽣ これらの問題が発⽣した際、個別に全て対応するのは現実的ではない。 組織のデータ活⽤において重要度の⾼い部分から対応を進めることが重要。 基盤でデータ品質の課題が起こる理由 9 

● 経営上の意思決定や⽇々の業務遂⾏において影響の⼤きいデータをCDEとして定義する ● CDEはデータ利⽤者へのヒアリングから決定する ○ 業務部⾨のKPIを算出するために利⽤しているテーブル‧カラム ○ データ分析チームやマーケティング施策の企画担当者が参照しているデータ ● 特定したCDEに対して優先度を評価する 改善活動：Critical Data Element(CDE)を特定する 10 テーブル カラム 販売分 析 需要予 測 商品企 画 物流管 理 評点 優先度 商品 JANコード A A A A 24 1 売上 販売数量 A A B A 22 1 商品 商品名 A B A B 20 2 店舗 エリア C B C A 14 3 評価 評点 備考 A 6 経営リスク B 4 業務効率に影響 C 2 参考程度に利用 D 0 影響なし CDE管理表 評点⼀覧 

● 優先度の⾼いCDEに対し、観点ごとの⽬標値(閾値)を設定する ○ 利⽤要件：データ利⽤者側で許容される精度から⽬標値を逆算する ○ 現実性：いきなり100%を⽬指さず、段階的に⽬標値を設定する 改善活動：品質⽬標を設定する 11 CDE(カラム) 観点 目標 JANコード 完全性 欠損率 1%以下 JANコード 一意性 商品マスタ内の重複 0件 販売数量 完全性 欠損率 5%以下 販売数量 有効性 0以下の異常値 1%以下 商品名 正確性 商品マスタの正式名称との一致率 90%以上 エリア 有効性 許可値リスト外の値 5%以下 品質⽬標⼀覧 

● ⽬標との乖離を継続監視する ○ どこで：直接ユーザーが使⽤するテーブルやカラム ○ なにを：品質⽬標との乖離 ○ どうする：乖離が検知されたら担当者へ通知 ● データの⼊⼝をチェックする ○ どこで：RAWデータをデータ基盤のテーブルに取り込むタイミング ○ なにを：形式 / ⽋損 / 型 / 許可値 ○ どうする：問題を検知したら取り込み拒否 / 隔離 設計：継続監視と⼊⼝検査 12 

実装：AWS Glue Data Qualityを例に 13 

実装：AWS Glue Data Qualityを例に 14 基盤へのデータ流⼊⼝では データの型や形式をチェックする 

実装：AWS Glue Data Qualityを例に 15 直接ユーザーが利⽤するデータでは 品質⽬標との乖離を定点観測する 

運⽤：継続的な改善活動 16 対象データ特定 品質要件定義 品質測定 品質確認 品質改善 CDEの⾒直し 評価軸や⽬標値の⾒直し ‧CDEの特定 ‧データの優先順位付け ‧品質⽬標の設定 ‧品質ルールの設計 ‧品質ルールの実装 ‧品質チェックの実⾏ ‧⽬標達成度の確認 ‧品質低下の原因特定 ‧エラーデータの修正 ‧発⽣原因への対策検討 Plan Do Check Action 品質の定期チェック 

運⽤：シフトレフトの原則 17 ● エラーデータのクレンジングなどの対症療法は、問題の根本的な解決にはならない ● 根源治療を⽬指すには、基盤のより上流であるデータの発⽣源への対策が必要 データの品質低下 対症療法： ● データのクレンジング ● エラーデータの退避 根源治療： ● システム上で⼊⼒ミス → バリデーションチェックの機能を実装 ● 作業者ごとの⼿順不整合 → 作業マニュアルの整備 ● 業務プロセスの理解不⾜ → 担当者への教育や説明会の実施 

● データマネジメントの理想形としては、組織全体で課題に取り組む体制が求められる ● しかし実際はこのような体制をいきなり整えるのは難しい 運⽤：現実的な管理体制 18 

● まずはソースデータを管理する部⾨でデータオーナーを設定する ● 責任の所在を明確化することで、データ品質問題の発⽣から改善までのフローを確⽴する 運⽤：現実的な管理体制 19 

構造化データ × データ品質のまとめ 20 ● 利⽤者起点によるCDEの定義 ● 影響度を考慮した優先度付け 1 ⼊⼝側から守る ● 取り込み時の品質チェック ● データ⼊⼒システムの⾒直し ● ⼊⼒担当者への教育 2 体制は少しずつ ● データオーナーの設定 ● 改善フローの確⽴ 3 重要なものに絞る 

⾮構造化データ × メタデータ管理 

構造化データ ● 基本的に基盤において構造化データは、テーブルとして管理されている ● ネイティブなカタログツールとの統合や、AIによるメタデータ付与機能が充実してきている ⾮構造化データ ● IDCの調査によると企業の持つデータの90%は⾮構造化データとも⾔われている ○ 90% of your data is unstructured — and it’s full of untapped value ● しかしそのほとんどは、ただ保管されているだけで活⽤には⾄っていない 課題：溜まる⼀⽅なのに、うまく活⽤できない 22 

● フォルダ階層やファイル名の命名規則で頑張って管理していることが多い ● しかしそれだけだと表現できない情報もたくさんある 課題：⾮構造化データの難しさ recordings/ ├── 2026/ │ ├── 06/ │ │ ├── 01/ │ │ │ ├── TKT-20260601-0001.wav │ │ │ ├── TKT-20260601-0002.wav │ │ │ ├── TKT-20260601-0003.wav │ │ │ └── … │ │ ├── 02/ │ │ └── … 23 例：コールセンター対応の録⾳データ 「◯◯◯について聞きたい」 「△△△△△をご確認ください」 オペレーターID 顧客ID 商品ID 問い合せ分類 

● メタデータで情報を補完することで、⾮構造化データの活⽤の幅が広がる ● しかし⾮構造化データは膨⼤にあるため、管理⾯やコスト⾯でも全てを扱うのは⾮現実的 課題：膨⼤なデータのメタデータ管理は⾮現実的 24 オペレーターID 顧客ID 商品ID 問い合せ分類 recordings/ ├── 2026/ │ ├── 06/ │ │ ├── 01/ │ │ │ ├── TKT-20260601-0001.wav │ │ │ ├── TKT-20260601-0002.wav │ │ │ ├── TKT-20260601-0003.wav │ │ │ └── … │ │ ├── 02/ │ │ └── … 例：コールセンター対応の録⾳データ 

● データ品質と同じく、経営‧業務において重要度の⾼いデータ(CDE)から基盤に取り込む ○ 担当者が業務判断のために⽇常的に検索‧参照しているドキュメント ○ 監査や法規制の対応で提出を求められるファイル ● 特定したCDEに対して優先度を評価する 改善活動：重要なオブジェクト(CDE)を特定する 25 データ種別 品質管理 製品開発 監査 評点 優先度 検査報告PDF A A A 18 1 設計図PDF A A B 16 1 製品画像 B A C 12 2 設備の異音録音 C A D 8 3 評価 評点 備考 A 6 経営リスク B 4 業務効率に影響 C 2 参考程度に利用 D 0 影響なし CDE管理表 評点⼀覧 

改善活動：メタデータ設計のポイント ● データ利⽤者のニーズを起点に設計する ○ 基盤‧データ管理者の⽬線ではなく、あくまで利⽤者の⽬線でメタデータを設計する ● 業務⽤語を統⼀する ○ “不具合” / “故障” / “障害” などの表記揺れが多い⽤語を⼀つの表現に統⼀する ● 必要なメタデータのみに絞る ○ 項⽬を増やせばデータの管理はしやすくなるが、メタデータ提供側の負担になる 26 ファイル種別 メタデータ コールセンター録音音声 オペレーターID、顧客ID、問い合わせ分類、対応日時 検査報告PDF 製品ID、検査日、検査結果 製品画像 製品ID、撮影日、撮影目的 設備の異音録音 設備ID、ライン名、録音日時 メタデータ管理表 

● ⼊⼝でメタデータを付与する仕組み ○ どこで：基盤へのオブジェクトアップロード ○ なにを：メタデータ、プレフィックスの階層 ○ どうする：事前に設計したメタデータから選択、決まったルールを参照して⼊⼒ 具体的にどのように仕組み化するか？ ● ⾃動化できる部分はできるだけ⾃動化する ○ AWSではS3 Metadata、Google Cloudではオブジェクトテーブルを利⽤する ● ⼊⼒後のチェックシステムを実装する ○ メタデータを管理するテーブルに対する品質チェックの実施 ● ユーザーのオブジェクトアップロードフォームを⽤意する 設計：基盤⼊⼝でのメタデータ登録に注⼒する 27 

メタデータ⼊⼒の強制とRAGのユースケース 28 ● アップロードアプリからデータをCloud Storageに登録 ○ メタデータはプルダウンから選択 ● 構造化データが紐づく場合はシステム的に連携 ● オブジェクトテーブルに⾃動的に反映 ● Vertex AI Search (Agent Search) ⽤にデータ変換 ● オブジェクトの中⾝やメタデータ情報を包括的に検索 

運⽤：継続的な改善活動 29 対象データ特定 メタデータ 要件定義 メタデータ拡充 ユーザー ヒアリング メタデータ改善 CDEの⾒直し 登録メタデータの⾒直し ‧CDEの特定 ‧データの優先順位付け ‧メタデータ設計 ‧メタデータの登録 ‧登録フローの修正 ‧利⽤状況の確認 ‧メタデータ要望の受領 ‧メタデータの修正 ‧登録フローの修正検討 Plan Do Check Action 設計改善 

● こちらもデータ品質と同様に、まずはソースデータを管理する部⾨でデータオーナーを設定する ● 利⽤者からの問い合わせをデータオーナーに橋渡しし、協⼒してメタデータの改善を⽬指す 運⽤：現実的な管理体制 30 

⾮構造化データ × メタデータ管理のまとめ 31 ● 利⽤者起点によるCDEの定義 ● 影響度を考慮した優先度付け 1 ⼊⼝のメタデータ登録徹底 ● ⾃動収集機能の利⽤ ● ⼊⼒後の登録状況チェック ● 登録者の負担を考慮した設計 2 体制は少しずつ ● データオーナーの設定 ● 改善フローの確⽴ 3 重要なものに絞る 

まとめ 

2つのパートに共通する3つのポイント 33 1 2 3 重要なものに絞る ● 全てのデータを対象にデータマネジメント活動を⾏うのは難しい ● 費⽤対効果を意識し、価値創造に必要なデータのみに注⼒する シフトレフトの原則 ● ⼀度基盤に⼊ってしまったデータの改善活動には⼤きな労⼒を要する ● 課題の発⽣源の特定、根本原因への対策を最優先事項とする 体制もスモールスタート ● データマネジメントにおける課題は、基本的にシステムでは解決しない ● まずは最⼩限の体制から、泥臭く⼈の⼒で仕組みを作っていく 

データマネジメント活動の最適解は組織によって変わる 他組織での最適解が、必ずしも⾃組織に適⽤できるわけではない。 ● 「この事例の実装、うちのシステムには使えないな」 ● 「うちの組織体制ではこんな運⽤は⾮現実的だな」 ● 「予算的に厳しいし、そもそもうちのメンバーじゃ⼈⼿が⾜りない」 34 

クラスメソッド / データ分析‧活⽤での⽀援（再掲） 35 

全てのデータが正しく活⽤される未来へ 36 データ提供部⾨ IT部⾨ ⾃部⾨が⽣み出すデータが、 組織の意思決定や価値創造に 貢献していることが可視化される 「データを取られる部⾨」から 「価値あるデータを作る部⾨」へ データ利⽤部⾨ ⾃部⾨が管理するデータが、 組織の意思決定や価値創造に 対して⼤きな影響⼒を持つ 「裏⽅のコストセンター」から 「組織のデータ活⽤リーダー」へ ⽬的のデータを素早く⾒つけ、 信頼できるデータから 確かな分析‧意思決定ができる 「データを探し回る時間」から 「データから価値を⽣む時間」へ 

No content