秋が深まるころ、名古屋市郊外の部品メーカー・東海精工の情報システム部長、鈴木誠一は、サーバールームの蛍光灯の下で古い台帳を眺めていた。2007年に導入したオンプレミスの基幹系サーバーは、すでに延長サポートも終わり、スペアパーツの調達さえ困難になっていた。ライン稼働中にシステムを止めることは許されない。しかし、このまま放置することもできない。そのジレンマは、多くの製造業の現場が抱える静かな緊張感と重なる。Azureへの移行は「いつかやること」ではなく、今この瞬間に設計を始めなければならない問題として、彼の机に積み重なっていた。

なぜ「一気に移行」が失敗するのか

東海精工が最初に検討したのは、ゴールデンウィークの10連休を使った一括移行だった。しかしその計画は、システム構成を詳細に棚卸しした段階で静かに棚上げされた。基幹系と生産管理系が密結合しており、どちらか一方を切り離すだけで、受注データの整合性が崩れる構造になっていたからだ。一括移行は、移行作業そのものの技術的リスクよりも、「見えていない依存関係」が本番稼働後に顕在化するリスクの方が大きい。Azureへの移行を段階的に設計する最大の理由は、この依存関係の地図を、現場を動かしながら少しずつ描いていくためにある。停止時間をゼロに近づけるための設計とは、要するに「いつでも引き返せる退路を持ちながら前進する」という思想だ。

フェーズ1：棚卸しと共存設計 — 冬の準備期

11月、鈴木と担当エンジニアの林田が最初に着手したのは、既存システムの「現況図」を描くことだった。構成管理ツールとして Azure Migrate を使い、オンプレミス上の仮想マシン37台のCPU使用率、ネットワーク依存、ストレージI/Oを4週間にわたって計測した。重要なのは、このフェーズでクラウドに何も移さないことだ。ひたすら観察し、記録し、依存マップを育てる。東海精工では、生産管理システムと在庫DBが1日に約2万回のAPIコールを交わしていることが、このフェーズで初めて可視化された。移行後の設計はすべてこの数字から逆算される。共存設計とは、オンプレミスとAzureが同時に動く「ハイブリッド期間」のアーキテクチャを先に描くことを意味する。ExpressRouteの帯域試算もここで行う。

フェーズ2：周辺系から始める段階移行 — 春の実装期

3月の芽吹きと同じように、移行は周辺の小さなものから始まる。東海精工では、社内向けのファイルサーバーとメール補助システムを最初のターゲットに選んだ。これらは基幹系への依存が薄く、停止しても生産ラインに直接影響しない。Azure Files と Azure Blob Storage への移行は2週間で完了し、エンドユーザーからの問い合わせは3件だった。この「小さな成功」は、組織の移行疲労を防ぐ意味でも重要だ。次に着手したのは、読み取り専用のレポートサーバー群だ。Azure SQL Database へのリフト＆シフトを行い、オンプレミスのDBと1ヶ月間並行稼働させた。差分確認にはSQL Server Data Tools を使い、クエリ結果の一致率を日次で計測した。この並行稼働期間の長さを削らないことが、フェーズ2の核心にある。

フェーズ3：基幹系の切り替えと退路の設計 — 夏の決断

7月の第2週、東海精工は基幹系の切り替えを実行した。切り替えの瞬間は土曜日の深夜0時と決めた。ラインが止まる週末の最深部を選ぶことで、万が一の際のロールバック猶予を最大化する。Azure上に構築した新環境は、切り替え前日まで本番データのレプリケーションを受け続けており、SQL Server の Always On 可用性グループを活用してフェイルオーバー時間を90秒以内に抑えた。切り替え後72時間は、旧オンプレミス環境をスタンバイ状態で保持した。これが「退路」だ。問題が発生すればDNSを切り戻すだけで旧環境に戻れる設計にしておく。東海精工では結果として切り戻しは不要だったが、この退路の存在そのものが、現場の緊張を大きく和らげた。設計の良し悪しは、本番当日の判断の速さに現れる。

移行後の運用設計：Monitor と Cost Management の現実

移行が完了した後、最初の請求書が届いたとき、鈴木は一瞬眉をひそめた。Azure Cost Management を開くと、予算超過の原因はすぐに見えた。テスト用に残していた仮想マシンが11台、そのまま稼働し続けていた。移行直後の1ヶ月は、このような「残留リソース」の棚卸しが必要だ。東海精工では、Azure Policy を使ってタグ付けルールを強制し、環境ごとに予算アラートを設定することでコスト可視化を仕組み化した。また、Azure Monitor と Log Analytics を組み合わせて、基幹系の応答時間とエラーレートをダッシュボード化した。オンプレミス時代には「見えなかった」ものが、クラウド上では数値として浮かび上がる。この可視性こそが、移行後の最大の資産になる。

3フェーズ設計が持つ本当の意味

3フェーズという構造は、単なるスケジュール管理の話ではない。それは、組織がクラウドと向き合う「経験の積み方」を設計することだ。フェーズ1で現場は「自分たちのシステムを初めて正確に知る」。フェーズ2で「小さく動かして失敗の重さを学ぶ」。フェーズ3で「腹を決めて切り替える覚悟を持つ」。東海精工の林田エンジニアは、移行完了後のレビューでこう述べた。「一番学んだのは、技術より段取りでした」。Azureの機能は年々進化するが、現場を動かしながら変化を吸収していく設計の思想は、どのバージョンの技術環境でも変わらない。

名古屋の部品工場の蛍光灯は、今も変わらず夜遅くまでついている。ただ、その光の下で動くシステムは、もうあの古いサーバーラックではない。移行とは、技術の問題である前に、現場の時間と信頼を守る設計の問題だ。3フェーズという枠組みは、その信頼を損なわずに前へ進むための、静かな約束のようなものである。