はじめに
こんにちは！Webアプリケーショングループの羽鳥です！ 愛媛の松山で開催されたRubyKaigi 2025に弊社のメンバー5人で参加してきました！
以下は参加したメンバーによるレポートです。
参加メンバーによるレポート
羽鳥
前回の沖縄で開催されたRubyKaigi 2024に続き、2回目の参加でした！（前回の参加レポートはこちら）
今回、印象に残ったセッションは以下の2つです。
一つ目は、mameさんによるWriting Ruby Scripts with TypeProfです。
TypeProfとは何かと、その使い方についてお話しでした。 TypeProfは型アノテーションなしで、エラー検知・定義ジャンプ・補完機能をサポートするVS Codeの拡張機能です。
前回参加したRubyKaigi 2024のGood first issues of TypeProfで初めてTypeProfの存在を知り、面白いなと思っていたので今年も発表を楽しみにしていました。
私はTypeProfが型アノテーションが不要という点がとても魅力的だと思いました。型を推論し、薄くエディタでサポートしてくれる点が好きです。
セッション終了後にmameさんに感想を伝えると、詳しい内部動作についてはRubyKaigi 2023で発表した内容を参照してほしいとアドバイスいただいたので、読みたいと思います。このように直接お話しできることがRubyKaigiの楽しみでもあり、魅力でもありますね。
二つ目は、tompngさんによるAnalyzing Ruby Code in IRBです。
irbに入力されたコードをどのようにして解析するかというお話しでした。
シンタックスハイライトは以前はRipper::LexerのTokenで解析して色付けしていたが、PrismでそのTokenとSyntax Treeで解析するようにしたそうです。
個人的にはPrismはパーサだと認識していたので、lexもできることに驚きました。 PrismはRuby3.4からデフォルトパーサになり、様々なシーンで利用されていることを確認できて面白かったです。前述のTypeProfにも利用されています。
irbがこんなにも便利なのは、コミッターの皆さんのお陰だと実感できました。いつもありがとうございます！
全体の感想としては、セッションの内容をとても興味深く、楽しく聞けたのでよかったです。前回のRubyKaigi 2024に参加したが何も分からなかったので、事前に予習をしてきたのが功を奏しました。 毎時間ごとに気になるセッションがあり、途中の休憩以外はずっと聞いていましたが、あまり疲れなかったです。ただ、ずっとセッションを聞いていたこともあり、あまりスポンサーブースを回れなかったのが心残りです。
伊尾木
かなりの久しぶりにRubyKaigiに参加したテックリードの伊尾木です。
いくつかのセッションの簡単な感想をつらつらと書いていきます。
Make Parsers Compatible Using Automata Learning
オートマトン学習を利用してパーサー同士（e.g. Prism vs parse.y）の能力の比較を行おうという発表でした。 2つのパーサー同士の能力を比較するのは、多くのテスト用のコードをパースさせてその結果を比較するという手法が考えられます。 ただし、これではもちろん十分じゃないですね。テスト用のコードから少し外れたコードだと全く違ったパース結果が出力されるかもしれません。
というわけで、この発表では、オートマトン学習を用いて、パーサーをオートマトンに変換する（推測する）というアイデアを採用していました。 雑にいってしまえば、テスト用コードはあまりにも点のチェックになってしまうので、それをオートマトンに変換（推測）することによってもう少しカバーできる領域を大きくしてチェックしようという話です。 これはなかなか面白いなと思いました。 実際、これでPrismの間違った部分を見つけることができたようです。
Goodbye fat gem 2025
fat gemというのは、gem内に各環境ごとにビルドされたバイナリを持つgemのことで、そのfatを止めようっていう話でした。
印象的だったのが、gem開発は大変だなぁっというのも、もちろんあるんですが、それ以上にRuby全体のエコシステムとしてのあり方を訴えている点でした。 fat gemの整備の労力が大きくて、fat gemのリリースが遅れてgem利用者にも不利益がでていると指摘されていました。 さらにfat gemの労力が嫌でgem開発から人が離れるんではないかとも指摘されていました。 これはfat gemに限らずすべてのOSSに言えることで、エコシステムとして言語開発者・OSS開発者・利用者を含めて全体で幸せになる方法を模索していくことが重要だなっと考えさせられました。
Improvement of REXML and speed up using StringScanner
REXMLの開発において、正規表現を利用してXMLをパースするよりも、StringScannerを使うとグッとスピードアップしたよっていう報告でした。
StringScannerも正規表現を受け取るので結局単純なマッチ処理に関しては同じことをやっているはずなんですが、正規表現を生で使うとマッチオブジェクトを作ってしまい、それがスピードに影響するということでした。 これは、すぐにでも使えるテクニックで、勉強になりました。
How to make the Groovebox
RubyでGroovebox（音楽制作ツール。シンセサイザーやシーケンサーなどが一体化されたもの）を作ろうという発表でした。 Rubyで作ってしまうというのも面白かったんですが、ドラムなどの音源も自作されていて、その音がめっちゃカッコよかったです。 さすが asonas さん。
RuboCop: Modularity and AST Insights
Rubocopは、カスタムCopを作れるんですが、その拡張の内部実装がモンキーパッチになっていたので、プラグイン機構を導入したという話でした。 Rubocopみたいに歴史があるgemでも、そういう部分があるんだなぁっと、なんというか「そうやんね〜〜」っという気持ちになって聞いていました。
さらに、Prism対応をどうしようかという話題もありました。確かにパーサー変われば大きな影響受けますよね。 その中でCSTを使うのどうかみたいな話もあり、とても興味深かったです。
ちなみに、この日の夜のDrink upにたまたま koic さんと一緒になったので、その後2次会として久しぶりにお話しできたのが嬉しかったです。
Toward Ractor local GC
RactorごとにGCを実行する local GCは、早くていいんですがRactor同士で共有する shareable objects が問題になるけど、どうしようっていうお話しでした。 この対応として、シンプルにlocal GCでは、shareable objectsのGCはせずに、shareable objectsは適宜全部のRactorを止めてGCするというようなアイデアを発表されていました。
シンプルなアイデアですが、結構スピードは向上するようでした。なんだかJavaの世代間GCのアイデアと似ているなと思って、 _ko1 さんに話しかけたら、似たアイデアだとおしゃっていました。 このアイデアの前にも色々なアイデアを数年試されていたようで、いやぁGCの実装も大変ですよね...
その他
個人的な話ですが、ここ10年くらい食文化研究者として頑張っていたので、こういう技術系イベントへの参加が本当に久しぶりでした。 なので、会う人会う人が久しぶりでみなさんから「珍しいですね！」と声をかけてもらえました :-) なんだか同窓会に来たような気分になり、とても楽しいイベントでした。
技術系イベントへのモチベーションもあがってきたので、弊社も色々発表などを頑張っていきたい所存です。
隅山
クライアントグループの隅山です。 普段はFlutterでモバイルアプリの開発をしていて、最近はRubyも勉強中です。 今回はその一環として、初めてRubyKaigiに参加してきました。 印象に残ったセッションをいくつか紹介していきます。
Ruby Taught Me About Encoding Under the Hood
モバイルアプリの開発をしていると、文字の描画まわりでつまずくことが時々あります。 これまで文字コードについて深く掘り下げて考える機会はあまりなかったので、今回のセッションはとても勉強になりました。 特に印象に残ったのは、同じように見える文字でも一文字として表現されている場合と基底文字と結合文字の組み合わせで複数の文字として構成されている場合があるという点です。 RubyKaigiの一発目の発表だったこともあり、文字の歴史に触れながら丁寧に説明されていたので、とても聞きやすく印象に残るセッションでした。
Introducing Type Guard to Steep
普段のモバイル開発では静的型付け言語を使っているため、まずはRubyのような動的型付け言語がどうなっているのかを知る良いきっかけになりました。 このセッションではRubyでどのように型の絞り込みを行っているかの説明があり、さらにそれをSteepにType Guardとして取り入れているという内容でとても分かりやすかったです。 Rubyが型に対してどういう考え方を持っているのかまではまだ理解しきれていませんが、Ruby初心者であり静的型付け言語から入った自分としてはSteepのように最初から型がある方が理解しやすいと感じました。 一方で、型がないからこそ得られるRubyのメリットも多くあるのだろうなとも思い、改めて言語ごとの設計思想の違いを考えさせられるセッションでした。
まとめ
モバイル系のカンファレンスと比べると、RubyKaigiはより技術を深く掘り下げたセッションが多い印象を受けました。 中でも特に印象に残っているのが、TRICKのセッションでした。 Rubyを使って遊び心のあるコードを披露する内容で他のカンファレンスではなかなか見られないユニークさがあり、とても記憶に残りました。 セッション以外にもブースを回ったりアフターイベントに参加して他の参加者の方々と交流したりする中で、Rubyに対する熱い思いや他の会社ではどんな取り組みをしているのかを知ることができ、とても有意義な時間を過ごすことができました。
外囿
Webアプリケーショングループ25卒のホカゾノです。RubyKaigiに参加した感想と、勉強になったセッションについて書きます。
勉強になったセッション
勉強になったセッションは“Automatically generating types by running tests” です。発表者の Takumi Shotoku さんが紹介した rbs‑trace は、テスト実行中に TracePoint でメソッド呼び出しを監視し、引数と戻り値のクラス名を収集して、そのまま # @rbs コメントとしてソースコードに書き込んでくれるツールです。導入は簡単で、gem 'rbs-trace' を test グループに追加し、spec_helper.rb に trace.enable と trace.save_comments を挟む 3 行を記述するだけで済みます。あとは RBS_TRACE=1 rspec を実行すれば、テスト終了時には型コメント付きのファイルが手に入ります。Redmine や Mastodon での計測ではテスト時間が 2 分から 12 分、45 秒から 3 分と 4〜5 倍に延びてましたが、CI で一度だけ走らせて RBS をアーティファクトとして保存し、ローカルでは rbs-trace merge と inline を使って差し込む運用にすれば実害はほとんどありません。
型について改めて考える
このセッションがきっかけで、型について改めて考えることになりました。RubyKaigiで他の型関連セッションを見ていて、「静的な型チェックは大規模開発でこそ威力を発揮する一方、言語の思想や運用を考慮しないと現場で使われにくい」という現実を痛感したからです。
まず、Rubyは「楽しさ」を最優先に設計されており、PythonやRubyに慣れた私にとって、Rubyで型を書く作業にはあまり慣れていませんでした。次に実行時コストの問題があります。たとえばrbs-traceではvoid返り値を判定するために追加解析を行う分、テストが遅くなり、生成済みの型コメントが再実行で上書きされない運用課題も残ります。これらのハードルを考えると「Rubyに型を導入すべきか？」という疑問が湧きました。
しかし、「テストを回すだけで静的な型が定義される」というrbs-traceのアプローチは、言語の楽しさと運用現実の双方を意識した落としどころだと感じました。手書きは無理だと諦めていた既存プロジェクトでも試す価値があるかもしれません。
まとめ
最後に、RubyKaigiに参加して本当によかったと感じました。これまで業務でしかRubyに触れてこなかったのですが、会場では参加者が楽しそうにRubyの話をしており、その光景がとても新鮮で印象的でした。他社ブースでは採用の取り組みや扱っている技術について直接聞くことができ、交流を通じて多くの刺激を受けることができました。
Rubyコミュニティは本当に多くの人に支えられ、その活動自体を「楽しい」と感じている人がたくさんいるのだと実感しました。職場の枠を越えて他のエンジニアと関わることで、自分の視野を大きく広げることができた貴重な体験でした。また来年も参加したいと思います！
田嶋
2025年新卒のソフトウェアエンジニアとして初めてRubyKaigiに参加しました！
RubyKaigiに参加した感想を簡単に表すと、「Rubyコミュニティの熱気がすごい。そしてセッションの内容のレベルが高い！」
絶対に来年・再来年も参加しようと思いました。
印象に残ったセッション
印象の残ったセッションは、Day1のKeynoteであるima1zumiさんの「Ruby Taught Me About Encoding Under the Hood」です。
このセッションは文字コード・エンコーディングに関するセッションでした。
普段、何も意識することなくコンピュータに文字を入力・閲覧・送信・受信できていますが、このセッションでそれが当たり前のことではないことを実感しました。
1991年にUnicode1.0がリリースされるまでは、国や地域によって使用される文字コードがバラバラで同じバイト列が違う文字に解釈されてしまい、文字化けが起こるのは当たり前な状態になってしまっていたが、Unicodeがリリースされてからは世界中の言語の文字を一意に表示することができるようになった時代の変遷を聞いて、そんな大変な時代があったのか・・・と思いながら聞いていました。
また、面白かったのがirbで家族絵文字「🧑🧑🧒🧒」を入力して、BackSpaceをして実行するとクラッシュしてしまう問題についてです。
普通は1文字換算のはずが、なぜか7文字換算になってしまうみたいです。
その理由は、家族絵文字の中身が7つの文字コードで構成されているためでした。
この問題をima1zumiさんがRelineの修正をすることで解決したお話を聞き、すごい行動力・遂行力だなと感じました。
普段全くと言っていいほど気にしない部分ですが、歴史を辿ったり実際に中身深くを見ていくとこんなにも奥が深いものなのかと非常に驚いたとともに、これから低レイヤーの話もできるよう、新卒として日々の業務を丁寧にこなしていきたいと改めて感じることができました。
出展ブースについて
今年のRubyKaigiは46の企業等のブースが出展されていました。
来場者が各ブースを回るような施策としてスタンプラリーがあったのですが、見事に全部回りました。
各企業さんがクイズや独自ゲームなどを用意しており、それに応じたノベルティの配布もたくさんあり、最終的には両手にパンパンのトートバックを持つ状態でした。
スタディプラスは今回ブースの出展はなかったですが、来年はブースの出展したいと考えています。
現地のご飯や観光
鯛めし もとやま
愛媛といったら鯛！ということで何回も鯛めしを食べました！ 特に美味しかったのが、松山城近くにあるもとやまさんの鯛めしです！ 卵醤油に薬味と鯛を自分好みに入れてそれをご飯にかけて食べるスタイルの鯛めしだったのですが、美味しすぎて全員おかわり必至でした。じゃこ天もつけて愛媛感満載です！
つけめん 倉木
スタディプラスのエンジニアは麺好きが多いので、地元で人気なつけ麺にもいきました！ コシがある麺にモツ煮がゴロゴロ転がってるスープにダイブ！評価が高い理由がちゃんとわかりました。
道後温泉
愛媛は全国屈指の温泉地！道後温泉です！ 館内の方の接客も非常によく、もちろん湯加減もよく、その日の疲れが全部飛んで行きました！
四国カルスト
RubyKaigi終了後、土曜日に四国カルストに行きました！ 四国カルストならではの石灰岩の奇岩はもちろん、四国山地の山々が連なる景色は本当に絶景でした。
まとめ
今回のRubyKaigiの参加で本当に様々なことを得ることができました。 Rubyの温かいコミュニティの中で切磋琢磨することで今後のエンジニア人生も薔薇色になると確信しました！ 来年は4/22〜24に北海道の函館で開催ということで、既にワクワクしています！
おわりに
Rubyって改めて面白いプログラミング言語だな、もっとRubyについて知りたいなと思えるような素敵なカンファレンスでした。 スタッフ・登壇者・参加したRubyistの皆さん、本当にありがとうございました！
