【動画】Rails World 2026：オープニング基調講演を振り返る

Railsコミュニティの祭典、Rails World 2026のオープニング基調講演動画が公開されました。次世代のRailsの展望や重要アップデートが語られています。詳細は動画本編をご覧ください。

Rails 9.0に関するニュースを期待していたんだけど、なんだかこれでRuby on Railsも終わりって感じがする。もうHeyですらRuby on Railsアプリじゃなくなってるし、Rustへの書き換えでCPU使用率を99.9%も削減できたなんて話は、間接的にRubyが遅いって認めてるようなものだよね。

彼の政治的なスタンスは一旦置いておくとして、彼が語っていることには真実味があるし、開発者が今直面している、あるいは近いうちに直面する現実をありのままに突きつけていると思う。多くの人にとって、聞きたくないような耳の痛い話だろうね。

特筆すべきは、今回のトークでの彼の視点が、フレームワークの責任者というよりは、完全に「開発者兼ユーザー」の立場から語られていること。これには驚かされたし、Railsにとってはあまり良い兆候ではない気がする。

エージェント駆動開発をこれだけ推奨している割には、この新しいエージェント中心の現実にフレームワークをどう適応させるかという具体的な話が何もない。現状でもエージェントはRailsとそれなりに動くけど、何かを前進させるような動きは今のところ見当たらないね。

僕自身のプロジェクトに関して言えば、彼がRustを使う理由と似たような動機で、大部分をElixir/Phoenixに移行した。本当は新しい言語なんて学びたくなかったけど、今となっては学ばなくていいし、言語の強みを享受できているからね。

昨日、デビッドのトークを最前列で聞いていたんだ。前日に彼と話をしていたから、正直そこまで驚きはしなかったかな（準備ができていなかったわけでもないし）。

#RailsWorld からの現場報告だけど、ここの雰囲気は決して悲観的じゃない。むしろ逆だね。業界がどこに向かっていようと、僕たちの多くは今も「修復屋」として働いている。顧客が頼りにしていて、企業が喜んで対価を払っているシステムを維持管理しているんだ。

僕たちのほとんどは、真っ白なキャンバスに向かって未来のアーキテクチャを設計しているわけじゃない。何年も前に決められた決定を引き継ぎ、古いパターンを更新し、制約の中で工夫し、このクソみたいなシステムを安定して動かし続けているんだ。

最近のツールは、僕たちが引き継いできたシステムについて、もう一度考える機会を与えてくれていると思う。なぜその仕組みになっているのかを解き明かす機会。これまで時間も自信も許可もなくてできなかった、前提を疑うという実験をしてみる機会だ。そして、それを共有すれば次の人やエージェントが少し楽になるはず。

8年前に決めたあのデプロイモデル？もう一度見直す価値はあるよね。Webアプリの中には、ネイティブアプリだったらよかったのにと思っているものも多いだろう。僕たちが「忙しいから」という理由だけで使い続けてきた設計上の決断もたくさんある。

新しいツールが僕たちの仕事に何を意味するのか、不安があるのは当然だ。でも、これらのツールが「何を再検討してもいいか」という許可を僕たちに与えてくれているようで、ますます興味が湧いてくるよ。

キーノートが公開されたら、僕が取り組んでいる、まさにこの好奇心にアプローチするための「プログラミング言語に近しいフレームワーク」についてもっと詳しく話すつもりだ。

それまで……顔を出し続けよう。問い続けるんだ。

Rubyに栄光あれ。Railsに栄光あれ。

これまでのところ、Rustへの書き換えが成功するかどうかは、適切に設計されたテストスイートの存在と（おそらく極めて直線的に）相関している。Bunなどの書き換えが成功しているのはそのためだ。37Signalsの書き換えも同じようになるはず。

書き換えが終わったら、いくつか知りたいことがある。

1. テストスイートによる支援が終わった後、バックエンドでどうやって機能を追加し、同じ品質を維持し続けるのか。LLMによるテスト生成は少し難しくて、往々にして昔Randy Coulmanが呼んだ「トートロジー（同語反復）テスト」を好む傾向があるからね。そうさせないようにするのはかなりの手間だし、37Signalsの面々もこの部分は読み込んでいるはずだ。Rustを一切読まないなんてことは考えられない。

2. 彼らは長年、Railsが得意とする「ドメイン設計」にいくつか革新をもたらしてきた（例えばdelegated typeパターンなど）。Rustでこれをどう再現するのか、ソースコードを読まないとわかるはずがないし、そもそも気にする必要はないのか？さらに、新しいパターンはどうやって生まれるのか？そして、僕たちの強力な抽象化の武器は今後どうやって増えていくのか？

答えはまだわからないけど、その答えを学べるチャンスがあるのは嬉しいね。

DHHのキーノート、すごく楽しめたよ。自身の家系にまつわるストーリーを、美術史と技術進化を重ね合わせた絵画から写真への変遷になぞらえて、今のテクノロジー界で起きていることを説明していたのが秀逸だった。

キーノートでは、これからはプログラマーではなく「モノを作る人（maker of things）」になるという視点が語られていたけど、誰も言及していない疑問がある。なぜAIを直接使うのではなく、わざわざ君が「作った」ものを使う必要があるの？その視点に立てば、アプリという概念そのものが消えてしまうんじゃないかな。

開発者向けのカンファレンスが、今や完全に化けの皮が剥がれた人種差別主義者やファシストに1分でも登壇時間を与えるなんて信じられない。Rails界隈は知らないのか、それとも気にしないのか？

追記：実際のRailsConfからは出禁を食らってるから、これは彼のカンファレンスなのか。悲しい勝利だね。

ネイティブ対Webアプリの問題については、完全に人間が作り出した問題だよね。ゲームエンジンのような決定論的なソリューションの方が好みだったけど、Webの仕様に基づいてエージェントがネイティブアプリをコード化するっていうのも、悪いアイデアではないと思う。

僕にとっての大きな疑問は、オリジナルの実装についてだ。エージェントがそれをやるのか、人間が手でコードを書くのか。個人的な意見だけど、今エージェントをかなり使い込んでいて毎日何千行ものコードをレビューしている立場から言わせてもらうと、自分の頭の中に作りたい仕様が明確にない限り、この方法はうまくいかないと思う。

コードを実際に書く、つまり人間のスピードで打ち込むことで、どんなアーキテクチャにすべきか、どう作るべきかを深く理解できるんだ。頭で考えてアーキテクチャを導き出すなんてことは昔からあまりできていなかったし、エージェントに計画を立てさせて何度も説明させて理解できるものでもない。そして、一度アーキテクチャがわかってしまえば、エージェントがそこまでスピードを上げてくれるとは思わない。コーディングが7日かかるのを1日に短縮してくれるかもしれないけど、その7日間は無駄だったわけじゃない。その過程で将来何年にもわたって配当をもたらしてくれるようなアイデアやメンタルモデルが生成されるんだから。

仕立て屋に「工業用ミシンを使えば、繊細で美しい服を作るスキルが上がるよ」なんて言うかい？そんなはずはないよね。実際、2026年になっても、高品質で繊細な服の多くは手縫いされているんだ。コーディングにも同じことが言える。DHH自身も「ほとんど」という言葉で逃げ道を作っているように、コーディングにもそういう領域は残るはずだ。

僕としては、キャリアの舵を切って、極めて高品質で繊細なカスタムコードを作ることに集中し、エージェントによるコーディングみたいなのは工場の作業員に任せようと思う。エージェントが現れる前からそうしたかったし、今はそれを加速させる必要がある。そう、FAANG（大手テック企業）の仕事なんて、単なる工場労働みたいなものさ。

フロー状態か。

彼が、プログラミングに深く没頭している時に味わえる「フロー状態」が恋しくなると言っていたのは共感する。僕もそれが心配だったんだ。幸い、今のところフロー状態に入る方法は他にも見つけているけど、君も自分なりの方法が見つかるといいね。