この記事は10X 新春ブログリレー 2026の1月13日分の記事です。
はじめに
こんにちは。10Xでソフトウェアエンジニアをしていますjojo(@joj0hq)です。
2025年4月にチームが合併し、それまで触れてこなかった商品データパイプライン（ETL処理をdbtで実装）の開発に携わるようになりました。チーム合併の詳細については、EMのfutaboooさんが書かれた以下の記事をご覧ください。
新しい技術領域に触れる中で、バージョン管理の運用負荷という課題が明らかになってきました。本記事では、十数パートナーに対する共通パッケージのバージョンアップ作業を自動化し、開発効率を大幅に改善した取り組みを紹介します。
システム構成の概要
改善内容に入る前に、私たちのアーキテクチャについて簡単に説明します。
私たちは、共通パッケージ（data-express） と 実装プロジェクト（stailer-dbt） という2層構造でマルチテナント型のデータパイプラインを運用しています。
アーキテクチャ図
graph TB
subgraph "data-express (共通パッケージ)"
DE[dbtパッケージ<br/>共通モデル・マクロ提供]
style DE fill:#e1f5ff
end
subgraph "stailer-dbt (実装プロジェクト)"
direction TB
P1[パートナーA<br/>data-express v0.1.0使用]
P2[パートナーB<br/>data-express v0.2.0使用]
P3[パートナーC<br/>data-express v0.1.5使用]
style P1 fill:#fff4e6
style P2 fill:#fff4e6
style P3 fill:#fff4e6
end
DE -->|パッケージとして利用| P1
DE -->|パッケージとして利用| P2
DE -->|パッケージとして利用| P3
BQ[(BigQuery)]
P1 --> BQ
P2 --> BQ
P3 --> BQ
構成要素
- 共通パッケージ（data-express）: 複数パートナーで共通利用できる再利用可能なdbtパッケージ。データ変換ロジックや集計処理などのコアロジックを提供
- 実装プロジェクト（stailer-dbt）: 各パートナーの個別要件に対応する実装。共通パッケージを参照し、パートナー固有の処理を追加
- バージョン管理: 各パートナーは独立したバージョンの共通パッケージを利用可能。段階的なバージョンアップが実現
この構成により、共通ロジックの品質を保ちながら、各パートナーの要件にも柔軟に対応できています。
直面していた課題
共通パッケージの新バージョンがリリースされるたびに、以下のような手作業が発生していました。
- PR作成の手間: 十数パートナーに対して、都度バージョンアップ用のPRを手動で作成
- レビュー負担: パートナーごとにレビューと差分検証（developブランチとfeatureブランチのBigQueryテーブル比較）を実施。レビュワーの負担が大きい
- 差分確認の煩雑さ: 差分結果を都度Looker Studioのダッシュボードを確認しに行く必要があり、結果の把握に時間がかかる
- 通知の不足: データ作成の検証をするためのdbt Cloudでの処理完了や失敗を能動的に確認する必要がある
この運用負荷により、バージョンアップのたびにSprintのチケットを切り、計画的に作業時間を確保する状態になっていました。
改善への取り組み
上記の課題に対して、4つの観点から改善に取り組みました。
改善後のワークフロー全体像
graph TB
subgraph "改善後のワークフロー"
V[共通パッケージ<br/>新バージョンリリース]
subgraph Auto["自動フロー"]
RN[Renovate<br/>PR自動生成]
CR[Claude Code Review<br/>自動チェック]
DC[差分検証<br/>自動実行]
end
Manual[スラッシュコマンド<br/>/diffcheck]
subgraph Notification["通知"]
Comment[PRコメント通知<br/>完了/失敗通知]
Diff[差分結果表示<br/>差分の有無とサマリー]
end
V --> RN
RN --> CR
CR --> DC
DC --> Comment
DC --> Diff
Manual -.->|手動実行| DC
style V fill:#e3f2fd
style RN fill:#c8e6c9
style CR fill:#c8e6c9
style DC fill:#c8e6c9
style Manual fill:#fff9c4
style Comment fill:#c8e6c9
style Diff fill:#c8e6c9
end
Solution[✅ PR作成自動化<br/>✅ レビュー自動化<br/>✅ 差分確認自動化]
Notification -.-> Solution
style Solution fill:#e8f5e9
1. PR自動生成（Renovate導入）
課題
実装プロジェクトで適用する共通パッケージのバージョンを上げるために、パートナーごとにPRを手動で作成する必要がありました。十数パートナー分のPRを作成するのは非常に手間がかかります。
解決策
Renovateを導入し、共通パッケージのリリースと同じタイミングで各パートナー向けのPRを自動生成するようにしました。
実装詳細
- Renovateの設定ファイルで、共通パッケージの更新を監視
- 新しいタグがリリースされると、自動的にパートナーごとのPRを作成
- PRには変更内容のサマリーを自動で含める
効果
- PR作成作業がゼロに
- リリース直後に即座にPRが作成されるため、バージョンアップの遅延を防止
2. レビュー自動化（Claude Code Review × reviewdog導入）
課題
バージョンを上げるごとにパートナーごとのレビューが必要で、レビュワーの負担が大きくなっていました。
解決策
Claude Code Reviewとreviewdogを組み合わせて導入し、PR作成時に自動で基本的なチェックを実施するようにしました。
実装詳細
- GitHub ActionsでClaude Code Reviewを実行
- 共通パッケージの変更内容を解析し、パートナー固有の実装に影響がないかチェック
- reviewdogと連携することで、実装に紐づく細かいコメントをコードの該当行に直接投稿
- 問題があればPRにコメントで指摘
効果
- 基本的なチェックは自動化され、人間は最終確認のみに集中できるように
- reviewdogにより、コードの該当箇所に直接コメントが付くため、レビュー内容が分かりやすい
- レビュー時間の大幅な短縮
3. 差分検証の自動実行
課題
バージョンアップ前後でのデータ差分を確認する作業が手動で、毎回実行するのが大変でした。
差分検証とは: developブランチとfeatureブランチでそれぞれdbt runを実行し、生成されたBigQueryのテーブルを比較することで、機能開発や修正によるデグレ（品質劣化）を検出する取り組みです。この検証により、意図しないデータの変更を早期に発見できます。
graph TB
subgraph "差分検証の仕組み"
subgraph Branch1["developブランチ"]
D1[dbt Cloud<br/>dbt run実行]
D2[(BigQuery<br/>developスキーマ)]
D1 --> D2
style D1 fill:#e3f2fd
style D2 fill:#bbdefb
end
subgraph Branch2["featureブランチ"]
F1[dbt Cloud<br/>dbt run実行]
F2[(BigQuery<br/>featureスキーマ)]
F1 --> F2
style F1 fill:#fff3e0
style F2 fill:#ffe0b2
end
Comp[BigQuery<br/>テーブル・カラム比較]
D2 --> Comp
F2 --> Comp
Result{差分あり？}
Comp --> Result
Result -->|差分なし| OK[✅ デグレなし<br/>安全にマージ可能]
Result -->|差分あり| NG[⚠️ 差分を確認<br/>意図した変更か検証]
Visual[結果の可視化]
OK --> Visual
NG --> Visual
subgraph "確認方法"
V1[Looker Studio<br/>詳細ダッシュボード]
end
Visual --> V1
style Comp fill:#f3e5f5
style Result fill:#fff9c4
style OK fill:#c8e6c9
style NG fill:#ffccbc
style Visual fill:#e1bee7
style V1 fill:#c5cae9
end
この差分検証を自動化するため、以下の2つのアプローチを取りました。
解決策
差分検証を2つの方法で実行可能にしました：
- Renovateとの連携による完全自動実行: RenovateがPRを作成すると、自動的に差分検証が実行される
- スラッシュコマンドによる手動実行: 必要に応じて
/diffcheckコメントで差分検証を実行できる
実装詳細
- dbt Cloudのジョブを呼び出すGitHub Actionsを作成
- RenovateによるPR作成をトリガーに、自動で差分検証を実行
- 必要に応じて
/diffcheckコメントでも実行可能 - 検証結果をPRにコメントで返す
効果
- RenovateによるバージョンアップPRでは、完全自動で差分検証が実行される
- 手動での確認作業を大幅に削減
- 必要に応じてスラッシュコマンドで再実行も可能
4. 差分検証結果の通知と可視化
課題
差分検証の結果確認に関して、以下の問題がありました：
- 通知の不足: dbt Cloudで処理が実行されるため、処理の完了や失敗に気づきにくい
- 結果の確認が煩雑: Looker Studioのダッシュボードを見に行かないと差分の詳細が分からず、確認に時間がかかる
解決策
GitHub PRへのメンションコメント通知を導入し、差分検証の完了・失敗を自動的に通知するとともに、差分の詳細を可視化しました。
実装詳細
- dbt Cloudのジョブ完了/失敗をトリガーにGitHub Actionsを実行
- PRにメンションコメントで結果を通知
- PRコメントに差分サマリーを含める
- エラーの場合は詳細なログへのリンクも含める
効果
- dbt Cloudを能動的に確認する必要がなくなった
- 差分の有無とサマリーをPRコメント通知で即座に把握できるようになった
- Looker Studioに確認しに行かなくても、意図しない差分にすぐ気づけるようになった
改善の効果
Before / After比較
| 項目 | Before | After |
|---|---|---|
| PR作成 | 十数パートナー分を手動作成 | 完全自動化 |
| レビュー | パートナーごとに個別レビュー | 基本チェックは自動化 人間は最終確認のみ |
| 差分検証 | 手動で実行して結果確認 | Renovate PRでは自動実行 必要時はコマンド1つで実行可能 |
| 結果確認 | dbt Cloudで処理完了を確認 Looker Studioで差分を確認 |
PRコメント通知で即座に把握 |
得られた成果
- 作業時間の大幅削減: バージョンアップに伴う手作業がほぼゼロに
- リードタイムの短縮: リリースから適用までの期間を大幅に短縮
- レビュー負荷の軽減: レビュワーは本質的な確認に集中できるように
まとめ
本記事では、マルチテナント型dbtプロジェクトにおける共通パッケージのバージョンアップ運用を自動化した取り組みについて紹介しました。
一度にすべてを自動化するのではなく、課題を分解して1つずつ改善することで、着実に効果を得られました。Renovate、Claude Code Review、dbt Cloud、GitHub Actionsなど、既存ツールを組み合わせることで、短期間でバージョンアップ作業を大幅に削減することができました。
マルチテナント型のデータパイプライン運用において、同じような課題を抱えている方の参考になれば幸いです。
私たちのチームでは、このようなdbtを活用した開発効率改善のほか、dbtとAIエージェントを組み合わせたデータ調査など、AIを拡張した取り組みも行っています。
また、Podcastでチームの開発の裏側や働き方についても語っていますので、興味があればぜひご覧ください。
10Xはこの社会インフラとなるネットスーパーや、小売業のDXを通じて半径1mの人の生活を良くしていくために、仲間を募集しています。本記事のような開発効率を改善する取り組みに関心がある方は、ぜひカジュアル面談でお話ししましょう！
