--- title: "データ連携図の書き方｜システム関連図とDFDの粒度と記法・Mermaidでの版管理" url: "https://www.issoh.co.jp/tech/details/17180/" published: 2026-08-31 updated: 2026-08-31 categories: ["アーキテクチャ"] publisher: "株式会社一創" --- # データ連携図の書き方｜システム関連図とDFDの粒度と記法・Mermaidでの版管理 データ連携図は、描き始める前に「どの図で何に答えるか」を決めないと、1枚に情報が詰まって誰も読まない壁紙になります。この記事では、データ連携図と呼ばれているものの実体をシステム関連図・DFD・シーケンス図の3種類に切り分け、4要素の記号と整合ルール、1枚あたりのプロセス数7±2という粒度基準、レベル0から2までの分解と停止条件を実装者の粒度で扱います。図に書かず外部インタフェース一覧へ逃がす7項目、Mermaid 11系でテキスト化してGitHubの差分レビューに載せる運用まで含めました。数値と記法は2026年8月時点の一次情報で確認しています。 ## まとめ：データ連携図を3階層に割る判断と外部インタフェース一覧との分担 結論から置きます。実務で「データ連携図」と呼ばれている図の大半は、DFDのコンテキスト図（レベル0）に相当するシステム関連図です。データがどの処理を通ってどこに溜まるかまで踏み込むならDFD、1回の処理で誰がいつ誰を呼ぶかを追うならシーケンス図。この3つを1枚に混ぜた瞬間に、読み手も粒度も決まらなくなります。 粒度の基準は数字で引けます。1枚に置くプロセスは7±2、超えたら階層を割る。要件定義で描くのはレベル1までで、レベル2以降は基本設計の担当です。図の上に載せるのは「どこからどこへ」「何のデータが」「どの向きに」の3点だけに絞り、方式・契機・件数・異常時の扱いは外部インタフェース一覧という表へ逃がしてください。 保守の勝負は記法ではなく版管理で決まります。Mermaid 11系のflowchartでテキスト化してGitに置けば、図の変更がプルリクエストの差分に載り、レビューの対象になります。逆に連携が2本以下なら図は要りません。表1枚のほうが速い。 ## データ連携図が指す3種類の図とシステム構成図との描き分けの境界 同じ「連携図がほしい」という依頼でも、依頼者が見たいものは3通りに分かれます。ここを聞き分けないまま作図に入ると、完成後のレビューで「知りたいのはこれじゃない」と差し戻されます。 ### システム関連図とDFDとシーケンス図が答える問いの違いと使う工程 3つの図は答える問いが違います。システム関連図が答えるのは「どのシステムとどのシステムがつながっているか」。DFDが答えるのは「データがどの処理を経て、どのデータストアに溜まるか」。シーケンス図が答えるのは「1回の処理の中で、誰がいつ誰を呼ぶか」です。 工程との対応も分かれます。システム関連図とDFDは要件定義の成果物で、業務部門と合意するために描く図です。時間軸とメッセージの往復を扱う[シーケンス図とは？UMLの書き方・ライフラインやメッセージ・複合フラグメントを解説](https://www.issoh.co.jp/tech/details/13482/)は基本設計以降の内部設計向けで、業務部門のレビューには重すぎます。データの保持構造そのものはER図の担当なので、連携図に主キーや正規化の話を持ち込まないでください。 ### システム構成図に載せる情報とデータ連携図に載せない情報の線引き 混同されやすいのがシステム構成図です。構成図が扱うのはサーバ・ネットワーク・冗長化・可用性ゾーンといった物理と論理の配置で、読み手はインフラ担当になります。データ連携図の読み手は業務部門と情報システム部門であり、見たいのは業務データの発生源と行き先です。 だからロードバランサ、リバースプロキシ、可用性ゾーンの区画は連携図に描きません。逆に「受注データが日次でどこへ流れるか」は構成図には描きません。構成図側の描き分けは[システム構成図とは？種類と書き方・例、発注者が確認すべき観点を解説](https://www.issoh.co.jp/column/details/13136/)に譲ります。 ### 論理DFDと物理DFDの使い分けと要件定義で提出する順序の決め方 DFDには論理と物理の2種類があります。論理DFDが書くのは業務として何をするかで、プロセス名は「受注を登録する」のような業務の言葉です。物理DFDは手段まで書き、「販売管理SaaSのREST APIで登録する」のように製品名と方式が入ります。 提出順序は論理が先です。物理から先に描くと、既存製品でできることが業務要件のふりをして紛れ込み、後から「その業務は本当に必要か」を問い直せなくなります。手順としては、論理DFDを業務部門と合意してから、同じプロセス配置のまま製品名と方式を重ねて物理DFDに落とす。この2枚を並べて保管すると、製品を入れ替えたときに差分が業務側に及ぶかどうかを短時間で判定できます。 ## データ連携図の記法4要素と矢印・データストアの書き方の統一ルール 記法そのものは30分で覚えられます。実務で崩れるのは記号の選択ではなく、同じ図の中で書き方が揺れることです。 ### 4要素の記号と2つの記法体系のどちらを社内標準にするかの判断 DFDの構成要素は4つだけです。外部エンティティ（システムの外側にいる相手）、プロセス（処理）、データストア（保管先）、データフロー（矢印）。記法体系はヨードン／デマルコ記法（DeMarco 1978・プロセスを円で描く）とゲイン・サーソン記法（Gane & Sarson 1977・プロセスを角丸の四角で描く）の2系統に分かれます。 どちらを社内標準にするかで悩む価値はほとんどありません。判断基準は「使う作図ツールが標準で持っている形」に寄せることです。Mermaidのflowchartなら円は `A((受注処理))`、角丸は `A(受注処理)` でどちらも書けるため、テンプレートを1つ決めて全員がコピーして使う運用のほうが効きます。記号体系の統一よりも、1つの図の中で円と四角が混在しないことのほうが読みやすさに直結します。 ### 矢印のラベルに必ず書く4項目とレビューで指摘される記載漏れの典型 矢印は線を引くだけでは情報になりません。最低限、次の4項目を矢印のラベルに載せます。 - データ名（「受注」ではなく「受注ヘッダ・明細」まで書く） - 向き（片方向か双方向か。双方向は原則2本の矢印に分ける） - 契機と頻度（都度・日次バッチ・月次のいずれか） - 方式（REST API・SFTP・CSV連携・DB直参照のいずれか） 指摘される記載漏れは3つに集中します。双方向を1本の矢印で済ませて、どちらが起動側か読めなくなるもの。正常系だけを描き、エラー通知や取消データの戻りが図に存在しないもの。そして、バッチ連携で「誰がジョブを起動するか」が矢印のどちら側にも書かれていないもの。この3つは要件定義のレビューでほぼ確実に質問されます。 ### ブラックホールとミラクルを禁じる整合ルールと親子図のバランス検査 DFDには機械的に検査できる整合ルールがあります。出力を持たないプロセスはブラックホール、入力を持たないプロセスはミラクルと呼ばれ、どちらも誤りとして扱われます。データを受け取るだけで何も返さない処理が図に居るなら、書き忘れか、そもそもそのプロセスが不要かのどちらかです。 もう1つがデータストアの扱いになります。データストアと外部エンティティを矢印で直結してはいけません。読み書きは必ずプロセスを介します。そして階層を割ったときはバランスの原則を検査します。レベル1の図に出入りする矢印の集合は、レベル0のコンテキスト図に出入りする矢印と一致していなければなりません。この3つの検査は目視で回せます。図を配る前に自分で1周してください。 ## 1枚に何を描くかを決める粒度の基準と階層を止める条件の具体値 粒度は感覚で決めると人によってぶれます。数字と停止条件を先に決めておけば、レビューで「もっと細かく」という無限の要求に線を引けます。 ### 1枚あたりのプロセス数7±2という上限と階層を分割する起点の選び方 古典的な目安は1枚あたりのプロセス数7±2です。9個を超えたら階層を割る、と機械的に運用して構いません。この数字は人が一度に把握できる要素数に由来する経験則です。 割る起点は「業務の主体が変わるところ」に置きます。受注から出荷までを1枚に描いていて、営業部門・物流部門・経理部門の3者が登場しているなら、部門の境界が分割線です。処理の細かさで割ると、どの単位で分けたのか説明できない図になります。 ### レベル0から2までの分解で各階層が答えるべき問いと分解の停止条件 階層は3段までで足ります。各段が答える問いを固定しておくと、描く順番が迷子になりません。 1. レベル0（コンテキスト図）：対象システムを1つの箱にして、外部との入出力だけを描く。答える問いは「このシステムは誰と何をやり取りするか」 2. レベル1：対象システムの中を主要プロセスに分解する。答える問いは「入ってきたデータはどの処理を通ってどこに溜まるか」 3. レベル2：レベル1の1プロセスの中を分解する。答える問いは「その処理はどんな判定と分岐でできているか」 停止条件は、これ以上分解しても意味を持たない単位、いわゆるプリミティブプロセスに達したときです。実務では「1プロセス＝1本の外部インタフェース、または1画面、または1ジョブ」まで割れたら止めます。要件定義の成果物として提出するのはレベル1まで。レベル2は基本設計側の作業なので、要件定義の期間中に描き始めたら工程がずれている合図です。 ### 1システムを1ノードにするか業務単位で割るかの判断基準と例外 連携図でよく詰まるのが、ERPやSaaSのような大きな箱を1ノードにするかどうかです。判断基準は「保守の契約単位」に置きます。障害時の問い合わせ先が別なら別ノード、同じなら1ノード。この基準なら、図を見た人が誰に連絡すべきかまで読み取れます。 例外は2つあります。1つは、同一パッケージでもモジュールごとにインタフェースが独立している場合。ERPの販売モジュールと会計モジュールで連携仕様書が別々に存在するなら、図の上でも割ります。もう1つは、SaaS群をまとめて「SaaS各種」と1ノードにしてしまう省略です。相手が3つ以上あるなら、名前を書いて個別に並べてください。まとめた瞬間に、その図から移行の見積もりが作れなくなります。 ## 要件定義で連携図を合意に使う手順と外部インタフェース一覧への逃がし方 連携図の価値は、絵の美しさではなく合意形成の速さで測ります。読み手ごとに見る場所が違うので、図と表の役割分担を先に決めておきます。 ### 図に書かず外部インタフェース一覧に載せる7項目と項目定義書の分担 図に詰め込むほど読まれなくなります。矢印のラベルに残すのはデータ名と向きだけにして、残りは外部インタフェース一覧という表へ逃がします。表に載せるのは次の7項目です。 - インタフェースID（図の矢印に同じIDを振って対応させる） - 送信元システムと宛先システム - データ名と識別キー - 連携方式（REST API・SFTP・CSV・DB直参照など） - 契機と頻度（都度・日次何時・月次何日） - 想定件数と最大レコード長 - 異常時の扱い（自動再送・翌日リラン・手運用のどれか） 項目レベルの型・桁・必須区分は、さらに別の項目定義書へ分けます。表を1枚に統合したくなりますが、更新頻度が違うので分けたほうが保守は楽になります。要件定義書全体での置き場所は[要件定義書の書き方とは？記載項目・章立てサンプル・作成のコツを解説](https://www.issoh.co.jp/column/details/12849/)の章立てに沿わせてください。 ### 情シスと業務部門とベンダーで確認する観点をレビュー順に並べた表 同じ図を3者に同時に見せると議論が発散します。レビューは順番を決めて回します。 | 順 | レビュー主体 | 確認する観点 | 典型的な指摘 | | - | -------- | ----------- | ------------ | | 1 | 業務部門 | データの発生源と使う人 | この帳票の元が図にない | | 2 | 情報システム部門 | 既存システムとの重複 | 同じデータが2経路ある | | 3 | ベンダー | 方式と件数の実現性 | 日次3万件はAPIで無理 | | 4 | 情報システム部門 | 廃止対象と移行順序 | 旧連携の停止日が未定 | 業務部門を最初に置くのは、データの抜けが最も高くつくためです。方式の実現性をベンダーに問うのは3番目で構いません。順序を逆にすると、技術的に書ける形へ業務を寄せた図ができあがります。 ### 現行と将来の2枚を並べて移行対象と廃止対象を確定させる進め方 刷新案件では、現行（As-Is）と将来（To-Be）を同じ記法で2枚描き、並べて差分を取ります。差分から出てくるのは、新設するインタフェース、改修するインタフェース、そして廃止するインタフェースの3種類です。 見積もりの精度を左右するのは廃止の本数になります。新設は仕様が決まれば読めますが、廃止は「まだどこかで使われているかもしれない」という調査が必要で、稼働年数の長いシステムほど時間を食います。だからAs-Isの図は、現行の設計書ではなく実際のジョブ定義とアクセスログから起こしてください。実装の手順と認証・エラー処理の作り込みは[API連携の実装方法とは？REST・認証・エラー処理までの手順を実装者向けに解説](https://www.issoh.co.jp/tech/details/15351/)にまとめています。現行の棚卸しから新方式の設計・実装までまとめて外に出す場合は、[API開発・システム連携](https://www.issoh.co.jp/service/system/api/)で受けています。 ## Mermaidでテキスト化して差分レビューと陳腐化を止める運用の作り方 連携図が使われなくなる原因のほとんどは、記法の稚拙さではなく更新の停止です。テキストで書いてリポジトリに置くと、更新がレビュー対象に乗ります。 ### flowchartで連携図を書く最小記法とラベルに載せる情報の型 Mermaidのflowchartなら、連携図に必要な記号はほぼ揃います。宣言は `flowchart LR` のように書き、方向は TB・TD・BT・LR・RL から選びます。左から右へ流す LR が連携図には読みやすい向きです。 ノードの形は用途で決まります。外部エンティティは矩形の `A[受注管理SaaS]`、プロセスは角丸の `B(受注取込)`、データストアは円柱の `C[(基幹DB)]`。矢印にラベルを付けるときは `A -->|受注ヘッダ 日次| B` の形で、前の章で決めたデータ名と頻度をそのまま載せます。部門やゾーンで囲むときは `subgraph 販売部門` から `end` までで括ります。バージョン11.3.0以降は `A@{ shape: rect }` という形の形状指定も使えますが、既存図との互換を考えると括弧記法で揃えたほうが安全です。記法の全体像は[Mermaid記法の使い方を完全ガイド｜無料のLive Editorでフローチャート・シーケンス図を作成](https://www.issoh.co.jp/tech/details/3374/)を参照してください。 ### GitHubのMarkdownで描画される範囲とレビュー運用への載せ方 GitHubは `mermaid` の言語識別子を付けたフェンスコードブロックを図として描画します。公式ドキュメントによれば、描画されるのはIssue・Discussion・プルリクエスト・Wiki・リポジトリ内のMarkdownファイルです。図の実体がテキストなので、プルリクエストの差分に「どの矢印が増えてどの矢印が消えたか」が行単位で出ます。 運用としては、外部インタフェース一覧のCSVと連携図のMarkdownを同じディレクトリに置き、仕様変更のプルリクエストで両方を同時に直す規約にします。片方だけ直された変更はレビューで落とせます。なお、ブラウザにサードパーティのMermaidプラグインを入れているとGitHub上でエラーが出ることがあると公式に注記があるため、描画がおかしいときは拡張機能を疑ってください。描画エンジンのバージョンは `info` コマンドで確認できます。npm registry 上の mermaid は2026年8月時点で 11.17.2 が最新（2026年8月25日公開）で、11系が現行です。 ### 作図ツールとテキスト記法のどちらを正とするかの判断と併用の型 ここは言い切ります。版管理する図はテキストを正にしてください。作図ツールのファイルはバイナリ相当で差分が読めず、レビューが「新しい画像を見比べる」作業に退化します。 ただし社外提出用の資料では、テキスト記法の図は体裁が硬く、凡例や注記も置きづらい。併用の型はこうです。テキストを唯一の正としてリポジトリで管理し、提出時にそこから画像を書き出して資料に貼る。作図ツール側で直接編集するのは禁止にします。両方を人手で更新する二重管理は、3か月も経てばずれるのが常です。ずれた時にどちらが正か決まっていない図は、その時点で信用を失います。 ## データ連携図を作らないと決める判断と作っても失敗する3パターン 図はコストです。描く判断と同じくらい、描かない判断に価値があります。 ### 連携が2本以下のときに図を作らず一覧表だけで足りる条件と例外 連携するインタフェースが2本以下で、相手が1システム、方式も同一なら、図は不要です。外部インタフェース一覧の表だけで全員が理解できます。図を描いても情報量は表を超えず、更新の手間だけが増えます。 例外は2つ。相手が社外の取引先で、連携仕様を契約書や覚書の別紙として渡す場合は、1枚描いたほうが認識の齟齬を防げます。もう1つは、連携の追加が半年以内に見込まれている場合。将来3本以上になるなら最初から図の器を作っておくほうが安く済みます。 ### 1枚に全部載せて誰も読まない壁一面の図になる失敗と分冊の手当て 最も多い失敗が、全システムを1枚に並べた壁一面の図です。ノードが30を超えると、矢印の交差を追うだけで読み手の集中が切れます。 手当ては分冊です。全体はレベル0のコンテキスト図1枚に抑え、業務領域ごと（販売・調達・会計・人事）にレベル1を分けます。各図に載るノードは9個以内。1枚あたりの情報量を落とすと、レビューで指摘が出るようになります。指摘が出ない図は、読まれていないと考えたほうが実態に合っています。 ### 更新されない図が残す実害と廃止・凍結の判断を決める運用ルール 3つめの失敗が、更新されないまま残る図です。実害は2段階で出ます。障害対応のときに現存しない経路を前提に調査して時間を失うこと。そして刷新の見積もりで、すでに廃止済みのインタフェースまで改修対象に数えて金額が膨らむことです。 ルールは単純にします。図には最終更新日と対象リリース番号を必ず書く。6か月更新がなく、かつ参照している担当者が特定できない図は「凍結」と明記して、設計の根拠に使うことを禁じます。凍結の宣言をせずに放置された図は、誰かが必ず現行として読みます。廃止か凍結かを決めて書き残すところまでが、図を作った側の仕事です。 ## よくある質問 データ連携図をこれから描く担当者から実際に受ける質問を5つ挙げ、判断できる形で答えます。 ### データ連携図とシステム構成図の違いは何ですか？ 読み手と載せる情報が違います。データ連携図はシステム間を流れる業務データの発生源・行き先・向きを描き、読み手は業務部門と情報システム部門です。システム構成図はサーバ・ネットワーク・冗長化などの配置を描き、読み手はインフラ担当になります。可用性ゾーンやロードバランサを連携図に描くと論点が混ざるため、2枚に分けてください。 ### データ連携図はExcelやPowerPointで作ってもよいですか？ 提出用の資料としてなら問題ありません。判断が分かれるのは「正」をどこに置くかです。ExcelやPowerPointのファイルは差分が読めないため、更新レビューが画像の見比べになり、変更の見落としが起きます。連携が5本を超えて継続的に増える見込みがあるなら、Mermaidなどのテキスト記法をリポジトリに置いて正とし、提出時に画像を書き出す運用へ切り替えたほうが保守が続きます。 ### DFDのレベルはどこまで分解すればよいですか？ 要件定義で提出するのはレベル1までで足ります。停止条件は、1つのプロセスが「1本の外部インタフェース」「1画面」「1ジョブ」のいずれかに対応する粒度に達したときです。それ以上割ったものはプリミティブプロセスと呼ばれ、分解しても新しい合意事項が生まれません。レベル2以降は基本設計の作業なので、要件定義の期間中にレベル2を描き始めているなら、工程の線引きがずれている合図と考えてください。 ### データ連携図に性能や可用性などの非機能要件は書きますか？ 図には書きません。矢印のラベルに応答時間やSLAを載せると、線の数だけ文字が増えて読めなくなります。想定件数・最大レコード長・許容遅延・再送回数といった数値は外部インタフェース一覧の表に置き、図の矢印とはインタフェースIDで突き合わせます。ただし例外が1つあり、日次バッチと即時APIのように連携の性格そのものが違う場合は、矢印のラベルに契機と頻度だけは書いてください。方式選定の判断がその2語で決まるためです。 ### 連携図のサンプルやテンプレートは何から作り始めればよいですか？ 白紙から描かず、現行のジョブ定義とアクセスログの棚卸しから始めます。手順は、稼働中の連携を一覧表に洗い出す、送信元と宛先だけの矢印でレベル0を1枚描く、業務領域ごとにレベル1へ割る、の3段階です。テンプレートを探すより、自社の連携本数を確定させるほうが先に効きます。本数が20を超えるなら、最初から業務領域ごとの分冊を前提に器を作ってください。 ## 関連記事 - [ER図とは？書き方・エンティティやリレーション・カーディナリティを実装目線で解説](https://www.issoh.co.jp/tech/details/13484/)：連携図には書かないデータの保持構造を、エンティティとカーディナリティの粒度で扱っています - [シーケンス図とは？UMLの書き方・ライフラインやメッセージ・複合フラグメントを解説](https://www.issoh.co.jp/tech/details/13482/)：1回の処理の時間軸とメッセージの往復を描く、基本設計側の図の書き方です - [API連携の実装方法とは？REST・認証・エラー処理までの手順を実装者向けに解説](https://www.issoh.co.jp/tech/details/15351/)：図で確定した連携を実装に落とすときの認証方式とエラー処理の設計を扱っています - [API連携とは？仕組み・データ連携との違い・導入判断までわかりやすく解説](https://www.issoh.co.jp/column/details/15354/)：API連携とデータ連携という言葉の使い分けを、導入判断の視点から整理しています - [API連携ツールの選び方｜iPaaS・データ連携基盤・受託開発の使い分けを解説](https://www.issoh.co.jp/column/details/16376/)：連携図で本数と方式が見えたあとの、実現手段の選び分けを扱っています --- 出典: [データ連携図の書き方｜システム関連図とDFDの粒度と記法・Mermaidでの版管理]()（株式会社一創）