無料 · 登録不要 · .mmd ファイル対応

Mermaid フローチャートエディタ

フローチャートは処理の流れを示します。どんな手順があり、どこで分岐し、その分岐がどこで合流するか。判断の順序こそが要点であるとき——デプロイのパイプライン、リクエストの経路、承認フロー——に向いています。誰がいつ誰と通信するかが要点なら、シーケンス図のほうが適しています。

エディタで開く →ガイドを読む

失敗経路が 2 つある CI パイプライン

このサイトのフローチャートはたいていこの形から始まります。一本の正常系に、そこから外れていく判断ノードが付く形です。最後のノードの引用符に注目してください。ラベル内の括弧は引用符で囲む必要があり、これがフローチャートで最も多いエラーです。

flowchart TD
    Push[main へプッシュ] --> Lint[静的解析と型チェック]
    Lint --> Test{テストは通ったか}
    Test -->|いいえ| Fail[作成者に通知]
    Test -->|はい| Build[コンテナイメージを構築]
    Build --> Scan{脆弱性スキャンは問題なしか}
    Scan -->|いいえ| Block["リリースを停止 (要確認)"]
    Scan -->|はい| Deploy[本番へデプロイ]
    Deploy --> Smoke[スモークテストを実行]
    Smoke --> Done[リリース完了]

エディタで開く

実例で理解する

1. 最小限のフローチャート

ノード 2 つと矢印 1 本。`TD` は上から下、`LR` は左から右で、縦より横に長い図はたいてい `LR` のほうが読みやすくなります。

flowchart TD
    受付[リクエスト受信] --> 応答[レスポンス送信]

エディタで開く

2. ラベル付きの分岐

波括弧はひし形になります。縦棒に挟まれた文字が付くのはノードではなく辺です。この違いは後のエラーの節で効いてきます。

flowchart TD
    開始[リクエスト受信] --> 認証{トークンは有効か}
    認証 -->|はい| 処理[ハンドラを実行]
    認証 -->|いいえ| 拒否[401 を返す]
    処理 --> 完了[200 を返す]

エディタで開く

3. 形に意味を持たせる

形はフローチャートに情報を足すいちばん安上がりな方法です。角丸は開始と終了、ひし形は判断、円柱はデータストアを表します。

flowchart LR
    開始([ジョブ起動]) --> 読込[(Postgres から読み込み)]
    読込 --> 判定{対象データはあるか}
    判定 -->|なし| 終了([正常終了])
    判定 -->|あり| 変換[/データを変換/]
    変換 --> 書込[(S3 へ書き出し)]
    書込 --> 終了

エディタで開く

4. サブグラフで担当ごとにまとめる

サブグラフは関連するノードを枠で囲みます。最も役に立つのは工程ではなく担当でまとめることです。どのチームやどのサービスがどこを持つのかが分かれば、受け渡しの箇所が見えてきます。

flowchart TD
    subgraph client [ブラウザ]
        UI[フォーム送信]
    end
    subgraph api [注文サービス]
        検証[入力を検証]
        保存[注文を保存]
    end
    subgraph async [バックグラウンド処理]
        メール[確認メール送信]
        請求[請求書を生成]
    end
    UI --> 検証
    検証 --> 保存
    保存 --> メール
    保存 --> 請求

エディタで開く

5. 上限のあるリトライループ

フローチャートは循環をうまく扱えます。リトライループはその真価が出るところで、そのループに本当に出口があるのかが図で一目で分かります。

flowchart TD
    送信[Webhook を送信] --> 結果{2xx が返ったか}
    結果 -->|はい| 完了[配信済みとして記録]
    結果 -->|いいえ| 回数{試行回数は 5 未満か}
    回数 -->|はい| 待機[指数バックオフ]
    待機 --> 送信
    回数 -->|いいえ| 退避[デッドレターキューへ]

エディタで開く

フローチャート構文早見表

ここに挙げるものはすべてフローチャート専用です。とくに矢印の書き方は他の図には持ち込めません。シーケンス図の `->>` はここでは構文エラーになります。

構文	意味
flowchart TD	上から下。TB も同じ。処理を読む標準的な向き。
flowchart LR	左から右。RL もあり。横に広く浅い流れ向き。
A[文字]	長方形——ふつうの手順。
A(文字)	角丸長方形。
A([文字])	スタジアム形——慣例として開始か終了。
A[(文字)]	円柱——データストア。
A{文字}	ひし形——判断。
A[/文字/]	平行四辺形——入力または出力。
A --> B	矢印。
A --- B	矢じりのない線。
A -.-> B	点線の矢印——慣例として非同期または任意。
A ==> B	太い矢印——慣例として主経路。
A -->\|文字\| B	ラベル付きの辺。括弧を含むなら引用符で囲む。
A["文字 (括弧つき)"]	引用符付きラベル——括弧や引用符など、形の構文と読まれる文字に必要。
subgraph 名前 [表題] ... end	ノードを枠でまとめる。`end` で閉じる。
%% コメント	コメント行。描画されない。

実際にフローチャートを壊す 6 つのエラー

いずれもこのサイトが実際に使っているレンダラ (Mermaid 11.12.2) で再現したものです。壊れているほうをエディタに貼れば、書いてあるとおりのエラーが出ます。直したほうは描画されます。Mermaid のエラーは末尾を読むのが最短です。`got` の後ろに、解析器がつまずいたトークンが出ます。

表示されるもの

Parse error、末尾が: got 'PS'

原因

角括弧のラベルの中に開き丸括弧があります。丸括弧は形の構文で、`A(文字)` は角丸ノードを意味するため、角括弧内の裸の括弧は形の始まりと読まれます。

対処

ラベル全体を二重引用符で囲みます。引用符の中はすべて文字として扱われます。

誤り

flowchart TD
    A[リトライ (最大 5 回)] --> B[完了]

修正後

flowchart TD
    A["リトライ (最大 5 回)"] --> B[完了]

表示されるもの

Parse error、末尾が: got 'STR'

原因

ラベルの途中に二重引用符があります。解析器はそれを文字列の始まりとみなし、対になる引用符を期待した位置で閉じ括弧に出くわします。

対処

二重引用符で囲んだ中では単引用符を使うか、文字を `#quot;` と書きます。

誤り

flowchart TD
    A[状態は "保留"] --> B[完了]

修正後

flowchart TD
    A["状態は '保留'"] --> B[完了]

表示されるもの

Parse error、末尾が: got 'end'

原因

`end` をノード ID に使っています。小文字の `end` はサブグラフを閉じるため、ノードがあるべき位置でブロックの終端が現れたことになります。最後のノードの名前として `end` は自然なので、よく起こります。

対処

大文字にするか、ノードに ID を付けてその語をラベルに入れます。

誤り

flowchart TD
    Start[開始] --> end

修正後

flowchart TD
    Start[開始] --> End[終了]

表示されるもの

ノードに名前を付けた行で Parse error

原因

ノード ID に空白が入っています。ID は矢印の手前のトークンで、空白がそれを打ち切るため、置き場のない語がもう 1 つ残ります。

対処

ID は 1 語にし、読ませたい文字はラベルへ入れます。

誤り

flowchart TD
    auth service --> user db

修正後

flowchart TD
    auth[認証サービス] --> db[(ユーザー DB)]

表示されるもの

縦棒に挟まれた辺ラベルで Parse error

原因

辺ラベルの中に括弧があります。`|…|` にもノードラベルと同じ制約があり、括弧はそこでも構文であって文字ではありません。

対処

辺ラベルも引用符で囲みます。

誤り

flowchart TD
    A -->|はい (常に)| B

修正後

flowchart TD
    A -->|"はい (常に)"| B

表示されるもの

Lexical error on line 1. Unrecognized text.

原因

方向指定が不正です。フローチャートが受け付けるのは TB、TD、BT、LR、RL だけで、それ以外はノードを読む前の字句解析で失敗します。だからエラーは 1 行目を指し、実際の書き間違いの場所を指しません。

対処

5 つのどれかを使います。TD と LR でほぼ足ります。

誤り

flowchart TOPDOWN
    A --> B

修正後

flowchart TD
    A --> B

描画についての覚え書き

いずれもドキュメントからの引き写しではなく、このサイトが使う Mermaid 11.12.2 で実測したものです。フローチャートが玩具でなくなったときに効いてくる挙動です。

日本語のラベルは図をむしろ小さくする

直感に反しますが、実測するとそうなります。全角文字の表示幅は半角のおよそ 2 倍ですが、同じ意味を表すのに必要な文字数はおおむね 3 分の 1 程度です。`A[Payment received] --> B[Ship the order]` の viewBox は幅 204 ピクセル、意味の等しい `A[支払い受領済み] --> B[商品を発送]` は 189 ピクセルでした。折り返しが起きるピクセル幅は同じなので、日本語ラベルは 1 行により多くの意味を収められます。英語の図を訳した場合、体裁のために入れていた改行はたいてい取り除けます。

高さはノードあたり約 105 ピクセル増え、幅はほぼ変わらない

上から下のフローチャートで、ノード 3 つのときの viewBox はおよそ 122×382。40 個では 131×4230 になります。幅は 9 ピクセルしか増えていないのに、高さは 11 倍です。長いフローチャートはどの画面にも収まらない細長い帯になります。プレビューの中央寄せボタンはそのためにあります。縦に伸びすぎたときは `flowchart LR` に変えるだけで縦横比が半分近くになることがよくあります。

ラベルは HTML なので、以前は PNG 書き出しが壊れていた

フローチャートのラベルは SVG の `<foreignObject>` の中に本物の HTML として描かれます。ラベル内で `<br>` や簡単な Markdown が使えるのはそのためです。同時にブラウザはその SVG を canvas に描くことを拒むため、このサイトの PNG 書き出しは長らく黙って SVG ファイルを返していました。現在は書き出し時に SVG テキストのラベルで描き直すので PNG が正しく出ます。代償として、書き出した PNG の文字組みは画面とごくわずかに異なります。

テーマは色を変えるだけで、レイアウトは変えない

同じフローチャートを明るいテーマと暗いテーマで描画しても viewBox は完全に一致します。テーマの切り替えで図が組み直されたり、ラベルが枠からはみ出したりすることはありません。暗いテーマで変に見えるものは、明るいテーマでも同じく変です。

書き出しの寸法は画面ではなく viewBox から決まる

Mermaid は `width="100%"` を出力し、高さ属性を持ちません。画面上の大きさはコンテナ次第です。書き出しは viewBox を読み、その 2〜3 倍で描画するため、縦長のフローチャートの PNG は見ていたものよりずっと大きくなります。ズーム倍率は書き出しに影響しません。

別の図が向いている場合

図の主眼が誰が誰に何を送るかで、分岐よりも時間順のほうが重要なら、シーケンス図のほうが分かりやすく、規模が大きくなっても分かりやすいままです。6 つの関係者をノード名として書き込んだフローチャートは、まだそれを認めていないシーケンス図です。

手順ではなく、あるものが取りうる状態を説明しているなら状態遷移図を使います。見分け方は簡単で、ノードのラベルが「注文が保留中」「注文が発送済み」のような状態を表す語なら状態機械、「入力を検証する」「メールを送る」のような動作ならフローチャートです。

そしてノードが 40 を超えたあたりからは、正直なところどの図でも救えません。入口を 1 つ共有する複数の図に分けるか、説明しようとしているものが 1 枚の絵では理解できないほど複雑だと受け入れることです。それ自体が有用な情報です。

他の図の種類

執筆 Dominik Malsch · 最終更新: 2026年9月8日

エディタを開く →