ZERONOVA LAB（個人運営の AI ネイティブ実験スタジオ）で、100 本目の無料 Web ツールとして「Mermaid 記法を図に変換するツール」を公開しました。Mermaid というのは、テキストでフローチャートやシーケンス図を書くと図に変換してくれる記法のことです。そして Mermaid には、公式のオンラインエディタ（mermaid.live）がすでに存在します。公式があるのに、なぜ自作したのか。その判断を 4 つの軸で残しておきます。
「公式があるなら作らない」は、無料ツールを増やすときに最初に立てるべき妥当な判断です。私自身、当初は触らない前提で計画を立てていました。それを覆して「作る」に倒した判断の中身を、後から自分でも検証できる形にしておきたい、というのがこの記録の目的です。
ここで扱う 4 つの拘束条件は、順に「公式の空白を実測する」「ラストマイルの空きを見る」「単体でなくポートフォリオの軸に接続する」「作る判断と作り方を分ける」です。ここで言う「拘束条件」は、判断するときに自分が外さないと決めた制約のことで、フレームワークと呼ぶには軽いけれど、直感だけで「公式があるからやめておこう」と片付けないためには十分機能する、というくらいの粒度です。
なぜこの記録を残すか
無料ツールを 1 本ずつ積み上げていると、「これはもう公式や定番のサービスがあるから、わざわざ作る意味はない」と判断して見送るジャンルが何度も出てきます。実際、その判断はたいてい正しいです。公式があるところに同じものを並べても、検索でも使い勝手でも勝てません。
ところが、ときどきその判断が間違っていることがあります。「公式がある」という事実だけを見て見送ると、公式が埋めていない空白を見落とします。公式が英語圏向けにしか作られていない、ある特定の使われ方を想定していない、別のツールと組み合わせる動線が用意されていない。こうした空白は、「公式の有無」という粗い解像度では見えません。
だから「公式があるから作らない」を一度立てたうえで、それを覆す根拠が立つかどうかを 4 つの軸で順に確認する、という手順を踏みます。覆せなければ見送り、覆せたら作る。この記事は、Mermaid というひとつの題材で、その 4 軸が実際にどう回ったかの記録です。
「作らない」を誤ると失うものは、作ったはずのツール 1 本ではありません。空白が見えていなかったという事実そのものが、次の似た判断でも繰り返されます。逆に「作る」を誤ると、公式の劣化版を量産してサイト全体を薄めます。どちらの誤りも一度では致命傷になりませんが、判断軸を持たずに「公式の有無」だけで毎回片付けていると、両方の誤りが静かに積み上がっていきます。だから手順として残しておく価値があります。
判断軸①：公式の「空白」を実測する
最初に外さなかった拘束条件は、「公式がある」で止めず、公式が埋めていない空白を具体的に書き出すことでした。
mermaid.live は公式のエディタで、機能としては十分です。記法を書けば即座に図がプレビューされ、画像にもできます。ここで「だから作らない」で終わらせず、対象ユーザーを「Mermaid を初めて触る日本語話者」に固定して、その人にとっての空白を数えました。
- mermaid.live の UI は英語のみで、各図種の記法を毎回 GitHub の英語ドキュメントで調べる必要がある
- 表示テーマの切り替えが分かりにくく、記法の早見表（チートシート）が画面内に無い
この 2 点は、英語に不自由しない開発者にとっては空白ではありません。けれど「Mermaid を初めて触る日本語話者」に対象を絞ると、はっきりした空白になります。記法を調べるたびに英語ドキュメントへ往復するコストは、初学者にとって無視できない摩擦です。
ここで効いたのは、対象ユーザーを抽象的な「ユーザー」のままにせず、具体的に 1 人に絞ったことでした。「ユーザーにとって便利」では空白は見えません。「Mermaid 記法を覚えていない日本語話者が、AI が吐いた記法を手元で図にしたい」という具体像まで絞ると、日本語 UI と画面内チートシートという差別化軸が初めて輪郭を持ちます。
開発日記の体験メモには、この瞬間のことをこう書いていました。
mermaid.live を「公式があるから作らない」と判断していたら、Phase 21 でも触らなかった可能性。「日本語 UI × チートシート」の差別化軸が見えたのは spec を書く時の競合分析（Google 検索3つ）が効いた瞬間。
公式の URL を開いて 5 分触り、対象ユーザーを 1 人に絞って空白を数える。この実測をしないまま「公式がある」だけで見送っていたら、差別化軸そのものが見えませんでした。
判断軸②：ラストマイルの空きを見る
公式の空白を 2 つ見つけても、それだけでは「作る」に倒しません。次に確認したのは、そのツールが置かれる動線の中で、まだ誰も埋めていない区間（ラストマイル）があるかでした。
Mermaid 記法は、いまや人間が一から手書きするものではなくなりつつあります。ChatGPT や Claude、Gemini に「この処理をフローチャートにして」と頼むと、Mermaid 記法で返してくることが多い。開発者や PdM が日常的にやっている動線です。
この動線を分解すると、「AI に図を頼む」→「Mermaid 記法が返る」→「それを図（画像）にして資料やドキュメントに貼る」となります。前半（AI が記法を出すところ）はすでに各 AI サービスが埋めています。最後の「記法 → 最終成果物の画像」という区間が、対象ユーザーから見て一番手前にあるのに、日本語環境では埋まりきっていませんでした。
ラストマイルが空いているかどうかは、「公式の機能の優劣」とは別の軸です。mermaid.live は記法を画像にできますが、「AI 出力をコピーして貼り、日本語のチートシートで微調整して、テーマを選んで書き出す」という一連の動線を 1 画面で最短にする、という観点では設計されていません。
ここで自分が分けて考えたのは、「公式に機能があるか」と「対象ユーザーの動線の最後が短いか」は別の問いだということです。機能の有無で見ると「公式にもある」で終わりますが、動線の長さで見ると「AI 出力からのコピペ動線が日本語環境で長いまま」という空きが見えます。前者で判断を止めると、後者の空白に永遠に気づきません。
この「ラストマイルの空き」という見方は、公式の存在を脅威ではなく前提として扱えるところに利点があります。公式が記法の標準を定め、AI 各社が記法の生成を担い、その下流に「日本語環境で記法を最終成果物に変える」という区間が残る。上流が固まっているからこそ、下流の一区間だけを引き受ける小さなツールが成立します。公式と正面から機能を競うのではなく、公式が前提を整えてくれた動線の最後だけを短くする、という位置取りです。ここを取り違えて「公式と同じ機能をもっと良く」を目指すと、物量でも信頼でも勝てない正面衝突になります。空いているのは機能の優劣ではなく、特定の対象ユーザーにとっての動線の最後の一区間だ、という解像度で見ることが、この軸の肝でした。
判断軸③：単体でなくポートフォリオの軸に接続する
ここまでで「公式に空白がある」「ラストマイルが空いている」が立ちました。それでもまだ「作る」を最終決定しませんでした。3 つ目に確認したのは、この 1 本が、すでに持っているツール群の軸に接続するかでした。
ZERONOVA LAB の無料ツールには、いくつかの系列があります。そのひとつに「テキストやデータを入れると画像が出てくる」変換型のツール群があります。街路図を作るツール、間取り図、家系図、席次表。いずれも「テキスト／データ → 画像」という同じ構造を持っています。
Mermaid 図解ツールも、構造としてはまったく同じです。記法というテキストを入れると、図という画像が出てくる。つまり、既存の「ビジュアル成果物軸」にそのまま乗ります。
この接続を確認したことには意味があります。1 本だけを見て「公式の空白が埋まる」と判断するのと、「既存の系列の軸に新しいジャンルが 1 本増える」と判断するのとでは、同じ実装でも価値が違います。前者は単発の便利ツール、後者はポートフォリオ全体のテーマの広がりです。公式があるジャンルにあえて踏み込むなら、単体の便利さだけでなく、自分のツール群の軸を一段広げる効果まで取れるかを確認しておきたい、というのが 3 つ目の拘束条件でした。
逆に言えば、もし Mermaid 図解が既存のどの軸にも接続しない孤立したジャンルだったら、「公式に空白がある」「ラストマイルが空いている」が立っていても、優先度はかなり下げていたはずです。孤立した 1 本は、運用と保守のコストだけが積み上がって、サイト全体の軸を広げないからです。
判断軸④：「作る」判断と「どう作る」を分ける
3 つの軸を通って「作る」に倒れたあとに、最後にもうひとつ拘束条件を置きました。「作る」と決めることと、「いつ・どの順番で・どう作る」を決めることは別の判断だ、という分離です。
このとき、横展開の 4 本目として「Mermaid 図解」と「画像の背景透過」という 2 つの候補が並んでいました。どちらも「作る価値がある」までは立っていました。ここで効いたのが、技術投資の重さの比較です。
画像背景透過は、機械学習モデルをブラウザに載せて動かす必要があり、モデルの配信方法やスマートフォンでの動作検証など、独立した重い技術投資が必要でした。一方の Mermaid は、既存のライブラリを遅延読み込みする構成で済み、これまでの変換型ツールの作り方をそのまま流用できます。
「作る価値」が同じくらい立っているなら、技術投資が軽い方を先に倒す。この比較で、4 本目に Mermaid を選び、画像背景透過は別の投資として後ろに回しました。
ここで分けておきたかったのは、「公式があっても作る価値はある」という判断（軸①〜③）と、「では今これを作るか」という判断（軸④）を混ぜないことです。価値が立っているからといって、いつでも今すぐ作るべきとは限りません。価値（作る・作らない）と着手（いつ・どう作る）を別レイヤーに置くと、「価値があるのに重いから今はやらない」「価値があって軽いから今やる」という、二段階の判断ができるようになります。
ZeronovaZeronovaこの対話を経て、4 本目は Mermaid に確定しました。価値の判断（軸①〜③）と着手の判断（軸④）を分けたことで、「公式があるのに作る」という一見矛盾した結論に、自分でも納得できる筋道がつきました。
4 軸を逆順にすると何が崩れるか
4 つの拘束条件を①→②→③→④の順で回しましたが、順序を変えるとどこで判断が崩れるかを書いておくと、この手順の意味が見えてきます。
仮に④（技術投資の重さ）から始めると、「軽く作れるかどうか」が最初の関門になります。すると、公式の空白も対象ユーザーの動線も確認しないまま、「軽く作れるから作る」が通ってしまいます。軽く作れることは、作る理由にはなりません。公式の劣化版を軽く量産するだけになり、サイト全体を薄めます。
逆に①（公式の空白の実測）から始めると、「作る理由が立つか」を最初に固定できます。理由が立たなければ、どれだけ軽く作れても見送る。④は「作ると決めたものの中で、いつ着手するか」を決める制約として最後に置くからこそ、機能します。
②（ラストマイルの空き）を後回しにすると、公式の機能比較に引きずられて「公式にもある」で見送るリスクが上がります。機能の有無ではなく対象ユーザーの動線の長さで見る、という観点を①の直後に置くことで、「公式にあるから不要」という早すぎる結論を一度止められます。
順序そのものが拘束条件の一部だ、というのがこの手順の構造です。
個人開発に閉じない構造
この 4 軸は、個人で無料ツールを積み上げている状況に特化したものに見えるかもしれませんが、構造としては個人開発に閉じません。
「すでに定番・公式が存在する領域に、自分（自社）が踏み込むべきか」は、プロダクトを企画するあらゆる場面で現れる問いです。定番ツールがある SaaS のカテゴリ、大手が押さえている市場、公式アプリがあるプラットフォーム。そこに踏み込むかどうかを、「もうあるからやめておく」でも「とりあえず作ってみる」でもなく、判断軸で分けたい。
そのとき、規模が違っても構造は同じです。
- 既存・公式が埋めていない空白を、対象ユーザーを 1 人に絞って実測する
- 機能の優劣ではなく、対象ユーザーの動線のどこが空いているかを見る
- 単体の価値でなく、自分（自社）の既存資産の軸に接続するかを確認する
- 「作る価値があるか」と「今それを作るか」を別レイヤーで判断する
個人ラボの規模では、この 4 つを 1 人で順に回せるところに利点があります。組織になると、空白の実測はリサーチ、動線の評価は UX、軸接続はプロダクト戦略、着手判断はエンジニアリングと、担当が分かれてくるかもしれません。役割が分かれても、判断の構造が変わるわけではなく、ただ「どの軸が誰の責任か」が明示される必要があるだけです。
100 本目を公開した時点での記録としては、この 4 軸が「公式があるジャンルに踏み込む判断」に対して今のところ機能している、というだけのことです。次に「公式があるからやめておこう」と思ったときに、本当にやめるべきか、それとも空白が見えていないだけかを、同じ 4 軸でもう一度確かめてみるつもりです。
Zeronova（呑名 健造）
PdM × AI-Native Builder × Senior UX × Civic Tech
Web/IT業界19年以上・20以上のWebサービスを担当した PdM。コロプラ子会社（株式会社ビジプル）元代表として事業経営を経験。現在はシニア向け BtoC プラットフォームの PdM、かんたん連絡網合同会社（自治会DX）・Koship合同会社の共同代表として ZERONOVA LAB を並行運営。