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

Web-EDI開発の発注・外注は、取引先数と業務範囲を先に定義し、標準仕様への対応と基幹システム連携の要否をそろえて比較すると失敗しにくいです。少数の取引先がブラウザで注文を確認するだけならSaaS・ASPが向き、多数接続や自動連携まで求める場合は、要件定義から運用設計まで対応できる開発会社へ委託する方法が現実的です。

本記事では、Web-EDIを発注者側または受注者側で導入する企業に向けて、発注形態の選び方、RFPと要件の整理、契約形態、2026年時点で確認できる費用レンジ、委託先の選定、相見積もりの比較方法を順番に解説します。見積書の安さだけで決めず、取引先追加や障害対応まで含めた年間総額と業務の定着性を判断できる状態を目指します。

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

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

Web-EDIは、企業間で注文、出荷、納品、請求などの取引データをブラウザやデータ連携で交換する仕組みです。発注者が仕入先へ注文を出す場合と、受注者が取引先から注文を受ける場合では、必要な画面や運用が異なります。発注前にこの違いを整理しないと、不要な機能を作る一方で、現場が必要とする受注回答や例外処理が抜けるおそれがあります。

発注者側では、発注登録、納期回答の回収、出荷・納品の確認、検収、請求・支払照合、仕入先マスタの管理が中心になります。多数の仕入先を巻き込む場合は、アカウント発行、説明会、接続確認、問い合わせ窓口までがプロジェクトの一部です。受注者側では、注文確認、受注回答、出荷予定・実績の登録、納品書や請求データの作成が中心になります。既存の販売管理や在庫管理へ取り込むCSV・API連携まで必要かを先に切り分けます。

最初に検討する発注形態は、既製のクラウドSaaS・ASPを契約する方法、EDIパッケージやVANを導入して必要な設定を依頼する方法、既存サービスを拡張する方法、要件に合わせて個別開発する方法です。ブラウザでの確認とCSV入出力だけなら、SaaS・ASPを使うことで短期間に始めやすいです。一方、在庫引当、承認、返品、複数倉庫、基幹システムへの自動連携など、自社固有の業務が多い場合は、パッケージを中心に追加開発するほうが保守しやすいです。

全面的なスクラッチ開発は、標準サービスで対応できない差分が大きい場合に限って選択します。Web-EDIは取引先や業界標準の変更に追随する必要があるため、すべてを独自仕様にすると、取引先追加のたびに改修費が発生しやすくなります。流通BMS協議会も個社仕様のWeb-EDIが乱立することを抑える基本方針を示しているため、標準メッセージやCSV項目に寄せ、固有部分だけを拡張する設計が発注時の重要な判断になります。

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

発注は「会社を探して見積を取る」だけでは進みません。業務の対象範囲を決め、現状データを整理し、候補会社へ同じ条件でRFPを渡し、提案と見積を比較してから契約します。次の5ステップを社内の決裁日程と接続すると、担当者の経験だけに依存しない進行になります。

まず、電話・FAX・メール・Excel・既存EDIで行っている取引を、発注、受注回答、出荷、納品、返品、請求、支払照合の単位に分解します。各業務について、担当部署、入力する項目、処理の締め時刻、例外処理、月間件数、取引先数を一覧にします。目的も「紙をなくす」だけでなく、「入力転記を何回減らすか」「納期回答の回収率をどう上げるか」「取引先追加に何日かかっているか」まで具体化します。

受注者の場合は、取引先ごとに異なる画面やCSVを何種類使っているか、販売管理への二重入力がどこで起きているかを確認します。発注者の場合は、仕入先のデジタル対応状況、標準フォーマットに移行できる範囲、非対応先への代替手段を確認します。ここで業務責任者と経理・情報システム・現場の意見をまとめると、開発会社へ伝える要件の優先順位が明確になります。

RFPには、背景、対象業務、対象となる取引先数、月間伝票数、利用者数、希望時期、予算の考え方、既存システム、必須機能、将来機能、提案してほしい事項を記載します。機能は「発注データを登録する」のような画面単位だけでなく、「締め時刻を過ぎた注文は承認者の確認を必須にする」「出荷実績が未着の取引先を一覧化する」のように業務ルールまで書くことが重要です。

データ連携のRFPでは、商品コード、取引先コード、納品先、単価、税区分、数量、納期、返品理由などの項目を、送信元・送信先・必須／任意・桁数・形式・エラー時の扱いまで整理します。CSV、API、SFTPのどれを使うかを未決定のままにする場合は、候補会社に方式ごとの費用差と運用差を提案させます。画面、帳票、通知、権限、ログ、バックアップ、障害時の代替運用、解約時のデータ返却もRFPに含めます。

候補は、SaaS提供会社、EDI・VAN事業者、業務システム開発会社、既存基幹システムの保守会社などから、案件の性質に合わせて3社前後に絞ります。比較のため、同じRFPとサンプルデータを渡し、初期費用、月額費用、従量費用、追加開発、移行、テスト、教育、保守、取引先展開支援を分けた見積を求めます。Web-EDIに詳しくても基幹連携の実績が乏しい会社、開発力があっても取引先調整の体制がない会社は、役割分担を含めて評価します。

提案書では、要件への適合表だけでなく、標準機能で対応する箇所、設定で対応する箇所、追加開発する箇所、業務運用で補う箇所を確認します。候補会社が「標準対応」と書いていても、取引先ごとのフォーマット変換やCSVの手修正が残る場合があります。デモやサンプルデータによる検証を行い、正常系だけでなく、欠品、納期変更、返品、重複送信、通信失敗、月末締めのケースを確認します。

要件が固まっていて成果物を明確に定義できる範囲は請負契約、要件整理や運用設計のように検討しながら進める範囲は準委任契約が一般的な選択肢です。SaaS・ASPの利用部分はサービス利用契約、追加開発は請負または準委任、運用監視は保守・運用契約というように、仕事の性質に応じて分けることもできます。契約名だけで判断せず、成果物、検収条件、変更管理、再委託、知的財産権、個人情報、障害時の責任、解約時のデータ返却を確認します。

特にWeb-EDIでは、取引先ごとの接続テストやマッピングが遅れると、開発会社だけでは納期を保証できません。発注者が提供するマスタ、取引先への説明、検証データの準備、受入テストの担当を契約書やプロジェクト計画に明記します。追加要望の単価、見積の有効期限、納期遅延時の報告方法、サービスレベルの測定方法も、口頭合意にせず文書化します。

本番稼働の前に、代表的な取引先を1〜3社、代表商品、通常注文、納期変更、欠品、返品、月末処理まで含めたPoCを行います。発注者の場合は、取引先ごとにアカウントを発行して接続確認を行い、受注者の場合は、注文データが販売管理や在庫管理に正しく取り込まれるかを確認します。画面が表示できるだけでなく、数量・単価・税区分・納期・ステータスが最後まで一致することが合格条件です。

本番移行は、旧運用との並行稼働期間、切替判定、障害時の手戻り手順、問い合わせ窓口を決めてから行います。取引先が多い案件では、業界や取引量でグループを分け、段階的に展開します。稼働後も、入力ミス、未処理件数、取引先追加に要した時間、問い合わせ件数を月次で確認し、次の開発優先度を決めると、導入効果を継続して高められます。

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

Web-EDIの費用は、サービス利用料だけでなく、取引先接続、データ変換、基幹連携、移行、教育、運用監視を合算して考えます。公開価格から確認できる小規模導入の目安と、個別開発を含む案件の推定レンジは性質が異なるため、同じ「初期費用」として並べないことが重要です。以下の金額は2026年時点で確認できる公開情報と、業務システム連携を含む場合の一般的な見積傾向を整理したものです。

取引先が1〜数社で、ブラウザ利用が中心、既存システムとの自動連携を行わない場合は、初期5万〜30万円程度、月額1万〜5万円程度からが一つの目安になります。導入期間は数日から1か月程度が想定されますが、これはサービス登録や初期設定が中心のケースです。NECソリューションイノベータの受注者向けWebEDI ASPサービスでは、税別で基本加入5万円、基本導入20万円、基本月額4万円が公開されています。ただし、FITEDI利用料や統一企業コード更新費用などが別途必要と明記されています（出典: NECソリューションイノベータ、2026年確認）。

取引先が数社から数十社で、CSV入出力、専用帳票、ユーザー教育、移行支援を含める場合は、初期30万〜150万円程度、月額3万〜15万円程度が見積の出発点になります。基幹システムとの自動連携、複数フォーマット変換、取引先の一括展開が加わると、初期300万〜1,000万円程度、導入期間3〜6か月程度の案件になります。発注者側で共通基盤を新規構築し、多数拠点、高可用性、個別マッピング、運用監視まで含める場合は、初期1,000万〜3,000万円超となる可能性がありますが、これはWeb-EDI専用の公定相場ではなく、要件に基づく推定レンジです。

初期費用には、要件定義、画面・帳票設定、マスタ移行、データマッピング、APIやSFTPの接続、権限設定、テスト、教育、取引先説明会が含まれます。月額費用には、基本利用料、ユーザー数、取引先数、データ量、バックアップ、監視、サポート時間が関係します。さらに、取引先ごとの接続料、帳票追加、API利用、超過データ量、統一企業コード、通信費が別請求になる場合があります。

見積を比較する際は、3年間または5年間のTCOを算出します。たとえば月額4万円でも、取引先追加料やデータ量課金が毎年増える設計なら、初期費用が高くても定額に近いサービスのほうが有利になる可能性があります。逆に、少量取引なのに大規模基盤を契約すると過剰投資になります。候補会社へ「取引先10社、月間伝票1,000件、CSV連携あり」など共通条件を提示し、同じ条件の年間総額で比較します。

Web画面だけで始められるSaaSは短期導入に向きますが、毎日CSVを加工して手入力するなら、社内作業が残ります。反対に、自動連携を最初から構築すると初期費用は増えますが、入力や照合にかかる人件費を減らせる場合があります。NTTドコモソリューションズの公開事例では、手作業で10人以上を要していた受発注業務をEDI化した例や、約5,000社の導入実績、24時間365日のサポートが示されています（出典: NTTドコモソリューションズ、2026年確認）。個別企業の成果をそのまま自社へ当てはめず、削減できる作業時間を自社の件数で試算します。

導入期間も、開発会社が作る期間だけでなく、社内承認、マスタ整備、取引先調整、教育、並行稼働を含めます。少数取引先なら数日〜1か月、設定や教育を含めると1〜3か月、基幹連携と多数接続を含めると3〜6か月以上が一つの目安です。数百社から数千社へ展開する発注者は、接続先の回答待ちや説明会の回数によってさらに長期化するため、波次計画を見積条件に入れます。

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

委託先は、開発実績の数だけでなく、Web-EDI特有のデータ交換、取引先調整、運用監視をどこまで担えるかで評価します。候補会社の提案を同じ物差しで比べるには、要件の優先順位と質問項目をあらかじめ決めることが必要です。特に「使える画面があるか」ではなく、「取引が止まったときに復旧し、相手先へ説明できるか」まで確認します。

必須要件には、発注・受注・出荷・請求の対象範囲、利用者と権限、取引先数、月間伝票数、対応するフォーマット、稼働時間、保存期間、障害時の連絡方法を記載します。将来要件には、取引先追加、複数拠点、API連携、モバイル対応、在庫・会計連携、分析機能などを置き、初期開発に含めるか、拡張可能性だけを確認するかを分けます。要件を全部「必須」にすると見積が膨らみ、優先順位が見えなくなります。

セキュリティ要件は、TLS、MFA、IP制限、最小権限、操作・通信ログ、保存データの暗号化、脆弱性対応、バックアップ、RTO・RPO、インシデント連絡体制を確認します。取引データの保存や検索が関係する場合は、電子帳簿保存法やインボイス制度への対応を一律に断定せず、自社の保存業務と税務要件を整理したうえで、サービスの仕様と専門家の確認を分けます。

「製造業の実績がある」という説明だけでなく、取引先数、メッセージの種類、CSV・API・SFTPの方式、基幹システムとの接続、受注者への導入支援、運用時間を聞きます。発注者が数百社を展開する案件と、受注者が数社の注文を受ける案件では、同じWeb-EDIでも必要な体制が違います。可能なら、類似案件の画面、接続テスト計画、障害対応の流れ、稼働後の問い合わせ件数と体制を匿名化した範囲で提示してもらいます。

流通分野なら、流通BMSの標準メッセージや通信プロトコルにどの程度対応できるかを確認します。GS1 Japanは流通BMSを、メッセージと通信プロトコル・セキュリティに関するEDI標準仕様として説明し、発注、出荷、受領、返品、請求、支払の6業務・8種の標準メッセージを公開しています（出典: GS1 Japan、2026年確認）。標準に合わせられる会社ほど取引先追加時の個別改修を抑えやすい一方、自社業務との差分は別途整理が必要です。

見積書の比較表には、要件番号、対応方法、工数、単価、金額、納期、担当、前提条件、除外項目を並べます。A社は標準設定、B社は追加開発、C社は運用で対応しているという違いがあると、合計金額だけでは比較できません。取引先ごとのマッピング数、マスタ移行件数、帳票の種類、テストケース、説明会の回数をそろえ、追加1社・追加1帳票・追加1万件の単価も確認します。

安い見積ほど、データ移行、受入テスト、問い合わせ窓口、障害監視、バックアップ復元テストが除外されていないかを確認します。反対に、高額な見積でも、使わない独自機能や過剰なカスタマイズが含まれている場合があります。評価は価格だけでなく、要件適合度、導入後の社内作業、将来の拡張費、運用体制、担当者とのコミュニケーションを合算して決めます。

ブラウザ画面とCSVだけで足りるか、将来APIによる自動交換を行うかを、発注時に確認します。JiEDIAは2026年1月、EDI用途のWeb API利用ガイドラインを公開し、APIを使うデータ交換について一定の基準を設ける考え方を示しています（出典: JiEDIA、2026年1月）。APIを選ぶ場合は、認証、権限、レート制限、再送、冪等性、エラーコード、監査ログ、バージョン管理をRFPに入れます。単に「API対応」と書かれているだけでは、実運用に必要な条件を満たすとは限りません。

運用面では、夜間バッチの失敗、通信遅延、重複データ、取引先のパスワード忘れ、サービス障害、緊急の納期変更に誰が対応するかを決めます。24時間365日対応が必要か、営業時間内の一次受付で足りるかは、取引の締め時刻と業務停止の影響で判断します。監視費用、休日対応費用、復旧目標、連絡経路、月次レポートの有無を見積書とサービスレベル合意に反映します。

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

Web-EDIの外注では、費用の安さ、短期導入、標準対応のどれを優先するかによって適した選択肢が変わります。ここでは、発注前によく寄せられる疑問に、条件を分けて回答します。

取引先が少なく、ブラウザ利用やCSV入出力で業務が完結するなら、SaaS・ASPから始める方法が適しています。既存の販売管理・在庫・会計との自動連携、複雑な承認、独自の返品・請求処理、多数の接続先がある場合は、パッケージや開発会社による追加開発を比較します。自社開発は、標準サービスとの差分が大きく、長期的に保守できる人員と予算がある場合に限定して検討します。

公開料金を基準にすると、少数接続で自動連携なしの場合は初期5万〜30万円程度、月額1万〜5万円程度からが一つの目安です。CSV、帳票、教育を含めると初期30万〜150万円程度、基幹連携や多数接続を含む個別開発では初期300万〜1,000万円程度が見積の出発点になります。取引先数、伝票量、フォーマット、移行、保守によって変動するため、金額を一つに断定せず、初期・月額・従量・追加開発・運用の内訳と3〜5年のTCOで確認します。

背景と目的、対象業務、発注者・受注者の区分、取引先数、月間伝票数、データ項目、利用者権限、既存システム、連携方式、セキュリティ、希望時期、予算の考え方を記載します。正常系だけでなく、欠品、納期変更、返品、重複送信、通信失敗、締め処理も例として添えます。候補会社から同じ条件で、標準機能・設定・追加開発・運用対応のどれで実現するかを示してもらうと、相見積もりを比較しやすくなります。

不要とは限りません。流通BMSの標準メッセージや通信方式に対応していても、自社の販売管理・在庫・会計システムとのマッピング、独自の承認、帳票、例外処理、取引先ごとの運用が残ることがあります。標準部分を活用し、固有業務だけを追加開発できるか、取引先追加時の設定費とテスト費がいくらかかるかを委託先へ確認します。

まとめ

Web-EDI開発の発注・外注では、最初に発注者側か受注者側か、どの取引プロセスを対象にするかを定めます。そのうえで、SaaS・ASP、パッケージ・VAN、追加開発、スクラッチを比較し、標準仕様に寄せる範囲と自社固有の差分を整理します。RFPには、取引先数、伝票数、データ項目、既存システム、例外処理、セキュリティ、運用体制を記載することが重要です。

少数接続で画面利用が中心なら、初期5万〜30万円程度、月額1万〜5万円程度からが目安になります。CSVや教育を含むと初期30万〜150万円程度、基幹連携や多数接続を含むと初期300万〜1,000万円程度が一つの推定レンジです。公開料金、個別見積、一般的な開発費からの推定を区別し、取引先追加、データ量、保守、移行、教育まで含む3〜5年のTCOで比較します。

委託先を選ぶときは、機能の多さや初期費用だけでなく、同じ接続条件での実績、取引先展開の支援、標準仕様への対応、障害時の責任分界、APIや将来拡張の設計を比較します。まずは代表的な取引先とサンプルデータを用意し、共通のRFPで3社前後から提案と見積を取得してください。要件・見積・契約・テスト・運用を一つの計画として確認することが、Web-EDIを現場で使い続けるための近道です。

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

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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