はじめに
2026年4月22日から24日まで、函館で開催された RubyKaigi 2026 に、ピクシブ株式会社（Pixiv）の学生スカラシップ で参加させていただきました。
はじめまして、角鹿翔和（@t0waxx）です。北海道科学大学で情報工学を学びながら、エンジニアとして活動しています。
現在は視覚情報メディアシステム研究室に所属し、画像・映像処理やメディアシステムに関心を持っています。
普段の自分は、どちらかというと Ruby がメインの言語ではありません。インターンや個人開発では TypeScript や Python を触る時間のほうが長く、Ruby は「Rails のコードベースを読みに行く」「bundle install を打って動かす」「たまに gem の中身を覗く」ぐらいの距離感で付き合っている、というのが正直なところです。それでも Ruby という言語自体は素直に好きで、書いていて気持ちのいい瞬間や、コードが「読み物」として成立する感じが、自分の中の言語観の基準点のひとつになっています。
そのうえで RubyKaigi に来たのは、ここが 言語処理系そのもののカンファレンス だからです。コンパイラ・VM・JIT・組み込み（mruby / PicoRuby）といったテーマは、自分の主言語が何であれ追いかけたい領域で、RubyKaigi はそれが本人たちの口から、3日連続で聞ける ほぼ唯一の場です。だからこそ「言語の中身を作っている人たち」が集まる場に飛び込むのは、少し緊張しました。
正直に書いておくと、聞いたセッションの全部を完全に理解できたわけではありません。VM の制御フレームの話、JIT のレジスタ割り付け、Ractor のメモリ整合の話など、その場では「分かったような気がする」けれど、後でメモを開くと自分の言葉で説明できない部分が普通にありました。本記事はそれを誤魔化さずに、自分が今この瞬間に噛み砕けた範囲で書く ことを優先しています。なので、登壇者の意図と少しずれている表現があれば、そっと教えてください。
旅程：前日入り → Day 1, Day 2 フル参加 → Day 3 だけ不参加
会期は3日間。私の動き方はこんな感じでした。
- 4/21（前日入り）：北海道内から函館へ移動。スカラシップ組の学生たちと合流し、夜はピクシブさんの皆さんと夕食。詳細は次の節で書きます。
- 4/22（Day 1）：朝イチのドアオープンから、最後のLightning Talksまでフル参加。
- 4/23（Day 2）：Day 2 もフルで聴講。終わってからは STORES 株式会社さんのSTORES CAFE at RubyKaigi 2026 に参加しました。
- 4/24（Day 3）：別件の予定が入っており、残念ながら現地には居られず。X のタイムラインを横目に「Day 3 の Matz Keynote と Ruby Committers and the World は後日のアーカイブ or スライドで追う」と心に決めました。
このレポートは、自分が その場で実際に座って聴いた Day 1・Day 2 のセッション を中心に書いていきます。Day 3 のキーノート群は、参加者の皆さんの感想を読みながら別途追っているので、本文では深く触れません。
前日入り：試される大地北海道、桜の函館、そしてうに丼
到着前から軽く修羅でした。
道内の空港から函館へ向かう便が、当日まさかの ほぼ全便遅延。試される大地・北海道 の本領発揮で、空港のモニターに並ぶ「DELAYED」の文字を見ながら、「これ今日中に函館に着くのか？」と本気で焦っていました。それでも、同じくスカラシップで参加する学生たちと SNS でぽつぽつ連絡を取りながら、なんとか合流地点までこぎつけて、奇跡的に学生組で集合 することができました。集まった瞬間に「全員ちゃんと生きている」ことを確認し合うところから始まったの、もうこれだけで前夜祭感がありました。
そこから函館へはバス移動。窓の外には、ちょうど見頃の 桜と、函館の港町の景色 が次々と流れていきます。北海道で、4月下旬にこの密度の桜を見られたのは完全にボーナスでした。長旅で頭がぼーっとしている状態に、「桜 × 函館 × 海」 という反則みたいな組み合わせが流し込まれて、「あ、いま自分はちゃんと旅をしているな」と急に実感が立ち上がりました！
ホテルに荷物を置いて、いざ夕方。ここからが本番です。
うに丼 を、いただきました。
ピクシブさん本当にありがとう...！
学生スカラシップで旅費や参加費を支援していただいているうえに、現地での食事までここまで手厚くサポートしていただけるとは思っておらず、かなり驚きました。
その後、夜の本番でピクシブさんの社員の方々との 食事会 にお邪魔させていただきました。テーブルの上に、たくさんの海鮮（最高） が並びます。うに、いくら、ホタテ、いか、白身、刺身盛り……北海道に住んでいる自分でも普段ここまでの密度で食べる機会はなく、「もう言い残すことはあるまい」とぼやきたくなるレベルで充足していました。
そして食事の場の良さは、料理だけではありませんでした！なんといっても交流できてよかったです。
- 雰囲気が すごく和やかで、学生にも普通に話を振ってくれる 場でした！
- 自分の所属コミュニティや所属研究室の話をしていたら、業界が近くて共通の知人が次々に発覚 したりもしました！
- いつも使ってるサービスすくってるひとだなと感じながら話せるのはいい機会でした。
そして帰り際、集合写真を撮るタイミングで、生け簀のカニを見た社員さんが「ダラララララ……カニ🦀！！！」と、カニをビビらせていたのも忘れられません。
『超かぐや姫！』に脳を焼かれている身としては、この光景だけで一生分の記憶になりました。(？)
RubyKaigi本体が始まる前夜の食卓で、すでに「縁」が動き始めている。学生として参加していると、こういう場で得られる横の繋がりは、後から振り返ると本セッションと同じくらいの重みを持っていたりします。
ピクシブさんへ改めて。前日のうに丼から食事会、そしてRubyKaigi本体への送り出しまで、本当にありがとうございました。Day 1 の朝、会場に向かう足取りが軽かったのは、間違いなく前夜のおかげです。
Day 1：オープニングからすでに「函館の RubyKaigi」だった
ピクシブさんの法被を着て参戦しました！
Door Open とスポンサー LT — 「4万歩のフィールドワーク」
会場がオープンしてすぐの時間帯は、技術セッションではなく、スポンサー各社による短い LT から始まりました。
ここで印象的だったのは、単なる企業紹介ではなく、「なぜこの会社が RubyKaigi に来ているのか」 が、それぞれの言葉で語られていたことです。
RubyKaigi 2026 のメインビジュアルを手掛けたGaji-Laboさんのデザインスポンサー LT。函館を実際に2日間・約4万歩歩いて視察し、ローカルオーガナイザーと話しながらビジュアルを作り上げたという話で、「数年後にも『函館の RubyKaigi、楽しかったよね』と思い出してもらえる体験を作る」という言葉が記憶に残りました。
The Journey of Box Building（Satoshi Tagomoriさん / Day 1 オープニングキーノート）
Day 1 のオープニングキーノートは、Ruby 4.0 に 実験的機能 として入った RubyBox（旧称 Namespace）の設計と実装を、開発者本人が自分のモチベーションごと語る回でした。
RubyBox は、簡単に言えば「プロセスを分けずにライブラリやモンキーパッチの影響範囲を区切る仕組み」です。Ruby はトップレベルが世界全体に直結していて、誰かが String#+ を書き換えると、プロセス内のすべての String#+ が影響を受ける。これがモンキーパッチの強さでもあり、テストやマルチテナントで地獄を生む種でもあります。RubyBox は、その「世界」を箱（Box）単位で切り分けるための足場になるものだと理解しました。
技術的な話は、率直に言って自分の手にはまだ余りましたが、rb_control_frame_t への Box 情報の埋め込み、specval の再利用、BOX_REQUIRE のローディング中フラグ管理あたりは、Ruby VM の構造を頭の中で動かせる人にしかリアルに浮かばないと思います。私が掴めたのは「Ruby の実行を進めながら、いま自分はどの Box の中にいるかを VM が常に知っている必要がある」という設計判断の重さで、これは「機能を一個足す」レベルの話ではなく、実行モデル側を直すほどの覚悟が必要な変更だった ということでした。
そして、後半が個人的にいちばん刺さりました。Tagomori さんは「自分が何を欲しがっているか分かったのは、2023年の RubyKaigi で塩山さんの『マルチバース Ruby』トークを聴いた瞬間だった」と話していました。自分のニーズは自分で言語化できているとは限らず、他人のトークが背中をどついて初めて輪郭になる ことがある。OSS への貢献動機の話としても、「とりあえず人の発表を聴け」という雑な格言の根拠としても、強い実例だと感じました。
Tour of Ruby Box ≒ Tour of (a part of) Ruby VM.
このパンチラインがそのまま今回のキーノート全体を表していたと思います。
When Can You Skip a Test? Tracking Test Impact（Andrey Marchenkoさん / Datadog）
ここも、自分の手元のRailsアプリにすぐ持って帰れそうなテーマになりました。Test Impact Analysis（TIA）、つまり「この変更で本当に走らせる必要があるテストだけを選んで実行する」ためのエンジンを、Ruby向けに作った話。
冒頭の問題提起がそのまま自分事でした。テストスイートが大きくなると、CIが遅くなる。素直に全件回せばいいけど、お金と時間がきつくなる。だから「変更行に関係するテストだけ走らせよう」と考える。やるだけならスクリプトでも書ける、と思いがちです。
このセッションが面白かったのは、「やるだけなら簡単、正しくやるのは滅茶苦茶むずい」 ということが具体的に分解されていく過程でした。Ruby 標準の Coverage モジュールで作ろうとすると、per-test 用途に作られていないので速度が4倍遅くなる。じゃあ TracePoint を使えばいいかと思うと、正規表現バリデーション（validates :email, format: { with: /…/ }）のような C 拡張内のコードでは line event が発火しない。SimpleCov 的にはカバレッジ100%なのに TIA から見るとカバレッジ0%、という気持ち悪い裂け目が現れる。
ここで「あー、自分が雑に作ったらこの落とし穴に普通に落ちるな...」と感じる部分が多くありました。最終的に登壇者は、C拡張で内部イベントAPIを叩く + ISEQ ポインタ比較で「同じファイルの実行を続けているか」を高速判定する + Bytecode（RubyVM::InstructionSequence）の静的解析で定数参照を補う という三段構えで実用化していて、本番では 年15万時間以上のCI時間削減 を達成しているとのことでした。
AI 自体は deterministic ではありませんが、開発者ツールは deterministic であるべきです
この一言が、TIA という機能の輪郭をきれいに切り取っていました。スピードよりも先に「予測可能」が乗る。テストを「速くスキップする」より「どのテストを安全にスキップしたかを毎回同じ理由で説明できる」ほうが、結果として開発者から信頼される、という話です。AI コーディングがこれだけ普及しても、土台になる開発者ツールは「不確実性を持ち込まない」側にいる必要がある、という線引きは個人的に持ち帰りました。
PicoRuby as a Multi-VM Operating System（Katsuhiko Kageyamaさん）
午後のSmall Hallで、ESP32マイコン1枚の上で複数の PicoRuby VM を同時起動して、キーボードとディスプレイをつなぐだけで動く「Family mruby OS」 を実演する発表がありました。発表者の机の上には、コンポジット出力（黄色いRCA）の付いた 手作りの赤い基板 が置いてあります。
何が起きているかというと、
- ESP32 の 2コアのうち、片方のコアを描画専用、もう片方を mruby VM 専用 にする
- FreeRTOS のタスクとして 複数の mruby VM を独立に動かす（ウィンドウ1つ＝VM 1つ）
- VM 間のやり取りは MessagePack に乗せる
- 描画コマンドを愚直に送ると 300 cmd/秒しか出ないので、DSL 化して一気に投げる構造に変えたら 31,000 cmd/秒（だいたい100倍）まで伸びた
という構成です。説明だけ聞くと「マイコン芸かな」と思いそうですが、デモが本当にすごくて、BASIC・ファミコンエミュレータ・NSF音楽・DOOM風レンダラー・Flappy Bird風のゲームまで、その赤い基板1台の上で動いていました。
私は普段マイコンを触らないので、技術的な引き出しの中ではいちばん遠いトピックなのですが、「あえてマイコン上で Ruby を走らせる意味」 という問いの立て方が印象的でした。性能だけならスマホがあれば終わりです。でも、1つのチップの上に Ruby を乗せて、それを子供が触れるサイズの完結したコンピュータにする という発想は、Ruby の柔らかさ（とPicoRubyの軽さ）が前提になければ成立しません。
将来的に甥っ子にお年玉代わりに渡したい
このオチが面白く、技術発表として完成度が高いだけでなく、「自分がいま欲しいもの」を一直線に作っている人の話だ、という温度を会場に残していました。技術愛、Ruby愛が溢れててかっこよかったです。
Building a Standalone Ruby Programming Environment（Shunsuke Michiiさん / pixiv CTO）
Day 1 で個人的にいちばんテンション上って聴いたのは、ピクシブさんの CTO が登壇した、自作シングルボードコンピュータ「Halcom Board」 のセッションでした。
実は登壇前のお昼に少しお話しする機会があり、さらに先出しで基板や開発まわりの話まで見せてもらっていたので、セッションが始まる前からかなり楽しみにしていました。
距離感の近さは、RubyKaigi ならではだと思います。さっきまで普通に会話していた人が、数十分後には巨大スクリーンの前で、自作ハードウェアや実装について語っている。その切り替わりの速さも含めて、素晴らしい体験でした。
Halcom Board は、ざっくり言うと「HDMIとUSBキーボードをつなぐだけで起動して、その中で OS・IRB・日本語入力・プレゼンツールがすべて mruby スクリプトとして動く小さな基板」です。RP2350（Raspberry Pi Pico 2 と同じチップ）を使って、自作で約2,000円。
技術の核は、CPUを使わずに 640×480 の DVI 出力を作る ところでした。ここは一回でフル理解はできていないので、自分が掴めた範囲で書きます。
- RP2350 には HSTX というハードウェアシリアライザがあり、これと DMA を組み合わせると、CPU を介さずに DVI/TMDS 信号を吐き続けられる
- なので、片方のコア（Core1）は完全に「ピクセルを画面に流すだけ」の専用係に固定する
- もう片方のコア（Core0）は mruby VM 専用 にして、Ruby コードがリアルタイム描画に邪魔されずに走り続けられるようにする
ここまでで、「マイコンの上で Ruby が普通の言語みたいに振る舞うために、CPU の上ではなく CPU の隣で絵を作っている」ということが、なんとなく見えてきました。さらに、SRAM が DVI 転送と mruby ヒープで取り合いになって落ちる、という Bus Contention の問題に対しては、「mruby のヒープを PSRAM に逃がして、SRAM を完全に DVI 専用にする」 というメモリ分離で解決していました。「速いメモリは映像、遅いけど大きいメモリは言語」という割り当て方は、組み込みのお手本みたいな設計判断だと感じました。
そして圧巻だったのが、この発表自体を Halcom Board 1台だけで行っていた ことです。MacBook を出さない。スライドは IRB から me と打って自作のプレゼンツール「PicoRabbit」を起動して進める。「Ruby だけで全部できる」と言いながら、実際にその場で証明する という、メタにメッセージを乗せた構成でした。
繋げたらすぐ動く、OS 不要、キーボードとディスプレイだけで動く。そんな、最初のプログラミング体験になるものを目指しました
そして印象的だったのは、その話を会社の CTO 自身が壇上で語っていたことです。トップレイヤのエンジニア自身がコミュニティに深く関わっている。その距離感も含めて、かなり RubyKaigi らしいセッションだったと思います。「会社が学生を呼ぶ」だけではなく「会社のトップ層が壇上に立っている」 ことに、勝手に背筋が伸びました。
そしてなんと買える！
また、社員さんがうちわやペンライトをもって応援しており最高に面白かったです。
いつか稟議を承認しそうなうちわを持ってみたいな
Lightning Talks（11本連続）
Day 1 の最後は、Large Hall での 連続11本のライトニングトーク。短いのに濃度が高く、頭がショートしかけながらメモを取り続けました。全部はとても書ききれないので、自分の中に残ったものだけ書きます。
- Do Ruby::Box Dream of Modular Monolith（@joker1007）：Tagomori さんのキーノートで紹介された RubyBox を、Rails 上で実際に動かして、モジュラーモノリスの境界を引く デモ。LT 一本で「RubyBox って明日からどう使えるんだ？」のリアルな入口を見せてもらえました。
- Road to RubyKaigi: Play Hard(ware)（@makicamel）：Raspberry Pi Pico 2W でターミナル横スクロールアクションをコントロールするという、「LT が年々進化していくシリーズもの」 として記憶に刻まれた一本。
- Ruby on Bare Metal（@S-H-GAMELINKS）：mruby ではなく CRuby そのもの を自作カーネルの上で動かす話。「Ruby は OS の上で動くもの」という前提が削られていく感覚があり、PicoRuby とは別ベクトルで「Ruby の依存先」を露わにしていました。
- mruby-gpu（@yuji_teshima）：Raspberry Pi 5 の Vulkan Compute Shader に mruby から触る話。MNIST の学習が CPU-GPU 転送で詰まった、それをデータパイプライン側で直したらガッと速くなった、という 「ハードと会話するための最初の壁」 がリアルでした。
-
Class.new is all you need（@riseshia）：プロファイルしたら CPU の 14% が IR ノードのオブジェクト生成だった、ので素の
Classに置き換えたら劇的に速くなった、という 「設計ではなく実装の最下層が遅さの原因だった」 話。最適化の入口として教科書的。 - Your ruby.wasm Doesn't Work on Mobile. Here's Why.（@ryudoawaru）：MacBook では動くのに、iPhone と Android で順番にコケる、という 「現場でしか出ない3種類のバグ」 を10行以下で直す話。LTのフォーマットにいちばん向いている内容でした。
スライド：
- Do Ruby::Box dream of Modular Monolith?
- Road to RubyKaigi: Play Hard(ware)
- Ruby on Bare Metal
- mruby-gpu: The Joy of Talking to Hardware in Ruby
- Class.new is all you need
- Your ruby.wasm Doesn't Work on Mobile. Here's Why.
11本通して感じたのは、「Ruby を別の場所に置きにいく」発表が圧倒的に多い ことでした。マイコン、ベアメタル、GPU、ブラウザ、HTTP/2、モバイル。Ruby を「Web アプリの言語」に閉じ込めない動きが LT のレイヤから来ているのは、コミュニティの体力として頼もしいです。
Day 1 の最後は懇親会へ
セッションで登壇していた人が普通に隣でご飯を食べているし、さっきまで Large Hall で発表していた人と、そのまま continuation みたいに実装の話が始まる。
個人的には、「発表者」と「参加者」がかなり地続きだったのが印象的でした。
技術的な話をしていても、途中から急に
「函館どこ回りました？」
みたいな話になったりして、カンファレンスなのに妙に文化祭っぽい空気がある。
マグロの解体ショーが始まったり、
気づいたら CTO の方と実装やコミュニティの話で盛り上がっていたりと、
かなり濃い時間でした。
Day 2：JRuby の20年から、ドキュメントの未来まで
朝、バス移動の前にホテルを出たら、偶然知り合いの参加者の方とばったり遭遇。そのまま会場まで話しながら歩いたり、函館の景色を眺めたりして、かなり良い滑り出しでした。
バスの中ではなぜかずっとボルダリングの話をしていました。(たのしい)
Twenty Years of JRuby（Charles Nutterさん / Day 2 オープニングキーノート）
Day 2 のオープニングは、JRuby を 20年間ほぼ1人で作り続けてきた Charles Nutter さんの登壇でした。
正直、自分は JRuby を「名前だけ知っている処理系」のひとつとしてしか認識していませんでした。Java の上で動く、Logstash で使われている、ぐらいの粒度です。それがこのキーノートで、「処理系を1人で20年動かし続ける」とはどういうことか に一気に解像度が上がりました。
話は、2005年の「JRuby は IRB すらまともに動かなかった」状態から始まります。Rails が来た瞬間に「JVM × Rails で Java Enterprise の世界に新しい Web 開発を持ち込める」と確信した、という1点で開発の角度が変わったらしい。2006年の Minneapolis のコーヒーショップで初めて Rails のリクエストが通った瞬間（ただし開発モードのせいで10〜15秒かかった）、JavaOne 2006 で 1,800 人の前で発表した話、Sun Microsystems からのフルタイムオファー、そして Sun が買収されてオラクルに行き、自分はオラクルから離れて self-funded になった話まで、20年がそのままタイムラインで流れていきました。
技術的なハイライトはいくつもあったのですが、自分がいちばん「ほう」と声が出そうになったのは、「JRuby は CRuby より約8年早く opt_new 相当の最適化を入れていた」 というところでした。invokedynamic を使ってオブジェクト生成を最適化する、という話が 2016 年時点で動いていて、Ruby 4.0 で議論されている話の一部は JVM 側ではすでに通った道だった、ということです。JVM の最適化フレームワークが、言語実装に対してどれだけ効くか を一発で示す例だと思いました。
それと、Fiber の話。JRuby は長らく「OS スレッドを Fiber に見せかける」ことしかできず、数千 Fiber が限界でした。これが Java 21 の 仮想スレッド（Virtual Threads） で一気に数十万規模まで現実的になった、という10年越しの解決の話。ある言語実装の悩みが、土台のランタイム側のジャンプで解ける ことがあるんだ、というのが新鮮でした。
最後に、JRuby 10.1 をその場で 「今日初公開」 として発表し、オブジェクトサイズ32→24バイト、Project Lilliput でJVMオブジェクトヘッダ12→4バイト、Fixnum をパディングに埋めて数値ループを高速化、という話で締めました。CRuby（40バイト）を逆に下回る メモリ効率を、JVM 側の最適化を借りる形で達成しているのが面白かったです。
20年間この project に人生を使ってきました。なぜ続けるのか。理由はシンプルです。Ruby が好きだから
「現在の JRuby 開発者は実質1人で、self-funded」と本人が壇上で正直に語ったうえでこの一言。基調講演の場でスポンサーシップと CI マトリクスへの組み込みを静かに依頼する流れに、観客側も自然と背筋が伸びていました。世界で使われている OSS の維持コストを、誰がどう負担しているのか を直視させられる時間帯でした。
Uzumibi: Reinventing mruby for the Edges（Uchio KONDOさん）
エッジコンピューティング（Cloudflare Workers、Fastly Compute、Spin など）で 「Ruby を動かす」を本気でやる ための発表でした。
Uzumibi（うずみび）は、その上に乗っている Web フレームワークの名前で、ベースは mruby/edge という 純Rust 実装の mruby バイトコード互換 VM です。「mruby があるんだから、それを Wasm にすればよくない？」と素朴に思っていた自分の頭が、ここで一段階更新されました。
ポイントは2つあると感じました。
1つは、「自分が欲しい Ruby の部分だけを実装する」と決めた瞬間に、バイナリサイズが現実的になった こと。mruby/edge は mruby 3.4 命令の約 84% を実装していて、コンパイル後の非圧縮バイナリは約 300KB。Cloudflare Workers の 1MB 制限に対して余裕があります。Rust の feature flags で「使わないコードは入れない」を徹底した 結果でもあります。「全部入りの汎用 Ruby」ではなく、「エッジで動く Ruby が今欲しい人にだけ届く Ruby」を作る、という割り切りが小ささを生んでいる。
もう1つは、break や block return を内部的に exception の一族として実装している という話。これは VM の中身のディテールですが、「意味的に違って見える機能を、実装上は同じメカニズムで処理する」という設計が、コードベースを小さく保つコツだという例として記憶しました。自分の頭の中で「break と raise は別物」と並べていたので、ふたつをひと束にする発想が新鮮でした。
将来課題として共有されていたのが、「Wasm は JS の async function を import できない」問題 でした。現状は Asyncify で逃げているものの、そのぶんバイナリサイズが約1.5倍まで膨らんでしまうらしい。
なので最終的には、VM 自体をステートマシンとして作り直し、任意の命令地点で pause / resume できる構造にしたい とのこと
ここが個人的にかなり印象に残っていて、「一応動いている」状態からさらに先へ進むために、VM の前提そのものを組み替えようとしているのが、普通に途方もない話だと感じました。
「動いているから完成」ではなく、「動いているけど、将来やりたいことのためには設計ごと変える必要がある」という感覚が、言語実装の世界っぽくて良かったです。
private に欲しかった Ruby の部分だけを実装し、自分の ultimate pocket tool を作った
この自己定義が、Uzumibi を作る動機としていちばん腹落ちする一言でした。
スライド：Uzumibi: Reinventing mruby for the Edges
A Faster FFI（Aaron Pattersonさん）
タイトルは FFI（Foreign Function Interface）の話。中身は JIT コンパイラの話。本人もオチで「今日のトークは実は JIT の話でした」と回収していました。
冒頭、strlen のベンチマークで FFI が C extension の202分の1の速度しか出ない と示されたところで、会場がざわついていました。直感的には「FFI は薄いラッパなんだから、ほぼ C extension と同じ速さで動くはず」と思ってしまうところに、202倍というえげつない差が刺さる。
理由として説明されたのは、
- C extension は コンパイル時に引数の数・型・アンボクシング方法が確定する
- FFI はそれを すべてランタイムで決める
- そのうえ余分なフレームプッシュや動的な型変換が乗る
という構造でした。なるほど、と思います。FFI の遅さは「ネイティブ呼び出しの遅さ」ではなく「動的にネイティブ呼び出しを組み立てるコストの遅さ」だった、ということです。
この話の妙は、解決策が「FFI を捨てる」ではなく「FFI を JIT で速くする」 だった点にあります。Aaron さんは fjit という Pure Ruby 製の JIT コンパイラ を実装し、Ruby から実行可能メモリを確保して、Ruby 製の ARM アセンブラ aarch で機械語を生成し、それを Ruby メソッドとして直接アタッチする、という構成を作っていました。「Ruby の中に JIT コンパイラと ARM アセンブラがある」 というだけで字面の異常さがあります。
結果として、fjit は FFI より約2倍速く、フレームプッシュを減らした分だけ C extension すら微妙に上回る 速度を達成していました。「C extension が速さの天井」と思っていた自分の前提が静かに崩されました。
正直、メモリの確保の仕方やレジスタへの値の流し方は、その場で全部追えてはいません。それでも、「動的言語が高速化するときに、何を犠牲にして何を取り戻しているか」 を一つの具体例として持って帰れたのは大きかったです。
C extension のほうが 202.4 倍高速でした。「これ、FFIしてない（笑）」
最初の一言で空気を掴み、そのまま最後まで集中して聴ける構成になっていました。
From C to Ruby: Porting Doom（Chris Hasińskiさん）
1993年のゲーム Doom を、Chocolate Doom のCコードからほぼ翻訳ベースで Ruby に移植して、gem install doom && doom で遊べるところまで持ち込んだ話。タイトルだけで聴きに行きたくなる強さがありました。
何が刺さったかというと、性能改善のいちばん大きい一手が、JIT でもコンパイラでもなくアルゴリズムレベルの観察だった という事実でした。
最初は YJIT を有効にして約40FPS（無効時の2倍）まで持っていく、という普通に強い改善があるのですが、そのあとに 「floor と ceiling を最初に塗っているけど、後で壁とスプライトで全部上書きされている」 という無駄に気づいて、最初の塗りつぶしを削除しただけで 50% 高速化、Ruby 3.3 単体（YJIT 無効）でもプレイ可能にしてしまう。
これは自分の普段の作業に直接刺さる話でした。プロファイラを当てて、ホットスポットを見つけて、最適化を考える、というワークフローはよく聞きます。でも、「処理を全体として観察して、後で潰される計算をそもそもしない」 という改善は、プロファイラに張り付いているだけだと見つけづらい。コードの意味を考えるレイヤを上に持っていくと、CPUが楽になる量がいちばん大きい、というのは、覚えておきたい順序でした。
それから、RubyVM::YJIT.disable が存在しないことに対して、Fiddle 経由でメモリのバイトを直接書き換えて YJIT を on/off するハックを自作する くだりは、笑ってしまったし、Ruby らしい解決でした。「無いから諦める」ではなく「無いから書く」。
Doom is a Bigger Carrot
optcarrot に対しての「もう少し大きい人参」。これがそのまま、Ruby 性能の現在地を測る新しい物差しになりつつある、という話で締まっていました。あと、敵が追いかけてはくるけど撃ってこない MINASWAN モード（Matz is nice so monsters are nice）が実装されているくだりは、コミュニティ文化と技術発表の温度の混ざり方として、めちゃくちゃ Ruby でした。
Thread-Coordinated Ractors: The Pattern That Delivers（Maciej Mensfeldさん / Karafka）
Ruby 3.0 から「実験的」と言われ続けて4年経った Ractor が、Karafka という Kafka フレームワークのデシリアライズを実本番で 70% 高速化 した、という発表でした。「Ractor、結局誰か使えてるの？」のリアルな答え合わせ。
最初に共有された数字が容赦なくて、初期の Ractor を素朴に試したら JSON parse が3倍遅く、CPU が6倍 という、「これは戻すしかない」状態だった。Maciej さんは「Ruby Core Team に大量に complain した」と語っていて、これは技術発表のトーンとして非常に正直でした。実用化を阻んでいた問題の多くは、ユーザーが声を上げて Ruby Core 側が直したもの だ、という事実が、「OSS への貢献」とは PR を出すことだけではない ことを示しています。
設計面でいちばん腹落ちしたのは、「アプリ全体を Ractor-safe にしようとしない」 という割り切りでした。Karafka はユーザーにコードの変更を一行も求めず、フレームワーク内部の限定された building block（デシリアライズ部分）だけを Ractor 境界の中に閉じ込める 構造にしているというところです。
具体パターンとしては、
- pre-partition（全スレッドが全 Ractor に触る）はコンテンションが悪化して詰まった
- 最終的に intermediate coordinating thread パターンを採用
という流れ。コーディネータースレッドが仕事の分配と結果の回収を担当し、Worker は Ractor の中で parse に専念する。Ruby Queue は本来 Ractor-safe ではないけれど、コーディネータースレッドを介して間接的に使うことで、ノンブロッキング性を保ちつつ既存のものを使い回す、というのが現実解だ、と。
「Ractors を sprinkle して終わり」ではありません。完全に engineering challenge。でも実現可能です。
「Ractor を使えば速くなる」ではなく「設計と Core への突き返しを根気よくやれば速くなる」というメッセージとして受け取りました。
Practical TypeProf: Lessons from Analyzing Optcarrot（Yusuke Endohさん）
TypeProf（Ruby のコードを型注釈ほぼなしで型推論する道具）の作者ご本人が、自作の Optcarrot（約 6,000 行のファミコンエミュレータ）に TypeProf をかけてみた実験報告、という形式でした。「自分のツールを自分のコードに当てる」発表は、地に足がついていて非常に好きです。
最初に出てきた数字が、ファーストランで 669 件のエラー。多すぎ。「TypeProf すごい！」とは絶対ならない瞬間で、ここからどう減らすか、が中身でした。
戦略は2つ。
1つ目は、Key Point に絞って RBS を書く。全メソッドに型をつけるのではなく、データフローの上流（cpu_fetch のような「型がここで決まる」関数）にだけ RBS を書く。これだけで 669 → 177 に落ちる。Key Point の特定は Claude に「型エラーを減らすにはどこに RBS を書けばいい？」と聞くと、cpu_fetch を第一候補で出してくれた、という話で、AI を「型注釈の貼り付け先候補出し」に使う という運用が現実的にあり得る、と分かったのが面白かったです。
2つ目は、根本原因を直す。[nil, 1, 2, 3] の先頭 nil が原因で、TypeProf が「index 0 を読むかもしれない」と仮定して Integer | nil に推論し、nil が大量伝播していた。この nil を 0 に直すだけで 175 件まで減る。これは Claude には発見できず、自力デバッグが必要だった、と本人が正直に書いていて、「AI が得意なところと、実行時の挙動を踏まないと無理なところ」の境界線 が具体的に示されました。
最終的な変更量は 122行。比較として、Steep だと 1,429 行、Sorbet だと 1,248 行。だいたい 10 倍違う。Sorbet にいたっては、ランタイムオーバーヘッドが ON で 72%、OFF にしても 17% 残る。TypeProf と Steep は 0%。「型を入れる代わりに何を払うのか」 を、実数で並べた比較は強かったです。
TypeProf は Ruby code をほぼ変えなくていい。つまり、AI coding の邪魔をしにくい
最後の章で、動的言語の方が AI コーディングと相性が良いかもしれない という実験結果（mini Git を AI に書かせると、TypeScript・Python・JavaScript・Ruby の方が静的型言語よりトークン消費が少ない）まで踏み込んでいて、「型をつけるとは何か」「AI 時代に型ツールはどんな役割になるか」 をその場で考えさせられました。
The Future of Ruby Documentation（Stan Loさん）
Day 2 の最後を締めたのは、RDoc 8.0 の話。20年以上 Ruby のドキュメントを支えてきた RDoc が、Prism ベースの新パーサー、新デフォルトテーマ「Aliki」、Markdown 改善、RBS 統合、サーバーモード を揃えて生まれ変わる、という発表でした。
技術的に気持ちよかったのは、パーサーを Ripper + 独自実装から Prism に置き換えただけで、コードが 2,200 行 → 1,200 行 に減り、30% 速くなり、10年前から残っていた issue の山がまとめて閉じた という話。def foo = 1 のような endless method でスコープが崩壊するバグなど、「言語の構文が増えるたびに壊れていた箇所」が、共通パーサー基盤に乗ることで構造的に解消した、というのは、Ruby エコシステム全体での Prism の意味を改めて感じる瞬間でした。
ただ、このセッションのいちばん刺さった部分は技術詳細ではなく、「llms.txt は Claude には意味がない」 という結論にどう至ったかの話でした。
経緯はこうです。「AI がドキュメントを読みやすいように、Markdown 版 URL リスト（llms.txt）を生成する PR を出そう」と思い、プロトタイプまで作った。でも出す前に Claude の挙動を実測してみたら、Claude はすでに HTML を取得してから Markdown に変換して読んでいた。つまり llms.txt は追加価値を生まない。だから PR は出さなかった。流行りのフォーマットを採用する前に「自分で調べる」を1ステップ挟んだだけで、不要な作業が消えた、という話でした。
AI に良い docs は人間にも良い docs。今は AI によってその重要性がさらに増しただけです
この一文が今回の RubyKaigi で個人的にいちばん持ち帰った言葉です。精度が高いこと、フォーマットがシンプルなこと、型情報が入っていること——AI 向けに必要とされている要件は、結局、人間の開発者が読むときにも欲しかった要件と同じ。AI 専用フォーマット作る前に docs 本体直せ、はかなり好きな考え方でした。
Day 2 の終了後は、STORES CAFE at RubyKaigi 2026 へ
RubyKaigi 本編はどうしても情報量が多くて、
セッションを聞いているだけで脳が焼け気味になっており、
こういう “少し落ち着いて話せる場” があるとかなり助かりました。（笑）
会場では、
- どこのブースが楽しかったか
- 今日どのセッションが良かったか
- 普段どんなものを作っているか
みたいな話が自然に始まって、
技術イベントというより、
「技術好きが集まる大きな部室」みたいな空気を感じました。
特に印象的だったのは、
「Ruby メインじゃないけど来ている」
という人も普通に多かったことです。
自分も普段は TypeScript や インフラ を触る時間の方が長いので、
「Ruby を仕事で書いているか」より、
「言語実装とか開発体験に興味があるか」
の方が、このイベントでは重要なんだなと感じました。
お子さん連れで参加されている方もいて、
技術の話をしながらもどこか穏やかな空気が流れていたのが印象的でした。
セッションの外で起きたこと
学生スカラシップ組で過ごした時間
廊下や休憩スペースの話の前に、もう少し書いておきたいのが、
学生スカラシップで参加した同期たちのことです。
セッションの合間には「次どこ行く?」と Large Hall と Small Hall で
分かれる組を決め、休憩時間には「さっきのどうだった?」を交換する、
という時間も楽しかったです。
学生同士で話していて気づいたのは、
「同じセッションを聞いても、解像度が人によって全然違う」こと。
自分が VM の話で詰まっていたところを、
別の学生がさらっと「あれは〇〇ってことだよ」と説明してくれたり、
逆に自分の専門に近いところでは自分が説明する側に回ったり。
セッションを「一人で聴く」のと、
「同世代と一緒に聴いて、その場で会話する」のは、密度がかなり違いました。
学生として歩く廊下、ブース、地元の海鮮
廊下や休憩スペースでは、普段オンラインでしか名前を見ない人たちが普通に立っていて、コーヒー片手に話しかけられる距離にいる。その感覚は、参加するたびにやっぱり不思議です。
「あの最適化、どこから手を付けようって決めたんですか？」みたいな雑な質問に、本人がその場で普通に答えてくれる。実装の裏側にある迷いや優先順位の話は、むしろこういう廊下や休憩スペースのほうが濃いことも多くて、現地参加ならではの価値だと感じます。
個人的にかなり嬉しかったのは、『技術記事を書く技術 ITエンジニアの価値を高めるアウトプットのすべて』の著者の方にお会いできたことでした。実際に本へサインをいただきながら、技術記事やアウトプットについて直接お話しできたのは最高な体験でした。
「函館で開催される RubyKaigi は、街全体が懇親会の延長」 という空気感が良かったです。
Day 3 に行けなかったこと
正直に書くと、Day 3 はずっと心残りでした。Matz Keynote、Ruby Committers and the World は X のタイムラインを眺めるだけで、「コードの半分以上は AI に書かせている」というコミッター発言 とか、Ruby AOT Compiler の Spinel とか、「mruby が担っていた領域に Ruby 本体が広がる」 といったキーワードが流れてきていて、その場に居合わせていた人たちが羨ましかったです。
来年は最初から3日間フル参加前提で予定を押さえます！
そして何より、pixiv presents Ruby Illuminations 2026 に参加できなかったのが本当に悔しかったです。
自分は普段、スポーツ演出や空間演出まわりのシステム開発・オペレーションに関わることが多く、映像・照明・空間体験の設計そのものがかなり好きです。だからこそ、「RubyKaigi の文脈で、技術コミュニティと空間演出がどう結びつくのか」は、現地で絶対に見たかった。
タイムラインに流れてくる写真や感想を見ながら耐えていました。技術カンファレンスのイベントでありながら、単なる懇親会ではなく、空間の体験として成立していたことが伝わってきて、なおさら悔しかったです。
タイムラインの中で「超かぐや姫！」の同志を観測してしまい、さらに行きたさがMaxになりました。
しかも、#RubyIlluminations で
Reply が流れて無事終了しました え？
という投稿を見つけてしまい、無事終了しました。（？？）
結果、ワークショップでもらった基板を引っ張り出してきて、Reply を自力でMIDIに変換しソースコードに落とし込んで再生して “自宅 Ruby Illuminations” を開催していました。
現地には行けなかったのに、なぜか勝手にイルミネーションだけ参加している面白い体験でした（？？）
こちらも別途記事にする予定なのでお楽しみに！
持ち帰ったこと：Ruby は「言語」だけではなく「言語が動いている現場」だった
二日間を振り返って、自分の中で言語化できた持ち帰りを3つ書いてみます！
1. 「動いている＝完成」ではない、というメンタルモデル
RubyBox（Tagomori）、mruby/edge と Uzumibi（udzura）、fjit（tenderlove）、Karafka の Ractor 採用（mensfeld）、TypeProf（mametter）、RDoc 8.0（Stan Lo）——全部に共通して感じたのは、「いま動いているもの」を「もっと正しく動くもの」に作り変える設計が、ロードマップにきちんと書かれている ことでした。動いた時点で開発が止まる OSS は実は珍しく、長く生きている OSS は「動かす」と「直す」を同じテーブルでやり続けている。学生の自分が個人プロダクトを作るときも、「v1 を出す」だけで満足しない癖をつけたいです。
2. AI 時代でも、開発者ツールは deterministic でなければならない
TIA（anmarchenko）の 「AI は確率的でも、開発者ツールは決定論的であるべき」、TypeProf の 「コードをほぼ変えないから AI コーディングの邪魔をしない」、RDoc の 「AI 用フォーマットを作る前にドキュメント本体の品質を上げる」——切り口は違うけれど、向いている方向はだいたい同じでした。AI が普及したからこそ、土台側のツールは AI ではなく人間と同じくらい再現可能でいてほしい。これは自分が今後ツールを作る側に回ったときの軸として持っておきます。
3. 「Ruby を使う側」と「Ruby を作る側」は地続きだった
参加前の自分は、コミッターやコア実装者の世界を、勝手に「自分とは違うレイヤの人たち」と区切っていました。でも、廊下で話すと 作っている側も困っているし、ユーザーの complain がそのまま Ractor を直していたりする。Karafka の Maciej さんが「I complained a lot」と笑いながら言うシーンが個人的にいちばん象徴的で、ユーザーが声を上げることが、言語処理系を直すための入力になっている って初めて実感しました。学生として「ただ使う側」に閉じこもらず、issue の一行報告みたいな小さな貢献から始めてみようと思います。
おわりに
RubyKaigi 2026 を運営・登壇・スポンサードしてくださった皆様、会場で声をかけてくださった皆様、ありがとうございました。
そして、学生スカラシップで参加機会をくださったピクシブ株式会社さん、本当にありがとうございました。北海道在住の学生にとって、函館までの旅費と参加のハードルを下げてもらえたことは、文字通りこのレポートを書ける前提を作ってくれた支援です。Halcom Board のセッションで harukasan さんが話していた 「最初のプログラミング体験になるものを目指したい」 という話と、学生をこういう場に呼んでくださることは、自分の中で同じ方向の優しさに見えました。
一日目は前日入りの海鮮で胃を満たし、Day 1・Day 2 はホールに座り続けて頭を満たしました。Day 3 に行けなかったのが心残りなので、来年は最初から3日とも空けて参加したいです！
ありがとうございました！
付録：今回追いかけ直す予定のもの
- Day 3 の Matz Keynote と Ruby Committers and the World（録画・スライド・参加者ブログで）
- Tagomori さんが影響を受けた 2023 年の塩山さん「マルチバース Ruby」 トーク
-
gem install doomを自分のマシンで動かして YJIT on/off の差を体感する - TypeProf を自分の小さな Rails アプリにかけて、最初の Key Point を Claude に出してもらう
- RDoc 8.0 の
--serverモードで自作 gem のドキュメントを書き直す - mruby/edge を Cloudflare Workers にデプロイして、本当に 300KB に収まるかを試す
このリストを Day 3 の代わりに消化して行こうかなと思います！
ちなみに今回は 360度カメラも持って行っていて、かなり色々撮っていました。
ただ、人がめちゃくちゃ映っているので、モザイク作業が思った以上に重く、まだ整理できていません……。
うまく編集できたら、そのうち追記するかもしれません！
蛇足：ハッピーエンドのその先に
帰宅後、RubyKaigi のノベルティをカバンいっぱいに詰め込んでいたのですが、そこで事件が発生しました。
ハンドクリームが爆散しました。
しかも、かなり派手に。
結果、カバンの中に入っていたノベルティ類が、すべてハンドクリームに包まれることになりました。
ステッカーもしっとり、冊子もしっとり、布類はつやつやです。
「RubyKaigi 2026 の思い出、保湿力が高すぎるだろ……」となりながら、深夜にひたすら拭き続けていました。
最後の最後まで情報量の多い RubyKaigi でした。
そして改めて、
ピクシブさん！BIG KANSYA……！！
また来年！
Discussion