はじめに
2025年4月16日から18日にかけて愛媛県松山市で開催されたRubyKaigi2025に参加してきました。リンクウェルにジョインしてからは4回目のイベント参加となります。今回は会社として初めてRubyKaigiでブースを出展することとなり、いつもと違うRubyKaigiを楽しむことができました。
そちらの模様は他社ブースに学びあり。広報が歩いたRubyKaigi2025と初出展の記録でご覧ください。
私とRubyKaigi
少し個人的な話をすると、RubyKaigiおよび地域RubyKaigiは2010年あたりから度々参加してきました。RubyKaigi2016から東京以外の地域での開催となり、毎年RubyKaigiを理由に全国津々浦々に旅するようになり、多くの人や美味しい食べ物、地域の文化に触れる良い機会となりました。
この度、所属する組織としてブース出展が決まったときから準備を進めてきました。当初は心配でいっぱいだったのですが、弊社メンバー一丸となって準備に取り組み大盛況でイベントを終えることができました。ブースに来てくださった方、イベントのオーガナイザーの方々、そして弊社のイベントに関わってくださったみんなに感謝の言葉を伝えたいです。
セッションレポート
Day1
Ruby Taught Me About Encoding Under the Hood
IRBで 👨👨👦👦を入力してバックスペースを押すとクラッシュするという不具合を修正したことで、文字コードについて深く追求したというお話でした。私も知らなかったのですが👨👨👦👦（ファミリー）の絵文字は複数の顔文字から構成されているそうです。
# 手元で作った簡単な再現コード
str = "👨👨👦👦"
str.each_char do |char|
puts "文字: #{char}"
end
# 実行結果
文字: 👨
文字:
文字: 👨
文字:
文字: 👦
文字:
文字: 👦
発表の中で腕木通信の歴史やEBCDICコードのシフトイン・シフトアウトの説明などに触れられており、通信の歴史についても興味深い内容でした。今までRubyKaigiではUnicodeについて青山学院大学のマーティン先生から多くの事を学んできましたが、Unicodeが誕生した経緯や歴史についてまた一つ学ぶことができました。
Goodbye fat gem 2025
特定のGemが動作するために必要なライブラリをすべて内包しているfat gemはビルドエラーが発生しにくくとても便利なものです。しかしGemのサイズが大きくなってしまったり、セキュリティに問題があるライブラリのアップデートが困難であったり多くの問題を抱えています。メンテナの労力に頼る今の方式だと、いずれはGemのメンテナが減ってしまうという問題意識から、WindowsのRubyInstaller2を参考にこの問題にどのようにアプローチするかという興味深い内容でした。
将来的にはインストールが容易でサイズが小さいGemを構築する仕組みができるとよいですね。
State of Namespace
Rubyには他言語で一般的となっている名前空間が存在せずグローバルに展開されます。これはUserやCustomerなど一般的によく使われるクラス名をGemで利用できないことを意味します。
RubyにおけるNamespace実装が完成すれば、GemでのNamespaceを一定のスコープに閉じ込めることができ、バッティングを気にすることなく名前がつけれるようになります。
発表ではRubyKaigi2024のRubyKaigiでの発表から大きく内容は変わっておらず、現在はリリースに向けてデバッグを行っているとのことでした。
この発表の後で今年のクリスマスにリリース予定のRuby4.0で試験的に実装されるとの発表がありました。
dRuby on Browser Again!
dRubyとはRubyで分散オブジェクトを実現するための機能です。クライアントサーバーシステムが主だった2000年代は各種言語でこの機能が利用されており、私もかつてはC#を使って同様の機能を使ったサービスを開発していました。今回の発表ではwasmでdRubyを動かす2つの試みについて聞くことができました。
JSONによる文字列のパースを行うことなくRubyのオブジェクトを直接扱うことができるdRubyはwasmでRubyが動作する現在において魅力的な通信手段だということを再認識することができました。
Day2
Writing Ruby Scripts with TypeProf
TypeProfを使ってエディタ上で定義ジャンプ、メソッド補完、リネームが利用できるという発表でした。
設定ファイルでエディタの警告表示など細かく指定できるようでとても便利そうです。
発表者の遠藤さんの「すべての型を書かなくても良いと思いつつも、Gemやpackwerkのパッケージなどディレクトリをまたぐ箇所はrbsファイルを書いてもよいのではと思ってる」という言葉は、型とのちょうどよい付き合い方のヒントとなりました。
Speeding up Class#new
我々が日常でよく使うClass#newの高速化に取り組んだお話でした。
Rubyのクラス探査は元々インラインキャッシュによる高速化が図られていましたが、キャッシュにヒットしない場合のパフォーマンスの低下が大きいことが問題でした。
Class#newはC言語で書かれており、実行時にRuby => C => Ruby と言語をまたぐタイミングでオーバーヘッドが発生するそうです。これはRubyとCの呼び出し規約が異なっており、変換が必要であることが原因です。これをRubyによる実装に置き換えることで高速化が図られるそうです。ただ、デメリットもありわずかなメモリの増加およびスタックトレースの出力の変更が生じるとのこと。
感想ですが、Railsでは多くのclass#newが発生しており、チリツモで大きなパフォーマンス改善が期待できそうです。
Making TCPSocket.new "Happy"!
RFCで定義されているHappy EyeBall Version2をRubyのTCPSocket.newに実装するお話でした。Happy EyeBall Version2とはIPv6で接続できなかったときにIPv4で接続するためのフォールバックの解決として、名前解決をIPv4とIPv6の両方で同時に開始する仕組みのことです。
セッション中に発表者のShioiさんのプルリクを眺めながら聞いていたのですが、時系列でどのような改修をおこなったのかよく理解できました。
Day3
Ruby Committers and the World
毎年楽しみにしているRubyコミッターたちの座談会。今回は以下のテーマが話されていたようです。
- Static Barrierの是非
- ある時点でバリアを定義すると、その後は変数の再定義ができなくなる機能。バリアをプロセスグローバルで実施するか、範囲を限定するかという点について議論されていました。グローバル展開しないとフラグをメモリ上にたくさん展開する必要があるため、処理が複雑になるという話でした。
- Namespace
- この時点では「近い内に導入する」という内容でした。（後にRuby4.0で導入されることが決定）
- GemをロードするときにNamespace内に入れるなどを考えているが、リリースの時点では「とりあえずいれる」という感じになりそう。Gemなどの調整は間に合わないとのことでした。
- Ruby4.0で消したい機能
- namespaceが入ったらrefinementはけしたいかもとのこと。後に作者の前田修吾さんが弊社ブースに来てくださり、少しお話させていただきました。その時のお話ではRailsで一部のクラスのみ上書きするようなシーンで使われているケースがあるとのことでした。
- AIを使ったRubyの開発
- Railsは同じようなコードが大量にネットにあるが、RubyのコードはRubyのコードしかないので、それを元に改善はできないとのことでした。
The Ruby One-Binary Tool, Enhanced with Kompo
Rubyのコードをワンバイナリで動かすためのcompoというライブラリのお話でした。これを利用すると実行環境にRubyのセットアップが不要となるため、アプリケーションの配布が容易になります。2024年の発表ではファイルをloadしてまるっとevalするような作りだったため、Railsのような複雑な仕組みは動かすことができなかったが、仮想ファイルシステムを実装することで回避できたそうです。
On-the-fly Suggestions of Rewriting Method Deprecations
Railsを使った開発でよく遭遇するDeprecation Warningのスマートな解決方法についての話でした。現在は新しい書き方の示唆をテキストで表示するだけですが、PharoというSmalltalk系言語のDeprewriterという機能を参考にして自動的に新しい書き方に書き直してくれる機能の提案を行っていました。Ruby版Deprewriterは実行時にコードを書き換える機能です。実行時と聞くと本番環境でコードを書き換えるように聞こえますが、様々な動作モードが提供されておりCI環境やローカル環境でもコード移行ができそうでした。
Matz Keynote
なんとせり上がりステージからMatzが登場という今までにない演出で最後のキーノートが始まりました。
3日間さまざまな発表があったがAIに関する発表は無かったことに触れ、AI時代にマッチする言語とは何かというテーマでお話されました。
AIにおいては、「AIに使われている」ことは本当に楽しいのか。「AIを使うこと」で得られる楽しさ、もっとその楽しい部分を存分に味わえないか。静的型に関しては、型を書くことは楽しい作業ではあるものの、それがRubyを書く楽しさに直接つながるのか。という点に触れ、記述が簡潔、多様な表現力、拡張性があるRubyという言語のAIへの適用性の高さをアピールしていました。
感想
私は Rubyを使って 日常的に開発している人間です。RubyKaigiはRubyを作る側の話が多く週明けから業務にすぐさま反映できる話題は少ないです。しかし、このイベントへの参加の醍醐味は 未知の未知 を減らすことだと考えています。Rubyを取り巻くエコシステムがどのような仕組みで構成されているかをキーワードだけでも知ることで、全く知らない聞いたこともない 未知の未知 から 既知の未知 に変えることができます。
今回のRubyKaigiではRubyが抱える問題点や、これから歩むべき道筋を知ることができ、弊社のプロダクトの長期的な意思決定にいずれ役立つと感じました。
来年函館で開催されるRubyKaigi2026でも弊社はブースを出展する予定です。弊社に興味がある方は、ぜひブースにてRubyやRailsの未来についてお話しましょう。
Discussion