精度が上がっても嬉しくない？ - データプロダクトのVersioningとMigration

沖縄の企業に聞いてみた。Snowflake、実際使ってどうですか！？ ─ 第2回 Snowflake OKINAWA User Group LT
https://techplay.jp/event/1000826

Transcript

1. 精度が上がっても 嬉しくない？ データプロダクトのVersioningとMigration 2026/10/24 第2回 Snowflake OKINAWA User Group 株式会社ナウキャスト Data Engineer ⼤城 翼 © 2026 Finatext Group
2. Snowflakeのテーブルが、Consumerとのインターフェースになる データソース Producer（ナウキャスト） インターフェース クレカ‧POS 企業開⽰ Consumer Webアプリ Snowflake ＋ dbt テーブル 顧客 ほか30以上 （Data Sharingで利⽤） インターフェースであるテーブルの変更は、APIの変更と同じように Breaking Changeになり得る © Finatext Group
3. 2種類のBreaking Change 企業開⽰情報 決済データ 改善 改善 XBRLパース（v1）からLLM抽出（v2）へ拡張 推定売上の精度を上げる（v1 → v2） 変更 変更 スキーマが変わる（カラムの分割など） スキーマは同じ。値が変わる。 ヒストリーが短くなる 影響 影響 SQL‧アプリが動かなくなる SQLは動く。分析結果が変わる 今⽇は後者の話：SQLは動くのに、分析結果が変わる © Finatext Group
4. 決済データ：精度は上がったが、過去は作れない v1 ヒストリーは⻑いが、精度に課題 v2 この期間にはv2の⼊⼒データがない 過去 精度は⾼いが、ヒストリーが短い ↑ データホルダー側のシステム変更 v1の過去とv2の直近を単純につなぐと 現在 精度が⾼い ≠ 顧客の分析に使える v2（直近分） 段差＝売上の変化ではない v1（過去分） 継続中（いずれ停⽌） ヒストリーが短く、段差があると、 バックテストの結果が変わり、モデルの調整が要る 模式図（仮想例） © Finatext Group
5. どちらのBreaking Changeも、対応の⽅法は同じ 共通の⽅法 別テーブルでv1とv2を並⾏提供し、新しいv2に移⾏してもらう v1は置き換えずに残し、Consumerが⾃分のタイミングでv2に移る 違うのは、Consumerが「移⾏できる」と判断する条件 スキーマが変わる変更（企業開⽰情報） 中⾝が変わる変更（決済データ） ‧新しいスキーマへの対応 ‧SQL‧アプリの動作確認 ‧取れる値が期待どおりか ‧ヒストリーの⻑さ ‧新旧の値‧成⻑率の差 ‧⾃分の投資モデルで使えるか © Finatext Group
6. データの改善 ≠ Consumerの価値向上 変える前に考える3つの問い 1 誰が依存しているか？ 2 何が変わるか？ スキーマ‧値‧ヒストリー 3 どうすれば移⾏できるか？ リリースは終わりではない。 Consumerが改善を使えるようになるまでの道筋を設計する © Finatext Group