こんにちは Qiita 株式会社の @tomoasleep です。今年も Qiita として RubyKaigi 2026 に参加してきました。
(Qiita としては何度か RubyKaigi に参加しています。過去のレポートはこちらから見れます)
- RubyKaigi 2025 参加レポート - Qiita Zine
- 沖縄開催の「RubyKaigi 2024」にQiitaエンジニア2名が参加！印象に残ったセッションは…？ - Qiita Zine
- RubyKaigi 2023 1日目参加レポート - Qiita Zine
イベント・ブースレポート
(セッションレポートに熱が入って長文ができてしまったのでこっちを先に持ってきました 
)
今年は picoruby 関連の話題が多く、セッション裏では結構その辺を触ったり楽しんでたりしました。
Smartbank さんの PicoRuby ワークショップ
「絶対30分で光らせられる！！」との触れ込みだったので picoruby 初心者の自分も試しに参加してみましたが、万全に整った開発環境のおかげでものの数分で無事光りました。すごい。
Web エディタを使ってボードに書き込む為とっても簡単で、色々光らせた後は Qiitan を出してみたり、LTタイマー作ってみたりとか、会期中はずっとこれで遊んでました。 picoruby たのしい。
ANDPAD さんのコード懇親会/Code Party(Social Coding)
せっかくもらったボードを色々光らせることができたので、コードを書きながら交流するコード懇親会でも picoruby テーマに入ってみることにしました。
前に秋葉原で買った小型ディスプレイを picoruby で光らせたいが、参考実装が micropython しかないためこれをどうやれば動かせるか…というのを他の参加者の方に相談しながら試してました。
光らせるために picoruby/picoruby のビルド環境を通したり、 micropython 用の実装を (AI が) 移植したりと、一転して picoruby のハードな部分を懇親しながらチャレンジしてみてました。(初見だと方針立てるのが難しいので有識者と一緒に進められたのありがたや…)
セッションレポート
Require Hooks: Filling the Gap in Ruby's Extensibility
いわゆる babel/register などのような実行時のトランスパイルなどが実現できる ruby-next/require-hooks についての発表です。 bootsnap とうまく共存できるようにしたり、JRuby でのパフォーマンス問題だったり、 require 周りに手を加えるのはやっぱ色々大変なんだな… と思いつつ、そうした問題を減らすために Hook の API を生やすというアイデアは個人的には興味深かったです。 babel/register 的なことができると結構夢も広がりそうなので実際に使ってみたい。
HTML-Aware ERB: The Path to Reactive Rendering
HTML-Aware な ERB である Herb に関する発表です。
Kaigi on Rails 2025 で発表を見た時に アイデアの面白さとツールの完成度の高さに度肝を抜かれて、今回も見に行きました。
今回の内容としては、より詳細な Under the hood という感じで、Reactive な機能 (差分を検出しての自動更新) で View と実装の関連付けなどをどのように解析して追跡しているかという話が主眼でしたが、出てくるデモが「確かにこれは欲しかった」と思わせるようなものが多く、この辺の落とし込みが本当にすごいなと今回も感じました。いや本当にすごい。
Blazing-fast Code Indexing for Smarter Ruby Tools
型チェックやドキュメント作成などの静的解析ツールでは、ソースコードから「個々の Class や Module がどういった定義を含んでいるか」などの情報を解析して扱う必要があるのですが、これを効率よく行うための rubydex というツールです。
Sorbet や Tapioca, RubyLSP などさまざまなツールから利用することを想定して作られたツールで、発表では、rubydex の概要や動作アルゴリズム、実際に RubyLSP に組み込んで高速化されたことが話されました。
私見ですが、 Ruby では、オープンクラスや定数解決ロジックの複雑さ、ソースコードの読み込み順特定のしにくさなどにより、
- そもそもの解析の難易度が高い
- プロジェクトのファイル全体を見ないとわからないことが多く、立ち上がりが遅い
- 解析した大量の情報を保持するため、メモリ等の消費が増えやすい
があり、初心者泣かせ (?) な部分とそれぞれのツールが重い処理を行うことでの非効率な部分が多いと感じていました。 rubydex がこうした処理を効率的に実装し肩代わりしてくれることで、解析ツール全体のパフォーマンス向上や、ツール作成の障壁が下がることなどが期待できるかなと思います。個人的には大いに期待したいプロジェクトです。
Matz Keynote
Matz が最近 AI どう使っているという話もありつつ、matz/spinel の紹介だったのですが、これがかなり面白かったです。
spinel は Ruby の AOT コンパイラで、いわゆる Go などのようにワンバイナリ化するツールです。
これが便利なのは言わずもがなのですが、従来のアプローチは Ruby の処理系を同梱してパッケージ化するもので、これはどうしてもサイズが大きくなりがちなのに対し、spinel は C 言語に変換してからコンパイルするという方法なので、配布サイズを抑えられるというのが違いとして大きいです。
主に CLI ツールなどで活用の可能性が大きいのですが、現状は spinel が対応している範囲は Ruby のサブセットで、たとえば define_method などをサポートしていないため、現状の CLI ツールを直接変換するのは難しいので今後に期待です。(プリプロセッサとか書いて spinel 対応のコードに変換できないかなとか内心目論んでます)
色々出会いがあった話
本屋ブースで伊藤淳一さんと初めてお会いして挨拶したり、技術記事を書く技術 を買わせていただいたりもしました。
帰りの新幹線などで読ませていただいたのですが。かなり Qiita のことを取り上げてくださっていて非常にありがたいのと、改めてナレッジを共有し合うことのポジティブな体験を多くの人が感じられるように、運営として引き続き頑張っていきたいなと思いました。
技術記事を書く上でのノウハウが色々詰まっていてエンジニアとして学べることは多い本なので、これをみている読者の方々にもおすすめです。
あと、 Rubyist Bulk Reload も (地震等の影響で中止になってしまいましたが) 一緒に帰る Rubyist 同士で楽しく話しながら帰ったり、函館で再会してその後について話したりと色々交流できるきっかけにもなったので個人的には参加して良かったなと思います！
運営に関わった GMO のみなさんはハードな判断だったと思いますがお疲れ様でした！
