本文へ
ハクソク

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

Railsについてはどうですか？

元記事: 原文(jardo.dev)

概要

  • DHH がRails World 2026の基調講演でRailsの将来像を語らず
  • LLM活用 やRust移行を強調し、Rails離れを示唆
  • Heyなど主力プロダクトも Railsから別スタックへ移行
  • Railsの今後やビジョンが 不透明 なまま
  • 楽観論や自己肯定のみで 具体策や方向性は提示されず

DHHのRails World 2026基調講演とその影響

  • David Heinemeier Hansson（DHH） は依然としてRuby on Railsのリーダー的存在
  • 彼の発言や行動が Rails開発者やクライアントに直接影響
  • Rails World 2026の基調講演でRailsの未来像はほぼ語られず
  • 代わりに「 プロのプログラマー引退宣言」「今後は“maker”として活動」と発言
  • 英語が最良のプログラミング言語 （LLMの進化により）と主張
  • LLMによるコード生成に全面的にシフト、 手書きコーディングの経済的価値の低下 を強調
  • Rustやネイティブアプリ開発 への転換を明言、Heyの新バージョンも新スタックで構築
    • サーバーサイドはRust、クライアントは各プラットフォームのネイティブアプリ
  • Rustは「人間には醜いがLLMには最適」と評価、 自身はコードを読まない 姿勢
  • 今年はコードの3%しかRubyで書いておらず、 Railsからの距離感を示唆
  • 「 人間がコードを読むのは例外的なケース」とし、LLM主導開発を推進

Railsへの姿勢の変化とその矛盾

  • Railsは「 必要に迫られたWebアプリのための選択肢」へと位置付けを縮小
  • Convention over Configurationも「 トークン効率」へと再定義
  • Railsは「 成熟し安定したフレームワーク」として評価されるも、DHH自身の関心は薄れる
  • CLI（コマンドラインインターフェース）重視 の要求は、37signalsのUI/UX重視路線と矛盾
  • Heyの再構築理由も「Webの表現力不足」だが、同時に「全てCLIで操作したい」と発言
  • 差別化や戦略の不在 が浮き彫り

Railsコミュニティの今後とリーダーシップ問題

  • Mosscap プロジェクトは「Railsは完成し、今後は保守中心」と主張
  • Hanami は明確なロードマップとビジョンを提示
  • Railsの日々の開発は Shopify等の他社が主導、DHHのリーダーシップは後退
  • HeyやBasecampなど代表的Railsアプリの離脱は 象徴的な出来事
  • DHHの講演は「 自信や称賛だけで具体的な計画は皆無」
  • 他のフレームワーク（Django、Laravel、Spring Boot）にも通じる空虚な激励

AI・LLM開発への懐疑と現実

  • 37signalsのプロダクトは シンプルさとマーケティングで成功、難易度の高い技術的課題は少ない
  • LLMによるコード生成は 小規模・簡易なアプリには有効 だが、現状では人間の確認が不可欠
  • DHHの「行数」比較は 指標として不適切 で、本人もその矛盾を自覚
  • Rustのパフォーマンス向上も、Webアプリ廃止による効果と区別が困難
  • 10倍・100倍・1000倍プログラマー論 も根拠に乏しい
  • Basecamp 5の「Swiss cheese」アーキテクチャは LLM開発の失敗例 として紹介
  • セキュリティや品質管理の課題 も未解決

Railsの未来とコミュニティへのメッセージ

  • DHHはHeyのRails離脱を発表しつつ、 Rails開発者には根拠なき称賛のみ
  • Railsが「完成」し保守フェーズに入るなら 明確な宣言が必要
  • もし新たなビジョンがあるなら 具体的な方向性の提示が不可欠
  • 楽観論やAI万能論だけでは不十分
  • Railsの将来像やリーダーシップの空白が 最大の課題

提供: ハクソク · 要約更新:

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

37signalsは、革新的な機能ではなく、意見が反映されたUI/UXで製品を差別化してるんだよね。ウェブの忠実度が足りないから、Heyを6つのネイティブアプリに書き直してるみたい。だから、UIは完全な書き直しを正当化するほど重要だけど、みんなCLIが欲しいの？最近これを何回か見かけたけど、もうUIを作るのはやめた方がいいよ。誰もUIとやり取りしたくないんだから。みんなのアプリはチャットボットで使えるAPIであるべきだよ。私のアプリを除いてね — 私のアプリは手作りの奇跡的なUXで、UIは世界の見方を変えるものだから。結局、これは昔からの議論と同じで、今はシェルパイプラインの代わりにLLMがあるだけ。機能性やユーザーへの価値に関して、ソフトウェアは柔軟で構成可能であるべきなんだ。80年代からそれは分かってた。でも、ソフトウェアを靴のように製品として売るモデルは、それとは相容れない。ユーザーがたくさんお金を払う理由を作るためには、大きなモノリシックなアプリケーションが必要で、印象的なインターフェースも求められる。ソフトウェア業界はそのモデルの上に成り立ってる。モノリシックなソフトウェアが目的に合わない場合、つまり大きなシステムの一部として必要なときは、（ほとんど無償の）OSSに頼るしかない。今はLLMのおかげで、技術的な知識がほとんどなくても、人間向けの非構造化データ/インターフェースの上に「プログラム可能な」インターフェースを貼り付けられるから、みんなそれをやるのは当然だよね。だから、最終的にはAPIからUI、またAPIに戻るまでの非常に高価なパイプラインができちゃう。真ん中のレガシーな「人間中心」のレイヤーと、それに基づいて築かれた業界がどれくらい持つのか、ちょっと気になるな。（ちなみに、チャットボットはほとんどのことに対してUIとしてはあまり良くないし、ユニバーサルUIを作る問題もまだ残ってる。でも、実際には多くのことに対して、人々は特定のタスク用の良いUIよりも悪いユニバーサルUIを好むことが分かった。）

└

最近これを何回か見かけたけど、もうUIを作るのはやめた方がいいよ。誰もUIとやり取りしたくないんだから。みんなのアプリはチャットボットで使えるAPIであるべきだよ。最初のスマートフォンが出たときも同じことがあったよね。「モバイルファースト」って言って、みんなスマホで何でもやるって言ってた。デスクトップは死んだ、すべてのアプリは主にスマートフォン用にデザインされるべきだって。結局、スマートフォンは一部のことには良いインターフェースだけど、他のことにはあまり向いていなかったってことが分かった。クラウドネイティブのムーブメントも同じだね。

└

みんなのアプリはチャットボットで使えるAPIであるべきだよ。こういう意見はよく見るけど、UIには顧客のニーズに応える以上の目的があるんだよね。それはニーズを形作るためにも使える。例えば、食料品店に行く代わりに、電話をかけて必要なものを伝えるって想像してみて。時には、自分が何を必要としているか分からないこともあるし、時には計画していなかったものを発見して買うこともあるんだ。

└

今はLLMのおかげで、技術的な知識がほとんどなくても、人間向けの非構造化データ/インターフェースの上に「プログラム可能な」インターフェースを貼り付けられるから、みんなそれをやるのは当然だよね。私はそれがみんなの望むものだとは思わないし、少なくとも私が望むものではない。私の理想のソフトウェアは、主要なインタラクションのためにしっかりデザインされたユーザーインターフェースを持っていて、基盤となるデータモデルを操作することではなく、達成しようとしている目標に集中できるようにしてほしい。さらに、基盤となるデータへのアクセスも提供してほしい。理想的には、ローカルでアクセス可能なAPIの形で、必要ならリモートでも構わないし、その上にCLIもあれば嬉しい。

└

チャットは多くの体験の入り口として素晴らしいと思う。親しみやすさと柔軟性は比類がないよね。問題は、チャット体験をタスク特化型のアクションにどう進化させるかってこと。私は聖書を探求するアプリを作ってるんだけど、チャットは素晴らしい出発点だよ。でも、実際の聖書を読む段階に入ると、ひどいものになる。これからもっとこういうことが見られると思う。チャットから体験を進化させる方法を考えてみたんだけど、他の人たちのアイデアも気になるな。 https://trysojourn.app

└

「人々はUIを作るのをやめるべきだ。誰もUIとやり取りしたくない。」UIが完全にローカルで、チャットがそうじゃないなら、UIの方がいいな。

└

LLMがCLI/API駆動の開発に役立つかもしれないと思ってる。少なくとも、私の経験ではそうだった。ほとんどのプロジェクトにはUIがあるけど、LLMが直接やりとりできるようにCLI/APIバージョンも作ってる。もう1年以上この「CLI駆動開発」アプローチを使ってて、素晴らしい結果が出てるよ。CLIの引数があれば、LLMが自分が書いたソフトウェアと簡単にやりとりできるからね。私はいつもLLMにライブラリを作るように頼んで、それをCLIとRESTful APIとして公開してる。

└

機能性やユーザーへの価値の観点から、ソフトウェアは柔軟で構成可能であるべきだ。技術的に優れたユーザーにはそうだけど、他の人にはUIは驚きが少ない原則に従うべきだね。

└

UIは素晴らしいけど、UIが見えなくなるとダメだよね。言葉は素晴らしいUIだ。音声や触覚に簡単に変換できるし。言葉を使って正確にこれを行うシステムはすでにたくさんある。確かに、きれいなグラフィックスはいいけど、その唯一の目的は情報を伝えることだよ。情報を簡単に伝えられないユーザーインターフェースは悪いインターフェースだ。現代のAIの世界は完璧ではないけど、アクセシビリティが必要な多くの人々にとっては、これまでのどの技術よりも彼らの生活にポジティブな影響を与えてると思う。

└

チャットボットと話すよりもUIの方が絶対好きだよ。あれは恐ろしいね。

Railsが死んでるのは明らかで、創業者に大きく依存してるから良くも悪くもそうなってるよね。彼が他の誰かに引き継ぐよりも、こうやって自ら終わらせることを選んだのはかなり示唆的だと思う。技術的なメモとして、太いクライアントがいくつかあるデザインは、サーバーサイドでレンダリングされたHTMLを必要としないっていう大きな違いがあるんだ。プログラミング言語に関係なく、サーバーの負荷が減るからね。Rubyでかなり軽いJSON APIを書けると思うけど、パフォーマンスは結局、ネットワークとDBの使用に支配されるから、コンパイル言語での同様の実装と比べてもそんなに変わらないよ。

└

https://github.com/rails/rails/commits/main/ https://github.com/rails/rails/graphs/contributors?from=6%2F... DHHからのコミットはゼロだね。彼はもう他の人に権限を渡したみたい。

Hacker Newsで議論の続きを見る