Legacy-Modernization on ROBOCO

バイブコーディングでレガシーをモダナイズする（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が必要

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

バイブコーディングでレガシーをモダナイズする（1/2）：20年もののC/C++アプリケーション

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

エージェントがレガシーC/C++の前で迷うのは、コードが複雑だからではなく、自分の作業が正しいかどうかを確かめる手段がないからです。モダナイゼーションの最初の投資先は、言語移行ではなく検証環境です。

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

バイブコーディング導入のコンサルティングをしていると、似たような悩みをよく耳にします。「うちのプロジェクトは複雑すぎて、エージェントが指示どおりに仕事をしてくれません」。最初は、ドメインが特殊なのか、プロンプトの書き方に問題があるのだろうと考えていました。しかし事例が積み重なるにつれて、共通点が見えてきました。こう話すチームのプロジェクトは、ほとんどが 20年以上前から続くC/C++のコードベース だったのです。

同じチームでも、新しく作ったPythonツールやWeb管理画面ではエージェントをうまく使いこなしていました。したがって、問題はチームの能力やエージェントそのものよりも、コードベースの側にあると考えるのが自然です。本記事では、こうしたレガシープロジェクトをバイブコーディングでモダナイズする方法を、公開事例と研究をもとに整理します。根拠資料は2026年10月15日時点で調査した公開事例・論文・ツールドキュメントであり、各数値は発表主体による自己報告である点もあわせてお断りしておきます。

本記事は、レガシーコードベースのモダナイゼーションを扱う2部作の1本目です。第1部ではC/C++で書かれたレガシーアプリケーションを扱い、第2部ではPHPで書かれたレガシーWebアプリケーションのモダナイゼーション戦略を扱います。

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

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

TL;DR

エージェントがレガシーC/C++で失敗する主な理由は、ビルドを再現できないこと、ポインタの所有権がコードに表れていないこと、変更を検証するテストがないことです（これは私のコンサルティング経験にもとづく解釈です）。
公開されている成功事例（Google giflib、Wiz fastText、Rukuzu）はいずれも、範囲の狭いモジュールを強力な検証とともに 置き換えています。数百万行を一度に別の言語へ翻訳した事例ではありません。
推奨するのは全面的な書き直しではなく、段階的なモダナイゼーションです。既存のコアはModern C++で安定化させ、境界が狭くメモリ欠陥の多いモジュールだけを選択的にRustなどへ移します。
エージェントは調査・変換・テスト・反復修正を担い、人は所有権の設計・互換性の判断・リリースに責任を持ちます。
最初の90日の目標は全面移行ではなく、代表的なモジュールを1つ本番移行し、同じ手順を繰り返せることを証明することです。

1. エージェントはなぜレガシーC/C++で迷うのか

コーディングエージェントは、コードを読み、修正し、ビルドとテストを実行して結果を確認するというループで仕事をします。このループの最後の段階である「確認」が塞がれると、エージェントは自分が修正したコードが正しいかどうかを知ることができません。私が現場で見てきた20年もののC/C++プロジェクトでは、このループが何か所も途切れていました。

第一に、ビルドを再現できません。 特定の開発者のPCに合わせたビルド設定、バージョンが固定されていないベンダーSDK、数十個のプリプロセッサマクロと条件付きコンパイルが絡み合っています。エージェントがクリーンな環境でビルドを実行できなければ、自分の変更がコンパイルできるかどうかすら確認できません。また、同じ関数でも、どのマクロが有効かによって実際にコンパイルされるコードが変わります。実際のコンパイルオプションなしにソースファイルだけを読んだエージェントは、存在しないコードパスを根拠に判断してしまいます。

第二に、ポインタの所有権がコードに表れていません。 古いC/C++コードでは、1つの T* が「このオブジェクトは自分が解放しなければならない」という意味の場合もあれば、「一時的に借りているだけ」という意味の場合もあります。その区別はコードではなく、20年前の作者の頭の中や、すでに失われたWikiの中にあります。エージェントがgrepで呼び出し箇所を見つけても、オブジェクトの破棄後にコールバックが実行されるのか、コンテナの再割り当てによって参照が無効になるのかまではわかりません。そのため、エージェントの修正はもっともらしく見えても、解放後使用（use-after-free）や二重解放を新たに生み出しかねません。

第三に、変更を検証するテストがありません。 テストがあったとしても、少数の正常系だけを扱っていることが多いです。人間の開発者はこの穴を経験と手動テストで埋めてきましたが、エージェントにはそのようなセーフティネットがありません。結果として、エージェントの生成速度は 検証されていない変更量 を増やすだけになります。

まとめると、これらのプロジェクトが「複雑すぎる」からエージェントが失敗するという診断は、半分しか正しくありません。より正確な診断は、エージェントが成否を判断する手段を持っていないということです。だからこそ、モダナイゼーションの最初の投資先は言語移行ではなく、エージェントがオリジナルと新しい実装をビルドし、同じ入力で比較できる検証環境 であるべきです。

2. 公開事例が実際に示していること

エージェントでC/C++をモダナイズした公開事例は、まだ多くありません。そして数字だけを切り出すと、誇張して受け取られやすいものです。以下の表は主要な事例をまとめたうえで、各数値が何を証明し、何を証明していないのかをあわせて記しています。

事例	移行元と移行先	発表された結果	この結果が証明していないこと
Google giflib¹	C 約3千行 → Rust	3千万個以上のGIFで回帰比較、2億回以上の差分ファジング、性能は中立	大規模アプリケーションを一括翻訳できること
Wiz fastText²	C++ 約2万行 → Go	2日間で5,434行のGo、保有するモデル検証テストに100%合格	すべてのAPI・プラットフォーム・学習機能の同等性
Loxation Rukuzu³	Kuzu C++ 約20万行 → Rust	報告時点で15個のcrate、2,700件以上のテスト	20万行全体の機能同等性の完了
Google IDの型変更⁴	32ビット → 64ビットIDへの横断的変更	変更595件のうち74.45%をLLMが生成、総作業時間を約50%削減と推定	言語の全面置き換えの効果
Bun⁵	Zig → Rust（C++ではない）	2週間未満で100万行以上を生成、既存CIをすべて通過	本番での同等性（通過後も回帰が19件見つかった）

これらの事例には繰り返し現れるパターンがあります。GoogleはSIMDやアセンブリを含まない小さなライブラリを選び、C ABI（バイナリレベルの呼び出し規約）をそのまま維持する置き換え実装を目標にしました。初期の変換後、FFI（言語間の呼び出し境界）のメモリ管理が健全でないという問題が見つかり、専門家がunsafeコードを直接レビューしました。Rukuzuは、既存のC++バックエンドと新しいRustバックエンドが同じ抽象インターフェースを実装するようにし、ビルドオプションでどちらかを選べるようにしました。どちらの事例も、まず置き換え可能な境界を作り、その境界の背後で新旧の実装を比較 しています。