RubyKaigi 2025 に登壇した

RubyKaigi 2025 に登壇しました。参加者としての感想も、RubyKaigi 会期に関することは、まとめてこの記事に記しておきます。

自分の発表について
RuboCop Plugin, RuboCop 向け Ruby LSP Add-on, バックエンドパーサーへの今後の展望
印象に残った登壇をいくつか
今後の 362 日
廊下会議や The Tap トラックなどで得られた会話など
ご挨拶や質問し損ねた点
勤務先の永和システムマネジメントとしての活動や、もろもろ
おわりに

当日の発表スライドは以下です。

自分の発表について

満員御礼だったようで、ありがとうございました。自分の登壇を撮ることはできないので @kenchan のツイートから拝借。

#rubykaigi #rubykaigiC @koic 〜 pic.twitter.com/i5ModfAnRT
— 研ちゃんくん鑽Rubyプログラミング (@kenchan) 2025年4月17日

今回は去年話した『RuboCop: LSP and Prism』の続編的な位置付けでした。RuboCop が LSP や Prism を備えたことを背景に、RuboCop 自体にどのようなことを行なったか目玉の3つを取り上げています。

LSP と Prism の続編という意味では、Plugin の話は少し逸れているかな？と思いつつ、現時点でおそらくユーザー影響があるのは Plugin が一番だろうと思いテーマに含めました。結果として話は大きくなり、松山到着の Day 0 で脳内リハをした際には 1 時間近く掛かっていたので、これは巻きで話さねばと話しました。今回の Plugin 対応に関わる設計の中心はこの図に収めたつもりです。興味があればコードと照らし合わせてみると、何か発見があるかもしれません。

いくらか端折る形になった部分もあったため、トークで疑問があれば X でのメンションや Rails/OSS パッチ会などでご質問ください。

ここでは、本編の第3部として話している AST の洞察に関するトークのまとめとして話し損ねたことを書き残しておきます。少なくとも現状における RuboCop が依存する AST のインタフェースは、あくまで Parser gem の AST であり、Parser gem が事実上の機能拡張なしのメンテナンスフェーズに入った現在においても、インタフェースとしての AST は生きています。つまり、Parser gem から Prism に実装が変わってもインタフェースは維持されるので、「実装に対してではなくインタフェースに対してプログラミングをせよ」という GoF (Gang of Four) がデザインパターンで伝えていることは、現代においても重要というものでした。実装よりもインタフェースは長生きするので API 設計や選定重要。

そのうえで、処理系間とツールチェインが同一のパーサーを使うことを Universal Parser と定義するならば、現状の RuboCop は Prism によってそれを実現している状態。一方で、AST は Universal であるべきか？というのは AST 利用者としても関心のある命題。本編では AST は利用者ごとに求める抽象度が異なるのでは？というのが以下の図。

このあたりはふつうに判断が難しい部分なので、引き続き要検討といったところです。少なくとも RuboCop の Parser gem AST を、まったく構造の異なる構文木である Prism AST に置き換える作業は、おもしろくない作業だと思っています。AI エージェントとかそういった発展の先じゃないと、人間が無限に行う作業としてはつらい割に対価が薄いんじゃないかな。どうだろう。

また、RubyKaigi 初日にスマホを壊してしまったため、あまり X や Discord を見れていなかったのですが、今後の Parser gem についての状況としては、Prism translation layer は Parser gem の内部クラスへの依存があるため、すぐに RuboCop の依存先からドロップされるということはないというか削除できません。いずれ、Parser gem を解体して必要なモジュールを適材適所に引っ越しするということはあるかもしれませんが、特に議論が進んでいるわけではないのと喫緊の課題ではないため、追々必要があれば検討がされていくと思います (余談ですが Prism translation layer から parse.y への依存は現時点でもありません) 。

ひとまず、RuboCop のバックエンドのデフォルトパーサーでユーザーの裏で動いているのは、Ruby 3.3 までは Parser gem であり、Ruby 3.4 では RuboCop 1.74 以前のデフォルトは Parser gem で、RuboCop 1.75 以降のデフォルトは Prism translation layer となっています。少なくとも Parser gem は実質開発が止まったため、今後は Prism translation layer で解析されていくでしょう。

発表後には、RuboCop コアチームメンバーで RuboCop RSpec のヘッドメンテナーをしている Benjamin Quorning とも会えたというのが今回。

コアチームだと、RubyKaigi 2018 で Bozhidar Batsov と会って、最近だと RubyConf Taiwan 2023 やその他何度か Ted Johansson と会ったりしましたが、こういったカンファレンスは GitHub でのみ知っているという開発者をリアルで知れるのは面白いところ。Benjamin は pocke さんと会いたかったみたいで繋げたかったのですが、1,500 人のカンファレンスだとなかなか難しい。1,500 人本当にすごい。

RuboCop Plugin, RuboCop 向け Ruby LSP Add-on, バックエンドパーサーへの今後の展望

Plugin について、Shopify の ufuk から rubocop-sorbet でプラグイン化による lint_roller 依存でちょっと困っていることがあるような相談があったけれど、残念ながら私の英語力では問題認識は概ねわかったものの、それは本当に問題だろうか？といったところで、うまく答えることができなかったなあというところ。ただ、rubocop-sorbet としての問題だと思うので、RuboCop としてそれを機にドラスティックな何かというのは今の段階だとなさそう。

Ruby LSP Add-on については、何か行なっていくとすると、まずは組み込み LSP のクライアントとなる vscode-rubocop の方で textDocument/codeAction 対応をした後に、組み込み言語サーバー側の方で Ruby LSP にしかない不足機能を足すということを行うかなといったところ。以下の図で表すように、Ruby LSP Add-on へのエンジン共通化に向けた基盤はできたので、良い感じに機能面を統合できると良さそう。

バックエンドパーサーの方は、Prism ならびに Prism translation layer へのバグ報告がくることがあるので、その対応やトリアージなんかは平常運転の範囲内で見るつもりです。

ただ、これらは基本線はひと段落しているものと捉えており、現時点での個人的な関心事は LLM 周辺の領域と Ruby のあいだにあるので、気が向いた時にという感じで行うと思います。こういった OSS 活動は趣味なので、軸を持ちつつ気の赴くまま。

印象に残った登壇をいくつか

聞いたセッションぜんぶは書けないのですが、ひとまず筆が動く部分について書きます。

ima1zumi さんのキーノート

ima1zumi さんのキーノートはとても良くて、The Tap あたりでもご本人に話したように、おそらくはじめて ima1zumi さんを認識したのは家族の絵文字の一家離散のツイートで、おもしろいことする人がいるなあというのが始まり。その後、同僚の頃には文字コードや文字エンコーディング好きとして Ruby にどんなことができるかというのを考えていたのを見てきているし、そういった Rubyist としての ima1zumi さんの集大成といった話で心に響く良いキーノートでした。

私自身も職業プログラマーとしてキャリアのはじまりに EBCDIC に触れることになってしまっていた経歴があるのですが、そこでエンコーディングに対してより深い関心や楽しさを持てるかどうかで人類は別れ道があるんだなあ (当時だとなんで ASCII じゃないだとか、仕事の範囲で止まっていたのを思い出す) 。次回作にも期待しています！

TRICK

TRICK はどれもすごかったけれど、個人的に一番感動したのは mame さんの、git log --oneline を使った TRICK 芸。git は 365 日使うわけで、そんな毎日使っている馴染みのツールと組み合わせた実行方法という、聞けばわかるけれどそもそもの発想がすごくて、これが天才か。。。というものが本当にすごかった。

人類には2種類いる、人類と人類でないもの、ということを改めて認識しましたが、TRICK の人たちは本当に後者ですね。

Lightning Talks

LT は勤務先の大先輩である卒業生の kkd が LT とは？なぜ銅鑼？という話をされたのが良かった。その後の LT としては、ydah さんや makicamel さんの発表は特に良かった。makicamel さんは個人的には今年開催された東京Ruby会議12の (前夜祭込みでの) ベストトーカーでしたが、今回もトークのセンスが素晴らしくてさすがでした。

kkd のトークについて、「あれ？」と思ったのは kkd 自身があまり Rubyist の外の人っぽい感じで話しているのが他人行儀だなあという感じがある点でした。これを言えるのは数少ないと思うので、ここの日記に書き残しておきたいのですが、私が現職に入社した 2004年11月の社員旅行で kkd と出会い Ruby の話で盛り上がり、2005年4月1日に発行された勤務先のメルマガに「【News】Rubyが制約言語に正式採用へ」という記事を書いているくらいに、Ruby と関わりが長い古参の Rubyist です。

objectclub.jp

この記事は 4月1日発行ということでエイプリルフールなわけですが、今回 Matz が Ruby 4.0 のリリースについて 2025年4月1日のエイプリルフールにツイートされ、20 年越しのエイプリルフール繋がりで LT の壇上で銅鑼を叩くとか個人的にエモかった。RubyKaigi すごい。

sue445 さん

sue445 さんの話は、Ruby で Go 拡張できるようにするために、想像していたよりもはるかに多くのことを行っていたり、その副産物をライブラリ化したりなど、長い年月で積み重ねてきた感ある話でさすがでした。ひとつの目標を立てて、うまくいくこともあればないこともあるのはそうなのですが、きちんと時間を使って目標に向かって取り組み続けているのが、sue445 さんのキャラクターもあいまって、RubyKaigi は趣味を本気で突き詰めている人たちだなあと思いました。

ぺんさん

ぺんさんの話は、Prism が出てくるところもあり、自分以外でも Prism の使い勝手どう？みたいな話としてされている点として興味深く聞いていました。その後にも、ぺんさんと話したりしたのですが、Linter / Formatter はひと区切りついた、通常は妥当なシンタックスのコードを相手にできるものですが、IRB のような REPL だと入力中の不完全なコードを相手取る必要があり、そのあたりの難易度は上では？と改めて聞いていて思いました。多角的な考察の上にどうデザインされると良いかという思考も改めて参考になりました。ぺんさんは本当にすごいひと。

The Parser gangs

yahonda さんの言葉を借りれば、Parser gangs (金子さん、ydah さん、junk0612) は去年よりも、LR パーサーによって Ruby の世界をどのようにしたいかが見えてきたトークだったと思います。個人的には ydah さんの発表で最後に出てきた、Prism 互換の部分について「お、ついにそこに手が動くのか」といったところ。

金子さんとは今回あまり話せなかった気がするので、そのあたりは SmartHR さんの事後勉強会あたりで話したりあるかも？

今後の 362 日

最近は LLM が関心事として高くなっているところ、期せずして Matz のキーノートでも AI が取り上げられていたこともあり、引き続き AI 時代の Ruby の在り方みたいなものはひとつのテーマとして見ていくかもしれません。LLM の Fine-Turning となると Python という話になる気がするのですが、自分の発表中で少しだけ触れた RAG, LangChain, MCP あたりをキーワードとしたアプリケーションやライブラリと LLM の間というあたりはまだ Ruby としてフロンティアに近い部分もあるのでは？と見ていて研究中。次回に向けては、そのあたりをやるかもしれないし、それ以外かもしれない。いずれにしてもしばらく LLM について研究するかなというところです。次回作にご期待ください。

廊下会議や The Tap トラックなどで得られた会話など

伊尾木さんや江渡さんといった10年以上ぶりにお久しぶりですのご挨拶ができたり、今回初めて RubyKaigi に参加したという Rubyist と話せたりと、新旧の時代を楽しめる感じのイベントでした。

会場の廊下を歩いていたら、youchan が gibier (ジビエ) が WASM 2 対応で gibier2 (ジビエ2) になったと、実はジビエのゴッドファーザー (命名者) の私に教えてくれました。どこの居酒屋だったかは忘れてしまったのですが、本当に酒の肴で須藤先輩の Rabbit を打倒するプレゼンテーションツールを目指すという話題から生まれた名前が、後年の RubyKaigi にジビエ2として登場するいうまさかの展開で、Rubyist 同士の会話はどこでどう未来の RubyKaigi につながるか分からないので、Ruby のミートアップでは色々な人と色々と話してみると面白いと改めて思いました。

高橋会長とは、The Rails Doctrine の日本語訳を upstream に送るのはどうかという話をすることができました。長らく話そうと思って失念していたことだったので、状況を伺えて良かったです。

えにしテックの島田さんとは、『Programming Ruby 3.3 (5th Edition)』の翻訳プロジェクトへのスポンサーについて話を伺えました。この翻訳プロジェクトは Ruby コミュニティとしてとても意義深いものだと思いますので、興味のある方は一読のうえ、ぜひ島田さんにコンタクトを取ってみると良いと思います。

Day 3 の個人的 Extra Track である The Tap で、藤浪さん (makenowjust) と初めてお話しできた。以前頂いていた RuboCop への問題のある正規表現を検出する cop の提案について、bad ケースを検知しても、good ケースへの直し方がユーザーはわからなさそうで、RuboCop で検知しても無効化されということになりそうで、実用的に難しそうという点を話したりしていた。藤浪さんとしてもそのあたりはドキュメント化か何かで伝えられると良いのだろうかと、課題について共有できました。

ご挨拶や質問し損ねた点

挨拶し損ねたのは、まず Matz への還暦へのおめでとうございますを伝えられなかったこと。勤務先で配布していた『Ruby on Timeline』には「Matz の誕生」というカードがあり、その許諾確認を junk0612 から行ってもらったのですが、二つ返事でご快諾いただいたと聞いています。そのお礼や諸々の感謝を伝え損ねたなあと。また sylph01 さんは RubyConf Taiwan が一番話すタイミングという不思議な仲ですが、今回の地元開催にあたっての本気度への感謝を伝え損ねたなあ。

kenchan が mcp-rb にパッチを送っていたのを見ていたので、その背景にある LLM の話をしてみたいなあと思っていたのに、すっかり忘れいていたのだった。kenchan とは RubyKaigi 以外でも会おうと思えば会えると思うので、機会があればどこかで話したいところ。

勤務先の永和システムマネジメントとしての活動や、もろもろ

勤務先のノベルティとして配布していた『Ruby on Timeline』のパッケージ裏にあるバージョン v69.83.77 には実は意味があります。mame さんはこのバージョンについてノーヒントで10秒かからず解かれました。mame Ruby はやはり世界屈指の処理系を備えた頭脳で、慄くしかなかったです。ほんとうにすごい。興味のある方は v69.83.77 というバージョンという仕掛けについて、考えてみてください。

永和謹製『Ruby on Timeline 』ゲーム入手は、 #rubykaigi 会期中 @junk0612 @color_box @fugakkbn @haruguchiyuma @kasumi8pon @m_pixy @maimu @nsgc @wai_doi S.H. や私にお声がけください。還暦をお迎えされた @yukihiro_matz さんの誕生もタイムラインに入っています！ (おめでとうございます！) pic.twitter.com/3KnEgPbi9O
— Koichi ITO (@koic) 2025年4月14日

今回入手できなかった方は、別の機会に配布する予定がありますので、またそちらでお会いしましょう。

ESM Drinkup では、fukui.rb の taketo さん (通訳ありがとうございます！) が「RuboCop LTS を作ったよ」という pboling を紹介してくれて話を聞いていました。RuboCop にはランタイムバージョン (2.7 以上をサポート) と解析バージョン (2.0 以上をサポート) という2種類のバージョンの概念があり、Prism が Ruby 3.3 以上が解析バージョンということもあり古い解析バージョンをいつかドロップしようという声を聞くことがあります。今回のユースケースを聞いて、現状ではそんなメンテナンスが大変なわけではないので、古い解析バージョンのサポートは維持した方がいいよなあと改めて思いました。

余談ですが、Prism の translation layer は Parser gem の Builder などに依存していて、Ruby 3.2 以下をドロップしても現状の Parser gem 依存はそのままでは削除できません。これは時間の都合で説明を割愛していたと思うのですが、今回の私の登壇では以下の図で Prism translation layer が Parser gem に依存している関係を示していました。

で、逆説的に Ruby 2.0 までをサポートしようと思うと、Parser gem は Prism のことを知らない (依存していない) ため、RuboCop を Parser gem AST から Prism native AST に変えることはできません。つまり Ruby 2.0 までの解析サポートを維持するという方針であれば、改めて Parser gem AST を Prism native AST に置き換える意味とは？になるのでした。感想記事を書くと、いろいろと整理されてきますね。

kkd や hidenba といった XPJUG っぽい組み合わせでの会話もできて良かったです。

おわりに

Matz のキーノートが印象的で、今後のお仕事に向けたお話し的にも、生成 AI と Ruby というあたりは個人的にちょうど一番ホットなテーマでした。DD4D の帰りに何人かと話していたのですが、生成 AI 時代の Ruby の言語デザインがどうなっていくか、言語デザイナーのまつもとさんの動きを楽しみにしています。

また、ビアバー The Tap には滞在中4泊5日のうちの3日間を、遅い時間までありがとうございました。限られた時間の本編では話せなかった廊下テックトークやいろいろ多く話せる機会になりました。

来年の RubyKaigi 2026 も楽しみです。オーガナイザーのみなさん、スタッフのみなさん、ありがとうございました！