ストラングラーフィグパターンとは？レガシー移行の実装手順と切り戻し設計を解説

ストラングラーフィグパターンは、旧システムの手前にファサード（プロキシ）を置き、機能単位でリクエストの向き先を新システムへ移していく段階移行の設計パターンです。Microsoftのアーキテクチャセンターは、ファサード導入・段階的な振り分け・旧システムの廃止・ファサード除去という4フェーズで整理しています（2026年8月5日に参照した版の更新日は2026年5月29日）。この記事では、名称の由来から、transform・coexist・eliminateの3段階、ルーティング層の実装手段、モノリシックなデータベースの分解とCDC同期、そして採用を見送るべき条件までを実装目線でたどります。定義の紹介ではなく、明日から設計に落とせる粒度で書きました。

まとめ：段階移行が成立する前提と見送るべき場面

先に結論を置きます。このパターンが成立する前提は3つ。旧システムへのリクエストをファサードで傍受できること、旧システムのソースコードを改変できること、そして新旧が数か月から年単位で並走する期間を許容できること。1つでも欠けるなら、別の移行方式を選んだほうが安全です。

見送るべき場面もはっきりしています。依存関係が少なく規模の小さいシステム、あるいは旧環境の契約終了が目前に迫っていて全面停止が避けられない案件。前者は一括で書き直したほうが総工数が小さく、後者は並走期間そのものが取れません。判断の軸は「規模が大きいかどうか」ではなく、傍受可能性・改変可能性・並走許容期間の3点に置いてください。

絞め殺しのイチジクに由来する段階移行の考え方とファサードの役割

まず言葉の出所と、装置としての役割を分けて押さえます。ここが曖昧なまま進むと、「とりあえずプロキシを立てた」だけで移行計画が止まります。

Martin Fowler氏の記事が示す名称の由来と改題の経緯

出典はMartin Fowler氏のbliki記事「Strangler Fig Application」です。2026年8月5日に参照した版には「22 August 2024」の日付が表示されていました。本文では、木のくぼみで発芽したつるが宿主から養分を得ながら地面へ根を伸ばし、やがて樹冠まで届いて宿主の形をなぞる、という植物の生長が説明されています。

元の題名は「Strangler Application」でした。この呼び方だと「strangler（絞め殺すもの）」だけが独り歩きし、植物学上の由来が忘れられがちだったため、氏は現在の題名へ改めています。AWSのPrescriptive Guidanceも同記事を出典として明記したうえで、木の上部で種を落とすイチジクの比喩を紹介しています。呼称の揺れとして「ストラングラーパターン」も同義の呼び方です。

ファサードが担うリクエストの振り分けと移行4フェーズの進み方

Microsoftのアーキテクチャセンターは、ファサード（プロキシ）をクライアント・旧システム・新システムの間に挟む構成として説明しています。移行は次の順で進みます。

1. ファサードを導入し、当初はほとんどのリクエストを旧システムへ流す
2. 機能を実装するたびに、ファサードの振り分け先を新システムへ寄せていく
3. 旧システムへの依存がゼロになった時点で、旧システムを廃止する
4. ファサードを取り外し、クライアントを新システムへ直結させる

第4段階まで書かれている点に明確な価値があります。ファサードは恒久設備ではなく期限付きの構造物であり、残すなら「旧クライアント向けアダプタとして意図的に残す」という判断が必要です。同センターはこれを暫定アーキテクチャと呼び、リスク低減の効果と一時的なインフラ費用を天秤にかけるよう促しています。

一括リプレースおよびビッグバン移行と比べたリスクの出方の違い

一括リプレースは、切り替え当日に全リスクが集中する構図です。段階移行はそのリスクを機能単位へばらし、失敗したルートだけを旧系統へ戻せる形に変えます。投資回収の順序も変わり、効果の大きい領域から先に置き換えられます。

代償は並走コストです。二重の運用監視、二系統分のテスト、そして「どの機能がどちらで動いているか」を追う台帳が要ります。刷新手法の選択肢を横並びで比べたい場合はモダナイゼーションとは？レガシー刷新の手法と実装アプローチを先に読むと、リホスト・リファクタとの距離感がつかめます。段階移行は万能ではなく、並走を許容できる案件でだけ成立する手法だと考えてください。

transform・coexist・eliminateの3段階と各段階の完了条件

AWSのPrescriptive Guidanceは、モノリスからマイクロサービスへ移す工程をtransform・coexist・eliminateの3語で整理しています。各段階に完了条件を置くと、進捗が体感ではなく事実で測れます。

transform段階で切り出す機能単位と境界線の決め方の基準

transformは、置き換える部品を並行して作る段階です。移植（ポーティング）でも書き直しでもよく、旧システムを止めずに新コンポーネントを立ち上げます。切り出す単位はコードの行数ではなく、業務上の境界で決めます。

境界の引き方に迷ったら、ドメイン駆動設計の境界づけられたコンテキストを土台にしてください。「注文」「在庫」「請求」のように、データの所有者が1つに定まる範囲が良い候補です。移行先をマイクロサービスにする前提なら、マイクロサービスとは？分割の考え方と導入判断で分割粒度の目安を確認しておくと、サービス数の見積もりがぶれません。最初の1本は、参照系かつ他ドメインへの書き込みを持たない機能を選ぶのが定石です。

coexist段階でHTTPプロキシに傍受させるルートの並べ方

coexistは、旧システムを切り戻し先として残したまま、外部からの呼び出しをHTTPプロキシで傍受して新系統へ振り向ける段階です。AWSはモノリスの境界にAmazon API Gatewayなどのプロキシを置く構成を例示しています。

ルートは「広いパターンを後ろ、狭いパターンを前」に並べます。既定ルートで全量を旧システムへ送りつつ、移行済みの具体パスだけを手前に差し込む形です。この順序を守らないと、既定ルートが先に一致して新系統に一切トラフィックが届きません。ルート定義はコードとして管理し、追加・削除の履歴を残してください。手作業でコンソールを触った変更は、障害時の原因追跡を必ず遅らせます。

eliminate段階で旧機能を撤去しファサードを外す判断基準

eliminateは、新系統へ流れ切った機能を旧モノリスから撤去する段階です。ここで多いのが「動いていないコードを残したまま次へ進む」失敗。残骸は依存解析を汚し、次の切り出し範囲を見誤らせます。

撤去の判断材料は3つに絞れます。第一に、当該ルートの旧系統アクセスログが一定期間ゼロであること。第二に、バッチや夜間ジョブなど、プロキシを通らない経路から旧テーブルを読み書きしていないこと。第三に、切り戻し要件の期限が過ぎていること。この3つが揃った機能から順に消していきます。全機能の撤去が終わって初めて、ファサードの除去を検討する段階に入ります。

ルーティング層の実装手段とファサードを単一障害点にしない構成

ファサードは全リクエストが通る一点です。AWSも「適切に設計しないと単一障害点や性能上のボトルネックになりうる」と明記しています。実装手段の選定と冗長化を同時に決めてください。

リバースプロキシとAPIゲートウェイの使い分けと選定の判断材料

実装手段は大きく3系統です。判断材料を並べます。

社内システムでパスが数十本なら逆プロキシで足ります。外部公開APIを含み、キーの発行やクォータ管理まで必要ならAPIゲートウェイとは？役割と構成、導入時の設計観点で挙げられている機能群を持つ層に寄せたほうが、後から作り込む手間が減ります。冗長化は、ファサードを複数ゾーンに配置し、ヘルスチェックの失敗時に旧系統へフェイルオープンする設計を初期から入れておいてください。

重み付けルーティングで新系統へ段階的に寄せる手順と監視の指標

ルートを一気に切り替えず、重みで割合を動かすと事故の影響範囲が縮みます。手順は、内部ユーザーのみ、次に全体の数％、そして段階的に引き上げ、という順です。各段階で最低1営業日は様子を見ます。

見る指標は、エラー率・p95応答時間・業務KPIの3層に分けてください。技術指標が正常でも、新系統の計算仕様の差で受注金額がずれる、といった事故は起きます。流量を割合で動かす作法そのものはカナリアリリースとは？段階的リリースの手順と判断基準と同じで、違いは戻し先が旧バージョンではなく旧システムである点だけ。切り戻しの操作は、担当者以外でも実行できるよう手順書に落としておきます。

新旧システムの相互呼び出しを腐敗防止層で受け止める実装上の分担

並走期間は双方向の呼び出しが発生する局面です。新システムが未移行機能を旧システムへ問い合わせることもあれば、未移行の旧コンポーネントが移行済み機能を呼ぶこともあります。Microsoftのアーキテクチャセンターは、この橋渡しに腐敗防止層（Anti-corruption Layer）を置くよう推奨しています。

腐敗防止層は、両者の語彙を翻訳するアダプタです。旧システムの「顧客区分コード1」を新システムの列挙型へ変換する、といった対応表をここに閉じ込めます。この層が無いと、新システムの設計が旧来の命名や制約に引きずられ、せっかく切り出したドメインモデルが旧仕様の写しになります。実装上は新システム側のパッケージに置き、翻訳先の型を新システムの語彙で定義するのが扱いやすい形です。呼び出しの経路を識別できるよう、X-Migration-Routeのようなヘッダを付けて記録しておくと、撤去判断のログ確認が楽になります。

モノリシックなDBの分解とCDC同期で切り戻し余地を残す設計

難所はアプリケーションではなくデータです。Microsoftのアーキテクチャセンターは、複数ドメインを抱えた一枚岩のデータベースから、ドメイン単位でテーブル・ストアドプロシージャを抜き出す3段階の手順を示しています。

ETLの初期ロードとCDCの差分同期でドメインDBを立ち上げる順序

順序を誤ると、切り戻しの余地ごと失います。同センターが示す流れは次の通りです。

1. 新サービスを立ち上げるが、読み書きは旧来の一枚岩データベースへ向けたままにする
2. ドメイン専用データベースを用意し、ETLで対象テーブルと履歴データを初期ロードする
3. CDC（変更データキャプチャ）で一枚岩から新データベースへ差分を同期し続ける
4. 両者の整合性を検証したうえで、新データベースを正本（system of record）へ切り替える
5. 一枚岩側から当該ドメインのテーブルと依存物を削除する

第2段階の間、旧システムは一枚岩を読み書きし続けます。新旧が同じデータを別の場所で持つ期間が必ず生じるため、同期の遅延をどこまで許すかを業務側と決めてから着手してください。

二重書き込みを避けて整合性の検証を通すための実務上の判断基準

新旧の両データベースへアプリケーションから同時に書く「二重書き込み」は、一見わかりやすい方法です。ただし片方の書き込みが失敗したときに整合性が壊れ、復旧がトランザクションの外側に出てしまいます。既定の選択はCDCによる一方向同期です。

検証は件数一致だけでは足りません。主キー単位のハッシュ突合、金額や数量など集計値の一致、そして更新の遅延分布を見ます。判断基準を1つ置くなら「業務日次で締めた集計値が両系統で一致すること」。ここが合わないまま正本を移すと、後続の月次処理まで巻き込んで手戻りします。分散した書き込みの整合をアプリケーション側で担保したい場合は、Sagaパターンとは？分散トランザクションの補償設計で扱っている補償トランザクションの考え方が下敷きになります。

切り戻しが成立する期間と成立しなくなる境界の具体的な見極め方

切り戻しには有効期限があります。Microsoftのアーキテクチャセンターは、第2段階の全期間と第3段階の開始時点までは一枚岩データベースへ戻せると説明しています。ドメインテーブル・ストアドプロシージャ・同期処理が一枚岩側にまだ存在しているからです。

境界を越えるのは、一枚岩側からそれらを削除した瞬間。以降に戻すには、削除したオブジェクトを復元したうえで、その間のデータ変更を再生する必要があり、工数もリスクも跳ね上がります。だからこそ旧オブジェクトの削除は「各ドメインの最終工程」として意図的に実行し、新システムの検証が終わるまで着手しない。ここは条件付きではなく、順序として固定してください。

採用してよい条件と見送るべき条件を分ける実務上の線引きの基準

ここからは判断の話です。競合記事の多くは利点と注意点を並べて終わりますが、実務で必要なのは「やらない」と言い切る基準のほうです。

リクエストを傍受できない場面で採用を見送ると判断する4つの条件

Microsoftのアーキテクチャセンターは、このパターンが適さない条件を明示しています。実務での言い換えを添えて並べます。

• バックエンドへのリクエストを傍受できない（専用線や独自プロトコル直結など）
• 旧システムのソースコードへ手が入らない（機能の無効化や内部呼び出しの付け替えができない）
• 規模が小さく、全面的な置き換えが単純に済む
• 旧システムを短期間で完全に廃止する必要がある

重みは同じではありません。実務でまず確認すべきは上2つ。傍受とコード改変のどちらかが不可能なら、この時点で採用を見送ります。3つ目と4つ目は「不可能」ではなく「割に合わない」条件で、テーブル数十本規模の社内ツールなら一括で書き直したほうが速く終わります。

マネージドサービス前提が崩れたときの実装手段の組み替えの判断

移行支援のマネージドサービスに寄りかかった設計は、提供状況の変化で足元が崩れます。実例があります。段階的リファクタリング専用のAWS Migration Hub Refactor Spacesは、2025年11月7日をもって新規顧客の受け付けを終了しました。既存利用者は進行中の移行を完了できますが、新規機能の追加は行われず、後継としてAWS Transform（2025年5月提供開始）が案内されています。

この構図は特殊ではなく、数年がかりの移行では珍しくない出来事です。だから経路制御の中核は、逆プロキシやAPIゲートウェイのような入れ替え可能な部品で組み、ルート定義を宣言的なコードとして保持しておく。そうしておけば、実装を差し替えても振り分けの意図は残ります。移行計画そのものを外部と組んで進める場合は、システムマイグレーション・リプレイスの支援のように、現行資産の調査から並走期間の運用設計まで一貫して引き受けられる体制かどうかで選定してください。

傍受できない構造で選ぶブランチバイアブストラクションの適用範囲

傍受ができない場合の代替が、ブランチバイアブストラクションです。プロセスの外側にプロキシを置く代わりに、コード内部に抽象インターフェースを差し込み、その実装を旧ロジックから新ロジックへ切り替えます。切り替えの単位はHTTPルートではなく、関数やクラスの呼び出しになります。

適用範囲は、単一のプロセス内で完結する処理。バッチ、帳票生成、計算エンジンのような領域が向いています。逆に、切り替え制御をフィーチャーフラグで持つため、フラグが増えすぎるとコードの分岐が読めなくなる弱点があります。フラグには除去期限を付け、切り替え完了後に消す運用を最初から決めておいてください。ネットワーク層とコード層、どちらで分岐させるかを機能ごとに選べる状態が、移行計画としては強い形です。

よくある質問

設計レビューや見積もりの場で実際に挙がる質問を5つ取り上げます。

ストラングラーフィグパターンとマイクロサービス化は同じ意味ですか？

別物です。ストラングラーフィグパターンは「どう移すか」という移行の進め方であり、マイクロサービスは「移した先をどう分けるか」というアーキテクチャの様式です。移行先はマイクロサービスとは限らず、整理されたモジュラーモノリスでも、別言語で書き直した単一アプリケーションでも構いません。AWSの資料ではモノリスからマイクロサービスへ移す文脈で紹介されていますが、これは代表的な使われ方の一つと捉えてください。

移行にはどのくらいの期間を見込めばよいですか？

Microsoftのアーキテクチャセンターは、このパターンの適用条件として「旧システムが移行期間中も長期にわたって存続できること」を挙げています。裏を返せば、短期決戦の案件には向きません。期間の見積もりは、切り出す機能の本数と、1本あたりの並走検証期間の掛け算で概算します。1本ごとに検証と切り戻し猶予を数週間ずつ確保する前提で計画を引くと、実態から大きく外れにくくなります。

ファサードは移行完了後に必ず撤去すべきですか？

原則は撤去です。Microsoftのアーキテクチャセンターも、移行完了後は通常ファサードを取り除くとしたうえで、旧クライアント向けのアダプタとして残す選択肢を併記する立場です。残す場合は「暫定構造を恒久設備に昇格させる」判断であり、監視・更新・障害対応の責任者を決める必要があります。惰性で残したファサードは、数年後に誰も仕様を説明できない層になります。

データベースを分けずにアプリケーションだけ移行できますか？

可能です。Microsoftの例でも、第1段階では新サービスが旧来の一枚岩データベースを読み書きしたまま稼働します。アプリケーション層だけを先に移し、データ分解は後続の工程へ回す進め方は現実的な選択です。ただしその状態では、データ層のスキーマ変更が新旧双方に影響し続けます。分解を先送りする期間の長さは、あらかじめ上限を決めておいてください。

小規模なシステムでも採用する価値はありますか？

薄いです。AWSの資料は「複雑性が低く規模の小さいシステムには適さない」と明記しています。ファサードの構築・二重の監視・並走中の整合性検証というコストが、一括で書き直す工数を上回りやすいためです。判断の目安として、停止できる時間帯が確保でき、かつ全面テストが数日で回る規模なら、段階移行を選ばず一括で置き換えたほうが早く終わります。

関連記事

• ドメイン駆動設計とは：切り出す機能の境界を決めるときの土台になる考え方をまとめています
• イベントソーシングとは：新旧の状態差を追跡しやすくする記録方式として、移行期の設計と相性があります
• ブルーグリーンデプロイメントとは：一斉切り替え型の方式と比べると、段階移行の位置づけがつかめます
• APIゲートウェイとは：ファサードをマネージドな層で実装する場合の機能範囲を確認できます