CyberSource障害で全国のカード決済が停止｜「自社が選んだ覚えのない1社」の変更作業で売上が止まる——間接依存の3段階マッピングと契約・変更管理チェック

最初に結論を置く。2026年7月16日の朝から昼にかけて、全国の店舗・EC・交通系チャージでクレジットカード決済が利用しづらくなった。止めたのはランサムウェアでも標的型攻撃でもない。Visa子会社の決済接続サービスCyberSourceの障害であり、報道によればその原因は「プログラム変更の影響」——つまり、どこかの誰かのリリース作業だった。

この事案から経営者が持ち帰るべき教訓は、「決済は複数用意しよう」という表面的な話ではない。自社が選んだ覚えもなく、契約書も交わしていない1社の変更作業で、自社の売上が数時間止まる——この構造が、決済に限らず、ECカート、SaaS課金、予約システム、あらゆる「外部サービスの上に売上が乗っている」事業に埋まっているという事実だ。攻撃が原因ではない以上、セキュリティ投資では防げない。防げないなら、やるべきことは3つに絞られる。(1)自社の売上がどの外部サービスの、さらにその先の何に依存しているかを平時に可視化しておくこと。(2)直接の契約相手との契約書で、障害時に何が請求でき、何が請求できないかを把握しておくこと。(3)自社が発注するシステムでは、同じ事故——攻撃ゼロでも変更作業で止まる事故——を起こさないよう、変更管理を発注時点で仕様に書き込むこと。本記事はこの3つを、実行できる手順に落として解説する。

なお、当サイトでは直前にニチレイのサイバー攻撃事案を題材にした取引先起点のBCPを扱った。あちらは「攻撃起因で、モノの仕入先・物流委託先という直接の取引先が止まる」場合の需要側BCPである。本稿が扱うのはその隣にある別の穴、すなわち「攻撃なし・変更作業起因で、自社が契約すらしていない間接の依存先が止まる」場合だ。取引先リストをいくら眺めても今回の穴は見つからない。CyberSourceは、ほとんどの加盟店の取引先リストに載っていないからである。この「リストに載らない依存」をどう見つけるかが、本稿の中心テーマになる。

この記事を読むべき人

• EC・店舗決済・サブスク課金など、外部の決済・課金サービスの上に売上が乗っている会社の経営者・事業責任者
• 7月16日の障害で実際にレジやECの決済が通らず、「うちは何もしていないのに」と感じた店舗・EC運営者
• 決済代行やECカートを1社に任せており、その会社の「さらに上流」が何かを答えられない管理部門・EC担当
• 専任の情シスがおらず、外部サービスの契約書を「金額と期間しか見ていない」自覚がある決裁者
• 自社でもシステムを外注しており、「リリース作業で本番が止まる」リスクを発注側としてどう縛ればいいか知りたい会社

一つでも当てはまるなら、今回の障害は他人事ではなく、自社の構造の予告編として読んでほしい。

何が起きたか——障害タイムライン

まず事実関係を時系列で整理する。CyberSource公式ステータスページ(インシデント番号INC26452085)が一次情報であり、国内各社の影響は各社の告知またはpiyolog等がまとめた報道に基づく。原因に関するVisa日本法人の説明は報道ベースである点に注意してほしい。

このほか、カード発行会社では三井住友カード・三菱UFJニコスが自社告知を出し、モバイルICOCA・モバイルPASMO・d払い等への影響も報じられた(報道ベース)。本稿では、各社告知または報道で確認できた社名のみを記載している。

このタイムラインから読み取るべきことは3つある。

第一に、影響時間帯の起点はUTCの深夜、日本の朝だったという点だ。CyberSource公式の影響開始はUTCで7月15日23:12。米国では夜間だが、日本ではちょうど7月16日の朝8時すぎ、コンビニ・駅・ドラッグストアが動き出す時間帯に重なった。今回の障害の原因作業がいつ行われたかは公表されていないが、一般論として、海外事業者にとって「影響が小さい時間帯」は日本の加盟店にとっての書き入れ時と重なり得る。海外SaaS・海外決済基盤に依存する事業は、この時差構造そのものをリスクとして認識しておく必要がある。

第二に、「自社の実影響」と「上流の公式な影響時間帯」はずれるという点だ。国内の主要サービスは午前中から正午にかけて概ね復旧したと各社が告知した一方、CyberSource公式の影響時間帯は日本時間17:19まで、正式なResolved掲示は翌17日朝(日本時間9:20)である。逆のずれ——上流が「復旧」を宣言した後も自社側の影響が残るケース——も当然あり得る。障害対応の記録は「上流のステータスページの時刻」と「自社で決済が通らなかった実時刻」の両方を残さなければ、後述するSLA請求や原因整理の材料にならない。

第三に、イシュア(カード発行会社)でさえ、渦中では原因を特定して語れなかったという点だ。エポスカードの10:41の告知は、自社カードが使いづらいことと「他社でも同様の事象が起きている」ことまでしか書いていない。カード会社ですら渦中で言えるのはそこまでなのだから、末端の加盟店が障害の瞬間に原因を突き止められるはずがない。だからこそ、原因究明を渦中にやるのではなく、依存構造の把握を平時にやっておく——これが本稿の手順論の前提になる。

「選んだ覚えのない1社」に売上が握られる構造——間接依存とは何か

なぜ、CyberSourceと契約した覚えのない全国の店舗やECで、いっせいに決済が通らなくなったのか。カード決済が多層構造だからである。

買い物客がカードを使うとき、その裏では概ね「加盟店 → 決済代行・決済端末事業者 → カードネットワークへの接続基盤 → カード発行会社の承認システム」という経路で認証・売上データが流れる。今回止まったのは、この中段にあるVisa傘下の接続基盤(CyberSource / Visa Platform Connect)だった。加盟店が契約しているのは手前の決済代行や端末事業者であり、その先の接続基盤が誰で、どう運用されているかは、契約書にも管理画面にも普通は出てこない。それでも、そこが止まれば売上は止まる。

この構造を本稿では間接依存と呼ぶ。定義はシンプルで、「自社の売上や業務が依存しているのに、自社との間に契約が存在しない事業者・サービス」である。間接依存には、直接依存にはない3つの厄介さがある。

一つ目は、選定権がないこと。直接の契約先なら、選定時に体制や実績を比較できる。だが契約先の、さらにその先を自社が選ぶことはできない。二つ目は、契約上の請求権がないこと。障害で売上を失っても、自社が何かを請求できる相手は直接の契約先だけであり、その契約先自身も「上流起因」を免責事由にしていることが多い(後述)。三つ目は、存在自体を知らないことだ。障害が起きて初めて「うちの決済はそこを通っていたのか」と知る。今回、多くの事業者にとってCyberSourceはまさにそれだった。

ここで重要なのは、この構造が決済に限らないことである。自社のECカートは、その裏でどのクラウド基盤の上で動いているか。顧客へのメール配信は、カートベンダーがさらにどの配信基盤を使っているか。SaaSのログイン認証は、どの認証サービスに委ねられているか。売上が外部サービスの上に乗っている事業は、例外なくこの多層構造の上に立っている。そして各層のどこか1社の変更作業が失敗すれば、今回と同じことが自社に起こる。

もう一点、経営者として押さえるべきなのは、攻撃起因と非攻撃起因では、備えの性質が変わることだ。サイバー攻撃なら「攻撃されにくくする」投資に意味がある。しかし今回のような変更作業起因の障害は、上流事業者の内部プロセスの問題であり、自社側の防御投資では発生確率を1ミリも下げられない。下げられないリスクへの正しい向き合い方は、発生を前提に「影響を小さくする」「早く気づく」「事後に請求・交渉できる状態にしておく」の3つしかない。以降の手順は、すべてこの3つのための段取りである。

依存点マッピングの手順——3段階で「売上が通る道」を洗う

では、リストに載らない依存をどう見つけるか。以下の3段階でマッピングする。特別なツールは要らない。表計算1枚と、半日から1日の作業時間で最初の版は作れる。

段階1: 自社の「金が動く経路」を業務単位で棚卸しする。 最初に見るのはシステムではなく売上だ。自社の売上が発生してから入金されるまでに通る経路を、チャネルごとに書き出す。店舗ならレジ・決済端末・POS、ECならカート・決済・受注管理・配送連携、サブスクなら課金基盤・請求・督促。このとき「売上の何%がこの経路を通るか」を粗くていいので割り付ける。目的は、止まったときの痛みが大きい経路から順に調べるためであり、全経路を均等に調べる必要はない。売上の8割が通る経路が2〜3本に絞れれば、段階1は完了だ。

段階2: 各経路の「直接契約先」を列挙する。 段階1で洗った経路ごとに、自社が契約している事業者・サービスを並べる。決済代行、カート、POSベンダー、課金SaaS、通信回線。ここまでは請求書と契約書をめくれば機械的にできる。あわせて、各契約先について「契約書の保管場所」「障害時の連絡窓口」「公式のステータスページや障害告知ページのURL」の3点を同じ表に記録する。障害の渦中に契約書を探し始める会社は驚くほど多く、それだけで初動が1時間遅れる。

段階3: 直接契約先の「その先」を調べる。 ここが本稿の肝であり、多くの会社がやっていない工程だ。直接契約先が依存している上流を、把握できる範囲で書き加える。調べる手段は現実的には4つある。(1)契約先の公式サイトやヘルプにある構成・提携情報——決済代行なら対応カードブランドや接続先ネットワーク、SaaSなら利用インフラの記載。(2)個人情報保護方針や利用規約にある委託先・再委託先(サブプロセッサー)の一覧——海外SaaSは一覧を公開していることが多く、上流を知る最短ルートになる。(3)契約先の過去の障害告知——過去の障害文面に「上流の〇〇社の障害により」と書かれていれば、それが依存先の自白である。(4)直接、契約先の営業・サポートに聞く——「御社のサービスが依存している外部基盤と、そこが止まった場合の御社の対応方針を教えてほしい」という質問は、発注側として何ら失礼ではない。

3段階を終えると、「自社→契約先→その先」の3層が1枚の表になる。そこで初めて見えるものがある。典型は見かけ上の複線が、上流で1本に合流しているケースだ。たとえば決済手段を2社に分けて冗長化したつもりでも、2社が同じ接続基盤を使っていれば、今回のような上流障害では両方同時に止まる。冗長化の投資判断は、この表なしにやると「安心を買ったつもりで同じリスクを2回買う」ことになりかねない。

マッピングの最後に、経路ごとに2つの数字を書き込む。「この経路が1時間止まると失う売上の概算」と「止まったとき、顧客に代替手段を案内できるか(現金、別ブランド、後払い、取り置き)」。この2つが埋まっていれば、障害当日の判断——どの経路の復旧を待ち、どの経路は代替に切り替え、顧客に何を案内するか——は、渦中ではなく平時に済ませたことになる。

契約書のどこを見るか——SLA・障害時責任・返金条項の読み方

マッピングで依存が見えたら、次は直接契約先との契約書・利用規約を「障害の目」で読み直す。金額と期間しか見ずに締結した契約書には、たいてい次の6点で落とし穴がある。順に確認してほしい。

1. SLAの稼働率は「分」に換算して読む。 「稼働率99.9%保証」は立派に聞こえるが、月に換算すると約43分の停止が許容されている。99.5%なら月3.6時間、99%なら月7.3時間だ。今回の国内影響はおよそ朝から正午までの約4時間である。つまり99.5%のSLAなら、今回級の障害が起きてもSLA違反にすらならない可能性がある。自社の「1時間止まったら失う売上」と並べて、その許容時間が事業として飲めるかを判断する。

2. 稼働率の計算から「除外」される時間を確認する。 計画メンテナンス、事前通知済みの作業、そして「第三者サービスに起因する障害」がSLA計算から除外される建て付けは非常に多い。除外が広いSLAは、数字がいくら高くても実質的な保証にならない。

3. 救済手段は多くの場合「利用料の減額・クレジット」止まりである。 SLA違反時に受け取れるのは月額利用料の一部返金であって、止まっていた間の逸失売上ではない。月額数万円のサービスの障害で数百万円の売上を失っても、契約上戻るのは数千円〜数万円、という非対称は珍しくない。この非対称を消す交渉は現実には難しいので、「契約で取り返せない部分は、複線化・代替手順・保険でカバーする」という設計判断に落とすのが実務的だ。

4. 免責条項に「上流起因」が入っていないか。 「当社の合理的支配の及ばない第三者のサービスに起因する障害については責任を負わない」という趣旨の条項は、今回のようなケースでまさに発動する。この条項がある契約先に対しては、賠償を求める前提ではなく、「上流障害時に何分以内に第一報をくれるか」「代替経路への切替を提供してくれるか」という運用面の約束を取りにいくほうが実益がある。

5. 障害通知と報告書の義務を確認する。 障害発生時の通知期限(検知から何分・何時間以内か)、通知手段(メールか、ステータスページ掲示のみか)、収束後の原因報告書の提出義務があるか。書かれていなければ、更新時に一筆加える交渉をする。報告書は再発防止の確認だけでなく、自社が顧客や社内に説明する際の根拠にもなる。

6. 解約・乗り換えの自由度を確認する。 重大障害やSLA連続未達の際に中途解約できる条項があるか、データや設定のエクスポートが保証されているか。障害対応の最後の手段は乗り換えであり、その出口が塞がれた契約は、障害のたびに交渉力を失う。

以上の6点は、新規契約の審査項目としてだけでなく、既存契約の総点検リストとして使ってほしい。今回の障害は、その点検を経営会議の議題に載せる格好の口実になる。「先日の全国的な決済障害を受けて、当社の外部サービス契約を障害の観点で総点検した」——この一文が言える会社と言えない会社の差は、次の障害の日に出る。

自社システム側の教訓——攻撃がなくても、変更作業で止まる

今回の事案には、発注側としてもう一つの重要な教訓がある。報道ベースではあるが、原因は攻撃ではなく「プログラム変更の影響」とされている。世界規模の決済基盤ですら、変更作業の失敗で数時間止まる。ならば、自社が外注で作る基幹システムやECが、リリース作業で止まらない保証はどこにもない。実務の現場感覚としても、システム停止の原因は外部からの攻撃よりも、変更作業やリリースの失敗であることのほうがはるかに多い。

問題は、発注側の多くがこのリスクを契約とRFPで一切縛っていないことだ。「良いものを作ってください」という発注はしても、「どう変更するか」を仕様にする発注はほとんど見ない。変更管理は開発会社の内部運用に丸投げされ、その品質は納品後の障害で初めて判明する。これは発注時に仕様化できるし、すべきである。具体的には、RFPや契約・SLAに次の項目を書き込む。

1. 環境分離と本番直接変更の禁止——本番と検証環境を分離し、検証を経ない本番変更を原則禁止とすること。緊急時の例外手順と承認者もあわせて定義する。
2. ロールバック(切り戻し)の手順と目標時間——すべてのリリースについて、失敗時に旧版へ戻す手順を事前に用意し、「切り戻し判断から30分以内に復旧」のような目標時間を定めること。今回のCyberSource障害でも、影響開始から公式の影響時間帯終了まで9時間かかっている。切り戻しがどれだけ速いかが、変更失敗の被害額をほぼ決める。
3. 段階リリース——影響の大きい変更は、全ユーザー・全店舗へ一斉適用せず、一部から段階的に適用して監視する方式(カナリアリリース)を採ること。
4. 変更凍結期間——自社の繁忙期・セール期・月末請求処理など、止まったら困る期間を発注側から指定し、その間の非緊急リリースを凍結すること。海外ベンダーや海外基盤を使う場合は、時差の関係で「先方の深夜=こちらの営業時間」に作業が入りやすいことを踏まえ、作業時間帯を日本の業務時間基準で合意しておく。
5. 事前通知と変更内容の説明——本番変更の何営業日前に、何が変わり、失敗時に何が起こり得るかを通知すること。「軽微な変更のため通知しません」の線引きも文書で合意する。
6. リリース判定の記録——リリース可否を判断したチェック項目と承認者の記録を残し、障害時に提出できること。
7. 決済成功率・エラー率の監視としきい値——リリース直後にビジネス指標(決済成功率、注文完了率)を監視し、しきい値を割ったら自動または即時に切り戻す運用とすること。インフラの死活監視だけでは、今回のような「システムは動いているが決済が通らない」障害を検知できない。
8. 障害時の第一報SLA——障害検知から発注側への第一報までの時間(例: 30分以内)と、続報の間隔を定めること。

この8項目は、開発会社にとって過大な要求ではない。まともな開発会社なら大半を既に実践しており、むしろこの8項目に具体的に答えられるかどうかが、開発会社選定の強力な選別基準になる。「ロールバックの目標時間は?」「段階リリースはできるか?」「凍結期間は受け入れるか?」——この質問に即答できないベンダーへの発注は、今回のCyberSourceと同じ構造のリスクを、自社のシステムの中に自分で作り込むことを意味する。要件定義や開発会社選定の段階からこの観点を織り込みたい場合は、DX・システム開発の支援で、発注準備・RFP設計・ベンダー評価の枠組みから伴走できる。

もう一つ、忘れられがちなのが障害当日の顧客対応の初動だ。今回のような外部起因の障害では、自社に非がなくても、顧客の目の前で決済を断るのは自社の店頭でありECの画面である。「現在、カード決済サービス全体で障害が発生しております。現金・〇〇はご利用いただけます。復旧見込みは公式発表があり次第ご案内します」——この一枚が出せるかどうかで、失うものが売上だけで済むか、信頼まで失うかが分かれる。原因がサイバー攻撃か変更ミスかは、顧客対応の初動設計にとっては二次的な問題であり、検知・判断・告知・記録という初動の骨格は共通だ。外部起因・攻撃起因の双方を含む初動体制をまとめて整えたい場合は、インシデント対応支援で発生前の体制構築から支援している。

FAQ——外部起因の決済・サービス障害をめぐる実務の疑問

Q1. 契約先の決済代行から「上流の障害なので当社では対応できない」と言われた。加盟店側にできることはないのか。

渦中にできることは3つある。第一に、記録——自社で決済が通らなかった時間帯、エラーの内容、失った注文の概算を残す。SLA請求にも、契約更新交渉にも、社内説明にも、この記録がすべての土台になる。第二に、顧客への代替案内——止まった経路を眺めるのではなく、使える手段(現金、別ブランド、後払い、注文の取り置き)へ顧客を誘導する。第三に、上流の一次情報の監視——契約先の告知が遅い場合でも、上流のステータスページ(今回ならCyberSource)を直接見れば復旧の進捗を先に掴めることがある。段階3のマッピングで上流のステータスページURLを控えておくのは、このためだ。

Q2. 決済手段の複線化は、中小企業に現実的か。

全面的な二重化は不要で、費用対効果も合わない。現実的なのは、(1)既に導入済みの複数手段(カード、コード決済、現金、銀行振込)を「障害時にどれへ誘導するか」という手順として整備する、(2)新規に足すなら、依存マップを見て上流が重ならない手段を選ぶ、の2点だ。前述のとおり、上流が同じ2社を並べても冗長化にならない。手段を増やす投資より先に、「切り替えの手順と案内文」を用意するほうが、費用ゼロで効果が出る。

Q3. サイバー攻撃ではなかったのなら、セキュリティ対策とは無関係の話か。

無関係ではない。事業継続の観点では、攻撃起因と非攻撃起因は「売上が止まる」という同じ結果に合流する。BCPや初動体制を原因別に別冊で作る必要はなく、「決済が止まった」「基幹が止まった」という事象起点で手順を作り、原因究明は並行して走らせるのが正しい。むしろ今回のような非攻撃事例は、「うちは狙われないから大丈夫」という理屈が可用性リスクには一切通用しないことを示した点で、セキュリティと事業継続を分けて考えること自体の危うさを教えている。

Q4. 今回のような障害で、SLAに基づく返金は請求できるのか。

契約次第であり、一般論として楽観はできない。請求の相手は自社の直接契約先に限られ、その契約に第三者起因の免責やSLA除外があれば対象外になり得る。それでも、影響時間の記録を添えて問い合わせる価値はある。返金額そのものより、「この加盟店は障害を記録し、契約を読んで請求してくる」と契約先に認識させることが、以後の通知の速さや対応の優先度に効くからだ。あわせて、次回更新時に通知義務・報告書義務を条項化する交渉材料にもなる。

GXOに相談すべきタイミング

以下のいずれかに当てはまるなら、次の障害が起きる前に、一度外部の目を入れることを勧める。

• 売上の過半が通る決済・EC・課金の経路について、「直接契約先のその先」を誰も答えられない
• 外部サービスの契約書を、SLA・免責・障害通知の観点で読んだことが一度もない
• 7月16日の障害当日、店頭やECで顧客に何を案内するか、その場の判断に任せてしまった
• 自社システムの外注で、ロールバック手順や変更凍結期間を仕様・契約に入れたことがない
• 決済やシステムの見直しを考えているが、何を基準にベンダーを比較すべきか軸がない

GXOは、システム開発の発注側支援を軸に、売上経路の依存マッピング、外部サービス契約の点検観点の整理、RFP・契約への変更管理要件の織り込み、障害時初動の設計までを一貫して支援している。「うちの売上は、どこの誰の変更作業に握られているのか」——この問いに答えられる状態を作るのが出発点だ。現状の共有だけでも構わないので、お問い合わせから相談してほしい。

まとめ——依存は消せない。見えない依存だけが危険だ

外部サービスの上に売上を乗せること自体は、間違いではない。決済基盤を自前で持つ会社は存在しないし、SaaSやクラウドの活用は中小企業にとって合理的な選択であり続ける。依存そのものは、消すべきものではなく、経営の前提である。

危険なのは依存ではなく、見えていない依存だ。今回の障害は、契約書のない1社の、攻撃ですらない変更作業が、全国の売上を数時間止められることを示した。そして同じ構造は、あなたの会社の決済にも、カートにも、課金にも、外注したシステムにも埋まっている。売上が通る道を3段階で描き、契約書を障害の目で読み直し、自社の発注には変更管理を仕様として書き込む。どれも技術投資ではなく段取りであり、始めるのに必要なのは表計算1枚と半日の時間だけだ。次にどこかの誰かがリリースボタンを押す日までに、間に合わせてほしい。

---

参考ソース

• Authorizations and Decision Manager Service Disruption (INC26452085)｜CyberSource公式ステータスページ
• エポスカードのご利用について｜エポスカード(2026年7月16日)
• 2026年7月に起きたクレジットカード決済の全国的障害についてまとめてみた｜piyolog(2026年7月17日)

※障害の原因(プログラム変更の影響・外部からの攻撃ではない)に関するビザ・ワールドワイド・ジャパンの説明は、ITmedia Mobileの取材報道(piyologの整理を含む)に基づく二次情報であり、CyberSource公式ステータスページには原因の記載がない。影響を受けた各社名は、各社告知または報道で確認できた範囲のみを記載した。本稿の記載は2026年7月19日時点の情報に基づく。