こんにちは。kickflowプロダクト開発本部の小本です。
2025年4月15日から18日にかけて愛媛県松山市で開催された「RubyKaigi 2025」に、kickflowがシルバースポンサーとして参加した際のレポートをお届けします。
RubyKaigi 2025 概要
今年のRubyKaigiは、愛媛県松山市に国内外から1500人強のRubyistが集結し、熱気あふれるイベントとなりました。
kickflowのスポンサーシップについて
株式会社kickflowは今回シルバースポンサーとして協賛しましたが、人手不足もあってロゴのみの参加となりました。
kickflowも来年か再来年には、ブースを出店したいところです。
セッションで感じた技術トレンド
各セッションを通じて、Ruby業界のトレンドを感じました。
次期Rubyの大型機能は「Namespace」
多くのRubyコミッターが次期バージョン（おそらくRuby 4.0）の主要機能として「Namespace」に言及していました。大規模開発におけるコードの整理や名前衝突の回避に貢献することが期待されます。
型チェック
RBS や Steep といった型チェック関連のセッションは常に多くの聴衆を集めており、関心の高さがうかがえました。Rubyにおける静的型付けは、開発効率やコード品質向上の観点から、ますます重要なテーマになっていくでしょう。
「Prism」の存在感
Prism はRuby 3.3.0からバンドルされた新しい公式Rubyパーサーです。多くのセッションで、Prismを利用したツール（後述するrbs-traceなど）が紹介されていました。Prismの登場により、Rubyコードの静的解析やコード変換を行うツール開発のハードルが下がったと言えそうです。
VSCodeのデファクトスタンダード化
Ruby LSP (Language Server Protocol) の開発が活発で、その主なターゲットが Visual Studio Code (VSCode) であることから、Ruby開発環境においてVSCodeがデファクトスタンダードになりつつあると感じました。
kickflowにはRubyMineユーザーもいるのですが、VSCodeの動向も注視しています。
なお、RubyMineの開発元のJetBrainsもスポンサーとして出展していました。
AI関連の話題は限定的
意外にも、AIをテーマにしたセッションはほとんどありませんでした。
ただし、最終日のMatz氏のキーノートではAIがテーマとして取り上げられ、RubyコミュニティがAIとどのように向き合っていくのか、今後の展望が語られました。
個人的に気になったツール・技術
セッションで紹介された中で、特に気になったツールや技術をいくつかご紹介します。
rbs-inline: RBSをインラインコメントで記述
https://github.com/ruby/rbs/pull/1649 (マージに向けたPull Request)
RBSの型定義を、RDocやYARDのようにソースコード中のコメントとして記述できるようにするツール（または機能）です。.rbsファイルを別途管理する手間が省けるため、型定義の記述とメンテナンスが容易になる可能性があります。次期バージョンのRBSにマージされる予定とのことです。既存のRDoc/YARDコメントからの移行も検討する価値がありそうです。
rbs-trace: テスト実行からRBSを自動生成
rbs-inline と組み合わせて使われることが多いツールです。ユニットテストなどを実行する際に、メソッドの引数や返り値の型情報を収集し、rbs-inline形式のコメントとしてコードに自動挿入してくれます。既存コードへの型定義導入を支援する強力なツールとなりそうです。
quickjs.rb: 軽量JavaScriptエンジン QuickJS のRubyバインディング
QuickJS という軽量なJavaScriptエンジンのRubyバインディングです。mini_racer (V8バインディング) の代替となりうるライブラリです。作者の所属企業ではすでに本番環境で使用されているとのことですが、現状ではタイムアウト処理が実装されていないため、巨大なJavaScriptコードの実行には注意が必要とのことでした。
deprewriter: 非推奨メソッドの書き換えを支援するGem
ライブラリ開発者などが、古いAPIから新しいAPIへの移行を促すためのGemです。非推奨メソッドが呼ばれた際に警告を表示するだけでなく、開発環境で自動的に新しいメソッド呼び出しに書き換える機能を提供します。
# ライブラリ側のコード例 require "deprewriter" class Legacy def old_method(arg) # ... 処理 ... end def new_method(arg) # ... 新しい処理 ... end extend Deprewriter # old_method呼び出しをnew_method呼び出しに書き換えるよう定義 deprewrite :old_method, to: "new_method({arguments})" end # 利用者側のコード legacy = Legacy.new legacy.old_method("value") # => 実行時に new_method("value") に書き換えられる (開発環境のみ)
書き換え処理には synvert というコード変換ツールが内部で使用されています。ライブラリのバージョンアップに伴う破壊的変更への追従コストを低減するのに役立ちそうです。
なお、個人的意見としては、書き換え処理というより、非推奨化を宣言的に書けるメリットが大きいのではないかと思いました。今でも warn で警告メッセージを出すことはできますが、その内容は各人任せなので。
defer: Go言語ライクな後処理記述構文
Rubyコミッターのセッションの中で、将来的にGo言語のdeferを導入する話題がでました。deferは関数の最後に実行する処理を記述する構文です。
def foo f = File.open("...") defer { f.close } # f を使った処理をする # ブロックの最後に f.close が呼ばれる end
Rubyには既にensureがありますが、deferには「openの近くにcloseを書ける」メリットがあります。元Gopherとしては是非導入して欲しいと思いました。
なお，C言語にはdeferを導入する動きがあるようです。
We are hireing
kickflowでは、Ruby on Railsをはじめとする技術を駆使して、ワークフローシステム「kickflow」の開発を行っています。私たちと一緒にプロダクト開発を進めてくれる仲間を募集しています！ 興味のある方は、ぜひ採用サイトをご覧ください。
