Web-EDI開発の発注/外注/依頼/委託方法について

Web-EDI開発の発注は、業務範囲を整理し、標準仕様との適合を確かめ、委託先を比べる順に進めると、現場に合う運用につながります。

発注形態、5ステップ、費用相場、委託先の選び方を順に見ていきます。全体像はWeb-EDI開発の完全ガイドでも確認できます。

▼全体ガイドの記事
・Web-EDI開発の完全ガイド

Web-EDI開発を発注・外注するときの全体像

Web-EDIは、注文や出荷、納品、請求などの取引データを、ブラウザやデータ連携で交換する仕組みです。発注側と受注側とでは、必要な画面も運用も異なります。

発注者と受注者の違いを発注前に整理しておかないと、不要な機能が増えるうえに、受注回答や例外処理が抜けるおそれがあります。

発注者と受注者それぞれの発注範囲

発注側と受注側で、Web-EDIの対象にする業務を分けて洗い出します。

  • 発注者:発注登録、納期回答の回収、出荷・納品確認、検収、請求・支払照合、仕入先マスタ管理
  • 受注者:注文確認、受注回答、出荷実績、納品書・請求データ作成

仕入先が多い場合は、アカウント発行や接続確認に加え、説明会や問い合わせ窓口もプロジェクトの作業に入れておく必要があります。

受注者は出荷の予定と実績も登録します。また、販売管理や在庫管理に取り込むCSVやAPI連携が要るかどうかも切り分けます。

SaaS・パッケージ・個別開発の比較

発注形態は、業務の複雑さと標準サービスとの差分をもとに選びます。

  • SaaS・ASP:ブラウザでの確認とCSV入出力を、短期間で始めやすい
  • パッケージ等:EDIパッケージ、VAN、既存サービスの拡張、追加開発
  • スクラッチ開発:標準サービスとの差分が大きい場合に限られる

固有業務には、在庫引当や承認、返品があります。複数倉庫や基幹連携も、固有業務の代表例です。

Web-EDIは、取引先や業界標準の変更に追随していく必要があります。特に、独自仕様が多いと、取引先を追加するたびに改修費がかかりやすくなります。

流通BMS協議会も、個社仕様のWeb-EDIが乱立しないよう、基本方針を示しています。この方針を踏まえると、標準メッセージやCSV項目に寄せ、固有部分だけを拡張する設計にするかどうかが、発注時の重要な判断になります。

ポイント

発注者と受注者のどちらの業務かを分けずに進めると、不要な機能が増えたり、受注回答や例外処理が抜けたりします。対象業務を先に決め、発注形態は業務の複雑さと標準サービスとの差分で選びます。

Web-EDI開発の発注・外注を進める5ステップ

現状整理から本番展開前の試行まで、Web-EDI発注の5段階を矢印で示した図。
前工程で決めた条件を次の工程へ引き継ぐ構成です。

会社探しや見積取得の前に、業務範囲と現状データを整理しておくことが欠かせません。そのうえで、共通条件のRFPで提案を比べ、契約へ進みます。5段階を決裁日程と結び付けると、担当者の経験に頼らずに進められます。

1. 現状業務と発注目的の整理

既存の取引を、発注から支払照合までの業務ごとに洗い出します。手段は、電話やFAXのほか、メール、Excel、既存EDIも対象です。

  • 業務と現状:担当部署、入力項目、締め時刻、例外処理、月間件数、取引先数
  • 導入目的:「紙をなくす」に加え、転記を何回減らすか、回答回収率、追加にかかる日数まで具体的に示すこと
  • 受注者側:取引先別の画面とCSVの種類、二重入力の箇所
  • 発注者側:仕入先のデジタル対応と標準化の範囲

発注者は、標準フォーマットへ移せる範囲と、対応できない取引先への代替手段も確認します。業務責任者と経理の意見を集め、情報システムや現場の意見も加えると、要件の優先順位が明確になります。

2. RFPと要件定義書の作成

RFPでは、業務要件とデータ連携、運用と障害時の条件を、候補会社へ共有します。

  • 基本情報:背景、対象業務・取引先数、伝票数、利用者数、時期、予算、既存システム、提案事項
  • 業務ルール:締め後の承認や未着の出荷実績一覧など、画面の外にある要件
  • データ仕様:項目、送受信先、必須・任意、桁数、形式、エラー時の扱い
  • 運用条件:画面、帳票、通知、権限、ログ、バックアップ、障害時の代替運用、解約時のデータ返却

データ項目には、商品・取引先コードや単価、税区分などがあります。数量や納期、返品理由も、項目として書き出しておきます。

方式が未決定のまま進める場合は、CSV、API、SFTPごとの費用差と運用差を、候補会社に提案してもらいます。

3. 委託先からの提案と見積の取得

候補は案件に応じて3社前後に絞り、同じRFPとサンプルデータを渡して比べます。

  • 候補会社:SaaS、EDI・VAN、開発会社、既存基幹の保守会社
  • 見積内訳:初期・月額・従量、追加開発、移行、テスト、教育、保守、展開支援
  • 対応方法:標準機能、設定、追加開発、業務運用のどれで実現するか

EDIに詳しくても基幹連携の実績が少ない会社や、取引先調整の体制がない会社は、役割分担の面も評価します。ただし、「標準対応」と書かれていても、個別フォーマットの変換やCSVの手修正が残る場合があります。

デモやサンプルデータでは、欠品や納期変更、返品を検証します。さらに、重複送信、通信失敗、月末締めも確かめます。正常時の動きだけで判断せず、異常系も含めて見ることが大切です。

4. 契約形態と責任範囲の決め方

契約では、仕事の性質に合った契約形態を選び、双方の責任範囲を定めます。

  • 契約形態:成果物が明確なら請負、要件整理や運用設計など検討しながら進める業務は準委任
  • 契約の分割:SaaS・ASP利用はサービス利用契約、追加開発や運用監視は別契約にする方法もある
  • 確認事項:成果物、検収条件、変更管理、再委託、知的財産権、個人情報、障害時の責任、解約時のデータ返却
  • 発注者の準備:マスタや取引先説明、検証データ、受入テストの担当者を決めておく

接続テストやマッピングが遅れると、開発会社だけでは納期を保証できません。そのため、発注者の準備事項は、契約書やプロジェクト計画に明記しておきます。

追加要望の単価や見積の有効期限、納期遅延時の報告方法、サービスレベルの測定方法は、口頭の合意で済ませず文書に残します。

5. 小規模な試行を経た本番展開

本番の前に、代表的な取引先1〜3社と商品を選び、PoCで接続と業務処理を確かめます。

  • 検証ケース:通常注文、納期変更、欠品、返品、月末処理
  • 発注者側:取引先アカウントの発行と接続の確認
  • 受注者側:注文データの販売管理・在庫管理への取り込み
  • 合格条件:数量、単価、税区分、納期、ステータスが最後まで一致すること

本番移行の前に、旧運用との並行期間と切替の判定を決めておきます。障害時の手戻り手順や問い合わせ窓口も、あわせて決めておきます。

取引先が多い場合は、業界や取引量で分けて、段階的に展開します。

稼働後は、入力ミスや未処理件数、取引先追加にかかる日数、問い合わせ件数を、月次で確認します。その結果をもとに次の開発の優先度を決め、導入の効果を高めていきます。

ポイント

会社探しや見積取得の前に業務範囲と現状データを整理し、共通条件のRFPで提案を比べる順に進めます。各段階を決裁日程と結び付けておくと、担当者の経験に頼らず進められます。

Web-EDI開発の費用相場と見積の内訳

Web-EDI開発の4つの規模区分について、初期費用の目安をカードで並べた図。
接続範囲が広がるほど、初期費用の想定レンジも上がります。

費用は、サービス利用料に加えて、接続やデータ変換、基幹連携、移行、教育、運用監視まで合算して考えます。公開価格と個別開発の推定レンジは、分けて見ます。

以下の金額は、2026年時点の公開情報と、業務システム連携を含む場合の一般的な見積傾向に基づいています。

規模別の初期費用と月額費用の目安

費用と導入期間の目安は、規模や連携範囲によって異なります。

  • 少数接続:初期5万〜30万円程度、月額1万〜5万円程度
  • CSV・帳票・教育:初期30万〜150万円程度、月額3万〜15万円程度
  • 基幹連携・複数形式・一括展開:初期300万〜1,000万円程度、導入期間3〜6か月程度
  • 共通基盤の新規構築:発注者側で新規構築する場合、初期1,000万〜3,000万円超の可能性

少数接続の目安は、ブラウザ利用が中心で、自動連携を行わない場合を指します。その場合の導入期間は、サービス登録や初期設定が中心で、数日から1か月程度です。

NECソリューションイノベータは、受注者向けWebEDI ASPサービスについて、税別で基本加入5万円、基本導入20万円、基本月額4万円を公開しています。

FITEDI利用料や統一企業コード更新費用などは、別途必要です(出典: NECソリューションイノベータ、2026年確認)。また、CSVや帳票、教育、移行支援を含む場合は、導入期間が規模や準備状況によって変わります。

上の共通基盤の新規構築の費用は、多数拠点、高可用性、個別マッピング、運用監視まで含む場合が対象です。ここでの金額は、要件に基づく推定レンジで、公定相場ではありません。

見積書の初期費用・月額費用・連携費の分け方

見積は、費用の性質ごとに分けて読みます。

  • 初期費用:要件定義、設定、移行、連携、権限、テスト、教育、説明会
  • 月額費用:基本料、ユーザー・取引先・データ量、バックアップ、監視、サポート
  • 追加費用:接続料、帳票、API、超過データ、企業コード、通信費

比較は、3年または5年のTCO(総所有コスト)で行います。取引先の追加料やデータ量課金が毎年増える設計もあるため、初年度の金額だけでは比べにくくなります。

少量取引では、大規模な基盤が過剰投資になることもあります。そこで、たとえば「取引先10社、月間伝票1,000件、CSV連携あり」といった共通条件をそろえ、年間総額を比べます。

導入期間と社内負担を含めた費用比較

費用を比べるときは、社内作業がどこまで残るかと、導入準備にかかる期間も見ておきます。

  • 画面中心のSaaS:短期導入しやすいが、CSV加工や手入力が残る場合がある
  • 自動連携:初期費用が増えても、人件費を減らせる場合がある
  • 導入期間:社内承認、マスタ整備、取引先調整、教育、並行稼働を含めた期間

NTTドコモソリューションズの公開事例には、10人以上の手作業を要した受発注業務のEDI化があります。

同社は、約5,000社の導入実績と24時間365日のサポートも示しています(出典: NTTドコモソリューションズ、2026年確認)。ただし、個別企業の成果が自社にそのまま当てはまるとは限らないため、自社の件数で削減時間を試算します。

導入期間の目安は、少数接続なら数日〜1か月、設定や教育を含む場合は1〜3か月、基幹連携や多数接続では3〜6か月以上です。数百〜数千社へ展開する場合は、回答待ちや説明会で期間が延びやすいため、波次計画も見積条件に含めます。

ポイント

費用は規模や連携範囲によって大きく変わるため、公開価格と個別見積の推定レンジを分けて読みます。比較は初年度の金額だけでなく、3年または5年のTCOで、同じ条件をそろえて行います。

RFP・要件整理と委託先選定のポイント

接続条件、導入支援、運用実績、標準対応の4項目を並べた委託先選定の確認図。
同じ観点を各候補に当てると、提案内容を比べやすくなります。

委託先は、実績の数だけでなく、データ交換や取引先調整、運用監視を担えるかで評価します。まず、要件の優先順位と質問項目を決めておきます。

画面の使いやすさに加え、特に取引が止まったときに復旧できるか、相手先へ説明できる体制があるかも確認します。

RFPでの必須要件と将来要件の分け方

RFPには、初期導入で必須の条件と、将来に備える要件を分けて書きます。

  • 必須要件:対象業務、利用者・権限、取引先・伝票数、形式、稼働、保存、障害連絡
  • 将来要件:取引先追加、拠点、API、モバイル、在庫・会計連携、分析
  • セキュリティ:TLS、MFA、IP制限、最小権限、ログ、暗号化、脆弱性対応、バックアップ

将来要件は、初期開発に含めるか、拡張性の確認にとどめるかを分けて考えます。すべてを必須にすると、見積が膨らみ、優先順位も見えにくくなります。

RTO・RPOやインシデント時の連絡体制も整理します。電子帳簿保存法やインボイス制度への対応は一律には言い切れないため、自社の保存業務や税務の要件とサービス仕様を確認します。そのうえで、専門家に確かめる事項と分けておきます。

業界名より似た接続条件での実績

業界名だけでなく、案件に近い接続条件や運用体制について、候補会社に尋ねます。

  • 接続条件:取引先数、メッセージ、CSV・API・SFTP、基幹接続
  • 導入支援:受注者支援、接続テスト計画、障害対応の流れ
  • 運用実績:運用時間、問い合わせ件数、対応体制
  • 標準対応:流通BMSのメッセージと通信プロトコルへの対応

数百社へ展開する発注者と、数社から受注する企業とでは、必要な体制が異なります。このため、類似案件の画面も確認し、障害対応や問い合わせの実績は、匿名化した範囲で提示してもらいます。

GS1 Japanは、流通BMSをEDI標準仕様として説明しています。さらに、発注、出荷、受領、返品、請求、支払の6業務と、8種の標準メッセージを公開しています(出典: GS1 Japan、2026年確認)。

標準に合わせれば、取引先を追加するときの個別改修を抑えやすくなります。一方で、自社業務との差分は、別途整理しておく必要があります。

見積比較の前提条件と除外項目

比較表は、前提条件と除外項目をそろえておきます。会社によって、標準設定や追加開発、運用対応の範囲が異なるため、合計金額だけでは判断できません。

  • 比較表:要件、対応方法、工数、単価、金額、納期、担当、前提、除外項目
  • 数量条件:マッピング、移行、帳票、テスト、説明会の件数を統一
  • 追加単価:取引先1社、帳票1件、データ1万件あたりの金額

安い見積では、移行や受入テスト、問い合わせ窓口、障害監視、復元テストが除外されていないかを確かめます。

高額な見積に、不要な独自機能や過剰なカスタマイズが含まれていることもあります。したがって、価格だけでなく、適合度や社内作業、拡張費、運用体制、意思疎通を合わせて判断します。

2026年の見積条件に含めるAPIと運用設計

発注の時点で、APIを採用するかどうかの方針と、稼働後の障害対応を確認します。

  • APIの必要性:ブラウザ・CSVで足りるか、将来の自動交換を行うか
  • API要件:認証、権限、制限、再送、冪等性、エラー、ログ、版管理
  • 障害対応:バッチ失敗、通信遅延、重複、パスワード忘れ、緊急変更の担当
  • 運用条件:受付時間、監視・休日費、復旧目標、連絡経路、月次報告

JiEDIAは2026年1月、EDI用途のWeb API利用ガイドラインを公開しました。APIを使うデータ交換に一定の基準を設ける考え方を示しています(出典: JiEDIA、2026年1月)。「API対応」と書かれていても、実運用の条件を満たすとは限りません。

受付が24時間365日か、営業時間内かは、締め時刻と業務停止の影響で判断します。決めた条件は、見積書とサービスレベル合意に反映します。

ポイント

委託先の選定は、同じ条件で出させた提案を、接続の実績や導入支援、標準対応の範囲で比べて決めます。RFPでは初期導入の必須要件と将来要件を分け、候補会社の提案を一つの基準で見比べられるようにします。

Web-EDIの発注・外注でよくある質問

費用、短期導入、標準対応のどれを優先するかで、適した選択肢が変わります。発注前によくある疑問を、条件ごとに並べます。

Web-EDIは自社開発とSaaSのどちらがよいですか?

取引先が少なく、ブラウザやCSVで業務が完結するなら、SaaS・ASPが適しています。

基幹連携や複雑な承認、独自の返品・請求、多数接続がある場合は、追加開発も比較の対象になります。

自社開発は、標準サービスとの差分が大きく、長期の保守を担える人員と予算がある場合に限って検討します。

Web-EDIの外注費用はどのくらいですか?

少数接続で自動連携がない場合は、初期5万〜30万円程度、月額1万〜5万円程度からが目安です。この数字は、公開料金を基準にしています。

CSVや帳票、教育を含む場合は初期30万〜150万円程度、基幹連携や多数接続では初期300万〜1,000万円程度が、見積の出発点になります。

費用は、取引先数や伝票量、フォーマット、移行、保守によって変わります。そのため、初期費用や月額、従量、追加開発、運用を分けて、3〜5年のTCOで比べます。

RFPには何を記載すればよいですか?

候補会社から同じ条件で提案を受けるため、RFPには次の情報を記載します。

  • 基本情報:背景、目的、対象業務、発注・受注区分、取引先数、伝票数、データ項目、利用者権限
  • システム条件:既存システム、連携方式、セキュリティ、希望時期、予算
  • 例外ケース:欠品、納期変更、返品、重複送信、通信失敗、締め処理
  • 提案方法:標準機能、設定、追加開発、運用対応のどれで実現するかを、同じ条件で示してもらうこと

流通BMS対応ならWeb-EDIの追加開発は不要ですか?

流通BMSに対応していても、追加開発が必要になることはあります。標準メッセージや通信方式に対応しても、基幹システムとのマッピングや独自承認が残る場合があるためです。

帳票や例外処理、取引先ごとの運用も確認します。加えて、固有業務だけを追加開発できるかどうかや、追加時の設定費とテスト費も委託先に尋ねます。

ポイント

選ぶ基準は、取引先の数、基幹連携の有無、標準対応の範囲です。条件に合う選択肢から比べ、費用は初期と月額、追加費用を分けて、3〜5年のTCOで見ます。

まとめ

Web-EDIの発注では、まず発注者と受注者の別と、対象業務を決めます。

SaaS・ASP、パッケージ・VAN、追加開発、スクラッチを比べ、標準仕様と自社固有の差分を整理します。

RFPには、取引先数や伝票数、データ項目、既存システムを記載します。さらに、例外処理やセキュリティ、運用体制も記載します。

相場のレンジと年間総額での判断

条件ごとの費用レンジと、比較の前提を、あらかじめそろえておきます。

  • 少数接続:ブラウザ中心で自動連携なしなら、初期5万〜30万円程度、月額1万〜5万円程度
  • CSV・帳票など:教育・移行支援も含む場合、初期30万〜150万円程度、月額3万〜15万円程度
  • 基幹連携など:自動連携、複数形式変換、一括展開を含む場合、初期300万〜1,000万円程度
  • 費用の根拠:公開料金と個別見積、一般的な開発費の推定を区別して示す
  • TCO:取引先追加、データ量、保守、移行、教育を含めた、3年間または5年間の比較

共通条件のRFPによる3社前後への相談

委託先は、接続条件の実績や展開支援、標準対応、障害時の責任分界で比べます。

  • 候補準備:代表的な取引先とサンプルデータを用意
  • 相見積もり:共通RFPで3社前後から提案と見積を取得
  • 評価範囲:APIや将来拡張も含め、要件から運用まで一体で確認

要件、見積、契約、テスト、運用を一つの計画として確かめておくと、現場で使い続けやすくなります。

▼全体ガイドの記事
・Web-EDI開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。