公開2026.08.24更新2026.10.08 Webシステム

データ連携の事例：6つの型と業種別の制約・効果指標の置き方

データ連携の事例を調べる目的は、他社の成功談を読むことではないはずです。知りたいのは、自社でつなごうとしている2つのシステムが世の中のどの型に当てはまり、どこで詰まり、つないだ後に何が数字として動くのかという点です。本記事では、業種をまたいで繰り返し現れる連携パターンを6つの型に整理し、自治体や医療用医薬品のように外部の制度が要件を先に決めてしまう業種の事情、そして効果をどの指標で測るかまでを扱います。API連携そのものの仕組みやデータ連携との言葉の違いはAPI連携の仕組みとデータ連携との違いを整理した解説に譲り、ここでは自社の案件を型に当てはめる作業だけに集中します。

まとめ：データ連携の事例から読み取る結論と自社への当てはめ方

先に結論を書きます。データ連携の事例は業種ごとに見ると無数にありますが、構造で見ると6つの型に収まります。基幹システムとSaaS、店舗と本部、企業間EDI、現場設備と業務システム、分析基盤への集約、外部標準へのコード合わせ。自社の案件がどれに当たるかを決めれば、必要な検討項目はほぼ自動的に決まります。

型を決めたら、次に確認するのは接続先にAPIがあるかどうかと、月間の処理件数、そして例外処理の複雑さの3点です。ここが軽ければ連携ツールで足り、重ければ受託開発に寄ります。事例を読むときも、その会社が何のツールを選んだかではなく、この3点がどうだったかを読み取ってください。

そして、事例のほとんどが書き落としている論点が効果の測り方です。連携は導入した瞬間に効果が出る施策ではなく、手作業がどれだけ消えたかで測るもの。転記の件数、データが反映されるまでの時間、突き合わせで見つかる差異の発生率。この3つは着手前に測っておかないと、後から取り直せません。

着手を急がなくてよい場面もはっきりしています。転記が月に数件しかない、片方のシステムが1年以内に入れ替わる、項目の定義が部門間でまだ揃っていない。この状態でつなぐと、揃っていない定義がそのまま連携先へ流れ込みます。

データ連携の事例を6つの型に整理する：業種が違っても構造は繰り返す

ベンダーが公開している導入事例は、製造・流通・金融・医療と業種の見出しで並んでいます。ただ、その中身を接続元と接続先の組み合わせで並べ直すと、業種の違いは思ったほど効いてきません。以下の6つは、実務でぶつかる論点が異なる単位として分けたものです。

基幹システムとSaaSをつなぐ型：受注と顧客のマスタを片方向で寄せる

営業支援や名刺管理のSaaSに入った顧客情報を基幹システムへ渡す、あるいは基幹の受注データを営業側へ見せる。もっとも件数が多いのがこの型です。事例として紹介されるものの多くは、SaaS側にAPIがあり、基幹側にはないという非対称な構成になっています。

この型で最初に決めるのは、どちらを正とするかです。両方向で更新できる設計にすると、同じ顧客レコードを両側で直したときにどちらが勝つかという問題が必ず発生します。実務では片方向に倒し、逆向きは参照のみに割り切る事例が安定しています。マスタの重複判定に使うキーを取引先コードにするか法人番号にするかも、この段階で決めておく項目です。

店舗と本部をつなぐ型：売上と在庫を締め処理の時刻に間に合わせる

飲食チェーンや小売の事例で繰り返し出てくるのが、店舗ごとに異なる形式の売上データを本部で集計する構成です。フランチャイズでは店舗側が別々の業務システムを入れていることも珍しくなく、項目名も桁数も店舗ごとに違います。

この型の勘所は、リアルタイム性ではなく締め時刻にあります。本部の集計が朝9時なら、必要なのは秒単位の同期ではなく、前日分が朝8時までに全店から揃うことと、揃わなかった店舗を検知する仕組みです。事例を読むときは、連携の頻度より、欠損したときに誰へどう通知しているかを見ると設計の質が分かります。

企業間EDIの型：取引先が指定する手順と伝票種別に自社を合わせる

受発注をデータでやり取りする企業間の連携は、自社の都合で方式を選べない点が他の型と決定的に違います。通信手順も伝票の種別も取引先の指定が先にあり、自社はそれに合わせる側。取引先が5社あれば、5通りの仕様に対応する前提で見積もることになります。

中小企業の間では、業種をまたいで共通のフォーマットを使う中小企業共通EDIのような枠組みも動いています。請求の部分だけはデジタルインボイスの国際規格へ寄せ、受発注は共通EDIで回すという組み合わせも検討の対象です。導入の工程そのものはEDI導入を六工程で進める手順とクラウドEDIの前提条件で扱っているため、本記事では型としての位置づけにとどめます。

現場設備と業務システムをつなぐ型：稼働データを日次で吸い上げる

製造ラインの装置や物流拠点の機器から稼働実績を取り、生産管理や保全のシステムへ渡す構成です。設備側は連携を想定していない機器が混じるため、出力できるのがCSVや独自形式のログだけということも起こります。

この型では、取得の粒度を先に決めるかどうかで工数が変わります。1分間隔で全項目を取ると通信量も保管費用も膨らみますが、実際に見るのは日次の稼働率と停止回数だけ、という事例が多くあります。何を意思決定に使うかから逆算して、取る項目を削るところが設計の中心です。製造業でこの型を設計するときの階層別インタフェースと取得方式の選び分けは、製造業のデータ連携を設備・MES・基幹の3層で整理した記事にまとめています。

分析基盤へ集約する型：部門ごとの集計表が壊れ続ける状態を止める

販売・会計・人事のデータを1か所へ寄せ、経営会議の資料を自動で作る構成です。この型の事例で語られる課題はほぼ共通していて、部門ごとに作られた集計ファイルが、元システムの改修のたびに壊れるという話に行き着きます。

集約の方式は、夜間に全件を入れ替えるか、変更があった行だけを拾うかの二択になります。件数が数十万行を超えると前者は時間内に終わらなくなるため、更新差分を捉える方式へ移る判断が必要です。仕組みの詳細は変更データを捕捉するCDCの3方式と採用判断で扱っています。集約した先で何を見るかについては経営管理システムの機能範囲とデータ連携の比較が参考になります。金融機関で勘定系から情報系へ複製を寄せるときの制約は金融のデータ連携における受け皿の置き方を整理した記事で扱っています。

外部標準にコードを合わせる型：識別コードを業界仕様へ寄せる連携

自社の商品コードや取引先コードを、業界や制度が定めた識別コードへ対応づける型です。医薬品のGS1コード、物流や建設で使われる標準コード、行政手続きで使う各種の番号が該当します。

他の5つと違い、この型は連携先が特定の1社ではなく仕様書です。相手に相談して仕様を変えてもらう余地がないため、自社マスタ側に読み替え表を持つ設計になります。読み替え表を誰が保守するかを決めないまま稼働させると、数年後に誰も更新できない表が残ります。

業種別のデータ連携事例：自治体と製薬と通信で先に決まる制約を見る

業種によっては、連携の要件を自社ではなく外部の制度や期限が決めてしまいます。ここで挙げる4つは、事例を読むときに前提条件として押さえておく必要があるものです。

自治体の事例：標準化とガバメントクラウド移行が連携要件を先に決める

地方公共団体の基幹業務システムは、住民記録や税など20業務について標準仕様へ揃える取り組みが進んでいます。移行の原則期限は2025年度末に置かれましたが、公表されている進捗を見ると、2026年1月末時点で対象34,592システムのうち標準準拠システムへの移行が完了したのは13,283システム、全体の38.4%という水準でした。移行済みのシステムを1つ以上持つ団体は1,188団体で、団体数では66.4%に達しています。

一方で、期限内の移行が難しく特定移行支援システムに該当する見込みのものは8,956システム、25.9%との集計です。自治体側の連携案件では、この移行スケジュールが先にあり、既存の周辺システムをいつつなぎ替えるかがそれに従属する形になります。クラウド側の前提はガバメントクラウドの全体像と自治体が直面する移行期限で整理しています。

製薬と医療の事例：GS1コードの表示義務がトレーサビリティの起点になる

医療用医薬品では、容器へのバーコード表示が2022年12月1日の施行で義務となりました。商品コードだけでなく、有効期限とロット番号を含めて表示する運用が求められており、包装の単位によって使うバーコードの種類も変わります。

この制度があるおかげで、医薬品を扱う現場のデータ連携は識別コードから設計できます。卸から医療機関、病棟の在庫までを同じコードで追える前提が整っているためです。逆にいえば、自社マスタの商品コードとGS1側の商品コードの対応表を持たない限り、入出庫の記録は自社内で閉じたままになります。製薬領域の事例で工数が大きいのは連携そのものより、この対応表の初期整備であることが多くあります。診療側の連携、つまり電子カルテと部門システムをつなぐ話は別の設計になり、医療のデータ連携で院内4方式と更新時の移行判断を整理した解説で扱っています。

通信手順の事例：INSネット終了で企業間EDIの接続が期限つきになる

企業間のデータ交換を長く支えてきたISDN回線には終期が示されています。NTT東西のINSネットは2024年8月31日に新規の申込受付を終了し、2028年12月31日でサービス提供が終了します。切替後のデータ通信を支える補完策も同じ日で終わるため、電話回線経由の手順で受発注を続けている企業には、インターネット経由の方式へ移す期限が実質的に設定された形です。

この移行は、通信方式を差し替えるだけでは終わりません。手順が変わると、送信の単位、再送のルール、到達を確認する方法まで見直しの対象になります。取引先ごとに切替時期が異なるため、旧方式と新方式を一定期間並行させる段取りも要ります。期限までまだ間があるように見えて、取引先の数だけ調整が発生する点を勘定に入れてください。

小売とECの事例：モールと自社サイトの在庫差異が売上機会を削る

自社ECとモール店舗、それに実店舗の在庫をどう一致させるかは、小売の連携事例で必ず出てくる論点です。売れた瞬間に他チャネルの在庫を減らせないと、在庫切れの注文を受けてしまいます。

ここで効くのは連携の速さより、安全在庫の置き方です。反映に5分かかるなら、その5分で売れる数を見込んで各チャネルへ配分しておく。この割り切りができていない事例では、リアルタイム連携に投資したのに欠品が減らないという結果になります。技術で埋める部分と運用で吸収する部分の線引きが、この型の判断です。

データ連携の効果指標の置き方：件数と時間で測ってから金額に直す

ベンダーの事例ページには、作業時間が8割減ったといった数字が並びます。ただ、その数字がどう測られたのかまで書かれていることは多くありません。自社で同じ形の説明を経営に出すには、測る対象を先に決めておく必要があります。

測る指標は三つ：転記の件数と反映までの時間とデータ差異の発生率

1つ目は、人が転記している件数です。月に何レコードを手で入れ直しているかを数えます。2つ目は、片方のシステムに入った情報がもう片方へ反映されるまでの時間。3つ目が、両システムを突き合わせたときに食い違うレコードの割合です。

指標	測り方	連携後に見る点
転記件数	月間の手入力レコード数	ゼロに近づいたか
反映までの時間	入力から反映までの実測	締めに間に合うか
差異の発生率	突合で不一致の割合	件数が減ったか

導入前に測っておく基準値：後からは取り直せない数字を先に押さえる

この3指標に共通するのは、連携を入れた後では測れないという性質です。転記件数は仕組みが動いた瞬間に消えますし、差異の発生率も同じように観測できなくなります。着手を決めた時点で1か月分を記録しておくと、後の説明が楽になります。

記録の方法は簡単で構いません。担当者に作業ログを付けてもらう、あるいは1週間分を数えて4倍する。精度より、同じ基準で前後を比べられることのほうが効きます。

金額へ直す手順：削減した作業時間と差異対応のコストを二本立てで

金額換算は2本立てにすると説明が通りやすくなります。1本目は削減した作業時間に人件費の時間単価を掛けたもの。2本目は、データの食い違いが起きたときの対応にかかっていたコストです。

後者は見落とされがちですが、金額としては大きくなることがあります。請求金額の誤りを取引先から指摘されて調べ直す、在庫の不一致で棚卸しをやり直す。こうした差異対応は発生件数が少なくても1件あたりの時間が長く、担当者の役職も上がる傾向があります。件数と1件あたりの所要時間を掛けて出すのが実務的です。

数字が動かないときに疑う点：つないだのに手作業が残る三つの典型

連携を入れたのに転記件数が減らない事例には、いくつかの共通した型があります。1つは、連携対象から漏れた項目を人が補っているケース。2つは、エラーになったレコードを担当者が手で入れ直しているケース。3つは、連携後のデータを別の形式に整えるために新しい手作業が生まれているケースです。

いずれも、連携そのものではなく対象範囲の決め方に原因があります。稼働から1か月後に転記件数を測り直し、残っている作業の中身を書き出すところまでを導入計画に入れておいてください。

内製とiPaaSと受託開発の分岐：事例から逆算して構築方式を決める

ここまで挙げた型のどれに当てはまるかが決まると、構築方式の選択肢は自然と絞れます。事例を読むときも、選ばれた製品名ではなくこの分岐条件のほうを見てください。

iPaaSで足りる条件：接続先にAPIがあり件数と例外処理が軽い場合

接続する両方にAPIかコネクタがあり、月間の処理件数が数千件程度に収まり、変換のルールが単純な条件分岐で書ける。この3つが揃えば、連携ツールで組んで運用まで現場に持たせる判断が成り立ちます。基幹とSaaSをつなぐ型や、分析基盤へ寄せる型の入口は、ここから始まる事例が多く見られます。

導入の進め方や社内での運用体制についてはZapierやMake、Workatoなどを使ったiPaaS導入支援で扱っている整理が下敷きになります。ツールの類型そのものの比較はAPI連携ツールの4類型と選定の5軸を参照してください。

受託開発へ切り替える条件：基幹側の改修と業務例外の作り込みが要る

接続先にAPIがなく基幹システム側の改修が必要になる、処理件数が多く従量課金でコストが逆転する、業務の例外パターンが十数通りある。このいずれかに当たると、ツールで組んだ処理は設定画面の中で肥大化していきます。企業間EDIの型と、外部標準へコードを合わせる型は、この領域に入りやすい構成です。物流業を例にした社内連携と企業間連携の切り分けは、物流のデータ連携でWMS・TMSと企業間EDIを二層に分けて設計する解説にまとめています。

全部を作り込む必要はありません。件数の多い経路や例外の多い経路だけをAPI開発とシステム連携の受託で作り込み、残りはツールのまま回す併用の形が、費用と保守性の両面で落ち着きます。

内製で持てる条件と持てない条件：担当者が辞めた翌週を想定して決める

内製を選ぶ判断で見るべきなのは、作れるかどうかではありません。作った人が異動した翌週に、別の担当者が障害対応できるかどうかです。設定内容とエラー時の再送手順が文書で残り、実行ログを第三者が読める状態なら内製は続きます。

逆に、特定の担当者しか中身を知らないスクリプトが夜間に動いている状態は、事例では語られませんが実務では頻繁に見かける形です。動いている間は費用が安く見え、止まった瞬間に代替がききません。内製する範囲は、この点で線を引くのが現実的な判断だと考えています。

データ連携に着手してよい三つの条件と、手作業のまま見送る場面の線引き

着手してよい条件を3つに絞ります。1つ目は、転記や突き合わせの作業が月間で数十件を超え、担当者が特定できていること。2つ目は、つなぐ両側のシステムが今後2年は入れ替わらないと見込めること。3つ目は、連携する項目の定義について部門間で合意が取れていること。この3つが揃っていれば、規模の大小にかかわらず投資は回収の見込みが立ちます。

見送ってよい場面も明示しておきます。転記が月に数件で担当者が片手間に処理できている、片方のシステムを1年以内に刷新する予定がある、同じ項目名を部門ごとに違う意味で使っている。とくに3つ目の状態でつなぐと、定義の食い違いが連携先へそのまま流れ込み、差異対応の手間が連携前より増えます。この場合は、まず項目定義の突き合わせだけを先に済ませてください。連携の設計はその後で構いません。

よくある質問

データ連携とAPI連携は同じものですか？

同じではありません。データ連携はシステム間でデータを受け渡すこと全体を指す言葉で、API連携はその実現手段の1つです。手段としてはほかに、CSVなどのファイルを受け渡す方式、データベースを直接参照する方式、画面操作を自動化して転記する方式があります。相手システムにAPIがない事例では、ファイル方式が現実的な選択肢です。用語の切り分けはAPI連携の解説記事で詳しく扱っています。

データ連携の事例で費用はどれくらいかかっていますか？

接続する本数と方式で幅が大きく、一律の相場を出しにくいのが実情です。目安として、APIを持つSaaS同士を連携ツールでつなぐ構成なら、初期の設定費用と月額のツール利用料に収まります。基幹システム側の改修を伴う受託開発になると、接続1経路あたりの設計・実装・テストが工数の中心になり、桁が変わります。見積もりを比べるときは、接続経路の本数と例外処理の数を揃えた条件で出してもらってください。初期費用だけでなく改修と利用料まで含めた3年総額の見方は、データ連携のコスト削減を費用構造から分解した解説で整理しています。

連携する項目はどこまで決めてから相談すればよいですか？

接続する対象システムの一覧、渡したいデータの種類、更新の頻度、そして誰がエラーに対応するかの4点があれば相談は始められます。項目レベルの定義書までは不要です。むしろ、項目の対応づけは相談の中で詰めたほうが早く、開発会社側が持っている過去案件の型を当てられます。ただし、両側の項目名と桁数を書き出したファイルは早い段階で用意しておくと工程が短くなります。

データ連携の効果を経営に説明する材料は何を用意しますか？

着手前に測った転記件数、反映までの時間、差異の発生率の3つと、稼働から1か月後の同じ測定値を並べるのが基本の形です。金額は削減時間の人件費換算と、差異対応にかかっていたコストの2本立てです。事例で見かける削減率の数字をそのまま自社に当てはめると、前提が違うため後で説明が崩れます。自社の基準値で出した数字のほうが説得力を持ちます。

取引先ごとに仕様が違うEDIは、まとめて1つの仕組みにできますか？

受け口を1つにまとめる構成は取れます。取引先ごとに異なる手順とフォーマットを受ける層と、自社の基幹システムへ渡す層を分け、その間に読み替えの処理を置く形です。取引先が増えたときに手を入れるのは受け口の層だけで済みます。ただし、取引先の仕様変更が続く前提は変わらないため、読み替え表を誰が保守するかは最初に決めておいてください。