BtoB EC並行稼働と切り替え設計｜期間と判断基準

◆監修・編集責任者　小園 将隆　2026年8月17日

B2B EC-COLUMN

並行稼働とは何か——切り替え設計で決める5項目

BtoB ECの並行稼働と切り替え設計とは、現行の受発注のしくみと新システムを一定期間そろって動かして故障を洗い出し、そのうえで切り替える移行のリスク対策であり、停止可否・EOL/EOS・利用部門の許容度という判断軸で設計を決めます^*1*2。

BtoB ECの並行稼働とは、現行の受発注のしくみと新システムを一定期間そろって動かし、故障を洗い出したうえで切り替える移行のリスク対策です^*2。IPA（独立行政法人情報処理推進機構）の刊行物では、リリース後に潜在バグが顕在化する場合に備えるリスク対策の例として整理されています^*2。

この論点は一部の企業に限った話ではありません。経済産業省が2025年5月に公表した「レガシーシステムモダン化委員会総括レポート」は、IPA「2024年度ソフトウェア動向調査」（2024年12月〜2025年2月実施）をもとに、ユーザー企業の61%（n=516）がレガシーシステムを保有し、大企業では74%（n=402）にのぼると整理しています^*5。刷新に踏み切る母数が大きいぶん、切り替えをどう設計するかは、レガシーを抱える61%の企業に共通する検討事項になります。

切り替え設計で決めるべき項目は、方式・期間・新旧データの同期・判定と切り戻し・体制の5つです。このうち方式選びと期間の決め方は本記事の中心テーマであり、新旧データの同期と判定基準は次章以降で扱います。体制面は、切替期間中の故障対応体制を指しており、定常運用の体制設計とは切り分けて考える必要があります。

BtoB ECには固有の前提があります。受注は止められず、切り替えには取引先が巻き込まれるという点です。

BtoC ECと異なり、締め・請求サイクルや個別の取引条件が絡むため、社内都合だけで切替日を決められません。この前提が、判断軸③・④（後述）の重みを高めています。

切り替え全体の進め方（一斉・段階・並行の3方式の説明、切替日の置き方、取引先への通知、旧システムの停止時期）は、で手順として整理しています。本記事は「どう決めるか」の判断基準に絞って扱います。

一斉切替か並行稼働か——3つの判断軸と決定表

方式そのものの一覧・比較はに既出のため、ここでは繰り返しません。ここで扱うのは「何を見て選ぶか」という選定の基準です。非機能要件全体の合意の進め方はで扱っています。

判断軸①：移行のためのシステム停止が取れるか。IPA非機能要求グレード2018は「システム停止可能日時」（D.1.1.2）を移行性の項目として立てています。そのうえで「並行稼働の有無」（D.1.1.3）では、移行のためのシステム停止が不可の場合に「移行時のリスク軽減を最優先して並行稼働は必要」とし、停止期間を十分に確保できる場合は「並行稼働の必要性は低い」としています^*1。停止時間を確保できないシステムほど、並行稼働の必要性が高まるという判断の順序です。

判断軸②：現行システムのEOL・EOSの期限内で実施可能か。並行稼働は現行システムを稼働させ続ける期間を延ばすため、保守サポートの終了時期を圧迫します^*2。EOL・EOSの期限が近い場合、並行稼働の余地は限られます。

判断軸③：利用部門がどれほど並行稼働を許容できるか。並行稼働では同一オペレーションを新旧両方で実施するため、利用部門の負担が増加します^*2。負担を許容できるかどうかは、事前に利用部門との合意が要ります。

判断軸④（BtoB EC固有）：取引先に二重の運用を強いられるか。受発注のやり取りが取引先とひも付く以上、社内の判断だけでは完結しません。取引先セグメントごとに二重運用の負担を洗い出し、判断軸③と合わせて検討する必要があります。

並行稼働を「代償のない選択」と決めつけないことが重要です。停止時間が確保できないという事情に押されて選ぶ手段であり、選んだ瞬間に利用部門の負担とデータ同期の難易度という代償を引き受けることになります^*2*3。

並行稼働の期間——業務サイクルの一巡を基準にする

並行稼働の期間を決める基準は、「業務サイクルが一巡するか」です。月次の締め・請求まで通してはじめて、普段は表に出ない故障が見えてきます。日次の受注テストだけでは、月末の請求処理に潜む不具合を洗い出せません。

期間は感覚で決めるものではなく、非機能要求として合意する事項です。IPA非機能要求グレードは「システム移行期間」を項目として定義し、レベル4を2年未満、レベル5を2年以上としています^*1。並行稼働の期間も、この移行スケジュール全体の中に位置づけて合意する必要があります。

並行稼働は長くするほど、増えるものがあります。利用部門の二重入力負担、EOL・EOSの期限の圧迫、そしてデータ不整合が蓄積するリスクです^*2*3。期間を安易に延ばすことは、代償を先送りしているにすぎません。

切替日は、期首や繁忙期を避けて置くのが基本です。締め日との関係を含めた切替日の具体的な置き方は、で詳しく扱っています。

新旧データの同期——二重入力・片方向・双方向の使い分け

並行稼働で特に難易度が上がるのは、データ同期です。デジタル庁の「地方公共団体情報システム ガバメントクラウド移行に係る手順書」は、新旧並行稼働の可否と切り替えタイミングを策定するタスクを示しています。

そのうえで、並行稼働では移行元と移行先の環境をまたいでデータの同期が必要となるため「難易度が高くなることを考慮すること」と述べています^*3（原文はオンプレミス環境とガバメントクラウドの間の同期を指しています）。同手順書は自治体向けですが、新旧システムを並行させる際の技術的な課題は業種を問わず共通します。

同期のパターンは、二重入力・片方向同期・双方向同期の3つに整理できます。二重入力は仕組みが単純な一方、件数が増えるほど利用部門の負担が跳ね返ります。

片方向同期は、変更頻度の低いマスタデータに向いています。双方向同期は柔軟ですが、突合の設計を誤ると差異に気づけません。

マスタと受注データでは、扱いを分けて設計します。取引先・商品・価格といったマスタは、片方向同期で新システムへ反映するのが基本です。一方、受注データは動きが速いため、原則としてどちらか一方を正のデータとして扱い、もう一方は参照専用にする設計が現実的です。

突合（コンペア。新旧のデータを照合し、差異の有無を確認する作業）の設計も欠かせません。何を・いつ・どの粒度で照合し、差異が出た場合にどう扱うかを、稼働前に決めておく必要があります。

粒度を明細レベルまで細かくするほど精度は上がりますが、確認にかかる手間も増えます。

移行対象データの棚卸では、コード体系の差異、必須項目の欠損、桁数の差異といった論点を先に潰しておく必要があります。デジタル庁の手順書は、コード値のバリエーション差異・必須データの欠損や誤り・項目桁数の差異を、移行時に洗い出すべき事項として例示しています^*3。

データそのものの移行工程（棚卸・変換設計）はで扱い、定常運用時のシステム間連携はに譲ります。並行稼働中に発生する一時的な同期は、本記事の対象です。

切り替え判定と切り戻しの基準——数値基準を稼働前に決める

誰が判定するかは、あらかじめ決めておく事項です。IPA非機能要求グレードは、移行作業分担の項目で「最終的な移行結果の確認は、レベルに関係なくユーザが実施する」としています^*1。ベンダー任せにせず、利用側が最終確認の責任を持つという前提です。

何を見て判定するかも、数値で先に決めておく必要があります。突合の一致率、未解決の不具合の件数と重大度、利用部門の習熟度が代表的な指標です。当日になって判断基準を作り始めると、現場の空気に流されやすくなります。

故障対応体制とマニュアルの整備も、判定基準と並ぶ準備事項です。IPAのユーザガイドは、試験工程に新システムの運用担当を組み込む、または開発要員を運用担当として一定期間残す方法を挙げています^*2。判定後に慌てて体制を組むのではなく、判定前から整えておく話です。

定常運用の体制設計はで扱い、本記事では切替期間中に限った体制の要点にとどめます。

移行期間中の電子帳簿保存法——改ざん防止措置は必須

移行期間中も、電子取引データの改ざん防止措置は必要です。国税庁の電子帳簿保存法一問一答（電子取引関係）によれば、旧システムから新システムへ電磁的記録を取り込むまでの間は、改ざん防止が担保できない期間です。

そのため、移行期間中も改ざん防止措置を講じる必要があるとされています^*4。並行稼働はこの移行期間そのものを長く保つ選択でもあるため、法令面の論点として避けて通れません。

この要件は「訂正削除の防止に関する事務処理規程の制定・遵守」で満たせます。タイムスタンプを引き継げない場合でも、データ移行時の事務処理規程を定めて守ることで、改ざん防止措置の要件を満たすことができます^*4。

ただし、注意点があります。スキャナ保存データと電子取引データをまとめて移行する場合、事務処理規程による方法は認められません^*4。スキャナ保存にはタイムスタンプの付与が要件となっており、電子取引データとは取扱いが異なるためです。

両方を同時に移行する計画がある場合は、この限定を忘れずに確認してください。

もう一点、システム更改それ自体は猶予の理由になりません。国税庁の一問一答は、令和5年度の税制改正前から要件どおりに保存できていた事業者が、特段の事情なくその後のシステム更改によって検索要件を満たせなくなった場合について、「相当の理由がある」とは認められず、規則第4条第3項の適用はないとしています^*4。事業規模の大幅な変更など事業実態の変化がある場合は別途の判断となりますが、原則としては、検索要件を満たせるかどうかは、並行稼働の期間設計以前に、製品選定の段階で確認しておくべき事項です。

移行前システムでどのように要件を満たしていたかを説明できるよう、取扱説明書等を保存しておくことも望ましいとされています^*4。旧システムを実際にいつまで参照専用として残すかは、の停止時期の論点に譲ります。

まとめ：並行稼働を決める3つの判断軸

本稿では、BtoB ECの並行稼働と切り替えを「どう決めるか」という観点で整理しました。要点を3つに集約すると次の通りです。第一に、並行稼働にするかどうかは複数の判断軸で決まります。移行のためのシステム停止が取れるか、EOL/EOSの期限内か、利用部門と取引先が二重運用を許容できるか、という軸です^*1*2。第二に、期間は「業務サイクルが一巡するか」を基準に、非機能要求として合意する事項です^*1。第三に、並行稼働を選ぶ場合はデータ同期の設計と切り戻しの数値基準を稼働前に固めます。移行期間中も電子帳簿保存法上の改ざん防止措置を維持する必要があります^*3*4。

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

よくある質問——並行稼働と切り替え設計

並行稼働の期間はどれくらいが目安ですか。

一律の月数ではなく、業務サイクルが一巡する長さを基準に、非機能要求として合意します。IPA非機能要求グレードは移行スケジュールをレベル4（2年未満）とレベル5（2年以上）に区分しており、並行稼働の期間もこの合意の枠組みの中で決める事項です^*1。

並行稼働をしないと危険ですか。

並行稼働をしないこと自体が危険というわけではありません。並行稼働はリスク対策の一つであり、段階的リリースや故障対応体制の整備といった別の対策もあります^*2。停止時間が十分確保できるなら、一斉切替でも問題ありません。

並行稼働中は常に二重入力になりますか。

同期方式次第です。片方向同期や双方向同期を設計すれば、二重入力を減らせます。ただし、デジタル庁の手順書が示すとおり、並行稼働ではデータの同期自体の難易度が高くなる点は変わりません^*3。

並行稼働中の受注データも電子帳簿保存法の対象ですか。

対象です。旧システムから新システムへ取り込むまでの移行期間中は改ざん防止が担保できない期間にあたるため、移行期間中も改ざん防止措置が必要です^*4。事務処理規程の制定・遵守で満たせますが、スキャナ保存データと一緒に移行する場合は認められない点に注意してください^*4。

切り戻しの判断は誰がしますか。

最終的な移行結果の確認は、システムの重要度によらずユーザー側が実施します^*1。ベンダー任せにせず、判定の実施者と承認者を稼働前に確定しておくことが前提になります。

1. *1　出典：独立行政法人情報処理推進機構（IPA）技術本部 ソフトウェア高信頼化センター（SEC）「非機能要求グレード2018 改訂情報 ～初版との差異～」（2018年4月）
2. *2　出典：独立行政法人情報処理推進機構（IPA）技術本部 ソフトウェア高信頼化センター（SEC）「SEC BOOKS：システム再構築を成功に導くユーザガイド 第2版」（2018年2月）
3. *3　出典：デジタル庁「地方公共団体情報システム ガバメントクラウド移行に係る手順書【第2.0版】」（令和6年8月）
4. *4　出典：国税庁「電子帳簿保存法一問一答【電子取引関係】」（令和7年6月）
5. *5　出典：経済産業省 商務情報政策局 情報産業課 情報処理基盤産業室「DXの現在地とレガシーシステム脱却に向けて レガシーシステムモダン化委員会総括レポート」（2025年5月28日）