PAYMENT INFRASTRUCTURE
決済基盤の停止
店舗、EC、加盟店、カード会社が正常でも、 取引処理を担う共通基盤が応答しなければ決済は完了しません。
Original Source / Citation
Original: https://www.ieee802.co.jp/articles/article-204-spof.php
Publisher: 慧通信技術工業株式会社 （Kei Communication Technology Inc.）
出典： 慧通信技術工業株式会社 「 99.99％は事業継続を保証しない｜クラウド・決済・通信に移転した見えない単一点障害 」
本文リンク例（アンカーテキスト）
99.99％は事業継続を保証しない｜クラウド・決済・通信に移転した見えない単一点障害
参考文献記載例
慧通信技術工業株式会社「99.99％は事業継続を保証しない｜クラウド・決済・通信に移転した見えない単一点障害」
要約・一部引用は歓迎（条件あり）／全文転載・AIリライト転載（劣化コピー）・学習用再利用は許可しません。 AI Usage & Citation Policy
※ 要約・引用は歓迎します。出典としてOriginalページへのリンクをご記載ください。
SPOF / High Availability / Cloud / Payments / Communications / BCP
99.99％は事業継続を保証しない｜クラウド・決済・通信に移転した見えない単一点障害
クラウド、CDN、決済、認証、通信は、個々には高い可用性を実現しています。 しかし、複数の企業や業務が同じ外部基盤へ集中すれば、 一つの障害が広い範囲へ同時に波及します。
99.99％という数字は、サービスの平均的な稼働率を示します。 それは、停止時にも自社の業務を継続できることを保証する数字ではありません。 本稿では、自社設備から外部基盤へ移転した「見えない単一点障害」を整理します。
👁️ -- views
慧通信技術工業株式会社
THE INVISIBLE SINGLE POINT OF FAILURE
99.99％は、事業継続を保証しない。
高い稼働率は信頼性の指標であって、 外部基盤の停止時にも業務を継続できることを示すものではない。
INVISIBLE SPOF
99.99％は、事業継続を保証しない。
Two Incidents, One Structural Lesson
同じ日に表面化した二つの外部基盤障害
2026年7月16日朝、国際ブランドの決済ネットワークに関係する基盤で 取引処理のタイムアウトが発生し、国内でも一部のカード決済が利用できない状態となりました。 同日夕方には、世界規模のCDNで障害が発生し、 決済、配信、ブログ、動画など異なるサービスが同時に利用しにくくなりました。
二つの障害は、原因も事業者も異なります。 しかし利用企業から見れば、共通する事実があります。 自社の設備が正常でも、外部の共通基盤が止まれば事業は止まるということです。
CONTENT DELIVERY INFRASTRUCTURE
CDNの停止
個々のウェブサービスが稼働していても、 配信経路の共通機能に障害が起きれば、利用者からはアクセスできなくなります。
障害点は自社内にあるとは限りません。 自社が制御できない場所にあるからこそ、SPOFは見えにくくなります。
Four Nines / Availability / Dependency
99.99％でも、止まるときは同時に止まる
通信業界やクラウド業界で用いられてきた 「99.99％」という稼働率は、 年間停止時間に換算すると約52分です。
99.99％の実際
1年間で、約52分は停止し得る
365日を基準にすると、 99.99％の稼働率は年間約52分34秒の停止時間に相当します。 これは高い可用性を示す一方、 無停止を保証する数字ではありません。
しかし、この数字が表しているのは、 原則として個別サービスの平均的な利用可能時間です。 事業継続にとって重要な、次の問題までは説明しません。
- 01 その約52分が、いつ発生するのか
- 02 決済、認証、CDN、DNS、通信が同じ基盤へ依存していないか
- 03 一つの外部基盤の障害が、何社・何サービスへ波及するのか
- 04 障害時に、独立した代替経路へ切り替えられるのか
- 05 中央システムが利用できなくても、現場で業務を継続できるのか
なぜ、一つの外部サービスが止まるだけで全体が使えなくなるのか
インターネット上のサービスは、 一つのシステムだけで完結しているわけではありません。 利用者がウェブサイトや業務システムへ到達し、 ログインし、画面やデータを受け取り、 決済を完了するまでに、複数の外部基盤を順番に利用しています。
DNS
「example.com」のようなドメイン名を、 接続先を示すIPアドレスへ変換する仕組みです。 DNSが停止すると、サーバー自体が正常でも、 利用者は接続先を見つけられず、サービスへ到達できません。
CDN
ウェブページ、画像、動画、プログラムなどを、 利用者へ効率的に届ける配信基盤です。 元のサーバーが正常でも、CDNに障害が発生すると、 ページが表示されないことがあります。
認証基盤
利用者のID、パスワード、権限などを確認し、 システムへのログインを許可する仕組みです。 認証基盤が停止すると、業務システムが正常でも、 利用者はログインできません。
決済基盤
カード情報、本人認証、取引承認、 不正利用判定などを処理する仕組みです。 店舗やECサイトが正常でも、決済基盤が応答しなければ、 購入手続を完了できません。
通信回線
利用者、店舗、拠点、データセンター、 クラウドを結ぶ経路です。 システムとデータが正常でも、 通信できなければ利用者からは使えません。
電源
ONU、ルーター、スイッチ、Wi-Fi、 端末などの現場機器を動かします。 クラウドが正常でも、 現場側の電源が止まればサービスを利用できません。
利用者から見た、一般的な処理の流れ
- 1. DNSで、接続するサーバーの所在を確認する
- 2. 通信回線を通じて、ウェブサイトや業務システムへ接続する
- 3. 認証基盤で、利用者のIDと権限を確認する
- 4. CDNやクラウドから、画面、画像、プログラム、データを受け取る
- 5. 決済基盤で、支払いの承認と処理を完了する
このうち一つでも利用できなければ、 利用者から見れば「サービス全体が停止した」のと同じ状態になります。
高可用性サービスを組み合わせるほど、全体の可用性は下がる
例えば、ある業務を完了するために、 DNS、認証、決済という3つのサービスがすべて正常である必要があるとします。
このように、どれか一つが停止するだけで業務全体が成立しなくなる関係を、 直列の依存関係と呼びます。
99.99％のサービスを3つ直列に組み合わせた場合
0.9999 × 0.9999 × 0.9999 ＝ 0.99970003
システム全体の可用性は、約99.97％
年間停止時間に換算すると、約2時間38分です。 個々のサービスは99.99％でも、 すべてが正常でなければ業務が成立しない場合、 システム全体として正常に動作する確率は低下します。
※上記は、各サービスの障害が互いに独立し、 3サービスすべてが正常でなければ業務を継続できない 直列構成として単純化した計算です。
実際には、DNS、CDN、認証、決済などが 同じクラウド、通信、電源、管理基盤を共有している場合があります。 その場合、複数の機能が同時に停止するため、 障害は単純な掛け算では評価できません。
稼働率が高くても、 依存関係が一つの外部基盤へ集中していれば、 SPOF（単一点障害）は消えていません。
むしろ、従来は社内のサーバー、通信回線、 ルーター、電源などにあった障害点が、 クラウド、決済基盤、認証基盤、CDN、DNSなど、 自社から見えにくく、制御できない外部基盤へ移転しています。
99.99％は、サービスがほとんど止まらないことを示す数字です。
止まったときにも事業を継続できることを保証する数字ではありません。
The SPOF Has Moved
SPOFは消えず、外部基盤へ移転した
従来の単一点障害は、社内サーバー、一本の通信回線、一台のルーター、 一系統の電源、一人の担当者など、物理的に確認しやすいものでした。
クラウド化と外部委託によって、これらの一部は高度に冗長化されました。 しかし依存関係そのものがなくなったわけではありません。 障害点は次の外部基盤へ移転しています。
CDN
配信経路が止まれば、オリジンサーバーが正常でも利用できない。
DNS
名前解決が止まれば、サービスの所在へ到達できない。
認証・ID
一つのID基盤が止まると、複数のSaaSへ同時にログインできない。
決済
取引処理、本人認証、不正検知の共通基盤が停止すると販売が止まる。
API
外部APIの停止が、受注、在庫、配送、請求へ連鎖する。
クラウドリージョン
複数システムが同じ地域・同じ管理系へ集中する。
通信事業者
回線を複数契約しても、局舎や上位網を共有する場合がある。
電源
クラウドが正常でも、現場のONU、ルーター、端末が止まれば利用できない。
Redundancy Is Not Independence
多重化していても、同じ基盤なら分散ではない
サービスを二つ契約していることと、独立した二つの経路を持つことは同じではありません。 表面上は別のサービスでも、背後で同じクラウド、同じCDN、同じ認証基盤、 同じ通信事業者、同じ管理者アカウントに依存している場合があります。
見かけ上の多重化
- 異なるSaaSだが、同じクラウドリージョンを使用
- 回線は二契約だが、同じ局舎・同じ上位網を経由
- 決済手段は複数だが、同じゲートウェイへ集中
- バックアップが本番と同じ認証・管理環境に接続
実質的な分散
- 障害ドメイン、管理権限、通信経路が独立している
- 中央基盤がなくても最低限の業務を継続できる
- 一部を切り離しても他の領域へ波及しない
- 安全確認後に部分単位で再接続できる
冗長化の評価単位は「契約数」ではありません。 障害ドメイン、管理権限、認証、通信、電源がどこまで独立しているかです。
Controllability / Isolation
必要なのは可用性だけでなく、切離し可能性
高い可用性を持つサービスを選ぶことは重要です。 しかし、自社で制御できない外部基盤の停止をゼロにすることはできません。 したがって事業継続では、外部基盤が利用できない状態を前提にします。
切り離せる
障害や侵害が発生した領域を、他の業務から隔離できる。
単独で動かせる
中央、クラウド、通信が失われても、最低限の機能をローカルで継続できる。
順番に戻せる
安全を確認した機能から、依存関係に沿って段階的に復旧できる。
決済停止時の別手段、認証停止時の緊急アカウント、通信断時のローカル運転、 クラウド停止時の手作業、停電時の無瞬断電源など、 代替運用はシステムの外側にも必要です。
Stop / Test / Restore
定期的に止めて、依存関係を確認する
止めないことだけを目標にすると、組織は停止、切替、独立運転、再投入の経験を失います。 有事に初めて外部サービスを切り離すのでは遅すぎます。
-
1. 対象を止める
通信、認証、決済、クラウドの一部を計画的に切り離す。
-
2. 残る機能を確認する
現場業務、ローカルデータ、手作業、電源が機能するか確認する。
-
3. 依存を記録する
想定外のAPI、認証、担当者、電源、通信への依存を台帳化する。
-
4. 安全に戻す
復旧順序、確認項目、責任者を明確にして段階的に再投入する。
止められないシステムは、有事にも安全に止められません。 戻したことがないシステムは、有事に安全に戻せるとは限りません。
Distributed Architecture
分散型システムの設計原則
中央システムやクラウドを廃止する必要はありません。 必要なのは、中央の効率性を利用しながら、 その停止時にも重要機能が残る構造です。
| 設計項目 | 確認する内容 |
|---|---|
| 業務 | 止めてはいけない機能、停止許容時間、最低限の処理量 |
| クラウド | リージョン、管理系、CDN、DNS、APIの共通依存 |
| 認証 | 中央ID停止時の緊急アクセス、権限管理、ローカル認証 |
| 通信 | 物理経路、局舎、キャリア、VPN、DNSの独立性 |
| 決済 | 別方式、オフライン処理、後払い、現場判断の条件 |
| 電源 | ONU、ルーター、スイッチ、端末、監視を維持する無瞬断・長時間電源 |
| 復旧 | 安全確認、復旧優先順位、部分再接続、ロールバック |
可用性の時代から、依存関係を制御する時代へ。
99.99％を信じるだけではなく、残りの0.01％に何をするかを設計する。
FAQ
よくある質問
Q1. 99.99％の稼働率なら、ほとんど止まらないのではありませんか？
停止時間の目安としては高い水準です。ただし、停止する時刻、影響範囲、共通依存、代替経路、利用企業の損失までは示しません。
Q2. クラウドへ移行すればSPOFはなくなりますか？
なくなるとは限りません。社内設備にあった障害点が、クラウド、CDN、DNS、認証、決済、APIなどへ移転する場合があります。
Q3. 二つのサービスを契約すれば分散になりますか？
背後のクラウド、通信、認証、決済ネットワークを共有していれば、同じ障害ドメインに属します。契約数ではなく独立性を確認します。
Q4. 最初に何を確認すべきですか？
重要業務、停止許容時間、外部依存、代替経路、ローカル運転、手作業、電源、復旧順序を確認してください。
AI要約・引用は可（出典明記・改変なし・全文転載なし）｜全文転載・AIリライト転載・学習用再利用は不可