M&Aで増え続ける企業を統合管理する、最強のAzureデータ基盤を作る
はじめに：M&Aによる北米市場での急成長
GENDAは「世界一のエンターテイメント企業」を目指し、積極的なM&A戦略を展開しています。特に北米市場では、2024年から2025年にかけて立て続けに大型M&Aを実施しました。
- National Entertainment Network（NEN）のグループイン - 米国で約8,000箇所のミニロケを運営する大手事業者
- Player One Amusement Groupのグループイン - ゲームセンター104店舗、ミニロケ約2,000箇所を展開
- Barberio Music Companyのグループイン - 高級ホテルやリゾート施設内にアミューズメント施設を展開
これらのM&Aにより、GENDAの北米におけるミニロケ拠点は13,000箇所以上に拡大しました。
しかし、短期間で大型M&Aを連続して実施することには課題が伴います。その1つが、データの統合です。グループインした各企業は、それぞれ異なるシステム、異なるデータソースを使って、似たようなKPIを分析しています。
経営統合を進めるためには、これらのバラバラなデータを統合し、同じダッシュボードから経営指標を確認できる状態を作る必要がありました。
私は現地法人に出張し、データ基盤の構築を担当することになりました。現地で確認した事項は以下の通りです。
- 各社が使用しているシステム
- データの保存場所と形式
- 現地メンバーのスキルセット
- 現地チームが抱えている課題
これらを踏まえ、現実的に運用できるシステムを設計しました。
現状の課題：既存システムの限界
現地で確認したところ、一部の企業ではAzure Synapseを使ったデータパイプラインが構築されていました。
この構成では、スケジュール設定、ログ確認、アラート設定がすべてSynapse上のGUIで管理されています。
この構成は個社での運用には十分機能していましたが、複数企業のデータを統合管理する観点では、以下の課題がありました。
| 課題 | 詳細 |
|---|---|
| 個社最適化 | 個社の業務フローに合わせて構築されており、統合後の全体で再利用するには設定の見直しが必要 |
| GUIベースの設定管理 | Azure Portalでの設定変更は履歴が残りにくく、誰がいつ何を変更したかの追跡が難しい |
| Notebookでのロジック管理 | データ変換ロジックがNotebook内に分散しており、コードレビューやテストの仕組みが整備されていない |
| デプロイ手順の属人化 | 本番環境への反映手順がドキュメント化されておらず、特定メンバーに依存している |
| 生成AIとの親和性 | GUIベースの操作はAIによるコード生成・レビュー支援を受けにくい |
これらの課題を解決し、複数企業のデータを統合的に管理できる基盤が必要でした。
ゴールと設計思想
ゴール
今回のプロジェクトで達成すべきゴールは、以下の2つです。
- データの信頼性を担保する - 経営判断の基盤となるデータは、正確で欠損がないことが絶対条件
- 現地メンバーでメンテナンスできる - 出張から帰った後も、現地チームだけで回せる構成
そして、これらの要件を最速で実現する必要がありました。M&Aによる成長スピードに合わせて、データ基盤も迅速に立ち上げなければ、経営判断に必要なデータが揃わないためです。
以下では、このゴールを実現するためにどのような設計・実装を行ったかを説明します。
設計思想
上記のゴールを達成するため、システム設計において以下の2つを重視しました。
1. 自動でデータの信頼性を保証する設計
人間が介入しなくてもデータの信頼性が保たれる仕組みを構築しました。
- 自動実行 - Timer Triggerによるスケジュール実行で手動操作を排除
- 自動リトライ - Dead Letter Queueによる一時的エラーからの自動復旧
- 整合性チェック - データ欠損の自動検知と通知
- 監視・アラート - 異常発生時のSlack通知で即座に対応可能
- Rolling Windowの適切な設定 - 過去数日分を毎日取得し直すことでデータ欠損を防止
2. 簡単にメンテナンス可能な構成
現地チームが自律的に運用でき、必要に応じて日本からもサポートできる構成にしました。
- 現地メンバーの既存スキルの最大活用 - 現地メンバーが慣れているAzureを採用
- 責務の分離とバージョン管理 - データ収集と変換を分離し、すべてGitで管理することで、安定稼働と高いメンテナンス性を両立
- リモートサポート可能な構成 - IaCとCI/CDにより日本からでも変更・デプロイが可能。日本の技術スタック（Databricks、dbt）に揃えることで、日本チームがいつでもサポートに入れる
この設計思想に基づき、以下のアーキテクチャを設計しました。
アーキテクチャ概要
全体設計
このアーキテクチャは、大きく分けて以下の4つのレイヤーで構成されています。
| レイヤー | 役割 | 主要コンポーネント |
|---|---|---|
| Data Sources | 外部データの取得元 | 各社基幹システム、外部API |
| Ingestion Layer | データの収集・検証 | Azure Functions (Durable Functions) |
| Storage Layer | データの永続化 | Data Lake Storage (ADLS Gen2) - Bronze Layer |
| Analytics Layer | データの変換・分析 | Azure Databricks (dbt) |
データの流れ
- 外部データソースから、Timer TriggerでスケジュールされたAzure Functionsがデータを取得
- Azure Functions (Durable Functions) がデータを検証し、Bronze層に保存
- エラーが発生した場合はDead Letter Queueに送信され、自動リトライ
- リトライ上限を超えた場合はLogic App経由でSlackに通知
- Bronze層のデータはDatabricksでdbtを使ってSilver/Gold層に変換
- 最終的にBIツールでダッシュボードとして可視化
Bronze層までを担保する：責務の分離
データレイクの設計において、Bronze / Silver / Goldの3層アーキテクチャを採用しました。
ただし、今回の基盤が担当するのはBronze層までです。
[External Sources] → [Azure Functions] → [Data Lake (Bronze)]
↓
[Databricks (Silver/Gold)]
↓
[BI Tools]
なぜBronze層だけなのか
- 責務の分離 - データ収集と変換を分けることで、安定した運用が可能になり、必要に応じて人員をスケールさせやすい
- 最速での基盤完成 - 分離することで互いの作業を待たずに開発を進められる
今回は最速で基盤を完成させるため、Silver/Gold層の実装は日本のデータチームに依頼しました。これにより、私は外部システムや外部APIの理解とBronze層への取り込みに集中でき、日本のデータチームはデータ整形ロジックの実装に集中できました。
技術選定
なぜAzureを選んだのか
クラウドプラットフォームとしてAzureを選択した理由は明確でした。
| 理由 | 詳細 |
|---|---|
| 基幹システムがAzure上にある | 既存のインフラとの親和性が高い |
| 現地メンバーがAzureに慣れている | 学習コストを最小化できる |
| Entra IDの活用 | 現地法人で発行しているIDをそのまま認証に使える |
「現地メンバーでメンテナンスできる」という設計思想に沿った選択です。
なぜDatabricksを選んだのか
Silver/Gold層およびBIツールとしてAzure Databricksを採用しました。
| 理由 | 詳細 |
|---|---|
| 国内データチームがすぐに参加できる | 既に使い慣れた技術スタックで、基盤実装のスピードが上がる |
| dbtによるバージョン管理 | SQLベースの変換ロジックをGitで管理できる |
| 現地メンバーの将来的な運用 | 現地メンバーはDatabricks自体は未経験だが、SQLは書けるため初期ハードルを超えれば運用可能 |
| サポート体制 | 問題があっても日本のデータチームがサポートしやすい |
現地メンバーはDatabricksの使用経験はなかったものの、SQLは書けるため、最初の学習ハードルを乗り越えれば将来的に現地だけでの運用も可能と判断し、今回は日本のデータチームが使い慣れた技術スタックを採用して最速で基盤を完成させることを優先しました。
具体的な実装
BicepによるInfrastructure as Code
「簡単にメンテナンス可能な構成」を実現するため、インフラ管理にはAzure Bicepを採用しました。これにより、Gitでのバージョン管理、コードレビュー、CI/CDパイプライン統合、生成AIによる開発支援が可能になります。
Azure Durable Functionsによる堅牢なデータパイプライン
「データの信頼性を担保する」ため、データ収集にはAzure Durable Functionsを採用しました。
通常のAzure Functionsでは、長時間実行されるワークフローや、複数ステップの処理を管理するのが困難です。Durable Functionsを使うことで、以下が実現できます。
- Fan-out/Fan-in パターン - 複数のデータソースを並列で取得し、結果を集約
- 自動リトライ - 一時的なエラーからの自動復旧
- 状態管理 - 処理の進捗を追跡可能
- 長時間実行 - タイムアウトを気にせず大量データを処理
Timer Triggerによるスケジュール実行
「データの信頼性を担保する」ため、すべてのデータ取得をスケジュール実行にしています。
毎日決まった時間に自動でデータ収集が実行されるため、手動での操作は不要です。
データを取得するだけでなく、事前に定義したスキーマやフォーマットを満たしているかの検証も実施しています。ファイルの存在確認と内容検証が両方成功して初めて完了とすることで、不正なデータがBronze層に混入することを防いでいます。
また、障害発生時のリカバリ用に手動実行用のHTTPエンドポイントも用意しています。過去日付を指定して再取得できるため、データ欠損が発生しても迅速に復旧できます。
Dead Letter Queue（DLQ）による自動リトライ
「データの信頼性を担保する」ため、エラー時の自動リカバリを実装しています。
外部システムとの連携では、一時的なエラーが避けられません。DLQを活用することで、以下のフローを実現しました。
- データ取得でエラー発生
- エラーデータをDLQに送信
- Queue Triggerが自動でリトライ
- 最大リトライ回数を超えたらPoison Queueへ移動
- Logic AppがSlackに通知
これにより、一時的なエラーは自動復旧し、本当に対応が必要な問題だけが通知されます。
Rolling Windowによるデータ欠損の自動回復
「データの信頼性を担保する」ため、毎日の取得対象を当日だけでなく過去数日分に設定しています。
DLQによるリトライは一時的なネットワークエラーには有効ですが、外部システム自体が長時間停止している場合はリトライしても結果は変わりません。Rolling Windowを設定することで、外部システムが復旧した翌日以降に自動的に欠損分を回復できます。追加の手動オペレーションなしでデータの完全性を維持できる仕組みです。
TerraformによるDatabricks権限とEntra ID連携
「現地メンバーでメンテナンスできる」を実現するため、Databricksの権限管理をTerraformでコード化し、Entra IDと連携させました。
なぜTerraformでコード管理するのか
今回の基盤では、インフラ（Azure Functions等）はBicep、Databricks権限はTerraformと、IaCツールが分かれています。一見デメリットに見えますが、以下の理由からこの構成を採用しました。
| 理由 | 詳細 |
|---|---|
| 数百人規模の権限設計が必要 | 現地法人メンバー全員に対して「見ていいデータ」と「見てはいけないデータ」を分ける必要があった。GUIでの管理は現実的ではなく、コードでの管理が必須 |
| Entra IDの活用 | 現地メンバーは全員Entra IDを持っていたため、既存のIDをそのまま認証・認可に活用できる |
| デプロイライフサイクルの違い | インフラは構築時に一度デプロイすれば安定。権限設定は組織変更に応じて継続的に更新が必要。分離することで変更影響を局所化できる |
| 生成AIとの親和性 | BicepもTerraformもコードベースのため、生成AIによる開発支援を受けやすい。ツールが分かれていても開発効率への影響は小さい |
まとめと今後の展望
ゴールの達成
本記事で紹介したアーキテクチャは、2つのゴールを以下のように実現しています。
| ゴール | 実現方法 |
|---|---|
| データの信頼性を担保する | Durable Functions、DLQ自動リトライ、整合性チェック、Slack通知、Timer Triggerによる自動化 |
| 現地メンバーでメンテナンスできる | Azure（既存スキル活用）、BicepによるIaC、SQLベースのデータ変換、日本チームとの連携体制 |
今後の展望
今回構築した基盤は、現在本番環境で稼働しています。
今後の課題は、この基盤を現地メンバーにハンズオフすることです。
- ドキュメント整備とナレッジトランスファー
- 障害対応手順の確立
- 新規データソース追加時の手順整備
- 定期的なレビューと改善
M&Aによる成長が続く中、新しくグループインした企業のデータを迅速に統合できる体制を整えていきます。
おまけ：Claudeを活用した並列開発
本プロジェクトの開発では、こちらの記事で紹介したClaudeを用いた並列開発を活用しました。
| 指標 | 数値 |
|---|---|
| 開発期間 | 約3人日（設計1日 + 実装2日） |
| 変更行数 | 約15,000行 |
| PR数 | 約130件 |
複数のBicepモジュールやFunction Appの実装を、Claudeエージェントを並列で動かすことで効率的に進めることができました。
コードベースでの管理（IaC）を選択したことで、生成AIとの相性が非常に良く、従来であれば数週間かかるようなデータ基盤の構築を、わずか3人日でスクラッチから本番稼働まで持っていくことができました。
Discussion