Singularity Society の周辺では、いくつものツールが並行して生まれている。MulmoChat、MulmoClaude、MulmoTerminal。一見するとバラバラの実験に見えるが、作っている側から見ると、これらは同じ一つの方向を向いている。この記事では、それぞれの公式ドキュメントで事実を確かめながら、何がどうつながっているのかを整理する。
この記事は、中島聡が作る各プロジェクト（MulmoChat・MulmoClaude・MulmoTerminal・MulmoCast）を、公開ドキュメントに当たって筆者が整理したものです。「いずれ融合する」「FDE 的な仕組みである」といった見立ては、中島のこれまでの言動をもとにした筆者の考察であり、ドキュメント上で確定している事実とは分けて書いています。
1. 二つの「動的にアプリを作る」やり方
いま起きている一番大きな変化は、「アプリを事前に作って配る」から「必要なときにその場で立ち上げる」へ、という移行である。
ここで本質は「瞬時に作れること」そのものではない。もとをたどれば、アプリを作るコストが十分に小さくなったことが先にある。コストが高かった時代は、一本のソフトを大勢で分け合って元を取るしかなく、誰もが「平均向け」を使わされていた。コストが消えると、その算数がひっくり返る。一人ひとりが、自分の必要に応じて、その場で、自分だけのアプリを作れる——「その場で」「瞬時に」はその結果にすぎない。重要なのは、作る相手が「市場」ではなく「目の前の一人」になったことだ。
そのやり方が、少なくとも二通り生まれている。
- 話すと、その場でアプリが生まれて、使われる —— MulmoChat
- アプリがデータ（スキーマ）になり、蓄積される —— MulmoClaude の collection
同じゴールに、別の入り口から迫っている。順に見ていく。
2. MulmoChat — 話すと、アプリがその場で生まれて消える
MulmoChat は、公式リポジトリの説明では「マルチモーダルな AI チャット体験の新しいパラダイムを探る研究プロトタイプ」と位置づけられている。従来のチャットがテキストの往復なのに対し、MulmoChat では会話をしながら、画像・地図・プレゼン・ゲームといった視覚的で操作可能なものが、会話の流れの中で直接キャンバスに現れる。
入り口は音声である。README の手順も「Start Voice Chat を押して話しかける」であり、マイクを許可して話すところから始まる。
思想を書いた LLM_OS.md は、Andrej Karpathy の「LLM OS」構想を土台に、これをアーキテクチャと UX の設計にまで広げている。核心はこうだ。50 年のあいだ OS は「アプリケーション」——探して、起動して、使い方を覚えるアイコン——を中心に回ってきた。そこでは利用者が、アプリとアプリのあいだを自分でつなぐ「オーケストレーター」をやらされている。この文書はそれを「アイコンの海」と呼ぶ。
その代わりに置くのが、意図（intent）を語ることだ。GUI はなくならないが、主役ではなくなる。LLM が利用者の意図を理解し、必要な「capability（能力）」を動的に組み合わせ、必要なときだけ文脈に合わせた GUI を生成して結果を返す。アプリは「UI＋ロジック＋データの束」から「ロジックだけ（UI は都度生成）」へと溶けていく、と表に整理されている。
つまり MulmoChat 側の「アプリ」は、話した瞬間に生成され、その場で使われ、会話が進めば次のものに置き換わる、動的で揮発的なものだ。
声で頼むとプレゼンが動画になり、AI が講演を聞いて絵を描き続ける —— MulmoChat のデモ（Singularity Society）。
AI ネイティブな OS を今日ゼロから作るとしたら —— 中島聡（Windows 95 開発）が語る MulmoChat の背景（Singularity Society）。
3. MulmoClaude の collection — アプリがデータになる
もう一方の MulmoClaude は、自分のパソコンの中で動く、自分だけの AI アシスタントを「育てる」ためのツールだ（MIT ライセンス、npx mulmoclaude@latest で起動）。記憶も、データも、作ったアプリも、すべてワークスペースの中の素のファイルとして手元に残る、という点を強く打ち出している。
ここで本記事の軸になるのが collection である。設計思想を書いた MANIFEST.md の「Pattern B: Applications become data（アプリケーションがデータになる）」が、まさにこれを説明している。
collection とは、小さな宣言的スキーマ——フィールド、項目どうしの関係、どの値で「完了」とみなすか、いつリマインドを出すか、どう繰り返すか——を記述した、一種のドメイン固有言語（DSL）だ。利用者が「こういうものを管理したい」と日常の言葉で言うと、エージェントがそのスキーマと中身のレコードを生成し、ホストがそれをテーブル・かんばん・カレンダーとして描画し、検証し、通知や繰り返しを実行する。
MANIFEST.md はこれを一行でこう言い切る。
The records are data. The schema is the application. The model is the runtime. （レコードはデータ。スキーマがアプリケーション。モデルがランタイム。）
従来のアプリが「データベース＋ORM＋UI フレームワーク＋ワークフローエンジン」の四点セットだったのに対し、collection ではデータベースは素のファイルになり、ORM は消え、UI はスキーマから描画され、ワークフローはホストの厳密なルールと素の文章に分かれる。レストランの一覧、請求書の管理、単語の練習——「利用者一人」のためのソフトは、これまで採算が合わず作られなかった。エージェントが一分の会話でスキーマを書けるなら、その算数はひっくり返る。
そして MulmoClaude には、記憶のための wiki もある。README によれば、これは Karpathy の「LLM Knowledge Bases」のアイデアに触発されたもので、素の Markdown ファイルとして置かれ、[[wiki link]] 記法でページどうしがつながる、育っていく知識ベースだ。collection（構造化データ）と wiki（相互リンクされた記憶）という二つの蓄積の形が、ここに同居している。
MulmoChat が「揮発的なアプリ」なら、MulmoClaude の collection は 蓄積されるアプリだ。アプリそのものがデータとして手元に残り、公開レジストリに出して他人がワンクリックで取り込むこともできる。
LLM が主役の「自分専用アプリ」—— MulmoClaude のデモ（Singularity Society Bootcamp 第4期キックオフ）。
4. 二つをつなぐ土台 — LLM-as-controller と GUI Chat Protocol
この二つは、別々のアイデアではない。同じ一つの思想の上に立っている。
MANIFEST.md は、AI ネイティブなアプリを支える柱として、次の二点を挙げている。
- エージェントは「ユニバーサルなコントローラ」である。MVC のコントローラが「入力を受けてどのモデルを呼びどのビューを描くか決める」役なら、LLM も同じ仕事を自然言語という別の入力でやる。しかも一つのアプリのコントローラではなく、本来なら別々のアプリだったはずのプラグイン群のレジストリ全体を横断して操る。「先月の経費を円グラフで」と言えば、会計プラグインから読み、グラフプラグインへ書く——が一回の発話で済む。
- チャットが GUI を呼ぶ。エージェントの返事は文字列ではなく、内容に合った形式——Markdown、HTML、プレゼン、そして GUI を伴うツール呼び出し（グラフ・フォーム・wiki・3D）——から選ばれる。逆に、利用者から構造化データが欲しいときはフォームを出して埋めてもらう。入出力の両方向がマルチモーダルになる。
MulmoChat の LLM_OS.md が言う「意図を語る／capability を動的に組む／必要なときだけ GUI」と、これは同じことを別の言葉で言っている。だから二つは地続きなのだ。
その「地続き」を実際に支えているのが GUI Chat Protocol（npm パッケージ gui-chat-protocol）である。MANIFEST.md の説明では、エージェントとツールのあいだには tool calls と MCP（Model Context Protocol） という既存のオープン標準がすでにある。しかしそれらは、ツールの結果が単なるデータではなく、利用者が操作し、ホスト側に処理を呼び返す操作可能な GUI（グラフ、フォーム、wiki、3D シーンなど）だったときに何が起きるかを定めていない。その隙間を埋めるのが GUI Chat Protocol で、MCP の上に乗って視覚レイヤーを拡張する小さなオープンな契約——イベントの購読／配信、スコープ付きの REST、ロケール、ログ、エラーの隔離——を定義する。ホストが実装し、プラグインが消費する。両者は設計上、切り離されている。
ここが重要な点だ。MulmoChat も MulmoClaude も、そのプラグインは同じこのプロトコルに対して書かれている。だから、片方で作った GUI プラグインがもう片方でも動きうる。融合は理念ではなく、プロトコルという具体で担保されている。
5. 融合 —— 揮発的な生成と、蓄積される構造（筆者の考察）
ここからは筆者の考察である。
MulmoChat の「話すとその場で生まれて消えるアプリ」と、MulmoClaude の「データとして蓄積される collection」は、最終的には一つに融合するはず——中島のこれまでの言動から、筆者はそう見ている。
これは、両者が同じ土台（LLM-as-controller、chat summons GUI、MCP＋GUI Chat Protocol）に立っていることを踏まえれば、方向としては自然に見える。会話の中でその場に立ち上がったものが、価値があれば構造（スキーマ）として手元に残り、次からは蓄積された資産として呼び出せる——揮発と蓄積は、同じ連続体の両端になる。音声で意図を語る入り口（MulmoChat）と、素のファイルとして自分の手元に残る蓄積（MulmoClaude）が、一つの体験の中でつながる、という絵だ。
ただし、これはあくまで方向性の仮説であって、現時点で「統合版」が公開されているわけではない。公開されているのは、同じ思想とプロトコルの上に立つ二つの実装である。
6. もう一つの軸 — 並列と、ビジネス向けハーネス
ここまでは「どうアプリを作るか」の話だった。中島が自分で作りたいものとして挙げるもう一つの軸が、並列である。
MulmoTerminal は、複数のコーディングエージェントのセッションを並べて走らせ、「いまどれが自分を必要としているか」を色で示すブラウザ端末だ（tmux 基盤、git worktree で作業を隔離、MIT）。青は作業中、緑は完了、アンバーは待ち。利用者は探し回るのをやめ、光っているところへ行く。一人のエージェントを回しているときは要らないが、何本も走らせて「どれが止まっているか」を見失うときのための道具だ、と README は言う。
この延長にあるのが、ビジネス向けハーネスの記事で論じた仕組みだ。そちらの記事は、生成 AI で「作る」は速くなったのに「確かめる」が速くなっていない、という問題を扱った。AI の成果物を人の目に届く前に「止める」か「通す」かを決める仕組み——ソフトウェア開発で先に動いているその層（ハーネス）を、ビジネスの業務に移植する、という提案だった。
この並列とハーネスを、筆者は FDE（フォワードデプロイド・エンジニア）的な仕組みの一つだと見ている。これも中島のこれまでの言動をもとにした考察である。FDE は、作ったものを顧客の現場に持ち込み、その場で噛み合わせて成果を出す動き方を指す。並列に走るエージェント群と、それを一定品質で現場に届けるためのハーネスは、エンジニアが現場に入り込んで回していた仕事を、仕組みとして回すための層だ——という捉え方だ。
7. もう一つの出力形式 — MulmoCast
第 4 節で、MulmoClaude のエージェントが返す形式の一つとして「MulmoScript（マルチメディアのプレゼン）」を挙げた。その MulmoScript を実際に動画や音声にするのが MulmoCast（完全ガイド）だ。
MulmoCast は、AI と人間が協働してコンテンツを作る、AI ネイティブ時代のマルチモーダルなプレゼンテーション基盤である（MIT ライセンスのオープンソース）。公式リポジトリの説明によれば、PowerPoint や Keynote が AI 以前に人間の作り手向けに設計されたのに対し、MulmoCast は最初から AI と手を組んで動くよう作り直されている。
その中核が MulmoScript ——脚本や Web マークアップのように働く JSON ベースの中間言語だ。LLM が MulmoScript を生成し、そこには構成からナレーション、ビジュアルまでが記述される。MulmoCast はそれを受けて、動画・ポッドキャスト・スライドショー・PDF・マンガといった複数のフォーマットへ出力する。
ここで、この記事を貫く型がもう一度現れていることに注目したい。collection では「スキーマがアプリケーション、モデルがランタイム」だった。MulmoCast では、MulmoScript という精密な中間生成物を LLM が書き、エンジンがそれを実行する。LLM はエンジンそのものではなく、精密な生成物を自然言語から書き起こすインターフェースだ——という同じ構図だ。collection がデータアプリの、MulmoChat が揮発的な GUI の例なら、MulmoCast はマルチメディア表現における同じ思想の実装である。
Introducing MulmoCast: A New Era of Presentations —— MulmoCast の紹介動画（中島聡のLife is Beautiful）。
8. なぜ DSL なのか —— 普通の vibe coding との違い
ここまでの三つ（collection・MulmoChat・MulmoCast）に共通するのは、LLM に自由にコードを書かせていないことだ。ここが、いわゆる vibe coding——「こういうものを作って」と頼んで LLM に任意のコードを書かせ、そのまま動かすやり方——との決定的な違いである。
vibe coding で生成したアプリは、その場では動いて見えても、セキュリティ上の穴や不安定な挙動を抱えやすい。コードを書いたのは「ときに自信満々で間違える」システムで、それを読んで検証できない人の手に渡るからだ。一人ひとりがその場でアプリを作る世界では、この危うさがそのまま一人ひとりに降りかかる。
この三つが取る解は、LLM に書かせるものを、任意のコードではなく、制約された中間表現（DSL）に限定することだ。
- collection では、LLM が書くのはコードではなくスキーマだ。
MANIFEST.mdが言うように、不変条件はホスト側にあり、モデルが書いたものは実行前にすべて検証される——無効なアプリは走らない。ビューも、通知も、繰り返しのルールも、推測しないエンジンのコードが担う。 - MulmoCast では、LLM が書くのは MulmoScript（JSON の台本）だけで、画像・動画・スライドへの変換はエンジンが行う。出力できる形式はあらかじめ決まっていて、生成物はその枠の中に収まる。
- GUI Chat Protocol は、GUI プラグインとホストのやりとりを、スコープ付きの配信・エラーの隔離といった契約として定める。プラグインが一つ転んでも、ホスト全体は巻き込まれない。
つまり DSL は、単に便利な書き方なのではない。安全性・正確性・安定性を、個々の生成物に頼らず仕組みの側で保証するための要である。LLM は「精密な中間表現を自然言語から書き起こすインターフェース」に徹し、実行の責任は検証可能なエンジンが持つ。この役割分担があるからこそ、プログラミングの知識がない人でも、安全で正確なアプリをその場で作れる。自由なコード生成の危うさを、DSL という制約で引き受けているのだ。
9. まとめ — 作っているのは「アプリ」ではなく、その下の層
整理すると、こうなる。
| プロジェクト | 何をするか | アプリの性格 |
|---|---|---|
| MulmoChat | 音声で会話しながら、その場で GUI が生成される（研究プロトタイプ） | 揮発的 —— 話すと生まれ、使われ、消える |
| MulmoClaude の collection | 宣言的スキーマ（DSL）でアプリがデータになる | 蓄積的 —— データとして手元に残り、共有もできる |
| MulmoCast | MulmoScript（JSON の台本）から動画・音声・スライドなどを生成 | 中間生成物 —— LLM が台本を書き、エンジンが実行する |
| MulmoTerminal / ハーネス | 並列エージェントを観測し、一定品質で現場に届ける | 下の層 —— 作る速さではなく、確かめて通す仕組み |
バラバラに見える三つは、「LLM をコントローラに据え、チャットが GUI を呼び、アプリはアイコンではなく意図から立ち上がる」という一つの思想の、違う面である。そして MulmoChat と MulmoClaude は、GUI Chat Protocol という具体のプロトコルで地続きになっている。
作っているのは、個々の便利なアプリではない。アプリがその上で生まれ、蓄積され、現場に届く——その下の層だ。