1. はじめに

RubyKaigi 2026

開催日時：2026/4/22(水)~2025/4/24(金)
場所：函館アリーナ / 函館市民会館

私はRubyKaigiには2021年から参加していて、6年連続6回目の参加でした。

YOUTRUSTに入社してからは4回目の参加になり、今年もRubyに関する最新の情報をキャッチアップするという目的のもと、会社の業務として参加しました。

2. セッションのレポート

Keynote：The Journey of Box Building (@tagomoris)

speakerdeck.com

tagomoriさんによるRuby Boxについての発表で、Ruby Boxの仕組みと開発の経緯について語られました。

2024年はclass.cについて、2025年はload.cについて、そして今年はvm.cで行われている現在のBoxの判定方法について詳細に説明されました。

Box(旧Namespace)の目的が、アプリケーションやライブラリやmonkey patchを隔離された空間に分離することであることはこれまでのセッションでも語られていましたが、どのクラス定義やメソッド定義を参照するかを決める目的で現在のBoxを特定するために多くの複雑な工夫がなされていることを知ることができました。

また、2023年のshioyamaさんのセッションを聞いて飲み会で話したことがきっかけでモチベートされ、Boxを開発して函館("Hako"date)でRubyKaigiを開催するに至ったというtagomoriさんのエピソードから、多くのセッションを聴いて、多くの人たちと話して、みなさんもモチベートされてほしいというメッセージがすごく刺さり、とても素敵なKeynoteでした。

Rapid Start: Faster Internet Connections, with Ruby's Help (@kazuho)

speakerdeck.com

OkuさんによるRapid Startについての発表で、インターネット通信を高速化する輻輳制御アルゴリズムであるRapid Startの仕組みと、そのパフォーマンス評価や可視化手法について語られました。

HTTP/3とQUICによってハンドシェイクはかなり高速化されてきましたが、既存のアルゴリズム(Slow Start)ではTTLBはまだ遅いため、そのボトルネックを解決するために生み出されたのがRapid Startです。

初期送信を強化し、増加速度とリカバリを改善した結果、TTLBがGlocalで14.7%改善されたという結果でした。

また、これらの成果を生み出すまでの何回もの仮説検証を行う過程で、ログ解析が重すぎたのでRubyを使って自作でクエリエンジンを開発したという話でした。

私は今SREをしていてネットワークまわりにも関心があったのでこのセッションを聞きに行ったのですが、RubyやAIも駆使して使えるものを総動員して改善に取り組んでいたのが印象的でした。

The Less-Told Story of Socket Timeouts (@coe401_)

speakerdeck.com

shioiさんによるsocketライブラリのタイムアウトの歴史の話で、Ruby 4.1で Socket.tcp と TCPSocket.new に open_timeout が追加されるまでの、長年の試行錯誤の経緯について説明されました。

Ruby 2.0で接続試行のタイムアウトであるconnect_timeoutが導入され、Ruby 2.7で名前解決のタイムアウトであるresolv_timeout が追加されましたが、fork時に子プロセスにワーカースレッドがコピーされないという問題があり、getaddrinfo_a を使った非同期DNS解決の実装がロールバックされたようです。

しかし、Ruby 3.3でgetaddrinfo を別スレッドで実行できるようになり、Ruby 3.4でHappy Eyeballs v2が導入された結果、Ruby 4.0でopen_timeoutの導入がやっと実現できたというストーリでした。

socketライブラリはほんの1つの例であり、Rubyの進化の裏側には数多くのRubyistの努力が積み重ねられているという締めくくりは、shioiさんの人柄が表れていて、Rubyの歴史を作ってきた人たちへの感謝を改めて意識する機会となりました。

Ruby Releases Ruby (@hsbt)

hsbtさんによるRubyを使ってRubyをリリースするという話で、Rubyのリリース作業を効率化するための工夫について話されました。

Rubyのリリースは3, 4年前と比べて2〜3倍に増えていて、現在は2週間に1回のリリースを実現されています。

リリースマネージャーの実作業は1時間未満で完了する状態になったと話されていました。

その過程には、GitHub ActionsとRuby CI を使ってCI/CDを実現し、Ruby製のCIツールであるchkbuildでログを集計し、Ruby製のChefのようなツールであるmitamaeを使ってインフラ構成を管理するといった、Rubyのリリースも徹底的にRubyを使って動かすことによってレバレッジを効かせていくという取り組みがされているそうでした。

今後の展望としては、今はBundlerのプラグインはドキュメントがないものが多くてAIが有効に機能しないものが多いようで、Bundlerのプラグインの仕組み改善や、RubyとBundlerにSigstore署名ができるようにするといったことが挙げられていました。

私は普段YOUTRUSTで使っているRubyやgemのアップグレードを担当していますが、その作業の最上流に位置するRubyのリリースの話はとても関心が強かったので、今回裏側での工夫を知ることができて良かったです。