Singularity Society@MulmoClaude/MulmoTerminal

シンギュラリティ・ソサエティは、中島聡x夏野剛の呼びかけにより設立された、内発的動機付けで行動するエンジニア、起業家、社会起業家をサポートするコミュニティー。MulmoClaude/MulmoTerminal開発中。AI/MaaS/VR/ドローン/Web3/教育

[Singularity Society@MulmoClaude/MulmoTerminal @SingularitySoci]

中島聡氏が中心になって開発している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は、その確かめる側に立っています。

詳細はこちら。

https://t.co/gIMFMWDsDp

[Singularity Society@MulmoClaude/MulmoTerminal @SingularitySoci]

AWSの設定ミスを瞬時に判断するゲーム。この速度で判断できるようになったら、かなり強固なクライド環境が作れそう。

[Toni @tonitoni415]

倍速なし。AIにこのゲームを最高速までやらせた。

Lv367、カードが落ちてくるのが速すぎて目で追えない。

人間は何レベルまで行ける？
https://t.co/zzcUb4LvMV

#ブラウザゲーム #情報セキュリティ

[Toni @tonitoni415]

https://t.co/UBxecCToZe

[Toni @tonitoni415]

APIの番人。｜目指せクラウドマスター
生存 81.7秒 / 420 pt
正しい検知 6・正常通過 6
架空のイベントを使う練習記録 https://t.co/TWFiXPPflJ

[Singularity Society@MulmoClaude/MulmoTerminal @SingularitySoci]

落ちゲーで遊んでいるだけで、AWSのセキュア設定が身につくプロダクト！！！
AWSのセキュリティが気になる人は遊んでみると良さそう！

[Toni @tonitoni415]

「俺自身がWAFになることだ」に影響を受けて、「目指せクラウドマスター」を作りました。
流れてくるAWSの操作から危険なものだけをタップする、脅威検知サービスの気持ちになれるゲームです。日英対応。
感想や分かりづらかった点を教えてもらえると嬉しいです！
https://t.co/jHhQ2FiYFQ

元ネタ: https://t.co/1xtwgwy8pS

[Singularity Society@MulmoClaude/MulmoTerminal @SingularitySoci]

AI時代のモノづくりで大事だと思っていること。

① アイデアは、とにかく作って試す
作るコストは劇的に下がった。昔なら企画書を書いて議論して…だったものが、今は半日でプロトタイプが動く。だったら頭の中で悩むより、作ってしまった方が早い。
② 作ってみないとわからないことが多すぎる
机上で完璧に見えたアイデアが、触ってみると全然しっくりこない。逆に「微妙かも」と思っていたものが、動かした瞬間に面白くなることもある。答えは手を動かした先にしかない。

③ 自分にピンとこなくても、誰かには刺さる
作り手の感覚は、ユーザーの感覚と一致しないことが多い。自分の好みで判断を止めず、できるだけ多くの人に触ってもらう。思いもよらない人から「これ欲しかった」と言われることがある。
④ ダメな機能を削除する勇気
作るのが簡単になった分、機能はいくらでも増やせてしまう。だからこそ、使われないもの・体験を濁すものは、思い切って消す。作ったコストが小さいなら、捨てるのも惜しくないはず。

作るのが安くなった時代に差がつくのは、「試す量」と「捨てる判断」だと思う。

[むい🍵 Mouï @ChronoToledo]

僕はIT業界の人間ではないけれど、この記事は面白かった。

それに説明が上手い。「なるほどー」と脳内相づちを打ちながら読みました。

https://t.co/02qOjMIRLn

[TUTAYADX @ki_mutaku]

めちゃくちゃ面白いし勉強になる。
確かに仕様書作って一気に作らせるのは違和感あったんだよな。
作る単位を小さくすることの重要性がすごく理解できた

https://t.co/smH3jmowkE

[山口征啓@地獄のAI @ID_HelpDesk]

note書きました。
今回は、急いで出したコードを借金にたとえた「技術的負債」、Martin Fowlerの二つの言葉、そして僕の大好きなYAGNIについてです。

プログラマの名言と法則をやさしく読む（6）｜yukihiroyamaguchi @ID_HelpDesk https://t.co/8JjX5QSoES

[Singularity Society@MulmoClaude/MulmoTerminal @SingularitySoci]

AI時代に、人間として価値を生むために　BootCampで必要なマインドセットや行動の指針です。

1. 「AIではなく、自分がやる理由」を持つ
AIがこれだけ多くのことをこなす時代に、人間に残された役割は何か。
指示を待ち、与えられた仕事をこなすだけなら、AIで十分です。人間に求められるのは、自ら課題を見つけ、仕事を作り出し、行動することです。
いま必要なのは「起業家マインド」。これは、会社を起こすことだけを意味しません。組織の中でも、個人のプロジェクトでも、社内ツール作りでも、自分で課題を見つけて動く姿勢を指します。

2. コーチャブルである
コーチャブルとは、他者の意見や助言を素直に受け止め、実行に移せることです。
助言を求めても、聞き入れず、行動も変えないのであれば、双方の時間が無駄になります。学ぶ意思は、助言を受けた後の行動に表れます。

3. 本気度は、実践と質問に表れる
サッカー選手になりたいのに、一度もボールを蹴ったことがない人は、そういません。ところが、プログラミングや起業では、何も試さないまま「やりたい」と言う人が少なくありません。
本気なら、まず手を動かす。試して、つまずいて、具体的な質問をする。何を質問するかを見れば、どれだけ実践しているかがわかります。

4. 毎日使うものを、自分で作る
自分で作ったものを、自分で使う。これが「ドッグフーディング」です。
毎日使えば、不便な点や足りない機能が見えてきます。自分自身が利用者になることで、改善すべき課題を具体的につかめます。

5. 完璧を待たずに出す
完成度が10％でも、価値を試せる形になったら、すぐに出して使ってもらう。
頭の中で完成度を高めるより、実際に使われることで得られる学びを優先します。作り込んでから確かめるのではなく、使ってもらいながら育てる。

6. 意見より、利用と支払いを見る
「意見をください」と頼めば、人は何かしら答えてくれます。立場のある人ほど、もっともらしい助言をしてくれることもあります。しかし、立派な意見が、そのままプロダクトの価値を示すわけではありません。
重視すべきなのは、お金を払ってくれる人、本気で使う人の声と行動です。
「その機能はよさそうですね」で終わらせず、「その機能に、いくら払いますか？」と聞く。好意的な感想と、実際の需要を区別することが大切です。

7. 「その機能があれば使う」を、そのまま信じない
「○○の機能があれば使う」という言葉だけで、開発の優先順位を変えないこと。
機能を追加しても、その人が使ってくれるとは限りません。本当に価値を感じている人は、多少の不足があっても、今あるプロダクトを使おうとします。
将来使うという約束より、今使っている人の行動を重視する。 改善の軸は、そこに置きます。

[Singularity Society@MulmoClaude/MulmoTerminal @SingularitySoci]

プログラミングは、AI が書いて、リンターとテストと AI レビューが確かめる世界になりました。人が一行ずつ見なくても、本番に出せるコードがどんどんできています。

でも、契約書・報告書・規程・議事録といった文書の仕事は、まだそこまで来ていません。分野ごとの道具は出てきているけれど、どこも手探りです。

プログラミングが速くなったのは、AI が書けるようになったからだけではありません。書いたものを機械が確かめる仕組みが先にあったからです。文書にも、それが要ります。

そこで作っているのが chaff です。文書のためのリンターとテストで、日本語と英語の文書をそのまま読みます。

・判定に AI を使わないので、毎回同じ結果
・条や番号の飛び、定義の二重、日付や合計の食い違いまで見る
・「直す計画」を JSON で出して、そのまま AI に書き直させられる
・書き直しで数字や日付が落ちていないかを compare で確かめる
・動かなかったルールを理由付きで出す（「指摘なし」を「全部見た」と取り違えない）

文章チェッカーは外れます。だから、外れた実例を集めて直す仕組みも作りました。実在の文書と判定を chaff-corpus に公開していて、外れた文書を PR で送ってもらうと、それをもとに chaff を直し、直したことが戻らないように守ります。

記事では、なぜ作ったか、使い方、textlint・Vale・PerfectIt・AI 契約レビューなど既存の道具との比較、文書の送り方までまとめました。

npx chaffjs 文書.md で、すぐ試せます。

https://t.co/H1hEARgEuF

[Singularity Society@MulmoClaude/MulmoTerminal @SingularitySoci]

良いイベントでしたが映像アーカイブがなかったので、記事がとても参考になります！！

[Michitoshi Yano @nagauta_jp]

イベント企画者として思い描いた映像を本人の価値観で受け止めてくれて嬉しすぎる！
https://t.co/aMcAmJJ6MG

[Singularity Society@MulmoClaude/MulmoTerminal @SingularitySoci]

情報漏洩対策を十分に講じられない中堅サービスは、今後も撤退や閉鎖に追い込まれていくでしょう。大手はおそらく、おおむね対応できる。一方、小規模なサービスでは、そもそも漏洩に気づいていないケースもありそう。

受託開発も、セキュリティまで意識して対応できる会社でなければ、生き残るのは難しくなる。何次請けなのか、誰が実際に作業しているのかも分からないような委託構造は、リスクが大きすぎて仕事を任せにくくなるでしょう。

同時に、AIの活用が進めば、「ひ孫請けに投げるくらいなら、元請けでやったほうがいい」という判断も増えるはず。独自の技術や強みを持たない下請け企業は、淘汰されていく。

結果として、セキュリティが甘いまま存続する小規模サービスと、対策の整った外資系サービス、そして対応力のある一部の日系企業が残る。そんな二極化が進むのかもしれません。

2026年10月は、AIとセキュリティを軸に、業界が大きく再編されるきっかけの月になる気がします。

一方、政府や役所がここぞとばかりに、実効性の乏しいガイドラインや法案を増やし、天下り先をつくるような方向に進まないかは気になります。そうなれば、現場の負担ばかりが増え、結局、日本のITが世界からさらに遅れを取ることにもなりかねません。

https://t.co/KGbHrsUmhV

[Singularity Society@MulmoClaude/MulmoTerminal @SingularitySoci]

空を飛ぶ車を作る会社が従業員に出社を求めるのはよく分かるけど、資料作って根回しする会社が出社を求めるのは意味がわからない。
出社を求めるなら、そのくらいのイノベーションをできる仕組みをつくろう。
でも、殆どの仕事はリモートで良いと思うよ。

[Singularity Society@MulmoClaude/MulmoTerminal @SingularitySoci]

MulmoTerminalってなに？っていう人のために動画をつくりました。Claude Codeなどのコーティングエージェントを複数使うときに便利になる機能を満載しています！！

https://t.co/EYVlwg2p9z

[Toni @tonitoni415]

MulmoTerminalにTailscale経由でアクセスする方法｜bull https://t.co/3sh4hTO6Df #zenn
書きました

[Singularity Society@MulmoClaude/MulmoTerminal @SingularitySoci]

MulmoClaude / MulmoCast / MulmoTerminalの解説動画はSingularitySocietyにあります。
随時情報を更新しているのでこちらを登録して参照してください！！

https://t.co/WEoVt9vExE

[Singularity Society@MulmoClaude/MulmoTerminal @SingularitySoci]

@33339999g 別の進化をしていますが、MulmoTerminalはMulmoClaudeの変形バージョンでもあります。ぜひ、どれも活用してください！！

[Singularity Society@MulmoClaude/MulmoTerminal @SingularitySoci]

中島聡氏が中心になって開発している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は、その確かめる側に立っています。

詳細はこちら。

https://t.co/gIMFMWDsDp

[Michitoshi Yano @nagauta_jp]

日本コミュニティを立ち上げてからRaycastという現代の最高傑作をつくる人の話をいつか日本の人に届けたいと思っていました
それをtechworldの市川さんとvantaの河野さんが叶えてくださいました！！本当にありがとうございます😭
Pedroの特異で素晴らしい人生の挑戦とRaycastに賭ける想いを聞くと僕もそんな素晴らしい製品を作りたいと刺激をくれる素晴らしいインタビューです！

[Singularity Society@MulmoClaude/MulmoTerminal @SingularitySoci]

@BudgetIce37955 この機能の良さが分かる人がいて嬉しいです！！