RubyKaigi2026 in 函館 参加レポート

はじめに

ITD2-2-3のI.Hです。今回、RubyKaigi 2026 in 函館に参加する機会をいただきました。

RubyKaigiは、Ruby本体やエコシステムに関する最新の知見が集まる技術カンファレンスです。
今回の参加を通して、Rubyそのものについて学べたのはもちろん、他社エンジニアとの交流やスポンサーイベントでのLT登壇など、普段の業務だけでは得られない多くの経験をすることができました。

この記事では、Rubyに関する知見の共有だけでなく、技術イベントに参加すること自体の意味や価値についてもあわせてまとめました。

Day0(イベント前日)

函館に前日入り

場所が北海道の函館と言うことで、当日出発では間に合わないため前日の夜に出発しました。
空港に到着すると、空港の至る所にRubyKaigiの看板や垂れ幕がありました。

また、路面電車の車内外にもRubyKaigiの看板が。町おこしさながらの盛り上がりでした。

空港で明らかにrubyistの方（第一rubyist）を見かけたので、タクシーに相乗りしました。
有名なラーメン屋さんで降りるとのことだったので、一緒に食べながら技術の話やお互いの会社の制度・AIツールの導入状況などに花を咲かせました。

Day1

会場へ

会場は、JR函館駅から市電で30分ほどの場所にある「函館サーモン・まるなまアリーナ/ホール」でした。命名権を地元の水産会社が取得されたらしく、函館感全開の良い会場名とロゴになってました。

チェックインすると、首から掛けるストラップと名札をいただきました。
会場で「どこの会社の方ですか？」と度々聞かれるので弊社のロゴを手書き。
なんとか伝わりました。

基調講演 The Journey of Box Building

発表資料はこちら
初日の講演は、rubyコミッターでもある田籠 聡さんの基調講演から始まりました。
内容は、2025年12月25日にリリースされた Ruby4.0.0 の新機能の一つである、Ruby::Box についてでした。

Ruby Boxはクラス等の定義の分離／隔離のための機能を提供する、実験的機能です。

実験的な機能として位置付けられているとのことでしたが、安全にコードの分離ができるようになる点は業務にも活かせそうでした。

Exploring RuboCop with MCP

発表資料はこちら
Keynote以外の公演は基本的に大ホール・小ホール・サブアリーナで行われ、同時刻に開催される講演に同時に参加することはできないため、タイムスケジュールと発表内容を見て選ぶ形式でした。
英語での講演も多く、同時翻訳アプリで聴くことにも挑戦しましたが、やはり日本語の講演の方が理解しやすく、自然と日本語の講演を選ぶことが多かったです。

そんな中で、初日の午後に参加した伊藤浩一さんのRuboCop x MCPの話が印象に残りました。

RuboCopは人間や他のプログラムによってトリガーされていました。AI時代においては、AIエージェントが新たなトリガーとして登場しました。本講演では、生成型AIとリンターおよびフォーマッターを組み合わせる実践的な方法について議論します。

決定性がLinterとしての価値だった中で、非決定性を持つLLMを組み合わせることでどんな価値が創出できるのか（又は失われるのか）という試行錯誤の話が面白く、こういったイベントに参加して直接コミッターの方のお話を聞く醍醐味だと感じました。

Day2

基調講演 Twenty Years of JRuby

2日目は20年以上JRuby（Java仮想マシン上で動作するRubyの処理系）を開発している、Charles Nutterさんの基調講演から始まりました。
内容はJRuby が誕生してからの20周年の振り返りと、JRuby 10.1 のリリースについてでした。
業務を含めこれまでCRuby（C言語で実装されたRubyの処理系）しか触ったことがなかったのですが、JRubyやMRubyのような別の処理系にも興味が湧きました。

Practical TypeProf: Lessons from Analyzing Optcarrot

発表資料はこちら
2日目はTypeProf開発者の遠藤侑介さんの講演が印象に残りました。

メインの話は、TypeProfを実際に適用してみた事例です。題材に選ばれたのは、発表者自身が開発したRubyで書かれたNES（ファミコン）のエミュレータで、約6000 行の複雑なコードに TypeProf を適用したところ600個以上のエラーが出たとのことです。

対応としては、型推論結果に強く影響する箇所にRBSを書くことと、TypeProf 側の誤認識の根本原因を直すことの2方向から進められ、最終的には Ruby 55行＋RBS 67行、合計122行の変更でゼロエラーに到達したとのことでした。SteepやSorbetと比べても、既存コードへの変更量がかなり少ないという結果でした。

終盤では、AI コーディングエージェントが普及する中でTypeProfをどう位置づけるのか、という問いも提示されていました。エディタ支援を主目的としてきたツールが、AI 時代にどんな価値を持てるのかという点についても言及されていました。

Day2の交流会

2日目の夜は、Drink Upに参加し、LT枠が空いていたので発表しました。

3日目のRubyKaigiがより面白く聞けるようにと思い、Rubyが実行されるプロセスをParserの話からGCの話まで、一通りまとめてみました。

資料はmarp + Opus4.6で作成

Day3

Lightning-Fast Method Calls with Ruby 4.1 ZJIT

発表資料はこちら
RubyKaigi最終日は、国分崇志さんのZJITの講演が印象に残りました。
注目度の高い ZJIT ですが、今回の発表では特にメソッド呼び出しの高速化に焦点が当てられていました。

Rubyでは依然としてメソッド呼び出しのオーバーヘッドが大きく（動的型付けだから仕方ないが）、YJIT によって改善が進んできた現在でも、なお大きなボトルネックとして残っているそうです。ZJIT ではこの処理の最適化が大きなテーマになっており、バックトレースや例外処理、ローカル変数アクセスに必要なメタデータをどう保持しつつ、無駄なメモリライトを減らすかが論点になっていました。

そこで紹介されていたのがLightweight Framesでした。これは、メソッド呼び出し時に必要なフレーム情報を最初からすべてメモリに書き込むのではなく、必要になるまで遅延させ、まずは最小限の情報だけを持つことでコストを下げるアプローチです。

Rubyの柔軟な書き心地は維持しつつ、高速に動くようにしていく取り組みをしていただいてる事に感謝です

Matz Keynote

もちろん最後は、Rubyを作った「まつもと ゆきひろ」さん（Matz）の基調講演でした。

ここ半年くらいは自分でコードを書かずに、ほぼ全てAIに書かせるという縛りを自らに課しているとのことでした。コードレビューやプロンプトを細かく制御できるからこそできる事だと思いますが、実務の現場でもAIエージェントは欠かせない存在になってきているのではないでしょうか。

そんな中で大きなトピックは、新しいRubyのAOTコンパイラ「Spinel」の発表です。RubyコードをC言語に変換してからコンパイルすることで、ネイティブバイナリを生成するという試みで、すぐに業務レベルで役立てられるものではなさそうですが、インタプリタ言語×AOTコンパイルという発想と開発過程が興味深かったです。（Rubyは動的機能が多いので、機械語にできる=高速化ではないことに注意してください）

まとめ

RubyKaigiに行って良かったと思う1番のポイントは、Rubyやプログラミングが大好きな人達の「熱」を感じられたことでした。普段「仕事」としてプログラミングをしていると商業的な観点で価値を測り測かられる癖がついてしまって、楽しいとか知的探求という側面を忘れていたなぁと思いました。

また、現地での他社のエンジニアとの交流も刺激的でした。今まで自分がマイナビ色に染まっている自覚はありませんでしたが、他社のエンジニアと交流すると明らかに各社個性というか雰囲気があって、たまには視野を広げるためにも交流して新しい知見を持ち帰ってくる必要があると感じました。