古いPHPバージョンを維持できずに、そのままサービスを終了せざるを得ないWebサービスやサーバーのニュースを耳にする機会が増えています。古いPHPにおける「PHP2Shell」などの脆弱性リスクやサポート終了に伴う対応の難しさは、IT業界の大きな頭痛の種です。
ふと思ったのですが、これってスマートフォンのAndroidアプリにおける「Android SDK（APIレベル）」のバージョン強制問題とまったく同じ構造ではないでしょうか？
今回は、この「レガシー基盤のジレンマ」について、共通点と背景を整理してみたいと思います。
🤔 なぜ「同じ」と言えるのか？ 共通する3つの構造
表面上は「サーバー側の言語（PHP）」と「モバイルのOS環境（Android）」で領域が違いますが、本質的な課題は驚くほど似ています。
土台のライフサイクルと、容赦ない切り捨て
PHPの現実： 古いPHPバージョン（7系や初期の8系など）はすでに公式サポートが終了しています。重大な脆弱性が見つかってもパッチが当たらないため、安全性を保つには最新版へ上げるしかありません。しかし、古いWebアプリや自作のプラグインがそのバージョンに対応していません。
Androidの現実： Google Playストアのポリシーにより、アプリがターゲットとすべき「ターゲットAPIレベル（SDKのバージョン）」の最低要件が毎年引き上げられます。古いSDKのまま放置されたアプリは、新しいAndroid OSのセキュリティ基準を満たせず、ストアから削除されたりアップデートができなくなります。
「動いているのに、強制的に動かなくなる」ジレンマ
どちらのケースも、「プログラム自体は今のままで、エラーも出さずに元気に動いている」という状態であることが多くあります。
しかし、言語側やプラットフォーム側が「セキュリティ」や「エコ全体の健全化」を理由にアップデートを強制するため、現役で動いていたはずのシステムが突如として「NG」判定を受けることになります。
膨大な「移行・修正コスト」の壁
古いコードを最新のPHPや新しいAndroid SDKに追従させるには、非推奨（デプリケーティッド）になった関数の書き換えや、ライブラリの全面的な見直しが必要です。これには膨大な開発工数とコストがかかるため、リソースのない個人開発や中小サービスでは、「直すくらいならサービスを終了しよう」という苦渋の決断に至ってしまいます。
🤔 決定的な違いは「誰が強制しているか」
構造は似ていますが、外圧の性質には少し違いがあります。
Android SDK： Googleという「絶対的なプラットフォームホルダー」が、規約をもってトップダウンで強制してくる。
PHP2Shell / サーバー： プラットフォームからの強制というよりは、ネット上の「セキュリティの脅威（ボットによる攻撃や脆弱性）」というボトムアップ（環境起因）の現実が、サービスを安全に継続させることを不可能にさせる。
結果として「続けられなくなる」という結末は同じでも、そのプレッシャーの出所が異なります。
🤔 まとめ：ITエコシステムの高齢化という宿命
PHPのバージョン問題も、Android SDKの追従問題も、根っこにあるのは「ITエコシステムの高齢化と、それに伴う保守コストの肥大化」です。
ソフトウェアは一度作ったら終わりではなく、その周りを取り巻く環境（OSや言語、セキュリティ基準）の高速な進化に合わせて絶えずメンテナンスし続けなければなりません。
「動いているからそのままにしておきたい」という開発者側の願いと、「安全のために進化を強制する」というプラットフォームのルールの板挟み。このジレンマにどう向き合うかが、現代のシステム開発・運営における大きな課題だと言えそうです。
