Ruby Kaigi 2025 参加レポート

Ruby Kaigi 2025が地元愛媛で開催されることになり、今年初参加を果たしました。世界中からRuby Kaigiに参加するために来日している外国人の方も多かったです。海外からわざわざ参加するとは愛が深すぎますね。

3日間に渡って開催されたのですが、セッションだけでなく毎日Drink upイベントがありました。しかも参加費無料ということで毎日飲み歩いていました。太っ腹すぎる。外国人が同席することが多く、英語で会話する機会が多かったです。話しているうちにそこの会社に誘われたりして、自分のサバイバル・イングリッシュのレベルでも通用するのかと少し自信になりました。

Ruby歴が浅くてあまり深い内容は書けないのですが、印象に残った発表を書き残しておこうと思います。誤っているかもしれないので話半分で読んでください。

Ruby Taught Me About Encoding Under the Hood

最初のキーノートは文字コードの話でした。スピーカーの方は文字コードに関するirbのとあるバグを踏んだことをきっかけにRubyコミッターになったそうです。文字の符号化の歴史から始まり、コンピューター上で文字を取り扱うことの難しさについて語っていました。

特に面白かったのは複合絵文字の説明でした。👨‍👩‍👧‍👦 という家族を表す絵文字があるのですが、これは男性と女性と女の子と男の子の絵文字の合字という扱いになっているようです。 「👨‍👩‍👧‍👦.chars」を実行すると実際に絵文字に展開されるそうです。

=> ["👨", "", "👩", "", "👧", "", "👦"]

「え、そんな仕組みなの？」という驚きがありました。ニッチなことに詳しくなればRubyコミッターの一員に加わることができるんだなぁ、と感心しました。

Introducing Type Guard to Steep

スピーカーがSteepへ提案している機能改善を紹介するセッションでした。

例えば、次のようなコードがあります。

if user.present?
  user.name
else
end

従来はuser.nameを参照しようとすると、presentメソッドが存在しない型エラーとなっていました。スピーカーの方の提案がリリースされたことにより、presentメソッドで型ガードを記述することができるようになったそうです。

しかし、独自メソッドで型ガードを書こうとすると、型エラーになってしまう問題はまだ残っているそうです。

if user.admin?
  user.name
else
end

また、動的なType Narrowingも開発中とのことです。下記の例は公開された記事ならtitleがStringに絞り込まれる例です。

if article.published?
  article.title # ドラフト記事はnilableだけど、published?の中ならStringになる
end

Empowering Developers with HTML-Aware ERB Tooling

HERBというツールを使ってERBのパースを行えるツールの紹介でした。HTMLにRubyのコードが混在しているような場合にもうまくパースできるようになります。将来的にはフォーマッターやリンターの機能を備えたツールにしたいそうです。

Automatically generating types by running tests

rbs-traceという、自動テストを実行することによって型定義ファイルを自動生成するというツールの紹介でした。当然、テストがなければ型定義も生成されません。

型定義を生成するために自動テストを書こうというモチベーションにもなるのかなと思いました。うまくハマると、自動テストを整備すると同時に型定義も整備されていくという一石二鳥な状態になりそうです。

型アノテーションをつけるのとは別のアプローチで興味深いです。

ただし、自動テストに合わせて型生成を行うため、当然ながらテストの実行時間は余分にかかるそうです。

State of Namespace

RubyにおけるNamespace機能の追加の現状についてでした。そもそも、RubyにNamespaceがないことを知りませんでした。Namespaceが実装されることにより、例えば同じライブラリの異なるバージョンなどを利用しても衝突せずに使うことができるようになります。

膨大なコードベースに大きな新機能を追加するので、それはそれは大変な作業なんだろうと想像に難くありません。

mruby/c and data-flow programming for small devices

災害防止のためにセンサーで気象情報を記録したいという要求に対して、モバイル回線を使うとお金がかかるので、安く広範囲に使えるローカルネットワークが求められているそうです。言及されていませんでしたが、勝手にWiFi Halowのことかなと思いました。その上で、IoT端末に如何にRubyで書かれたコードを搭載するか。

mruby/cを使うことでコンパイルされたコードを端末上で実行できるようになり、Low power・Low costに処理を実行できます。また、Data Flow ProgrammingはIoTに向いているんじゃないかというお話もされていました。

Running JavaScript within Ruby

quickjsというgemを使って、Ruby内でJSを実行することができるそうです。

consoleを使ったり、関数定義もできるそうです。

vm.eval_code('console.log("hello")')
vm.logs
=> [hello]

vm.define_function 'rubykaigi' do |year|
  'RubyKaigi ' + year.to_s
end
vm.eval_code('rubykaigi(2025)')
=> RubyKaigi 2025

vm.define_function 'raise' do |message|
  raise MyError.new(message)
end
vm.eval_code('raise("sadness happened")')
vm.eval_code('try { raise("sadness") } catch (e) { console.error(e)}')
vm.logs
=> Error: sadness

How to make the Groovebox

groovebox-rubyというツールを使ってCLI上で演奏することができます。MIDIのインポートやエクスポートにも対応しているそうです。シーケンサーを備えていて、小節をループしながら徐々に音を変化させていくというライブコーディング的なことができます。作曲をするというよりはライブ向きだなと思いました。

演奏動画を作ってみたくなりました。

MicroRuby: True Microcontroller Ruby

PicoRubyとMicroRubyの性能比較の話でした。一般にPicoRuby (mruby/c) の方がリソース使用率が低いことが知られていますが、ある程度の規模のアプリケーションを作った際にはMicroRuby (mruby) の方が効率が良いという仮説を立て、R2P2をMicroRubyで動かして計測してみたそうです。今の所、仮説を裏付ける結果が得られているようです。

The Ruby One-Binary Tool, Enhanced with Kompo

kompoというツールを使うことで、Rubyをバイナリ化する手法について紹介されていました。バイナリ化することで配布しやすくできます。Dockerで配布するなどのやり方もありますが、ゲーム開発などDockerを立ち上げるのがtoo muchな環境で配布しやすいです。

Inline RBS comments for seamless type checking with Sorbet

Rubyにおいても型システムは年々注目度が高まっていますが、特にユーザーが気にしているのは型の記述方法だということがアンケート調査によって分かりました。そこで型定義の記法の見直しを行い、SorbetでもRBS Commentの記法をサポートし始めたそうです。このことにより、型定義もRubyの構文規則に基づいて記述できるようになりました。

Porting PicoRuby to Another Microcontroller: ESP32

PicoRubyをRasberryPiだけでなく、ESP32上で動かせるようにするまでの軌跡を紹介していました。「ポーティング」という手法を使ってR2P2を動かせるようにしていました。個人的にもM5Stackを所有しているので興味深かったです。

On-the-fly Suggestions of Rewriting Method Deprecations

ライブラリ開発者がAPIを非推奨にする際に、警告だけでなく、修正案を表示させるのが望ましいです。ユーザーにとってライブラリのアップデートは痛みを伴うからです。Deprewriterを使うと、Synvertというgemの記法に則って変換ルールを定義することで、自動マイグレーションを行うことが可能です。

Matz Keynote

AIコーディングが普及してきた今、プログラミングの在り方について問い直すというキーノートでした。 コーディングというプログラマーにとって楽しい作業をAIが巻き取って、仕様を吸い出したり、交渉したり面倒な仕事を人間がやらなくてはならない状況になっていないでしょうか。人間がAIに奉仕するサーバントになっているのではないかという疑問を呈していました。そんな時代にどのようなプログラミング言語が望ましいのか考え直す必要があるのではないか、と投げかけました。

確かに、静的型付け言語であれば、現時点においてはAIは早くエラーを見つけて、自律的に修正できます。しかしながら、AIが十分に賢くなればそのようなエラーは型検査を経ることなく見つけらるのではないかという仮説を提示しました。

また、型エラーは仕様の間違いやロジックの不備に比べれば致命的ではないので、未来において静的に型検査できることは重要な特性ではないと論じます。

一方で、パズルのように型を定義することは楽しい作業なので、それ自体を否定しないとも述べていました。しかしながら、型システムをサポートすることはRubyが目指している「A PROGRAMMER’S BEST FRIEND」になることに繋がらないという価値観をお持ちのようです。

確かに、正常に動作するのに型定義を直すための作業などは不毛に感じることがあるので、その主張自体は筋が通っていると思いました。でも、型をパズルのように定義するのが好きでもあるので複雑な気持ちです。

AIがどのように成長するのか誰も分かりませんし、長期的な視野でRubyが世界を席巻する日が来るのかもしれません。