2026-05 鳥ワープ理論 - HADASHIKICK LAND

鳥が空を飛んでいた。鳥は普段、ものを考えないのだが、その日はとくにすることも、するべきことも、女の子とデートする予定もなく、暇だったのか、あるいは、およそ幸せとは言い難い生い立ちを持つこの鳥の、鳥なりのやるせなさ、鳥なりの苦悩、鳥なりの胸騒ぎ、そこから逃れようとする虚しいもがきなのか。わからない。わからないが、とにかく、その鳥は、その日、飛びながら、こんなことを考えた。「なぜ空は、どこまでも続くのだろうか？」およそまともで健康な鳥は、そんなことは考えない。むしろ、なにも考えないからこそ、鳥は空を飛べている。と言える。鳥だったらみんなわかっていることだ。「どうして鳥は空を飛べるのだろう？」とか、一度でも考えてしまったら、鳥として終わりである。通常、まともな論理的思考能力をもち、お父さんとお母さんの言うことをよく聞くような種類の動物は、空を飛ぶことができない。空を飛びたいと思っても、「ふつうに考えると、飛べるわけがない」と、至極真っ当な結論に至ってしまうためだ。逆に言えば、鳥はそういうことを一切考えないからこそ、空を飛べている。と言える。換言すれば、鳥はアホだから空を飛べている。一度でも、答えのない問いに迷い込んでしまったら、もうそんなのは鳥じゃない。鳥であるとは、どこまでも頭を空っぽにし、新鮮な風が入り込む余地を常に心に持つことでたり、その心の軽さが鳥を宙に浮かべているのだから。しかし今回、この鳥は、考えた。「もしかして」と、鳥なりに考えた。「理論的に考えて、鳥的に考えて……」鳥は考えた。鳥なりの論理的思考能力を駆使し、考えた。「どこまでも空が続く、なんてことは、ありえそうにない」考えた結果、今回、この鳥はこんな結論に達した。 ![[tori_zu1-1.png]] > (図1) 空が大地よりも広い場合、鳥の真下に地面がない場所が出現鳥の考察: 1. まず第一に、地上の大地は有限である。と、考えられる。 - 地上の人間は、未だに領土を争って戦争を繰り返している。従って、鳥的に考えて、大地には限りがある。 - 歴史を思い出してみよう。チンギス・ハーン、アレキサンダー大王。古代から、異様にやる気がある奴らは「世界制覇」を目標としていた。ここで、世界征服とは、大地が有限であることを前提にしていることに注意しよう。もしも、大地が無限にあるのに世界征服とか言っていたらアホである。(もちろん、大地が有限であってもアホである) - Q.E.D。 2. つまり地上に終わりがある。このことから、空にも終わりがある。という結論が自ずと導かれる。 - (図1) のように、空だけがどこまでも広がっているとすると、鳥が飛んでいくと大地のない空が現れてしまうことになる。 - 「そろそろ陸に下りようかな？」と鳥が思ったとき、下に陸地がなかったことは一回もない。 - 以上の考察から、空には終わりがある。 - Q.E.D。どこかに空の終わりがあるーーもちろん、この考えは平凡だ。鳥にも自覚はあった。もっと、鳥的な、空を我が物とせんとする鳥にふさわしく、自由に発想の翼を広げるべきか……？　いやしかし、いかなる理論も、まずは確かな土台、基礎を積み重ねていった先にあるはずだ。鳥なので、地に足はついていないが、しかし地に足がついた感じで考えを進めていかなければ、高い境地には届かないだろう。そのようにして丁寧につくった土台が強固であればあるほど、その上に鳥的な自由な発想が構築されうるはずなのだ。「しかし、空に終わりがあるとすると、おかしなことになるな」鳥は飛びながら考えた。鳥の考察 - もしも、空の終わりが図2のように、これ以上進めない壁のようなものになっている場合、Ａ地点で鳥は激突してしまう - Ｂ地点、つまりA地点の真下には、落下した鳥の亡骸が山積みになってしまうことになる。 ![[tori_zu2.png]] > (図2) 空の終わりが壁である場合、Ａ地点に激突した鳥はＢ地点に落下するところが、鳥が山積みになっている場所(Ｂ地点のような場所)は見たことも聞いたこともない。鳥といえど、墜落することはもちろんある。しかし墜落地点が空の終わりに沿うような分布はまったく見られない。従って、Ｂ地点は存在しない、と考えるのが妥当だ。このことから、空の終わりは壁ではない。と考えられる。もしかして。　空の終わりというのは、空の始まりと同じなのではないか？ ![[tori_zu3.png]] > (図３) 空の終わりに到達すると空のはじまりへワープつまり、上記の図３のような形になっているのではないだろうか？鳥が空の終わりに到達すると、またはじめに巻き戻る。このような仕掛けになっていれば、空の広さに限りがあるとしても、鳥が「終わり」に激突することはないわけだ。空の終わりは空のはじまりなのだから。「鳥ワープ理論」この理論に、鳥は満足した。この発想、鳥にしておくにはもったいない。鳥は自画自賛した。しかし鳥なので、学会で発表しようだとか、鳥podcastで喋ろうだとか、有名な鳥と対談しようとか、そういった功名心は露ほどもなかった。あるのはただ探究心と、自由な心だけだった。鳥ワープ理論が正しいとすると…… 鳥の考察 - 空を飛び続けるには、以下二つの条件が必要不可欠である 1. 「空を飛べる」 2. 「空の終わりに到達すると空のはじまりにワープすることができる」空を飛び続けるには、空の終わりに到達するとワープする能力が同時になければならない。そうでなければ、Ｂ地点に落下してしまう。空を飛ぶことが、鳥的に考えると、まじで簡単、人間でいえばチャリに乗るくらい簡単なのに、多くの動物が空を飛べない理由が、鳥ワープ理論によって説明可能になる。鳥の考察 - 実は、飛ぶ(1)がむつかしいというよりも、1と2の能力を合わせもつ動物がすくないのではないだろうか？たとえば、レミングという名前のげっ歯類の動物がいる。この動物は、奇妙なことに、集団で水に飛び込んでまとめて死亡する、といった行動が稀に観察されるらしい。もうおわかりだろう。鳥の考えによれば、レミングは自ら水に飛び込んでいるのではない。空を飛べるのだが、ワープすることはできないため、Ｂ地点に落下してしまうのだ。つまり、彼らは集団自殺をしているのではない。飛行中に、空の縁に激突し、揃いも揃ってその真下に落下してしまうために、同じ場所で死亡しているだけなのだ……。鳥の推理は、早朝の空気のように冴え渡り、様々な考察を重ね、自身の理論に改良を加えていった。さて、この鳥は、この推理に辿りついてから数日の後、消息を絶った。現在も、この鳥の消息は不明である。鳥はどこへ消えたのか。任意の位置にワープする能力を開眼させ、誰も行ったことのない場所へ行ってしまったのか。飛ぶ、という行為のメカニズムを頭で考え過ぎたために、飛ぶ能力を失い、地面に落下してしまったのか。それは誰にもわからない。わかっていることは、空は今日も青く、実際にそれなりに広いのだろう。ということだけだった。 ## ChibiRuby 1.0 近頃取り組んでいた、ピュア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#」という名前も「.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アプリとかもつくりたいですね。自分の場合は、なにもしない時間、ぼーっとしている時間がないと、なにをどうつくりたいかっていうところが見えないので、ひとつずつしかできない。ゲーム制作が迷子になっているせいでつくりたいものが渋滞している。