Ruby on Rails の未来とエージェント開発への移行

DHHのエージェント開発への転換とRustへの移行

Ruby on Railsの創始者であるDavid Heinemeier Hansson(DHH)は、ソフトウェアエンジニアリングのアプローチに根本的な変化を示しており、手書きコードから「エージェント開発(agentic development)」のモデルへと移行している。彼はRails World 2026の基調講演で、自分を「プロのプログラマー」ではなく「創造者(maker)」と位置づけ、大型言語モデル(LLM)の能力により、英語が現在の主要なプログラミング言語になったと主張した。

DHHの新しい技術戦略の主なポイントは以下の通りである:

  • 手書きコードの放棄: DHHは、手でコードを書くことは大多数のプログラマーにとって経済的に生産的ではないと主張。人間が生成されたコードをほとんど読む必要がないワークフローを推奨し、コードレビューをSentryでのバグ調査と同様に例外扱いにするべきだと述べている。
  • バックエンドでRustへの移行: DHHはかつてRustを「人間にとって醜い」と批判してきたが、現在はLLMにとって非常に効果的であるため、Rustの導入を推奨している。彼はRubyが年間コード出力の3%に過ぎず、LLM生成のRustコードが急増していると報告している。
  • ネイティブアプリケーションの優先: 37signalsは、主力メール製品Heyを、さまざまなプラットフォーム向けの6つのネイティブアプリケーションに書き直している。DHHは、以前のウェブアプリへの依存は、小規模チームの生産性を補うための妥協策であり、LLMによるコード生成の効率性が高まった今、もはや必要ないとしている。
  • CLI最優先の統合: DHHは、すべてのサービスがCLIを提供する未来を予想しており、AIエージェントがUIを必要とせずにサービスとやり取りできるようにする。

Ruby on Railsエコシステムへの影響

DHHが37signalsの主力製品がRailsスタックから離脱すると発表したことにより、フレームワークの長期的ビジョンについて不確実性が生じている。20年間、Railsは「小規模チーム、野心的な製品」のためのツールとしてマーケティングされてきたが、DHHの現在の方向性はその範囲を狭めているように見える。

「メンテナンスモード」の議論

コミュニティ内では、Railsが成熟し「完成した」という状態に達したかどうかの議論が広がっている。一部の開発者は、Railsが安定した成熟したフレームワークであり、LLMにとって「トークン効率的」なコンベンションを持っているため、メンテナンスやエージェント開発に適していると主張する。他方、プロジェクトMosscapは、フレームワークは実質的に完成しており、メンテナンスのみが必要だと指摘している。

BDFLの影響

批判者たちは、オープンソースにおける「Benevolent Dictator for Life(BDFL)」文化が、リーダーの個人的な関心が変わると、フレームワークに不安定さをもたらすと指摘している。基調講演でRailsの明確なロードマップが提示されず、代わりにAIに関する一般的な楽観論が述べられたことから、一部の開発者はDHHのリーダーシップから完全に切り離す必要があると主張している。これにより、フレームワークの継続的な進化が確保されるべきだと考えている。

エージェント理論の技術的批判

業界の専門家や開発者たちは、「コードを一切見ない」という主張や基調講演で述べられた主張に対して、いくつかの懸念を表明している。

構造的劣化

批判者たちは、Basecamp 5の「スイスチーズアーキテクチャ」を例に挙げ、レビューされないエージェント生成コードが構造的な劣化を引き起こすことを指摘している。これはShopifyのCEOであるTobi Lütkeの警告とも一致しており、彼は「スロップグレネード(slop grenades)」——低品質なAI生成コード——がコードベースを損なう可能性があると警告している。

パフォーマンスとメトリクス

DHHは、HeyをRustバックエンドに移行したことでCPU使用量が99%、メモリ使用量が95%削減されたと主張した。しかし、技術的な批判者たちは、この数値が誤解を招くと指摘している。なぜなら、ネイティブバックエンドとフルウェブアプリケーションを比較しているためであり、Webフロントエンドを含まない純粋なRubyバックエンドでも同様の改善が見られるため、Rustの影響を明確に分離することは不可能であると述べている。

SREにおける信頼のギャップ

サイト信頼性エンジニア(SRE)たちは、LLMに100%のコードを任せることの安全性に疑問を呈している。懐疑派の間では、99%の正確性は確かに素晴らしいが、残りの1%の幻覚(hallucinations)が本番環境で壊滅的な影響を及ぼす可能性があると合意しており、特にLLMがデプロイコードも生成する場合、そのリスクはさらに高まる。

コミュニティの視点:移行への反応

新しいパラダイムの正当化

一部の開発者はDHHに同意し、業界全体が「プログラミングの機械的側面」を自動化する方向に進んでいると主張している。彼らは、静的型付け言語であるRustが、エージェントフィードバックループに適していると指摘しており、コンパイラがRubyにはない厳密な安全網を提供するからだと述べている。

Web/Railsの継続的有用性の主張

他の開発者は、多くのアプリケーションにおいてRubyのパフォーマンスオーバーヘッドは無視できるほど小さいと主張している。アプリケーションがI/Oバウンドである限り、AIを補完的に活用したRailsの生産性の向上は、Rustへの書き換えの利点を上回ると考えている。

ネイティブアプリのトレンド

一部の観察者たちは、DHHがネイティブアプリに移行する動きが、業界全体の認識の変化を反映していると指摘している。以前はOSバージョンの管理が労力が大きかったため、ウェブが配信手段として使われてきた。AIがネイティブアプリの構築コストをほぼゼロにまで引き下げた場合、HTML/CSSよりも優れたUXとパフォーマンスを提供するクライアント・サーバーアーキテクチャへの業界の移行が起こる可能性がある。

主な主張の要約

パースペクティブ Railsに対する見解 AIコーディングに対する見解
DHH / 楽観主義者 ウェブアプリ用の安定したツール;生産的な唯一の手段ではない。 人間はエージェントを指揮する「創造者」であるべき;コードを読むことは時代遅れ。
懐疑主義者 / 伝統主義者 明確なビジョンがないと停滞の危険がある;新たなリーダーシップが必要。 「スロップグレネード」と構造的劣化は、人間によるレビューがなければ避けられない。
現実主義者 I/Oバウンドアプリや迅速なプロトタイピングには依然として非常に効果的。 AIはボイラープレート用の強力なツールだが、エンジニアリングの代替手段ではない。

Sources

関連