ハクソク

世界を動かす技術を、日本語で。

2026年にレールに戻る

75日前原文(markround.com)

概要

  • 副業プロジェクト として自作アプリ開発を決意した体験談
  • Ruby on Rails 8 の現代的な魅力と進化の紹介
  • フロントエンド開発の変化 とHotwire/Stimulusの活用方法
  • 開発ワークフロー やレトロな開発手法への回帰
  • AI生成コンテンツとの葛藤 についての個人的考察

副業プロジェクトから始まるRails再発見

  • バンド活動 の中でセットリストや曲メモ管理の課題を感じ、 自作アプリ 開発を決意
  • 既存のスプレッドシートやチャット では十分な使い勝手が得られず、課題解決のための新規開発に着手
  • https://setlist.rocks を数ヶ月かけて開発、満足のいく成果を得る
  • 趣味的な開発 の楽しさを再認識、Feynmanの「The Pleasure of Finding Things Out」に共感
  • Ruby on Rails を選択した理由は、純粋な楽しみと「初恋の言語」への回帰

Rubyistとしてのこだわり

  • Rails は過去の技術と思われがちだが、個人プロジェクトでは 自分の好きな技術 を優先
  • Ruby の持つ自然な表現力、柔軟なメソッドチェーンやブロック記法の魅力
  • Perl からRubyへ移行し、より直感的なコーディング体験を享受
  • インフラやDevOps領域 でのRuby活用経験、YAMLやHCL主体の現代とは異なる開発体験
  • コミュニティの独自性 やWhy the Lucky Stiffなどの文化的側面にも愛着

エンジンルーム志向の開発スタイル

  • バックエンドやインフラ寄り の開発が本分、フロントエンドにはあまり情熱を持たない
  • 90年代のWeb開発 経験、HTMLやテーブルレイアウト、Matt’s Script Archiveなどの懐かしさ
  • 現代のJSフレームワークやビルドツール には馴染めず、必要最低限の関与に留める姿勢
  • フロントエンド開発 は趣味ではなく、必要に応じて対応するスタンス

Rails 8：懐かしくも新しい存在

  • 長年Railsから離れていたが、Rails 8で再会
  • MVC構造やジェネレータ など基本は変わらず、古い経験でもすぐに馴染める設計
  • ActiveSupport などはSinatra等でも活用し続けていた
  • 内部構造や周辺技術 は大きく進化、特にフロントエンドの扱いが大きく変化

フロントエンドの進化とHotwire/Stimulus

  • Webpack不要の「No Build」アプローチ がRails 8の大きな特徴
  • サーバーサイド生成ページ の現代的アプローチを高評価
  • Hotwire（Turbo & Stimulus） により最小限のJSでSPAライクな体験を実現
    • Turbo ：リンクやフォーム送信を傍受し、ページ断片のみを差し替え
    • Stimulus ：必要な動的要素だけを簡単に追加可能
  • importmap によるJSライブラリ管理の簡便化
    • $ bin/importmap pin @stimulus-components/dialog で簡単導入
    • Webpackやnpm不要 で、Rails標準のアセットパイプラインだけで完結
  • UIコンポーネント はテンプレートやAI生成案を組み合わせて効率的に構築
  • Railsパーシャル 活用による再利用性の高いUI設計

AI生成コンテンツとクリエイティビティの葛藤

  • AI生成UIコンポーネント の利用に対する複雑な心境
  • 音楽やアート、詩など人間らしさの表現 はAIに任せたくないという価値観
  • コーディングも創作活動のひとつ としてAI利用に葛藤
  • Bootstrap等のテンプレート流用とAI生成の違い についての自問
  • 今後もAI活用の是非について内省を続ける姿勢

開発ワークフローとRailsの魅力

  • 「設定より規約」 の思想で、複雑なXMLや設定不要のシンプルな開発体験
  • 短期間で本格的なアプリが構築可能 なフロー
  • モデル設計から実装までの流れ をRailsジェネレータで効率化
  • タグ機能 など実例に基づく開発プロセスの紹介
  • 現代的な開発手法とレトロな楽しさの両立

Hackerたちの意見

Railsは使ったことないけど、「現代の状況」には同意するよ。過去を振り返るんじゃなくて、未来を見ようとしたら、ElixirとPhoenixフレームワークに出会ったんだ。

└

Rubyでプロジェクトを作ってるって言ったら、ここ数日で5人目だよ、Elixirを勧めてくれたのは。次のプロジェクト（何になるかは分からないけど）で絶対チェックしなきゃ。どうしてそんなに魅力的だと思ったのか、最初に見ておくべき「これすごい！」なポイントを教えてくれない？

RailsのDevOpsをやってて、今は一人でウェブ開発を10年以上やってるけど、またやりたいね。こんなに長く続いてるフレームワークは少ないし、それには理由があるよ。全てが揃ってて、整理されてて生産的だし、読み書きしやすい言語だもん。最近のStackoverflowの調査でも、10年以上経っても「次のプロジェクトで使いたいスタックのトップ5」に戻ってきた！試してみて。

└

Railsで何かをやってる人たちは、スタックを盛り上げるためにアンケートに答えたりしないと思うんだよね。まあ、俺だけかもしれないけど。だから、他の人がどう思ってるかなんて気にせず、自分に合ったツールを使ってさっさと進めようぜ。

└

rails = ruby = oo/可変 && 遅い && リソース食い

└

「一人用フレームワーク」っていうのが大きな魅力だね。これを使ってると、どれだけ生産的になれるかに驚いてるし、コードレベルだけじゃないんだよね。25年以上もsysadminやdevops、アーキテクトの仕事をしてきたけど、今はHA PostgreSQLクラスターを立てたり、Redisのことを考えなくていいのが本当に楽だし、デプロイもほぼ解決済みの問題だよ。

└

もう20年以上も前からRailsはあるんだよ！2004年に登場したから、Djangoよりちょっと若いくらい。

こんな風に公に言ってくれてありがとう、私たちがもっといるってことを。アイデアが過剰な擬似マイクロサービスアーキテクチャを救うって聞くのに疲れたし、夜にいくつかのプロジェクトに出くわすけど、STOAや不必要な解決策、アーキテクチャなしで問題を解決してるんだ。RoRには興味ないけど、キャリアの初めは主にPHPを救ってたから、どちらも問題解決者だよ。座って、ミニマルな（PHPの場合は見た目があまり良くないけど）コードを書いて、次のタスクに進もう。

└

新年からライブのグリーンフィールドプロジェクトでRoRを使い始めたんだけど、正直言って新鮮な風を感じてる。昔の「箱から出した」デスクトップ開発の体験に一番近いかも。Visual StudioやIntelliJ IDEA、NetBeans、Eclipseとか、90年代や00年代のIDEでデスクトップソフトを作ってた頃の感じ。Web開発はずっと、10,000個の動くパーツを追いかけるフラストレーションの塊だったから、実際に解決したい問題から気をそらされてた。だから、基本的な作業負荷がいつも高くて、無駄が多すぎるんだよね。でもRailsはそれをぐっと下げて、デスクトップソフトを（少なくとも表面的には）作って、動かして、配布するのに必要な最小限の無駄に近い感じ。もちろん、デスクトップの環境はそれぞれ違うから挑戦はあるけど、日々の開発体験は現代のWeb開発よりずっと摩擦が少ないよ。それに、うんざりするTypeScriptともおさらば。TypeScriptが嫌いなんだよね。醜くて冗長で、ボイラープレートだらけの化け物で、JavaScriptの一番楽しい特徴（ダックタイピング）を捨てちゃうから、最悪だ。

└

ここでのSTOAって何の略なの？

└

FTA: 「考えてることとタイプすることの間には、ほんの少しの翻訳が必要なんだ。それがRubyの本質だと思う。」

RoRやDjangoが提供するバッテリーは好きだけど、古いプロジェクトを維持するのにどれだけ時間がかかるかも思い出す。5〜6年前に始めたプロジェクトを更新するのはすごく時間がかかるよ。その一部は依存関係の管理だね。Djangoの場合、簡単に100を超えることもあるし、その中には特定のバージョンのシステムライブラリでコンパイルしなきゃいけないものもある。Dockerを使っても多くの問題からは逃れられないよ。今は、シンプルなフレームワーク、あるいはフレームワークなしでGoを使いたいな。Goなら、バイナリをコピーするのがすごく簡単だから。

└

時々、ここでの問題は回転率かもしれないと思う。セキュリティ修正は別として、更新された依存関係が本当に何をもたらすの？これらのプロジェクトの中には、ただ…止まってもいいんじゃない？

└

バッテリーが含まれていると、古いプロジェクトのアップグレードがより大変になるってことはあるのかな？逆だと思うけど。

└

今、大きな（少なくとも30万行以上の）Djangoコードベースに取り組んでて、直接の依存関係が32個あるよ。主にlxml、pillow、pandasみたいなもの。素晴らしいDjangoライブラリを使うのはすごく簡単だけど、別に使わなくてもいいんだ。

└

Laravelではそんなにひどい経験はしたことないな。彼らのライブラリはずっと安定してる気がする。ここ1年半でLaravelのメジャーバージョンを5つも上げたけど、どれも結構簡単だったよ。

└

私の経験では、魔法のようなものは簡単な部分をさらに簡単にし、難しい部分をより難しくするんだよね。

└

以前は作業に最低でも1日はかかってたけど、2025年11月以降は1時間もかからないよ。質の高いLLMセッションに当たれば、15分で済むかもね。

└

俺の経験とは真逆だな。

Ruby on RailsとLaravel、最高だね。堅実で、実績があって、安定してて、スケーラブル。

アップグレードの話は過小評価されてるよね。Next.jsのプロジェクトを維持してた時、メジャーバージョンアップで基本的なパターンが壊れたことがあった（ページルーター → アプリルーター、全然違うデータフェッチ）。Railsの非推奨から削除までのサイクルは遅いけど、ずっと破壊的じゃない。製品を出す時には、最新のパラダイムよりも、構築するインターフェースの安定性が重要なんだよ。

└

Nextのページルーターからアプリルーター（デフォルトでRSC）に切り替えるのは、アーキテクチャの大きな変化で、実質的にプラットフォームを再構築することになるよ。軽視しない方がいいし、TanStack Startみたいな意見が少ない現代的な代替案を考える良いタイミングだね。

CRUDをやるならRailsは最高だよ。自動生成の機能もあるし。ただ、アプリが標準的なCRUDパターンに合わないと、いろいろなことをいじくり回す羽目になる。そういう時は、Djangoをおすすめするよ。Djangoは十分な柔軟性を持ちながら、良いベースを提供してくれるから。Djangoにはあまり魔法がないしね。

└

真面目な質問なんだけど、2012年にRoR開発者としてプロのキャリアをスタートした者として、CRUDをやるならバイブコーディングが最高じゃない？軽く言ってるわけじゃないよ。当時、私にとって魔法のように感じたのは、Railsがいくつかの簡単なコマンドで提供してくれたスキャフォールディングのおかげで、ユーザーが認証してデータを入力・表示できるものをすぐに作れたことなんだ。確かに、Ruby自体やその文化も素晴らしかったし、今でも心の中に特別な場所がある。でも、全ての設定よりも規約を重視するやり方やスキャフォールディングの部分が、私が特に好きだったところで、他の言語やフレームワークの組み合わせでは、あんなにスムーズに感じたことはなかった。でも今は、スキャフォールディングにAIを使っていて、サイドプロジェクトではコードに触れることもほとんどない。だから、将来的に頭痛の種になるかもしれないCRUDアプリのために、なんでそんな選択をするのか理解できない。もっと自由な言語やフレームワークを使って、AIにスキャフォールディングをやらせればいいのに。実際にコードを書くのが楽しいなら分かるけど、目標がすぐに動くものを作ることなら、RoRではうまく対応できないものを作る可能性もあるのに、そのメリットがよく分からないんだ。

└

ちなみに、現代のRailsもかなり魔法が少ないよ。彼らは学んだんだ。ActiveJobがフレームワークの一部になったことで、イベントキューや非同期処理がバッテリーの一部として使えるようになった。私はファンボーイだから偏ってるけど、2026年の一般的なビジネス用途にはまだまだRailsは素晴らしいよ。

└

純粋なSaaSアプリを作るなら、Railsは完璧だよ。もしSaaSに加えて、たくさんのWebhookを調整するような複雑なバックエンドサービスが必要なら、Elixirを選ぶかな。ドキュメンテーションサイトや軽いサーバーアプリにはNodeを使うし、もっと真剣なパフォーマンスが必要ならGoやRustが役立つよ。

以前は、Ruby/Railsがほとんどの問題を解決する最良の方法だと思ってたし、今でもそう思ってるけど、昔もそうだった。

2007年からずっとRailsアプリを運用してるけど、ソフトウェアを完全に使い捨て以外のものとして扱うなら、19年以上もずっとそれが正解だったよ（年齢のせいじゃなくて、むしろそのおかげで）。フロントエンドでJavaScriptを使わなきゃいけないからって、バックエンドでも意味のある効率が得られるっていう前提は、今や完全に否定されてる。むしろ、フロントエンドのエコシステムが毎月アイデンティティクライシスを起こすとき、影響範囲が広がるだけだよ。OPの「スタック・デュ・ジュール」やプログラミング言語の「今月のフレーバー」という枠組みはまさにその通り。ウェブソフトウェアアーキテクチャの驚くべき量は、技術的な意思決定として着飾った流行に従っているだけ。技術スタックの変動のほとんどは、エンジニアリングの要件から来てるんじゃなくて、履歴書の最適化やHacker Newsの不安から来てる。Railsはずっと真剣なビジネスを支えてきたんだ。NPMの310万パッケージがRubyGemsの19万パッケージよりも多くの機能を提供していると思う人はいるのかな？

└

うちも2011年から15年以上Railsを本番環境で運用してるけど、すごく役立ってるよ。採用は大変だけど、生産性の向上のおかげでその分はカバーできてると思う。2025年の終わりに、そのうちの1つをInertiaに移行することにしたんだ。公開ページはもう終わってて、ログインエリアの移行は80%終わったところ（かなり大きなアプリなんだ）。Vue.jsを選んだよ。このスタックがどれだけ強力で、バックエンドをほとんど変えなくて済むかは驚きだね。

Railsは大好きなんだけど、大きなRailsコードベースで働いたり、.NETや他のフレームワークで実際に型を使ったりした後だと、個人プロジェクト以外ではRailsには戻れないな。型なしの大きなコードベースで作業するのは本当に悪夢だよ。RubyMineみたいな強力なIDEがあっても、いくつかの問題をカバーするのは難しいしね。最近のSorbetはどれくらい良くなってるんだろう、特にRoRの体験について。

└

手動でコーディングしてるの？

└

Rust/Locoは今、一番面白いフレームワークだね。LocoはRailsのフォーミュラにかなり近いし、ボイラープレートコードを処理してくれるからRustを学ぶのが楽になるよ。