Mermaidの価値は、図の中の判断を文字で検査できることにある

業務フローの図は、できあがった瞬間に、会議資料の中で最も疑われない部品になります。矢印が整然と並んでいるだけで、手順が漏れなく書かれているように見えるからです。Mermaid（マーメイド）は、文字だけで図を描ける記法として紹介されることが多いのですが、価値の中心は描く速さではありません。図の中に隠れていた判断が文字になり、抜けや矛盾を読めるようになることです。この記事では、Mermaidの仕組みと図の種類、使える場所と注意点を押さえたうえで、AIに図を描かせるときに、きれいな図に惑わされずに中身を検査する方法を示します。

Mermaidは、図をテキストとして持つ記法です

Mermaidは、テキストの記述からフローチャート、シーケンス図、ガントチャート、クラス図、ER図、状態遷移図、ユーザージャーニーマップなどを描くオープンソースのライブラリです。Markdownの中に直接書けるため、開発のドキュメント、要件定義、業務フローの整理など、幅広い場面で使われています。

以前は、Markdownの資料に流れ図を入れるには、文字で絵を組むか、外部ツールで作った画像を貼るしかありませんでした。画像は修正のたびに作り直しが必要で、どこを変えたのかも追えません。Mermaidは図をテキストそのものとして持つので、Gitなどで版を管理でき、変更点の差分がそのまま読めます。英語ベースの短い構文で覚えやすく、GitHub（2023年時点で公式にサポート）、GitLab、Notion、Confluence、Obsidian、Typora、VSCodeの拡張機能など、多くの場所で表示できます。mermaid-cliというコマンドラインの道具を使えば、SVGやPNGの画像に書き出すこともできます。

画像の図は、判断の抜けを隠します

画像の図には、描かれていないものが見えないという弱点があります。分岐の矢印が一本足りなくても、図はそのまま美しく完成して見えます。テキストの図では、判断のノードと、そこから出ていく矢印が一行ずつ並ぶので、数えることができます。

flowchart TB
  A[見積もり依頼を受け付ける] ==> B{在庫があるか}
  B ==>|はい| C{金額が上限を超えるか}
  B ==>|いいえ| D[納期を回答する]
  C ==>|はい| E[上長の承認を得る]
  E ==> F[請求書を送る]

このコードを読むと、判断のノード C から出る矢印は、はいの一本しかありません。金額が上限を超えない場合にどうなるのかが、どこにも書かれていないのです。描画した図を眺めているだけでは、この欠けに気づくのは難しいでしょう。ない矢印は、見えないからです。きれいなフローチャートが会議を一発で通るのは、図が正しいからではなく、図に描かれていない分岐を誰も指させないからです。

書き方の基本も押さえておきます。1行目で図の種類を宣言し、フローチャートなら続けて向きを指定します。LRは左から右、TBは上から下、RLは右から左、BTは下から上です。角括弧は長方形、波括弧はひし形、二重の丸括弧は円になり、矢印の途中に縦棒で囲んだ文字を入れると条件を書けます。A、B、CはノードのIDで、同じIDを別の場所で使うと同じノードとして扱われます。まとまりは subgraph と end で囲み、色は classDef で定義します。

図の種類を選ぶことが、最初の判断です

図の種類は、1行目のキーワードで決まります。

flowchart は処理や判断の流れ、sequenceDiagram は人やシステムの間のやりとりの順番（participantで登場者を定義し、alt、loopで分岐や繰り返しを書く）、gantt は日程表（dateFormatで日付の形式、sectionで段階、after で前のタスクに続ける）を描きます。classDiagram はクラスの属性や継承、erDiagram はテーブルの関係、stateDiagram は状態の切り替わり、journey は利用者の行動と満足度の流れです。

種類の選択は、見た目の好みではなく、何を本質として扱うかの判断です。同じ受注業務でも、flowchart で描けば判断の分岐が見え、誰が担うかは隠れます。sequenceDiagram で描けば担い手の間のやりとりが見え、分岐は目立たなくなります。図の種類を一つ選ぶたびに、何かを見えなくしていることは覚えておく価値があります。

よくあるつまずきは、表示されない（環境が対応していないので、mermaid-cliなどで画像にして貼る）、一部が描かれない（IDに空白を入れた、大文字と小文字を間違えた、線と矢印の記号を取り違えた）、図が見づらい（ノードが多すぎるのでサブグラフにまとめるか図を分ける）、環境で結果が違う（版によって構文が違うので公式のドキュメントで確認する）の四つです。

AIに描かせたら、テキストのまま検査します

MermaidはAIとの相性がよい記法です。AIは画像を直接描くより、テキストの構文を書くほうが得意だからです。そのぶん、もっともらしく整った図が一瞬で返ってきます。検査の手順を、依頼に組み込んでおきます。

次の業務の流れを、Mermaid の flowchart で描いてください。向きは上から下（TB）にします。
対象は、見積もり依頼の受付から請求書の送付までです。
判断の分岐は「在庫があるか」と「金額が上限を超えるか」の二つです。
ノードのラベルは12文字以内の日本語にしてください。
コードの後に、判断のノードごとに、出ていく矢印とその条件を表にしてください。
条件が書かれていない分岐や、どこにもつながらないノードがあれば挙げてください。

後半の二行が検査です。判断ごとの表を見れば、はいといいえの両方が揃っているか、条件に漏れや重なりがないかを確かめられます。表示されない箇所があれば、エラーの出た部分をそのまま貼って直させます。

この方法が向かない場面もあります。配置そのものに意味がある図、たとえば座席表や空間の配置図は、テキストから自動で配置されるMermaidでは表しにくいでしょう。ノードが数十を超える図では、自動の配置が読みにくくなり、テキストのほうが頼りになります。また、AIが図の構造の誤りをどこまで自分で見つけられるかは、図の大きさやモデルによって変わり、AIの申告がないことは誤りがないことの証明になりません。業務フローは作りました、と言える組織と、業務フローを読みました、と言える組織は、別の組織です。図は描き終えた瞬間ではなく、分岐を一つずつ指でなぞった瞬間に仕事をします。

あなたの職場にある業務フロー図で、いいえの矢印が描かれていない判断はいくつあるでしょうか。その図の分岐を最後に一つずつ確かめたのは、誰だったでしょうか。

この記事の背景にある考え方は、拙著『ChatGPT はじめてのプロンプトエンジニアリング』の4章1節「発散と収束で単純化」のうち、MECEとロジックツリーを扱う項に書きました。本書は、AIが分解した結果をそのまま受け取らず、「なぜこの分解がMECEと言えるのですか？」と問い返すことを勧めています。この項を読むと、図や分解をAIに作らせたあと、漏れと重なりがないかを自分の問いで確かめる手順を、業務の図にも当てはめて考えられるようになります。