Kaigi on Rails 2025に参加してきました 🛤️
こんにちは！
株式会社ココナラのマーケットプレイス開発部 Web開発グループ バックエンド開発チーム所属のさいぴーです。
今回は、2025年9月26日（金）〜27日（土）に開催されたKaigi on Rails 2025に、さいぴー、とーる、よるま、こうやの4名で参加してきました！
この記事では、私たちが今回のカンファレンスで学んだことや感じたことをレポートしていきます！
Kaigi on Rails 2025とは
Kaigi on Rails 2025は、Ruby on Railsを中心としたWeb技術に焦点を当てた技術カンファレンスです。
「初心者から経験豊富なプロフェッショナルまで、誰もが参加しやすい」をコンセプトに、今年はハイブリッド形式（オフライン＋オンライン）で開催されました。
開催概要
- 日程: 2025年9月26日（金）〜27日（土）
- 会場: JP TOWER Hall & Conference（東京駅近く）
- 形式: ハイブリッド開催（オフライン＋オンライン）
今回のテーマは「動的（dynamic）」。継続的に変化し続けることについて、Ruby、Rails、そしてプロダクトのスケーリングという観点から議論されました。
ココナラでもバックエンド領域の主要部分にRuby on Railsを開発言語／FWとして採用しているため、最新の技術動向を知る貴重な機会となりました。
印象に残ったセッション
ここからは、メンバーそれぞれが特に印象に残ったセッションを紹介していきます！
さいぴーが選ぶセッション
あなたのWebサービスはAIに自動テストしてもらえる？アクセシビリティツリーで読み解く、AIの『視点』
Yusuke Iwakiさんのセッションに参加してきました。
実は先日、社内のQAチームメンバーからAIを使ったテストケース生成について取り組んでいるという話を聞いたばかりで、
Browser UseやPlaywright MCPなど、ブラウザをAIで操作する手段が増えていく中で、実際にAIがどういう要素をもとにページ構造を分析しているのかに興味をもっていました。
このセッションで取り上げられていた、Browser UseとPlaywright MCPが自然言語の指示やUI要素をどう解釈し、処理するのかという内容はとても学びが多かったです。
特に印象的だったのは、AIがアクセシビリティノードを使ってページを分析しているという事実で、私は今回の発表を聞いて初めて知りました。
さらに、独自実装でUIコンポーネントを作成した場合、アクセシビリティノードが生まれず、AIがページを分析できない状態に陥るリスクがあるという点も非常に重要と感じました。
このセッションを通じて、「ユーザーに対するアクセシビリティ向上」と「システム運用面でのテストケース生成」という、今まで自分の中では遠かった2つの領域がグッと近づいた印象を持ちました。
アクセシビリティ対応を進めることが、AIによる自動テストの精度向上にもつながるという、領域同士の大きな相乗効果を生み出していきたいですね。
登壇者ご本人によるブログ記事もぜひご覧ください：
2分台で1500examples完走！爆速CIを支える環境構築術
Hayato OKUMOTOさんのセッションでは、RSpecのテストを並列実行で高速化する技術について紹介いただきました。
AI活用が進むにつれて、コード生成のスピードは飛躍的に上がった一方で、それに対して他のステップの実行速度に目を向ける必要性が出てきています。
コンテナの起動に必要な時間、単体テスト・統合テストの実行時間、デプロイといったCI/CDにかかる時間を併せて削減しないと、開発フロー全体のリードタイムは短縮されません。
このセッションでは、ただ並列化するだけではなく、プロセスごとの実行時間を均すことやディスクアクセス負荷を低減するためにディスクキャッシュを使用するなど、具体的なアプローチが紹介されました。
そして最も面白かったのは、最終的にクラウド上ではなく物理マシンに移行したことが最もインパクトがあったという結論です。様々な最適化手法を試した上での、この大胆な選択は非常に印象的でした。
ココナラ、というより個人的にはテストの実行時間がAI活用の課題になることがあります。このセッションで学んだ最適化手法も含め、すぐにチームに持ち帰り課題シートに起票したので、これから検討を進めていきたいですね。
SpeakerDeckに登壇資料が公開されています：
2重リクエスト完全攻略HANDBOOK
Webサービスを運用する上で、通信路における障害やリトライの可能性を事前に考慮することはとても重要です。
特にココナラでは、サービスの購入や電話相談機能など、多重リクエスト・多重処理が発生するとユーザーのお金や満足度に直結する機能が多くあります。
社内で試行している取り組み以外に新しい知見を得るため、Shohei Mitaniさんのセッションに参加しました。
このセッションでは、対策をクライアント側とバックエンド側で大別し、さらにバックエンド側ではHTTPリクエストレベル、DB、セッションなど、複数の層で多重リクエストを回避する方法を紹介していました。
冪等性の確保、悲観的／楽観的ロック、ワンタイムトークンなど、様々な防止手法が体系的に整理されていて非常に分かりやすかったです。
Railsに限らず、言語やフレームワークに依存しない汎用的な知識が得られたことも大きな収穫でした。この知識は、自社プロダクトに適用するだけでなく、外部APIの調査時にも活きてきます。
このセッションで学んだ知識を、決済周りなどの重要な機能を実装する際の設計レビューでも活かしていきたいと思いました。
SpeakerDeckに登壇資料が公開されています：
「技術負債にならない・間違えない」権限管理の設計と実装
最後に紹介するのはnaro143 (Yusuke Ishimi)さんのセッションです。
権限管理は、システムが成長するにつれて複雑化しがちな領域です。私も最初は単純にadmin?のような条件分岐で作っていたロジックが、いつの間にか条件が複雑になり、修正が怖くてパンドラの箱になる...という過去の苦い経験があります。
このセッションでは、ModelsとPoliciesを1対1で対応させるRails Wayに従うことで、権限管理の仕組みが明瞭になるという手法が紹介されていました。
特に重要だと感じたのは、エンジニアでない方でも、英語が読めれば「誰が何をできるか」を正確に理解できる状態をコード上に作るという点です。
ただ機能として動くものを作るのではなく、CSや運用担当者でも機能名と権限とポリシーをもとにその挙動が正しいかを判断できるという状態を作ることは、プロダクトとしての堅牢性、運用容易性を向上させることに直結します。
ココナラでも、出品者、購入者、コンテンツ執筆者など複数のロールがあり、それぞれができることが異なります。
随所に存在する権限管理機能を整備することで、新たな機能追加を行う際の考慮事項を減らすとともに、誰でも一目で理解できる権限管理の仕組みを構築できる、そのヒントを得られた発表でした。
SpeakerDeckに登壇資料が公開されています：
こうやが選ぶセッション
そのpreloadは必要？──見過ごされたpreloadが技術的負債として爆発した日
mugiさんのセッションでは、N+1対策で多用されるpreloadメソッドを使う際の注意点について、実例を用いて解説していただきました。
preloadメソッドはN+1対策として便利ですが、関連データの階層の深さや件数を考慮せずに使うと、不要な大量のActiveRecordインスタンスを取得してしまいます。
プロダクトの成長により、不必要なインスタンスが大きくなりすぎて、Out Of Memoryが発生したという内容でした。
こちらのセッションを拝聴して一番最初に思い浮かんだことは、同様の事例が弊社でも発生しうるということでした。
例えば、弊社ではユーザーが複数のサービスやコンテンツを出品しており、それらが購入された際の決済履歴などがアソシエーションで繋がっています。
ユーザーインスタンスに関連する子インスタンス・孫インスタンスをpreloadで一気に取得しようとすると、Out Of Memoryが起きそうだと思いました。
セッションで学んだ知見に基づき、個人レベルでの対策としては、自分がpreloadを使う際には取得前にデータサイズを見積もったり、preload以外でN+1が回避できるかといったことを考えながらコードを書くようにしたいと思いました。
また、会社としての仕組みでこのような事態を防止するには、オーソドックスなやり方ではありますが、モニタリングをサボらないといったことがあると思いました。
SpeakerDeckに登壇資料が公開されています：
Railsによる人工的「設計」入門
こちらはYasuko Ohba (nay3)さんのセッションでした。
内容としては、初心者エンジニアにどのように設計を教えていくかというものでした。
このセッションの中で出てくる初心者エンジニアの事例が、1年くらい前の自分と重なる部分が多かったので、初めて設計にチャレンジしてみる新人君がハマってしまうところは大体同じなのだろうと思いましたw
初心者の傾向として、抽象的な設計をせずに、いきなりテーブル設計やモデル内での具体的なメソッドを考えてしまうということが挙げられていました。
設計に慣れたエンジニアであれば、完成像を先に想定し、そこから機能設計や基本設計、詳細設計という順で設計を進めていくと思います。
しかし、過去の私も含め、初心者エンジニアはその逆の流れで設計しようとしていきます。
完成したシステムやそのシステムがどのように利用されるのかが思い浮かばず、テーブルにどんなカラムを用意するかや、モデルに定義するインスタンスメソッドが先に思い浮かんでしまい、それを積み上げて全体像や設計書を作り上げるという順番で進めてしまいがちです。
結論としては、完成したシステムを先に思い浮かべて、そこから逆算して設計を進めていくというのが対応策でした。
完成したシステムを先に想像して、そのシステムに対する疑問や課題を洗い出していき、それらに対応できるように設計を進めるというのは、慣れていれば当たり前ですが、初心者エンジニアにとっては未知の設計方法です。
シニアクラスやミドルクラスの先輩エンジニアの方は、自分たちが考える設計と初心者エンジニアが考える設計では流れが逆になっているということを認識することから始めないといけないのかもしれません。
その上で、レビューなどでフォローしてあげることが、初心者エンジニアたちの設計力向上に繋がっていくのだと思いました！
SpeakerDeckに登壇資料が公開されています：
全体を通じて
Kaigi on Rails 2025は、初心者から経験豊富なプロフェッショナルまで幅広い参加者層が集まるカンファレンスでした。オフライン会場ではリアルタイム翻訳（日本語→英語）の仕組み（このイベント専用に作ったとのこと！）が導入されており、聴衆体験への配慮が多く見られました。
全体のセッションを通じて感じたのは、AIが広く普及した今の開発現場では、コーディング以外のステップにも目を向ける重要性が高まっているということです。CI/CDの高速化、テスト自動化、アクセシビリティ対応など、開発周辺領域の最適化が競争力を左右します。今後は企画やデザイン、QA、運用といった領域を含めてシームレスに開発を進められる企業が生き残っていくでしょう。私たちココナラのエンジニアも、日々の業務の中で越境を意識した動きを取り入れていきたいと思います。
最後に
ココナラでは、一緒に事業のグロースを推進していただける様々な領域のエンジニアを募集しています。
Ruby on Railsを使った開発だけでなく、フロントエンド領域・インフラ領域などでも積極的にエンジニア採用を行っています。
少しでも興味を持たれた方がいましたら、エンジニア採用ページをご覧ください。
Discussion