データ連携図とは？方式別の描き方と6つの連携パターンを解説

システム刷新やデータ基盤の構築を進めると、「どのシステムからどのデータが、どの方式で流れているのか」を1枚で示す資料が必ず求められるのが通例です。その役割を担うのがデータ連携図であり、ベンダーへの見積もり依頼や障害時の影響調査でも最初に開かれる資料になります。

ところが実際の現場では、矢印だけが引かれた図や、連携方式が書かれていない図が多く残っています。API・ETL・EAI・CDC・EDI・iPaaSといった方式の違いが図に表れていないため、移行対象の洗い出しや二重経路の発見ができず、調査のやり直しが発生するのです。

本記事では、データ連携図に載せるべき5つの要素と連携方式ごとの図のパターン、棚卸しからレビューまでの作成手順、失敗パターンと活用事例を解説します。読者が自社の連携図に方式と契機のラベルを付け、刷新・運用の判断材料として使える状態にするための手順と判断基準を確認してください。

データ連携図とは：システム間のデータの流れと連携方式を可視化する図

データ連携図は、社内外のシステム同士の間でデータがどの方向に、どの方式で、どの契機で流れるのかを1枚に表した図です。システム構成図やDFD、ER図と混同されやすい資料ですが、読み手も描く対象も異なります。ここでは定義と5つの記載要素、他の図との線引き、必要になる場面、作成で得られるメリットの順に整理し、以降の方式別パターンや作成手順を読む前提をそろえます。

データ連携図の定義と記載する5つの要素：送信元・宛先・データ名・連携方式・契機

データ連携図は、システムをノード（箱）、データの流れを矢印で表し、矢印ごとに「何のデータが、どの方式で、いつ流れるか」を書き込んだ図です。最低限記載すべき要素は送信元・宛先・データ名・連携方式・契機の5つで、このうち1つでも欠けると移行や障害対応のたびに調査が発生します。たとえば「販売管理→会計システム」という矢印に「売上伝票・ファイル連携（CSV）・日次23時」と添えるだけで、夜間バッチの失敗時にどの業務が止まるかが読み取れます。

現場でよくあるつまずきは、矢印は引いたものの契機を「随時」とだけ書いてしまうケースです。随時には「業務操作のたびに都度」と「5分間隔のポーリング」の両方が含まれ、障害時の復旧手順がまったく変わります。契機は「都度（イベント駆動）」「定期（5分・時間・日次・月次）」「手動」の3区分で書き分けてください。データ名も「顧客データ」のような粒度では不十分で、「顧客マスタ（差分のみ）」「受注明細（全件）」のように差分か全件かまで添えると、データ量の見積もりに直結します。

データ統合とは？統合の目的や初心者向けの進め方を解説

システム構成図・DFD・ER図との違い：読み手と描く対象の線引き

データ連携図と似た図は複数ありますが、描く対象と読み手が異なります。システム構成図はサーバー・ネットワーク・ミドルウェアといった物理的な配置を示す図で、主な読み手はインフラ担当者です。DFD（データフロー図）は業務プロセスの中でデータがどう加工されるかを階層的に分解する図で、業務分析の資料として使われます。ER図はデータベース内部のエンティティ同士の関係を定義する図であり、テーブル設計者が読む資料です。

判断基準は「業務部門の担当者が説明なしで読めるか」で、読めない情報はデータ連携図から外してください。たとえばサーバーのIPアドレスやLBの構成は構成図へ、テーブルのカラム定義はER図へ分けると、連携図は1枚で2つのシステムの関係に集中できます。既存資料にすべてが混在している場合は、無理に描き直さず、まずデータの流れだけを抜き出した別紙を作る方が1〜2日で済み、現実的です。読み手が迷う要素を1つ減らすだけで、レビューでの質問が減り、会議時間も短くなります。

ER図とは？基本ルールから書き方まで徹底解説！

データ連携図が必要になる場面：システム刷新・SaaS導入・データ基盤構築

データ連携図が最初に求められる場面は、基幹システムの刷新やERP移行です。移行対象のシステムに出入りする連携を漏れなく洗い出さなければ、ベンダー見積もりの前提が崩れ、追加費用の原因になります。SaaS導入の場面でも、既存の販売管理や会計とのつなぎ方を検討するために、現行の連携の全体像が必要です。クラウドDWHを中心にしたデータ基盤構築でも、どのシステムからどの頻度でデータを取り込むかを決める前に、現行の流れを図にする作業が先に来ます。

刷新案件での目安として、連携本数が20本を超えたあたりから、一覧表だけでは経路の重複や抜けに気づけなくなるのが実情です。連携図を作るタイミングは「要件定義の前」が原則で、要件定義の途中から作り始めると、発見した連携のたびに要件が揺れて手戻りが発生します。逆に連携本数が10本未満で、かつ対象システムが2〜3個なら、インタフェース一覧の表だけで足りる場合もあります。その場合は図の作成に工数をかけず、一覧に方式と契機の列を追加するだけで同等の効果が得られる場合がほとんどです。

データ分析基盤とは？基盤を構築するための5つのステップ

データ連携図を作成するメリット：重複経路の発見・合意形成の迅速化・障害影響範囲の特定

連携図を作る最大のメリットは、一覧表では見えない重複経路が一目で分かることです。たとえば販売管理から会計へ売上データを送る経路が、旧来のファイル連携とETL経由の2本存在しているケースは珍しくありません。どちらかが廃止漏れのまま動き続けており、二重計上や保守コストの原因であり、担当者も片方の存在を忘れているのが常です。図に描くと同じ2つのノード間に矢印が2本引かれるため、担当者が気づかなかった経路でも、レビューの場で指摘されます。

合意形成の面でも、業務部門・情シス・ベンダーの3者が同じ図を見て話せるため、認識のズレが減るのが利点です。障害時には「止まったシステムから出ている矢印を追う」だけで影響範囲を特定でき、調査時間が数時間から数十分に短縮されます。メリットを定量的に示したい場合は、作成前後で2つの指標を記録してください。「障害時の影響範囲の特定にかかった時間」と「見積もり後に発覚した追加連携の件数」で、次の案件で図の更新工数を確保する根拠になります。

データ連携図に記載する連携方式の種類：API・ETL・EAI・CDC・EDI・iPaaSの特徴

連携図の矢印に書き込む「方式」とは、データが流れる仕組みそのものです。同じ「販売管理→会計」の矢印でも、API連携なら業務操作のたびに即時で流れ、ETL連携なら夜間にまとめて流れるため、障害時の影響や改修範囲がまったく違います。ここでは図に載せるべき7つの方式について、仕組みの要点と図上での書き方、採用の判断基準を順に整理し、最後に4軸の比較表にまとめます。

API連携：都度・リアルタイムでシステム同士が直接やり取りする方式

API（Application Programming Interface）連携は、送信元のシステムが宛先のAPIを直接呼び出し、1件ごとにデータを受け渡す方式です。在庫引当や与信確認のように、業務操作の結果を数秒以内に反映させたい場面で選ばれます。図上では矢印に「REST API・都度」のように書き、呼び出し元から呼び出し先へ向けて矢印を引きます。レスポンスで返るデータが業務上の意味を持つ場合は、逆向きの細い矢印を添えてください。

現場でのつまずきは、SaaSのAPI呼び出し回数制限（レートリミット）を見落とすことです。たとえば1日あたり数万回の上限があるSaaSに対して、全件再送のバッチをAPIで組むと、月初の処理が途中で止まります。判断基準として、1日あたりの件数が数千件以下で即時性が必要ならAPI、数十万件を扱うならバッチ系の方式に切り替えてください。連携図には上限値を注記として残しておくと、増量時の設計変更の判断が早くなります。

ETL／ELT連携：DWH・データ基盤へバッチで集約する方式

ETL（Extract・Transform・Load）は、業務システムからデータを抽出し、加工してからDWHに格納する方式です。ELTは順序を変え、生データを先にDWHへ格納してからSQLで加工する点が違いです。どちらも夜間や時間ごとのバッチで動くため、連携図では「ETL・日次2時」「ELT・1時間ごと」のように契機を必ず添えます。流れは業務システムからDWHへの一方向が基本で、逆向きの矢印は通常ありません。

図に載せる粒度で注意したいのは、ETLツール内部の処理ステップまで描かないことです。ジョブの中で10個の変換が走っていても、連携図ではツールを1つのノードとして置き、入出力の矢印だけを描くのが原則です。ETLとELTの選び分けは、加工ロジックが業務システム側に依存するならETL、DWHの計算資源が十分でSQLで加工を完結できるならELTが向いています。ステップ単位の詳細はジョブ定義書へ切り出し、連携図からは参照先の文書名だけを書いておくと、図が肥大化しません。

データウェアハウス（DWH）とは？具体例を用いて解説！

EAI／ESB連携：ハブを介して社内システムを統合する方式

EAI（Enterprise Application Integration）とESBは、社内システムの中央にハブを置く方式です。ESBはEnterprise Service Busの略で、EAIと同じくハブ型の統合基盤を指します。各システムはハブとだけ接続し、ハブが振り分けを担います。システムが10個あるときに個別接続すると最大45本の経路が必要ですが、ハブを置けば10本で済む計算です。図上ではハブを中央に大きめのノードとして置き、各システムからハブへ、ハブから各システムへ矢印を引きます。ハブ内部のルーティングルールは図に描かず、「配信先：会計・物流・CRM」のようにハブからの矢印に書き添えます。

現場でよくあるのは、EAIを導入したのに、一部のシステムがハブを経由せず直接つながったまま残っているケースです。この状態を連携図で可視化すると、ハブを素通りする矢印が目立つため、統合の未完了箇所が分かります。導入済みの製品名（たとえばDataSpiderやASTERIA Warpなど）はノード名に併記しておくと、保守担当者が設定画面を開く際に迷いません。保守体制の面では、ハブの設定を変更できる担当者が社内に2名以上いるかを確認し、1名しかいない場合は図に「属人化」の注記を付けてください。

CDC連携：データベースの変更差分のみを準リアルタイムで転送する方式

CDC（Change Data Capture）は、データベースのトランザクションログを読み取る方式です。追加・更新・削除された行だけを、数秒から数分の遅れで宛先に転送する仕組みです。全件抽出のバッチと異なり業務システムへの負荷が小さく、夜間バッチの枠に収まらなくなった大量データの連携で採用されます。図上では「CDC・準リアルタイム（遅延1〜5分）」のように遅延の目安を書くと、業務部門が「どの時点のデータを見ているか」を判断できます。

CDCで注意すべきは、送信元のテーブル構造が変わると転送が止まる点です。カラム追加を伴うリリースのたびに連携の設定変更が必要になるため、連携図には対象テーブル名と「スキーマ変更時に要確認」の注記を残してください。採用の判断基準は、1日の更新件数が数十万件以上で、かつ業務システム側の夜間停止時間が確保できない場合です。更新件数が数万件程度なら、日次のETLで十分に処理できるため、CDCの導入コストに見合いません。

データレプリケーションとは？初心者向け解説

EDI連携：取引先と標準フォーマットで受発注データを交換する方式

EDI（Electronic Data Interchange）は、取引先との間で受発注・納品・請求のデータを、業界標準のフォーマットで交換する方式です。流通業なら流通BMS、製造業なら業界ごとの標準があり、VAN事業者やWeb-EDIサービスを経由してデータが流れます。連携図では社外のノードを点線の枠で囲い、「EDI（流通BMS）・1日3回」のように標準名と回数を書きます。社内側の受け口となるシステムとの間には、変換処理を行うノードが挟まることが多いため、省略せずに描いてください。

よくあるつまずきは、取引先ごとにフォーマットや接続方式が違うのに、図では「取引先」の1ノードにまとめてしまうことです。新規取引先の追加時に、どの変換設定を流用できるかが図から読めなくなるのが問題です。取引先が5社以上あるなら、接続方式ごと（流通BMS・固定長・Web-EDI）にノードを分け、各ノードに社数を書く方が実務で役立ちます。2024年のISDN回線廃止のように、通信方式の切り替えが必要になる場面でも、方式別にノードが分かれていれば、影響を受ける取引先数をすぐに数えられます。

iPaaS連携：クラウド基盤でSaaS間をノーコードでつなぐ方式

iPaaS（Integration Platform as a Service）は、クラウド上の連携基盤です。SaaS同士やSaaSと社内システムを、ノーコードまたはローコードでつなぎます。Workato、Boomi、Make、Zapierなどが代表例で、SaaS側のコネクタが用意されているため、API仕様を1つずつ読まなくても連携を組める点が利点です。図上ではEAIと同じくハブ型に描きますが、ノードがクラウド上にある点を示すため、社内ネットワークとの境界線を引いて外側に置くと分かりやすくなります。

iPaaSの落とし穴は、現場部門が自由に連携を追加できるため、情シスが把握していない経路が増えることです。1年運用すると、図に載っていない連携が10本以上見つかるケースもあります。対策として、iPaaSの管理画面でレシピやフローの一覧をエクスポートし、四半期ごとに連携図と突き合わせるルールを設けてください。EAIとiPaaSの選び分けは、接続先の大半がSaaSならiPaaS、オンプレミスの基幹システムが中心で複雑な変換が必要ならEAIが向いています。

ファイル連携（CSV・SFTP）：レガシーシステムに多い方式と図上での扱い

ファイル連携は、送信元がCSVや固定長のファイルを出力し、SFTPや共有フォルダ経由で宛先が取り込む方式です。メインフレームや導入から10年以上経った基幹システムでは、今も連携の過半数がこの方式で動いています。図上では「ファイル連携（CSV・SFTP）・日次1時」のように、形式と転送手段と契機の3つを書きます。中継する共有フォルダやファイルサーバーが障害の原因になりやすいため、省略せずノードとして置いてください。

現場でのつまずきは、ファイルの出力と取り込みが別々のジョブで動いており、片方だけ時刻が変更されて取り込み漏れが起きることです。矢印に「出力1時・取込2時」のように両方の時刻を書くと、時刻の順序が崩れていないかをレビューで確認できます。刷新の際にはファイル連携をAPIやETLに置き換える判断が必要になりますが、1本あたりの置き換え工数は小さくても、本数が50本を超えると数か月単位の作業です。図で本数を数え、業務影響の大きい経路から順に置き換え対象を決めてください。

レガシーシステムとは？放置するリスクと脱却時の5つのポイント

連携方式の比較表：リアルタイム性・データ量・接続範囲・保守性の4軸

7つの方式を1つずつ理解しても、現場で選ぶ際には横並びの比較が必要です。比較軸はリアルタイム性、1回あたりのデータ量、接続範囲（社内か社外か、SaaSか基幹か）、保守性（社内で設定を変更できるか）の4つに絞ると、方式選定の議論が短く済みます。軸を増やすほど表が読めなくなるため、コストやセキュリティは方式を絞り込んだ後に個別に検討します。以下の表は、各方式を連携図に載せる際の標準的な契機の書き方も含めてまとめたものです。

表を連携図の凡例に転記しておくと、レビューの場で「この矢印はなぜAPIなのか」という質問に即答できます。判断に迷うときは、リアルタイム性の要件を最初に確認し、「数秒以内」が業務上必須でなければバッチ系の方式を第一候補にしてください。即時性を要求する業務は想像より少なく、聞き取りを行うと「翌朝までに反映されていれば足りる」という回答が7〜8割を占めます。残りの2〜3割についても、「誰が、何分以内に、何を判断するか」を確認すると、本当に即時性が必要な業務はさらに絞られます。

連携方式ごとのデータ連携図パターン：6つの描き方と向いているケース

方式が決まれば、図の形もおおむね決まるものです。API中心なら少数のノードを直接つなぐ形に、EAIやiPaaS中心なら中央にハブを置く形になり、ETL中心なら流れがDWHへ一方向に集まります。ここでは実務で遭遇する6つのパターンについて、ノードの配置、矢印の引き方、向いているケースと向かないケースを順に解説します。自社の現行図がどのパターンに近いかを確認しながら読み進めてください。

ポイントツーポイント型：API直接連携を中心とした少数システム構成

ポイントツーポイント型は、システム同士を仲介なしで直接つなぐ最も単純な形です。ノードを横一列または業務の流れに沿って左から右へ並べ、API連携の矢印を直接引きます。対象が3〜5システムで連携本数が10本以内なら、この形が最も読みやすく、作図も半日で終わる規模です。SaaS導入初期のスタートアップや、1つの業務部門内で完結する構成に向いています。ノード同士の距離を均等にし、矢印が斜めに交差しないよう配置するだけで、説明なしで読める図になります。

向かないのは、システムが6個を超えて矢印が交差し始めた段階です。ノード数がnのとき最大でn×（n−1）÷2本の経路が生まれるため、8システムで28本、10システムで45本と急増し、1つの改修が複数の相手先に波及します。連携図を描いた時点で矢印が10本を超え、かつ今後も接続先が増える見込みなら、次に述べるハブを中心に置く形への移行を検討する判断材料になります。作図ツールはdraw.ioやLucidchartで十分で、ノードは四角、矢印は方式ごとに線種を変えてください。

ハブ＆スポーク型：EAI・iPaaSを中心に置いた多システム統合構成

ハブ＆スポーク型は、中央にEAIまたはiPaaSのハブを置き、各システムをスポーク（車輪の輻）のようにハブへ接続する形です。ハブを中心に円形または放射状にノードを配置し、各システムとハブの間に双方向の矢印を引きます。ハブからの配信先は、矢印のラベルに「配信：会計・物流」のように書き、ハブ内部のルーティングは省略が原則です。社内システムが10個を超え、相互にデータをやり取りする構成に向いています。放射状の配置では、ハブから各ノードまでの距離をそろえると、矢印の長さが均一になり、本数を数えやすくなります。

よくあるつまずきは、ハブを経由しない「抜け道」の直接接続を描き忘れることです。EAI導入前から残っていたファイル連携が数本残っているのが通常で、これを描かないと刷新時の移行漏れになります。棚卸しの際にはEAIのログに現れない連携を疑い、ジョブ管理ツールの定義も必ず確認します。ハブを経由する矢印は実線、経由しない矢印は破線で描き分け、凡例に「ハブ未経由：要移行判断」と明記してください。ハブの製品保守期限（EOL）も図の注記に残しておくと、更改時期の議論が早く始められます。

集約型：ETL／ELTでDWHへ流れを一方向に揃えた分析基盤構成

集約型は、左側に業務システム群、右側にDWHやデータレイクを置き、ETL／ELTの矢印をすべて左から右へ一方向に引く形です。分析基盤の構築時に描く典型的なパターンで、矢印が交差しないため、取り込み対象と頻度が一覧のように読めます。DWHの右側にBIツールや帳票システムを置き、「参照」の矢印を添えると、データの利用先まで1枚に収まります。ノードの縦方向の並びは、業務の流れ（販売→購買→生産→会計）にそろえると、業務部門が自分の領域を探しやすくなるのが利点です。

集約型で見落としやすいのは、DWHから業務システムへ戻る「逆方向の連携」で、たとえば分析結果のスコアをCRMへ書き戻す経路がこれにあたります。一方向にそろえた図に逆向きの矢印が1本でも入ると、障害時の影響範囲が分析基盤の外へ広がるため、色を変えて目立たせてください。向いているのは、取り込み元が5〜30システムあり、リアルタイム性の要件が日次で足りるケースです。更新頻度が時間単位以下の連携が増えてきたら、次のストリーム型との組み合わせを検討します。

データアーキテクチャとは？基本概念と設計の手順、注意点までを解説

ストリーム型：CDCでイベントが流れる準リアルタイム構成

ストリーム型は、CDCやメッセージキュー（Apache Kafka、Amazon Kinesisなど）を中央に置く形です。送信元から流れ込んだ変更イベントを、複数の宛先が購読します。図では中央に横長のストリーム基盤を描き、上側に送信元、下側に購読するシステムを配置すると流れが読みやすくなるのが特徴です。矢印には「CDC・遅延1〜5分」「トピック名：order-events」のように、遅延の目安とイベントの単位を書きます。

現場のつまずきは、購読側のシステムが増えたときに、誰がどのイベントを使っているかが把握できなくなることです。購読側の矢印には必ず「利用目的（在庫更新・通知）」を添え、半年ごとに不要な購読を棚卸ししてください。向いているのは、1日数十万件以上の更新を複数システムへ即時配信したいECや製造現場です。更新件数が少ない、または宛先が1つしかない場合は、CDCを単純なDB間のレプリケーションとして描く方が、図も運用も簡単です。

社外接続型：EDI・APIで取引先・外部サービスと境界を越える構成

社外接続型は、図の中央に社内と社外の境界線（点線）を引き、取引先や外部サービスを境界の外側に置く形です。EDIによる受発注、決済代行サービスや物流業者とのAPI連携、Web-EDIサービスの3種類が境界を越える代表例になります。社内側は業務システムをまとめて右側に置き、境界を越える矢印が左から右へ流れるようにそろえます。境界線上には、ファイアウォールやAPIゲートウェイ、VANサービスといった中継点を必ず描き、どこで認証や変換が行われているかを示してください。

境界を越える矢印には、方式と契機に加えて「認証方式（IP制限・証明書・APIキー）」を書きます。社外接続はセキュリティ監査の対象になりやすく、監査のたびに調べ直すと1件あたり数日かかるためです。取引先が10社を超える場合は、1社ずつノードを置かず、接続方式ごとにまとめたノードに社数を書く方が、追加時の作業量を見積もりやすくなります。新規取引先の追加にかかる期間も、方式ごとに「流通BMS：2週間」「固定長：4週間」のように注記しておくと、営業部門からの問い合わせに即答できます。

混在型：複数方式が共存する現行システムの描き方と凡例の付け方

現行システムを描くと、ほとんどの企業ではAPI・ETL・EAI・ファイル連携が混在した図になります。混在型を描くコツは、無理に1つの配置ルールへ当てはめず、ハブ＆スポーク型を基本の骨格にしながら、集約型のDWH部分を右側に、社外接続を左下にまとめることです。方式ごとに線種と色を分け、凡例を図の右上に固定で置きます。線種の例は、API＝実線、ETL＝太線、ファイル＝破線、EDI＝二重線、CDC＝点線です。

混在型の図は情報量が多くなるため、A3用紙1枚に収まらなくなった時点で、業務領域ごとの分割図を作ります。全体図では各領域を1つのノードにまとめ、領域間をまたぐ連携だけを描くと、全体と詳細の2階層で管理できます。凡例には線種と色の対応だけでなく、「廃止予定」「移行対象」「属人化」の注記記号も含め、図を見た人が方式と状態の両方を読めるようにしてください。凡例のない混在型の図は、作成者以外には方式が読めず、結局一覧表に戻って調べることになります。

データ連携図の作成手順：棚卸しからレビューまでの5ステップ

パターンが決まったら、実際の作図に入る段階です。作成の流れは、現行の連携を一覧化する棚卸しから始まり、図の目的と粒度の設定、ノードの配置、矢印へのラベル付け、関係者レビューの順に進みます。5つのステップを飛ばさずに踏むことで、方式と契機が抜けた図になる事態を防げます。以下では各ステップで使うツール、工数の目安、つまずきやすい点を順に説明するので、自社の進め方と照らしてください。

STEP1：ジョブ定義・バッチ・APIログから現行の連携を一覧化する

最初の作業は、現行の連携をもれなく一覧にすることです。情報源は4つあります。ジョブ管理ツール（JP1、Systemwalker、Rundeckなど）のジョブ定義、ETLツールのジョブ一覧、APIゲートウェイやWebサーバーのアクセスログ、EAI・iPaaSのフロー一覧です。ジョブ管理ツールからはジョブ名・実行時刻・実行コマンドをエクスポートし、コマンドに含まれるファイルパスや接続先から送信元と宛先を特定します。この段階ではExcelやスプレッドシートに「送信元・宛先・データ名・方式・契機・情報源」の6列で記録してください。

現場でのつまずきは、担当者への聞き取りだけで一覧を作り、ログに残っている連携を見落とすことです。聞き取りで把握できる連携は全体の6〜7割で、残りはジョブ定義やログを読んで初めて見つかります。棚卸しの工数は、対象システムが10個程度で連携が50本前後なら、2人で2〜3週間が目安です。一覧には「最終実行日」の列も追加し、半年以上実行されていない連携は廃止候補として色を変えておくと、後のAs-Is／To-Be整理で役立ちます。

STEP2：図の目的と読み手を決めて粒度（全体図／業務領域別）を設定する

一覧ができたら、図を描く前に「誰が何のために見る図か」を決めます。経営層や業務部門への説明が目的なら、システムを業務領域単位にまとめた全体図を1枚作ります。刷新プロジェクトの見積もりや移行計画が目的なら、業務領域ごとの詳細図を複数枚作り、全体図から参照する2階層構成にしてください。粒度を決めずに描き始めると、詳細すぎて経営層が読めない図か、粗すぎて見積もりに使えない図のどちらかになります。この判断は作図ツールを開く前に、A4で1枚の「図の目的書」として関係者に合意を取ると後戻りしません。

判断基準として、ノード数が15個以下で矢印が30本以内なら1枚の全体図で足りる規模です。それを超える場合は、販売・購買・生産・会計といった業務領域ごとに分割し、各図のノードは10個前後が上限です。図の目的と読み手を表紙に1行で書いておくと、後から図を更新する担当者が「何を載せ、何を省くか」を判断できます。読み手が業務部門の場合は、システム名を業務上の通称（「受注システム」「経理システム」）で書き、製品名は括弧で添える方が伝わります。

STEP3：システムをノードとして配置し、データの流れを矢印で結ぶ

作図ツールはdraw.io（diagrams.net）かLucidchart、社内標準がMicrosoft製品ならVisioやPowerPointでも構いません。draw.ioの場合は、左のシェイプパネルから四角を選んでシステム名を入力し、ノードの上にカーソルを置くと表示される青い矢印をドラッグして接続します。接続後に矢印を選び、右側の「スタイル」パネルで線種と色を方式ごとに設定してください。先にノードをすべて配置してから矢印を引く方が、後の整列作業が減ります。

配置の原則は、データの流れが左から右、または上から下へ向かうようにノードを並べることです。社外は左端、業務システムは中央、DWHやBIは右端に置くと、混在型でも読み順が定まります。矢印が交差する場合は、ノードの位置を入れ替えて交差を減らすことを優先し、それでも残る交差は「ジャンプ（跨ぎ線）」の設定で区別するのが定石です。作図の工数は、ノード15個・矢印30本程度の図で初版が1〜2日、レビュー後の修正を含めて1週間を見ておくと余裕があります。

STEP4：矢印にデータ名・方式・契機（都度／日次／月次）をラベル付けする

このステップが連携図の価値を決めます。矢印をダブルクリックしてラベルを入力し、「データ名／方式／契機」の順で書く形式を全矢印で統一してください。例は「受注明細（全件）／ETL／日次2時」「在庫数／API／都度」「請求データ／EDI（流通BMS）／月次1日」です。契機は「都度」「5分」「時間」「日次」「週次」「月次」「手動」の7区分から選び、日次以下の場合は実行時刻も添えます。ラベルの書式がそろっていれば、後から一覧へ機械的に転記でき、図と一覧の突き合わせが短時間で済みます。

ラベルが長くなって図が読みにくい場合は、矢印に番号を振り、番号とラベルの対応表を図の下に置く方法も有効です。ただし、番号だけの図は一覧と照合しないと読めなくなるため、全体図では番号方式、詳細図では直書き方式と使い分けてください。方式と契機のどちらかが分からない矢印は「要確認」と赤字で書いたまま残し、空欄にしないことがレビューで抜けを拾うコツです。ラベル付けの作業は矢印30本で半日程度ですが、確認待ちの矢印が多いと1〜2週間延びることがあります。

STEP5：インタフェース一覧と対応付け、業務部門・情シス・ベンダーの順でレビューする

図が描けたら、STEP1で作った一覧に「図上の矢印番号」の列を追加し、一覧の全行が図に載っているかを突き合わせます。一覧にあって図にない連携は描き忘れ、図にあって一覧にない矢印は根拠不明の連携として、どちらも解消してから次に進みます。レビューの順番は、業務部門→情シス→ベンダーの順が効率的です。業務部門には「この流れで業務が回っているか」を確認し、情シスには方式と契機の正しさを、ベンダーには自社製品に関わる矢印の正確性を確認してもらいます。

レビュー会議は1回60分で、図を1枚ずつ投影しながら矢印を順に読み上げる形式が確実です。指摘はその場で図に赤字で書き込み、会議後に反映して翌日までに再配布します。レビューで最も多い指摘は「この連携はもう動いていない」という廃止漏れで、全体の1〜2割の矢印がこれに該当する企業も珍しくないのが実態です。レビュー後は図と一覧の両方に版番号と日付を入れ、以降の変更は必ず両方を同時に更新するルールを次の章で述べる運用に引き継ぎます。

データ連携図を実務で機能させる作成ポイント：方式選定の判断基準と運用ルール

図が完成しても、方式の選定基準が共有されておらず、更新も止まってしまうと、半年後には誰も信用しない資料になります。ここでは方式選定の判断基準、線種と凡例の設計、エラー系の描き方、As-Is／To-Beの2枚構成、図と一覧の同時更新ルールの5点を、作成後の運用まで見据えて解説します。

連携方式の選定基準：リアルタイム性・データ量・接続先の数・社内の保守体制

新設や改修の連携で方式を選ぶ際は、リアルタイム性、データ量、接続先の数、社内の保守体制の4つを順に確認します。リアルタイム性は「数秒以内に反映が必要か」で切り分け、必要ならAPIかCDC、不要ならETLやファイル連携を候補にします。データ量は1回の連携で流れる件数で判断し、数千件以下ならAPIでも処理できますが、数十万件なら差分転送のCDCか全件バッチです。接続先が多くて相互にやり取りするならEAIかiPaaS、1対1なら直接連携で足ります。

見落とされやすいのが4つ目の保守体制で、社内にAPI開発者がいないのにAPI連携を選ぶと、改修のたびにベンダー依頼となり、1件数十万円の費用が発生するのが通例です。方式の選定は技術的な最適解よりも「社内で設定を変更できる人が2名以上いる方式」を優先する方が、3年後の保守コストが下がります。判断の記録として、矢印ごとに「選定理由」を一覧の備考欄に1行で残しておくと、担当者交代時に方式変更の是非を再検討する手間が省けます。

方式ごとに線種・色を分けて凡例を付け、一目で混在状況を読めるようにする

方式の混在を一目で読めるようにするには、線種と色の2軸で描き分けるのが基本です。線種は方式に割り当て、API＝実線、ETL＝太線、ファイル＝破線、EDI＝二重線、CDC＝点線とします。色は状態に割り当て、通常＝黒、移行対象＝青、廃止予定＝赤、新設＝緑とすると、方式と状態を同時に読めます。モノクロ印刷でも線種で方式が区別できるため、色だけに頼らない設計が実務では安全です。色は社内の既存ルール（たとえば赤＝要注意）と衝突しないよう、情シスの文書規程を先に確認します。

凡例は図の右上に固定で置き、全図で同じ順序で並べます。draw.ioでは凡例をグループ化してライブラリに登録しておくと、新しい図に同じ凡例をドラッグで追加できる仕組みです。現場でよくあるつまずきは、担当者ごとに線種の割り当てが違う図が混在し、図を横断して読めなくなることです。ライブラリはチームで共有し、更新があれば版番号を上げて周知します。線種と色の割り当て表を社内の作図ルールとして1枚にまとめ、図を作る前に全員が同じ表を参照する運用にしてください。

正常系だけでなくエラー通知・取消データの戻りも矢印として描く

多くの連携図は正常系の流れだけを描いていますが、実務で問い合わせが来るのは異常時です。ETLジョブの失敗通知がどこへ飛ぶか、APIがエラーを返したときに再送するのか手動対応か、受注の取消データが会計へどう戻るかを矢印として描いてください。エラー通知の矢印は細い灰色の線で、取消や訂正データの戻りは正常系と同じ線種で逆向きに引き、ラベルに「取消」と明記します。再送の有無も「自動再送（3回まで）」「手動再実行」のように矢印の注記に書くと、運用担当の判断が速くなります。

取消データの戻りを描き忘れると、刷新時に「取消の連携が実装されていない」ことが受け入れテストで初めて判明し、リリースが数週間延びる事態の原因です。正常系の矢印1本につき、「失敗時にどうなるか」「取消・訂正時にどう戻るか」の2つを確認する観点をレビュー項目に加えてください。すべての矢印に異常系を描くと図が煩雑になるため、業務影響が大きい連携（売上・請求・在庫）に限定し、それ以外は一覧の備考欄に書く運用が現実的です。

As-Is／To-Beの2枚を同じ記法で描き、新設・改修・廃止の連携を確定させる

刷新案件では、現行（As-Is）と刷新後（To-Be）の2枚を同じノード配置と同じ凡例で描きます。As-Isの図をコピーしてTo-Beを作ると、配置がずれず比較しやすいのが利点です。配置をそろえると、2枚を並べたときに消えた矢印が廃止、増えた矢印が新設、ラベルが変わった矢印が改修として読み取れます。To-Be図では方式変更を伴う矢印（たとえばファイル連携→API）を色で強調し、移行時に業務部門の確認が必要な連携を目立たせてください。

2枚を比較した結果は「新設・改修・廃止・現状維持」の4区分で一覧に記録し、ベンダー見積もりの依頼書に添付する流れです。見積もりの前提をこの4区分で確定させると、後から「この連携は含まれていなかった」という追加費用の交渉を避けられます。判断基準として、As-Isで半年以上実行されていない連携はTo-Beで廃止候補に入れ、業務部門に「残す理由」の説明を求める形にすると、不要な連携が自然に減ります。As-Isの作成に2〜3週間、To-Beの作成に1〜2週間が目安です。

図とインタフェース一覧の同時更新をルール化し、最終更新日と対象リリースを明記する

図の鮮度を保つ唯一の方法は、変更管理のプロセスに図の更新を組み込むことです。連携の追加・変更・廃止を伴うリリースでは、リリース判定の必須成果物に「更新済みの連携図とインタフェース一覧」を含め、未更新ならリリースを承認しないルールにします。図の右下には「最終更新日」「対象リリース番号」「更新者」の3項目を固定で記載し、どのリリース時点の状態かを明示してください。この3項目があれば、図を見た人が「どの時点の状態か」を更新者に確認する手間がなくなります。

更新の担当は、連携を変更したプロジェクトの担当者が行い、情シスの図の管理者が月1回まとめて版を確定する運用が現実的です。管理者が1人で全変更を追うと、月に10件を超えた時点で更新が追いつかなくなります。図と一覧は同じリポジトリ（SharePoint、Confluence、Gitなど）に置きます。片方だけ更新された状態を作らないように、同じ変更申請で両方を提出させる仕組みにしてください。データリネージツールを導入している場合は、ツールの自動収集結果と図を四半期ごとに突き合わせると、人手の更新漏れを拾えます。

データリネージとは？データリネージの意味やメリット、重要性、主なツールなどを解説

データ連携図でよくある失敗パターン

連携図の失敗は、描き方の問題よりも「何を載せるか」と「どう運用するか」の判断ミスに起因します。ここでは実務で繰り返し見られる5つの失敗を取り上げ、それぞれが何を引き起こすか、どの時点で防げたかを説明します。自社の現行図に当てはまるものがあれば、前の章の作成ポイントに戻って修正の優先順位を決めてください。

矢印だけで方式・契機が書かれておらず、移行や障害対応時に調査が必要になる

最も多い失敗は、ノードと矢印だけが描かれ、ラベルが「売上データ」のように名前だけになっている図です。この図では、夜間に会計システムが止まったときに「どの連携が失敗したのか」「翌朝までに復旧すれば業務に影響しないのか」が読めず、ジョブ定義を開いて調べ直すことになります。調査には1連携あたり30分から数時間かかり、障害対応の初動が遅れます。連携が20本程度ある会計システムなら、原因の特定だけで半日が過ぎるケースも珍しくないのが実情です。

防ぐには、作図のルールとして「方式と契機が書かれていない矢印は未完成」と定義し、レビューの合格条件に含めてください。すでにある図を修正する場合は、全矢印を一度に埋めようとせず、業務影響の大きい連携（売上・請求・在庫・給与）から順にラベルを追加します。優先順位の判断は、業務部門に「止まると翌日の業務に影響する連携」を挙げてもらう方法が確実です。矢印30本の図なら、方式と契機の追記は担当者への確認を含めて1週間程度で終わり、障害時の調査時間を大きく減らせます。

全システムを1枚に詰め込み、読み手が追えない図になる

システムが30個、矢印が100本を超える図を1枚に描くと、A3で印刷しても線が重なって読めません。経営層への説明で使うと「結局どこが問題なのか」という質問に答えられず、図の存在そのものが信用を失います。作成者本人は読めるため問題に気づきにくく、レビューで初めて指摘されることが多い失敗です。ノードが30個あると矢印の交差が数十か所に達し、どの線がどこへ向かうかを追う時点で読み手が離脱します。図のサイズを大きくしても解決せず、情報の階層化だけが対策です。

対策は、STEP2で述べた2階層構成への分割です。全体図では業務領域を1ノードにまとめて領域間の連携だけを描き、詳細図を領域ごとに作ります。判断基準として、1枚あたりノード15個・矢印30本を上限に設定してください。すでに詰め込まれた図を分割する場合は、矢印の両端が同じ領域に収まるものから詳細図へ移し、領域をまたぐ矢印だけを全体図に残すと、1〜2日で分割できます。全体図から詳細図への参照は、領域ノードに詳細図の名前を書いておけば迷いません。

ETL・EAI・APIが混在しているのに区別がなく、二重経路に気づけない

方式の区別がない図では、同じ2つのシステム間にETL経由とファイル連携の2本の経路が存在していても、矢印が1本にまとめられてしまいます。これは「ETLを導入したときに旧来のファイル連携を止め忘れた」という典型的な状況で、二重計上やデータの不整合として業務部門に表面化する問題です。原因調査では両方の経路を追う必要があり、方式が図に書かれていないと数日を要します。業務部門からは「数字が合わない」という形で報告されるため、連携の問題だとすぐには気づけないのが難点です。

防ぐには、方式ごとに線種を変えるルールを徹底し、同じノード間に複数の矢印がある場合は必ず別々に描きます。二重経路が見つかったら、どちらを残すかを「保守できる担当者がいる方」「障害時の復旧が速い方」の2基準で決め、廃止側に赤字で「廃止予定（期日）」を書いてください。刷新前の棚卸しで二重経路が見つかる割合は、連携50本あたり2〜5本が目安で、放置すると移行後も重複が引き継がれます。廃止の期日を過ぎたら、ジョブ定義の削除まで確認して矢印を消します。

作成後に更新されず、廃止済みの連携が改修対象として見積もりに含まれる

図が作られた時点では正確でも、1年後には連携の1〜2割が変わっているのが通常です。特にSaaSの追加やiPaaSによる連携は情シスを経由せずに増えるため、半年で図との差が10本以上開くこともある領域です。更新されていない図をもとにベンダーへ見積もりを依頼すると、すでに廃止された連携の改修費用が含まれたり、新設された連携が漏れたりします。見積もり後に判明した差異は追加費用の交渉になり、金額だけでなくスケジュールにも影響します。

対策は、前の章で述べたリリース判定への組み込みと、月1回の版確定です。加えて、見積もり依頼の直前には必ずジョブ定義やログと図を突き合わせる「棚卸し再実施」を行い、図の日付が3か月以上前なら更新してから依頼してください。見積もり依頼時には「図の最終更新日」と「棚卸し再実施日」の2つを依頼書に明記し、前提の鮮度をベンダーと共有します。図の鮮度を保つ工数は月に数時間程度ですが、更新を怠った結果の追加費用は1件で数百万円に達することがあります。

物理構成（サーバー・ネットワーク）を混ぜてしまい、業務部門が読めなくなる

インフラ担当者が連携図を作ると、サーバー名、IPアドレス、ネットワークセグメント、ロードバランサーまで描き込んでしまうことがあります。技術的には正確ですが、業務部門が見ると「受注システム」がどの箱なのか分からず、レビューに参加できません。合意形成に使えない図は、刷新プロジェクトの初期で最も避けたい失敗です。構成図の要素をそのまま流用した図は、ノード数が業務システムの数倍に膨らみ、矢印の本数も読み切れない量に達します。

対策は、連携図とシステム構成図を別の資料として分け、連携図のノードは業務上のシステム名で書くことです。サーバーが複数台で構成されていても、連携図では1ノードにまとめ、物理構成は構成図へ参照リンクを置きます。判断基準は「業務部門の担当者が説明なしで読めるか」の1点で、読めない要素は連携図から外してください。両方の図を1人で管理するのが難しい場合は、連携図は情シスの業務側担当、構成図はインフラ担当と、管理者を分ける運用が機能します。

データ連携図の活用事例：方式を可視化して課題を解決した3つのケース

方式と契機を書き込んだ連携図が、実際にどのような判断につながるのかを3つの事例で示します。製造業・小売業・卸売業の匿名事例で、それぞれハブ＆スポーク型、集約型、社外接続型のパターンに対応しています。事例は複数の案件をもとに再構成したもので、数値は目安として読んでください。

製造業：基幹システム・MES・SaaSの混在をハブ＆スポーク型に整理し、保守対象を半減

従業員数約2,000名の製造業では、基幹システム（ERP）、生産管理システム（MES）、品質管理や勤怠のSaaSが混在していました。連携はファイル連携とAPIとEAIが入り混じり、約60本に達していました。EAIは導入済みでしたが、半数の連携がEAIを経由せずに直接接続されたままで、改修のたびに影響範囲の調査に1週間かかる状態でした。連携図を方式ごとに線種を分けて描いたところ、EAI未経由の直接接続が28本あることが一目で分かりました。

図をもとに、直接接続のうち業務影響の大きい20本をEAI経由へ順次移行し、残りの8本は廃止または統合しました。移行後の連携図はハブ＆スポーク型に整理され、保守対象の経路数は約60本から約30本へ半減した形です。成果を生んだのは方式の可視化そのもので、EAI未経由の矢印が破線として並ぶ図を見た経営層が、移行予算の承認を1回の会議で決めました。移行期間は約8か月で、連携図のAs-Is作成に3週間、To-Be作成に2週間という内訳です。

小売業：ファイル連携とETLの二重経路を連携図で発見し、データ基盤の集約型へ統合

店舗数約300の小売業では、POSシステムから本部のDWHへ売上データを送る経路が2本並行して動いていました。10年前からのファイル連携（日次）と、3年前に導入したETL（時間ごと）です。両方のデータがDWHに取り込まれており、帳票によって参照先が異なるため、同じ日の売上が帳票ごとに数%ずれる問題が長年放置されていました。原因は分かっておらず、現場では「システムのクセ」として扱われていた状態です。

連携図を作成した際に、POSとDWHの間に線種の異なる矢印が2本並んだことで、二重経路が初めて明示されました。経路の統合では、ETL経由を残してファイル連携を廃止し、帳票の参照先をすべてETL経由のテーブルに切り替える対応です。二重経路の発見から統合完了までは約3か月で、統合後は帳票間の売上のずれが解消され、月次の数値照合にかけていた約20時間の作業がなくなりました。図は集約型に整理され、現在も新しいSaaSの取り込み経路を追加する際の設計の起点として使われている状態です。

卸売業：EDIとAPIの社外接続を1枚で可視化し、取引先追加時のリードタイムを短縮

取引先約400社を持つ卸売業では、EDI（流通BMS、固定長、Web-EDI）とAPIによる社外接続が混在していました。新規取引先の追加のたびに、「どの接続方式で、どの変換設定を流用できるか」を担当者が個別に調べる状態です。接続方式ごとの担当者が異なり、取引先からの接続依頼を受けてから接続完了まで、平均で6週間かかっていました。営業部門は方式の違いを知らないため、依頼の窓口も毎回変わり、取引先からの催促が営業に集中する状況でした。

社外接続型の連携図を1枚で作成し、接続方式ごとにノードを分けて社数と標準的な追加期間を注記しました。図を営業部門にも配布した結果、取引先からの依頼時点で営業が方式を判別し、適切な担当者へ直接つなぐ流れができた形です。取引先追加のリードタイムは平均6週間から3週間に短縮され、通信方式の切り替えが必要な取引先の数も、図の社数の注記からすぐに把握できるようになりました。作成に要した期間は、棚卸しを含めて約4週間です。

まとめ：データ連携図は連携方式を可視化してこそ刷新・運用の判断材料になる

データ連携図は、送信元・宛先・データ名・連携方式・契機の5つの要素をそろえて初めて、刷新計画や障害対応の判断材料になります。方式ごとに線種と色を分け、API・ETL・EAI・CDC・EDI・iPaaS・ファイル連携の混在を1枚で読めるようにしてください。そうすることで、二重経路の発見や移行対象の確定、見積もり前提の固定が可能です。作成は棚卸し・粒度設定・配置・ラベル付け・レビューの5ステップで進め、As-Is／To-Beの2枚構成と、図と一覧の同時更新ルールで鮮度を保ってください。

• 送信元・宛先・データ名・連携方式・契機の5要素が全矢印に書かれているか
• 方式ごとに線種・色が分かれ、凡例が図の右上に置かれているか
• 同じノード間の複数経路が別々の矢印として描かれているか
• 図とインタフェース一覧が同じ版番号・日付で管理されているか
• 最終更新日と対象リリース番号が図に明記されているか

「これからシステム刷新やデータ基盤構築に向けてデータ連携を整理したいけれど、何から手をつけたらいいかわからない」「データ連携やデータ基盤の専門家の知見を取り入れたい」という方は、データ基盤構築の実績豊富な弊社、データビズラボにお気軽にご相談ください。

貴社の課題や状況に合わせて、データ連携の整理からデータ基盤構築までの取り組みをご提案させていただきます。

データビズラボの実績無料相談・お見積り