FuelPHPで構築したシステムを、今も現役で使い続けている。動いてはいるものの、フレームワークの正式な更新は止まり、PHPのバージョンも古いまま。このままでよいのかと不安を感じている担当者の方は少なくないはずです。
この記事では、FuelPHPのサポート状況とPHP 8で動くのかという疑問に答えたうえで、使い続けるリスク、移行先としてLaravelが選ばれる理由、移行の難所を整理し、約25万行の基幹システムをFuelPHPからLaravelへ移行した当社の事例を紹介します。
FuelPHPのサポート状況
FuelPHPは2011年に登場したPHPフレームワークで、軽量で自由度が高く、2010年代前半には国内でも多くのシステムに採用されました。しかし現在、正式版の更新は止まっています。
- 最後の安定版は2019年6月リリースの1.8.2で、以降7年以上新しい安定版が出ていない
- 1.8.2が公式に対応を明記しているPHPは7.3までです。PHP 8系に対応する1.9は開発版のまま正式リリースされていない
- 後継として2015年にアルファ版が公開された2.0は、リポジトリの更新が2017年で止まり、開発チームは設計を一新する計画そのものを取りやめている
一方、PHP本体は7.4のセキュリティサポートが2022年11月に終了しています。つまりFuelPHP 1.x系のシステムは、フレームワークとPHP本体の両方でセキュリティ修正を受けられない状態で稼働していることになります。
FuelPHPとPHP 8の対応状況
フレームワークはそのままで、PHPだけを8系に上げられないか。このご相談もよくいただきます。答えは「安定版のままでは動かず、開発版に載せ替えれば動く」です。
安定版の1.8.2が公式に対応をうたうのはPHP 7.3までです。公式ドキュメントの動作要件は「PHP 5.3.3以上、PHP 7に完全対応」、GitHubのREADMEは「PHP 7.3に完全対応」とあり、PHP 8への言及はありません。PHP 8で動かすには、開発版の1.9/developブランチに載せ替える必要があります。
開発者は2025年8月の公式フォーラムで、1.9-devはPHP 8.4まで対応しており、自社の開発はすべてこのブランチで行っていると答えています。ただし同じ投稿で、テストが不足していてコードのすべてを検証できていないこと、1.9の正式版はPHP 8.5が出てから検証したうえで出す予定であることも認めています。PHP 8.5は2025年11月にリリース済みですが、この記事を更新した2026年9月の時点で、公式サイトが案内する最新版は1.8.2のまま、開発ブランチのバージョン表記も「1.9-dev」のままです。GitHub上には2021年12月付で「1.9.0」というバージョン番号のタグが付いていますが、公式サイトのリリース一覧には載っておらず、開発チーム自身が1.9を「これから出す」と語っている以上、正式版として案内されたものではありません。
| 1.8.2(安定版) | 1.9/develop(開発版) | |
|---|---|---|
| 公開 | 2019年6月 | 正式リリースなし(2026年9月時点) |
| 対応PHP | 7.3まで(公式ドキュメント・README) | 8.4まで(開発者のフォーラム回答) |
| 位置づけ | 公式サイトが案内する最新版 | 開発中。テストは不十分と開発者自身が説明 |
発注側にとって重要なのは、開発版を本番で使うことの意味です。動かすこと自体はできても、脆弱性が見つかったときに誰がいつ修正するのかの保証はなく、PHP本体は毎年新しいバージョンが出て、古いバージョンのセキュリティサポートは順次終了していきます。そのたびに開発版の追従を待ち、載せ替え後の動作確認を自社で引き受けることになります。載せ替えの作業自体も、依存ライブラリの版が上がっているため、ファイルを差し替えるだけでは済みません。PHPのバージョンアップが目的であっても、結局はフレームワークごと移行するかどうかの判断に行き着きます。
使い続けた場合のリスク
「動いているから問題ない」と先送りしたくなりますが、時間の経過とともにリスクは着実に大きくなります。
セキュリティリスク。 脆弱性が見つかっても、修正版が正式に提供される保証はありません。外部公開しているシステムであれば、攻撃の入口になり得ます。
動作環境の維持の難しさ。 古いPHPを動かせるOSやミドルウェアは年々減っていきます。サーバーの更新やクラウド移行のたびに、古い環境を維持するための追加コストが発生します。
保守人材の確保難。 FuelPHPの経験者は年々減っており、新しく学ぶエンジニアはほぼいません。改修のたびに対応できる人を探すのが難しくなり、属人化が進みます。
改修コストの増大。 ドキュメントが残っていない、仕様を知る担当者が退職した、といった状態が重なると、小さな改修にも大きな調査工数がかかるようになります。
こうしたリスクはFuelPHPに限らず、レガシーシステム全般に共通する構図です。放置するほど移行の難易度と費用が上がるため、どこかで移行を決断する必要があります。
「オワコン」と言われる理由と使い続ける判断の基準
FuelPHPについて調べると「オワコン」という言葉が目に入ります。開発が完全に止まっているわけではありません。GitHubの開発ブランチには2026年に入ってもコミットが続いています。それでもそう言われる理由は、大きく3つあります。
1つ目は、正式なリリースが7年以上ないことです。1.9の正式版は、2022年1月の時点で開発者が「リリースできるよう努力する」と答えていましたが、2026年9月現在も出ていません。2つ目は、後継バージョン2.0の開発が止まったことです。2015年1月にアルファ版が公開されたものの、リポジトリの更新は2017年4月が最後で、開発者は2021年に、当初の2.0の設計は既存アプリケーションの継続性を損なうため取りやめたと説明しています。3つ目は、開発が実質的に一人の開発者に支えられていることです。2024年以降の開発ブランチのコミットは9割以上が同じ開発者によるもので、その開発者自身が2019年にフレームワークの将来を問われ、「正直なところ、私にもわからない」とフォーラムで答えています。
公平に見れば、FuelPHPは見捨てられたフレームワークではなく、一人の開発者の会社が自社の開発のために保守を続けているフレームワークです。ただ、企業システムの基盤に求められるのは、今動いているかどうかではなく、5年後も安全に動かし続けられる体制があるかどうかです。リリース計画と修正期限が公開されているか、脆弱性に対応する体制があるか、保守を任せられる人材を採用できるか。FuelPHPはこの3つのいずれも満たしにくくなっています。対照的にLaravelは、毎年のメジャーリリースと、各バージョンのバグ修正18か月・セキュリティ修正2年という期限を公開しています。
オワコンかどうかの議論より大切なのは、自社のシステムをいつ、どう移すかを決めることです。使い続けるなら、誰がPHPの更新に追従し、誰が脆弱性に対応するのかを決めておく必要があります。移行するなら、次に述べるLaravelが現実的な移行先になります。
移行先にLaravelが選ばれる理由
FuelPHPからの移行先としては、同じPHPのフレームワークであるLaravelが選ばれるケースが大半です。理由は明快です。
- PHPの資産を活かせる。 言語が同じため、業務ロジックの多くを引き継ぎやすく、別言語への移行に比べて費用と期間を抑えられます
- デファクトスタンダードである。 LaravelはPHPフレームワークの中で最も広く使われており、開発が活発に続いています。毎年メジャーバージョンが更新され、最新のPHPに追従しています
- 人材が豊富。 国内のPHP求人はLaravel案件が中心で、保守を引き継げるエンジニアを確保しやすい状況です
- エコシステムが充実している。 認証、テスト、キュー処理などの周辺機能が公式に整備されており、FuelPHP時代に自作していた仕組みを標準機能に置き換えられます
機能を変えずにフレームワークだけを新しくする移行は、リライトと呼ばれる方式です。移行方式ごとの費用の違いはシステムマイグレーションの費用相場で解説しています。
Laravelへの移行の難所
同じPHPとはいえ、FuelPHPとLaravelは設計思想が異なるため、移行は単純な作業ではありません。難所は主に4つあります。
書き換えが全面に及ぶ。 ディレクトリ構成、ルーティング、ORM(データベース操作の仕組み)、認証、バリデーションなど、フレームワークに依存する部分はすべて書き直しになります。ソースコードの大半に手が入ると考えるべきです。
仕様の把握に時間がかかる。 FuelPHP時代のシステムは構築から10年前後が経過していることが多く、設計書が残っていない、仕様を知る担当者がいない、といった状態が珍しくありません。コードを読み解いて仕様を復元する作業が移行工数を押し上げます。
テストの工数が膨大になる。 移行前とまったく同じように動くことの確認には、プロジェクト全体の半分近い工数がかかることもあります。ここを削ると本番切替後の障害に直結します。移行期間全体に占めるテストの比重はシステムマイグレーションの期間はどのくらい？で解説しています。
移行中も業務は止まらない。 人手による移行は規模によっては年単位のプロジェクトになり、その間の機能改修をどう扱うかが問題になります。改修を長期間凍結すれば業務に影響し、凍結しなければ移行作業が終わらないというジレンマが、移行を難しくしています。
こうした難所があるため、人手を前提とした従来の見積もりでは、中規模以上のシステムで数千万円規模になることが珍しくありませんでした。この構図を変えつつあるのが、AIを活用した移行です。
移行事例: 約25万行の基幹システム
当社が株式会社ウイズ・ワンと共同で実施した、サービス管理基幹システムの移行事例を紹介します。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| 対象 | サービス管理の基幹システム(約25万行) |
| 移行元 | FuelPHP |
| 移行先 | 最新PHP + Laravel 12 |
| 背景 | 言語・フレームワークのサポート終了によるセキュリティ・事業継続上のリスク |
結果として、従来手法の見積もりと比較して金額・工期とも約60%の削減を実現しました。移行後のシステムは本番環境で問題なく稼働しており、品質は従来手法と同等です。
進め方の特徴
このプロジェクトでは、マイグレーション専用に開発した独自のAIエージェントと、人による品質担保を組み合わせました。
設計書が十分に残っていなくても、AIがコードから構造と仕様を読み取るため、仕様把握の工数を大きく抑えられます。この進め方は仕様書がないシステムはAIで移行できる？で詳しく解説しています。約25万行を作業単位に分割し、並行して変換と新旧比較を繰り返した手順はAIマイグレーションの進め方で解説しています。また、AIによる変換は繰り返し実行できるため、移行中の機能改修にも移行作業を追従させることができます。このプロジェクトでは、改修の凍結期間を2週間に抑えました。先に挙げた4つの難所を、それぞれAIと体制の工夫でカバーした形です。
AIを活用した移行の仕組みや導入時の注意点は、AIマイグレーションとは？仕組みと効果、導入前に知っておきたい注意点で詳しく解説しています。
まとめ
FuelPHPは安定版の更新が途絶えて7年以上が経ち、使い続けるリスクは年々大きくなっています。同じPHPであるLaravelへの移行は資産を活かせる現実的な選択肢であり、AIの活用によって、かつては高額で断念していた規模のシステムでも現実的な費用と期間で移行できるようになってきました。
とはいえ、実際にどこまで効率化できるかは、コードの状態や構成によって異なります。検討の第一歩として、実際のソースコードに基づく診断で移行可能性と概算費用を把握することをおすすめします。
DEN-NOのAIマイグレーションサービスでは、NDA(秘密保持契約)を締結のうえシステム概要とソースコードの一部をお預かりし、現状リスクと移行可能性をまとめた診断レポートと概算費用を無料でご提示しています。仕様書・設計書のご準備は必須ではありませんので、お手元にないお客様もご安心ください。
よくある質問
Q. FuelPHPのまま最新のPHPで動かすことはできませんか？
開発版の1.9/developブランチに載せ替えればPHP 8系で動かせますが、正式リリースではなく、テストが不十分であることを開発者自身が認めています。企業システムの基盤として長期に頼れる状態ではないため、根本的な解決にはなりません。詳しくは本文の「FuelPHPとPHP 8の対応状況」の節をご覧ください。
Q. FuelPHP以外のフレームワークからの移行にも対応できますか？
対応できます。CodeIgniterやCakePHPの古いバージョンなど他のPHPフレームワークからの移行のほか、PHP 5系から8系への言語バージョンアップ、VB6からC#への言語変更まで幅広く対応しています。CakePHP 2からの移行先の選び方はCakePHP 2の移行で、JavaのSeasar2からSpring Bootへの移行はSeasar2のサポート終了で、それぞれ解説しています。
Q. 移行費用はどのくらいかかりますか？
対象システムの規模と状態によって変わります。規模別・方式別の相場観はシステムマイグレーションの費用相場にまとめていますので、あわせてご覧ください。個別の概算は無料診断でご提示できます。
