内部にテキスト記法を一層挟む——それだけの話です。
DLM を AI 化した実例から、中間記法パターン（MNP）の全景を解説します。
DLM は、サービスに関わる人・使わない人も含めて、全ての意思決定の分岐を一枚の地図に描く手法です。CJM（カスタマージャーニーマップ）が「使う人の一本道」を描くのに対して、DLM は使わない人、離脱する人、別のサービスに行く人まで含めた全景を描きます。私は業務で日常的にこの手法を使っています。
私ひとりで使っている分には、手書きでもホワイトボードでも困りません。でも他の人にも書いてもらうとなると、手書きでは回らなくなります。手法の解説書を渡しても、いざ書こうとすると筆が止まってしまう。AI に任せて、楽に書けるようにしたい。ここから話が始まりました。
頭の中にある手法なので、自分なら迷わず書けます。付箋でも、紙でも、Miro でも構いません。
解説書を渡しても、いざ書こうとすると手が止まるのがよくある話です。AI にラフを書かせて、人がそれを直す、くらいが現実的だと考えました。
AI に図を書かせる方法は、今はいくつかあります。私も試してみたのですが、DLM のような独自の要素を含む図にはどれも合いませんでした。
「この概念は角丸四角、この矢印は破線」と AI に毎回教え直すことになります。手法の用語がただの図形に化けてしまいます。受け手にもアカウントが必要です。
手法の説明を載せるには向いていますが、DLM のような分岐のある図は Notion では描けません。テンプレを埋める体験も単調になりがちです。
一発で動くものは出ます。でも再現性がありません。「前の配色に戻して」「ここだけ直して」が効きませんでした。
Mermaid の語彙は「矢印・ノード・分岐」の汎用だけです。「大数通過点」「解放端」「離脱」といったDLM 固有の語彙が表現できません。
独自の記法と、それを
図に変換するパーサーを
自分で作ればいいんじゃないか？
つまり、自分の出したい図に特化した「小さな Mermaid」を AI に作ってもらえばよいのです。記法も、パース処理も、描画も、編集画面も、AI に書かせるプロンプトも、全部まとめて 1 枚の HTML に収まります。
Mermaid や PlantUML に代表される、特定の用途に特化した独自言語のことです。HTML や Python のような汎用言語ではなく、あるドメインの状態を表現するための記号と構文の体系です。MNP では、この DSL を「AI が読み書きする専用言語」として使います。
私が業務で使っている独自の図解手法です。記号 * は出発点、| は並列、>> は「多くの人が通る地点」、~ が終着、.. が離脱を表します。書くと描かれる仕組みです。
GUI と LLM の間にテキスト記法という中間層を置く設計パターン。人はGUIで操作し、AI はテキストで読み書きする。この分離が安定した双方向更新を実現します。Middle Notation Pattern（MNP）——名前にそのまま構造が入っています。
ここまで見てきた MNP の実装例がこちらです。DLM（意思決定マップ）を AI に書かせて、人が GUI で直せるエディタ。記法を覚える必要はなく、AI に書いてもらった記法を貼るだけで使えます。
今までの DSL は「人が覚えて書く」前提で作られていました。でもこのやり方では、人は DSL を書きませんし、見る必要もありません。DSL はAI とツールの間だけで流れる中間の形になります。人が持つのは、手法の考え方だけで十分です。
使う人が覚えるのは「手法の考え方」だけです。記号もツール操作も、基本は覚える必要がありません。あとは AI に頼んで、返ってきたテキストをエディタに貼るだけです。
5 つ前後の考え方を記事 1 本で読みます。
エディタ内に用意されたプロンプトを AI に貼ります。
「こういう図を書いて」と普通の日本語で頼みます。
返ってきたテキストを貼ると図が描かれます。
マウスで動かしたり、AI に差分を頼んだりします。
作る側も DSL の中身を知らなくても構いません。拡張したくなったら、今の HTML を AI に渡して「こう変えて」と頼めば、新しいバージョンが返ってきます。資産はコードではなくなります。代わりに大切になるのが、「良い図とは何か」を言葉にしたプロンプトです。
読みやすさ、拡張性、保守性、API 設計に投資します。チームで共有し、長期で育てる前提で書きます。
コードは作り直せる副産物です。磨くのは、手法の判断軸を言語化したプロンプトの方。実装にかけていた労力が、プロンプトの質に振り替わります。
記法の語彙が変わるだけで、「テキストが GUI と AI の間を流れる」構造はどれも同じです。画面設計・採用CMS・脱出ゲーム——それぞれ試してみてください。
条件は二つだけです。状態がテキストで表現できることと、同じ構造が繰り返されること。この二つが揃えば、どんなドメインにも適用できます。
screen: login field email button "送信"
job: "Webエンジニア" type: 正社員 tag: #React #リモートOK
npc "どう対応する？" score 62 fire_up 15 choices "確認"|"受ける"
node 認知 → 検討 .. 離脱 ~ 解放端 / #3
contract: 業務委託 party: 甲 乙 date: 2026-06
AI に渡すプロンプトの内訳を見ると、記号のルールは最低限で済みますが、「良い図とは何か」の判断軸の方がずっと厚くなります。この判断軸の厚みがないと、どんなに記号を作り込んでも、平凡な出力しか返ってきません。
このやり方は、手法が先にあることが前提です。手法が薄ければ、AI が出してくるのは「どこかで見た平凡な図」になってしまいます。AI は平均的なものを出すのが得意で、固有の経験の代わりにはなりません。
自分の手法を持っている（あるいは育てている）場合です。良し悪しを自分の言葉で説明できること。個人〜小チーム〜クライアント数社の規模で配る使い方に向いています。
手法がまだ曖昧で、判断軸をプロンプトに落とし込めない場合です。大勢で同時編集することが必須の場合。会社が AI の使用自体を禁止している場合。
「手法専用の、小さな Mermaid」を作ります。Mermaid を使う話ではありません。
AI に渡すのは手法の考え方だけです。記法も描画も編集もプロンプトも、全部 AI が組みます。
コードは再生成できる副産物です。作る側が磨くのはプロンプトに移ります。
効くかどうかは、手法の判断軸を自分で言葉にできるかの一点にかかっています。
着想は新しくありませんが、AI が独自の記法を扱えるようになったことで、ようやく実用的な選択肢になりました。