Enterprise Architecture
国内大規模エンタープライズ向け
次世代データ基盤設計
集約インフラ・分散ガバナンス アーキテクチャ
(5-Layer Pivoted Model)
日本国内に多数の拠点（店舗・工場）を持つ大規模企業を対象とした Databricksプラットフォームの標準設計仕様。 本社の「頭脳」と現場の「手足」を論理的に統合します。
Core Concept
設計の核心コンセプト
Centralized Brain (HQ)
全社データの統合、大規模機械学習、数理最適化、マスタ管理を一手に担う「頭脳」
Distributed Execution (拠点)
現場の状況（天気・イベント・人員）に基づく最終調整と実行を担う「手足」
集約インフラ・分散ガバナンス
物理インフラ（アカウント・メタストア）は統合し、データカタログと権限管理によって論理的に本社と拠点を分離
Domain-Driven Placement
ドメイン特性に基づき、最適な処理配置（集中型 vs 分散型）を決定
Physical Topology
インフラストラクチャ設計
管理コストの最小化とガバナンスの統一のため、物理リソースは集約します。
Databricks Account
全社で 1つ (Single Account Strategy)
Unity Catalog Metastore
全社で 1つ (Single Metastore Strategy)
リージョン
ap-northeast-1 (AWS Tokyo) または japaneast (Azure Japan East)
{domain}: core | sales | hr | finance | operations | logistics など
| 組織 | 拠点Code | 種別 | ワークスペース名 | 用途 |
|---|---|---|---|---|
| 本社 | hq | hub | prod-hq-hub-core-ws | 全社戦略・モデル開発・マスタ管理 |
| 関東支社 | kanto | analytics | prod-kanto-analytics-sales-ws | 関東営業エリアの運用・アプリホスト |
| 関西支社 | kansai | analytics | prod-kansai-analytics-sales-ws | 関西営業エリアの運用・アプリホスト |
| 本社営業分析 | hq | analytics | prod-hq-analytics-sales-ws | 全社営業戦略・分析専用 |
Logical Topology
データアーキテクチャ設計
5層構造をカタログレベルで物理的に分割し、本社と拠点の責任分界点を明確にします。
| Layer | 識別子 | 説明 |
|---|---|---|
| L1 | base | 基盤・生データ |
| L2 | kpiactual | 実績・事実データ |
| L3 | appcore | 予測・モデル・中間解析 |
| L4 | kpifusion | 予実統合・調整ワーク |
| L5 | appfront | アプリ/BI向け公開ビュー |
役割: Heavy Compute, Global Optimization
| レイヤー | カタログ名 (例) | データ内容 | アクセス権限 |
|---|---|---|---|
| L1 | prod_hq_base_gold | 全社商品マスタ、全社顧客マスタ (Golden Record) | DE: RW, Branch: Read |
| L2 | prod_hq_kpiactual_finance | 全社連結売上、財務実績 | Analyst: Read |
| L3 | prod_hq_appcore_forecast | 全店舗・全SKUの需要予測結果、LTV予測モデル | DS: RW |
| L4 | prod_hq_kpifusion_scm | 物流センター在庫配分計画、配送ルート計画 | SCM: RW |
| L5 | prod_hq_appfront_board | 経営コックピット (Tableau/PowerBI用) | Exec: Read |
Domain-Driven Placement
配置判断基準
「ハイブリッド」を排除し、処理の主体をHQかBranchのどちらかに二分します。
大規模データ処理
データ集約による精度向上、全社最適化の実現
例: 需要予測 - 全店舗データで季節性・地域性を学習
規模の経済効果
まとめて交渉による調達力向上、コスト削減の最大化
例: 発注最適化 - 全社一括発注で仕入れ価格交渉
複雑なアルゴリズム
高度な専門知識の集約、品質の統一
例: 機械学習モデル、最適化ソルバー
全社横断統合
一貫性とガバナンスの確保、重複排除によるコスト削減
例: 顧客統合、商品マスタ管理
リアルタイム要求
顧客体験の向上、機会損失の回避
例: POS処理、在庫照会
ローカル知識依存
現場判断・経験値が競争優位、地域特性の最大活用
例: 店舗レイアウト、地域イベント対応
個別カスタマイズ
地域ニーズへの最適適応、差別化戦略
例: 地域限定商品、店舗固有促進
軽量・高頻度処理
運用効率の向上、迅速な意思決定
例: 日次発注調整、シフト管理
Industry Use Cases
業界別ユースケース定義
10業界にわたる具体的なユースケースと、HQ/拠点の配置判断を定義しています。
| カテゴリ | ユースケース | 配置 | ワークスペース | カタログ | 処理概要 |
|---|---|---|---|---|---|
| 機械学習 | 全店需要予測 | HQ | prod-hq-analytics-sales-ws | prod_hq_appcore_demand | 全過去データ×気象予報で、翌週のSKU別需要をバッチ計算。 |
| 数理最適化 | 調達戦略最適化 | HQ | prod-hq-analytics-operations-ws | prod_hq_appfront_procurement | 交渉済み仕入条件と需要予測を統合し、総調達コスト最小化モデルで最適発注量を算出。 |
| 数理最適化 | 物流・配送計画 | HQ | prod-hq-analytics-logistics-ws | prod_hq_appcore_logistics | トラック積載率とルートを最適化。 |
| 機械学習 | パーソナライズドプロモーション | HQ | prod-hq-analytics-sales-ws | prod_hq_appcore_personalize | 顧客購買履歴と行動データで個別向けキャンペーンを自動生成。 |
| 数理最適化 | ダイナミックプライシング | HQ | prod-hq-analytics-sales-ws | prod_hq_appcore_pricing | 需要変動と競合価格を考慮し、時間帯別最適価格を算出。 |
| 数理最適化 | 値引/シフト作成 | 拠点 | prod-kanto-analytics-sales-ws | prod_kanto_appfront_pricing | 店長が鮮度や人員状況を見て最適価格を決定。 |
| ダッシュボード | 発注確定 | 拠点 | prod-kanto-analytics-sales-ws | prod_kanto_kpifusion_order | HQ推奨値に対し店長が補正を行い確定値を記録。 |
| ダッシュボード | 在庫回転率分析 | 拠点 | prod-kanto-analytics-sales-ws | prod_kanto_appfront_inventory | 店舗別在庫状況と売れ筋商品を可視化し、陳列改善を支援。 |
Data Flow Patterns
データフローパターン設計
本設計では、本社と拠点の関係性に応じて2つの基本データフローパターンを採用します。
パターン1: 完全独立型 (Isolated Pattern)
適用ケース: 製造業の工場OTデータ（設備保全・品質管理）
本社と工場（拠点）がレイヤーを共有せず、それぞれが独立したデータパイプラインを持つパターン。 完全に異なるドメインを扱う場合や、物理的に分離されたOTデータなどを扱う場合に適用します。
本社 (HQ)
- • 完全な5層構造 (L1-L5)
- • 独自のデータソース: 受注・ERP
- • ユースケース: 需要予測・S&OP
- • 工場とのデータ共有なし
工場 (Factory)
- • 完全な5層構造 (L1-L5)
- • 独自のデータソース: センサー・IoT
- • ユースケース: 設備保全・品質
- • 本社とのデータ共有なし
適用ケース
- • 完全に異なるドメインを扱う
- • データソースが重複しない
- • 独立した意思決定が必要
- • 処理特性が大きく異なる
パターン2: 依存関係型 (Shared Pattern)
適用ケース: 本社データを拠点が共有利用し、独自解析を構築
拠点が本社の基盤データ(L1)や実績データ(L2)を共有利用（参照）し、その上に独自の解析層(L3以降)を構築するパターン。 データの一貫性を保ちつつ、地域固有の調整を行う場合に適用します。
ケース1: 小売業の店舗発注（本社マスタ利用＋地域補正）
本社が算出する全店需要予測に対し、店舗側が地域イベントや天候（ローカル知識）を加味して補正を行い、 最終発注量を確定して本社へ同期するフロー。
本社 (HQ)
- • 完全な5層構造 (L1-L5)
- • データソース: 全社POS・ERP
- • ユースケース: 全店需要予測
- • L1, L2を拠点と共有
拠点 (Branch)
- • L3-L5の3層構造
- • データソース: 店舗POS+ローカル知識
- • ユースケース: 地域補正・発注
- • 本社のL1, L2を利用
結果統合
- • 本社が全店需要予測を提供
- • 店舗がローカル知識で補正
- • 発注確定を本社へ連携
- • 全社的な可視性を確保
ケース2: 製造業の生産計画（需要予測＋工場制約調整）
本社が予測した需要に対し、工場側が設備制約やシフト状況（OTデータ）を加味して調整要求を出し、 最終的な生産計画を確定・共有するフロー。
本社 (HQ)
- • 完全な5層構造 (L1-L5)
- • データソース: 全社ERP
- • ユースケース: 全社需要予測
- • L1, L2を工場と共有
工場 (Factory)
- • L3-L5の3層構造
- • データソース: 設備OT+シフト
- • ユースケース: 制約調整・生産計画
- • 本社のL1, L2を利用
結果統合
- • 本社が需要予測を提供
- • 工場が制約を加味し調整
- • 確定計画を本社へ連携
- • 全体最適と現場制約の融合
パターン選択指針
| 判断基準 | パターン1: 完全独立型 | パターン2: 依存関係型 |
|---|---|---|
| データ共有 | なし（完全分離） | L1/L2を共有利用 |
| ドメイン関係 | 完全に異なるドメイン | 関連するドメイン |
| 意思決定 | 独立した意思決定 | 協調的な意思決定 |
| 結果統合 | 不要 | 必要（本社へ連携） |
| 処理特性 | リアルタイム/エッジ処理 | バッチ/ハイブリッド処理 |
| 代表例 | 製造業OTデータ（設備保全） | 小売発注、製造生産計画 |
結論
本設計は、日本国内の大規模エンタープライズが持つ「強力な現場力（Human Insight）」と「データドリブンな中央戦略（AI Insight）」を 統合するための最適解である。
7.1 設計の革新ポイント
Domain-Driven Placement
ドメイン特性に基づく配置判断基準により、集中型・分散型の最適選択を体系化した。
2つのデータフローパターン
完全独立型 (Isolated Pattern): 物理的・論理的分離による独立運用型
依存関係型 (Shared Pattern): 本社資産活用と現場調整を融合するハイブリッド型
集約インフラ・分散ガバナンス アーキテクチャ
物理インフラ統合と論理分離により、ガバナンス効率と運用柔軟性を両立した。
業界横断適用性
10業界80ユースケースにより、多様な企業での実装可能性を実証した。
7.2 実現される価値
運用効率化
Single Account/Metastore戦略による管理コスト削減
意思決定高度化
中央計算と現場知識の最適融合
組織変革
データドリブンかつ現場力を活かす新しい組織モデル
スケーラビリティ
拠点数・データ量の拡張に対応する成長可能なアーキテクチャ
このアーキテクチャにより、「ガバナンスの効いた自律分散型データ組織」への変革が可能となり、日本企業特有の現場力を活かしたデータ活用の新たなスタンダードを確立する。