はじめに
プロダクト開発部プラットフォームエンジニアリンググループの小椋です。
4月22日〜24日に北海道函館市で開催された RubyKaigi 2026 に参加してきました。 コアサービスであるOfferBoxはPHPをメイン言語としていますが、部分的にRubyを採用しているところや、AI時代に言語設計者がどういう考えで開発をするのかという興味もあり、言語処理系やエコシステムの動向をキャッチアップする目的で参加できました。
今回は3日間を通して印象に残ったセッションをピックアップして紹介します。振り返ってみると、JITやコンパイラ周りのセッションを多く聞いており、最終日のMatzキーノートで発表されたAOTコンパイラ「Spinel」に向けて伏線が回収されていくような体験になりました。
Day 1
The Journey of Box Building / tagomoris
昨年「Namespace」として発表されていた機能が「Box」に改名され、引き続き実験的機能として開発が進んでいます。モンキーパッチや依存ライブラリ同士の干渉を隔離することで、アプリケーションの安定性を高める仕組みです。
印象的だったのは、VM内部でどのBoxに属するコードを実行しているかを常に把握しなければならないという設計上の制約です。制御フレームを参照してBoxポインタを管理する実装になっており、スタックVMだからこそ実現できるアプローチだと感じました。RubyのスタックとenvはVMの両端から挟み込むように読まれるため、オーバーフローは両者が衝突したことを意味するという話も、普段意識しない低レイヤの知見で面白かったです。
Rapid Start: Faster Internet Connections, with Ruby's Help / kazuho
FastlyのRapid Startアルゴリズム提案に至った話と、その検証のための大規模ログ分析ツール「jrf」の紹介というセッションでした。
Rapid StartはTCP接続確立時のスロースタートを改善する提案です。輻輳制御において、パケットが溢れるまで送信量を増やしてからリカバリーする従来方式の無駄を、ACKバイト数に合わせた送信量調整で削減するというアプローチが紹介されました。
jrfは、このRapid Startの実効性を検証するための20M行・80GBのJSONログをjqでは展開できないという課題から生まれたツールです。jqの文法をRuby DSLとして使えるようにし、並列処理で爆速に分析できるというもの。ベースのDSLエンジンはCodexやClaudeにほぼ書かせてレビューしたという話が印象的で、「アドホッククエリは人間が雑に書き、基盤機能はしっかり作り込む」というAI活用の実践的な線引きが参考になりました。DSLフレンドリーな文法設計とJITコンパイルの組み合わせがRubyの強みであり、それがAI活用によって加速されるという視点は、この後聞くセッションにもつながるテーマでした。
The design and implementation of ZJIT / Max Bernstein
RubyのJITコンパイラ「ZJIT」の設計と現状についての発表です。英語のネイティブ発音で聞き取りには苦戦しましたが、内容は非常に密度が高いものでした。
ZJITの戦略は、Smalltalk・V8・JavaScriptCoreなど過去40年にわたる動的言語コンパイラの知見を再利用し、Rubyのセマンティクスを維持しつつ不要な型チェックやシェイプチェックを除去して高速化するというものです。パフォーマンス5倍を目標に掲げており、マイクロベンチマークでは成果が出ている一方、マクロベンチマーク（Railsアプリケーション等）ではまだ改善途上とのこと。
特に興味深かったのは、劇的な高速化にはメソッドのインライン化が不可欠だが、Array#eachのようなC言語で実装された組み込みメソッドがボトルネックになっているという課題です。CからRubyへの書き直しが必要というランタイム側への要請は、後述するNarakuプロジェクトの動機とも通じる話でした。
Day 2
Surviving Black Friday: 100 billion requests with Falcon! / ioquatix 他
Shopifyが2025年のブラックフライデー・サイバーマンデー（BFCM）に向けて、WebサーバーをUnicornからFalconに移行した壮大なプロジェクトの全貌です。秒間142万リクエスト、期間中3,290億リクエストという規模感が圧巻でした。
UnicornからFalconへの移行は、1プロセスで複数リクエストを並行処理（Async/Fiber）できるようにするためです。しかし本番同等の負荷テストで、ネイティブC拡張によるFiberブロッキング、Spanner gRPCのフリーズ、ワーカープロセスのサイレントデス、Kafkaコネクション数の爆発という4つの深刻な問題が発覚しました。
特にKafkaのコネクション問題は印象的で、BFCMまで残り6週間のタイミングで一度Unicornにロールバックする決断を下し、そこから4週間で「Outbox」というコネクション集約の仕組みをプロトタイプから本番投入しています。エゴを捨ててロールバックし、時間を稼いで解決策を作り上げるという判断が、教訓として強く響きました。
個人的には、このセッションがきっかけでSpannerやKafkaのアーキテクチャを改めて調べ直すきっかけになりました。自社サービスの規模とは桁が違いますが、FiberベースのI/O多重化やコネクション管理の考え方は普遍的なものです。
From Formal Specification to Property Based Test / ohbarye
形式仕様からプロパティベーステストを自動生成する「SPEC to PBT」というツールの発表です。AIコーディングエージェントの普及により、誤った仕様から不適切な実装が生成されるリスクが高まっているという課題認識が出発点になっています。
形式仕様で仕様自体の正しさを保証し、そこからテストを決定論的に生成するという考え方は筋が良いと感じました。一方で、ツールの設計思想として「コンパイラ型ではなくスキャフォールド型」を採用し、仕様と実装のギャップは人間が設定ファイルで埋めるという現実的な割り切りをしている点が好印象でした。
Day 3
(Re)make Regexp in Ruby / makenowjust
Ruby専用の新しい正規表現エンジンを一から作り直すという「Naraku」プロジェクトの発表です。名前の由来は『犬夜叉』の「鬼蜘蛛」から「奈落」への変化で、既存エンジン「Onigmo」からの進化を意味しています。
現状のRubyの正規表現は、Onigmoに渡るまでに4段階の前処理が挟まっており、正規表現リテラルとRegexp.newで挙動が変わるなどのバグの温床になっているとのこと。これを「前処理のカオス」と呼び、汎用エンジンをRuby用に無理やり改造するのではなく、Ruby専用エンジンとしてゼロから設計し直す判断に至っています。
Day 1のZJITセッションで「C実装の組み込みメソッドがJIT最適化のボトルネック」と指摘されていた点と、Narakuが将来的にRuby実装+JITで高速化を目指すという方向性がつながっていて、カンファレンス全体を通したストーリーを感じました。
Matz Keynote / matz
最終日のキーノートは、AIとの協業によるプログラミングのパラダイムシフトと、AOTコンパイラ「Spinel」の発表でした。
Matz自身が長年愛用していたEmacsを封印し、Claude Codeなどのエージェントを活用した開発スタイルでAIの使いどころを探り、Railsアプリを作成したという話は会場に衝撃を与えました。「何を作るか」「どの問題を解決するか」「結果が受け入れ可能か」という意思決定に注力し、コード記述はAIに任せるスタイルで、SetクラスのC言語化を自分では1行もCを書かずに実現したり、以前挫折したカラツバ法の実装を1日で完了させたりと、具体的な成果も示されました。
そしてハイライトのSpinelは、RubyコードをAOTコンパイルしてネイティブバイナリを出力するコンパイラです。3月16日に開発開始、わずか数日でセルフホスティング可能な段階に到達。マイクロベンチマークではJITなしRubyの36〜86倍の高速化を記録しています。CLIツールやサーバーレスファンクション、組み込みシステムがユースケースとして想定されており、既存のRubyを置き換えるのではなく補完する位置づけです。
3日間を通してJITコンパイラの可能性と限界を聞いてきた中で、最後にAOTという別のアプローチが提示されたのは見事な構成でした。「Rubyを速くする」というテーマに対して、JIT（ZJIT）、エンジン刷新（Naraku）、AOT（Spinel）という複数の道筋が同時に進行しているRubyコミュニティの厚みを実感したRubyKaigiでした。
会場の様子
今年の会場は函館アリーナでした。たまたまこの週に函館の桜が満開だったため、翌日五稜郭公園を回って花見を堪能できました。食事も海鮮やラッキーピエロなど函館グルメを楽しみつつ、3日間のカンファレンスに没頭できました。
おわりに
普段PHPを主戦場としている身ですが、言語処理系の進化やエコシステムの設計思想に触れることで、自社サービスの開発にも活かせる視点が多く得られました。特にAIとの協業は言語を問わないテーマであり、Matzのキーノートで示された「意思決定に集中し、実装はAIに任せる」というスタイルは、日々の開発でも意識していきたいところです。
