はじめに

みなさん、こんにちは。はたらく未来図構想統括部 JobQ部でエンジニアをしている川村と田中です。私たちは現在、キャリアや転職に特化した相談サービス「JobQ Town」の開発を担当しています。キャリアに関する不安や悩みの解消と支援を目的としたサービスで、バックエンドにはRuby on Railsを採用しています。

2025年9月26日・27日に開催されたKaigi on Rails 2025に参加してきました。今回は、JobQ部のエンジニア2名が、オフラインとオンラインそれぞれの形で参加しました。本記事では、当日のイベントの様子やセッションで得られた学びを共有していきます。

過去Kaigi on Railsに参加した記事はこちらです。

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アーカイブをチームメンバーと視聴し、感想や導入アイデアを共有するような取り組みも面白そうだと感じています。知見の輪を広げる良いきっかけになりそうです。