✅
データ品質 どう担保する？ 〜 複雑化を乗り越える品質管理のリアル 〜
公開
2025-04-14
更新
2025-04-14
文章量
約3957字
Yard 編集部
Yardの編集部が、テック業界の最新トレンドや知見について発信します。
目次
1. 「完全自動運転のモデル開発におけるデータ品質とは」
完全自動運転に向けた“データ中心”の開発
3つのレイヤーで捉えるデータ品質
まとめ
2. 「データ品質を守り続けるためのデータ基盤の考え方」
データ基盤の変更容易性が品質を守る
“変更容易性”を高める設計
ADR・テストの導入で“悪しき共通化”“雑なコピペ”を防ぐ
3. 「分析観点での正確性を管理するためADRを導入した話」
主要データを統一しようとしたら…“本当に合ってる？”が立ちはだかる
ADR（アーキテクチャーディシジョンレコード）の導入
効果と今後の課題
Q&A・全体ディスカッション：組織のバリエーションを前提に考える
最後に - 「品質」を育てる柔軟な設計とコミュニケーション
「データ活用の重要性が増すにつれ、データの不備や仕様の曖昧さ、そしてさまざまな視点での分析需要が絡み合い、“品質管理”が一段と困難になっている」。 2025年3月18日に開催された本イベントでは、そうしたデータ品質にまつわる課題を乗り越える実践事例が共有されました。 複雑なデータ基盤構築やAI開発の現場で、どのように品質を維持し続けているのか――当日は、下記3名のエンジニアが自社のリアルな取り組みを発表し、最後には質疑応答から見えてきた課題・視点も議論されました。
1. 「完全自動運転のモデル開発におけるデータ品質とは」
Turing株式会社 / matsさん
完全自動運転に向けた“データ中心”の開発
Turing株式会社は、カメラ映像だけで車を走らせる“完全自動運転”を目指すスタートアップ。膨大なセンサーデータを収集・活用してAIモデルを訓練している点が大きな特徴です。 モノづくりというより、どれだけ“良いデータセットを作るか”が結果的にモデルの性能に直結するため、「データの質」「多様性」「量」を高めることが極めて重要とのことでした。
3つのレイヤーで捉えるデータ品質
車両での収集レイヤー
センサーが安定動作しているか
欠損や不整合が生じていないか
車両ごとのキャリブレーションずれを検知
ロー（Raw）データそのものの品質
ライダー情報や位置情報など、多種多様なセンサー間の同期が正しいか
一部状況（トンネル、屋内）だとGPSが不安定で後処理が必要
学習に使う“シーン”を構成するデータの品質
20秒ごとのまとまりを“シーン”として抽出した際に、中途半端な映像断片を含んでいないか
雨の日や夜間など、多様な走行条件がきちんと含まれているか
特に、自動運転では現実世界の不確実性が高く、「後からデータを補正・再処理できる仕組みを残しておく」ことが極めて重要だと語られました。 また、データを可視化しつつ「これはライダーとカメラのタイムスタンプがずれてそう」といった異常に気づく仕組みを作り込むことで、後になってからも再補正・再学習をしやすくするそうです。
まとめ
自動運転のようなリアルなセンサーを扱う現場では、“エラーや欠損が起きる前提”で設計し、その時に再補正や再抽出が容易になる仕組みを整えることがカギ。大量のデータを前に、人の目と自動処理を組み合わせた“継続的な観測”がデータ品質向上には欠かせないと強調していました。
2. 「データ品質を守り続けるためのデータ基盤の考え方」
株式会社10X / tenajimaさん
データ基盤の変更容易性が品質を守る
10Xは、ネットスーパー事業を支えるプラットフォームを提供する企業。アナリティクスエンジニアとしてtenajimaさんは、多数のモデルが乱立するデータ基盤で“品質をどう保ち続けるか”に挑戦しています。 過去にはモデル数（派生含む）が膨大に増え、ジョインミスやバグ修正が困難になりがち。そこで「レイヤーを明確に分割し、責務に応じた制約を設定する」ことで、後から変更しやすい構造を目指したそうです。
“変更容易性”を高める設計
責務が曖昧なレイヤーを作らない 「ステージング」「履歴を表現するレイヤー」「ビジネスロジックレイヤー」「社内向けのディメンショナルモデリングレイヤー」など、段階をはっきり区切り、それぞれのレイヤーでどんな処理まで許可するかを制限。
マートがマートを参照しない レイヤーをまたぐ参照ルールを徹底。複数マートが相互依存すると修正範囲が雪だるま式に広がるため、厳密に禁止する。
テストによる守り DWH上のSQLに合わせてテストコードを準備。レイヤーごとにどのような粒度のテストが必要かをあらかじめ定義し、漏れを防ぐ。
ADR・テストの導入で“悪しき共通化”“雑なコピペ”を防ぐ
tenajimaさんのチームでは、過去に“PoC段階のモデルが多数コピペされ、保守負荷が爆増”という事態を経験。その反省から、「一時的なモデルに撤退期限を設ける」「分析用途・ビジネス用途を明確に区別する」など、管理ルールを厳格化しているとのことでした。 こうした制約・レイヤー分割がしっかりできると、テストや共通化を正しく導入しやすくなり、結果としてデータ品質を守り続けることが可能になる、と強調していました。
3. 「分析観点での正確性を管理するためADRを導入した話」
株式会社MonotaRO / 吉本 直人さん
主要データを統一しようとしたら…“本当に合ってる？”が立ちはだかる
MonotaROでは、さまざまな部署がデータを活用していて、売上の定義1つを取っても部署・個人によって微妙に異なるといった問題が顕在化。 そこで「全社の主要データを1つのDWHで定義し、業務を超えて統一しよう」という方針でデータ基盤を再整備したものの、実装時点で「要件を満たしているか」「データソースが想定通りか」など、いくつもの“根拠づけ”が必要になりました。
ADR（アーキテクチャーディシジョンレコード）の導入
何をしたかった？ 分析観点で“これで正しいのか”と問われたときに、ソースコードやドキュメントだけでは判断しきれない。そこで「こういうビジネス理由で、こういうロジックにした」という“議論の経緯と結論”をテキストで残す仕組みを作った。
具体的な運用 DWHの実装ごとに「誰がどんな議論をし、最終的にどう決断したか」をADRとして書き残す。そしてそのURLをDWHポータル内でリファレンスしておく。
「この利益計算は、発注ロジックのAパターンとBパターンがあるため、こういうロジックで合算している」というような背景を詳しく残す。
業務側・データエンジニア側が「これだと例外Cは考慮してないですよね？」と後から指摘しても、ADRに紐づけて差分を追記できる。
効果と今後の課題
“間違ってるかどうか”を判断するための材料が増えた ADRにより「これはAパターンとBパターンのための実装。Cパターンは考慮外」と書いてあれば、業務チームは「Cパターンも必要」と早めに気づける。
すべてを解決したわけではない 既に定義済みの2つの課題、つまり「ビジネス要求の理解」と「データソース仕様の理解」はADRだけでは補いきれない。各ドメインとの密接な連携が必要となる。
組織的にはアナリティクスエンジニアを増やす方針 ドメイン別にデータを管理・活用し、中央集約だけでは対応しきれない要求にも対応する。「データメッシュ」的な発想を取り入れつつ、ADR活用で品質を支えたいとのことでした。
Q&A・全体ディスカッション：組織のバリエーションを前提に考える
最後の質疑応答では以下のような論点が出ました（要約）:
「品質を守ろうと言っても、社内で抵抗はなかったか」
matsさん「自動運転ではデータ量がとにかく多く、そもそも不備が当たり前。品質保証への理解は比較的スムーズだった。ただ、高品質といっても‘後で再補正できる余地を残す’ことで柔軟に運用している」
tenajimaさん「通常のWeb系サービスでも、初期から設計を厳密に決めるのは大変。途中で“わりとラフなモデル”をつくってしまいがちだが、撤退条件を設けるなど、管理ルールを決めることで変化に備えている」
「すべてを中央チームで面倒見るのは無理では？」
吉本さん「ADRでロジックの背景を記録しておくのは必須だが、結局ドメイン知識を深く理解する人がいないと判断が難しい。アナリティクスエンジニアなど、ドメインに入り込んだ人材を増やす取り組みを進めている」
全体として、各社でデータ品質管理の現場は異なるものの、「安易なコピペや属人的な仕様で混乱を招く」「後になって見返せる議論のログを整備することが欠かせない」という共通認識が見えました。
最後に - 「品質」を育てる柔軟な設計とコミュニケーション
今回の3社の事例を通して浮かび上がったのは、「データ品質は静的に保証されるものではなく、データソースや要件が日々変わる中で、どう‘保ち続けるか’が課題」という点でした。
後で補正できる設計を残す
自動運転のようにセンサーがずれる現場では、そもそも“誤差が発生しない”ことは期待できない。柔軟に再処理できる余地が大きく品質維持の鍵。
レイヤー分割と制約で設計を守る
10Xのように「マートがマートを参照しない」など、組織内ルールを厳格に定めることで、複雑化を遅延させる。
議論の背景を“ADR”などで残す
MonotaROの事例では、どのような理由でこのロジックを採用したかを記録することで、「実は例外があった」「別のパターンが要る」などに気付きやすくなる。修正もスピーディに。
まとめると、日々更新されるデータを一度に“完璧”に保証するのは困難ですが、変更容易性を高める設計・履歴を追える仕組み・ドメイン理解を組織に広げる――これらを少しずつ整備し、運用の中で柔軟に品質を担保していくことが現実解なのでしょう。 多くの企業が膨大なデータを扱う時代、「どのレイヤーで何を守り、どのように認識を揃えるか」という設計思想が、データ品質を大きく左右する。その一端を、今回のイベントは示してくれました。
Yardでは、テック領域に特化したスポット相談サービスを提供しています。
興味がある方は、初回の無料スポット相談をお申し込みください。
また、資料請求やお問い合わせもお待ちしております。テック領域の知見を獲得し、事業成長を一緒に実現していきましょう。
