Singularity Society@MulmoClaude/MulmoTerminal

中島聡氏が中心になって開発している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…

🕵️‍♀️ メールの「間違いさがし」で、フィッシング耐性を鍛えよう tenkacloud.com/mail-detectiv… 悪意のあるクラッカーの侵入口は、高度なAPIの悪用やゼロデイ攻撃よりも、まだまだメールやSMSを使ったフィッシング／スミッシングが多くを占めています。 狙われるのはシステムではなく「人」。 どれだけ堅牢な仕組みを作っても、たった1回のクリックで突破されてしまう。 とはいえ、フィッシングを見抜く練習って、普段なかなかできないんですよね。 実際の怪しいメールを開くわけにもいかないし、研修資料を読むだけでは「目」は育たない。 そこで紹介したいのが「メールの間違いさがし。」 🔍 遊び方はシンプル ・正規の「見本メール」と「調べるメール」を見比べる ・危険につながる違いだけをタップ ・送信元ドメイン、リンク先、文面の不自然さ…ゲーム感覚で怪しいポイントを探す ✅ ここが良い ・登録不要、ブラウザーですぐ遊べる ・登場するのはすべて架空のメール。リンクや添付は開かないので安全 ・日本語／英語対応 ・スマホでもサクッとできる短時間ゲーム 「なんとなく怪しい」ではなく、「どこが、なぜ危ないのか」を瞬時に見抜く感覚を、遊びながら身につけられます。 セキュリティ担当の方は社内の啓発に、 エンジニアの方は家族や同僚への布教に、 そして自分の腕試しにもぜひ。 あなたは全部見抜けますか？👀 #フィッシング #スミッシング #セキュリティ #情報セキュリティ #TenkaCloud

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

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

AI時代のモノづくりで大事だと思っていること。 ① アイデアは、とにかく作って試す 作るコストは劇的に下がった。昔なら企画書を書いて議論して…だったものが、今は半日でプロトタイプが動く。だったら頭の中で悩むより、作ってしまった方が早い。 ② 作ってみないとわからないことが多すぎる 机上で完璧に見えたアイデアが、触ってみると全然しっくりこない。逆に「微妙かも」と思っていたものが、動かした瞬間に面白くなることもある。答えは手を動かした先にしかない。 ③ 自分にピンとこなくても、誰かには刺さる 作り手の感覚は、ユーザーの感覚と一致しないことが多い。自分の好みで判断を止めず、できるだけ多くの人に触ってもらう。思いもよらない人から「これ欲しかった」と言われることがある。 ④ ダメな機能を削除する勇気 作るのが簡単になった分、機能はいくらでも増やせてしまう。だからこそ、使われないもの・体験を濁すものは、思い切って消す。作ったコストが小さいなら、捨てるのも惜しくないはず。 作るのが安くなった時代に差がつくのは、「試す量」と「捨てる判断」だと思う。

AI時代に、人間として価値を生むために　BootCampで必要なマインドセットや行動の指針です。 1. 「AIではなく、自分がやる理由」を持つ AIがこれだけ多くのことをこなす時代に、人間に残された役割は何か。 指示を待ち、与えられた仕事をこなすだけなら、AIで十分です。人間に求められるのは、自ら課題を見つけ、仕事を作り出し、行動することです。 いま必要なのは「起業家マインド」。これは、会社を起こすことだけを意味しません。組織の中でも、個人のプロジェクトでも、社内ツール作りでも、自分で課題を見つけて動く姿勢を指します。 2. コーチャブルである コーチャブルとは、他者の意見や助言を素直に受け止め、実行に移せることです。 助言を求めても、聞き入れず、行動も変えないのであれば、双方の時間が無駄になります。学ぶ意思は、助言を受けた後の行動に表れます。 3. 本気度は、実践と質問に表れる サッカー選手になりたいのに、一度もボールを蹴ったことがない人は、そういません。ところが、プログラミングや起業では、何も試さないまま「やりたい」と言う人が少なくありません。 本気なら、まず手を動かす。試して、つまずいて、具体的な質問をする。何を質問するかを見れば、どれだけ実践しているかがわかります。 4. 毎日使うものを、自分で作る 自分で作ったものを、自分で使う。これが「ドッグフーディング」です。 毎日使えば、不便な点や足りない機能が見えてきます。自分自身が利用者になることで、改善すべき課題を具体的につかめます。 5. 完璧を待たずに出す 完成度が10％でも、価値を試せる形になったら、すぐに出して使ってもらう。 頭の中で完成度を高めるより、実際に使われることで得られる学びを優先します。作り込んでから確かめるのではなく、使ってもらいながら育てる。 6. 意見より、利用と支払いを見る 「意見をください」と頼めば、人は何かしら答えてくれます。立場のある人ほど、もっともらしい助言をしてくれることもあります。しかし、立派な意見が、そのままプロダクトの価値を示すわけではありません。 重視すべきなのは、お金を払ってくれる人、本気で使う人の声と行動です。 「その機能はよさそうですね」で終わらせず、「その機能に、いくら払いますか？」と聞く。好意的な感想と、実際の需要を区別することが大切です。 7. 「その機能があれば使う」を、そのまま信じない 「○○の機能があれば使う」という言葉だけで、開発の優先順位を変えないこと。 機能を追加しても、その人が使ってくれるとは限りません。本当に価値を感じている人は、多少の不足があっても、今あるプロダクトを使おうとします。 将来使うという約束より、今使っている人の行動を重視する。 改善の軸は、そこに置きます。

プログラミングは、AI が書いて、リンターとテストと AI レビューが確かめる世界になりました。人が一行ずつ見なくても、本番に出せるコードがどんどんできています。 でも、契約書・報告書・規程・議事録といった文書の仕事は、まだそこまで来ていません。分野ごとの道具は出てきているけれど、どこも手探りです。 プログラミングが速くなったのは、AI が書けるようになったからだけではありません。書いたものを機械が確かめる仕組みが先にあったからです。文書にも、それが要ります。 そこで作っているのが chaff です。文書のためのリンターとテストで、日本語と英語の文書をそのまま読みます。 ・判定に AI を使わないので、毎回同じ結果 ・条や番号の飛び、定義の二重、日付や合計の食い違いまで見る ・「直す計画」を JSON で出して、そのまま AI に書き直させられる ・書き直しで数字や日付が落ちていないかを compare で確かめる ・動かなかったルールを理由付きで出す（「指摘なし」を「全部見た」と取り違えない） 文章チェッカーは外れます。だから、外れた実例を集めて直す仕組みも作りました。実在の文書と判定を chaff-corpus に公開していて、外れた文書を PR で送ってもらうと、それをもとに chaff を直し、直したことが戻らないように守ります。 記事では、なぜ作ったか、使い方、textlint・Vale・PerfectIt・AI 契約レビューなど既存の道具との比較、文書の送り方までまとめました。 npx chaffjs 文書.md で、すぐ試せます。 zenn.dev/singularity/article…

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

情報漏洩対策を十分に講じられない中堅サービスは、今後も撤退や閉鎖に追い込まれていくでしょう。大手はおそらく、おおむね対応できる。一方、小規模なサービスでは、そもそも漏洩に気づいていないケースもありそう。 受託開発も、セキュリティまで意識して対応できる会社でなければ、生き残るのは難しくなる。何次請けなのか、誰が実際に作業しているのかも分からないような委託構造は、リスクが大きすぎて仕事を任せにくくなるでしょう。 同時に、AIの活用が進めば、「ひ孫請けに投げるくらいなら、元請けでやったほうがいい」という判断も増えるはず。独自の技術や強みを持たない下請け企業は、淘汰されていく。 結果として、セキュリティが甘いまま存続する小規模サービスと、対策の整った外資系サービス、そして対応力のある一部の日系企業が残る。そんな二極化が進むのかもしれません。 2026年10月は、AIとセキュリティを軸に、業界が大きく再編されるきっかけの月になる気がします。 一方、政府や役所がここぞとばかりに、実効性の乏しいガイドラインや法案を増やし、天下り先をつくるような方向に進まないかは気になります。そうなれば、現場の負担ばかりが増え、結局、日本のITが世界からさらに遅れを取ることにもなりかねません。 news.yahoo.co.jp/articles/df…

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

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

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

終身雇用、解雇規制の強い日本では、できない１０％の人にも仕事ができるように、環境を整備して、仕事を割り振っています。 米国のIT/AI企業は、少数の出来る人が全力で仕事を回せるように会社の仕組みをつくります。ダメなら会社ごとなくなる。会社が大きくなっても、できる１０％が全力を発揮できる仕組みを維持するように会社をかえていきます。 これを２０年続けた結果が現在です。