PHPのリバースエンジニアリングは、小規模なシステムで1〜2ヶ月、中規模の業務システムやWordPressポータルサイトで2〜4ヶ月、難読化ファイルを含む大規模なシステムで4〜8ヶ月以上が目安です。ただし、期間を最も狂わせるのは「ソースが読めるからすぐ終わる」という思い込みです。
見積もりの前提がずれると、計画全体が後から崩れやすくなります。
- 対象：改修対象と業務条件
- 工程：対象選定から文書化まで
- 確認：品質と運用条件
本テーマに関する全体ガイドは、以下の記事をご覧ください。
▼全体ガイドの記事
・PHPのリバースエンジニアリングの完全ガイド
AI駆動開発の基本や工程ごとの活用方法、費用・期間への影響については、無料ホワイトペーパー「【2026年最新版】AI駆動開発の完全ガイドブック」で詳しく解説しています。
PHPリバースエンジニアリングの開発期間が読みにくい理由
PHPはインタープリタ型のスクリプト言語のため、通常はソースコードがサーバー上にそのまま置かれています。そのため「バイナリ解析のような手間はかからない」と楽観的に見積もられがちです。
ただ、実際の期間を左右するのは、コードが読めるかどうかより、設計意図まで正確に読み解けるかどうかです。
変数名が意味を持たない短縮形になっていたり、コメントがまったく残っていなかったりするコードは珍しくありません。その結果、コードが「どう動くか」は追えても、「なぜそう実装されているか」は不明なままになるケースが大半です。この構造的なギャップが、見積もりを難しくしている最大の要因です。
「ソースが読める＝解析が簡単」という誤解が招く過小見積もり
COBOLはJCLやCOPY句を展開しなければ全体像が見えない言語ですが、PHPは一見すると解析のハードルが低そうに見えます。その印象から、「1週間もあれば終わるだろう」と楽観的なスケジュールを組んでしまう発注担当者が少なくありません。
実際には、長年の改修で継ぎ足された条件分岐や、includeやrequireが多段になった制御フローが複雑に絡み合っています。さらに、グローバル変数の多用によってデータの流れを追うのも難しく、「読めるが理解しにくい」コードが大量に存在します。
着手前にこの誤解を解いておかないと、当初想定の1.5〜2倍の期間がかかった段階で、初めて事の重大さに気づくことになりかねません。
バージョン・フレームワーク・難読化の有無で工数が数倍変わる構造
同じPHPシステムでも、LaravelやCakePHPで整然と構築されたコードか、フレームワークを使わない生PHPのスパゲッティコードかによって、解析にかかる時間は大きく変わります。
PHP4.x・5.x時代のレガシーコードには、廃止済みの関数（mysql_connect・split・ereg等）や短縮タグが混在しています。そのため、現行の解析ツールやテスト環境と相性が悪く、動的解析ができずに静的解析だけに頼る場面が生じます。
さらに、ion.cubeやSourceGuardianによる商用難読化が施されたファイルがあると、その解除だけで別途工数が発生します。これら複数の要因が重なることで、同じ行数のシステムでも期間は数倍の幅になるのが実態です。
規模・工程別に見る開発期間の目安
PHPのリバースエンジニアリングは、対象選定、環境構築、静的解析、動的解析、設計レベルへの抽象化、成果物化という一連の工程で進めるのが一般的です。そのため、全体のスケジュールを描くには、工程ごとの期間を個別に把握しておく必要があります。
対象選定〜静的解析までの期間
対象選定では、まずPHPコードの一覧を作り、目的をはっきりさせます。一覧には、バージョンやフレームワーク、難読化ファイルの有無などを書き込みます。小規模なシステム（ファイル数十本、総行数4,000行程度、ECサイトの商品登録機能など）であれば、この段階は1〜2週間が目安です。
続く静的解析では、PhpStormのコール階層表示、PHPStanによる型解析、UMLクラス図の自動生成機能を使い、クラス構造や依存関係、データベース操作のパターンを把握します。同じ規模で標準的なケースなら、2〜4週間が目安です。
ただし、フレームワークを使わない生PHPのスパゲッティコードで、include/requireの多段構造が複雑に絡み合っている場合は、1〜2ヶ月に伸びることも珍しくありません。たとえば、WordPressのポータルサイト（総行数1万行前後）のCMS構造解析なら、静的解析だけで1〜1.5ヶ月程度を見込むのが現実的です。
動的解析〜仕様書化までの期間
動的解析では、Xdebugによるステップ実行やBlackfireによるプロファイリングを使います。WordPressであればQuery Monitorプラグインも用い、実際の業務フローが実行されたときに、どのファイルのどの関数が呼ばれるかを追跡します。
静的解析では把握しきれない、条件分岐の実際の動作や外部API連携、セッション管理の挙動を確かめます。この工程は、標準的な規模で2〜4週間を見込みます。その後の抽象化（Design Recovery）から文書化までは、実装レベルの制御フローを業務機能単位の設計ドキュメントや、仕様レベルの業務仕様書へ引き上げる工程です。
どの深さまで文書にするか（フローチャートのみか、詳細設計書まで求めるか）によって、2〜8週間程度の幅があります。これらを合算すると、小規模プロジェクトは1〜2ヶ月、中規模のWordPressポータルサイトや業務システムでは2〜4ヶ月、大規模で難読化ファイルを含むシステムでは4〜8ヶ月以上を要することもあります。
開発期間が長期化する主な要因
工程ごとの期間目安を押さえたうえで、実際のプロジェクトで納期が計画どおりに進まなくなる典型的な要因を理解しておくことが、現実的なスケジュールを組むうえで欠かせません。
ion.cube・SourceGuardian難読化コードの解除工数が読めない問題
事前に対象ファイルを洗い出しても、着手して初めて判明することがあります。たとえば「このプラグインの一部ファイルがion.cubeで暗号化されていた」「SourceGuardianのシグネチャは確認できたが、正規のデコーダがない」といったケースです。これらはオペコード単位で暗号化されるため、通常のPHP解析ツールでは中身を確認できず、解除には専用の技術知識と法的な判断の両方が必要です。
難読化ファイルが対象に含まれると、解析工数は標準料金の30〜100%程度上乗せされるのが一般的な相場です。ただ、着手前にその比率を正確に知ることは難しく、これがPHPリバースエンジニアリング特有の期間の読みにくさを生む最大の要因になっています。
発注側と開発会社は、契約前の提案段階で、難読化ファイルが見つかった場合の追加期間と追加費用の合意の進め方を、あらかじめ定めておくことが不可欠です。
業務ロジックの「Why」解明に伴う業務部門ヒアリングの遅延
コードを読めば「何をしているか（How）」は分かりますが、「なぜその仕様になっているのか（Why）」は、コードからは判断できません。長年の運用で継ぎ足された条件分岐やWordPressの独自カスタマイズには、当時の担当者しか知らない業務上の理由が埋め込まれていることが多くあります。
Whyを解明するには、業務担当者へのヒアリングが欠かせません。ただ、業務部門の繁忙期や担当者の異動で、日程調整が難航することがあります。こうなると、解析チームの作業は終わっているのに、ヒアリング待ちで工程全体が止まる事態が頻繁に起きます。
この遅延を防ぐには、解析チームが「How」を読み解き、業務担当者が「Why」を補う協働体制を、静的解析の段階から並行して立ち上げておくことが最も効果的です。
納期を守るための進め方
長期化の要因を踏まえると、納期を守るには、解析ツールを活用して作業を短くする方法と、着手の順番を工夫する方法の2つが有効です。
静的解析ツール（PHPStan・PhpStorm・UnPHP等）による期間短縮
PhpStormのコード解析機能やPHPStan、PHP_CodeSnifferといった静的解析ツールは、クラス構造や関数の依存関係を自動で一覧にします。そのため、手作業で洗い出す場合に比べて、解析フェーズの期間を大幅に短縮できます。
オープンソースの逆難読化ツール（UnPHP等）は一部の難読化パターンに有効ですが、アルゴリズムに依存するため万能ではありません。ion.cubeやSourceGuardianのような商用エンコーダには、通用しないケースが大半です。
汎用ツールに加えて、PHP・WordPress特有の解析実績があるツールと専門技術者による解析を組み合わせることが、期間短縮に直結します。
機能単位のパイロット選定による段階的着手
全システムを一括で解析する進め方では、難読化ファイルや想定外のスパゲッティコードが見つかったときに、全体スケジュールへの影響が大きくなります。加えて、納期のリスクも高まります。
一方で、業務への影響が比較的小さく独立性の高い機能（受注処理・在庫管理・管理画面など）から、パイロット領域として先に着手する段階的な進め方が有効です。そのうえで、実際の解析工数を実測し、残りの範囲のスケジュールの精度を高めます。
パイロット領域での実測値から、「1万行あたり何人日かかるか」という自社システム固有の解析生産性を把握できます。これにより、以降のフェーズの見積もり精度が大きく向上します。
依頼先選定・着手タイミングが期間に与える影響
同じ規模・技術構成のPHPシステムでも、どのパートナー企業に依頼するか、いつ着手するかによって、開発期間は大きく変わります。
PHP・WordPress解析実績とクリーンルーム体制の確認基準
依頼先を選ぶ際は、「PHP対応可能」という説明に加えて、解析実績を見ることが重要です。見るべきは、対象のPHPバージョン（5.x/7.x/8.x）や利用フレームワーク（Laravel・CakePHP・WordPress等）に応じた実績を、具体的に示せるかどうかです。
この実績が乏しいベンダーに依頼すると、静的解析の途中で難読化コードやバージョン差異にぶつかります。そのため体制を立て直すことになり、結果として期間全体が想定以上に伸びるリスクが高まります。
発注側は、解析チームと開発チームを分けるクリーンルーム体制の整備状況や、成果物の粒度と品質基準がどれだけ明確かを確認しておくと、着手後の手戻りを防げます。
PHP7.x以前のEOL進行と着手を先送りするほど期間が伸びる構造
PHP7.x系は、すでにすべてのバージョンでセキュリティサポートが終了しています。そのため、これらのバージョンで稼働し続けているシステムは、緊急度が高い状態にあります。
着手を先送りするほど、当時のカスタマイズやWordPress独自フックの意図を説明できる有識者が、すでに退職している事態に直面しやすくなります。すると、いざ着手したときにヒアリングの協力者を確保できず、期間がむしろ長くなるという逆説的な構造が生まれます。
担当エンジニアが退職予定で、急いで知識を保存したいと考えて動き出すプロジェクトも多いですが、退職の2〜3ヶ月前では十分な期間を確保できません。そこで、余裕のあるうちに対象を選んで現状を洗い出すだけでも早く始め、有識者が在籍しているうちにヒアリングを進めておくことが、期間を現実的に管理する最も有効な備えです。
まとめ
期間が読みにくい理由と工程・規模ごとの目安を整理したうえで、長期化の要因、納期を守る進め方、依頼先の選び方まで解説してきました。
期間を正しく見積もる鍵は、「ソースが読める言語だからすぐ終わる」という誤解を捨て、バージョン差異やフレームワークの有無、難読化が絡み合う複合的な調査として捉えることです。
目安は、小規模なシステムで1〜2ヶ月、中規模のWordPressポータルサイトや業務システムで2〜4ヶ月、難読化ファイルを含む大規模なシステムで4〜8ヶ月以上です。ion.cubeやSourceGuardianによる難読化の発覚や、業務部門へのヒアリングの遅れが、計画を崩す典型的な要因になります。
静的解析ツールの活用、パイロット領域からの段階的な着手、PHP・WordPressの解析実績が豊富なパートナーの選定が、現実的な納期への近道です。
PHP7.x以前のEOLはすでに到来しています。着手を先送りするほど有識者の退職リスクが高まり、期間がかえって伸びます。その構造を踏まえ、余裕のあるうちに対象範囲を絞って現状を洗い出すことから始め、実績のあるパートナーに早めに相談することをお勧めします。
▼全体ガイドの記事
・PHPのリバースエンジニアリングの完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。