はじめに

こんにちは！バックエンドエンジニアをしている津曲です。

今日から函館で開催されている「Ruby Kaigi 2026」において、株式会社リンクアンドモチベーションはプラチナスポンサーを務めております。

私自身、実は技術カンファレンスへの参加は初めてなのですが、Rubyに対する熱量や現地の方々の温かさを感じて、非常に楽しく過ごさせていただいています！

ブース出展も行っているためすべてのセッションを拝聴できたわけではありませんが、1日目に参加したセッションの内容と感想をレポートとしてお届けします。

1日目のタイムテーブル

The Journey of Box Building

The Journey of Box Building - RubyKaigi 2026

オープニングキーノートは、Ruby に新しく追加される実験的な機能「Ruby::Box」のお話でした。Box は「プロセス内にコンテナ的な分離空間を作り、モンキーパッチ・定数・gem を Box 単位に閉じ込める仕組み」だと改めて理解しました。

gem のモンキーパッチが他に漏れ出さない、ActiveSupport 6 と 7 を同一プロセスに共存させる、新バージョンを別 Box にロードしてルーターを切り替えるインプロセスの Blue/Green デプロイ、といったユースケースが紹介され、これが Ruby 本体に入るのは面白いなと素直に感じました。

内部実装のパートで印象に残ったのは、「コントロールフレームと env が同じメモリ空間を両端から使っていて、ぶつかったところで Stack Overflow が起きる」という構造でした。普段アプリ開発でメモリ空間を意識することはないので、よくあるエラーの正体が見えた瞬間で、Ruby 本体をもっと勉強したいと思えるキーノートでした。

When Can You Skip a Test? Tracking Test Impact

When Can You Skip a Test? Tracking Test Impact - RubyKaigi 2026

Datadog の Andrey Marchenko さんによる、Test Impact Analysis (TIA) のお話でした。「全件テストではなく、変更箇所に影響があるテストだけを実行したい」という課題に対しての試行錯誤のセッションです。

英語のセッションだったので細かいところまでは追い切れなかったのですが、「Ruby の内部からどう『依存』を捕まえるか」という問いの立て方が面白かったです。行カバレッジだけでは validates :name のような DSL の依存が拾えないので、オブジェクト生成イベントや YARV bytecode の解析といった別のレイヤの信号を組み合わせて補う、という流れが紹介されていました。

「1つの信号で捕まえきれないなら、別のレイヤに降りて別の信号を探す」という発想は自分が普段あまり持っていなかった視点で、スライドが公開されたらもう一度読み返したいセッションでした。

Portable and Fast - How to implement a parallel test runner

Portable and Fast - How to implement a parallel test runner - RubyKaigi 2026

test-unit gem にマルチプロセスベースの並列テスト実行を実装した話。「ポータブル（Windows 含めどこでも動く）」かつ「速い」という両立が難しい要件に、どうアプローチしたかのお話でした。

ちょうど開発の現場でも RSpec の全件テストの高速化に取り組もうとしていたタイミングだったので、エッセンスを学ぶことができました。大前提として「並列化よりも各テストを速くする方が大切」で、そのフェーズを終えた上で並列化に進む、というプロセスは持ち帰りたいと思います。

実装の細部についても興味深かったのですが、セッション全体として事実 → 課題 → 解決策という構成を貫いて話されており、プレゼンの手法としても参考になるセッションでした。

Exploring RuboCop with MCP

Exploring RuboCop with MCP - RubyKaigi 2026

RuboCop コアチーム koic さんによる、「AI エージェントが新しい操作者として加わった時代に、RuboCop をどう位置づけるか」というお話でした。RuboCop MCP サーバー（experimental）の実装を紹介しつつ、後半はツール設計の思想に踏み込んでいく構成でした。

特に印象に残ったのは、「決定性 × 非決定性」をどう設計するかという部分です。従来のツールは入力に対して出力が確定していたのに対し、LLM は同じ入力でもコンテキスト次第で出力が変わります。両者を組み合わせてツールを設計する上で、「何を AI に任せ、何を従来のツールで固定するか」はアイデア勝負になっていきそうだと感じたセッションでした。

Kingdom of the Machine: The Tale of Operators and Commands

Kingdom of the Machine: The Tale of Operators and Commands - RubyKaigi 2026

Lrama（LALR パーサージェネレータ）作者の Yuichiro Kaneko さんによる、パーサーの本質的な問題を掘り下げるセッションでした。

象徴的だったのが 1 + 2 * 3 の例で、パーサーが 1 + 2 まで読んだ時点で「次に * が来たから一塊にするのをやめて読み続けるか」を判断しなければならない、という話です。Ruby 固有の難しさとして、return と raise で ** の扱いが変わる、といった「続くトークンによって文の終わりかどうかが決まる」ケースも紹介されました。記法の自由さと構文解析は本来トレードオフのはずなのに、Ruby はそれをなんとか共存させている凄みが伝わる内容でした。

最近は AI にコードを書かせているのであまり意識しなくなりましたが、入力途中のコードを瞬時に「構文が違う」と返してくる裏側に、これだけの設計判断の積み重ねがあるのだと改めて感じました。つかみと翻訳の凝り方も含めて、非常に楽しめたセッションでした。

Digits, Digits, and Digits

Digits, Digits, and Digits - RubyKaigi 2026

IRB / Reline / BigDecimal メンテナーの tompng さんによる、BigDecimal の BigMath モジュールの性能改善のお話でした。

核は「掛け算の計算量をどう減らすか」でした。exp のテイラー展開は掛け算がボトルネックになり、筆算方式は O(N²) だが FFT 系を使えば O(N log N) に落とせる。さらに引数を分割して「そこそこの計算を 2 回」にする方が「重い計算 1 回」より速い、1 桁ずつ掛けるのは最悪で、似た桁数同士で掛ける方がロスが少ない、といった観察が積み重なって、Binary Splitting + Digit Split（= Bit-burst）にたどり着く流れが面白かったです。「知らずに車輪の再発明をしていたが、それが楽しさでもある」という姿勢もよかったです。

普段使っている標準ライブラリの裏でこんなアルゴリズムの探究が行われていると知ると、「十分速い」で止まらずに問い続ける姿勢が標準ライブラリの品質を支えているんだなと感じる、静かに熱いセッションでした。