結論：正常に登録できるだけでは、ERP連携の受入は完了しない
ERP連携の受入テストでは、正常な注文が登録されることに加えて、同じ依頼の再送、確定後の応答喪失、訂正、取消、権限、切戻しを確認します。画面でエラーが出なかったというだけでは、取引が正しく一度だけ処理されたかは分かりません。
本稿では、受注データを周辺システムからERPへ渡すケースを想定したテスト設計を提案します。特定ERPで検証済みの仕様ではありません。API、CSV、利用権限、ライセンス、テスト環境の可否は、対象製品の仕様と契約で確認してください。
テスト前に決める5つの前提
基幹・ERP連携の設計ページでは、データの正、連携方式、再送、削除、権限の扱いを整理しています。受入テストは、この設計の合意事項を入力・期待結果・証跡に落とす作業です。[1]
| 前提 | 決めておくこと | 未決定のまま試験すると起きること |
|---|---|---|
| データの正 | 品番、取引先、受注、単価をどちらが管理するか | 双方が違う値でも合否を決められない |
| 登録の単位 | 注文単位か明細単位か、部分成功を許容するか | 一部失敗のときの件数を判定できない |
| 一意な識別子 | 送信元、注文ID、版、処理種別をどう区別するか | 再送と訂正を混同する |
| 確定のタイミング | 承認後か、下書き段階でも連携するか | 未承認の情報が本取引へ混ざる |
| 障害時の責任 | 停止、再送、取消、利用者連絡を誰が行うか | 復旧操作が担当者ごとに異なる |
「登録後の正しい状態」を先に書きます。受信側のIDが1件あるだけでなく、金額、数量、承認状態、関連する監査記録まで確認対象を定めてください。
正常系は、基準となる1ケースを固定する
テスト専用の取引先と品番を使い、業務上安全な検証環境に限定します。実在の顧客取引を試験用に作成しないでください。
以下は説明用の架空データです。
{
"source_system": "test_order_front",
"order_id": "TEST-ORDER-001",
"revision": 1,
"operation": "create",
"approval_status": "approved",
"lines": [
{"item_code": "TEST-PART-A", "quantity": 10, "unit": "pcs"}
]
}
ここに示したキー名を、実際のERPのAPI仕様だと扱わないでください。送信データの保存版、処理日時、受信側の登録ID、件数、数量の対応を、採用した連携方式に合わせて記録します。
再送と訂正は、違うケースとして試す
同じ依頼を再送する
同じ注文ID・同じ版・同じ処理を再送し、最終的な業務取引が二重に作られないことを確認します。再試行のたびに新しい業務キーを発行する設計では、再送が新規取引と区別できなくなります。
通信要求を識別するIDと、業務取引を識別するIDも分けます。同じ業務取引を確認するための複数回の通信を、すべて新規の取引と扱わないためです。
登録は完了したが、応答が届かなかった
受信側で登録が完了した直後に、送信側が結果を受け取れない状態を検証します。ここで単純に再送すると、二重登録になる実装もあり得ます。再送の結果だけでなく、受信側の最終状態を照会して、合意した件数と一致するか確認します。
試験のための通信遮断や障害注入は、許可されたテスト環境だけで実施してください。本番で故意に障害を発生させる手順ではありません。
注文の数量を訂正する
同じ注文の第2版を送り、第1版の再送と区別できることを確認します。古い版が遅れて届いた場合に、最新の注文を古い数量へ戻さないことも、合意する仕様の一つです。
訂正を更新APIで扱うか、訂正伝票で扱うかはERPによって異なります。記事のサンプルを根拠に、登録済みデータを直接上書きしないでください。
最低限用意する受入テスト票
次は設計例です。合否欄は、実環境で確認するまで未実施とします。
| ID | ケース | 期待する業務上の結果 | 残す証跡 |
|---|---|---|---|
| ERP-01 | 正常な承認済み注文 | 合意した単位で一度だけ登録される | 送信版・受信ID・数量 |
| ERP-02 | 同じ注文・同じ版を再送 | 二重取引にならない | 再送ID・最終件数 |
| ERP-03 | 登録確定後の応答喪失 | 再確認・再試行後も取引が重複しない | 障害の時点・受信側の確定記録 |
| ERP-04 | 第2版で数量訂正 | 最新版の仕様どおりに反映される | 新旧版・訂正の監査記録 |
| ERP-05 | 第2版の後に第1版が到着 | 古い版へ無条件に戻らない | 到着順・採用版 |
| ERP-06 | 1明細だけ品番が不正 | 全体中止か部分成功か、合意した方針に従う | 成功・失敗明細と再処理対象 |
| ERP-07 | 未承認の注文 | 合意していない確定処理へ進まない | 承認状態・拒否理由 |
| ERP-08 | 権限のない利用者 | 対象外の取引の閲覧・登録・訂正ができない | 権限・操作種別・結果 |
| ERP-09 | 単価の適用日が境界にある | 対象日のルールが適用される | 単価版・適用日時 |
| ERP-10 | 登録後の取消 | 合意した取消または訂正処理が残る | 元取引・取消ID・理由 |
| ERP-11 | 連携の停止・再開 | 未処理範囲が特定でき、重複なく再開できる | 停止時点・処理済み範囲 |
| ERP-12 | 切戻し | 登録済み取引と未処理データの整合が説明できる | 手順・件数照合・責任者確認 |
CSV連携では、ファイル単位と行単位を分ける
CSVの場合も、ファイルが正常に読み込めたことだけでは判定しません。文字コード、列の意味、空欄、日付、数量の桁区切り、単位を明確にします。同じファイル名で中身を変更できる運用なら、ファイル名だけで重複を判断しない設計が必要です。
部分成功を認める場合は、どの行が成功し、どの行を再送するかを結果ファイルや画面で特定できるようにします。全体を中止する設計なら、途中まで登録された取引が残らないことを確認します。どちらが常に正しいという話ではなく、業務上の合意に一致していることが合格条件です。
「システムの切戻し」と「取引の訂正」を混ぜない
連携プログラムを前の版に戻しても、その間にERPへ登録した取引が自動で元に戻るわけではありません。切戻し手順には、プログラムの版だけでなく、処理済み・未処理の境界、登録済み取引の扱い、再開時に使用する版を記載します。
業務上取り消せない処理がすでに発生している場合、機械的な削除ではなく、訂正・取消・追加処理が必要になることがあります。対象ERPと現場の責任者が、実際に可能な手順を合意してください。
復旧目標の時間や許容する未処理件数も、記事の一律数値では決めません。出荷・請求・製造指示の締め時刻に合わせ、対象業務ごとに決めます。
合格判定は、担当者の感想ではなく証跡で行う
受入テストの基本を確認したうえで、テスト票の各行に入力データ、期待結果、実際の結果、証跡、担当者、実施日、使用したシステムの版を残します。[2]
不合格が見つかった場合は、修正したケースだけでなく、正常登録・再送・訂正など、変更の影響を受けるケースを再実施します。合格条件の変更で不合格を消した場合は、変更前の条件と理由も残します。
受入の前段で、開発側が外部連携の状態遷移や再送を結合テストとして自動で確認しておくと、受入では業務上の合否の判断に集中できます。外部連携の結合テストを自動化する考え方は、外部連携の統合テストをCI/CDに載せる方法（ステートフルモックとシナリオ駆動）で紹介しています。
全ケースが合格しても、試していないデータ量や製品設定まで検証済みとはしません。稼働開始後の監視項目と、停止・再開の判断者を決めた状態で受入を終えます。
相談時には、今の仕組みと困っている処理から整理する
ERPの製品名と版、利用できるAPIやCSV、対象データ、登録・訂正の頻度、現在の二重入力や復旧方法が分かると、最初の確認範囲を絞れます。仕様が分からない箇所は、分からないまま項目として残してください。見積や受注の入力をAIで自動化してからERPへ渡す計画であれば、自動化部分の評価は製造業のAI見積PoCの評価方法で分けて確認できます。
基幹・ERP連携の支援内容を確認するでは、方式の比較や相談時の確認事項を案内しています。認証情報、実際の顧客取引、APIキーは相談フォームへ記載しないでください。必要な資料の共有方法は、取り扱い条件を確認してから決めます。
参照情報と適用範囲
[1] シンシア：製造業の基幹・ERP連携（2026年10月29日確認）。データの正、連携方式、同期失敗・再送・重複の扱い、切替・並行稼働の設計上の区分を参照しています。
[2] シンシア：受入テスト（UAT）の進め方（2026年10月29日確認）。受入テストと検収の関係、テストケースの分担、範囲の決め方を参照しています。
本稿のテスト票とデータは独自の設計例です。特定製品の対応保証、実施済み試験、製造業全体の標準規格を示すものではありません。
この記事の作成にはAIによる下書き支援を使用し、編集部が内容確認・加筆・事実確認を行っています。参照した公開ページの記述は、2026年10月29日に照合しました。
