あなたのビジネスが暗転した時間（そしてそれはあなたのせいではなかった）
2025年10月20日午前3時（東部時間）、アマゾン・ウェブ・サービスのUS-EAST-1リージョン内でのDNS解決障害が連鎖反応を引き起こし、60カ国にわたる3,500社以上の企業をダウンさせました。9日後の10月29日、マイクロソフトのAzure Front Doorサービスにおける構成ミスにより、Microsoft 365、Outlook、Xbox Liveが世界中でオフラインになり、コストコのレジシステム、スターバックスのモバイルオーダー、アラスカ航空の予約ツールも巻き込まれました。どちらの企業にも火災、洪水、侵入はありませんでした。彼らのサーバーは無事でした。他の誰かのサーバーが無事ではなく、それだけでレジが止まるのに十分だったのです。
今日、中小企業を経営しているなら、あなたのPOSシステム、予約カレンダー、請求ツール、顧客データベースの多くが、あなたが所有も管理もしていないインフラ上で動いている可能性が高いでしょう。そのインフラがダウンすると、火災の時とまったく同じように収益を失います。ただし、あなたの標準的な事業用財産保険は、あなたが所有するものに損害がなかったため、ほぼ間違いなく一銭も支払いません。
このギャップには名前があります——コンティジェント・ビジネス・インタラプション保険（CBI保険）——そして、これを理解することは、売上総利益率を知ることと同様に、中小企業の基本的なリテラシーになりつつあります。
既存の保険がおそらくこれをカバーしない理由
ほとんどの中小企業は、総合賠償責任保険、事業用財産保険、および標準的な事業中断特約をバンドルした事業者向け包括保険（BOP）に加入しています。この特約は、あなた自身の被保険物件が物的に損害を受け（厨房の火災、配管破裂、屋根の風害など）、その損害のために事業を閉鎖せざるを得なくなった場合に支払われます。
問題は、クラウド障害はあなたの財産に損害を与えないことです。あなたのラップトップ、店舗、サーバー室（あるとしても）はすべて物理的に無傷でそこにある一方、Shopify、Square、QuickBooks Online、または予約ソフトウェアが自社のバックエンドにアクセスできないため、注文を処理できないだけです。標準的な事業中断補償は、完全に「物的損害」トリガーに基づいて構築されており、遠く離れた州でのDNS設定ミスはその条件を満たしません。
コンティジェント・ビジネス・インタラプション（CBI）保険は、この穴を埋めるために特別に存在します。自社の財産への損害を要求する代わりに、あなたが依存している指定された供給業者、ベンダー、またはパートナーが混乱に陥り、あなたの事業運営を停止させた場合に支払われます。POSベンダーに連動したCBI補償を持つレストランは、そのベンダーの障害により注文ができなくなった場合、火災がなくても支払いを受けられます。
落とし穴：それでもどこかで「物的損害」を必要とするCBI
問題を解決したと思った後に事業主を驚かせるのは、多くのCBI特約がクラウド以前の経済向けに書かれており、依然として物的損害を必要とすることです——ただし、あなたの場所ではなく供給業者の場所で発生する必要があります。主要ベンダーでの倉庫火災は保険をトリガーします。同じベンダーのクラウドダッシュボードを15時間ダウンさせるソフトウェアのバグはトリガーしません。なぜなら、物理的なものが燃えたり、浸水したり、壊れたりしていないからです。
保険アナリストは、これを市場で最も急速に成長している無保険エクスポージャーカテゴリーの一つとして指摘しています。ランサムウェア攻撃、悪質なソフトウェア展開、またはクラウドプロバイダーでのキャパシティ障害は、工場火災と同様に完全に事業を停止させる可能性がありますが、ほとんどの従来のCBI文言はそれを認識するように書き換えられていません。AWSがサイバー攻撃ではなく、DNSレコードの設定ミスや内部エンジニアリングエラーによってダウンした場合、一部のサイバー特化型CBIライダーも対応しません。なぜなら、それらは「セキュリティインシデント」によってトリガーされ、日常的な障害には対応しないからです。
実用的なポイント：宣言書に「コンティジェント」という言葉が書いてあるからといって、この特定のシナリオが補償されると思い込まないでください。次の3つを読むか、ブローカーに説明してもらう必要があります。
- トリガー文言。 補償には「セキュリティ障害」、「システム障害」が必要ですか、それとも広く障害/サービス中断を指定していますか？（サイバー攻撃文言だけでなく）システム障害文言こそが、実際に通常のクラウドプロバイダーのダウンを補償するものです。
- 供給業者スケジュール。 多くのCBI特約は、特定の名前が指定された供給業者での混乱のみを補償します。AWS、あなたの決済処理業者、またはSaaSベンダーがそのリストにない場合、トリガー文言がどうであれ、そこの障害は補償されません。
- サブリミット。 一部の保険は、CBIをより広範なサイバー保険または財産保険にバンドルし、全体的な補償額をはるかに下回るサブリミットを設定しています。これは書類上は安心に見えますが、実際の1週間分の失われた収益を補填するには不十分です。
クラウド障害の実際のコスト
これらの数字は、保険会社がこの補償の提供に殺到している理由を説明しています。業界のベンチマークによると、大企業全体でのITダウンタイムの平均コストは、1分あたり約14,056ドルです。これは、大量の取引量を持つ大企業によって水増しされた数字ですが、方向性としては有用です。クラウドに依存した収益が1日10万ドルのビジネスは、レジまたは予約システムが完全にダウンした場合、1時間あたり約29,000ドルを失います。2025年10月のAWSインシデントは15時間以上続きました。その数分の一の規模のビジネスでも、半日ダウンすれば、システムが暗転している間に溜まった手動での再予約、再請求、調整の人件費を数える前に、5桁の損失に直面する可能性があります。
パン屋、メディカルスパ、ニッチなEコマースショップ、個人事業主のコンサルタントにとって、これは抽象的な話ではありません。それは悪い月、時には悪い四半期を意味し、事業主に何の警告もなく、何の責任もなく発生します。
コンティジェント・ビジネス・インタラプション補償が実際に支払うもの
適切に構成されている場合、CBI（「ダウンタイム保険」またはサイバーCBI特約として販売されることもあります）は、通常以下を補償します。
- 逸失純利益：障害がなかった場合に得られたであろう利益で、過去の収益に基づいて計算されます。
- 継続的な固定費：家賃、給与、ローン支払いなど、POSシステムが停止したからといって支払いが止まらない費用。
- 追加費用：障害中に事業を継続するために発生した費用：手動のカードリーダー、紙の注文を処理するための臨時スタッフ、迅速なソフトウェア修正。
- SLA関連の責任：一部の保険では、あなた自身の顧客があなたとサービス契約を結んでおり、障害のためにそれを履行できなかった場合。
待機期間は表面的な補償額よりも重要
すべてのCBI保険には、保険金が支払われる前の待機期間（実質的な時間の免責額）があり、通常は保険会社と保険料レベルに応じて24～72時間です。1日未満で解決する短い障害（クラウドインシデントの多くを占める）は、この待機期間内に完全に収まり、何も支払われない可能性があります。購入前に直接尋ねてください：「AWSが6時間ダウンした場合、この保険は何か支払いますか？」多くの標準的な保険では、正直な答えは「いいえ」です。より短い待機期間が必要であり、それはより高額になるか、あるいはCBIは日常的な障害ではなく、複数日にわたる最悪のシナリオに対する保護であると受け入れる必要があります。
費用と購入方法
スタンドアロンの事業中断保険は、一般的に小規模事業の場合、月額40～130ドル（年間480～1,560ドル）で、総合賠償責任保険、財産保険、事業中断保険をバンドルした完全なBOPは、平均年間1,450～2,650ドルです。コンティジェント/サイバーCBIは、通常、非常に小規模な事業向けのスタンドアロン製品として販売されるのではなく、特約またはライダーとして追加され、価格は収益、業種、および単一のクラウドベンダーへの依存度に大きく依存します。
実践的な手順：
- 現在のブローカーに2つの質問をする：「私のBOPの事業中断条項は、トリガーに物的損害を必要としますか？」および「コンティジェントまたはサイバーCBI特約は利用可能ですか？また、それは私の実際のクラウド/SaaSベンダーを指定していますか？」
- 単一障害点をリストアップする——障害が実際に顧客対応を停止させる2、3のベンダー（ホスティング、決済、予約、メール）。これらの名前が供給業者スケジュールに記載される必要があります。
- 補償限度額だけでなく、トリガー文言について交渉する。通常の障害で実際にトリガーされない5万ドルの限度額の保険は、確実に支払われる2万ドルの保険よりも価値が低いです。
- 待機期間を実際のリスクと比較する。ベンダーを襲う障害のほとんどが1日未満で解決する場合、72時間の待機期間はほとんど意味がありません。
保険は優れた記録に代わるものではない——それに依存している
ほとんどの補償説明で見落とされる部分はこれです：CBI請求を行うには、実際に失ったものを証明する必要があり、それはつまり、得られたであろうものを証明することを意味します。保険会社は、過去の収益データ、明確な前後比較、そして事業継続のために行った追加費用の文書化を求めます。清潔で日付のある財務記録を作成できない事業は、保険が支払うべき場合でも、請求を立証するのに苦労します。
これは、会計を完全に自分で管理し、いつでも監査できる形式で保持するもう一つの理由です。事後に、おそらく同じく障害の影響を受けている会計SaaSが生成するレポートに再構築を委ねるのではありません。Beancount.ioは、プレーンテキストでバージョン管理された財務記録を提供します。これは、完全で日付があり、エクスポート可能な台帳であり、事業中断の請求を慌てて行うのではなく、簡単に文書化できるようにします。台帳はあなたが管理する単なるテキストファイルであるため、実際に数字を確認する必要がある週に、別の会社のクラウド障害の影響も受けません。プレーンテキストのアプローチが日常の簿記にどのように対応するか興味があれば、ドキュメントで基本を説明しており、Favaはその上に視覚的なレポートレイヤーを提供します。
結論
AWSやAzureがまた悪い朝を迎えるかどうかは、あなたがコントロールできることではありません——地球上で最大の2つのクラウドプロバイダーは、それぞれ過去1年間に一度それを経験しており、小規模なベンダーは報道されることなく常にダウンしています。あなたがコントロールできるのは、6桁の収益の一日が、補償について監査したことのないインフラに依存しているかどうか、そして万が一そうなった場合に損失を証明できるかどうかです。今週中にあなたのBOPの事業中断文言を読み、ブローカーに物的損害トリガーの質問を直接行い、CBI特約の供給業者スケジュールが実際にあなたをオフラインにできるベンダーを指定していることを確認してください。