Web受発注システムの繁忙期対策:詰まる場所の見極めと、システム・運用の手当ての順番

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

B2B EC-COLUMN

Web受発注システムの繁忙期に詰まるのは受付・受注後の作業・顧客対応のどれか

受注の確認が追いつかない日に限って注文画面が重くなり、取引先からの電話も鳴りやまない。
繁忙期の困りごとはこうして重なって見えるため、システムの増強と人の手配のどちらから手を付けるか決めにくくなります。
詰まりを「受付」「受注後の作業」「顧客対応」の三つに分けると、手当ての順番が見えてきます。
受付の詰まりには、過負荷時の振る舞いと復旧手順を繁忙期前に試しておきます。
受注後の作業と顧客対応の詰まりには、締め時刻・例外注文の扱い・連絡役を先に決めます。
自社で構成を管理しているか、提供元のサービスを使っているかで打てる手が違うため、確認先も分けて考えます。

症状から見分ける3つの場所

受付は、取引先が注文画面で入力して送信する段階、あるいは取引先のシステムから連携で注文データが届く段階です。
ここが詰まると、画面の表示や送信が遅くなる、送信時にエラーが出る、同じ注文が二重に届くといった症状が出ます。

受注後の作業は、届いた注文を自社の担当者が確認し、在庫を引き当て、出荷を指示し、請求までつなげる段階です。
システムは動いていても、確認待ちの注文が積み上がる、当日の出荷に回せない注文が増えるといった形で詰まりが表れます。

顧客対応は、取引先からの問い合わせ、注文内容の変更、取消を受ける段階です。
「注文は届いているか」「いつ出荷されるか」という電話やメールが増え、その対応に担当者の手が取られます。

やっかいなのは、この三つが連鎖して同時に見えることです。
たとえば受付の画面が重くなると、取引先は送信できたか分からないまま再送し、二重注文が生まれます。
受注後の確認では重複を見つけて取り消す作業が増え、取引先からは「届いているか」の問い合わせが来ます。
担当者の体感では三か所すべてが詰まっていますが、起点は受付です。
逆に、受付は問題なく流れているのに確認作業が追いつかず、出荷遅れの問い合わせが増えている場合は、起点は受注後の作業にあります。
手当ての順番を決めるうえで大事なのは、困りごとが最初にどこで生まれ、どこへ波及したかを分けて見ることです。

自社の記録で確かめる指標

起点を見分けるには、場所ごとに見る記録を決めておきます。
受付なら画面やデータ連携の応答時間とエラーの発生割合、受注後の作業なら時間帯ごとの未処理件数とその日の処理が終わった時刻、顧客対応なら問い合わせの件数と内容です。
Google Cloudの障害復旧試験の指針でも、試験中に遅延・エラー率・処理量を観測し、ログやアラートが期待どおりに出るかを確かめることが挙げられています²。

受付の負荷を測るときは、注文の件数だけを見ないことにも意味があります。
GoogleのSRE本は、容量を要求の数ではなく、CPUやメモリといった実際に使える資源で測るほうがよいとし、接続を維持し続けることやバッチ処理の集中も容量を消費すると説明しています¹。

受発注システムに置き換えると、注文の件数が前年と変わらないのに画面が重い日は、夜間に回していた在庫の同期や取引先からの一括取込が、日中の注文と重なっていないかを疑う手掛かりになります。
ただしSRE本はGoogle社内の大規模サービスを前提にした資料なので、ここで借りているのは「件数ではなく資源の使われ方を見る」という考え方までです。

これらの記録が手元にない場合、前年の繁忙期を振り返って起点を特定することはできません。
その場合は、今期の繁忙期から応答時間・未処理件数・問い合わせ件数を日ごと、できれば時間帯ごとに残し始めることが、次の判断の材料になります。
問い合わせは件数だけでなく、「届いているか」「いつ出荷か」「変更したい」のどれだったかを分けて残すと、どの場所の詰まりが問い合わせを生んだかを後からたどれます。

場所別に、最初に手を打つのはシステムか運用か

受付が詰まる場合

起点が分かったら、場所ごとに先に手当てする側を決めます。
全体の対応を一覧にすると次のようになります。

起点が受付にあるなら、先に手を打つのはシステム側です。
画面が送信を受け付けられない状態では、人をどれだけ増やしても注文そのものが入ってこないからです。

SRE本は、過負荷のときに全体を止めるのではなく、利用者ごとに上限を設けて、問題を起こしている利用者にだけエラーを返し、他の利用者への影響を避ける設計を紹介しています¹。
さらに、重要度の低い要求から断る、簡略化した応答を返すといった、段階的に受付を絞るやり方が全面停止より望ましいとしています¹。

受発注システムに当てはめると、たとえば特定の取引先が大量の注文データを一括で送ってきたときに、その取り込みだけを順番待ちにして、他の取引先の画面からの注文は通す、という考え方になります。
過去注文の検索や帳票の出力など、注文の送信より急ぎでない機能を混雑時に後回しにする設計も同じ発想です。
どこまで実現できるかはシステムの作りによるため、まずは自社のシステムが混雑時にどう振る舞うのか、全体が遅くなるのか、一部の機能だけを止められるのかを知ることが出発点になります。

データ連携の再試行も見落とせない点です。
取引先のシステムが送信に失敗して自動で何度も送り直すと、混雑しているところへさらに負荷が上乗せされます。
SRE本は、再試行を行う場所を限り、要求ごとの回数とシステム全体での割合に上限を設けて、再試行が連鎖しないようにする考え方を示しています¹。
連携の取り決めの中で、失敗時にどこまで、どれくらい間を空けて送り直すかを取引先と確認しておくと、負荷の上乗せと二重注文の両方を抑える手当てになります。

受注後の作業が詰まる場合

起点が受注後の作業にある場合は、運用側を先に手当てします。
受付が問題なく流れていても、届いた注文を確認する人の手が追いつかなければ、画面を速くしても未処理の注文がより早く積み上がるだけだからです。

ここで効くのは、いつまでに届いた注文をその日のうちに処理するかという締め時刻、その日に受けられる量の目安、特急や数量変更といった例外注文を誰がどの条件で受けるかの取り決めです。
具体的な決め方は後の節で扱います。
取り決めが固まり、確認作業のどこに時間がかかっているかが記録から見えてきたら、そこで初めて確認画面の改善や作業の自動化が検討の対象になります。

問い合わせ・変更・取消が詰まる場合

問い合わせ・変更・取消が詰まっている場合は、問い合わせの中身で起点が変わります。
「注文が届いているか」という確認が多いなら、受付の遅れや、受付が完了したことの知らせ方に原因があり、受付側の手当てが要ります。
「いつ出荷されるか」が多いなら、受注後の作業の遅れが表に出ている状態です。
「変更したい」「取り消したい」が多いなら、変更・取消をいつまで、どの方法で受けるかが決まっていないことが詰まりの元になっています。

後の二つは運用側の手当てが先です。
出荷の遅れが原因なら受注後の作業の取り決めを、変更・取消が原因なら受付期限と受ける窓口を決めることで、問い合わせそのものが生まれにくくなります。

自前運用と提供元サービス利用での違い

手当ての順番は同じでも、打てる手は運用の形で変わります。
自社でサーバーやクラウドの構成を管理している場合は、混雑時の振る舞いを設定で変えたり、事前に試験したり、繁忙期に合わせて資源を増やしたりできます。
提供元のサービスを使っている場合、そうした手段の多くは提供元の側にあり、自社にできるのは契約や規約の範囲を確認し、繁忙期の見込みを伝え、障害時の連絡経路を押さえることです。
運用側の手当て、つまり締め時刻や例外注文の取り決めと連絡役の配置は、どちらの形でも自社で決められます。

なお、ここで示した順番は、詰まりの起点から逆算した整理であり、システム側と運用側のどちらの対策の効果が大きいかを測った結果ではありません。
また、過負荷時の設計の考え方を借りたSRE本と、次の節で使う障害復旧試験の指針は、どちらもGoogle系の資料で、大規模なクラウド上のシステムを前提にしています。
二つの資料から言えるのは、受付を段階的に絞る設計と、復旧や切替を事前に試して記録する運用は併用できるということまでです。
中小規模の受発注システムでどれだけ効くかは、自社の記録で確かめていくことになります。

▼ 図の内容を文字で読む

1. 受付の画面が重くなる
2. 送信できたか分からず取引先が再送し二重注文が生まれる
3. 受注後の確認で重複を見つけて取り消す作業が増える
4. 取引先から「届いているか」の問い合わせが来る

繁忙期前にシステムで確認・試験しておくこと

復旧目標と切替・巻き戻しの確認

システム側を先に手当てすると決めたら、最初に決めるのは「止まったときにどこまで許せるか」です。
これを表すのがRTOとRPOで、RTO（目標復旧時間）は止まってから復旧するまでに許せる時間、RPO（目標復旧時点）は障害時にどの時点までのデータを取り戻せればよいかを指します。

受発注システムでは、RPOは「失われてもよい注文はどこまでか」という問いになります。
直近の注文が失われれば、取引先に再入力を頼むか、自社で控えから入力し直す必要が出ます。
繁忙期は同じ時間に届く注文が平常時より多いので、平常時と同じ復旧時点のままでは、取り戻せない注文の件数が増えます。
RTOについても、止まっている間にどの方法で注文を受けるのか、電話やメールで受けるなら誰が控えを取り、復旧後に誰が登録するのかまで決めておくと、目標が実際の動きにつながります。

Google Cloudの指針は、リージョンの切替、リリースの巻き戻し、バックアップからの復元を含む障害復旧の試験を定期的に行い、RTOとRPOが守れるかを検証するよう勧めています²。
試験には本番に近い検証環境を使い、本番環境で試す場合は監視と手動で元に戻す手段を用意しておくことも求めています²。

繁忙期の前に特に確かめておきたいのは、直前に入れた改修を元に戻す手順と、バックアップから注文データを戻す手順です。
繁忙期の直前は、取引先の要望に合わせた改修が入りやすい時期でもあります。
改修後に不具合が出たとき、どの手順で元の状態に戻し、戻すまでの間に届いた注文をどう扱うかが決まっていれば、障害の時間を短く抑える助けになります。
この指針はGoogle Cloud上で自社が構成を管理するシステムを対象にしているため、そのまま使えるのは自前運用の場合です。

過負荷時の挙動の確認

障害の試験と並べて確かめたいのが、注文が集中したときのシステムの振る舞いです。
Google Cloudの指針は、障害の試験と併せて負荷試験を取り入れ、トラフィックが増えた条件の下でも試すよう勧めています²。
ただし負荷試験の進め方そのものは詳しく扱っていないため、何をどう試すかは自社のシステムと取引の形に合わせて組み立てることになります。

どの程度の余裕を見込むかについて、SRE本は、バックエンドは割り当てられた容量を大きく上回るトラフィックを受けても、大きな遅延やクラッシュを起こさずに処理できるべきだとしています¹。
これも大規模サービスの設計上の目安なので、自社の試験の合格基準としてそのまま使うより、想定を超えたときにどう振る舞うかを見るという観点を借りるのが現実的です。

試験で見るのは、速く処理できるかどうかより、想定を超えたときの崩れ方です。
全体が少しずつ遅くなるのか、ある時点で一斉にエラーになるのか、負荷が下がった後に自然に元へ戻るのか、それとも再起動が必要なのか。
受発注システムでは、混雑の中で送信された注文が二重に登録されないか、送信がエラーになった注文が取引先の画面でどう表示されるかも確かめておきたい点です。
取引先が「送れていない」と判断して再送すれば、受注後の確認作業に重複の確認が加わるからです。

提供元サービス利用時に確認する項目

提供元のサービスを使っている場合、ここまでの試験を自社の判断だけで行うことはできません。
負荷を掛ける試験は提供元の他の利用者にも影響しうるため、行えるかどうか、行えるならどの範囲かは、提供元の許可と規約に従います。
代わりに、契約書・利用規約・提供元への問い合わせで、次の点を繁忙期の前に確かめておきます。

<ul><li>同時に処理できる注文や利用者の上限、データ取込の量の制限</li><li>上限を超えたときに画面や連携がどう振る舞うか</li><li>繁忙期と重なる保守作業や停止の予定</li><li>障害時に提供元から連絡が来る方法と、自社から問い合わせる窓口</li><li>障害時にどの時点までの注文データを戻せるか</li><li>自社や取引先が負荷試験を行ってよいか</li></ul>

これらは提供元ごとに条件が違い、一般的な値を示せるものではありません。
大事なのは、受け取った答えを自社の繁忙期の見込みと並べることです。
上限が見込みに近いなら、受付が詰まる前提で、次の節で扱う締め時刻や受注量の目安を余裕を持たせて決めておく判断につながります。

▼ 図の内容を文字で読む

• 「注文が届いているか」が多い
  • 受付の遅れ、または受付完了の知らせ方に原因がある
  • 受付側の手当てが要る
• 「いつ出荷されるか」が多い
  • 受注後の作業の遅れが表に出ている
  • 受注後の作業の取り決めを先に手当てする
• 「変更したい」「取り消したい」が多い
  • 変更・取消をいつまで、どの方法で受けるかが決まっていない
  • 受付期限と受ける窓口を決める

注文集中時の締め時刻・例外注文・変更取消の決め方

締め時刻と受注上限

運用側の手当ては、締め時刻を決めることから始めます。
締め時刻とは、その時刻までに届いた注文をその日の出荷や処理に回し、以降の注文は翌営業日に回すという区切りです。
受注後の作業が詰まる原因の一つは、どこまでが今日の仕事かが曖昧なまま、注文が流れ込み続けることにあります。

繁忙期に締め時刻を前倒しするかどうかは、受注後の作業にかかる時間から逆算して考えます。
確認・在庫引当・出荷指示までに平常時より時間がかかるなら、出荷の締めに間に合うよう受注の締めを早める必要が出てきます。
前年の記録で、未処理件数が積み上がり始めた時間帯や、その日の処理が終わった時刻を見ると、どこで区切ればよいかの手掛かりになります。

締め時刻と組み合わせて考えたいのが、その日に受けられる量の目安です。
出荷能力や確認する人数から、無理なく処理できる量の見当を付けておくと、それを超えそうな日に何をするかを先に決められます。
翌日に回す、取引先に分納を相談する、応援の人を入れるなど、超えたときの動き方まで決めておくことが、目安を設ける意味です。
ここでの締め時刻や目安は、効果を測った基準ではなく、受注後の作業を止めないための取り決めとしての提案です。

例外注文の受け方

繁忙期に受注後の作業を乱しやすいのが、特急の依頼、数量の変更、取消といった例外注文です。
平常時なら担当者がその都度判断して対応できても、注文が集中する時期には一件ごとの判断が積み重なり、通常の注文の処理が後回しになります。

そこで、例外の種類ごとに「受けられる条件」「判断する人」「受けたときに誰へ知らせるか」を決めておきます。
特急なら、在庫があり出荷枠に余裕がある場合に限って受け、判断は出荷の責任者が行う、といった形です。
数量変更と取消は、出荷指示を出す前か後かで扱いを分けると判断がぶれにくくなります。
出荷指示の前なら注文の修正で済みますが、指示の後は倉庫や配送への連絡と取り消しが必要になり、作業が一段増えるからです。

変更・取消を受ける方法を一つにまとめておくことも、受注後の作業を軽くします。
電話で受けた変更がシステムに反映されないまま出荷される、といった食い違いは、受ける窓口が複数あるときに起きやすくなります。
システムの画面で変更を受けられるならそこへ寄せ、電話やメールで受ける場合は、誰がシステムへ反映するかを決めておきます。

取引先への事前周知

締め時刻や例外の扱いを変えるなら、繁忙期に入る前に取引先へ知らせます。
発注する側にとっては、締め時刻が早まったことを知らずに注文すれば、予定していた日に品物が届かないことになります。
その後の問い合わせが受注側の顧客対応を詰まらせるので、周知は取引先への配慮であると同時に、自社の詰まりを防ぐ手当てでもあります。

知らせる内容は、いつからいつまで適用するか、何が変わるか、例外を頼みたいときはどこへ連絡するか、の三点に絞ると伝わりやすくなります。
知らせる手段は、受発注システムのお知らせ欄、メール、取引先の担当者への連絡など、相手が普段見ているところを選びます。
繁忙期に入る直前にもう一度知らせると、見落としを減らせます。

締め時刻の前倒しが取引先の業務に大きく響く場合は、一方的に通知するより、事情を説明して相談する形をとるほうが関係を保ちやすくなります。
相手の発注の締めと自社の受注の締めの間にどれだけ余裕があるかは、相手に聞かなければ分からないからです。

取引適正化の法令を確認する場面

取引のルールを変えるときに頭に置いておきたいのが、2026年から施行された取適法です。
中小企業庁の解説によると、下請法が改正されて中小受託取引適正化法（取適法）となり、協議に応じない一方的な価格の決定や、手形による支払い等、振込手数料を受託側に負担させることが禁止されました⁴。

この法律が自社の受注に関係するかどうかは、取引の形態によって変わります⁴。
一般的な商品の売買が対象になるか、注文内容の変更ややり直しをどう扱うかといった細かな点は、取引の中身と事業者の規模を照らし合わせなければ判断できません。
また、注文を受ける側だからといって常に保護される側とは限らず、繁忙期に配送や加工を外部へ頼む場面では、自社が頼む側に回ることもありえます。

繁忙期の対応で確認が必要になりやすいのは、締め時刻の変更や受注量の調整に合わせて、価格や支払いの条件にも手を入れる場面です。
特急の料金を新たに設ける、繁忙期だけ支払いの条件を変えるといった判断をする前に、公正取引委員会や中小企業庁の資料、相談窓口で、自社の取引が対象になるか、どの点に注意すべきかを確かめておくと安心です。

▼ 図の内容を文字で読む

• 自社で構成を管理している
  • 混雑時の振る舞いを設定で変える
  • 事前に試験する
  • 繁忙期に合わせて資源を増やす
• 提供元のサービスを使っている
  • 契約や規約の範囲を確認する
  • 繁忙期の見込みを伝える
  • 障害時の連絡経路を押さえる
• どちらの形でも自社で決める
  • 締め時刻や例外注文の取り決め
  • 連絡役の配置

繁忙期中の監視と、問題が起きたときの連絡・動き方

期間中に見る指標

繁忙期に入ったら、事前に決めた指標を、詰まりの起点を早く見つけるために使います。
見る項目は最初の節で挙げたものと同じで、受付の応答時間とエラー、受注後の未処理件数、問い合わせの件数と種類です。
違うのは、後で振り返るための記録としてではなく、その日のうちに手を打つための合図として見る点です。

合図として使うには、いつ誰が見るかと、どうなったら動くかを決めておきます。
たとえば未処理件数なら、締め時刻の前に一度確認し、その時点で積み残しが目安を超えていれば応援を頼む、といった形です。
受付の応答時間やエラーは、人が画面を見張り続けるより、異常時に知らせが届く仕組みを使うほうが見落としを減らせます。
Google Cloudの指針は、重要な出来事でログとアラートが実際に発火するかを確かめるよう勧めています²。
知らせの仕組みがあっても、繁忙期の前に一度鳴らしてみて、誰の手元に届くかを確かめておかなければ、いざというときに働くかは分かりません。

提供元のサービスを使っている場合は、提供元が障害情報を出す場所を担当者が把握しておくことも監視の一部です。
自社の画面だけが遅いのか、提供元のサービス全体に障害が起きているのかによって、取引先への知らせ方も、自社でできることも変わるからです。

連絡役と取引先への知らせ方

問題が起きたときに混乱を大きくするのは、誰が判断し、誰が誰へ知らせるかが決まっていないことです。
繁忙期の前に、少なくとも次の役割を割り当てておきます。

<ul><li>状況を把握して、受付を絞る・締め時刻を早めるといった判断をする人</li><li>提供元や社内のシステム担当へ連絡する人</li><li>取引先へ状況と見通しを知らせる人</li><li>止まっている間に電話やメールで受けた注文の控えを取り、復旧後に登録する人</li></ul>

担当が一人しかいない場合でも、役割を分けて書き出すことには意味があります。
一人で全部を担うと、システムの復旧に気を取られて取引先への連絡が遅れがちです。
役割を並べておけば、手が回らないものを誰に頼むか、あるいはどれを先に済ませるかを事前に決められます。
取引先へのお知らせの文面を、受付が止まった場合、出荷が遅れる場合と場面ごとに用意しておくと、障害の最中に一から文章を考える手間が省けます。

取引先への知らせでは、何が起きているか、注文はどう扱われるか（再送が必要か、不要か）、次にいつ連絡するか、を伝えます。
なかでも再送の要否をはっきり書くことが、二重注文とその後の問い合わせを防ぐ手当てになります。
状況がまだ分からない段階でも、次の連絡の時刻を約束して知らせておけば、取引先が問い合わせをしてくるのを待つだけの状態を減らせます。

連絡体制を整えるときの参照先として、IPA（情報処理推進機構）が2026年に公開した「中小企業の情報セキュリティ対策ガイドライン」第4.0版には、付録として「中小企業のためのセキュリティインシデント対応の手引き」と説明資料が用意されています³。
この手引きは情報セキュリティの事故への対応を扱う資料で、繁忙期の遅延や停止をそのまま対象にしたものではありません。
それでも、社内の連絡体制を考えるときの公的な手掛かりとして、自社の手順と見比べることはできます。

▼ 図の内容を文字で読む

1. RTOとRPOを決める
2. 本番に近い検証環境で切替・巻き戻し・復元を試す
3. 遅延・エラー率・処理量とアラートを観測する
4. 手順・時刻・ログ・指標を記録する
5. 課題を重大度の順に整理して手順書を直す

繁忙期後の振り返りと次回への反映

記録する項目

繁忙期が終わったら、詰まりが起きた場所、時間帯、原因、取った対応を、受付・受注後の作業・顧客対応の三つに分けて記録します。
最初の節で起点を見分けたのと同じ区分で残しておくと、次の繁忙期の前に「どこから手を付けるか」をすぐに判断できます。

Google Cloudの指針は、障害復旧の試験について、手順・時刻・ログ・指標を記録し、見つかった課題を重大度の順に整理して手順書を更新し、関係者へ報告するよう勧めています²。
これは試験の振り返りの手順ですが、繁忙期を一回の大きな試験とみなして同じ流れで振り返ると、記録が次の行動につながりやすくなります。

システム面だけでなく、締め時刻を守れなかった日、受けた例外注文の件数と種類、取引先からの問い合わせの中身も残します。
例外注文が見込みより多かったなら、条件が緩すぎたのか、締め時刻の周知が届いていなかったのか、記録があれば理由をたどれます。

次回の準備へ戻す

記録は、次の繁忙期前の確認項目へ戻して初めて役立ちます。
受付で詰まった記録があれば、繁忙期前のシステムの試験にその条件を加え、提供元を使っているなら提供元への確認事項に加えます。
受注後の作業や顧客対応で詰まったなら、締め時刻、受注量の目安、例外注文の条件、取引先へのお知らせの時期を見直します。

同じ指針は、定期的な試験に加え、インフラやソフトウェアの変更、トラフィックの変化があった後にも試験し直すよう勧めています²。
受発注システムでいえば、取引先が増えた、連携する相手が変わった、大きな改修を入れたといった変化があれば、次の繁忙期を待たずに確認をやり直す理由になります。
振り返りを一度で終わらせず、変化のたびに確認する流れにしておくと、繁忙期の直前に慌てて準備する負担を減らせます。

▼ 図の内容を文字で読む

• 状況を判断する人
  • 受付を絞る・締め時刻を早めるといった判断をする
• システム側へ連絡する人
  • 提供元や社内のシステム担当へ連絡する
• 取引先へ知らせる人
  • 何が起きているか、再送が必要か不要か、次にいつ連絡するかを伝える
• 注文の控えを取る人
  • 止まっている間に電話やメールで受けた注文の控えを取る
  • 復旧後に登録する

詰まりの起点が受付と受注後の作業のどちらにあるかは、記録の読み方や提供元との契約条件が絡み、社内だけでは切り分けにくいことがあります。

相談では、手元の記録や契約内容をもとに、システム側と運用側のどちらへ先に手を打つか、提供元へ何を確認するかを整理できます。無料相談で要件を整理する

要点の整理

軸	基準
詰まりの起点	受付・受注後の作業・顧客対応のどこで最初に生じたか
先に手当てする側	受付はシステム側、受注後の作業は運用側、顧客対応は問い合わせの中身で決める
繁忙期前のシステム確認	RTOとRPO、切替・巻き戻し・復元の手順、想定を超えたときの振る舞い
提供元サービス利用時	上限、保守予定、障害時の連絡、データを戻せる時点、試験の可否
運用の取り決め	締め時刻、受注量の目安、例外注文の条件と判断者、変更・取消の窓口、事前周知
法令	価格や支払条件に手を入れるなら取適法の適用を窓口で確認
振り返り	三つの区分で記録し、次回の試験と取り決めへ戻す

▼ 図の内容を文字で読む

• 繁忙期前：試験・提供元への確認・締め時刻など の取り決め・取引先への周知
• 繁忙期中：指標の監視・連絡・記録
• 繁忙期後：受付・受注後の作業・顧客対応の三つに分けて振り返る
• 記録を確認項目と取り決めへ戻し、次の繁忙期前の準備へ

振り返りの記録を次の準備へ戻すには、試験の範囲や取り決めの見直しを、繁忙期が始まる前の限られた時間で決める必要があります。 相談では、前回の記録から、次回の確認項目と締め時刻や例外注文の取り決めのどこを直すかを一緒に洗い出せます。

よくある質問

提供元の既製サービスを使っている場合、繁忙期前に提供元へ何を確認すればよいですか。

同時に処理できる注文や利用者の上限、上限を超えたときの画面や連携の振る舞い、繁忙期と重なる保守の予定、障害時の連絡方法と問い合わせ窓口、障害時にどの時点までの注文データを戻せるか、負荷試験を行ってよいかの六つです。
あわせて自社の繁忙期の見込みを伝えておくと、上限に近いかどうかを提供元と同じ前提で話せます。
答えが見込みに近い場合は、締め時刻や受注量の目安を余裕を持たせて決める判断材料になります。

負荷試験は本番環境でやってもよいですか。

Google Cloudの指針は、本番に近い検証環境で試すことを基本とし、本番で試す場合は監視と手動で元に戻す手段を用意するよう求めています²。
受発注システムを本番で試すなら、取引先の注文が少ない時間帯を選ぶこと、試験用の注文が実際の注文に混ざらないよう後始末の方法を決めておくことも欠かせません。
提供元のサービスを使っている場合は、他の利用者にも影響しうるため、提供元の許可と規約に従います。

注文の締め時刻を早めたいとき、取引先にどう伝えればよいですか。

繁忙期に入る前に、適用する期間、何が変わるか、例外を頼みたいときの連絡先を伝えます。
お知らせ欄やメールなど相手が普段見ている手段を使い、直前にもう一度知らせると見落としが減ります。
相手の業務に大きく響く場合は、一方的な通知より事情を説明して相談する形のほうが関係を保ちやすくなります。
締め時刻の変更に合わせて価格や支払いの条件も変える場合は、取適法の適用を窓口で確かめてから進めます。

取適法は自社の受注に関係しますか。どこで確認できますか。

2026年から下請法が改正されて取適法となり、協議に応じない一方的な価格の決定や手形による支払い等が禁止されました⁴。
ただし適用されるかどうかは取引の形態によって変わり⁴、一般的な商品の売買が対象になるかを含め、記事の範囲では断定できません。
自社の取引が対象か、どの点に注意すべきかは、公正取引委員会や中小企業庁の資料、相談窓口で確認してください。

担当が一人でも使える繁忙期の連絡体制はどう作ればよいですか。

判断する人、システム側へ連絡する人、取引先へ知らせる人、止まっている間の注文の控えを取る人、という役割を書き出し、自分が抱えきれないものを誰に頼むか、どれを先に済ませるかを決めておきます。
取引先へのお知らせの文面を場面ごとに用意し、再送が必要かどうかと次の連絡の時刻を書く形にしておくと、障害の最中の負担が軽くなります。
提供元の障害情報の掲載場所と問い合わせ窓口も、すぐ見られる場所に控えておきます。

繁忙期後の振り返りで最低限残す記録は何ですか。

詰まりが起きた場所、時間帯、原因、取った対応を、受付・受注後の作業・顧客対応の三つに分けて残します。
問い合わせは「届いているか」「いつ出荷か」「変更したい」といった種類別に残すと、次回どの場所から手を付けるかを判断しやすくなります。

1. 1　出典：Google「Site Reliability Engineering: Handling Overload」
2. 2　出典：Google Cloud「Architecture Framework: Perform testing for recovery from failures」
3. 3　出典：独立行政法人情報処理推進機構（IPA）「中小企業の情報セキュリティ対策ガイドライン 第4.0版」解説ページ（2026年）
4. 4　出典：中小企業庁 ミラサポplus「下請法の改正（取適法）」解説ページ（2026年）