「クラウドファースト」と言うのは簡単だ。例えば経営が「ワークロードの大半をクラウドへ」と要請することもある。だが現実には、設計の意思決定が なぜか最後の最後で鈍化 する。オンプレDCが中心性を失わないまま、DC中心のハブ＆スポークの図だけが残り続ける。
このズレは、思想や気合いの問題ではない。クラウド移行は、サーバやNW機器を動かす“技術移行”ではなく、アプリ・データ・運用・統治に跨る依存関係をほどき、同時に動かす単位（waves / move groups）へ落とし込み、順序を取り戻す構造変換だからだ。実際、主要クラウドの移行ガイドは例外なく「依存を見て、移行候補をウェーブにグルーピングし、同時移行単位として計画せよ」と繰り返す。
この記事では、クラウド中心化／“DCを周辺化（spoke化） するという言葉が、なぜ現場で空転するのかを、グラフ理論 （DAG／強連結成分）と データのセマンティクス（真実＝SoT、整合性契約）の両輪で解きほぐす。結論を先に言えば、勝負は「図を描くこと」ではなく、依存の中心性と意味の中心性をどこへ移すかを決め切れるかにある。
この記事では便宜上 “on-prem data center as a spoke (DC as a Spoke)” と呼ぶ。
要は「クラウドをハブに据え、オンプレDCは接続される側（周辺）」という意味。
1. なぜ「DC as a Spoke」が“正しいはず”なのに止まるのか
クラウドファーストを掲げ、レジリエンス／セキュリティ／投資規模でクラウド優位を認めているにもかかわらず、DCが中心性を保ち続ける――この現象は「技術が難しい」より先に、 移行の対象がネットワーク図ではなく“依存構造”そのもの であることに起因する。
主要クラウドは移行計画の中核として、依存関係を把握し、同時に移せる単位にまとめてウェーブ（waves）を作れ と繰り返し述べる。
| CSP | 出典 | 要点 |
|---|---|---|
| Microsoft Azure | CAF | 大規模移行プロジェクトを、小さく管理可能なグループ（migration waves）に整理して実行することを推奨。反復的に計画し、各ウェーブから学びながら進める方法が示されている。 |
| Google Cloud | Migration Cneter | Discovery/Assessmentフェーズで収集した情報に基づき、移行候補を移行ウェーブにグループ化できる。グループ化はアプリ・場所・コンポーネント単位でも可能と説明されている。 |
| AWS | Migration Hub | Migration Hub の network visualization を用いて高忠実度な依存関係モデルを作成し、migration waves と move groups を特定する方法が示されている。移行波と移動グループは、検出された依存から導かれる計画単位として扱われる。 |
ここから導かれる要点は単純である。
移行の設計単位は“サーバ”ではなく、依存の塊（同時移行単位）である。
そして、その塊を同定・分割・順序付けする行為は、形式的にはグラフ問題である。
DC as a Spoke 議論が空転するのは、ネットワークの形を議論しているようで、実際は依存の 中心（中心性）と意味の中心（SoT）をどこへ移すか が未決のままだからである。
2. 形式化：依存関係グラフで「移行」をモデル化する
移行対象を、グラフ $𝐺 = (𝑉,𝐸)$ として扱う。
𝑉： ノード（アプリ／データストア／共通基盤／外部SaaS・委託先等）
𝐸： 有向辺（依存関係）
重要なのは、辺は「通信した」だけではないことだ。実務で移行を支配する依存は、少なくとも次を区別する必要がある。
- 可用性依存（落ちると落ちる）
- 遅延依存（レイテンシでSLOが破綻）
- 整合性依存（同一トランザクション境界／強整合の要請）
- 運用依存（鍵更新・監査・障害指揮が一体）
- 意味依存（同じ業務概念を共有し、定義不一致で業務が壊れる）
この区別がないと、ウェーブ計画は「都合の良い並べ替え」になり、後半で破綻する。各社の移行ガイダンスが移行計画で依存関係の把握を繰り返し要求するのは、まさにこの破綻を避けるためである。
3. “順序が付かない”という本質：強連結成分（SCC）が移行を止める
移行が詰まるとき、現場では「難しい」「複雑だ」と言う。しかし、形式的に見ると多くは 順序（ordering）が存在しないだけである。
依存がサイクルを持たない（DAG）なら、トポロジカル順序で段階移行できる。
サイクルがあると、順序が消える。サイクルを含む塊は 強連結成分（SCC） としてまとめて扱わざるを得ない。
つまり移行の最難所は、技術の難しさというより 「SCCをどう壊すか」 である。
強連結成分（SCC: Strongly Connected Component）
強連結成分（SCC）の説明
有向グラフにおいて、あるノード集合の中の任意の2点が相互に到達可能なとき、その集合を 強連結成分（SCC） という。
直感的には、一度入ると順番に切り離せない“循環依存の塊” である。重要なのは次の2点。
- SCC は一意に定まる： 依存関係グラフは、必ずSCCの集合に分解できる。解釈の余地はない。
- SCC を1ノードに縮約すると DAG になる： 循環はSCCの内部にしか存在せず、SCC同士の関係は必ず一方向（順序付け可能）になる。
このため、
- SCC は「順番に移せない最小単位」
- 移行や設計では、SCC単位で“同時に扱う”しかない
という実務的な結論が導かれる。
今回の文脈では、SCC ＝ migration wave / move group の核に相当する。
移行が止まるとき、それは技術が難しいのではなく、SCC を順序で解こうとしている場合がほとんどである。
数式（最小限）
以下は“移行可能性”を語るための最小の数式である。
G = (V, E), \quad E \subseteq V \times V
\text{If } G \text{ is a DAG, then } \exists \text{ a topological ordering }
\pi : V \to \{1, \dots, |V|\}.
\text{If } G \text{ has cycles, then }
V \text{ can be partitioned into SCCs } C_1, \dots, C_k.
\text{Contract SCCs: }
G' = \bigl(\{C_i\}, E'\bigr) \text{ is a DAG.}
実務的含意はこれで十分である。
- SCCが大きいほど 「同時移行」になり、停止・調整・調達・テストが指数的に重くなる。
- したがって勝ち筋は「SCCを崩すための境界設計」に移る。
4. セマンティクス：グラフを“切る”瞬間に、意味が暴走する
依存関係グラフは必要条件だが十分条件ではない。十分条件を壊すのが セマンティクス（意味） である。
セマンティクスとは、移行文脈では次を指す。
- 「このデータは業務上何を意味するか」
- 「どのデータが真実（source of truth）か」
- 「整合性の契約は何か（強整合／準リアルタイム／最終的整合）」
- 「移行中の二重化・同期・突合（reconciliation）はどう担保するか」
依存の辺を切る行為は、多くの場合「データ境界を切る行為」であり、その瞬間に 意味の一貫性 が支配的になる。
だから、移行は“サーバを動かす”よりも“意味を壊さずに境界を作る”仕事になる。
5. SCC破壊装置としての Strangler Fig：パターンはグラフ変形である
ここで、実務の定石が情報工学的に再解釈できる。
Strangler Fig パターンは、レガシーの前段に ファサード（proxy） を置き、リクエストを旧系／新系へ振り分けながら段階的に置換する。大規模・長時間軸のクラウド移行でよく言及されるアーキテクチャである。
このパターンの本質は「段階移行」一般論ではなく、グラフ変形（graph transformation） として次をやることにある。
- ファサードを新ノードとして挿入し、依存の向きを変える
- 旧→新の経路を徐々に増やし、サイクル（SCC）を壊す
- 最終的に旧ノード群を孤立させ、撤去可能にする
この理解に立つと、Strangler Figは“アーキテクチャ美学”ではなく、移行を止めるSCCを破壊するための、極めて実用的な操作になる。
6. 「DC as a Spoke」を依存関係グラフで言い換える
ここでようやく本題に戻る。
Hubとは「ネットワーク中心」ではなく「依存中心」である
Hub/Spokeをネットワーク図としてのみ定義すると、DC as a Spoke は単なる配線図の好みに落ちる。
しかし移行をグラフとして捉えると、Hubとは以下の複合体になる。
- 経路制御の中心（connectivity）
- 検査・強制の中心（security enforcement）
- 観測・証跡の中心（logging / audit）
- 身元・鍵の中心（identity / keys）
- 真実・整合の中心（SoT / consistency）
このうちどれかがDCに残れば、図の上でDCがSpokeでも、依存中心はDCに残る。すると「クラウドファースト宣言」と「DC中心性」が矛盾せず共存する（＝議論が終わらない）。
命題に見える条件
DC as a Spoke が「避けて通れない命題」に見えるのは、以下が同時に成立するとき。
- 依存中心（制御面・運用面）をクラウドに寄せると決めている
- セマンティクス（SoT・整合性契約）を境界単位で定義できている
- SCCを壊す境界操作（Strangler等）が計画されている
逆に言えば、これらが欠けると「命題」ではなく「スローガン」になる。
したがって、問題は“ネットワークの正しさ”より グラフ（依存）と意味（セマンティクス）と統治（責任境界）の同時設計 にある。
7. 実務に落とす：三層依存モデル（Runtime / Data / Semantic+Governance）
ここまでを“現場で使える最小モデル”に落としこむ。
層1：Runtime依存（観測可能）
- 通信フロー、API呼び出し、ジョブ連鎖、接続先
- Migration Hub network visualizationのような可視化で高忠実度化し、waves / move groups を組む、というのがAWSの推奨である。
層2：Data / Consistency依存（設計が必要）
- 整合性の契約、同期方式、移行中の二重化
- “辺”ではなく“重み”として扱う（許容遅延、RPO/RTO、突合難度など）
層3：Semantic / Governance依存（決めないと進まない）
- SoT（真実）宣言、データ定義、監査、障害時指揮、例外承認
- CAFやGoogleがウェーブ計画を中核に置くのは、結局ここを暗に要求しているからである。
この三層が揃ったとき、初めて「DCをSpokeに落とす」は“図”ではなく“実行計画”になる。
8. 依存関係グラフとSCC、そして境界挿入
以下は、典型的な「順序が付かない（SCC）」と、ファサード挿入でサイクルを壊す直観図である。
上段のA–B–Cは強連結（サイクル）で、単純な順序移行ができない。
ここにファサードFを入れ、依存の向き・経路を設計し直すことで、段階的に旧系を“孤立化”させる。
9. 結論：移行は「制約付きグラフ変形」であり、技術単体では解けない
最終的に、この問題は次の形で表現できる。
- 現状：依存関係グラフ 𝐺（サイクルを含む）
- 目標：クラウド中心の依存構造 𝐺′
- 移行：停止・監査・セキュリティ・整合性という制約の下で、𝐺 → 𝐺′ を段階的に変形する
そして、DC as a Spoke を実現するとは、ネットワークの見た目を変えることではない。依存中心・意味中心・統治中心をクラウド側へ移し、SCCを壊して順序を取り戻すこと である。
主要クラウドが「依存関係の把握」「ウェーブ計画」「move group」「段階移行パターン」を中核に据えるのは、この本質を（直接“グラフ理論”とは言わずとも）実務手順として体現しているからである。
終わりに
クラウド移行が進まない理由を、技術力や覚悟の不足に帰すのは簡単だ。しかし実際には、問題はもっと構造的である。
依存関係グラフに循環（SCC）が存在する限り、移行に“正しい順序”は定義できない。これは意志の問題ではなく、数学的な制約だ。
「DC as a Spoke」という言い方が示しているのも、単なるネットワーク構成ではない。中心に置くべきなのは配線ではなく、依存の起点と統治の適用点 である。そこが動かない限り、図だけがHub & Spokeになっても、実態は変わらない。
ファサード（Strangler）は魔法ではないが、入口を固定し、循環を主経路から外すことで、はじめて順序を取り戻せる。
移行の成否を分けるのは、「何を先に移すか」ではなく、どこに順序を与えられるか を見極められるかどうかだ。
クラウドファーストとは、技術選択のスローガンではない。
依存関係を読み解き、切れない塊を受け入れ、切れる境界を設計する――その地味な作業をやり切ることに他ならない。