図（Mermaid）

仕組み

Mermaid 図。 ```mermaid のフェンスにフローチャート（flowchart/graph、四方向すべて）、シーケンス図（sequenceDiagram）または円グラフ（pie）が書かれていると、読書モード、エクスポートしたファイル、そして図がいちばん多く届くノートに質問の回答で、図として描画されます。描画はノートのテーマ（文字色・紙・アクセント）に従うので、どちらのテーマでも周りの文章になじみます。書式付き編集（既定のモード）でも図は描画されます。図の上にはブロックのバー（コピー・編集・削除）が出ます。編集を押すと下にソースのバーが開きます。開いている間ノートはロックされ、図は入力しながら描き直されます。閉じると適用され（保存もキャンセルもありません）、Ctrl+Z は変更全体を一度で取り消し、欄を空にするとブロックが削除されます。分割モードでは、図をクリックするとカーソルが素のテキストのフェンスへ移動します。テキストエディターではすべて文字のままです。図を見るには Ctrl+E を使ってください。リストの項目の中では、図 (SMILES の構造式、ブロックの数式、[files]、![[ノート]] も同様) は書式付き編集ではテキストのままで、読書モードで描画されます。そこでは項目の記号をファイルに戻す方法がないためです。

サブグラフ（subgraph … end、入れ子も含む）は見出し付きの枠として描かれ、辺は本物のノードから枠の境界を越えて伸びます。サブグラフの id を辺の端点にすることもできます（sub --> X）。作者が指定した色も反映されます: classDef、class、:::クラス、style（塗り、枠線、太さ、破線、文字色）。作り始めるにはノートのバーの挿入 → 図（Mermaid）を使ってください。選んだ種類のひな形がそのまま入ります。メニューにはよく使う六つが直接並び、すべての図…から 33 種すべての選択画面が開きます。用途ごとにまとまっていて、検索（名前でも、図が示す内容でも）と、それぞれの実際に描いたプレビューが付きます。33 種もあると、名前を読むより絵を見るほうが速く決まります。図のフロントマター（先頭行の前にある --- のブロック）も読みます。title は図の上に描かれるタイトルになり（本文の title が優先）、LightNote が知っている config のキーは図に届きます（gitGraph.mainBranchName、gantt.displayMode、そして packet の bitsPerRow、行を左右反転する bitOrder: descending、showBits: false）。知らないキーは無視され、ノートを拒否しません。

シーケンス・エンティティ・クラス・状態

シーケンス図では participant/actor（as 付き）、矢印の各形（->>、-->>、-x、-)）、活性化（+/- と activate/deactivate）、ノート（Note left of/right of/over）、loop/alt/else/opt/par のブロック、そして autonumber が使えます。まだ描画できないもの — ほかの図の種類 — は今までどおり色付きのコードブロックとして表示されます。サブグラフ内の direction と linkStyle は無視されます。 Mermaid v11 のノード記法（A@{ shape: rounded, label: "テキスト" }）を読み取り、v11 の図形カタログを描画します。doc、lin-doc、docs、tag-rect、win-pane、hourglass、bolt、flag、das などで、それぞれの名前が示す記号そのものです。長方形で代用しないのは、書類の代わりに長方形を描くことが別の図になるからです。Mermaid にない名前は行番号付きでコードブロックに戻ります。エッジ ID（A e1@--> B）と e1@{ animate: true } は受け付けたうえで無視します。アニメーションは描画しません。型付き参加者（participant DB@{ "type": "database" }）はライフラインの上に UML の記号を描きます——boundary、control、entity、database、queue、collections ——ここで宣言した "alias" は as と同じ働きをします。

erDiagram も描画されます。各エンティティは属性付きのボックスになり、関連の両端にカーディナリティが表示されます（||--o{、}o--||、|o、|{）。-- は識別関連、.. は非識別関連です。エイリアス p[Person] は、関連が参照する id を変えずにボックスの名前を決めます。subgraph … end もここで使えます。中のエンティティはタイトル付きの枠に入り、サブグラフは入れ子にでき、枠の ID を関係の端にできます（CLIENTE ||--o{ Vendas : faz）——その場合は同名のエンティティではなく枠の境界につながります。

classDiagram も同様です。3 つの区画（名前、属性、メソッド。メソッドの括弧で分かれます）を持つボックス、独立した行の <<interface>>、ボックスになる namespace、そして 6 種類の関連（<|--, *--, o--, -->, ..>, ..|>）に対応します。向きに注意: A <|-- B では三角が A 側に付き、継承するのは B です。引用符のカーディナリティは両端に表示されます（"1" --> "*"）。ジェネリクス List~T~ は List<T> として表示され、メンバーでも同様です。ロリポップインターフェース（bar ()-- foo）は、() がある側の箱の上に円を描き（その側だけ）、関係線はその円に接します。namespace も入れ子にでき、内側の } のあとはクラスが外側の namespace に戻ります。

stateDiagram-v2 は状態機械を描きます。[*] は開始（塗りつぶした円）と終了（環のある円）、state X { … } はボックス、<<fork>>/<<join>> はバー、<<choice>> はひし形になります。複合状態の中の -- は並行リージョンを区切り、破線で示されます。

タイムライン・ジャーニー・象限・ガント

timeline も描画されます。各期間はタイムラインの列になり、その下に出来事が積み上がります。section は時代を色帯でまとめます。複数の出来事は同じ行にコロンで並べる書き方（2004 : Facebook : Google）と、次の行に続ける書き方（: 別の出来事）の両方が使えます。ここでは title・section・direction 以外の行はすべて自由な文字列です。direction TD（縦向きのタイムライン）はまだ描画できず、コードブロックのままになります。

journey（ユーザージャーニー）も描画されます。各タスクはジャーニーの軸の上のボックスになり、1 から 5 の評価が顔を上下に動かします。その顔が描く起伏こそ、この図が見せるためにあるものです。section はフェーズをまとめ、アクターはタスク上の色付きマーカーになり、凡例が左側に出ます。ここでの文法は timeline と違って厳密です（タスク: 評価: アクター, アクター）。名前と評価の組がなければ顔を置く場所がないので、形の崩れた行や 1〜5 の外の評価は行番号付きで図を拒否します。

そして quadrantChart は四象限の平面を描きます。x-axis と y-axis が各軸の両端に名前を付け（--> の右側は省略できます）、quadrant-1 から quadrant-4 が各領域のラベルになり、点は 名前: [x, y] の形で、x と y は 0 から 1 です。番号に注意してください。これは読む順ではなく数学の平面の番号です。quadrant-1 は右上で、そこから反時計回りに進みます。y = 1 は上端です。点の色と半径は直接（P: [0.5, 0.5] radius: 10, color: #109060）でも、クラス（P:::クラス と classDef）でも指定でき、直接指定がクラスに勝ちます。0〜1 の外の座標は切り詰めずに行番号付きで図を拒否します。座標は平面上の位置なので、切り詰めると書いていない象限に点が入ってしまうからです。

gantt は工程表を描きます。dateFormat は書き込む日付の書式（既定は YYYY-MM-DD）、axisFormat は軸ラベルの書式（%m/%d）を指定し、section がタスクを帯にまとめます。各タスクは テキスト : 印, id, 開始, 終了 の形です。印の done・active・crit・milestone は先頭に置き、組み合わせられます。開始は日付か after 別のid、終了は日付・期間（5d、2w、3h、45m）・until 別のid のいずれかです。項目が一つだけなら、前のタスクが終わった時点から始まります。

after はノートの後ろで宣言されたタスクも指せます。一方、どこにも存在しない id や循環する依存関係は、バーを今日の日付に置くのではなく、行を示して図を拒否します。excludes weekends（excludes monday や日付も可）は除外した日の分だけ各タスクの終了を後ろにずらすので、バーの長さが変わります。includes 2026-03-07 は週末より優先され、その土曜は稼働日だと伝えます。マイルストーンはひし形で表示され、todayMarker off は今日の線を消します。同じ行に複数のタスクを積む displayMode compact も描画します。ここでは、タスクが占める範囲（ラベルを含む）が既存のものに触れないときだけ同じ行を共有します。vert マーカー（開始 : vert, v1, 20:15, 0m）は瞬間を図全体を貫く垂直線として描き、行を占有せず、ラベルは軸の下に出ます。dateFormat X（または x）は日付を秒（またはミリ秒）単位の Unix 時間として読み、軸では %s/%Q がそれを書き戻します。Mermaid が知らない tickInterval（1decade）は本家と同じく黙って無視され、軸は自動に戻ります。

マインドマップ・要求・Git・C4

mindmap では階層をインデントが決めます。項目の深さは、その本文が始まる桁そのもので、括弧も矢印も使いません（タブは次の 4 の区切りまでと数えます。エディターと同じ勘定です）。最初の項目がルートで、その桁にもう一つ項目が来れば二つ目のルートになってしまうため、そこで図は行番号付きで拒否されます。各項目は形を宣言できます —— [四角]、(角丸)、((円))、{{六角形}}、))爆発((、)雲(。区切りがなければ角丸になります。::icon(...) と :::クラス は認識したうえで無視します（アイコン用フォントを同梱しておらず、クラスはここに存在しない外部 CSS を指すからです）。描画は左右の二方向で、ルートを中央に置いて枝を振り分け、枝ごとに色を持ち、その色は子孫が受け継ぎます。枝は深くなるほど細くなります。

これは木であって、mermaid のような力学シミュレーションではありません。マインドマップでは階層こそが中身なので、位置から読み取れる必要があります。しかも図はテーマを変えるたびに描き直されるため、ランダムな初期位置から収束する配置では地図全体が毎回組み替わってしまいます。

treeView（treeView-beta）はプロジェクトのフォルダー木を描き、二つの書き方を受け付けます。字下げ（自分で打つ場合）と、tree コマンドそのものの文字（├──、│、└──）です。後者があるからこそ、端末の出力をそのまま貼り付けられます——そこでは字下げだけでは足りず、│ と空白は同じ列を占めるのに、枝が続くと言えるのは前者だけだからです。末尾のスラッシュはフォルダーを示し（src/）、空白を含む名前は引用符で囲み、## テキスト は行末にコメントを付け、:::highlight は名前を強調します。icon(...) はマインドマップの ::icon() と同じく、認識したうえで無視します。アイコンパックは JavaScript 経由で Iconify から来ており、Mermaid 自身も既定では描きません。

ishikawa（ishikawa-beta）は原因分析の特性要因図（魚の骨）を描きます。最初の項目が「結果」（右端の頭）で、次の階層がカテゴリ（大骨）、その内側二つが要因と子要因です。階層は三つまでで、四つ目は行番号を示して拒否します——Mermaid に存在しないからです。大骨は背骨の上下に交互に伸び、隣り合うカテゴリの文字が重ならないようになっています。要因を書いた順は、どちらの側でも上から下へ読めます。

venn（venn-beta）は重なり合う集合を描きます。set A["望ましい"] で一つ宣言し、union A,B["作れる"] で共通部分に名前を付け（合成は交わる集合の名で呼びます）、その直下の text A1["React"] でその領域に項目を入れます。集合は三つまでで、四つ目は行番号を示して拒否します——円四つではすべての領域を作れる配置がなく、「ほぼ正しい」図は宣言された領域を隠してしまうからです。ラベルの後ろの :数字（set A["Alpha"]:20）は円の大きさを変え（面積が数字に従います）、交わりの大きさは変えません。交わりまで比例させるのは別の図（オイラー図）で、数値最適化が必要になります。style A fill:#ff6b6b は集合を塗り、カンマ付き（style A,B color:#333）ならその集合たちの合成にかかります。

cynefin（cynefin-beta）は意思決定を分類するスノーデンの枠を描きます。五つの領域は名前が固定で——complex、complicated、chaotic、clear、confusion——位置も固定（四つの象限と、真ん中の confusion）です。選ぶのはそれぞれの中身だけです。項目は一行に一つ、引用符で囲み、complex --> complicated : "パターンが見えた" で領域間の遷移を描きます。五つ以外の名前は行番号を示し、ある名前を並べて拒否します。clear と chaotic の境界は波打つ線で出ます。モデルではそこが崖だからで、形がそれを語ります——ここでは波は常に同じで、開くたびに図が変わることはありません。

swimlane（swimlane-beta）は、担当ごとのレーンで分けた工程を描きます。文法はフローチャートと同じ（形も矢印もラベルも classDef も）で、subgraph が箱ではなくレーンになります。すべてのノードはどれかのレーンに入る必要があり——外にあるノードは、誰の作業か言えないので拒否します——レーンの入れ子も拒否します。LR ではレーンが行で流れは右へ、TB では列で流れは下へ進みます。流れの上の位置は各作業への最長経路で決まり、帯は持ち主のものです。作業は、そのほうがコンパクトになる場合でも決して自分のレーンを出ません。

agentflow（agentflow-beta）は AI エージェントの流れを描きます。中身はフローチャートの別の語彙です：矢印は同じで、flow id["名前"] … end が subgraph の役割を果たし（入れ子も可）、global … end は全エージェントが参照するものを置き、connector id["名前"] は外部システムを宣言します。本当に違うのは形で、各ステップの役割を表します——@{ shape: input }、task、tool（ツール呼び出し）、decision、refdoc（参照文書）、action（最終の行動）。文書は -.- で、矢印なしでつなぎます。参照するだけで、流れのステップではないからです。エージェントを文で説明するキー（instruction、params、returns、connectorRef、protocol、endpoint）は読み取ったうえで描画では無視します。これらの形名はここだけで有効で、flowchart では拒否します——あちらでは Mermaid にもないからです。

usecase（usecase-beta）は UML のユースケース図を描きます。actor で宣言したものが人型になり、それ以外はすべてユースケースとして楕円で描かれます——この区別こそがこの図の目的です。ユースケースは Id("ラベル")、Id[ラベル]、Id だけ、引用符の文字列だけ、のどれでも書けます。systemBoundary "名前" … end がシステム境界で、note for X "テキスト" が注釈をつけます。関係は UML どおりで、--> が関連、--|> が汎化（白抜き三角が一般側）、A ..> : include B（対象はコロンのあと）が点線の「include」で、extend も同じです。アクターを説明するだけのキー（type、business、icon）は読み取って無視し、<<ステレオタイプ>> はラベルに入ります。json ノードはまだ描けず、コードブロックのままです。複数行に渡るデータの木だからで、そこでは JSON がテキストとしてそのまま読めます。

wardley（wardley-beta）は Wardley マップを描きます。縦軸は利用者からの見えやすさ（上が利用者に見えるもの）、横軸は Genesis から Commodity までの進化度です。

組の順番に注意：component お茶 [0.63, 0.81] は [見えやすさ, 進化度] で、最初の数が縦軸です。逆に読むと地図はそのまま描けてしまい、別の戦略を語り出します。anchor は上の利用者、A -> B は連鎖（名前に空白を含められ、引用符は任意）、A +> B はフロー（太め。+<> は双方向、+'文字'> はラベル付き）、evolve ケトル 0.62 は進むべき先までの破線の矢印です。ほかに evolution（軸の段階名）、size、(build)/(buy)/(outsource)/(market)、(inertia)（抵抗のバー）、label [dx, dy]、pipeline X { … }、note、accelerator/deaccelerator、番号付きの annotation と annotations の凡例が使えます。

eventmodeling はイベントモデリングを描きます。三つのレーンの時間軸で、上が画面、真ん中がコマンド（とリードモデル）、下がイベントです。各行は tf 02 cmd AddItem の形で、数字が時点（列）、真ん中の語が種類でレーンを決めます——ui、cmd/command、pcr/processor、rmo/readmodel、view、evt/event（長い形も同じ）。レーンは宣言しません。それがこの手法そのものだからです。rf（resetframe）は新しいスライスを開き、破線の区切りが入ります——物語がやり直す場所です。スキーマは中括弧（{ description: string }）か、data … { … } ブロックへの参照（[[Data]]）で与えます。ブロックはあとに書いても構いません。->> 02 ->> 03 はその枠を支える時点を番号でつなぎます。

railroad（railroad-ebnf-beta、-abnf-beta、-peg-beta、railroad-beta）は文法を線路図として描きます。各規則が指でたどれる経路になり、書けるものがそのまま辿れるものになります。規則は 名前 = 式 ;（PEG は 名前 <- … ;）で、複数行にまたがっても構いません——閉じるのは ; です。引用符の文字列は終端記号（カプセル形）、裸の名前は別の規則（四角）です。|（または /）が選択、? が任意、+ が一回以上、* が零回以上、( )・[ ]・{ } がグループ・任意・繰り返しです。ABNF は繰り返しを前に置き（1*( ALPHA / "-" )、*DIGIT）、PEG は述語 !x・&x を受け付けます（入力を消費しないのでラベルに入ります）。railroad-beta は関数記法（sequence(choice(terminal("+"), …))）です。四つとも同じ絵になり、上の迴回が任意、下のループ（戻る向きの矢印付き）が繰り返しです。

requirementDiagram は要求と要素を区画付きのボックスとして描きます。宣言した種類（requirement、functionalRequirement、performanceRequirement、interfaceRequirement、physicalRequirement、designConstraint）は名前の上にギュメで表示され、id・text・risk・verifymethod の各項目が行になります（element では type と docref）。関係（satisfies、traces、derives、verifies、refines、copies、contains）は a - satisfies -> b または反転した b <- satisfies - a と書き、反転形では先に書いた名前が宛先です。実線になるのは contains だけで、記号は含む側に付きます。ほかは破線で、矢印は宛先側です。空白を含む名前は引用符で囲みます。

gitGraph はリポジトリの履歴を描きます。commit ごとに時間が進み、branch 名前 は新しいレーンを開いてそのままそこで作業を続け（git switch -c と同じ）、checkout で別のレーンに戻り、merge が二つを合流させます。属性はコロンで書きます：commit id: "テキスト" tag: "v1" type: HIGHLIGHT（REVERSE も可）、branch 名前 order: 2 はレーンの並び順を変えます。cherry-pick id: "…" には実在するコミットの id が必要です。形が種類を表します——通常のコミットは塗りつぶした丸、強調は四角、取り消しは X 付きの円、マージは二重の輪、cherry-pick は切れ目のある円——。テーマによってはパレットの二色が似て見えるため、形だけが両者を分けるからです。LR:（既定）、TB:、BT: で時間軸の向きが変わります。存在しないブランチへの checkout/merge は、頼んでいないレーンを勝手に作らず、行を示して図を描くのをやめます。

C4 系（C4Context、C4Container、C4Component、C4Dynamic、C4Deployment）も描画します。ここではすべてがマクロで、構文に矢印は一つもありません。各要素は、型をギュメで囲んだ行、太字の名前、その下の説明という箱になります：Person(alias, "名前", "説明")、System、Container、Component、および Db・Queue・_Ext の各種です。Container と Component では3 番目の引数が技術で（Container(app, "App", "C++/Qt", "役割")）、ほかでは 3 番目がそのまま説明になります。境界（Boundary、Enterprise_Boundary、System_Boundary、Container_Boundary、C4Deployment の Node）は波かっこを開き、入れ子も含めて見出し付きの枠になります。つながりは Rel(a, b, "ラベル", "技術") で、BiRel は両端に矢印を付け、Rel_Back は逆向きを指します。C4Dynamic は関係を出現順に番号付けします。位置のヒント（Rel_U、Rel_D、Rel_L、Rel_R）と Update…Style は受け付けたうえで無視します——配置はほかの図と同じレイアウトが決め、色はノートのテーマから来るからです。宣言していない別名を指す関係は、書いていない箱を勝手に作らず、行を示して図を描くのをやめます。

ボード・グラフ・パケット

kanban では字下げが構文で、二段階あります。外側がレーン、内側がカードです（id[ラベル]、あるいは本文だけ）。カードのあとの @{ ticket: LN-9, assigned: 'ana', priority: 'High' } はカードの本文には入りません。チケットと担当者は専用のフッターに置かれ、優先度（Very High、High、Low、Very Low）は左端の帯の色になり、暖色から寒色へ並びます。レーンはすべて同じ高さで終わり、カードのないレーンもそのまま残ります——空の列を示すのがそれだからです。これはノートの中で流れを説明するための描かれたボードです。カードをドラッグして実際に作業するボードは、アプリ本体のタスクパネルのほうです。

xychart（xychart-beta）は 2 本の軸の上に棒と折れ線を描きます。x-axis "見出し" [1月, 2月, 3月] でカテゴリを与え（空白やカンマを含む名前は引用符で囲みます）、y-axis "見出し" 0 --> 100 で目盛りの範囲を決め、bar [10, 40, 90] や line [20, 30, 80] がそれぞれ系列を 1 つ足します。値はカテゴリごとに 1 つ、宣言した順に対応します。値の数が合わない系列は、行を示して図を描かないことで知らせます。棒が別のカテゴリにずれ、グラフが別のことを主張し始めるからです。y-axis がなければ目盛りはデータから決まり、データが下に出ない限りゼロから始まります。最小値から始めると棒どうしの差が誇張されますが、それは誰も選んでいません。範囲を宣言した場合、範囲外の値は枠からはみ出さずに拒否されます。

x-axis は連続した範囲（0 --> 100）も受け付け、書かなければカテゴリは番号になります。棒の系列が 2 つあるときは横に並べて描きます。mermaid のように重ねると後ろの系列が消えてしまうからです。xychart-beta horizontal はまだ描けず、コードブロックのまま残ります。縦向きに描くと、軸が入れ替わったグラフを渡すことになるからです。系列には名前を付けられます（bar "公開" [10, 40]、line "非公開" [20, 30]）。名前はプロットの上の凡例になり、塗りつぶしの棒・点付きの線という形で示されます——色だけでは区別できないからです。線の系列では値にラベルを付けられ（[540 "PaLM", 65]）、点の上に描かれます。棒では Mermaid と同じく無視されます。

radar（radar-beta）は、中心から伸びる軸の上に 1 本以上の曲線のプロファイルを描きます。axis a["ラベル"], b, c で軸を宣言し（この行は繰り返せます）、curve x["名前"]{80, 60, 90} で軸ごとに値を 1 つ与えます。値は軸を宣言した順に対応します。名前付きの書き方（{a: 80, c: 90, b: 60}）も使えます。向きに注意: 最初の軸は上を向き、回りは時計回りです。max と min は目盛りの範囲を決め（max がなければ読み取った最大値になります）、範囲外の値は切り詰めずに、行を示して図を描かないことで知らせます。ticks は輪の数を変え、graticule circle は輪を円にし、showLegend false は凡例を消します。軸の数と値の数が合わない曲線も同様に拒否されます。それは不完全な図ではなく、別の図になってしまうからです。

packet（packet-beta）はパケットのビット配置を描きます。各フィールドは 0-15: "ラベル" と書き、範囲は両端を含みます。0-15 は 16 ビットです。1 ビットだけなら 4: "ラベル"、相対形式の +16: "ラベル" は次の 16 ビットを取るので、途中にフィールドを挿入しても数え直す必要がありません。フィールドは隙間なく連続していなければなりません。隙間や重なりは、行を示して図を描かないことで知らせます。どちらも後続すべてを黙ってずらしてしまうからです。1 行は 32 ビットで、行をまたぐフィールドは両方の行に描かれ、ラベルは広いほうに入ります。格子の上の数字は各フィールドの開始位置と、各行の最後のビットを示します。

グリッド・面積・アーキテクチャ・フロー・ZenUML

block（block-beta）は箱のグリッドを描きます。位置は書いた順で決まります。columns 3 で列数を決め（書かない場合はすべて 1 行に並びます）、各箱はフローチャートと同じ形（a["ラベル"]、b(("円"))、c{"ひし形"}）を受け付け、a:2 は箱に 2 列分を占めさせ、space（または space:2）は空きを作ります。block:id … end はグリッドの中にグリッドを入れ子にし、独自の columns を持ち、周りが枠になります。矢印はフローチャートのもの（a --> b、ラベル付きは a -- "文字" --> b）ですが、ここでは宣言済みのブロックを参照するだけです。存在しない名前への矢印は、書いていないセルに箱を作らず、行を示して図を描かないことで知らせます。列の間隔は矢印のラベルが収まるまで広がり、隣の箱に触れません。ブロック矢印（a<["往路"]>(right)）は矢印の形をした箱です。向きは括弧の中に書き（right、left、up、down、水平両方の x、垂直両方の y）、組み合わせられます（(x, down)）。存在しない向きは、適当な矢印になるのではなく行番号を示して図を拒否します。

treemap（treemap-beta）は面積の地図を描きます。各長方形の面積は値に比例し、字下げで入れ子になり、深さに制限はありません。葉は値を宣言し（"名前": 12）、セクションは何も宣言しません。その値は子の合計で、独自の合計を許すと自分の中身について嘘をつく長方形ができてしまうため、行を示して図を描かないことで知らせます。空白やコロンを含む名前は引用符で囲みます。classDef と :::クラス で色が付きます。配置は squarified で、長方形を正方形に近く保ちます。いつも同じ軸で切ると目で比べられない細長い帯になり、面積を比べることがこの図の唯一の役目だからです。ラベルと値は長方形の中に丸ごと収まるときだけ表示されます。縁で切れていては何も伝わらないからです。

architecture（architecture-beta）はサービスとその間の接続を描きます。service api(server)[API] で構成要素を宣言し、group kumo(cloud)[クラウド] で境界を開き、in kumo を付けるとサービスがその中に入り（グループは入れ子にできます）、junction j は接続を折り曲げる角を作ります。

位置を決めるのは接続の「辺」です。 a:R -- L:b は a の右辺を b の左辺に付けるので、b は a の右に置かれます。L、R、T、B が使え、矢じりは < や > のある側に出ます（-->、<-->、矢じりなしの --）。端に付けた {group} は、線を中の箱ではなくグループの境界へ向けます。アイコンは Mermaid が内蔵する 5 つだけです — cloud、database、disk、internet、server — 。それ以外の名前は、行を示し、使える名前を挙げたうえで図を描きません。残りは（logos:aws-lambda のような）Iconify のもので、ページを公開する側が JavaScript でパックを登録した場所でしか表示されず、GitHub でさえ登録していません。ここで受け入れれば、ほかのどこでも再現しない絵を渡すことになります。align row a b c（または align column）は指定したメンバーを同じ行（または同じ列）に並べます。存在しない名前は、理由を告げずに配置をそのままにするのではなく、行番号を示して図を拒否します。

sankey（sankey-beta）はフロー図を描き、帯の太さがそのまま値になります。本文に矢印は一つもなく、3 列の CSV（始点,終点,値）で 1 行が 1 本のつながりです。同じ名前を両端に書くことで流れがつながります。カンマを含むラベルは引用符で囲み、その中の引用符は二重に書きます（"固定 ""費用"""）。同じ始点と終点の組を繰り返すと合算されます。ノードのバーの高さは、入ってくる量と出ていく量の大きいほうです。受け取るより多く配るノードで、出ていく帯が枠からはみ出さないためです。列は各ノードまでの最長経路から決まり、出口のないノードは最後の列に置かれます。0 以下の値、自分自身へのつながり、循環は、行を示して図を拒否します。循環には最長経路が存在せず、描くためにつながりを切れば、書いていない流れを見せることになるからです。ここに title はありません。本文は純粋な CSV で、受け入れれば LightNote では描けても Mermaid では構文エラーになります。

zenuml は同じ絵のための別の書き方——シーケンス図——で、矢印ではなくコードのように書きます。同期呼び出しは宛先だけを書き（Store.register(item)）、送り手はそれを囲むブロックです。Store.register() { Stock.reserve() } の中で Stock を呼ぶのは Store です。いちばん外側で呼ぶのはスターターで、@Starter(Ana) が名前を与えます。指定しなければ棒人間の User が使われ、呼び出しが必要とするときだけ現れます。非同期メッセージは A->B: テキスト（開いた矢先、誰も待たない）で、A->B.method() は送り手を明示した同期呼び出しです。{} が入れ子になり、return x は囲んでいる呼び出しの呼び手へ戻り（途中の if は関係ありません）、x = A.m() は同じ応答の別の書き方、new A(args) は生成、// コメント は次のメッセージの上のノートになります。ブロックは if/else if/else、while/for/forEach/loop、opt、par、try/catch/finally です。} else { は新しい枠を開かず、同じ枠を仕切りで続けます。@Actor は棒人間を描き、ほかの注釈子（@Database、@Boundary など）はラベルのステレオタイプ（«Database» Stock）になります。ここではそれらのアイコンを描かないからで、名前はそのまま残ります。空白を含む名前は引用符で囲みます。

このブロックの行き先に注意してください。Mermaid では zenuml はページが JavaScript で登録しなければならない外部の図で、GitHub はそれをしません。ここで描かれる同じノートが、あちらではコードブロックのまま表示されます。

そして図を読み取れなかったときは、ブロックのすぐ下に理由と行番号が表示されます。まだ描画していない種類では警告は出ません。書いた内容に誤りはないからです。