結論から書くと、CodeIgniter 3 のシステムをどうするかは、あと何年使うか、どのくらい変更を続けるか、誰が保守するか の3つで決まります。先に押さえておきたいのは、Laravel へ移すのも CodeIgniter 4 へ移すのも、中身は「書き換え」に近いということです。逆に延命は、サポート期間内の PHP で動かせる見込みが立つかどうかにかかっています。
古いフレームワーク全般の判断の基準は「古い PHP フレームワークのシステム、書き換えか延命かの判断基準」で説明しました。この記事では、CodeIgniter 3 に絞って、公式の情報と、移すときの具体的な対応関係を扱います。
CodeIgniter 3 の現状を公式の情報で確かめる
2026年11月4日に公式のページで確認した内容です。
- 最新版は 3.1.13。 CodeIgniter 3 の変更履歴では、3.1.13 のリリース日は2022年3月3日で、これが最新です。
- 要件の記載は古い PHP が前提。 CodeIgniter 3 のサーバー要件には「PHP 5.6 以上を推奨」とあり、PHP 8 系での動作についての記載はありません。
- CodeIgniter 4 との互換性は無い。 3.x から 4.x への移行の案内には、CodeIgniter 4 はフレームワークの書き直しで後方互換性がなく、アップグレードというより、アプリケーションの変換と考えるほうが適切だと書かれています。
- CodeIgniter 4 は新しい PHP が前提。 CodeIgniter 4 のサーバー要件では PHP 8.2 以上が必要で、PHP 8.5 で使うには 4.7.0 以上が必要です。
一方で、PHP のサポート期限は、PHP 8.2 が2026年12月31日、PHP 8.3 が2027年12月31日です。つまり CodeIgniter 3 を使い続けるなら、新しい PHP への対応は、フレームワーク本体も含めて自分たちで持つ ことになります。
3つの選択肢
| 選択肢 | 内容 | 向いている状況 | 注意点 |
|---|---|---|---|
| 延命 | CodeIgniter 3 のまま、サポート期間内の PHP で動くように直す | 変更が少ない。数年のうちに入れ替えや廃止の予定がある | フレームワーク本体の修正も自分で持つ。PHP を上げるたびに同じ確認が要る |
| CodeIgniter 4 へ変換 | 同じ系統の新しいフレームワークへ移す | CodeIgniter の書き方に慣れた体制で、構成を近く保ちたい | 公式のとおり互換性は無く、アプリケーションの変換になる |
| Laravel へ移行 | 別のフレームワークで作り直す | 長く使い、機能の追加が続く。Laravel を保守できる体制がある | 毎年メジャー版が出て、各版のセキュリティ修正は2年。定期的な更新が前提 |
Laravel について補足すると、公式のリリースノートのとおり、メジャーバージョンは毎年出て、各バージョンのセキュリティ修正は2年です。移した後も、使っているバージョンのセキュリティ修正が終わる前に次のバージョンへ上げる作業を、保守の計画に入れておく必要があります。移すこと自体より、移した後に更新を続けられるかのほうが、長い目で見ると重要です。
延命する場合の作業
延命では、まず検証環境で移行先の PHP にして動かし、エラーと警告を洗い出します。直す対象は、自前のコードと、system/ ディレクトリにあるフレームワーク本体の両方です。
本体に手を入れる場合は、元の 3.1.13 からの差分を必ず記録します。どこを直したかが分からなくなると、次に PHP を上げるときに、同じ調査を一からやり直すことになります。本体も含めて git で管理し、本体の修正は独立したコミットに分けておくと、後から追えます。
PHP 8.2 の動的プロパティの警告は、PHP の公式の説明のとおり、クラスに #[\AllowDynamicProperties] 属性を付けると出なくなります。ただしこれは警告を止める方法で、コードの書き方が新しくなるわけではありません。どのクラスに付けたかも、差分として記録しておきます。
判断の軸
次の順に考えると整理しやすくなります。
- あと何年使うか。 数年のうちに業務の入れ替えや廃止の予定があるなら、延命が有力です。大きな投資を回収する時間がありません。
- 変更の頻度。 機能の追加や変更が今後も続くなら、移行の効果が大きくなります。変更がほとんど無いなら、延命で足ります。
- 誰が保守するか。 社内か外部か。保守する人が慣れているフレームワークを選ぶと、移した後の費用を抑えられます。
- 延命の見込み。 検証環境で PHP 8.3 以上にして動かし、フレームワーク本体と自前のコードでどれだけ問題が出るかを調べます。PHP 8.2 で動的プロパティの作成が非推奨になったことなど、新しい PHP の変更がどこに影響するかは、実際に動かして確かめるのが確実です。
- 規模と構造。 コントローラに処理が集中しているか、モデルに分かれているか。データベースの処理が整理されていれば、移す作業は見積もりやすくなります。
延命と移行は、どちらか一方でなくても構いません。期限が迫っているなら、まず延命でサポート期間内の PHP に乗せ、その間に移行を計画する、という順番もあります。
Laravel へ移すときの対応関係
移すと決めた場合に、主な部品がどう対応するかの目安です。
| CodeIgniter 3 | Laravel | 移すときの注意 |
|---|---|---|
application/config/routes.php と URL の自動の対応 |
routes/web.php |
すべての URL を明示的に定義する必要がある |
application/controllers/ |
app/Http/Controllers/ |
処理の多いコントローラは、移すときに分ける |
application/models/（$this->db のクエリビルダ） |
Eloquent、またはクエリビルダ | SQL の結果が変わらないかを確かめる |
application/views/ |
Blade のテンプレート | 出力のエスケープの扱いを確認する |
| フォームのバリデーション | バリデーション、フォームリクエスト | エラーメッセージの文言を合わせる |
| セッションのライブラリ | セッション | 形式が違うので、切り替えるとログインし直しになる |
libraries/ helpers/ |
サービスのクラス、ヘルパー | 使われていないものは移さない |
特に注意したいのが URL です。CodeIgniter 3 は、公式の URL の説明のとおり、example.com/class/function/ID の形で、URL の区切りがそのままコントローラとメソッドに対応します。ルートの定義に書かれていない URL も動いているので、アクセスログと照らし合わせて、実際に使われている URL を洗い出してから移します。
段階的に移す場合の進め方
全部を一度に移さず、機能ごとに移すこともできます。
- 入口で振り分ける。 Web サーバーの設定で、移した URL だけを Laravel へ、残りを CodeIgniter 3 へ渡します。
- データベースは共有する。 新旧の両方から同じテーブルを読み書きするので、移している間はテーブルの構造を大きく変えません。
- ログインの扱いを先に決める。 セッションの形式が違うため、新旧をまたいでログインを保つ方法を最初に決めます。段階移行では、ここに手間がかかりやすくなります。
- 移した機能の古いコードは削除する。 残すと、どちらが使われているのか分からなくなります。
h-system でできること
h-system では、CodeIgniter 3 で作られたシステムについて、延命、CodeIgniter 4 への変換、Laravel への移行のどれが合うかを、ソースコードとサーバー環境を調べたうえでご説明しています。延命の見込みを確かめるために、検証環境で新しい PHP に上げたときの問題を洗い出す調査だけのご依頼も可能です。初回のご相談と概算のお見積りは無料で、詳細な調査は有償です。範囲と費用は着手前にご案内します。