Mac版ObsidianでMermaid状態図を簡素化するには、すべての有効な遷移を明示的に保持し、ラベルを短縮し、読み取り方向をテストします。ソース、デスティネーション、遷移テキストを比較し、結果を受け入れる前に確認してください。

このチュートリアルでは、AからDまでの4つの合成状態を使用します。課題は、直接遷移、戻りパス、開始および終了マーカーを保持しながら、図を読みやすくすることです。遷移表は、レンダラが矢印をどのように配置するかに依存せず、それらの保持を確認する具体的な方法を提供します。

図を簡素化する際に何が変わってはならないか？

まず、プレゼンテーションの変更とモデルの変更を分離します。表示ラベルを短くしたり、読み取り方向を変えたりすることは可読性を向上させます。矢印を削除すると、別のルートで同じデスティネーションに到達できても、直接遷移のセットが変わってしまいます。

たとえば、AからCへの直接遷移と、Bを経由するルートの両方が存在するとします。直接遷移を削除すると、読者はBへの中間訪問を推測せざるを得ません。それは到達可能性を保ちますが、有効な単一ステップ遷移を失います。このタスクでは、最終的に同じデスティネーションに到達できるだけでは不十分です。

以下の遷移インベントリを元の仕様として使用します。ラベルは合成イベント名であり、この例内で意味を持ち、元の矢印に付属したままである必要があります。

ソース デスティネーション 遷移テキスト
Start A なし
A B step
A C alternate
B C next
B A reset
C B back
C A reset
C D finish
D End なし

開始と終了を含めて9つの遷移があります。2つの矢印がラベルresetを共有していますが、異なる状態から発生しています。両方を保持してください。同様に、BとCの間の矢印は方向とラベルが異なるため、別々の遷移です。

より大きな図の場合、編集前に各遷移をソース、デスティネーション、テキストの組み合わせとして記録してください。元のテキストに条件やアクションが含まれている場合、それらも保持してください。矢印の総数が一致するだけでは、デスティネーションやラベルが変更された矢印を検出できません。

インストールされているObsidianが使用するレンダラを確認する

Macで、サイドバーの歯車アイコンから設定を開き、一般を選択します。上部に表示されている現在のアプリケーションバージョンとインストーラバージョンを記録してください。関連するリリースノートを調べる際にはアプリケーションバージョンを使用します。これらの場所はObsidianの設定ヘルプに記載されています。

レンダラの境界は重要です。Obsidianの1.15.0デスクトップ版早期アクセスリリース（2026年10月22日付）は、図のレンダリングをPeleに切り替え、Mermaid 12.1.0構文との互換性があるとしています。そのリリースノートでは、このバージョンにはMermaidライブラリが含まれなくなったとも述べています。その記述は指定されたリリースに適用されるものであり、インストールされているすべてのObsidianバージョンのレンダラを特定するものではありません。Obsidian 1.15.0 デスクトップ版リリースノートを参照してください。

構文互換性と視覚的外観は別個のチェックとして扱ってください。他のエディタで受け入れられた図は有用な比較になりますが、インストールされているアプリケーションこそが最終結果を検証する場所です。アップストリームのレイアウト設定や新しいドキュメントの例が、ローカルのレンダラで同じように動作するとは限りません。

以下の例では、レンダラ設定、テーマ設定、スタイリングを意図的に避けています。すでに動作する図がある場合は、その既存の図宣言から始め、一度に1つのプレゼンテーション詳細を変更してください。この記事で説明する遷移インベントリとラベル編集を行うためだけにアップグレードする必要はありません。

明示的な遷移を持つコンパクト版を構築する

以下の完全な例は、インベントリのすべての9行を実装しています。表示される状態名は意図的に短くしています。状態Aが開始点で、BとCには戻りパスがあり、のみDが終了マーカーへの遷移を持ちます。

Mermaidは状態エイリアス、ラベル付き遷移、開始および終了マーカー、方向ステートメントを状態図リファレンスで文書化しています。Obsidianの文書化された挿入方法は、言語識別子mermaidを持つフェンスコードブロックであり、高度なフォーマット構文で説明されています。

```mermaid
stateDiagram-v2
    direction LR

    state "Stage A" as A
    state "Stage B" as B
    state "Stage C" as C
    state "Stage D" as D

    [*] --> A

    A --> B : step
    A --> C : alternate

    B --> A : reset
    B --> C : next

    C --> A : reset
    C --> B : back
    C --> D : finish

    D --> [*]
```

このMarkdown例全体を、開始と終了のトリプルバックティック行を含めてノートに貼り付けてください。ここで示されている外側の4重バックティックフェンスは、この記事で例を表示するためのものであり、ノートの内容には含まれません。

正確なテキストを検査するには、ソースモードを使用してください。レンダリング結果を検査するには、リーディングビューに切り替えてください。macOSではCmd+Eでリーディングビューと編集ビューを切り替えられます。Obsidianではこれらの操作がビューと編集モードで説明されています。

遷移ステートメントはソース状態ごとにグループ化されているため、各状態の出力オプションを一緒に確認できます。この構成はソーステキストの維持に役立ちますが、レンダラが各状態をどこに配置するかの保証として扱うべきではありません。

普段使用しているノート幅で例を試してください。次に、direction LR行のみを削除して結果を比較してください。分岐と戻りパスをより追いやすいプレゼンテーションを採用してください。左から右への図はより多くの水平スペースを必要とする場合があるため、実際のノートペインで結果を判断してください。

ラベルはその意味が許す限りでのみ短縮してください。この合成例では、Stage B以上の説明は不要です。ご自身の図では、2つの状態を区別するために必要な語句を保持してください。長い説明が必要な場合は、隣接する散文の段落に記述し、状態識別子への明確なマッピングを保持してください。

モデルを変更してしまうショートカットはどれか？

繰り返しの矢印を見ると、共有の中間ノードを導入したくなるかもしれません。そうする前に、そのノードが何を表し、元の直接遷移が依然として存在するかを自問してください。

共有リセットノードは直接パスを変更する

インベントリでは、BとCがそれぞれresetで直接Aに遷移しています。これらの矢印を、新しい状態Rを経由するパスに置き換えると、中間状態が作成され、元の直接エッジが削除されます。読者は依然としてAへのルートをたどれますが、図は異なるステップを記述することになります。

この記事の正確な結果を得るには、2つのリセット矢印を保持してください。それらの繰り返しは、同じイベントに対する2つの有効な開始条件を記録しています。視覚的なフットプリントを減らすのは、その意味が生き残る場合のみ有用です。

選択またはフォークにはモデル内での理由が必要

Mermaidは、パス間の分岐に<<choice>>、フォークとジョイン構造に<<fork>>と<<join>>を文書化しています。これらは状態図リファレンスで定義される別個の図構成要素です。

それらを、単にいくつかの散らかった矢印を共通のジャンクションに集めるためだけに導入しないでください。この例では、タスクは直接の状態間遷移を保持することです。中間構成要素を追加すると、そのパスが元のモデルにどう対応するかを別途説明する必要があります。明示的な矢印なら、その対応は即座にわかります。

複合状態には文書化された境界がある

Mermaidは複合状態をサポートしていますが、そのドキュメントでは、異なる複合状態に属する内部状態間の遷移を明示的に禁止しています。複合状態を参照してください。

ノードのグループ化がその状況を生む場合、このタスクでは接続された状態をフラットに保ってください。矢詞を外側の複合状態に移動すると、そのエンドポイントが変わります。それは自動的に等価な置き換えにはなりません。階層を使用するのは、それがモデルの実際の構造を表し、そのエントリと出口の振る舞いを説明できる場合です。

4状態の例では、ネストはほとんど役立ちません。有用な簡素化は、遷移構造をそのままに、より短いラベルとより明確なプレゼンテーションを実現することです。

遷移とレンダリング結果の両方を検証する

元の図を置き換える前に、2回のパスで確認してください。1回目はモデルをチェックし、2回目は選択したプレゼンテーションが有用かどうかをチェックします。

  1. インベントリの各行を遷移ステートメントと比較してください。両方のエンドポイントと完全なラベルを確認してください。
  2. すべての遷移ステートメントをインベントリと比較して戻してください。これにより、余分な矢印や欠落した矢印も検出できます。
  3. 開始と終了を別個にチェックしてください。ここでは、開始はAのみに、のみDが終了につながっています。
  4. レンダリングされた図で、読みやすいラベルと区別可能な矢印ヘッドがあるか検査してください。
  5. BとCからの戻りパスをたどってください。前方の進行のみを見てレビューしていると、これらは見落とされがちです。

この例では、3つの読み取りチェックを試してください：開始からA、次にC、次にD、次に終了；開始からA、次にB、次にリセットでAに戻る；開始からA、次にC、次にバックでBに戻る。これらのチェックは、代替ルート、リセット、逆接続を実行します。これらは行比較を補完するものであり、置き換えるものではありません。

決定論的なテキスト比較により、例の9つの遷移ステートメントがラベルを含めてインベントリと一致することが確認されました。この例は準備中にインストール済みのObsidianアプリケーションでレンダリングされていないため、最終的なスペーシングと矢印のルーティングは、お使いのローカルバージョンで確認する必要があります。

ノートにリテラルコードが表示される場合は、まずリーディングビューで表示しているか、開始フェンスがmermaidと言っているかを確認してください。編集後にパースエラーが発生した場合は、完全な例に戻り、一度に1つの変更を再適用してください。レイアウトが不恰好なだけの場合は、遷移を保持しながら、ラベル長、方向、利用可能なペイン幅を比較してください。

インベントリ比較がパスした後、ラベルとパスが最も読みやすいバージョンを保持してください。成功した簡素化は、読者がより少ない労力で同じ有効な遷移を追えるようにし、ソースが検査および保守しやすい状態を保ちます。

出典