クラウド移行費用を計算するとき、サーバー料金以外に含めるべきもの

TCO計算ツールが示すのは定常状態です

クラウド移行の見積もりで月額のVM・Database・Storage料金だけを比較すると、一つの質問には答えられます。移行が終わった後、移行先環境を運用するのに毎月いくらかかるか、という質問です。しかしそれだけでは次の質問に答えられません。現在の環境を実際に止めて移行先環境へ切り替えるのに、総額いくら必要か、という質問です。

クラウド移行の総費用は、移行先環境の定常運用費に、調査・設計・Refactoring・データ移動・Dual Run・検証・Downtimeリスク・教育・既存契約の残存費用・Rollback・安定化の費用を加えた値です。計算式で表すと次のようになります。Migration TCO(H) = 移行先環境の反復費用(H) + 移行元環境の残存費用 + 一回性の移行費用 + 一時的な重複費用 + リスク調整費用。Hは12か月、36か月のように比較に用いる同一の評価期間です。現在の環境を維持する場合と移行する場合は、いずれも同じ期間・同じサービス水準で比較しなければなりません。

Cloud Providerが提供するTCOツールは、現在の資産を発見し、移行先環境の適正サイズと想定運用費を計算する出発点として有用です。Google Cloud Migration Centerも資産グループのMemory・Storage使用量と移行先製品をもとに費用を比較し、^[13] Azure Migrateは現在の環境とAzureの費用を明示的にTCO (steady state)として区分しています。^[9]

問題は、実際の移行プロセスが定常状態ではないことです。移行期間中は移行元環境と移行先環境が同時に存在し、データを何度もコピーし、新しいセキュリティ・監視・デプロイ体制を構築します。Cutoverに失敗すれば元の環境に戻れなければならず、成功した後も一定期間はMigration Teamが運用チームを支援する必要があります。

AWSの詳細なBusiness Caseガイドも、移行先Cloudの運用費のほかに、Migration・Modernization、資産の廃止と契約の早期終了、既存環境と移行先環境のParallel Run費用を別途計算するよう案内しています。^[7] したがってTCO計算ツールは移行先環境の定常運用費の根拠として使い、実際の移行予算は別途の移行費用台帳で補うほうが安全です。

費用は四つの性格に分けます

同じ費用でも、いつ発生し、いつ終わるかによって判断が変わります。一つの項目が複数の分類にまたがることもあります。たとえばMonitoringでは、新環境のDashboardとAlertを作る費用はOne-timeですが、Logの収集と保管料はRecurringです。Rollback Runbookを作成して試験する作業はOne-timeですが、実際にRollbackが発生したときの追加人員・再同期・事業中断はRisk-adjustedの費用です。

FinOps Foundationも、Workload Placementの費用入力をInfrastructure Costに限定せず、Support・Run、Modernization・Implementation・Migration Costまで含め、Parallel Run・Phased Rollout・DecommissioningのようなTransition Stateの期間と費用を別途管理するよう定義しています。^[6]

Migration TCOに含めるべき16の費用領域

下の表は、AWS・Microsoft・Googleの公式Migration Guidanceに分散している活動を、一つの費用台帳として再構成したものです。^[7][10][14] 各領域は後のWorksheetに1行ずつ再び登場します。

Discoveryはサーバー一覧で終わりません

サーバーとDatabaseの一覧だけでは、どの順序で移すべきかは分かりません。一つのApplicationが中央認証、内部DNS、File Share、外部API、Batch Jobや特定のLicense Serverに依存していることがあるためです。

GoogleのAssessment Guidanceも、Workload InventoryをApplicationに限定せず、Database、Message Broker、Configuration Store、Source Repository、CI/CD、Artifact Repository、Runtime、さらに物理的なNetwork・Security Applianceまで含めています。また、Inventoryの作成そのものが、自動化されたCatalogがなければないほど相当な労力を要する作業であると説明しています。^[14]

Assessment費用は次の式で推定できます。Assessment Cost = 自動Discovery Tool費用 + 担当者Interview時間 + Dependency検証時間 + 現在の費用・契約資料の整理 + POC・Benchmark費用。現在の環境をよく把握できていないほど、Assessmentを省略するのではなく、不確実性の範囲をより大きく取るべきです。

Architecture ChangeとRefactoringは同じ項目ではありません

Architecture Changeは移行先環境の運用構造を変える作業です。Network、IAM、Account構成、デプロイPipeline、Monitoring、Secret管理、高可用性構成などがここに含まれます。RefactoringはApplication自体を修正する作業です。Runtimeの互換性、Local Fileへの依存、Session、Authentication、Databaseの機能、外部連携やデプロイ方式が変わるときに発生します。

二つの項目を一つにまとめると、インフラ設計は完了したのにApplicationの修正が終わっていない状態や、逆にCodeの移行は終わったのに運用基盤が準備できていない状態を見落としやすくなります。AWSも、Replatform・Repurchase・Refactorの対象についてはWorkloadごとにMigration・Modernization費用をより詳細に算定するよう区分しています。^[7]

Data TransferとData Synchronizationも分けます

Data Transferは現在のデータを移行先環境へ一度移す作業です。Data Synchronizationは、コピーが進行している間に移行元で新たに生成・変更されたデータを継続的に追従させる作業です。

大容量データの移動では、Network Egressだけでなく、移行元StorageのRead Operation、追加回線とBandwidth、Transfer ToolまたはAppliance、一時的なStaging Storageの費用が発生することがあります。転送の人員と承認手続き、失敗したファイルの再試行、ChecksumとData Integrityの検証も費用です。

Googleの公式ガイドは、データ転送にはNetwork、Storage Operation、Transfer Product、人員の費用が含まれ、計画とテストに転送そのものと同じくらいの時間が必要になることもあると説明しています。また、初回コピー後にData Integrationの問題を解決して検証し、移行元がFallbackとして不要になった時点で廃止する順序を示しています。^[15]

したがってデータ費用は最低限、次のように分けます。Data Migration Cost = Initial Bulk Transfer + Incremental Synchronization + Validation + Failed Transfer Retry + Rollback Re-synchronization Risk。

Dual Run期間は日付で計算します

Dual Runは単にサーバーを2セット稼働させる費用ではありません。移行元と移行先環境のCompute・Database・Storageだけでなく、両側のMonitoring、Security、License、Support、Network接続と運用人員が同時に維持されることがあります。

Microsoftの現行のMigration Plan例は、Cutover方式をBig Bang、Phased、Blue-greenに区分しています。^[11] Blue-greenは二つの環境を並行して維持するため費用影響は大きいものの、DowntimeとRollbackのリスクを下げることができ、Big Bangは直接費用は低いもののDowntimeとRollbackの難度が高くなります。これは特定の方式を常に選べという意味ではなく、Cutover方式そのものが費用とリスクの間の選択であることを示しています。

Dual Run費用は次のように期間に結び付けます。Dual Run Cost = (移行元環境の月次残存費用 + 重複するLicense・Monitoring・Support + 環境間のNetwork・Synchronization + 追加の運用人員) × 実際の重複か月数。ここで最も重要な入力はCutover予定日ではなく、移行元環境のDecommission承認日です。Cutover後に検証が終わらず移行元を維持し続ければ、Dual Runも続きます。

総額より先に月次キャッシュフローを描きます

移行費用を1行の総額としてのみ記録すると、費用がいつ重なるかが見えません。段階ごとにどの費用が重なるかは下の表のとおりです。

Azure MigrateのFuture-state Cash Flowも、すべてのサーバーが一度に消えると仮定せず、年ごとのMigration比率に応じて残っている現在の環境の費用とAzureの費用を併せて計算します。^[9] AWSも、Cloud費用のRamp-upを移行元環境のRamp-downより先に開始し、テストとDecommissioningの時間を確保する構造をBusiness Caseに反映しています。^[7]

Workloadが複数ある場合は、会社全体を一つの移行日で計算せず、Waveごとに日付を置きます。Target Build Start、Replication Start、Cutover Date、Acceptance Date、Rollback Window End、Hypercare End、Source Decommission Date、Contract End Dateの八つの日付です。^[8]

現金費用・会計費用・機会費用を混ぜません

Migration TCOには性格の異なる財務項目が入ってきます。たとえば既存サーバーの帳簿価額を全額損失として処理しながら、同じ金額を再び契約解除の現金費用として加えると、二重計算になることがあります。

社内の正社員も同様です。給与は移行の有無にかかわらず支払われますが、Migrationに投入した時間の分だけ他の開発が遅れることがあります。この場合、会計上の増分現金支出と意思決定上の機会費用を分けて報告するほうが正確です。

Cash Cost

CSP Invoice、Consultant、Tool License、Egress、追加回線、時間外勤務のように実際に支出される費用です。実際の支出時点で反映します。

Accounting Cost

まだ残っている機器の帳簿価額の償却や廃棄損のように、現金流出のない費用です。現金流出と区別して別途表示します。

Opportunity Cost

既存の開発者がMigrationのためにProduct Roadmapを先送りする時間です。すでに人件費をCash Costに入れている場合は二重に計算しません。

DowntimeとRollbackは予備費率で代替しません

リスク費用は「予算全体の何パーセント」のように一律に適用するより、リスク事象ごとに計算します。Risk-adjusted Cost = 発生確率 × 発生時の財務影響。

たとえばCutoverの時間超過、データ整合性エラー、性能基準の未達、Application Dependencyの漏れ、DNS・Routingエラー、Rollback後のデータ統合、Hypercare期間の延長、移行元契約の解除遅延を別項目として置きます。各リスクにはLow・Base・Highの影響値、発生確率、緩和策と責任者を記録します。

ただし、期待費用が小さいからといって高い衝撃のリスクを許容してよいわけではありません。許容できる中断時間やデータ損失を超える事象は、平均費用に薄めるのではなく、別途の設計・承認条件として残すべきです。^[5] Googleは、Migration Planの各段階ごとにRollback戦略を作成して実際に動作するか検証し、段階ごとの最大実行時間を過ぎたらRollbackを開始する条件を定めるよう推奨しています。^[14]

Cutoverが終わっても移行プロジェクトは終わりません

DNSが移行先環境を指し、ユーザーが接続できるようになったからといって、すぐにMigration Teamを解散してはいけません。AWSのWave Planningは、Cutover後にMigration Teamが運用チームを支援し最適化を行うHypercare段階を別途置いています。運用チームがWorkloadを引き受け、Cutoverの問題を解決してからWaveを終了します。^[8]

安定化期間には、性能ボトルネックとConfigurationの修正、漏れていたAlert・Dashboardの補完、Log VolumeとCloud Costの調整、権限・セキュリティポリシーの補正の費用が残ることがあります。ユーザーからの問い合わせとデータ精算、運用Runbookの更新、On-callとSupportの拡大、移行元環境の廃止承認、残った一時リソースとLicenseの整理も、この期間の費用です。

Googleも移行後のOptimizationを反復作業として説明し、最適化にはResource・Time・Effort・Skillという費用がかかると明記しています。^[16] Post-migration Stabilizationは、移行後いつか行う一般的なコスト最適化と区別し、Migration Project自体のTemporary Costとして予算化するほうがよいでしょう。

Migration TCO Worksheet

下のWorksheetは、WorkloadまたはMigration Waveごとに1行ずつ複製して使います。各行にはLow・Base・Highの金額と発生時点・期間、OwnerとEvidenceの欄を置きます。

使用原則は六つです。評価期間Hを先に決めます。費用は発生月と終了月を併せて記録します。確定費用と不確実な費用を同じ値に混ぜません。社内人員は現金費用と機会費用のどちらの基準で計算したかを表示します。すべての金額に見積書・契約書・使用量・作業時間などのEvidenceとOwnerを結び付けます。Low・Base・Highのいずれかを隠してBase値だけを報告することはしません。

分類別の合計と最終計算式

Worksheetの行を埋めたら、分類別に合算します。合計項目は次の九つです。

最終計算式は3行です。Committed Migration Cash Cost = One-time + Temporary + Recurring(H) + Retained Source + Non-cancellable Contract Remainder。Risk-adjusted Expected Cost = Σ(各リスクの発生確率 × 発生時の財務影響)。Migration TCO = Committed Migration Cash Cost + Risk-adjusted Expected Cost。

Accounting ImpactとOpportunity Costは意思決定資料には併せて表示しますが、Cash TCOと一つの数字に合算するときは重複がないか確認しなければなりません。

One-time subtotal

確定した一回性費用の合計です。

Temporary subtotal

移行期間中のみ発生する増分費用の合計です。

Recurring subtotal

移行先環境の反復費用 × 評価期間Hです。

Retained source subtotal

移行元環境のCutover以降の残存費用です。

Risk-adjusted subtotal

各リスクの発生確率 × 発生時の影響の合計です。

Migration TCO — Cash basis

上記の現金費用の合計です。

Accounting impact

資産の償却・廃棄など非現金の費用です。別途報告します。

Opportunity cost

社内人員の転用とRoadmapの遅延です。別途報告します。

Current-state baseline(H)

移行しない場合に同じ期間にかかる費用です。比較用に置きます。

一つの数字より三つのシナリオのほうが優れています

Migration TCOは、単一の正解よりLow・Base・Highの三つのシナリオで見るほうが実用的です。AWSも詳細なBusiness Caseにおいて、最小限の変化、最も可能性の高いケース、重要な前提が変わるケースを別々のシナリオとしてモデル化するよう案内しています。^[7]

各シナリオで特に敏感な入力は、RefactoringのPerson-day、データ量とChange Rate、Dual Runのか月数、移行元環境のDecommission日付です。Hypercare期間、既存契約の終了日、許容できるDowntime、Rollbackの発生可能性と影響も結果を大きく動かします。これらの値が変わったときにTCOがどれだけ変わるかを見ることが、単一サーバーの価格を小数点単位で比較することより重要である場合が多いのです。

Low / 円滑な移行

計画した期間内に移行が完了し、Dual Runが短く、追加のRefactoringがない場合です。

Base / 最も可能性の高い移行

想定された欠陥修正と安定化、承認済みのBufferを含む場合です。

High / 不利な移行

Dual Runの延長、追加のRefactoring、再転送または一部のRollbackが発生した場合です。

移行予算を承認する前に確認する質問

次の質問に答えられないなら、そのTCOはまだ移行先環境の見積もりに近いものです。どのWorkloadとDependencyが移行範囲に含まれているか。WorkloadごとにRehost・Replatform・Refactorの範囲が決まっているか。初回のData Transferと継続的なData Synchronizationを分けているか。移行元と移行先環境が重なる開始日と終了日があるか。機能・性能・セキュリティ・業務の受け入れ条件が文書化されているか。

続いて五つを追加で問います。CutoverとRollback Triggerの決定権者が決まっているか。移行元環境のDecommission条件と契約終了日が結び付いているか。運用チームの教育とMonitoring・Securityの引き継ぎが予算に含まれているか。Hypercareの終了条件があるか。Low・Base・Highシナリオと各入力のEvidenceがあるか。

クラウド移行の経済性は、最も安いサーバー見積もりを探す問題とは異なります。移行先環境の月額費用が低くても、Refactoring、契約の残存期間、長いDual Runと安定化の費用が大きければ、移行時点の現金負担は大きくなり得ます。逆に一回性の移行費がより多くかかっても、運用の複雑さや事業中断リスクを減らす設計が合理的である場合もあります。

結論はVendor名や割引率ではなく、次の順序で下すべきです。Workloadと制約 → 目標運用モデル → 移行戦略 → 月次の移行キャッシュフロー → リスクとRollback → 同一期間のTCO比較。Migration TCO Worksheetの役割は、クラウド移行が常に費用を削減すると証明することではありません。どの費用とリスクを引き受け、いつ既存環境を終わらせられるかを、意思決定者が確認できるようにすることです。