モダナイゼーションとは、既存のアプリケーション、インフラ、開発運用プロセスを更新し、事業や運用上の成果を改善していく取り組みです。 サーバーの老朽化、サポート切れ、有識者の退職、新機能の追加に時間がかかりすぎるといった問題が重なると、経営の議題に上がります。 このとき最初に出てくる案は、たいてい「とりあえずクラウドに移す」か「いっそ作り直す」のどちらかです。 しかし、クラウドへ移すか、アーキテクチャを変えるか、既製品へ置き換えるかは別々に検討できます。
「クラウドに移すこと」と同義ではない
クラウド移行は、ワークロードを移行元の環境からクラウドへ移す取り組みです。 一方、モダナイゼーションは、アーキテクチャや運用モデル、ソフトウェアの提供プロセスまで対象にします（AWS「Phased approach to modernizing applications in the AWS Cloud」）。
両者の範囲は重なりますが、一致はしません。 たとえば、リプラットフォームやリファクタリングを伴う移行は、移行とモダナイゼーションを同時に進めます。 これに対して、アプリケーションを変更せずにクラウドへ移すリホストだけでは、アプリケーションの構造やリリース手順まで改善されるとは限りません。 逆に、オンプレミスのまま監視、テスト、デプロイを自動化する取り組みもモダナイゼーションに含められます。
したがって、以下の7Rはモダナイゼーション全般を漏れなく分類するものではありません。 AWS Cloudへの移行を検討するときに、アプリケーションごとの扱いを決めるための分類です。
AWSが定義する7つの移行戦略
AWS Prescriptive Guidanceは、ワークロードをAWS Cloudへ移行するアプローチを7つの移行戦略（7R）として整理しています。 RetireとRetainを含むため、移行対象のポートフォリオから「移さないもの」も選別できます。
| 戦略 | AWSにおける定義 | 候補になりやすい条件 |
|---|---|---|
| Retire（廃止） | アプリケーションを廃止またはアーカイブする | 利用実態や保持する事業価値がなく、依存先を解消できる |
| Retain（保持） | ソース環境に残すか、移行できる状態になるまで延期する | データ所在地の要件、特殊なハードウェア、未解消の依存関係がある |
| Rehost（リホスト） | アプリケーションを変更せず、ソース環境からAWS Cloudへ移す | データセンターの退去期限が迫り、まず移行を完了させたい |
| Relocate（リロケート） | 多数のサーバーをクラウド版の同一プラットフォームへ移すか、AWSリソースを別のVPC、リージョン、アカウントへ移す | アプリケーションや既存の運用を変更せず、対応するプラットフォーム上でまとめて移したい |
| Repurchase（再購入） | アプリケーションを別のバージョンまたは別製品へ置き換える | 要件を満たすSaaSやベンダー製品があり、自社実装を維持する理由が弱い |
| Replatform（リプラットフォーム） | クラウドへ移しつつ、効率、コスト、クラウド機能の活用に必要な最適化を加える | データベースをマネージドサービスへ移すなど、移行に合わせて運用負荷を下げたい |
| Refactor / Re-architect（リファクタリングまたは再設計） | クラウドネイティブ機能を活用するため、移行に合わせてアーキテクチャを変更する | 現行のアーキテクチャがリリース速度、性能、拡張性などの事業要求を妨げている |
7Rの「Refactor / Re-architect」は、コードレベルのリファクタリングより広い移行戦略です。 Martin Fowlerが定義するリファクタリングは、外部から見た振る舞いを保ったままソフトウェアの内部構造を変える作業を指します。 一方、AWSの移行戦略はクラウドへの移行とアーキテクチャ変更を組み合わせた分類であり、既存実装をすべて捨てる全面リライトを必ず意味するわけでもありません。 移行計画では「Refactor」という名称だけで改修範囲を判断せず、既存コードを段階的に変更するのか、一部を再実装するのか、全面的に作り直すのかを明記する必要があります（リファクタリングとリライトの違い）。
Retireはクラウドへ移さずに廃止し、Retainは少なくとも今回の移行ではソース環境に残す選択です。 棚卸しによって、利用されていないシステムや重複した機能が見つかることがあります。 Retireを決める前には、利用部門、システム間の依存関係、データの保存義務を確認する必要があります。 その確認を終えたものから除外すれば、移行対象の総量を減らせます。
7Rは2軸だけでは決められない
事業価値と変更頻度は、優先順位を付けるための初期評価には使えます。 しかし、この2軸から7Rを一意に決めることはできません。 たとえば、変更頻度が低いシステムでも、サポート切れや高額なライセンス費用があればReplatformやRepurchaseが候補になります。 事業価値が低くても法令上の保存義務があるなら、確認せずにRetireを選ぶことはできません。
AWSのモダナイゼーション準備評価は、アプリケーションを5つの観点から評価します。 AWSのポートフォリオ評価ガイドも、事業上の目的、技術方針、優先順位の基準、事業戦略を組み合わせて移行戦略を決めるよう求めています。 この枠組みに沿うと、7Rを選ぶための判断材料を次のように整理できます。 AWSが5つの観点を各Rへ機械的に対応付けているわけではないため、表の右列は個別評価の出発点です。
| 判断材料 | 確認する内容 | 選択への影響例 |
|---|---|---|
| 戦略または事業との適合 | 事業成果、業務の重要度、今後の変更需要 | 保持にも移行にも価値がなければRetire、強い事業需要を現行構造が妨げていればRefactor / Re-architectを検討する |
| 機能の充足度 | 現行機能と将来要件の差、代替製品の適合度 | 要件を満たす製品やSaaSがあればRepurchaseを検討する |
| 技術の充足度 | サポート期限、保守性、性能、依存関係、移行先との互換性 | アプリケーションを変更しない移行ならRehost、対応するプラットフォーム単位の移行ならRelocate、基盤の最適化が必要ならReplatform、アーキテクチャ変更が必要ならRefactor / Re-architectを検討する |
| 財務上の適合 | 移行費、並行運用費、ライセンス費、移行後の総保有コスト | 戦略ごとの投資回収を比較し、条件が整うまでRetainする選択も含める |
| デジタル対応力 | スキル、テスト、自動化、運用体制 | 実行できる変更量と移行順序を決め、足りない能力は移行前かパイロットで補う |
1つのアプリケーション全体に同じRを割り当てる必要もありません。 AWSのポートフォリオ評価ガイドは、アプリケーション全体ではなくコンポーネント単位で評価し、層ごとにRehost、Replatform、Refactor / Re-architectを使い分ける方法を示しています。
この評価に、規制や監査の要件、データ移行の難度、システム間の依存関係、停止可能時間を加えます。 7Rの選択と、どの順番で移すかという移行ウェーブの設計は別の判断です。 リスクが高いことだけで特定のRが決まるわけではありませんが、一度に変更する範囲と切り戻し方法には影響します。
なお、AWSのガイドは大規模な移行について、Rehost、Relocate、Replatformで移行し、その完了後にモダナイゼーションを進める順序を勧めています。 Refactor / Re-architectは移行中に中核コンポーネントを再設計するため、7Rの中で最も複雑でコストが高く、多数のアプリケーションを同時に扱うと管理が難しくなるという理由です。 これは大規模移行を対象とした推奨であり、すべての案件でリホストを先行させる原則ではありません。 ほかの戦略では要件を満たせない場合や、移行時のアーキテクチャ変更を避けられない場合は、Refactor / Re-architectを選ぶ余地があります。
段階移行とストラングラーフィグ
旧システムを止めて新システムへ一斉に切り替える方式は、切替日にリスクが集中します。 移行単位が大きいほど、障害原因の切り分けと切り戻しの範囲も大きくなりやすいためです。
この対案として広く参照されるのが、Martin Fowlerが段階的なレガシーモダナイゼーションに与えた比喩であるストラングラーフィグです。 新旧のシステムを共存させ、機能や業務能力の単位で新しい側へ移し、旧システムの責務を徐々に減らしていきます。 小さい単位で提供と検証を繰り返せるため、投資と効果を段階化し、移行中に得た知見を次の単位へ反映できます。
入口にファサードやプロキシを置き、リクエストを新旧へ振り分ける構成は、ストラングラーフィグの代表的な実装例です（Microsoft「Strangler Fig pattern」）。 ただし、経路を旧システムへ戻せることと、データまで安全に切り戻せることは同じではありません。 旧側のデータと同期処理を残し、整合性を検証できる間は切り戻しやすくなりますが、旧データを削除した後の復旧には追加の移行作業が必要です。
段階移行にも、新旧間のデータ整合性、双方にまたがる依存関係、二重運用の費用という負担があります。 ファサードが単一障害点や性能上のボトルネックにならない設計も必要です。 リクエストを途中で振り分けられないシステムではファサード方式を使えないため、機能を分離できる別の境界が必要です。 旧システムを長期間残せない案件や、独立して置き換えられる境界を作れない案件には、段階的な置き換え自体が適さない場合があります。 4段階の流れ、並走期間のデータ整合、適さない場面の詳細はストラングラーフィグパターンの解説で扱っています。
進め方
- 成果指標を決める：リリース間隔、復旧時間、運用費など、モダナイゼーションで改善したい数字と基準値を決めます
- 棚卸しする：システム、利用部門、費用、利用状況、変更需要、連携、データ、規制要件を一覧にします
- 7Rと移行順序を決める：システムまたはコンポーネントごとの戦略を選び、所有者と依存関係を確認してからRetire、Retain、移行対象に分けます
- 小さなパイロットで検証する：影響範囲を限定でき、成果と移行手順の両方を検証できる対象を選びます
- 運用を更新して展開する：監視、バックアップ、リリース、障害対応の手順と担当を移行先に合わせ、得た知見を次の移行ウェーブへ反映します
刷新後に採用技術がシステムごとに無秩序に増えると、数年後に同じ問題が再発します。 どの言語や基盤を既定とするかを決める標準スタックの考え方を並行して用意すると、合理的な理由のない独自構成を抑えやすくなります。
注意点
避けたいのは、すべてをRefactor / Re-architectに寄せてしまうことです。 現行への不満が大きいほど、全面的な作り直しが唯一の解に見えてきます。 しかし、AWSの大規模移行ガイドでは、Refactor / Re-architectは中核コンポーネントの再設計を移行中に行うため、7Rの中で最も複雑でコストが高い戦略とされています。 さらに、この戦略の名称だけでは、既存コードの改修と全面リライトのどちらを行うかは決まりません。 判断の基準はリファクタリングと作り直しの比較で整理しています。
もう一つ避けたいのは、移行そのものが目的になることです。 「全システムをクラウドへ」のような目標は進捗を測りやすい一方、事業側の指標とつながっていないと、完了しても何が良くなったか説明できません。 リリース間隔、復旧時間、運用費など、改善する数字と基準値を着手前に決めます。
移行後も継続して変更するなら、必要な知識を社内に残せる体制かどうかも検討します。 この論点は内製と外注の判断で扱っています。
関連して読める記事
モダナイゼーションは、レガシーシステムと技術的負債の話と地続きです。 何が「レガシー」なのかから押さえたい方は、次の解説からどうぞ。
レガシーシステムとは？「古い」だけでは決まらない判定基準と放置のリスク
レガシーシステムの本質は古さではなく、許容できるコストとリスクで保守や変更を続けられなくなったことです。経産省のレガシーシステムモダン化委員会総括レポートの定義を起点に、EOL・自動テスト・属人化・ドキュメントなど8観点の判定チェックリスト、セキュリティ・事業・人材の3面から見た放置のリスク、「2025年の崖」その後の政策動向、資産棚卸しから始める対応の入口までを整理します。
2026年7月29日
技術的負債とは？「借金」の比喩の本来の意味と、返済の優先順位の付け方
技術的負債とは、短期には便益がある、または当時の理解では妥当だった設計や実装が、将来の変更や保守に追加コストを生む状態を捉える比喩です。Ward Cunninghamによる比喩の初出とFowlerの4象限を原典に沿って整理し、利子が変更リードタイムや障害という形で現れる構造、経営への翻訳のしかた、変更頻度×変更コストで返す場所を選ぶ優先順位の付け方、AI時代に増えやすい理解負債までを解説します。
2026年7月29日
リファクタリングとリライト（作り直し）の違い：分岐条件と、リライトが失敗しやすい理由
リファクタリングは外部から見た振る舞いを変えずに内部構造を改善する作業、リライトは実装を新たに作って置き換えることです。この2つはリスクの形も前提条件も違います。Joel Spolskyの古典が指摘した全面リライトの2つのリスク（暗黙の仕様の喪失・追いかけ続ける本番）、リファクタリングで足りる条件とリライトに寄る条件の分岐、ストラングラーフィグによる中間の道、どちらでも先に必要になる投資までを整理します。
2026年7月29日
ストラングラーフィグパターンとは？システム全体を一括停止せずに置き換える段階移行の設計
ストラングラーフィグパターンとは、既存システムを稼働させながら、業務機能やデータを小さな単位で段階的に新実装へ移し、旧システムの廃止を目指すアプローチです。Martin Fowlerによる比喩の由来と2004年の原文、ファサードで受けるMicrosoftの4段階とAWSの3ステップ、継ぎ目（seam）と移行期アーキテクチャの考え方、並走期間のデータ整合と切り戻し条件、適さない場面の判定、最初の移行単位の決め方までを原典に沿って整理します。
2026年7月29日
小さな会社ほど、AI開発の「標準スタック」を決めた方がいい
案件ごとに認証や決済を選び直すと、設計だけでなく障害対応・更新手順・監査ログまで案件の数だけ分岐します。小さな会社ほど「まず通る道」としての標準スタックを決める価値が上がる理由と、標準に含めるべき十の領域（フレームワーク、認証、決済、メール、ジョブ、ログ、監視、CI/CD、IaC、テスト）、製品名より先に決める選定基準、例外承認の運用、標準の陳腐化への備えを整理します。
2026年7月28日