製造業 API連携 開発｜ERP・MES・WMSのRFPと受入設計

製造業 API連携 開発で本当に発注すべきものは、エンドポイントの本数ではありません。ERP・MES・WMS・QMS・ラベル／出荷系の間で、同じ要求が再送されても二重計上せず、障害後に復旧でき、結果を監査できる「業務取引の契約」です。本稿では、タイ工場の経営、製造、IT、調達、導入責任者がRFPから90日PoC、FAT/SAT、運用引継ぎまで使える実務仕様を整理します。

「APIがある」と「生産を止めずに運用できる」は別問題

ベンダー比較で「標準APIあり」と回答があっても、それだけでは運用可能性を判断できません。接続してHTTP 200や202を受け取ることと、在庫移動、製造実績、検査判定、出荷確定が相手システムに正しく記帳されたことは別です。受信した後の内部処理が失敗する場合、部分的にだけ成功する場合、応答が通信途中で失われる場合があります。

製造現場で問題になるのは、正常系よりも境界です。たとえばMESが製造完了をERPへ送信し、ERPへの登録は成功したが応答だけがタイムアウトしたとします。MESが同じ要求を再送したとき、ERPが二重の完成実績を作れば在庫、原価、ロット履歴がずれます。再送しなければ、MESとERPの正本が食い違います。必要なのは「再送するか」という一般論ではなく、同じ業務取引をどう識別し、重複時に何を返し、最終状態をどう照合するかという契約です。

IETF RFC 9110はHTTPの意味論として、PUT、DELETE、安全なメソッドの冪等性と、非冪等要求をクライアントが自動再試行する際の注意を示しています。しかしHTTPメソッドの意味論は、工場の業務取引全体が冪等である保証ではありません。製造完了POST、払出、出荷確定など状態を変える取引には、安定した業務キー、重複排除、結果参照、照合まで含むAPI冪等性が必要です。

先に合意する七つの成果物

RFPでは少なくとも次を納品物として指定します。

1. 取引一覧とsource of truth（正本）マトリクス
2. スキーマ、コード、単位、時刻、精度を含むデータ契約
3. 業務キーと冪等性・重複排除の規則
4. タイムアウト、有限再試行、例外キュー、手動再実行の規則
5. 相関ID、ログ、ダッシュボード、日次照合の設計
6. バージョン、互換期間、廃止通知、ロールバックの方針
7. 正常系と障害注入を含むAPI受入試験の証跡

これらがない見積は、開発費が安く見えても、障害後の調査、二重計上の修正、属人的な再実行を運用費へ移しただけです。逆に、全システムを刷新しなくても、取引ごとの境界を明文化すれば段階導入できます。業務システム開発とERP連携の全体像を先に整理し、本稿の取引契約を個別インターフェースへ適用すると、企画と実装をつなげやすくなります。

ERP・MES・WMS・QMSの正本と取引所有者を決める

REST、イベント、ファイルの選択より先に「どの業務事実を、誰が、いつ完成と判定するか」を決めます。正本は単に最初にデータを作ったシステムではありません。変更権限、確定条件、訂正方法、監査責任を持つシステムです。

この表は企業ごとに置き換えます。重要なのは、矢印の両端で「成功」の意味を共有することです。通信受領、構文検証、業務検証、記帳、後続処理完了を一つの成功コードに押し込めないようにします。

transport successとbusiness acceptanceを分ける

応答には少なくとも二つの状態が必要です。

• transport success：要求をAPI基盤が受け付け、形式を検査できた
• business acceptance：対象の在庫、指図、実績、判定が業務ルールを通り、正本へ記帳された

非同期処理なら、受付時に相関IDまたは処理IDを返し、送信側が最終状態を照会できるようにします。失敗理由も「エラー」だけでなく、再試行可能、データ修正が必要、マスタ不足、承認待ち、既に処理済みなど、次の行動に結び付く分類にします。

所有者不在をRACIで消す

各取引には、業務所有者、送信側技術所有者、受信側技術所有者、データ所有者、障害時の承認者を割り当てます。APIゲートウェイ担当だけを所有者にしてはいけません。ゲートウェイは通信を観測できますが、製造完了や品質判定が正しいかは判断できないからです。担当者が異動した場合にも運用できるよう、役職と当番で定義し、連絡先はランブックで更新します。

データ契約はJSON例ではなく意味の契約にする

API仕様書にサンプルJSONが一つあるだけでは、実データの揺れを吸収できません。Microsoft Azure Architecture CenterのAPI設計ガイダンスが述べるように、APIは内部データベースの表をそのまま公開するのではなく、業務ドメインを表現するべきです。これはAzure購入の要件ではなく、製品に依存しない設計の参考として使えます。

データ契約には次を明記します。

タイのデータ相互運用性という文脈では、ETDA Recommendation 27-2564が、電子メッセージを一貫して設計するためのコアコンポーネント、業務情報エンティティ、データ型を扱っています。共有データ定義を考える参考になりますが、個別工場APIに対する強制認証制度として扱ってはいけません。

コードと単位の責任を曖昧にしない

「EA」と「PCS」、「KG」と「kg」、現地時刻とUTC、工程実績日と会計日が混在すると、接続は成功しても業務結果がずれます。送信側が変換するのか、受信側が変換するのか、共通サービスを使うのかを一意にします。未知コードを自動で仮登録すると後日追跡が難しくなるため、例外キューへ保留するか、承認済みの変換表だけを使います。

スキーマ検証は境界で行う

NIST SP 800-228 Update 1は、クラウドネイティブシステムのAPI保護について、実行前と実行時のライフサイクルにわたり、インベントリ、スキーマ検証、認証・認可、監視、スロットリングなどをリスクに応じて組み合わせる考え方を示しています。製造業規制ではありませんが、設計、配備、運用を分断しないチェックリストとして有用です。無効な入力は業務システムの深部へ届く前に拒否し、拒否理由と相関IDを残します。

API冪等性：同じ要求を安全に再送できる契約

冪等性は「重複を無視する」だけではありません。同じ意図の要求を再送したとき、追加の副作用を起こさず、呼出側が元の結果を取得できる性質です。AWS Builders’ Libraryは、一時障害に対する再試行を安全にする設計として、クライアント要求識別子などを説明しています。AWSの採用が必須という意味ではなく、遅れて到着する要求や同一意図の判定を考える材料です。

業務キーを通信IDから分離する

相関IDは追跡に、業務冪等キーは重複排除に使います。再送のたびに変わる通信IDだけでは、同じ製造完了を判定できません。たとえば「工場＋指図＋作業＋完了連番」のように、業務上同一なら変わらないキーを送信側で生成し、受信側が保存します。

受信側は同じキーを受けたとき、次のいずれかを契約します。

• 内容も同じ：初回と同じ結果IDと状態を返す
• キーは同じで内容が違う：競合として拒否し、上書きしない
• 初回が処理中：処理中を返し、結果照会を案内する
• 初回結果が期限切れ：保持期間と照合手順に従う

この規則がなければ、ネットワークタイムアウトのたびに担当者が「もう一度押してよいか」を判断することになります。

有限再試行、backoff、jitter

一時的なタイムアウト、スロットリング、依存先の短時間停止だけを再試行対象にします。認証失敗、スキーマ違反、未知マスタ、業務競合は同じデータで繰り返しても直りません。最大試行回数、総時間、待機増加、ランダムなjitter、打切り後の行先を定義します。AWS Architecture BlogのExponential Backoff and Jitterは集中再試行を避ける方法の参考になりますが、無限再試行を推奨するものではありません。冪等性と有限回数を必ず組み合わせます。

遅延・順序逆転・部分成功を試す

製造実績より前に取消が届く、在庫移動の明細の一部だけが受理される、ラベル印刷は成功したが出荷確認が失敗する、といった状況を設計段階で決めます。順序番号だけに依存せず、前提状態を検証し、未到着の先行取引を待つか、拒否するか、保留するかを契約します。部分成功が許されない取引は原子的に扱い、許される場合は明細ごとの結果と再送単位を返します。

例外キュー、手動再実行、相関ID、照合

再試行の上限を超えた要求を捨てたり、担当者のメールにコピーしたりしてはいけません。例外キューには、業務キー、相関ID、送信元、対象取引、発生時刻、直近エラー、試行履歴、現在の所有者、次の行動、証跡へのリンクを保持します。秘密情報や個人データはマスクし、生の要求・応答はアクセス制御された保管先へ置きます。

手動replay権限を職務分離する

再実行は便利ですが、二重計上を起こし得る変更操作です。閲覧、データ修正、再実行承認、実行を分けます。誰がどの根拠でデータを直し、どの結果を確認したかを記録します。高影響取引では二者承認を採用する余地がありますが、必要な承認段階は自社のリスクで決めます。

手動再実行の前には、相手システムを業務キーで照会します。「応答がない＝未処理」と推定してはいけません。すでに処理済みなら元の結果を回収し、未処理なら同じ冪等キーで再実行します。

相関IDを全区間で保持する

ERP、APIゲートウェイ、MES/WMS/QMS、監視、例外キューで同じ相関IDを検索できるようにします。ただし相関IDだけで業務同一性を判定しません。ダッシュボードでは件数、成功、処理中、業務拒否、技術失敗、キュー滞留を取引別に表示します。平均だけでなく、長時間滞留や特定マスタに偏る例外を見ます。

日次照合は最後の安全網

メッセージ監視が緑でも、業務レコードはずれることがあります。日次または業務に適した周期で、正本の指図・実績・在庫移動・検査判定・出荷と、相手側の記帳を業務キーで照合します。件数だけでなく数量、ロット、状態、改訂を確認し、差分を例外キューへ戻します。照合の所有者、完了期限、未解決時のエスカレーションをランブックに含めます。

APIゲートウェイとセキュリティ統制、その限界

APIゲートウェイは、ルーティング、認証、mTLS終端、レート制限、ログ、監視を集約できます。Microsoft Azure Architecture Centerのゲートウェイ解説は、こうした役割を理解する参考になります。Azureに限定される考え方ではありません。

一方、ゲートウェイだけでは次を解決できません。

• 製造完了が業務上同じ取引か
• 在庫の正本がERPかWMSか
• 品質判定の変更を誰が承認するか
• HTTP成功後に業務記帳が完了したか
• 二重出荷をどう訂正するか
• 日次照合の差分を誰が解消するか

つまり、ゲートウェイは交通整理と境界防御には有効でも、業務所有権と照合の代わりにはなりません。

セキュリティRFPの最小項目

NISTのライフサイクル観点とOWASP API Security Top 10 — 2023を、認可、資源消費、インベントリ、外部API利用などの確認に使えます。OWASPは専門家コンセンサスに基づく認識用チェックリストであり、個別工場のリスク量を数値化するものではありません。

• APIと利用者、所有者、環境、版のインベントリ
• オブジェクト単位・機能単位の認可
• サービス間認証、短命な資格情報、秘密の保管と更新
• スキーマと入力サイズの検証
• レート、同時実行、ペイロード、照会範囲の制限
• 外部API応答を未信頼入力として扱う検証
• ログの改ざん防止、マスキング、保持、アクセス制御
• 脆弱性対応、変更承認、緊急遮断、復旧手順

記事例や図へパスワードやAPI秘密情報を入れません。試験用資格情報も本番と分離し、ログ、画面キャプチャ、エクスポートファイルへ残らないことを確認します。

バージョン、互換期間、consumer inventory、rollback

製造業のAPIは、送信側と受信側を同時停止して一斉更新できないことがあります。そのため「最新版へ更新する」だけでなく、旧版をいつまで受けるか、どの利用者が残っているか、問題時にどこへ戻すかを契約します。

変更を三種類に分ける

1. 互換変更：任意項目の追加など、既存利用者を壊さない変更
2. 条件付き互換変更：コード追加、桁数変更など、利用者の実装次第で影響する変更
3. 非互換変更：必須項目、意味、単位、キー、処理順の変更

「項目追加だから互換」と決めつけず、厳格なデシリアライザ、画面、帳票、下流ファイルへの影響を回帰試験します。consumer inventoryにはAPI名、版、工場、システム、所有者、利用取引、最終通信、移行予定を持たせます。

廃止通知とrollback

RFPに、通知方法、互換期間、移行環境、テストデータ、停止判定、延長承認を記載します。ロールバックはアプリ版を戻すだけでは不十分です。新しい版で書き込んだデータを旧版が読めるか、重複排除台帳やキューを引き継げるかを検証します。切替前後の業務キー範囲を記録し、同じ取引が両版から処理されないようにします。

API連携 RFP：ベンダー比較を成果物と証拠で行う

システム開発契約の実務ポイントと組み合わせ、契約一般に加えてAPI固有の完了条件を別紙へ落とします。提案書の製品機能だけでなく、誰が何を作り、どの証拠で受け入れるかを比較します。

RFP要求事項の例

見積の比較条件を揃える

「API開発一式」では比較できません。インターフェースごとに、設計、実装、ゲートウェイ、テストハーネス、テストデータ、監視、運用手順、教育、保証範囲を分けます。ライセンス、クラウド、通信、証明書、監視、オンコール、回帰試験の継続費も分離します。

提案ベンダーには、重複、タイムアウト、順序逆転、部分成功、スキーマ変化、トークン期限切れ、レート制限、依存先停止、切替rollbackをどう再現するか説明させます。「対応可能」ではなく、試験手順、期待結果、取得ログ、責任者を回答させます。製造業システムインテグレーター選定の評価軸を併用すると、技術力だけでなく現場引継ぎまで比較できます。

API受入試験：FAT・SAT・90日PoCで障害時を証明する

API受入試験は、正常な一件が通るデモではありません。同じテストを再現でき、期待した業務状態、ログ、アラート、キュー、照合結果が残ることを確認します。FATは統制された環境で契約と障害挙動を検証し、SATは本番に近いネットワーク、認証、マスタ、運用体制でサイト固有の条件を確認します。

90日PoCの構成

PoCは機能を広げる競争ではありません。代表取引で、失敗を安全に検知、保留、復旧、照合できることを先に証明します。

正常系と障害注入のチェックリスト

• 正常要求が一度だけ記帳される
• 同じ業務キー・同じ内容の重複要求が副作用を増やさない
• 同じ業務キー・異なる内容が競合として拒否される
• 応答喪失後の再送で元の結果を取得できる
• 遅延メッセージと順序逆転を保留または規則どおり処理する
• 部分成功時に明細結果と再送単位が分かる
• スキーマdriftと未知コードを隔離する
• token expiry時に秘密を漏らさず失敗する
• rate limiting時に有限再試行し、集中再送しない
• 依存先停止時にキュー、アラート、ダッシュボードが一致する
• 手動replayが承認され、操作履歴が残る
• 切替失敗時にrollbackし、二重処理しない
• 送信元レコードから受信先記帳まで相関IDと業務キーで追跡できる
• 日次照合が意図的な差分を検出する

テスト証跡には、試験ケース、前提データ、実行時刻、入力、期待結果、実結果、ログ検索条件、画面または出力、欠陥ID、再試験結果、承認者を含めます。生の要求・応答を保管する場合も、秘密や個人データを除外します。監査用証跡は「大量にログを残す」ことではなく、特定の業務取引を端から端まで説明できることです。

5インターフェース・年500万メッセージの試算例

以下はTOMAS TECHが検討対話に使う説明用モデルであり、市場平均、見積、顧客実績、効果保証ではありません。実際のメッセージ数、例外ログ、人件費、事故費、インフラ見積へ必ず置き換えてください。

対象は五つです。ERP→MESの生産指図、MES→ERPの製造完了、ERP↔WMSの在庫移動、QMS→ERPの検査判定、ERP/WMS→ラベル・出荷確認を想定します。

メッセージと例外の仮定

• 1日20,000業務メッセージ
• 年250稼働日
• 年間5,000,000メッセージ
• 改善前の例外率仮定0.30%＝年15,000件
• データ契約、冪等性、有限再試行、照合後の例外率仮定0.05%＝年2,500件
• 1件の処理時間仮定8分
• 改善前120,000分＝年2,000時間
• 改善後20,000分＝年333.3時間
• 負担込み人件費仮定900 THB/時間
• 例外対応人件費は改善前1,800,000 THB/年、改善後300,000 THB/年
• 説明上の削減額は1,500,000 THB/年

初期費用と年間運用費の仮定

追加の回避損失もすべて仮定です。重複した製造／出荷訂正を年12件、1件60,000 THBとして720,000 THB/年。インターフェース停止を年10時間相当、1時間60,000 THBとして600,000 THB/年です。

説明用の年間総価値は1,500,000＋720,000＋600,000＝2,820,000 THBです。年間運用費420,000 THBを引くと、年間純価値は2,400,000 THB。単純回収期間は2,800,000÷2,400,000＝1.17年です。

効果の50%だけ実現する感度では、2,820,000×50%−420,000＝990,000 THB/年の純価値となり、単純回収期間は2,800,000÷990,000＝2.83年です。基準値だけで意思決定せず、控えめな感度を並べる理由は、例外減少と回避損失が現場データに強く依存するからです。

自社値へ置き換える順番

1. ゲートウェイや推測値ではなく、業務取引別の実メッセージを数える
2. 例外を技術失敗、データ不備、業務拒否、手作業補正に分類する
3. 実作業の時間と負担込み人件費を測る
4. 二重計上、停止、誤出荷の実際の訂正費を財務・製造と合意する
5. インフラ、ライセンス、開発、テスト、運用の正式見積を取る
6. 基準、保守、悪化ケースで感度を見る

データを複数システムから文脈化する全体構想は製造業データファブリックで扱っています。本稿の試算では、データ基盤全体ではなく、五つのAPI取引の失敗と回収に範囲を限定します。

よくある質問

ERP MES API連携はRESTとイベントのどちらを選ぶべきですか？

方式より業務取引から決めます。即時の照会・明確な要求応答が必要ならRESTが適する場合があり、疎結合や複数購読者にはイベントが適する場合があります。既存設備や一括連携ではファイルが現実的なこともあります。どの方式でも、正本、業務キー、順序、重複、結果照会、照合、所有者は必要です。製品の得意方式だけで決めないでください。

WMS API連携で最初に固定すべき項目は何ですか？

倉庫、ロケーション、品目、ロット、在庫状態、数量、単位、移動理由、伝票と明細のキーです。ERPとWMSのどちらが所在・引当・会計数量の正本かを状態別に分けます。部分受入、取消、棚卸差異、遅延到着の扱いも先に試験します。

API連携 RFPにはエンドポイント一覧だけで足りますか？

足りません。取引所有者、正本、完成条件、データ契約、冪等性、有限再試行、例外キュー、手動replay、相関ID、照合、版管理、rollback、FAT/SAT証跡を要求してください。件数と性能も平均だけでなく、ピーク、ペイロード、許容遅延、滞留回復を示します。

API受入試験で最重要のケースは何ですか？

正常系一件ではなく、「受信側では成功したが応答が失われた」ケースです。ここで同じ業務キーを再送し、二重計上せず元の結果を返せるかを見ると、API冪等性、ログ、結果照会、照合の設計をまとめて検証できます。加えて順序逆転、部分成功、スキーマdrift、token expiry、rate limiting、依存先停止、rollbackを試します。

API冪等性はPUTを使えば保証されますか？

保証されません。HTTP意味論上の冪等性と、製造完了、在庫払出、出荷確定という業務副作用の冪等性は分けて設計します。安定した業務キー、重複台帳、同一キーで内容が違う場合の拒否、元結果の再取得、保持期間、照合が必要です。

APIゲートウェイを入れれば例外運用も解決しますか？

いいえ。認証、ルーティング、制限、ログの共通化には有効ですが、製造・品質・物流の正本、データ修正、再実行承認、日次照合の責任は業務側と各システム所有者に残ります。ゲートウェイ導入と業務契約設計を別の作業として見積もります。

まとめ

製造業のAPI連携は、つながった瞬間ではなく、重複、遅延、部分成功、依存先停止、版変更が起きた後に価値が分かります。RFPでは、取引ごとの正本と所有者、意味を含むデータ契約、業務キーと冪等性、有限再試行、例外キューと手動再実行、相関IDと照合、互換期間とrollback、障害注入を含むFAT/SAT証跡を一つの受入条件にしてください。HTTP成功と業務受入を分け、現場が自力で復旧できるランブックまで渡って初めて「運用可能なAPI」です。

ERP・MES・WMS・QMSのどの取引からPoCを始めるか、既存仕様をRFPへどう直すかという検討段階でも、TOMAS TECHへご相談ください。実メッセージ、例外ログ、運用体制を確認し、90日PoCと受入証跡の範囲を一緒に整理できます。

参考資料

1. NIST, *SP 800-228 Update 1: Guidelines for API Protection for Cloud-Native Systems*

https://csrc.nist.gov/pubs/sp/800/228/upd1/final

1. IETF, *RFC 9110: HTTP Semantics*

https://datatracker.ietf.org/doc/html/rfc9110

1. AWS Builders’ Library, *Making retries safe with idempotent APIs*

https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/

1. AWS Architecture Blog, *Exponential Backoff and Jitter*

https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/

1. Microsoft Azure Architecture Center, *API design*

https://learn.microsoft.com/en-us/azure/architecture/microservices/design/api-design

1. Microsoft Azure Architecture Center, *Use API gateways in microservices*

https://learn.microsoft.com/en-us/azure/architecture/microservices/design/gateway

1. OWASP, *API Security Top 10 — 2023*

https://api-security.owasp.org/editions/2023/en/0x00-header/

1. Thailand ETDA, *Recommendation 27-2564: Core Component Specification for Data Interoperability*

https://www.etda.or.th/getattachment/017b9ba7-fb0e-4648-922d-cb1117eeec3b/%E0%B8%82%E0%B8%A1%E0%B8%98%E0%B8%AD-27-2564.aspx

1. Thailand BOI, *1H 2026 investment announcement*

https://www.boi.go.th/un/boi_event_detail?language=en&module=news&topic_id=139075

BOI発表では、2026年上期のSmart and Sustainable Industryに、機械更新、デジタル技術、自動化、ロボティクスを対象とする申請が132件、約172億THBとされています。これはタイ製造業の投資文脈を示す数字であり、API案件数でも、個別API開発が自動的に投資恩典の対象になるという意味でもありません。適用可能性は個別に確認してください。