初めに

この記事はKaigi on Rails 2025 day1の感想と自分が思うキーワードのまとめです。
半ば勢いで書いていますので、参加していない方は「こいつは何を言っているんだ？」となる可能性があります。
詳しい内容や過去を遡って確認したい方は向いていない可能性があります。

よって、対象は以下を想定しています。

Kaigi on Rails 2025 に参加していて、他の人の感想が気になる方
day1の興奮が冷めやらず、夜ふかしをしている方

セッションごとのキーワードと感想

補足

キーワード → セッション直後に残した単語
感想 → ある程度まとめた自分自身の言葉

Keynote: dynamic!

発表資料URL

https://speakerdeck.com/moro/dynamic

キーワード

MVPより小さい、「ハッピーパス」
動くソフトウェアで検証
FBをもらって直す

感想

普段SGで仕事するうえで聞いたり考えたりすることと似ているなと思いました。
違う言葉で同じことを聞くと、今まで聞いたことがつながる感覚があっていい出だしだなと感じました。
利用者の気持ちで試せる最小の実装がハッピーパスというみたいです。親方からは「バームクーヘンを巻くように実装する」と聞いたのがこれに当たるなと思いました。
MVPを目指して最初から大きいものを作るのではなく、最もシンプルに試せるものから作る。考えてみようと思いました。

高度なUI/UXこそHotwireで作ろう

発表資料URL

https://speakerdeck.com/naofumi/uxkosohotwiredezuo-rou-kaigi-on-rails-2025

キーワード

HotwireとReactの違い
HotwireでもリッチなUIは作れる
Stimulus同士の通信に「Zustand」というのがある
Stimulusの値変更コールバック

感想

複雑っぽいけど簡単に作れるUIのところで、ブラウザのデフォルトとかVanilla JSでもできると聞いて、すごい進化してるんだなと思いました。
あまりReactを触っていないのですが、Hotwireでも同じくらいのことができるとわかりました。
早速使ってみたいと思った。特に、値変更コールバックとグローバルステート管理。
あまり見れてなかったので、HotwireとStimulusのドキュメントを読み直したいです。

そのpreloadは必要？──見過ごされたpreloadが技術的負債として爆発した日

発表資料URL

(発見次第追記)

キーワード

不要なpreload
アラートの不足
常にトレードオフ(N+1 ↔ メモリ消費)

感想

とりあえずN+1を消すためにpreloadしておくか、みたいな考え方をしていると将来痛い目を見るんだなとわかりました。
それをやるとどうなるか、やらないとどうなるか。ツヨツヨエンジニアなら当たり前のことですが、自分もできていないといけない。指摘されて直すだけじゃ駄目だなと考えるセッションでした。

もう並列実行は怖くないコネクション枯渇とデッドロック解決の実践的アプローチ

発表資料URL

(発見次第追記)

キーワード

並列処理をするとDBとのコネクションが不足する
デプロイ時、タイミングが悪いとコネクションがデプロイ前と後で同時につながり、想定の2倍のコネクションが必要

感想

Railsアップデートのときなどに見た「RAILS_MAX_THREADS」ってここで使ってるんだーって思いました。
並列実行をしないとこういう考慮はしないので、自分が本番作業をする前に追体験のような形で知ることができて良かったです。

Web Componentsで実現する Hotwire とフロントエンドフレームワークの橋渡し

発表資料URL

(発見次第追記)

キーワード

カスタムエレメントを定義して使いまわし
Railsで使えるようにフォームビルダーを上書き

感想

カスタムエレメントを使いまわす方針自体はとても良さそうですが、フォームビルダーを上書きしたり別で作成する必要があるのでメンテナンスは大変そうだなと率直に思いました。
すでに基盤があるなら乗り換えが楽ですが、新規開発なら無理にやらなくても他の方法で十分できそうだなと感じました。

あなたのWebサービスはAIに自動テストしてもらえる？アクセシビリティツリーで読み解く、AIの『視点』

発表資料URL

(発見次第追記)

キーワード

自然言語でテスト作成
アクセシビリティを見てAIが解釈
最終的には、自然言語でテストを書く → それを元にテストコードを作成

感想

最初は「すごい時代がきた」と同時に「さすがにこれでテスト書かなくね？」と思いました。
ただ、最終的に自然言語でテストを作って、それをテストコードにすると考えるとかなりやりやすい。ぜひそういう未来がきてほしいなと思いました。

Kamalって便利？社内プロジェクト3つをKamal + AWSで運用した体験談

発表資料URL

(発見次第追記)

感想

我らがyappuさん。デプロイ時にはお世話になりました。自動デプロイができるまでのハードルを聞けて良かったです。

Railsによる人工的「設計」入門

発表資料URL

https://speakerdeck.com/nay3/kaigi-on-rails-2025-she-ji

キーワード

ベテランと初学者の設計の差(そもそも設計できていない)
なってほしい状態から逆算して考えて一本通す
逆算すると手順を考えられて、この時点でレビューをもらえるだろう
命名とはこの領域は何か、本質は何か
本質を考えると、開発する順番も見えてくる

感想

Kaigi on Rails 2025に参加してよかった。このセッションを聞くことが参加した目的だったんだと思いました(大げさ)。
実務を2年近くやってきて、「なんか設計うまくできたな」と思ったときがどういうときなのか理解できました。
完成した機能から逆算するというのはうまい言語化だなと感じました。このメソッドが有効かどうかは僕が検証します。有効ならもっと広めたいです。

今改めてServiceクラスについて考える〜あるRails開発者の10年〜

発表資料URL

(発見次第追記)

キーワード

サービスクラスもフォームクラスも本質は変わらない
modelやテーブル、カラムなどの命名から逃げてはいけない
チームで開発するときに、驚きが少ない状態に

感想

命名が重要ということ、ServiceクラスもFormオブジェクトも本質は変わらず、命名から逃げてはいけないことは理解しました。
ただ、話が難しかったなと感じました。しばらく経って読み返すとまた違う理解ができるのかもしれません。

終わりに

発表資料が出ていない、見つかっていないセッションがあるのであとで追記します。
まだ1日目ですが、参加して良かったなと思いました。明日も楽しみです。

追記) 当日のxへのポストをまとめています。もはや見ても伝わるとは思いませんが、ライブ感は味わえるかも？ → https://posfie.com/@umikun_summer/p/tGBjX4f