Kaigi on Rails 2025 参加レポート💎

はじめに

はじめまして。zaico フロントエンドエンジニアの@sakiadachi といいます。
今回は @nobu09さんに声をかけていただいたことをきっかけに、初めて Kaigi on Rails に参加しました。カンファレンスでは Rails に特化した専門的な話題もありますが、チームでの開発論や、フロントエンド開発など、 Rails をベースにした多様な講演があることから、参加することにしました。
Rails の初学者かつ、JavaScript でフロントエンドを開発していた自分にとって、Rails コミュニティでのフロントエンド開発への取り組みや考え方などにとても興味がありました。

はじめまして。zaico Webエンジニアの @nobu09 です。普段は Rails を使って開発しています。
Kaigi on Rails には2023年、2024年に現地参加し、今年2025年からは運営として関わりました。
昨年は会社から1人で参加していましたが、今年は @sakiadachiさんも一緒に参加してくれて仲間が増え、とてもうれしかったです。

この記事では、私たち2人が Kaigi on Rails 2025 で印象に残ったセッションやイベントの感想をそれぞれレポートしていきます。

@sakiadachiの印象に残ったセッション

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

自然言語からブラウザーを自動操作をするcapybaraドライバのOSS開発を行っているYusuke Iwakiさんの発表でした。
発表では、BrowserUseや Playwright MCPが、自然言語による命令をどのように理解し、Webサービスを自動操作しているのかを、ソースコードや内部プロンプトの調査を元に紹介されていました。

これらのツールは、ブラウザのAccessibility Treeを利用し、クリック可能な要素や文字入力が可能な要素(ボタンやinput)を特定しているとのことです。
たとえば「検索する」という指示であれば、“search” など関連性の高い単語を含む要素を探して操作する仕組みになっており、「かなり泥臭い処理をしているんだな…」と感じました。

発表を通じて、生成AIツールがどのように自然言語をもとに要素を特定しているのか、その具体的な仕組みを知ることができ、とても勉強になりました。
特に印象的だったのは、「AIの把握しやすさ ≒ アクセシビリティツリーが明快であること」という点。
つまり、AIが理解しやすい構造で作られたサイトは、結果的にアクセシビリティも高いということです。

将来的には、自然言語から自動テストまでを完全に自動化する世界もそう遠くないかもしれません。さらに、実装をAIに支援してもらう場合でも、アクセシビリティやコードの可読性は大いに関係してくると感じました。
以下に、アクセシビリティの良いアプリケーションを作るために気をつけることをまとめました。

• セマンティックな実装を心がけること
• UIの独自実装を避けること
  • 一般的によく使用されているライブラリを使用する
  • どうしても独自実装が必要な場合は、アクセシビリティツリーでの要素取得が容易かどうかを実装時に考慮する
• ツールチップは、操作上なくても問題がない補足程度の内容が良さそう
  • ホバー時にエレメントが生成される場合アクセシビリティツリーから取得できないため

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

今回の講演が、Hotwireを初めて知るきっかけになりました。RailsとHotwireを組み合わせて開発することで、モダンフロントエンドフレームワークを使用する場合と遜色ない、良い開発体験（DX）が得られることを知ることができました。

zaico では Ruby on Rails + Vue.js を使った MPA（Multi Page Application） で開発しており、個人的にはSPAで開発していた時に比べて、開発体験が非常に良いと感じています。そのため「SPA を使う理由はなんだろう？」という疑問やモヤモヤは以前から抱いていました。今回の発表では、モダンJavaScriptフレームワーク（Next.js）と Hotwire の比較検証で、パフォーマンスや UI/UXの優位性についても学ぶことができ、とても勉強になりました。

Hotwireを使用しているサービスの例として挙げられていたBasecampに登録して、実際に使用感を試しました。タブホバーでprefetchするなどのフレームワークに組み込まれた仕様や、UI/UXの良さをキープしつつ独自性のあるデザインが特徴で、今後実装のお手本にしていきたい、作り込まれた良いWebアプリケーションだなと思いました。

後に記述するMarcoさんの発表では、erbでのDX向上を目的とした開発において、モダンフロントエンドのデバッグ体験の良さが挙げられていました。Hotwireでも同様の利点があるのか気になり、こちらも個人開発で試してみたいと思っています。

Introducing ReActionView: A New ActionView-Compatible ERB Engine / Marco Roth

既存のRailsの開発体験(Developer Experience)をより良くし、モダンフロントエンドフレームワークの良さをRails開発に紹介するライブラリHerbの開発についての発表でした。

ちょうど私自身も、最近erbで作られていた画面をVue.jsコンポーネントにリプレイスする作業を行っていたため、とても共感する内容でした。
特にerbは、エラーの原因を特定しづらいメッセージや、デバッガーツールの乏しさなどから、デバッグに時間がかかる印象がありました。

Herbの発表では、その課題を解決するための エラーメッセージ改善が紹介されており、長くて読みにくかったerbのエラーメッセージが、Herbではほぼ1行でエラー位置を明示する形式に改善されていました。実際のデモではそのわかりやすさに会場から拍手が起こるほどで、開発者目線の工夫がとても印象的でした。

さらに、Tailwind CSSクラスのフォーマッター導入（実装予定）など、「あると開発体験が上がる！」という痒いところに手が届く機能が多数開発されており、まさに“すぐ使いたい！”と思える内容でした。

@nobu09 の印象に残ったセッション

Keynote: dynamic! / MOROHASHI Kyosuke

Kaigi on Rails 2025 幕開けの Keynote でした。
「変化する状況の中で価値を生み出すために、ソフトウェアも少しずつ継続的に良い方向へ変わり続けていく」というお話で、「動的に開発することの楽しさと価値」を3つの視点から語ってくださいました。

1. Rubyで動的に開発する

Rubyの irb や rails console などで Ruby と対話し、動かしながら自分がほしいプログラムに近づく、動的な開発はたのしい！というお話でした。わかる。

2. Railsアプリケーションを動的に開発する

「ハッピーパス」という言葉が出てきました。これは、ふつうの利用者が期待する最もシンプルな操作ができるところまで実装できている状態、MVPより小さいものを指していました。
ハッピーパスを見つけるには「最もシンプルで、うまくいきそうなもの」に集中し、集中するもの以外は保留します。
ハッピーパスだけでは利用者向けの本番リリースは無理ですが、本番リリースをしなくても、フィーチャフラグでの隠蔽、ステージング環境や検証環境で確認、ローカルのrails sでの画面共有など、いろんな方法でフィードバックを得ることができます。
そしてハッピーパスを動かすことで、次にどんな方向へ進めばいいかの選択肢が見えてきます。
「Railsアプリケーションを動的に開発する」とは、その時点でわかっていることを小さく丁寧にできるだけ標準の道具で作る、わかることが増えたらそれをコードに反映していく、それはたのしい、というお話でした。

3. チームでプロダクトを動的に開発する

最後は、動的な開発の良さを、チームでのプロダクト開発にスケールさせたい、というお話です。
企画者と開発者のコミュニケーションは、ドキュメントでの意思疎通はむずかしく、動くソフトウェアで会話することで、それぞれの脳内の理想と現実の差異がわかり、それぞれの職能の方がより多くの発見ができ、判断や見直しなどもできるようになるという話がありました。
ソフトウェアは、dynamicな「関わる人たち皆の、現在の理解の表現である」という話が印象的でした。

最後に、Kaigi on Rails で、自分自身を動的に変えていきましょう、変わることを楽しんで！というメッセージがあり、そこからのカンファレンスの開幕にわくわくしました。
セッションを聞いて、「最もシンプルで、うまくいくことはなんですか？」という問いが強く胸に残りました。この問いをかみしめながら dynamic な開発をたのしんでいきたいと思いました。

今改めてServiceクラスについて考える 〜あるRails開発者の10年〜 / Tomohiro Hashidate(joker1007)

今から11年前、2014年に出版された『パーフェクト Ruby on Rails』第1版で、joker1007 さんは「サービスクラス」の章を執筆されました。
今回のセッションでは、そのサービスクラスについて、当時から現在に至るまでの考え方の変化についてお話されました。とても楽しみにしていたセッションでした。

現在の joker1007 さんの立場は、「実務ではできる限りサービスクラスを使わない方が良い」というもの。その理由として、開発統制の難しさを上回るほどのメリットが得にくいことを挙げられていました。
11年前当時は、Rails がビジネス領域で広く使われるようになり、モデルクラスが肥大化する “Fat Model” の問題が顕在化したことを背景に、当時はサービスクラスがその解決策として注目されていました。ですが、2014年の『パーフェクト Ruby on Rails』でも、「適切な名前付けができないなら、サービスクラスは使わない方がいい」といった内容を書かれていたそうです。

しかし、ビジネスドメインの語彙理解がばらばらであることにより、サービスクラスの使い方や判断基準が人によってばらついてしまい、その結果、チームメンバーがコードを読んで「ちゃんと想像できる」状態を保つことが難しい、という問題があることが分かったそうです。
Service や Form といったクラスよりも、まず RDB と向き合い、ドメインコンテキストを理解し、それをコードの中で自然に表現すること が重要だとお話されていました。
また、同じ語彙で話せる業務領域を分けていく現実的な選択肢としてモジュラーモノリスを挙げ、コンポーネントの境界が明確になった時に、その境界を跨ぐ公開エンドポイントとして Service クラスを利用するのは意味があると説明されていました。

セッションの最後では、チームで継続的に開発していくことの難しさに触れ、Service や Form を使う場合は、なぜ使うのか・どんなときに使うのかをチームで言語化して共有することが大切であり、重要なのは、想像がつき、驚きが少なく、読める構造にしていくことと語られ、ソフトウェア設計は正解があるものではなく、判断を続けていく営みだという言葉が印象的でした。

このセッションは Kaigi on Rails 1日目の最後に行われましたが、内容も流れもすばらしかったです。
弊社でも最近、中心となるモデルクラスの Fat Model への課題感から Service クラス導入の話が進んでいるのですが「使いどころをチームで言語化して共有する」という観点が十分にできていないことに気づかされました。
また、弊社で最近導入されたモジュラーモノリス構成の中で、まさにコンポーネントの境界エンドポイントとして Service クラスが使われていたのを見て、joker1007 さんの言っていたのはこのような使い方のことなのか、と納得しました。

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

個人的に、この生成AI台頭の流れの中で設計は重要になってきていると考えており、このセッションも必ず聞きたいと思っていました。

「設計をどう教えるか」というテーマで、Ohba さんが試行錯誤を通して見つけた、うまくいった教え方を紹介してくださいました。
設計を体得した人は、設計ができない人の思考を想像しづらく、どう教えるかが難しい問題があります。
初学者はコードのレベルだけでシステムのことを考えがちですが、ベテランは抽象度の高いレベルでシステムのことを考えて（＝設計）から、その後にコードのレベルで考えて実装します。
設計は脳内実装から抽出することでもコードから考えることでもなく、コードとは別のレベルで全体を考える活動（抽象的概念の獲得）であるというお話がありました。

「何をすると設計したことになるのか、実装しないでどう考えるのか」の壁を長年越えられなかったが、強制的に設計に導ける方法として「逆算」という方法を見つけたとお話されていました。
まず、完成したシステムを思い浮かべ、そこから逆算して必要な構造や処理の流れを考えていきます。ゴールを明確にすることで、本質的な要素を優先して考えられるようになります。
このとき、コードの詳細は考えず、枠組みや輪郭、データのつながりなど全体の構造を俯瞰して捉え、
設計を逆算で進めると、どの部分が中心で、どの部分が補助的かが自然と見えてきます。
また、設計段階で決めた内容はすべて「仮置き」とし、後から選び直せるようにしておくことが重要だと話されていました。「全ての決定は仮置きだ」という言葉が印象的でした。

「設計する」ということはどんなことかを初学者にもわかるように紐解いて伝えてくださり、逆算することで設計を人工的に作り出す、というこのセッションは、次に設計するときにこの発表のスライド見ながら取り組みたいと思いました。

運営に携わって

@nobu09 です。今年、初めて Kaigi on Rails に運営メンバーとして参加したので、その感想を書きます。
Kaigi on Rails 2023、2024と2年連続で現地参加し、とても楽しく次の日の業務へ向かう活力を毎回もらっていました。自分は小学校高学年の子どもが1人いて子育てなどでカンファレンスなどに参加しにくい時期があったため、託児所の用意がありオンラインでも参加できる Kaigi on Rails は、様々な状況にある人でも「参加していいんだ」と思えるようなカンファレンスだと感じ、感謝の気持ちを持っていました。自分も運営する側として関わってみたいと思っていて、元同僚の運営メンバーの方にいろいろ教えていただきながら去年の年末頃から参加しました。

運営はチームで進めていて、事前準備では定期的に全体でミーティング、チームごとに必要に応じてミーティングを重ねていました。
自分は託児チームに参加しました。託児チームは3人で全員お子さんのいるメンバーでした。託児サポートはスポンサー企業さんが提供してくださったので、スポンサー企業の担当の方とのやりとり、託児申し込みの告知などを行いました。

開催当日は、現地参加の方がたのしんでいる様子を見てうれしい気持ちが込み上げました。初参加の @sakiadachi さんにも本編から懇親会まで楽しんでもらえたようで、お声掛けしてよかった・・！と思いました。

後日、SmartHRさんの事後勉強会 でオーガナイザーでLTしませんかと声かけていただいたので、託児の取り組みについて5分お話しました。
Kaigi on Rails での今までの託児の取り組み（なんと2022年から託児サポート提供していて今年4回目！）や、今年託児でやったことについてお話させていただき、託児サポートについて共感の声をいただいてうれしかったです。

おわりに

@sakiadachiです。Kaigi on Railsに初めて参加した感想を書きます。
ポジションやレベルを問わず、新しい知識や経験を持ち帰ることのできるカンファレンスだなと思いました。
カンファレンスの合間や、本屋さん、アフターパーティで様々な方と交流することができて、すごく刺激になりました。コーヒーも美味しくて、オリジナルグッズもとても素敵でした！

Railsコミュニティは活発で、首都圏だけでなく全国津々浦々で集まりがあるということも発見でした。
お声をかけていただいたカンファレンスオーガナイザーの@nobu09さんをはじめ、情報発信や、登壇、イベントの企画など、皆さんが積極的に活動されている様子が印象的でした。

自身の今までを振り返るとインプット中心の活動が多かったように思います。今回のカンファレンスをきっかけに、今後はよりアウトプットを積極的にしていこうと思いました🔥