「このシステム、もう限界です。作り直しましょう」
あなたがエンジニアなら、一度はこう言ったことがあるかもしれない。あるいは、経営者として言われたことがあるかもしれない。
創業期を支えたPHP（CakePHP 2.xや古いLaravel）のモノリスシステム。度重なる改修でスパゲッティ化し、テストはなく、デプロイは手動。誰も触りたがらない「技術的負債」の塊。
多くの現場はここで
「フルリニューアル（完全作り直し）」という選択をする。
しかし、断言しよう。そのプロジェクトは9割の確率で失敗する。
仕様の漏れ、終わらない並行稼働、膨れ上がる予算……。
GC Next Archが推奨するのは、「システムを捨てずに、生かしながら移行する」アプローチだ。
本記事では、古いPHP環境を維持したまま、フロントエンドにNext.js、インフラにAWS (Fargate/Lambda) を導入し、段階的にモダン化する「ストラングラー・パターン」の実践的アーキテクチャを解説する。
ストラングラー・パターンとは？
ストラングラー・パターン (Strangler Fig Pattern) とは
巨大なレガシーシステム（既存の木）を、新しいマイクロサービス（絞め殺しのイチジク）で徐々に覆い尽くしていく移行戦略のこと。
一気にシステムを置き換えるのではなく、特定機能（例：検索画面、決済機能）から順番に新技術へ切り出し、最終的にレガシーシステムを自然消滅させる手法。リスクを最小限に抑えながら、モダン化の恩恵（UX向上など）を早期に得られるのが特徴。
第1章：なぜ「フルリプレイス」は失敗するのか
まずはマインドセットを変える必要がある。なぜ「ゼロから作り直し」は地獄を見るのか。
- 「正解」はソースコードの中にしかない 仕様書は更新されていない。退職した担当者の頭の中にあった「例外処理」や「ドロドロのビジネスロジック」は、今の汚いコードの中にだけ存在する。ゼロから作ると、これらを必ず見落とす。
- 開発中は「価値」が生まれない リプレイスに1年かかるとすれば、その1年間、ユーザーには何の機能追加も提供できない。ビジネスの機会損失が大きすぎる。
- 「第2システム症候群」の罠 「次はきれいに作ろう」と意気込むあまり、過剰な機能を盛り込みすぎて、結局完成しない。
だからこそ、「動き続けている車（PHP）のタイヤを、走りながら交換する」技術が必要なのだ。
F1でいう、レース中にピットにたちよったタイミングで行うようなものだ。
第2章：AWS × Next.js による「ハイブリッド構成」の全体像
私たちが目指すのは、以下のような構成だ。
- ユーザー（ブラウザ）: 見た目は一つのサイト。
- 入口 (ALB / CloudFront): URLのパス（
/search/mypageなど）によって、振り分け先を変える。 - Legacy (Old): 既存のPHPアプリ。Dockerコンテナ化してAWS Fargateに乗せる。
- Modern (New): 新規開発部分。Next.js (Front) + Go/Python (API) on Lambda。
これを作るための3ステップを解説する。
Step 1: レガシーの「コンテナ化」と「塩漬け」
まずは、古いPHP環境をAWS Fargate（コンテナ基盤）に移行する。 オンプレミスやレンタルサーバーから脱却し、「いつでもスケールできる」「いつでも捨てられる」状態にするのが目的だ。
- ポイント: PHPのバージョンアップは無理にしない。Dockerなら古いPHP 5.xでも動かせる。まずは「環境をモダンなAWSに移す」ことだけに集中する。
- ルール: 今後、このPHPコードには「新機能」を追加しない。バグ修正のみとする（塩漬け）。
Step 2: フロントエンドの「ヘッドレス化」 (Next.js導入)
最もユーザーに価値がある部分、例えば「トップページ」や「検索結果」だけをNext.jsで作り直す。
- 構成:
- View: Next.jsで爆速のUIを作る。
- Data: 既存のPHPを「APIサーバー」として使う。PHP側でJSONを返す簡単な改修を行い、Next.jsがそれを叩く。
- メリット:
- 裏側の複雑なロジック（決済や在庫管理）には触れずに、見た目と操作性だけを劇的に改善できる。
- 経営陣に「リニューアルで売上が上がった」という実績を早期に見せられる。
Step 3: 機能ごとの「切り出し」 (マイクロサービス化)
Next.js化が進んだら、次はバックエンドのロジックもPHPから引き剥がしていく。
- 例: 「お気に入り機能」
- これまではPHPがMySQLに書き込んでいた。
- 新しくAWS Lambda (Python) + DynamoDB でAPIを作る。
- Next.jsからは、PHPではなくこの新APIを叩くように変更する。
- これを機能単位で繰り返していくと、気づけばPHPへのアクセスはゼロになり、役目を終える（Strangled）。
第3章：技術スタック選定の「勘所」
なぜこの組み合わせなのか？ アーキテクトとして説明できなければならない。
🟢 Next.js (App Router)
- 採用理由: 単なるReactではなく、BFF (Backend For Frontend) の機能を持っているから。
- PHPのAPIが吐き出す「汚いデータ構造」を、Next.jsのサーバーサイド（API Routes）で整形してからクライアントに渡せる。これにより、フロントエンドのコードを綺麗に保てる。
🟢 AWS Fargate
- 採用理由: 「サーバー管理をしたくない」から。
- EC2だとOSのパッチ当てや管理が必要になるが、Fargateならコンテナを置くだけ。少人数のチームでも運用が回る。
🟢 Amazon Aurora Serverless v2
- 採用理由: 「スパイクアクセス対策」。
- レガシーシステムはDBがボトルネックになりやすい。アクセス負荷に合わせて勝手に容量が増えるServerless v2にしておけば、DBチューニングの魔術から解放される。
移行プロセス自体を「設計」せよ
モダン化とは、単に新しい言語で書き直すことではない。
「ビジネスを止めずに、システムの新陳代謝を再開させること」だ。
この「ストラングラー・パターン」を採用すれば、あなたは巨大な敵（レガシーシステム）と正面衝突する必要がなくなる。 まずは「トップページだけNext.js」から始めてみよう。その小さな成功体験が、チームとシステムを蘇らせるきっかけになるはずだ。
📚 合わせて読みたい
- 移行の前に知っておくべき「データ」の話 👉 【水曜連載】DB設計の常識を疑え。分析のためのスタースキーマ入門（準備中 comming soon）
- 上流工程へのキャリア戦略 👉 【完全保存版】年収1000万を超える「次世代システムアーキテクト」の教科書
🛠️ 【無料診断】あなたのシステムの「移行難易度」は？
移行戦略は、システムの「結合度」によって変わります。
GC Next Archでは、簡単な質問に答えるだけで、
あなたのシステムに最適な「モダナイズ手順書」が分かる無料診断を提供しています。
- Q. DBのテーブル数は100以上ですか？
- Q. フレームワークは独自のものですか？
[👉 3分で完了！「レガシーシステム健康診断」を受ける]（準備中 cooming soon）
❓ よくある質問 (FAQ)
- PHPエンジニアしかいないのですが、Next.jsを導入できますか？
-
可能です。むしろ、PHPエンジニアこそNext.js（特にTypeScript）の型定義やサーバーサイドの概念に馴染みやすく、習得が早いです。まずは小さな「LP（ランディングページ）」から導入して学習コストを分散させましょう。
- セッション管理（ログイン状態）はどう引き継ぎますか？
-
ここが最大の難所です。一般的には、PHPのセッションをRedis (Amazon ElastiCache) に保存し、Next.js側からもそのRedisを参照して認証トークンを検証する構成（共有セッション）をとります。詳細な設計パターンは別記事で解説します。
👉 記事を書いた人
AI参謀GAくん | じーえーくん
tech leadかねやん | 金岡潤
＋α
「システムも野菜も、鮮度が命。」
元メガ企業のSEとして、大規模サービスのバックエンド開発・アーキテクチャ設計に従事。その後、福岡に移住し起業。「八百屋」を地域No1にするという異色の経歴を持つ。 現在はBig Tech企業のモダンな開発手法（ベクトル検索、GraphRAG、エージェント技術など）を、地方企業や中小ビジネスの現場に落とし込むDX支援を行っている。 技術の複雑さを感じさせない設計、ビジネスの成果（CX）に直結させる「翻訳者」としてテックリードを担っている。