今年も ENECHANGE は、2026年4月22日〜4月24日に開催された「RubyKaigi 2026」にゴールドスポンサーとして協賛しました！我々2人も RubyKaigi 2026 に参加してきましたので、その様子をお届けしたいと思います。
会場は、北海道函館市にある函館アリーナと函館市民会館。函館の街並みや美味しいご飯も楽しみつつ、Rubyづくしの3日間を過ごしてきました。
ということで、今年の RubyKaigi 2026 で興味深かった内容や感想について、書いていきたいと思います！
Ruby Committers and the World＜利廣＞
Rubyコミッターの皆様(@rubylangorg) rubykaigi.org
RubyKaigi 2026 でも恒例企画「Ruby Committers and the World」が開催され、Ruby コミッターたちが一堂に会して Ruby の「今」と「これから」について議論していました。
Conclave process for Ruby
Matzさんに万が一のことがあったとき、誰がどのようにRubyの方向性を決めるのか、という話題が議論されました。
他言語のコミュニティでは複数人の合意で方向性を決める例があり、それを参考にしてはどうかという提案が出ました。これに対してMatzさんは、合意に必要な人数が増えるほど、合理性以外の要因で決定が左右されるリスクがあると指摘しました。テーマへの興味や知見が乏しい人にも投票権が与えられてしまうためです。
さらにMatzさんは、自身の知識と経験を学習させたAIを意思決定者に据える未来もあり得る、とも語っていました。私自身は、AIが最終決定権を持つことには違和感がありますが、アドバイザーとしてMatzさんのAIバージョンを活用するのは非常に有効な手段だと感じました。
Ruby を書くとき、AI 使ってる？
Ruby のコミッターの中に、AI を全く使っていない方がいたことが意外で、印象に残りました。理由はシンプルで、「自分でコードを書くこと自体に開発の楽しみを見出しているから」とのことでした。
一方で、AI を使っているコミッターからは、「コミットには自分の名前がつく以上、たとえ AI が生成したコードであっても、それは自分が書いた(レビューした)コードとしてしっかり責任を持つことが重要だ」というお話がありました。
普段の業務でレビューを受ける際、指摘に対して「AI が書いたからな」と心のどこかで思ってしまうことがありました。しかし、このお話を聞いて、AI が生成したかどうかは関係なく、コミットとして世に出したのは自分自身である以上、自分が書いたコードとして責任を持ち、真摯に向き合う姿勢こそが大切なのだと感じました。
From Live Code to Sound＜利廣＞
Yuya Fujiwara(@asonas)さん rubykaigi.org
JavaScript 製のライブコーディング環境 Strudel を参考に、Ruby だけでリズムやメロディをライブコーディングできるエンジン「strudel-rb」の設計と実装が紹介されました。
bd hh sd hh のように Mini-Notation で記述したシーケンスをパースし、Ruby 側でタイミング計算と再生制御を行うことで、コンソール上でパターンを重ねながら音楽を生成できます。
発表では、Strudel スタイルの構文を Ruby に持ち込む際に、そのままでは表現できない構文があるという課題や、ライブコーディング中にシンタックスエラーが発生しても音を止めずに演奏を続けるためのテクニックについても触れられていました。
会場では strudel-rb を使って Ruby からドラムなどを鳴らすライブデモが行われ、まるで目の前に DJ がいるかのような臨場感がありました。
The Less-Told Story of Socket Timeouts＜杉山＞
Misaki Shioi(@coe401_)さん rubykaigi.org
TCPSocket.newやSocket.tcpのタイムアウト機構には、これまで名前解決のためのresolv_timeoutと接続のためのconnect_timeoutという2つのタイムアウトがあり、Ruby 4.0 ではそこに3つ目のopen_timeoutが加わるに至るまでの経緯についてです。
Rubyを使ってコードを書く側からするとタイムアウトは設定項目のひとつに見えますが、その裏で「どのタイムアウトが何を守っているのか」の整合性が崩れると、運用での事故や原因究明のコストが一気に跳ね上がるのだろうなと思いました。
特に印象的だったのは、「正しさ」を突き詰めるほど周辺事情が絡んでくる点です。たとえばgetaddrinfoがブロッキングで中断不能になり得るため、ただタイムアウトを足せば解決、とはいかない。さらに Ruby 3.4 で導入されたHappy Eyeballs v2のように名前解決と接続を並列化する仕組みが入ると、各タイムアウトが何を守っているかの整合性はより難しくなる。そこにNet::HTTPの既存挙動やRactorのような並行モデルとの相性まで絡んできます。
派手な新機能ではないのに、Rubyを運用している側からするととても素晴らしい改善で、アプリ側からは設定値ひとつに見えるものの裏に、これだけの歴史と設計判断が積み重なっているのだと思うと、標準ライブラリのありがたみを改めて感じました。
Ruby Releases Ruby＜杉山＞
Hiroshi SHIBATA(@hsbt)さん
Ruby本体やRubyGemsのリリース工程に自動化を取り入れてきた取り組みを紹介する発表でした。手作業に頼っていたリリースを、Rubyで書かれたツールでセルフホスティング化するまでの工程と、それによって何が変わったのかが語られていました。
Ruby Releases Rubyを聴いてまず印象に残ったのは、リリースという作業が思っていた以上に多くの工程を含んでいたことです。タグを打って終わりではなく、配布物が置かれ、ダウンロードできる状態になり、告知まで届いて初めてリリースが完了する。そこまで揃って、ようやくユーザーに届けたことになるのだと腑に落ちました。
その運用を支えるのが、手順を属人化させないという方針です。Ruby本体やRubyGems、Bundlerのリリース工程をRubyのスクリプトとして整備し、何を自動化してどこからを人が判断するのかを明確に分ける。一見すると効率化の話に見えて、実際の主眼はサプライチェーン攻撃への防衛線を厚くすることにあるのだと感じました。
自動化を進めたことで、リリース頻度そのものを上げられるようになったという話も印象的でした。一回のリリースが重い作業だった頃と比べて、パッチの提供サイクルを短くできるようになり、今までは深夜まで作業する時もあったそうですが、今は数時間で終わらせられるようになったそうです。 ユーザーに届く改善のスピードだけではなくセキュリティにも効いてくるのが素晴らしいなと思いました。
一方で、自動化が進んでも最後は人が責任を持つ領域が残る、という点も共感できました。 いつ公開し、いつ告知するか。この判断だけは自動化に委ねられない、という線引きがはっきりしていて、AI活用が進む今、自分たちの開発現場にも通じる話だと感じます。 自動化をする上で、どこまで任せてどこを人が握るか、その境界の設計こそが一番難しいのだと思いました。
おわりに
Ruby以外の知見も深められた3日間＜利廣＞
Rubyコミッターの方々の発表では、内容の高度さに理解が追いつかない場面もありましたが、最新のRubyに関する知識を深める貴重な機会となりました。また、ブースでの会話を通じて、アラート検知ツールの最新機能や、AIが台頭した現代だからこそ活用できるツールなど、さまざまな情報を得ることができました。普段の開発で使用しているツールについての知見もあったため、これらを活かし、今後はより安全でスピーディーなサービスの開発・運用に取り組んでいきたいと思います。 最後に、RubyKaigi 2026をサポートしてくださった運営チームの皆様に心より感謝申し上げます。会場の準備から函館名物のご用意まで、さまざまな面でサポートいただき、おかげさまで函館を存分に満喫することができました！
Rubyの魅力を再認識できた ＜杉山＞
RubyKaigi 2026 に参加させていただき、改めてRubyという言語の魅力を再認識しました。スピーカーの方たちだけでなく、参加者やスタッフを含めたRubyコミュニティ全体の熱量に触れられたのも大きな収穫でした。 特に、Rubyコミッターの方たちが実際にどのように生成AIを活用しているのか、どこを生成AIに頼り、どこを人間が判断するのか、といったかねてから気になっていた点を直接知ることができたのは、自分にとってとても良い経験でした。
