近頃取り組んでいた、ピュアC#製mruby vm実装である MRubyCS、1.0 のリリースと同時に名前を変更することにしました。 新しい名前は 「ChibiRuby」 (ちびRuby) です。 [Project Renaming (Again) · Issue #153](https://github.com/hadashiA/ChibiRuby/issues/153) 名前を変えたとて、認知されやすくなるとか、コンセプトが伝わる、みたいなことはあんまり考えてません。割と自分にとって愛着を持てそうな固有名を与える、という動機を優先してあたらしい名前を選びました。 これまでは、mrubyに対しての強い互換性というコンセプト、そして C# であることを表明したい、という理屈から「MRubyCS (mruby/cs)」を名乗っていました([issues#1](https://github.com/hadashiA/ChibiRuby/issues/1)) が、そうした社会性からの動機で名前をつけている割に、ちょっと名前の通りが悪かったかなと思います。 - C#/Unity界隈ではそもそも Ruby が知られていない。「mruby」はもっとわかりずらい - Ruby界隈では C# であることの利点が伝わりずらい - Ruby界隈では、mruby/〇〇 というネーミングスタイルが慣習的に存在はしているが、一般Rubyユーザには十分に知られていない。むしろ、 PicoRuby、monoruby、JRuby、TruffleRuby…… など、 「〇〇Ruby」という苗がRuby VM 実装として受け止められやすい。 今思うと、「mruby/〇〇」 というスタイルは、このスタイルを知っている人間同士であればわかりやすいのだけど、発話したときの語調がけっこう長い。「エムルビー」の段階でけっこう長い。「エムルビー」のお尻に何か足すともはや固有名詞として認知されずらい。 そうこうするうちに、MRubyCS.* のパッケージがどんどん増えたし、 dotnet tool も追加はれ、このプロジェクト固有だとはっきりわかる名前空間があったほうが名前の機能としても良いな、という気持ちになってきた。 このプロジェクトの名前について、「◯◯.NET」という名前、「〇〇Sharp」という名前を踏襲したほうがいい、という意見をもらいがちなんですが、この辺りの名前は個人的にはあまり好きではない。 まともに書いたプログラミング言語は少なめに見積っても10以上はあり、それなりに客観的な目線でC#を見ているつもりですが、ライブラリ開発活動ではもはやほぼ100% C#にコミットしているくらいC#が優秀だと思っているし、C# の過少評価は払拭されるべきだ、とも常々思ったます。 そんな僕から言いいたいことがあります。 「C#」という名前も「.NET」という名前も、初見の者たちへ良いイメージを与えていない。と思います。生まれ変わったはずなのに、リブランディングにこの名前は貢献していない。 - 「C」「C++」を冠していることは、新しくモダンなランタイムであるイメージにつながらない。21世紀に新しく書き直された最新のクロスプラットフォーム JITつきVMに与える接頭辞じゃない。 - 「C#って、C++ をさらに ++ したやつなんですよね？　C++のさらに強いやつなんですよね？」この質問はもう終わりにしよう。 - 「しーしゃーぷ」という間延びした語感 - もしもバンド名だったら、男女二人組デュオがピアノとハーモニカとか吹いてそうなゆったりとした語感じゃだめなんです。 - もっと、「Zig」とか、もしもバンド名だったら、隣街から苦情が来そうな硬質なギターサウンドを鳴らしてそうな名前にするべき。 - 「.NET」の意味がわからない。「JVM」はわかる。「JVM」は知っているけど「.NET」の意味を説明できる人間が少ない。そんな世の中は間違っている。 ここで注意したいこと。「.NET」は意味がまったくわからないのだが、「dotnet」はかっこいい。という点だ。いきなり「.」からはじまるところは、はっきりいっておしゃれである。ここは評価したい。 以上のような理由から、私はライブラリに「〇〇Sharp」という名前をつけることに懐疑的である。もちろん「シャープ」はそれなりにかっこいいことは認めるが、語感がよくない。語呂もよくない（音の数が多い）また、私にとって「◯◯Sharp」は、書き直される前の過去の Windows限定の「.NET Framework」を過度に想像させる。 ……以上のような理由から、悩んだ末、僕のmruby ランタイム実装には「Sharp」とはつけませんでした。 ## ChibiRuby.Debugger 実は 1.0 のロードマップはぜんぜん達成していないんですが、自分のプロジェクトで使っていることもあり、さったさと名前を変えたかったので 1.0 ということにしました。 最新版では以下のものが入りました。 - デバッガー - UnityFiberScheduler - Ruby の型定義ファイルの提供(自動ビルド) - 実装しているRubyメソッドノAPIリファレンスとしても使える - この辺をちゃんとしていくと、mrubyにない機能や本家とは違ったAPI を提供する場合にもドキュメントが整理しやすい。 - macOS/windows/linux に加え、ios/android/browser-wasm へも mrbコンパイラを提供することにした - ランタイムはピュアC# なんだけど Rubyパーサ部分がprism。 本番ではバイトコードだけビルドする想定なのだけど、便利かなと思ってプラットフォームいろいろ追加した。 デバッガーは、なんと Unity 上で動いているプロセスに対して、 JetBrains製品、VSCode、Zed など、DAP対応のエディタからならなんでもアタッチ可能です。 ![[demo_debugger_set.gif]] > ステップイン/ステップオーバー/ローカル変数書き換えをサポート UnityをPlayしっぱなしで mrubyスクリプトをホットリロードするようなケースで割と便利だと思います。 DAP については完全に開発環境用の機能なので、あまり実装の細かいところまでは見ておらず、けっこう claude に書かせてました。ただやっぱり APIサーフェイスが汚なかったり、設計に注目しはじめるとそのまま使えないアドホックでメンテしたくなちコードになりがちなので、割と「ここ直してー」とつっこみは入れ続けてましたが、手書きはほとんどしてないかも。 ## [NoJsonSchema](https://github.com/hadashiA/NoJsonSchema) 珍しく小さいライブラリをつくって公開してみました。 DAP（Debug Adapter Protocol ）のサーバー（JSON over TCP）をつくるためだけにつくったツールです。 JSON schemaが既に手元にある場合、そこからJSONライブラリに依存しない高速なC#型とシリアライザを自動生成するツールです。 このツールの唯一の存在意義は、「生成結果がライブラリ非依存」であること。 .NET環境と Unity 環境に対応したライブラリにJSON パーサがほしい場合、なにを使うかは微妙な問題です。UnityではJsonUtilityもあるけど80%の確率だNewtonsoftが何故かいつのまにか入っていたり、かなり強い気持ちがなければSystem.Text.Jsonはない、ていうのが実際のところだと思います。ライブラリ側としては、依存の依存としてSystem.Text.Jsonの使用を強いるより、何にも依存しない状態が理想だと思うんですやね。 (自分だったら使ってないくそでかいjsonライブラリが依存の依存としてくっついてくるようなライブラリをできれば入れたくない） 「ゼロアロケーション」といえばUnity C#界に一大ムーブメントを巻き起こした重要な用語でありますが、「ゼロディペンデンシー」にこだわるというのも最近はけっこうアツい。そんな気もしたりしなかったりします。 自分の考えでは、アプリケーションに対して外部ライブラリ依存を増やす、という行為自体が複雑さを上げるマイナスの行いで、ライブラリを入れるなら、そのマイナスを払拭して余りあるメリットがなければいけない、と思う。 だから、「1つの問題が解決する」くらいでは、よくてプラスマイナスゼロ、いや全体最適を考えると複雑性は増しているので、悪くなっていると思ってます。 そういう指向なので、あまり目的が限定され過ぎている小さなライブラリをつくる、という方向には興味が向きずらかったんですが、ほとんど労力をかけずにスクラッチでほしいツールが生成できるのでなんかやってみた。 「Unityでゼロディペンデンシーで動く、まともなAPI とまともなパフォーマンスの〇〇」このお題でアイデアを出していくとけっこう欲しいものはあるかもしれないですね。 ## [VitalRouter.MRuby](https://github.com/hadashiA/VitalRouter) ![[ss 2026-06-05 15.16.23.png]] mrubyからC#へ非同期メッセージングが簡単に書けるフレームワークVitalRouter.MRubyですが、自動的に追加されるRubyメソッドの型定義ファイル（.rbs）を自動生成できるようになりました。 でもなんか、Unityプロジェクト内の特定ディレクトリにあるmrubyスクリプトたちに対しでコード補完とかちゃんと動くようにするの意外とだるいのでちゃんと考えるともっと改善できそうだけどあんまり困ってないので掘ってない。 ## ゲーム制作 今月もけっきょくなんも公開していません。 けっこう飽きてるのでいまやってるやつはさっさと手放して次に行きたい。 エーアイでアプリ開発が簡単になったので、Webアプリとかもつくりたいですね。 自分の場合は、なにもしない時間、ぼーっとしている時間がないと、なにをどうつくりたいかっていうところが見えないので、ひとつずつしかできない。 ゲーム制作が迷子になっているせいでつくりたいものが渋滞している。