Mermaid入門 第4回：2025–2026 Mermaid大全 ― 新ダイアグラム・新Shape・Look/Layout

前回の第3回では、状態遷移図と ER 図という古典的な二つのダイアグラムを深掘りしました。この二つが押さえられれば、「振る舞い」と「関係」はもう大抵のものが描けます。

一方で、この一年間（2025年4月から2026年4月）で、Mermaid は別の方向でも大きく進化しました。v11 系で描画エンジンが刷新され、従来になかったタイプのダイアグラムが次々に追加されたのです。クラウド構成図、タイムライン、カンバン、レーダー、ツリーマップ、パケット図、ブロック図。さらにフローチャートには 30 種類の新 Shape が入り、ダイアグラム全体の「見た目」を選べる Look 機能、より洗練されたレイアウトエンジン ELK もやってきました。

第2回執筆時点（2025年4月）から本記事執筆時点（2026年4月）までの一年分の進化を、この第4回でまとめて棚卸しします。一つひとつは短い紹介ですが、どの図を、いつ、なぜ使うかが選べるようになることを目指します。

1. Architecture Diagram（v11.1.0+）

クラウドアーキテクチャやマイクロサービス構成を描くための専用ダイアグラムで持ち、さらに Iconify の20万以上のアイコンを登録して使うこともできます。

architecture-beta
    group api(cloud)[API Layer]
    service gateway(internet)[Gateway] in api
    service auth(server)[Auth] in api
    service app(server)[App] in api
    
    group data(cloud)[Data Layer]
    service pri(database)[Primary] in data
    service cache(disk)[Cache] in data
    
    gateway:R --> L:auth
    gateway:B --> T:app
    app:R --> L:pri
    app:B --> T:cache

注目すべきは gateway:R --> L:auth という辺の書き方です。:R（右）、:L（左）、:T（上）、:B（下）で、サービスのどの面から線が出るかを明示できます。これによって、自動レイアウトが崩れても人間の意図どおりの線の引き回しが維持されやすくなります。

これまでフローチャートでシステム構成を描いていた人は、architecture-beta に乗り換えるだけで一気に「それっぽい」図になります。AWSやGCPの構成図を資料に入れたいとき、従来は draw.io や Cloudcraft を引っ張り出していた場面が、Mermaid 一枚で済むようになりました。

2. Timeline

時系列を描くダイアグラム。歴史年表、プロダクトロードマップ、プロジェクトの節目など、「いつ何が起きたか」を縦断的に見せるときに使います。

timeline
    title Mermaid の進化
    2019 : JavaScript Open Source Award 受賞
    2024 : v11.0 リリース（描画エンジン刷新・ELK導入）
         : Packet Diagram 追加
         : 30 の新 Shape と @{shape:...} 記法
         : Hand-Drawn Look 追加
         : Architecture / Kanban 追加
    2025 : Radar（v11.6）
         : Treemap（beta）追加
         : Venn / Ishikawa 追加（v11.13）
    2026 : 表現力がさらに拡張

同じ時期に複数の出来事を書くときは、行頭を : で揃えて並べます。ガントチャートが「期間」を示すのに対し、タイムラインは「点」を時系列で並べるのに向きます。会社沿革、技術史、個人のキャリアマップなどに最適です。

3. Kanban（v11.4+）

カンバン式のタスクボードを Mermaid で描けるようになりました。列を columnId[列名]、タスクをインデントした下の行に taskId[タスク内容] で定義します。

kanban
    todo[ToDo]
        t1[要件整理]
        t2[ワイヤーフレーム]
    doing[Doing]
        t3[API実装]@{ assigned: "田中", priority: "High" }
    done[Done]
        t4[要件定義書作成]
        t5[キックオフ]

@{ ... } の属性記法で、担当者・優先度・チケット番号などのメタデータを添えられます。ticketBaseUrl を設定すれば、チケット番号から自動的に Jira / GitHub Issues へのリンクも張れます。「Jira や Trello で管理するほどじゃないけど、資料の中で軽くタスクを見せたい」というときに便利です。プロジェクトキックオフの一次資料や、提案書のタスク分担図としてよく馴染みます。

4. Radar（v11.6.0+）

レーダーチャート。複数軸のスコアを同心多角形で表示します。スキルマップ、製品比較、ベンチマーク結果の可視化に向きます。

radar-beta
    title AIエージェント互換性スコア
    axis str["構造化データ"], sem["セマンティクス"], perf["性能"], sec["セキュリティ"], a11y["アクセシビリティ"]
    curve before["Before"]{55, 40, 75, 80, 65}
    curve after["After"]{88, 85, 82, 85, 80}
    max 100
    min 0

axis で軸を宣言し、curve で名前付きのスコア配列を指定するだけ。複数の curve を重ねれば before/after や競合比較がそのまま描けます。これまでレーダーチャートは Excel や専用ツールに頼っていましたが、Mermaid で描けるようになったことで、テキストでバージョン管理できる診断レポートが現実的な選択肢になりました。

5. Treemap（beta）

階層データを面積で表現するツリーマップです。構成比を示したいとき、円グラフよりも情報量が多く、フォルダ構造や予算配分の可視化に向きます。

---
config:
  treemap:
    valueFormat: "$0,0"
---
treemap-beta
    "プロダクト開発予算"
        "既存強化"
            "UI改善": 30000
            "性能最適化": 20000
        "新規開発"
            "AIエージェント対応": 40000
            "多言語対応": 15000

フロントマターで valueFormat を指定すると、raw の数値（たとえば 30000）が $30,000 のように整形されて表示されます。$.2f で小数点つき通貨、.1% でパーセント、, で三桁区切りなど、D3 のフォーマット指定子をそのまま使えます。予算配分や工数内訳を視覚化するときに、棒グラフよりも階層構造が一目で伝わります。

6. Packet Diagram（v11.0.0+）

ネットワークパケットやバイナリプロトコルのビットフィールドを描くための、かなり専門的なダイアグラム。技術ドキュメントで「このパケットはこういう構造です」と示すときに重宝します。

packet-beta
    title TCPヘッダ（抜粋）
    0-15: "送信元ポート"
    16-31: "宛先ポート"
    32-63: "シーケンス番号"
    64-95: "確認応答番号"
    96-99: "データオフセット"
    100-105: "予約"
    106-111: "制御フラグ"
    112-127: "ウィンドウサイズ"

ビット範囲を start-end: の形で指定する簡潔な文法です。プロトコル仕様書、バイナリフォーマット説明、ネットワーク教育資料で、従来は Visio や自作の画像でしか描けなかったものが、テキストで管理できるようになります。直前のフィールドから何ビットぶんかを指定する +<count>: 記法も併用できるので、設計変更の差分が小さく済みます。

7. Block Diagram

自由度の高い「ブロック積み」ダイアグラム。CSS グリッドのような発想で、列数を指定し、その中にブロックを並べていきます。Architecture ほど制約のないシステム概念図を描きたいときに使います。

block-beta
    columns 3
    Input["入力"] Logic["処理"] Output["出力"]
    Data["データ"] Model["モデル"] Result["結果"]
    Input --> Logic
    Logic --> Output
    Data --> Model
    Model --> Result

概念説明のとき、フローチャートだと「流れ」が強すぎて、ブロック同士の並置関係が伝わらないことがあります。そういうときは Block Diagram に切り替えると、階層と並列をきれいに見せられます。

Architecture と Block の使い分け。 Architecture はクラウド・CI/CD 的な「サービスとリソースの配線図」に特化しており、組み込みアイコン（cloud/server/database など）と :L/R/T/B による辺の接続指定が強みです。一方 Block は意味づけがなく、ひたすら自由なブロック配置ができるため、概念モデル、システムのレイヤー構造、教材スライド向けの「箱と矢印」など、汎用的な抽象図にはこちらが向きます。「具体的なクラウド構成を描くなら Architecture、抽象的な構造を描くなら Block」と覚えておくと迷いません。

8. 30 の新 Shape と新しい記法

v11 ではフローチャートのノード形状が 30 種類追加され、同時に新しい記法が導入されました。A@{ shape: cyl, label: "データベース" } のように、@{ ... } でシェイプ名を明示する書き方です。

flowchart LR
    Input@{ shape: lean-r, label: "入力" }
    Process@{ shape: rect, label: "処理" }
    Decision@{ shape: diam, label: "判定" }
    DB@{ shape: cyl, label: "DB" }
    Doc@{ shape: doc, label: "レポート" }
    
    Input --> Process --> Decision
    Decision -->|Yes| DB
    Decision -->|No| Doc

主な追加シェイプに、cyl（データベース＝円筒）、doc（書類）、docs（複数書類）、disk（ディスク）、das（ダイレクトアクセスストレージ）、lean-r/lean-l（データ入出力＝平行四辺形）、manual-file（手作業ファイル）、manual-input（手入力）、delay（遅延）、event（イベント）、extract（抽出）、display（表示）、comment（注釈）があります。従来の [ ]・( )・{ } に比べ、意味論的に正しい形状を名前で選べるようになったのが大きな違いです。

図解の世界には「この処理は円筒で、この処理はひし形で」という長年の慣習があります。Mermaid の古い記法ではその慣習に対応する形状が限られていましたが、v11 以降はほぼすべての定番シェイプが使えるようになりました。業務フロー図や ETL パイプライン図を描くとき、この恩恵は大きい。

9. Look と Layout ― 見た目そのものを変える

v11 の目玉のひとつが、ダイアグラム全体の「見た目」を選べるようになったことです。フロントマターに数行足すだけで、同じコードが別の表情になります。

---
config:
  look: handDrawn
  theme: forest
  layout: elk
---
flowchart LR
    A[開始] --> B{条件}
    B -->|Yes| C[処理1]
    B -->|No| D[処理2]
    C --> E[終了]
    D --> E

設定できる三つの軸を整理します。

• look: classic（OSS のデフォルト）、handDrawn（RoughJS による手描き風。v11+）、neo（シャドウつきのモダンな見た目。v11.14.0+ で OSS にも追加され、Mermaid Chart ではこちらがデフォルトになっている）
• theme: default、forest、dark、neutral、base（カスタム用）
• layout: dagre（従来からの既定）、elk（より洗練されたレイアウトエンジン。複雑な図で破綻が少ない。フローチャートと状態遷移図を中心に対応が進んでいる）

プレゼン資料向けには neo + default、アイデアスケッチやワークショップ資料には handDrawn + forest のように使い分けると、同じ図でも「どの段階の資料か」が読み手に伝わります。整った図は「確定した設計」、手描き風の図は「議論中の叩き台」——そういう記号的な読み分けが、資料の中で自然にできるようになります。

まとめ

この一年で加わった新ダイアグラム群と表現力の拡張を一気に見てきました。Architecture・Timeline・Kanban・Radar・Treemap・Packet・Block、それに 30 の新 Shape と Look/Layout。どれも一つひとつ見れば「あの場面で使いたかった機能」に思い当たるはずです。

大事なのは、これらを覚えきることではありません。どの種類の図が、どの情報表現に向いているかを知っておくことです。

• 構成を描くなら → Architecture（クラウド構成図）/ Block（汎用ブロック）
• 時系列を描くなら → Timeline（点の年表）/ Gantt（期間の工程表）
• 進捗を描くなら → Kanban
• 指標の比較なら → Radar / XY Chart（棒・折れ線）
• 構成比なら → Treemap / Pie
• プロトコルなら → Packet
• 振る舞いなら → State（第3回参照）
• 関係なら → ER（第3回参照）

XY Chart は本文では扱いませんでしたが、売上推移や計測値のトレンドなど「二軸の定量データ」を描きたいときの定番です。Mermaid でそのまま棒グラフ・折れ線グラフが書けるので、ビジネス資料の表紙グラフを手早く用意したいときに覚えておくと便利です。

「どの図で描くか」の選択肢が増えたことは、そのまま「どう情報を構造化するか」の選択肢が増えたことを意味します。これは記法の話というより、思考の粒度を選ぶ話です。

次回の 第5回 では、Mermaid の図にインタラクティビティを加える技法（click・classDef・icon）と、この一年でもう一つの大きな変化となった AI時代の図解思考——LLM と一緒に図を描くときの実務とコツを扱います。発展編の締めくくりとして、技術と思考の両面をまとめる回です。

参考情報

• Mermaid 公式サイト — 全情報の起点

• Architecture Diagram（v11.1.0+） — サービスとグループによるシステム構成図

• Radar Diagram（v11.6.0+） — 多軸スコアのレーダーチャート

• Treemap Diagram（beta） — 階層構造の面積表現と valueFormat

• Kanban Diagram — columnId[Column Title] と taskId[Task Description] の構文

• Packet Diagram（v11.0.0+） — ビットフィールド表現

• Block Diagram — 自由度の高いブロック構造

• Flowcharts Syntax（30新Shape含む） — @{ shape: ... } 記法と追加シェイプ一覧

• Mermaid Config Schema — look・layout・theme の設定一覧

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

• Mermaid v11 リリースノート（GitHub） — 描画エンジン刷新と ELK レイアウト導入

• Mermaid v11 is out!（Mermaid Chart blog） — v11 全体像のわかりやすい概要

• Expanding the Horizons of Mermaid Flowcharts: Introducing 30 New Shapes! — 30シェイプと @{ shape: ... } 記法の公式アナウンス

• Mermaid Innovation – Introducing New Looks for Mermaid Diagrams — Neo / Hand-Drawn ルックの導入背景

• Mermaid supports Treemap Diagrams now!!! — Treemap の設計意図と valueFormat の例

• Iconify — Architecture Diagram で使える20万超のアイコンライブラリ