BtoB EC移行のサイト停止時間短縮｜決め方と4方式

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

B2B EC-COLUMN

BtoB EC移行のサイト停止時間とは ― 切替方式より先に止められる時間を決める

BtoB EC移行でサイト停止時間を短縮するには、まず自社の停止許容時間を明確にする必要があります。IPA「非機能要求グレード2018」が定める段階的な基準で言語化し、制約に合う切替方式と当日のDNS・503対応を選びます^*1。

BtoB EC移行のサイト停止（ダウンタイム）とは、旧サイトでの受注受付を止めてから新サイトで受注を再開するまで、取引先が発注できなくなる時間を指します。停止時間は大きく3つの作業に分かれます。事前に移していないデータを移す「データ移行」、システムの向き先を新環境へ切り替える「切替」、そして新環境が正常か確認する「再開判定」の3要素です。

結論：短縮策を検討する前に停止許容時間を確定する

停止時間を短くする技術的な打ち手は複数存在しますが、どれを選ぶべきかは自社が「何分・何時間なら止めてよいか」を決めていない限り判断できません。得意先の発注締め時間や月末月初の請求処理など、業務側の制約を先に洗い出す作業が、切替方式の選定より前に必要です。

非機能要求は「移行性」という区分で体系化されている

停止時間の設計は、独立行政法人情報処理推進機構（IPA）が2018年4月に公表した「非機能要求グレード2018」で体系立てられています^*1。このグレードは非機能要求を6大項目・35中項目・118小項目・238メトリクスに整理しています^*1。移行に関する要求は、6つの大項目のひとつである「移行性」にまとめられています^*1。

移行性はさらに、移行時期・移行方式・移行対象（機器）・移行対象（データ）・移行計画という5つの中項目に分かれます^*1。なお本事業は2018年度で終了しており、以後の改訂はありません^*1。そのため本稿の数値は「2018年版の基準」として扱います。

停止許容時間の決め方 ― IPA非機能要求グレード2018の3項目に自社を当てる

停止許容時間を決めるとは、自社の業務制約をIPAが定義する段階（レベル）に当てはめ、目標となる数値へ翻訳する作業です。ベンダーとの合意も、この段階を共有できて初めて成立します。

「システム停止可能日時」の6段階で自社の制約を言語化する

IPAのD.1.1.2「システム停止可能日時」は、移行のためにシステムを止めてよい期間を6段階（レベル0〜5）で定義しています^*1。レベル0は制約無し、レベル1は5日以上、レベル2は5日未満です^*1。

レベル3は1日（計画停止日を利用）、レベル4は利用の少ない時間帯（夜間など）、レベル5は移行のための停止不可という区分です^*1。レベルが高いほど、移行計画に影響する制約が大きいことを示します^*1。自社がどのレベルに該当するかを最初に確認する作業が必要です。

目標値へ翻訳する ― サービス切替時間とRTO

停止可能日時のレベルが決まったら、具体的な目標値へ翻訳します。IPAのA.1.2.2「サービス切替時間」は、対策を施すことで業務再開までに要する時間を指します^*1。区分は24時間以上・24時間未満・2時間未満・60分未満・10分未満・60秒未満の6段階です^*1。

RTO（目標復旧時間、A.1.3.2）はサービス切替時間とは別の指標です^*1。業務の継続対策していない場合の障害復旧時間を示し、1営業日以上から2時間以内までの5段階で定義されています^*1。サービス切替時間とRTOは意味が異なるため、混同せず併記して合意する必要があります。

稼働率から逆算する ― 24時間稼働と日中稼働で基準が変わる

IPAのA.1.5.1「稼働率」は、24時間365日稼働を前提とした換算値を示しています^*1。99.9%で年間8.76時間、99.99%で年間52.6分、99.999%で年間5.26分の中断が許容範囲になります^*1。

一方、1日8時間・週5日稼働のシステムでは条件が変わります。IPAは同項目で、この稼働形態におけるサービス切替時間と稼働率の関係を、週に1時間なら97.5%、月に1時間なら99.4%、年に1時間なら99.95%と整理しています^*1。自社システムの稼働形態に合わせて、どちらの前提で稼働率を語るかを明確にすることが欠かせません。

止められる窓を業務スケジュールから逆算する

IPAは特定日の運用時間（A.1.1.2）や計画停止の有無（A.1.1.3）も項目として定義しています^*1。休日や月末月初など通常と異なるスケジュールの日を個別に扱うよう求めています^*1。

BtoB ECでは、得意先の発注締め時間・棚卸・請求締めのタイミングが、停止してよい窓を実質的に決めます。これらの業務日程を洗い出したうえで、IPAのレベルに当てはめる手順が現実的です。

自社の停止許容時間が見えてくると、「なぜこの時間で切り替えられないのか」という疑問が具体的に生まれます。無料相談で要件を整理すると、この後の切替方式の選定にも判断軸を持ち込めます。

停止時間を短くする4つの切替方式

停止許容時間が決まったら、その制約に収まる切替方式を選びます。BtoB EC移行の切替方式は、大きく一括切替・段階切替・並行稼働・旧サイト参照残置の4つに整理できます。

4方式の比較 ― 停止時間・難易度・向く条件

段階の粒度はIPAの展開ステップ数で決める

段階切替を選ぶ場合、何段階に分けるかはIPAの2つの指標で規定できます。D.2.1.1「拠点展開ステップ数」は一斉展開・5段階未満・10段階未満・20段階未満・20段階以上の区分です^*1。

D.2.1.2「業務展開ステップ数」は全業務一斉切り替え・4段階未満・6段階未満・10段階未満・10段階以上の区分です^*1。IPAは「拠点展開時のリスクによっては難易度が逆転し、一斉展開の難易度が高くなる場合もある」と注記しています^*1。段階数を増やしても、安全性が比例して高まるとは限りません。

並行稼働を選ぶなら期間と場所を先に規定する

並行稼働を選ぶ場合、IPAのD.1.1.3「並行稼働の有無」はレベル1（有り）を選んだ時点で、その期間と場所等を規定することを求めています^*1。期間を定めずに並行稼働を始めると、旧サイトの停止時期が決まらないまま長期化する事態を招きます。

停止中の作業量を減らすデータ移行の設計

どの方式を選んでも、停止窓に載せる作業量を減らせば停止時間は短くなります。IPAのD.4.1.1「移行データ量」は移行対象無し・1TB未満・1PB未満・1PB以上でデータ量を区分し、D.4.1.2「移行データ形式」は移行先と形式が同一か異なるかを区分しています^*1。形式が異なる場合は変換処理が必要になるため、停止窓に載せる作業が膨らみます。

そのため、形式変換や大量データの移行は事前に済ませ、停止中は差分データの同期だけに絞る設計が有効です。データ移行の手順そのものは、受発注システムのデータ移行を扱う別記事で詳しく解説しています。

移行当日に停止時間を削る具体策 ― DNS・503・リハーサル

切替方式を決めたら、当日の作業そのものを短くする打ち手に移ります。DNSの設定・停止中のHTTP応答・リハーサルの3か所に、具体的な削減余地があります。

DNSのTTLを事前に短くしておく

DNS（ドメイン名を管理する仕組み）のTTL（Time To Live、キャッシュの有効期間）は、RFC 1035の3.2.1節で定義されています^*4。「リソースレコードをキャッシュしてよい時間間隔を示す32ビットの符号付き整数」という定義です^*4。

値を0にすると、進行中の処理にのみ使われキャッシュされません^*4。切替の数日前からTTLを短く設定しておけば、古い向き先を参照し続ける利用者を減らせます。

停止中は503とretry-afterで再開見込みを伝える

サイトの一時停止時の対応は、Google検索セントラルの公式ドキュメントが案内しています^*2。停止中に用意するのは、503のHTTPレスポンスステータスコードを返す情報提供ページです^*2。あわせてretry-afterヘッダーで、再開見込みの日時または期間を示すことが推奨されています^*2。

一方でrobots.txtファイルへのクロールは、継続して許可しておく必要があります。robots.txt自体には503を返さないよう、同ドキュメントに明記されています^*2。

長期化する見込みなら200のプレースホルダーへ切り替える

同じGoogle公式ドキュメントは、サイトの完全な閉鎖は長くても数日程度にとどめるべきものとしています^*2。停止が1〜2日を超える見込みになった段階では、200のステータスコードを返す簡易な代替ページへ切り替えます^*2。

こうしておけば、利用者が検索結果からサイトを見つけられる状態を保てます。数週間にわたる閉鎖はインデックスに悪影響を及ぼすとされているため^*2、長期化が見えた時点で早めに切り替える判断が必要です。

URLが変わる移行ならリダイレクトの設計も停止時間に影響する

URLが変わる移行では、Google公式ドキュメントがサーバー側の恒久的なリダイレクト（301・308）を推奨しています^*3。Googlebotが追跡できるリダイレクトのチェーンは10ホップまでで、理想は3以下、5未満に抑えることが望ましいとされています^*3。

リダイレクトを維持する期間について、同ドキュメントは「一般的に最低1年間」という目安を示しています^*3。新しいURLへシグナルを引き継ぐために要する期間という位置づけです^*3。URLを変更する移行では、旧サイトのSEO評価を新サイトへ引き継ぐ設計もあわせて必要になります。

リハーサルで手順時間を実測する

IPAのD.5.2.1「リハーサル範囲」は5段階で定義されています^*1。リハーサル無し・主要な正常ケースのみ・全ての正常ケースなど、異常時の切り戻しまで含め5段階に区分されます^*1。D.5.2.3「リハーサル回数」は、リハーサル無しから5回以上までを規定する項目です^*1。回数を重ねるほど各手順の実測値が蓄積されるため、当日の見積もり精度を上げる手立てになります。

EDI連携先がいる場合はD.5.2.4「外部連携リハーサルの有無」を計画し、新旧の接続仕様を事前に確認する必要があります^*1。業界標準のEDIを使う卸売業では、この外部連携リハーサルの設計が特に重要です。

停止中も取引を止めない設計

サイトを止めても、取引先との商売そのものは止められません。停止設計は、サイトの停止時間だけでなく、取引の継続性まで含めて検討します。

受付の代替運用と得意先への事前告知

停止中に発注を受け付ける代替手段（電話・FAX・メールなど）と、告知のタイミングをあらかじめ決めておきます。告知には、停止する日時・代替受付の方法・再開見込み時刻の3点を含め、誰がいつ通知するかまで決めておくと、当日の混乱を避けられます。

停止中も電子取引データの参照手段を確保する

電子帳簿保存法第2条第5号は、電子取引を定義しています^*5。「取引情報（注文書、契約書、送り状、領収書、見積書その他これらに準ずる書類に通常記載される事項）の授受を電磁的方式により行う取引」という定義です^*5。

BtoB ECで授受する注文書・見積書のデータはこの電子取引に該当します。旧システムの参照を止める期間があっても、保存・提示に必要な参照手段は別途確保しておく必要があります。

保存要件の詳細（検索機能の確保等）は国税庁の一問一答等で個別に確認したうえで対応してください。

切り戻しの判断基準と権限を事前に合意する

IPAのD.5.3.1「トラブル対処」は、規定無し・対応体制のみ規定有り・対応体制と対応プランの規定有りの3段階で定義しています^*1。D.5.1.1「移行作業分担」は全てユーザ・ユーザとベンダーの共同・全てベンダーの3区分です^*1。

IPAは「最終的な移行結果の確認は、レベルに関係なくユーザが実施する」と明記しています^*1。つまり作業をベンダーに委託していても、切り戻すかどうかの最終判断は自社側の責任範囲です。誰が・どの時点で・何を基準に切り戻しを判断するかを、当日より前に合意しておく必要があります。

再開判定の合格条件を決めておく

再開判定とは、新環境が受注を受け付けられる状態かを確認し、実際に受付を再開すると宣言する工程です。会員データや取引先データの疎通確認、文字化けなどの表示崩れの確認は、再開判定の代表的な合格条件になります。会員データの検証手順や文字化けの防ぎ方は、それぞれ別記事で扱っています。

停止時間短縮チェックリスト ― そのまま使える手順

ここまでの内容を、移行前・当日・再開後の3つの時期に分けたチェックリストとして整理します。

1か月前〜前日に済ませておくこと

1. 停止許容時間をIPAのレベルに当てはめ、ベンダーと合意します。
2. DNSのTTLを短く設定します。
3. リハーサルし、各手順の所要時間を実測します。
4. 得意先への告知内容とタイミングを決めます。
5. 切り戻しの判断基準と権限を承認しておきます。

当日に確認すること

1. 停止中は503とretry-afterを返し、robots.txtは503にしません。
2. 作業の順序と各作業の開始・終了予定時刻を関係者間で共有します。
3. 中止・切り戻しを判断するタイムボックス（判断すべき期限）を守ります。

再開後に確認すること

1. URLを変更した場合はリダイレクトの動作を確認します。
2. 検索エンジンのインデックス状況を確認します。
3. 受発注データの疎通と旧システムのデータ参照を確認します。

まとめ：停止時間短縮は要求定義から始まる

本稿では、BtoB EC移行のサイト停止時間を短縮する考え方を、技術的な打ち手ではなく要求定義から整理しました。要点を3つに集約すると、第一に、IPA非機能要求グレード2018のレベルで自社の停止許容時間を言語化する必要があるということです。

第二に、切替方式は一括・段階・並行稼働・参照残置の4方式から、決めた許容時間に合うものを選ぶという順序になります。第三に、当日はDNSのTTL短縮・503とretry-after・リハーサルによる実測という3つの打ち手で、停止時間を実際に削れるということです。

停止許容時間の決め方は受発注システム全体のデータ移行設計とも関係するため、あわせて確認しておくと計画の精度が上がります。

---

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

よくある質問

BtoB EC移行のサイト停止は何時間まで許容されますか。

一律の目安はなく、自社の業務制約によって決まります。IPA非機能要求グレード2018のD.1.1.2「システム停止可能日時」はレベル0（制約無し）からレベル5（停止不可）まで6段階で定義しています^*1。まずこのレベルのどこに自社が当てはまるかを確認する必要があります。

サイト停止をゼロにすることはできますか。

並行稼働や段階切替を選べば停止時間を短くできますが、その分IPAが定める並行稼働の期間・場所の規定や、展開ステップ数の管理といった運用負荷が増えます^*1。停止時間の短縮とコストは見合いの関係にあり、自社の許容時間に応じて方式を選ぶ考え方が現実的です。

停止中にサイトはどのHTTPステータスを返すべきですか。

Google公式ドキュメントは、短期の停止では503のHTTPレスポンスステータスコードとretry-afterヘッダーを使うよう案内しています^*2。あわせてrobots.txt自体には503を返さないことも明記されています^*2。

サイトを停止すると検索順位は下がりますか。

数日以内の短期停止であれば、503とretry-afterで対応する限り大きな影響は避けられるとされています^*2。一方でGoogle公式は、数週間にわたる完全な閉鎖には悪影響があるとしています^*2。長期化する見込みが立った時点で200のプレースホルダーページへ切り替える対応が案内されています^*2。

切り戻しはいつ判断すればよいですか。

当日に判断するのではなく、事前にタイムボックス（判断すべき期限）と判断権限を合意しておく方法が有効です。IPAは、移行結果の最終確認はレベルに関係なくユーザが実施すると明記しており^*1、切り戻しの最終判断も自社側の責任範囲になります。

1. *1　出典：独立行政法人情報処理推進機構（IPA）「非機能要求グレード2018」（2018年4月）。本稿の項目番号・レベル区分は配布一式（zip）収録の「システム基盤の非機能要求に関する項目一覧」（04_項目一覧.pdf）により、体系の項目数（6大項目・35中項目・118小項目・238メトリクス）は同ページ掲載の「非機能要求グレード」実践セミナー資料（000066192.pdf）p.18による。配布ページ：https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html
2. *2　出典：Google「Temporarily pause or disable a website」Google Search Central（2025年12月10日更新、https://developers.google.com/search/docs/crawling-indexing/pause-online-business）
3. *3　出典：Google「How to move a site」Google Search Central（2026年8月20日更新、https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes）
4. *4　出典：P. Mockapetris「RFC 1035 DOMAIN NAMES – IMPLEMENTATION AND SPECIFICATION」IETF（1987年11月、https://www.rfc-editor.org/rfc/rfc1035.txt）
5. *5　出典：e-Gov法令検索「電子計算機を使用して作成する国税関係帳簿書類の保存方法等の特例に関する法律」第2条第5号（1998年3月31日公布、https://laws.e-gov.go.jp/law/410AC0000000025）