過去バージョン

この記事の要点

DietCake は CakePHP 1.x ベースの軽量版 PHP フレームワーク。日本で 2009 年頃に登場 現在は活発な開発停止。新規採用は推奨されず、既存プロジェクトはモダンフレームワークへ移行検討 移行先候補: CakePHP 4.x / 5.x（同系列）、Laravel（最大シェア）、Symfony（堅牢） CakePHP 1.x の規約（fat model / thin controller、find() 配列、Bake CLI）は現代版でも一部継承 既存 DietCake コードは PHP 5 系で書かれていることが多く、PHP 8 系へのアップグレードが同時に必須

DietCake とは

DietCake はCakePHP 1.x をベースに、コア機能だけを残してダイエットした軽量版 PHP フレームワークです。2009 年頃に日本のコミュニティで開発され、当時 CakePHP の重さに悩む現場で「最小構成で動く CakePHP 互換」として一定の支持を集めました。

しかし 2026 年現在、本家 CakePHP は 4.x / 5.x に進化し、PHP も 8 系がメインです。DietCake のリポジトリは更新が止まっており、PHP 8 系では動作しないコードも多々あります。本記事では「すでに DietCake で動いているプロジェクトをどうするか」を中心に整理します。

当時の特徴

項目	DietCake	CakePHP 1.x（本家）
サイズ	コアのみ。数百 KB	数 MB
機能	Model / Controller / View だけ	+ Helper / Behavior / Component 等フル機能
ORM	find() 配列ベース	同じ
セッション	軽量実装	SessionComponent 経由
ルーティング	シンプル（規約優先）	同じ
テスト	同梱なし	SimpleTest 同梱

DietCake の現状（2026 年）

• GitHub リポジトリは数年前からコミットなし
• PHP 5.6 までで動作するが、PHP 7.4 以降は致命的な互換性問題（mysql_* 関数削除、each() 削除、各種 deprecated）
• セキュリティアップデートなし → 本番運用は強くリスク
• 新規採用は非推奨

選択肢の比較

移行先	難易度	メリット	デメリット
CakePHP 4.x / 5.x	中	命名規約・Bake が継承、知識が活きる	ORM API が全面刷新（find が変わった）
Laravel	中-高	最大シェア・パッケージ豊富・人材確保しやすい	設計思想がかなり違う
Symfony	高	堅牢・大規模向け・EU で人気	学習コスト高
Slim / Lumen	低	マイクロ。小規模 API に最適	大規模化で機能不足
放置（PHP のみ更新）	低	すぐ済む	セキュリティ不安継続

CakePHP 4.x への移行

同系列なので命名規約・MVC 構造・Bake CLIは活きます。ただしORM が ResultSet / Entity ベースに刷新されており、コードは大幅な書き換えが必要です:

// DietCake / CakePHP 1.x
$users = $this->User->find('all', [
    'conditions' => ['User.active' => 1],
    'order' => 'User.created DESC',
    'limit' => 10,
]);
foreach ($users as $u) {
    echo $u['User']['name'];
}

// CakePHP 4.x
$users = $this->Users->find()
    ->where(['active' => 1])
    ->order(['created' => 'DESC'])
    ->limit(10)
    ->all();
foreach ($users as $u) {
    echo $u->name;     // Entity オブジェクト
}

移行ステップ:

1. Composer 導入: composer create-project --prefer-dist cakephp/app:5.* new_app
2. テーブル名 / カラム名規約を確認（基本は維持）
3. Bake で Entity / Table クラスを自動生成: bin/cake bake all users
4. 旧 find() 呼び出しを QueryBuilder に書き換え
5. View ファイルを ctp → php へ拡張子変更
6. 独自 Helper / Behavior を移行

Laravel への移行

Laravel は最も人材確保しやすく、エコシステムが豊富。コードは大幅に書き換えになりますが、「結局移行するなら最大派閥へ」という判断は妥当です:

// Laravel
namespace App\Http\Controllers;

use App\Models\User;
use Illuminate\Http\Request;

class UserController extends Controller
{
    public function index()
    {
        $users = User::where('active', 1)
            ->orderByDesc('created_at')
            ->limit(10)
            ->get();
        return view('users.index', compact('users'));
    }
}

導入: composer create-project laravel/laravel myapp → DB 接続を .env → php artisan make:model User -mfc でモデル / マイグレーション / コントローラ / ファクトリを一発生成。

段階的移行のパターン

「一気に書き換え」は失敗しやすいので、現実的には共存 → 段階置換を推奨:

1. 新機能だけ新フレームワークで実装。同じ DB を共有
2. Nginx / Apache のリバースプロキシでURL パスごとにルーティング
   • /new/* → Laravel
   • /* → DietCake（旧）
3. セッションは共有: Redis セッション or DB セッション
4. 認証は新側に統一、旧側からは新の認証 API を呼ぶ
5. 機能単位で旧 → 新へ移植 → 完全置換

移行できない／したくない場合

「とりあえず PHP 8 で動かしたい」だけなら以下:

• PHP 5.6 → PHP 8.x の互換修正（mysql_* → PDO、each() 撤去、create_function 撤去、メソッド名規則）
• Rector で自動修正: composer require rector/rector --dev
• テストカバレッジを確保してから着手（無いなら主要シナリオの E2E テストを先に追加）
• 恒久対応にはならないことを認識

FAQ

Q: DietCake で書かれた既存サービスのリスクは？
A: ① PHP 5.x 系のセキュリティパッチが切れている、② DietCake 自体のメンテ無し、③ 攻撃が見つかっても誰も直さない。移行か凍結（外部公開停止）を強く推奨。

Q: 互換ライブラリは無いの？
A: CakePHP 1.x → 4.x の自動移行ツールは無し。find() の書換が最大の作業。設計を整理する好機と捉えるべし。

Q: 学習コストが心配
A: Laravel は日本語情報が圧倒的に多い。公式ドキュメント完全和訳済。動画教材・書籍も豊富。3 ヶ月で実務投入レベルに到達可能。