状態図とは何ですか？
A 状態図（状態チャートとしても知られる）は、行動的なUML図は、単一のオブジェクトまたはサブシステムの有限なライフサイクルをモデル化するものです。コアなUML図の種類として認識されており、エンティティが取りうる離散的な状態（ステート）、それらの状態間を強制的に移行させる外部イベントやトリガー（遷移）、実行パスを変更する条件付きルールの分岐を示します。このマッピングは、注文の履行から配送への進行、ユーザーのセッションタイムアウトシーケンス、または埋め込みハードウェアのスイッチループといった複雑なオブジェクトのライフサイクルを追跡する上で不可欠です。
With Mermaid.js、宣言的でテキスト駆動のスキーマを使用して、反応型の状態機械を定義できます。パーサーエンジンは最適なレイアウト間隔を自動計算し、再帰的なループ矢印を処理し、状態コンテナの境界を滑らかにスケーリングします。
コア構文ガイド：要素と構造
Mermaidで正確で標準準拠のUML状態図を設計するには、エントリ/エグジットマーカー、遷移文字列、複合ネスト、条件付き選択ブロックを習得する必要があります。
1. エントリ、エグジット、および標準状態の定義
1行目にstateDiagram-v2キーワードを使用して状態キャンバスを初期化します。ライフサイクルには明示的な開始点と終了点が必要で、それらは実線の円記号（[*]):
- 初期状態（エントリ）：
[*] --> StateName（ライフサイクルの開始地点を示す）。 - 終端状態（エグジット）：
StateName --> [*]（ライフサイクルの終了地点を示す）。
2. 遷移トリガーとイベントラベルの設定
状態変更をマッピングするには、定義した状態トークンを標準の矢印線で接続します（-->）。この遷移を引き起こす正確なイベント、API応答、またはボタンクリックを文書化するには、コロン（:）の後に説明テキスト文字列を追加します：
stateDiagram-v2
Active --> Suspended : PaymentFailed
Suspended --> Active : InvoiceSettled
3. 条件付き選択ブロックの実装
分岐評価ループを処理するには、<<choice>>スタereotypeを使用します。これにより、キャンバス上に明確なダイヤモンド型が作成され、実行時ロジックチェックに基づいて単一のインバウンド遷移パスを複数の異なるアウトバウンドパスに分割します：
stateDiagram-v2
state check_status <<choice>>
[*] --> check_status
check_status --> PremiumUser : if balance >= 100
check_status --> StandardUser : if balance < 100
4. 複合（ネストされた）状態の構造化
複雑なシステムをモデル化する際、単一の高レベル状態が独自の独立した内部ライフサイクルを含むことができます。親状態を定義した後に波かっこで囲まれた本体ブロックを記述することで、ネストされたサブ状態レイアウトを作成できます：
stateDiagram-v2
state OrderProcessing {
[*] --> Packaging
Packaging --> Labeling
}
クリーンな状態機械レイアウトのためのベストプラクティス
- 状態トークンは短く保つ： 内部状態トークンには簡潔なCamelCaseテキスト文字列を使用してください（例：
AwaitingRefund）。キャンバス上に長い説明タイトルが必要な場合は、state "説明テキストブロック" as Token明示的な別名を作成するための構文。 - 単一のエントリポイントを強制する： 図を常に単一の
[*]ノードから開始する。複数の開始ポイントがあると、システムの初期化パスを追跡しようとするユーザーを混乱させる可能性がある。 - 常に stateDiagram-v2 を使用する： 常に
stateDiagram-v2キーワードを、レガシーなstateDiagramフラグよりも選択する。v2 レンダリングエンジンは、より明確な線のルーティングと、より良いネストされたボックスの配置を提供する更新されたレイアウトアルゴリズムを使用している。
実際の Mermaid.js 状態図の例
例1：デジタルウォレット取引ライフサイクル（選択分岐と失敗ループ）
この機能的ブループリントは、デジタル決済取引のライフサイクルをモデル化し、取引が初期の提出ポイントから不正検査の分岐を経て、最終的な帳簿状態へと移行する様子を示している。
stateDiagram-v2
state fraud_check <<choice>>
[*] --> TransSubmitted
TransSubmitted --> fraud_check : ExecuteRiskAssessment
fraud_check --> TransApproved : Risk Score Low
fraud_check --> TransFlagged : Risk Score Elevated
TransFlagged --> TransApproved : ManualManagerOverride
TransFlagged --> TransDeclined : SecurityTimeout
TransApproved --> SettlementPending : CommitLedger
SettlementPending --> TransCompleted : BankSettlementSuccess
TransDeclined --> [*]
TransCompleted --> [*]
構文の分解： このワークフローは<<choice>> ブロックを用いて、開始直後に安全スコアを評価する。取引はこれらのスコアに基づいて明確な経路を経由して移行し、明確なイベント名（例：ExecuteRiskAssessment）が遷移矢印上に直接記述されている。
例2：Eコマース注文履行パイプライン（複合ネスト構造）
この高度なエンタープライズブループリントは、履行フェーズ内で発生する内部処理を示すために、ネストされた複合ブロックを使用して、配送および注文管理のライフサイクル全体を概説している。
stateDiagram-v2
[*] --> OrderPlaced
OrderPlaced --> InFulfillment : PaymentCaptured
state InFulfillment {
[*] --> ItemPicking
ItemPicking --> QualityAudit : BatchPicked
QualityAudit --> SecureBoxPacking : AuditPassed
SecureBoxPacking --> CarrierManifest Generated : LabelPrinted
}
InFulfillment --> Shipped : CarrierHandshake
Shipped --> Delivered : OutForDeliveryConfirmed
Delivered --> [*]
構文の分解： ステップを以下のブロックで囲むことで、state InFulfillment {...} ボディブロック内にステップを囲むことで、キャンバス上に明確な構造的境界を作成できます。エンジンはこのブロックを、内部のワークフローステップを順次レンダリングする際の単一の統合された親ステートとして扱います。これにより、複雑な多層構造のライフサイクルも簡単にナビゲートできるようになります。