• Home
• ブログ
• Kaigi on Rails 2026に参加しました

今回のブログ担当は石川です。 2026年10月16日・17日にベルサール渋谷ガーデンで開催された「Kaigi on Rails 2026」に参加しました。

Kaigi on Rails 2026 公式サイト

Kaigi on Railsは、Ruby on Railsを中心とした技術カンファレンスです。今回はRailsの便利な使い方だけでなく、プログラミングの楽しさやプログラマーの役割、OSSコミュニティのこれから、AIとの関わりなどについても考える機会になりました。

どのセッションも興味深かったのですが、その中から特に印象に残った話をいくつか紹介します。 セッション名や発表者は公式のタイムテーブルからも確認できます。

キーノート1：Where the tracks go next

発表者：David Heinemeier Hansson（DHH）さん

セッション情報

AIによって、これまで自分たちが身につけてきた技術や、コードを書くという行為そのものが大きく変わりつつある。そうした変化に対する期待だけでなく、戸惑いや喪失感にも触れられていました。

以前JANOG56でまつもとさんのAIコーディングに関する話を聞いたときにも、便利になる一方でプログラミングの楽しさはどうなるのだろう、と感じていました。今回もすぐに答えが出るわけではありませんでしたが、同じ変化に戸惑っているのは自分だけではないんだなと思いました。

また、AIによってコードを変更するコストが下がると、設計の前提も変わるかもしれないという話もありました。DRYなど、今まで当たり前と考えていた原則がこれからどのように変わっていくのか、まだ想像がつかない部分も多いです。今までのやり方を知っているからこそ、変化を試しながら考え続けていきたいです。

余談ですが、画面上に表示されるリアルタイム翻訳の精度にも驚きました。英語の発表でしたが、日本語の字幕を追うことで十分に内容を把握できてすごかったです。それと共に、レシーバーを使えば通訳の方によるリアルタイムの音声翻訳もありました。個人的にはそちらの方がスライドとのズレが小さく感じて全体を通してレシーバーも使用しました。

キーノート2：I Want Both

発表者：まつもとゆきひろ（matz）さん

セッション情報

AIがコードを書く時代にRubyを使うことについて話されました。

Rubyは人間が気持ちよくプログラムを書けるように設計された言語です。では、人間ではなくAIが書くようになったら、その良さは意味がなくなるのでしょうか。発表では、AIによる開発における言語ごとのコストや開発時間を比較した実験が紹介され、人間のための設計が、現在のAIにとっても扱いやすい可能性があるという話がありました。（発表内で触れられたとおり、最新のAIエージェントだと、その差も縮まってきているそうですが……）

また、Rubyの実行速度やメモリ消費についての取り組みとして、Spinelが紹介されていました。Spinelは、RubyのソースコードをC言語に変換し、ネイティブバイナリを生成するAOTコンパイラです。

これから開発の仕方が変わっても、Rubyを使って楽しいと感じる気持ちは持ち続けていたいです。

AIエージェントのデバッグ能力を向上させよう — AI時代にRailsが輝く理由

発表者：rira100000000さん

登壇資料

コードとテストだけで結果を確かめられる問題に比べて、実行時の状態に依存する問題はソースコードを読むだけでは原因を特定しづらくなります。そこで、Rubyのdebug gemのリモート接続をMCP経由でAIから使えるようにするdebug-mcpが紹介されていました。

人間がデバッグするときと同じように、AIも実行中の状態を確認できれば、推測だけで修正する場面を減らせそうです。Railsが持つ実行時の情報の取り出しやすさがAIと一緒に開発するときにも強みになるという視点が面白かったです。

AIにどう指示するかだけでなく、AIが自分で調べて確かめられる環境を用意することも大事なんだなと思いました。

Domain Modeling with Vanilla Rails: 「操作」から再考するRailsの設計論

発表者：Yuichi Goto（yasaichi）さん

登壇資料

Fat ModelというのはRailsで開発していると気になるテーマです。この発表では、ユースケースごとに必要な処理が一つのモデルに集まることで、モデルが肥大化していくと説明されていました。

例えばユーザー登録でも、メールアドレスによる登録とGoogleによる登録では必要な処理が異なります。それらをすべてUserモデルに置くのではなく、EmailSignUpやGoogleSignUpのように、業務上の操作を表すモデルとして分けるという考え方です。

操作の記録が不要ならActive Modelを使い、記録が必要ならActive Recordを使う例が示されていました。実装はそれぞれフォームオブジェクトやイベントエンティティと同じになりますが、どちらも「ドメインの操作」という共通の視点で捉えられるという説明でした。RailsのCRUDを中心とした構成を維持できる点も特徴です。

単にコードが長いから別のクラスに移すという話よりも、「この処理はどの操作のために必要なのか」と考えると、分け方がわかりやすく感じました。

現場と育てるRailsモデリング 〜Spreadsheetから始めたモデル設計〜

発表者：Emiko Ando（siroemk）さん

登壇資料

スプレッドシートにあるデータを見ただけでは、現場でどのように使われているかまではわからない。要望に合わせてカラムや機能を追加していくだけでは、スプレッドシートでやっていたことをそのまま作り直すことになってしまう、という話でした。

この事例では、最初からRailsアプリに移行するのではなく、まず校舎ごとに異なっていたシートを共通の項目で作り直し、レッスン情報の入力を自動化していました。実際に使ってもらう中で寄せられた要望から、情報を何に使うのか、どの期間の記録が必要なのかを把握していく過程が紹介されていました。

私も業務で表計算シートで管理されたものをシステム化したことがあります。そのときは新人だったのもあって、あまり実際の業務を理解しないままシステム化してしまいました。その後データ構造や実際の運用とのギャップに困る場面があり、実際の業務や操作を理解することの大切さを改めて感じました。AIに実装を手伝ってもらう場面が増えても、何を作りたいのか、どんなルールを表現する必要があるのかを整理する力は、引き続き磨いていきたいです。

作れる、でも消せるか？──安全に「枯らして消す」機能削除術

発表者：Miyuki Koshiba（chobishiba）さん

登壇資料

使われていないように見えるけれど、本当に消していいのかわからない機能。どうすれば呼び出せるのかもわからなくなったAPIをどう消していくのかという話でした。

発表では、実際に機能を削除された際の事例を元に、段階を踏んで機能を使われない状態にし、確認しながら削除していく考え方が紹介されていました。まずデータがない状態でも動くようにし、新規利用を止め、残っている利用を終了させ、入口を閉じるという手順です。古いバージョンのアプリからはAPIが呼ばれ続けることも考慮する必要がありました。

どのバージョンになったら削除できるのかをコメントに残すことや、コード上の依存関係だけでなく機能の名前でも検索することなど、実際に削除を進めるときに意識したい話がありました。

私も、機能の呼び出し元を削除しても、内部の処理はほかへの影響が怖くて残してしまうことがあります。しばらく経ってから思い出したように削除することもあるので、安全に削除できる条件を整理し、段階的に進めたいと思いました。

How to Design Configuration for Rails Applications

発表者：Shinichi Maeshima（willnet）さん

登壇資料

環境変数、credentials、YAML、データベースなど、設定の置き場所をどう選ぶかという話がありました。秘密の値かどうかや、誰がどのタイミングで変更するかによっても、適した管理方法は変わります。

設定の持ち方はいろいろありますが、種類が増えるほど、どこを確認すればよいのかわかりづらくなります。また、必要な値が入っていない、形式が間違っているといった問題は、できるだけ早い段階で気づけるようにしたい。

設定もアプリケーションコードの一部として可読性やバリデーションを考えるというお話もあり、設定のバリデーションは考えたことがなかったけど確かに良さそうだと思いました。機能の実装に比べると後回しにしがちな部分ですが、日々の開発や運用のしやすさにつながるところなので、見直すきっかけにしたいです。

Browser Spec: HotwireをRubyでテストする

発表者：高橋征義（takahashim）さん

登壇資料

実ブラウザを使わずにJavaScriptを含むRailsアプリケーションをテストする取り組みの発表でした。

RubyによるDOM実装のDommyと、JavaScriptを実行するためのQuickJSを組み合わせ、Railsアプリケーションと同じRubyプロセス内でテストを動かす構成です。レイアウトの描画は対象にせず、DOMの論理的な関係を扱います。実ブラウザとの通信が不要になる一方で、実装したDOMなどの振る舞いが正しいかを確かめる必要があります。そのための「テストオラクル」、つまり正しいかどうかを判断する基準の重要性も話されていました。

また、セッションの最後の方に触れられたAI時代のOSSとの関わり方についても考えさせられました。

AIを使えば、既存のOSSに手を入れたり、自分に必要な機能だけを実装したりすることが、以前よりやりやすくなります。一方で、自分の手元だけで問題を解決できるようになると、修正を本体に提案したり、ほかの開発者と相談したりする機会が減ってしまうのでは、という話がありました。

OSSのコードは残っても、それを一緒に育てるコミュニティはどうなるのだろう。便利になることを喜ぶだけでは済まない、悩ましい話だなと思いました。

一方で、ZippというJavaScriptエンジンに不具合を報告したところ、18件ほどが1日で修正されたという経験も紹介されていました。AIによってOSSのコミュニケーションが変わるとしても、悲観的な話だけではないという点も印象に残りました。

私は普段Redmineの改善に関わっていますが、パッチを送った先で意見をもらったり、別の考え方を知ったりすることも、その活動の大切な部分です。これからOSSコミュニティがどのように変わっていくのかはわかりませんが、手元で直せることが増えても、そこで得られたものを共有したり、人と相談したりする機会は大切にしていきたいと思いました。

Solid Queue: two years on Rails

発表者：Rosa Gutierrez（rosa）さん

登壇資料

Solid Queueのこれまでの開発を振り返りながら、ジョブの実行方式の変化や、今後追加する機能について紹介する発表でした。

そのなかで、バッチ機能の開発経緯も紹介されていました。複数のジョブをまとめて管理し、すべて完了したときや、途中で失敗したときに処理を行うための機能です。APIの設計を何度も見直し、Rails側の関連する変更がマージされるまでに2年半以上かかったそうです。機能を実装するだけでなく、どういう使い方を提供するかを決めることにも時間がかかるのだなと感じました。

こうした開発の話とあわせて、AIの生成物をブラックボックスとして扱わず、理解することが大切だという話も心に残りました。コードを書く環境が大きく変わっても、設計の判断や、実際にリリースして保守することの重要性は変わらないという話でした。理解できないシステムを保守していくのは難しい。作ることが簡単になっても、使い続けていくために、コードや仕組みを理解することは大切にしたいです。

感想

今回のKaigi on Railsでは、AIによって開発が速くなることへの期待と、その変化の中で何を大切にしていくかという話の両方を聞けたのがよかったです。

実際に動きを確かめること、業務を理解すること、作ったものを理解して保守すること、人と話しながら改善すること。今回の発表を聞いて、普段の開発で大事にしたいことを改めて考えることができました。変化に戸惑うこともありますが、まずはいろいろ試しながら、これからも開発を楽しんでいきたいです。

登壇者、運営、スポンサーの皆様、ありがとうございました！

会場が渋谷だったので、道玄坂を何度も歩きました。「The 都会！」という感じで、街を歩くのも楽しかったです。

---