isamu

中島聡氏が中心になって開発しているMulmoシリーズ。一見するとそれぞれはバラバラなコンセプトで作られているアプリケーションであるようにみえます。 しかしその背景にあるのは共通の未来を見据えた概念があります。 MulmoChatは、話すとその場でアプリが生まれます。MulmoClaudeでは、頼んだものがデータになって手元に溜まっていきます。MulmoCastは、書いた台本から動画や音声を作ります。MulmoTerminalは、何本ものコーディングエージェントを並べて走らせる道具です。 こうした違いの奥に、4つの共通点があります。 ひとつめは、作る相手が変わったことです。 ソフトを作るコストが高かったあいだは、一本を大勢で分け合って元を取るしかありませんでした。だから誰もが「平均向け」を使っていました。レストランの一覧が欲しい、請求書を管理したい、単語を練習したい — そう思っても、使うのが一人しかいないソフトは採算が合わないので、作られませんでした。コストが消えると、この算数がひっくり返ります。作る相手が「市場」ではなく「目の前の一人」になるわけです。 MulmoChatで生まれるアプリは、会話が進むと次のものに置き換わっていきます。製品というより、話しているあいだだけ現れて消えるものです。MulmoClaudeのcollectionは逆で、アプリがスキーマという小さなデータになり、素のファイルとして手元に溜まっていきます。入り口の形は違っても、どちらも一人のために作られています。 ふたつめは、それを安全にする仕組みです。DSLを使ったハーネスがそれにあたります。 collectionとMulmoChatとMulmoCast、この三つはどれもLLMに任意のコードを書かせていません。書かせるのはスキーマや台本といった制約された中間表現だけで、実行は検証できるエンジンが持ちます。無効なものは走りません。 言われたとおりにコードを書かせてそのまま動かす作り方（いわゆるvibe coding）は、その場では動いて見えても、穴と不安定さを抱えやすいものです。コードを書いているのは、ときに自信満々で間違えるシステムです。そのコードが、読んで検証できない人の手に渡ります。一人ひとりが自分のアプリを作る世界になると、その危うさもそのまま一人ひとりに降りてきます。 先に制約を置いているのは、生成物の出来不出来に安全性を左右されないためです。仕組みの側が安全性と正確さを持っているので、プログラミングを知らない人でも、その場で作ったものを信用できます。 みっつめは、少し意外かもしれませんが、UIの優先度が下がったことです。 50年のあいだ、OSはアプリケーションを中心に回ってきました。探して、起動して、使い方を覚えるアイコンです。利用者はそこで、アプリとアプリのあいだを自分でつなぐ役をやらされてきました。 その代わりに中心へ来るのは、意図を語ることです。画面はなくなりませんが、主役ではなくなります。collectionでは、画面はスキーマから描かれます。アプリは「UI＋ロジック＋データの束」から「ロジックだけ」へ溶けていき、必要なときに文脈に合わせて出てくるものに変わります。 よっつめが、個人的にはいちばん面白いところです。同じ制約が、AIの進化を受け取る口になります。 MulmoCastでLLMが書くのはMulmoScriptという台本だけで、動画や音声やスライドへの変換はエンジンがやります。台本はどのモデルで作ったかに依存しないので、新しい画像や動画のモデルが出てきたら、同じ台本をそのまま流し直せます。データと仕組みが生き残り、入れ替わるのはモデルのほうです。制約を先に置いたことで、モデルが入れ替わっても使い続けられる寿命まで付いてきました。 この地続きは、GUI Chat Protocolという具体の規約として置かれています。片方の製品で書いた画面の部品が、もう片方でも動きうる形です。 MulmoTerminalがこの並びにいる理由も、ここでつながります。生成で「作る」は速くなったのに、「確かめる」は速くなっていません。MulmoTerminalは、その確かめる側に立っています。 詳細はこちら。 singularitysociety.org/artic…