8月、金融安定理事会（FSB）のアンドルー・ベイリー議長は、G20の財務大臣らに対し、具体的な警告を発した。すなわち、世界の金融安定に対する差し迫った脅威は、フロンティアAIそのものではなく、ごく少数のサードパーティ技術プロバイダーに集中しているフロンティアAIであるという。同議長は規制当局に対し、「金融システムにとって、最も差し迫った懸念は、フロンティアAIがサイバーリスクに及ぼす潜在的な影響である。 フロンティアAIは、サイバーリスクの速度、規模、経済性を実質的に変える可能性があり、特にサードパーティのサービスプロバイダーへの依存度が極めて高いことから、システム全体にわたって市場の信頼を損なう恐れがある。」
ベイリーが指摘しているのは、金融システムの基盤に少数のプロバイダーが集中しているという、システム的な規模でのサードパーティ・リスクである。そのうちの1社が侵害された場合、被害は1社内に留まることはない。連鎖的に拡大していくのだ。
ほとんどのサードパーティ・リスク管理プログラムでは、この集中リスクを把握することができません。御社のプログラムには、ベンダー一覧、質問票、更新カレンダーは備わっていますが、ベンダー集中リスクが表面化した際に、実際にどの程度のリスクにさらされているのかという可視性が欠けています。
ベンダーリストに集中リスクが反映されない理由
もはや、大規模な企業がすべてを単独で運用していることはありません。中核となる財務システムはあるクラウドプロバイダー上で稼働し、メールは別のプロバイダー、分析システムはさらに別のプロバイダー、セキュリティ監視はまた別のプロバイダーで運用されています。これらのプロバイダーは、一覧上では別々のものとして表示されますが、その整然としたリストの裏側では、目に見えないインフラの相互依存関係が存在しており、それが企業のリスクプロファイル全体を根本的に変えているのです。
実際にこれらの依存関係を可視化してみると、状況は一変します。最も重要なプロバイダーのうち3社は、同じクラウドリージョンでインフラを運用している可能性があります。2社は、インテリジェンス機能に同じAIプロバイダーを利用しているかもしれません。また、1社は、他のベンダーが提供していない重要なAPIに単一障害点を抱えている可能性があります。実際の依存関係グラフを作成してみると、それは5つの独立したベンダーではなく、同じインフラに依存している5つのベンダーであり、すべてが同じ障害の影響を受けやすいことがわかるのです。
ベンダー集中リスクは、表面化するまでは目に見えず、表面化した時にはすでに手遅れとなっている。
個別のプログラムの内部に潜む集中リスク
ある企業では、ベンダー評価プログラムを実施しており、銀行は毎年50社のベンダーと面談を行い、各ベンダーを個別に評価しています。質問内容は単純明快です：
- このベンダーにはセキュリティ対策が講じられていますか？ はい。
- 事業継続計画？ はい。
- 稼働率99.9％？ はい。
すべての回答が「はい」であるため、すべてのベンダーが承認されました。
その後、あるベンダーで、共有インフラストラクチャ層の障害に起因するサービス停止が発生した。銀行はこれについて一切問い合わせていなかった。というのも、ベンダー評価プログラムは個々のベンダーを評価するために構築されたものであり、ベンダー同士がどのように相互に依存しているかを把握するためのものではなかったからだ。 同じ共有層を利用していた他の2社の重要ベンダーも影響を受けた。トレーディングデスクは2時間にわたりオフラインとなり、その後、CISOは規制当局に対し、なぜ銀行がベンダーのアーキテクチャにおける重要な依存関係について尋ねなかったのか、またベンダー間のその依存関係を結びつけて把握していなかったのかを説明せざるを得なくなった。
ベンダー向けアンケートは、送信した当日の状況を反映した「その時点でのスナップショット」に過ぎず、日が経つにつれてその正確性は低下していきます。ベンダーのセキュリティ態勢は変化し、買収されることもあり、インフラは移り変わり、依存関係も変化していきます。しかし、更新時まで再調査が行われないアンケートには、こうした変化は一切反映されません。1年後には、ベンダーの状況は3回も変化しているにもかかわらず、リスク評価では依然として前年の回答が使用され続けているのです。
なぜリスク管理プログラム間で連携が取れていないのか
集中リスクは、連携すべきであるにもかかわらず連携が取れていない複数のプログラムの交差点に存在するため、表に出てこないままになっている。ほとんどの企業には、相互に可視性が必要とされる3つの独立した機能があるが、実際にそれが確保されていることはめったにない。
サードパーティ・リスク・プログラムでは、ベンダーのセキュリティ対策、事業継続性、およびデータガバナンスについて評価を行います。この評価により、ベンダーAは決済データを処理していることから、重要度が高いと特定され、「高リスク」と評価されました。 一方、貴社のオペレーショナル・レジリエンス・プログラムでは、重要サービスとその依存関係をマッピングしており、市場運営に不可欠な3つのサービスが、いずれも主要なサービスコンポーネントにおいて同じプロバイダーを利用していることが判明しました。オペレーショナル・レジリエンス・チームはこれをテスト計画に明記しましたが、リスクとして正式にエスカレーションは行っていません。同時に、貴社のサイバーセキュリティ・プログラムでは、サードパーティのセキュリティインシデントを監視し、どのインシデントが貴社の業務に影響を与える可能性があるかを追跡しています。ベンダーAにはインシデントが発生していないため、ベンダーAは引き続き承認された状態を維持しています。
ここで、これら3つのサービスすべてが依存している共有インフラストラクチャのプロバイダーがダウンし、3つの重要なサービスがすべて同時に停止してしまいます。その結果、運用レジリエンスのテストは失敗に終わります。 各ベンダーが個別に評価されていたため、サードパーティ・リスク管理プログラムにはエスカレーションの仕組みがなく、また、障害が発生したプロバイダーが主要ベンダーリストに含まれていなかったため、サイバーセキュリティプログラムには追跡すべき対象がありません。そのプロバイダーは依存関係レイヤーに位置していたのです。本来なら封じ込め可能だったはずの障害が、3つの別々のプログラムの間の隙間に潜むシステミックリスクへと変貌し、どのプログラムもその発生を予見できていませんでした。
依存関係のマッピングへ進む
このギャップを埋めるには、ある転換が必要です。それは、「ベンダー一覧」から「ベンダー依存関係マップ」への移行です。ベンダー一覧は「当社はこのベンダーと取引している」という情報を示すのに対し、ベンダー依存関係マップは「当社はこのベンダーと取引しており、このベンダーは他の3つのベンダーに依存しており、それらのベンダーはこのリージョンでインフラを共有しており、そのリージョンに障害が発生した場合、これらの重要なサービスが停止し、それが当社の統制機能に連鎖的な影響を及ぼす」という情報を示します。
ここで、サードパーティ・リスク・インテリジェンスが真価を発揮します。Archer Evolv™は、ベンダーとの関係、ベンダーへの依存関係、共有インフラのリスクを自動的に追跡し、変化が発生したその場で特定するとともに、その影響を貴社の義務や統制に照らし合わせて可視化します。さらに重要なのは、サードパーティ・リスクを貴社の実際の統制環境と結びつける点です。 同じ地域にある3社のベンダーに依存しているという事実だけでなく、どの義務が各ベンダーに依存しているか、その地域で障害が発生した場合にどの統制が機能しなくなるか、そして具体的にどれだけのリスクを負っているかまで把握できます。金融安定理事会（FSB）がAIプロバイダーの集中化について警告を発した際、それが自社の問題となったとしても、慌てる必要はありません。すでにその全体像を把握しているからです。
継続的なモニタリングによって課題が明らかになる
サードパーティを継続的に監視している企業は、集中リスクがシステム全体に波及する前にそれを検知します。こうした企業は、年次アンケートや数ヶ月遅れて届く情報漏洩通知を通じてではなく、ベンダーのインシデントをリアルタイムで把握しています。インフラストラクチャの変化は即座に把握されます。ベンダーのサービスが停止すれば、その影響が自社の業務にどの程度及んでいるかを、数分以内に正確に把握できるのです。
実用的なメリットは、対応時間の短縮です。ベンダーのリスクが表面化してから、貴社のプログラムが対応できるまでの時間が、数ヶ月から数時間に短縮されます。リスク管理チームは、スプレッドシートを使ったその場しのぎの対応から脱却し、本格的なリスク管理に取り組み始めます。また、ベンダーを年1回ではなく継続的に監視することで、ベンダーは常に最新の状態を維持できるようになります。
事後対応型のベンダー管理プログラムは、リスクが発生した後にそれを把握します。一方、継続的なインテリジェンスに基づいて運用されるプログラムは、リスクが発生する前にそれを把握します。これこそが、単なるベンダー管理プログラムと、正当性を説明できるプログラムとの違いです。選択すべきは、「監視を強化するか、緩和するか」ではなく、「集中リスクに先手を打てる監視」と、「連鎖反応が始まってからその不備を説明せざるを得なくなる監視」との違いなのです。
Archerのサードパーティ・リスク・インテリジェンスのデモをご覧ください。
これは、アーチャーがGRC業界のニュースやイベントについて取り上げる連載「The Signal」の一部です。規制変更の管理や、要件の変化に合わせてコンプライアンス・プログラムを適切に維持するために必要なことについては、 『The Signal：2026年9月号』をご覧ください。
よくある質問
サードパーティ集中リスクとは、組織が、同じ基盤となるサービスプロバイダー、インフラ、または技術を共有する複数のベンダーに依存している場合に生じるリスクです。共有されているプロバイダーの1つに障害が発生すると、複数のベンダーや重要なビジネスサービスに同時に影響が及ぶ可能性があります。金融機関やその他の規制の厳しい組織にとって、こうした依存関係は、個々のベンダー評価では特定できないような、システミックな運用リスクやサイバーセキュリティリスクを引き起こす可能性があります。
組織は、第三者、その下請け業者、クラウドプロバイダー、AIプロバイダー、およびその他の重要なインフラへの依存関係の間にあるつながりを可視化することで、ベンダー集中リスクを特定することができます。これらの関係を重要なビジネスサービス、規制上の義務、および内部統制と結びつけることで、リスク管理チームは共通の障害発生ポイントを特定し、サービス中断による潜在的な影響を評価しやすくなります。また、継続的なモニタリングを行うことで、ベンダーとの関係や依存関係の変化が重大なリスクにつながる前に、それを検知することも可能です。
従来のサードパーティ・リスク管理では、多くの場合、アンケート、セキュリティ評価、定期的なレビューを通じて、ベンダーを個別に評価します。これらの活動は個々のベンダーのリスクを評価する上で役立ちますが、複数のプロバイダーやビジネスサービスに共通する依存関係が明らかにならない可能性があります。サードパーティ・リスク、オペレーショナル・レジリエンス、サイバーセキュリティ・プログラム全体を可視化できなければ、組織は、複数の重要な業務を同時に混乱させる可能性のある共通の障害要因を見落としてしまう恐れがあります。
継続的なモニタリングにより、組織は定期的な評価の合間にも、ベンダーのセキュリティ態勢、サービスの可用性、所有権、およびインフラ間の依存関係の変化を把握することができます。これを依存関係マッピングと組み合わせることで、リスク管理チームは、ベンダーの業務中断によってどの重要なサービス、統制、および規制上の義務が影響を受ける可能性があるかを把握できるようになります。Archer Evolv™ などのサードパーティ・リスクインテリジェンス・ソリューションは、ベンダーとの関係や新たなリスクを、組織のより広範なリスクおよびコンプライアンスの枠組みと結びつけることで、より的確かつタイムリーな意思決定を支援します。
