Mermaid入門 第5回：インタラクティブ表現と、AI時代の図解思考

第3回で状態遷移図とER図という古典を、第4回でこの一年に加わった新ダイアグラム群を見てきました。発展編の最終回となる本稿では、もう一段進んだテーマを扱います。

一つは、Mermaid の図を静的な画像から、クリックできる・反応する生きた図に変えるインタラクティブ表現。もう一つは、ここ一年で決定的に変わった LLM と一緒に図を描くワークフロー。どちらも「実務でMermaidをどう使いこなすか」に直結するテーマです。

1. Mermaid の応用テクニック ― 挙動・意味・見た目を乗せる

Mermaid は「生成して終わり」の静的画像ではなく、クリックできる・意味をクラスで表現できる・アイコンやロゴを埋め込める——そんな応用テクニックを備えています。第2回で予告した「インタラクティブ表現」を、ここで回収します。

この節では三つの層に分けて整理します。挙動（click によるリンクやコールバック）、意味（classDef による意味のエンコーディング）、見た目（アイコンと画像の埋め込み）。それぞれ独立した機能ですが、組み合わせると図は一気に情報量が増えます。

1-1. click 構文でリンクを貼る（挙動）

ノードにクリックイベントを付けられます。

flowchart LR
    A[ドキュメント] --> B[図解]
    B --> C[問い合わせ]
    
    click A href "https://example.com/docs" _blank
    click B href "https://example.com/diagrams" _blank
    click C href "https://www.untype.jp/contact" "お問い合わせページへ"

click ノード名 href "URL" [target] ["tooltip"] の書式で、ノードからの外部リンクを作れます。JavaScript コールバックを指定する click ノード名 call 関数名() "tooltip" という形式もあり、埋め込み先のアプリ側でイベントを受けて任意の処理を走らせることもできます。

⚠️ 重要：click は環境依存で動かないことがある

公式ドキュメントには次のように明記されています——「click 機能は securityLevel='strict' では無効、securityLevel='loose' で有効」。strict が既定値なので、何も設定しないと click は動きません。href リンクもコールバックも、どちらも同じ挙動です。

以下の二つの比較表は、本稿執筆時点（2026年4月）の観察に基づくものです。Mermaid 本体や各ホストサービスのアップデートにより挙動は変わりうるため、実運用の前に対象環境で一度試すことを前提にしてください。

① ドキュメント・ノートツール（Mermaid 自体はレンダリングされる前提）

② AIエージェント（そもそも Mermaid が描画されるかが第一関門）

この表が意味するところは大きく二つあります。

第一に、click をあてにした図を公開用に書くべきではない。GitHub や Obsidian、多くのドキュメントサイトでは click は無効です。実装の労力に対して、読者がクリックできる環境は限定的です。リンクは click ではなく、図の近くに普通の Markdown リンクを並べるほうが結果的に確実に伝わります。click は自分の管理下にある環境——自社サイト、社内ツール、Mermaid Live Editor での試行、Mermaid Chart の共有——で使うのが筋です。

第二に、AI と一緒に Mermaid を扱うなら、Mermaid がネイティブ描画される環境を選ぶと生産性が段違いに上がる。ChatGPT や Gemini で Mermaid を書いてもらう場合、出力されたコードを Mermaid Live Editor に毎回貼り付けて描画確認する手間が発生します。一方 Claude.ai の Artifacts なら、生成・描画・修正がチャット上で一体になるため、反復サイクルが速い。「AI で Mermaid を書く」というワークフロー自体が、実はツール選択で大きく生産性が変わる領域なのです。AI サービスは短いスパンで機能追加が続いているため、この優劣は今後変わっていく可能性もあります。

なお、ユーザー生成コンテンツを扱うサイトで loose を安易に設定すると、悪意のあるコードで XSS の温床になりえます。loose を選ぶのは、ダイアグラムのソースを自分（またはチーム）が完全に管理している場合に限るべきです。社内ツールでダッシュボード的に使うなど、出し入れする図の中身を信頼できるケースでは、コールバックを組み込んで任意の JavaScript を走らせると非常に効果的です。公開サイトでは href リンクに限定し、外部リンクは _blank で新規タブ遷移にするのが実用的なバランスです。

1-2. classDef と linkStyle で「意味」をスタイルに乗せる（意味）

第2回でも style 命令は扱いましたが、規模が大きくなるとクラスベースの定義のほうが保守しやすくなります。CSS と同じ発想です。

なお、この機能は見た目の制御であって、クリックなどの挙動そのものは作りません。「色や線で何かを伝える」ための道具と割り切って使います。

flowchart LR
    A[正常ノード]:::normal
    B[重要ノード]:::critical
    C[警告ノード]:::warning
    D[廃止ノード]:::deprecated
    
    A --> B
    B --> C
    C --> D
    
    classDef normal fill:#fff,stroke:#333,stroke-width:1px
    classDef critical fill:#bbf,stroke:#33f,stroke-width:3px,color:#000
    classDef warning fill:#fdd,stroke:#d33,stroke-width:2px,color:#000
    classDef deprecated fill:#eee,stroke:#999,stroke-dasharray:5 5,color:#666
    
    linkStyle 2 stroke:#d33,stroke-width:2px

ノードに :::クラス名 を付けるだけでスタイルが適用されます。linkStyle はエッジ（線）を対象にし、インデックス番号（0 から）で指定します。

ここで強調したいのは、色やボーダーは「装飾」ではなく、意味のエンコーディングとして使うべきだということです。「重要＝青で太線」「廃止＝グレーの破線」といったルールをチーム内で決め、それを classDef で辞書化する。すると図の色そのものが情報になり、凡例なしで読める図に近づきます。classDef は click と違って securityLevel の影響を受けないので、GitHub でも Obsidian でも、AI エージェントが Mermaid を描画する環境でも、そのまま描画されます。

1-3. iconShape と imageShape ― 図の中にアイコンやロゴを埋め込む（見た目）

v11 では、フローチャートのノードをアイコンや画像にできるようになりました。Iconify のアイコンパックをブラウザに登録しておけば、企業ロゴから UI アイコンまで、20万種を超える規模から選んで使えます。

unType のブログで登録しているアイコンパック

このブログでは、以下の 3 つの主要パックをあらかじめ登録しています。三つ合わせて数千〜1万種規模のアイコンが、コード一行で呼び出せる状態です（パック内のアイコン数は随時追加されるので参考値）。

• logos — AWS、GCP、React、GitHub、OpenAI など、企業・製品ロゴのコレクション
• lucide — 統一感のある線画 UI アイコンセット
• mdi — Google の Material Design Icons（7,000種規模）

各パックの正確なアイコン数と最新ラインナップは、上記リンクの Iconify 公式検索サイトで確認できます。

自分のサイトに組み込む場合は、Mermaid 初期化時にアイコンパックを登録します。

mermaid.registerIconPacks([
  { name: "logos",  loader: () => fetch("https://unpkg.com/@iconify-json/logos@1/icons.json").then(r => r.json()) },
  { name: "lucide", loader: () => fetch("https://unpkg.com/@iconify-json/lucide@1/icons.json").then(r => r.json()) },
  { name: "mdi",    loader: () => fetch("https://unpkg.com/@iconify-json/mdi@1/icons.json").then(r => r.json()) },
]);

アイコン名は パック名:アイコン名 の形式で指定します。logos:react で React ロゴ、lucide:user でユーザーアイコン、mdi:robot でロボットアイコン、といった具合です。

基本例：UIアイコンで役割を表現する

まずは lucide パックで、汎用的な役割を表してみます。

flowchart LR
    User@{ icon: "lucide:user", form: "circle", label: "ユーザー", pos: "b" }
    Shield@{ icon: "lucide:shield-check", form: "square", label: "認証", pos: "b" }
    App@{ icon: "lucide:server", form: "square", label: "アプリサーバー", pos: "b" }
    DB@{ icon: "lucide:database", form: "square", label: "データベース", pos: "b" }
    
    User --> Shield --> App --> DB

form は背景の形状で、square（四角）・circle（円）・rounded（丸角）、指定なしなら背景なしを選べます。pos はラベルの位置で、t（上）か b（下）です。

企業ロゴでスタックを表現する

システム構成を説明するとき、汎用的な「サーバー」「データベース」ではなく、実際に使っている製品のロゴで描けると、提案書や技術資料の説得力が段違いに上がります。これまで PowerPoint でロゴを1つずつ貼り付けていた作業が、Mermaid のコード一行で済むようになります。

flowchart LR
    React@{ icon: "logos:react", form: "square", label: "React", pos: "b" }
    Next@{ icon: "logos:nextjs", form: "square", label: "Next.js", pos: "b" }
    Vercel@{ icon: "logos:vercel-icon", form: "square", label: "Vercel", pos: "b" }
    PG@{ icon: "logos:postgresql", form: "square", label: "PostgreSQL", pos: "b" }
    Redis@{ icon: "logos:redis", form: "square", label: "Redis", pos: "b" }
    
    React --> Next --> Vercel --> PG
    Vercel --> Redis

アーキテクチャ図で企業ロゴを使う

第4回で紹介した architecture-beta でも、同じアイコンパックが使えます。group と service の両方で、pack:name 形式でアイコンを指定できるため、本物のクラウド構成図が Mermaid 一つで完結します。

architecture-beta
    group cloud(logos:aws)[AWS Cloud]
    service cdn(logos:cloudflare)[Cloudflare] in cloud
    service api(logos:nodejs)["Node.js API"] in cloud
    service cache(logos:redis)[Redis] in cloud
    service db(logos:postgresql)[PostgreSQL] in cloud
    service ai(logos:openai)[OpenAI]

    cdn:R --> L:api
    api:R --> L:cache
    api:B --> T:db
    api:T --> B:ai

AI 時代のスタックを一枚で描く

三つのパックを組み合わせた、もう少し現代的な例も置いておきます。AI エージェントを中心に据えたシステムの概念図です。ブランドロゴ（logos）、抽象アイコン（lucide）、Material Design（mdi）を、役割に応じて使い分けているのがポイントです。

flowchart LR
    User@{ icon: "lucide:user", form: "circle", label: "ユーザー", pos: "b" }
    UI@{ icon: "logos:react", form: "square", label: "React UI", pos: "b" }
    Agent@{ icon: "mdi:robot", form: "square", label: "AIエージェント", pos: "b" }
    LLM@{ icon: "logos:openai-icon", form: "square", label: "GPT-4", pos: "b" }
    MCP@{ icon: "lucide:plug", form: "square", label: "MCPサーバー", pos: "b" }
    DB@{ icon: "logos:postgresql", form: "square", label: "DB", pos: "b" }
    Search@{ icon: "lucide:search", form: "square", label: "Web検索", pos: "b" }
    
    User --> UI
    UI --> Agent
    Agent --> LLM
    Agent --> MCP
    MCP --> DB
    MCP --> Search

アイコン選びのコツ

機能・役割で選ぶなら lucide か mdi、ブランド・製品を示すなら logos、と使い分けると混乱しません。lucide と mdi は見た目のテイストが違うので、一枚の図ではどちらか一方に寄せるのが原則です。ただし、上の AI スタック例のように、ブランドロゴ（logos）に対してアクター・機能は lucide、主役級の存在は mdi、とパックそれぞれに役割を持たせる書き分け方もあります。

使いたいアイコンが見つからないときは、各パックの検索サイト（上のリンク参照）で日本語・英語どちらでも検索できます。logos:aws か logos:amazon-aws か？ を毎回覚えていられない問題は、LLM との組み合わせで一瞬で解決します。「Mermaid で AWS、Cloudflare、PostgreSQL のスタック図を logos パックで書いて」と頼めば、それらしいアイコン名で返ってきます。ただし、後述するようにAI は存在しないアイコン名を自信満々で創作することがあるので、初見のアイコンは Iconify 検索サイト で一次確認する習慣をつけるのが安全です。

imageShape ― 任意の画像をノードにする

アイコンパックに含まれていない独自ロゴや、自社の製品画像をノードにしたい場合は、画像ノード @{ img: "..." } を使います。

flowchart LR
    A@{ img: "https://www.untype.jp/logo.svg", label: "unType", w: 80, h: 80, pos: "b" }
    B@{ icon: "logos:react", form: "square", label: "React", pos: "b" }
    A --> B

※ 上記は Mermaid の @{ } メタデータ構文を使った将来的な記法の想定例です。flowchart での img / icon シェイプは v11.x 現在は正式サポートされておらず、現行版ではエラーになります。icon を使う場合は architecture-beta、画像埋め込みは HTML ラベル (<img>) で代替してください。

w と h でピクセル単位の大きさを指定できます。自社のブランディング色を保ったまま、オフィシャルロゴをそのまま Mermaid に組み込めるのが強みです。ただし画像は外部 URL からの読み込みになるので、サイトの CSP（Content Security Policy）によってはブロックされることがあります。社内利用でない場合、画像は自社ドメインに置くのが運用上は無難です。

2. AI時代の「図解思考」

ここまで記法の話が続いたので、最後は思考法の話に切り替えます。この一年で起きたもうひとつの変化——LLM が Mermaid を書くようになったことが、実務にどう影響するかを整理します。

2-1. なぜ LLM は Mermaid と相性がいいのか

大規模言語モデルは、画像ではなくテキストで世界を扱います。画像を生成するには別途の拡散モデルが必要ですが、Mermaid のようなテキスト記法なら、モデルは普段の言語生成と同じ能力だけで図を出力できる。

これは Mermaid の側から見ると決定的な優位性です。Markdown、YAML、JSON、Mermaid——これらはすべて「AIが自然に書ける構造化テキスト」の系譜にあります。しかもテキストであるがゆえに、Git で差分管理でき、レビューでコメントを付けやすく、バージョン履歴を辿れる。Figma や Illustrator の独自バイナリフォーマットには真似できない強みです。

つまり Mermaid は、AI と人間が同じ言語で設計を議論でき、さらに差分で履歴を残せる、数少ない図解メディアです。「このフローチャートの C のあとに、エラーハンドリングを足して」と自然言語で言えば、AI は Mermaid コードを書き換えて返してくれる。それを Git に commit すれば、いつ・誰の判断で図が変わったかが後から辿れる。これはここ一年で実現した、まったく新しいワークフローです。

ただし 1-1 の比較表で見たとおり、AI が Mermaid を「書ける」ことと、そのチャット画面で「描画される」ことは別問題です。ChatGPT や Gemini は Mermaid コードを返しますが、描画は別環境で行う必要があります。Claude.ai の Artifacts のように生成と描画が一体になった環境を選ぶと、生成 → 確認 → 修正のサイクルが大幅に短縮されます。AIツールの選択は、「モデルの賢さ」だけでなく「Mermaid ワークフローとの親和性」でも評価する時代になりました。

2-2. AI に「伝わる」図を書くコツ

逆方向、つまり AI が読む側 になるケースも無視できません。LLM に仕様書や設計書を読ませるとき、本文に Mermaid 図を埋め込んでおくと、モデルはその構造をかなり正確に把握します。フローチャートのノードとエッジはそのまま「どれがどれに依存しているか」のグラフとして解釈されますし、ER 図は「テーブル関係の地図」として機能します。

AI に読ませる前提で図を書くときのポイントを三つ。

ノード名を曖昧にしない。 「処理A」「ステップ1」ではなく、「ユーザ認証」「在庫チェック」のように内容が名前から分かるようにする。LLM は名前から多くを推論します。

遷移ラベルを省略しない。 矢印に条件や動作を明記することで、モデルは「なぜその方向に進むのか」を読み取れます。省略すると、AI が勝手に補完して誤読するリスクが出ます。

スタイル情報を混ぜすぎない。 classDef や色指定は人間向けの装飾です。ロジックに関係しない色情報を混ぜすぎると、AI がそれをノードの種類と誤解することがあります。意味を持たせるなら意味を持たせる、装飾なら装飾と割り切る。

2-3. 生成 → 検証 → 修正のワークフロー

AI に Mermaid を書かせる実務ワークフローは、次の三段階で整うはずです。

flowchart TB
    A[プロンプト設計] --> B[AIが生成]
    B --> C[Live Editor で描画確認]
    C --> D{問題あり?}
    D -->|構文エラー| E[エラー文をAIに戻す]
    D -->|意味が違う| F[要件を追記して再生成]
    D -->|OK| G[本番に反映]
    E --> B
    F --> B

プロンプト設計では、「何を描きたいか」だけでなく「どの種類の図で描きたいか」まで指定します。「この業務フローを stateDiagram-v2 で、コンポジット状態を使って書いて」と指示すると、AI の出力が安定します。図の種類を AI に選ばせると、意図と違うダイアグラムを選びがちです。

生成後は、必ず描画確認をします。Claude.ai の Artifacts ならチャット上でそのまま確認でき、ChatGPT や Gemini を使っている場合は Mermaid Live Editor に貼り付けるのが定番です。AI の生成コードは、もっともらしく見えても構文エラーを含んでいることが珍しくありません。

検証で問題が見つかったら、エラーメッセージをそのまま AI に投げ返すのが最速です。「この図を描いたら Parse error 〜〜 が出た。直して」と言えば、AI は自己修復してきます。これを数回繰り返すと、最終的にはクリーンなコードに収束します。

意味が違っている場合は、要件を足して再生成させます。ここで大事なのは、AI の出力を信用しきらないこと。AI は「平均的にそれらしい図」を出すのが得意ですが、その「平均」があなたの業務の特殊性を反映しているとは限りません。AI が生成するのはあくまで叩き台で、最終的な意味を通すのは人間の役割です。生成物をそのまま公開するのではなく、一度自分の言葉で読み直して、違和感があれば直す。これを省略すると、読み手に伝わらない「AIっぽい図」が量産されます。

2-4. 典型的な失敗パターン

AI に Mermaid を書かせて、よく遭遇する失敗を三つ挙げます。

版が古い文法を混ぜる。 LLM の学習データには、古い Mermaid 記法と新しい記法が混在しています。そのため、stateDiagram（v1）と stateDiagram-v2 が混ざったり、存在しないシェイプ名が出たりします。最新版の記法を明示的に指定する（「stateDiagram-v2 で」「v11 の新シェイプ cyl を使って」など）とこれが減ります。

記号のエスケープミス。 日本語ラベルに (、)、{、} が含まれると構文が壊れることがあります。AI の生成コードでラベルが途中で切れていたら、まずエスケープか引用符（"..."）で囲っていないのが原因と疑ってください。

存在しないシェイプやアイコン名の創作。 AI はときどき、存在しない flowshape や databaseCylinder のような機能や、logos:postgres-database のようなもっともらしい架空のアイコン名を"自信満々で"出してきます。Mermaid 公式ドキュメントや Iconify の検索サイトに無いキーワードは、遠慮なく疑う。迷ったら一次資料で正式な記法を確認する習慣をつけると、遠回りに見えて結果的に速く仕上がります。

連載全体のまとめ ― 図解は「構造的抽出」の思考訓練でもある

第1回で Mermaid の基礎を、第2回で応用的な図解技法を、そして本発展編（第3〜5回）で状態遷移図・ER 図・新ダイアグラム群・Look/Layout・インタラクティブ表現・AI 時代の図解思考と、一気に進んできました。

Mermaid を使いこなすことの本質は、実は記法を覚えることではありません。ある現象を観察したとき、それが「状態の遷移」なのか「データの関係」なのか「処理の流れ」なのか「構成比」なのか「時系列」なのかを見分けられるようになること。 そして、それぞれの構造に最適な表現方法を選び取れるようになること。これは図解ツールの話であると同時に、現象から構造を抜き出す思考訓練でもあります。

AI 時代、ますます多くの生成物が「平均的にそれらしい」形で供給されます。その中で、自分の理解を、自分の言葉と図で定着させる能力は、希少価値を上げていきます。Mermaid のようなテキストベースの図解ツールは、その訓練場として、とても都合がよい道具です。テキストだから Git でバージョン管理でき、AI と共同編集でき、人間の目でレビューでき、そしてまた書き直せる。

次回以降で扱いたいテーマとしては、マインドマップ・Git グラフ・Quadrant・XY Chart・Sankey など残る定番ダイアグラムの実務活用、そしてドキュメントシステム（Docusaurus、Notion、Obsidian、静的サイトジェネレータ、Confluence）との連携実践を考えています。運用の現場で使える Tips を別連載としてまとめる機会をまた作れればと思います。

図解はツールである前に、思考の形式です。Mermaid を通じて、その形式を自分のものにしていってください。

参考情報

• Mermaid 公式サイト — すべての一次情報の集約点

• Mermaid Live Editor — ブラウザ上で即座に試せる公式エディタ

• Flowcharts Syntax — フローチャートの全構文。click・classDef・linkStyle・新 Shape すべてここに

• Configuration Usage — securityLevel と click の挙動に関する一次情報

• Mermaid Config Schema — securityLevel・htmlLabels などの設定一覧

• Registering icon pack in mermaid — registerIconPacks の公式ガイド

• Architecture Diagram（v11.1.0+） — Iconify パックを使うアーキテクチャ図

• Iconify 検索サイト — 20万種を超えるアイコンを横断検索できる公式サイト

• logos（@iconify-json/logos） — 企業・製品ロゴのコレクション

• lucide（@iconify-json/lucide） — 統一感のある線画 UI アイコン

• mdi（@iconify-json/mdi） — Material Design Icons

• How to Use Mermaid as an AI Diagram Generator — Mermaid Chart 公式の AI 活用ガイド

• Mermaid 公式ブログ — リリース情報と新機能の一次発表