はじめに
こんにちは、ITANDI株式会社でエンジニアをしているたのもきです。
2026年4月22日〜24日にかけて函館で開催された「RubyKaigi 2026」に参加してきました！
さすが北海道ということもあり、会場が2つになり、最大規模の開催となりました。 私自身今回2回目の参加でしたが、前回は内容自体も難しくかつ英語での発表だったこともあり、あえなく撃沈しておりました。
今回はリベンジ！といきたいところでしたが、やはり内容は難しく、全てを理解することはできませんでした。
だがしかーし！メモ内容や公開していただいているスライド、自身の感じたことを元にAIと深掘りすることで、ある程度自信を持って理解できたセッションもいくつかありました。 ありがとうAI。
今回はその中から特に印象に残ったセッションをいくつか紹介したいと思います！
No Types Needed, Just Callable Method Check
セッション概要
これまで、RubyコミュニティではRBSやSteepなど「型」を導入する機運が高まっていました。
型はドキュメントになると共にインターフェースの境界を明確にし、事前にエラーを防ぐ優れもの。しかし、生成AI（Claude Codeなど）の登場で前提が変わりました。
- LLMによる生成速度やコストの面で、Rubyのような動的型付け言語が優位に働く場合がある: 登壇資料での紹介によると、Claude Codeにコードを生成させた場合、RubyやPython、JavaScriptの方が、静的型付け言語よりも「速く・安く・安定して」生成できるという研究データがあるとのことでした。
- 型を書くコスト（Type ops cost）: AIは型なしでも本番レベルのコードを書けるようになっていますが、人間が最後に辻褄を合わせる「型合わせ」の負担が相対的に重くなっています。
そこで型を書く最大のメリットは NoMethodError を防ぐことであると割り切り、全く新しいアプローチのGemを開発したというものでした。
得られた学びと感想
開発しているプロダクトでも、型を書く場合があり、事前に型を定義しておくことで、コードを書く際の補完が効きやすくなったり、コードの意図が伝わりやすくなったりするメリットは感じつつも、型を記載するのにどうしても少し時間がかかるのでその点だけデメリットかなと感じていました。
型を書く最大のメリットは NoMethodError を防ぐことじゃない？という根本原因を追求されており、なるほどなーと感心しっぱなしでした。
今回単純な型に対する新たなアプローチも新鮮でしたが、何より根本原因を追求し、最適解を探求する姿勢が改めて自身も意識していきたいなと感じました。
From Formal Specification to Property Based Test
セッション概要
従来から、ソフトウェア開発には2つの大きな課題がありました。
- 仕様の正確性 (Specification correctness): その仕様は本当に矛盾なく成立しているか？
- 実装の検証 (Implementation verification): 実装は本当にその仕様を満たしているか？
LLMによるコード生成が普及するにつれ、「曖昧な仕様（自然言語）を渡せばAIも間違える」「テストが不十分ならバグがそのまま本番に出る」という形で、この問題はより深刻になっています。
そこで登壇者は、以下の2つを組み合わせるアプローチを提唱しています。
- 形式仕様 (Formal Specification): AlloyやQuintといった専用言語を使い、数学的に矛盾のない仕様を書く。
- プロパティベーステスト (Property Based Testing = PBT): 「特定の入力（例）に対する出力」をテストするのではなく、「どんな入力であっても常に満たすべき性質（プロパティ）」を定義し、大量のランダムデータを自動生成して検証するテスト手法。
形式仕様は既存の専用言語を使い作成。その仕様からPBTのテストコードを自動生成するツール（spec-to-pbt）を開発されたというお話でした。
得られた学びと感想
2月に参加したRailsTokyoの壊して育てる、テストの信頼性のセッションでも同じように「AIが書いたテストが本当に信頼できるか」をどう判断するかという問題提起がされていましたが、今回のセッションではさらに一歩踏み込んで、そもそも「仕様が正確か」をどう担保するかという根本的な問題にも切り込んでいて非常に興味深かったです。
仕様の正確性を担保するツールとProperty Based Testingができるような環境を導入する手段は数多くありそうですが、何かしらの形で会社に導入していきたいと感じました。
Class.new is all you need
セッション概要
Shiaさんが自身のツール（type-guessr）の起動速度を改善しようとした際の、驚きの発見から始まります。
プロファイリングを行った結果、起動時のCPU時間の14%を Data.define の初期化処理が消費していることが判明しました。そこでRubyコアコミッターの笹田氏（ko1氏）に相談したところ、返ってきたのは「Class.new の方が速いよ」という衝撃の一言。
「データ保持だけなら Struct や Data の方が軽量で速いのでは？」という直感に反するこの発言を検証すべく、Shiaさんが徹底的なベンチマークとプロファイリング（perf）を行った結果、Class.new と通常の initialize を使った方が、Struct や Data よりも起動速度が速いという驚きの結論に至りました。
LTの後半では、「Class が一番速いなら、Class の仕組みを使って Struct をRubyで再実装（RubyStruct）すれば、本物の Struct より速くなるのでは？」という狂気の発想に至るのがもう最高。
class_eval の中にゴリゴリの文字列展開（"def self.members; #{members_literal}; end"など）を詰め込んで動的にクラスを生成する、黒魔術コードでした。
「こんなの（Ruby本体に）commitできるか！（笑）」という完璧なオチも最高でした！
得られた学びと感想
多くのRubyistは「振る舞いを持たないデータ保持用オブジェクトなら、Class を定義するより Struct や Data.define を使ったほうが軽量で速い」と漠然と考えがちのようなことを話されてて、それって俺やないかい！とまさに自分事のように感じました。
最終的に学べたのは以下二つ。
- 推測（雰囲気）でパフォーマンスを語らない: 「シンプルだから速いだろう」という思い込みを捨て、プロファイラ（perf）でボトルネックを特定する重要性。
- パフォーマンスが重要な場面では、Ruby内部で最適化されている仕組みを見極めて選ぶ: 今回のケースでは Class が最も最適化されていたため、Struct や Data よりも速かった。「何が内部的に最適化されているか」を意識することが大事。
終わりに
RubyKaigiは2回目の参加で前回と比べてセッション中でも少しは理解が深まりましたが、まだまだその場で理解しきれないセッションが多かったなと感じました。
その場で全て理解できなくても大丈夫！聞いただけで満足せず、後から深掘りすることで、理解を深めていくことが改めて大事だなと感じました。復習を大切に。
来年は宮崎開催とのことで、北へ南へ大忙しですがまた参加したいと思います！
