--- title: "ERP連携とは？連携先別の設計とAPI上限から決める方式選定・失敗条件" url: "https://www.issoh.co.jp/column/details/10850/" published: 2026-02-04 updated: 2026-10-12 categories: ["ERP"] publisher: "株式会社一創" --- # ERP連携とは？連携先別の設計とAPI上限から決める方式選定・失敗条件 ERP連携でつまずく原因は、方式の知識不足ではなく、繋ぎたいERPが1分間に何回呼べるかを確認しないまま設計に入ることにあります。Microsoftが公開しているDynamics 365 Business Centralの上限は、利用者単位で5分間に6,000件、同時に処理される要求は5件です。freee会計の証憑アップロードAPIは事業所単位で1分間に300回で、しかも超過は429ではなく400で返ります。この記事では、ERP連携の定義と連携先別の設計を整理したうえで、公開されている上限値から方式を逆算する手順と、二重計上が起きる条件をまとめます。 ## まとめ ERP連携とは、ERPと周辺システムを接続し、マスタやトランザクション、業務イベントを共有する仕組みです。どのシステムを正本にするかは製品単位で固定するものではなく、顧客名、与信限度額、受注といったデータ項目ごとに決めます。一度きりのデータ移行とは別物で、締め処理や再送との整合を設計に織り込む必要があります。 連携方式はAPI、ファイル、データベース直結、連携基盤の4類型ですが、どれを選べるかはERP側の上限が先に決めます。Dynamics 365 Business Centralは1ページ最大20,000件、OData要求のタイムアウト8分、バッチ要求の操作数100件といった上限を公開しており、設計はこの範囲を前提に組む必要があります。 事故が集中するのは、レート超過の応答コードが429とは限らない点、上限の単位が利用者ではなくテナントである点、部分成功した送信を丸ごと再送して二重計上する点の3つです。以下、連携先ごとの設計から順に見ていきます。 ## ERP連携の定義と、データ移行との違い ERP連携は、ERPと会計、販売、人事、倉庫といった周辺システムとの間でデータを流し続ける状態を作ることを指します。[ERPそのものの役割と基本機能](/column/details/12806/)が単一データベースへの業務統合であるのに対し、連携はその外側に残るシステムとの接続を扱います。 設計の出発点は、どのデータをどのシステムが所有するかを決めることです。Microsoftの実装ガイダンスは、Dynamics 365 SalesとFinanceの間で取引先と得意先を連携する例として、顧客名と連絡先はSales側、与信限度額と支払条件はFinance側が所有すると説明しています。所有者はシステム単位ではなく項目単位で分かれる、という前提を最初に共有しておかないと、双方向の更新が衝突します。 データ移行との違いは、時間軸と可逆性にあります。移行は一度実行して終わり、失敗すればやり直せます。連携は毎日動き続けるため、1回の失敗が翌日以降の残高や在庫にずれとして蓄積します。したがって連携設計の中心は、データ変換の作り込みよりも、失敗したときにどこまで戻せるかという再実行の設計になります。 もう1つの前提が、どこまでをERPの標準機能で賄うかという線引きです。ERPが標準で持つ範囲は製品ごとに違うため、[ERPモジュールの機能範囲](/column/details/10898/)を先に確認し、モジュールで足りる部分を外部連携で作り込まないようにします。 ## ERPの連携先別に決まる同期の向きと粒度 連携先ごとに、データが流れる向きと同期の粒度は変わります。ここを一律にリアルタイム双方向で設計すると、後述する上限に真っ先に当たります。 ### 会計システムとの連携 販売や購買で発生した明細をそのまま会計へ送る設計は、件数が膨らむうえに仕訳の修正が追えなくなります。日次や締め単位で集計した仕訳として、ERPから会計への一方向で送る構成が扱いやすくなります。 ただし証憑ファイルは明細単位で送ることが多く、この部分が上限に当たりやすい箇所です。freee会計のファイルボックス（証憑ファイル）アップロードAPIは、事業所単位で1分間に300回という上限が設定されています。明細をそのまま送るか日次集計にするかは、会計側が求める証跡の粒度と訂正仕訳の運用を確認したうえで決めます。ERP内部で会計をどこまで持つかは[ERPの会計機能と部門別採算の設計](/column/details/10910/)の範囲と重なるため、二重に持たない切り分けも必要です。 ### CRM・SFAとの連携 顧客マスタと案件情報の所有者を決めないまま双方向同期を組むと、更新の衝突が日常的に発生します。前述したMicrosoftの設計例のように、エンティティ全体ではなく項目単位で所有者を割り振るのが実際的です。取引先コードと与信はERP側、商談の進捗はCRM側と決め、所有者でない側は参照専用にします。受注確定のタイミングだけをCRMからERPへ流す一方向の設計にすれば、衝突は構造的に起きなくなります。 ### BIツールとの連携 BI連携は読み取り専用のため書き込みの衝突は起きませんが、集計クエリが本番のERPに直接当たると業務側の応答が落ちます。Business Centralの場合、GET要求にData-Access-Intent: ReadOnlyヘッダーを指定するとデータベースのレプリカに対して実行させることができ、公式の性能ガイドでも推奨されています。ただし同じページには、この指定がセカンダリレプリカでの実行を保証するものではないという注記が併記されています。 件数についても、1ページの上限が20,000件であってこれが取得可能な総件数の上限ではありません。それを超えるデータはサーバー駆動ページングで継続リンクをたどって取得します。したがって万単位というだけでAPI連携を外す判断にはなりません。読み取り専用の指定とページングで必要な応答速度を満たせない場合、または本番処理との分離を確実にしたい場合に、締め処理の完了後のスナップショットを分析基盤へ複製し、BIはその複製を参照する構成へ切り替えます。 ### EC・倉庫・人事など実務系との連携 受注、出荷、勤怠は発生頻度が高く、遅延の許容度もそれぞれ違います。公式の指針も、件数と即時性で方式を分けるよう求めています。Dynamics 365 Supply Chain Managementの契約ライフサイクル管理との連携ガイドラインは、非同期でバッチ処理に対応するData management package REST APIと、同期でバッチに対応しないODataを対比し、大量のマスタデータには前者、即時同期とエラー処理が要る場合には後者を推奨しました。ただし後者の条件として、ピーク時のデータ量が過大でないことも併記されています。 出荷指示のように分単位の鮮度が要る処理と、日次で足りる勤怠を同じ実行間隔にする必要はありません。Business Centralは変更発生時に通知を受け取るwebhookの利用を推奨しており、購読数の上限は200件です。ポーリング間隔を詰めて上限に当たる前に、通知を受けて動く形に寄せられないかを先に検討します。連携の本数が増えるほど改修コストが積み上がる点は[連携本数と改修頻度で決まる費用構造](/column/details/16930/)で整理しています。 ## 連携方式4類型と、選定を分ける条件 方式はAPI連携、ファイル連携、データベース直結、連携基盤の4類型に整理できます。それぞれの適性は次のとおりです。 - API連携：件数が少なく鮮度が要る処理。上限に当たりやすい - ファイル連携：日次の大量件数。鮮度は落ちるが上限の影響を受けにくい - データベース直結：主にオンプレミスERPで検討する方式。クラウドERPでは接続可否を製品ごとに確認する - 連携基盤：複数の接続で変換、監視、再送を共通化し、個別実装より運用負荷を下げられる場合 分岐を決めるのは、1回に流す件数と許容できる遅延の2軸です。件数が数十件で分単位の鮮度が要るならAPI連携、件数が万単位で日次処理が許されるならファイル連携が候補になります。どちらが安く済むかは件数だけでは決まらないため、API利用料、開発費、監視と再送を含む運用費を並べて比較してください。方式ごとの詳細な判定条件は[連携方式5種の選定表と分岐条件](/tech/details/16495/)に、基盤製品としての料金の数え方は[iPaaSの仕組みと料金の数え方](/column/details/13373/)にまとめています。 ## ERP側のAPI上限による連携方式の制約 方式の一般論より先に見るべきは、繋ぐERPが公開している上限値です。主要製品の公式ドキュメントに記載された数値を並べると、設計で取れる選択肢がかなり絞られることが分かります。 | 製品 | 項目 | 上限 | 超過時の応答 | | --------------- | ----------------------- | --------- | --------------------------- | | Dynamics 365 BC | OData 速度（利用者単位） | 6,000件/5分 | 429 | | Dynamics 365 BC | OData 同時処理（利用者単位） | 5件 | 空きが出るまでキュー待機。8分でタイムアウトなら503 | | Dynamics 365 BC | OData 接続数 | 100件 | 429 | | Dynamics 365 BC | OData キュー長 | 95件 | 429 | | Dynamics 365 BC | バッチ要求の操作数 | 100件 | 記載なし | | Dynamics 365 BC | 1ページのエンティティ数 | 20,000件 | 413 | | Dynamics 365 BC | OData operation timeout | 8分 | 408 | | Dynamics 365 BC | API要求の実行時間 | 10分 | 504 | | freee会計 | 証憑アップロード（事業所単位） | 300件/分 | 400 | Dynamics 365 Business Centralの数値は、Microsoft Learnの運用上限ページ（2025年4月8日付）に記載されたものです。速度上限はもともと環境単位で本番600件毎分、サンドボックス300件毎分でしたが、スループットを上げるため利用者単位へ移行し、現在は5分間のスライディングウィンドウで6,000件と定義されています。同ページは、単一の利用者やサービスプリンシパルに処理を集めるとこの上限に早く到達するため、複数の利用者へ処理を分散させる方法を推奨しています。連携用のアカウントを1つだけ作る設計は、この推奨と正面から衝突します。 実行時間の上限も見落とされがちです。OData要求のoperation timeoutは8分で、超えると408が返ります。加えてAPI要求全体の実行時間は10分に制限されており、応答できない場合はサービスが要求を中断して504を返すとMicrosoftは明記しています。夜間バッチで全件を1回の要求にまとめる設計は、件数が増えた時点でここに当たります。同ページはSOAPについて、将来的にスループットを下げて非推奨にする方針も明記しているため、新規の連携でSOAPを選ぶ理由はほぼありません。 Oracle NetSuiteは、アカウントに割り当てられた同時実行の枠を連携ごとに配分する方式を採っています。ヘルプには、未割り当ての同時実行枠の最小値は1であること、個別連携に設定できる上限値は常にアカウントの未割り当て合計より1小さいことが記載されています。注意すべきなのは、サービスティアの契約やSuiteCloud Plusライセンスが失効するとアカウントの同時実行上限が既定値に戻る、という記述です。契約更新の漏れが連携の詰まりとして現れるため、上限値はライセンス管理と合わせて監視する必要があります。 ## ERP連携が壊れる3つの条件 ここからは、一般的な注意点ではなく、実装したコードが実際に落ちる条件を挙げます。いずれも公式ドキュメントに書かれていながら、設計時に飛ばされやすい箇所です。 ### 429以外で返るレート超過応答 freeeは2025年3月21日に、freee会計のファイルボックス（証憑ファイル）アップロードAPIの上限を600リクエスト毎分から300リクエスト毎分へ変更すると告知し、2025年5月19日に実施しました。変更種別はBreaking Changeとされています。ここで重要なのは上限値の変化ではなく、超過時の応答が変更の前後ともステータスコード400である点です。エラーメッセージは、1分間にアップロードできるファイル数の上限を超えた旨を返します。429を検知してリトライする実装は、この400を業務エラーと誤認して再送せず、証憑が欠けたまま処理を完了させます。リトライ判定はステータスコードだけでなく、応答本文のメッセージまで見て分岐させるべきです。 ### 利用者単位とテナント単位のAPI上限差 freeeの同じ告知には、上限が事業所単位で設けられているため、直列実行の場合でも複数の利用者が同時にアップロードすると制限を超える可能性があると明記されています。API処理時間は1秒程度で、直列なら超えにくいという説明も併記されています。つまり、自社の連携処理が単独で走る前提の負荷試験では足りません。同じ事業所に紐づく別の連携や別部門の処理が同時に動く可能性を含めて見積もる必要があります。Dynamics 365 Business Centralが利用者単位で数え、freeeが事業所単位で数えるように、同じレート制限という言葉でも数える単位は製品ごとに違います。上限値を書き写す前に、その単位を必ず確認してください。 ### 部分成功後の一括再送による二重計上 freeeの告知は、並列実行で上限に達した場合でも、制限にかかる前にアップロードされた証憑は既に登録済みであるため再アップロードは不要である、と説明しています。これは失敗した処理が全体としてロールバックされないことを意味します。エラーを受け取った側が処理単位でまとめて再送すると、成功済みの分が重複します。 一方、バッチ要求の扱いは製品によって作り込まれています。Business Centralは2020 release wave 2（バージョン17.1）以降、$batch要求にIsolation: snapshotヘッダーを付けると、呼び出されたALコードがCOMMITしない限りバッチ全体が同一トランザクションで動き、途中の失敗で成功分も取り消されます。逆に言えば、このヘッダーを付けない場合や途中でCOMMITされる場合は取り消されません。送信側で一意キーを持たせ、受信済みかどうかを問い合わせてから再送する冪等な設計にするか、それが難しければ再送を自動化せず手動確認に倒すのが安全です。 これらを踏まえると、ERP連携でリアルタイムの双方向同期を選ぶべき場面はかなり限られます。双方向は更新の衝突と再送の重複という2つの問題を同時に抱え込むためです。採用するなら、双方のピーク時の要求数と1件あたりの処理時間を実測し、同時処理5件、キュー95件、5分間6,000件といった上限の範囲に収まるかを確認してください。収まらなければ、鮮度が本当に分単位で必要な業務だけをAPIの一方向連携に切り出し、残りは日次のファイル連携へ寄せます。連携が原因で止まった実例は[ERP導入の失敗事例と原因](/column/details/10900/)にまとめています。 ## ERP連携の進め方 設計の順序を、上限値を先に確認する形に組み替えます。 1. 連携するERPと相手システムの公式ドキュメントから、レート上限、同時処理数、1ページの件数上限、タイムアウト、上限の単位（利用者かテナントか）を書き出す 2. 業務ごとに許容できる遅延を決める。分単位が必要な業務だけを抽出する 3. 1回あたりの想定件数と処理時間を見積もり、上限の範囲に収まるかを計算する。収まらない業務はページングかファイル連携へ回す 4. 所有者をデータ項目ごとに決め、所有者でない側は参照専用にする 5. 再送時の重複を防ぐ一意キーと、部分成功時の突き合わせ手順を設計する 6. 本番相当の件数と、他の連携や部門の操作が重なる時間帯を含めて負荷を確認する 1と3を飛ばすと、実装が終わってから方式ごと作り直すことになります。上限値の確認は数時間で済むため、要件定義の段階で必ず入れてください。相手がSaaSの場合はAPI制限の設計がそのまま実装方針を決めるため、[kintone連携における4方式の判定とAPI制限の設計](/tech/details/17178/)のような製品別の整理も参考になります。 ## よくある質問 ### ERP連携とは何ですか？ ERPと会計、販売、人事などの周辺システムを接続し、マスタやトランザクション、業務イベントを共有する仕組みです。正本をERPに固定するのではなく、顧客名や与信限度額といったデータ項目ごとに所有者を決めます。一度実行して完了するデータ移行と違い毎日動き続けるため、失敗時の再実行と二重計上の防止が設計の中心になります。 ### ERP連携の方法にはどんな種類がありますか？ API連携、ファイル連携、データベース直結、連携基盤の4類型です。選定を分けるのは1回に流す件数と許容できる遅延で、万単位かつ日次で足りるならファイル連携、数十件で分単位の鮮度が要るならAPI連携が候補になります。データベース直結は主にオンプレミスERPで検討する方式で、クラウドERPでは接続の可否を製品ごとに確認します。 ### 基幹システムの連携とERP連携は何が違いますか？ 対象範囲の違いです。基幹システムの連携は個別に構築された業務システム同士を繋ぐ場合を含みますが、ERP連携はデータが1か所に統合されたERPが接続の中心にある点が前提になります。ただしERP連携でも、どのデータをどのシステムが所有するかを決める作業は必要です。Microsoftの設計例のように、CRMが顧客名と連絡先、ERPが与信限度額と支払条件を持つといった項目単位の分担になります。 ### ERPとBIツールは連携できますか？ 可能ですが、BIから本番のERPへ集計クエリを直接投げる構成は避けます。業務側の応答を圧迫するためです。Business Centralの場合、GET要求にData-Access-Intent: ReadOnlyを指定するとレプリカでの実行を指示でき、1ページの上限20,000件を超えるデータはサーバー駆動ページングで取得します。これらで必要な速度を満たせない場合や本番処理との分離を確実にしたい場合に、締め後のスナップショットを分析基盤へ複製する構成へ切り替えます。 ### ERPとCRMを双方向で同期しても問題ありませんか？ 更新の衝突と再送の重複を同時に抱えるため、まず一方向で組めないかを検討します。取引先コードと与信はERP、商談の進捗はCRMというように所有者を項目単位で決め、受注確定など必要な瞬間だけを一方向で流す設計です。双方向にする場合は、ピーク時の要求数と処理時間を実測し、同時処理5件やキュー95件といった上限に収まることを確認してから決めてください。 ## 関連記事 - [iPaaSとETLの違いを実装視点で判定｜連携方式5種の選定表と分岐条件](/tech/details/16495/) - [ERPとは何か？企業の経営を支える統合基幹業務システムの意味と基本機能を初心者にもわかりやすく徹底解説](/column/details/12806/) - [iPaaSとは？仕組み・RPAとの違い・料金の数え方と導入判断をわかりやすく解説](/column/details/13373/) - [ERPの会計機能とは？財務会計・管理会計と部門別採算の作り方](/column/details/10910/) - [ERP導入の失敗事例と原因｜判例・開示資料で確認できる4件と回避策](/column/details/10900/) --- 出典: [ERP連携とは？連携先別の設計とAPI上限から決める方式選定・失敗条件]()（株式会社一創）