AI Readyな安定性の高いデータ基盤を目指し、120個のデータコントラクトを結んだ話

freee 技術の日 2026のセッション資料です。

Transcript

1. AI Readyな安定性の⾼いデータ基盤を⽬指し、 120個のデータコントラクトを結んだ話 ⻲⽥量英/⽯井健太朗 2026年10⽉3⽇
2. CDO室データ部データマネジメントチーム 亀田量英 ベンダー系 SIer (ネットワーク)、データベース エンジニ アを経て、スタートアップ企業にてデータ サイエンティス トとして AI 開発、データ分析、データ分析基盤構築に 携わる。 現職ではデータ マネジメントをメインに活動していま す。
3. データ部チームマネージャー 石井健太朗 SIer, AI系スタートアップでデータサイエンティスト、 データエンジニアとしてデータ分析・レポートパイプ ラインの開発等に従事したのち、GO株式会社にて 約5年MLOpsエンジニアとしてML基盤の運用・開 発に携わる。現在はデータエンジニアとしてデータ 基盤の運用・開発を行なっています。
4. データ基盤ってなんだろう？ いろんな場所で⽣まれるデータを、必要なところに安全に届ける仕組みのこと 分析‧レポート freeeのプロダクトのデータ データ / AI プロダクト 営業、マーケティング データ基盤 DX / オペレーション 社内業務
5. AI/データ活⽤の成否を分ける安定的なデータデリバリー • データ基盤でのAI/データ活⽤の安定的な稼働にはデータの安定的な デリバリーが⽣命線 ◦ データ/AI活⽤の品質は⼊⼒データの品質に完全に依存する ◦ データパイプラインの停⽌はデータ/AI活⽤において致命的な障害
6. データ基盤をおびやかす⽇常的なリスク • 突然のテーブル/カラム削除やスキーマ変更などがAI/データ活⽤をおびやかす ◦ 予告無しのデータ型変更でシステム停⽌ ◦ ⽋損値や異常値の混⼊がデータ活⽤に影響 ◦ 上流のデータが障害発⽣すると多数の下流データの影響が出るのと復旧に も時間がかかる
7. スキーマ変更リスクなどはどうすればいいの？現実から理想へ • 現実 ◦ 今まではなんとなく運⽤でお互いになんとなくでしかルールがなかった ▪ こういうことがあると、下流に影響があるよ、ということを知らない⼈ が多かった ▪ 知っていて善意で教えてくれる⼈のおかげで“⼀部”成り⽴っていた ◦ プロダクト数も多いので担当者を把握するのも⼤変 • 理想 ◦ データ提供者と利⽤者が双⽅が楽に共通認識を持てる ◦ 変更があったときに速やかに双⽅が情報共有できる ◦ I/Fを決めておくことで、ルールさえ守っておけばお互いの事情を知らなく て済むのでスケールしていく
8. じゃあ具体的に何をすればいいの？ • データ提供側とデータ利⽤側で以下の内容等を合意形成する ◦ データスキーマ変更の検知や品質の保証 ◦ 担当者間でコントラクトを結び、担当者不在をなくす ◦ 障害時やスキーマ変更時のコミュニケーション明確化 • この契約のことを「データコントラクト」といいます
9. データコントラクトを“運⽤する”ということ • コントラクトという⾔葉が⽰す通り、データ基盤とステークホルダーの 間の関係性の上に成り⽴つもの • データ基盤メンバー以外の協⼒を⽋かすことはできない 一方的に制定したルールは定着しない
10. データコントラクトを“運⽤する”ということ • 特に開発側は以下のような運⽤負担が増える → 不均衡な利害関係 ◦ スキーマ変更時の連絡 ◦ 連携失敗時のトラブルシューティング etc • 利害を超えた協⼒関係を実現するには、北極星(= データを活⽤し、⾃分たちの 仕事を変えていくこと)を強く⽰すことが⼤切
11. データコントラクトの⽬的に⽴ち返る • データコントラクトの⽬的は、⽂⾯に書かれていることを守ることでは なく以下を達成すること ◦ 安定したデータ供給が重要であることの共通認識の醸成 ◦ 提供者側と基盤側で協⼒して運⽤する関係の構築 • 次に、それらをより低コストに維持するためにルールを設ける ◦ ルールを守れば、安定してデータ基盤が運⽤できますよねという、お 互いの関⼼ごとを減らすためのツール 何のためにルールを作るのかに⽴ち返る。 ⽬的はあくまで安定してデータをデリバリーし続けること。 “ルールを設ける”というのはあくまでそのやり⽅の⼀つ。
12. 困難を乗り越えるためのTips
13. Tips 1: すぐに同期で説明する 「いきなり⾔われても、テンプレートに書いてある内容すら分からない」とい うケースは少なくない。 そんなときは、「お時間をいただいてご説明させてください」とお願いし、同 期で話す機会をつくるようにした。 ⽂⾯を渡して終わりにするより、画⾯を共有しながら項⽬を⼀つひとつ説明し たほうが、記⼊してほしい内容を格段に理解してもらいやすくなる。
14. Tips 2: ペインを聞き出す 「忙しい」「こんなにたくさん書きたくない」という声も少なからずあった。 その時はまず、相⼿がどの部分に抵抗を感じているのかを聞き出す。多くの場合、 ⽂章量の多さから重厚な印象を持たれていた。 そこで、「最低ここだけは読んでほしい」「運⽤のために、せめてこの項⽬だけでも 記⼊してもらえませんか」と、負担の少ない着地点を⼀緒に探した。（完璧を求める より、まずスタートする） これは 無理かも… できることからやっ てみよう！ 守って ほしいな… これくらい なら…
15. Tips 3: 巨⼤な組織への対応 • データコントラクトは1プロダクト単位で締結した。1プロダクトを1チームで開発し ている場合は⽐較的スムーズだが、⼤きなプロダクトではチームが細分化されてい ることがある • すると、「プロダクトAのテーブルαの取り込みが失敗している」という状況になっ ても、そもそもどのチームに問い合わせればよいのか分からない、という事態が起 こる • そうしたケースでは以下のような“障害時の初動体制だけは決めておく”という運⽤ 体制を敷いた ◦ ①プロダクト側にデータコントラクトの対応責任者を⽴ててもらう ◦ ②障害発⽣時にはデータ基盤からその責任者に連絡し、適切なチームへフォワー ドしてもらう • すべてを⼀度に整えようとせず、まず⽌⾎できる形をつくることを優先した
16. データコントラクトの現在地 freeeではデータコントラクトは単なる契約の締結ではなく、 安定したデータ基盤を運⽤するための活きたルールとして根付きつつある。 AI Readyなデータ基盤へ全社をあげてコミットしています。
17. 将来の展望 フェーズ 1(現在) フェーズ 2(システム化 ) フェーズ 3(リネージ化 ) 文章ベースでデータ提供側とデータ収集側 システム 化 をして 規 定 したデータ 品 質 や 上流データで結んだコントラクトを下流のコ がコントラクトを締結している状態 SLAを自 動 的にチェックや検 知ができる状 ントラクトと伝搬させるようにする状態 態