NaCl東京支社の早川です。
RubyKaigi 2026が2026年4月22日(水)～2026年4月24日(金)に開催されました。
本社から井上、まつもと、前田、高尾、原、佐田、加納が、東京支社からは後藤、早川が参加しました。
弊社からは以下メンバーが登壇していました。
- 基調講演
- まつもと
- セッション
- 高尾、原
- Ruby Committers and the World
- まつもと、前田、後藤
この記事ではRubyKaigi2026で、私の印象に残ったセッションを紹介します。
Exploring RuboCop with MCP
koic (Koichi ITO) さんによるRuboCopとMCPのお話です。
AI時代のRuboCopの役割、MCP Ruby SDKの現状、RuboCopへの統合といったトピックでお話しされました。
AI時代のRuboCopの役割
AIエージェントがコードを生成する際、人間が介在せずにそのコードがスタイルガイドや非推奨APIの使用を確認するための「ガードレール」としてRuboCopが機能するということです。
AIが書いたコードをAIにレビューさせるというのはよくある話ですが、レビューが成功するかどうかも確率の話になってしまいます。
一方でRuboCopはルールに基づいて確実に検知、修正することができるという強みがあります。
MCP Ruby SDKの現状
Shopifyのエンジニアが中心となって開始された公式のRuby SDKプロジェクトにkoicさんもコミッターとして参加されています。
現在、SDKはTier 3（実験的）ですが、仕様カバレッジを広げ、安定版のv1.0（Tier 2）を目指して開発が進められているということでした。
また、MCPの2つのトランスポート層の実装についても紹介されました。
MCPの2つのトランスポート:
Stdio: ローカルプロセス間で標準入出力を用いて通信する方式で、RuboCop単体での利用に適している
Streamable HTTP: HTTPとSSE (Server-Sent Events) を組み合わせた双方向通信方式でRailsなどのWebアプリケーションへのマウントが可能
Streamable HTTPを利用することでSampling(サーバからクライアントに推論を依頼する機能)やElicitation(サーバから人間に入力を求める機能)が利用可能になります。
RuboCopへの統合
決定論的な解析ツール（RuboCop）と確率論的なAI（LLM）をどう繋ぐかを模索されていて、まだ明確な答えは出ていないということでした。
AIエージェントが抱える問題として、エージェントがツールを呼び出すべき時に確実に呼び出すことが保証されない問題があります。
hooksを使うことで確実に実行することは可能ですが、必ず実行してしまうので柔軟性が犠牲になるというトレードオフがあるようです。
感想
RuboCopにおけるMCPの導入にとどまらず、MCP Ruby SDKの現状を聞くことができたのが良かったです。
AIが書いた膨大なコードでもRuboCopによる静的解析がガードレールになってくれるのは心強く、RuboCopが検知できる部分についてはAIのレビュー観点から外せるのも嬉しいと思いました。個人開発でもCopをちゃんと整備したいです。
Elicitationなど、SDK側の仕組みで複雑な実装を吸収できるということを聞き、改めてmcp gemのありがたさを実感することができました。
- 参考情報
TutorialKit.rb: interactive Ruby gem docs powered by Wasm
Bakaface (Albert) さんによるTutorialKit.rbの紹介です。
ブラウザ上で完結するインタラクティブなRubyチュートリアル作成フレームワーク、TutorialKit.rbについて解説されました。
TutorialKit
TutorialKit.rbを使うことでユーザのローカル環境でwasmを使ってチュートリアルを動かすことができます。
画面左側にレッスンの内容、右側にコードエディタ、ターミナル、そしてアプリのライブプレビューが表示される構成です。
TutorialKit.rbは昨年、Ruby Associationの助成金（Ruby Association Grant）に採択されています。
なぜブラウザベースなのか
通常、クラウド上に開発環境を構築してユーザーにチュートリアルを提供しようとすると、そのコストは開発者の負担となります。
TutorialKit.rbの最大の特徴は、すべてがユーザーのブラウザ内で完結することです。
Rubyのインタプリタ、ファイルシステム、さらにはデータベースまでがユーザーのローカルマシン上で動きます。
サーバー側は静的ファイルを配信するだけで済むため、ほぼ無料でホスティングが可能になります。
多くの開発者がチュートリアルを作成し、新規ユーザーの導入がスムーズになるという「正の循環」が生まれるということでした。
チュートリアルを作る
チュートリアルの作成は所定のディレクトリにMarkdown形式のファイルを配置することで行います。
最近はAIエージェントにフレームワークのルールを学習させ、チュートリアル生成を自動化することも試みられているそうです。
技術構成
ブラウザ上でRailsを動かすためには、いくつかの技術が組み合わされています。
- ruby.wasm: C RubyをWebAssemblyにコンパイルしたプロジェクトです。これにより、ブラウザ内でRubyインタプリタを直接実行できます。
- WASI-VFS: 必要なGemなどの静的ファイルを、WebAssemblyモジュール内にパッケージ化する仮想ファイルシステムです。
- WebContainer: ブラウザ内で動作するNode.jsランタイムです。TutorialKitは、この中でRubyを実行することで、ファイルシステムやプロセス管理、シェル実装を実現しています。
- Express-Railsブリッジ: WebContainer上で動くExpress.jsがHTTPリクエストを受け取り、それをJavaScript経由でRuby側に渡してRailsのレスポンスを受け取るという、独自のブリッジ機構です。
- PGlite: ブラウザで動作するPostgresの実装で、RailsのActive Recordアダプタを通じてデータベース機能を提供します。
今後の展望
今後は、Rails以外のテンプレート（Rubyのみ、データベースなし等）の提供や、WASI Preview 2でのネイティブソケット対応が予定されているそうです。
また、WebContainerへの依存をなくし、Service Workerを活用した独自実装への移行を検討しているということでした。
感想
私も個人的にGemを公開しているので、ユーザがサクッと使い心地を確かめられ、それをほぼ無料で提供できるのは大変魅力的に感じました。
特に今後Railsアプリ以外でもチュートリアルを作れるようになるという展望が聞けたので、とても期待しています。
チュートリアルそのものをAIが自動で作成してくれる可能性も語られていたので、コマンド一発でチュートリアルが作られるような世界になったら嬉しいですね。
Autoresearching Ruby Performance with LLMs
nateberkopec (Nate Berkopec) さんによるLLMを用いたRubyパフォーマンスのauto-researchのお話です。
auto-researchとは何か、AIの抱える「品質」の問題、ゲートの必要性、ソフトウェアファクトリーという未来について話されました。
auto-researchとは
通常プログラミングのパフォーマンス改善は、人間がどこが遅いかを探し、修正案を考え、実際に速くなったかテストするという作業の繰り返しです。
auto-researchは「改善案の作成→ 検証（ベンチマーク）→ 学習 → 再試行」というループをAIに自動で実行させる手法を指します。
ShopifyのCEOがAIを使ってライブラリを50%高速化したという事例が話題になりましたが、現在のAIはまだ「すべてお任せ」の段階ではなく、「改善のヒントを探す」段階にあるということでした。
AIの抱える「品質」の問題
発表の中で、ソフトウェア開発には『新しい解決策をどんどん探し、試す役割』と、『出された案が本当に正しく、美しく、保守しやすいかを判断する役割』が必要だという話がありました。
前者はAIが得意な領域で、後者は人間が得意な領域です。
AIにパフォーマンス向上を依頼すると、1%の速度向上のためにシンプルだったコードをやたらと長くて複雑なコードにしてしまうようなことがあります。
現状では人間が出力されたコードの良し悪しを判断する必要があります。
ゲートの必要性
そこで登場するのがゲート、検証プロセスです。プログラムが正しく動くか、本当に速くなっているか、コードが複雑になっていないかを自動で検証するようにし、合格基準を満たすまでAIが試行錯誤できるようにするというアイデアです。
これを支援するツールとして『auto-research』が紹介されましたが、現時点ですべてをバランスよく調整できるわけではないようです。
ソフトウェアファクトリーの可能性
将来的に、人間がコードを書かず、レビューもしなくなる。というソフトウェア・ファクトリーの概念が紹介されました。
実際にIntercom社では、プルリクエストの45%がAIによって自動承認・マージされているそうです。それでも障害が減り、コストも削減できているという事例が紹介されました。
一方で内部のコード品質スコアが低下したことも認められていて、品質の担保が今後の課題とされています。
感想
今回の発表ではAIがパフォーマンス改善できることを前提に、その方法が正しいのか、保守性が保たれているのかということが主題になっていました。
発表の最後に「auto-researchは興味深いが、現状では人間にさらなる仕事を増やすだけのものになりがちである」と話され、AIによる開発自動化の期待感と難しさを感じさせられました。
AIが不必要に複雑なコードを書いたり、保守性についての意識が薄いことに関しては普段から感じているところで、興味深い発表でした。
おわりに
今年はmrubyやPicoRubyに関する発表が多く、数えてみると11セッションありました。去年は3つだったので大躍進です！
今回参加するにあたり、PicoRubyについて詳しく知りたいというモチベーションがあったのですが、PicoRubyベースのOSやSPAフレームワークの登場など、PicoRubyの世界が想像以上に大きく広がっていたので驚きました。
また、AIに関する発表が去年より増えていたのも印象的でした。会場の挙手アンケートでも多くの方がAIを使ってコードを書いてるということがわかりました。
まつもとさんのキーノートでもコーディングエージェントの話題が上がり、RubyとAIの親和性についても触れられました。
今後Rubyの領域でAI利用が活発化、発展する可能性が感じられ、とても楽しみです。
おまけ
RubyKaigiは20周年！
五稜郭タワーはRubyカラーにライトアップされていました！
去年に引き続き、今年もNaClメンバーで集合写真を撮りました！
