基幹システム連携の方式と項目の決め方｜ファイル・API・DB直接・連携ツールを5軸で選ぶ

◆監修・編集責任者　小園 将隆　2026年10月27日

B2B EC-COLUMN

CSV転記・二重入力のずれはどこで起きているか：まず「何を・どちらからどちらへ・いつ」を業務の対象で決める

ECの受注をCSVで基幹システムに取り込み、エラーになった行を手で打ち直している。
あるいは、新しい営業支援システムを入れるので基幹とのつなぎ方を決めてほしいと頼まれた。
こうした場面で方式の比較から入ると、どの項目を渡すかが決まらないまま、方式の議論だけが進んでしまいます。
先に、注文・在庫・顧客などの業務対象ごとに「何を、どちらからどちらへ、いつ渡すか」を書き出し、項目とコードを定義します。
そのうえで、即時性・データ量・再処理・改修可否・保守負担の5軸で、ファイル、API、DB直接、連携ツールを絞ります。
失敗したときの運用まで決めてから動かします。

注文・在庫・顧客などの対象ごとに「正」のシステムを決める

たとえば、次のような運用を考えます。
ECサイトの受注を毎朝CSVで出力して販売管理の基幹システムに取り込み、夕方には基幹システムの在庫数をCSVで出してECへ反映しています。
取り込みでエラーになった行は、担当者が画面から打ち直しています。
昼間に売れた分は、夕方まで在庫に反映されません。
顧客が住所を変えたときは、EC側と基幹側の両方を誰かが直しています。
この例でずれが出ているのは、手で打ち直す行、反映を待つ時間、二か所で直す顧客情報の三か所です。

三か所に共通するのは、ファイルの形式よりも手前の決めごとが曖昧なことです。
注文はどちらで確定したものを正しいとするのか。
在庫はどちらの数字を信じるのか。
顧客住所はどちらで直すのか。
ここが決まっていないと、どの方式でつないでも「どちらに合わせるか」をその都度人が判断することになります。
転記は減っても、確認作業は残ります。

デジタル庁は、経済産業省とIPAのレガシーシステムモダン化委員会の内容を解説する記事で、ある状態を指摘しています。
改修を重ねた結果、どこにどのようなデータがどのような形で存在するのかわからない状態になりうる、というものです²。
これは古くなったシステム全般についての指摘で、連携の不具合がどれくらい起きるかを示すものではありません。
それでも、連携の相談を受けた担当者が最初に手を付ける場所を考える手掛かりにはなります。
どのデータがどこにあり、どちらが元なのかを書き出さないまま方式を選べば、つないだあとに所在の分からないデータがもう一つ増えるだけになりかねないからです。

そこで、業務の対象ごとに「正」を一つ決めます。
正とは、そのデータの元として扱うシステムのことです。
在庫数なら基幹システム、ECで受け付けた注文の内容ならEC、というように、対象によって正が変わってもかまいません。
顧客情報のように両方で更新したい対象は、項目ごとに分けて考えます。
住所はECで顧客本人が直したものを正とし、与信枠や請求先は基幹側を正にする、といった分け方です。
基幹の顧客情報を営業支援システムへ渡す場合は、営業支援側で直した住所を基幹へ戻すかどうかも、この段階で決めておきます。

渡す向きとタイミングを一覧にする

正が決まれば、渡す向きは自然に決まります。
次に決めるのは、いつ渡すかです。
ここでは、今の運用のタイミングと、業務が本当に必要とするタイミングを分けて書くことが大切です。
在庫を夕方に一度しか反映していない理由が、業務上それで十分だからなのか、CSV作業が一日一回しかできないからなのかで、次に選ぶ方式が変わります。

整理表には、少なくとも次の列を用意します。

• 業務の対象（注文、在庫、商品、顧客、売上・請求など）
• 正のシステム
• 渡す向き（基幹から相手へ、相手から基幹へ、両方向）
• 業務が必要とするタイミング（その場で、1時間以内、翌朝までなど）
• 今のやり方と、困っていること

この表は編集部が提案する整理の型で、決まった様式があるわけではありません。
ここで書いたタイミングは、後で比べる即時性の軸につながります。
対象の列は、連携項目を洗い出す単位になります。
表の行が埋まらない対象があれば、それは方式の問題ではありません。
社内で誰が決めるかの問題として、先に解いておく必要があります。

▼ 図の内容を文字で読む

1. 基幹システム
2. 在庫数の正
3. 与信枠・請求先の正
4. 在庫数をECへ渡す
5. ECサイト

連携項目は何を決めておくか：コード・必須項目・更新ルール・履歴

コード体系と採番元

整理表で「注文をECから基幹へ、毎朝」と決めたら、次はその注文に何を載せて渡すかです。
注文番号、受注日、顧客、商品、数量、単価、税区分、配送先、支払方法と、項目を並べること自体は難しくありません。
手戻りの元になりやすいのは、同じ商品や顧客を、両方のシステムが別の番号で呼んでいる場合です。

ECの商品にはSKUと呼ばれる在庫管理用の番号が振られ、基幹側には別の商品コードがある場合を考えます。
このとき、連携のどこかでSKUを商品コードに読み替える必要があります。
読み替え表を誰が作るのか、新商品が出たときに誰が追加するのかまで決めておかないと、新商品の注文だけが取り込みエラーになります。
顧客も同じです。
ECで初めて買った顧客には、基幹側の顧客コードがまだありません。
顧客コードを基幹で振るのか、EC側の会員番号をそのまま使うのか、つまり採番元をどちらにするかで、新規顧客の注文を受け取ったときの処理が変わります。

コードの読み替えは、ファイルでもAPIでも連携ツールでも、方式を問わず発生します。
方式を決めてから読み替えが必要だと気づくと、変換をどこで行うかを後から探すことになります。
項目を洗い出す段階で、読み替えが要る項目に先に印を付けておくと整理しやすくなります。

必須項目と型・桁

項目ごとに、型（数値か文字か日付か）、桁数、必須か任意かを両側で並べると、受け取る側が受け付けないデータが見えてきます。
たとえば、EC側の配送先住所が長い文字数まで入力できるのに、基幹側の住所欄の桁数が短ければ、取り込み時に文字が切れるか、エラーになります。
日付の書き方、全角と半角、金額の小数点以下の扱いも、両側の仕様を並べて初めて違いに気づく項目です。

必須項目のずれも同じです。
基幹側では担当者コードや部門コードが必須なのに、ECの注文にはその情報がない場合、連携のたびに誰かが補うことになります。
決め方には、既定値を入れる、受け取る前に補う、受け取らずに差し戻す、といった選択肢があります。
どれを選ぶかは業務側の判断で、方式を選んでも自動では決まりません。

新規・更新・削除と履歴の扱い

最後に、データが新しく作られたとき、変わったとき、消えたときの扱いを決めます。
注文がキャンセルされたら、基幹側の受注を削除するのか、取消の状態に変えるのか。
商品の販売を終えたら、ECへは削除として渡すのか、非表示の状態として渡すのか。
更新のときに全項目を上書きするのか、変わった項目だけを渡すのかも、受け取る側の処理に影響します。

履歴の持ち方も一緒に決めておきます。
単価が変わった商品について、過去の注文を変更前の単価のまま残す必要があるなら、基幹側が単価の履歴を持つのか、注文に単価を載せて渡すのかを決めることになります。
また、何をいつ送り、何が失敗したかという連携そのものの記録をどこに残すかも決めておきます。
この記録は、後で説明するエラー対応の前提になります。

ここまでの項目は、決めておくと後から迷いにくい観点として編集部が整理したもので、公的な様式があるわけではありません。
取引先のシステムとつなぐ企業間の連携では、相手が定めた仕様に合わせる部分が大きくなります。
自社で決められる項目と、相手に合わせる項目を分けて書いておくと、交渉や確認の範囲がはっきりします。

▼ 図の内容を文字で読む

1. コード体系と採番元
2. ECのSKUと基幹の商品コードの読み替え表
3. 顧客コードの採番元は基幹かECの会員番号か
4. 必須項目と型・桁
5. 住所欄の桁数のずれ

ファイル・API・DB直接・連携ツールは何が違うか：5つの軸で比べる

比較の5軸：即時性・データ量・再処理・改修可否・保守負担

項目が見えてきたところで、方式の比較に入ります。
比べる軸は、即時性、データ量、失敗したときの再処理、基幹側の改修可否、運用開始後の保守負担の5つです。
即時性とデータ量は最初に作った整理表のタイミングと件数から、再処理と保守負担は運用の体制から、改修可否は基幹システムの事情から答えが出ます。
軸ごとに答えを出す場所が違うため、ひとりの担当者だけで全部を埋めようとせず、業務側や提供元にも聞きながら埋めていくことになります。

方式の分類については、ITmediaの@ITに2015年に掲載された技術解説が、システム間連携をリソース共有、アプリケーション連携、ファイル連携、メッセージングの4つの基本パターンに分けています³。
リソース共有は相手のデータベースに直接アクセスする形で、この記事でいうDB直接連携にあたります。
アプリケーション連携は公開されたインターフェースを呼び出す形で、APIによる連携にあたります。
この解説はTISに所属する執筆者によるもので、公的な規格ではありません。
本文で詳しく説明されているのもこの2つで、ファイル連携は分類の見出しにとどまります。
また、EAIやiPaaSと呼ばれる連携ツール（複数のシステムの間でデータの変換や受け渡しを受け持つ製品やサービス）は、4つの分類の外にあります。

下の表では、この解説で確かめられる特性と、編集部の整理として置いた見立てを分けて示しています。
ファイル連携と連携ツールの欄は、方式の仕組みから考えた整理か、提供元で確かめる事項です。
方式に順位を付ける意図はありません。

DB直接連携が強い結合になる理由

@ITの解説は、相手のデータベースに直接アクセスして共有する方式について、整合性を保ちやすいとしています。
一方で、システム同士の依存関係が強くなり、使える機能は製品ごとに異なるため、事前の確認が必要だとも述べています³。
整合性を保ちやすいのは、間にファイルや別の処理を挟まず、同じデータそのものを見に行くからです。
在庫数を基幹側のテーブルから直接読めば、ファイルを待つ間のずれは生じません。

その代わり、連携する側は、基幹システムのテーブルの名前、列の意味、値の入り方を前提に作られます。
基幹システムの版上げで列が増えたり意味が変わったりすれば、連携側も直さなければなりません。
先に整理した項目定義は、本来は両側が約束として合意する範囲です。
DB直接連携では、その約束が基幹システムの内部構造そのものになります。
改修不要で早くつながるように見えても、保守負担の軸では重くなりやすい、というのがこの方式の読み方です。
基幹システムの提供元がデータベースへの直接の参照や更新を認めているかどうかも、保守の条件にかかわるため、事前に確かめておく項目です。

API連携の待ちと再試行

APIは、システムが外部からの呼び出しを受け付けるために公開している窓口です。
@ITの解説は、公開されたインターフェースを経由するアプリケーション連携について、リアルタイムに連携できるとしています。
一方で、呼び出し先の処理が重いと呼び出し元が待たされ、失敗したときの再試行も設計が必要だと述べています³。
結果をすぐに待たない非同期の方式では、処理が終わった側から知らせる（コールバック）か、呼び出した側が定期的に問い合わせる（ポーリング）ことで結果を受け取る、とも説明しています³。

在庫の例に置き換えてみます。
ECで注文が入るたびに基幹の在庫を問い合わせれば、夕方まで在庫がずれる問題は小さくなります。
ただ、基幹システムの処理が重い時間帯に問い合わせが集中すれば、ECの画面側が待たされます。
問い合わせが失敗したとき、注文を受け付けて後で在庫を引き当て直すのか、受け付けを止めるのかは、APIがあるだけでは決まりません。
即時性を得る代わりに、待ちと失敗の扱いを業務の判断として設計する必要がある点が、まとめて渡すファイル連携との大きな違いです。

同じ解説は、RESTと呼ばれる形式は実装が簡単な一方、複雑な型のチェックが必要な場合には向かないとも述べています³。
項目定義で型や桁のずれを洗い出しておくと、どこでチェックを行うかを決めるときの材料になります。
なお、これは2015年時点の解説で、現在のクラウドサービスや連携ツールの状況は反映されていません。
個々の製品のAPIが何を受け付けるかは、その製品の公式仕様で確かめることになります。

自社の基幹システムと相手システムの条件から、どの方式を先に検討するか

基幹側が公開しているインターフェースの確かめ方

5つの軸のうち、改修可否は、検討を始める前から答えが決まっていることがある軸です。
基幹システムがAPIを公開していなければ、API連携は選べません。
データベースへの直接の参照が認められていなければ、DB直接連携も選べません。
つまり、選択肢の上限を決めるのは、基幹システムが外に向けてどんな出入口を用意しているかです。

提供元の公式仕様やマニュアル、保守窓口で確かめるのは、次のような点です。

• APIの有無と、扱えるデータの範囲（注文の登録はできるが在庫の参照はできない、といった差がないか）
• ファイルの取り込み・出力の機能と、その形式や自動実行の可否
• データベースへの直接の参照や更新が、保守の条件上認められているか
• これらを使うための追加の契約や設定の有無

相手側のシステムについても同じ点を確かめます。
相手がクラウドで提供されるサービスであれば、ファイルの取り込みには対応していても、データベースには触れられない、という組み合わせもありえます。
両側の出入口を並べ、共通して使えるものだけが方式の候補として残ります。

改修できない場合の考え方

デジタル庁の解説記事は、レガシーシステム（長年の改修で構造が複雑になった古いシステム）がユーザー企業の61%、大企業では74%で残っているという調査結果を紹介しています。
そのうえで、既存のシステムに新しい技術をつなげることは難しいと指摘しています²。
この割合は古いシステム全般の残り具合を示すもので、自社の基幹システムがそれに当たるかどうかや、会社の規模ごとの状況までは示していません。
自社の基幹システムが同じ状況にあるなら、連携のために基幹側を改修する案は、費用以前に、改修を引き受けられる人や提供元がいるかという点でつまずくことがあります。

改修が難しいときは、基幹側に手を入れない方式を先に検討するのが筋です。
具体的には、基幹システムがすでに持っているファイルの取り込み・出力機能や、公開済みのAPIのように、今ある出入口だけを使います。
コードの読み替えや形式の変換、失敗時のやり直しは、基幹の外側で受け持つ形です。
連携ツールを使う場合も、ツールが基幹とつながる口は基幹側の出入口です。
出入口がなければ、ツールだけでは補えません。
これは編集部の考え方としての整理で、どの方式が使えるかは、前の手順で確かめた出入口次第です。

改修不要に見えるからといって、基幹のデータベースへ直接書き込む方法を選ぶのは、慎重に考えたいところです。
先に見たとおり依存関係が強くなるため、古い基幹システムほど、版上げや刷新のときに連携側の作り直しが重なります。

日本情報システム・ユーザー協会（JUAS）の企業IT動向調査2026では、2025年度にIT予算が増えた企業の理由として、「既存システム・基盤の刷新・更新・増強」が66.3%で最も多く挙げられています¹。
東証上場企業とそれに準じる企業のIT部門長への調査（957社が回答）で、刷新全般の理由を尋ねたものですから、連携方式の選び方を示す数字ではありません。
ただ、自社でも基幹システムの刷新が予定に入っているなら、今つくる連携は刷新後に置き換える前提で考える判断もありえます。
その場合は、作り込みよりも、項目定義と整理表を引き継げる形で残すことに力を割くことになります。

即時性とデータ量による絞り込み

出入口で候補が残ったら、最初の整理表に書いたタイミングと、件数の見込みで絞ります。
在庫の引き当てのように、数分の遅れでも売り越しにつながる対象は、即時性を優先します。
この場合、APIで問い合わせる形が候補の先頭に来ます。
一方、日々の売上を会計システムへ渡すように、翌朝までに揃えばよい対象は、まとめて渡すファイル連携で足りることがあります。
APIで一件ずつ送る必要は薄くなります。

データ量は、即時性と引き換えになりやすい軸です。
一件ずつすぐに渡す形では、件数が多い時間帯に呼び出しが集中し、先に見た待ちの問題が表に出ます。
商品マスタの全件入れ替えのように一度に大量の件数を渡す処理と、注文のように一件ずつ発生する処理を、同じ方式でつなぐ必要はありません。
対象ごとに方式を分けてかまいません。
同じ基幹システムでも、在庫はAPI、売上はファイル、という組み合わせは自然な選択です。

ここまでの判断の流れを図にすると、次のようになります。
条件ごとの方式は編集部の提案で、出入口の確認結果によっては、先頭の候補が使えないこともあります。

▼ 図の内容を文字で読む

1. 基幹と相手の出入口を確かめる
2. 基幹側を改修できるか
3. 業務が必要とするタイミング
4. データ量と対象の分け方

連携後にエラーや項目変更が起きたら：検知・再処理・変更管理を先に決める

検知する人と再処理の単位

方式が決まると、つくる作業に目が向きがちです。
しかし、運用が始まってから困りやすいのは、失敗したときです。
@ITの解説はAPI連携について失敗時の再試行の設計を求めています³。
どの方式でも、届かなかったデータや受け付けられなかったデータの扱いは、つくる前に決めておく必要があります。
編集部としては、検知する人、再処理の単位、二重取り込みの確認、項目変更時の連絡経路の4点を先に決めることを提案します。

検知する人を決めるときは、エラーの種類によって担当が変わることを踏まえます。
通信が途切れて届かなかったものは、情報システム担当者が再送すれば済みます。
一方、商品コードの読み替え表に新商品がなかった、必須の担当者コードが空だった、というエラーはどうでしょうか。
業務側がマスタを直さない限り、何度送っても同じところで止まります。
エラー通知の宛先を一か所にまとめると、受け取った人が自分では直せないエラーを抱えることになります。
種類ごとに受け取る人と対応の期限を決めておくと、止まったままの注文が残りにくくなります。

再処理の単位は、1件ずつやり直すのか、1回分のファイルや1回の実行をまとめてやり直すのか、という選択です。
まとめて取り込んだ注文のうち一部だけが失敗したとき、ファイル全体を取り込み直せば、成功していた注文が重なります。
失敗した注文だけを送り直すには、失敗した行を特定できる記録が必要です。
項目定義の段階で決めた連携の記録は、ここで使われます。

二重取り込みを防ぐ確認

再送や取り込み直しで起きやすいのが、同じ注文が基幹側に二重に登録されることです。
設計の考え方として、同じ要求を何度送っても、結果が一度送ったときと変わらないようにすることを冪等性（べきとうせい）と呼びます。
たとえば、ECの注文番号を連携のキーとして基幹側にも持たせ、同じ注文番号が来たら新しく登録せずに既存の受注と照らし合わせる、という形です。
どのように実現するかは方式や製品によって異なるため、ここでは考え方の紹介にとどめます。

仕組みとは別に、確かめる手段も用意しておきます。
送った側と受け取った側で一日分の件数と金額の合計を突き合わせれば、二重に入ったものや届かなかったものがあるかどうかの手掛かりになります。
件数や合計が合わないときも、それだけで原因を決めつけないことが大切です。
連携キーごとの明細を照合して、どの注文が重なったのか、あるいは欠けたのかを特定します。
突き合わせを手作業で続けるのか、連携の仕組みに組み込むのかも、保守負担の軸で考える事項です。

項目変更時の連絡経路

連携は、つないだ時点の項目定義を前提に動いています。
相手のサービスが項目を追加したり、基幹システムの版上げで桁数が変わったりすると、エラーにならないまま値が欠けたり切れたりすることもあります。
エラーが出ないずれは、検知の仕組みでは拾えません。
変更の情報を事前に受け取る経路を決めておくことが、ここでの対策になります。

具体的には、相手のサービスや基幹システムの提供元からの仕様変更の案内を誰が受け取り、連携への影響を誰が判断するかを決めます。
変更があったら項目定義の表を更新し、本番の前に試験用の環境で一度流してみる、という手順を書き残しておきます。
そうすれば、担当者が替わっても同じ確認ができます。
項目定義の表を最初に作っておくと、ここで変更の影響範囲を調べる手間も減らせます。

▼ 図の内容を文字で読む

1. 検知（種類ごとに受け取る人を決める）
2. 原因の切り分け（通信の失敗かマスタや項目の不備か）
3. 再処理（1件単位か1回分の実行単位か）
4. 突き合わせ（件数・金額の合計と連携キーごとの明細）
5. 項目定義の更新（仕様変更の案内を受け試験用の環境で確認）

方式を決めて進める順序：確認事項チェックと小さく試す

並行して進められる確認

ここまでの判断を、作業の順に並べると次のようになります。

1. 業務の対象ごとに、正のシステム・渡す向き・タイミングを整理表にする
2. 対象ごとに連携項目を定義し、コードの読み替えが要る項目に印を付ける
3. 基幹側と相手側の出入口（API、ファイル入出力、DB参照の可否）を提供元の仕様で確かめる
4. 改修可否・即時性・データ量・再処理・保守負担の5軸で、対象ごとに方式を絞る
5. 検知する人、再処理の単位、二重取り込みの確認、項目変更時の連絡経路を決める
6. 範囲を絞って試し、結果を見て広げる

このうち、3番目の出入口の確認は、1番目や2番目と同時に始められます。
提供元への問い合わせは、返事を待つ時間がかかることがあります。
整理表と項目定義が固まってから聞くと、そこで作業が止まります。
先にAPIやファイル入出力の仕様書を取り寄せておけば、項目定義の段階で型や桁を実際の仕様と照らし合わせられ、項目定義のやり直しも減らせます。
相手側のシステムが取引先のものであれば、相手の担当窓口への確認も同じ時期に始めておくと進めやすくなります。

社内で迷いやすいのは、正のシステムを誰が決めるかです。
在庫の正は物流部門、顧客住所の正は営業部門、というように業務の持ち主が分かれていると、情報システム担当者だけでは決めきれません。
整理表の行ごとに決める人の名前を書く列を足しておくと、どこで止まっているかが見えます。

小範囲での試行

方式が決まっても、すべての対象を一度に切り替える必要はありません。
まずは注文だけ、あるいは特定の店舗や商品分類だけのように範囲を絞ります。
今のCSVの運用と並べて動かしてみると、項目定義で見落としたずれが、少ない件数のうちに見つかります。
並行して動かす期間は、連携の結果と手作業の結果を突き合わせられます。
運用の検討で決めた件数と合計の照合を、実際に試す機会にもなります。

試行で確かめたいのは、つながることそのものよりも、失敗したときの手順が回るかどうかです。
わざと読み替え表にない商品コードを流してみる、通信を止めてから再送してみる、といった確認を一度行います。
そうすれば、エラー通知が決めた人に届くか、再処理で二重に登録されないかが分かります。
本番のデータを使う場合は、試験用の環境で行えるかを提供元に確かめてから実施します。

試行の結果、転記が減った作業と、まだ残っている確認作業を書き出しておくと、次の対象に広げるかどうかの判断材料になります。
連携は一度つないで終わりではありません。
対象を足し、項目が変わるたびに、整理表と項目定義に戻ってくる作業です。
最初の整理表を丁寧に作っておくことが、その後の判断を軽くする助けになります。

基幹側と相手側の出入口を並べ、対象ごとにどの方式が候補に残るかを見極めるには、両方の仕様を読み比べる必要があり、社内だけでは判断に迷いやすい部分です。

業務対象の整理表と項目定義の案をもとに、候補に残る方式と、提供元へ確かめるべき点を整理できます。無料相談で要件を整理する

5つの軸で自社の条件を確かめる問い

比較の5軸それぞれについて、自社の業務対象に当てはめて答える問いとして整理した

• 即時性：その対象のデータが何分、何時間遅れると業務で困るか

• データ量：一度にまとめて渡す処理と、一件ずつ発生する処理のどちらが中心か

• 再処理：失敗したデータを1件単位で特定して、やり直せるか

• 改修可否：基幹側に手を入れられるか、入れるなら誰が引き受けるか

• 保守負担：仕様変更や障害のとき、誰が対応し続けるか

即時性とデータ量の答えが対象ごとに違えば、方式も対象ごとに分けて選ぶ

要点の整理

最初に決めること	業務の対象ごとに、正のシステム・渡す向き・タイミング
項目定義	コードと採番元、型・桁と必須、新規・更新・削除、履歴
方式の候補を決めるもの	基幹側と相手側が公開している出入口
絞り込みの軸	即時性・データ量・再処理・改修可否・保守負担
改修できない場合	今ある出入口を使い、変換と再処理は外側で受け持つ形を先に検討
運用で先に決めること	検知する人、再処理の単位、二重取り込みの確認、項目変更時の連絡経路

運用が始まってからのエラー対応や項目変更は、担当や手順を決めないまま進めると、止まった注文や重複した登録が残りやすくなります。 検知する人、再処理の単位、二重取り込みの確認方法が自社の体制で回るかを、試行の範囲とあわせて確認できます。

よくある質問

基幹システムが外部向けのAPIを持っていない場合、まず何を確認すればよいですか。

まず、ファイルの取り込み・出力機能があるか、その形式と自動で実行できるかを、提供元の公式仕様や保守窓口で確かめます。
あわせて、データベースへの直接の参照が保守の条件上認められているかも確認します。
ただし、認められていても依存関係が強くなる点は考慮が必要です。
APIがなくても、ファイルの出入口を使い、変換や再処理を基幹の外側で受け持つ形で連携できる場合があります。

連携は一度に全部つなぐべきですか、それとも業務対象ごとに分けて始めるべきですか。

業務の対象ごとに分けて始める方が進めやすくなります。
対象によって正のシステムも必要なタイミングも違うため、方式も対象ごとに変わりえます。
注文など困りごとの大きい対象から小さな範囲で試し、失敗時の手順が回ることを確かめてから広げると、見落としたずれを少ない件数のうちに見つけられます。

相手システムの仕様変更や項目追加は、どう検知して対応すればよいですか。

項目の追加や桁数の変更は、エラーにならないまま値が欠けたり切れたりすることがあるため、エラー通知だけでは拾えないことがあります。
相手のサービスや提供元からの仕様変更の案内を誰が受け取り、連携への影響を誰が判断するかを決めておきます。
変更があれば項目定義の表を更新し、本番の前に試験用の環境で流して確かめます。

同じデータが二重に取り込まれていないかは、どう確かめればよいですか。

送った側と受け取った側で、一日分の件数と金額の合計を突き合わせるのが手掛かりになります。
合わないときは、注文番号などの連携キーごとの明細を照合し、どれが重なったか、欠けたかを特定します。
あわせて、同じ連携キーが再び届いたら新しく登録せずに照らし合わせる、という冪等性の考え方を設計に取り入れられるかを、方式や製品の仕様に照らして検討します。

連携ツール（EAIやiPaaS）を使えば、基幹側の改修は不要になりますか。

必ずしも不要にはなりません。
連携ツールは、基幹システムとつながるときに基幹側の出入口（APIやファイル入出力など）を使います。
基幹側が必要なデータを出し入れできなければ、ツールだけでは補えません。
どの基幹システムや相手サービスにつなげられるか、変換や再実行をどこまで任せられるかは製品ごとに異なるため、ツールの提供元と基幹システムの提供元の両方で確かめます。

1. 1　出典：一般社団法人日本情報システム・ユーザー協会（JUAS）「企業IT動向調査2026 プレスリリース第1弾」（2026年）
2. 2　出典：デジタル庁「デジタル庁ニュース：レガシーシステムモダン化委員会 総括レポート解説」（2025年）
3. 3　出典：ITmedia @IT「システム間連携のアーキテクチャ、4つの基本パターンと整理・適用のポイント（ITアーキテクトとは何か？(4)）」（2015年）