対象バージョン: Rails 8.1 系 / Laravel 13 系 前提: 各エコシステムでデファクトスタンダードとされる gem / パッケージを使う前提で比較する。
目次
結論（先に要約）
- Webアプリに必要な機能は、デファクトの gem / パッケージまで含めればほぼすべて対応関係がある。 「片方でしか実現できない機能」はほぼない。
- 実際の違いは主に次の4点。
- どこにあるか — フレームワーク本体 / 公式パッケージ / サードパーティ / 有償サービス
- 設計思想 — バリデーションの置き場所、DIコンテナの有無、ランタイムモデルなど
- 公式エコシステムの広さ — Laravel は公式パッケージ・公式SaaSが多い。Rails は本体同梱が多く、残りはコミュニティ gem に頼る
- フロントエンドの方向性 — Rails は Hotwire（HTML over the wire）が標準。Laravel は Livewire と Inertia（React/Vue/Svelte）から選べる
1. 全体比較表
凡例: 本体 = フレームワーク同梱 / 公式 = 公式の別パッケージ / 3rd = サードパーティのデファクト / 有償 = 有償サービス・製品
| 分野 | Rails | Laravel | 差の大きさ |
|---|---|---|---|
| ORM | Active Record（本体） | Eloquent（本体） | 小 |
| マイグレーション | 本体（schema.rb / structure.sql） | 本体（schema dump あり） | 小 |
| バリデーション | モデルに定義（本体） | Form Request / Validator（本体） | 中（設計思想） |
| ルーティング | 本体（resources 中心） | 本体（クロージャ / コントローラ / 属性） | 小 |
| テンプレート | ERB（本体） | Blade（本体） | 小 |
| 認証（ログイン） | rails g authentication（本体）/ Devise（3rd） | スターターキット + Fortify（公式） | 小 |
| パスキー（WebAuthn） | webauthn-ruby 等（3rd） | Fortify / スターターキット（公式、13〜） | 中 |
| ソーシャルログイン | OmniAuth（3rd） | Socialite（公式） | 小 |
| APIトークン認証 | generates_token_for 等（本体）/ devise-jwt（3rd） | Sanctum（公式） | 小 |
| OAuth2 サーバー | Doorkeeper（3rd） | Passport（公式） | 小 |
| 認可 | Pundit / CanCanCan（3rd） | Gate / Policy（本体） | 小 |
| バックグラウンドジョブ | Active Job + Solid Queue（本体）/ Sidekiq（3rd） | Queue（本体）+ Horizon（公式） | 小 |
| ジョブのバッチ・チェーン | 本体に無し（GoodJob / Sidekiq Pro で対応） | Bus::batch / chain（本体） | 中 |
| ジョブの途中再開 | Active Job Continuations（本体、8.1〜） | 本体に同等機能無し（自前で分割） | 中 |
| 定期実行（cron） | Solid Queue の recurring tasks（本体）/ whenever 等 | Task Scheduling（本体） | 小 |
| キャッシュ | Solid Cache / Redis 等（本体） | Cache（本体、DB / Redis 等） | 小 |
| WebSocket | Action Cable + Solid Cable（本体） | Reverb（公式）+ Echo | 小 |
| メール送信 | Action Mailer（本体） | Mail（本体） | 小 |
| メール受信 | Action Mailbox（本体） | 本体に無し（3rd パッケージ） | 中 |
| 通知（複数チャネル） | noticed（3rd） | Notifications（本体） | 中 |
| ファイル保存 | Active Storage（本体、variant・直接アップロード付き） | Filesystem / Flysystem（本体） | 中 |
| 画像変換・メディア管理 | Active Storage variants（本体） | spatie/laravel-medialibrary 等（3rd） | 中 |
| リッチテキスト | Action Text（本体） | 本体に無し（Filament 等のエディタ） | 中 |
| 全文検索 | pg_search / Searchkick（3rd） | Scout（公式） | 小 |
| 決済（Stripe 等） | Pay（3rd） | Cashier（公式） | 小 |
| 機能フラグ | Flipper（3rd） | Pennant（公式） | 小 |
| 管理画面 | ActiveAdmin / Avo / Administrate（3rd） | Filament（3rd）/ Nova（公式・有償） | 小 |
| API レスポンス整形 | Jbuilder（本体）/ Alba 等（3rd） | API Resources（本体）、JSON:API（本体、13〜） | 小 |
| ページネーション | Pagy / Kaminari（3rd） | 本体 | 小 |
| レート制限 | rate_limit（本体）/ Rack::Attack（3rd） | RateLimiter（本体） | 小 |
| 暗号化 | Active Record Encryption（本体） | Crypt / encrypted cast（本体） | 小 |
| 国際化 | I18n（本体） | Localization（本体） | 小 |
| イベント / リスナー | ActiveSupport::Notifications、コールバック（本体） | Events / Listeners / Observers（本体） | 中 |
| 構造化ログ | Rails.event（本体、8.1〜） | Context / Log channels（本体） | 小 |
| デバッグ・監視 | rack-mini-profiler、Mission Control（公式） | Telescope / Pulse（公式） | 中 |
| テスト | Minitest（本体）/ RSpec + FactoryBot（3rd） | Pest / PHPUnit（本体）、Factory（本体） | 小 |
| ブラウザテスト | System Test + Capybara（本体） | Dusk（公式）/ Pest Browser | 小 |
| テスト用 Fake | ジョブ・メール等のテストヘルパー（本体） | Mail::fake()、Queue::fake() 等（本体） | 小 |
| 静的解析 / 型 | RuboCop、Sorbet / RBS（3rd） | PHP の型宣言 + Larastan（3rd）、Pint（公式） | 中 |
| セキュリティスキャン | Brakeman（本体同梱） | 本体に無し（3rd） | 小 |
| ローカルCI | config/ci.rb（本体、8.1〜） | 本体に無し | 小 |
| REPL | rails console | php artisan tinker | 小 |
| 開発環境 | devcontainer 生成（本体） | Sail（公式）/ Herd（公式アプリ） | 小 |
| フロントエンド | Hotwire（Turbo + Stimulus）、importmap | Livewire / Inertia（React・Vue・Svelte） | 大（方向性） |
| アセット | Propshaft（本体） | Vite（本体） | 小 |
| アプリサーバー | Puma + Thruster | PHP-FPM / Octane（FrankenPHP・Swoole・RoadRunner） | 中（ランタイム） |
| デプロイ | Kamal（公式、OSS） | Forge / Vapor / Laravel Cloud（公式・有償） | 中 |
| AI 連携 | RubyLLM（3rd）、Markdown レスポンス（8.1〜） | Laravel AI SDK（公式、13 で安定版）、Boost | 中 |
2. 実際に差が出るポイント
2-1. Rails のほうが標準機能として強いもの
| 機能 | 内容 | Laravel での代替 |
|---|---|---|
| Action Text | Trix ベースのリッチテキストエディタと保存・添付が本体に統合されている | エディタ（Tiptap 等）と保存処理を自分で組み合わせる。Filament 利用時はエディタが付属 |
| Action Mailbox | 受信メールをルーティングしてコントローラ的に処理できる | beyondcode/laravel-mailbox 等の 3rd |
| Active Storage | 画像 variant、直接アップロード、モデルへの添付が本体で一貫して扱える | Filesystem + spatie/laravel-medialibrary の組み合わせが定番 |
| Active Job Continuations | 長いジョブを step に分け、再起動後に途中から再開できる（8.1〜） | ジョブを自分で分割し、チェーンやバッチで代用 |
| 複合主キー | Active Record が複合主キーに対応 | Eloquent は複合主キー非対応（パッケージか回避策が必要） |
| Kamal | 無料・OSS のデプロイツールが公式で用意されている | Forge / Cloud は有償。無料なら Deployer 等 |
| Brakeman / ローカルCI | セキュリティ静的解析とローカルCIが新規アプリに最初から入っている | 自分で導入する |
2-2. Laravel のほうが標準機能として強いもの
| 機能 | 内容 | Rails での代替 |
|---|---|---|
| Notifications | メール・SMS・Slack・DB・Broadcast などへの通知を1つのクラスで送れる | noticed gem |
| ジョブのバッチ | 複数ジョブの進捗・完了・失敗をまとめて扱える | GoodJob の batch、または Sidekiq Pro（有償） |
| Task Scheduling | routes/console.php に定期実行を書くだけで動く。重複実行の防止なども揃っている | Solid Queue の recurring tasks で近いことができる。高度な制御は gem が必要 |
| 認可（Gate / Policy） | 本体に組み込み済み | Pundit を入れれば同等 |
| 公式パッケージ群 | Socialite、Sanctum、Passport、Cashier、Scout、Pennant、Horizon、Telescope、Pulse、Reverb など、すべて公式でメンテされている | 同等の gem はあるが、作者・メンテナンス体制がバラバラ |
| パスキー | Fortify / スターターキットで標準対応（13〜） | webauthn-ruby 等を組み込む |
| AI SDK | プロバイダ非依存の公式 AI SDK（13 で安定版） | RubyLLM 等の 3rd |
| JSON:API | JSON:API 仕様のリソースクラスが本体に入っている（13〜） | jsonapi-serializer 等の 3rd |
| ページネーション | 本体に組み込み済み | Pagy / Kaminari |
| 監視ダッシュボード | Telescope（開発時のリクエスト・クエリ・ジョブ確認）、Pulse（本番の簡易メトリクス） | 単一の公式ツールは無い。rack-mini-profiler、Mission Control Jobs、APM を組み合わせる |
3. 設計思想・アーキテクチャの違い
機能の有無ではなく、書き方・考え方の違いとして差が出る部分。
| 観点 | Rails | Laravel |
|---|---|---|
| バリデーションの置き場所 | モデル（validates）。どこから保存しても同じ検証がかかる | リクエスト層（Form Request）。モデル自体は検証を持たないのが一般的 |
| Mass Assignment 対策 | コントローラの Strong Parameters | モデルの $fillable / $guarded |
| 属性定義 | DB スキーマから自動。型は attribute で上書き | DB スキーマから自動。型変換は $casts / casts() |
| DI | DI コンテナは無い。Ruby の言語機能（モジュール、Concern）で対応 | サービスコンテナ + Facade が中心。インターフェースへのバインドが容易 |
| 設定の書き方 | DSL（クラスマクロ）中心 | 配列設定 + PHP 属性（13 で属性による設定が大幅に拡充） |
| 規約の強さ | 「設定より規約」が強い。ディレクトリ構成もほぼ固定 | 規約はあるが柔軟。構成を変えやすい |
| ランタイム | 常駐プロセス（Puma）。メモリ上に状態が残る | 基本は share-nothing（リクエストごとに初期化）。Octane を使うと常駐型になる |
| 型 | 動的型付け。型が欲しければ Sorbet / RBS | 言語レベルで型宣言がある + PHPStan（Larastan） |
| フロントエンド | サーバーで HTML を返す Hotwire を推奨。SPA は脇役 | Livewire（サーバー駆動）と Inertia（SPA 的）を対等に扱う |
| エコシステムの収益モデル | ほぼ OSS + コミュニティ | OSS 本体 + 公式の有償製品（Forge、Vapor、Cloud、Nova） |
4. 選定の目安
| 状況 | 向いている方 | 理由 |
|---|---|---|
| React / Vue で画面を作りたいが、API は分けたくない | Laravel | Inertia スターターキットが公式 |
| JS をなるべく書かずにリッチな UI を作りたい | どちらも可 | Hotwire（Rails）/ Livewire（Laravel） |
| 公式サポートのパッケージだけで揃えたい | Laravel | 決済・検索・OAuth・機能フラグ・監視まで公式 |
| リッチテキスト・メール受信・ファイル添付が多い | Rails | Action Text / Action Mailbox / Active Storage が本体 |
| 自前サーバーに安く・シンプルにデプロイしたい | Rails | Kamal が無料で公式 |
| マネージドに任せたい（費用は許容） | Laravel | Laravel Cloud / Vapor |
| 既存チームのスキル | 言語次第 | 機能差より、Ruby / PHP の習熟度の影響のほうが大きい |
| 共有レンタルサーバーで動かしたい | Laravel | PHP なら動く環境が多い |
5. まとめ
- デファクトの gem / パッケージを使う前提なら、機能面で「できる / できない」の差はほぼない。
- 差が出るのは次の部分。
- Rails が本体で持っているもの: Action Text、Action Mailbox、Active Storage、Job Continuations、複合主キー、Kamal
- Laravel が本体・公式で持っているもの: Notifications、ジョブのバッチ、Gate / Policy、パスキー、AI SDK、JSON:API、監視ツール群（Telescope / Pulse）
- 選定に効きやすいのは、機能差よりも次の3点。
- フロントエンドの方針（Hotwire か、Livewire / Inertia か）
- デプロイの方針（Kamal で自前運用か、公式マネージドか）
- チームの言語スキル