Kaigi on Rails 2025カンファレンスレポート【各講演の学び】

RIZAPテクノロジーズ社に2024年4月に新卒エンジニアとして入社し、chocoZAPアプリ開発のBE（バックエンドエンジニア）を担当している佐藤です。

2025年9月26日～27日に開催された「Kaigi on Rails 2025」に、弊社のエンジニアメンバーが参加してまいりました。Railsコミュニティ最大級のカンファレンスとして、今年も多様なセッションが繰り広げられ、技術的な学びはもちろん、コミュニティとの交流を通じて大きな刺激を受ける2日間となりました。

本記事では、参加したメンバーそれぞれが特に印象に残ったセッションについてレポートいたします。各メンバーの視点から見たKaigi on Rails 2025の魅力をお伝えできればと思います。

１：Keynote: dynamic!（梅田）

【概要1】"動的"で柔軟なRails開発の真髄

今年のKaigi on Rails 2025の基調講演を飾ったのは、MOROHASHI Kyosukeさんによる「dynamic!」というセッションでした。

MOROHASHI Kyosukeさんは昨年、一昨年と続けて登壇され、そのたびに聴衆を魅了してきた方です。私自身も過去のトークを現地で聴き、大きな学びと高揚感を得ました。その積み重ねが今回の基調講演という形に結実したのだろうと感じます。

タイトルの「dynamic!」は、Rubyの動的型付けという特徴を指すだけでなく、「今にも動き出しそうな」RubyやRailsの活力、そして開発者の心を動かすワクワク感を象徴していました。

講演では、RubyのirbやRailsのrails consoleのように、対話的にコードを動かしながら仮説検証を繰り返せる環境の素晴らしさが強調されました。

人と対話するようにプログラムと向き合い、動かしながら欲しいものへ近づいていける――その「対話性」こそRubyやRailsの魅力であると語られていました。

さらに、良いコードや良いプロダクトは静的に一度決まったものではなく、常に動的に変化し続ける営みそのものであると指摘されました。利用者視点でハッピーパスを最優先に捉え、枝葉の機能やコードは「そのとき」まで温存しておく。最重要エンティティの名前づけとCreate/Readを押さえれば、自然と次の開発も進めやすくなる――MOROHASHI Kyosukeさんは、そうした柔軟な姿勢こそが「dynamic」なRails開発だと説いていました。

＊

MOROHASHI Kyosukeさんの講演内容だけでなく、その根底に流れる「動的で柔軟なものづくり」への姿勢は、同日の他セッションにも大きな影響を与えていたように感じます。

【概要２】「Railsによる人工的『設計』入門」

Yasuko Ohba (nay3)さんは、初学者向けに設計の思考法を解説されました。

「コードから設計を導くのではなく、完成形から逆算することが光の道」と語り、まず利用者が何を達成したいのかを思い描く重要性を強調。悩ましい部分はシンプルな仮置きに留め、必要な「そのとき」が来たら考える――これはまさにMOROHASHI Kyosukeさんの「ハッピーパスに集中する」姿勢と重なります。

【概要３】「今改めてServiceクラスについて考える」

『パーフェクト Ruby on Rails』の著者の一人として知られるHashidate (joker1007)さんは、サービス層を巡る自身の変遷を語りました。

サービス層はあくまで手段にすぎず、その本質は「ドメインコンテキストをどう理解し、境界を描くか」にあると指摘されました。RailsのMVCがもたらす「どこに何があるか想像できる」安心感を重視しつつ、ユビキタス言語による共通理解の必要性を説かれました。

MOROHASHI Kyosukeさんが「最重要エンティティを見出し、名前をつけること」と語ったのと、Hashidate (joker1007)さんが「ドメインコンテキストを理解し、ユビキタス言語を用いて命名する」と述べたのは、言葉こそ違えど同じ意味だったように思います。

実際、前イベントのタイムテーブル解説会でも、運営チームがHashidate (joker1007)さんのトークを「1日目最後の実質的な基調講演枠」と紹介していました（実際にそうした枠はありませんが…）。MOROHASHI KyosukeさんとHashidate (joker1007)さん、両者のトークは奇しくも共鳴し合い、Kaigi on Railsの歴史に残る内容だったと感じます。

【感想】dynamic!が生み出した熱気と共鳴

「dynamic!」というタイトルに込められた意味は、単なる動的型付け以上のものでした。

仮説と検証を対話的に繰り返し、利用者のハッピーパスを起点に柔軟に変化し続ける。その営み自体が良いコードであり、良いプロダクトです。そうした思想が、他の登壇者の話とも自然に呼応していたのが印象的です。

今年のKaigi on Rails 2025は、まさに「dynamic!」という言葉にふさわしい、活気と多様な視点に満ちたカンファレンスでした。参加者一人ひとりが、自分なりのdynamic!を感じ取ったのではないでしょうか。

２：そのpreloadは必要？──見過ごされたpreloadが技術的負債として爆発した日」（松嶋）

【概要】便利なpreloadが“負債”になるとき

mugiさんのセッションでは、 ActiveRecordのpreloadが便利な一方で、安易に使い続けると深刻なパフォーマンス問題につながることが具体例とともに紹介されていました。

私自身、普段からN+1問題を避けるためにpreloadを使うかどうか迷う場面が多く、基本的には発行されるSQLを確認しつつ不要なら書かないように努力しています。

しかし今回、不要なpreloadにより1リクエストが大量のインスタンスを生成し、400MB以上のメモリを消費、最終的にはサーバーがOut Of Memoryで落ちたという事例を知り、その危険性を強く実感しました。

特に印象に残ったのは「成長のある時点では正解だった選択が、時間の経過とともに負債に変わる」という点です。システムのメモリ状況は変化するため、放置せずに継続的に見直すこと、そして変化を検知できる仕組みを作ることの重要性を学びました。

今後は「そのpreloadは今も必要か？」を常に問い直し、過去のコードも含めて有効性を確認する習慣をつけたいと思います。また、パフォーマンス監視やメトリクスの計測を取り入れ、負債が顕在化する前に気づけるチーム体制を整えていきたいです。

【感想】学びと刺激、そして一歩前へ

さまざまなスピーカーが登壇し、有益な話を多く聞くことができました。参加するだけで大きな刺激となり、新しい気づきや学びを得られたことは大変良かったです。

他方で、自分の理解が追いつかずに内容を十分に消化できなかったセッションや、初めて触れるRailsの機能についてはついていくのが精一杯でした。

加えて、今回の参加において自社以外の方と直接会話したのは企業ブースで説明を受けているときのみで、自分から積極的に話しかけることはできませんでした。

オフラインイベントの醍醐味は、同じRailsを扱うエンジニア同士で交流することにあると思うので、その機会を活かせなかったのは少し後悔しています。

今回、先輩社員の梅田がスピーカーとして登壇されており、自分も将来そのような立場を目指して技術研鑽に励みたいと思いました。正直に言うと、今回のセッションの中には理解が追いつかない内容や、自分の業務領域から離れていると感じるテーマもありました。

しかし、業務を通じて着実に力をつけ、いつかはそうした話題も理解できるようになりたいと考えています。現時点では来年の登壇を目標に、さらに成長を加速させていきたいです。

３：5年間のFintech × Rails実践に学ぶ - 基本に忠実な運用で築く高信頼性システム（阿久津）

【概要】“運用力”が支えるFintechの信頼性

Kaigi on Railsのような技術カンファレンスでは、多くの場合「どう作るか」にフォーカスする発表が並びます。そんな中でohbarye秀朋さんによる本セッションは「どう運用していくか」を正面から扱った珍しい発表でした。現場経験の浅い新卒一年目の私にとっても、このテーマは「運用がビジネスを支えている」という実感に直結し、学びを与えてくれる内容でした。

Ohbaryeさんが語った中で特に印象的だったのは、「信頼性とはビジネスを可能にすること」という視点でした。資金移動処理が止まれば、事業そのものが継続できない。バッチが遅延すれば、利用者への入出金が不可能になり、信用を失う。つまり信頼性とはシステムが落ちないこと以上に、規制を満たし、利用者にサービスを提供し続けられる状態を保つこと。そしてそれはコードだけでは担保できず、運用を通じて実現していくものだということです。

Ohbaryeさんはアーキテクチャ設計についても具体的な工夫を紹介していました。規制上とくに重要な機能については、本体から切り出して独立させることで、責任範囲を明確にする。その一方で、システム全体はあくまでモノリスを前提にしており、実際には九割以上のコードが単一のリポジトリで管理されているそうです。

分散や細分化を安易に進めるのではなく、機能ごとにnamespaceとしてmoduleを切り、内部で秩序を保つ。こうすることでシンプルさを維持しながらも、規制要件に応じた分離や責務の明確化を両立させているのだと感じました。

また、信頼性を支える運用の実践として、ohbaryeさんは「障害は起きる前提」とお話しされていました。大事なのはそれをいかに素早く検知し、正しく報告し、迅速に解決へと導くか。その徹底こそがFintechにおける信頼性を支えているのだと強く感じました。

加えて他のセッションとの共通点も感じることができました。例えば、MOROHASHI Kyosukeさんの基調講演「dynamic!」では、変化を前提としながらまずはハッピーパスから進める姿勢が強調されていました。システムをいきなり複雑にせず、シンプルに動かす。その考え方は、Fancyな構成に走らずにモノリスを前提とし、運用を通じて信頼性を担保していくFintechの実践と重なりました。

さらに共通点を感じたのは、昨年のKaigi on Rails 2024の島田さんの基調講演「Wholeness / Repairing」で語られた「修復とは全体との調和を取り直す」という考え方です。障害対応フローやRunbook整備といった取り組みは、まさに問題を修復しながら全体の調和を再構築する営みそのものだと感じました。

「運用」「変化」「調和」「修復」という一見異なる切り口が、Railsの思想として響き合っていたような感覚を覚えたKaigi on Rails 2025でした。

【感想】現場で実感した思想が“生きた学び”に

今回のカンファレンスで私にとって何よりの収穫だったのは、セッションそのもの以上に、MOROHASHI Kyosukeさんと一緒にコードを読む機会をいただけたことでした。MOROHASHI Kyosukeさんのソースコードを直接見ながら、その背景、経緯、意図を解説していただいた時間は本当に貴重でした。

そこで目にしたコードや説明、会話には、基調講演「dynamic!」や歴代の名講演で語られていた思想が息づいていました。ハッピーパスを基点に設計し、複雑さは必要になるまで導入しない。またコメントにはwhyを書き、後から他の読み手が見ても理解できるように書くべきだということなど、これまでの講演で聞いた内容が抽象論ではなく、実際にコードの中で具体的にどう生きているのかを体感できました。

新卒1年目の私にとって、Kaigi on Rails 2025全体を通して最大の経験を持ち帰ることができたと思います。

４： Railsによる人工的『設計』入門（梶村）

【概要】設計を「逆算」から考える重要性

今回のKaigi on Railsでもさまざまな題材のセッションがありましたが、特に印象に残ったのはYasuko Ohba (nay3)さんのセッションです。

発表の前半では導入として「設計を教える側」と「教わる側」がそれぞれ持つ設計に対するイメージのギャップを、分かりやすく説明されていました。このパートの結論をまとめると以下のとおりです。

「『設計を教える側』と『教わる側』の両者が、同じシステムを捉えているレイヤーの抽象度が異なっており、そのために認識のズレが生じ、うまく教えられなかったり、設計を体得するまでに時間がかかったりするという課題がある」

つまり、設計を体得している人はシステムを抽象度の高いレイヤーで捉えていますが、設計を教わる側（特に初学者）はシステムをコードレベルの抽象度で捉えようとしがちということです。

そのため、設計を教わる際に「イメージしてみる」や「図示してみる」といったアドバイスを受けても、「コードを書かないとそれはできない」という状態からなかなか抜け出せず、設計を身につけるまでに時間がかかると説明されていました。

従来は「漫然とコードを書いていたら設計ができるようになる」という考えも根強くありましたが、AIによってコードが簡単に生成できるようになった現代では、「設計ができること」の重要性はますます高まっています。

そこで、中盤のパートでは「何もない状態からゴールに向かって進めていく（順算）」のではなく、「目指すべきゴール＝作りたいシステムを起点に、どのようなパーツが必要かを考える（逆算）」ことが、設計を身につけるための再現性のある方法の一つなのではないか、という内容に話が展開されました。

こうすることで、設計段階で選択肢を比較することができ、比較した選択肢を組み合わせることで開発全体の見通しが立てやすくなる、という利点があるそうです。

【感想】今、設計を自分ごととして捉える

全体を通して、セッションで挙げられていた例や指摘に自分自身も重なる部分が多くありました。新卒エンジニアとして、今の自分がこのセッションを現地で見ることができたことに大きな意味を感じています。今後、設計を行う際には、この講演で学んだ内容を思い出し、実践していきます。

５：避けられないI/O待ちに対処する: RailsアプリにおけるSSEとAsync gemの活用 & 小規模から中規模開発へ、構造化ログからはじめる信頼性の担保（小川）

【概要1】避けられないI/O待ちに対処する: RailsアプリにおけるSSEとAsync gemの活用

本セッションはmoznionさんによる、I/O待ちに対するSSEとAsync gemの活用に関する体系的な知識と実践的な説明が語られました。イベントストリームの活用事例から、SSE実装におけるブロッカーなど実践的な内容を学ぶことができ、良い刺激となりました。

特に印象に残っている箇所は、async gemを用いたSSEレスポンスの非同期処理化です。私もSSE自体は利用したことがあったのですが、SSEレスポンスを非同期化することで、I/O待ちで占有してしまうワーカーやスレッドを効率的に扱うという発想は全く出てきませんでした。私の中で、発想に至らなかった内容を見聞きできたことは、とても良い刺激になったと感じています。

また、後日談としてmoznionさんの登壇資料と一緒に、セッションで話せなかった内容について語っていらっしゃる記事があります。こちらの内容もかなり面白い内容となっていました！

【概要2】小規模から中規模開発へ、構造化ログからはじめる信頼性の担保

2つ目はkakudoooさんによるログの扱いに関するセッションです。

私はSREエンジニアをしており、主にアプリにおける関心はオブザーバビリティを中心に寄せています。そのため、構造化ログとその信頼性という視点は私にとって非常に良い体験を提供してくれると確信していました。

実際、logrageやRails Semantic Loggerといったgemのそれぞれの特徴や、Rackにおいてログの構造化が適応されなかったケースなど、体系的な知識に加え、はまりケースなどもお聞きすることができました。logrageを問答無用で利用していた私にとって、このセッションは再度私に選択肢を探すキッカケを与えてくれました。感謝です！！

【感想】新しい発見がモチベーションをくれる

カンファレンス全体で言えることですが、新しい技術や自分にない考え方に触れる中で、自身のモチベーションの向上や自分の技術力に危機感を覚えることができ、Kaigi on Rails ならではの刺激をもらうことができました！

SREエンジニアという立場ながら、感動するセッションの数々で楽しい2日間となりました。

６： rails g authenticationから学ぶRails8.0時代の認証（清野）

【概要】Rails8.0標準認証の本質を知る

登壇されたのは、Shinichi Maeshimaさんでした。willnetさんは昨年に続いての登壇で、今回もRailsの最新機能について解説してくださいました。セッションのテーマは「Rails 8.0時代の認証」。Railsに新たに標準機能として追加された認証ジェネレータを用いて、認証の仕組みやセキュリティにどう向き合うべきかが語られました。

Railsで認証といえば、やはり有名なのは devise（The Ruby Toolbox調べ）。メールアドレスとパスワードの基本認証だけでなく、専用の拡張gemを利用すれば二要素認証や招待メール機能など多様な認証方法をサポートできます。

一見「deviseを入れておけば安心」と思えますが、公式READMEには注意点が書かれています。初心者にはdeviseの利用は推奨されていません。その理由は、挙動を変更したい場合にrack・warden・railsの仕組みを深く理解する必要があるためです。

そこで登場したのがRails 8.0から使える認証ジェネレータです。

なぜ標準機能になったのか？　スライドでは、DHHがこの機能を作った経緯が紹介されていました。Railsにはもともと認証用メソッドが存在していましたが、「どう使えばいいのか分からない」ということが多くあったのです。その道しるべとして、具体的な利用例を示すために認証ジェネレータが用意された、という背景です。

ただし、この認証ジェネレータはシンプルです。提供されるのは メールアドレスとパスワードのログイン/ログアウト/パスワードリセット といった基本機能のみ。多機能な認証が必要なら、これまで通りdeviseなどを使うことになるだろうと説明されていました。

話題はセキュリティにも広がります。認証ジェネレータで生成されたコードに脆弱性が含まれていた場合、利用者自身で修正するのは難しいという課題があります。また、gemを使う場合でもカスタマイズ時には細心の注意が必要です。結局のところ大切なのは、「ツールを使えばOK」ではなく、開発者自身が認証やセキュリティの知識を持つことだと強調されていました。

その学びの方法の一つとして紹介されていたのが、認証ジェネレータの生成コードを題材に学ぶこと。実際のソースコードを示しながら、認証の仕組みやセキュリティ対策がどのように組み込まれているかが解説されました。

僕自身、初めてRails newをしたのはわずか3ヶ月前ですが、Railsはまさに「レールに沿って」開発できるフレームワークだと感じています。Railsガイドなどドキュメントも充実しており、使っているだけで自然と新しい技術を学べる環境があります。今回の発表を通じて、Railsは認証やセキュリティの分野でも学びを提供してくれる存在だと実感しました。

【感想】初参加でも広がる“学びとつながり”

Kaigi on Rails 2025 1日目の最後には懇親会がありました。今回が初参加だったこともあり、知り合いもほとんどいなかったため、はじめは会場で少し孤立してしまう場面もありました。たまたま声をかけてくださる方がいて、そのおかげで自然に会場の輪に入ることができ、楽しくお話しすることができました。

さらに、スピーカーの方やRailsコミッターの方とも直接お話しする機会に恵まれ、とても貴重な体験になったと感じています。普段なかなか会えない方々と交流できるのは、カンファレンスならではの魅力だと思いました。

今回Kaigi on Rails 2025を通して、イベントに参加すること自体の楽しさを実感することができました。これからはカンファレンスや勉強会にも積極的に参加し、学びと交流の輪を広げていきたいと考えています。

学ぶを共有する社内懇親会

2日間のカンファレンスを終えた後は、参加メンバーに加え、バックエンド以外のメンバーも交えて懇親会を開催しました。普段はフルリモートで在宅勤務をしているため、こうして対面で顔を合わせる機会は貴重です。

地方在住のメンバー含めた仲間が集まった仲間が一堂に会したこの場では、モバイル部門やQA部門で働くメンバーの姿もありました。リモート上では名前や顔を知っていても、直接言葉を交わすのは初めてというメンバーも多く、部門の垣根を越えた交流が自然と生まれていきました。

カンファレンス参加者たちは、それぞれが聴講したセッションについて意見を交わし、学んだことや感じたことを共有していきました。「dynamic!という言葉が全体を貫いていた」「運用の重要性を改めて実感した」「設計の考え方が変わった」など、各人が異なる視点から得た学びが語られ、それがチーム全体の財産になっていく手応えを感じました。

また、新卒メンバーからは「来年は登壇を目指したい」「もっと積極的に交流したい」といった前向きな声も聞かれました。技術的な知見の共有だけでなく、対面での交流を通じて、カンファレンスが個々のモチベーション向上につながったことを実感する時間となりました。

まとめ

Kaigi on Rails 2025は、技術的な学びだけでなく、Railsコミュニティの温かさや多様性に触れることができる貴重な機会でした。

今回得た知見を日々の業務に活かしながら、来年のKaigi on Railsでは、私たちRIZAPテクノロジーズからもより多くの発信ができるよう、チーム一丸となって技術研鑽を続けていきたいと思います。

最後に、素晴らしいカンファレンスを運営してくださったKaigi on Railsの運営チームの皆様、登壇者の皆様、そして交流の場を共にしてくださった参加者の皆様に、心より感謝申し上げます。