RubyKaigi 2025 参加レポート

はじめに

今年も RubyKaigi の季節がやってきました。世界中の Rubyist が一堂に会する、一年の一度のお祭りに参加してきましたので、その様子をレポートしたいと思います。

開催概要

開催日程：2025/4/16(水) 〜 4/16(金)
会場：愛媛県県民文化会館
参加者数：約 1500 名

セッション

自分が聞いたセッションに限りますが、ちょっとした要約（間違っていたらすみません…！）と感想を述べていきます！

1 日目

Ruby Taught Me About Encoding Under the Hood

今年から Ruby コミッターとなった @ima1zumi さんによる、Ruby の文字エンコーディングに関する発表でした。Unicode における文字表現の複雑さ、特に一つのコードポイントまたは複数のコードポイントの組み合わせで一文字を表現するための言語処理の実装のために、各プログラミング言語でルールセットの定義が存在している、という点は驚きでした。

また、@ima1zumi さんのファーストキャリアにてメインフレームの文字出力に苦労した経験が、この取り組みのきっかけとなったという話には、同様の経験を持つ私も強く共感しました。自身の経験が OSS への貢献に繋がっていくというのは、多くの人にとって OSS を自分ごとにできるいいきっかけだなと思いました。

Bringing Linux pidfd to Ruby

Ruby のプロセス管理における技術的な進展についての発表でした。現在、Ruby はプロセス管理に pid を使用していますが、pid は使用可能な数が非常に限られており、再利用されることでレースコンディションやセキュリティ上の問題が発生する可能性があることが指摘されています。

この問題を解決するために、Linux 5.x 以降で導入された pidfd という機能に注目が集まっています。pidfd はファイルディスクリプタを利用することで、pid の再利用による問題を解消する仕組みです。しかし、これまで Ruby には pidfd を公式にサポートする実装が存在していませんでした。

発表では、pidfd をサポートするための具体的なツールの実装について詳しく解説がありました。Ruby の高速化のために、並行処理は一つの解決策となると思っていますが、プロセスの管理は今以上に複雑になるはずです。その安全性を高める本実装の重要性は極めて高いと感じました。

A side gig for RuboCop, the Bookworm code crawler

RuboCop の内部実装と、その機能を活用した新しいアプローチについての発表でした。一般的に単なるリンティングやリファクタリングツールとして認識されている RuboCop ですが、その中核となる NodePattern API は Ruby の AST を解析する強力な機能を持っています。この機能を活用し大規模な Ruby コードベースを解析するための Bookworm というオープンソースツールを開発したとのことでした。

遅い cop に解析が引きずられず、欲しい結果が返るまでを高速化できる点や、このツール自体が非常にメンテナンス性が高い点において、ツールの有用性が語られていました。こういったエコシステムの成熟が Ruby としての言語の価値を大きく高めていると思わされます。

Goodbye fat gem 2025

RubyKaigi Takeout 2020 で議論された「Fat gem」の問題について、その後の進展を共有する発表でした。Fat gem とはビルド済みのバイナリを同梱した gem のことを指し、インストールの容易さのために多くの gem で採用されています。ただ gem のメンテナンスコストの増大を招くなど、問題がないわけではありません。

この課題に対して、「rubygems-requirement-system」が提案されました。これは RubyInstaller2 で採用済みの手法を RubyGems に組み込み、ビルド環境の自動セットアップとビルドの自動化を実現するものです。

一方で、ビルド時間の増加やマシン全体への暗黙的な影響といった懸念点も指摘されました。これらに対してはパラレルビルドの採用や、Docker などのコンテナ利用による影響の局所化が解決策として挙げられています。ただ、RubyGems コミュニティでは python にある wheel のような仕組みの採用も検討されているとのことで、今後の方向性について活発な議論が行われています。

Automatically generating types by running tests

既存のアプリケーションへの RBS 導入を支援する新しい gem についての発表でした。大規模なコードベースに対して手動で全てのメソッドの型情報を書くことは現実的ではないという課題に対し、テスト実行時に型情報を収集し、RBS の型宣言を作成する手法が提案されました。

特に興味深かったのは、Ruby 特有の課題への対応です。例えば、Ruby では明示的な return を使用しないことが多いため、メソッドが void を返すかどうかは、呼び出し元でその戻り値が使用されているかどうかで判断する必要があります。

大規模なアプリケーションで行われた実験でも、パフォーマンスへの影響も予想以上に小さいとのことで、RBS 導入のハードルを大きく下げる可能性を感じました。

50.000 processed records per second: a CRuby & JRuby story

Zendesk が開発した Indexer という RDB から ElasticSearch に毎秒数万という単位のレコードをインデキシングするためのツールの改善についての発表です。CRuby から、GVL の影響を受けずにマルチスレッド処理が可能となる JRuby への移行の話が中心でした。

その他にも、Event Sourcing パターンの採用によるデータベース負荷の軽減や、Ractor による並行処理の活用など、Ruby の進化と共に Indexer がどういった改善を繰り返してきたのかが垣間見えます。

dRuby on Browser Again!

RubyKaigi 2017 で発表された dRuby の WebSocket 実装と Opal を使用したブラウザ上での dRuby 実装について、Ruby.wasm を活用した新しい展開の発表でした。ruby.wasm により、ブラウザ上で新たな Ruby の実行環境が実現され、その上で dRuby を動作させることに成功したとのことです。

特に印象深かったのは、サーバーとクライアントで同じインターフェースを実現した、という点です。これにより、サーバーサイドでデバッグ（Node.js を使って JS のランタイムを入れる）しながら実装したコードを、そのままブラウザ上で動作させることができます。ruby.wasm の扱いにくさを解決する素晴らしいアプローチだなあ…と思いました。

TRICK 2025: Episode I

今年も大変変態的でした。入賞作品は次の ruby のリリースにサンプルコードとして含まれるそうなのでご参考までに。

2 日目

Performance Bugs and Low-level Ruby Observability APIs

パフォーマンスバグの調査に必要な Ruby の内部実装（C コード）のトレース手法についての発表でした。特に Ruby VM が提供する低レベルな観測用 API の詳細な解説がありました。

とはいえ提供されている API は機能的に限りがあるため、Datadog ではそれを拡張した LowLevelToolkit を実装しているそうです。例えば、TracePoint API では捕捉できるイベントが限られているので、独自にオブジェクトの生成イベントなどが追加されています。

他に印象的だったのは、Postponed Job API の紹介です。アプリケーションコードと同期的にトレースを行うのではなく、非同期でトレースを実行することで、プロダクションコードの実行時にパフォーマンスへの影響を最小化した安全なトレースを実現できます。

GVL（Global VM Lock）のトレースに関する新機能として、GVL profiler の追加も紹介されました。より詳しいプロファイリングが可能になるとのこと。

話の最後には Performance Bugs の発生に対して、開発者がどのような判断基準で行動を起こすべきかが語られ、いちツールの利用者にとっても非常に得る物の大きい講演でした。

Benchmark and profile every single change

パフォーマンスに関する興味深いアプローチとして、Benchmark-Driven Development（BenchDD）が提案された発表でした。1%程度の小さなパフォーマンス低下は気付かないうちに積み重なり、結果として大きな問題になりうるという問題提起から始まりました。

@osyoyu さんは、全ての変更に対してベンチマークとプロファイリングを行うという手法を実践し、Sinatra の実装を 100 倍高速化することに成功したとのことです。具体的には、ルーティング時の探索アルゴリズムを O(n) から O(log n) に改善したり、採用する構造体を Class から Data や Struct に変更するなどの改善を重ねていったそうです。

アプリケーション開発において、パフォーマンスを継続的に意識する文化を作るための良いアプローチだと感じました。

Improvement of REXML and speed up using StringScanner

Ruby の標準 XML ライブラリである REXML の高速化についての発表でした。Ruby 3.3.0 の rexml 3.2.6 から Ruby 3.4.0 の rexml 3.4.0 にかけて、約 40% のパフォーマンス改善を達成したとのことです。

特に興味深かったのは、StringScanner を活用した高速化のメカニズムです。StringScanner はこれまでの String に対する操作と比較して 1.5-1.8 倍高速に動作するとのことで、その理由として以下が挙げられました：

memcmp() を使用した効率的な文字列比較
無駄な文字列からなるマッチオブジェクトを作成せず、Integer で文字列の位置を返す実装

適切なツールの選択が大きな影響を与えることを実感させられる発表でした。

RuboCop: Modularity and AST Insights

RuboCop の新しいアーキテクチャと将来の展望についての発表でした。プラグインシステムの導入、Ruby LSP との統合、そしてパーサーエンジンの移行という 3 つの重要な変更について解説がありました。

まず、カスタム Cop の実装方法が大きく変わり、従来の require ベースから lint_roller を使用したプラグインシステムへと移行されます。これにより、カスタム Cop 側では Lint::Loader クラスを実装するだけで RuboCop 側がそれをプラグインとして読み込めるようになります。

次に、Ruby LSP との関係性も整理されます。これまでは RuboCop 専用の LSP が起動し、それがすべての検査と自動修正を行なっていましたが、新しい設計では add-on を通じて処理が Ruby LSP に委譲される形になります。これにより、パース結果の再利用などでパフォーマンス面での改善が図れるそうです。

さらに、バックエンドパーサーについても大きな変更が予定されています。長年使用されてきた parser gem から Prism への移行を検討しているとのことです。ただし、既存のインターフェースは維持される、というポイントは非常に興味深かったです。Prism のパース結果を parser gem 互換のインターフェースに変換して利用する方針を進めており、他パーサー実装と交換可能な状態を保つとのこと。

RuboCop と Ruby 全体のエコシステムを見据えた、面白い未来に向けた話だと感じました。

Speeding up Class#new

Ruby 3.5 での Class#new の高速化についての発表でした。オブジェクトの初期化処理において、C から Ruby の initialize を呼び出す際のオーバーヘッドを削減する取り組みについて解説がありました。

これまでの実装では、C が Ruby の initialize を呼び出す必要があり、この呼び出しがパフォーマンスのボトルネックとなっていました。とりわけ、引数の呼び出し順を両者の間で維持する部分に課題があり、そのメモリ効率は非常に悪い状態となっていました。

これらの課題に対して、C から Ruby を呼び出さない「Inline 化」というアプローチを採用することで、引数なしの場合で約 2 倍、引数ありの場合で約 3 倍のスループット向上を達成したとのことです。

Class#new はあらゆる箇所で実行される非常に影響の大きい機能です。この改善がもたらす効果は非常に大きいだろうと思わされました。Ruby 3.5 のリリースが待ち遠しいです。

Making TCPSocket.new “Happy”!

Happy Eyeballs Version 2 (HEv2) の実装についての発表でした。アドレスの名前解決に時間がかかる場合や、特定の IP アドレスが利用できない場合に、他の選択肢へのフォールバックが遅くなる問題を解決する取り組みです。

HEv2 はなるべく IPv6 アドレスを取得しようと試みますが、IPv6 の応答のみが極端に遅い場合に無駄な待ちが発生してしまいます。今回の改善はこの点を解消するものです。この改善により、IPv6 アドレスが永遠に返ってこないような環境では、従来の実装と比べて 150 倍もの高速化が達成されたとのことです。

特にトライアンドエラーを経ながら、このコントリビュートまでを達成した過程を詳しく共有していただいた点がとても印象的でした。

Lightning Talks

LT は今や広く日本でも行われていますが、その日本における起源は YARPC (Yet another Ruby/Perl Conference) とのこと。Ruby Community の影響力の凄まじさを感じます。なんと今年はそれから 25 年の節目の年。おめでとうございます…！

発表を聞いて印象に残ったのが、ゲーム、音楽、といった Web 以外の Ruby 活用事例の紹介が多かったことです。Ruby の未来にとてもワクワクさせられる時間でした。

3 日目

Ruby Committers and the World

毎年恒例の Commiter が壇上に勢揃いして Ruby の将来について話し合うイベントです。初手の質問から static barrier の是非について熱い議論が繰り広げられておりました。開発者会議の一端が垣間見えてとても楽しかったです。

Running ruby.wasm on Pure Ruby Wasm Runtime

Pure Ruby で実装された WebAssembly ランタイム「Wardite」についての発表でした。Ruby で WebAssembly の仕様や命令を実装し、基本的な Ruby の機能を実行できる ruby.wasm の実行環境を実現したという取り組みです。

大量の実装が必要となるアサンブラの命令セットの実装をスクリプトによる自動生成で実現するなど、ツールの実装における試みも非常に興味深いものでした。

また、Wardite の高いポータビリティを活かして、CI 環境や、テスト環境での活用が期待できるというアイデアについても触れられていました。

The Ruby One-Binary Tool, Enhanced with Kompo

Ruby アプリケーションをワンバイナリ化するツール「Kompo」についての発表でした。元々はゲームエンジンのための開発だったということでしたが、ポータブル性を追求した実行環境として、広く応用されることを期待しているとのこと。

これまでは Ruby スクリプト以外は簡単にワンバイナリ化できなかったため、Rails アプリケーションを動かすことはできなかったのですが、今年の発表があったバージョンアップではその起動に成功していました！すごい…！

一つ前の @udzura さんの発表に引き続き、どこでも動く Ruby を作る試みが、開発体験の向上を求める Ruby らしいなあ…と感じていました！

Road to Go gem

Go 言語で Ruby の拡張ライブラリを作成するためのツール「go-gem-wrapper」についての発表でした。これは CRuby のネイティブな API を Go から実行できるようにするものです。

実装上の課題として特に印象的だったのは、C 言語と Go の型の違いへの対応です。また、削除された関数の存在による Ruby のバージョンによる分岐が必要になる点や、Ruby 実行時に必要な大量の環境変数の管理など、メンテナンス性に対する課題も挙げられていました。

この Gem を利用する利点はそのまま Go で Gem が作れることです。とりわけ goroutine による高速な並列処理は非常に魅力的で、Ruby による同等の処理の実装を速度面で圧倒します。Ruby を利用するアプリケーションのもつ処理速度の課題に対する非常に面白いアプローチだなと感じました。

Analyzing Ruby Code in IRB

IRB のコード解析機能と、その Prism への移行についての発表でした。シンタックスハイライト、マルチライン入力の終了検出、自動インデント、補完など、IRB が実現する種々の機能をどのように実現しているかに関する詳しい解説がありました。

これまでの Ruby perser は error-tolerant ではなかったので、Ripper::Lexer を使用していましたが、Prism であればその移行が可能です。Prism への移行により、Array の値の正確な型推論などの、より柔軟な解析が可能になるとのことです。

開発者体験の向上に向けた地道な改善が着実に進められていることを実感させられる発表でした。

Matz Keynote

AI 時代におけるプログラミング言語の在り方についての基調講演でした。

Matz は今後のプログラミング言語に求められる特性として、以下の 3 点を挙げました：

Concise：より少ないトークンで表現できること
Expressive：現実世界の問題に対応できる表現力があること
Extendable：拡張可能であること

これらは Ruby がこれまで培ってきたものに合致しており、AI 時代において改めて Ruby が注目される可能性は十分にあると述べていました。

ただ AI 時代に選ばれるプログラミング言語のために不足している部分を補う必要があるのも事実です。データ、ツールの豊富さ、パフォーマンスの向上など取り組むべき課題は多くあります。これらには Ruby コミュニティの一層の拡大が必要不可欠です。

Ruby を 20 年先も使われる言語に、というメッセージはこの言語に関わるすべての人をまた改めてワクワクさせてくれました！

コミュニティとの交流

Official Party @ 城山公園まるで野外フェス！松山城がそびえたちます。

RubyKaigi の醍醐味は、セッションと同じくらい参加者との交流にもあります。

私は今回とある企業のメンバーとして参加したのですが、そのドリンクアップの企画・運営、本番では司会も務めさせていただきました。微力ながらも、誰かにとっての RubyKaigi の楽しい思い出の一つになっていたら嬉しいなと思います。

また、純粋に参加者としても RubyKaigi を楽しみつくしてきました！

初日の Official Party は野外フェスのような雰囲気で最高でした！そして、各企業主催のドリンクアップにも参加させていただき、毎晩 Ruby コミュニティの温かさを実感していました。特に RubyKaraoke や Music Mixin では、普段技術的な話をしているみなさんの意外な一面を見ることができて、とても楽しかったです。

初めて出会った Rubyist の方々との交流も多く、新しい友達がたくさんできました。技術的な議論はもちろん、Ruby への思いや将来の展望など、深い話もできて本当に充実した時間でした。