こんにちは、CTO の小宮です。

先日、RubyKaigi 2025 follow up というイベントが開催されました。このイベントに自分は登壇者として参加してきました。こちらが当日のスライドです。

最近の進捗

TypeGuard 関連

スライドにも書きましたが、RubyKaigi 2025 のトーク で今後の課題とした User-defined Type Guard については進捗がありませんでした。

rbs_rails のメンテナンスに時間を割いていたこともあり、まったく手を付けずじまいでした (あと、生成 AI で遊ぶのにも時間を取られていました)。期待している方には申し訳ないです。

rbs_rails

一方、rbs_rails についてはかなり改善ができました。12月にメンテナになったもののまったく活動できていなかったこともあり、RubyKaigi 後はこちらをメインに活動していました。

ある程度修正が溜まってきたこともあり、現在 次のリリースを提案しています 。
提案の際に改修内容をまとめていたのですが、結構な量の修正を行いました。

• Rails8 への対応
• Rails7 スタイルの Enum への対応
• Steep の resolve-type-names ヘッダのサポート (起動高速化)
• Path ヘルパーの型をデフォルトで有効化
• HABTM (has_and_belongs_to_many) のサポート
• 新しい ActiveRecord のメソッド群の型生成
• コマンドラインインターフェース (rbs_rails command) の追加

しばらく開発が停滞していたため、実プロジェクトで使いづらい部分があったのですが、これで導入しやすくなるはずです。これらの変更はもう少しでリリースできると思います。もう少しだけお待ち下さい。

RubyKaigi が一段落して、メンテナとしての活動時間が確保できるようになったこともあり、今後も改善を進めていくつもりです。要望やバグレポートは遠慮なく送ってもらえると助かります。

rbs_rails LSP サーバ

少し前に GitHub Actions を使って RBS ファイルの更新を自動化する という記事で紹介したように、社内のあるチームでは CI による型抽出を自動化しています。自動化によって、開発者は型抽出を意識せず、型の恩恵を自然に受けられるようになっています。

当時は、一連の自動化により ゆるやかな型の導入 が完成したのではないかと考えていたのですが、こうして記事にまとめてみると「型生成ツールの実行コストの高さ」を解消するともう一歩先に進めることに気づきました。

先程の記事でも、実行コストについて以下のように説明しています。

一方、rbs_rails やその他の型抽出ツールはもう少しやっかいです。

これらの型抽出ツールは 1回の実行に数十秒〜数分かかるものが多く、コードを編集するたびに実行するには高コストです。
実装が一段落し、PR を作成する直前に都度実行すればよいのですが、実行しわすれてコードと型が一致しない状態になりがちです。

たしかに、GitHub Actions を使って RBS ファイルの更新を自動化する のワークフローでは、自動生成により開発者は型抽出を意識せずに済みます。

一方、GitHub Actions が実行された後、次に git pull をするまでその恩恵が得られないという、遅延も大きいものでした。型の恩恵は得られるものの、即時性が薄いのが少しもどかしいです。TypeScript などと比べると便利さがひとつ落ちてしまいます。

理想としては、ソースを更新するたびにオンデマンドで型定義が生成され、即座にフィードバックを受けたいですよね。自動化というアプローチは悪くないのですが、生成コストが重いという問題を改善しない限り、理想形には近づけません。ここを改善できると体験が大きく変わるはずです。

そこで、試しに開発してみたのが rbs_rails LSP サーバです。

型抽出ツールの実行コストの大部分は起動コストやアプリケーションの読み込みコストに起因しています。ですから、常駐型のサーバとしてあらかじめアプリケーションをロードしておけば、型抽出が高速化するという目論見です。

実際に動作させてみたのが以下の動画です。

ファイルを変更すると、ほぼオンタイムで型定義が更新されていることがわかります。動作確認ついでにしばらく使ってみたのですが、体験は非常によいです。

まだできたてほやほやで rbs_rails にはマージされてはいません。興味がある方は PR をチェックアウトして試してみてください。

RubyKaigi 2025 follow up 参加レポート

さて、ここまでは自分のトークでしたが、少しだけイベントについても触れたいと思います。

このイベントは RubyKaigi の各種トークのその後の話を聞けるというイベントなので、RubyKaigi 本編と同じく分野はさまざまです。パーサーに文字コード、処理系や型などさまざまな方面のトークがありました。

トークを聞いていて実感したのは、Ruby は進捗を続けているということです。これらの改善がつぎの Ruby のリリースや来年の RubyKaigi につながっていくのだと思うとワクワクしますね。年末の Ruby 4.0 (仮) や来年の函館が今から楽しみです。

おそらく、こうしたコミュニティ全体の活動が角谷さんのおっしゃる「362日の Rubyist」だとも感じました。

「RubyKaigi」ですごい発表をしている人たちの成果は、イベント以外の362日の間の取り組みがあってこそなんですよ。

RubyKaigi の発表は中間地点でしかなく、ハックはずっと続いているわけですね。かく言う自分も (Type Guard は進んでいないとはいえ) rbs_rails の改善に精を出していたわけですしね

次の RubyKaigi が開催される 2026/4/22 まであと 228日ですね (この原稿を書いているのは 9月6日)。

irb(main):001> Date.today
=> #<Date: 2025-09-06 ((2460925j,0s,0n),+0s,2299161j)>
irb(main):002> Date.new(2026, 4, 22) - Date.today
=> (228/1)

僕もいち Rubyist として、さらに 228日の Rubyist として活動していこうと思います。