BtoB ECの障害告知ページ運用｜第一報の型と掲載項目

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

B2B EC-COLUMN

第一報の必須項目（上位3）：発生時刻・影響範囲・現在の状況

BtoB EC障害告知ページの位置づけ｜広報のお詫びとの違い

BtoB ECの障害告知ページとは、サービスの停止や不具合が発生した際に、影響範囲・現在の状況・復旧の見通しを取引先へ一斉に伝えるために常設しておく告知手段です。国内のBtoB-EC市場規模は514.4兆円（2024年）に達し、システム停止は複数の取引先の業務を同時に止めます^*1。

障害告知ページの定義と、広報のお詫び文との違い

障害告知ページは謝罪文ではなく、契約に基づく履行状況を伝える通知の場です。広報のお詫び文が感情面のフォローを主目的とするのに対し、告知ページは「今どうなっているか」という事実を継続的に更新する役割を担います。

結論：決めるべきは「誰に・何の通知として・どの経路で」の3つ

告知ページの設計で最初に決めるべきは、誰に向けた通知か、何の性質の通知か、どの経路で届けるかの3点です。この3点が曖昧なまま文面から作り始めると、承認フローも掲載項目も後から揺れ動きます。

この記事で扱う範囲と扱わない範囲

本記事は、サービス全体の停止・不具合を常設ページで一斉に伝える運用を扱います。個々の取引先へ送る通知メールの文面設計や、特定の出荷案件の遅延連絡は別のテーマとして扱いません。

BtoB-EC市場規模514.4兆円が示す「止まる」の重さ

BtoB ECの障害告知ページ運用を考えるうえで、まず押さえておきたいのが取引規模の重みです。経済産業省の調査によると、2024年の国内BtoB-EC市場規模は514.4兆円で、前年の465.2兆円から10.6%増加しました^*1。

BtoB-EC市場規模514.4兆円・EC化率43.1%の意味

同調査では、全商取引金額に対する電子商取引の割合を示すEC化率も示されています。BtoB-ECのEC化率は43.1%（前年比3.1ポイント増）で、BtoCの9.8%（前年比0.4ポイント増）を大きく上回りました^*1。この差は、企業間の受発注が電子商取引に依存する度合いが高いことを表しています。

BtoCと異なり、相手の生産・販売計画まで止まる

BtoCの障害は個々の消費者の買い物を止めますが、BtoBの障害は取引先企業の発注・仕入・販売計画にまで波及します。相手方の担当者が特定できる関係であるため、告知の宛先も一般消費者向けの発信とは性質が異なります。

自社の受発注データの流れを自社の数字で確かめるには、無料相談で要件を整理するのが近道です。

だから告知は「広報」ではなく「履行に関する通知」になる

取引が止まるという事実の重さゆえに、告知ページは広報物ではなく履行に関する通知として設計する必要があります。次章では、この通知を混同なく運用するための3分類を整理します。

告知の3分類｜一斉告知・法定報告・個別連絡の違い

障害が起きたときに出す情報発信は、一斉告知・法定報告・個別連絡の3種類に分かれ、それぞれ宛先と期限が異なります。この3つを同一の「お詫び」として一括りにすると、承認や期限の管理を誤ります。

①サイト上の一斉告知（常設の障害告知ページ）

すべての関係者への個別通知が難しい場合や、影響が広範囲に及ぶ場合に、状況をウェブサイトで公表する経路です^*2。IPAの手引きでは、公表によって被害の拡大を招かないよう時期・内容・対象を考慮するとされています^*2。

②個人情報が絡む場合の法定報告と本人への通知

個人データの漏えい等が生じた場合は、障害告知とは別に、個人情報保護委員会（個人情報の適正な取扱いを監督する国の機関）への報告と本人への通知という法定義務が生じます。個人情報保護委員会への報告は、速やか（概ね3〜5日以内）に行うこととされています^*4。本人への通知も、事態の状況に応じて速やかに、概要・個人データの項目・原因などを本人に分かりやすい方法で行う必要があります^*4。この3〜5日という期限は個人情報保護委員会への報告に関するものであり、障害告知ページの掲載期限ではない点に注意してください。

③取引先担当者への個別連絡（BtoB固有）

BtoBでは取引先が特定・少数で、担当者名まで把握できていることが一般的です。一斉告知だけで済ませず、影響の大きい取引先には個別連絡を併用する運用が実務上求められます。

3種類の比較｜目的・宛先・期限・書く人・根拠

第一報の型｜IPAが示す報告・公表の2段階

第一報とは、IPAが報告・公表の最初の段階として示す告知です^*2。実務上は、原因が未確定の段階でも、確定した事実と対応状況を伝える版として運用します。次に何を書くべきかを、公的な資料に沿って整理します。

IPAが示す「報告・公表」の2段階＝第一報／第二報以降・最終報

IPA（独立行政法人情報処理推進機構）の「中小企業のためのセキュリティインシデント対応の手引き」（2026年6月）は、インシデント対応を「検知・初動対応」「報告・公表」「復旧・再発防止」の3段階に分け、報告・公表をさらに「第一報」と「第二報以降・最終報」に分けています^*2。ここでいうインシデントには、情報システムの機能停止またはこれにつながる可能性のある事象が含まれます^*2。

原因が未確定でも第一報は出す｜確定した事実と未確定を分けて書く

原因調査には時間がかかるため、原因確定を待ってから告知すると初動が遅れます。第一報の段階では、確定している事実（発生時刻・影響範囲）と、まだ分かっていないこと（原因）を明確に分けて書くのが実務上の要点です。

公表の時期・内容・対象を考える理由

IPAの手引きは、公表によって被害の拡大を招かないよう、時期・内容・対象を考慮するよう求めています^*2。すべての関係者への通知が難しい場合や、影響が広く一般に及ぶ場合には、ウェブサイトやメディアを通じた公表が選択肢になります^*2。

問い合わせ窓口を同時に開く

IPAの手引きは、顧客や消費者に関係する場合は受付専用の問い合わせ窓口を開設するよう示しています^*2。BtoB ECでも、取引先からの照会を一本化するために同じ考え方が当てはまります。被害の動向を速やかに把握し、対応につなげる体制が第一報の段階から求められます。

掲載項目の設計｜第一報・第二報・最終報で書くこと

第一報・第二報以降・最終報のそれぞれで書くべき項目は異なります。ここでは版ごとの項目と、書いてはいけない内容を整理します。

第一報の必須項目（発生時刻・影響範囲・現在の状況・次回更新予定・窓口）

第二報以降で足す項目（原因・復旧見込み・暫定回避策）

第二報以降では、被害者や影響を受けた取引先・顧客に対して、対応状況や再発防止策を報告します^*2。判明した原因、復旧見込み、暫定的な回避策があれば、その時点で分かっている範囲を追記します。

最終報で足す項目（原因・復旧完了時刻・再発防止）

最終報では、原因と再発防止策を報告します^*2。必要に応じて、被害者への補償対応の有無にも触れます^*2。あわせて復旧完了時刻を明記しておくと、取引先が自社の業務再開を判断しやすくなります（実務上の推奨）。

書いてはいけないこと（未確定の原因の断定・個人名・攻撃手口の詳細）

原因が確定していない段階での断定的な記述は、後で訂正が必要になり信頼を損ないます。個人名や、攻撃を受けた場合の手口の詳細も、二次被害を招く恐れがあるため告知ページには書きません。

規約・SLAとの整合｜免責は書けば通るものではない

告知ページの文面は、規約・SLA（サービス品質に関する取り決め）に定めた免責条項と矛盾しないよう設計する必要があります。ここでは民法の該当条文を確認します。

帰責事由がなければ損害賠償責任は生じない（民法415条1項ただし書）

民法415条1項は、債務者が履行しないとき又は履行が不能なときは損害賠償を請求できるとしつつ、「その債務の不履行が契約その他の債務の発生原因及び取引上の社会通念に照らして債務者の責めに帰することができない事由によるものであるときは、この限りでない」と定めています^*5。

双方に帰責事由がない履行不能では反対給付を拒める（民法536条1項）

民法536条1項は「当事者双方の責めに帰することができない事由によって債務を履行することができなくなったときは、債権者は、反対給付の履行を拒むことができる」と定めています^*5。障害によるサービス不履行の場面でも、あらかじめ踏まえておくべき規定です。

相手方の利益を一方的に害する免責条項は合意しなかったものとみなされる（民法548条の2第2項）

定型約款（定型取引において契約の内容とすることを目的として準備された条項の総体）の条項のうち、相手方の権利を制限し、又は義務を加重する条項であって、その定型取引の態様及びその実情並びに取引上の社会通念に照らして信義誠実の原則（民法1条2項）に反して相手方の利益を一方的に害すると認められるものは、合意をしなかったものとみなされます^*5。規約に免責と書いてあれば内容を問わず通るわけではなく、内容次第で効力が否定される点に留意が必要です。個別の条項が有効かどうかの判断は、専門家に確認することをおすすめします。

規約を変更するときの周知義務（民法548条の4第2項）

定型約款を変更するときは、効力発生時期を定め、変更する旨・変更後の内容・効力発生時期を「インターネットの利用その他の適切な方法」により周知しなければなりません^*5。障害告知ページも、こうした周知の経路の一つです。

だから告知は「謝罪」ではなく「事実と対応の通知」として設計する

ここまでの条文が示すのは、免責の有効性が個々の条項の内容次第で決まるという点です。告知ページの文面も、謝罪の言葉を並べることよりも、確定した事実と対応状況を正確に伝えることを優先して設計します。

障害告知ページを立ち上げる7ステップ

ここまでの整理を実際の立ち上げ手順に落とし込むと、次の7ステップです。

1. 告知の対象と経路を決めます（一斉告知と個別連絡の役割分担）。
2. 掲載項目のテンプレートを第一報・第二報・最終報の3版で用意します。
3. 告知ページを本体サイトと別の経路に置きます（本体が落ちても見える場所に）。
4. どの事象から告知するか、判断基準を決めます。
5. 書く人・承認する人・公開する人を決めます（夜間休日を含む体制）。
6. 個人情報が絡む場合の分岐を書き込みます（法定報告への切り替え）^*4。
7. 年1回以上、BCPの進捗と役割分担の確認に合わせて内容を見直します^*3。

事前準備｜BCP指針が示す情報発信の体制整備

障害告知ページは、障害が起きてから作るものではなく、事前対策として整備しておくものです。この位置づけは公的な指針でも裏づけられています。

BCPの事前対策項目としての情報発信手段

中小企業庁の「中小企業BCP策定運用指針（第2版）」は、事前対策の検討・実施のチェック項目として「緊急時に取引先等へ情報を発信、取引先等の情報を収集する手段を整備しているか？」を挙げています^*3。

「ホームページを公開し、緊急時に自社の被害状況や復旧状況を発信できる体制等を整備する」の意味

同指針は、この項目の実施内容の例として「ホームページを公開し、緊急時に自社の被害状況や復旧状況を発信できる体制等を整備する」を示し、担当例に広報担当者を挙げています^*3。障害告知ページの整備は、BCP（事業継続計画）上の事前対策の一部として位置づけられます。

取引先の連絡先を最新に保つ｜発信と収集は両輪

同指針のチェック項目は「情報を発信」する手段だけでなく「取引先等の情報を収集する手段」の整備も同時に求めています^*3。告知ページによる発信と、取引先連絡先の最新化は、どちらか一方では機能しません。

過去の障害事例から学ぶ限界｜IPAの一覧は2019年で終了

IPAは2010年から、社会に影響を与え全国紙等に報道された情報システムの障害情報を半年ごとに取りまとめて公開していました^*6。ただし「2019年後半データをもちまして、『情報システムの障害状況』事業は終了しました」とされており、現在は継続して公表されていないアーカイブです^*6。過去の傾向を参照する際は、この一覧が2019年後半で終了している点を踏まえておく必要があります。

やってはいけない運用と、今日始める2つのこと

設計の要点を踏まえたうえで、避けるべき運用と、すぐに着手できることを整理します。

やってはいけない4つ｜本体との同居・原因の断定・更新予定の欠落・窓口の欠落

告知ページを本体サイトと同じ基盤に同居させると、障害発生と同時に告知ページ自体も閲覧できなくなり、問い合わせが電話に集中する事態を招きます。原因が未確定なのに断定的に書くこと、次回更新予定を書かないこと、問い合わせ窓口を書かないことも避けるべき運用です。

この運用を内製で設計するには、システム構成の知識と、規約・免責に関する法務的な視点の両方が必要です。どちらか一方が欠けると、置き場所の設計は整っても文面の設計が抜け落ちる、といった片手落ちが起こりやすくなります。

今日やること①：第一報テンプレートを1枚作る

本記事の掲載項目表（第4章・第5章）を基に、発生時刻・影響範囲・現在の状況・次回更新予定・窓口の5項目を空欄のまま1枚のテンプレートにしておくと、実際の障害発生時にすぐ使えます。

今日やること②：告知ページの置き場所を本体から切り離す

告知ページの置き場所を本体サイトと異なる基盤にしておくだけでも、本体障害時に告知が見えなくなるリスクを避けられます。構成の検討や構築・保守を任せる相手を選ぶ判断材料としても、この論点は実務上重要です。

自社の構成でこの分離が実現できているかを確かめるには、無料相談で運用設計を整理することをおすすめします。

まとめ｜障害告知ページ運用の3つの判断軸

本稿では、BtoB EC障害告知ページの運用設計を、告知の分類・第一報の型・掲載項目・法的な整合・事前準備の観点から整理しました。要点を3つに集約すると次の通りです。第一に、告知は一斉告知・法定報告・個別連絡の3種類に分け、混同しないこと。第二に、第一報はIPAが示す型に沿って原因未確定のまま出し、確定事実と未確定を分けて書くこと。第三に、告知ページは障害発生後ではなくBCP上の事前対策として、本体と切り離した場所にあらかじめ用意しておくことです^*2*3。

---

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

よくある質問

原因が分からない段階で障害告知を出してよいですか。

原因未確定のまま出してかまいません。IPAの手引きは、公表の際に時期・内容・対象を考慮するとしており、原因確定を前提にしていません^*2。確定した事実（発生時刻・影響範囲）と未確定の事項を明確に分けて書くことが要点です。

障害を公表すると責任を認めたことになりますか。

公表そのものが法的責任の承認を意味するわけではありません。損害賠償責任は、債務者の責めに帰することができない事由による不履行であれば生じないと民法415条1項ただし書に定められています^*5。個別の責任の有無は、専門家に確認することをおすすめします。

障害告知ページはサイト内に置いてよいですか。

本体サイトと同じ基盤に置くのは避けるべきです。本体が障害で閲覧できなくなると、告知ページ自体も同時に見えなくなるためです。中小企業庁のBCP指針も、緊急時に情報発信できる体制の整備を事前対策として挙げています^*3。

取引先への個別連絡があれば、サイト上の告知は不要ですか。

個別連絡だけでは不十分な場合があります。すべての関係者への通知が難しい場合や影響が広範囲に及ぶ場合は、ウェブサイトでの公表が必要になるとIPAの手引きは示しています^*2。BtoBでも両方の使い分けが実務上求められます。

個人情報の漏えいを伴う障害では、告知のほかに何が必要ですか。

個人情報保護委員会への報告と本人への通知が別途必要です。個人情報保護委員会への報告は速やか（概ね3〜5日以内）に、本人への通知は事態の状況に応じて速やかに行うこととされています^*4。この期限は障害告知ページの掲載期限とは別のものです。

1. *1　出典：経済産業省 商務情報政策局 情報経済課「令和6年度電子商取引に関する市場調査」ニュースリリース（2025年8月26日公表）
2. *2　出典：独立行政法人情報処理推進機構（IPA）「中小企業のためのセキュリティインシデント対応の手引き」（中小企業の情報セキュリティ対策ガイドライン第4.0版 付録8・2026年6月）
3. *3　出典：中小企業庁「中小企業BCP策定運用指針 第2版－どんな緊急事態に遭っても企業が生き抜くための準備－」（全369ページ）
4. *4　出典：個人情報保護委員会「漏えい等報告・本人への通知の義務化について」（2026年8月26日確認）
5. *5　出典：e-Gov法令検索（デジタル庁）「民法」第415条第1項・第536条第1項・第548条の2第2項・第548条の4第2項（law_id 129AC0000000089・現行版施行日2026年6月24日）
6. *6　出典：独立行政法人情報処理推進機構（IPA）「情報システムの障害状況一覧」（2019年後半で終了したアーカイブ）