みなさん、こんにちは。 はたらく未来図構想統括部 JobQ部でエンジニアをしている川村と田中です。 私たちは現在、キャリアや転職に特化した相談サービス「JobQ Town」の開発を担当しています。 キャリアに関する不安や悩みの解消と支援を目的としたサービスで、バックエンドにはRuby on Railsを採用しています。
2025年9月26日・27日に開催されたKaigi on Rails 2025に参加してきました。
今回は、JobQ部のエンジニア2名が、オフラインとオンラインそれぞれの形で参加しました。 本記事では、当日のイベントの様子やセッションで得られた学びを共有していきます。
過去Kaigi on Railsに参加した記事はこちらです。
Ruby on Rails（以下、Rails）はプログラミング言語RubyをベースにしたWebアプリケーションフレームワークです。
「Kaigi on Rails」は「初学者から上級者までが楽しめるWeb系の技術カンファレンス」というコンセプトのもと、2020年に始動し、今年で第6回を迎えました。
今年の会場は東京にある「JPタワー ホール & カンファレンス」で、オンライン配信とのハイブリッド開催となっています。
2本の基調講演、34本の一般セッションでは、国内外のエンジニアがRailsの最新知見や現場での工夫を共有し、実践的な学びが得られる内容が盛りだくさんでした。
発表は後日アーカイブ配信される予定です。興味のある方はぜひご覧ください。
Keynote: dynamic!
オープニングキーノートでは「dynamic!」をテーマに、RubyやRails、そしてプロダクト開発における dynamic（動的であること） の価値について語られていました。
「Railsアプリの dynamic! 」として紹介されていた「ハッピーパス」は、利用者が期待する最もシンプルな操作、つまり正常系のユースケースをまず作るという考え方です。
自プロダクトで言えば「質問する」ボタンを押すと「質問を投稿しました」と表示される。この一連の流れがハッピーパスです。それ以外の要素（画面のリッチ化、他カラムの同時更新、通知メール送信など）は一旦保留にし、作りすぎず、次のハッピーパスへ動的に進めていくという考え方が印象的でした。
自分は拡張性を意識しすぎて大きく考えがちなので、「小さく作る（＝プルリクを小さくする）」を改めて意識したいと感じました。
また、「プロダクト開発の dynamic!」として語られていたのは、企画者と開発者がドキュメントではなく動くソフトウェアで会話する、という考え方です。
ハッピーパスで作った機能を検証環境にデプロイして実際に動くものを通じて議論することで、企画・デザイン・QAそれぞれの職能が発揮され、より多くの発見が得られます。
AIでデモを素早く作れる今だからこそ、こうしたdynamicな開発スタイルをより積極的に取り入れていきたいと感じました。
5年間のFintech × Rails実践に学ぶ – 基本に忠実な運用で築く高信頼性システム
Fintech領域での品質・高信頼性をどのように築いてきたかをテーマにした非常に実践的なスピーチでした。
エラートラッキングや障害対応フローなど日々のプロダクト運用荷直結する内容が整理されており、運用体制づくりの重要性を改めて実感しました。
印象的だったのは、バッチ処理ごとにドキュメントを整備しているという点です。
アラートを受け取ったエンジニアが、実装の詳細を知らなくてもリトライ判断ができるようにしておくことで、対応が属人化せず、運用負担を軽減しているとのことでした。
実際、自分自身も「今リトライしていいのか？」と迷う場面があったので、この仕組みには非常に共感しました。
自チームでは GitHub Copilot を導入しており、このセッションをきっかけに、早速プロダクトで使用しているバッチ処理のドキュメントをAIに生成させ、チームメンバーに共有しました。
コードベースから直接生成することでスピーディかつ精度の高い内容が得られ、運用ドキュメントの整備にはAI活用が有効だと発見になりました。
あなたのWebサービスはAIに自動テストしてもらえる？
発表のポイント
- AIによる自動テスト生成の核心は「UIの理解」
ブラウザ上で描画された要素をAIが解釈し、
「このボタンを押すと何が起きるか」を人間と同じように“読む”という試み。
SeleniumのようなDOM操作ベースではなく、AXツリー（アクセシビリティツリー）を介してUI構造を把握する。 - “AIが理解できるUIは、人にも優しいUI”
アクセシビリティ（a11y）対応をサボると、AIも画面を正しく理解できない。
結果的に、AIテスト＝a11yテストになるというパラダイム転換。 - Railsでの実践例
Turbo/Stimulus構成で画面遷移を明示化
aria-*属性やrole指定をきちんと入れることで、AI側の理解精度が上がる
スナップショットテストやビジュアルリグレッションの代替としてAIを使う未来も見えてきた
印象と考察
「AIでE2Eテストを自動化」は夢物語ではなくなっている。
RailsがアクセシビリティとUXを両立できる土壌を整えてきた今、
“AIに読まれるUI”を意識した設計が新しい品質基準になりそう。
rails g authenticationから学ぶRails 8.0時代の認証
発表のポイント
- Rails標準の認証ジェネレータ誕生
rails g authentication が示すのは「Deviseを卒業するための教材」。
生成コードを読めば、has_secure_password の中身から学べるように設計されている。 - 特徴的な仕組み
authenticate_by でタイミング攻撃を緩和
normalizes でメールなどの入力揺れ吸収
rate_limit でログイン試行をレート制限
ActiveSupport::CurrentAttributes により現在のユーザー状態をスレッド安全に管理
generates_token_for でパスワードリセットを安全に - 注意点
生成されたコードはgemのように自動更新されないため、メンテナンス責任は開発者に残る
あくまで「学びと雛形」であり、複雑要件は引き続きDeviseやRodauthが担当
印象と考察
Rails 8 の思想は「フレームワークを学びながら使う」へ。
コードを自分たちの手で読む文化を後押しするアップデート。
学習・理解・拡張すべてが循環する“Railsらしい進化”を感じた。
川村（オフライン参加）
部を代表してのオフライン参加だったので、プロダクトへの還元を意識して臨みました。
この2年間で継続的にプロダクトのコードに触れてきた経験から、「この内容は具体的にここに活かせそうだ」という具体的な改善のイメージを持ちながらセッションを聞けたのが大きな収穫でした。
また、今回の発表では過去のKaigi on Railsでの内容が引用される場面が多く、積み重ねの中でRailsコミュニティが成熟していることを感じました。
最新トピックだけでなく、長年の運用から得られた知見も多く共有されており、Railsが今も進化し続ける強い技術基盤であることを改めて実感しました。
Kaigi on RailsのYouTubeアーカイブをチームメンバーと視聴し、感想や導入アイデアを共有するような取り組みも面白そうだと感じています。知見の輪を広げる良いきっかけになりそうです。
今年は横に広いメインステージ
オフィシャルで貰ったノベルティ
キーホルダーがかわいかったのでセキュリティキーにつけました
田中（オンライン参加）
初参加でしたが、どのセッションもRailsの原点を掘り下げる実践的な内容ばかりで、とても刺激的な2日間でした。
派手な新機能の紹介よりも、既存の仕組みをどう磨いて開発体験を上げていくかという現場感のある話が多く、日々の開発にすぐ活かせる学びが多かったです。
特に印象に残ったのは、HotwireやFormObjectといった昔からあるRailsの仕組みを、再評価し、どのように再活用するかというテーマでした。
全体を通して「まず動かす」「速く回す」「境界を明確にする」という姿勢が一貫しており、改めてRailsらしさ＝実装の軽さとスピード感を感じました。
オンライン参加ならではのメリットもあり、
– 社内のコードを見ながら聞ける
– 巻き戻して再確認できる
– 英語セッションもリアルタイム翻訳で理解できる
といった点で非常に学びやすい環境でした。
一方で、通信トラブルなどで一部のセッションを聞き逃す場面もあり、現地の熱量には少し届かない部分も感じました。
それでも、リアルタイムでSNS上の反応を追いながら盛り上がれるのはオンラインならではの良さでした。
どのスピーチも現場での実践に根ざした内容で、今後の開発や運用の方針を考えるうえで非常に有意義な時間となりました。
登壇者の皆さま、そして運営スタッフの皆さまに心より感謝いたします。
また、このような貴重な機会を与えてくださったマネジャーをはじめ、日々支えてくれているチームメンバーの皆さんにも深く感謝しています。
今回得た学びを、プロダクトの改善やチームの成長にしっかり還元していきたいと思います。
田中 涼晴 Ryosei Tanaka
カスタマーP&M本部 はたらく未来図構想統括 JobQ部 エンジニアリンググループ エンジニア
JobQの開発をしているWebエンジニア。子供と猫２匹に囲まれて暮らしています。
※2025年11月現在の情報です。
