2026年に再びRailsへ戻る

 (markround.com)
2 ポイント 投稿者 GN⁺ 2026-03-13 | 4件のコメント | WhatsAppで共有
  • バンドのセットリスト管理アプリ(setlist.rocks) を作る中で、久しぶりにRuby on Rails開発の楽しさを再発見
  • 最新のRails 8は従来のMVC構造を保ちながら、Hotwire(Stimulus・Turbo) ベースの「no-build」フロントエンド、Solid Cache/Queue/Cable などによってモダン化
  • SQLite は基本設定だけでも本番サービスに適用できるほど最適化され、Kamal デプロイツールによりコンテナベースの無停止デプロイが簡単に
  • Railsの「設定より規約」哲学と豊富なgemエコシステムにより、アイデアからプロトタイプまで素早く実装可能
  • RubyとRailsの人気は以前より下がったが、今なお成熟して一貫性のあるOSSフレームワークとして開発の楽しさを提供

サイドプロジェクトとRailsへの回帰

  • バンドのセットリストと曲のノートを管理するためにWebアプリを自作し、既存のスプレッドシートやチャットより効率的な方法を追求
  • 開発の過程でRailsのシンプルさと生産性を改めて実感し、近年の複雑なWebエコシステムと比べて「純粋な開発の楽しさ」を感じたと言及
  • Rubyは今でも自然な文法と表現力により、思考をコードへ移しやすい言語として評価される
  • Stack Overflow 2025調査によればRubyとRailsの人気は低下したが、個人プロジェクトでは今なお好まれている

Rails 8の変化とフロントエンド

  • Rails 8は既存のMVC構造を維持しつつ、Hotwire(Stimulus・Turbo) ベースのフロントエンド統合を提供
    • Turboはリンククリックやフォーム送信を横取りし、SPAレベルの応答性を提供
    • Stimulusは必要な部分にだけJSの動作を加え、最小限のJavaScript記述でインタラクティブなUIを実現可能
  • Importmap の導入により、WebpackやnpmなしでJSライブラリをCDNから直接読み込める
  • AIツールを活用してUIを生成したが、創作とコードの芸術性の間で葛藤も示した

開発ワークフローと生産性

  • Railsの「設定より規約(Convention over Configuration) 」哲学により、モデル・ルーティング・コントローラ・ビューを素早く構成できる
    • 例としてTagモデルの生成、RESTfulルーティングの自動化、JSONレスポンス処理の流れを実演
  • ERBテンプレートとライブリロードで高速なプロトタイピングが可能
  • 豊富なgemエコシステムにより、CSVやPDFなど多様な機能を容易に統合できる

バックエンド改善: Solid*シリーズとSQLite

  • Solid Cache/Queue/Cable がRails 8に標準搭載され、Redisなしでキャッシュ・ジョブキュー・WebSocket処理が可能
    • Solid CacheはDBベースのキャッシュによりRAMの節約と単純化を実現
    • Solid QueueはDBベースのバックグラウンドジョブ管理で、SOLID_QUEUE_IN_PUMA=1 設定だけで実行可能
    • Solid CableはDBベースのAction Cableアダプタとしてリアルタイム機能を支援
  • SQLite はdatabase.ymlのpragmas:設定により、WALモード、NORMAL同期などの最適化が標準適用
    • 別途DBサーバーがなくても小規模な本番環境で実用的に利用できる

デプロイ自動化とKamal

  • 過去のCapistrano・Ansibleベースのデプロイの複雑さに触れつつ、Kamal をRails 8の標準デプロイツールとして紹介
    • コンテナのビルド→プッシュ→サーバー配備→ヘルスチェック→無停止切り替えの流れを自動化
    • kamal-proxy がトラフィック切り替えとSSL処理を担当
    • .kamal/secrets ファイルにより、環境変数ベースの安全なシークレット管理を支援
  • GitLab CIと連携すれば、git push だけでデプロイが可能で、かつてのHerokuのシンプルさを再現

認証とその他の機能

  • Rails 8は組み込み認証ジェネレータ(auth generator) を提供し、Deviseよりシンプルな認証システムを構築可能
  • Deviseは今なお豊富な機能とドキュメントで有用だが、Rails標準認証のシンプルさも魅力として評価

Railsエコシステムの現在と持続性

  • RubyとRailsの人気は低下したものの、Shopify・Basecamp・SoundCloud・GitHub など主要サービスで今なお利用されている
  • 多くのgemはメンテナンス段階にあるが、Railsは毎年安定したリリースサイクルを維持
  • 「新しい開発者層の流入は減ったが、それでも楽しく開発できるフレームワーク」と評価

結論

  • Railsは最新トレンドとは距離を置いているが、開発の楽しさとシンプルさを取り戻させてくれるツールとして強調
  • 人気よりも作る楽しさと創造性を重視し、「もう一度Railsを試してみてほしい」というメッセージで締めくくられる

関連記事

4件のコメント

 
joyfui 2026-03-14

Rails って「設定より規約」じゃなくて「規約より設定」だったと記憶しているのですが...
 
savvykang 2026-03-14

most of the web frameworks I’d (...) required endless amounts of XML boilerplate and other configuration to wire things up. Rails threw all that away and introduced the notion of “convention over configuration”

LLMが語順を変更せず、入力順のまま出力したようです。原文では正しくなっています。
 
xguru 2026-03-14

LLMでもこういうのは間違えるんですね。修正しておきました。ありがとうございます
 
GN⁺ 2026-03-13
Hacker Newsの意見

  • Railsは本当に大好きだけど、大規模な動的型付けコードベースで働いた経験をして以来、個人プロジェクト以外でRailsに戻るのは難しくなった
    型のない大規模コードベースは、RubyMineのような強力なIDEがあっても保守が悪夢レベル
    最近Sorbetがどれほど進化したのか、特にRoRとの相性が気になる

    • 最近ではRust/Locoが最も興味深いフレームワークだと思う
      Railsの哲学をうまく踏襲しつつ、Rustの学習を容易にしてくれる
    • IHPはHaskellベースのRailsに着想を得たフレームワークで、両方の世界の長所を組み合わせようとしている
      週末に試してみる価値はある
    • 問題は型がないことだけではなく、実行時に関数や属性が定義される構造のせいでデバッグがほぼ不可能なこと
      実際の本番データをローカルに複製したり、サーバーにSSH接続してREPLで状態を調べたりしなければならない
      IDEでのデバッグは地獄のような体験だった
      Rubyは本当に好きだったけれど、ライブデバッグを経験してからは厳しくなった
    • なぜ大規模な動的コードベースがそこまで悪夢なのか気になる
    • 最近は**エージェント型コーディング(agentic coding)**のおかげで、言語やフレームワークの重要性はますます下がっている
      もはやRubyやPythonをあえて選ぶ理由はない
      PythonはML分野でしばらく持ちこたえるだろうが、いずれ消えていく気がする

  • 私もこういう考えを公に言ってくれてうれしい
    最近は過剰なマイクロサービスアーキテクチャにうんざりしている
    夜は余計な構造なしに、単純に問題を解決するプロジェクトに触っている
    昔はPHPの構成を多く扱っていたが、RailsもPHPも結局は問題解決のための道具にすぎない

    • 今年初めから新規プロジェクトでRoRを使っているが、本当に新鮮な空気のような体験だ
      昔のデスクトップIDE開発のように、「箱の中で」すべてが回っている感覚がある
      Web開発の複雑な構成要素の管理から離れ、生産性中心のシンプルさを取り戻した気分だ
      しかもTypeScriptを書かなくていいのが最高。TypeScriptは冗長で不要なボイラープレートの塊だと思う
    • STOAが何を意味するのか気になる
    • 「思考とコードの間の翻訳が最小化される」という表現は、Rubyの本質をよく表していると感じる

  • 私たちは2007年からRailsアプリを本番環境で動かし続けている
    Railsの長寿の秘訣は年齢ではなく、その安定性と実用性にある
    バックエンドでJavaScriptを使えば効率が上がるという主張は、すでに反証されている
    技術スタックの変化の大半は履歴書最適化やトレンドへの不安によるもので、実際のエンジニアリング上の要請ではない
    Railsは静かに本物のビジネスを動かし続けてきた
    NPMの310万パッケージがRubyGemsの19万個より多くの機能を提供していると考える人はいないだろう

    • 私たちも2011年から2社でRailsを本番運用している
      Inertia + Vue.jsへ移行中だが、バックエンドの変更がほとんど不要なほど強力な組み合わせだ
      生産性の向上によって採用の難しさも相殺できている
    • NPMのパッケージ数が多いというのは、ユーザー数が多いことを意味する
      ユーザー数が多いほどエコシステムは健全になる
      ただしRubyGemsにも古いパッケージが多いので、単純比較は難しいと思う

  • RoRやDjangoの**「バッテリー同梱」という哲学は良いが、古いプロジェクトの保守には時間がかかる
    5〜6年物のプロジェクトを更新するには依存関係の管理が大きな負担になる
    そのため最近は    Go**でシンプルなフレームワークを使うか、あるいは何も使わずに開発する方を好んでいる

    • 私は30万行を超えるDjangoコードベースを管理しているが、直接依存は32個しかない
      本当に必要なライブラリだけを使えば保守は容易だ
    • 問題は**継続的な変更(churn)**のように思える
      セキュリティパッチ以外で、わざわざ更新しなければならない理由があるのだろうか
    • Laravelではこうした問題をほとんど経験しない
      この1年半で5つのメジャーバージョンを上げたが、それでも比較的簡単だった
    • 結局、依存関係管理の戦略によって保守の難しさは変わる
      初期に慎重に構成すれば、長い間ほとんど手を入れずに済む
    • 「バッテリー同梱」がむしろアップグレードを難しくしているのか気になる。私は逆だと思う

  • アップグレード体験は過小評価されていると思う
    Next.jsはメジャーバージョンごとに構造が完全に変わるが、Railsは段階的廃止(deprecation)のサイクルが遅く、はるかに安定している
    製品を継続的にリリースするなら、最新のパラダイムよりもインターフェースの安定性の方がはるかに重要だ

    • Railsを長く運用してきた人だけが、この点を本当に理解している
      Next.jsのpages → app router移行は、実質的に全面的なリプラットフォーム級の変化だった
      一方Railsには文書化されたアップグレードパスと予測可能な廃止サイクルがある
      Rubyのバージョン管理もrbenv/asdfのおかげで環境不一致の問題をほとんどなくしている
    • Nextのapp routerへの移行は構造的な大変革なので、この時点ではTanStack Startのような、より意見の少ない代替案を検討する価値がある

  • 私は10年以上RailsでDevOpsから一人Web開発者までやってきたし、やり直しても同じ選択をすると思う
    Railsはすべてが揃ったクリーンで生産的なフレームワークだ
    Stack Overflowの調査でも、依然として「次のプロジェクトで使いたいスタックTop 5」に入っていた

    • Railsの**「一人用フレームワーク」**としての性格は本当に魅力的だ
      インフラ構成まであまり気にする必要がなく、デプロイも簡単だ
    • Railsで実際に仕事をしている人は、わざわざ調査に参加しないのかもしれない
      結局重要なのは他人の目ではなく、自分に合った道具を使うことだ
    • Railsは2004年にリリースされ、今や20年以上続くフレームワークだ
      Djangoより1年早く登場した
    • Stack Overflow 2025調査では、RailsはWebフレームワークの「Admired vs Desired」部門で10位を記録した
      調査リンク

  • 昔はRuby/Railsがほとんどの問題に対する最適解だと思っていたが、今でもやはりそう思う

  • Railsは使ったことがないが、最近のWeb開発環境の混乱には共感する
    だから私は未来を見据えてElixirとPhoenixを選んだ

    • ここ数日でRubyでプロジェクトをやると言ったら、Elixirを勧めてきた人が5人もいた
      次のプロジェクトではぜひ試してみるつもりだ
      Elixirの何がそこまで魅力的なのか、最初に触れるときに注目すべき点が気になる

  • 10年前、スウェーデンの大手放送局のストリーミングフロントエンドをRailsで構築した
    Herokuで100万人以上の同時接続を処理したが、本当にうまく動いていた
    その後はストリーミングインフラ、API、AI/MLなど別の分野へ移ったが、Railsが失敗したからではなく、問題の性質が変わったからだ
    Railsはデータモデルとビジネスロジック中心の問題に向いており、並行性やインフラ中心の問題には別の言語の方が合っている
    Rubyは今でも美しく表現力のある言語であり、懐かしさが大きい

    • 私も「問題に合った道具を選ぶ」という哲学には共感する
      ただ、好きな言語に対する個人的なバイアスを完全に捨てるのは難しいと感じる
      次のプロジェクトではどの言語を選んだのか気になる

  • 静的型付けの欠如を惜しむ人には、Sorbetのような優れたソリューションがある
    Rubyの生産性と静的型付け、LSP統合を同時に享受できる
    ShopifyのおかげでRailsでもSorbetのサポートは充実している
    私は今でもRailsで働きたいと思うほど、このエコシステムが大好きだ
    AIツールの進化のおかげで、今や想像力の大きさだけが限界だと思う

    • 最近AI分野で最大の話題はOpenClawだ
      これをベースに、24時間店舗監視とSlack通知を行うeコマースエージェントを作った
      AI関連のプロジェクトをするなら、selzee.com/openclawはぜひ確認してみる価値がある