RubyKaigi 2025参加レポート

Posted by Network Applied Communication Laboratory Ltd. on May 09, 2025 · 8 mins read

2025年4月16日(水)～2025年4月18日(金)に開催されたRubyKaigi 2025に本社からは井上、まつもと、前田、高尾、西田、高田、原、佐田、岸野が、東京支社からは後藤、小倉、早川が参加しました。
弊社からは以下メンバーが登壇していました。

  • 基調講演
    • まつもと
  • TRICK
    • まつもと、原
  • LT
    • 前田
  • Ruby Committers and the World
    • まつもと、前田、後藤

この記事では小倉、高田、佐田、早川がそれぞれが印象に残ったセッションの感想をお届けします。

初日のLunch Breakに集合写真を撮影しました。RubyKaigi会場でのNaClメンバーの集合写真は中々レアな気がしますね。(撮影時にいなかった原は後ほど1人で撮影して合成しています。最近の加工技術はすごいですね！)

01_all.png

1日目

楽しみすぎて会場が開く前についてしまった小倉は初日から道後温泉まで散歩してきました。会場と道後温泉が近くてとてもよいロケーションでした。

Ruby Taught Me About Encoding Under the Hood

mari imaizumiさん によるキーノートです。文字コードの歴史の話から始まり、Unicodeの課題と解決策に焦点を当てた話へと続きました。
家族絵文字をIRBに入力しバックスペースを押すとクラッシュする問題を発見、修正したことから、Unicodeの書記素クラスタに面白さを感じるようになったそうです。
現在@ima1zumiさんはRubyコミッターになり、RubyでのUnicode15.1.0と16.0.0への対応作業を進めており、Unicode正規化への対応が今後の課題であるというお話でした。

見た目は1文字なのに実際は7つのコードポイントで構成される家族絵文字を例に、書記素クラスタの概念の説明と修正にいたるまでの流れが説明され、Unicodeの奥深さを感じられるキーノートでした。
また、Unicode15.1.0からはインド系文字への対応が求められるという話を聞き、世界中の言語に対応しているUnicodeの偉大さを感じました。

(早川)

Automatically generating types by running tests

Takumi Shotokuさんによる自作のRBS::Traceについての発表でした。 RBS::Traceはテストを実行するだけでrbs-inline形式の型定義を自動で追加してくれるものです。
ある程度規模のある Rails アプリケーションとしてRedmineとMastdonで概ね型宣言が定義されることを確認しているそうですぐに使えそうな印象を受けました。メソッドの引き数と返り値を記録し、そこから型を推論して型宣言を定義するといったことをしているためテストは通常の実行に比べて3.8~5.4倍ぐらい遅くなるようですが、毎回RBS:Traceを有効にする必要はないためあまり問題ではなさそうです。
また、並列実行したテストから作られた型宣言をrbs-trace mergeで結合することもできるそうです。
大抵のアプリケーションでは十分なテストがあるはずなので、テストを実行することで型宣言を定義できると導入のハードルが下がってよさそうに思いました。

(小倉)

Goodbye fat gem 2025

Sutou Kouheiさんによる、Fat Gemへの問題提起のお話でした。
Fat Gemとは、事前ビルド済みのバイナリーライブラリを含むGemを指します。
Fat Gemには以下の3つの問題があると述べられました。

  1. 最新のRubyへの対応遅延: Fat Gemは新しいRubyバージョンごとに更新が必要で、一つでも対応していないFat Gemがあると最新Rubyが使えない状況になる
  2. セキュリティリスク: 特にバインディング系のFat Gemは依存ライブラリも含むため、脆弱性が見つかった場合、Fat Gem作者の更新を待つしかない
  3. メンテナンスの負担: 開発者は44種類もの環境に対応したFat Gemを作成・メンテナンスする必要があり、メンテナンスコストが非常に高い

解決策として「RubyGem Requirement System」という新しいGemを作成したことが紹介されました。
ビルド環境を自動で整備し、システムのパッケージマネージャを使って依存ライブラリをインストールする仕組みで、このGemを使えば、Fat Gemのメンテナンス問題を解決しつつ、Ruby開発者の負担を減らし、エコシステム全体の健全性を向上させることができると提案されました。

発表の中では、Gem開発者の負担を減らすことでよりよいエコシステムを考えるという事を、開発者だけの問題ではなく、Gemを使う側の人たちも考えなければならないというメッセージが伝えられました。
より健全なRubyの未来のためにビルドは自分たちで行うべき、という主張はとても納得できるものでした。

(早川)

State of Namespace

Namespaceの開発者の Satoshi Tagomori さんの発表でした。
Namespace について、現在の進捗や今後の課題について紹介されました。
RubyKaigi 2024 から RubyKaigi 2025 までは不具合修正を主に作業されてきたとのことです。

最初に Namespace の説明で、グローバルから分離された名前空間に変更されたというお話しがありました。

  • グローバルな名前空間: Ruby のプロセス内で全てのクラス/モジュールが共有
  • 分離された名前空間: apps/libs を分割された名前空間にする

上記の変更をするため、Ruby の RClass と rb_classext_t に変更をおこない、各 Namespace で classext のシャローコピーするようにされたそうです。
定数参照も変更がおこなわれ、Namespace で const_tbl をシャローコピーしていましたが、定数が削除された場合に参照中の const_tbl が GC で解放されてしまい SEGV が発生することが判明したので const_tbl はディープコピーするように変更されたとのことです。

また、複数の Namespace で同じ拡張ライブラリを dlopen で読み込もうとすると、一度しか読み込まれないため、拡張ライブラリをコピーして別ファイルとして読み込むことで対処されたそうです。
その他にもさまざまな不具合修正について紹介があり、Ruby 4.0 で Namespace が取り込まれることについてもお話しがありました。

(佐田)

TRICK 2025: Episode I

一日目の最後が TRICK(Transcendental Ruby Imbroglio Contest) でした。難解プログラミングのコンテストにもかかわらず開始時刻が近づくとメインホールに続々と参加者が集まり、スタッフから満員が予想されるので席を詰めてくださいと声がかかりました。

TRICK では puts 'Hello, World' のように単に 'Hello, World' を出力するのはダメなコードと言われます。例えば 'Hello, World' をアスキーアートにしたり趣向を凝らすのだそうです。難解プログラミングの練りこまれたアイデアを実装したコードが評価されるコンテストです。

セッションでは、TRICK 2025 の応募作品の中から高得点を獲得した受賞作品が発表されました。
TRICK 2025 は審査員による応募も許されており、審査員の作品は採点が終わってから作者を明かすようにしていたそうです。

弊社のまつもと、原が審査員として登壇しました。

プログラムに "Feel, don't think." と書かれていますが、TRICK の楽しみかたの解説がありました。

  • TRICK の楽しみかた
    1. 実行する
    2. 眺める
    3. 読み解く

今回、mame award: "Most shifted" (もっともズレているで賞)を受賞した弊社、原の作品で試します。

原の作品を実行すると、画面に表示される文字が動きズレていきます。

Most shifted_1

コードを眺めますが、読めません。

Most shifted_2

会場でコードの読み解きがありました。メソッドがズレているようですが、原は満足そうです。

Most shifted_3

Ruby のソースコードの sample ディレクトリには過去の TRICK の受賞作が同梱されています。TRICK 2025 の受賞作もバージョン 4.0 になるかもしれない次の Ruby のリリースにサンプルとして同梱されるそうです。

(佐田、高田)

2日目

前夜の Official Party の余韻も感じつつ 2 日目が始まろうとする会場です。

02_start.jpg

Dissecting and Reconstructing Ruby Syntactic Structures

parse.yとLramaのメンテナでLR Parser GANGSのydahさんによる文法規則の構造を再構築することでparse.yの保守性を向上させたお話でした。
Rubyは人間にとってシンプルで柔軟な文法を持っていますが、その実現のトレードオフとしてパーサーが悪魔城に喩えられるほど複雑になっているそうです。また、コードの規模が大きく終端記号も非終端起動も他の言語に比べて多いそうです。
そんな複雑なパーサーの構造を見ていくと同じような構造がいろいろなところに現れることに気がつき、それらをParameterizing Rulesを使い共通化した結果以下のような効果を得られ、可読性が上がったことで実際にパーサーのバグの解決に役だったそうです。

  • コードの重複の除去
  • 再利用性の向上
  • 保守性の向上
  • 可読性の向上

今後はさらに整備していき将来の拡張がやりやすくなるよう活動を続けられていくそうです。複雑なパーサーに挫けず共通化を進めていく姿勢がかっこいいです。
ydahさんは関西Ruby会議のチーフオーガナイザーもされており6月には関西Ruby会議08を開催されるそうです。楽しみですね！

(小倉)

Writing Ruby Scripts with TypeProf

Rubyのフルタイムコミッタで、TRICKの審査員の Yusuke Endoh さんの発表でした。
最初に、執筆された書籍の「型システムのしくみ ― TypeScriptで実装しながら学ぶ型とプログラミング言語」が販売されることについてご紹介がありました。
また、STORES のブースで景品がもらえるIRB宝探しについてもご案内がありました。

TypeProf は Ruby Editor Support で幾つもの機能(エラーレポート、定義ジャンプ、アノテーション、など)が提供されているとのことです。
どのように型推論しているのかは、メソッドの呼び出し元をパースして調べる方法が使用されているそうです。
今回はユースケースへのためにおこなわれた改善や不具合修正について説明がありました。

  • diagnostic_severity: TypeProf のレポートのエラーレベル("error", "warning", "info", "hint")を変更
  • analysis_unit_dirs: 各指定ディレクトリで解析を分けるように設定

Ruby の定数参照が複雑なため、型指定を型推論で全て自動生成するのは難しいので、自動生成するのと手動で書いていく両方が必要では、というお話しもありました。

(佐田)

MicroRuby: True Microcontroller Ruby

PicoRubyの開発者の Hitoshi HASUMI さんの発表でした。
プロポーザルとして MicroRuby, PicoRuby.wasm, Keyboard の3つを提出されたところ、どれを発表してもよいことになったそうです。
また、プロジェクトの開発はまつもとさんからメンタリングを受けながら進めているとのことです。

PicoRuby と MicroRuby は、以下のような構成で動作しているそうです。

  • PicoRuby: picoruby-compiler + mruby/c
  • MicroRuby: picoruby-compiler + mruby

上記のような構成のメモリ消費を比較した場合、一般的に mruby の方が mruby/c よりも多くメモリを消費すると言われているとのことです。
ただし、puts 'Hello, World' のような単純なコードではなく、実際のプロダクトに近いコードで比較した場合には、そこまで大きな差が生まれないのではという仮説を考えて確認されたそうです。
そのため、R2P2 の Ruby のエンジンを MicroRuby に変更できるようにして比較をおこなったとのことです。

  • R2P2+PicoRuby: 78KB
  • R2P2+MicroRuby: 109KB

その結果、R2P2 on MircoRuby が現実的なメモリ消費で動作するようになったとのことでした。

(佐田)

Making TCPSocket.new "Happy"!

shioimmさん による Happy Eyeballs Version 2 (RFC8305) (以下、HEv2) の Ruby のソケットライブラリ Socket.tcp と TCPSocket.new への実装の発表です。HEv2 は IPv4 と IPv6 のデュアルスタック環境で速やかに TCP コネクションを確立するための仕組みです。

前回の RubyKaigi 2024 で Ruby で書かれた Socket.tcp への HEv2 の実装を発表されたのに続けて、その後の1年になされた Socket.tcp の再実装と C で書かれた TCPSocket.new への HEv2 の実装が報告されました。

Socket.tcp を再実装したのは、IPv6 で接続する状態、IPv4 で接続待ちなどの状態遷移に実装が寄り過ぎだったためで、再実装の結果、よりシンプルな実装になったそうです。また、Ruby による Socket.tcp の実装をベースにしつつも、C で書かれた TCPSocket.new への HEv2 の実装にあたり対処された C に固有の問題が報告されました。

そして、Ruby 3.4 に TCPSocket.new の HEv2 の実装が取り込まれるタイミングで Rubyのコミッターとなられた経緯を紹介されました。
まつもとさんが Ruby Comitters and the World で舞台の上のコミッターと客席の距離は思っているほど遠くないと客席の参加者を作る側に誘っていたのと同じようなメッセージを感じました。

(高田)

Lightning Talks

弊社の前田が LT に登壇しました。
タイトルは「Displaying "アパート" correctly on Textbringer」です。
Textbringer は前田が開発する Ruby で動く Emacs-like なテキストエディタです。

初日の mari imaizumiさん の基調講演とつながる LT で、文字を正しく表示したり編集する大変さを感じました。
LT のスライドがまだまだ残っていたので、どこかで話すかもしれないそうです。

lt.jpg

(佐田、高田)

Agileware Drinkup at RubyKaigi 2025

一部のメンバーはアジャイルウェアさんの Drinkup に参加しましたが、Zigによる拡張ライブラリの作成についてLTで西田が発表しました。
ドリンクアップではLT以外にもクイズの企画などがあって盛り上がりました。

drinkup_lt.jpg

(佐田、高田)

3日目

3日目にもなると大分疲れてきますね。。、ANDPADさんブースのコーヒーがとてもありがたかったです。

The Ruby One-Binary Tool, Enhanced with Kompo

ahogappaさんによるKompoの改善に関する発表です。
KompoはRubyスクリプトをワンバイナリ化するツールです。以前のバージョンでは小規模なプロジェクト（Sinatraなど）は動作可能でしたが、Railsのような大規模プロジェクトには対応できていませんでした。
以前の実装では、requireをオーバーライドする方法を採用していましたが、これにはいくつかの問題がありました。

  1. オートロードとの相性が悪く、例外が発生することがあった
  2. ユーザーが任意のタイミングで埋め込まれたファイルを取り出せなかった
  3. ディレクトリ構造を含む階層的なデータ構造に対応できなかった

これらの課題を解決するため、新しい実装では以下のアプローチを採用されました。

  • バイナリ内に仮想ファイルシステムを構築
  • 実ファイルシステムとバイナリからの読み込みを切り替える機能の実装

これにより、Railsのような大規模なRubyプロジェクトもワンバイナリ化できるようになったそうです。
目標としては「簡単にどこでもそこそこ早く動く」ことを掲げており、クロスプラットフォーム対応や追加インストール不要という特徴を目指しているということでした。
現在は追加インストール不要という部分は対応済みで、クロスプラットフォーム対応などは今後の課題となっているそうです。

Rubyがワンバリナリ化されてどこでもポチっと起動するだけで動く、というのはとても魅力的だと感じました。
さらにRailsのような複雑なアプリケーションが動かせるようになったというのは驚きです。
クロスプラットフォーム対応されることでどこでもRubyスクリプトが動くようになるというのも、とてもワクワクするお話でした。

(早川)

Toward Ractor local GC

RubyのフルタイムコミッタでRactorの開発者である Koichi Sasada さんの発表でした。
最初に Ractor local GC のご紹介があり、Ractor local GC において root オブジェクトとして共有可能なオブジェクトを維持できるように変更された点と、そのベンチマーク結果について説明がありました。

現在の Ractor は、各 Ractor が独立したオブジェクト空間を持ち、他の Ractor はそのオブジェクト空間に対してアクセス(read/write)できません。
そのため、 Ractor 同士でオブジェクトを操作するには、共有可能なオブジェクトを使用する必要があります。
ただし、全ての Ractor は並列処理で実行されているため、並列処理でそのような共有可能なオブジェクトの参照状態を保つのが難しいとのことです。
このセッションでは、その課題を解決する方法としてグローバルなオブジェクト空間を持ち、その中でオブジェクトを共有するという方法が紹介されました。

最後にベンチマークの性能改善の結果をグラフで表示しながら紹介されました。

(佐田)

Porting PicoRuby to Another Microcontroller: ESP32

Yuhei Okazakiさんによる、発表です。
通常Raspberry Pi Picoで動かすことの多いPicoRubyを、ESP32へ移植（ポーティング）する方法を研究、発表されました。
ライブラリ作成、プロジェクトビルド、標準入出力対応、mrbgemをESP32向けにポーティングという手順を踏むことでESP32への移植が実現されたそうです。
発表の後半では実際にESP32が動作する様子のデモも行われました。

今回解説された移植の手法は他のマイコンにも応用可能ということで、Rubyの世界が広がる可能性を感じる発表でした。
ESP32に対応することで人気のマイコンモジュールM5StackのコードがPicoRubyで書けるようになる、というのはとても興味深いです。
これをきっかけにマイコンに入門するRubyistも増えるのではないでしょうか。

(早川)

Programming Language for AI age

最後の基調講演は まつもとさん でした。
まつもとさんは照れながらも両手を広げてステージ中央からせりあがって登場しました。

Matz_Apperance

最初に、「次の RubyKaigi の開催地を事前に知っているのでは？」と尋ねられるけれど基本的に事前には知らないとのことでした。今回の基調講演のテーマに AI を選んだのは、AIの話題が世界を席巻している中で今回の RubyKaigi に AI をテーマにする講演が見当たらなかったからだそうです。

Matz_keynote_title

まず AI には得意なことと苦手なことがあり、AI は決められたことを実行するのが得意だが、仕様などが決められていないことをするのが苦手な印象を持っているそうです。

以下のような Alpha Syndrome を例に挙げて、AI の苦手なことを人が代わりにやっているうちに、AI が人の主人のようになり、Ruby が大事にするプログラミングの楽しさを見失うことになるのではないか懸念している。何を任せて何を自分たちでやるか考えるときでないかと語られました。

  • Alpha Syndrome: 犬を大事にし過ぎると、犬が自分を群れのリーダー(アルファ)だと勘違いして吠えたり噛んだりするようになる。
  • Reverse Alpha Syndrome: できないことをやっているうちに上下関係が逆転してしまう。

Ruby の開発は楽しさのためにしているそうです。

講演は言語の話に移っていき、数学が自然言語よりも簡潔かつ論理的で数学の記述に適していたから発展したように、コンピューターに指示を与えるには自然言語は冗長すぎるので、プログラミング言語が発展したことを挙げてから、AIの時代には人間がプログラムを書き、AI がプログラムを書き、互いにプログラムを修正すると続けました。

そして、静的型があれば型チェックで間違いを検出できるが、静的型を持っていることが本当に必要だろうかと問いかけ、論理のミスや仕様のミスが重要で型エラーはあまり重要でないという見方もあると語りました。AI が簡単な型の間違いをするか考えると、AI が適切に処理することで静的型の重要性は下がるのではないか。AI 時代のプログラミング言語にとって Concise(簡潔)であること、Expressive(表現力)があることや Extendable(拡張性)があることが重要だと考えると、どこかで聞いたことがある感じで牽強付会かもしれないが、Ruby は AI の時代に合う言語ではないだろうかと Ruby の未来を語りました。

また、最後に多分 Ruby 4.0 をリリースすると発表がありました。
Ruby の最初の公式リリースである Ruby 0.95 から数えて今年は 30 年になることもあり、Linux のバージョンのスタイルに倣ってセマンティックなことにこだわらずバージョンを 4.0 にすることにしたそうです。試験的な機能として Namespace や ZJIT が取り込まれるそうです。ただし、4.0 とならない可能性もちょっとあるのでそのときはエイプリルフールでとのことでした。

(佐田、高田)

TOKIUM & mybest Drinkup at RubyKaigi 2025 Day3

一部のメンバーは TOKIUMさんとマイベストさん合同の Drinkup に参加して、LTで西田が発表しました。西田はRabbit に変更を加え、LT で音を鳴らして盛り上げました。

drinkup_lt2.jpg

(佐田、高田)

感想

matz_sign.jpg

RubyKaigi は活気に満ちていました。たくさんのセッションを聞き、そして RubyKaigi だから会うことができた方々と話すことができました。RubyKaigi は想像以上でした。

(高田)

Ruby の開発の最新情報を知ることができて楽しかったです。

(佐田)

大分久しぶり(10年ぶりぐらい？)のRubyKaigiでした。新人のころに一緒にお仕事をした方に再会できたりオンラインでしか会ったことのない方にリアルでお会いできたり、またRubyistの熱量に触れることができ自分も何かをしたくなってくるとても楽しいイベントでした。
ただ、去年の動画で予習をして今回臨みましたがやはり英語セッションは難しかった。。、来年の函館に向けて英語力とRuby力を高めていきたいと思います！！

(小倉)

2年ぶり2回目の参加でした。前回はまったく何もわからない…という状態だったのですが、今回は入念に予習をしたおかげもあり、セッションを興味深く聞くことができ、とても楽しかったです。
どの発表にもRubyistたちの努力、ひらめき、工夫を感じ、「自分も何かやらなくては！」と熱い気持ちになりました。

(早川)

今年もインターンシップやります！

今年もインターンシップをやります！、ということでスポンサーブースにあるノベルティ置き場にチラシを置かせていただいていました。まつもとさんとの交流会もあるので学生のみなさんこちらからエントリーよろしくお願いします。

internship.jpg

← Previous Post