2025/09/26-27に JP TOWER Hall & Conferenceで開かれた「Kaigi on Rails 2025」に参加しました。
Kaigi on Rails 2025
会場入りしました
— thinkAmi (@thinkami.bsky.social) 2025年9月26日 13:26
[image or embed]
Kaigi on Rails 2025のいろいろな資料は以下のサイトにまとめられています。
Kaigi on Rails 2025 - ruby-jp
所用で参加が遅れたり途中抜けしたりしたものの、得たものが多かったです。簡単ですが、参加したときのメモを残します。
目次
- 参加したセッション
- 1日目
- 2日目
- 2重リクエスト完全攻略HANDBOOK
- 小規模から中規模開発へ、構造化ログからはじめる信頼性の担保
- Railsアプリから何を切り出す？機能分離の判断基準
- 非同期処理実行基盤、Delayed脱出〜SolidQueue完全移行への旅路。
- Railsだからできる、例外業務に禍根を残さない設定設計パターン
- ドメイン指定Cookieとサービス間共有Redisで作る認証基盤サービス
- "複雑なデータ処理 × 静的サイト" を両立させる、楽をするRails運用
- 「技術負債にならない・間違えない」権限管理の設計と実装
- rails g authenticationから学ぶRails8.0時代の認証 (後日資料を確認してメモ)
- Keynote: Building and Deploying Interactive Rails Applications with Falcon
- インフラ・会場まわり
- Kaigi Effect
- おわりに
参加したセッション
1日目
1日目は、朝どうしても外せない用事があったため、午後からの参加となりました。
後からキーノートの資料を読みましたが、直接お話を聞いたら色々得るものがありそうと思いました。
dynamic! - Speaker Deck
もし動画が後で公開されたら見てみたいと思います。
RailsのPostgreSQL 18対応
資料：RailsのPostgreSQL 18対応 - Speaker Deck
RailsのバックエンドとしてPostgreSQLを見かけることが多いため、PostgreSQL 18対応する上での注意点を知りたくて参加しました。
「PostgreSQL 18の長いキャンセルキー対応については pg gem 1.6以上を推奨」との情報が得られてよかったです。また、仮想生成列についてのPostgreSQLの状況も理解できました。
他に、Railsの文脈ではないのですが、PostgreSQLプロトコル3.2の登場も知ることができたのも良かったです。以前、PostgreSQLのプロトコルを話すクライアントを作ったことがあったため、バージョン3.2のプロトコルが気になりました。
入門 FormObject
資料：入門 FormObject / An Introduction to FormObject #kaigionrails - Speaker Deck
同僚からFormObjectのことを教えてもらって以降、「params の型が分かるので便利」的な感じで使ってたものの、きちんと入門したほうが良さそうとなって参加しました。
FormObjectの特徴や使いどころがまとまっていて、チームで認識合わせするときの参考資料として良さそうと感じました。
一方で、OpenAPIスキーマがない状況だと、Controllerの実装をする上で params の型を知りたいことが個人的によくあるので、基本的にFormObjectは使いたいと感じたりもしました。
もう並列実行は怖くない コネクション枯渇解消のための実践的アプローチ
資料：もう並列実行は怖くない ~コネクション枯渇解消のための実践的アプローチ~ - Speaker Deck
コネクション枯渇の例が解説されていて分かりやすい内容でした。
発表ではどこの値がどのように影響するかも解説されていました。そのため、もし今後並行実行を増やしていくときは、この資料を見つつ、適切な値を計算していこうと思いました。
Web Componentsで実現する Hotwire とフロントエンドフレームワークの橋渡し
資料：Web Components で実現する Hotwire とフロントエンドフレームワークの橋渡し / Bridging with Web Components - Speaker Deck
フロントエンドに疎く Web Components を知りたかったため、参加しました。
発表では Web Component の概要から実際の利用する上での注意点もふれられていました。特に、どこをJavaScriptで実装し、どこをRailsで実装するのが良いのかの解説があり、分かりやすく感じました。
最近、ちょっとしたものをStimulusで実現したため、今後機能を追加して橋渡しが必要になったときはこの資料を参考にしようと思いました。
5年間のFintech × Rails実践に学ぶ - 基本に忠実な運用で築く高信頼性システム
資料：5年間のFintech × Rails実践に学ぶ - 基本に忠実な運用で築く高信頼性システム / 5 Years Fintech Rails Retrospective - Speaker Deck
仕事では開発〜運用まで取り組んでいるので、何か良いヒントを得られそうと考えて参加しました。
開発時点から運用を見据えて、品質特性から開発上の工夫として
- アーキテクチャ設計
- 金融事故対策
- テスト設計
- ドキュメンテーション
- モジュール化
- イベントソーシング
などに取り組まれているとのことでした。
また、運用についても
- 障害対応フロー整備
- 異常検知の仕組み
- アラートトリアージ
- パフォーマンスモニタリング
- バッチ管理
- Runbook
などの紹介がありました。
身近ではすでに環境構築済のものもあるため、この資料をベースに環境の把握・理解を深めていこうと思いました。
他の資料へのリンクもあったため、それも含めて確認していきたいです。
2分台で1500examples完走！爆速CIを支える環境構築術
資料：2分台で1500examples完走！爆速CIを支える環境構築術 - Kaigi on Rails 2025 - Speaker Deck
CI速度の改善方法が気になったため参加しました。
爆速CIに至るまでの試行錯誤の内容が参考になりました。
ちなみに、この資料を見た同僚がさっそく試していました。
Railsによる人工的「設計」入門
資料：kaigi_on_rails_2025_設計.pdf - Speaker Deck
Railsでは初学者という立場はたぶん脱出できていると思うのですが、他の分野では初学者になります。そのため、有識者から学んだり作業を進めていく時は、この資料の考え方で有識者とすり合わせしていこうと感じました。
それに加え、AIと協業していく際に「ゴールから逆算して考えさせる」という指示の出し方にも応用できそうだと感じました。この資料を元に、色々試行錯誤していこうと思います。
また、最後の方にはRailsのデザインパーツが色々と紹介されていたのもありがたかったです。
今改めてServiceクラスについて考える 〜あるRails開発者の10年〜
資料：今改めてServiceクラスについて考える 〜あるRails開発者の10年〜 - Speaker Deck
Serviceクラスについて、分かったような分からないような状態だったので参加しました。
RailsにおけるServiceクラスの変遷やそのまわりの状況が理解できました。
身近では、幸いなことに先人たちが議論・認識合わせをしてくれたおかげでServiceクラス的なものは存在していないことから、今後も、資料p42の
- 重要なのは、開発者にとって想像が付くこと、驚きが少ない開発。読めるコード、そして読める構造へ
- ServiceクラスやFormクラスはコード上の表現技法の一つに過ぎない。コンテキストマッピングをしっかり考えて、継続的に改善をし続けること
あたりを頭において、チームで認識合わせをして、都度使う/使わないを判断していこうと感じました。
あと、Serviceクラスとは直接関係ないのですが、RDBの基本のところで「RDBではステータス更新はいいやり方ではない」旨の解説がありました。
運用していると「状態変化を UPDATE + updated_at で実現すると、事実が消えてしまってつらい」ということがあったので、とても納得感ありました。
2日目
2日目はお昼前を除き、各セッションに参加できました。
2重リクエスト完全攻略HANDBOOK
資料：2重リクエスト完全攻略HANDBOOK / Double Request Handbook - Speaker Deck
時々2重リクエストのことを考える時に引っかかることがあるため、気になって参加しました。
2重リクエストについて資料をまとめたかったという登壇者の発表にあった通り、色々なパターンがまとまっていました。
特に、
あたりの考え方がためになりました。
今後、2重リクエストを考えることがあったら、都度この資料を見直していきたいと思いました。
小規模から中規模開発へ、構造化ログからはじめる信頼性の担保
資料：小規模から中規模へ 構造化ログからはじめる信頼性の担保 - Speaker Deck
運用をしているとログを見る機会があるため、構造化ログの考え方について知りたく参加しました。
構造化ログの考え方に加え、
という情報も得られ、ありがたかったです。
Railsアプリから何を切り出す？機能分離の判断基準
資料：Railsアプリから何を切り出す？機能分離の判断基準 Kaigi on Rails 2025 - Speaker Deck
自分が機能分離の判断をすることになった時に備えて参加しました。
機能分離の判断軸として5つが紹介され、各実例が紹介されました。
また、「チームで重みを話し合って分離するかどうかを決める」旨の話もあり、ここでもチームでの認識合わせの重要性を感じました。
非同期処理実行基盤、Delayed脱出〜SolidQueue完全移行への旅路。
資料：非同期処理実行基盤 Delayed脱出 → Solid Queue完全移行への旅路。 - Speaker Deck
非同期実行基盤はあるものの Solid Queueは使われていないため、どんなものか知りたくて参加しました。
現在の課題を元に、設計・実装していくストーリーが分かりやすかったです。
また、 Solid Queueの内部実装もや移行方法の解説もあり、もし導入していくときには参考にしたいと感じました。トランザクション内部のジョブ問題とか、実際に引っかかりそうなためです。
Railsだからできる、例外業務に禍根を残さない設定設計パターン
資料：Railsだからできる 例外業務に禍根を残さない 設定設計パターン - Speaker Deck
身近では「基本は標準業務とし、例外業務が出そうでも標準業務に寄せられるようにする」という大方針に従い進められているのでありがたいのですが、もし例外業務が出てきた時にどうすればよいか知りたくて参加しました。
手元のメモにある「良さそう」と感じたポイントとしては以下でした。
- 例外業務は設定化し、テーブルに保存する
- 設定値がDB上のマジックナンバーになるので、文字列を使う
1ではなくacceptedにするなど- ちなみに、自分の身近でも文字列化する事例があった
- 最初は違和感があったものの、運用する中で「文字列になっていてとても便利...!」と感じることがよくあったので、最近の自分は文字列派になった
- 設定したときの履歴は残すようにする
- 値をUPDATEせず、時系列化できるようにする
- あとで誰が何をいつ行ったかの履歴を追えるようにするため
- 値をUPDATEせず、時系列化できるようにする
- 学び方
- OSSのER図を出力し、設定テーブル設計を確認する
一方、設定をテーブルに保存する場合、SQLアンチパターンのEAVパターンにならないように気をつけないといけないなとも感じました。
ドメイン指定Cookieとサービス間共有Redisで作る認証基盤サービス
資料：ドメイン指定Cookieとサービス間共有Redisで作る認証基盤サービス
以前、Rails + doorkeeper でOIDCの習作をしてたこともあり、認証基盤まわりが気になったため参加しました。
個人的には、可能な限り標準に乗りたいということでOpenID Connectを選択したくなる派なのですが、色々考えて認証基盤を作り切っているのがすごいと感じました。
また、Rodauth gemの感想も参考になりました。
"複雑なデータ処理 × 静的サイト" を両立させる、楽をするRails運用
自分も個人で静的サイトを持っているため、どんなふうにRailsが使えるのか気になり参加しました。
Railsの各パーツの得意なところを活かしている構成になっていて、こういう方向も良さそうと参考になりました。
「技術負債にならない・間違えない」権限管理の設計と実装
資料：「技術負債にならない・間違えない」 権限管理の設計と実装 - Speaker Deck
最近、権限管理まわりで習作をしていたこともあり、権限管理というタイトルに惹かれて参加しました。
「役割でなく、権限に依存する」方針のもと、「権限管理を、対象・操作。役割・条件」に分けて実装したものを順を追って説明があったことで、権限まわりの読みやすさを実感できました。
また、RailsだけでなくNext.jsの例もあることで、RailsをAPIとして使っている環境でも使えそうなのが良かったです。
そのため、今後、権限まわりで何かの担当になった場合は、この資料を踏まえて認識合わせをしていきたいと感じました。
一方、「役割と条件が固定」という状況ではとても良さそうと思った一方で、「ユーザーが自由に役割を作り、その役割に対して自由に条件(権限)を割り当てる」という状況ではどのようにするんだろうと感じました。
そこで、トーク後に質問をしてみたところ、特に良いgemはなく、データベースを使いながら色々と考える必要があるとのことでした。
最後のキーノート間際まで快く質問に答えていただき、ありがとうございました。
rails g authenticationから学ぶRails8.0時代の認証 (後日資料を確認してメモ)
資料：rails g authenticationから学ぶRails8.0時代の認証 - Speaker Deck
当日は権限の方に参加していたものの、後日資料を見てメモしたいことがあったため、ここに記載します。
スライドを読んでいると、「認証ジェネレータから生成されるコードから学ぶ」ということで、認証まわりで知っておくべきことがいくつも紹介されていました。
特に、Railsのバージョンアップに伴う
- rate_limit
- キー拡張と呼ばれる処理を行う回数 (cost) について
- authenticate_by
- normalizes
- has_secure_password
- password_reset_token
のあたりは、色々学びがありました。
Keynote: Building and Deploying Interactive Rails Applications with Falcon
Falconがどこまで使えるかを示してくださったキーノートでした。
また、Falconがどこでも使えるように、いろいろなところにコントリビュートしているのがすごいと思いました。
インフラ・会場まわり
- 東京駅からとても近い会場だったので、とても便利でした
- 会場提供のWiFiの「QRコードを読み取るだけでそのWiFiに接続できる」がとても良い体験でした
- Kaigi on Rails 2025用のスマホ向けアプリも提供されていて、自分が参加するセッションを把握するのにとても役立ちました
- 各ルームの脇にはリアルタイムで文字起こししている大きな画面も用意されていて、うっかり聞き逃してしまったときはその画面を見ればリカバリできる感じでした
- わいわいルームには本屋さんがあったり、美味しいおやつをいただいたりと、こちらもありがたかったです
Kaigi Effect
Railsまわりの話を聞いているうちに、自分もRailsまわりで何かしたくなりました。
そこで、メンテナンスを後回しにしていた、JetBrains IDEプラグインRailroadsのissue対応に着手しました。
意外と修正範囲が広くなってしまったものの、今後のメンテナンスコストを下げた形で改修ができました。その結果、JetBrains IDEのバージョン 2025.2系でも動くようになりました。
修正で得た知見は別記事として書こうと思います。
おわりに
Kaigi on Rails 2025 Teamのみなさま、ありがとうございました。
色々と収穫があり、これからのRails開発に活かしていけそうです。
来年のKaigi on Railsは渋谷ということで、楽しみにしています。
— thinkAmi (@thinkami.bsky.social) 2025年9月27日 18:20
