Ruby on Rails はまだ理にかなっていますか？

Ruby on Rails はまだ理にかなっていますか？

2026年10月18日

LLMが存在し、今後も改善され続けることを考えると、Ruby on Rails はまだ理にかなっているか、と尋ねられました。これは、コードを書くことが非常に安価になり、好きな言語で何でも構築できるため、すべてをRustに書き換えるのはなぜではないか、という含みがあります。これは素晴らしい質問であり、明らかにすべての好奇心旺盛な開発者の心にある疑問です。

答えは簡単です。はい、Ruby on Rails や一般的なフレームワークは依然として理にかなっていると思います。それは、構造を提供し、車輪の再発明を避け、セキュリティアップデート、無料のパフォーマンス改善、アップデートによる新機能の追加など、常にそうであった理由と同じです。人間がコードを書く生産性を向上させるために作られたものはすべて、LLMの生産性も向上させます。そして同じ理由で、ライブラリも理にかなっています。プログラミング言語も、データベースも、オペレーティングシステムもです。なぜなら、もしそうでなければ、私たちは皆、最終的なアプリケーションだけでなく、すべてをゼロからRustで書いていることになるからです。

LLMがコードを書くようになったという事実は、私たちが以前に行った抽象化が、突然重要でなくなったり、有用でなくなったりすることを意味するものではありません。Rustでの書き換えを試みたときに、自分で配管作業を書かなければならなかったのは好きではありませんでしたし、LLMにも、少なくともソフトウェアを書くプロセスで、それに多くのトークンを費やしてほしくありません。人々のための製品を構築するとき、私たちはジョブキューやORMを書くことよりも、彼らの実際の問題を解決することに集中すべきであり、LLMがコードの100パーセントを書く状況でも、それは真実であり続けると信じています。フレームワークは、プロジェクトを簡単にナビゲートし、理解し、デバッグし、拡張するための予測可能な構造を提供します。そしてもちろん、LLMもフレームワークとその使用法でトレーニングされています。

多くの人が、大量のトークンを消費して、さまざまな言語に書き換えることができることを示しました。これは、アプリケーション全体を別の言語に書き換えることが実際に簡単になり、単にお金がかかるだけだということでしょうか？少なくとも現時点では、私は確信していません。異なるプログラミング言語、フレームワーク、そしてそれらを取り巻くエコシステムは、すべて異なる制約の下で作成され、異なる設計方向を取りました。これは、別の言語に切り替えるということは、考えたこともなかったようなあらゆる種類の決定を下さなければならないことを意味します。LLMは、目標（同じテストをパスする機能的に同等なプログラムを作成すること）を達成するために、ランダムな決定を下すだけです。

しかし、完全なRustへの書き換えは本当に同じように動作するのでしょうか？多くの動作は、実際にはフレームワーク、ライブラリ、またはプログラミング言語自体によって引き起こされている可能性があります。異なるプログラミング言語を使用するということは、これらの動作の多くがすでに変更されていることを意味します。たとえその上に書くビジネスロジックが計算上同等であってもです。元のアプリケーションの、ユーザーが今日すでに依存しているバグを修正するかもしれません。または、元のフレームワークでは発生しないが、別のフレームワークでは発生する微妙な新しいバグを導入する可能性もあります。いずれにせよ、ユーザーはどのような書き換えによっても影響を受ける可能性が高いと思います。アプリケーションが高速化された場合は良い方向かもしれませんが、突然動作が異なるようになった場合は悪い方向かもしれません。

だからこそ、特にユーザーインターフェースを扱う場合、Rustへの完全な書き換えは難しいと考えています。コードを書くことではなく、徹底的にテストする必要があるからです。私たちのユーザーは、毎日何時間も私たちのアプリケーションを使用するタイプの人々です。彼らは、そのすべての癖や機能に非常に慣れており、仕事を完了するためにそれらに大きく依存しています。ピクセルを少し移動させたり、アイコンや説明を変更したりすると、すぐに苦情が寄せられます。書き換えは、まったく同じように機能するのでしょうか？どうすれば確信できますか？それだけの価値があるのでしょうか、それともすべてのユーザーを、あなたの決定を信頼しなくなるほどイライラさせてしまうのでしょうか？

では、LLMに単に既存のアプリケーションのパフォーマンスを向上させるように依頼できるのに、なぜRustへの書き換えを考えるのでしょうか？ソフトウェアを最適化する方法はたくさんあり、そのほとんどでプログラミング言語を切り替える必要はありません。ボーナスとして、「高速化してくれ」と指示するだけで、動作を変更する可能性ははるかに低くなります。

活発に開発されているフレームワーク、ライブラリ、プログラミング言語は、定期的に改善とセキュリティチェックを受けています。LLMの使用は、それをさらに加速させるだけです。依存関係を更新するだけで、自分でテストすることなく、それらすべてを無料で入手できます。これは以前からそうであり、今日も続いています。おそらく近い将来、新しいRubyバージョンが登場し、既存のコードすべてが10倍高速に実行され、10倍少ないメモリしか使用しないようになるかもしれません。

コードを見て質問できることにも、まだ価値があると思います。それは、LLMがあなたに尋ねなかった決定をしばしば明らかにします。それは、既存のコードや構造がコピーされたものであった可能性があり、既存のコードはすべて正しいだろうという仮定に基づいています。あるいは、プロンプトの言葉遣いが曖昧だったかもしれませんが、あなたが明確にするための質問を引き出すほど曖昧ではなかったかもしれません。結局、テストで見つけることになるでしょう。あるいは、ユーザーが見つけてあなたに不満を言うことになるでしょう。いずれにせよ、私はコードを見ることでこれらの状況を避けたいと思います。そして、コードがRubyでフレームワークがRailsであるということは、エージェントが大量の変更を提案したときに、どの部分が最も重要であるかをすでに知っているということです。

Rustでは得られないRubyを使用する他の利点もあります。変更されたコードのインスタントリロードを可能にし、変更をテストするためにコンパイルを待つ必要がありません。REPLを使用してコードを操作したり、データを検査したり、完全なコンパイルやデプロイサイクルなしでスクリプトを簡単に実行したりできます。コーディングエージェントがこれらの機能を頻繁に使用して問題を迅速に診断するのを見てきました。

これらすべてを踏まえて、私は確かに興奮しており、特にパフォーマンス上の理由から、そして好奇心から、そして私にとって新しいことを学ぶ機会になるから、ソフトウェアの一部を別のプログラミング言語に書き換える可能性について考えています。私にとってそれはGoプログラミング言語でしょう。そのシンプルさと高速なコンパイル時間のためです。私はGoを自分でたくさん書くのは好きではありません。かなり冗長で繰り返しが多いと感じるからです。しかし、いずれにしてもそれほど多く書く必要はありません。そして、たとえ書いた経験が少なくても、非常に読みやすいです。Goはコンパイルもかなり速いため、特にRustと比較して、比較的迅速なイテレーションとデプロイが可能です。Rustはもちろんさらにパフォーマンスが高くなりますが、コンパイルが遅く、コードが読みにくいという欠点が伴います。ほとんどの場合、Goのパフォーマンスは十分すぎるほどです。既存のRailsスタックとの複雑な相互運用性の必要性を回避するために、バックグラウンドで使用されるいくつかのユースケースがあります。

フロントエンドでは、Svelteを非常に楽しんでおり、開発中のホットリロード機能が好きです。これは、スタイルやレイアウトを試すときに便利です。しかし、フロントエンドを（HTMXから）Svelteに切り替えるということは、かなり大きな破壊的変更を意味します。理想的にはSvelteKitを使用し、バックエンドでNodeを実行することになります。これは基本的にJavaScriptでの完全な書き換えを意味します。あるいは、RailsバックエンドはJSONまたはGraphQLとしてデータを提供する必要があります。私はこの種のフロントエンド/バックエンドの分割はあまり好きではありません。それは、バックエンドへの多数のHTTPリクエストを待つ間に、いたるところに恐ろしいスピナーと脈打つ灰色のプレースホルダーをもたらすからです。おそらく、LLMがバックエンドとフロントエンドの両方を担当する場合、それらの問題も担当できるでしょう。

LLMにすべてをRustに書き換えさせるという決定に戻ると、最終的にはソフトウェアの責任者は人間であり、行われた決定を説明する必要があります。そして、その人間が私である場合、私は少なくとも今のところ、現在のアプリケーションをRailsで構築し続けることを選択します。他にエキサイティングな技術はありますか？はい。それはRailsよりも多くの問題を解決しますか？おそらく違います。新しいプロジェクトにRailsを使用しますか？間違いなく。ただし、新しいものを試してみて、それがどのように見え、どのように感じられるかを確認することにもっと惹かれるでしょう。Rustを何かで使用しますか？パフォーマンスが他のすべてよりも重要になるものを作りたい場合は、おそらくそうですが、ほとんどのありふれたビジネスソフトウェアにはあまり適していないと思います。

結論として、Ruby on Rails はまだ理にかなっていますか？はい、そうだと思います。