はじめに：全国でカード決済が使えなくなった朝

2026年7月16日の朝、全国各地でクレジットカード決済の障害が発生しました。午前8時過ぎから、コンビニのレジや駅の券売機、モバイルSuicaのチャージ、ECサイトの決済などで、一部のクレジットカードが使えなくなったのです。店舗では、現金や別の決済手段を案内する動きも見られました。

運用保守に携わる私たちにとって、今回の障害には特に考えさせられる点があります。それは、「自社のシステムには障害が発生していないのに、サービスが利用できなくなった」事業者がいたことです。

実際、あるカード会社は自社システムに問題はなかったと説明し、ある決済ネットワーク事業者は「自社の障害ではない」と明言しました。それでも利用者から見れば、「カードが使えない」という事態に変わりはありません。

本記事では、今回の障害について、各社の公表資料や報道をもとに経緯を整理します。そのうえで、「自社に障害がなくても、外部サービスの影響を受ける」という、現代のシステム運用が抱える課題を、ITILの関係管理やサプライヤー管理、インシデント管理などのプラクティスに照らして考えます。

なお、障害の原因については、Visaの日本法人がプログラム変更の影響であったと説明しています。一方、各社が公表した障害情報と、この原因との関係がすべて明らかになっているわけではありません。本記事では、各社が公表した事実と、そこから読み取れる運用上の教訓を分けて考えていきます。

第1章：何が起きたのか――各社で異なる障害の説明

まず、公表された情報をもとに、2026年7月16日の動きを時系列で振り返ります。

午前8時10分頃：三井住友カードが、後にこの時刻から一部加盟店でカードが利用できない事象が発生していたと公表。

午前中：CARDNET（日本カードネットワーク）が、通常より多くの決済エラーを検知し、加盟店向けページに障害検知の報告を複数回掲載。

午前10時頃：JR東日本のモバイルSuicaで、外部のクレジットカードシステムの障害によりカード決済がしづらくなっていた事象が解消。

午前10時40分頃：CARDNETの加盟店向けページに回復報が掲載。ITmedia NEWSも、この頃までに障害が解消したとみられると報道。

正午過ぎ：三井住友カードが復旧を案内。同社は、障害の発生時間を午前8時10分頃から午後0時8分頃までと説明。

ここで注目したいのは、関係する事業者によって、障害についての説明が異なっていたことです。

三井住友カードは、一部加盟店でカードが利用できなくなった原因を「国際ブランドネットワーク障害」と説明しました。

JR東日本は、モバイルSuicaへのチャージなどがしづらくなった原因について、「外部クレジットカードシステム」の障害と説明しました。ただし、具体的にどのシステムで障害が起きたのかまでは明らかにしていません。

一方、CARDNETは、自社システムの障害ではないと説明しています。同社の加盟店向けページに掲載された障害情報は、加盟店で通常より多くの決済エラーが発生したことを検知したものであり、自社システムの障害を意味するものではなかったということです。

このように、各社が把握していた状況や説明の対象は同じではありませんでした。

復旧時刻についても、モバイルSuicaは午前10時、三井住友カードは午後0時8分頃と、案内された時刻に違いがあります。ただし、これは必ずしも説明の矛盾を意味しません。各社で利用しているシステムや確認しているサービスの範囲が異なるため、影響が解消するタイミングにも差が生じた可能性があります。

利用者にとっては同じ「カードが使えない」という問題でも、裏側では複数のシステムや事業者が関係しています。そのため、障害の発生直後から全体像を把握することは簡単ではなかったと考えられます。

第2章：Visaが説明した障害の原因

障害の翌日となる2026年7月17日、Visaの日本法人が原因について説明しました。

ITmedia Mobileの報道によると、Visaの日本法人は、今回の障害について次のように回答しています。

「加盟店接続サービスのプログラム変更の影響によるもので、外部からの攻撃等によるものではございません」

原因となったのは、Visaが提供する加盟店接続サービス「Cybersource」におけるプログラム変更の影響だとしています。

また、Visaの基幹ネットワークであるVisaNetについては、次のように説明しました。

「本事象発生中も正常に稼働しており、影響はございませんでした」

つまり、Visaの説明によれば、今回の障害は外部からの攻撃によるものではなく、Cybersourceのプログラム変更の影響で発生したものです。一方で、VisaNet自体は正常に稼働していたことになります。

Cybersourceの公式ステータスページにも、2026年7月16日に決済処理の遅延やタイムアウトが発生した記録が残されています。

ここで気になるのは、やはりプログラム変更が障害の引き金になったという点です。

以前の記事でも取り上げましたが、システムへの変更は、サービスの安定稼働に影響を与える可能性があります。今回も、Visaの説明によれば、プログラム変更が障害につながりました。

ただし、変更に伴うテストや承認などが適切だったかどうかは、公表された情報からは判断できません。プログラム変更が原因だったからといって、変更管理に不備があったと断定することはできない点には注意が必要です。

また、三井住友カードが説明した「国際ブランドネットワーク障害」と、Visaが説明したCybersourceの障害が、技術的にどこまで同じ事象を指しているのかも、公表情報だけでは完全には確認できません。

それでも、今回の障害から学べることはあります。

それは、自社のシステムが正常に動いていても、外部サービスの障害によって利用者へのサービス提供に支障が生じるということです。

第3章：なぜ「自社は無事」でもサービスが止まるのか

今回の事案を運用保守の視点で考えると、原因となったプログラム変更そのものだけでなく、決済サービスが多くの事業者によって支えられている点にも目を向ける必要があります。

私たちがクレジットカードで買い物をするとき、その裏側では、加盟店の決済端末やECサイト、決済代行会社、加盟店接続サービス、カード会社、国際ブランドのネットワークなど、さまざまなシステムが連携しています。

実際の決済経路はサービスによって異なりますが、複数の事業者が役割を分担している点は共通しています。

利用者は普段、その仕組みを意識することはありません。しかし、決済に必要な外部サービスの一つで障害が起きれば、他のシステムが正常でも決済を完了できなくなる場合があります。

今回、三井住友カードは自社システムに障害がなかったと説明し、CARDNETも自社の障害ではないとしています。それでも、一部のカード決済は利用できなくなりました。

影響はカード会社だけにとどまりません。コンビニやECサイト、交通系サービスなどでも、カード決済ができない、あるいは利用しづらくなる事象が報告されています。

こうした状況を見ていると、以前取り上げた通信障害やクラウド基盤の障害と同じ問題が見えてきます。

それは、自社からは見えにくい外部サービスへの依存です。

自社のサーバーやネットワークに問題がなくても、その先で利用しているサービスが止まれば、自社のサービスにも影響が及びます。

しかも、障害が発生した時点で、どの外部サービスに原因があるのか分からないこともあります。自社が直接契約している事業者ではなく、さらにその先で利用されているサービスに原因がある場合、状況の把握は一段と難しくなります。

運用保守の現場では、自社のシステムが正常に稼働していることを確認できれば、ひとまず安心したくなるかもしれません。

しかし、利用者から見れば、自社システムの障害なのか、外部サービスの障害なのかは関係ありません。使いたいサービスが使えなければ、同じ障害として受け止められます。

そう考えると、「自社のシステムが正常であること」と「利用者にサービスを提供できていること」は、分けて考える必要があるのではないでしょうか。

ITILで考える備え

では、こうした外部サービスに起因する障害に対して、運用保守の担当者はどのような備えができるのでしょうか。

ここからは、ITILのプラクティスを参考に、日頃の運用で意識しておきたいことを考えます。

関係管理・サプライヤー管理：依存の連鎖を把握する

ITILには、サービスに関わるステークホルダーとの関係を維持・改善する「関係管理」と、サービス提供に必要なサプライヤーを管理する「サプライヤー管理」というプラクティスがあります。

今回の事案から考えたいのは、自社が直接契約している相手だけでなく、その先で利用されている外部サービスにも目を向けることです。

決済のように多数の事業者が関わるサービスでは、自社の直接の委託先だけでなく、委託先が利用する別の事業者やサービスの障害が、自社に影響することがあります。

もちろん、すべての依存関係を把握するのは現実的ではありません。契約関係やセキュリティ上の理由から、外部サービスの構成を詳しく確認できない場合もあります。

それでも、少なくとも自社サービスに大きな影響を与える外部サービスが何かは、整理しておきたいところです。

例えば、重要な外部サービスについて、次のような点を確認しておくことが考えられます。

どの業務やシステムが、その外部サービスに依存しているのか。

障害が発生した場合、どの範囲に影響が及ぶのか。

障害情報は誰から、どのような経路で入手できるのか。

障害が長期化した場合、代替手段はあるのか。

特に、委託先との契約や運用上の取り決めで、障害時の連絡方法や情報提供の範囲を明確にしておくことは重要です。

障害が起きてから初めて「どこに問い合わせればよいのか」と調べ始めるのでは、初動が遅れてしまいます。

インシデント管理：原因が分からない段階で、どう対応するか

今回の障害では、発生直後から原因が明確になっていたわけではありません。

三井住友カードやCARDNETなどが自社システムでの障害を否定する一方、利用者の間ではカードが使えない状況が続いていました。

こうした場面で考えたいのが、ITILのインシデント管理です。

インシデント管理では、障害の根本原因を究明することよりも、まずサービスへの影響を抑え、通常の状態に戻すことを重視します。

つまり、原因が分からないからといって、利用者への対応まで止めてよいわけではありません。

例えば、外部の決済サービスに問題があると考えられるものの、詳細が分からない場合には、確認できている範囲で状況を伝えることができます。

「現在、一部のクレジットカード決済が利用できない状況です。原因は調査中ですが、現金や他の決済手段をご利用ください」

このように、原因を断定せずに発生している事象を伝え、利用者が取れる行動を案内することは可能です。

実際、今回の障害でも、現金や交通系ICカード、コード決済サービスなどの利用を案内した店舗があったと報じられています。

一方で、今回のように複数の事業者が関係する障害では、利用者に何を説明するかという点も難しくなります。

自社で確認できた事実と、外部事業者から提供された情報を整理しなければ、誤った原因を案内してしまう可能性があります。また、事業者によって復旧状況が異なれば、利用者に伝える内容も変わってきます。

そのため、平時から障害時の情報収集先や社内の連絡体制、利用者への案内方法を決めておくことが重要になります。

原因が分からない段階であっても、何が起きているのか、現在何を確認しているのか、利用者はどうすればよいのかを伝える。

こうした初動対応が、障害時の混乱を抑えることにつながります。

サービス継続管理：外部サービスが止まったときの代替手段

もう一つ考えたいのが、サービス継続管理の観点です。

今回の障害では、クレジットカードが使えない場合でも、現金や他の決済手段が利用できる店舗がありました。

しかし、すべてのサービスで同じように代替手段を用意できるとは限りません。例えば、オンライン決済や特定の外部サービスに依存した業務では、利用者が別の手段を選べない場合もあります。

また、決済手段が複数あったとしても、それらが同じ決済基盤に依存していれば、同時に影響を受ける可能性があります。

この点は、サービス継続を考えるうえで見落としたくないところです。

決済手段を複数用意するだけでなく、それぞれがどのような仕組みに依存しているのかを把握し、障害時に本当に代替手段として使えるかを確認する必要があります。

そのためには、以前の記事でも取り上げた障害訓練が役立ちます。

例えば、「外部の決済サービスが突然利用できなくなった」という状況を想定してみるのはどうでしょうか。

障害情報をどこから入手するのか。利用者には誰が、何を伝えるのか。代替手段への切り替えは可能なのか。外部事業者から復旧の連絡が来ない場合、どのように対応を続けるのか。

こうした点を訓練で確認しておけば、実際に障害が起きたときにも、対応に迷う場面を減らせるはずです。

外部サービスそのものを自社で復旧させることはできなくても、障害による影響を小さくするための準備はできます。

最後に：見えない依存を、見える備えに

社のサーバーやネットワークが正常でも、依存している外部サービスで障害が起きれば、利用者に影響が及びます。しかも、外部サービスとの関係が複雑になるほど、原因や影響範囲の把握には時間がかかります。

だからこそ、日頃から外部サービスへの依存関係を把握し、障害が起きた際の連絡体制や利用者への説明、代替手段を準備しておくことが重要です。

ITILの関係管理やサプライヤー管理、インシデント管理、サービス継続管理の考え方は、こうした備えを整理する際の参考になります。

「自社のシステムは正常だから大丈夫」ではなく、「自社が利用している外部サービスが止まったら、どうするか」。

皆さんが担当しているサービスにも、普段は意識していない外部サービスへの依存があるのではないでしょうか。

どの外部サービスが止まると、自社の業務や利用者に影響が出るのか。そのとき、誰に連絡し、利用者に何を伝えるのか。

障害が起きてから冷や汗をかく前に、一度確認しておきたいところです。

※本記事の障害経緯や原因に関する記述は、各社の公表資料および報道をもとにしています。Visa日本法人はCybersourceのプログラム変更を障害の原因として説明していますが、関係各社が公表した事象との技術的な関係がすべて確認されたわけではありません。また、ITILの各プラクティスを用いた考察は筆者の見解であり、ITILの公式な見解や、記事中で言及した各事業者の見解を示すものではありません。

参考文献

ITmedia Mobile（2026年7月17日）「“クレカ障害”の根本原因、Visa日本法人が明かす――『外部からの攻撃等によるものではございません』」
https://www.itmedia.co.jp/mobile/spv/2607/17/news103.html

ITmedia NEWS（2026年7月16日）「朝のクレカ障害、復旧か　『国際ブランドネットワーク』でトラブル【更新】」
https://www.itmedia.co.jp/news/articles/2607/16/news071.html

ITmedia Mobile（2026年7月16日）「“クレカ障害”の原因、三井住友カードが明らかに　都内店舗は『現金や交通系ICカードをご利用ください』と客に案内」
https://www.itmedia.co.jp/mobile/amp/2607/16/news102.html

日本経済新聞（2026年7月16日）「クレジットカード、一時使えず　国際ブランドの通信障害か」
https://www.nikkei.com/article/DGXZQOUD162GI0W6A710C2000000/

piyolog（2026年7月17日、以降更新）「2026年7月に起きたクレジットカード決済の全国的障害についてまとめてみた」
https://piyolog.hatenadiary.jp/entry/2026/07/17/065349

Cybersource（2026年7月）「Authorizations and Decision Manager Service Disruption」
https://status.cybersource.com/incidents/ry0rqlcp824c

PeopleCert「ITIL 4 Practitioner: Relationship Management」
https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-4-practitioner-relationship-management-3865

PeopleCert「ITIL 4 Practitioner: Supplier Management」
https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-4-practitioner-supplier-management-3869