#kaigionrails Kaigi on Rails 2026に参加しました

イベント

2026/10/16-17に、ベルサール渋谷ガーデンで開催されたKaigi on Rails 2026へ現地で参加しました。
https://kaigionrails.org/2026/

Kaigi on Rails 2026 会場に着いた

[image or embed]

— thinkAmi (@thinkami.bsky.social) 2026年10月16日 10:49

　
資料などは以下にまとめられています。
https://scrapbox.io/ruby-jp/Kaigi_on_Rails_2026

　
最近のAIの流れやRails World 2026まわりで、今後どうなっていくのかというやや不安な気持ちを抱えての参加でした。

しかし、参加した後は「引き続きやっていこう」「こういうのが作りたい」といった前向きな気持ちになれました。参加してよかったです。

　
以下、参加したセッションなどの簡単なメモです。

　
目次

　

1日目

Keynote: Where the tracks go next

初めてDHHを生で見ることができて、参加してよかったと思いました。一方で、Rails World 2026での出来事もあり、どんな話になるのかドキドキしながら聞きました。

その中でも、Railsは長年にわたって効果の高い投資であるという話があり、なるほどと思いました。それとともに、今後どうしていこうかと考えました。

　

お昼休み

たまたま相席した方々と最近のAIや学び方、Omarchyなどの話をしました。

色々と刺激を受けたり、現在の方向性を再認識できたりするなど、良い時間でした。ありがとうございました。

　

FactoryBotをやめればRSpecは速くなるのか？

FactoryBotをやめればRSpecは速くなるのか？ - Speaker Deck

CIに時間がかかっているので、どのような手段があるかが気になって参加しました。

　
RailsのFixturesへ移行しなくても、

など、まだまだやれることがありそうだと分かりました。

　

AIエージェントのデバッグ能力を向上させよう — AI時代にRailsが輝く理由

AIエージェントのデバッグ能力を向上させよう — AI時代にRailsが輝く理由 - Speaker Deck

Railsではデバッグに必要な情報を手に入れやすい仕組みがそろっていると理解できました。

また、debug-mcpを使うと、人間がデバッガでやっていることをAIに任せられると知り、使える場面がありそうだと思いました。
https://github.com/rira100000000/debug-mcp

　

Domain Modeling with Vanilla Rails: 「操作」から再考するRailsの設計論

Domain Modeling with Vanilla Rails

Railsでのモデリングに興味があり参加しました。

サインアップフォームを題材に、要件が増えたときにどんなふうに実装するのが良いかを解説されていました。

まだ消化しきれていないところはあるものの、「詳しくは『パーフェクト Ruby on Rails』の次の改訂版で」という旨の話が出てきて、お世話になった本がさらに改訂されるのかと思い、それを読むのが楽しみになりました。

　

現場と育てるRailsモデリング 〜Spreadsheetから始めたモデル設計〜

現場と育てるRailsモデリング 〜Spreadsheetから始めたモデル設計〜 - Speaker Deck

現場の運用を理解しないまま作り直すのではなく、Spreadsheetで小さく作って見せながら認識合わせをしていっているのが印象に残りました。

AIで何でもすぐ作れる今だからこそ大事だと感じました。

　

ActionController meets Protocol Buffers… たのしい API スキーマ定義!

ActionController meets Protocol Buffers - Speaker Deck

普段はOpenAPIでREST APIを定義して使っている中、RailsとProtocol Buffersの組み合わせだとどうなるのかを知ることができて良かったです。

また、Linguistを使ったGitHubでの表示方法制御も参考になりました。
https://github.com/github-linguist/linguist

　

Railsバージョンを4倍にした話 〜Rails 2系から8系へ〜

Railsバージョンを4倍にした話 - Speaker Deck

最近、自分のリポジトリのRailsをAIとともに6.1→8.1にした時は、テストやCI、フォーマッターなどを追加した後でバージョンアップをしました。これだけでもそこそこ大変だったのですが、2系から8系にするのはどれほど大変なのだろうと思い参加しました。

　

考古学的な調査や、テストの整備、動作環境の整備などを行っていて、やはり丁寧にバージョンアップをしていくのが近道になると再認識しました。

また、「コード量が少なければ、2系→8系のような大きなバージョンアップは1つずつ上げるのではなく、8系でrails newしてファイルをコピーしたほうが早い」という旨の話がありました。たしかにAIとともに進められるのであれば、それが良さそうだと感じました。

この「新しいバージョンでまっさらなものを作ってから移植する」という考え方は、AIと組み合わせるのならば、他のフレームワークでも有効そうだとも思いました。

　

Railsのためのパスキー実践入門 〜マルチテナントSaaSでの意思決定〜

Railsのためのパスキー実践入門 〜マルチテナントSaaSでの意思決定〜 - Speaker Deck

ふわっとしかパスキーを理解していなかったので参加しました。

パスキーを導入するときに考えるべきことがまとまっていて参考になりました。必要に応じて参照したいと思います。

また、1人あたり上限15個までパスキーを登録できるようにしたり、パスワードでのログインも残したりと、紛失についても備えているようでした。自分が導入することになった時はこのあたりもよく考えてみたいと感じました。

　

全ての永続トークンを、生まれる前に消し去りたい！

全ての永続トークンを、生まれる前に消し去りたい！ - Speaker Deck

無期限・長寿命で強い権限を持つトークンの扱いについて考えさせられたセッションでした。

有効期限を短くしたり、権限を適切な範囲にしたりと、考えていくポイントがまとまっていました。

これらを丁寧に検討して、意思決定していくのが大事だと感じました。

　

2日目

Keynote: I want both

1日目のキーノートを聞いた後、今後どうしていこうかと考えさせられたままでした。

そんな中、朝一番でMatzからSpinelやRoundhouseの話を聞きました。

この話を聞いて、自分は自分でまだまだやれることはあるかもしれないなと前向きな気持ちになれる、そんな良いキーノートでした。

　

作れる、でも消せるか？──安全に「枯らして消す」機能削除術

作れる、でも消せるか？──安全に「枯らして消す」機能削除術 / Drain, Then Delete - Speaker Deck

AIで色々作れるようになった一方で、実際に作ってしまったものを運用しながら消していくには何をするとよいのかを学べました。

Railsに限らず、丁寧にきちんと消していくのが大事だとあらためて感じました。

また、「モノを作る時は消す時のことも考える」という旨の話もあり、AIで作りやすい時代だからこそ、これを意識していきたいと思いました。

　

Zen and the Art of File Upload Maintenance

Zen and the Art of File Upload Maintenance

Railsのファイルアップロードに関する歴史と、CarrierWave gemに関するお話でした。

壊れやすいファイルパスへの対応など具体的な話が多かったので、今後CarrierWaveを運用しているアプリに出会った時に参考にしたいです。

　

RailsはAIという責務をどう受け入れるのか — AIという新しい責務をRailsらしく設計する

RailsにAIの構造をどう乗せるかを学べました。

Active Agent gemを使うことで、Railsの構造と同じようにAIの構造も扱えるというのが興味深かったです。
https://github.com/activeagents/activeagent

　

Railsで挑む大量データ永続化 〜600億件を永続化するための設計とボトルネックとの戦い〜

Persisting Massive Data with Rails ~Designing for 60 billion rows, and fighting the bottlenecks~ Railsで挑む大量データ永続化 〜600億件を永続化するための設計とボトルネックとの戦い〜 - Speaker Deck

600億件をどのように扱うのかが気になって参加しました。

600億件をそのまま扱うのではなく、要件をもとに現実的な件数や構成に落としていくのが大事と分かりました。

　

Browser Spec: HotwireをRubyでテストする

Browser Spec: Testing Hotwire with Ruby - Speaker Deck

「HotwireをRubyでテストする」というタイトルに惹かれて参加しました。

内容は、RubyによるDOM実装を作り、さらにはRailsのテスト（Browser Spec）もできるようにしたというお話でした。

何か困った事象に出会った時、今までは既存のライブラリを探そうとしていましたが、AI時代なら自分でも作ってみてもいいのではという気持ちになりました。

　

その Valkey 使いこなしていますか？

その Valkey 使いこなしていますか？ - Speaker Deck

今のところセッションストアなどでしか使えていないので、他にValkey（Redis）では何ができるかを知りたくて参加しました。

色々なデータ型があり、ランキングなどに使いやすいデータストアであることが分かりました。

今後Valkeyが使えそうな状況を見かけたら、この資料を参考に色々試してみたくなりました。

　

How to Design Configuration for Rails Applications

How to Design Configuration for Rails Applications - Speaker Deck

Railsの設定を分かりやすくするにはどうしたらよいかを知りたくて参加しました。

設定は「まとめる」「確認しやすい形にする」という方針で、小さいアプリならconfig.x、大きいアプリなら専用クラスにすると確認しやすい、という話が参考になりました。

また、1Password CLIなどを使うことで、安全な方法で開発環境の秘匿情報を取り扱えることが紹介されており、これも必要に応じて使っていきたいです。

　

Web Framework Benchmark Battle 2026, Any%

Web Framework Benchmark Battle 2026, Any% - Speaker Deck

現在のAIができること、9/23のRails World 2026で起きたことの衝撃が伝わってきました。

PinesとSpinelでRailsが動くようになる未来が来るかもしれないという話を聞いて、気分が明るくなりました。

また、Rails 8.1の型定義がgem_rbs_collectionに追加されたのも良い話でした。例えば、Active Supportは次のプルリクエストで追加されていました。
https://github.com/ruby/gem_rbs_collection/pull/1084

　

Solid Queue: two years on Rails

Solid Queue: two years on Rails | rosa.codes

Solid Queueの作者であるRosaさんからSolid Queueの歴史や機能、今後のことなどをお聞きしました。

印象に残ったのは、AIにコードを生成させたとしても、ブラックボックスのままにせず自分で理解するのが大事という旨の内容でした。

自分のまわりでもコードを書く機会はものすごく減っているので、きちんと理解していこうとあらためて思いました。

また、Rosaさんがこのような考え方をされているのなら、Solid Queueは安心して使えそうだという気持ちにもなりました。

Kaigi on Rails 2026を締めくくる、良いセッションでした。

　

終わりに

Kaigi on Rails Teamのみなさま、ありがとうございました。

今年も色々な収穫とモチベーションをもらえました。

来年のKaigi on Railsも楽しみにしています。

Kaigi on Rails 2026、ありがとうございました。いろいろ知れたり学べたりして楽しかったです。 来年の11/26,27も楽しみです。

[image or embed]

— thinkAmi (@thinkami.bsky.social) 2026年10月17日 19:03