基幹システムのデータ連携、外注前に決める発注手順

何から調べる？ 連携先の仕様を先に確認する

連携の可否は、つなぐ相手の仕様で決まります。見積もりを取る前に、既存システムやサービスが外部連携の口を公開しているかを確認してください。

順序を逆にすると、要望を伝えて見積もりが出てから「その連携はできません」と分かる事態になります。相手の仕様は、発注側の予算でも受注側の技術力でも変えられません。

確認する3つの項目

確認するのは次の3項目です。いずれも公式のドキュメントやFAQに書かれていることが多く、発注前に自社で調べられます。

確認項目	具体的に見ること
読み取りができるか	外部から参照できるAPIがあるか、CSVの書き出し機能があるか
書き込みができるか	外部から登録や更新ができるか、読み取り専用か
取得できる粒度	明細単位で取れるか、日次や月次の集計しか取れないか

3つめの粒度が、実務ではいちばん効きます。明細が取れないと、後工程で集計をやり直すことも、内訳を確認することもできません。

公式ドキュメントで裏取りする

当社では、小規模店舗で広く使われているPOSサービスを在庫や売上の情報源の正として扱う設計を検討したとき、公式情報で仕様を裏取りしました。結果は次のとおりです。

• 外部から参照できるAPIは読み取り専用であること
• 取得できるのは限られたカテゴリの日次集計にとどまり、商品単品の粒度では取れないこと
• 書き込みのAPIは提供されていないこと

つまり、POS側へ在庫数を書き戻す運用は成立せず、CSVの受け渡しを前提に設計するほかありませんでした。もしこれを調べずに進めていたら、書き戻しを前提にした見積もりがそのまま通っていたはずです。

発注前にやることは次のとおりです。

1. 連携したいサービスの公式ドキュメントとFAQを開く（所要時間の目安: 半日）。
2. 上の3項目について、書かれている内容をそのまま書き写す（つまずきやすい点: 営業担当の説明だけで判断すること。書面の仕様と食い違うことがあります）。
3. 分からない項目は、提供元の窓口に問い合わせて回答を文面で残す。
4. 調べた結果を、見積もり依頼の資料に添付する。

4つめまでやっておくと、受注側の前提も揃います。方式の選び方は次のセクションで扱います。

連携方式にはどんな選択肢がある？ 4つの型で比較する

連携方式は、API連携、ファイル連携、データベース直接参照、手動の書き出しと取り込みの4つに整理できます。相手の仕様と更新の頻度で選びます。

どれが優れているという話ではありません。相手が読み取り専用のAPIしか公開していなければ、書き込みを伴う連携はそもそも選択肢から外れます。

4つの方式の比較

方式	向いている場面	注意する点
API連携	相手が外部連携の口を公開している	取得できる粒度と回数の制限を確認する
ファイル連携	CSVの書き出しと取り込みができる	受け渡しの間に起きた更新の扱いを決める
データベース直接参照	自社で管理しているシステム同士	相手の更新で壊れやすく、保守契約の範囲を確認する
手動の書き出しと取り込み	頻度が低く、件数も少ない	担当者の作業として残るため、手順を文書化する

4つめを最初から除外しないでください。月に1回、数百件の連携であれば、作り込むより手作業のほうが総額で安く済むこともあります。

実装者の視点で注意したいのは、2つめのファイル連携です。CSVを全件上書きする方式にすると、ファイルを書き出してから取り込むまでの間に発生した更新が、警告もなく消えます。当社では差分のみを反映する方式に変更し、取り込みを営業時間外のバッチに寄せ、送信済みかどうかのフラグを持たせて二重反映を防ぐ設計にしました。

この種の事故は、動作確認では見つかりません。テストのときには、書き出しと取り込みの間に更新が起きないためです。

リアルタイム連携が必要かを見極める

リアルタイムでの同期は、実現の難易度も費用も上がります。まず、本当に必要かを業務から確認してください。

1. 連携したデータを、誰がいつ見るかを書き出す（所要時間の目安: 2時間）。
2. 更新から反映までどれくらい遅れて困るかを、業務ごとに答える（つまずきやすい点: 全部を即時と答えてしまうこと。理由を添えられない項目は、たいてい即時でなくても回ります）。
3. 即時が必要な業務だけを抜き出し、それ以外は日次や時間単位でまとめる。
4. 抜き出した業務について、相手の仕様が即時の取得に対応しているかを確認する。

夜間バッチで足りる業務にリアルタイム連携を組むと、費用だけでなく障害時の影響も大きくなります。止まったときに誰が気付くかという話は、後のセクションで扱います。

なぜ既存システムが足かせになる？ 公的資料が示す構造

既存システムの老朽化が、データの一元管理やシステム間の連携を妨げているという指摘が公的資料で示されています。連携の難しさは自社固有の問題ではありません。

経済産業省は2018年9月7日に公表した「DXレポート ITシステム「2025年の崖」の克服とDXの本格的な展開」の中で、老朽化、複雑化、ブラックボックス化した既存システムを放置した場合、2025年から2030年の間に最大で年間12兆円の経済損失が生じる可能性があると指摘しています（出典: 経済産業省「DXレポート」2018年9月7日公表）。

レガシーシステムと連携の関係

同レポートでは、2025年には大企業の約6割で基幹系システムが導入から21年以上経過するとされています。また、2025年までに先端IT人材が不足し、その規模は約43万人に達すると予測されています（出典: 同レポート）。

導入から20年以上経ったシステムは、当時の前提で作られています。外部とデータをやり取りする想定が無ければ、連携の口も用意されていません。

老朽化が連携に及ぼす影響	発注時に現れる形
外部連携の口が無い	ファイルの書き出しに頼らざるをえない
仕様書が残っていない	データの意味を調べる工数が別途かかる
改修できる人がいない	既存側を触らない設計に寄せる必要がある

3行目は特に重要です。既存側を改修できないなら、連携は新しいシステム側で吸収する設計になります。この前提を見積もり依頼の時点で伝えておくと、提案の精度が上がります。

全面刷新と連携のどちらを選ぶか

老朽化しているなら全面刷新すべきだ、という話に直結させないでください。刷新は費用も期間も大きく、業務を止めるリスクも伴います。

判断の順序は次のとおりです。

1. 今困っていることが、連携で解消するのか刷新でないと解消しないのかを切り分ける（つまずきやすい点: 使いにくさと連携できないことを混ぜて議論すること）。
2. 既存システムをあと何年使う想定かを決める（所要時間の目安: 半日）。
3. 連携で対応する場合の費用と、刷新する場合の費用の両方を出してもらう。
4. 連携を選ぶ場合、既存側に手を入れない前提で設計できるかを確認する。

2つめが決まると、議論が具体的になります。あと2年で入れ替える予定なら、作り込まずに手作業を残す判断も合理的です。

なお、外部サービスと自社システムを連携する設計では、どちらの情報を正として扱うかを先に決めておく必要があります。決めないまま進めると、老朽化したシステムと同じように、データの不整合と連携の複雑化を自ら作り出すことになります。

データ量はどこまで見込む？ 件数から設計が変わる

扱うレコード件数を先に見積もってください。件数が一定を超えると、処理のやり方そのものを変える必要があります。

見積もり依頼に件数が書かれていないと、受注側は小さい前提で設計します。稼働してから件数が想定を超え、処理が終わらないという事態は、発注時の情報不足から起きます。

件数の数え方と将来分の見込み

数えるのは、初回に移行する件数と、毎日増える件数の2つです。この2つがあれば、数年後の規模も計算できます。

1. 既存システムから対象テーブルの件数を出す（所要時間の目安: 1時間。システム担当者か保守会社に依頼します）。
2. 1日あたりまたは1か月あたりの増加件数を数える（つまずきやすい点: 繁忙期の山を平均に均してしまうこと。最も多い月で見てください）。
3. 何年分を保持するかを決める。
4. 初回移行分と、保持期間分の合計を見積もり依頼に書く。

3つめを決めていない会社は多いのですが、ここが決まると設計が楽になります。3年で締める前提なら、無制限に増え続ける設計にする必要はありません。

件数が大きい場合に確認すること

当社では、不動産情報の連携基盤において140万件を超えるレコードをPythonとpandasで処理した実績があります。この規模になると、1件ずつ処理する素直な書き方では現実的な時間で終わりません。列単位のベクトル化された演算と、メモリに載る単位への分割処理が前提になります。

ただし、件数が増えたときに本当に効いてくるのは処理の速さそのものではありません。次の2点です。

確認する観点	具体的に聞くこと
途中で失敗したときの再開	どこから再開できますか。最初からやり直しになりますか
同じ処理を2回流したとき	結果は変わりませんか。二重に登録されませんか
処理にかかる時間	想定件数で何分かかりますか。業務時間に影響しますか
件数が増えたとき	何件までなら構成を変えずに耐えられますか

上の2つは、発注側が受注側に必ず聞いてほしい項目です。夜間の処理が途中で落ちたとき、翌朝に最初からやり直すしかない作りだと、業務開始に間に合いません。

同じ処理を2回流しても結果が変わらないかも重要です。失敗したかどうか分からないときに、もう一度流せる作りになっていれば、運用の負担が大きく減ります。

これらは稼働後に直そうとすると作り直しに近い規模になります。見積もりの段階で聞いておいてください。

責任範囲はどう決める？ 発注時に書いておくこと

連携先の仕様変更で動かなくなった場合に誰が対応するかを、発注時に決めます。ここを決めないまま進めると、障害のたびに交渉が始まります。

連携は、自社と受注側だけで完結しません。相手のサービスや既存システムの保守会社という第三者が関わるため、責任の線引きが曖昧になりやすい領域です。

書いておく4つの項目

契約書または仕様書に書く項目は次の4つです。

項目	書く内容
連携の対象範囲	どのデータを、どの方向に、どの頻度で流すか
前提とする仕様	調べた相手の仕様を、日付とともに明記する
監視と通知	連携が止まったとき、誰がどう気付くか
仕様変更時の扱い	相手の仕様が変わった場合の対応と費用の考え方

2つめの「前提とする仕様」を日付つきで書くことが要点です。相手の仕様は将来変わりうるため、契約時点でどの仕様を前提に見積もったのかを残しておかないと、変更時の議論ができません。

3つめも忘れられがちです。夜間バッチで連携している場合、止まったことに誰も気付かないまま数日経つ例があります。失敗時に通知が飛ぶ仕組みを、最初から入れてもらってください。

1. 連携の対象データと方向を一覧にする（所要時間の目安: 半日）。
2. 調べた相手の仕様を、確認日と出典つきで資料にまとめる（つまずきやすい点: 口頭で共有して書面に残さないこと）。
3. 止まったときの通知先と、一次対応を誰がするかを決める。
4. 相手の仕様変更があった場合の対応を、保守契約の範囲に含めるかどうかを決める。

連携先の仕様変更への備え

相手のサービスが仕様を変えることは、珍しくありません。備えとしてできるのは、変更の通知を受け取れる状態にしておくことと、変更時の費用の扱いを先に決めておくことです。

費用の扱いは、次のどれかに寄せると揉めにくくなります。

• 保守契約の範囲に含め、月額に織り込む
• 発生時に都度見積もりとし、上限の目安だけ決めておく
• 軽微な変更は保守の範囲、大きな変更は別見積もりと線を引く

どれが良いかは連携の重要度で決まります。止まると業務が止まる連携なら、1つめに寄せておくほうが安心です。

連携の設計は、相手の仕様という自社では変えられない条件の上に立ちます。何を確認し、何を契約に残すかで、稼働後の負担が大きく変わります。判断に迷う場合は、無料診断で現状の整理からご相談ください。

つまずきやすい点は？ 発注側が見落とす3つのこと

相手の仕様を確認せずに見積もりを取る、更新の頻度を決めない、連携が止まったときの運用を決めないという3点が、稼働後の手戻りにつながります。いずれも発注前に手を打てます。

更新の頻度と停止時の運用については、ここまでのセクションで扱いました。ここでは、仕様の制約が持つ意味と、止まったときの人の動きを整理します。

仕様の制約は後から変えられない

当社がPOSサービスの仕様を調べたとき、外部から参照できるAPIは読み取り専用で、書き込みのAPIは提供されていませんでした。この制約は、発注側がいくら要望しても変わりません。

制約を先に知っていれば、設計を寄せられます。当社では在庫の書き戻しを諦め、CSVの受け渡しを前提に、差分のみを反映する方式へ切り替えました。取り込みは営業時間外のバッチに寄せ、送信済みかどうかのフラグを持たせて二重反映を防いでいます。

仕様の制約は設計を縛りますが、縛られ方を先に調べておけば、後から気付く整合性の事故は避けられます。逆に、調べずに進めた場合に起きるのは次のような事態です。

確認を飛ばした場合	稼働前後に起きること
書き込みの可否	書き戻し前提の設計が途中で崩れる
取得できる粒度	必要な内訳が取れず、手作業の集計が残る
取得の回数制限	想定した頻度で取れず、連携の間隔を延ばすことになる

止まったときの運用を先に決める

システムの作りだけでなく、人の動きも決めておいてください。連携は、止まること自体を前提に運用を組みます。

1. 止まったことに誰が気付くかを決める（つまずきやすい点: 通知先を担当者個人のメールだけにすること。休暇中に気付けません）。
2. 止まっている間、業務をどう回すかを決める（所要時間の目安: 半日）。
3. 復旧後に、止まっていた間のデータをどう反映するかを決める。
4. 手順を1枚にまとめ、担当者以外も読めるところに置く。

3つめは設計にも関わります。止まっていた間の差分を後から流し込めるか、それとも手入力で埋めるかで、必要な作り込みが変わるためです。

連携は一度作れば終わりではなく、相手の変化に合わせて手当てが続く仕組みです。発注の段階で、作る費用だけでなく、維持する体制まで含めて見ておいてください。

よくある質問

発注前の相談で実際に聞かれることの多い質問をまとめました。費用の具体額は案件により変動するため、判断の順序を中心に整理しています。

基幹システムを入れ替えずに、新しいシステムと連携できますか？

つなぐ相手の仕様によります。外部から参照できるAPIやCSVの書き出し機能があれば、既存側に手を入れずに連携できることが多くなります。既存側を改修できない場合は、新しいシステム側で差異を吸収する設計に寄せます。まず公式ドキュメントで読み取りの可否、書き込みの可否、取得できる粒度の3点を確認してください。

API連携とファイル連携では、費用はどれくらい違いますか？

金額の目安は案件により変動するため、ここでは示しません。判断の基準になるのは、更新の頻度と件数です。月に1回、数百件であれば、作り込むより手作業を残すほうが総額で安く済むこともあります。頻度が高く件数も多い連携ほど、自動化した場合の効果が大きくなります。

連携先のサービスが仕様を変更した場合、追加費用はかかりますか？

契約での取り決めによります。保守契約の範囲に含める、都度見積もりとする、軽微な変更のみ保守の範囲とするなど、方式を先に決めておいてください。あわせて、契約時点でどの仕様を前提に見積もったのかを、確認日つきで書面に残しておくことが重要です。

リアルタイムで同期する必要があるかは、どう判断すればよいですか？

連携したデータを誰がいつ見るかを書き出し、更新から反映までどれくらい遅れて困るかを業務ごとに答えてください。理由を添えられない項目は、たいてい即時でなくても回ります。即時が必要な業務だけを抜き出し、相手の仕様が即時の取得に対応しているかを確認する順序になります。

連携がうまくいかなかった場合、どちらの責任になりますか？

前提とした仕様のとおりに動かないのか、仕様そのものが変わったのかで扱いが変わります。だからこそ、前提とする仕様を日付つきで契約書に書いておく必要があります。相手のサービスや既存システムの保守会社という第三者が関わるため、三者の役割を発注時に整理しておいてください。

最後に、発注までの流れをまとめます。

1. つなぐ相手の仕様を公式ドキュメントで確認する（所要時間の目安: 半日）。
2. 更新の頻度と件数から、連携方式を絞る（つまずきやすい点: すべてを即時同期にすること）。
3. 前提とする仕様、監視と通知、仕様変更時の扱いを契約に書く。
4. 止まったときの人の動きを手順にまとめる。

関連リンク

• 基幹システム連携の進め方を無料診断で整理する
• システム発注の進め方をまとめたDXガイドブック
• システム開発の料金の考え方
• システム導入に使える補助金の情報