EDIは取引先・基幹システム・通信回線をまたぐため、要件定義とRFPの質が導入や刷新を左右します。接続は当然と軽視されがちですが、詰めが甘いと後工程の費用や企業間トラブルに響きます。
全体像はEDIシステムの完全ガイドもご覧ください。
▼全体ガイドの記事
・EDIシステムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
企業間連携の責任分界点の要件化
EDIの要件定義で特に見落とされるのが、企業間の責任分界点です。社内システムとは異なる企業間連携では、それならではの視点が必要になります。
境界が曖昧なままだと、障害時に責任を押し付け合うおそれがあります。そのため、ここを要件として明文化することが最も重要です。
データ到達・正当性の責任境界の定義
まず、自社の責任を果たしたとみなすデータ到達点を要件に書きます。到達点が受信サーバーへの到達時点か、相手の基幹システムへの正常取込時点かで、責任の重さが変わります。さらに、到達確認（受信通知）の有無と、それを双方が取引の証跡と認めるかも、あらかじめ定めておく必要があります。
これらが未定義のままでは、注文未処理時にどちらの責任か判断できません。
受信データの正当性チェックを、送信側と受信側のどちらが担うかも合意しておきます。必須項目の欠落、桁数違反、未登録の商品コードについては、それぞれへの対応を決めておく必要があります。
- 送信側の対応：データの訂正と再送
- 受信側の対応：受信データの補正
- システムの対応：不備の検知とエラーの返却
エラー処理は技術の問題であると同時に、業務上の分担でもあります。そのため、取引先と合意したうえで、不備時の責任分担と再送ルールをRFPに明記します。
荷待ち記録など企業間のデータでは、入力者と入力時点、双方が証拠と認めるかも決めておきます。受発注・出荷データの遅延や訂正が起きたときは、記録先と権限も定めます。
異常時や例外時の扱いまで定めておくと、後から事実関係を確認でき、責任分界が実効性を持ちます。
複数ベンダー間の責任境界を契約に落とす要件
EDIには、基幹システムのベンダー、EDIツールのベンダー、取引先側の担当者が関わります。そのため、障害箇所によって責任を負う主体が変わります。
- 一次窓口：障害発生時に一次対応を担うベンダーをRFPで指定する
- 責任境界：ベンダー間の責任範囲を要件として明記する
- 境界の証跡：各インターフェースで受け渡しを確認するログ
API連携で全体最適を目指す提案では、複数のシステムをまたぐため、障害の切り分けが難しくなります。そこで、各システムの境界（インターフェース）を明確に定義しておきます。
境界ごとにデータの受け渡しをログで確認できる仕組みを要件に含めると、責任の切り分けが容易になります。反対に、境界が曖昧なままだと、各社が担当外と主張し、復旧が遅れます。
riplaはフルスクラッチ受託の立場から、責任分界を契約と要件の両面で整理します。
通信手順・データ変換要件の数値化
EDIの要件定義で具体性が問われるのは、通信手順とデータ変換です。これらを抽象的に書くと、見積もりが不正確になり、想定外の追加費用が発生します。
そのため、取引先構成や形式を棚卸しして具体化しておきます。要件が具体的であれば、ベンダーは精度の高い提案を出せ、複数社の提案も公平に比べられます。
通信手順・取引先構成の洗い出しと要件化
通信手順の要件は、取引先ごとの採用状況を洗い出すことから始めます。そのうえで、対応手順の一覧と、手順別の取引先社数・取引量をRFPに記載します。
- 流通業界標準：JX手順
- 金融標準：全銀TCP/IP手順
- 国際的な手順：AS2、ebMS
- 従来型の手順：全銀手順
INSネットの終了に伴って移行が必要になる取引先数も、あわせて明記します。これにより、ベンダーは必要な手順対応の範囲を把握できます。
Web-EDIとシステム間EDIの対象となる取引先も区分しておきます。たとえば、IT対応が難しい中小取引先は画面入力、大手取引先はシステム間連携とする使い分けが一般的です。
FAXや電話による注文を、AI-OCRなどでデータ化して統合するかどうかも判断します。取引先構成を丁寧に洗い出すほど、要件と見積もりの精度は上がります。
データマッピング要件の具体化
データマッピングはEDI構築で工数がかかるため、要件の精度がそのまま費用に直結します。取引先形式と基幹形式の差を、RFPに具体的に書き出します。
- 文字コード：EBCDIC、Shift_JIS、UTF-8など
- 値の形式：日付・金額の桁数や表記
- 項目構成：データ項目の並び順
- 変換規模：商品コード件数と取引先別のマッピング数
変換テーブルの件数やマッピングのパターン数を示せば、工数を見積もれます。一方で、「適宜対応」とだけ書くと見積もりが甘くなり、後の調整につながります。
変換ルールを、画面上でノンプログラミングに保守するか、プログラムとして実装するかも明記します。変更の頻度が高い企業では、現場で保守できる機能が要件の候補になります。さらに、未登録の商品コードや想定外の形式を検知する要件も加えます。
このように、具体的な数値と例を示すことが、追加費用の膨張を防ぎます。
基幹連携とトランザクション要件の設計
EDIと基幹システムを連携するなら、トランザクション（処理の一貫性）を設計段階で定めておく必要があります。EDI側で受信した後に基幹への取込が失敗すると、片方だけが処理された不整合が生じます。
この「片肺飛行」の状態を検知して復旧する手段を要件に含めておかないと、原因の分からない受注漏れや二重計上が起きます。
不整合検知とロールバック・リカバリ要件
トランザクション要件では、不整合の検知と復旧方法を定めます。受信成功後に基幹取込が失敗した状態を自動で検知し、どの段階で停止したかを見えるようにします。
- 再取込：失敗したデータを安全に取り込む
- ロールバック：処理全体の取り消し
どちらの方式で実現するかを、要件に定めておきます。仕組みがなければ、担当者が手作業でデータを照合することになります。
受発注データの二重取込は、過剰出荷や過剰請求を招き、取引先との信頼を損ないます。そのため、同じデータを再送したときに重複を防ぐ冪等性も検討します。
冪等性とは、同じ処理を何度実行しても結果が変わらない性質です。一意キーで重複を排除する方法が、要件の候補になります。
また、J-SOXでは、いつ、誰が、どのデータを復旧したかという証跡をログに残します。トランザクション要件は、企業間取引の正確性を支える業務要件です。
連携方式・データ受け渡し方式の要件
基幹との連携方式は、データの性質に応じて決めます。APIによるリアルタイム連携にするか、CSVや固定長ファイルを使うバッチ連携にするかで、構成と費用が変わります。
- 即時性が重要な受注：リアルタイム連携
- 夜間処理でよいデータ：バッチ連携
すべてをリアルタイムにすると、費用は膨らみます。そのため、業務上の必要性に照らして方式を切り分けます。
対象となる基幹の製品名、バージョン、連携用インターフェースの有無も明記します。APIがなければ、ファイル連携や中間テーブルが必要になります。
その場合は追加の工数を見込んでおきます。基幹側の制約を要件定義で洗い出さないと、開発後半に連携できず、致命的な手戻りが起きます。
連携の頻度とタイミングも定めておきます。受注の即時取込、一定間隔の処理、夜間一括処理では、現場の運用が変わります。
失敗に誰が気づくか、再実行を誰の権限で行うかも決めておきます。連携方式は、基幹システムとセットで設計し、異常時の運用まで定めます。
法令・非機能・移行要件の抜け漏れ防止
機能要件を固めたら、見落とされやすい法令・非機能・移行の要件も、RFPに加えます。これらは、動くだけでなく安心して長く使えるシステムにするための要件です。後付けすると大きなコストがかかるため、最初の要件定義で押さえておきます。
電帳法・J-SOX・インボイス対応の要件
EDIのRFPでは、法令ごとに必要となる保存・検索と統制の要件を整理します。
- 電子帳簿保存法・インボイス制度：取引データの保存・検索と適格請求書の必要項目
- J-SOX（内部統制）：承認者・送信者の証跡を残し、承認権限と実行権限を分ける
- 法令の適用範囲：業種・規模に応じて対象法令を洗い出し、EDI要件に反映する
法令対応を後付けすると、新規構築の段階で含めた場合の2〜3倍のコストがかかると言われています。実例では、サポート費を年100万円節約した一方で、稼働半年後のインボイス改正対応を別会社へ500万円で追加発注しました。そのため、法令対応は最初から含めるのが最も安上がりです。
J-SOX対応は監査対応の前提にあたり、上場企業では必須です。
移行・拡張・追加開発単価の要件
INSネットの終了に伴うレガシーEDIの移行要件を、RFPで具体化します。
- 移行計画：取引先の移行順、旧新EDIの並行運用、データ移行範囲、ベンダーの支援体制
- 稼働後の変更：取引先・通信手順・マッピングの追加にかかる費用と期間
- 追加開発単価：人月単価のテーブルを事前に取り決める
取引先を巻き込む移行では、一斉切替にリスクが伴うため、段階的な移行が現実的です。また、追加開発の人月単価が後から1.5倍に上がるといった契約の落とし穴もあり、長期のコストに影響します。
そのうえで、自社の取引実態、法令、将来計画をRFPに反映させます。
riplaはフルスクラッチ受託の立場から、責任分界を含むEDI要件を整理します。追加費用が膨らまない契約と要件の設計も支援します。
セキュリティ・可用性・性能の非機能要件
非機能要件では、取引データの安全性と安定稼働を左右する項目を定めておきます。
- セキュリティ：通信の暗号化、アクセス制御、改ざん検知、不正アクセス対策
- Web-EDIの認証：インターネット経由のアクセスに対する認証強度とログイン履歴
- 可用性：稼働率と障害時の復旧目標時間
- 性能：月末など集中時の想定件数と、ピーク時に1時間あたり処理できる件数
EDIは機微な取引データを扱い、受発注が止まると取引そのものが滞ります。セキュリティは後から付けると大きな改修が必要になるため、最初の要件定義で具体化します。
非機能要件が曖昧だと、遅いシステムや復旧に時間がかかるシステムになりがちです。そのため、数値で定義しておくことが安定利用の条件です。
まとめ
EDIシステムの要件定義とRFPでは、責任分界、通信と変換、基幹連携とトランザクションを押さえます。電帳法・J-SOX、移行、追加単価などの法令・非機能要件も、漏れなく整理します。
データ到達責任、片側だけ処理された際の検知と復旧、ベンダー間の責任境界は、RFPで抜けがちな論点です。いずれも企業間システム特有で、トラブル時に大きな負担となります。
要件定義は機能を並べるだけでは完結しません。そのため、取引先構成、通信手順、データ形式、法令、将来計画を洗い出しておく必要があります。
責任分界まで言語化することが、精度の高いRFPの条件です。追加費用や企業間トラブルの防止にもつながります。
riplaはフルスクラッチ受託とAI駆動開発を組み合わせ、責任分界・トランザクション・法令対応を含む要件整理を支援します。全体像は完全ガイドをご覧ください。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。