2025/9/11 株式会社テレシー：欧陽 江卉 クラスメソッド株式会社：相樂 悟 Snowflake×dbtを⽤いた テレシーのデータ基盤のこれまでとこれから 

⽬次 2 - はじめに - テレシーのデータ基盤のこれまでとこれから - パネルディスカッション 

はじめに 

⾃⼰紹介 4 2020年9⽉ ⼊社 - Modern Data Stackに該当する製品の 技術⽀援‧プリセールスを担当 - 新しい技術情報を定期的に収集し、 ブログで情報発信 - 名前（ニックネーム） - 相樂 悟 （さがら） - 部署‧役割 - Modern Data Stackチーム テックリード - Snowflake関連の表彰 - Snowflake Data Superhero 2022 - 2025 

エンジニアを必要とするすべての企業を応援する プロフェッショナル・エンジニア・カンパニー 経営理念 「オープンな発想と高い技術力により、すべての人々の創造活動に貢献し続ける」 5 クラスメソッド 会社紹介 

データ分析基盤に関わるソフトウェアの販売～導入支援を行うチーム 6 クラスメソッド Modern Data Stackチーム 

テレシー様との関係性 7 - dbt Cloudに関してお問い合わせを頂き、 dbt Cloudの製品ライセンス‧導⼊⽀援をご契約頂きました （弊社HPにて、事例も公開中です！） - 導⼊⽀援の概要 - Snowflakeおよびdbt Coreを活⽤したデータ基盤の現状ヒアリング - dbt Cloudの導⼊とベストプラクティスに基づいた開発プロセスの改善提案 - dbt Cloud環境設定⽀援 - その他、dbt Cloud‧Snowflakeに関する技術Q&A‧コンサルティング 次のスライドから、株式会社テレシー欧陽さんに 「テレシーのデータ基盤のこれまでとこれから」をお話頂きます！ 

テレシーのデータ基盤のこれまでとこれから 

⾃⼰紹介 9 - 職務経歴 新卒で株式会社CARTA HOLDINGSに入社し、インターネッ ト広告の配信ロジックに関する設計・開発・運用に従事。その 後、国内大手ECサービス事業会社へ転職し、2022年に CARTA HOLDINGSへ再入社。現在はグループ会社である 株式会社テレシーにて、データプランニングチームのチーム リーダーとして、社内のデータ分析基盤の構築・運用を担当し ている。あわせて、マーケティング施策を支えるためのデータ 設計・整備にも取り組んでいる。 - 名前（ニックネーム） - 欧陽 江卉（おーやん） - 部署‧役割 - データプランニングチーム チームリーダー 

運⽤型テレビCMを軸とした統合コミュニケーション施策の企画‧実⾏ 運⽤型テレビCMとは、地上波テレビCMをデジタル広告のように、 データを活⽤しながら継続的に改善を図る⼿法 このアプローチにより、テレビCMの費⽤対効果を分析し、 放映枠の最適化や効果の継続的な改善を実現することが可能になる テレシーについて 10 従来のテレビCM 運⽤型テレビCM 

テレシーデータ基盤の変遷 11 - 事業背景と当時のアーキテクチャ - 分析現場で直⾯した課題 2021年〜 Aurora単独時代 2022年〜 Snowflakeへの移⾏ 2024年〜 Snowflake+dbtの活⽤ 2025年〜 Snowflakeを中核とした データ基盤の進化 - dbt Cloudの採⽤による開発⽣産性向上 - リモデリングによるデータ可⽤性の向上 - データ分析基盤の選定(Snowflake含む2製品を⽐較) - Snowflake移⾏後のアーキテクチャ - 今後の展望 

Aurora単独時代：事業背景とアーキテクチャ 12 事業背景 「運⽤型テレビCM」を軸に事業を成⻑させるためには、テレビCMの放映効果の分析や、ダッ シュボードによる可視化が不可⽋。そこで、私たちは「テレシーアナリティクス」というプロ ダクトを開発し、クライアントへの提供を開始 アーキテクチャ テレシーアナリティクスの管理画⾯上で設定されたレポート情報（流⼊チャネルの指定など） に基づき、S3上のRAWデータに対してETL処理を実⾏し、処理結果をAuroraに挿⼊ Amazon S3 Amazon Aurora 顧客行動データ ※例：Google Analytics テレビCMデータ アーキテクチャ（⼀部抜粋） ETLバッチアプリ ※分析レポート単位で集約　さ れたデータが入ります 

Aurora単独時代：分析現場で直⾯した課題 13 課題背景 テレシーアナリティクスにおいては、プロダクトによる全⾃動の定常分析に加え、デー タサイエンティストによるアドホック分析を組み合わせることで、顧客ごとの課題や ニーズに応じた質の⾼いサービス提供の実現を⽬指す 従来の分析 コスト プロダクト 顧客 データサイエンティストの スペシャリストによる 役務提供 

Aurora単独時代：分析現場で直⾯した課題 14 データ基盤構造に起因する課題 1. レポートに依存した加⼯ロジックには限界があり、新たな分析軸や切り⼝を追加するたびに、 S3からのデータ抽出や加⼯作業がその都度必要になる 2. RDB内のデータを利⽤する場合、正規化により情報が複数のテーブルに分散されているため、 分析に必要なデータを取得するには毎回複雑なSQLを記述する必要がある 分析組織のパフォーマンス低下 データの取得や変換のやり直しに多くの⼯数がかかり、分析者が本来注⼒すべき顧客課題の解決に 向けたソリューション開発に⼗分な時間を確保することが困難になる まずは課題1を解決するために、トランザクションデータの⽣ログを容易に アクセスできるように、データ分析基盤の導⼊を検討し始めた 

Snowflakeへの移⾏：データ分析基盤の選定 15 データ分析基盤の選定にあたっては、Snowflake含む2製品を候補として選定し、 課題1の解決に関しては、いずれの選択肢でも対応可能と考えられますが、テレシーには専任 のデータエンジニアがいないため、「運⽤のしやすさ」を最も重視して検証を進めた 観点 Snowflake ⽐較したDWH クラスタ管理‧イ ンフラ設計 コンピュートは仮想ウェアハウス単位で管理 され、クラスタ構成の意識は不要。インフラ に依存せず、⾃動でスケール可能 ノード数やインスタンスタイプの選定が必要。スケールや 構成変更時にクラスタ再構築が伴う場合もある スケーリングの柔 軟性 コンピュートとストレージが完全に分離され ており、⽔平⽅向の⾃動スケーリングが可 能。⽤途に応じた仮想ウェアハウスの追加‧ 分離も柔軟 ノード単位のスケーリングが前提となるため、スケールア ウトには時間やダウンタイムを伴うことがある パフォーマンス チューニング クエリ最適化やリソース管理は⾃動化されて おり、DISTKEYやSORTKEYなどの物理設計 は不要 Workload Management（WLM）やDISTKEY/SORTKEYの 設計など、パフォーマンスを保つにはチューニングが必要 

Snowflake+dbtの活⽤：dbt Coreの導⼊ 16 Snowflakeの導⼊と同時に、dbt Coreの導⼊を実施した Amazon SageMaker ETL Amazon S3 DWH 顧客⾏動データ ※例：Google Analytics 視聴率データ アーキテクチャ（⼀部抜粋） 分析環境 Amazon Aurora 専任のデータエンジニアがいないチーム体制のため、dbt Coreを運⽤する際に苦労していた 

Snowflake+dbtの活⽤：dbt Coreにおける運⽤課題 17 dbt Coreにおける運⽤課題 ● 開発環境のセットアップ〜利⽤⽅法を理解することに時間がかかる ● makefileやGitHub Actionsを⽤いた⾃分たち独⾃のCIを開発‧運⽤していた ● 開発後の本番環境へのデプロイが⼿動であった 

Snowflake+dbtの活⽤：dbt Cloudの採⽤による開発⽣産性向上 18 dbt Cloudの標準機能を⽤いたCI/CDを組み込んだ開発〜デプロイを実現し、開発⽣産性が向上 dbt Cloudを⽤いた開発プロセス 1. dbt CloudのStudio(IDE)でブランチを切り、新しいModelを開発 a. Studio上でdbt buildを実⾏することで、 開発者専⽤のスキーマにテーブル＆ビューが作成される 2. 開発を終えたらコミット‧プッシュを⾏い、プルリクエストを発⾏ この際、dbt CloudのCIジョブが実⾏される（右図が設定画⾯） a. CIジョブの特徴：差分が確認されたファイルとその下流のModelだけをbuild対象にし、 CIジョブ専⽤のスキーマにテーブル＆ビューを作成しテストを⾏う 3. CIジョブの結果が問題なければ、mainブランチへマージ＆Mergeジョブ(CDの処理)を実⾏ 

Snowflake+dbtの活⽤：dbt Cloudの採⽤による開発⽣産性向上 19 dbt Cloud導⼊による開発⽣産性向上 ● dbt Coreを運⽤するときの悩みを解消し、dbtの開発に携わるメンバーも倍増 ○ 開発環境の構築‧dbt Coreの実⾏環境の保守が不要となった ○ dbt Cloud標準のCI/CD機能を⽤いて、別途開発することなくCI/CDを実現 +α クラスメソッドの⽀援を経て得られた効果 ● 開発環境‧検証（QA）環境‧本番環境のマルチ環境運⽤にすることで、 明確な環境分離ができるようになり、レビューの負荷も削減 ● Snowflakeのロール階層とdbt Cloudの実⾏ロールを整理し、 権限の強弱を考慮したうえで開発者と運⽤者のアクセス境界を明確化 

Snowflake+dbtの活⽤：リモデリングによるデータ可⽤性の向上 20 DS組織における課題のおさらい： 1. レポートに依存した加⼯ロジックには限界があり、新たな分析軸や切り⼝を追加するたび に、S3からのデータ抽出や加⼯作業がその都度必要になる →Snowflakeを導⼊することで、柔軟かつ⼿軽に分析を⾏える環境を実現 2. RDB内のデータを利⽤する場合、正規化により情報が複数のテーブルに分散されているた め、分析に必要なデータを取得するには毎回複雑なSQLを記述する必要がある →dbtを⽤いたリモデリングによって分析しやすい構造へ再設計 

Snowflake+dbtの活⽤：リモデリングによるデータ可⽤性の向上 21 ● 複数のテーブルから必要な情報を集約してテーブルを設計 ○ dbt-utilsのgenerate_surrogate_keyマクロを使ってユニークキーを付与し、 dbtのgenericテストでテーブル品質を担保 ● テーブルの定期ビルド ○ dbt tag機能を使って、該当テーブルのみ定期更新 ● dbtのconstraintsを⽤いてSnowflakeの制約を定義してテーブル間の依存関係を明⽰ 化し、SchemaSpyを⽤いたER図の⾃動⽣成が可能に ○ 右図：dbtを⽤いた制約の実装例  

Snowflake+dbtの活⽤：リモデリングによるデータ可⽤性の向上 22 同じ情報を表現するために必要なテーブル数を⼤幅に削減でき、シンプルな構造によって 利⽤の容易性が担保され、作業者のSQL作成コストも⼤幅に削減 AURORA ER図（102個） Snowflake MART層 ER図（30個） ※ER図の⽣成にはSchemaSpyを使⽤ 

Snowflake+dbtの活⽤：成果のまとめ 23 成果まとめ ● Snowflake+dbt Cloudの導⼊により、柔軟かつ⼿軽に分析を⾏える環境を実現 ● さらに、Snowflakeとdbtを活⽤してデータをリモデリングすることで、 分析しやすい構造へと再設計し、SQLクエリ作成の⼿間を⼤幅に削減 成果の定量評価 ● 従来、データサイエンティストが1案件あたり5~6時間かけて⾏っていた アドホック分析の前処理が、約1時間で対応可能に ● データサイエンティストの⼯数削減により、年間で1千万円以上のコスト削減に つながった 

これから：Snowflakeを中核としたデータ基盤の進化 24 サービス開発を⽀えるためのデータ基盤のフル活⽤ ● Scalability：データ量と種類の増加に耐えられる拡張性のある設計を推進 ● Availability：必要なときに正しいデータを確実に利⽤可能な状態を確保 ● Stability：データ品質やパフォーマンスを⻑期的に安定して運⽤ 「データを蓄積‧分析する基盤」から、「意思決定を⾃動で実⾏する仕組み」への進化 ● 業務ログや社内ビジネスプロセスに関わるデータを横断的に集約 ● セマンティックレイヤーを活かし、データドリブンな意思決定を⺠主化 

パネルディスカッション 

dbt Cloudで特に気に⼊っている機能は どの機能ですか？ Q： 相樂⇛欧陽さんへ 

Snowflake内でもdbtの開発が⾏えるdbt Projects がリリースされましたが、dbt Cloudが優れてい る点はどこにあるでしょうか？ Q： 欧陽⇛相樂さんへ 

Snowflake+dbt Cloudにより開発⽣産性は向上し たと思いますが、現在データ分析基盤を開発‧運 ⽤する中で⼤変なことは何でしょうか？ 加えて、どうやって乗り越えていますか？ Q： 相樂⇛欧陽さんへ 

Snowflakeがデータ分析基盤に必要な領域を広く 担えるようになってきていますが、他のSaaSを導 ⼊する際のポイントがあれば教えてください！ Q： 欧陽⇛相樂さんへ 

技術⽀援に関してクラスメソッドに対して期待し ていたことと、実際に⽀援を受けてのご感想を教 えてください！ Q： 相樂⇛欧陽さんへ 

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