RubyKaigi 2026 参加レポート — Day 2 - Link and Motivation Developers' Blog

はじめに

リンクアンドモチベーションでエンジニアをしている代慶です。普段は新規プロダクトの開発に携わっています。
昨日から開催されているRubyKaigi 2026の2日目のレポートをお届けします！
1日目のレポートはこちらから
https://link-and-motivation.hatenablog.com/entry/2026/04/22/183310

RubyKaigi 2026は北海道・函館で開催されています。

RubyKaigiに行く前に

今朝、とてもいい天気だったので、五稜郭に行ってきました。一生分の桜を見た気がします、とても綺麗でした。

五稜郭の桜

Day 2 タイムテーブル

2日目のタイムテーブルはこちらから確認できます。 https://rubykaigi.org/2026/schedule/day2/

講演レポート

1. [Keynote] Twenty Years of JRuby — Charles Nutter (@headius)

スピーカー

Charles Oliver Nutter氏。JRubyプロジェクトの共同リードを20年間務めている方です。

概要

2004年、参加者65人のRubyConfでRubyに出会い、そこから20年JRubyを開発し続けてきた歴史が語られました。Sun Microsystemsでのフルタイム開発、Ruby初のJITコンパイラ(2008年)、JVM史上初の新バイトコード invokedynamic(2011年) の追加など、JRubyのためにJVMそのものを変えてきた話です。

並列性能の比較として、JSONパースのベンチマークが示されました。CRuby Ractor (Ruby 4.0) が3.7x改善に対し、JRuby Threadは20コアサーバーで20x改善という結果が示されました。

感想

何よりも20年間、同じものを探究し続けるこだわりがすごいなと。本人もおっしゃっていましたが、Rubyへの愛がそれを可能にしているんだなと感じました。

JRubyは使ったことがないのですが、CRubyと比較したときの性能の高さも印象に残りました。特に並列時の性能差。JRubyにはCRubyのGVL（Global VM Lock）がなく、全スレッドが真に並列実行されるため、コア数に応じてリニアにスケールするとのこと。CRubyではRactorを使ってもまだボトルネックがある中、JRubyは既存のRubyコードをそのままスレッドで並列実行できるというのは大きな強みだなと思いました。

2. No Types Needed, Just Callable Method Check — Daichi Kamiyama (@dak2)

スピーカー

Daichi Kamiyama氏。Timee Inc.のプロダクトエンジニアで、型あり(Sorbet)/型なし両方のRubyプロジェクトを経験されています。今回紹介されたMethod-Ray gemの作者で、RubyKaigi初登壇です。

概要

"In the age of AI, maybe we only need to check that a method is callable. At least in Ruby."

Timee社での「Sorbetは投資に見合っているか？」という議論がきっかけで、AI生成Rubyの品質が向上した今、型の恩恵の大半は NoMethodError の防止 に帰着するのではないか、という問題提起でした。

また、型注釈はあくまで人間の読みやすさに最適化されたもので、AIに最適化されたものではないという話もありました。契約としての型は依然として必要だが、guardrailはフル型システムでなくてよいという切り分けが示されました。

この思想で作られたのが Method-Ray gem。「メソッドが呼び出し可能か」だけをRust実装で高速にチェックする、型注釈不要のアプローチです。

感想

AI時代に型が必要なのか？という点に関して、自分の中ではまだ答えはありませんが、個人的には型をつけることでAIもよりコードの理解を解釈しやすくなり、品質の高いコードを書けるのではと思い込んでいたので、そもそも型って、AIではなく人に最適化されたものだよねという話は、確かにと思いました。

登壇スライド

https://speakerdeck.com/dak2/no-types-needed-just-callable-method-check

3. Chasing Real-Time Observability for CRuby — Shintaro Otsuka (@White_Green2525)

スピーカー

Shintaro Otsuka氏。STORES, Inc.のソフトウェアエンジニアの方。

概要

CRubyの全メソッド呼び出し・GC・スレッドをリアルタイムに3D可視化するツール rrtrace の紹介です。

既存のプロファイラーは統計情報を返すもので、リアルタイムではない。そこで「CRubyにはGVLがあるので同時に使われるのは基本1コア。16コアあったら残りの15コアは観測に自由に使える」という逆転の発想から、CRuby C拡張でイベントをキャプチャし、共有メモリリングバッファ経由で別プロセスのRust製ビジュアライザに送り、GPU(wgpu)で3D描画する仕組みです。

ライブデモでは、Rails consoleでfibonacci(30)を実行したときのスタックの積み上がりや、Railsアプリへのリクエスト処理の様子がリアルタイムに3D空間（時間×スレッド×コールスタック）で可視化されていました。

感想

自分自身も、プロファイラーを使って性能改善をしたことが何回かあり、使うたびに、コードを修正して、プロファイラーを使って分析を行うのを繰り返してイライラしていたことがあったので、リアルタイムでの分析はいいなと思いました。また、実装に使ってるコア以外も何か使えないかという思考は他のところにも活かせそうだと思いました。

4. From Formal Specification to Property Based Test — Masato Ohba (@ohbarye)

スピーカー

Masato Ohba氏。SmartBank, Inc.で銀行システムやカード決済システムを担当されているRubyist。RubyKaigi 3年連続登壇の方。

概要

講演の全体像として、形式仕様（Formal Specification）・Property-Based Testing（PBT）・実装の3つがあり、形式仕様からPBTへの変換が欠けているピースだという話でした。PBTをAIが非決定論的に生成しても信頼できない。だから人間が形式仕様を書き、そこから決定論的にPBTを生成するのがあるべき姿だと。このミッシングピースを埋めるために作られたのが spec-to-pbt gemです。

PBTは従来のテスト(Example-Based)と違い、「このプログラムはこういう性質です」と記述してランダムな入力で大量検証する手法です。失敗時にはshrinkingでバグを再現する最小反例を自動で見つけてくれます。

spec-to-pbtはAlloy形式仕様からStateful PBTコードを自動生成する仕組みで、デモではStackクラスにLIFO/FIFOのバグを仕込み、生成されたテストが「push(0), push(-1), pop」のわずか3操作でバグを検出する様子が示されました。

感想

自分もAIを前提にした開発プロセスでいかに品質とスピードを両立できるかということを考えていますが、まさにコードの品質を守るテスト生成において、AIの非決定性は考えるべきところだと思ったので、ためになりました。Property-Based Testingは今回初めて知りましたが、Example-Based Testingよりも本質的なテストができそうだと思う一方で、不要なテストとかたくさん増やしてしまわないかなど気になるところはあったので、実際に試して理解を深めたいと思います。