はじめに
こんにちは。
オプティムの石元、市川、宮城、勝田です！
オプティムではRuby / Ruby on Railsを採用した複数のプロダクトを開発しています。
今年もRubyコミュニティ最大の国際カンファレンス RubyKaigi 2026 に参加しましたので、その様子をレポートします。
RubyKaigi 2026 について
今年のRubyKaigi 2026は北海道函館の「函館サーモン・まるなまアリーナ」にて開催されました。
メインアリーナがまるごとスポンサーブースになっており、昨年よりも多い34のブースが立ち並んでいました。
オプティムの参加・協賛について
オプティムはプラチナスポンサーとして協賛し、昨年に引き続きブースも出展しました！
ブースの様子
昨年よりもブースが広くなったおかげで、キレイに展示できました。
昨年は「Ruby Gem Guessr」というコードを読んでRubyのgemを当てるゲームを作成しました。
今年はパワーアップさせ、「Ruby Method Guessr」というCRubyの内部実装を読んでメソッドを当てるゲームを提供しました。難易度は昨年より上げたつもりでしたが、普段からRubyにコミットしているRubyistの皆さんには馴染み深い問題も多かったようです。
挑戦いただいた皆さま、ありがとうございます！
成績上位の方には、オプティム特製の折りたたみ式バッグハンガーをプレゼントいたしました！
気になったセッション
ここからは、現地参加メンバーそれぞれが、印象に残ったセッションを紹介します。
When Can You Skip a Test? Tracking Test Impact
by Andrey Marchenko
本セッションは自動テストの高速化のために、テストの効果を計測しようというものです。自動テストは多く実施すればその品質が上がると思われがちですが、その分自動テストの速度が落ちてしまい、結果として開発スピードへブレーキがかかってしまいます。改善にはテストの品質を計測する必要がありますが、その計測自体が負荷になると元も子もありません。
そこで、Andrey氏はテストカバレッジを測定する新たな方法を開発し、既存のCoverage APIやSimpleCovとの比較結果を共有されました。
弊社のプロダクトも自動テストの時間について課題を感じており、開発の段階に応じて必要なテスト量を変えています。
一方、必要なテストが何かの計測や判定には悩んでいたため、本講演の内容を元に改善していけると思いました。
(石元 記)
Digits, Digits, and Digits
by tomoya ishida
本セッションは BigMath のパフォーマンス改善と保守、および桁演算の設計の面白さを扱っていました。
BigDecimal の BigMath モジュールは、数学に関係する関数（例えば三角関数）を任意精度で計算できます。例えばsin関数を小数点以下1億桁まで求めることもできますが、その計算に推定で約6万年もかかっていました。そこで、関数の計算をうまく工夫することで、約150秒で計算できるようになりました。
掛け算は、筆算のように、掛けられる数と掛ける数を各ビットごとに分けて、それぞれを掛けていきます。このような一般的な掛け算の計算量は になってしまいますが、実は
に近いアルゴリズムが存在するようです。（なお、このアルゴリズムの具体的な手法は本セッションでは登場しませんでしたが、最終日に Matz が基調講演で紹介した「カラツバ法」は
よりも速いです。）また、その他にも大きな掛け算の仕方を工夫することで、劇的に処理を速くする方法を紹介していました。例えば
という値を律儀に求めると時間がかかってしまいますが、
といったように、小数点以下を1桁、2桁、4桁……区切りにしていくと、効率よく計算することができることを示していました。これは exp 関数の引数の精度が上げれば上げるほど計算に時間がかかるのに対し、引数の絶対値が小さければ小さいほど値が速く収束するため、小数点以下の桁が大きいほど精度を上げてバランスよく計算することができるというトリックです。
ところで、宇宙サイズの円を描く必要があったとしても円周率の精度はせいぜい40桁で事が足りるため、exp関数を小数点以下1億桁まで求める必要性はありません。しかし、本人曰くロマンがあるとして、極端な最適化による保守性の低下に気をつけながら、パフォーマンスの改善を行っていました。個人的には「宇宙人と遊ぶときに、円周率を100万桁先に求めたほうが勝ちになるゲームで役に立つ」という説明がウケました。ロマンですね。
(市川 記)
Programming with a DJ Controller - not vibe coding
by Masatoshi SEKI
本セッションは、DJコントローラーをDJコントローラーとしてではなく、ヒューマンインターフェースデバイスとして効果的に活用してみようという内容でした。マウスとキーボード中心のGUIでは複数パラメータを同時に触りにくいことや、フォーカスが1つしか取れないツールでは照合作業がしづらいことなど、開発作業の身体性まわりの課題に向けた話でした。あわせて、Ractorのように並行処理の状態をテキストログだけで追うのが難しい場面でも、人間が状況を把握しづらいという課題が挙げられていました。
新しかったのは、安価なDJコントローラーを「音楽用」ではなく高密度の物理入力装置として扱い、RubyからMIDI（Note、Control Change、SysExなど）で読み書きする設計でした。1つの例として、画像加工ソフトの彩度のノブと明るさのノブをDJのように同時に操作できるという活かし方が示されていました。別の例では、 クイーン問題（
の盤に、互いに利きを通さない位置へクイーンを
枚置く解の数を数える、有名な配置問題）をRactorで解かせる途中経過をテキストログに頼らず、状況を音に落とし込み、コントローラでワーカーごとに停止や再開を出し、音色の違いでどの並行処理が動いているか聞き分けるというアイデアが挙げられていました。
専用プロトコルではなく楽器向けメッセージの寄せ集めであること、ノブの絶対位置が取れないときは商用ソフトの初期化ログを手本にSysExを再現するといった調査の型、バーストするメッセージを外部・内部の両方から扱える小さなライブラリで切り出すこと、ジョグと固定ノブでイベント圧縮とキューを分けることなど、ハードウェアを活かすための具体的な提案が印象的でした。
(市川 記)
Pure Intonation on Browser: Building a Sequencer with Ruby
by nagachika
本セッションは、純正律のシーケンサーをRuby/WASMを使って作る話でした。普通のドレミファソラシドはオクターブを12等分してできています。これを12平均律といいます。 12平均律は和音の整数比が微妙にズレており、若干汚い音に聞こえますが、現代の一般的な音楽理論では12平均律を採用しており、多くのDAW上では結局平均律に寄せてしまうことが多いです。そういった課題に対し、ブラウザ上で純正律に基づく和音をそのまま鳴らすシーケンサーを実現しようと試みていました。あわせて、RubyとWeb Audio APIをどう組み合わせるかという実装面の難しさもテーマになっていました。
新しかったのは、純正律ベースのpurified-synthを、モジュラーシンセ・和音エディタ・マルチトラックの一体構成で示した点です。創作プロジェクトLamplightに由来する格子図に基づく記法で、和音と進行を先に置き音階を後から立てるという発想は、従来の鍵盤中心の入力とは違う設計でした。技術面ではWASIとJSジェムで JS::Object から JavaScript をプロキシし、オーディオノードを Ruby ラッパーで JavaScript と一対一に接続する一方、JavaScriptとRuby を深く行き来させると WASMとCRubyの例外の相性で深いネスト時に致命傷になり得るため、実装をできるだけ片側に寄せるという現実的な整理が参考になりました。
RubyがWASM経由でブラウザのリアルタイム音声処理に入り込み、音楽理論の実験場として使われている点に、言語の応用範囲の広がりを感じました。プリミティブの明示変換など、境界をまたぐときの作法が共有されることも、今後のRubyとWebの統合が進むうえでの手がかりになりそうです。
(市川 記)
Ruby on NES - how to make the smallest ruby ever
by Yutaka HARA
本セッションは、ファミコンでRuby製のゲームを動かすことについて発表していました。ファミコンの WRAM 程度の極小メモリでは CRuby も mruby もそのままでは載らないという制約に対し、mruby のバイトコード形式を流用しつつ、パースとコンパイルはホスト側の mruby に任せ、本体では C で小さな VM だけを動かすという方針で nesruby を構築した話でした。
新しかった視点としては、フルのクラス階層ではなくトップレベルメソッドと少数の命令で self にメソッド名を送って分岐するといった、ハードに合わせた割り切りの API 設計や、Symbol を mruby/c に近い形で名前から整数 ID に落とし、組み込みシンボルは固定番号と辞書順二分探索で探すといった、限られた RAM の中でのデータ表現の工夫が印象的でした。Optcarrot のような文脈から「エミュ上のソフトも Ruby で」という動機が語られ、バイトコード互換の VM を自作する必然もよく理解できました。
今後の課題としては、機能不足の解消が挙げられていました。「Ruby らしさ」としてオブジェクト指向を広げたい一方、ヘッダと値でメモリが倍増し、例えば弾幕ゲームでは弾幕が三十個程度でメモリを食い尽くして破綻しやすいというジレンマも説明されていました。参照カウントで自動解放しようとすると、オブジェクトごとに「何回参照されているか」を記録する場所が要ります。RAM が 2KB しかないので、その記録用の数バイトが積み重なると、弾の数などがすぐ減ってしまいます。自動 GC は便利ですが、参照カウントはオブジェクトが細かいほど不利で、このような極端な環境ではむしろプログラム側で解放のタイミングを手動で決める方がマシという場合もあるようです。
メモリが 2 キロバイトしかない環境でも Ruby のバイトコードが回るという移植性の高さに感動し、Ruby の実装がどこまで削れるかという実験が今後どう続くかも楽しみです。弊社の Optimal Remote も様々なプラットフォームに対応して、デバイスの画面をリアルタイムで共有・遠隔操作することができます。いつかファミコンもサポートできる日が来るかもしれません……！（冗談です！）
(市川 記)
Ruby Committers and the World
by CRuby committers
本セッションは、Rubyのコア開発者（CRubyのコミッター）たちが集まり、言語の内部実装や今後の設計について議論するパネルディスカッション形式の内容でした。主なテーマは、例外処理の仕組みやメモリ管理、そしてデータを「変更できない状態（不変）」にするための仕組みについてです。
まず大きな論点の1つが、Ruby の例外処理における「longjmp」という仕組みです。これはエラー発生時に処理を一気に別の場所へ移動させる仕組みですが、その過程で本来実行されるはずの後処理（メモリ解放など）がスキップされる可能性があり、結果としてメモリリークにつながることが指摘されていました。特に C 拡張や Rustなど、Rubyの外部で管理されるリソースと連携する場合、この問題はより顕著になります。そのため、安全性を確保するにはエラー処理を慎重に書く必要がありますが、その分パフォーマンスに影響が出るというトレードオフが議論されていました。
また、「frozen string literal」に関する話題も重要でした。これは文字列を最初から変更不可にすることで、メモリ効率の向上やバグの防止につながる仕組みです。将来的にこれをデフォルトにするかどうかについては、段階的に移行する計画が共有されていました。さらに、配列やハッシュも含めて中身まで完全に不変にする「deep freeze」という考え方も提案されており、データの安全な共有や予期しない変更の防止という観点から注目されていました。
感想としては、普段Rubyを使っているだけでは意識しにくい低レイヤーの課題が多く取り上げられており、非常に興味深い内容でした。特に「書きやすさ」と「安全性・性能」のバランスをどのように取るかという点に、言語設計の難しさを強く感じました。また、普段何気なく使っている機能の背景を理解することで、より良いコードを書くための視点が得られたと感じています。Rubyが今後どのように進化していくのか、その方向性を考える上でも示唆に富むセッションでした。
(宮城 記)
HTML-Aware ERB: The Path to Reactive Rendering
by Marco Roth
本セッション「HTML-Aware ERB: The Path to Reactive Rendering」は、Ruby on Railsで使われるERBテンプレートを、より便利でリアクティブに進化させることを目的とした内容です。ERBはHTMLの中にRubyコードを書ける仕組みで、画面表示を作る際に広く使われています。しかし従来のERBは、内部では単に文字列を組み立てているだけで、HTMLの構造を理解していませんでした。そのため、タグの対応ミスに気づきにくく、また一部のデータだけが変わった場合でもページ全体を再読み込みする必要があり、リアクティブな画面更新には向いていませんでした。
この発表では、HTMLとERBを同時に解析する仕組みを導入し、テンプレートの構造を正しく理解できるようにする方法が紹介されています。特に、Prismを使ってERB内のRubyコードも解析することで、実行前にエラーを検出したり、どのデータがどこに影響するかを把握できるようになります。これにより、変更があった部分だけを更新する「差分更新」が可能になり、リアクティブな動きを実現できるようになります。この考え方は、Phoenix LiveViewのように、サーバー側で画面を制御しながらリアルタイムに更新する仕組みに近いものです。
普段Railsを使っている立場としては、「RubyだけでリアクティブなWebアプリが作れる可能性がある」と感じました。これまでは、画面を動的に更新するにはReactなどのJavaScriptフレームワークが必要になることが多かったですが、この仕組みが発展すれば、Railsの書き方を大きく変えずに同様の体験が得られるかもしれません。また、コードのミスをすぐに検出できたり、変更が即座に画面に反映されたりするなど、開発体験の向上も非常に魅力的だと感じました。
一方で、まだ発展途中の技術であり、複雑な処理や実運用での安定性には課題が残ると考えられます。しかし、それでも「シンプルなRails開発のままリアクティブな体験を実現する」という方向性は非常に魅力的であり、今後の進化に期待したいと感じました。Railsが最強のフルスタックフレームワークとなり、Railsだけでフロントエンドもバックエンドも開発が完結する未来が来るのがとても楽しみです！
(宮城 記)
The future of Ruby documentation
by Stan Lo
本セッションはRubyにおけるドキュメントの将来についての話です。
RDocはRubyの標準ドキュメントツールとして長く使われてきましたが、以下の問題に直面していました。
- 新構文に追従できず不正確: 独自パーサが最新のRuby構文に対応できず、ドキュメント生成が破綻していた
- Markdownが不完全: 独自拡張が散乱し、標準との整合性が取れていなかった
- 型情報が活用されていない: RBSで型定義が行われても、ドキュメント生成に反映されていなかった
これらの問題は、弊社が設計書・ドキュメント管理で直面している課題と驚くほど一致していると思いました。
このセッションの本質は、「ドキュメント問題は技術的な問題ではなく、設計の問題」であるという気づきにあります。
セッションの結論では「AIにとって良いドキュメント＝人間にとって良いドキュメント」は、ドキュメント改善への投資の正当性をあらためて示していると思いました。
弊社も現在ドキュメント管理の改善に取り組んでいますが、RDocの改善事例から学べることは多く、同じ設計転換の思想で進めば、単なる「自動化」ではなく、本質的に保守性が高く信頼できるドキュメント基盤が実現できると思いました。
(勝田 記)
https://st0012.dev/assets/slides/2026-04-23-rubykaigi.pdf
おわりに
RubyKaigi 2026は、Rubyにとって1つの大きな節目だったと感じています。
2025年末には、ここ数年にわたって注目を集めてきたRuby::Box（Namespace）のリリースやRuby 4.0があり、言語としての基盤は一段と強固になりました。 そして今回のRubyKaigiを経て、「Box Building（函館）」を終えたRubyが、次にどこを目指していくのか――その北極星が、少しずつ見えてきたように思います。 最終日に発表されたspinelをはじめ、AI時代の開発におけるRubyの在り方、さらなるパフォーマンス向上への挑戦など、これからのRubyにはまだまだ大きな伸びしろがあります。
私たちオプティムも、そんなRubyとともに成長し続けていきます。
Rubyが好きな方、Rubyで本格的なプロダクト開発に興味がある方、ぜひ一度お話ししましょう！
