DATA × AIをスケールさせるデータ基盤へ ― セルフサービスで実現するデータ品質管理 / Shibuya_AI_6

2026年10月16日開催の「渋谷 Biz × AI: ビジネスにおける AI 利活用 事例勉強会 第6回」の登壇資料です。
https://cyberagent.connpass.com/event/406165/

▼関連資料
1人1アプリから標準化へ：Vertex AIを活用したMLOps推進
https://speakerdeck.com/visional_engineering_and_design/shibuya-ai-4

技術的負債から考える、AI時代のエンジニアリング投資 — ビズリーチの技術的負債と向き合った経験から、変更し続けられるソフトウェアを考える
https://speakerdeck.com/visional_engineering_and_design/technical-debt-con2026

AI駆動開発が変える、大規模開発の前提 ーHuman in the Loop から Human on the Loop へ
https://speakerdeck.com/visional_engineering_and_design/aie2026

Percolatorを廃止し、マルチ検索サービスへ刷新した話
https://speakerdeck.com/visional_engineering_and_design/search-engineering-tech-talk-2026-spring

ブラックボックス化したMLシステムのVertex AI移行
https://speakerdeck.com/visional_engineering_and_design/mlops-community-62

ビズリーチにおける検索・推薦の取り組み
https://speakerdeck.com/visional_engineering_and_design/deim2026

-----
Visionalのエンジニアリングに関する最新情報はX、ブログで発信しています！📣

▼Visional Engineering Blog
https://engineering.visional.inc/blog/

▼VISIONAL ENGINEERING / X
https://twitter.com/VISIONAL_ENG

Transcript

1. DATA × AIをスケールさせるデータ基盤へ ― セルフサービスで実現するデータ品質管理 株式会社ビズリーチ ⽯⼭和樹
2. ⾃⼰紹介 ⽯⼭ 和樹 （いしやま かずき） 株式会社ビズリーチ プロダクト本部 データプロダクト部 データエンジニアリンググループ 経歴 ‧2026年 ⼤阪⼤学⼤学院 情報科学研究科 修了 （コンピュータビジョンの研究） ‧同年 新卒としてビズリーチに⼊社、データエンジニアリンググループに配属 ‧現在は BigQuery / dbt を⽤いた新規データ基盤の開発‧運⽤に従事 趣味 ‧漫画、アニメ、旅⾏、五⽬並べ
3. 今⽇お話しすること AIプロダクトのデータ加⼯と品質管理を データ利⽤者⾃⾝が⾏える データ基盤を作った
4. 背景 : 即戦⼒⼈材と企業をつなぐ転職サイト「ビズリーチ」 ビズリーチは求職者と企業のマッチングの機会を創出 個⼈ （求職者） マッチング機会 企業
5. 背景 : ビズリーチのマッチングを⽀える AIプロダクト AIプロダクトは30個以上 レコメンド‧検索‧予測から⽣成AIまで、マッチングの各場⾯で稼働 採⽤決定 個⼈ （求職者） マッチング機会 企業 企業向けレコメンド スカウトする候補者を AI が提案 求職者検索のリランキング レジュメ添削 求める⼈材を検索結果の上位に 職務経歴書の作成を AI が⽀援 ほか多数
6. 背景 : モデル開発はすでに「0→1」から「1→10」へ 前回の弊社発表「1⼈1アプリから標準化へ：Vertex AIを活⽤したMLOps推進」より https://speakerdeck.com/visional_engineering_and_design/shibuya-ai-4 0→1：速さと独⽴性を重視 1→10：数が増え、標準化へ 今⽇は、そのデータ側の話
7. 背景：0→1 の段階のデータ利⽤ 0→1 の段階では、データ基盤も AIプロダクトも、まず動かすことを優先していた • 各AIプロダクトが未加⼯データを受け取り、AIプロダクト側で特徴量に加⼯ • データ品質を確かめる仕組みはデータ基盤にもAIプロダクトにもまだなかった • データ基盤 : 重複や⽋損などのチェックがない • AIプロダクト : 加⼯の中でデータをテストする仕組みがない プロダクト DB データ基盤 品質チェックなし AIプロダクト 加⼯ テストなし AIプロダクト 加⼯ テストなし AIプロダクト 加⼯ テストなし
8. 問題１ : データ仕様変更に伴う修正⼯数の増⼤ データ変更に対し、影響するAIプロダクトの洗い出し、対応調査、修正 この作業を個別のAIプロダクトごとに繰り返す必要あり 開発チーム 変更 プロダクト DB データ基盤 AIプロダクト 加⼯ 修正 AIプロダクト 加⼯ 修正 AIプロダクト 加⼯ 修正
9. 問題２ : データの異変に気づくのが遅れ、影響が⻑引く データの⽋損や仕様変更で整合性が崩れても、気づく仕組みがない → 異常の⾒逃しに起因する障害の対応遅延が発⽣することも 障害 ⽋損 プロダクト DB データ基盤 AI開発チーム AIプロダクト 異変が出るまで わからない
10. 課題 : 責任と仕組みの整備 問題１ データ仕様変更に伴う 修正⼯数の増⼤ 問題２ データの異変に気づくのが遅れ、 影響が⻑引く 加⼯ 品質 加⼯の型と 品質の責任者を決め、 置き場所をそろえる テストを仕組みにする
11. 施策：誰が何に責任を持つか決める 基盤 データ利⽤者 データエンジニア • データの取り込み • 検証済みデータの品質テスト • 統制のレビューと、仕組みの提供 AI開発チーム • 加⼯ロジックの実装と修正 • 加⼯済みデータの品質テスト
12. 施策 : データ基盤の中に、利⽤者の領域をつくる • 加⼯と品質テストを、各AIプロダクトのコードから、基盤の中の利⽤者の領域へ • 統制の仕組みは、データエンジニアが基盤の機能として提供 新規データ基盤 BigQuery + dbt 利⽤者の領域 データエンジニア 検証済み データ プロダクト DB データ利⽤者 加⼯済み データ 加⼯ 品質テスト 品質テスト 統制（データエンジニア） CI デプロイ⽅法 アラート アクセス制御 データ利⽤者 AI プロダクト
13. 施策：利⽤者ごとの責任と実装の分割 利⽤者チームごとにディレクトリを分割 各チームが⾃分で加⼯ロジックを変更 <dbt プロジェクト>/models/ ├── raw/ valid/ dwh/ # データエンジニアの担当 └── mart/ ├── ai/ │ ├── feature_<AIプロダクトA>/ │ └── …（AIプロダクトごと） └── <別の利⽤者>/ # AI開発チームの担当 # 別の利⽤者チームの担当
14. 施策：統制の仕組みはデータエンジニアの責任 設定は利⽤者に任せ、統制のレビューと仕組みはデータエンジニアが担当 レビュー • 権限やデータの扱いといった テスト • 統制⾯だけ ※加⼯の中⾝は利⽤者同⼠でレビュー PRごとのCIと定期実⾏でテス アクセス制御 • ト • 失敗はアラートで通知 利⽤者がdbtで公開範囲を設 定できる仕組みを提供 • 重要度の⾼い列は、列単位で 制御
15. 施策：2層の品質テストの実装 データエンジニア： データそのものの正しさ - name: <区分コード列> data_tests: - name: <特徴量テーブル> data_tests: - not_null # ⽋損がないか - accepted_values: # 想定外の値が⼊っていないか values: [...] 利⽤者： 加⼯や要件に応じたテスト - dbt_utils.unique_combination_of_columns: # 粒度が想定どおりか combination_of_columns: [...]
16. 効果１：データ変更への対応の⼿間が減る 以前 洗い出し 修正 現在 影響するAIプロダクトを 依存関係をもとに、 ⼈が探す 影響する加⼯までCIが⾃動でテスト プロダクトごとの独⾃実装を 共通の型（.sql, .yml, .md）で 個別に直す 同じやり⽅で直せる
17. 効果２：異変に早く気づき、影響の⻑期化を抑える 以前：下流で問題が発⽣するまで検知困難 現在：データが取り込まれた時点でテストで検知 アラート ⽋損 プロダクト DB AI開発チーム 新規データ基盤 検知 品質 テスト AIプロダクト
18. 効果３：AI開発チームが⾃分で開発‧デプロイ可能 共通の型と品質テストの上で、0→1の時代の⾃律性を保ったまま開発 AI開発チーム 加⼯‧テスト 修正 CIで テスト デプロイ 結果 次の改善へ
19. やってみてわかったこと 利⽤者が増えると 仕組みだけでは テストにも マージが詰まる テストは増えない 費⽤がかかる • 利⽤者が少ないうちは • 1つのレポジトリで運⽤できる • • 増えると、各チームが 利⽤者側のテストは まだ⼗分でない • 基盤側から、ルールや マージやリリースの時期を モニタリングで後押し ⾃分で決めにくくなる する必要がある レポジトリやデプロイの 分け⽅は今後の検討課題 • 全量のテストは コストが⼤きい • PRのCIでは、変更した モデルとその下流だけ • 定期実⾏では、前回 からの差分だけ
20. 展望：⼈もAIも、⾃律的にデータを使える基盤へ 次 その先 データ所有者の⾃律 AIの⾃律 ⾃分のデータの意味‧品質‧ 意味と品質が紐づいたデータを、データプロダクト 変更の判断を、所有者が持つ として公開し、AIエージェントも⾃律的に使える 基盤が提供するもの 基盤が提供するもの 所有者が、品質テストと意味を書ける場 どの⽤途でも同じ意味で使えるよう定義し、 変更の影響を、変更前にわかる仕組み メタデータとしてAIが読める形で提供
21. まとめ やったこと データ利⽤者が、加⼯と品質テストを⾃分で⾏える、 セルフサービス型のデータ基盤を作った • 基盤の中に利⽤者の領域を作り、統制の仕組みはデータエンジニアが持つ 効果 • データ変更への対応の⼿間が減る • 異変に早く気づき、影響の⻑期化を抑える • AI開発チームは、⾃律性を保ったまま開発できる 次 ⼈もAIも、⾃律的にデータを使える基盤へ
22. ご清聴ありがとうございました！ 技術イベント 開催情報 エンジニア 最新情報 プロダクト組織は 仲間を募集中 connpassページ Xアカウント 採用サイト https://d-cube.connpass.com/ @VISIONAL_ENG https://careers.bizreach.co.jp/