概要
Railsの主要アーキテクチャを2025年12月時点でまとめてみました
MVC, Hotwire, Inertia.js, API分離をベースに記述しています
余談ですが、Serviceクラスを使うべきかの議論についても記述しました
1. Rails標準: MVC (Model–View–Controller)
- RailsではMVCを中心とした「サーバレンダリング＋HTML」返却がデフォルトです
- ルーティング → コントローラ → モデル → ビュー の流れでHTMLを返すのが基本
- Skinny Controllers / Fat Models（肥大化は避けつつもロジックはモデル中心へ）
- スコープ・バリデータ・フォームオブジェクト・Queryオブジェクトなどで整理されたモデル構造が理想
- 複雑化時にServiceへ追い出す前にまずModelを整えるのがRailsの基本思想
近年は「Fat Modelを推奨する」よりも
“Well-structured Models”に整理するアプローチが重要
→ Domain/Value Object等を適宜導入し、責務の明確化を図る
- Form Object（入力・更新のためのロジック整理）
- Query Object（複雑な検索条件の切り出し）
- Value Object（値・属性の不変条件を保持）
- Service Object（複数モデル・外部APIを跨ぐ際）
ケース
- CRUD中心で実装する場合
- フロントエンドの複雑さを増やしたくない場合
2. Hotwire（Turbo + Stimulus）：Railsだけで“ほぼSPA体験”を作る
- Hotwireは“HTML Over The Wire”という思想で、SPAのような体験をRails中心で実現できる
- 中心はTurbo（Drive/Frames/Streams）とStimulus（軽量JS）で、React/Vueを使わずに現代的なUI体験を構築できる
- Rails 7以降での統合が進み、Rails 8でも有力な選択肢
- Turbo Drive：リンク/フォームを高速化（<body>差し替え・<head>維持）。SPA的な遷移
- Turbo Frames：<turbo-frame>内を部分更新
- Turbo Streams：複数DOM同時更新・リアルタイム（ActionCableと相性◎）
- Stimulus：必要最小限のJSでインタラクション付与
フルSPAではない
サーバ駆動UIが中心。複雑な状態管理には設計に工夫が必要
長所
- React/VueなしでUX向上
- サーバサイド中心で開発速度が高い
- Turbo StreamsでリアルタイムUIが容易
注意点（弱点）
- 状態管理の複雑なUIには不向き
- JSが増えてくると保守性が落ちやすい
- 大規模SPA用途ではInertia/API分離の方が合うことも
ケース
- RailsだけでUI改善・高速化したい
- リアルタイム更新・部分更新を入れたい
- API分離ほどの設計コストはかけたくない
3. Inertia.js + Rails（inertia-rails）：APIレスでReact/VueなどをView層に
- Inertiaはコントローラから props を返し、ViewをReact/Vueなどで描画する仕組み
- ルーティング・認証・セッションはRailsをそのまま活用できます
特徴
- API不要（JSON設計・CORSやBFFなし）でSPA的に動作
- Railsのルーティングを継続しつつReact/Vue等のコンポーネントへ描画
- SSRは現状実験段階（2025年時点）
利点
- HotwireよりリッチなUIを構築可能
- React/Vueの資産・知見を活かせる
- フロント専任が多いチームで親和性高い
注意点
- 内部は完全SPAではない（サーバルート依存）
- UI規模が大きくなると状態管理や最適化は普通のSPA同様に必要
- モバイルアプリや外部サービス連携が増えると
- → 結局API化が必要になることも多い
ケース
- React/Vueで開発しつつRailsの恩恵（ルーティング/認証）も維持したい
- APIを完全に切り離すほどの規模ではない
- SPA体験のコストを下げたい
参考サイト
4. APIモード＋SPA分離（Rails API + React/Vue.js/Angular）
- RailsをAPI専用（--api）とし、フロントを完全に別リポジトリで構築するアプローチ
長所
- Next.js/Vite等のモダン技術をフル活用
- SSR/SSG/Island Architectureなども取れる
- モバイル・複数フロント統合・GraphQL化に強い
短所
- 認証・CORS・デプロイが複雑化
- RailsによるUI開発の強みを失う
- API管理が必要
5. アーキテクチャ一覧
| 目的 / 状況 | 選択肢 |
|---|---|
| Rails完結でUI改善・高速化、リアルタイム要件あり | HHotwire (Turbo + Stimulus) |
| React/Vueを使いつつAPI設計を省きたい | Inertia.js + Rails |
| SSR/SSGやネイティブ併用、自由なフロント構成が必要 | Rails API + SPA |
6. 余談: Serviceクラスは非推奨なのか？
- RailsコミュニティではService Objectsに肯定／慎重の両論があります
肯定派：
- 複雑な業務ロジックを1箇所に集約できる
- 外部API連携・課金処理などで効果的
- テスト容易性が高い
慎重派：
- 乱立すると責務境界が不明瞭
- “なんでもServiceに投げる”と迷走しやすい
- まずModel整理し、補助的に導入するのが本来の姿
実務的な判断軸
- 単一モデル内の業務ルール
- → Model / バリデータ / スコープ / ValueObject で十分
- 複数モデル横断 / 外部API処理 / 取引・課金
- Serviceでトランザクション制御・例外処理を集約
参考サイト
【参加レポート】Kaigi on Rails 2025で学んだRails開発の実践知
6. 用語説明
- MVC：Rails標準の層分離
- Hotwire：HTMLベースで高速UI、部分更新/リアルタイムに強い
- Turbo Drive / Frames / Streams：UI更新方式
- Inertia.js：APIレスでReact/VueをView層に
- Service Object：複数モデル・外部連携など高凝集ロジックを切り出すパターン
- ActionCable：WebSocketリアルタイム通信
7. まとめ
- Railsの選択肢
- 小規模CRUD → MVCが最速
- UIリッチにしたいがRails中心で進めたい → Hotwire
- React/Vueの生産性も欲しい → Inertia.js
- Web/Native/複数サービス展開・拡張性重視 → API + SPA
- Service Objectの扱いは宗教論ではなく設計判断
- 責務を分離し、やりたい事に合わせてアーキテクチャを考えることが大事