「メディアリストの更新が追いつかない」「ちょっとした管理ツールが欲しいだけなのに、見積もりを取ると数週間待ち」。広報やマーケティングの現場は、増え続けるExcel管理表の手入れに追われがちです。
この常識が、変わり始めています。「メディアの掲載実績を管理する管理表を作って。媒体名、URL、掲載日、反響を記録できるように」。そう日本語で頼むと、数十秒後には、登録できて日付順に並べ替えられる自分専用のアプリがブラウザに現れます。プログラムは1行も書きません。
サービスの名はMulmoClaude（マルモクロード）。中島聡氏の新作で、いま日本のAI界隈で急速に話題になっています。
ただ、このソフトが何をするものなのかを一言で言うのは、実は簡単ではありません。作者自身、メルマガでの呼び名を2か月近く決めかねて、7月7日号でこう率直に書いています。
一般の人に「MulmoClaudeとは何か」をひとことで説明するのは簡単ではありません （中島聡『週刊 Life is beautiful』2026年7月7日号）
説明が難しいのには、理由があります。このソフトの面白さの核心が、画面には映らない裏側の仕組みにあるからです。今回、メルマガを数か月分遡り、公開されているソースコードを読み解き、手元のMacでアプリをいくつも作らせて、その仕組みを確かめてみました。本記事では、それを広報・マーケの現場で使える形までほどきます。
先に、実務的な注意をひとつ。現バージョンはWindowsだと環境構築でつまずく報告が多く、とくにARM64版（一部の軽量ノートパソコン）は現状そもそも動きません。これから実際に試すなら、Macでやるのが確実です（この点は後半のFAQでも触れます）。
MulmoClaudeとは
MulmoClaude（マルモクロード）とは、中島聡氏が公開したオープンソースの無料ソフトです。例えば「メディア掲載実績の管理表を作って」と日本語で頼むだけで、AIが自分専用の業務アプリをその場で作ります。出来上がりのイメージで言えば、kintoneなどに近いでしょうか。
AIにプログラムは書かせず、設計図だけを書かせ、動作はあらかじめ用意されたエンジンが担う点が特徴です。利用には米Anthropic社のClaude Code（有料）が必要です。
仕組みは「機械は一台、AIは三役」です。①固定ルール（プログラム）で常時動く機械のエンジン、②AIが最初に一度だけ書くデータの設計図、③AIが入力や依頼のたびに行う接客。機械で毎回同じ、AIで一度きり、AIで毎回違う。この記事は、この3つを順にほどいていきます。
命名に迷い続けた中島氏は、2026年7月14日号のメルマガでこう命名しています。
先週、MulmoClaudeを何と呼べば良いのか悩んでいると書きましたが、ようやく答えを見つけました。「AIアシスタント育成ツール」です。 （同・2026年7月14日号）
その翌日には、この定義を氏自身が8分の解説動画にしています。仕組みから安全装置、実験の結果まで本人の言葉で語られているので、先にこちらを見てから読み進めるのもおすすめです。
さらに氏は現在、このソフトのビジョンを英語の学術論文にまとめ、arXiv（アーカイブ。研究者が論文を公開する米国のサーバー）への投稿準備を進めています（メルマガ7月21日号）。ビジョンを語る映像とその台本もGitHubで公開済みです。理論の体系化は、本人の手で進みつつあります。本記事では、その手前の理解で立ち止まっている人のために、仕組みを分かりやすく説明します。
なお、同じ中島氏のMulmoCast（動画生成）やMulmoChat（音声対話）とは別の製品です。コードはGitHub（receptron/mulmoclaude）で公開されています。
見落とされがちですが、使い手にとって決定的な違いがもう1つあります。操作の場所です。土台のClaude Codeは、ターミナル（エンジニアが使う黒い文字だけの画面）の道具で、これが「開発者のツール」にとどまってきた壁でした。MulmoClaudeは起動するとブラウザで画面が開き、表もカレンダーも承認ボタンも、すべてブラウザに描かれ、そこで完結します。公式の紹介記事も「ターミナルの中に閉じ込められている。その制約を外す」と、この解放を真っ先に挙げています。管理表が生える場所が、エンジニアの領土から、誰もが毎日開く場所へ移った。非エンジニアに門が開いた直接の理由は、実はこれです（現時点では導入時に一度だけ、ターミナルで npx mulmoclaude@latest というコマンドを1行打つ必要はあります）。
一言添えると、MulmoClaudeにはチャット、wiki、定時実行など複数の顔があります。ここでは、中島氏自身が「なくてはならないソフトウェア」になりつつあるきっかけと語る核心機能、管理表（コレクション）を軸に読み解きます。
全体像：機械は一台、AIは三役
「AIがアプリを作るツールなら、他にもあるのでは」と思うかもしれません。MulmoClaudeの独自性は、AIにプログラムを書かせないところにあります。
料理にたとえます。いま流行りのバイブコーディング（AIに会話でプログラムを書かせる開発）は、腕のいいシェフを厨房に放り込み、毎回ゼロから料理させる方法です。速いけれど、毎回少しずつ味がぶれます。MulmoClaudeは違います。シェフ（AI）にはレシピカードだけを書かせ、調理はホットクック（機械）がやる。同じレシピなら、100回作って100回同じ味です。
分解すると、アプリの仕事は3つに分かれています。「誰が・どの頻度で動くか」の1本の軸で割ると、重なりも漏れもありません。
| 区分 | 担当 | いつ動くか | 仕事 |
|---|---|---|---|
| ① エンジン | 機械（固定ルール） | 常時 | 画面表示・保存・検査 |
| ② 設計図 | AI（設計士） | 最初の一度だけ | 管理表の項目と型を決める |
| ③ 接客 | AI（受付係・相談係） | 入力のたび・依頼のたび | 発話を枠に収め、枠に書けない判断を埋める |
機械で毎回同じ。AIで一度きり。AIで毎回違う。イメージは、冒頭の図のとおり「中身の見える一台の機械と、その外で働く三役のAI」です。機械の筐体の中（検問ゲート・保管棚・表示窓）は全部プログラムで、いつも同じに動きます。AIは機械の外から、設計士として設計図を一度だけ差し込み、受付係としてあなたの発話を枠に書き写し、相談係として溜まった記録を読んで毎回違う答えを返します。
この3つの分担は、当社の深読みではありません。前掲の解説動画で、氏自身がこう言い切っています。
一言で言えば、設計図がアプリ、AIが作者、そしてホストが実行係です。 （中島聡・解説動画「自分で育てるAIアシスタント」より。動画では①のエンジンを「ホスト」と呼んでいます）
どの仕事が機械で、どれがAIか。見分ける質問は1つです。
その仕事、手順書に最後まで書き切れますか？
書き切れる仕事（日付ならカレンダーに置く、1件ずつ保存する）は機械の担当です。書き切れない仕事はAIの担当です。毎回同じであってほしい仕事からAIを締め出し、毎回違っていい仕事だけをAIに残す。この仕分けが、MulmoClaudeが安定して動く秘密です。氏も動画で「きっちり決められることはホストが確実に実行し、言葉の解釈はAIが引き受ける」と、同じ線引きを語っています。
では、機械の中身から順に開けていきます。
① エンジン：機械が「常時」同じに動く
エンジンは、ルールどおりに動くプログラム、図でいえば機械の筐体の中身です。仕事は3つ。画面を表示する、データを保存する、そして入ってくるものを検査する。どれも常時、誰が使っても同じに動きます（これがAIとの大きな違いです）。
まず画面表示です。設計図に「日付」の項目を書くだけで、カレンダー画面が勝手に現れます。これは「日付の項目があればカレンダー表示を出す。選択肢の項目があればかんばん（付箋を並べ替えるボード）を出す」というルールが、エンジンの中に下記のように最初から書いてあるからです。（エンジンの画面判定ファイル collectionViewMode.ts の判定部。前後の定型行は省略）。
const modes: CollectionViewMode[] = ["table"]; const fields = Object.values(schema.fields); if (fields.some((field) => field.type === "date" || field.type === "datetime")) modes.push("calendar"); if (fields.some((field) => field.type === "enum")) modes.push("kanban");
訳すと4行です。「表はいつでも出す」「設計図の欄を全部見る」「日付か日時の欄が1つでもあればカレンダーを足す」「選択肢の欄があればかんばんを足す」。ここに判断も学習もありません。あるのは固定のルールだけです。だから画面や操作は、誰が使っても同じです。ワープロソフトが誰のパソコンでも同じ見た目なのと同じ理屈で、人によって違うのは中身（データと設計図）だけです。
保存も同じです。管理表の1件は1つのファイルとして、決まった手順で書き込まれます（ファイルの形式は後述します）。ここにも判断はありません。
3つ目の検査が、このエンジンの最も重要な仕事です。エンジンは、AIの書いたものを無条件には信用しません。関所が2つあります。AIが書いた設計図は受理審査（discovery.ts）にかけられ、文法違反なら登録されません。AIが保存しようとしたデータは検査係（validate.ts）が確かめ、選択肢にない値や空欄は、理由の文章付きで差し戻されます。規格外のものは、機械が入口で止める設計です。
AIに仕事をさせるソフトなのに、AIを検査する。矛盾ではなく、これこそが作者の設計思想です。メルマガの最新号で、氏自身がこう明言しています。
AIは、ユーザーからの曖昧な指示の解釈や、領収書の写真から必要な情報の抽出は非常に優れていますが、AIが生成したデータがデータベース側が要求する仕様（スキーマ）にあっているかどうかの判別、決まりきった計算などはコードで実行するべきなのです。 （同・2026年7月21日号）
MulmoClaudeに限った流儀でもありません。同じ号で氏が紹介している米国の財務AI導入企業は、成功するAIエージェントの中身を「85%が普通のコード、15%だけがAIモデルの呼び出し」だと明かしています。AIの自由を機械で絞る設計は、実務で成果を出しているAI活用に共通する型になりつつあります。
エンジンの仕事を実物のソースコードと対応させると、こうなります。
| 仕事 | 担当 | 実体（ソースコード） |
|---|---|---|
| 画面を決める | 機械 | 上の4行（日付→カレンダー等の固定ルール） |
| 保存する | 機械 | 1件＝1ファイルでJSONを書き込む保存処理 |
| 入力を検査する | 機械 | データ検査（validate.ts）。選択肢にない値や空欄を、理由の文章付きで差し戻す |
| 設計図を受理する | 機械 | 受理審査（discovery.ts）。文法違反の設計図は登録しない |
4つとも「手順書に最後まで書き切れる」仕事です。だからプログラムとして一度だけ書かれ、以後まったく同じに動きます。では、この機械に差し込まれる設計図とは何なのか。
② 設計図：AIが「最初の一度だけ」考える
「掲載実績の管理表を作って。媒体名、URL、掲載日、反響を記録できるように」。この依頼を受けた瞬間だけ、AIは設計士になります。決めるのは、管理表にどんな項目（欄）を持たせ、それぞれをどんな型にするかです。媒体名は文字、掲載日は日付、反響は自由メモ。この設計を、AIは設計図ファイル（schema.json）に一度だけ書き込みます。
以後、AIはこの設計図を書き直しません（あなたが「欄を足して」と頼まない限り）。書かれた設計図は①のエンジンが常時読み、「掲載日という日付の欄がある。ならカレンダー画面を出そう」と、固定ルールで画面と操作に変換します。賢さは最初の一度だけ設計図に注ぎ込まれ、日々の動作は機械が守る。この分業が、全て丸投げのバイブコーディングとの決定的な違いです。AIが毎回プログラムを書けば毎回味が変わりますが、設計図は一度書かれたら変わらないので、明日も来月も同じに動きます。
当社実測：AIは自分の「取扱説明書」まで書いていた
この段階でAIが一度だけ書くものは、設計図にとどまりませんでした。当社もMacにインストールし、お手本が存在しないアプリを複数作らせてみました（ホットクックのレシピ管理表、食事の記録など）。できあがったアプリの奥のフォルダを開くと、設計図（schema.json）と並んで、SKILL.mdというファイルが生成されていました。AIが書いた、そのアプリの取扱説明書です。
中身は、AIが未来の自分に宛てた業務マニュアルでした。データの追加や更新の手順が道具の名前つきで並び、こんな注意書きまであります。
デフォルト upsert は全体置換なので注意。 （当社環境で生成されたSKILL.mdより）
意訳すると「何も考えずに上書きすると、レコードの中身を消してしまうぞ。気をつけろ」。AIが自分の失敗を予測し、自分に警告を残しているわけです。
この説明書は、仕組みが透けて見える窓でもあります。文面に並ぶ manageCollection（データの出し入れ）などの道具の名前は、すべてエンジン側が用意したものでした。AIは自由作文をしているのではなく、エンジンが用意した用紙に記入している。取扱説明書を書くこと自体も、実は仕組み側が手順として教えている行動です（第三者の利用報告でも、設計図と説明書が自動生成されると記されています）。
一方で、明らかにAI自身の判断と呼べる部分もありました。こちらでやったことは、レシピ管理表と食事記録を、別々のアプリとして頼んだだけです。ところがAIは2つを「姉妹コレクション」として相互にリンクさせ、食事記録の側にはレシピ管理表への参照（ref）を正式な作法で定義し、「記録から好き嫌いの傾向を読んでレシピを提案する」という連携までお膳立てしていました。
中島氏はメルマガ6月2日号で、将来はMulmoClaude自身が自分の機能を拡張できるようになる、と予言していました。その芽が、7月には当社のパソコンの中で顔を出していたことになります。もっとも、AIの提案が常に正しいとは限らないので、生やしたアプリの点検はいまのところ人間の仕事のようです。
設計図と取扱説明書が書き上がったら、AIの設計士としての仕事は終わりです。ここから先、AIは毎日の現場に立ちます。
③ 接客：AIが「依頼のたび」枠に書けない判断を埋める
先に「埋める」という言葉を正確にしておきます。AIが埋めるものは、タイミングの違う3つあります。
| いつ | AIが埋めるもの | 例 |
|---|---|---|
| 最初の一度だけ | 設計図の項目（どんな欄を持たせるか） | 「媒体名・記者名・メモの3欄にしよう」と決めて設計図に書く |
| 入力のたび | 欄の中身（あなたの発話から値を拾い、枠に収める） | 「東都経済新聞の佐藤記者を追加して」→媒体名欄と記者名欄に振り分けて保存 |
| 依頼のたび | どの欄にも書いていない「判断」 | 溜まった事実を材料に、媒体別のメール文面を作る |
1つ目が②（設計図＝図の設計士）の仕事、2つ目と3つ目がこの③（接客＝図の受付係と相談係）の仕事です。この章で見るのは3つ目、いちばん人間くさい部分です。
メディアリストの管理表に、こんな2行があるとします。
| 欄 | 東都経済新聞・佐藤記者 | 情報番組「いまドキ」・田中ディレクター |
|---|---|---|
| 媒体タイプ | 新聞 | テレビ |
| 得意ジャンル | 中小企業のDX | 暮らしのトレンド |
| 過去のやり取りメモ | 4月の調査リリースに「数字の裏付けが薄い」と返信。データ好き。長文を嫌う | 映像になる画がないと動かない。現場の絵を好む |
ここでAIに頼みます。「この新しいリリース、媒体別の送付メールにして」。
管理表のどこにも「佐藤記者へのメールはこう書け」という欄はありません。作ろうとすれば、場合分けが無限に増えます。データ好きなら数字を先頭に、ただし長文嫌いなら3行で、前回指摘を受けていたら冒頭でひと言触れて……。手順書には書き切れません。
AIは、その場でこう埋めます。佐藤記者へは、件名に調査の数字を入れ、冒頭で「前回ご指摘いただいた裏付けの件、今回は生データを添付しました」と触れ、要点を3行で切る。田中ディレクターへは、同じリリースなのに「撮影できる現場があります」と、絵になる場面を先頭に置く。管理表が持っているのは事実だけで、その事実を今回どう使うかという判断を、AIが毎回その場で考えています。
月末には、管理表をまたいだ質問もできます。「どの媒体に送ると掲載につながりやすい？」。配信ログとクリッピングの管理表には事実しかありませんが、AIは2つを突き合わせ、「経済系3紙は調査リリースなら3回中2回掲載。イベント案内は0回」とその場で読み解いて答えます。
AIがやっていることを一般化すると、一行になります。
蓄積した事実から傾向を抽象化し、新しい場面に当てはめて推測する。
これは、有能な広報担当や秘書が毎日やっている仕事と同じ型です。過去のやり取りを覚えていて（蓄積）、「あの記者はデータ好きだ」と掴み（抽象化）、次のメールに活かす（当てはめ）。AIが何か特別なことをしているわけではなく、人間の仕事の型を、管理表を読みながらなぞっています。
ただし人間との違いも一行で言えます。AIの推測は管理表にある蓄積の範囲に縛られ、判断の責任は取りません。だから、責任を取れるAIが出るまでは、送信ボタンは人間が押したほうが良いかもしれません。
本質は「アプリ」ではなく「データの残し方」にある
この設計の狙いは、公開リポジトリの開発文書に一行で書かれています。
The workspace is the database. Files are the source of truth. （ワークスペースがデータベースであり、ファイルこそが真実の源である）
MulmoClaudeでは、アプリ自体は保存されません。手元に残るのはデータと設計図だけで、画面は毎回そこから立ち上がります。つまりこのソフトの正体は、「AIが読める形でデータを残す」ための仕組みです。
このことは、誕生の経緯からも裏づけられます。着想元は、著名AI研究者カーパシー氏が提唱した「Wiki＋LLM」でした（当社の以前の紹介記事）。ただし中島氏は、そこで止まりませんでした。
Wikiだけでは不満で、コレクションというデータベース機能を付け加えたあたりから、私自身にとって「なくてはならないソフトウェア」になりつつあります （同・2026年7月7日号）
知識には2種類あります。小説のように文章で語る「文章型」と、データベースのように項目で持つ「表型」です。学校でいえば、作文とマークシート、仕事でいえばWordとExcelの違いです。経緯や物語は前者に、メディアリストや経費は後者に向きます。
LLM wikiは、文章型の残し方としては発明でした。ただ、表型の知識には弱点があります。メディアリストのような表をmdファイル（文章）で残しても、AIは読めます。読めますが、読むたびにAIが文章を解釈し直すので、並べ替え・集計・絞り込みといった「きっちりした処理」の答えがぶれかねません。同じ知識を構造化して持たせれば、こうした処理はプログラムが受け持ち、毎回まったく同じ、正確な結果になります。MulmoClaudeは、この弱点を埋めた後継です。表型の知識にスキーマ（設計図の書式＝DSL）を与えて、構造化して残す。だからAIも機械も、効率よく確実に読み書きできます。
当社はこの形態を、「構造化アプリ」と呼びたいと思います。データを構造化した管理表として残し、画面と操作はそこから自動で生成され、管理表に書き切れない判断はLLMが埋める。アプリの新しい形です。なお「構造化」という言葉自体は当社の言い方で、中島氏自身の語彙ではDSL、スキーマ、決まった枠組み。散らばったそれらを束ねる日本語として、本記事ではこう呼びます。
自社をツールに合わせる時代の終わり
この形が広がると、もう少し大きな話にもつながります。これまで「管理表アプリ」は、月額課金の業務サービス（SaaS）を契約して使うのが当たり前でした。顧客管理も、案件管理も、社内の申請フォームもそうです。ところが、数十秒で自分専用の管理表が手元に生まれるなら、わざわざ契約して他社の作った汎用フォームに自社を合わせる必要が、どこまであるのか。中島氏自身、メルマガ7月21日号で大手SaaS企業の先行きに触れ、積み上げてきた画面（UI）の価値が薄れ、従業員一人あたり課金のモデルが揺らぐ可能性を指摘しています。すべてが置き換わるとは思いません。ただ、ありものの汎用ツールに自社を合わせる時代から、自社の言葉で自分専用を生やす時代へ、重心が動き始めている。当社はそう見ています。
氏自身による最も近い整理は、メルマガ6月2日号の質問コーナーにあります。設計の「肝」（デザイン・プリンシプル）として、「LLMの挙動はDSLを使ってコントロールする」「ファイルシステムに書かれたものが常に真実」「より多くの機能を汎用的なコレクションを使って実装する」「より多くの仕事をLLMにさせる」という4か条を挙げているのです。本記事の言う構造化アプリの部品が、すべてここに並んでいます。ただし、これは「何をするか」の列挙であり、「なぜそうするのか」の筋道（自由すぎるAIには枠が要る。枠はファイルの上に作れば軽い）と、全体を貫く名前は書かれていません。補足すると、筋道の方は7月15日の解説動画で氏自身が語り始めています。AIは失敗する、だから3つの安全装置を用意した、ということです。残っているのは、それらを束ねる一つの名前だけ。それが「構造化アプリ」です。
見方を変えると、これは労働の移動でもあります。従来のアプリでは、フォームに合わせて入力する、つまり情報を構造化する労働は人間の仕事でした。MulmoClaudeでは、人間は話すだけです。発話を構造化データに変換して枠に収める仕事を、AIが引き受けます。構造化の労働が、人間からAIへ移りました。
中島氏は前身のMulmoChatを「自然言語が理解できるAIが存在する時代のマン・マシン・インターフェイス」を問うプロトタイプだったと振り返っています（メルマガ7月7日号）。人間は自然に話し、AIが構造化し、構造化された蓄積が機械を動かす。氏が探してきた答えの現在形が、このソフトです。
JSONという「ただのメモ」で足りる理由
思い出してほしいのは、ほとんどのデスクワークが、突き詰めれば管理表（構造化データ）と、その周りの判断でできていることです。メディアリストも、掲載実績も、経費も、顧客管理も、中身は管理表です。MulmoClaudeは、その管理表を軽いJSONにして手元に置き、管理表に書き切れない判断はAIがその場で埋める。だから業務の広い範囲に効きます。
JSON（ジェイソン）と聞くと文系人間からするとなにやら難しそうですが、正体は「項目名と中身をセットで書く、ただのテキストのメモ」です。たとえばレシピ管理表の1件は、こんな1枚のメモとして保存されています。
{ "料理名": "カレー", "調理時間": 20, "評価": 5 }
人間がメモ帳アプリで開いて読めて、機械も確実に読める。中島氏はこの設計を「パソコンのファイルシステムをデータベースとして使う」ビジョンだと説明しています（メルマガ5月12日号）。データベースを無くしたのではなく、メモの束がそのままデータベースになる。専用のデータベースサーバーを立てなくても管理表が回るのは、この「人にも機械にも読める軽いメモ」のおかげです。逆に言えば、数百万件のデータや大人数での同時編集は守備範囲外で、個人から小さなチームまでの道具です。
しかもこの保存フォルダは、ブラウザの画面からそのまま覗けます。多くの業務サービスではデータはサービスの奥に預けっぱなしで中身が見えませんが、MulmoClaudeでは管理表の1件1件が普通のファイルとして目の前に並ぶ。「データが手元に残る」が、比喩ではなく目で確かめられる事実になっています。
設計図は檻ではなく骨格：引き継ぎ資料という正体
管理表の「隙間」にも強さがあります。請求書づくりに「時給」が必要なのに、データベースのどこにも時給の項目がない。それでも顧客メモ欄に「時給：5000円」と書いてあれば、AIが文脈から読み取って請求書に反映します。
従来型のデータベースよりもはるかに柔軟で優秀だとすら言えます （同・2026年6月2日号）
設計図は、項目を固めた「檻」ではなく、隙間をAIの言語理解が埋める「骨格」として働きます（この比喩は当社の言い換えです）。きっちり定義しないと動かない、という従来のIT常識が、だいたい書いておけばAIが察する、に変わりつつあります。
そして、使えば使うほどデータが溜まり、AIがあなたの仕事の文脈に詳しくなる。ここで役に立つ判定テストを1つ紹介します。
その管理表と手順書を、人間の新人に渡したら、仕事が回りますか？
回るなら、AIにも回せます。MulmoClaudeのワークスペースは、よくできた引き継ぎ資料の形をしています。中島氏の「アシスタントを育てる」という言葉の正体は、新人教育とほぼ同じ営み、つまり良い引き継ぎ資料を作ることです。氏自身も、価値の在りかをこう言い切っています。
MulmoClaudeが提供する価値はあくまで「足場」であり、足場には足場の価値があるものの、その上に建てられる建物こそが最終的に価値を生み出すものになると考えて良いと思います （同・2026年7月14日号）
足場とはハーネス、建物とはあなたのデータとアプリの蓄積のことです。
ちなみに、この設計は最初からあったわけではありません。中島氏は5月、会計や顧客管理を「プラグイン」（エンジニアがプログラムを書いて機能を足す方式）として実装し、機能を足すほどAIに渡す説明文が長くなって性能が落ちる、という壁に当たりました。6月、氏はいったん作ったものを捨てて、汎用の管理表（コレクション）を軸にした現在の方式へ作り直しています。公式の紹介記事にも、かつて作り付けの機能だったカレンダーやToDoが「あえて削除され、すべてCollectionとして表現し直された」とあります（プラグインという拡張の仕組みそのものは、現在も内部に残っています）。
AIのおかげで開発コストが大きく下がった結果、この「サンクコスト」の呪縛から逃れることができるようになりました （同・2026年6月2日号）
捨てたのは3人日ぶんの作業でした。AIで作るのが速くなると、捨てる決断も軽くなる。試作品と本番の区別が消えていく、という経営側の変化も、この記録から読み取れます。
原文を「意訳」で読む：仕組みは開発文書に全部書いてある
ここまでの解説は勝手な解釈ではなく、公開されている開発文書とソースコードの中に、自然文で書いてあります。代表的な原文を、思い切った意訳つきで紹介します。
その1、プロジェクトの憲法。開発者向け文書（リポジトリ直下の CLAUDE.md）の冒頭に、「Core philosophy（核となる思想）」としてこうあります。
The workspace is the database. Files are the source of truth. Claude is the intelligent interface.
意訳すると「大事なものは、ぜんぶノートの束。本当のことはノートに書いてある。AIは、ノートを読んで話し相手になる係」。
その2、管理表（コレクション）の定義。設計図の型定義ファイル（packages/core/src/collection/core/schema.ts）の冒頭です。
A "collection" is a skill (under
.claude/skills/<slug>/) that also ships a siblingschema.json.
意訳すると「管理表とは、AIに渡すおしごとカード（SKILL.md）に、ノートのわく（schema.json）を付けたもの。置き場所は決まった棚」。注目してほしいのは、この定義がプログラム言語ではなく普通の文章で書かれ、それをAIが読んで動くことです。読者がAIだから、文章がそのまま仕組みの部品になります。
その3、カレンダーが生える4行。画面の種類を決めるコードは、意訳するとこれだけです。「日付の欄があったら、カレンダーも出そう。選ぶ欄があったら、付箋ボードも出そう」。賢さはここには要りません。賢さは設計図を書くAIに寄せ、実行は素朴なルールに落としてあります。
その4、見張り係とAI宛ての注意書き。データ検査のファイルには、想定される事故まで書いてあります。
a single malformed file looks like "records vanished."
意訳すると「書き間違えたページは黙って飛ばされる。すると『記録が消えた！』ように見える。だから見張り係が先に見つけて、直し方まで教える。いちばん多い事故は、文章の中に出てくる二重引用符（"）の書き方だよ、と」。面白いのは、このエラー文の宛先です。コードには「LLMが行動に移せるように書かれた問題文」と明記されています。エラーメッセージの想定読者が、人間ではなくAIなのです。
その5、アプリの正体。AIに配られる手引き（packages/core/assets/helps/collection-skills.md）の結論部です。
No database, no migration tool, no ORM — a schema.json plus a folder of
<id>.jsonrecords is the app. you are the runtime for any behaviour the schema can't express declaratively.
意訳すると「データベースはいらない。わく（設計図）と記録の束、それがアプリ」「わくに書けないお願いは、AIくん、きみの仕事だよ」。ただのテキストファイルだからAIがそのまま読み書きでき、導入の手間もなく、1件壊れても他は無事です。これらの言い切りは、すべて原文の翻訳です。簡単に言えたのは、原文がすでに言っていたから。
Claude Code・OpenClaw・Hermesと何が違うのか
冒頭で言い切ったとおり、Claude Codeは何でもできる代わりに、出力に決まった枠がありません。MulmoClaudeとは、そのClaude Codeに枠を与えたものです。この視点で似た道具を並べると、違いは1つの軸で整理できます。「AIに何を書かせ、何が資産として残り、誰が動作を保証するか」です。
| Claude Code | OpenClaw / Hermes Agent | MulmoClaude | |
|---|---|---|---|
| 正体 | コーディングエージェント | 常駐型のアシスタント基盤 | AIアシスタント育成ツール |
| 操作する場所 | ターミナル（黒い画面） | チャットアプリ／ターミナル | ブラウザ（表・カレンダー・ボタン） |
| AIに書かせるもの | プログラムそのもの（毎回） | 行動（ツール操作・スキル） | 設計図と手順書だけ |
| 資産として残るもの | コード | スキルと記憶 | データと設計図（ワークスペース） |
| 動作を保証するのは | 生成されたコード次第 | 実行環境の枠 | エンジン |
Hermesは「経験からスキルを自動生成する自己改善型」を看板に掲げますが、本人（AI）に尋ねると、スキル作成のきっかけは基本的に人間の依頼で、乱造を防ぐため確認を挟む設計だと答えました。自己改善を謳う側も、実装では品質のためにAIの自由を絞っています。MulmoClaudeは最初から出力を設計図に絞る。アプローチは逆でも、思想は同じです。
AIを賢く使う鍵は、AIの賢さではなく、枠の設計にある。
なお、日本語圏の反応は熱く、非エンジニアの利用者が、触り始めて10日ほどでリンク集・英単語帳・読書ノート・資産管理・ポッドキャスト記録と5種類の自分専用アプリを作ったと報告する一方、海外の技術コミュニティではまだほとんど話題になっていません。呼び名すら定まらない説明の難しさが、普及の壁になっている段階です。だからこそ、仕組みを翻訳して伝える価値があると当社は考えています。
広報・マーケ業務への活かし方
「エンジニア向けの面白いツールだとは分かった。でも、文系の自分には関係ないのでは」。いいえ、広報・マーケティングの現場こそ、この道具の恩恵を最も受けられる領域だと当社は見ています。使い道は2つあります。
1つめは、即席の「管理表」として使い倒すこと。メディアリスト、掲載実績の管理、配信先リスト、クリッピングの整理。広報の現場は管理表仕事の宝庫なのに、専用システムを作るほどの予算はなく、属人的なExcelが乱立しがちです。MulmoClaudeなら、日本語で頼んで生やし、合わなければ捨てて作り直せます。中島氏自身、請求書発行や出張のスケジューリング、メルマガの執筆準備までコレクション化し、その数は20を超えると書いています（メルマガ7月7日号）。仕分けの物差しは、この記事で見てきた2つの質問です。手順書に最後まで書き切れる仕事は機械に。管理表と手順書を新人に渡して回る仕事は、AIに任せられます。
ここで、③接客の章で見た「媒体別メール」を思い出してください。記者が100人いれば、100通りに書き分ける。相手の得意ジャンルも、前回のやり取りも踏まえて、一人ひとりに最適化する。これがAI時代の広報の最適化です。かつて、100人に100通りなど不可能でした。人手も時間も足りなかったからです。ところが、その作文コストが、ほぼ0に近づきました。残るのは、管理表に事実を溜め、AIに任せると決める人間の側のコストだけです。 文系に縁遠い話ではないことを示す実例が、メルマガ7月21日号の質問コーナーに載っています。経営企画の非エンジニアの読者が、Claude Codeを触り始めて1か月で家族向けアプリや子どもの学習アプリを作り、「AIが安定して良い仕事をするためのSkill、テンプレート、チェックリスト、データ形式、レビュー手順のような『仕組み』を作る力」こそが重要だと実感した、と報告しているのです。管理表と手順書を整える力は、プログラミングの力ではありません。業務を整理して、引き継げる形にする力です。それなら、広報・マーケの現場が毎日やっていることと同じです。
2つめは、AI検索対策（LLMO）のヒントにすることです。メモ欄の「時給：5000円」をAIが察したように、AIはキーワードの一致ではなく意味で情報を読みます。これは当社がClaudeの検索の解剖で実測した、AIが検索結果を意味で選ぶという性質と同じものです。読者がChatGPTやClaudeで情報収集する時代、自社の発信がAIにどう拾われるかは、この同じ原理で決まります。AIという新しい読者に自社を正しく知ってもらいたいなら、キーワードを詰め込むのではなく、意味の通る自己完結した情報を、AIが読める形で残しておく。MulmoClaudeが教えてくれるのは、社内のデータも社外への発信も、これからは「AIが読める形で残す」が基本になる、ということです。
広報・PRも「対人」から「対マシン」に変わりつつあります。これがいわゆる「マシンリレーションズ」の世界であり、従来の「テレビ・ヤフトピ」ではなくAIに理解・推奨される時代に突入しています。
明日からできる4つのアクション
- 社内のExcel管理表を1つ選び、AIに頼んで生やしてみる（メディアリスト、掲載実績など）。作って捨てる前提で身軽に試します。
- 要件をきっちり固める前に「だいたい書いてAIに察させる」を一度試し、どこまで通じるか体感する。
- 自分の業務を「手順書に書き切れるか」「管理表と手順書を新人に渡したら回るか」の2つの質問でふるいにかけ、機械・AI・人間の分担を仕分けする。
- 自社の発信情報を「AIが意味で拾う」前提で見直す（詳しくは技術編の5つのポイントへ）。
Claude Codeは「相棒」、MulmoClaudeは「師匠」
最後に、実際に触ってみた当社の、正直な手触りを書いておきます。
文系にとってのバイブコーディングの楽しさは、これまでエンジニアの領域だった「プログラムを作る」に、土足で踏み込める快感にあるといっても過言ではありません。
文明5000年。人類はついに「話すだけで創れる」時代に到達した。
— 熊谷正寿【GMO】 (@m_kumagai) June 25, 2026
ClaudeCodeで開発をスタートして2か月😊 遂に10万行突破🖥️
・誰にも教わらず、質問もせず
・本もYouTubeも見ず
・ほぼ音声入力だけ
・スクショでClaudeと対話しながら開発
トークンコスト6万円（驚） #AI #革命 #ClaudeCode pic.twitter.com/xgUho6WJu3
土台のClaude Codeは、こちらの無茶な思いつきにも付き合ってくれる相棒（バディ）です。自由で、思うままに動かせます。
MulmoClaudeは、少し手触りが違います。すごいのは間違いありません。ただ、枠がある分だけ、「AIに従わされている」感覚がわずかに残ります。MulmoClaudeは「データはこう構造化して持つべきだ」という道を、先に示してきます。相棒というより、型を教える師匠に近い。
この手触りの違いは、小さくないと感じました。0から自由に踏み込む快感を知った文系マーケターにとっては、唯一といっていい心理的な引っかかりが、ここかもしれません。
しかし、思い出してほしいのです。その「こうするべき」という型こそが、100回作って100回同じ味を生む、あの枠の正体でした。自由な相棒とのセッションは、確かに楽しい。ですが、毎日の仕事を安心して任せる相手としては、型を崩さない師匠のほうが、結果を裏切りません。楽しさを取るか、確かさを取るか。仕事の道具として選ぶなら、後者が良いのかもしれません。
まとめ
たった1行で言えば、MulmoClaudeとは「AIが読める形でデータを残す」ための仕組み、当ブログでは「構造化アプリ」と呼ばせていただきます。
機械のエンジンが「毎回同じ」を守り、AIは設計図を最初に一度だけ書き、あとは溜まった管理表を読んで、依頼のたびに人間の仕事と同じ型で推測しながら接客する。機械で毎回同じ、AIで一度きり、AIで毎回違う。AIの自由を絞ることで品質を生み、データが溜まるほどアシスタントがあなたに詳しくなる。「育てる」という言葉の正体は、良い引き継ぎ資料を作ることでした。
もし小学生に説明するなら、こうなります。話しかけるだけで「じぶん専用の記録ノート」を作ってくれる道具。ノートのわくを考えるのはAI、ノートを作って守るのは機械、たまったノートを読んで相談にのってくれるのもAI。ノートがふえるほど、AIはきみにくわしい相棒になっていく。
社内のデータ管理も、社外への発信も、読者にAIが加わる時代です。自社の情報がAIにどう読まれ、どう語られているかを知りたい方は、お気軽にご相談ください。
AI時代の広報・PRを支援するサービス
関連記事
- Claudeは何を「読んで」答えている？AIに拾われる文の書き方
- MulmoCast（マルモキャスト）とは？プレスリリース動画をAIで作る方法
- LLM wikiをPR戦略に活用する方法
- AIを使ってメディアリストを爆速で作り上げる方法
- マシンリレーションズとは
参考・注記
- 中島聡『週刊 Life is beautiful』（まぐまぐ）2026年5月12日号・5月26日号・6月2日号・6月23日号・7月7日号・7月14日号・7月21日号。引用は同メルマガの規定（出典明記の引用可）に基づきます。
- 中島聡氏の解説動画：「自分で育てるAIアシスタント #mulmoclaude」（YouTube「中島聡のLife is Beautiful」チャンネル、2026年7月15日公開、8分19秒）。本文中の動画からの引用はこの動画の発言に基づきます。
- 中島氏のビジョン資料：ビジョン映像の台本・MulmoScript・論文要約版がGitHub receptron/presentationsで公開されています。氏は同じビジョンを英語論文としてarXiv（研究者向けの論文公開サーバー）へ投稿準備中です（メルマガ7月21日号）。
- MulmoClaude公式リポジトリ：GitHub receptron/mulmoclaude。「The workspace is the database」等の引用は同リポジトリの開発者向け文書・ソースコードより。主要な英文引用は2026年7月21日にGitHub上の原文と一字一句照合しました。
- 当社実測：MacにMulmoClaudeを導入し（Dockerサンドボックス有効）、お手本のないアプリを複数生成。AIが書いた設計図（schema.json）と取扱説明書（SKILL.md）、およびソースコード（ビュー自動判定・スキーマ定義・コレクション生成の手順書）を分析しました（2026年7月13日〜19日）。
- 本文中の「東都経済新聞」「いまドキ」等はシーン説明のための架空の媒体・人物です。
- 公式の紹介記事：Singularity Society「MulmoClaude — 自分だけのAIアシスタントを『育てる』ツール」（機能の全体像。「アプリはデータであり、スキーマがハーネス、Claudeがランタイムである」「あえて削除され、すべてCollectionとして表現し直された」の引用はこの記事より。2026年7月21日に原文確認済み）
- 非エンジニアの利用報告：Zenn「非エンジニアがMulmoClaudeで自分専用アプリを作ってみた」（10日ほどで5種類のアプリを作成した報告）／Windows環境の報告：note「MulmoClaudeをWindowsで動かそうとしたら詰まった話」
- MulmoClaudeは開発途上のソフトウェアで、仕様は頻繁に変わります。本記事の内容は2026年7月21日時点のものです。
