Kaigi on Rails 2026 参加レポート ――生みの親のキーノートから企業ブースまで、学びが詰まった2日間

こんにちは。RIZAPテクノロジーズのバックエンドユニットに所属する新卒1年目の大石、佐伯、佐藤です。

2026年10月16日（金）・17日（土）に、ベルサール渋谷ガーデンで「Kaigi on Rails 2026」が開催されました。

Kaigi on RailsはRuby on Rails（以下、Rails）のユーザーのための技術カンファレンスで、「A Conference for Ruby on Rails users」を掲げています。7回目となる今年は、なんとRailsの生みの親であるDHH（David Heinemeier Hansson）さんが来日し、キーノートに登壇しました。さらにRubyの生みの親であるまつもとゆきひろさんもキーノートに登壇し、RubyとRailsの生みの親の話を同じ会場で聞けるという、Railsエンジニアにとってまたとない機会になりました。

この記事では、参加した3人の視点から、2日間の様子をご紹介します。参加できなかった方にも、当日の熱気が少しでも伝われば嬉しいです。

会場の雰囲気

会場に入ってまず驚いたのがその広さです。セッションルームは大きいMagenta Hallと少し小さめのLime Hallに分かれていました。Lime Hallですら数百人は入りそうな規模で、Magenta Hallに至っては千人入るのではないかと思います。Magenta Hallで後方の席に座ってしまうと、登壇者の表情が見えなくなってしまうほどでした。

これだけ広いホールが本当に埋まるのだろうかと思っていましたが、Magenta Hallで行われたOpeningではなんとほぼ満席。参加者の方々の年代は学生からシニアまで幅広く、Railsが世代を問わず使われている技術であることを実感するとともに、日本にはRailsの仲間がたくさんいるのだと心強く感じました。

お弁当の無料配布や同時通訳（日英・英日）レシーバーの貸し出しなど、運営の配慮が行き届いていたことも印象に残っています。こういったホスピタリティが、Kaigi on Railsがたくさんの人に愛されている理由なのかもしれません。

キーノート

キーノート：DHH

Kaigi on Rails 2026の幕開けを飾ったのは、DHHさんのキーノートです。話の中心は、Rubyが大切にしてきた価値観と、AIの時代にエンジニアがどうあるべきかについてでした。

DHHさんはRubyに出会ったとき、それまでの言語とはまったく異なる印象を受けたそうです。当時は実行速度などの効率性を重視する言語が多い中で、Rubyには書いていて楽しいことや美しさといった、速さ以外の大切な側面があったからです。

一方で、DHHさん自身が「Rubyは遅い」と言われることに正面から触れていたのが印象的でした。それでも、同じものを作るならRubyのほうがずっと少ないコードで書けて読みやすい。速さが必要になったらAIエージェントに改善してもらえばいい。そんな話があり、とても共感しました。業務では、人が書いたコードを読んだり、自分のコードを誰かに読まれたりすることが日常的にあります。だからこそ、コードは読みやすいほうがいいはずです。

後半では、AIの時代を生きるエンジニアとしての姿勢についても語られました。DHHさんが紹介した、レーニンの言葉とされる「何も起きない数十年もあれば、数十年分のことが起きる数週間もある」のとおり、AIの登場により開発のあり方が大きく変わっています。自分の技術を奪われたように感じて怒る人もいますが、怒っても時代は止まってくれません。そう話したうえで、DHHさんはトークを「Become a beginner again.（もう一度、初心者になろう）」という言葉で締めくくりました。

変化を怖がるのではなく、初心者の気持ちで新しいことを楽しもう。Railsの生みの親からそう背中を押してもらえた、勇気の湧くキーノートでした。

キーノート：Matz

2日目は、Rubyの生みの親であるまつもとゆきひろさん（Matz）のキーノートから始まりました。タイトルは「I want both」。開発効率と実行効率、その両方が欲しいというメッセージです。どちらかを諦めるのではなく両方を求める姿勢に、Rubyらしい欲張りさを感じました。

開発効率の面では、遠藤さん（mame）のベンチマークが紹介されました。Claude Codeに複数の言語で同じプログラムを書かせると、Rubyなどの動的言語のほうが時間もコストも少なかったそうです。「人間に優しい記法で設計されたRubyは、AIにとっても優しい言語である」という話には、こうした裏付けもあり納得しました。

実行効率の面では、Matzさんが開発しているSpinelが紹介されました。RubyのコードをCに変換し、ネイティブバイナリにするコンパイラです。evalなどの動的な機能には制約があり、今のRailsアプリをそのまま変換できる段階ではないそうです。それでも、いつかRailsアプリをSpinelでコンパイルして動かせるようになれば、Railsでも「I want both」が叶うかもしれません。

これからのRubyとRailsの進化が楽しみになるキーノートでした。

3人の印象に残ったセッション

今回参加した3人が、それぞれ1本ずつ特に印象に残ったセッションについてレポートいたします。

小さく作ってわかるRailsの仕組み ～mini-rails～（Noboさん/紹介：大石）

＞＞ セッション紹介ページ（Kaigi on Rails 2026 公式サイト）

登壇者は新卒3年目のエンジニアの方で、Railsのソースコードを読もうとしたものの、難しくて読み進められなかったそうです。私も同じ壁にぶつかった経験があり、他人事とは思えませんでした。

印象的だったのはその後の取り組みで、Railsの仕組みを自分の手で再現する「mini-rails」を作ったとのこと。「読んで理解できないなら、小さく作って理解する」という発想と、それを実際に形にした姿勢に感銘を受けました。Railsの内部を知りたいけれど、何から手をつければよいかわからない方におすすめしたいセッションです。

作れる、でも消せるか？──安全に「枯らして消す」機能削除術（Miyuki Koshibaさん/紹介：佐藤）

＞＞ セッション紹介ページ（Kaigi on Rails 2026 公式サイト）

「機能を作るのは簡単になりました。でも、消すのはどうでしょう？」という問いかけから始まるセッションでした。普段は新規機能の開発に携わることが多いのですが、振り返ると「この機能はどう削除されるべきか」を意識して実装できていなかったと気づかされました。

印象的だったのは、「枯らしてから消す」という進め方です。いきなり消すのではなく、まず機能を使わせないようにして値を返すのもやめ、古いアプリのバージョンにも配慮しながら段階的に使われない状態にしていきます。そしてトラフィックやデータが枯れてから、安全な順序で消していくというものでした。一度リリースした機能は簡単には消せないからこそ、この型を知っているかどうかで、消せるか消せないままかが分かれるのだと感じました。型を知っておけば、新規開発の段階から削除しやすさを考えて設計できそうです。

Web Framework Benchmark Battle 2026, Any%（Akira Matsudaさん/紹介：佐伯）

＞＞ セッション紹介ページ（Kaigi on Rails 2026 公式サイト）

RubyとRailsのコミッターである松田明さんによるセッションです。

もともとはRailsのベンチマークスコアを「手段を問わず」引き上げるという内容でしたが、途中からSpinel on Railsの話に切り替わるという予想外の展開に驚きました。Railsアプリ全体はまだ動かない段階とのことですが、松田さんは楽しんで挑戦しているように見えました。

印象に残ったのは、Spinelの型推論を助けるうえでRailsのRBSエコシステム（型定義）が重要になる、という松田さんの見解です。Railsの型定義が充実すれば、IDEでの型補完もより便利になり、Railsのパフォーマンスだけでなく、開発やレビューの効率にも恩恵がありそうだと感じました。書きやすさはそのままに速く動くRailsの実現に、今後も期待しています。

ブースとアクティビティ

セッションの合間には、スポンサー企業のブースを回りました。これまでのRailsを用いた開発の歴史を展示するような真面目な内容から、Railsで実装されたゲームをプレイできるユニークなものまで様々でした。

企業ブースを歩いていると、なんとDHHさん、Matzさんと一緒に写れる（合成の）プリクラを発見しました！大はしゃぎでプリクラを撮ってきました。

こうした限定のコンテンツに出会えるのも、オフラインカンファレンスならではの魅力だなと感じました。

終わりに

DHHさんやMatzさんのキーノートをはじめ、2日間で多くの刺激をもらえたカンファレンスでした。

懇親会では、他社の新卒エンジニアの方々と話す機会があり、同じ立場ならではの話題で盛り上がりました。

ここで得た学びは、chocoZAP（チョコザップ）の開発にも活かしていきます。来年もぜひ参加したいです！

最後までお読みいただき、ありがとうございました。