Mermaid.js フローチャート構文ガイド

フローチャートとは何ですか?

A フローチャートフローチャートは、ステップバイステップの運用ワークフロー、アルゴリズム的手順、または順次的なビジネス論理を可視化する基盤となる行動マップです。システムのアクションを明確な幾何学的形状として表現し、制御フローを方向性を持つ矢印で示すことで、ソフトウェアエンジニアやシステムアーキテクトが条件付き実行パスを追跡し、単一障害ポイントを特定し、実際のバックエンドコードを書く前にシステム論理ループを分析しやすくなります。

With Mermaid.jsMermaid.js を使うと、ボックスを何時間もドラッグしたり、グリッド線を細かく管理したり、パディング変数を再計算したりする必要がありません。レイアウトエンジンは、あなたの原始的な宣言型スクリプトからノードの座標を動的に計算するため、システムの根本的な論理に完全に集中できます。

コア構文ガイド:要素と構造

Mermaidで洗練され、非常にスキャンしやすいフローチャートを設計するには、キャンバスの方向インジケータ、幾何学的ノードの囲み、リンク配線変数、構造的サブグラフをマスターする必要があります。

1. キャンバスの方向を設定する

フローチャートの方向性は、1行目に適用されるキーワードペアによって直接決定されます。graphまたはflowchartラッパーに適用されます。4つの主要な方向キーを使って、レイアウトの視覚的スケーリング方向を制御できます:

  • flowchart TD(上から下へ/垂直方向)
  • flowchart BU(下から上へ方向)
  • flowchart LR(左から右へ/水平方向)
  • flowchart RL(右から左へ方向)

2. ノード幾何学(形状)のカスタマイズ

デフォルトでは、単純なID宣言は鋭い長方形ボックスとして描画されます。図のスキャンを容易にするために、Mermaidの特別な囲み記号を使用して、異なるワークフローステップに即座に視覚的文脈を注入してください。すべての定義ブロックは、正しく解析されるために、方向性レイアウトトークンで始まる必要があります:

  • ラウンドエッジ: id(テキスト) — 一般的なプロセスステップを表します。
  • スタジアム/カプセル形状: id([テキスト]) — 開始および停止の境界マイルストーンを示す標準的なマークです。
  • サブルーチン/事前に定義されたプロセス: id[[テキスト]] — カプセル化されたシステムルーチンまたは外部クラススクリプトを表します。
  • 円筒/データベース: id[(テキスト)] — データベースの永続化、キャッシュ、またはデータウェアハウスを表します。
  • 菱形/決定ダイアモンド: id{テキスト} — 条件付きスイッチ、if/elseの分岐、または評価ポイントを表します。
  • 平行四辺形: id[/テキスト/] または id[テキスト] — 明示的なデータ入出力(I/O)を表すために歪んだ境界を描画します。
flowchart TD
    start_node([実行開始])
    query_db[(PostgreSQL インスタンス)]
    validate_check{承認済みですか?}

3. リンク配線ルールとインラインラベル

接続線を調整することで、異なる構造的関係や通信スタイルを表現できます。チャートを整理するために、説明的なラベルをリンクパス上に直接挿入してください:

flowchart TD
    %% 標準の接続矢印とテキストラベル
    A --> |"JSONペイロード"| B

    %% 点線/非同期ラインとテキストラベル
    B -.-> |"非同期イベント"| C

    %% 太くて太字のラインとテキストラベル
    C ==> |"重要な書き込み"| D

4. サブグラフによるモジュール化された分離

明確なネットワーク境界を確立したり、マイクロサービスをグループ化したり、チームの責任を分離したりするため、構造的なサブグラフラッパー内に要素をグループ化します。サブグラフは内部IDとオプションの表示タイトルを指定して定義し、endタグ:

flowchart TD
    subgraph auth_sub["セキュリティ境界"]
        gateway[APIゲートウェイ] --> auth_worker(トークン検証者)
    end

クリーンなフローチャートのためのベストプラクティス

  • レイアウトを水平方向に分離する: 長く、複数ステップにわたるエンジニアリングパイプラインの場合、flowchart LR 方向を選択する。これは、長く垂直方向に配置されたレイアウトよりも、標準のワイドスクリーン・ランドスケープモニタではるかにスケーラブルでクリーンな表示が可能になる。
  • 複雑なループを分離する: ワークフローに重い繰り返しループが含まれる場合、逆方向の接続を明確にラベル付けする(例:retry --> |"再試行リセット"| start)これにより、読者がループを標準的な前進パスと混同するのを防ぐことができる。
  • グラフタイプの混在を避ける: 現代的なflowchart キーワードを、レガシーなgraph フラグよりも使用する。flowchartエンジンは、高度な矢印の組み合わせとクリーンなパスルーティングをサポートする、更新されたレイアウトアルゴリズムを使用している。

実世界のMermaid.jsフローチャートの例

例1:マイクロサービス型イベント駆動型インジェストメッシュ(左から右へのアーキテクチャ)

この機能的なブループリントは、ウェブテレメトリインジェストサービスをモデル化している。データ入力、意思決定のダイアモンド、クラウドデータベースの形状を、明確な水平キャンバス上でどのように組み合わせるかを示している。

flowchart LR
    %% 要素ノードを明示的な幾何形状で定義
    init([Webhook発動]) --> input_io[/HTTPリクエストをキャプチャ/]
    input_io --> auth_check{トークン検証}
    
    auth_check --> |"無効なトークン"| err_stop([401 Unauthorizedを返却])
    auth_check --> |"有効なJWT"| write_queue[[Kafkaキューに公開]]
    
    write_queue --> worker_proc(コンシューマーダーモン)
    worker_proc --> db_store[(TimescaleDBクラスタ)]
    db_store --> term([終了したフロー])

    %% クイックなカスタムスタイルオーバーライド
    style auth_check fill:#fff3cd,stroke:#ffc107,stroke-width:2px
    style err_stop fill:#f8d7da,stroke:#dc3545,stroke-width:1px

構文の分解: この図は左から右へスムーズに流れます。検証ステップでは黄色の決定ダイアモンド形状(auth_check{トークンの検証})が、実行パスを明確に二つの異なる結果に分岐させます。データストアは、カスタムのデータベースシリンダー([(TimescaleDB クラスタ)])と平行四辺形の入力によって、すぐに識別できます。

例2:エンタープライズマルチティアユーザー登録エンジン(垂直方向でネストされたサブグラフ付き)

この高度なエンタープライズブループリントは、アプリケーション登録パイプラインを描いています。三つの別々の構造的サブグラフに沿ってステップを垂直に整理することで、異なるアーキテクチャ層を表現しています。

flowchart TD
    subgraph Client_Tier["プレゼンテーションUIレイヤー"]
        app[モバイルアプリUI]
        web[Web SPAフロントエンド]
    end

    subgraph Service_Tier["コアゲートウェイルーター"]
        proxy[[Nginxイングレスリバースプロキシ]]
        auth_svc(認証サービスワーカー)
    end

    subgraph Persistence_Tier["セキュアなデータセンター"]
        main_db[(ユーザー アカウントプライマリDB)]
        cache_node[(Redisセッションキャッシュ)]
    end

    %% サブシステム層間の通信パイプラインを定義
    app -- "HTTPSリクエスト" --> proxy
    web -- "HTTPSリクエスト" --> proxy
    
    proxy --> |"ルート /v1/auth"| auth_svc
    
    auth_svc --> |"セッションを検証"| cache_node
    auth_svc --> |"アカウントをコミット"| main_db

構文の分解: 上から下への方向指定(flowchart TD)は、レイアウトエンジンがコンポーネントを上から下へクリーンに積み重ねることを強制します。バウンディングブロックは関連するコンポーネントを明確なレイヤー(クライアント、サービス、永続化)にグループ化し、全体のアーキテクチャに直感的で非常に構造的な印象を与えます。

上部へスクロール