先に要点
- 既存システムのフレームワーク特定は 「複数の証拠を重ねて当てる」 のが基本。1 つのヒントで決め打ちすると外れる(特に「ヘッダだけで判定」 は隠蔽されていると当てにならない)。
- 調べる順番は (1) 人 / ドキュメント → (2) リポジトリのマニフェスト → (3) DevTools と HTTP / Cookie → (4) コードベース → (5) AI に読ませて確認。リポジトリにアクセスできるなら 9 割は (2) で終わる。
- フロントは HTML 属性 / グローバル変数 / バンドル名 / Wappalyzer、サーバは レスポンスヘッダ / Cookie 名 / 拡張子 / エラーページ、リポジトリは package.json / composer.json / Gemfile / pom.xml / requirements.txt / build.gradle など、レイヤごとの「決定打」を覚えると速い。
- レガシーシステムでは「フレームワークの上に独自フレームワークが乗っている」パターンも多く、最終的にコードを読まないと判別できないことがある。AI に読ませる アプローチで効率化できる時代になった。
「先輩から引き継いだシステム、何で動いてるか誰も覚えてない」「外注に出した Web サイトを内製で改修したいけど、どのフレームワークか聞いてもらえなかった」「お客さんが 「既存のシステムに機能追加して」 と言ってきたけど、技術スタックが書類に書いてない」 ── レガシー保守や引き継ぎで最初にぶつかる壁です。
ざっくり言うと、フレームワーク特定は 「証拠を集めて積み上げる」 作業で、刑事の現場検証に近いです。1 箇所だけ見て決め打ちせず、フロント / サーバ / リポジトリ / 設定ファイル の複数レイヤから手がかりを集めると、ほぼ確実に当たります。
この記事では、その手順をレイヤごとに整理します。
大前提 — まず人に聞く / ドキュメントを探す
技術的な詮索を始める前に、手間を 1 桁減らせる確認を必ず先にやります。
過去のメンバー / 外注先に聞く
「フレームワークは何ですか」 と聞けば、5 秒で済む可能性が高い。聞ける相手がいるのに自力解析を始めるのは時間の無駄。
提案書 / 設計書 / 見積書
外注した案件なら提案書や見積書に「Laravel 8 を採用」「Spring Boot で実装」 と書いてあることが多い。社内システムなら稟議書、SES 案件なら契約書周辺。
README / docs フォルダ
リポジトリの README.md や docs/ 配下に書いてあるのが理想。「セットアップ手順 → 「composer install」 と書いてある」 → PHP 系、「bundle install」 → Ruby、「mvn package」 → Java、で大半の言語は分かる。
サーバの構成図 / Wiki
社内 Wiki(Confluence / Notion)に「インフラ構成図」「アーキテクチャ図」として残っていることがある。技術選定の経緯まで書いてあれば、判断軸の理解にも繋がる。
「人に聞ける」 「ドキュメントを探せる」 環境なら、以降の技術的解析はほぼ要りません。「誰も知らない / 何も残っていない」 状況に陥ったときに、初めて以下のテクニックの出番です。
ステップ 1 — リポジトリのマニフェストファイルを見る
ソースコードにアクセスできるなら、マニフェストファイル(依存関係を宣言するファイル)で 9 割は決着します。
| ファイル名 | 言語 / プラットフォーム | 特定できるもの |
|---|---|---|
package.json | Node.js / JavaScript | React / Next.js / Vue / Nuxt / Angular / Svelte / Express など |
composer.json | PHP | Laravel / Symfony / CakePHP / CodeIgniter / WordPress プラグイン |
Gemfile | Ruby | Rails / Sinatra / Hanami / Padrino |
requirements.txt / pyproject.toml / Pipfile | Python | Django / Flask / FastAPI / Pyramid |
pom.xml / build.gradle | Java / Kotlin | Spring Boot / Quarkus / Micronaut / Struts |
go.mod | Go | Echo / Gin / Fiber / Beego / chi |
Cargo.toml | Rust | Actix-web / Axum / Rocket / Tide |
*.csproj / packages.config | .NET / C# | ASP.NET MVC / ASP.NET Core / Blazor |
pubspec.yaml | Dart / Flutter | Flutter SDK バージョン、利用パッケージ |
Podfile / Package.swift | iOS / Swift | UIKit / SwiftUI / 各種ライブラリ |
build.gradle(android/ 配下) | Android | Jetpack / Compose / その他依存 |
たとえば composer.json に "laravel/framework": "^10.0" と書いてあれば、即「Laravel 10 系」 と確定します。「package.json に "next": "14.x"」 なら Next.js 14。マニフェストはほぼ嘘をつかないので、最も確度の高い証拠です。
補助的な特徴ファイル
マニフェストが無い古いプロジェクトでも、ルートにある特徴的なファイルでほぼ当たります。
| ファイル / フォルダ | 示唆するもの |
|---|---|
artisan + app/ + routes/web.php | Laravel |
bin/console + config/services.yaml | Symfony |
config/routes.rb + app/controllers/ | Ruby on Rails |
manage.py + settings.py | Django |
app.py 単体 + Flask import | Flask |
main.py + FastAPI ルータ | FastAPI |
src/main/java/ + application.yml | Spring Boot |
wp-config.php | WordPress |
web.config + Global.asax | ASP.NET MVC(古め) |
Program.cs + Startup.cs | ASP.NET Core |
nuxt.config.ts | Nuxt |
next.config.js | Next.js |
vite.config.ts | Vite ベース(Vue / React / Svelte の SPA) |
astro.config.mjs | Astro |
ルートディレクトリの「目立つファイル」 を 1 回見れば、フレームワークはほぼ判別できる、ということです。
ステップ 2 — ブラウザ DevTools で調べる(フロントエンド)
ソースコードが手元にない / Web サイトしか見られない場合は、ブラウザの DevTools が主戦場です。
「ブラウザの DevTools + Wappalyzer」 だけで、Web サイトのフロントは 80 〜 90% の確率で当てられます。
ステップ 3 — HTTP レスポンスヘッダと Cookie を見る(サーバサイド)
サーバ側のフレームワークは、HTTP レスポンスに痕跡が残ります。
X-Powered-By ヘッダ
X-Powered-By: PHP/8.2 / X-Powered-By: Express / X-Powered-By: ASP.NET / X-Powered-By: Next.js など、サーバが自己申告するヘッダ。セキュリティ強化で消されていることも多いが、残っていれば即答。
Server ヘッダ
Server: Apache / nginx / Microsoft-IIS / cloudflare など。Web サーバ自体の特定だが、IIS なら .NET 系、Apache + PHP モジュールならレガシー PHP の可能性、というように絞り込みのヒントになる。
Cookie 名から推測する代表例
| Cookie 名 | フレームワーク / プラットフォーム |
|---|---|
PHPSESSID | 素の PHP / 古めの PHP アプリ |
laravel_session + XSRF-TOKEN | Laravel |
_yourapp_session(_ + アプリ名 + _session) | Ruby on Rails |
JSESSIONID | Java(Tomcat / Jetty / WebLogic / WebSphere) |
ASP.NET_SessionId / .AspNetCore.Session | ASP.NET / ASP.NET Core |
connect.sid | Express(connect 系セッションミドルウェア) |
sessionid + csrftoken | Django |
session(Cookie 値が JWT 風) | Flask(itsdangerous 署名) |
cf_* + __cf_bm | Cloudflare 経由 |
wp-settings-* | WordPress 管理画面 |
NEXT_LOCALE + __Host-next-auth.csrf-token | Next.js + NextAuth |
「Cookie 名は意外と消し忘れられている」 ので、ヘッダが隠されていても Cookie で当たることがよくあります。
ステップ 4 — URL / 拡張子 / エラーページから推測
URL の形にも痕跡が残ります。
拡張子で見る
.php / .asp / .aspx / .jsp / .do(Struts)/ .cgi / .cfm(ColdFusion)など、URL に拡張子が出ているレガシー系は即判別できる。モダンなフレームワークは拡張子無し URL(/users/123)が多い。
管理画面の URL
/wp-admin/ → WordPress、/admin/ + Django 管理画面の見た目 → Django、/_next/ → Next.js、/_nuxt/ → Nuxt、/typo3/ → TYPO3、/drupal/ → Drupal。URL のクセが残る。
「URL / エラーページ / フォーム」 は本来出すべきでない情報源だが、現実には運用で消し忘れられていることが多く、特定の材料になります。
ステップ 5 — DB のテーブル命名で推測
DB にアクセスできる場合、テーブル命名規約がフレームワークの指紋になります。
| パターン | 示唆するもの |
|---|---|
created_at / updated_at カラムが全テーブルにある | Laravel / Rails / Sequelize など Active Record 系 |
migrations テーブル(or schema_migrations) | Laravel / Rails / Phoenix の DB マイグレーション機構 |
django_*(django_session など) | Django |
wp_*(wp_posts など) | WordPress |
ar_internal_metadata | Rails 5+ |
__EFMigrationsHistory | Entity Framework Core(.NET) |
spring_session / SPRING_SESSION_ATTRIBUTES | Spring Session |
テーブル名が複数形(users / posts) | Rails の慣習 |
テーブル名が単数形(user / post) | Laravel ではどちらも、Django は単数形が多い |
「マイグレーション履歴テーブル」 を見るのが最速。migration の中身を開けば、フレームワークの DSL がそのまま残っているので、即答できます。
ステップ 6 — AI に読ませて確認する
2026 年の現実的なアプローチとして、AI コーディング環境にコードベースを読ませて当ててもらうのが速い場面が多くなりました。
Claude Code / Cursor / GitHub Copilot
リポジトリをクローンして Claude や Cursor で開き、「このプロジェクトのフレームワークと言語を特定して」 と頼むだけで、マニフェスト / ディレクトリ構造 / コードのクセを総合して判定してくれる。
人間より速い場面
「Symfony 6 のスタイルだけど内製ラッパー App\Core が乗っている」「Spring Boot 2.x の上に Struts の名残がある」 のようなハイブリッド構成を見抜くのは、AI のほうが速いことも多い。
人間が最終確認すべき理由
AI は「それっぽい答え」 を返すバイアスがある。バージョンや存在しないパッケージを幻覚で返すこともあるので、最終的にマニフェストファイルか実装で確認する。
既存記事との接続
AI に古いコードを読ませる の発展形。フレームワーク特定 → 仕様の再ドキュメント化 → テスト後付け → 段階移植、というレガシー保守の入り口に AI を使うのが現代的。
「自力で grep するより、AI に tree 結果を見せて聞くほうが速い」 という場面が増えました。ただし最終確認は必ず人間が物的証拠を取るのがプロの作法です。
よくある罠
特定作業でハマりやすいパターンを 3 つ。
独自フレームワークが被さっている
「ベースは Laravel だが、社内で App\Framework\Foundation が被さって名前空間も全部書き換えられている」 ような独自ラッパーがある。Laravel の特徴が外見上消えていても、composer.json を見れば本体が分かる。
フロント / バックでフレームワークが違う
「フロントは React、API は Rails」 のような分離構成は普通。「フレームワーク」 を 1 個に特定しようとせず、レイヤごとに別物として考える。
バージョンの嘘
composer.lock / package-lock.json / Gemfile.lock に書いてあるのが実際にインストールされている版。composer.json の ^10.0 表記より、lock ファイルの方が事実に近い。
「1 つの証拠で決め打ちしない」「複数レイヤで照合する」 を守ると、誤判定はほぼ無くなります。
既存システムのフレームワーク特定に関するよくある質問
Q. 一言でまとめると、まず何から見ればいいですか?
A. 「リポジトリのマニフェストファイル(composer.json / package.json / Gemfile / pom.xml など)」 を最初に見てください。これが見られるなら 9 割は決着します。リポジトリにアクセスできない場合は、ブラウザの DevTools(HTML 属性 / Cookie 名 / Network のファイル名)+ Wappalyzer の組み合わせが次に強い。
Q. HTTP の X-Powered-By ヘッダだけで判定して大丈夫ですか?
A. 不十分です。本番運用ではセキュリティ強化のために消されていることが多く、出ているとも限らない。逆に古いまま誤った情報を返しているケースもある(例えば技術スタックを変えたのにヘッダだけ前のまま)。必ず他のレイヤ(Cookie / 拡張子 / 中身)と照合してください。
Q. WordPress かどうかを最速で判定する方法は?
A. サイト URL の末尾に /wp-login.php を付けてアクセスします。ログインページが出れば WordPress 確定。あるいは HTML の <meta name="generator" content="WordPress X.Y"> でも分かりますが、消されていることもあります。What CMS(whatcms.org)も WordPress 判定が得意です。
Q. SPA(React / Vue / Angular)で、API のバックエンドは何か知りたい場合は?
A. API のレスポンスヘッダと Cookie を見る。X-Powered-By や Set-Cookie でフレームワークが推測できます。API のエラー応答形式(JSON 構造)も特徴的(Laravel: {message, errors}、Rails: {errors: [...]}、Django REST Framework: {detail: ...}、Spring: {timestamp, status, error, path})。
Q. 自分の会社のシステムなのに、誰もフレームワーク名を覚えていないことはある?
A. 結構あります。10 年以上稼働しているシステム、外注で作って引き取った後にメンバーが全員入れ替わった、提案書を紛失した、などのパターンで「実は何で動いているか分からない」 という状況は珍しくない。だからこそ、引き継ぎ時にREADME に「フレームワーク名 / バージョン / 採用理由」 を残す習慣が大事です。
Q. 古い PHP プロジェクトで、CakePHP か CodeIgniter か Symfony か区別がつきません。
A. (1) ルートディレクトリのファイル構成を見る。CakePHP は app/Controller/ + cake/、CodeIgniter は application/controllers/ + system/、Symfony は src/AppBundle/(2.x)or src/Controller/(3.x+)+ app/ or config/。(2) composer.json がある場合は require セクションで即判別。(3) コントローラのクラスが何を継承しているか(extends AppController → CakePHP、extends CI_Controller → CodeIgniter、extends AbstractController → Symfony)。
Q. AI に判定させる場合のコツは?
A. 「ファイルツリー + ルートのマニフェストファイル全文」 を AI に渡して、「使われているフレームワーク・言語・主要ライブラリ・バージョンを根拠付きで」 と頼みます。「根拠付きで」 を付けないと、断定的に幻覚を返すことがある。返ってきた答えは必ずマニフェストの該当行を自分で開いて確認してください。
参考リンク
- Wappalyzer: wappalyzer.com
- BuiltWith: builtwith.com
- What CMS: whatcms.org
- Google Chrome DevTools: Get started with DevTools
- 関連記事: 代表的なフレームワークとユースケース / AI でレガシー保守を加速する / 枯れた技術を選ぶ価値