業務システム・管理画面
社内ツール、予約、受発注
推奨：Ruby / Rails
推奨
Ruby / Rails
- DB中心のCRUDなので性能差は効かない。画面数の多い業務システムはRailsが最も速く作れる（§2-10 手順2）
構成行を開くと詳細（乗り換える条件・根拠・費用・習熟度）
アプリRails＋Hotwire＋tailwindcss-rails＋ViewComponent
Rails
言語別の既定§2-3
Railsの標準構成（「Rails omakase」）にできるだけ乗る。外部依存を増やさないことが最大のメリットになる。
選ぶ場面§2-10
- DBの読み書きと業務ロジックが中心ボトルネックはDB。言語の性能差はほぼ効かないので、開発速度とチームで選ぶ
既定：CRUD中心のWebアプリ・管理画面作成物ごとの言語の決め方
乗り換える条件
- TypeScript外部API連携が中心、またはReactで画面を作り込みたいとき
- Kotlin業務ルールが非常に複雑で、既存のJava資産と連携するとき
採用の根拠§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
習熟度
Hotwire
ケース別の構成§19
- 業務システム・社内ツール（Rails構成）アプリ：Rails＋Hotwire＋tailwindcss-rails＋ViewComponent
tailwindcss-rails
既定：CSSRuby / Rails
ケース別の構成§19
- 業務システム・社内ツール（Rails構成）アプリ：Rails＋Hotwire＋tailwindcss-rails＋ViewComponent
ViewComponent
ケース別の構成§19
- 業務システム・社内ツール（Rails構成）アプリ：Rails＋Hotwire＋tailwindcss-rails＋ViewComponent
DBPostgreSQL
PostgreSQL
採用の根拠§22-2
OSSでライセンス費用がかからない。AWS、GCP、Azureを含む主要クラウドがすべてマネージド版を提供している。拡張機能（pgvector、pg_bigm）でベクトル検索や日本語全文検索までこなせるため、専用DBを増やさずに済む
「MySQLの方が一般的では」→ 機能・標準SQLへの準拠・拡張性で優位。移行ツールも揃っている
ケース別の構成§19
習熟度
ジョブ・キャッシュSolid Queue／Solid Cache
Solid Queue
ケース別の構成§19
- 業務システム・社内ツール（Rails構成）ジョブ・キャッシュ：Solid Queue／Solid Cache
Solid Cache
ケース別の構成§19
- 業務システム・社内ツール（Rails構成）ジョブ・キャッシュ：Solid Queue／Solid Cache
認証Railsの認証ジェネレータ（社内ならGoogle／Entra IDのSSO）
Rails
言語別の既定§2-3
Railsの標準構成（「Rails omakase」）にできるだけ乗る。外部依存を増やさないことが最大のメリットになる。
選ぶ場面§2-10
- DBの読み書きと業務ロジックが中心ボトルネックはDB。言語の性能差はほぼ効かないので、開発速度とチームで選ぶ
既定：CRUD中心のWebアプリ・管理画面作成物ごとの言語の決め方
乗り換える条件
- TypeScript外部API連携が中心、またはReactで画面を作り込みたいとき
- Kotlin業務ルールが非常に複雑で、既存のJava資産と連携するとき
採用の根拠§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
習熟度
Google Workspace
既定：社内ツール認証・認可
Microsoft Entra ID
既定：社内ツール認証・認可
帳票Playwright（HTML→PDF）
Playwright
既定：テスト（E2E）TypeScript（Node.js）
代替：システムテストRuby / Rails
ケース別の構成§19
- 業務システム・社内ツール（Rails構成）帳票：Playwright（HTML→PDF）
デプロイKamal（オンプレVM・VPS）またはRender
Kamal
成長したら → 複数台／ECS§24
- きっかけ
- 1台で処理しきれない、冗長化が必要
- 最初からの備え
- アプリをステートレスにする。セッションとファイルはDB・S3に置く
ケース別の構成§19
習熟度
Render
代替：デプロイRuby / Rails
既定は Kamal。サーバー管理をしたくないとき に乗り換える。
ケース別の構成§19
- 業務システム・社内ツール（Rails構成）デプロイ：Kamal（オンプレVM・VPS）またはRender
- 業務システム・社内ツール（TypeScript構成）デプロイ：Render（AWSならECS on Fargate、オンプレならコンテナでVM）
- データ基盤・バッチ実行：RenderのCron Job（AWSならECSのスケジュールタスク）
静的解析RuboCop、Brakeman、bundler-audit
RuboCop
ケース別の構成§19
- 業務システム・社内ツール（Rails構成）静的解析：RuboCop、Brakeman、bundler-audit
Brakeman
既定：セキュリティ静的解析Ruby / Rails
ケース別の構成§19
- 業務システム・社内ツール（Rails構成）静的解析：RuboCop、Brakeman、bundler-audit
bundler-audit
既定：依存の脆弱性Ruby / Rails
§19-4の構成
構成図 業務システム・社内ツール（Rails構成）
flowchart TB
U["社員"] --> SSO["SSO<br/>Google／Entra ID"] --> R["Rails<br/>Hotwire"]
R --> DB[("PostgreSQL<br/>Solid Queue／Solid Cache")]
R --> PDF["Playwright<br/>PDF 帳票"]
K["Kamal"] -. "デプロイ" .-> R作り始める
共通の準備
# 言語・ツールのバージョン固定（使う言語だけ）
mise use node@lts pnpm@latest
mise use go@latest
mise use ruby@latest
mise use python@latest uv@latest
# Gitフックと依存更新
pnpm add -D lefthook && pnpm exec lefthook install
# renovate.json を置き、GitHubでRenovateアプリを有効化する業務システム・Rails構成（§19-4）
gem install rails
rails new app -d postgresql -c tailwind
cd app
bin/rails generate authentication
bundle add pundit pagy
# Kamalの設定は config/deploy.yml に生成済み