システム連携図の書き方 システム構成図との違いと記載項目・連携方式の整理方法を解説

基幹システムを入れ替えることになり、影響範囲を調べようとしたら、どのシステムと何をやり取りしているのか誰も全体像を把握していなかった。障害が起きたとき、原因がどこにあるのか切り分けるのに半日かかった。こうした状況の背景には、システム同士のつながりが図として整理されていないという共通点があります。

システム連携図は、どのシステムからどのシステムへ、どんなデータが、どの方式で、どのタイミングで流れるのかを1枚で見渡せるようにした図です。似た名前の「システム構成図」とは対象がはっきり違うため、まずここを区別することが出発点になります。

本記事では、システム連携図の役割と構成図との違いから、載せるべき要素、連携方式の整理、インターフェース一覧との使い分け、作成手順、そして運用で活かすための工夫までを順番にまとめます。

確認したいポイント	結論	詳細
システム連携図とは何ですか？	システム間のデータの流れを表す図	どのシステムからどこへ、どんな方式で何が渡るかを1枚で見渡せるようにしたものです。
システム構成図との違いは？	表す対象が異なる	構成図は何で動いているか、連携図はシステム間で何が行き来しているかを示します。
図に何を載せればいい？	方向・方式・データ・頻度	システム名と管理部門に加え、連携の向き、方式、渡すデータ、実行タイミングを添えます。
図だけで足りますか？	一覧表と組み合わせる	詳細な項目定義はインターフェース一覧に書き、図とは連携番号で対応づけます。

無料サービス資料

AIコンサル・AX伴走支援サービス
ご紹介資料

• 
• 
• 

少数精鋭で高利益率な「筋肉質企業」への変革を実現するための考え方や支援内容をまとめた資料です。

こんな方におすすめ

• AI導入を検討している
• 業務改善の進め方を知りたい
• 導入事例を確認したい

サービス資料をダウンロードする

目次

この記事でわかること

• システム連携図の役割と、システム構成図との明確な違い
• 図に載せるべき要素と、それぞれをどこまで書くかの粒度
• API、ファイル、データベース参照など連携方式の整理の仕方
• インターフェース一覧との役割分担と、図との対応づけ方
• 障害対応や改修の影響調査で実際に使える状態を保つ運用

▼ 社内システムの全体像を整理したい方へ 業務の棚卸しからシステム化・AI活用までの進め方、支援内容、導入までの流れをまとめた資料をご用意しています。検討の初期段階でも構いませんので、まずは全体像の把握にご活用ください。 ＞ 資料請求はこちら

システム連携図とは何を表す図か

まず役割を整理します。システム関連の図は名前が似たものが多く、社内で「あの図を出して」と言われたときに認識がずれる原因になります。違いをはっきりさせておきます。

システム間のデータの流れを表す

システム連携図は、複数のシステムがどうつながり、どんなデータをやり取りしているかを可視化した図です。システムを四角で表し、データの流れを矢印でつなぐ形が基本になります。

矢印には、渡されるデータの内容、連携の方式、実行のタイミングを添えます。「受注データ」「CSVファイル」「毎日23時」といった情報です。この3点が書かれているかどうかで、図の実用性が決まります。

自社のシステムだけでなく、外部サービスやクラウドサービス、取引先のシステムも対象に含めます。自社の責任範囲の外にあるものほど、図に残す価値が高くなります。

システム構成図との違い

最も混同されやすいのがシステム構成図です。構成図は「何で動いているか」、連携図は「何が行き来しているか」を表します。対象としている情報が違います。

構成図には、サーバー、ネットワーク機器、ミドルウェア、OSといった要素が並びます。インフラの視点です。対して連携図には、業務システムやサービスが並び、その間をデータが流れます。業務とデータの視点です。

両方が必要ですが、すべての種類の図を作る必要はありません。図は作った後に更新されないと誤った情報源になります。多くの現場では、構成図と連携図の2つを正確に保つだけで、日々の運用と障害対応はカバーできます。

なお、データの流れをより詳しく表すデータフロー図や、業務の流れを表す業務フロー図も近い位置づけの図です。どこまでを1枚に含めるかは、社内で使う目的に合わせて決めてください。

何のために作るのか

目的は主に3つです。1つ目が改修時の影響範囲の把握。あるシステムの項目を変更したとき、どこに影響が及ぶのかを即座に判断できます。

2つ目が障害時の切り分けです。データが届いていないとき、送信側の問題か、経路の問題か、受信側の問題か。図があれば、確認すべき箇所を順に絞り込めます。

3つ目がシステム刷新や統合の検討です。入れ替えの対象がどれだけの連携を持っているかが分かれば、移行の工数とリスクを見積もれます。

いつ作るのか

新規開発では、要件定義から基本設計にかけて作成します。外部システムとの接点が明らかになる段階で、連携の一覧とあわせて整理するのが自然な流れです。

既存システムに図がない場合は、刷新の検討を始めるタイミングで作ることになります。この場合、担当者へのヒアリングと実際の設定の確認から作り起こす作業になるため、相応の時間を見込んでおいてください。

工程全体での位置づけを整理したい場合は、IPAの共通フレームが参考になります。企画から要件定義、開発、運用までの作業項目と役割が体系的にまとめられており、用語をそろえる土台として使えます（出典：IPA「共通フレーム2013」）。

システム連携図に載せる要素

ここからは中身です。必要な要素は5つで、これらが揃っていれば障害調査にも改修検討にも使えます。

システムと管理部門

各システムを四角で表し、システム名に加えて管理している部門や担当者を記載します。障害時に誰へ連絡すればよいかが図から分かる状態にしておくためです。

自社が管理しているものと、外部のサービスや取引先のシステムは、形や線の種類で区別します。責任範囲の境界が図の上で見えることが重要になります。

システム名は、社内で通じる正式名称に統一してください。同じシステムが図では略称、資料では正式名称と書かれていると、対応関係を追うのに手間がかかります。

連携の方向

データがどちらへ流れるのかを矢印で示します。片方向なのか、双方向なのかを明確に区別してください。双方向の場合は、往路と復路でデータの中身も方式も違うことが多いため、矢印を2本に分けたほうが正確です。

また、「参照しているだけ」と「更新している」では影響の大きさがまったく違います。読み取りのみなのか、書き込みも行うのかを区別できるようにしておいてください。

廃止が決まっている連携や、稼働していない連携も、判明した時点で図に印を付けておいてください。「使っていないはず」の状態が続くと、いつまでも調査対象として残り続けます。

連携方式

どうやってデータをやり取りしているのかを矢印に添えます。API、ファイル、データベースの直接参照、メッセージング。方式によって障害時の挙動も、改修時の影響も変わります。

方式ごとの違いは次の章で扱いますが、図の段階では方式名が書かれていれば十分です。詳細は後述するインターフェース一覧に譲ります。

データの内容とタイミング

何のデータが、いつ流れるのかを記載します。「顧客マスタ」「受注明細」といったデータの種類と、「リアルタイム」「毎日23時」「月初1回」といった実行のタイミングです。

タイミングは障害調査で特に効いてきます。「今朝のデータが反映されていない」という問い合わせに対して、そもそも連携がいつ動くのかが分からなければ、調査に入れません。

件数の目安も書いておくと、性能に関わる検討で役立ちます。1日100件と10万件では、対策の方向性がまったく違います。

凡例と更新情報

図形や線の種類が何を意味するのかを定義した凡例を、必ず図の中に記載してください。自社管理か外部か、同期か非同期か、読み取りのみか更新ありか。区別の基準を書いておけば、解釈のブレがなくなります。

あわせて、作成日、最終更新日、作成者を記載します。連携図は実態と合っていないと危険な文書なので、いつ時点の情報かが読み手に分かることが前提になります。

▼ 社内システムの棚卸しからご相談いただけます 現状の全体像の整理、刷新の検討、業務の自動化まで含めて、実務目線でご一緒に進めます。検討の初期段階でも構いません。 ＞ 相談予約はこちら

連携方式を整理する

図の精度を左右するのが方式の記述です。主な方式は5つあり、それぞれ障害時の挙動と改修時の影響が異なります。

API連携

システム同士が直接やり取りする方式です。リアルタイムで結果が返るため、即時性が求められる処理に向いています。Web APIを使う構成が現在の主流です。

図に書く際は、どちらが呼び出す側かを明示してください。呼び出す側と呼び出される側では、障害が起きたときの対処がまったく違います。

相手先が応答しない場合の扱いも重要です。再試行するのか、エラーとして止めるのか。この情報は一覧側に書きますが、図に注記として残しておくと調査が早くなります。

API連携では、相手先の仕様変更が影響します。バージョンの管理や提供終了の予定について、情報が届く体制になっているかも確認しておいてください。

ファイル連携

CSVなどのファイルを介してデータを渡す方式です。古くから使われており、いまも多くの基幹システムで現役です。夜間のバッチ処理と組み合わせて使われることが一般的です。

この方式では、ファイルの置き場所、ファイル名の規則、文字コード、区切り文字が実質的な仕様になります。図にはファイル名の規則まで書き、詳細は一覧に譲る形が扱いやすくなります。

障害としては、ファイルが生成されない、生成されたが取り込まれない、文字コードが違って化ける、といったパターンが定番です。どこまで進んだかを確認できる仕組みがあるかも、図に注記しておくとよいでしょう。

データベースの直接参照

あるシステムが別システムのデータベースを直接見に行く方式です。実装は簡単ですが、参照される側の変更が参照する側に直接影響するという強い結合を生みます。

テーブル構造を変えた途端に別のシステムが止まる、という事故はこの方式で起きます。連携図では特に目立つように記載し、どのテーブルを見ているかまで一覧に残しておいてください。

新規に設計する場合は、この方式を避けてAPIやファイルを経由させる構成が推奨されます。既存で使われている場合も、刷新のタイミングで見直す候補になります。

メッセージングとイベント連携

送信側が処理を待たずにメッセージを投げ、受信側が自分のタイミングで処理する方式です。相手が一時的に止まっていてもデータが失われにくく、負荷の変動にも強くなります。

一方で、処理が非同期になるため「送ったはずのデータがまだ反映されていない」という状態が正常な範囲で起こります。図には非同期であることを明示し、遅延の許容範囲も書いておいてください。

連携ツールを経由する

システム同士を直接つながず、連携用のサービスやツールを間に挟む構成もあります。接続先が増えても組み合わせが複雑になりにくい点が利点です。

この場合、連携図にはツール自体も1つのノードとして描きます。ツールが止まると広範囲に影響が及ぶため、どの連携がそのツールを経由しているかが分かる状態にしておくことが重要です。

▼ 「この連携方式で問題ないか」から相談できます 既存システムとのつなぎ方、刷新時の影響範囲、自動化ツールの活用まで、設計段階の判断からご相談いただけます。 ＞ 相談予約はこちら

インターフェース一覧との使い分け

図だけですべてを表現しようとすると破綻します。図は全体像、一覧は詳細という役割分担が実務の標準です。

図だけでは足りない理由

連携の詳細をすべて図に書き込むと、すぐに読めない図になります。項目名、桁数、文字コード、エラー時の挙動、再送の条件。これらを矢印の脇に書くのは現実的ではありません。

図の価値は一目で全体を把握できることにあります。その価値を保つためには、書き込む情報を絞る必要があります。

連携ツールを使う場合も、設定内容がツールの中に閉じてしまわないよう注意が必要です。誰がどの設定を持っているかが分からなくなると、結局は同じ問題が起こります。

インターフェース一覧に書く項目

一覧には、連携番号、送信元、送信先、連携方式、データの内容、実行タイミング、想定件数、エラー時の扱い、担当部門といった項目を並べます。1行が1つの連携に対応する形です。

さらに詳細な項目定義が必要なら、連携ごとに別紙を用意します。一覧から別紙へたどれるようにしておけば、必要な粒度で情報を追えます。

一覧は表形式なので、絞り込みや並べ替えができます。「このシステムに関わる連携だけを抽出する」といった使い方は、図ではできない一覧の強みです。

図と一覧を番号で対応づける

図の矢印に連携番号を振り、一覧の行と対応させます。「IF-012」のような番号を使えば、図を見ながら一覧で詳細を確認できます。

番号の付け方はプロジェクト開始時に決めてください。途中から変えると、他の資料との対応関係を取り直すことになります。

どちらを正本とするか

更新の手間を考えると、詳細な情報は一覧を正本とし、図は一覧から起こすという運用が現実的です。項目が増減しても、図を描き直す必要がありません。

ただし、連携そのものが増減した場合は図も更新が必要です。どちらをいつ更新するのかを、変更管理の手順に組み込んでおいてください。

システム連携図の作成手順

既存システムの連携図を作る場合を想定して、手順を整理します。いきなり描き始めず、洗い出しから進めるほうが確実です。

STEP1：対象範囲を決める

まず、どこまでを図に含めるのかを決めます。全社のすべてのシステムを一度に描こうとすると、完成しません。

業務領域で区切る、刷新の対象システムとその接続先に限る、といった絞り方が実用的です。範囲外のシステムも、接点があるなら境界上に置いて名前だけ書いておきます。

STEP2：システムを洗い出す

対象範囲の中にあるシステムを列挙します。業務で使われているサービスや、部門で個別に契約しているツールも忘れずに拾ってください。情報システム部門が把握していないものが出てくることは珍しくありません。

この段階で、システム名、管理部門、稼働状況を一覧にしておくと、次の作業が楽になります。

退職者が管理していたシステムや、契約が自動更新されているサービスも対象に含めてください。全体像の把握は、不要な契約を見つける機会にもなります。

STEP3：連携を洗い出す

洗い出したシステムについて、どこと何をやり取りしているかをヒアリングと設定の確認から拾い上げます。担当者の記憶だけに頼らず、実際のジョブ定義や設定ファイルを確認してください。

記憶と実態がずれていることはよくあります。「使っていないはず」の連携が動き続けていた、という発見もこの作業で出てきます。

拾い上げた連携は、この段階でインターフェース一覧の形にまとめておきます。図はこの一覧から起こします。

STEP4：図として配置する

一覧をもとに、システムを配置して矢印でつなぎます。線が交差しないよう、関連の深いシステムを近くに置くのが配置のコツです。

業務領域ごとにグループを作って囲むと、全体の構造が読み取りやすくなります。社内と社外の境界も、枠で区切って示しておいてください。

STEP5：関係者でレビューする

各システムの担当者に確認してもらいます。「この図のとおりですか」と聞くと、必ず修正が出てきます。その差分こそが、これまで文書化されていなかった部分です。

外部の委託先が関わる連携については、先方にも確認を取ってください。自社側だけで把握している内容が、実際の仕様と違っていることがあります。

▼ システムの現状整理を第三者視点で支援します 全体像の可視化、刷新の検討、業務自動化の設計まで含めてご相談いただけます。何から手をつけるべきか整理したい段階でも構いません。 ＞ 相談予約はこちら

わかりやすい図にするコツ

同じ内容でも、描き方で読みやすさは変わります。読み手が迷わない図に共通する特徴を挙げます。

層で分けて配置する

業務システム、共通基盤、外部サービスといった層に分けて配置すると、構造が読み取りやすくなります。上から下、あるいは左から右に階層を並べる形です。

層が決まっていると、新しいシステムを追加するときの配置にも迷いません。図の寿命を延ばすうえでも有効な工夫です。

矢印が集中して読みにくくなる場合は、中継点として共通基盤を1つ置く構成を検討してください。図が読みやすくなるだけでなく、実際の設計としても妥当な場合があります。

粒度をそろえる

1つの四角が表す単位を統一してください。業務システム全体と、その中の一機能が同じ大きさで並んでいると、読み手は重要度を判断できません。

迷ったら「別々に契約または開発されているか」「管理部門が違うか」を基準にします。判断に一貫性があれば、多少の例外があっても図は読めます。

1枚に収める、収まらなければ分ける

全体を見渡せることが連携図の価値です。収まらない場合は、全体を俯瞰する図を1枚用意し、領域ごとの詳細を別図にする二層構造にします。

分割した図の間は、参照先を明記してつなぎます。境界をまたぐ連携については、どちらの図にも表れるようにしておいてください。

色だけに意味を持たせない

色分けは便利ですが、印刷やモノクロでの共有では意味が失われます。線の種類や形でも区別がつくようにしておくほうが安全です。

色を使う場合は凡例で意味を明記し、種類を2〜3色に抑えます。装飾を増やすほど、更新の手間も増える点も見落とせません。

作った図を運用で活かす

連携図は、実態と合っていて初めて価値が出る文書です。作って終わりにしない仕組みを整えます。

障害対応と影響調査で使う

最も効果が出るのがこの場面です。障害の一次切り分け手順に「連携図を開く」を組み込んでおくと、実際に使われる文書になります。

改修の検討でも同じです。「この項目を変えたら、どこに影響するか」を図から拾い、一覧で詳細を確認する。この流れを標準の手順として定めておいてください。

新しく参加したメンバーへの説明資料としても有効です。口頭で全体像を伝えるより、図を見せながら説明するほうが、短時間で理解してもらえます。

更新されない状態を防ぐ

連携が追加されたり廃止されたりしても図が更新されなければ、すぐに実態と乖離します。システムを変更したら図と一覧も直す作業を、変更管理の手順に組み込むのが確実です。

実態と合っていない連携図は、ないよりも危険です。障害時に誤った前提で調査を進めることになります。年に1回など、棚卸しの時期も決めておいてください。保管場所も決めておいてください。障害時にすぐ開けない場所にあると、いざというときに使われません。関係者が誰でも参照できる場所に正本を置きます。

個人データを扱う連携の確認

連携の中身に個人情報が含まれる場合は、取り扱いの確認が必要になります。社外のシステムへ渡す場合は、委託にあたるのか第三者提供にあたるのかによって手続きが変わります。

個人データの漏えいや滅失を防ぐため、必要かつ適切な安全管理措置を講じることが事業者に求められます（出典：個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」）。連携図に個人情報を含む経路を印で示しておくと、点検の際に見落としが減ります。

なお、個別の判断は事情によって異なります。該当しそうな連携がある場合は、法務部門や専門家にご確認ください。

書ける人を1人に限定しない

連携図を維持できるのが特定の1人だけという状態は、組織として脆弱です。部署内に最低2人は全体像を理解している人を置き、更新の担当と時期を決めておいてください。

記号のセット、層の分け方、番号の体系。この3点を1枚のルールにまとめておけば、担当が変わっても一定の品質が保てます。業務全体の整理の仕方は業務効率化アイデア55選の記事でもまとめています。

あわせて、社内で図を読み書きできる人を増やす取り組みも進めてください。システムが増えるほど、全体像を把握している人の存在が重要になります。育て方の考え方はAI研修の目的と選び方をまとめた記事も参考になります。

まとめ

システム連携図は、どのシステムからどのシステムへ、どんなデータが、どの方式で、どのタイミングで流れるのかを可視化した図です。インフラの構成を表すシステム構成図とは、対象がはっきり異なります。

載せる要素は、システムと管理部門、連携の方向、連携方式、データの内容とタイミング、そして凡例の5つです。詳細な項目定義はインターフェース一覧に譲り、連携番号で図と対応づけます。

連携方式は、API、ファイル、データベースの直接参照、メッセージング、連携ツール経由の5つに整理できます。特にデータベースの直接参照は結合が強く、改修時の影響が大きいため、図の上で目立たせておいてください。

そして、実態と合っていない連携図は、ないよりも危険です。変更管理の手順に更新を組み込み、障害対応の手順に図を開く工程を入れる。ここまで設計して初めて、連携図は使われ続ける文書になります。

▼ システムの全体像整理と改善を、社内に定着する形で進めませんか 株式会社ネクストスケールでは、現状の棚卸しから要件の整理、システム化・AI活用の設計、社内への定着支援までを一貫してご支援しています。まずはお気軽にご相談ください。 ＞ 相談予約はこちら