Kaigi on Rails 2026

「すべての永続トークンを、生まれる前に消し去りたい！すべての宇宙、過去と未来の全ての永続トークンを、この手で」 外部サービス連携やマイクロサービスにおいて、アクセストークンを永続的に利用可能なものに設定して使い続けたい、と思ったことはあるでしょう。しかし同時に、それがセキュリティホールであるということもなんとなく感じていることでしょう。また、トークンリフレッシュというものについて聞いたことはあるけれど、トークンのライフサイクルの管理が難しい、ということも考えたことがあるでしょう。 このトークでは、永続トークンをやめる理由、やめるための方法、その上でも気をつけるべきセキュリティ上の懸念事項などについて話します。みなさんの使う・作るサービスの認証について、改めて考えてみませんか？

RESTはRailsにおいて重要な要素であり、RESTという用語が普及するひとつのきっかけにもなりました。しかし多くの現場で、「RESTはAPIの設計手法」のように誤解されています。 本来のRESTは、Webがなぜ成功したかを分析した9つの制約です。本発表ではまず、この制約を満たすと「古いものを壊さずに新しいものを足せる」拡張性と、「制御できない相手と通信しても壊れない」インターネット規模という2つの特性が得られることを、RESTの原典の論文に基づいて解説します。そのうえで、Hotwire、React + JSON API、Inertiaといった現在のRailsで採用されるアーキテクチャが、2つの特性のどれを得てどれを失っているかを一枚の図で診断します。 両方の特性を満たす「真のREST API」、すなわちハイパーメディアAPIは、理想だが現実には難しいと長年言われてきました。その評価が、いま反転しつつあります。真のREST APIが前提としていた、あるクライアントがついに現れたからです。後半では、同じToDoアプリをHotwire版とReact + JSON API版で用意し、そのクライアントで動作させる比較を行います。どちらのスタイルの開発者も、自分の設計の現在地と、明日から取れる一歩を持ち帰れます。

「試しにアプリをデプロイしたい」— そう思っても、サーバーの準備に加えて DB やストレージを整えるにはインフラの知識が必要で、”ちょっと試す” には敷居が高い。結局ローカルで動かして終わり、という経験はないでしょうか。 Rails 8 に標準搭載された Kamal を使うと、自前サーバーへのデプロイ自体はコマンド一発になります。それでも「アプリを動かすこと」までで、DB やストレージの準備、複数サーバーをうまく扱う運用の手間は、変わらず残ります。 そこで、Kamal を土台に、その “残り” を丸ごと引き受ける社内 PaaS を Rails で作りました。リポジトリを選んでボタンを押すだけでサービスが動き出す、例えるなら社内版 Heroku です。 狙いは “動かす” だけではなく、限られたサーバー群に多数のアプリを安全に同居させ、実運用に耐えること。複数サーバーへの自動分散やゼロダウンタイム入れ替えも裏側で担います。運用もデバッグもブラウザだけで完結。さらに API を通じて、AI Agent に会話で原因調査や修正まで任せられます。 本発表では、Kamal にどこまで任せ、どこを作り込んだのかを紹介しながら、「インフラの仕組みも、使い慣れた Rails の道具で作れる」という実感を、きっと持ち帰ってもらえるはずです。

機能を作るのは簡単になりました。でも、消すのはどうでしょう？ どこからも呼ばれていないと判断することは可能です、でも「呼ばれる経路は残っているが、使われない」機能はどうでしょう？ 目的があって追加した機能も、機能刷新や、別の機能に役割を奪われたりする場合もあります。検証のために追加したが、役目を終え不要になるケースもあります。そうして”あまり”使われなくなった機能は静かに積み上がります。残したままにすると、回帰テストは膨らみ、コードは少しずつ重くなり、変更のたびに足を引っ張る。 では、どうすれば安全に消せるのか。鍵は「もう誰からも呼ばれていない」状態を作ることです。別のコードからも、積まれたジョブからも、古いアプリからも呼ばれなくなれば、その機能は安心して消せます。この「呼ばれなくしていく」作業を、このトークでは「枯らす」と呼びます。いきなり消すのではなく、まず使わせない。値を返すのをやめる。旧バージョンのアプリを壊さないよう受け止める。そうしてトラフィックやデータが枯れてから、順序を守って消す。 実際に廃止したRails APIの機能を題材に、この「枯らしてから消す」一連の流れをお見せします。型を持てば、削除は一大事ではなく日常の選択肢になる。すると、作る合間に消せる。作るときから「どう消すか」も一緒に考える。そんな当たり前を持ち帰ってもらう15分です。

ファイルアップロードは一見地味ですが、現代のWebサービスには欠かせない機能です。一方Railsでは、Active Storage登場以前のライブラリが本番環境で動き続けていることも多く、設計の負債が溜まりやすい領域でもあります。 このトークでは、とある人事労務系SaaSで長年稼働してきたファイルアップロード機能を題材に、サービスを止めずに改善してきた実践の記録をお話しします。動き続ける古い基盤に対して、「どの順番で負債をほどくか」「今ある大量のデータをどう扱うか」「既存ライブラリをどこまで延命し、どこまでモンキーパッチし、どこから置き換えを検討するか」などなどの、現場の試行錯誤と格闘の過程をそのまま開示します。 具体的には以下のテーマを扱います。 このトークが、皆さんにとって自分のサービスの負債と向き合うための道標となり、ファイルアップロード機能の「禅」に触れるきっかけになれば幸いです。

AI can generate code at unprecedented speed, but it can also generate bugs and regressions at unprecedented speed. As software creation becomes cheaper, the bottleneck shifts from writing code to verifying behavior. This talk revisits the rise and fall of Cucumber and BDD, exploring why executable specifications struggled to gain adoption and how AI may have changed the economics behind them. We’ll discuss how Ruby teams can build practical testing pipelines for AI-generated code using AI-assisted system tests as a safety net.

普段Railsで開発していて、フロントエンドとバックエンドを二重に管理している感覚はありませんか？その問題の原因と解決策のひとつは、RESTの 忘れ去られた4つめの制約 にあるのかもしれません。 RESTの統一インターフェースには4つの制約があります。最初の3つはRESTful API設計でおなじみのものです。しかし4つめは H ypermedia a s t he E ngine o f A pplication S tateという制約で、後にHATEOASと名付けられましたが、あまり多くは語られてきませんでした。 Fielding博士はこうも言っています。 REST APIs must be hypertext-driven 気になります。私は「作者の気持ちを答えよ」の本当の正解が気になって仕方がないたちです。 そこで、私はRailsでHATEOASを実践することをテーマに自分用の易占い（六十四卦）アプリを作り始めました。 本トークでは易占いアプリの、特にHATEOASを意識した仕様や実装を紹介しながら、 アプリケーションの状態遷移をハイパーメディアに駆動させる という設計がもたらす恩恵を具体的にお見せします。そして、普通のRailsアプリとHATEOASの関係、HotwireがHTMLを扱う必然性にも迫ります。

LLMを利用したAI機能をRailsアプリケーションへ組み込むこと自体は、それほど難しくありません。APIへプロンプトを送り、結果を受け取るだけであれば、これまでの外部API連携と同じように実装できます。 しかし、実際にプロダクトへ導入してみると、プロンプト管理、モデル選択、Structured Output、非同期実行など、AIならではの設計上の課題に直面しました。AIでは、API通信だけでなく、アプリケーション側がAIの振る舞いそのものを設計する必要があります。 本セッションでは、RailsアプリケーションへAI機能を導入した実例をもとに、「AIという責務をRailsでどのように設計するべきか」という問いに向き合った過程を紹介します。 当初の実装でどのような課題が生まれたのか、どのような選択肢を検討したのか、そして最終的にどのような観点で責務を整理したのかを、実際の設計判断や採用しなかった選択肢も交えながら共有します。 これからAI機能を導入する方はもちろん、すでに導入しているものの設計や責務分割に悩んでいるRailsエンジニアにとって、AIという新しい責務をRailsアプリケーションの中でどのように位置付けるべきかを考えるきっかけとなるセッションです。

Railsアプリでの大量データ永続化や移行では、普段のCRUD中心の開発とは異なる設計が求められます。 データ量が増えるにつれ、単純な保存処理だけではなく、データモデル、データストア、バッチアーキテクチャ、システム負荷まで考慮した設計が必要になります。 弊社では、ユーザーの不正利用対策等のために、2.5億件を超える電話番号と、その20年以上にわたる使用履歴データをRailsアプリケーションへ取り込むプロジェクトに取り組みました。 最初の課題は、20年以上の使用履歴をそのまま保存すると、600億件を超えるレコードになってしまうことでした。そこで、「状態が変化したタイミングだけを保存する」データモデルへ変更し、保存件数を大幅に削減しました。 この変更により保存件数を大幅に削減できました。しかし、それでも数億件規模のデータを扱う必要があり、データストア選定、50GBを超えるCSVのストリーミング読み込み、並列Bulk Upsert、バッチのリラン設計、OOM、デッドロック、RDBMSのCPU負荷など、さまざまな課題に直面しました。 本セッションでは、それぞれの課題に対する設計判断と、そのトレードオフを紹介します。 単なる高速化テクニックではなく、Railsアプリケーションで大量データを安全かつ継続的に扱うための設計の考え方を持ち帰っていただける内容を目指します。

ActionCable の相手は、いつもブラウザとは限りません。センサーを積んだ Raspberry Pi をコンシューマにすると、Rails はデバイス群にコマンドを配り、結果を受け取る「制御プレーン」になります。 本発表では、その設計を実機の Raspberry Pi を繋いだ動くシステムで紹介します。物理デバイスを Device モデルと状態機械で扱い、heartbeat と定期照合で生死を追いかける。ActionCable を双方向の transport にして、結果は冪等に取り込む。ActiveJob で「実行先が物理デバイス」なジョブを組み、落ちる前提でリトライとバックプレッシャを設計する——おなじみの道具だけで、ここまで作れます。 山場は「リアルタイムで Turbo Streams と生 ActionCable をどう使い分けるか」。毎秒届くスペクトルを HTML で撒くと転送量は約26倍、毎フレーム257個の DOM ノードが生まれます。実測ベンチから、低頻度の状態変化は Turbo Streams、高頻度の数値ストリームは生 ActionCable + canvas という判断基準を導きます。通知やダッシュボードなど、ふつうの Rails 開発にそのまま効く勘所です。 ライブデモとともに、見慣れた Rails の意外な射程をお見せします。

現代Webの動作環境において、JSは欠かすことができません。 フルスタックRailsアプリケーションですら、TurboやStimulusやその他JSのコードを当たり前のように使っています。 しかし、いざ動作確認をしようとすると、ヘッドレスブラウザを使ったSystem Specが必要となり、遅い上にflakyなテストとの戦いが勃発します。つらい。 本発表では、新たなテストの枠組みとしてBrowser Specを提唱し、その実装であるDommy::Browserについて解説します。 DommyはRubyで書かれたDOM実装で、Dommy::BrowserはDommy上に構築されたテスト向け軽量ブラウザです。本セッションではDommy::Browserを使って、単一のRubyプロセス内でJSを使ったWebアプリケーションのテストを行い、Railsにおけるテストの可能性を広げることに挑戦します。

A security incident exposed the resumes of 460 job seekers. The surprising part? There was no single bug or obviously wrong decision to blame. Instead, a series of reasonable technical choices interacted in unexpected ways, creating a vulnerability that went unnoticed until it was too late. In this talk, I’ll share how the incident was discovered, investigated, and resolved, along with practical lessons on security, complexity, and hidden assumptions in Ruby on Rails applications.

Valkey (Redis) は単なる KVS ではありません。多彩なデータ構造を備えたインメモリデータストアです。 それなのに、普段のアプリケーション開発では session store や cache、Sidekiq の queue としてしか使っていない、というケースは少なくないのではないでしょうか。せっかくそこにある機能を使わないのは、少しもったいないと思っています。 このセッションでは、まず Sorted Set を使ったランキング実装を題材にして Valkey のパワーを紹介します。ランキング専用のロジックをアプリケーション側に持たず、Valkey のデータ構造そのものに仕事を任せる設計は、とても気持ちが良いものです。 さらに、公式モジュールである Valkey Search によるベクトル検索や、Bloom Filter のような確率的データ構造にも触れ、「Valkey をアプリケーションの機能として使う」という発想を紹介します。 「Valkey = キャッシュ」ではもったいない。ランキング、検索、レコメンド、重複判定など、アプリケーションの中核となる機能を支えるデータストアとして Valkey を使い倒す。その面白さを、実例を交えながらお話しします。

以下のコードのように、文字列操作やArelのようなメソッドチェインではなく、Rubyの自然な式でクエリを書きたいと思いませんか？ かつてRefinementsを使ってwhereを拡張するactiverecord-refinementsというgemがありましたが、Refinementsをブロックスコープで有効にする機能が処理系の実装上の都合でRuby 2.0から削除されてしまい、その夢は潰えました。 Ruby 4.1の新機能となる予定のProc#refinedを使って、activerecord-refinementsを現代に蘇らせてみましょう。

多くのRailsアプリケーションには、日次の集計やデータ連携のような、決まった時刻に動くジョブがあります。こうした処理は、Solid QueueやSidekiqのような非同期ジョブを使えば手軽に始められます。しかし、業務システムが複雑になると、定期実行ジョブには単なるスケジューリング以上の要件が求められるようになります。 たとえば、同時実行の防止、長時間実行による突き抜け、失敗時の再実行、依存関係の制御、実行履歴の追跡、通知、可観測性などです。これらを扱うには、専用の実行管理基盤として進化させる必要があります。 また、こうした基盤をアプリケーションの外につくっても、ジョブが実行するドメインロジックはRailsアプリケーションの中にあります。そのため、Railsに書かれた処理を基盤からうまく呼び出す工夫が欠かせません。 この発表は、sidekiq-schedulerの定期実行ジョブを、AWS中心のクラウドネイティブな実行基盤へ移行した経験にもとづきます。発表者が定期実行ジョブ基盤をつくるのは、これで3回目です。Railsアプリケーションのための定期実行ジョブ基盤をどのように設計し、実装するかに焦点を当てます。どうやって既存のジョブを移行しやすくするか、どうやってアプリケーションエンジニアの認知的負荷を下げるか、どうやって運用しやすくするか、という観点から具体的に議論します。

Railsアプリケーションを動かすには、Railsやインフラの設定、アプリケーション固有の設定など、数多くの設定が必要です。その管理方法にも、環境変数、Credentials、YAML、DB、PaaSやIaaSの設定管理機能、各種gemなど、多くの選択肢があります。さらに、管理した設定値をアプリケーションからどのように参照するかにも、ENV、config.x、独自のクラスやメソッドなどの選択肢があります。これらをどのように組み合わせれば、開発者がアプリケーション開発に集中できるでしょうか。 設定の管理方法は、アプリケーション開発の初期には深く検討されないことも少なくありません。そして、問題に気づいてもリファクタリングされにくい領域です。設定の変更は障害につながる可能性があり変更の心理的ハードルが高いうえ、そもそも設定の管理方法をリファクタリングするという発想自体が生まれにくいからです。 この発表では、設定を「起点・中継点・終点」という流れと、秘密性や変更タイミングなどの性質から整理したうえで、「まとめる」「確認しやすい形にする」という2つの方針を軸に、Railsアプリケーションにおける設定の設計方法を説明します。発表を通じて、アプリケーションの規模や要件に応じて設定方法を選択し、設定に関する負債を溜めにくい設計を考えられるようになることを目指します。

世間に出回っている「webフレームワークベンチマーク対決」みたいなコンテンツを眺めていると、Ruby on Railsは他言語のプロダクトたちに比べてかなり遅い部類のフレームワークという位置付けにされていることに気づきます。やられ役ですね。かませ犬ですね。そんな立場に甘んじているのはRailsのマーケティング上よろしくありません。どうにかしたいですね。 そこで、本セッションでは、この手のベンチマークのスコアを、あらゆる手段を用いて改善してみます。要はRails本体をホゲるISUC○Nです。 レギュレーションは、Any%とします。すなわち、対象のベンチマークがそれっぽく完走しさえすれば過程は問わないという競技となっています。 本セッションを通じて、参加者の皆さまには、以下のようなものをお伝えできる予定です。

Solid Queue 1.0 was released on 26 Sept 2024 and added as the default Active Job backend in Rails. Two years later, we’re ready for version 2.0 in a totally different world. Let’s review the basics and explore the path to a new major version. We’ll go through new features such as single-process mode, batches or sharding, the non-linear path to them, and how maintaining an open-source project has changed since Solid Queue got started.