NotionでMermaid図を扱う方法｜業務フロー図と仕様書を整理する

Notionで業務フロー、システム構成、画面遷移、データの流れを整理したい時、Mermaidは便利です。

テキストでフローチャートやシーケンス図を書けるため、画像編集ツールを開かなくても、仕様書の中に図の元データを残せます。

ただし、MermaidをNotionで使う時に大事なのは、「図が表示できるか」だけではありません。

実務では、次の問題が起きます。

• 図はあるが、どの業務手順を表しているか分からない
• Mermaidコードを誰が直してよいか決まっていない
• 仕様変更後も図が古いまま残る
• 図とタスクDB、問い合わせDB、顧客DBが紐づいていない
• Notion上の表示と、外部に提出する図の見た目が違う
• 日本語ラベルが長くなり、図が読みにくくなる
• Mermaid、PlantUML、画像、Figmaを何となく使い分けている

Mermaidは、図を作る手段です。

業務フローの正しさは、図そのものではなく、仕様書、関連DB、更新責任、承認フローで担保します。

NotionでMermaid図を扱う時は、コードブロックに図を置くことより、図を仕様書、更新者、承認、関連DBに紐づけて保守する設計 が重要です。

この記事では、NotionでMermaid図を扱う考え方を、コードブロック、業務フロー図、仕様書、更新責任、PlantUMLや画像との使い分けまで整理します。

先に結論：Mermaidは図ではなく仕様の一部として扱う

NotionでMermaidを使う時は、図を単独で置かない方がよいです。

図は、仕様書や業務手順の一部として扱います。

項目	Notionで管理すること
Mermaidコード	コードブロック、または図コード欄
図の意味	どの業務、画面、DB、処理を表すか
関連仕様	仕様書ページ、手順書、社内Wiki
関連DB	タスクDB、問い合わせDB、顧客DB、案件DB
更新者	図を直す人、レビューする人
承認	変更後に誰が確認するか
更新日	最終更新日、次回レビュー日
出力形式	Notion内コード、画像、SVG、外部資料

Mermaidは、テキストで図を更新できる点が強みです。

しかし、テキストで更新できるからこそ、誰でも勝手に直せる状態にすると、仕様の正しさが崩れます。

おすすめは、図を含む仕様書ページに次のプロパティを持たせることです。

プロパティ	型	目的
図種別	セレクト	業務フロー、画面遷移、シーケンス、ER、構成図
対象業務	リレーション、セレクト	どの業務の図か分ける
関連DB	リレーション、URL	タスクDB、問い合わせDBなどへつなぐ
図コード	テキスト、コードブロック	Mermaidコードの所在を明確にする
図オーナー	ユーザー	誰が更新責任を持つか
確認者	ユーザー	仕様として承認する人
ステータス	ステータス	下書き、レビュー中、公開、廃止
最終更新日	日付	図の鮮度を見る
次回レビュー日	日付	古い図を放置しない

Notion Wikiとは

Mermaidとは

Mermaidは、テキストとコードから図や可視化を作るためのツールです。

Mermaid公式ドキュメントでは、Markdown風のテキスト定義を使い、フローチャート、シーケンス図、クラス図、状態図、ER図、ガント図などを作れることが説明されています。

Mermaid公式ドキュメント：About Mermaid

業務で使いやすいのは、次の図です。

図	向いている用途
Flowchart	業務フロー、承認フロー、問い合わせ対応
Sequence diagram	システム間連携、API連携、通知処理
State diagram	ステータス遷移、案件状態、タスク状態
Entity Relationship Diagram	DBやマスタの関係
Gantt	大まかな工程、期間、マイルストーン
Timeline	導入計画、イベントの流れ

Mermaidの良さは、図を画像として直接編集するのではなく、コードとして残せることです。

たとえば、業務フローなら次のように書けます。

flowchart TD
  A[問い合わせ受付] --> B{担当者は決まっているか}
  B -- はい --> C[担当者が初回返信]
  B -- いいえ --> D[管理者が担当者を割り当て]
  D --> C
  C --> E[対応DBのステータス更新]

このコードは、図の元データとして残ります。

ただし、コードが残ることと、業務仕様として正しいことは別です。

仕様書として使うなら、誰が確認した図なのか、どのDBや運用に対応しているのかを決めます。

Notionでの扱い方

Notion公式ヘルプでは、ページにコードブロックを追加し、言語ごとの書式設定、コードの折り返し、コピー、キャプションを使えることが説明されています。

Notion公式ヘルプ：Code blocks

NotionでMermaidを扱う時は、まずコードブロックとして残す前提で考えます。

環境やNotion側の対応状況によって、Mermaidとして図表示できる場合でも、業務資料としては次の点を確認します。

確認項目	理由
Notion上で表示されるか	画面上の確認に使えるか
コードがコピーできるか	外部ツールやレビューで使えるか
日本語ラベルが読めるか	図として見やすいか
長い行が折り返されるか	コード保守がしやすいか
閲覧者がコードを見られるか	図の根拠を確認できるか
外部共有時に見えるか	顧客、パートナー共有に使えるか
印刷やPDFで崩れないか	提案書、仕様書に使えるか

Notion内で使うなら、図だけを置かず、図の下に説明を書きます。

図の下に書くこと	例
図の目的	問い合わせ受付から初回返信までの流れ
対象範囲	フォーム受付、担当者割り当て、返信確認
対象外	請求、契約、返金対応
更新者	CSリーダー
確認者	管理者、営業責任者
関連DB	問い合わせDB、顧客DB、タスクDB
最終更新日	2026年6月7日

Mermaidコードだけを置くと、読み手が「この図をどう使うのか」を判断できません。

図は、説明、責任者、関連DBとセットにします。

業務フロー図の用途

NotionでMermaidが向いているのは、業務フロー図です。

業務フロー図は、手順書よりも全体像をつかみやすく、会議でも確認しやすいからです。

業務	Mermaidで表す内容
問い合わせ対応	受付、担当者決定、返信、確認、完了
承認フロー	申請、一次承認、差し戻し、最終承認
採用管理	応募、書類確認、面接、評価、内定
請求確認	請求前確認、発行、入金確認、差戻し
障害対応	検知、一次共有、担当者割当、復旧、振り返り
社内申請	申請、確認、承認、通知、保管

業務フロー図を作る時は、例外処理を入れます。

よくない図は、正常系だけで終わる図です。

正常系だけの図	実務で必要な図
申請する → 承認する → 完了	差し戻し、再申請、期限超過、代理承認を含める
問い合わせ → 返信 → 完了	担当者未設定、社内確認待ち、顧客待ちを含める
タスク作成 → 実行 → 完了	保留、差し戻し、レビュー待ちを含める

Notionで業務フロー図を作るなら、図と一緒にステータス設計も書きます。

フロー上の状態	DBステータス
受付	未確認
担当者決定	対応中
社内確認	社内確認待ち
顧客返信待ち	顧客待ち
完了	完了
差し戻し	要修正

図とDBステータスが一致していないと、現場は混乱します。

Notionデータベースの作り方

仕様書に入れる場合

Mermaid図を仕様書に入れる場合は、図を本文の補助として扱います。

図だけで仕様を完結させない方がよいです。

仕様書に必要な項目	内容
背景	なぜこのフローが必要か
対象範囲	どこからどこまでを扱うか
図	Mermaidで全体像を示す
詳細手順	各ステップの入力、判断、出力
例外処理	差し戻し、期限超過、権限不足
関連DB	どのDBのどのプロパティを使うか
通知	誰に、いつ通知するか
承認者	誰が仕様として確認したか

Notion公式の社内Wikiガイドでは、会社の重要情報を一元化し、チームが必要な情報へアクセスできるようにする考え方が説明されています。

Notion公式ガイド：社内Wikiの作り方

Mermaid図を社内Wikiや仕様書に入れるなら、次のように分けます。

情報	置く場所
図のコード	仕様書ページ、図コード欄
図の説明	仕様書本文
関連手順	手順書、社内Wiki
実行タスク	タスクDB
変更履歴	仕様書DB、更新履歴
承認記録	承認DB、コメント、確認者プロパティ

仕様書DBがあるなら、Mermaid図もその1ページに入れます。

別ページに図だけを置くと、後から仕様との関係が分かりにくくなります。

図の更新責任

Mermaid図で一番起きやすい失敗は、古い図が残ることです。

コードとして直しやすい分、更新責任が曖昧になりがちです。

図のあるページには、更新責任を持たせます。

役割	責任
図オーナー	Mermaidコードを更新する
業務責任者	図の内容が実態と合っているか確認する
DB管理者	図とDBステータス、プロパティが合っているか確認する
承認者	仕様として公開してよいか確認する
利用者	実務でズレを見つけたらコメントする

更新タイミングも決めます。

タイミング	更新する内容
業務フロー変更時	図、手順、ステータス
DBプロパティ変更時	図内のDB名、プロパティ名
通知ルール変更時	通知先、通知条件
外部ツール変更時	システム間連携の図
月次レビュー	古い図、未承認図、廃止図

おすすめは、図のステータスを分けることです。

ステータス	意味
下書き	作成途中。業務標準として使わない
レビュー中	業務責任者やDB管理者が確認中
公開	現行運用として使う
要更新	実態とズレている
廃止	現在は使わない

図が古いと、手順書より危険です。

図は一目で信じられやすいからです。

だからこそ、更新責任とステータスを明確にします。

PlantUMLや画像との使い分け

Mermaidは万能ではありません。

Notionで扱う図は、Mermaid、PlantUML、画像、Figmaなどを使い分けます。

手段	向いている用途	注意点
Mermaid	軽い業務フロー、状態遷移、簡単なシーケンス	Notion表示や構文対応の差を確認する
PlantUML	複雑な業務フロー、システム構成、生成画像管理	別途レンダリング環境が必要
画像、SVG	提案書、外部共有、固定表示	更新時に元データが分からなくなりやすい
Figma	画面設計、UIフロー、見た目の説明	仕様本文やDBと分離しやすい
手書き図	初期検討、会議中の整理	正式仕様には向かない

Notion内の軽い業務フローなら、Mermaidで十分です。

ただし、顧客提出資料、細かいレイアウト、複雑なシステム構成では、PlantUMLや画像化した図の方が安定します。

判断基準は次の通りです。

条件	推奨
社内で素早く更新したい	Mermaid
コードとして図をバージョン管理したい	Mermaid、PlantUML
外部資料で見た目を固定したい	SVG、PNG
複雑なシステム構成を厳密に表したい	PlantUML
UIや画面遷移を見せたい	Figma
会議中に整理したい	ホワイトボード、手書き

Mermaidを使う時も、必要ならSVGやPNGに書き出して、外部共有用に固定します。

Notion上の図と外部資料の図がズレないよう、元コードの場所を必ず残します。

保守ルール

Mermaid図を業務で使うなら、保守ルールを決めます。

最低限のルールは、次の5つです。

ルール	内容
図は仕様書ページに置く	図だけの孤立ページを作らない
図オーナーを決める	誰が更新するか明確にする
DBと対応させる	ステータス、プロパティ、関連DBを図と合わせる
承認ステータスを持つ	下書きと現行仕様を分ける
月次で古い図を見る	要更新、廃止、重複を減らす

図のコメント運用も決めます。

コメント	対応
実際の運用と違う	ステータスを要更新にする
新しい例外が出た	図と手順に追記する
DB名が変わった	図コードと関連DBを更新する
外部ツールが変わった	システム連携図を更新する
もう使わない	廃止ステータスにする

図が多くなったら、図管理DBを作ります。

プロパティ	型	目的
図名	タイトル	図の名前
図種別	セレクト	業務フロー、シーケンス、ERなど
関連ページ	リレーション、URL	仕様書やWikiへ紐づける
関連DB	リレーション、URL	業務DBへ紐づける
オーナー	ユーザー	更新責任者
確認者	ユーザー	承認者
ステータス	ステータス	下書き、レビュー中、公開、要更新、廃止
最終更新日	日付	鮮度管理
次回レビュー日	日付	棚卸し対象
元コード	テキスト、URL	Mermaidコードの所在

ここまで作ると、Mermaidは単なる図作成ではなく、仕様書の保守対象になります。

Notionだけで足りない場合

NotionとMermaidだけで足りない場面もあります。

次のような場合は、外部ツールへ分けます。

状況	分ける先
複雑なシステム構成を厳密に管理したい	PlantUML、draw.io、専用設計ツール
画面デザインと連動したい	Figma
Gitで図コードを管理したい	GitHub、GitLab、PlantUML、Mermaid CLI
顧客提出資料として見た目を固定したい	SVG、PNG、PowerPoint
監査や承認証跡が必要	ワークフロー、ドキュメント管理

Notionは、図の背景、仕様、関連DB、更新責任を残す場所として強いです。

一方で、図のレンダリング、提出資料、厳密なバージョン管理は外部ツールの方が向く場合があります。

Notionには、図の意味と更新責任を残します。

外部ツールには、図の生成や提出形式を任せます。

まとめ

NotionでMermaid図を扱う時、重要なのはMermaidコードを書けるかどうかではありません。

図が、どの業務フロー、仕様書、DB、手順、承認に紐づいているかです。

Mermaidは、テキストで更新できるため、社内の業務フローや仕様整理に向いています。

ただし、図だけをNotionに置くと、すぐに古くなります。

仕様書ページに置く。

図オーナーを決める。

DBステータスと対応させる。

承認ステータスを持たせる。

月次で古い図を棚卸しする。

この運用まで入れると、Mermaidは「きれいな図」ではなく、Notion内の業務仕様を保守するための部品になります。