古いLaravelプロダクトの保守リスクを下げる方法

「作った担当者がもう社内にいない」「Laravelのバージョンがいくつかも分からない」「触ると壊れそうで誰も手を出さない」。何年も前にPHPやLaravelで作られたプロダクトが、こうした状態で塩漬けになっているケースを頻繁に見かけます。動いているうちは問題が表面化しませんが、放置期間が長いほどリスクは静かに積み上がっていきます。今日は動いていても、明日突然止まる可能性があるのがこの状態の怖さです。

なぜ「動いているから大丈夫」ではないのか

古いLaravelプロダクトが抱えるリスクは、大きく4つに分解できます。

1. PHP / Laravel本体のEOL(サポート終了)

PHPは概ね3年でセキュリティサポートが切れます。Laravelも同様にメジャーバージョンごとに18ヶ月〜2年程度でサポートが終了します。Laravel 5系・6系、PHP 7.2以前がまだ現役で動いている場合、それは「新しく発見される脆弱性が二度と修正されない」状態を意味します。攻撃者は公開されたCVE情報をもとに、EOLしたバージョンを狙って自動スキャンをかけてきます。

2. 依存パッケージの脆弱性の蓄積

composer.json の依存パッケージ自体が長期間更新されていないと、Laravel本体だけでなく個々のパッケージ(認証ライブラリ、画像処理、PDF生成など)にも既知の脆弱性が積み上がります。composer audit を一度も実行したことがないプロダクトでは、数十件のCVEが放置されているケースも珍しくありません。

3. 保守できる人材の減少

Laravel自体は現役の主要フレームワークですが、古いバージョンの作法(Laravel 5系のクエリビルダの書き方、旧来のミドルウェア構成など)を知っているエンジニアは市場で減っています。特に生PHP(フレームワークなし、もしくは独自の軽量フレームワーク)で書かれた部分が混在していると、対応できる人材はさらに限られます。求人を出しても応募が来ない、既存メンバーの退職で属人化が一気に表面化する、という相談が増えています。

4. バージョンアップの困難さが年々増す

Laravelはメジャーバージョン間で破壊的変更が多いフレームワークです。5系から11系まで放置すると、間に6回以上のメジャーアップグレードが挟まり、都度非互換な変更(認証まわりの刷新、ルーティング記法の変更、Eloquentの挙動変化など)に対応する必要があります。放置期間が伸びるほど、アップグレードに必要な工数は線形ではなく加速度的に増えます。 1年放置なら数人日で済んだ差分が、5年放置すると数ヶ月がかりのプロジェクトになる、というのはよくある実例です。

まずやるべきこと(優先順位順)

パニックになって「全部作り直そう」と判断する前に、次の順番で現状を把握することをお勧めします。

1. 現状診断 — バージョンと脆弱性の棚卸し

最初にやるべきは、感覚ではなく事実を確定させることです。

• composer.json / composer.lock から PHP・Laravel・主要パッケージのバージョンを確認
• 各バージョンのEOL日付を公式のサポート表と照合(PHPも同様にphp.netで確認)
• composer audit (Laravel 9以降で標準搭載、それ以前は composer require --dev roave/security-advisories:dev-latest などで代替)で既知の脆弱性を洗い出す
• テストコードの有無とカバレッジ(ゼロなら「触ると何が壊れるか誰も分からない」状態)
• デプロイ手順が属人化していないか(手順書があるか、特定の1人しか本番反映できない状態になっていないか)

この診断だけで、「今すぐ対応が必要な脆弱性」「バージョンアップの規模感」「保守体制のリスク度合い」の3点が数値・事実ベースで見えてきます。

2. 脆弱性対応 — 緊急度の高いものから止血

診断で見つかった脆弱性のうち、インターネットに公開されている(認証不要でアクセスできる)エンドポイントに関わるものを最優先で潰します。全部を一度に直そうとせず、CVSSスコアが高いもの・攻撃コードが公開済みのものから着手するのが現実的です。この段階ではフレームワーク全体のアップグレードをせず、パッケージ単位のパッチ適用や、WAF・リバースプロキシでの一時的な緩和策で時間を稼ぐ判断もあり得ます。

3. 保守体制の確保

技術的な対応と並行して、「誰が継続的に見るのか」を決めないと、直したそばからまた塩漬けに戻ります。社内に適任者がいない場合、月次の保守契約で外部に運用を委託し、脆弱性情報のウォッチ・軽微な修正・障害対応の一次窓口を確保するのが現実的な落としどころです。

バージョンアップ vs 他言語移行、どう判断するか

ここが発注者にとって一番迷う分岐点です。判断基準は次の3つです。

基準1: ビジネスロジック自体は健全か

コードの複雑さの原因が「フレームワークが古いこと」なのか、「設計・実装の質そのものが低いこと」なのかを見極めます。フレームワークが古いだけで設計は素直なら、バージョンアップで解決します。逆に、テーブル設計がそもそも破綻している、同じ処理が至る所に重複している、といった問題はバージョンアップでは解決せず、言語を変えても再発します。

基準2: 段階的アップグレードが可能な規模か

Laravelは幸い、メジャーバージョンを1つずつ順番に上げていく「段階的アップグレード」がしやすいフレームワークです。5→6→7→8…と1バージョンずつ上げれば、各段階の非互換変更は限定的で、テストがあれば都度検証できます。一足飛びに5系から11系へジャンプしようとすると変更点が積み重なって収拾がつかなくなるため、段階を飛ばさないのが鉄則です。 この方式が取れるなら、多くの場合は他言語への移行より低リスク・低コストで済みます。

基準3: チーム・組織として今後もPHPを使い続ける意思があるか

技術的にはバージョンアップで延命できても、「社内にPHPエンジニアを採用・育成する予定がない」「他プロダクトはRailsやGoに寄せている」といった組織的な事情がある場合、中長期ではRailsやGo、Next.jsなど他言語・他スタックへの段階的移行を選ぶ合理性もあります。ただしこれは技術判断というより経営判断です。技術的負債は改修とフルリプレイスどちらを選ぶべきかで整理した通り、フルリプレイスは完成までの期間中にビジネス要望が止まらず予算超過に陥りやすいリスクを伴うため、「PHPのまま延命できる部分は延命し、事業上のインパクトが大きい機能から他スタックへ段階的に置き換える」ハイブリッドな進め方が現実的な着地点になることが多いです。

外注時に確認すべきこと

古いLaravelプロダクトの保守・改善を外部に依頼する際、次の点を確認すると失敗を避けやすくなります。

• 診断フェーズを分離して発注できるか: いきなり「アップグレードお願いします」ではなく、まず現状診断だけを独立して発注し、規模感が見えてから本改修の見積もりを取れる進め方が望ましい
• 段階的アップグレードの実績があるか: 一足飛びの書き直しではなく、バージョンを1つずつ上げていく地道な進め方に慣れているか
• テストがない状態からの着手経験があるか: 多くの塩漬けプロジェクトはテストがゼロの状態から始まる。「まずテストを書きながら安全に進める」現実的な手順を提示できるか
• 保守フェーズまで継続して面倒を見る体制があるか: 直して終わりではなく、月次保守で継続的に見られる体制があるか(単発の受託だけだと、また数年後に同じ状態に戻る)

まとめ

• 古いLaravel・生PHPプロダクトの放置は、EOL・脆弱性の蓄積・保守できる人材の減少・アップグレード工数の増大という4つのリスクが静かに積み上がっている状態。動いていることは安全の証明にならない
• 対処は「現状診断(バージョン・脆弱性の棚卸し)→緊急度の高い脆弱性対応→保守体制の確保」の順で進めるのが安全。感覚でいきなり作り直しに踏み切らない
• バージョンアップと他言語移行の判断は、ビジネスロジックの健全性・段階的アップグレードの可否・組織としてPHPを使い続ける意思の3点で決める。多くの場合、段階的バージョンアップの方が低リスク

まず既存プロダクトの改善で最初に確認すべき観点を参考に、自社のプロダクトがどの段階にあるか確認してみてください。torcheees ではモダナイゼーションのサービスとして、開発診断でLaravel・PHPプロダクトのバージョン・脆弱性・保守リスクを可視化し、継続的な改善支援で段階的アップグレードから保守体制の構築までを継続的に支援しています。塩漬けになったプロダクトの現状を一度整理したい方は、お問い合わせフォームからご相談ください。