Kaigi on Rails 2026

「いつの間にかCIの実行時間が伸びている…」 Railsアプリケーションを運用するなかで、そんな経験をした方も多いのではないでしょうか？ 私もその一人です。 CI高速化の手がかりを探していたある日、XでDHHのポストを発見しました。 FactoryBot is the quickest way to kill your test suite performance with Rails. … The secret? Rails Fixtures! このポストに影響を受けた私は、FactoryBotをRails Fixturesへ移行する取り組みを始めました。 しかし、単純な置き換えでは済みませんでした。また、Fixturesを使えば必ず速くなるわけでもありませんでした。 本セッションでは、FactoryBotからFixturesへの移行で直面した課題や失敗を振り返りながら、 let_it_be やFixtureKitなども含め、それぞれの手段の特徴を整理します。 そのうえで、実行速度、保守性、導入コストといった観点から、改善手段を選ぶための判断軸を紹介します。

日々のCI failureや細かなライブラリの互換性変更といった、緊急性の高い作業に生成AIを活用できるようになった結果、これまで後回しにせざるを得なかった「重要だが緊急ではない」課題に、ようやく時間を割けるようになりました。 私にとっては、Active RecordのConnection Adaptersにある2つの課題がそれにあたります。ひとつは2019年に自分の力不足で断念したマイグレーションのサードパーティアダプター対応で、いまも設計を何度も練り直しながら取り組んでいます。もうひとつは2017年から動きが止まっていた、SUPER権限なしでPostgreSQLの外部キー制約を一時的に無効化する対応で、こちらはPostgreSQLの修正をおこなったパッチがPostgreSQL 18.4でリリースされ、それを前提にRails 8.2でリリースされる予定です。 生成AIはどんな問いにもそれなりの答えを返してくれるからこそ、その問いは本当に重要なのか、その答えは自分の課題を本当に解決するのかを考え抜く必要がある — この1年で得たその実感も含めてお話しします。

Rails 8.1で追加されたLocal CIは、CIの大幅な速度向上とコスト削減を両立する大きな可能性を秘めています。しかし、 などの懸念から導入を見送っていませんか？ 弊社では、Local CIとGitHub Actionsを併用することでこれらの懸念を解消し、それぞれの強みを活かして開発をしています。具体的には、mainブランチへのマージ時やDependabotのPRでは引き続きGitHub Actionsを利用しつつ、平常時はLocal CIを活用し、約140のモデルを持つRailsアプリケーションのCI実行時間を10分から2分程度に短縮しました。またGitHub Actionsのコストも約45%削減しました。 本トークでは、まずLocal CIとそれを支えるGitHub CLI 拡張機能のgh-signoffを紹介し、Local CIの結果をGitHub上に安全に反映する仕組みについてお話しします。その後、Rails 8.2で導入予定の group を活用した高速化のコツ、CIの併用に必要なBranch protection rulesやWorkflowsの設定、両者の実行コマンドをDRYに保つ方法など、半年間の実運用で得たTipsを余すことなくお伝えします。

AIエージェントにバグ修正を任せると、得意と不得意がはっきり分かれます。コードとテスト出力から原因を特定できるバグには強い一方、実行時の状態(レコードの実値、saveで実際に変わった属性、メモ化に残った古い値)に依存するバグでは切れ味が鈍ります。実行中のプロセスをその場で確かめる手段がないため、printの差し込みと再実行を重ね、最後は「動作確認をお願いします」と検証が人間に返ってきます。 本トークでは、debug gemをMCP(AIエージェントに外部ツールを接続する共通規格)経由でAIに開放します。AIは実行中のRailsアプリをブレークポイントで止め、その瞬間の内部状態を自分で確かめ、仮説を事実として確定させてから修正し、直ったことまで変数レベルで検証できるようになります。 実際にAIがrdbgに接続しバグを修正する様子をデモでお見せします。応用として、テスト失敗の瞬間のプロセスを保全しAIに調査させる構想にも触れます。 この解法を支えているのは、Railsが積み上げてきた資産です。ActiveSupport::Notificationsを使えば、アプリのコードに手を入れずにSQL発行やジョブ投入をAIに観測させられます。モデルのリフレクションを使えば、スキーマ、関連、バリデーション定義をAIがその場で確認できます。これらがAI時代になぜ効くのかを整理して紹介します。

複雑なロジックをどこに実装すべきか、そのために新しいレイヤーを導入すべきか。導入するならどこまでの責務を持たせるべきか。Railsコミュニティはこうした問いを長らく議論してきました。本発表は、これらの問いを一度手放すことを提案します。実装先に迷うとき、多くの場合、起きているのはレイヤーの不足ではなくモデリングの不足だからです。 Railsのモデルはテーブルと対となる形で定義され、比較的単純なアプリケーションであればうまく機能します。しかし、機能要求が複雑になると、注文の確定や在庫の補充、ポイントの付与といった「操作」に固有のルールが現れます。Railsでは、操作のルールはその主体や対象となるモデルに実装されやすく、独立した概念として見落とされる傾向があります。その結果、これらのモデルが静かに肥大化し、保守性が低下していきます。 本発表では、モデルとそのCRUD操作を中心としたRailsの設計が、高い生産性と引き換えにドメインにおける重要な操作を見落としやすい構造を持つことを解き明かします。そのうえで、ドメインのルールを、それを担うモデルごとに整理し、どの既存のモデルにも帰属しないルールから新しいモデルが生まれるまでの過程を設計判断とともに示します。 本発表のあと、みなさんは実装先やレイヤーを議論する前に問うべきことを手にしているはずです。「このルールを担う概念は何か」という問いです。

Rails promises a small team can stay productive across the whole stack. But what if you want to build your UI in React (or Vue, or Svelte)? Reach for it the usual way and Rails loses some of its magic. It becomes a JSON API behind a separate React app, and your small application grows into two codebases you sync by hand. The Rails ecosystem has a way out. Inertia Rails turns React into a view layer: your controllers still render the pages, with no API and no tangled client-state in between. Let’s see how React learns to play by the rules of the One-Person Framework!

「エンジニアの知らないところで作られたSpreadsheetが重要な業務の一部になっている。Spreadsheetの運用をRailsアプリに移行したい。」 こうした状況は多くの現場にあると思います。 弊社は英語塾でRailsを使った学習管理システムを開発しています。弊社でもコーチングに欠かせない「レッスン報告」がGoogleスプレッドシート(以下、Spreadsheet)で管理されていました。 東京から福岡まで分散する9つの校舎がそれぞれ独自のSpreadsheetを作り、レッスンごとに引き継ぎなどの業務日報を記録していました。レッスン報告は随時追記されるため、上書きで消える、データごとの権限管理ができないといった問題がありましたが、校舎ごとの差異が大きく、Railsアプリへの移行は長らく出来ずにいました。 そこで私たちが最初に作ったのは「全校舎共通のシンプルなSpreadsheet」でした。 当初は妥協案でしたが、このSpreadsheetが現場と業務概念を整理する場として機能し始めます。本セッションでは、半年の運用を通して業務概念が整理され、Railsアプリへの移行と約7万件のデータ移行が実現した過程を紹介します。 理想のモデルを最初から設計できない状況で、現場と一緒に段階的にモデリングを進めるヒントを持ち帰っていただけたら嬉しいです。

ライブエンタメのチケット販売や会場物販、ECでは、熱狂的なファンが販売開始と同時にアクセスし、販売プラットフォーム全体で数分間に100万件を超えるリクエストが発生します。一方、クラウドプラットフォームの提供するオートスケーリングでは、アクセス増加の検知からコンテナ起動まで約5分かかり、増設が完了する頃にはピークを過ぎてしまいます。 そこで、外部ID基盤とのプロトコル変換で販売開始時のログインを支えるRailsアプリケーションに、Fiberを活用するRack対応アプリケーションサーバ「Falcon」を使えないか検討しました。Pumaは外部API待ちにもスレッドを使いますが、FalconはFiber Scheduler対応のHTTP通信を待つ間に別のFiberへ処理を切り替えられます。定常時のコンテナ数を増やさず、短時間のピークを効率良く処理できる点に着目しました。 このトークでは、既存のRailsアプリケーションへのFalcon本番導入を紹介します。既存のgemとHTTP通信の見直し、PumaとFalconを並行稼働させた段階導入、切り戻せる状態で比較・評価を進めた方法をお話しします。Falconと新しいHTTPクライアントを組み合わせた構成のレイテンシとCPU使用量、移行中の500エラー、運用上の注意点を、具体的な本番データで共有します。

Protocol Buffers (aka: Protobuf). 主にgRPCで利用するものだと思われている事が多いかもしれません。実はスキーマ付きデータフォーマットとして、gRPCなどに留まらず気軽に利用できる仕組みです。バイナリ列にシリアライズできる・言語を問わない以上に、分かりやすくスキーマ定義を行える点が非常に強力です。 本講演ではprotobufをフル活用し、ActionContollerのAPIリクエスト・レスポンスからActiveRecordのjson型データまで、あらゆる所でスキーマ定義をしたRailsアプリを元に、活用法を紹介します。これには {foo: 42, …} といった雑なHashリテラルが存在せず、ほとんど全てProtobufを通してデータを生成しています。さらにOpenAPIスキーマもProtobufから自動生成されクライアントへ提供しています。 また、実験的にConnect RPCやgRPCをRailsで提供してみています。これまでRailsにおけるgRPCサーバーはUnicorn/Pumaではなくgrpc gemを利用する必要があり、これはRackではないため、開発や運用で難がありました。本セッションではFalconでActionControllerを通したRPCサーバーの実装も紹介します。

With teams, companies, and open source projects adopting Herb, it’s proving itself at scale and is on track to become an opt-in view engine in Rails 8.2. This talk explores what Herb brings to Rails, from its ActionView integration to the tooling and developer experience it unlocks. Then I’ll introduce the first production-ready version of ReActionView, bringing Phoenix LiveView-like fine-grained reactivity to standard HTML+ERB templates. Optional, gradual, no JavaScript framework, no new file format.

Ruby 1.8.7 / Rails 2.3で長年稼働してきた社内製品の管理サーバを、Ruby 3.4 / Rails 8へ載せ替えた実録です。フレームワークの破壊的変更だけでなく、散在する設計書、本番と乖離したブランチ、誰も触らなくなった運用が、バージョンアップを何倍も難しくします。マイグレーションの失敗、認証系ライブラリの移行、一気に上げるか段階的に上げるかの判断といったRailsのEoLに関する情報に加えて、ドキュメント探しの修行、AIにレガシー文脈を教える工夫、ブランチ整理の修羅場といった周辺の知識も含めて、チームで実際に踏んだ話としてお届けします。

ブラウザから送られたHTTPリクエストは、Rails内で「Rack → Router → Controller → View → Response」という流れで処理されています。この仕組みを知りたいと思っても、どこから読み進めればいいのかわからずにいました。 そこで、最小限のRails実装であるmini-railsを自分で作ってみることにしました。 本発表では、mini-rails上で簡易的なブログが動く様子を見ながら、リクエストを受け付けてからレスポンスを返すまでの実装をお話しします。 普段何気なく使っているRailsの内部がどうなっているのかを、一緒に覗いてみましょう。

パスキーによるログインは、金融機関から大手Webサービスまで急速に広がっています。そろそろ自社のサービスでも、と思いつつ、しくみがよく分からない、何から検討すればいいのか分からない、と後回しにしていませんか。 このトークでは、まずパスキーそのものについて解説します。パスキーとは何か、どういうしくみでログインできるのかを、登録・認証のフローとRailsでの実装例とあわせて解説します。 そのうえで、パスキーをマルチテナントのRailsアプリケーションに実装するときにどういう意思決定が必要になるのかを、SmartHRでの導入により得られた知見をもとに紹介します。パスキーをオートフィルで呼び出すか、専用ボタンで呼び出すかの意思決定や、サブドメインでテナントを分けるマルチテナント構成でのRP IDの決め方など、実際に下した判断とその理由についてお話しします。

Rails 8.1 でStructured Event Reportingという新機能が導入されました。 これはRailsのアプリケーションレイヤにpub/subの仕組みを導入するという機能です。 Rails.event.notify()でなんらかの「イベント」が起こったことを通知でき、通知されたイベントは事前に登録されているサブスクライバで処理されます。典型的には、サービス内で発生したコンバージョンのログ取得などに役立つでしょう。 さらに、イベントという語はDB論理設計にも現れます。コトを表す「イベントエンティティ」ですね。CRUDのシンプルさを実アプリケーションに適用するために重要な概念です。 他方で、アプリケーション設計における「イベント」といえば、イベント駆動アーキテクチャ(EDA)も想起されます。EDAは、システム内で発生した状態の変化すなわちイベントを起点にして処理を動作させる設計パターンです。話者は、RailsでこのEDAを手軽に導入する手段としても、このRails.eventに可能性を感じています。 本トークでは、これが同じ「イベント」と呼ばれる理由を考察し、「サービスで大事なことが起きた」ことを扱う標準のインターフェースが導入されたことを讃えながら、Structured Event Reportingの発展的な利用法を紹介します。