バイブコーディングでレガシーをモダナイズする（2/2）：Webの歴史とともに積み重なったPHP

Fri, 16 Oct 2026 18:00:00 +0900

PHPレガシーのリスクはポインタではなく、老朽化した実行環境、暗黙の型変換、権限チェック、そしてDBや外部連携に潜んでいます。ほとんどの場合、正解はPHPを捨てることではなく、PHPをサポート対象のバージョンに上げ、検証とデプロイの仕組みを先に整えることです。

チョン・ドヒョン - ROBOCO首席コンサルタント

第1部では、20年以上前のC/C++アプリケーションをバイブコーディングでモダナイズする方法を扱いました。¹ 今回は、レガシーWeb、なかでもPHPを扱います。

PHPは1995年に登場し、Webの歴史とほぼ同じ時間をともに歩んできました。その間に数多くの企業サイト、ECサイト、コミュニティ、社内業務システムがPHPで作られ、その相当数はいまも稼働しています。韓国国内だけでも、GnuboardやYoungcartで作られたサイト、自作のPHP5管理画面、古いLaravelやCodeIgniterのプロジェクトに、コンサルティングの現場でよく出会います。こうしたプロジェクトでも「エージェントがきちんと仕事をしてくれない」という声を聞きます。

第1部の結論は、PHPにもそのまま当てはまります。エージェントが失敗する主な理由は、自分が行った変更が正しいかを確かめる手段がないことです。だからこそ、モダナイゼーションの最初の投資先は検証環境であるべきです。しかし、何を検証すべきかはC/C++とは異なります。本記事では、2026年10月16日時点で調査した公開事例・公式サポートポリシー・ツールドキュメントをもとに、PHPに合ったモダナイゼーション戦略を整理します。事例の数値はすべて発表主体による自己報告であり、私が独自に再現したものではありません。

シリーズ：バイブコーディングでレガシーをモダナイズする

20年もののC/C++アプリケーション
Webの歴史とともに積み重なったPHP（本記事）

TL;DR

PHPレガシーの主なリスクはポインタの寿命ではなく、サポートが終了した実行環境、動的型付けと暗黙の動作、グローバル状態、認証・認可、DBと外部連携、そしてテストとデプロイの仕組みの欠如です。
ほとんどのプロジェクトには、PHPを維持しながらランタイムと依存関係をサポート対象のバージョンに上げ、検証・デプロイの仕組みを作ったうえで、必要な部分だけを再構成する方法が適しています。
ルールが明確な大量変換はRectorのような決定的なツールに任せ、エージェントは調査・残った例外の修正・テスト作成を担当します。人は業務上の動作・権限・データ・切り替えのリスクを判断します。
Webプロジェクトの同等性は、画面が表示されることでは確認できません。HTTPリクエスト、ユーザー権限、セッション、DBの変更、メール・決済のような外部効果を1つのシナリオとして比較する必要があります。
公開事例では、エージェントが権限チェックの欠落（IDOR）、メール送信の欠落、+1のような定数補正、DBカラムをnullableに変える回避策を実際に作り出しました。こうした失敗を捕捉する検証基準を先に立てる必要があります。

1. PHPレガシーはC/C++レガシーと何が違うのか

C/C++レガシーの核心的な難題は、ポインタの所有権とオブジェクトの寿命でした。PHPはリクエストが終わるとメモリが解放される実行モデルなので、この問題はほとんどありません。そのかわり、別のところで問題が起きます。

区分	C/C++レガシー	PHPレガシー
主なリスク	ポインタの所有権、オブジェクトの寿命、メモリ欠陥	実行環境の老朽化、暗黙の型変換、権限、DB・外部への副作用
事実上の仕様	オリジナルのバイナリの動作とABI	稼働中のサーバーのコード、DBスキーマとデータ、URL
同等性の比較単位	関数・ライブラリの入出力	HTTPリクエスト、ユーザーロール、セッション、DBの変更、外部効果
代表的な決定的ツール	clang-tidy、LibTooling、C2Rust	Rector、PHPStan、PHPCompatibility、Composer
よくある誤った目標	すべてをRustに翻訳	すべてを最新フレームワークとSPAで書き直し

私が現場で見てきたPHPレガシーで、エージェントの作業ループが途切れるポイントはおおむね4つです。

1つ目に、リポジトリのコードが本番のコードと異なります。 FTPでサーバー上で直接修正したファイル、ベンダーやCMSのコアを直接書き換えた部分、Gitに入っていない設定ファイルはよくあります。エージェントがリポジトリだけを読んで作業すると、実際には稼働していないコードを基準に判断してしまいます。

2つ目に、実際の実行環境を再現するのが困難です。 WebサーバーのPHPとcronが使うCLIのPHPとで、バージョンやphp.iniが異なることがあります。サポートが終了したPHP 5.xと古い拡張モジュール、EUC-KRのような文字エンコーディング、特定のMySQL設定に動作が依存しているケースも多くあります。

3つ目に、コード検索だけではエントリーポイントをすべて見つけられません。 URLから直接呼び出されるPHPファイル、動的なinclude、eval、DBに保存されたSQLやルールがあると、シンボル検索では呼び出し関係が見えてきません。そのため、アクセスログとcronのスケジュールもあわせて確認する必要があります。

4つ目に、DBと外部連携が事実上の仕様です。 ORMのモデルクラスが実際のDBスキーマと異なるケースは多くあります。実際のDDL、インデックス、trigger、データの分布が業務ルールを担っています。メール・SMS・決済（PG）連携は、テスト中に実際に実行されてしまうと取り消せません。

2. 公開事例が示すこと

PHPのモダナイゼーション事例はC/C++より多くあります。ただし、単純なAI支援コーディング、ツールを直接実行するエージェント、ルールベースの自動変換が混在しているので、区別して読む必要があります。

事例	元のシステムと目標	ツール	発表された結果	適用上の限界
DVHARDWARE²	2002年から積み重なった手続き型PHPのCMS → PHP 8.5とレイヤー構造	Codex、Docker、PHPStan、Deptrac	初期の機能対応版を3晩の作業で確保し、その後も改善を続けてデプロイ	比較的単純なCRUDのCMSであり、機能の同等性は運営者自身の判断
Progrit³	7つのリポジトリ、PHP 8.2→8.4、Laravel 10→12	Claude Code、Rector	通常の開発と並行して大きな問題なく完了したと報告	期間・コスト・自動化率は非公開
Rocket⁴	PHPの画面・ロジック → Angular中心の構造への残りの移行	Claude Code	教育を含めて4か月、シニアエンジニアの作業処理量が82件→201件	組織の変化もあわせて反映された数値であり、PHPサーバー全体の置き換えの根拠ではない
Boldare⁵	Symfony 5.4→6.4	Claude	数日と見込んでいた作業を数時間で実施	包括的な既存テストがあった。プロジェクト規模は非公開
2am.tech⁶	古いLaravelアプリ → 新しいLaravel APIとReact	GitHub Copilotエージェント	垂直な機能単位で移植しながら、権限・メール・状態の欠陥を発見・修正	期間と生産性の数値は非公開
FuelPHP→Laravel⁷	40万行以上、2千以上のファイル	ユーザー定義のRectorルール約80個	PHPファイルの99%を自動変換	2021年の作業でありLLMの事例ではない。約11か月にわたるQAとcanaryが必要

この表でもっとも学ぶべき点は、成果の数値ではなく、公開された失敗です。

Laravel on ROBOCO

バイブコーディングでレガシーをモダナイズする（2/2）：Webの歴史とともに積み重なったPHP

チョン・ドヒョン - ROBOCO首席コンサルタント

TL;DR

1. PHPレガシーはC/C++レガシーと何が違うのか

2. 公開事例が示すこと