相談する

PHPのリバースエンジニアリングの進め方/やり方/流れや方法/手法/工程/手順

PHPのリバースエンジニアリングは、目的の明確化から成果物の作成まで、6つの工程を順番に踏んで進めます。

PHPはソースコードを読めるぶん解析が簡単に見えがちですが、難読化されたコードや長年改修されたコードの解析には専門知識と体系的な進め方が必要です。費用の目安や外注判断のポイントも取り上げるため、発注を検討している方にも参考になります。

▼全体ガイドの記事
・PHPのリバースエンジニアリングの完全ガイド

AI駆動開発の基本や工程ごとの活用方法、費用・期間への影響については、無料ホワイトペーパー「【2026年最新版】AI駆動開発の完全ガイドブック」で詳しく解説しています。

PHPのリバースエンジニアリングとは：他言語との根本的な違い

PHPを中心に、サーバー上のソースコードと難読化解除、設計意図の解読を注釈で示した図解
コードの有無に加え、読解と意図の把握が論点になります。

リバースエンジニアリングと聞くと、コンパイル済みのバイナリを逆コンパイルして元のソースコードを復元する作業を思い浮かべる方が多いかもしれません。PHPの場合は、事情が大きく異なります。

PHPはインタープリタ型のスクリプト言語で、通常はソースコードがそのままサーバー上に存在しています。ソースコードが残っているので、C言語やJavaのように「バイナリからソースを復元する」作業は、原則として必要ありません。

PHPリバースエンジニアリングの主な論点：難読化解除と設計意図の解読

PHPのリバースエンジニアリングで主な論点になるのは、「難読化解除」と「設計意図の解読」の2点です。

  • 難読化解除：ion.cubeやSourceGuardianで暗号化・難読化された商用スクリプトがあり、解読には専用のデコーダや深い技術知識が必要
  • 設計意図の解読：難読化がなくても、長年の改修でコードが複雑に絡み合い、元の設計意図を読み解くことが困難になるケースは頻繁にある

変数名が意味を持たない短縮形になっていたり、コメントがまったく残っていなかったりすると、コードは「どう動くか」は分かっても「なぜそのような実装になっているか」が理解できないのです。

暗号化された商用スクリプトの無断解読は、法的にグレーゾーンとなるケースもあるため、取り扱いには細心の注意が必要です。

主な用途：WordPressカスタマイズ・バージョンアップグレード・仕様書復元

PHPのリバースエンジニアリングが求められる場面は、WordPressプラグインやテーマのカスタマイズ、レガシーPHPシステムのアップグレード、仕様書の復元です。

  • WordPressのカスタマイズ：サードパーティ製プラグインの特定の処理がどのような仕組みで動いているかを解析したうえで、安全に改変・拡張する
  • アップグレード：PHP 4.x・5.xのコードはPHP 8.xと非互換が多く、単純な置き換えでは動作しない。廃止予定の関数や構文の洗い出しが欠かせない
  • 仕様書の復元：外注先の設計書がない場合や、業務の変遷でドキュメントが陳腐化している場合に、現行コードから仕様を逆算する

WordPressポータルサイトのCMS構造解析に約60万円を要した事例のように、規模によってはまとまったコストが発生します。正確な仕様把握なしに次のシステム開発を進めるリスクを考えれば、こうしたコストも投資として合理的な選択です。

ポイント

PHPの解析では、ソースが残っているか、難読化されているかの2点で作業の性質が大きく変わります。依頼範囲を決めるときは、この2点を先に切り分けておくと判断を誤りにくくなります。

PHPのリバースエンジニアリング6工程：全体の流れと手順

対象選定と解析環境の構築から静的・動的解析を経て、設計の抽象化と成果物化へ進む流れ図
前半で対象と環境を整え、解析結果を設計情報へまとめます。

PHPのリバースエンジニアリングは、場当たり的に進めると重大な見落としが生じがちです。

次の工程を順番に踏むことで、漏れのない解析と有用な成果物の作成につながります。

  1. 工程1・2：解析対象の選定と目的の明確化、解析環境の構築
  2. 工程3・4：静的解析と動的解析の実施
  3. 工程5・6：設計レベルへの抽象化と成果物の作成

工程1・2：対象選定・目的の明確化と解析環境の構築

工程1・2では、最初に解析対象となるPHPコードの全量を把握し、解析の目的を明確にします。そのうえで、作業環境を整えます。

  1. 対象の把握：ファイル数、総行数、PHPのバージョン、フレームワーク（Laravel、CakePHP、Symfony、またはフレームワークなし）を洗い出す
  2. 難読化の確認：ion.cubeやSourceGuardianの暗号化ファイルがないかを見る。ある場合は法的リスクを法務部門とすり合わせ、対応方針を決める
  3. 解析環境の構築：本番環境への影響を完全に排除した専用の隔離環境を用意する
  4. 静的解析ツールの準備：PhpStormのコード解析機能、PHPStan、PHP_CodeSnifferが有効
  5. 動的解析ツールの準備：Xdebugを使ったステップ実行や、Blackfireによるプロファイリングが有効

PHPの場合は、オープンソースの逆難読化ツール（UnPHP等）も活用できますが、難読化のアルゴリズムに依存するため万能ではありません。

工程3・4：静的解析と動的解析の実施

工程3・4では、コードを読む静的解析と、システムを動かして調べる動的解析を行います。

  1. 静的解析：ソースコードをそのまま読み、クラス構造、関数の依存関係、データベース操作のパターンを把握する
  2. 依存関係の可視化：PhpStormのコール階層表示やUMLクラス図の自動生成機能を使うと、コード全体を視覚的に把握できる
  3. 動的解析：実際にシステムを動作させながらXdebugでステップ実行し、特定の業務フローごとに呼ばれるファイルと関数をトレースする
  4. 動的解析で分かること：静的解析で把握しきれない条件分岐の実際の動作、外部APIとの通信内容、セッション管理の挙動
  5. WordPressの場合：Query Monitorプラグインを使うと、フック・フィルターの呼び出し順序やデータベースクエリの全量をリアルタイムで確認できる

特にPHPのレガシーコードでは、グローバル変数の多用、関数内での直接SQL文発行（SQLインジェクション脆弱性の温床）、include/requireの多段構造による制御フローの複雑化がよく見られます。

工程5・6：設計レベルへの抽象化と成果物化

工程5・6では、解析で得た情報を「実装レベル」から「設計レベル」「仕様レベル」へ段階的に抽象化し、ドキュメントにまとめます。この工程はDesign Recoveryと呼ばれます。この作業には業務知識が欠かせないため、技術者だけでなく業務部門の担当者が積極的に関わることが成功の鍵になります。

  • 抽象化の例：個々の関数の働きという実装レベルの情報を、「この機能は○○業務の△△プロセスを担っている」という仕様レベルの記述に変換する
  • 業務部門の関与：「なぜその仕様か（Why）」は、業務担当者にしか分からない情報が多い

解析結果は、どこまで詳しく残すかによって、フローチャート、業務仕様書、詳細設計書の3種類のドキュメントにまとめられます。

  • フローチャート：最も簡略で、処理の流れを図示する
  • 業務仕様書：画面遷移、業務ルール、例外処理まで記述する
  • 詳細設計書：DB設計、API仕様、クラス設計まで含める

ドキュメントの粒度が上がるほど工数と費用は増えますが、そのぶん次のシステム開発への活用度も大幅に高まります。

ポイント

工程1・2で対象の範囲と目的を先に決めておくと、工程5・6で作る成果物の粒度も決めやすくなります。動的解析は、静的解析で把握しきれない条件分岐を確かめる段階として捉えると進めやすいです。

PHP固有の注意点と難読化・暗号化への対処

PHPのリバースエンジニアリングには、他の言語では起きにくいPHP特有の問題があります。そこで、これらを事前に把握しておけば、プロジェクトの途中で想定外のコストや法的リスクが生じる事態を防げます。

典型的な失敗パターン：バージョン差異と業務ロジック欠損

失敗は、バージョンの差異を見落とす場合のほかに、業務ロジックの意図が欠損したまま仕様書が完成してしまう場合もあります。

  • バージョン差異の見落とし：PHP 5.x時代のコードをそのまま解析して、PHP 8.x向けの仕様書を作ろうとする
  • 差異の中身：型システムの強化、廃止された関数群（mysql_*系関数の全廃など）、エラーハンドリングの仕様変更など、互換性を壊す変更が多数ある
  • 業務ロジックの意図の欠落：コードから分かるのは処理の事実で、なぜその条件でAの処理をするのかという業務上の理由は、コードのどこにも書かれていないことがある
  • ヒアリング不足：業務部門の担当者へのヒアリングを設計フェーズに組み込まないと、移行後にビジネスロジックのバグが多発するリスクが高まる

バージョン差異は、解析と並行して整理しておかないと、作成した仕様書が実際のアップグレード作業に使えないものになります。

ion.cube・SourceGuardian難読化コードへの現実的な対処法

ion.cubeやSourceGuardianで保護された商用PHPスクリプトの解読は、技術的にも法的にも高いハードルがあります。技術面では、これらのエンコーダがオペコードレベルで暗号化を行うため、通常のPHP解析ツールでは内容を確認できません。

法的には、ソフトウェアのEULA（使用許諾契約）に「リバースエンジニアリング禁止」条項が含まれている場合が多くあります。商用スクリプトの無断解読は、著作権侵害や契約違反に問われる可能性があります。そのため、無断で解読する前に、ベンダーへ開示を求める交渉ができないかを検討します。

  • 開示の交渉：まずソフトウェアベンダーに、ソースコードの開示を正式に求める
  • 交渉の余地がある例：サポートが終了した製品や、互換性の確保が目的の場合には、交渉が成立するケースもある

交渉が困難な場合は、自社が正規にライセンスを保有するソフトウェアについて、保守・修正の目的で最小限の解析を行うことは、著作権法上許容される範囲内であるという解釈もあります。いずれにせよ、法務部門との連携と詳細な記録の保持が不可欠です。

ポイント

暗号化されたファイルや古いPHPコードが含まれる場合は、解析の前に法務部門と方針をすり合わせ、業務部門へのヒアリングを計画に入れておくと、途中のコストや法的リスクを抑えられます。

解析チーム、法務・仲介担当者、開発チームを上下の層に分けたクリーンルーム手法の図解
仕様書の受け渡しに法務・仲介担当者が入ります。

PHPシステムのリバースエンジニアリングを進めるには、法的リスクを把握して回避策を講じることが欠かせません。そのため、日本の著作権法の枠組みとクリーンルーム手法を理解しておくと役立ちます。

2018年の著作権法改正（第30条の4）により、著作物に表現された思想・感情の享受を目的としない情報解析・研究目的のリバースエンジニアリングは、原則として合法化されました。

マルウェア解析、セキュリティ調査、仕様書復元のような「非享受目的」の行為が、これに該当します。そのため、PHPシステムの仕様書を復元するためにコードを解析する行為は、この規定の範囲内に収まる可能性が高いといえます。

合法化の条件となる「非享受目的」であることは、事後的に立証できるよう備えておく必要があります。具体的には、解析の進め方と成果物の管理を、あとから示せるように残しておきます。

  • 解析の進め方：解析専用の隔離環境で作業を行い、解析のプロセスをレポートとして記録に残す
  • 成果物の管理：解析で得られた情報（機能・アルゴリズム）と著作権保護の対象となる「表現」を明確に分けて、仕様書に著作権保護対象の記述が混入しないよう管理する

クリーンルーム手法の実務：解析チームと開発チームの分離

クリーンルーム手法とは、解析チーム（Dirty Room）と開発チーム（Clean Room）を完全に分離し、両者の間に法務・仲介担当者を配置することで、著作権侵害（依拠性）を回避する手法です。

1980年代のフェニックス・テクノロジーズによるIBM BIOS互換製品の開発で用いられた実績があり、セガ対アッコレード事件でも法的有効性が認められています。

PHPシステムのリバースエンジニアリングをベンダーに外注する場合は、そのベンダーにクリーンルーム体制が整っているかを確かめておく必要があります。解析する側と開発する側を切り離すには、各担当が何を受け持つかを明確にしておきます。

  • 解析チーム（Dirty Room）：PHPコードを解析し、仕様書を作成する
  • 法務・仲介担当者：仕様書をレビューし、著作権保護対象となりうる「表現の模倣」が含まれていないかをチェックしたうえで、開発チームに引き渡す
  • 開発チーム（Clean Room）：元のPHPソースコードを一切参照せず、仕様書のみを基に新たなシステムを構築する

担当を分けて進めることで、元コードへの「依拠性」がないことを立証できます。

ポイント

暗号化された商用スクリプトを扱うかどうかは法務部門と先に決め、外注する場合はクリーンルーム体制の有無を選定の基準に加えると判断しやすくなります。

外注vs内製の判断軸：PHPリバースエンジニアリングの担当の決め方

PHPのリバースエンジニアリングを内製で行うか外部ベンダーに委託するかは、対象システムの規模、社内の技術力、法的リスク管理体制の3点で決めます。

内製が適しているケース：小規模・自社開発コードの場合

内製での対応が適しているのは、次のような場合です。

  • 対象が自社開発のコード：著作権の問題が生じないケース
  • 小規模な対象：ファイル数が数十程度のWordPressプラグインのカスタマイズや社内ツールの仕様把握
  • 担当者：PHP開発の経験がある社内エンジニアが、静的解析ツールを使って対応できる場合がある

メリットと負担の両面を見ておく必要があります。

  • 利点：PHPの解析作業を通じてエンジニアが対象システムへの理解を深め、その後の保守運用の効率が向上する
  • 工数：解析のための工数確保に注意が必要
  • 成果物の品質：解析担当者の主観的な解釈が成果物に反映されると、仕様書の精度が低下する
  • 日常業務への影響：通常の開発業務と並行して行うには負荷が高く、担当者の日常業務に影響を与えるリスクがある

内製の場合は、専任体制とレビュープロセスを設けることが、高品質な成果物を得る条件です。

外注が適しているケース：大規模・難読化コード・法的リスクがある場合

外注が向いているのは、次のような場合です。

  • 大規模なシステム：ファイル数が数百以上、総行数が数万行超
  • 難読化されたコード：ion.cubeやSourceGuardianによる難読化が施されている
  • 法的リスクがある場合：サードパーティ製商用PHPスクリプトが絡む

専門ベンダーは、PHP解析の実績とツール・ノウハウを持つため、内製よりも短期間・高精度で成果物を作成できます。

解析の費用は、対象の規模と作業の範囲で大きく変わります。

  • 小規模なシステム（4,000行程度）：ソースコード解析による仕様書復元で、約30万円が目安
  • WordPressポータルサイト：CMS構造解析で約60万円
  • セキュリティ確認を含む大規模システム（30ファイル前後）：約80万円が相場
  • フルアップグレードへの発展：解析をPHP 8.xへのフルアップグレード・リビルドに発展させると、5億円以上・期間18ヶ月以上のプロジェクトになる可能性がある

リバースエンジニアリング単体の費用は、「次の開発に向けた投資」として評価することが欠かせません。

ポイント

規模が大きい、難読化されている、法的リスクがあるといった条件に当てはまるなら外注を検討し、小規模で自社開発のコードなら内製を検討する、という切り分けが目安になります。

まとめ：PHPリバースエンジニアリングを成功させるための要点

PHPのリバースエンジニアリングは、「コードから設計意図を読み解く」作業です。他のコンパイル型言語のように、バイナリから元のコードを復元する作業とは性質が異なります。

ソースコードが読める言語であるため解析のハードルは低く見られがちですが、難読化コードへの対処、業務ロジックの意図把握、PHPバージョン間の非互換への対応など、専門知識を要する場面は多くあります。

成功のポイントは、まず発注前に目的と成果物の粒度を明確にすることです。

次に、業務部門を解析プロセスに積極的に巻き込み、「Why（なぜその仕様か）」を記録しておく必要があります。さらに、法的リスクを事前に評価し、必要に応じてクリーンルーム体制を整えます。

そして、解析規模に応じて外注を積極的に活用すると、専門ベンダーの知見を借りられるため、成果物の品質とプロジェクトスピードを両立できます。PHPリバースエンジニアリングを正しい手順で進めることが、レガシーシステム刷新プロジェクトの成否を大きく左右します。

▼開発を相談する前に読みたい無料ホワイトペーパーはこちらをご覧ください。
・【2026年最新版】AI駆動開発の完全ガイドブックをご覧ください。

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。