EDIシステム開発の期間は、取引先数、カスタマイズの有無、基幹システムとの連携度合いで変わります。目安は、小規模で約1〜2か月、中規模で3〜6か月、大規模で6か月〜1年以上です。
納期を現実的にするには、規模に応じた工程設計、取引先との接続調整、マスタ整備の順に進めることが大切です。
▼全体ガイドの記事
・EDIシステムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
EDIシステム開発期間の全体像
規模の違いは、パッケージの使い方と基幹システムとの関わり方に表れます。
- 小規模：クラウド型パッケージやASP（アプリケーションサービスプロバイダ）の汎用機能のみの場合で、約1〜2か月です。
- 中規模：パッケージにカスタマイズを加える場合で、3〜6か月です。
- 大規模：基幹統合やフルスクラッチ開発を伴う場合で、6か月〜1年以上です。
EDIでは、自社内の機能開発に加えて、取引先との接続調整が期間を左右します。そのため、一般的なシステム開発と同じ感覚で予定を組むと、後工程で大きく遅れることがあります。
費用も規模によって変わります。クラウド型では、取引先数が50社以下、50〜300社、300社以上の三つで相場が分かれます。
- 50社以下：初期費用0〜10万円、月額費用1〜5万円です。
- 50〜300社：初期費用10〜50万円、月額費用5〜15万円です。
- 300社以上：初期費用50〜200万円、月額費用15〜30万円以上です。
オンプレミス型やフルスクラッチ開発の目安は、初期費用300万〜1,000万円以上、年間保守費用50万〜200万円です。
さらに、データ移行に10万〜100万円、研修に10万〜50万円、取引先向け説明会に5万〜20万円の費用も発生します。
期間と費用は合わせて検討しないと、実態と異なる計画になりかねません。
規模別の開発期間と費用の目安
計画を立てるときは、規模ごとの工程配分を確認し、開発後の並行運用まで含めて組みます。
- 小規模版：初期設定、移行・テスト、研修・周知を終えてから本稼働に入ります。
- 中規模版：開発後に移行と研修を行い、並行運用を経て本稼働します。
- 大規模版：段階的な並行稼働を経て、本稼働へ移ります。
小規模版（クラウド型・汎用機能のみ）では、要件定義と選定に2週間、契約と初期設定に1週間を割り当てます。データ移行・テストと社内研修・取引先周知には、それぞれ2週間を充てます。そのうえで、すぐに本稼働へ移るのが標準的です。
中規模版（パッケージベース・追加カスタマイズあり）では、要件定義と選定、契約とカスタマイズ要件の確定に、それぞれ1か月をかけます。開発と初期設定には2〜3か月、移行とテストには2週間、研修と周知には1か月をかけます。
並行運用から本稼働までには、さらに1〜3か月を確保します。
大規模版（基幹システム統合・フルスクラッチ開発）では、要件定義と選定、契約と仕様設計に、それぞれ2〜3か月を見込みます。開発とカスタマイズに3〜6か月、移行とテストに1〜2か月、研修と周知に1〜2か月を充てます。段階的な並行稼働から本稼働までは、3か月以上かかります。
上記の期間は、小規模版がクラウド型で汎用機能のみ、中規模版がパッケージベースで追加カスタマイズあり、大規模版が基幹統合やフルスクラッチ開発を伴う想定です。
基幹システム全体をリプレイスする場合は、プロジェクトが1〜3年規模になることも珍しくありません。
開発期間を左右する要因
期間を最も左右する要因は、取引先ごとに異なるEDI仕様や通信プロトコルへの対応です。
- 取引先の接続方式：仕様調整やテスト接続に時間がかかります。
- マスタのクレンジング：取引先マスタや商品マスタの整理に時間を要します。
- メッセージと形式：種類やデータ形式が増えるほど設計・テスト工数が積み上がります。
取引先が採用する方式もさまざまです。JCA手順や全銀協手順、流通BMSのほか、Web-EDIや個別開発のAPI-EDIを使う取引先もあります。
新システムへの切り替えでは、開発に加えて、事前通知と全取引先とのテスト日程の調整が必要になります。
取引先が多い卸売業や商社では、切り替えだけで2〜3か月かかることもあります。
取引先マスタや商品マスタには、「株式会社」と「（株）」の表記揺れ、重複登録、部分的な欠損がある場合があります。そのため、カットオーバー（本稼働への切り替え）の4〜6か月前から着手することが望まれます。
受発注・出荷・請求・支払など複数のメッセージを扱うと、データ形式の変換ロジックが複雑になります。
CSV・XML・固定長が混在すると、設計やテストの工数も増えます。
要件定義から本稼働までの工程別スケジュール
期間を見積もるには、まず全体を工程に分け、工程ごとに必要な時間を把握します。
開発期間がおよそ半年の中規模案件では、要件定義・仕様策定から始まり、開発・初期設定、取引先接続テストへと進みます。その後、並行運用を経て本稼働します。
EDIでは、要件定義の段階で通信手順とデータ形式を確定させ、後半の接続テストにも時間を厚く配分します。
上流の仕様確定を軽く扱うと、終盤になって取引先との形式の齟齬が見つかり、全取引先を巻き込む手戻りに発展します。
要件定義・仕様策定フェーズ（通信手順とデータフォーマットの確定）
要件定義と仕様策定は、プロジェクト全体の成否を左右する最上流の工程です。半年規模の案件なら、全体の1〜2割にあたる1〜2か月を割り当てます。
- 通信手順：流通BMS、全銀協TCP/IP手順、Web-EDI、API-EDIから選定し、複数併用も検討します。
- メッセージ種別：受発注から支払まで、各メッセージのデータ項目を定めます。
- マスタ統合：取引先マスタと商品マスタの統合ルールを決めます。
通信手順を後工程で変えると、取引先との再調整が発生し、全体の日程に深刻な影響を与えます。
要件定義を軽く見ると、取引先へのヒアリングが遅れます。その結果、必要な項目が開発の途中で判明し、手戻りが増えます。
要件定義書と接続仕様書を成果物として書面に残し、変更時の扱いルールまで合意しておくことが、納期遅延の予防策になります。
開発・初期設定フェーズと社内テスト
要件定義と仕様策定が固まったら、次は開発・初期設定フェーズに進みます。この工程は全体の中でも大きな比重を占め、半年規模の案件なら2〜3か月を見込みます。取引先の個別仕様を早めに洗い出しておくと、期間を見通しやすくなります。
- 接続機能：通信手順に応じたコネクタの実装
- データ変換：CSV・XML・固定長の相互変換ロジック
- 既存システム連携：販売管理システムや会計ソフトとのAPI・CSV接続
- 例外業務：返品、値引き、一部出荷、複数拠点への分割出荷への対応
共通化できる仕様と、個別の対応が要る仕様は、早めに分けておきます。標準機能で吸収できない商慣習が多いほど、開発やカスタマイズの工数は増えます。
社内テストでは、販売管理システムや会計ソフトとの連携が正しく動くかを確かめます。
この段階で不具合を直しておけば、次の取引先接続テストが円滑に進みます。
取引先との接続テスト・並行運用が期間に与える影響
自社の開発が終わっても、取引先との接続テストと並行運用を経なければ本稼働はできません。取引先数が多いほど、接続テストの日程調整だけで時間がかかります。これが、期間を読みにくくする最大の要因です。
期間への影響は、個別仕様とテスト日程の観点と、新旧システムの並行運用と切り替え時期の観点に分けて見られます。
取引先ごとの個別仕様への対応と接続テストのスケジューリング
取引先ごとに異なる仕様への対応は、自社内だけでは完結しません。そのため、事前通知と接続テストの日程調整を、全取引先と並行して進めます。
主要取引先から試していく段階的な進め方なら、問題を早く直せます。
取引先の多い卸売業や商社では、切り替え作業だけで2〜3か月かかることもあります。
- データの送受信：フォーマット変換が正しいか
- エラー時の再送：再送処理が機能するか
- システム同期：取引先側と適切なタイミングで合わせられるか
日程は取引先担当者や情報システム部門の予定にも左右されるため、自社の都合で組むことは難しくなります。そこで、窓口を一本化し、進捗が見える状態にしておくと、多数の取引先とのやり取りが込み合うのを防げます。
新旧システム並行運用とカットオーバーのタイミング設計
接続テストの後にすぐ全面移行せず、一定期間は新旧システムを並行稼働させる方法が安全です。
- 中規模：1〜3か月の並行運用期間
- 大規模：3か月以上の並行運用期間
並行運用の期間中は、受発注データの件数を照合し、返品や値引き、一部出荷などの処理を実際の運用で検証します。
カットオーバー（本稼働への切り替え）は、全取引先の新方式への対応状況に左右されます。一社でも遅れていれば、切り替えの時期をずらすこともあります。
取引先をグループに分けて順次切り替える方法もあります。その場合、新旧両方式のサポートが長引くため、運用の負荷とコストのバランスを見ながら計画します。
レガシーEDIからの移行が期間を押し上げる背景
EDIの新規構築や刷新が増える背景には、業界特有の事情があります。とくに、電話回線やISDNを前提としたレガシーEDIは、通信基盤の世代交代の影響を受けています。
この移行の圧力を知っておくと、期間や予算をかけてでも刷新が必要な理由が分かります。
ISDN回線の終了とWeb-EDI乱立という業界背景
EDI移行を促している業界の背景は、通信基盤の終了とWeb-EDIの乱立です。
- 「EDIの2024年問題」は、NTT東西のINSネット（ISDN）のデジタル通信モード終了に伴う課題です。
- 電話回線で動くJCA手順などのレガシーEDIは、そのままでは使えなくなります。
- 多くの企業は、システムの寿命にかかわらずIP-EDIや流通BMSへの移行が求められます。
- 移行では通信経路に加えて、プロトコルやデータ形式も刷新する場合が多く、取引先全社との調整が必要です。
- Web-EDIは取引先ごとのブラウザ画面に入力する方式で、乱立が受注側の負荷を高め、統合基盤への移行ニーズを後押しします。
ISDNの終了とWeb-EDIの乱立を背景とするEDI移行には、通常のシステム更改より長い期間を見込みます。
JCA手順・全銀協手順から流通BMS・インターネットEDIへの移行工数
旧方式から移る場合は、形式変換や取引先側の対応状況も工数に影響します。
- JCA手順や全銀協手順から流通BMSやAPI型インターネットEDIへ移ると、通信方式や形式が変わり、変換ロジックの再設計が必要です。
- 流通BMSはXML形式で、受発注・出荷・請求などの項目を標準化しています。
- 旧来の固定長データは流用できず、既存業務ルールを新形式に反映できるか検証します。
- 移行が遅れた取引先や非対応の中小企業があり、旧・新方式の併用で期間が延びる場合があります。
- 主要取引先の移行状況を早期に聞き取り、全体ロードマップに反映します。
変換ロジックを組み直す作業は、想定より多くの工数がかかることもあります。
納期遅延の典型要因と対策
綿密に計画しても、EDI開発の遅延リスクをゼロにはできません。そこで、典型的な要因を把握し、対策を契約や進捗管理に組み込みます。
主な要因は、マスタデータの整備不足と、現場の例外業務の洗い出し不足です。
マスタデータクレンジングの遅れ
納期遅延で筆頭に挙がるのは、取引先・商品マスタのクレンジング不足です。既存システムに散らばるマスタには、問題が必ずと言っていいほどあります。
たとえば、「株式会社」と「（株）」の混在、同一取引先の重複登録、商品コード体系の不一致などがあります。そのまま移行すると、受発注データを照合できない、請求金額が合わないといった深刻なトラブルを招きます。
- 要件定義の段階で、マスタデータの洗い出しに着手します。
- カットオーバーの4〜6か月前から整備を進めます。
- テスト移行を複数回行い、移行前後の件数と内容の差分を検証します。
整備を後回しにすると、開発が完了してもマスタが整わず、本稼働できない事態になり得ます。
イレギュラー業務の洗い出し不足とスコープクリープ
もう一つの遅延要因は、現場に根付いた例外業務の洗い出し不足です。仕様書にないルールは、開発の終盤や接続テストの段階で表面化します。
- 物流面の例外：数量の一部出荷、返品、複数拠点への分割出荷があります。
- 取引条件：値引きや得意先ごとの個別条件があります。
後から要件を加えると、開発範囲が無秩序に広がるスコープクリープを招き、納期を圧迫します。
要件定義の段階で現場担当者への聞き取りを徹底し、どこまでをシステムで対応し、どこからを手作業に残すかを明確にします。
仕様変更の際は、影響の調査、工数の見積もり、承認の進め方を変更管理ルールとして最初に合意しておきます。そうすれば、口頭の追加が重なって予算や納期を超える事態を防げます。
見積もりの段階で、全体工数の10〜20%程度をバッファとして確保しておくことも、現実的な対策です。
まとめ
ここまで、規模別の期間と工程配分を見てきました。あわせて、取引先テストと並行運用、レガシー移行、遅延要因と対策も確認しました。
開発期間は、クラウド型の小規模版で1〜2か月、パッケージにカスタマイズを加える中規模版で3〜6か月、大規模版で6か月〜1年以上が目安です。
費用は、クラウド型なら初期0〜200万円、月額1〜30万円以上が目安です。一方、オンプレミスやフルスクラッチは、初期300万〜1,000万円以上、年間保守50万〜200万円が目安です。
期間を決めるのは、自社内の開発工数だけでなく、取引先を含めた接続調整でもあります。取引先が多い企業では、その調整に2〜3か月かかることがあります。
ISDN回線の終了に伴い、レガシーEDIからインターネットEDIや流通BMSへの移行が、業界全体で急務になっています。
遅延の主因は、マスタデータのクレンジング遅れと例外業務の確認不足です。対策として、上流の段階でマスタデータを洗い出し、要件定義を徹底します。さらに、全体工数の10〜20%をバッファに設定します。
まず、取引先数と接続方式、現場の例外業務を整理します。そのうえで、複数の開発会社にEDI連携の実績を確認し、見積もりを取ることから始めます。
▼全体ガイドの記事
・EDIシステムの完全ガイド
▼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を創業。