こんにちは、ウォンテッドリーでバックエンドエンジニアをしている林です。
2026年10月16日（金）〜17日（土）にベルサール渋谷ガーデンで開催された Kaigi on Rails 2026 に、ウォンテッドリーは Ruby スポンサーとして協賛しました。
当日は富岡、江草、市古、小室、林の5名が参加し、ブース出展とスポンサー LT を行いました。
本記事では、LT とブースの様子に加えて、参加メンバーがそれぞれ印象に残ったセッションの感想を紹介します。
Kaigi on Rails とは
Kaigi on Rails は、Ruby on Rails を中心とした日本の技術カンファレンスです。Rails だけでなく、フロントエンドやプロトコルなど Web に関する技術を幅広く扱います。2020年に始まり、今年で7回目の開催となりました。
Kaigi on Rails 2026
スポンサー LT「ウォンテッドリーの最近のプロダクトとそれを支える技術」
ウォンテッドリーのサービスとして「Wantedly」だけを知っている方や、Wantedly を以前使っていても最近のアップデートは知らない方もいます。そうした方にウォンテッドリーの今を知ってもらうため、今回の LT ではウォンテッドリーが提供しているプロダクトと、それを支える技術を紹介しました。
LT で紹介したプロダクトの1つが Mendy です。Mendy は、ウォンテッドリーが開発している転職 AI エージェントです。転職エージェントから届くメールをアプリ内でまとめて管理し、スカウトとのマッチ度の判定や返信文面の作成を AI が手伝います。LT をきっかけに Mendy を知り、早速アプリをインストールしてくださった方もいました。
あなた専属の転職AIエージェント Mendy by Wantedly
LT を聞いてくださった皆さま、ありがとうございました！
ブースでの取り組み
ブースでは、ウォンテッドリーのプロダクトを紹介するパンフレットを配布しました。
ブースに立ち寄るきっかけを作るために、Mendy のプロジェクトリードである市古が、Mendy のキャラクターをモチーフにしたタイピングゲームを当日その場で作りました。多くの方がランキング上位を目指して、挑戦してくださいました。
プレイ画面：
プレイ環境の様子：
各メンバーの振り返り
富岡 真悟
Solid Queue: two years on Rails
https://rosa.codes/sq2026/presentation.pdf
Rails 8.0 で Active Job のデフォルトバックエンドとなった Solid Queue の作者でありメンテナーである Rosa Gutierrez さんによるセッションでした。内容としては Solid Queue が 1.0 から 2.0 に至るまでの2年間の道のりを振り返り、Hey という一つのアプリケーションにとって必要十分な機能でリリースしたところから、コミュニティに使われる中でどのような機能追加要望をもらい何を取り入れてきたか、またその過程での設計判断や苦労、さらにはメンテナーとしての信念なども語っていました。
同時実行制御については実は入れたくなかった、ジョブ実行側はシンプルな設計にしてアプリケーション側で制御すべきだと思うから、という述懐や、バッチ機能は早い段階でPRをもらい多くのユーザーから切望されたが、PR は細かい修正が必要で、最終的には Claude の Fable でエッジケースを修正できたことで2年半越しに取り込めた話などが印象的でした。
全体として、Solid Queue というプロダクトに対してオーナーシップを持ち、何を取り入れて何を取り入れないかに真剣に向き合っている点や、37signals の同僚でもあるDHHがコードをもう読まなくていいんだというようなことを言っている中で、コードの細部までは必ずしも全部読まないにしても内容をちゃんと理解して、入れた後もメンテナンスできるようにしている、それが今のところ私の哲学だと言っているところがかっこよかったです。冒頭でけっこう長い挨拶を日本語でされていたのもすごいなと思いました。
小室 光広
今回学びとなったセッションは utakaha さんによる「Railsのためのパスキー実践入門 〜マルチテナントSaaSでの意思決定〜」です。
パスキーはFIDO Allianceが標準化しているパスワードに代わる新たな認証方式で、ユーザーの生体認証やPINなどでユーザー検証し、パスキーとして登録している公開鍵を検証する方式です。ユーザーが認証情報を入力することがないためフィッシング耐性が高く、より安全な認証方式として注目していました。一方で、Railsでの具体的な実装方法は検討したことがなかったため、今回のセッションを聞き、webauthn-ruby で簡単に実装できることやRP ID (Relying Party Identifier) のスコープの切り方は非常に参考となりました。
パスキーに加え、FedCM (Federated Credential Management)やEVP (Email Verification Protocol) など新たな認証方式が登場する今日において、Rails での実現方法を考えさせられるセッションだと感じました。
この他にもブースでは多くの参加者にお立ち寄りいただき、技術的なお話ができました。特に、English Speakerの方と英語でお話しできたのはグローバルカンファレンスならではの体験だったと感じました。引き続き、様々なカンファレンスなどに足を運びつつ、技術の研鑽に努めていきたいです。
市古 空
Railsで挑む大量データ永続化 〜600億件を永続化するための設計とボトルネックとの戦い〜
スマートバンクの越智さんによる、理論上 600 億行になる電話番号の契約履歴を Rails のバッチで取り込む話でした。
結論や事実だけでなく、要件と制約からどう考えて設計を決めたのかが順を追って話されていて、聞いていて有意義でした。こういう大規模な ETL パイプラインを作るとなると、取り込み時間や再実行、DB への負荷など、確かに考えることが多いよなと思いながら聞いていました。
スループットやストレージは事前に試算しやすい一方で、CPU やメモリの使用率は実際に動かしてみないと分からない部分が多く、運用フェーズで調整することになりがちだと思います。本発表でも運用上の課題としてメモリ不足や CPU 使用率の上昇が挙げられており、個人的に共感の多い発表でした。
江草 亮太
Active Record Connection Adaptersにおける長年の課題に再び取り組む
Rails コミッターの Yasuo Honda さんによる Active Record Connection Adapters の課題に関するセッションでした。コーディングエージェントと一緒に作業するようになり、CI が落ちる問題などを任せられるようになった結果、重要だが緊急ではない課題に時間を割けるようになったそうです。そうして取り組んだ長年の課題が2つ紹介されました。
1つ目は PostgreSQL で superuser 権限なしに外部キー制約を無効化する話です。fixture のロード時に外部キー制約を無効化するために DISABLE TRIGGER ALL を利用していましたが、 superuser 権限が必要なうえ、無効化中に入ったレコードが検証されないという問題があります。そこで PostgreSQL 18 の NOT ENFORCED を使おうとしたところ、ENFORCED に戻すときに DEFERRED 制約の設定が消えてしまう PostgreSQL 側のバグを踏んだそうです。pgsql-hackers に報告し、日本の PostgreSQL コミュニティのレビューも経て 18.4 で修正された、という流れが非常に興味深かったです。
2つ目はサードパーティのアダプターにも migration compatibility を提供する話です。ActiveRecord::Migration[7.0] のようにマイグレーションにバージョンを指定すると、Rails のバージョンを上げても当時の挙動でマイグレーションが実行されます。ただ、アダプターごとの挙動の違いは Rails の実装でハードコードされており、サードパーティのアダプターはモンキーパッチで対応していたそうです。2018年に一度断念したこの課題に対して、AI と7回ほど設計をやり直して Rails 8.2 に入ることになりました。AI が見つけてくるエッジケースは、直すと既存ユーザーのリグレッションになるなら直さない、それは人が判断することだ、という話も印象に残りました。
「昔できなかったことも今ならできるかもしれない」という締めのメッセージには、自分も後回しにしてきた課題を思い浮かべて背中を押されました。
林 玲央
Event is what happens
このセッションでは、Rails 8.1 で追加された Structured Event Reporting をきっかけに、「イベントとは何か」が改めて考察されました。
moro さんは、Structured Event Reporting、RDB 設計のイベントエンティティ、Event-Driven Architecture（EDA）という3つの「イベント」が、どれも「サービスで大事なことが起きた」という事実を表す同じ概念だと整理していました。
特に印象的だったのは、EDA を開発の初期から無理なく取り入れられるという話です。EDA のような疎結合の仕組みは、開発初期には後回しにされがちで、サービスが大きくなってから導入しようとすると手間がかかります。Rails 8.1 では Rails.event が標準で備わっているので、受け取り先の購読者がまだなくても、大事なことが起きた場面で通知だけを書いておけます。後続処理が必要になった時点で購読者を追加すれば、イベントを発行する側のコードを変えずに処理を増やせます。
このセッションを通して、大事なことが起きたらイベントを通知し、その後の処理は購読者に任せるという、疎結合な設計の選択肢があることを学びました。今後の設計では、処理を一続きの流れに詰め込む前に、それがサービスにとってどんなイベントなのかを考えるようにしていきたいです。
まとめ
Kaigi on Rails 2026では、Ruby スポンサーとして協賛させていただきました。
ウォンテッドリーは、Wantedly のほかに、採用管理システムの Wantedly Hire や福利厚生サービスの Perk、Mendy など、複数のプロダクトを開発しています。今回の LT とブースを通じて、これらのプロダクトを含めた私たちの現在の姿を、Rails コミュニティの皆さまに知っていただけていれば嬉しいです。
改めて、運営の皆さま、登壇者の皆さま、ブースに立ち寄ってくださった皆さま、ありがとうございました。来年も Kaigi on Rails でお会いできることを楽しみにしています。
バックエンドエンジニアを募集しています
ウォンテッドリーでは、一緒にプロダクトを開発するバックエンドエンジニアを募集しています。カジュアル面談も受け付けているので、興味のある方はお気軽にご連絡ください。
/assets/images/24788591/original/95d3cea9-b793-4ae3-9f6e-df27666a4660?1791438796)
/assets/images/7052304/original/49100b17-5866-4cec-b50b-a37ea73565e9?1638782149)
/assets/images/7053725/original/28d1b135-13b4-4f46-895f-d5f5fb5ae243?1624246858)
