データ品質を壊しながら Snowflake の AI に分析させてみた データ事業本部ビジネスソリューション部 川中⼦凌平 

⾃⼰紹介 2 名前：川中⼦凌平 (かわなごりょうへい) 所属：データ事業本部 ビジネスソリューション部 業務：データ分析基盤の構築（データエンジニア） 趣味：⽝と遊ぶこと https://dev.classmethod.jp/author/kawanago-ryohei/ 

今⽇お話しすること ● ● 今回はデータ分析基盤で管理するデータの品質ついてお話しします ○ データ品質がAIによる分析に与える影響 ○ データ品質を守るためのSnowflakeの機能 データ品質などの運⽤⾯については6⽉のウェビナーでお話しています 3 

データ分析はAIが担う時代に ● AIの活⽤によりビジネスユーザーが⾃然⾔語でデータ分析できる時代に ● Snowflakeはデータの蓄積‧管理からAIによる分析まで⼀つのプラット フォームで完結するため⾮常に⼈気がある https://www.snowflake.com/ja/blog/ai-data-agents-snowflake-cortex/ 4 

AI活⽤におけるデータ品質の課題 ● PwC Japanの調査では、⽣成AIの効果が期待を下回った理由で「データ品質」が1位 ● 実態としては、そもそもデータ品質の課題に気付いていないケースも考えられる https://www.pwc.com/jp/ja/knowledge/thoughtleadership/2025/assets/pdf/generative-ai-survey2025.pdf 5 

データ品質がAIの分析結果に与える影響 6 

検証構成イメージ ● 内部ステージ：ソースシステムから⽣データのCSVを連携 ● Bronze層：COPY INTOで⽣データをロード ● Silver層：正規化‧型変換 ● Gold層：BI‧AI向けに公開 + Semantic Viewを定義 ● AI活⽤層：Cortex Analyst + Agentで分析 7 

Semantic Viewの定義 ● Gold層には以下のような定義でSemantic Viewを作成した CREATE SEMANTIC VIEW EC_SALES_ANALYSIS TABLES ( orders AS ORDERS PRIMARY KEY (ORDER_ID) COMMENT = '注⽂トランザクション', customers AS CUSTOMERS PRIMARY KEY (CUSTOMER_ID) COMMENT = '顧客マスタ', products AS PRODUCTS PRIMARY KEY (PRODUCT_ID) COMMENT = '商品マスタ' ) RELATIONSHIPS ( orders (CUSTOMER_ID) REFERENCES customers (CUSTOMER_ID), ... ) DIMENSIONS ( orders.order_id AS ORDER_ID COMMENT = '注⽂ID', ... ) METRICS ( orders.total_order_amount AS SUM(ORDER_AMOUNT) COMMENT = '注⽂⾦額合計', ... ) 8 

分析対象データ 9 

正常な状態での分析 ● 投げた質問に対して正しい情報が返ってくることを確認 ● 正常なテーブルでの売上集計は915,900円だった 10 

データ品質劣化の想定ケース 11 ● 現実のデータ基盤運⽤では、様々な原因でデータ品質が劣化する ● 今回は以下のケースを想定してデータ品質を壊してみました 原因 例 連携処理の不備 同⼀データが別名ファイルとして再連携されてデータが重複 ソース側の仕様変更 ソース側の障害 返品データが負の⾦額として混⼊ ⽇次エクスポートが停⽌してしまい鮮度が劣化 

ケース1 — 重複データの混⼊ 想定シナリオ：同⼀データが別名ファイルとして再ロードされた ● 8⽉のレコードが全て2⾏ずつに重複してしまっている状態 12 

ケース1 — 重複データの混⼊ ● 実⾏した集計処理は正しいが、実際の売上よりも2倍⾼い⾦額が出てしまう 13 

ケース2 — マイナス⾦額の混⼊ 想定シナリオ：ソース側の仕様変更で、負の⾦額が売上テーブルに混⼊した ● ORDER_AMOUNT列に負の値が⼊ってしまっている状態 14 

ケース2 — マイナス⾦額の混⼊ ● 負の値もまとめて集計されてしまい、実際の⾦額よりも低く出てしまう 15 

ケース3 — データの鮮度劣化 想定シナリオ：ソース側の⽇次連携が停⽌し、直近7⽇分のデータが⽋落 ● 8⽉25⽇以降のデータがテーブルに連携されていない状態 16 

ケース3 — データの鮮度劣化 ● 8⽉24⽇までのデータしか集計されず、実際の売上より低く出てしまう 17 

AIはデータ品質の異常を⾒落とすことがある ● 3つのエラーケースの結果は以下の通りだった ケース ● 重複データの混⼊ ⾦額が実際の2倍になる マイナス⾦額の混⼊ ⾦額が⼤幅に少なくなる データの鮮度劣化 ⽋落分だけ⾦額が少なくなる いずれのケースでもAIによる分析では異常を指摘しなかった ○ ● 分析結果への影響 内容によっては、異常に気付いて教えてくれるケースもあった ユーザーに誤った⽰唆を与えてしまうリスクが⽣じる 18 

なぜAIはデータ品質の異常に気付けないのか ● Semantic Viewではデータの構造や意味を説明している 定義するもの 例 テーブルの説明 「注⽂トランザクション」 主キー テーブル間の関係性 カラムの意味 集計指標 ORDER_ID ORDERS.PRODUCT_ID → PRODUCTS.PRODUCT_ID 「注⽂⾦額（⽇本円）」 SUM(ORDER_AMOUNT) → 注⽂⾦額合計 ● Cortex Analystはこの情報をもとにSQLを⽣成する ● しかしカラムの有効値や値の形式のようなデータ品質の制約は持てない ● データ品質を守り、異常を検知するには別の仕組みが必要 19 

データ品質を守るために 20 

データ品質を守る2つのポイント 21 ● ⼀度⼊ってしまったエラーデータをクレンジングするのは⾮常に⼤変 ● データが⼊ってくる⼊⼝と、活⽤の窓⼝の両⽅を監視することが重要 基盤の⼊⼝で守る データを定点観測する どこで：基盤への⽣データの取り込み どこで：公開するテーブル / カラム なにを：型 / ⽋損 / 形式 / 許可値 なにを：品質⽬標値との乖離 どうする：問題を検知したら拒否 / 退避 どうする：品質低下を検知したら通知 

データ取り込み時のエラー処理 ● ● 22 COPY INTOやSnowpipeでは基本的なスキーマレベルのエラーを検知する ○ データ型不整合 / カラム数の不一致 / NOT NULL制約違反 など ○ 値の重複 や許可値、値閾などの品質検証はできない エラー発⽣時の挙動はON_ERRORオプションで細かく制御が可能 値 動作 ABORT_STATEMENT 最初のエラーで全体を中断 CONTINUE エラー⾏をスキップして続⾏ SKIP_FILE エラーのあるファイルを丸ごとスキップ SKIP_FILE_n n件以上のエラー⾏があるファイルをスキップ SKIP_FILE_n% n%を超える⾏がエラーのファイルをスキップ 

エラー内容の確認 23 ● スキップされたファイル‧⾏のエラーはSnowflake内に記録される ● エラーの詳細はVIEW、またはテーブル関数で確認することができる 確認⽅法 粒度 ACCOUNT_USAGE.COPY_HISTORY ファイル単位 status、⾏数、最初のエラーメッセージ ⾏単位 どの⾏のどのカラムがなぜ失敗したか VALIDATE関数 主な情報 

DMF（Data Metric Functions） 24 ● テーブルやビューに紐づけて、対象のデータの品質をチェックする機能 ● 基盤⼊⼝になるBRONZE層や、ユーザーに公開するGOLD層に使⽤する ● データ変更時やスケジュールで⾃動実⾏できる ● Snowflake上で完結し、Horizon Catalogで品質状態を可視化できる ● 基本的な品質検証はデフォルトで準備されている 種類 特徴 システムDMF ビルトインで約50種あり、すぐに利⽤可能 カスタムDMF 独⾃ロジックが必要な場合にSQLで定義 

システムDMFの例 ● 25 システムDMFには以下のようなものがある カテゴリ ● 関数例 正確性 NULL_COUNT, NULL_PERCENT, BLANK_COUNT ⼀意性 DUPLICATE_COUNT, UNIQUE_COUNT 鮮度 FRESHNESS ボリューム ROW_COUNT テーブルへの適⽤例 ALTER TABLE ORDERS ADD DATA METRIC FUNCTION SNOWFLAKE.CORE.DUPLICATE_COUNT ON (ORDER_ID); 

カスタムDMFの例 — 鮮度チェック ● 独⾃ロジックが必要な場合はカスタムDMFを作成する ● 以下は最新データからの経過⽇数を返す鮮度検証の関数の例 CREATE OR REPLACE DATA METRIC FUNCTION DM_FRESHNESS_DAYS( ARG_T TABLE(ORDER_DATE DATE) ) RETURNS NUMBER AS $$ SELECT DATEDIFF( DAY, MAX(ORDER_DATE), SNOWFLAKE.CORE.DATA_METRIC_SCHEDULED_TIME() ) FROM ARG_T $$; 26 

Expectation — 品質の合否判定 ● DMFの結果に閾値を設定し、PASS / FAILで合否判定する仕組み ● 結果はHorizon Catalogに連携されるため、品質状態が⼀⽬で分かる ALTER TABLE ORDERS ADD DATA METRIC FUNCTION SNOWFLAKE.CORE.DUPLICATE_COUNT ON (ORDER_ID) EXPECTATION dup_check (VALUE = 0); ALTER TABLE ORDERS ADD DATA METRIC FUNCTION SNOWFLAKE.CORE.NEGATIVE_COUNT ON (ORDER_AMOUNT) EXPECTATION neg_check (VALUE = 0); ALTER TABLE ORDERS ADD DATA METRIC FUNCTION SNOWFLAKE.CORE.FRESHNESS ON (ORDER_DATE) EXPECTATION freshness_check (VALUE <= 604800); 27 

Horizon Catalogで品質を確認 ● テーブル > Data Quality タブでDMFとExpectationの結果を確認できる 28 

Notification Integration ● Notification Integrationを使⽤して品質エラー時の通知を設定可能 ● Expectation違反や異常を検知した際に、⾃動的に通知が⾶ぶ CREATE NOTIFICATION INTEGRATION dq_notify TYPE = EMAIL ENABLED = TRUE ALLOWED_RECIPIENTS = ('[email protected]'); ALTER DATABASE DEVIO_2026_DEMO SET DATA_QUALITY_MONITORING_SETTINGS = $$ notification: enabled: TRUE integrations: [DQ_NOTIFY] $$; 29 

Alertによる柔軟な通知 ● Notification Integrationより柔軟な条件で通知したい場合はAlertを使う ● DMFの結果テーブルを直接SQLでクエリするため、複雑な条件も書ける CREATE OR REPLACE ALERT dq_duplicate_alert WAREHOUSE = DEVIO_2026_WH SCHEDULE = 'USING CRON 0 */6 * * * Asia/Tokyo' IF (EXISTS ( SELECT * FROM SNOWFLAKE.LOCAL.DATA_QUALITY_MONITORING_RESULTS WHERE METRIC_NAME ILIKE '%DUPLICATE_COUNT%' AND VALUE > 0 )) THEN CALL SYSTEM$SEND_EMAIL( ... ); 30 

異常検出（Anomaly Detection） ※プレビュー ● DMFの実⾏結果の履歴をもとに、Snowflakeが⾃動で異常を検出する ● 閾値を⼿動で設定する必要がなく、予測範囲から外れた値を⾃動判定 ● 結果はDATA_QUALITY_MONITORING_ANOMALY_DETECTION_STATUSに管理される 対応するシステムDMF 検出できる異常 ROW_COUNT データ量の急増‧急減 FRESHNESS 更新頻度の異常（更新停⽌など） 31 

異常検出（Anomaly Detection） ※プレビュー ● ROW_COUNTを新たに設定し、異常検知の感度を設定する ● 検知の感度はLOW / MEDIUM(デフォルト) / HIGHから選択する ● 偽陽性を防ぎたい場合はLOW、偽陰性を減らしたい場合はHIGHにする ALTER TABLE ORDERS ADD DATA METRIC FUNCTION SNOWFLAKE.CORE.ROW_COUNT ON () ANOMALY_DETECTION = TRUE; ALTER TABLE ORDERS MODIFY DATA METRIC FUNCTION SNOWFLAKE.CORE.ROW_COUNT ON () SET SENSITIVITY = 'HIGH'; 32 

異常検出（Anomaly Detection） ※プレビュー ● 検知した異常もカタログ上のデータ品質タブで確認できる 33 

Cortex Data Quality ※プレビュー ● テーブルのメタデータを分析し、AIが適切な品質チェック項⽬を推奨 ● どんなデータ品質チェックを⼊れるべきか迷うときなどに便利 34 

Cortex Data Quality ※プレビュー 35 

dbtとの使い分け 36 ● よくSnowflakeと併せて利⽤されるdbtもテスト機能は充実している ● ただdbtでテストするのは主に、変換パイプラインを実⾏したとき ● dbtで変換時の検知、DMFでGOLD層の品質可視化などの使い分けもできる Snowflake dbt ● 変換前のBRONZE層にDMFを定義 ● データ変換時の品質を検証 ● 結果をHorizon Catalogで可視化 ● 不合格時にパイプラインを⽌められる ● 異常検知などの品質管理機能も強化中 ● テストがコードとして管理される 

まとめ 37 

まとめ AIが分析する環境になってもデータ品質は最重要 ● AIによる分析ができても、その結果はデータ⾃体の品質に左右される ● Cortex Analystで正しいSQLを⽣成できても、データの正しさは保証しない Snowflakeにもデータ品質に向けた機能が揃ってきている ● 測定‧判定‧通知‧可視化をSnowflake内で⼀貫して実装できる ● 今後は異常検出機能、Cortex Data Qualityによる品質検査の提案も まずはデータ品質の問題を検知できる仕組みづくりから ● SnowflakeのDMFなら外部ツールを使わずにすぐに実装ができる ● データの⼊⼝、ユーザー公開しているテーブルから品質検査を始めよう 38 

ご清聴ありがとうございました 

No content