帰福以来の微妙な喉の痛みも落ち着いたのと、経費精算におそらく成功したのでようやくRubyKaigiを締めることができる...。
ひとまず、発表もしたmruby/edgeとUzumibiに関しての振り返りを日本語で書く。AIは文章を書く上では使わない。はてなブログはなァ、AIなんか使って書いちゃだめなんだ。
Uzumibi: Reinventing mruby for the Edges
2024年に発表した mruby/edge の今年までの進化の話をした。
個人的に2024年からGitHub Pages + Marpでスライドをホストするようにしているが、3年連続で綺麗なPermalinkを作り続けられたのでありがたい話。
https://udzura.jp/slides/2024/rubykaigi/https://udzura.jp/slides/2025/rubykaigi/https://udzura.jp/slides/2026/rubykaigi/
さて、mruby/edgeはmruby VMのバイトコード仕様を流用した、既存のmruby、PicoRuby等とは別のRubyランタイムである。現状、mruby/edgeを使うと有利であろうシーンを整理する。
Cloudflare WorkersでRubyらしきコードを動かしたい
mruby/edgeの応用例の一つとしてUzumibiというものを作った。
Uzumibiはテンプレートジェネレータを持っているので、RustのランタイムとUzumibiをインストールしたら即座にアプリのテンプレートを作ってデプロイが可能である。詳細は以下の本で今すぐ試せます。
Cloudflare Workersの機能も最低限すぐに使える。また、assetsも一緒にデプロイできるようにしているので、フロントも普通に作り込んで同梱できる。
なおmruby/edgeをフロントで使うのはもちろん可能だが、その辺の作り込みは何もしていないので、フロントのRubyコード*1は Funicular という手もアリだと思う。
...とか言っていたら近いうちにFunicularがCloudflare Workersで動くようになりそうだけど...。
Cloudflare Workers自体は数年前から認識していて（yusukebeさんのことを以前から知っていたのもあるが）、このエコシステムがまるっとRubyistの視界に入ってないのはマジで勿体無いよなと思っていた。今回自分でもUzumibi経由で使って*2改めてこの手軽さにびっくり。Webアプリを作る時の常識や感覚が変わるので、ぜひ。
Google Cloud Runで爆速で起動するRubyアプリケーションをデプロイしたい
mruby/edge はなんと普通にネイティブでも動かせるので、Rustの爆速サーバHyperなどと組み合わせてCloud Runでアプリを書けるようにした。そうしたら起動所要時間が50ms以下とかになった。
mruby/edge、試みにCloud Runにデプロイしたら動いた
— Uchio Kondo 🦀 (@udzura) 2026年1月9日
起動レイテンシが 30 ~ 50ms、メモリ利用は 20MB程度らしい pic.twitter.com/59X98FlBgS
真にサーバレスのためのRubyだ！って思って、実はこっちの方が嬉しい気持ちになった。マジで、日々Cloud Runに苦労してるから...。
（追記: Cloud Runで動かせばええやん、というアイデアをくださったのはosyoyuさんです！ありがたう〜）
こちらもFirestoreでKVS、あとCloud Pub/Sub、IAPのJWTを検証する等の実装を対応した。Google CloudにおいてはCloud Pub/Subは超重要なのですでに結構便利という説がある。
あと、そのほか必要なサービスがあれば、Rustでアクセスする部分を書いてmruby/edgeのAPIでラップしてgemにすればシュッと行けるんで... というか例えば Memorystore for Redis あたりはもう対応してたりする。
発表で話したとおりtokioとの兼ね合いでややパフォーマンスを犠牲にしている箇所はあるが、十分高速だし運用可能なはず。
なお、ただのネイティブなので、理論上もちろんAWS Lambda等でも動かせるし、LambdaにはRust SDKがあるようなので即で組み込めると思う。お仕事でAWSを現状使ってないため、後回しにしているだけなので、希望が多ければ対応したい or PRいただければウェルカム。
WebAssemblyの低レベルAPIを経由してRubyを使いたい
WebAssembly.instantiate/instantiateStreaming を直接使わないといけない現場に出会った場合、生成されるWasmファイルでどの関数をimportして、どの関数をexportするのかについて意識せざるを得ない。それらを意識したい場合、Rustで薄いラッパーコードを書いて、内部でmruby/edgeを使えば比較的スッキリ行けると思う。
もしくは wasm-bindgen/wasm-pack と組み合わせたい時も、mruby/edgeが一番早いと思う。
とにかくRustと組み合わせて楽してワズムしたい時。
どうしてもWasm Component Modelを使いたい
上述の通り、Rustで薄いラッパーコードを書いて、内部でmruby/edgeを使えばRustのエコシステムをまるっと使えるので、例えば wasm32-wasip2 とかでビルドしてComponent対応を謳うこともできるだろう。
既存のRustのプロダクトにmrubyを埋め込みたい
mruby/edgeはとにかくなるべく「Rustエコシステムに素直なRust」で書いている。
- コア実装はほぼno_std（alloc周りは除く）
- 必要に応じてfeature flagを使ったり、crateを分割して細かく
- C FFIは回避
よってRustのコードに組み込むのはそれなりにやりやすいかと思う。たまには型がない言語でDSLを組み込みたくないですか？ LuaもPure Rust実装がいくつか出てますが... Rubyもありますよ？
おまけ: Google SpreadsheetでRubyを動かしたい
スプシに連携したApp ScriptにこのJSコードを貼り付ければRubyを実行できる。ただ、これは完全にmruby-compiler2に依存している。多分App Scriptでの動作は、picorubyでもすぐ同じことができると思います...。
性格が捻くれているので、Rubyも好きだが、Rustも好きで、最近はフロントエンドとかWeb標準に興味があったり、結局またeBPFを触り出したりしている。
捻くれたなりにとにかく自分で一貫した一つの世界を一度作ってみたいな、という気持ちがあり、今回はmruby VMをRustで再実装した上で、それなりに実用的（多分）なアプリケーションフレームワークも作って提示してみた。実際自分で欲しい要素が詰まってるし役に立ちそうなんだけど、多くの人に使ってもらうという観点ではまた別なんだよなあ。
でもそれなりに面白いと思うので試してみてください。
そしてAIというやつの力で短期間でここまで「ちゃんと使えてる」ものに仕上がったのもびっくり。mruby/edgeのコードに詳しいのは、一番は僕だけど、二番目はClaudeの可能性がある。界隈を見ると、 mizzyさん 、 gfxさん をはじめとして錚々たる超級アーキテクトの先輩たちが、すごいスケールのソフトウェアを、物理的人間は一人だけでAIを駆使して開発している。その中にMatzのSpinelも加わった今年であった。
プログラミングの力というより、「正しくソフトウェアを作れる力」のレバレッジが、AIによって今後どんどん大きくなる感じがする。mruby/edgeを大体一人でAIと作って、その潮流の一端を少しだけ感じられたのもいい経験だった（...いや、mruby/edge、こっからもっと使えるようにするよ）。
*1:面白い響きだ...
*2:Playgroundのコード保存機能で使ってます https://mrubyedge.github.io/playground/
