IF仕様書が「通信方式の説明書」になっている問題
インターフェース仕様書のレビューを依頼されて開くと、REST APIかファイル連携か、項目のデータ型は何か、という方式と形式の記述がほとんどを占めていることがよくあります。それらは必要ですが、連携障害の原因分析をすると、方式起因のトラブルはむしろ少数派です。実際に障害になるのは「仕様書に書いていないこと」──失敗したら誰が気づくのか、再送したら二重登録にならないのか、相手が止まっている間のデータはどこに溜まるのか──です。
この構造には理由があります。方式と形式は開発者だけで書けますが、異常時の振る舞いは両側のシステムの業務運用を突き合わせないと決められないからです。つまりIF仕様書の本体は技術文書ではなく、システム間の責任分担の合意文書です。書く順序もそれに従うべきで、通信方式は最後に決めても間に合いますが、責任分担は設計の最初に決めなければ両側の実装が進みません。
方式より先に決める7項目
MES側・相手側の設計者と発注側の三者で、インターフェース1本ごとに次の7項目を確定します。これが決まっていれば、方式・形式の詳細は各設計者が埋められます。
| # | 項目 | 決めること | 決めないと起きること |
|---|---|---|---|
| 1 | 正となるシステム | そのデータの発生源と修正権限はどちらか | 両側で修正され、どちらが正しいか分からなくなる |
| 2 | 単位と粒度 | 何の単位で1件か（指図／ロット／個体／イベント） | 集計してから送るか明細で送るかで実装が食い違う |
| 3 | タイミングと頻度 | 即時か、周期か、イベント駆動か。ピーク時の件数 | 夜間バッチ前提の実装に即時要件が後から乗る |
| 4 | キーと突合方法 | 両システムを結ぶキー項目。桁・体系・採番の主 | 突合不能データが月次で溜まり、手作業の照合が常態化 |
| 5 | 異常時の振る舞い | 失敗の検知方法、再送ルール、責任者への通知先 | 失敗が数日間誰にも気づかれない |
| 6 | 相手停止時の運用 | 溜める場所、溜められる時間、復旧後の流し方 | 復旧時に大量データが一気に流れ、二次障害を起こす |
| 7 | 変更時の手続き | 項目追加時の影響範囲確認と両側のリリース調整 | 片側の「軽微な変更」が相手側を黙って壊す |
このうち1・2・4はMES-ERP連携の設計で述べた粒度・キーの議論と同じものです。IF仕様書とは、その設計判断をインターフェース1本ごとに文書として固定したものだと言えます。ERP以外でも、WMSやLIMSとの連携で決めるべき項目は同一です。
異常系の記述は「再送・重複・順序」の3点で書く
7項目のうち最も筆が止まるのが5番と6番、つまり異常系です。網羅しようとすると書けなくなるため、実務では次の3点に絞って各インターフェースを点検すると、実用上十分な仕様になります。
再送──失敗したデータは誰が、いつ、どうやって再送するのか。自動リトライの回数と間隔、リトライ上限を超えたときの人手介入の手順、再送を指示できる画面や機能の有無。「自動で再送されます」とだけ書かれた仕様書は、リトライ上限超過後の世界を書いていません。
重複──同じデータが2回届いたら何が起きるのか。ネットワークのタイムアウトでは「送信側は失敗と認識、受信側は成功」という不一致が必ず起こり得るため、再送があるなら重複は必ず発生します。受信側が一意キーで重複を検出して読み飛ばす（冪等にする）のか、二重登録を許して後で人が消すのか。前者が原則ですが、そのためには4番のキー設計で「同一データを識別できるキー」を定義しておく必要があります。
順序──追い越しが起きたら何が起きるのか。「工程開始」より先に「工程完了」が届く、指図の「変更」より後に古い「新規」が届く。周期バッチでは起きにくい一方、イベント駆動・リアルタイム連携では普通に起きます。受信側でシーケンス番号やタイムスタンプにより順序を検証するのか、順序不整合をエラーに落として人が裁くのかを決めます。
様式は「1インターフェース1シート＋一覧表」で管理する
10年の運用に耐える様式として、私たちは次の2階層を推奨しています。
- インターフェース一覧表（1枚）：全IFの番号・名称・方向・相手システム・方式・頻度・担当を一覧化します。障害時に「このデータはどのIFで来ているか」を最初に引く索引であり、運用移管後に最も参照される紙です
- 個別仕様書（IFごとに1シート）：上記7項目＋項目定義（項目名・型・桁・必須・値域・コード変換）＋処理フロー図。コード変換表（MESの品目コードとERPの品目コードの対応など）は別紙にせず、この仕様書から参照される場所を一意に決めます
運用開始後にこの文書を腐らせないための要点は2つです。第一に、版管理とリリースの紐付け。仕様書の版数とシステムのリリース番号を対応させ、「今動いている仕様はどの版か」を常に特定可能にします。第二に、変更時の両側レビューの義務化（7番の手続き）。片側のベンダーだけで項目追加を進めさせない統制は、文書様式ではなく変更管理プロセスの問題であり、保守契約の変更管理条項と整合させておく必要があります（保守契約で確認すべき8項目参照）。
なお、設備との接続（PLC・SCADAレイヤ）は本記事の対象外ですが、タグリストとアドレスマップを同じ思想（一覧＋個別、版管理）で整備する点は共通です。
よくある質問
IF仕様書は発注側とベンダーのどちらが書くべきですか？
執筆はベンダーで構いませんが、7項目のうち1（正となるシステム）・3（タイミング）・6（相手停止時の運用）は業務判断であり、発注側が決めない限りベンダーは書けません。現実的な分担は、発注側が7項目を決定事項として提示し、ベンダーが項目定義・処理フローを含む仕様書に落とし、相手システム側ベンダーを含めた三者レビューで確定する形です。MESベンダーとERPベンダーの直接調整を放置すると、責任の押し付け合いになった時に発注側が仲裁できなくなります。
インターフェースは何本くらいになるのが普通ですか？
ERP・WMS・設備系を含めた標準的な構成で15〜30本程度に収まることが多いというのが、サオスの導入支援経験にもとづく目安です（公表された統計ではありません）。本数そのものより注意すべきは、1本あたりの設計・テスト工数が方式の新規性に大きく依存することです。既存の連携基盤・実績ある方式に乗るIFと、新規方式のIFを一覧表上で区別し、後者に工数とテスト日程を厚く配分してください。
標準規格（B2MMLなど）を使えば、仕様書は簡単になりますか？
項目定義の部分は標準の語彙に乗ることで議論が短縮できます。ただし本記事の7項目、特に異常時の振る舞い・停止時運用・変更手続きは、メッセージ形式の標準では定義されない運用の合意事項であり、標準を採用しても書く量は減りません。「B2MML準拠なので仕様書は簡略化できます」という提案があった場合、簡略化されるのが形式部分だけであることを確認してください。B2MMLで何が定義されるかはB2MML v7の解説を参照してください。
