RubyKaigi 2026 にRubyスポンサーとして協賛しました！

こんにちは！メドレーDevRelの重田（@Shige0096）です。 4/22(水)-24(金) に函館で開催されたRubyKaigi に今年も参加してきたので、その参加レポートをお送りします👟

はじめに

株式会社メドレーはRubyスポンサーとして協賛し、現地でブース出展しました。弊社のプロダクトの半数以上でRubyを用いていることもあり、 Rubyコミュニティへの貢献は、協賛活動の中でも特に重要視している活動です！

１番最初にロゴを掲載していただきました🙌 rubyロゴ

弊社VPoEの倉林（@terukura）が書き込み中✍️ rubyボード

今年は役員を含め総勢13名で参加し、RubyKaigi を堪能しました✨ 本レポートでは、現地の様子や弊社のブース企画のご紹介を写真メインで雰囲気が伝わるようお伝えします！ぜひ楽しんでご覧いただけると嬉しいです🙌

会場の様子

本年の開催場所は「函館」。（昨年の発表から心待ちにしていました!!!）

採用人事の福島さんとともに前日入りし、ブース設営⚒️ 事前設営

ブースの完成形。Rubyスポンサーは長机2つなので広々としていました🚩 ブース完成

上から見た会場。上からの会場全体写真

弊社ブースのご紹介

ブース企画その１_Ruby×AIアンケート調査

以下3つのAIに関するアンケートをとりました！🔍 ご回答いただいた皆様、ご協力ありがとうございました！！

AI（生成AIなど）を開発に取り入れ始めたのはいつ頃ですか？
使っている具体的なルールを教えて下さい
AIを活用したRuby開発における成功体験やお困りごとを教えて下さい

アンケート結果サマリ✍️

1.AIを開発に取り入れ始めた時期

2024年前半： 早期導入層が一定数存在し、この時期から活用が始まる。
2024年後半〜2025年前半： ボリュームゾーンです。この期間に圧倒的多数のエンジニアが導入を開始。
2025年後半〜2026年： 導入が一段落し、ほぼ全てのエンジニアが当たり前に利用しているフェーズに移行。

2.使っている具体的なツール

圧倒的シェア: Claude Code
併用・特定用途: Cursor, Codex, GitHub Copilot, Devin, Gemini など

結果としては単なる「コードの補完」ではなく、Claude Code や Code x、Devin のような「自律的にタスクを完了させるエージェント型」が主流であることが顕著に現れていました。

3.Ruby開発における成功体験・お困りごと ☀️ ポジティブ（成功体験）※一部抜粋

開発スピードの向上: 「実装が早くなった」「コードを書く時間が減った」「爆速」「PR（プルリクエスト）出すまでが早い」といった声が目立ちました。
学習・調査の効率化: 「知らない構文やライブラリをすぐ聞ける」「エラー解消が早い」「Rubyの古いバージョンからの移行に役立った」
テスト・ドキュメント: 「テストコードを書いてくれる」「仕様の言語化が楽になった」
精神的負担の軽減: 「一人で悩む時間が減った」「心理的ハードルが下がった」

☔️ ネガティブ（お困りごと） ※一部抜粋

精度の問題: 「嘘をつく（ハルシネーション）」「動かないコードが出てくる」「古い情報を出してくる」
レビュー・品質への懸念: 「レビューが大変になった」「AIが書いたコードの意図を追うのが苦労する」「コピペによる技術的負債への不安」
特有の悩み: 「トークン代が高い」「追いつくのが大変」「AIのスピードに人間がついていけない」

1日目のアンケートボード

2日目のアンケートボード

ブース企画その2_アンケート or XフォローでノベルティGET🎁

弊社の認知度をはじめとした簡単なアンケートへの回答またはXフォローでガラポンチャレンジをしてノベルティをプレゼントしていました✨ どちらもご協力いただいた方は2回引いていただきました💪

ガラポン写真

防災7点セットをはじめ絆創膏やポーチなどを用意しました🎁 防災7点・絆創膏写真

多くの方にお越しいただき、賑わいを見せた弊社ブースの様子👀✨わいわい。パネル前写真

ブースワイワイ写真

役員3名の写真

弊社役員のオフショット📸 役員3名の写真

Matzさんにお越しいただき記念撮影✨ ありがとうございました！

エンジニアによるセッションレポート

エンジニアによるセッションの感想を一部紹介します！

Ruby Committers and the World

RubyKaigi 2026, #rubykaigi

rubykaigi.org

Rubyの開発体制について。Matzさんがいなくなった場合を考えて、pythonのような合議制への移行などを検討すべきかが話された。Matzさんは大人数での合議制には否定的で、一部の意見によって言語設計が揺らぎやくなる懸念があると話していた。少人数での合議制か、AIでメカMatzを作るべきという意見があった。
RubyコミッターのAI活用について。コミッターも半分以上をAIに実装されている人が多い。Matzさんも一年以上自分でコードを書いていない、エディタも開発目的では使っていない（メールでもemacsを使っている）。CRubyは以前からMatzさんは実装から離れて他のコミッターに任せていた。同レベルのことをAIエージェントに任せてもアウトプットレベルはそんなに変わらないらしい。（言う事を効かないことがあるコミッターたちよりもAIエージェントを使ったほうが良いとのこと）

HTML-Aware ERB: The Path to Reactive Rendering

RubyKaigi 2026, #rubykaigi

rubykaigi.org

この発表は、ERBを単なる文字列生成の仕組みとしてではなく、HTML構造を理解できるテンプレートとして扱うことで、RailsのView層をより進化させようという内容でした。HerbはHTML+ERBを解析するための文法とパーサを提供し、Prismと組み合わせることで、Ruby構文やHTMLの不整合を実行前に検出できるようにします。普段Reactを書いている立場から見ると、JSXをツールが構造として理解できることがReactの開発体験を支えているように、HerbはERBにもそれに近い土台を作ろうとしているように感じました。Hotwireで進んできたHTML中心のRails開発を、テンプレート解析やエディタ支援の面からさらに押し進める取り組みに見えます。特に面白いのは、将来的に「どの状態がどのDOMに影響するか」を追跡し、必要な部分だけを更新するリアクティブな仕組みにつながる可能性がある点です。ただし、React的なリアクティビティがすぐそのまま実現するわけではなく、現時点ではそのための基盤づくりという位置づけに近そうです。サーバーサイドレンダリングを中心にしながら、必要なところだけ賢く更新できる方向性はとても魅力的です。ERBが構造を理解できる開発しやすいUI記述として進化していくなら、小規模なアプリや管理画面では、Reactを持ち込まずにこの方向性を選ぶ場面も増えていくかもしれません。
ERBの問題（HTMLの構造に問題があっても何も検出しない）とそれを解決するためにherbが生み出され、herbに何ができるか？といった話。herb-toolsでHTMLをパースしたり、dev serverでホットリロードできたりするの知らなかったので勉強になりました。

Matz Keynote

RubyKaigi 2026, #rubykaigi

rubykaigi.org

Rubyのソースコードをコンパイルして、実行ファイルを生成する取り組み。CRubyに比べて大幅な性能向上を実現していた（YJITとは別のアプローチ）。全てのRubyの機能が利用できるわけでなく、Ruby on Railsの置き換えは現時点で原理的に不可とのこと。CLIツールなどの一部のユースケースでは利用できる仕組みかもしれないと感じた。