Rails

言語別の既定§2-3

Railsの標準構成（「Rails omakase」）にできるだけ乗る。外部依存を増やさないことが最大のメリットになる。

選ぶ場面§2-10

• DBの読み書きと業務ロジックが中心ボトルネックはDB。言語の性能差はほぼ効かないので、開発速度とチームで選ぶ

既定：認証Ruby / Rails

乗り換える条件

• DeviseOAuth連携・多要素認証など機能を一式揃えたいとき
• Rodauth高度なセキュリティ要件

既定：CRUD中心のWebアプリ・管理画面作成物ごとの言語の決め方

乗り換える条件

• TypeScript外部API連携が中心、またはReactで画面を作り込みたいとき
• Kotlin業務ルールが非常に複雑で、既存のJava資産と連携するとき

既定：Rails認証・認可

乗り換える条件

• DeviseOAuth連携・多要素認証など機能を一式揃えたいとき（§2-3）

採用の根拠§22-2

CRUD中心のアプリで開発速度が非常に高い。近年のRailsはSolid Queue／Solid Cache／Solid Cableでジョブ・キャッシュ・WebSocketをDBだけで動かせるため、Redisなどの追加ミドルウェアが不要。GitHubやShopifyが大規模に運用している実績がある。Kamalで特定のPaaSに依存せずデプロイできる

「Rubyは下火では」→ 採用企業は安定して存在し、フレームワークは毎年活発に更新されている

成長したら → PostgreSQL§24

きっかけ

複数台構成にしたい、書き込み待ちが目立つ

最初からの備え

SQLite固有の書き方を避け、ActiveRecordの範囲で書く

ケース別の構成§19

• 業務システム・社内ツール（Rails構成）アプリ：Rails＋Hotwire＋tailwindcss-rails＋ViewComponent
• 業務システム・社内ツール（Rails構成）認証：Railsの認証ジェネレータ（社内ならGoogle／Entra IDのSSO）
• 個人開発・MVPRailsワンマン：Rails＋SQLite＋Kamal＋VPS