こんにちは！
株式会社グロービスのデジタルプラットフォーム（GDP）部門のGLOPLA事業開発室のエンジニアをしております、太田です。
4月22日〜24日に函館で開催された RubyKaigi 2026 に参加してきました。
個人的には2023年の松本、2025年の松山に続き3度目の参加となります。
3度目ともなると少し雰囲気にも慣れてきましたが、参加するたびに学びがたくさんあり、今回もとても楽しかったです。
この記事では印象に残ったセッションをいくつかに絞って感想を書いていきます。
なお、自分が理解できた範囲で書いているので、誤った理解が含まれている可能性があります。
もし誤っている箇所があればコメントいただけると嬉しいです。
The Journey of Box Building
- セッションページ: https://rubykaigi.org/2026/presentations/tagomoris.html
- スライド: https://speakerdeck.com/tagomoris/the-journey-of-box-building
オープニングキーノートは tagomoris さんによる Ruby::Box の開発ジャーニーのお話でした。
Ruby::Box は Ruby 4.0 で導入されました。
たとえば String クラスに無邪気に破壊的な変更を加えるとグローバル全体が壊れてしまうところを、Box の中での変更を Box の中だけに閉じ込めることができる、というものらしいのですが、正直に言うとこの段階ではまだちゃんと理解できておらずです、、、理解したい。
このセッションでとても印象に残ったのは、tagomoris さんは元々「Ruby 言語やランタイムに、自分が貢献できるものはない」とモチベーションを失っていたそうです。
それが転機を迎えたのが2023年の松本でのRubyKaigiで、shioyama さんのセッション「Multiverse Ruby」を聴いて「これだ！」とモチベーションを発見したそうです。
そしてその夜、松本の居酒屋で深夜まで語り合った中で「Hako（=Box）」と名付けたそうです。当時冗談で「いつか Hakodate で RubyKaigi をやろう、Hako-Kaigi になるね」と言っていたのが、3年後の今回 RubyKaigi 2026 in Hakodate として本当に実現することになったとのこと。
Ruby::Box が実際に Ruby 4.0 にリリースされるまでの3年のタイムラインがここから見られます。
この流れを汲んで今日のKeyNoteを迎えたのだという感動と、Rubyの開発のストーリーが見られてとても良かったです。
Things happen suddenly. You'll be motivated, unintentionally.
「いつ自分にモチベーションが降りてくるかは分からない」というメッセージはとても印象に残りました。
私もモチベーションを見つけるためにRubyKaigiに来ているところもあり、過去にもそうやって何かしらエネルギーを得ていたりしたので、とても共感したとともに今回のRubyKaigiがより楽しみになりました。
ちなみに去年の RubyKaigi 2025 で、最後の Matz Keynote で壇上のMatzから「Ruby 4.0 で Box 出せるよね？」と急に振られて困惑していた tagomoris さんを客席から見ていたので、その伏線が今年回収された感じになって、ストーリーを一連で見られたのはとてもよかったです。
連続で参加するとこういう様子も見れたりするのだな、と思いました。
Portable and Fast: Parallel Test Runner Implementation
- セッションページ: https://rubykaigi.org/2026/presentations/tikkss.html
- スライド: https://slide.rabbit-shocker.org/authors/tikkss/rubykaigi-2026/
Red Data Tools という Ruby のデータ処理ツールを提供するコミュニティで、サポートするデータセットが増えるにつれてテストが遅くなってしまった、という課題から始まるセッションでした。
並列実行で高速化したかったものの、遅いテストが1つでもあるとそこがボトルネックになり全体としては速くならない。そのため、test-unit 本体でテストの並列実行をサポートすることになった、という流れがとても自然で分かりやすかったです。
特に印象的だったのが、ありとあらゆる環境で動いてほしいという「Portable」へのこだわりでした。OS や Ruby 処理系（CRuby / JRuby / TruffleRuby）、Ruby のバージョンを問わずに動くようにするため、たとえば Kernel.#fork ではなく Windows でもサポートされている Kernel.#spawn を選ぶ、依存ライブラリは標準機能だけで済ませる、後方互換性を最大限重視する、といった選定の積み重ねが語られていました。
Kernel.#fork と Kernel.#spawn のどちらを選ぶか、という選定のプロセスは、まさに私たちが普段行っているエンジニアリングの営みそのもので、同じプロセスなのだな、と勝手に親近感を覚えました。
整理された要件・制約を一つずつ解決していくスライドの構成も気持ちよく、観ていてとても楽しかったです。Red Data Tools というコミュニティの存在も今回はじめて知ることができ、Ruby コミュニティの広さの理解が一段進んだセッションでした。
Faster Internet Connections with Ruby's help
- セッションページ: https://rubykaigi.org/2026/presentations/kazuho.html
- スライド: https://speakerdeck.com/kazuho/faster-internet-connections-with-rubys-help
Fastly で H2O HTTP サーバーの lead developer をされている kazuho さんによるセッションでした。HTTP / TLS / QUIC といった通信プロトコルを実装したり、IETF で RFC を共著したりされている方で、めちゃくちゃすごい人が目の前にいる！！と感動しました。
QUIC というトランスポート層プロトコルを通信基盤とした HTTP/3 によって、接続確立までは速くなったものの、TTLB（Time To Last Byte）はまだ遅い。その原因は輻輳制御の Slow Start が立ち上がりに時間をかけすぎていることで、これを改善する Rapid Start という新しいアルゴリズムを設計し、IETF に Internet-Draft として提案された、というお話でした。
データの分析には jq を使っていたものの、文法が複雑で遅く、大量の LDJSON を処理するのに不向きだったため、Ruby で jq の代替である JRF を実装したそうです。なんとこの JRF は 99.9% を Codex と Claude が書いたとのことで、いわゆる vibe coding でした。
前回のRubyKaigiでは最後にMatzが「昨今のカンファレンスではAIのトピックがとても多いが、今回のRubyKaigiでは驚くことに1つもない」と触れていたところから、今年は早速vibe codingな事例が聞けたので、前回からの変化を感じました。
（ちなみにAIをテーマにしたセッションは今年は4つに増えました。）
HTTP に深く精通した方の発表をリアルタイムで聴けたという事実そのものに感激しつつ、内容のスケール感に圧倒されて「インターネット…！」でした。
Do Ruby::Box dream of Modular Monolith?（LT）
LT 枠で、joker1007 さんによる Ruby::Box を Modular Monolith の実現に使えないか試してみた、という挑戦のお話でした。タイトルの通り『アンドロイドは電気羊の夢を見るか?』のオマージュです。
クラス空間を Box 単位で分離できるなら、Rails でも Modular Monolith が実現できるのではないか、という発想で実験されていて、結論は「実用的とは言えないができる」というものでした。LT なので進みが速くて細部までは追いきれなかったのですが、正直まだ Ruby::Box についての概念的な理解が乏しい自分にとっては、tagomoris さんの Keynote とあわせて Ruby::Box への解像度を上げるきっかけになり、ありがたい LT でした。
Ruby::Box で Modular Monolith ができたらたしかにロマンがあるよなぁ、と妄想がふくらみました。
The future of Ruby documentation
- セッションページ: https://rubykaigi.org/2026/presentations/_st0012.html
- スライド: https://st0012.dev/assets/slides/2026-04-23-rubykaigi.pdf
Shopify の Ruby DX チームに所属する Stan Lo さんによる、Ruby ドキュメンテーションの中核を担う RDoc の現状と未来についてのセッションでした。
私は普段RDocを使っていないのですが、RDocのことについて理解をして活用したいと思い聴講しました。
Ruby のドキュメンテーションは AI にも対応していかなければならない、という前提から始まり、その責務のほとんどが RDoc という1つのプロジェクトに集中していること、しかし RDoc 自身はまだその準備ができていなかったこと、という問題提起がなされました。
そこで RDoc 8.0 では、新しい Prism ベースのパーサー、新テーマ Aliki、Markdown サポートの強化、RBS 型シグネチャ表示、ライブプレビューサーバーといった大きな改善が入った、という内容でした。
特に Markdown 対応については、AI に対して HTML よりもトークン消費量を節約できる期待があった、という補足が興味深かったです。実際 llms.txt を生成して .md を並べて配信するプロトタイプも作っていたとのことなのですが、調べてみると主流の AI エージェント（Claude Code など）は自分で HTML→Markdown 変換しているため、サーバ側で Markdown を別途用意する必要は実はなかった、という結論に至っていました。
The best thing RDoc can do for AI is be good at its job.
「AI のために RDoc ができる最善のことは、本来の仕事を上手にこなすこと」という最後のメッセージはとても印象に残りました。AI のために何か特別なことをするのではなく、人間にとって良いドキュメントを作ることがそのまま AI にとっても良いドキュメントになる、という結論で、エンジニアらしい誠実な検証のプロセスとあわせて深く納得しました。普段あまり RDoc を直接触っていなかった自分にとって、RDoc という存在そのものを理解するきっかけにもなり、聴いてよかったセッションでした。
Stan Lo さんはたまたま廊下で見かけて挨拶程度のやり取りを交わしたのですが、とても紳士で素敵な方でした。
Autoresearching Ruby Performance with LLMs
- セッションページ: https://rubykaigi.org/2026/presentations/nateberkopec.html
- スライド: https://github.com/nateberkopec/rubykaigi-2026
Speedshop で Ruby on Rails のパフォーマンスコンサルティングをされている Nate Berkopec さんによるセッションでした。
ちなみにですが、GLOBISでは最近社内の輪読会でigaigaさんたちとNateさんの「Ruby on Rails パフォーマンス アポクリファ」を読み始めているところです。
Nateさんに話しかけて「読んでるよ！」と伝えたかったのですが、Nateさんの周りにはたくさんの人が常にいたので話しかけられず、、
セッションでは、冒頭で「RubyKaigi だしもっと技術的な内容になる予定だったがautoresearch を調べているうちに『良いソフトウェアとは何か』の話をしたくなった」ということで、RubyKaigiとしては少し珍しい趣向？なのかもしれません。とても楽しみに聞いておりました。
autoresearch は Andrej Karpathy が提唱した「AI に試行錯誤を任せ、ベンチマークが改善する変更だけを残していく自動ループ」のことです。
これが登場したことで、Ruby on Rails のパフォーマンスコンサルタントである Nate さん自身も「AI に仕事が奪われる」ことが他人事ではないと感じたそうです。
しかし実態を調べてみると、autoresearch で生成された PR のうちマージされず放置されているものも多くありました。一方で Stan Lo さんは Ruby LSP / Rubydex に対して autoresearch ベースの PR を出して実際にマージに至っています。両者の違いはどこにあったのか。それは コードベースを熟知し、前提を理解していたかどうか という話で、Automatic "research" であって Automatic "modification" ではない、自分が理解できるコードに対してのみ使うべきだ、というレッスンが提示されていました。
そこからセッションは「PR がマージされない理由とは何か」「あの GitHub のマージボタンを我々は何を基準に押しているのか」という問いに入っていきます。バグの有無は bugbots がそこそこ検知できる時代になったが、それ以外にも「複雑すぎる」「リスクが高すぎる」「テストが十分でない」といった、暗黙的に人間がレビューでチェックしている観点がたくさんある。これらを Software Gate として明示化することこそが本質的に重要だ、というお話でした。
いや確かにそう。緑色に光っているマージボタンが押せない理由はなんだろうと考えたことはなかったのですが、こういう曖昧で暗黙的な基準は確かにあるなと感じました。
Gate / eval design > code or skill design
スライドにあった「ゲートや eval の設計 > コードや skill の設計」には、確かにそうだなと思いました。「コードを生成することよりも、何が良いコードか（＝マージできるコードか）を定義することのほうが重要」というメッセージが私の印象に残りました。
autoresearch という切り口で始まったセッションでしたが、最終的にはAI時代でのソフトウェア開発のNateさんの主張が聞けるいいセッションでした。
ちなみにですが、「puma」の発音はプーマなのかピューマなのかという議論が私の周りでも今まで度々あり、勝手に私はピューマなのかなと思っていたのですが、メンテナであるNateさんは「プーマ」と発音していました。
調べるとアメリカ英語では「プーマ」、イギリス英語だと「ピューマ」なんですね。pumaの発音についての理解が進みました。
Matz Keynote
最終日は Matz による Keynote でした。
去年の RubyKaigi では「AI と私たちは Master / Slave（主従）の関係であり、AI を使う側にいることが大切だ」と語られていましたが、今年は「AI はパートナーだ」と表現されていたのが大きな変化として印象に残りました。
やりたいことはたくさんある、AI の登場によって状況が大きく変わり、やりたいことが実現しやすくなったという発言には、AI に対してとてもポジティブで、それ以上に「やりたいことがやりやすくなっている状況そのものに喜びを感じている」と伝わってきました。
そしてAIをパートナーとして、Matzは spinel を開発していると発表しました。
およそ1ヶ月ほどで作ったとのこと。
ちなみに今回も「静的型は一生涯入れない」と断言されていました。私は2023年、2025年に引き続き今年で3回目の RubyKaigi 参加なのですが、私が参加している回全てでこれを聞いているのでもしかしたら毎回言っているのかな、と思いました。
今回も強い意志を感じました。
まとめ
RubyKaigi 2026、とても楽しかったです。
今年は AI を扱ったセッションが体感的にぐっと増えていた印象でしたが、そのほかの内容や夜のDrink Upでの会話では（私の周りでは）AIの話はほとんどなく、いい意味で今までとあまり変わらない技術的な話やコミュニティの話が多かったです。
私が最近積読から引っ張り出して読んでいるオライリー出版『Googleのソフトウェアエンジニアリング』の第1章「ソフトウェアエンジニアリングとは何か」p4には、以下のような主張がありました。
土台となっている技術や製品の方向性の変化に反応する能力を根本的に欠いている場合、そのような変化が決定的に重要なものとなることは絶対にないという期待へのハイリスクな賭けを行っているに等しい。
これは、私たちが開発するソフトウェアの持続可能性の話の文脈の主張です。
長く稼働する想定のソフトウェアのコードが長く稼働するためには、土台となっている技術が長い年月で変化しうる依存関係の方向性の変化に反応していくことが大切であるという内容です。
今回のRubyKaigiで、ここに取り上げた内容のほかにZJITの話、RuboCopの話、Bundlerの話、JRubyやmruby, Hashの話などRubyの中の話にたくさん触れました。
最近、普段Rubyを使った開発をする中でRubyの方向性の変化に反応することがなかなか出来ていないなと感じていたのですが、RubyKaigiはそのきっかけを与えてくれると感じました。
来年のRubyKaigiは遠くへ、というメッセージとともに 4/14-16に宮崎での開催です。
読んでいただきありがとうございました。
Discussion