サイバー攻撃の被害はシステムの管理境界を越えて広がる

by

2026 年 9 月末から 10 月にかけて、国内ではクラウドサービスへのランサムウェア攻撃、大規模な会員情報の流出、大学の情報基盤障害などが相次いで公表された。サイバー攻撃を説明するとき、近年は生成 AI による攻撃作業の自動化や、攻撃技術の高度化に注目が集まる。AI によって脆弱性の探索や攻撃用プログラムの作成が高速化すれば、攻撃者が試行できる対象や手順は増える可能性がある。しかし、それによって一つの企業から数百万件の情報が流出する理由や、一つのクラウドサービスの障害が数百の企業・自治体に影響する理由まで説明できるわけではない。

攻撃者がどのような手段で侵入したかという問いと、侵入された場所からどれほどの被害が生じるかという問いでは、調べるべき対象が異なる。前者では脆弱性、認証情報、攻撃手順、攻撃者の能力などが問題になる。後者では、侵害されたシステムが何を管理し、どれほどの情報や機能が集まり、ほかの業務や組織がどのように依存しているかが問題になる。同じ種類の攻撃であっても、影響が一台のサーバーに収まる場合と、複数の組織の業務停止や大量の個人情報流出につながる場合とでは、侵害された資源の位置づけが異なる。

例えば、一つの業務システムが停止しても、ほかの業務が独立して動作し、必要なデータを別の環境から取得できれば、影響を限定できる可能性がある。一方、認証、計算資源、データ保存などの機能を共通基盤へ集約している場合、その基盤の障害が複数の業務へ同時に及ぶことがある。個人情報についても、一人分の情報への不正アクセスと、大量の会員情報を保存したシステムへの不正アクセスでは、攻撃者が取得し得る情報の範囲が異なる。被害の規模は侵入という出来事だけから決まるのではなく、侵入された場所に何が存在し、そこから何に到達できるかという条件に左右される。

さらに、被害の規模と回復可能性も分けて考える必要がある。停止したシステムは、独立したバックアップや代替環境が確保されていれば復旧できる場合がある。しかし、第三者が取得した情報の複製は、元のシステムを修復しても第三者の手元に残る可能性がある。システム停止によって失われた取引機会や業務時間も、サービスの再開によって自動的に取り戻せるものではない。サイバー攻撃の深刻さを評価するには、侵入に使われた技術だけでなく、侵害がどのような依存関係を通じて損失へ変わり、その損失のうち何が回復可能なのかを確認する必要がある。

1. 攻撃技術の高度さだけでは被害の深刻さを説明できない

攻撃者が生成 AI を使って偵察やプログラムの作成を高速化すれば、攻撃に必要な時間や労力が変化し得る。Google Threat Intelligence Group は 2026 年 9 月、攻撃者が AI を利用して認証情報の収集や複数段階の攻撃作業を自動化した観測事例を報告した[1]。攻撃手順の一部が自動化されれば、人間が個別に操作していた工程を連続して実行でき、同じ時間内に試行できる対象が増える可能性がある。これは攻撃の実行能力や効率に関する変化である。一方、侵入が成功した場合に取得できる情報の量や、停止する業務の範囲は、対象システムの構成や権限、依存関係にも左右される。攻撃能力が高まったという事実だけでは、個別事件の被害規模を説明する因果関係は完成しない。

この区別を欠くと、重大な被害が発生したという結果から、攻撃にも高度な技術が使われたはずだと推測しやすくなる。大規模な情報流出を見て AI による攻撃を想定したり、多数のシステムが停止したことから複雑な侵入手法を推定したりする説明である。しかし、被害規模から攻撃手法を一意に特定することはできない。既知の脆弱性や流出した認証情報が悪用された場合でも、侵害された権限から大量の情報や共通の管理機能に到達できれば、被害が広範囲に及ぶ可能性がある。既稿「AI を一つの物語に閉じ込めない」でも、一つの技術的な説明枠によって異なる現象をまとめると、評価すべき違いを見失いやすいという問題を扱った[2]。サイバー攻撃についても、AI の利用という属性と、実際に被害を生み出した条件を区別することで、検証すべき事実が明確になる。

2026 年 10 月 7 日、IDC フロンティアは、IDCF クラウドの東日本リージョン 1 で発生した障害について、ランサムウェア攻撃によるものと発表した[3]。翌日の公表では、tesla、henry、pascal、joule の四つのゾーンで仮想サーバーが停止し、再起動できない状態となり、495 の企業・自治体が影響を受けていると説明している。対象ゾーンの顧客データは取り出しや復元が困難な見通しであり、同社は顧客自身が保持するバックアップを用いた再構築を案内した[4]。

この事件では、侵害されたクラウドサービスの内部で生じた障害が、そのサービスを利用する企業・自治体のシステム利用へ直接影響した。仮想サーバーを提供する基盤が正常に動作していれば、利用者はその上で業務アプリケーションやデータベースを運用できる。しかし、仮想サーバー自体が停止し、再起動もできなくなると、利用者のアプリケーションに異常がなくても、そのアプリケーションを動作させる前提が失われる。さらに、仮想ディスクに保存されたデータを取り出せない場合、別の環境へ移行する作業も制約を受ける。基盤への依存が、利用者側での業務継続や復旧の選択肢に影響するのである。

ただし、今回の攻撃でクラウド内部のどの構成要素が侵害され、どのような経路で仮想サーバーの停止やデータの取り出し困難に至ったのかは、当該公表からは確定できない。管理基盤、仮想化基盤、ストレージなどの内部構成を想定することは技術的な分析には役立つが、実際に侵害された構成要素を特定するには追加の証拠が必要である。一方、仮想サーバーの利用不能と、顧客自身による再構築が求められている事実は確認できる。侵入経路の解明を待たなくても、利用者が共通基盤へ依存していたことと、その依存が復旧作業に影響したことは分析対象になる。

同年 9 月、タイムズカーは Web システムへの不正アクセスを確認し、約 660 万アカウントの情報が第三者に取得されたと公表した[5]。対象には現在の会員だけでなく、退会済みの会員や入会手続きが完了していない人も含まれる。追加調査では、そのうち約 160 万アカウントについて、運転免許証画像、現住所確認書類画像などの本人確認書類も流出したと判明した[6]。同社は不正アクセスによるサービス提供への影響を確認しておらず、サービスを継続していると説明している。IDC フロンティアの事件ではシステムの利用不能が中心的な被害として現れたのに対し、タイムズカーでは保存されていた情報の機密性が失われた。

タイムズカーの事例で被害規模を考える際には、約 660 万という数字が何を表しているかが重要になる。これは流出が確認されたアカウント数であり、重複を除いた人数や、同じ種類の情報が流出した人数をそのまま示すものではない。また、約 160 万アカウントで本人確認書類画像の流出が確認されたことは、すべての流出アカウントに同じ書類画像が含まれていたことを意味しない。情報の種類と対象範囲を分けなければ、被害の性質を正確に評価できない。

それでも、退会済みの会員や入会未完了者を含む情報が保存され、第三者による取得の対象となったことには構造上の意味がある。利用者がサービスの利用を終了した後も情報が保持されていれば、その情報は保存期間中、保管先システムのセキュリティに依存し続ける。本人確認書類の画像は、本人がパスワードを変更するように簡単に内容を変更できる情報ではない。画像が流出したことだけで第三者による本人確認の突破が成立するわけではないが、不正な本人確認の試行などに悪用される可能性は残る。情報の保管期間と種類が、侵害後に残るリスクの期間や性質に関係する。

このような情報の集中が大量流出に結び付いたとしても、具体的にどの認証情報、脆弱性、権限が悪用されたかは別の問題である。一つのアカウントから全件を取得できたのか、複数の操作が必要だったのか、どの内部機能を通じて情報が取得されたのかは、公表された件数だけからは判断できない。既稿「正しい数字から間違った結論は作れる」で論じたように、数字の正確さは、その数字から導く説明の正しさを保証しない[7]。IDC フロンティアの 495 組織という影響範囲と、タイムズカーの約 660 万アカウントという流出件数は、それぞれ被害の規模を示す。一方、それらの数字を攻撃技術の高度さ、AI の関与、内部管理の具体的な不備の証拠として用いるには、追加の調査結果が必要になる。

比較対象 IDC フロンティア タイムズカー
確認された事象 仮想サーバーの停止・再起動不能と、顧客データの取り出し・復元困難が公表された。 会員情報と本人確認書類画像が第三者に取得された。
確認された規模 対象ゾーンを利用する 495 の企業・自治体が影響を受けた。 約 660 万アカウントの情報が流出し、そのうち約 160 万アカウントで本人確認書類画像の流出が確認された。
失われた性質 主としてサービスとデータの可用性が損なわれた。 主として個人情報の機密性が損なわれた。
被害に関係する構造 複数の企業・自治体が共通のクラウド基盤を利用しており、その基盤の障害が利用者側のシステム運用へ影響した。 現在の会員に加えて退会者や入会未完了者の情報も保存され、保存されていた情報が不正取得の対象となった。
影響を受ける主体 クラウド上でシステムを運用する企業・自治体が直接影響を受け、そのシステムの利用者にも影響が及ぶ可能性がある。 現会員・退会者・入会未完了者など、保管情報の本人が影響を受ける。
回復上の論点 代替環境に業務システムを再構築し、必要なデータを確保できるかが問われる。 流出した情報の複製を第三者から確実に回収・消去することは困難であり、情報の不正利用に対する継続的な対応が必要になる。
公表情報から確定できない事項 具体的な侵入経路、侵害された内部構成要素、データの復元困難に至った詳細な機序は確定できない。 具体的な侵入経路、悪用された権限、情報取得の内部手順は確定できない。

両事件では、失われた性質と復旧の条件が異なる。IDC フロンティアでは、仮想サーバーが利用不能になったため、顧客が別の環境でシステムを再構築し、業務に必要なデータを確保できるかが課題となる。タイムズカーでは、システムが稼働を続けていても、第三者に取得された情報の機密性は元の状態へ戻ったとはいえない。前者では共通基盤への依存が業務の可用性に関係し、後者では保存されていた情報の範囲と種類が、流出後の影響に関係している。

この比較から、サイバー攻撃の被害を説明する際に、少なくとも三つの異なる関係を確認する必要がある。第一に、攻撃者がどの手段で対象へ到達したかという侵入の関係である。第二に、侵害された資源から、どれほどの情報や機能に影響が及んだかという依存の関係である。第三に、その影響が生じた後、どの状態まで回復できるかという損失の関係である。三つの関係は連続しているが、最初の侵入手法が分かっただけでは、残りの二つが自動的に決まるわけではない。

攻撃技術の高度化は、侵入の機会や実行速度を変化させ得る。一方、侵害されたシステムに大量の情報が保存されていることや、多数の業務が同じ基盤に依存していることは、攻撃者が AI を使ったかどうかとは別に存在する。IDC フロンティアとタイムズカーの事例は、攻撃手法の詳細が未解明であっても、侵害された資源の役割、影響を受ける主体、復旧によって回復できる範囲を区別して分析できることを示している。被害の深刻さを左右する条件は、攻撃を実行する技術と、攻撃を受ける側のシステム構造の双方に存在する。

2. 集中管理は効率性と被害の集中を同時に生み得る

企業がクラウド基盤を共通化する理由は、計算資源の調達、運用、監視、保守を個別に実施する負担を減らせるためである。業務システムごとにサーバーやストレージを調達する場合、設備の容量管理、障害対応、更新作業などをそれぞれ実施する必要がある。共通基盤を利用すれば、こうした機能を集約し、複数の業務システムに同じ運用体制を適用できる。会員情報の集中管理にも、複数のサービスで本人情報を再利用し、問い合わせや会員管理を一元化できる利点がある。利用者ごとに異なる情報を複数のシステムで重複して管理する負担を減らせるため、集中管理は正常時の効率性に関する合理的な選択となる。

しかし、運用上の共通化は、障害や侵害の影響を受ける範囲にも関係する。例えば、複数の業務システムが同じ計算基盤やストレージに依存している場合、その基盤が利用不能になると、個々の業務アプリケーションが正常であっても処理を継続できなくなる。個別のアプリケーションに問題が発生した場合は、そのアプリケーションだけを停止して復旧できる可能性がある。一方、複数のアプリケーションが共有する基盤が停止すれば、直接攻撃されていないアプリケーションにも影響が及ぶ。共通化によって運用対象をまとめたことが、障害時には複数の業務が同時に影響を受ける条件になる。

IDC フロンティアの事例では、東日本リージョン 1 の四つのゾーンで発生した障害が、495 の企業・自治体に影響した。これらの組織が個別に運用していた業務システムのすべてが直接攻撃されたという意味ではない。共通のクラウドサービスを利用していたため、提供側の基盤障害が利用者側のシステム運用へ波及したのである。さらに、仮想サーバーの再起動やデータの取り出しが困難になったことで、顧客側の復旧作業にも制約が生じた。クラウドによって設備の運用を事業者に委ねられる一方、その設備が利用不能になった場合には、利用者自身の管理権限だけで復旧できる範囲が限定される。

情報の集中管理では、同じ構造が異なる形で現れる。複数の利用者の情報を一つのシステムで管理すると、登録、更新、本人確認、問い合わせ対応などを統一した手順で処理できる。一方、そのシステムへの不正アクセスによって大量の情報が取得可能になれば、個々の利用者が別々に情報を保存していた場合よりも、多数の利用者が同じ事件の影響を受ける可能性がある。情報を集中させたこと自体が不正アクセスの原因になるわけではないが、侵害された権限や機能から到達できる情報の範囲が広ければ、一度の侵害が大量流出につながり得る。

タイムズカーでは、現在の会員に加えて、過去に退会した人や入会が完了していない人の情報も流出対象となった。これは、サービスの利用状況と、事業者による情報の保管状況が必ずしも一致しないことを示している。利用者が退会しても、事業者が法令対応や本人確認、不正利用防止などの目的で情報を保管している場合、その情報は保存期間中、不正アクセスの対象になり得る。利用者によるサービスの利用が終了したことと、保管先システムへの依存が終了したことは異なる。情報の保存期間が長くなるほど、その期間中に発生する侵害によって過去の利用者が影響を受ける可能性も残る。

ローソンが 2026 年 10 月 8 日に公表した事件でも、ローソン ID の 215 万 5,345 件とアプリ予約の 26 件について、個人情報の漏えいが確認された。同社は、アプリ上で利用者本人に情報を表示するためのセキュリティ機構が不正アクセスを受けたと説明している[8]。会員情報を保管する機能に加えて、その情報を誰に表示するかを制御する機能も、情報の機密性を維持するうえで重要な役割を持つ。大量の情報が保存されていても、利用者ごとの参照範囲が適切に制限されていれば、個別の操作から取得できる情報を限定できる。一方、情報表示に関わる機構が侵害されれば、その機構から到達可能な情報が不正取得の対象になり得る。ただし、今回の事件で実際にどの権限やプログラムの不備が悪用されたかは、公表内容だけでは特定できない。

IDC フロンティア、タイムズカー、ローソンの三つの事例には、異なる資源が集中しているという違いがある。IDC フロンティアでは計算資源や仮想サーバーを提供する基盤への依存が問題となった。タイムズカーでは、多数の利用者に関する情報の保管が被害規模に関係した。ローソンでは、会員情報を表示するための機構への不正アクセスが、大量の情報漏えいを伴った。計算資源の集中は主として可用性の問題に結び付き、情報の集中は機密性の問題に結び付く場合がある。ただし、実際に損なわれる性質は、侵害された機能と、その機能から到達できる資源によって決まる。

比較対象 集中による平常時の利点 侵害時に影響が拡大する条件 事例との対応
計算資源・共通基盤 設備の調達、運用、監視、保守を共通化し、個別管理の負担を減らせる。 複数の業務システムが同じ基盤に依存している場合、基盤の利用不能が複数の業務へ同時に影響する。 IDC フロンティアでは、対象ゾーンの障害が複数の契約組織に波及した。
会員情報の保管 本人情報の登録、更新、問い合わせ対応などを一元化できる。 侵害された権限や機能から大量の情報に到達できる場合、多数の利用者の情報が一度に取得され得る。 タイムズカーでは、退会者や入会未完了者を含む大量の情報が流出した。
会員情報の表示機能 共通の仕組みを通じて、利用者本人に必要な情報を提供できる。 情報表示に関わる機構が侵害され、アクセス可能な情報の範囲が広い場合、複数利用者の情報が影響を受け得る。 ローソンでは、利用者本人への情報表示に関わるセキュリティ機構が不正アクセスを受け、大量の情報漏えいが確認された。
管理権限の共通化 複数の資源に対する設定変更や保守作業を共通の管理手順で実施できる。 共通の管理権限が侵害された場合、その権限で操作可能な複数の資源に影響が及ぶ可能性がある。 三事件について、共通管理権限の侵害が実際の原因だったかは、公表情報から確定できない。

表の各行は、集中管理の対象によって、影響が拡大する仕組みが異なることを示している。計算資源の場合は、共通の基盤が停止することで、その上に構築された複数のシステムが利用不能になる。会員情報の場合は、不正アクセスによって取得可能な情報の範囲が、影響を受ける利用者の数に関係する。管理権限の場合は、一つの権限から操作できる資源の範囲が問題になる。これらを区別すれば、集中管理という共通点だけから個々の事件の原因を決めつけることを避けられる。

共通基盤が被害を増幅し得るという構造は、事故の直接原因と、事故を拡大した条件を分けて考える既稿「タイタニック号事故から読み解く巨大システム運用の本質」とも接続する[9]。事故の発端が局所的であっても、複数の機能が同じ資源に依存し、その資源が利用不能になれば、影響は当初の障害箇所を超えて広がる。ただし、障害が発生したことと、障害の影響が拡大したことでは因果関係が異なる。前者を説明するには故障や侵入の経路を調べる必要があり、後者を説明するには機能間の依存関係や、資源を共有する範囲を確認する必要がある。

米国 NIST のサイバーレジリエンスに関する指針は、攻撃や侵害を予期し、耐え、回復し、状況に適応する能力を、業務や組織のリスクと結び付けて捉えている[10]。この考え方では、一台のサーバーが再起動できることと、そのサーバーに依存する業務が再開できることを区別する。例えば、業務アプリケーションを別の環境で起動できても、必要なデータを取得できなければ業務処理を再開できない。反対に、元のシステムが停止していても、独立した代替手段によって必要な業務を継続できる場合がある。技術的な構成要素の稼働状況だけでなく、業務を成立させる資源の組み合わせが維持されているかが、回復力の評価に関係する。

情報の集中管理については、保存される情報の性質も被害の深刻さを左右する。メールアドレスやパスワードに関する情報が漏えいした場合、利用者が認証情報を変更することで、一部の不正利用リスクを抑制できる可能性がある。一方、氏名、生年月日、住所、運転免許証画像などは、利用者自身が容易に変更できる情報ではない。本人確認書類の画像が漏えいしても、それだけで第三者による本人確認が必ず成立するわけではないが、情報の不正利用を試みる材料として長期間利用される可能性がある。保存する情報の種類によって、流出後に実施できる対処と、残存するリスクが異なるのである。

個人情報保護委員会のガイドラインは、個人データの安全管理や委託先の監督など、情報を扱う事業者が考慮すべき条件を示している[11]。事業者が個人情報を保管する際には、利用目的や法令上の要請に加え、保存期間中のアクセス制御、情報の削除、委託先での取扱いなどを検討する必要がある。例えば、本人確認のために取得した書類画像を保管する場合、その画像をどの業務で必要とし、誰が参照でき、いつまで保管するのかによって、侵害時に取得され得る情報の範囲が変わる。ただし、実際の保存期間や管理方法が適切だったかを判断するには、事業者ごとの保存目的、制度上の条件、アクセス権限、運用実態を確認する必要がある。

集中管理による効率性と侵害時の被害規模は、同じ構造の異なる側面である。計算資源を共通化すれば設備管理を効率化でき、会員情報を集約すれば登録や本人確認の処理を一元化できる。その一方で、共通基盤の停止は複数の業務に影響し、大量の情報を参照できる機能への侵害は多数の利用者に影響し得る。ただし、資源が集中しているという事実だけでは、実際の被害範囲は決まらない。管理権限、情報へのアクセス範囲、障害領域が分離されていれば、共通基盤を利用していても影響を限定できる場合がある。

集中管理を評価するうえで問われるのは、どれほどの資源を一か所に集めたかだけでなく、一つの侵害によってどれほどの資源に同時に影響が及ぶかということである。IDC フロンティアでは共通基盤への依存が業務の可用性に、タイムズカーでは保管された情報の範囲が機密性の侵害規模に、ローソンでは情報表示に関わる仕組みへの侵害が大量流出に関係した。平常時の効率性を生む集中管理の構造は、侵害時に影響が及ぶ範囲を規定する条件にもなる。被害の深刻さを理解するには、集中管理の有無に加えて、実際に共有されている資源、侵害された機能、そこから到達可能な範囲を区別して評価する必要がある。

3. 被害はシステムの管理境界を越えて広がる

企業や大学などの組織では、システムを管理する主体と、そのシステムに依存する主体が一致するとは限らない。大学の情報基盤は大学が管理するが、その上で授業を受け、教材を取得し、課題を提出するのは学生である。物流事業者が運用する配送情報システムには、出荷を委託した企業や、荷物の送り主・届け先の情報が保存される。こうした関係では、侵害されたシステムの管理者だけでなく、そこに業務や情報を依存させている主体まで被害を受ける可能性がある。

この構造を理解するには、システムの管理範囲と、侵害によって損失を受ける範囲を区別する必要がある。システムの管理者は、アクセス制御、脆弱性への対応、障害復旧などを実施する権限を持つ。一方、利用者や取引先は、その管理方法を直接変更できない場合がある。利用者自身の端末や業務システムが正常でも、依存先のサービスが停止すれば業務を継続できなくなる。また、利用者が自分の情報を適切に管理していても、別の事業者に提供した情報が侵害されれば、情報の機密性が損なわれる可能性がある。被害を受ける主体が、その被害を生み出したシステムを管理できるとは限らないのである。

3.1 共通情報基盤の停止は教育活動の継続を制約する

大阪公立大学では 2026 年 10 月 2 日に情報基盤システムの大規模障害が発生し、教務、教育支援、メール、ネットワークなどの機能に影響が及んだ。授業は同月 8 日まで休講となり、大学は臨時の学習管理システムや学生向けの情報提供手段などを整備して、9 日から対面授業を再開した[12]。対面授業の再開は、従来の情報基盤が全面的に復旧したことを意味するものではなく、教育活動に必要な一部の機能を代替手段によって確保したことを示している。

大学の情報基盤には、授業の時間割や教材の配布、履修情報の管理、教員と学生の連絡など、異なる教育活動を支える機能が集まっている。例えば、授業を担当する教員が教材を準備できていても、学生が教材を取得する仕組みを利用できなければ、その教材を使った授業の実施には制約が生じる。学生が授業に参加する意思を持ち、教員が授業を実施できる状態でも、教室や時間割の変更を伝達する手段が失われれば、予定どおりに教育活動を進めることが難しくなる。個々の授業を構成する人員や教材が失われていなくても、それらを結び付ける情報基盤の停止によって活動全体が影響を受ける。

この事件では、情報基盤の障害が授業日程という時間的な制約にも波及した。サーバーを復旧できれば、保存されていた教材や履修情報を再び利用できる可能性がある。しかし、休講となった期間そのものは、サーバーの復旧によって過去に戻せるわけではない。授業を別の日に実施する場合にも、教員、学生、教室、履修日程などの再調整が必要になる。技術的な障害を解消する作業と、その障害によって変更された教育活動を調整する作業では、対象となる資源も必要な手続きも異なる。

一方、臨時の仕組みによって対面授業が再開されたことは、共通情報基盤が停止した場合でも、すべての教育活動が従来のシステムの復旧を待つ必要はないことを示している。既存の情報基盤を完全に復旧するまで授業を停止する方法と、授業に必要な機能を選び出して代替手段で提供する方法では、業務再開までの条件が異なる。今回の事例では、大学が後者の方法によって対面授業を再開した。これは情報基盤の技術的な復旧範囲と、教育活動の再開可能な範囲が一致しないことを示す具体例である。

3.2 配送業務では情報の管理主体と情報の本人が分離する

佐川急便は 2026 年 9 月 30 日に「お荷物問い合わせサービス」への不正アクセスを把握し、荷物の送り主、届け先、運賃契約先、会員登録者などの情報が流出した可能性を調査している。同年 10 月 9 日の公表では、対象件数は引き続き調査中であり、集荷・輸送・配達業務は継続する一方、一部の Web サービスを停止していると説明した。また、配送を委託した出荷人と連名で個人情報保護委員会へ報告する方向で準備を進めている[13]。

配送業務では、出荷を依頼する企業が保有する顧客情報の一部を、荷物の配送に必要な情報として物流事業者へ渡す。物流事業者は、送り主と届け先を識別し、配送状況を管理し、問い合わせに対応するために、その情報を自社のシステムで処理する。ここで情報の管理主体が変わっても、情報の本人と出荷を委託した企業の関係が消えるわけではない。例えば、通販事業者の顧客が商品を注文すると、その配送に必要な氏名や住所が物流事業者へ渡る。顧客は物流事業者の情報システムを直接利用していなくても、そこに自分の情報が保存される場合がある。

こうした情報の移転は配送業務を成立させるために必要だが、同時に管理上の依存関係を生む。出荷人が自社の顧客情報を適切に保護していても、配送先へ情報を渡した後は、物流事業者側の保管方法やアクセス制御が情報の安全性に関係する。出荷人は配送に必要な情報を提供する一方、委託先のシステム内部で実施される日常的な管理作業を直接操作できるわけではない。そのため、委託先で不正アクセスが発生すると、自社の情報システムに侵害がなくても、顧客情報の漏えいに関する確認や説明が必要になる場合がある。

佐川急便が出荷人との連名による報告を準備していることは、情報の取扱いに関する責任が単一の事業者の内部で完結しないことを具体的に示している。ただし、連名で報告するという方針だけから、個々の出荷人にどのような法的責任が成立するかを判断することはできない。委託関係、情報の取扱い、管理上の義務、実際の侵害内容を確認する必要がある。また、今回の事件では情報流出の可能性を調査している段階であり、対象件数や最終的な漏えい範囲は確定していない。

この事例には、大学の情報基盤障害とは異なる特徴がある。大阪公立大学では共通基盤の停止によって教育活動に必要な機能が使えなくなった。一方、佐川急便では集荷・輸送・配達という中核業務を継続しながら、情報流出の可能性と一部の Web サービス停止に対応している。物理的な配送業務が継続していても、配送に伴って保管される個人情報の安全性は別に評価する必要がある。業務の可用性が維持されていることは、情報の機密性まで維持されていることを保証しない。

3.3 外部委託先の存在は侵害箇所の特定にも影響する

米国 FBI は 2026 年 9 月 23 日、採用ポータルへの侵害と職員の個人識別情報への影響を主張する犯罪集団の存在を把握し、調査していると公表した。その時点では、侵害箇所が FBI 自身の情報基盤にあるのか、第三者が管理する基盤にあるのかは確定しておらず、採用ポータルを支援する外部事業者と連携して調査していると説明した[14]。

この声明は、外部委託先が実際に侵害されたことを確定した発表ではない。確認できるのは、採用ポータルの侵害が主張され、FBI 自身の基盤と第三者の基盤の双方が侵害箇所の候補となっていたこと、そして外部事業者を含む調査が行われていたことである。侵害場所が判明する前に、外部事業者の脆弱性や更新不足を直接原因として記述すれば、被害の存在に関する情報と原因についての推測を混同することになる。

その一方で、管理主体が複数存在するシステムでは、侵害箇所の特定に複数組織の協力が必要になるという構造は明確である。例えば、組織が採用情報を管理するために外部のサービスを利用している場合、利用者の認証、アプリケーションの動作、データの保管、基盤の保守などを異なる主体が担当することがある。不正アクセスの痕跡が確認されても、その痕跡がどの管理領域で発生したのかを特定するには、各主体が保有する記録や設定情報を照合しなければならない場合がある。原因調査に必要な情報そのものが管理境界を越えて分散しているためである。

また、組織が外部サービスを利用することで基盤の運用作業を委託できても、そこで処理される情報が機微なものであるという性質は変わらない。採用情報や職員情報のように本人の識別や職務に関係する情報は、保管先が組織内部か外部かにかかわらず、漏えいした場合の影響を検討する必要がある。管理作業の分担と、情報流出によって損失を受ける主体の範囲は、それぞれ別に把握しなければならない。

3.4 管理境界と被害の範囲を同じ軸で比較する

三つの事例は、管理境界を越える影響が一つの形に限られないことを示している。大学では、共通情報基盤の停止によって教育活動が制約された。物流事業者では、配送のために預かった情報が侵害の対象となる可能性があり、出荷人との連携が必要になっている。FBI の採用ポータルでは、侵害箇所の調査に外部事業者との協力が必要になった。いずれもシステムを管理する主体だけを調べれば十分という構造ではないが、被害の内容と確認状況は異なる。

事例 直接の管理対象 管理境界を越える関係 確認された影響と限界
大阪公立大学 教務、教育支援、メールなどを支える大学の情報基盤。 情報基盤の停止が、その機能を利用する教員や学生の教育活動に波及する。 授業の休講と、臨時システムによる対面授業の再開が確認されている。従来の情報基盤の全面復旧とは区別する必要がある。
佐川急便 配送情報や問い合わせ情報を処理する物流事業者のシステム。 出荷人から配送のために提供された情報が、委託先の管理領域に保存される。 不正アクセスが確認され、個人情報流出の可能性を調査している。対象件数と最終的な流出範囲は未確定である。
米国 FBI 採用ポータルと、それを構成・支援する情報基盤。 外部事業者を含む複数の管理主体が、サービスの運用や侵害箇所の調査に関係する。 9 月 23 日の声明では犯罪集団による侵害の主張を調査しており、侵害箇所は未確定だった。

表から確認できるのは、管理境界を越える関係が、少なくとも三つの異なる問題として現れることである。第一は、依存先の停止によって利用者の活動が制約される問題である。第二は、委託先で保管される情報の侵害が、委託元や情報の本人へ影響する問題である。第三は、複数の管理主体が関与するため、侵害箇所の調査や対応に組織間の協力が必要になる問題である。これらは互いに関連するが、同じ事実を表すものではない。サービス停止、情報流出、原因調査の難しさを区別することで、管理主体と被害主体の関係を具体的に評価できる。

3.5 組織間の依存関係は被害の評価範囲を広げる

OECD は、デジタルセキュリティのリスクを情報技術の内部だけで捉えるのではなく、経済活動や社会生活への影響と結び付けて評価する必要性を示している[15]。例えば、大学の情報基盤が停止したという技術的な事象と、学生が予定していた授業を受けられなくなったという結果では、評価対象が異なる。前者はシステムの稼働状況として把握できるが、後者を評価するには授業日程や教育活動への依存関係を調べる必要がある。システムの停止時間だけでは、教育活動への影響を十分に表せない。

NIST のサプライチェーンに関する指針も、組織が利用する製品や外部サービスについて、その開発、運用、保守などを組織自身が直接管理できるとは限らないことをリスク管理上の課題として扱っている[16]。組織が外部サービスを採用する際には、サービスが提供する機能だけでなく、そのサービスにどの業務が依存し、サービスの停止や侵害がどの主体へ影響するかを把握する必要がある。外部事業者の管理方法をすべて直接確認できない場合、組織が把握できる情報と、実際に負担するリスクの間に差が生じる。

この依存関係による影響の波及は、ネットワーク理論でも研究されている。Buldyrev らは、相互依存するネットワークを対象に、一方のネットワークで節点が機能を失うと、それに依存する別のネットワークの節点も機能を失い、その結果が再び元のネットワークへ影響するという連鎖を数理モデルで示した[17]。個々の節点が直接攻撃されていなくても、必要な機能を提供する別の節点が停止すれば、依存先も機能を維持できなくなる。この関係を通じて、局所的な障害が広範囲の機能喪失につながる条件が成立する。

ただし、同研究は相互依存するネットワークの障害連鎖を扱ったものであり、大阪公立大学、佐川急便、FBI の実際の情報システムを測定した研究ではない。また、サービス停止による機能的な障害の伝播と、情報漏えいによって多数の本人に影響が及ぶことは、同一の現象ではない。前者では依存先の機能喪失が別の機能喪失を引き起こす。後者では保管された情報の取得によって、その情報に関係する多数の主体が影響を受ける。いずれも管理境界を越えた被害を考える材料になるが、ネットワーク理論の障害連鎖モデルを情報流出の説明にそのまま適用することはできない。

IDC フロンティアの事件も含めて考えると、管理境界と被害の範囲が一致しないことは、共通基盤や外部委託を利用する組織に広く関係する。クラウド事業者が仮想サーバーを管理していても、その停止によって業務を中断するのは利用企業である。物流事業者が配送情報を管理していても、その情報が流出すれば、出荷人や届け先が影響を受ける可能性がある。大学が情報基盤を復旧しても、休講によって変更された教育活動の調整は、教員や学生との関係で生じる。管理主体が実施する技術的な対応と、被害を受けた主体が必要とする対応は、必ずしも同じ範囲で完結しない。

組織間の依存関係を評価する際には、どのシステムが侵害されたかに加えて、そのシステムを誰が管理し、誰が利用し、どの情報が預けられ、どの業務が依存しているかを確認する必要がある。システムの管理者が把握する障害範囲と、利用者や取引先が受ける損失の範囲は異なる場合がある。さらに、侵害されたシステムを復旧できても、外部の主体に発生した影響が同時に解消するとは限らない。サイバー攻撃による損失の評価範囲は、技術的な管理境界から、そのシステムに接続された組織や個人の活動まで広がるのである。

4. システムの復旧と失われたものの回復は一致しない

サイバー攻撃によって停止したシステムが再び起動し、正常な処理を受け付けるようになれば、技術的には復旧したと判断できる場合がある。しかし、そのシステムを利用していた業務や、そこに保存されていた情報まで元の状態に戻ったとは限らない。障害発生前のデータを復元できても、停止期間中に処理できなかった取引が自動的に実行されるわけではない。第三者に取得された個人情報については、侵入経路を遮断しても、既に取得された情報の複製が外部に残る可能性がある。システムの稼働状態を回復することと、侵害によって生じた損失を回復することでは、必要な条件が異なる。

この違いは、復旧の対象を三つに分けると理解しやすい。第一は、サーバー、ネットワーク、アプリケーション、データベースなどを再び利用可能にする技術的な復旧である。第二は、それらのシステムを使っていた業務を再開し、必要な処理を実施できる状態に戻す業務上の回復である。第三は、情報流出、取引機会の喪失、第三者に生じた負担など、侵害の結果として発生した損失への対応である。三つの対象は相互に関係するが、復旧に必要な作業、完了を判断する基準、回復できる範囲が一致するとは限らない。

4.1 バックアップが存在しても障害発生直前の状態まで戻せるとは限らない

データが削除されたり、ランサムウェアによって暗号化されたりした場合、利用可能なバックアップがあれば、保存された時点のデータを復元できる可能性がある。ただし、バックアップの存在と復旧可能性は同じ意味ではない。復元に必要なデータが保存されていることに加え、バックアップを読み出せること、復元先の環境を準備できること、アプリケーションや設定を再現できること、復元したデータを正常に利用できることが必要になる。これらの条件のいずれかが満たされなければ、バックアップが残っていても業務を再開できない場合がある。

IDC フロンティアの事例では、対象ゾーンの仮想サーバーが停止し、再起動できない状態となったうえ、顧客データの取り出しや復元が困難な見通しであると公表された。同社は、顧客自身が保持するバックアップを利用し、別の環境でシステムを再構築する方法を案内している[4]。この場合、復旧の成否はクラウド事業者の対応だけでは決まらない。顧客が利用可能なバックアップを持っているか、元の環境を再現するための設定情報を保持しているか、代替の計算資源やストレージを確保できるかによって、再構築できる範囲と必要な作業が変わる。

例えば、業務アプリケーションの実行ファイルとデータベースのバックアップが残っていても、認証設定や外部システムとの接続情報が不足していれば、元の業務を直ちに再開できるとは限らない。アプリケーションを起動できても、必要なデータベースとの接続が成立しなければ処理は失敗する。また、複数のシステム間でデータを受け渡している場合、異なる時点のバックアップを復元すると、システム間のデータが整合しない可能性がある。復旧作業では、個々の構成要素を動作させることに加え、業務処理に必要な構成要素の組み合わせが正常に機能するかを検証する必要がある。

バックアップを取得した時点と、障害が発生した時点の間にも差がある。例えば、毎日午前 0 時にバックアップを取得し、午後 3 時に障害が発生した場合、バックアップだけで復元できるのは原則として午前 0 時時点の状態である。その後の 15 時間に発生した更新を取り戻せるかどうかは、取引ログ、更新履歴、外部システムに残る記録など、別の情報を利用できるかによって変わる。更新内容を再現できない場合には、データの再入力や取引先との照合が必要になることがある。

このように、システムの再起動、データの復元、データの整合性確認、業務の再開は、それぞれ別の条件を持つ。バックアップによって一定時点のデータを復元できたとしても、障害直前までのすべての更新が回復したとは限らない。IDC フロンティアの事件で顧客自身による再構築が求められたことは、復旧に必要な資源と作業がクラウド事業者の管理領域だけで完結しない場合があることを示している。ただし、個々の顧客がどの範囲まで復旧できたかは、それぞれのバックアップと再構築の状況を確認する必要がある。

4.2 情報流出ではシステムを修復しても機密性が元に戻るとは限らない

情報流出による損失は、システム停止やデータ消失とは異なる性質を持つ。停止したシステムは、必要な環境を再構築することで利用を再開できる可能性がある。消失したデータも、利用可能なバックアップがあれば復元できる場合がある。しかし、第三者が情報を取得した場合、正しいデータが元のシステムに存在していても、外部に取得された情報の複製を確実に回収・消去することは困難である。情報の機密性は、保管元のシステムだけを修復しても、侵害前と同じ状態へ戻せるとは限らない。

タイムズカーの事例では、約 660 万アカウントの情報が第三者に取得され、そのうち約 160 万アカウントで本人確認書類画像の流出が確認された[5][6]。同社は不正アクセスによるサービス提供への影響を確認しておらず、サービスを継続している。この事件では、システムが正常に稼働していることと、そこに保存された情報の機密性が保たれていることを分ける必要がある。サービスの利用可能性が維持されていても、既に外部へ取得された情報については、別の対応が必要になる。

流出した情報の種類によって、利用者が実施できる対処も異なる。例えば、パスワードが漏えいした場合には、パスワードを変更し、漏えいした認証情報を使ったログインを防ぐことができる場合がある。認証情報がほかのサービスでも使い回されていれば、それらのサービスでも変更が必要になる。一方、氏名、生年月日、住所、運転免許証画像などは、利用者自身が容易に変更できる情報ではない。本人確認書類の画像を第三者が保有したとしても、それだけであらゆる本人確認を突破できるわけではないが、本人になりすました申込みや問い合わせなどに悪用される可能性は残る。

ここで、流出した情報が実際に悪用されたかどうかと、悪用される可能性が残ることも区別しなければならない。情報が流出したという事実だけで、不正な契約や金銭的被害が発生したと判断することはできない。反対に、調査時点で不正利用が確認されていなくても、第三者が取得した情報を将来使用する可能性まで否定できるわけではない。被害の評価には、流出した情報の内容、悪用するために必要な追加条件、実際に確認された不正利用の有無をそれぞれ確認する必要がある。

情報流出への対応には、侵入経路の遮断、アクセス制御の見直し、対象者への通知、認証情報の変更、不正利用の監視などがある。これらは追加の情報流出や不正利用の可能性を抑えるために実施される。しかし、既に取得された情報そのものを、第三者の手元から確実に消去できることを意味しない。システムの修復によって今後の侵入経路を制限することと、過去の侵害によって失われた機密性を回復することは、別の問題として残る。

4.3 業務の再開によって停止期間中の損失が消えるわけではない

業務システムの停止では、システムを再び稼働させることに加え、停止期間中に実施できなかった業務をどのように扱うかが問題になる。例えば、受注システムが停止すれば、その間に受け付けられなかった注文が生じる可能性がある。顧客が復旧後に改めて注文すれば処理できる場合もあるが、別の事業者から購入したり、注文自体を取りやめたりした場合には、システムの復旧によって取引機会が戻るわけではない。技術的な復旧によって処理能力を回復できても、停止期間中に生じた経済的な影響は別に評価する必要がある。

大阪公立大学の事例では、情報基盤システムの障害によって 2026 年 10 月 8 日まで授業が休講となり、大学は臨時の仕組みを整えて 9 日から対面授業を再開した[12]。この再開は、教育活動に必要な一部の機能を代替手段によって確保できたことを意味する。一方、休講期間中に実施する予定だった授業や課題、学生への連絡などについては、日程や実施方法の調整が必要になる場合がある。授業が再開したという事実だけでは、障害期間中に生じた教育活動への影響がすべて解消したとは判断できない。

授業のように実施する時期が定められている活動では、時間そのものが回復可能性に関係する。例えば、休講となった授業を別の日に振り替えられれば、授業内容を提供する機会は確保できる可能性がある。しかし、振替には教員や学生の予定、教室の利用可能性、ほかの授業との重複などの調整が必要になる。予定していた日時に授業を実施できなかったという事実は残り、その影響を緩和するために追加の作業が発生する。システムの停止時間と、教育活動を元の計画に近づけるための負担は、同じ尺度では測れない。

この関係は企業の業務にも当てはまる。停止中に処理できなかった取引を復旧後にまとめて処理できる場合、業務上の損失を一部回復できる可能性がある。しかし、取引の期限が過ぎていたり、顧客が別の選択をしていたりすれば、同じ処理を後から実行しても当初と同じ結果になるとは限らない。停止した業務の種類、時間的な制約、代替手段の有無によって、回復できる範囲が変わるのである。

4.4 復旧の完了時刻だけでは被害の回復状況を評価できない

システム障害の対応では、いつシステムを復旧できたかという時刻が重要な指標になる。しかし、システムが起動した時刻と、利用者が必要な業務を再開できた時刻は一致するとは限らない。例えば、データベースを起動できても、外部システムとの接続が復旧していなければ、連携を必要とする処理は実行できない。業務アプリケーションが利用可能になっても、停止期間中に蓄積した処理を完了するまでには追加の時間が必要になる場合がある。復旧の完了を一つの時刻だけで示すと、業務の回復状況との差が見えにくくなる。

NIST の緊急時対応計画に関する指針は、業務影響分析を通じて、情報システムの停止が業務に及ぼす影響や、復旧に必要な資源と優先順位を検討する枠組みを示している[18]。業務影響分析では、どの業務が停止すると、どのような影響が、どの時点から生じるかを把握することが重要になる。システムの構成要素が正常に動作するかだけでなく、そのシステムによって成立している業務を対象として評価するためである。

技術的な復旧計画では、復旧時間目標と復旧時点目標という二つの概念が用いられる。復旧時間目標は、障害発生後、対象のシステムや業務をどの程度の時間内に復旧させるかという目標である。復旧時点目標は、データを過去のどの時点の状態まで戻せるようにするかという目標である。例えば、復旧時間目標が 4 時間、復旧時点目標が 1 時間であれば、4 時間以内の復旧と、障害発生前 1 時間以内の時点までのデータ復元を目指すことになる。ただし、これは設計上の目標であり、実際の復旧結果を保証するものではない。

これらの目標を満たしたとしても、情報流出の影響や停止中に失われた機会まで回復したことにはならない。復旧時間目標は主として利用可能性を、復旧時点目標はデータをどの時点まで回復するかを扱う。第三者が取得した情報の複製を消去できるか、予定していた取引や授業を実施できるかという問題は、それぞれ別の評価を必要とする。技術的な復旧目標の達成と、侵害による損失への対応を区別することで、復旧後にも残る影響を把握できる。

損失の種類 技術的な復旧で対応できる範囲 復旧後にも残り得る影響 代表的な事例
システム停止 環境の再構築や代替環境への切り替えによって、サービスを再開できる場合がある。 停止期間中に実施できなかった取引や授業、利用者の対応負担は残る。業務の再開には追加の調整や処理が必要になる場合がある。 IDC フロンティア、大阪公立大学。
データ消失・暗号化 利用可能なバックアップがあれば、保存された時点のデータまで復元できる場合がある。 最終バックアップ以降の更新が失われる可能性がある。別の記録から復元する場合にも、整合性確認や再入力の負担が生じる。 IDC フロンティアでは、顧客側のバックアップによる再構築が案内された。
個人情報の流出 侵入経路の遮断や認証情報の変更、システム改修によって、追加の侵害や不正利用を抑制できる場合がある。 第三者に取得された情報の複製を確実に回収・消去することは困難である。情報の種類によっては、将来の不正利用リスクが残る。 タイムズカー。
業務機会の喪失 システムを復旧すれば、停止していた業務の処理を再開できる場合がある。 期限を過ぎた取引や変更された予定などは、復旧後に同じ処理を実行しても、当初と同じ結果になるとは限らない。 大阪公立大学では休講が発生した。取引機会の喪失は一般的な業務停止の例である。
第三者への波及 サービス提供者側の復旧によって、利用環境を再び提供できる場合がある。 委託元、取引先、利用者などに発生した個別の損失や対応負担は、管理者側の復旧とは別に残る。 IDC フロンティア、大阪公立大学。

表に示した損失は、技術的な復旧によって回復できる範囲が異なる。システム停止では利用環境の再構築が直接的な対応になる。データ消失では、復元できる時点と、その後に発生した更新を取り戻せるかが問題になる。個人情報の流出では、侵入経路を遮断しても第三者が取得した情報の複製が残る可能性がある。業務機会の喪失では、システムが再開しても、期限や利用者の判断によって元の取引を再現できない場合がある。第三者への波及では、管理者側の復旧後にも、情報の本人や取引先が対応を続ける必要が生じ得る。

同じ事件で、これらの損失が複数発生することもある。例えば、共通基盤の停止によって業務システムが使えなくなり、バックアップからの復旧が必要になった場合、システムの停止とデータ復元の問題が同時に生じる。復旧までの期間に取引や授業が中断すれば、業務上の影響も加わる。被害を一つの件数や停止時間だけで表すと、技術的な障害、業務上の損失、第三者への影響が同じ指標にまとめられてしまう。

4.5 回復可能性は失われた対象によって異なる

IDC フロンティア、タイムズカー、大阪公立大学の三つの事例を比較すると、システムの技術的な状態と、被害を受けた主体の状態が異なることが分かる。IDC フロンティアでは、クラウド基盤の利用不能に対して、顧客自身のバックアップによる再構築が案内された。タイムズカーでは、サービスを継続しながら、既に取得された個人情報への対応が必要になった。大阪公立大学では、従来の情報基盤の全面復旧とは別に、臨時の仕組みによって授業が再開された。三つの事例で、回復の対象と、その完了を判断する条件がそれぞれ異なる。

技術的な復旧では、サーバーやデータベースが正常に動作し、必要なデータを読み書きできるかを確認できる。業務上の回復では、そのシステムを利用して必要な活動を実施できるかを確認する必要がある。損失への対応では、既に流出した情報の悪用可能性や、停止期間中に発生した業務上の影響が残っているかを確認しなければならない。これらを区別することで、システムの復旧を完了と判断した後も、どの主体にどのような影響が残っているかを把握できる。

また、回復可能性は、損失が発生した時点で利用できる手段にも左右される。障害発生前に取得されたバックアップは、失われたデータを復元する手段になり得る。停止期間中の業務を代替する仕組みがあれば、システムの完全復旧前に一部の活動を再開できる可能性がある。しかし、外部へ取得された個人情報の複製を確実に消去する手段は、通常、情報を保管していた事業者の管理権限だけでは確保できない。損失の種類によって、事後的な対応の有効性に差が生じる。

この差を踏まえると、被害の深刻さを評価する際には、何が失われたかに加えて、誰がその損失を負担し、どの範囲まで元の状態へ戻せるかを確認する必要がある。システムの管理者が復旧に成功しても、情報の本人が抱える不正利用リスクや、利用者が失った業務機会まで解消するとは限らない。反対に、元の情報基盤が全面復旧していなくても、代替手段によって業務を再開できる場合がある。システムの稼働状態と、利用者や組織が必要な活動を遂行できる状態は、同じものではない。

サイバー攻撃による損失は、復旧作業によって元の状態へ戻せるものと、別の対応によって影響を緩和するもの、発生した事実そのものを取り消すことが困難なものに分かれる。IDC フロンティアのような基盤停止では、代替環境とデータ復元が業務再開の条件になる。タイムズカーのような情報流出では、追加の侵害を防ぐ対策と、既に取得された情報の不正利用への対応が必要になる。大阪公立大学のような業務停止では、代替手段による活動の再開と、停止期間中に変更された予定への対応が別々に発生する。

システムの復旧完了という一つの結果に、これらの異なる回復をまとめることはできない。侵害されたシステムを元の状態に戻すことと、そのシステムに依存していた人々や組織の損失を回復することは、それぞれ異なる条件を持つ。被害の深刻さは、技術的に復旧するまでの時間だけでなく、復旧によって回復できる範囲と、その後も残る損失によって左右される。

5. 集中しているから危険で、分散していれば安全というわけではない

共通基盤への依存や情報の集中管理が被害拡大の条件になり得るとしても、集中という構成だけで実際の被害範囲が決まるわけではない。一つのクラウド事業者が多数の顧客を収容していても、顧客ごとの資源や管理権限が適切に分離されていれば、ある顧客のシステムへの侵害が別の顧客へ直接波及することを防げる場合がある。一方、複数のサーバーやデータセンターにシステムを分散していても、認証基盤や管理権限を共有していれば、一つの権限の侵害が複数の環境へ影響する可能性がある。資源の配置と、侵害によって影響を受ける範囲は、区別して評価する必要がある。

この違いを理解するには、資源がどこに配置されているかという物理的な構成に加えて、誰が何を操作できるかという権限の構成と、どの機能がどの資源に依存しているかという業務上の構成を確認する必要がある。例えば、二つのデータセンターが物理的に離れていても、同じ管理者の認証情報で両方を操作できる場合、その認証情報の侵害によって二つの環境が同時に危険にさらされる可能性がある。反対に、同じ施設内に複数のシステムが存在していても、権限と資源が独立して管理されていれば、一方のアプリケーションへの不正アクセスが他方のデータ取得に直結するとは限らない。物理的な距離と、攻撃者が到達できる範囲は別の性質である。

5.1 物理的な分散と管理権限の分離は異なる

システムの可用性を高めるために、複数のサーバー、異なる施設、別のリージョンへ処理を分散する方法がある。例えば、一つのデータセンターで電源障害が発生した場合、別のデータセンターに同等の処理能力と必要なデータがあれば、業務を継続できる可能性がある。設備の故障や局所的な災害を想定した場合、物理的な分散には明確な意味がある。障害の原因となる設備を共有しなければ、一方の故障が他方へ直接影響する可能性を減らせるためである。

しかし、サイバー攻撃では、物理的に離れた設備が同じ管理機構を共有している場合がある。例えば、二つのデータセンターに配置されたサーバーが、一つの認証基盤によって管理されているとする。管理者の認証情報が奪われ、その認証情報によって両方の環境を操作できる場合、攻撃者は施設間を物理的に移動する必要がない。正規の管理操作として提供されている機能を悪用することで、複数の環境へ影響を及ぼせる可能性がある。サーバーを物理的に分離していても、管理上の権限が共通であれば、その権限が侵害の伝播経路になり得る。

同様の関係は、データの複製にも存在する。複数の保存先へデータを複製していれば、一つの保存装置が故障しても、別の保存先からデータを取得できる可能性がある。しかし、複製元で発生した不正な変更や削除まで複製される構成では、正常な装置が複数残っていても、必要な時点のデータを取得できなくなる場合がある。装置の故障から保護する仕組みと、不正な変更から過去のデータを保護する仕組みでは、対処する脅威が異なる。分散した保存先の数だけで、侵害後の復旧可能性を判断することはできない。

反対に、一つの事業者が共通の施設や計算基盤を利用していても、顧客ごとのデータへのアクセス権限や管理操作が適切に分離されていれば、個別の侵害を限定できる場合がある。例えば、ある顧客のアプリケーションが不正アクセスを受けても、そのアプリケーションの権限では別の顧客の情報を参照できない構成であれば、当該権限を悪用するだけで別の顧客の情報を取得することはできない。ただし、個別のアプリケーションの権限が分離されていても、それらを管理する共通基盤が侵害されれば、別の経路から影響が及ぶ可能性は残る。分離が成立している範囲と、その分離を管理する仕組みの権限を区別する必要がある。

5.2 IDC フロンティアの障害範囲から確認できること

IDC フロンティアは 2026 年 10 月 8 日の公表で、障害の対象を東日本リージョン 1 の tesla、henry、pascal、joule の四つのゾーンと説明した。一方、同じリージョンの radian、newton と、ほかのリージョンについては、その時点で不正アクセスを確認していないと説明している[4]。この公表から、確認された障害と不正アクセスの範囲が、同社の提供するすべてのゾーンやリージョンに及んでいたわけではないことが分かる。

ただし、障害が確認された範囲と、内部のセキュリティ境界がどのように機能したかは別の問題である。例えば、あるゾーンで不正アクセスが確認され、別のゾーンでは確認されなかったとしても、それだけでゾーン間のアクセス制御が攻撃の伝播を防いだと証明できるわけではない。攻撃者が別のゾーンへの侵入を試みなかった可能性もあれば、攻撃者の権限や侵入経路が特定の環境に限られていた可能性もある。ある領域で被害が確認されていないという観測結果から、被害が発生しなかった原因まで一意に特定することはできない。

さらに、同社は安全性を確認するため、障害が確認されていない環境についても管理コンソールの停止などの措置を実施した。これは、実際に侵害された範囲と、安全性の確認や被害拡大防止のために利用が制限された範囲が異なり得ることを示している。あるシステムが利用不能になっていても、そのシステム自体が攻撃によって侵害されたとは限らない。侵害された環境への接続を遮断したり、調査が完了するまで共通の管理機能を停止したりすることで、直接侵害されていない利用者にも影響が及ぶ場合がある。

このような状況では、被害の範囲を一つの数値だけで表すと、異なる状態が混同される。攻撃による直接的な侵害、共通基盤の停止による機能的な影響、調査や予防措置による利用制限は、それぞれ原因が異なる。IDC フロンティアの事例を評価する場合も、どのゾーンで何が確認されたのか、どの機能が利用不能になったのか、どの措置が安全性の確認のために実施されたのかを分けて把握する必要がある。障害範囲が限定されていたという事実は重要だが、その範囲が限定された理由を判断するには、内部の管理構造や攻撃経路について追加の情報が必要になる。

5.3 佐川急便の事例では確認された境界と調査中の境界が異なる

佐川急便も、「お荷物問い合わせサービス」への不正アクセスについて、対象となるシステム以外やグループ会社のシステムへの影響を確認していないと公表している[13]。この説明は、調査時点で判明していた影響範囲を示すものである。配送に関係するすべてのシステムが同じ被害を受けたと解釈することは適切ではない。一方、ほかのシステムへの影響が確認されていないという事実だけで、内部の権限分離やネットワーク分離が十分に機能したと判断することもできない。

不正アクセスの調査では、攻撃者がどのシステムへ侵入し、どの権限を利用し、どの情報へ到達したかを確認する必要がある。例えば、一つの Web サービスへの不正アクセスが確認された場合でも、そのサービスが利用しているデータベース、認証機構、外部接続先などへの影響は、それぞれ調べなければならない。サービスの画面から参照できる情報の範囲と、アプリケーションが内部で取得できる情報の範囲が一致するとは限らないためである。利用者に公開されている機能だけを調べても、攻撃者が侵害された権限で実行できた操作の全体像は把握できない場合がある。

また、調査で被害が確認されていないことと、技術的に侵入が不可能だったことは異なる。前者は、その時点で利用できる証拠から得られた観測結果である。後者を示すには、権限設定、通信経路、実装された制御、攻撃者の到達可能範囲などについて、より具体的な検証が必要になる。調査の進展によって影響範囲が更新される可能性もあるため、公表された時点と確認内容を対応させて扱うことが重要になる。

佐川急便の事例には、情報を管理する範囲と、情報流出によって影響を受ける主体の範囲が異なるという特徴もある。仮に不正アクセスが特定のサービスに限定されていたとしても、そのサービスに多数の出荷人や届け先の情報が保存されていれば、影響を受ける主体は複数の組織や個人に及び得る。技術的な侵害箇所が一つであることは、被害を受ける主体が一つであることを意味しない。侵害されたシステムの数と、そのシステムに依存していた利用者の数は、別の指標である。

5.4 被害範囲を決める境界は一種類ではない

集中と分散の違いを評価する際には、どの境界によって資源が分離されているかを確認する必要がある。システムの構成には、物理的な設備の境界、ネットワークの通信境界、管理権限の境界、データへのアクセス境界、業務上の依存関係などが存在する。それぞれの境界が防ぐことのできる影響は異なるため、一つの境界が存在することだけで、ほかの境界まで成立していると判断することはできない。

境界の種類 分離する対象 分離だけでは防げない可能性がある影響 評価に必要な確認事項
物理的な境界 サーバー、保存装置、データセンターなどの設備を異なる場所に配置する。 共通の認証情報や管理機構が侵害された場合、物理的に離れた環境にも影響が及ぶ可能性がある。 設備間で共有する管理機能、認証情報、データの複製経路を確認する。
ネットワークの境界 システム間で許可する通信の経路や接続先を制限する。 許可済みの通信経路や共通の管理サービスが悪用された場合、境界を越えた操作が成立する可能性がある。 許可された通信、管理経路、外部サービスへの接続範囲を確認する。
管理権限の境界 管理者やサービスごとに操作可能な資源と操作内容を制限する。 複数の環境を操作できる上位権限が侵害された場合、個別の環境を越えて影響が及ぶ可能性がある。 権限の付与範囲、上位権限、共通の認証機構を確認する。
データアクセスの境界 利用者や業務ごとに参照・変更できる情報の範囲を制限する。 広範囲の情報を参照できる内部機能や権限が侵害された場合、大量取得につながる可能性がある。 個別の権限から取得可能なデータの種類、件数、操作方法を確認する。
業務上の依存境界 業務を成立させる機能と、その機能が依存する外部・内部の資源を区別する。 技術的に独立した業務でも、共通の外部サービスや情報基盤が停止すれば、同時に継続困難になる可能性がある。 業務ごとの依存先、代替手段、停止によって影響を受ける主体を確認する。

例えば、二つのアプリケーションが異なるサーバーで稼働し、ネットワークも分離されている場合を考える。両方が同じ認証基盤に依存していれば、その認証基盤が停止することで、二つのアプリケーションへのログインが同時に利用不能になる可能性がある。サーバーの配置とネットワークの分離が成立していても、認証という機能への依存は残るためである。この場合、問題は二つのアプリケーションが同じ場所に存在していることではなく、正常な利用を成立させるために必要な機能を共有していることである。

反対に、一つの共通基盤上で動作する複数のアプリケーションについて、利用者ごとの参照権限が分離されている場合を考える。ある利用者の認証情報が漏えいしても、その権限でほかの利用者の情報を参照できなければ、当該認証情報を悪用した情報取得の範囲を限定できる。しかし、そのアプリケーションを管理する上位権限や共通のデータ保存機構が侵害されれば、別の範囲に影響が及ぶ可能性がある。個別のアクセス制御が成立していることと、共通基盤を含むすべての侵害経路が遮断されていることは異なる。

二つの例から、集中と分散はそれぞれ複数の性質を含んでいることが分かる。物理的に分散したシステムが共通権限によって管理されている場合もあれば、物理的に集中したシステムの内部でデータアクセスが分離されている場合もある。さらに、計算資源と認証基盤が分離されていても、業務上の依存関係が共通していれば、停止の影響が複数の業務へ及ぶ可能性がある。実際の被害範囲を評価するには、どの資源が共有され、どの境界によって到達可能範囲が制限されているかを個別に確認する必要がある。

5.5 被害が確認された範囲と侵害可能な範囲を区別する

NIST のリスク評価指針は、脅威、脆弱性、影響などを区別し、組織の置かれた状況に応じてリスクを評価する枠組みを示している[19]。今回の事例に適用する場合にも、攻撃者が実際に侵入した場所、侵入した権限から技術的に到達できる範囲、現実に確認された被害、調査や予防措置によって利用が制限された範囲を区別することが有効である。

例えば、攻撃者がある管理者の認証情報を取得し、その認証情報で複数の環境を操作できる場合を考える。攻撃者が実際に操作したのは一つの環境だけだったとしても、認証情報の権限によっては、ほかの環境にも到達できる可能性がある。この場合、実際に被害が確認された範囲は一つの環境であり、潜在的に影響を受け得る範囲は複数の環境となる。被害が確認されていない環境について、攻撃者が実際に侵入したと断定することはできないが、侵害された認証情報によって操作可能な範囲を調査する必要は残る。

逆に、ある共通基盤の障害によって多数の利用者がサービスを利用できなくなった場合でも、利用者ごとの情報やシステムが直接侵害されたとは限らない。共通基盤の停止によって利用できなくなったことと、攻撃者がその利用者のデータへ不正にアクセスしたことは、異なる事実である。IDC フロンティアの障害では、共通基盤の停止に伴う影響範囲を確認する必要がある一方、個々の顧客環境への不正アクセスや情報流出については、別の証拠によって評価する必要がある。

佐川急便のように調査が継続している事件でも、同じ区別が必要になる。ある時点でほかのシステムへの影響が確認されていなくても、それは当該時点までの調査結果である。追加調査によって新しい被害が判明する可能性もあれば、最終的に確認された被害範囲が当初の範囲にとどまる場合もある。公表情報を利用する際には、何が確認されたかに加えて、いつ確認された情報なのかを把握しなければならない。確認時点の異なる情報を無条件に組み合わせると、事件の状態や被害規模を誤って説明する可能性がある。

こうした区別は、システムの設計を評価する場合にも必要となる。実際に被害が一部の環境に限定されたとしても、その理由が権限分離にあったのか、攻撃者の行動にあったのか、侵入経路の制約にあったのかによって、設計に対する評価は変わる。防御機構の有効性を判断するには、その機構がどの操作を制限し、どの条件で侵害の拡大を防げるのかを検証する必要がある。観測された被害範囲だけを根拠に、特定の防御機構が有効だったと結論付けることはできない。

5.6 一点の侵害によって何が同時に失われるか

集中管理と分散構成を比較する際、単純にサーバーの台数、データセンターの数、契約する事業者の数を数えるだけでは、侵害時の影響範囲を把握できない。例えば、複数のデータセンターに分散した業務システムが、同じ管理権限によって操作され、同じ認証基盤に依存している場合、設備の配置が分散していても、管理上の侵害や認証基盤の停止によって同時に影響を受ける可能性がある。反対に、共通の計算基盤上に複数の業務システムがあっても、情報へのアクセス権限や障害領域が適切に分離されていれば、個別の侵害を限定できる場合がある。

また、一点の侵害が引き起こす影響は、技術的な機能停止だけに限られない。共通のクラウド基盤が停止すれば、その基盤に依存する複数の組織の業務が中断する可能性がある。多数の会員情報を保存する仕組みが侵害されれば、個々の利用者が直接攻撃されていなくても、情報流出の影響を受ける可能性がある。外部委託先のシステムで情報流出が発生すれば、委託元のシステムが正常でも、委託元やその顧客に対応が必要になる場合がある。侵害された技術的な資源と、そこから損失を受ける主体の範囲は、依存関係を通じて結び付いている。

IDC フロンティアでは、障害が確認されたゾーンと、確認されていないゾーンが区別された。佐川急便では、不正アクセスが確認されたサービスと、影響が確認されていないシステムが区別された。これらの事実は、同じ事業者が運用するシステムであっても、被害の確認状況が一様とは限らないことを示している。一方、その違いがどの内部構造によって生じたかを判断するには、権限、通信経路、資源の共有関係、攻撃者の行動などを確認する必要がある。

集中か分散かという構成上の区別よりも、一つの侵害によって何が同時に失われるかという問いの方が、被害の深刻さを具体的に説明できる。資源が物理的に離れていること、管理権限が分離されていること、情報へのアクセス範囲が制限されていること、業務が独立して継続できることは、それぞれ異なる条件である。これらの条件がどの範囲で成立しているかによって、侵害後の影響範囲と回復可能性は変わる。サイバー攻撃の被害構造を評価するうえでは、資源の配置そのものよりも、侵害が到達できる範囲と、その範囲に接続された業務や利用者を把握することが求められる。

6. サイバー攻撃の深刻さは失われるものから評価する

六つの事件では、ランサムウェアによるクラウド基盤の停止、大量の個人情報流出、大学の情報基盤障害、配送情報を扱うシステムへの不正アクセス、採用関連ポータルへの侵害申告など、異なる現象が確認または報告された。攻撃手法や被害の種類だけで分類すれば、それぞれ別の問題として整理される。しかし、侵害された資源がどのような役割を持ち、そこにどれほどの情報や業務が依存し、誰が損失を負担するのかを調べると、共通する構造を分析できる。攻撃が成功したという事実と、その結果として発生する損失の大きさを結び付けるのは、侵害された資源と、それに接続された業務や利用者との関係である。

例えば、一台のサーバーに対する不正アクセスでも、そのサーバーが個別の業務だけを処理している場合と、多数の利用者の情報を保存している場合では、影響を受ける対象が異なる。同様に、一つのクラウド基盤が停止した場合、その基盤に依存する業務が少なければ影響は限定される可能性があるが、多数の企業が業務システムを運用していれば、障害は複数の組織へ波及する。さらに、失われたものが復元可能なデータなのか、外部に取得された情報の機密性なのかによって、事後的に回復できる範囲も変わる。侵害された資源の役割、依存関係、回復可能性という三つの条件が組み合わさることで、同じような不正アクセスでも異なる被害が生じ得る。

六つの事件について、確認された事象、被害に関係する構造、技術的な復旧とは別に残る問題を整理すると、次のようになる。

事例 確認された事象 被害に関係する構造 技術的復旧と別に確認すべき影響
IDC フロンティア 東日本リージョン 1 の四つのゾーンで仮想サーバーが停止し、495 の企業・自治体が影響を受けた。 複数の組織が共通のクラウド基盤に依存しており、基盤の障害が利用者側のシステム運用へ波及した。 各組織が独自のバックアップから業務を再構築できるか、停止期間中にどのような損失が発生したかを確認する必要がある。
タイムズカー 約 660 万アカウントの情報が流出し、そのうち約 160 万アカウントで本人確認書類画像の流出が確認された。 退会者や入会未完了者を含む大量の個人情報が保管され、第三者による取得の対象となった。 既に取得された情報の複製を確実に回収・消去することは困難であり、情報の種類に応じた不正利用リスクが残る。
大阪公立大学 情報基盤の大規模障害によって授業が休講となり、臨時の仕組みによって対面授業が再開された。 教務、教育支援、連絡などの複数の教育活動が共通情報基盤に依存していた。 授業日程の変更、代替手段の準備、学生・教職員の対応負担は、情報基盤の技術的な復旧とは別に評価する必要がある。
佐川急便 配送情報を扱うシステムへの不正アクセスが確認され、個人情報流出の可能性について調査が続いている。 配送のために出荷人や届け先の情報が物流事業者へ渡され、委託元と委託先の間に情報管理上の依存関係が生じる。 情報流出の範囲が確定した場合、委託元や配送関係者への影響、通知や対応の分担を確認する必要がある。
ローソン ローソン ID の 215 万 5,345 件とアプリ予約の 26 件について、個人情報の漏えいが確認された。 多数の利用者情報を扱うサービスで、利用者本人への情報表示に関わるセキュリティ機構が不正アクセスを受けた。 流出した情報が外部で保持・利用される可能性があり、追加の流出を防ぐ対策と既存の流出情報への対応を区別する必要がある。
米国 FBI 採用ポータルへの侵害と職員の個人識別情報への影響を主張する犯罪集団について、FBI が調査を公表した。 採用関連サービスに複数の管理主体が関係し、侵害箇所の特定に外部事業者との協力が必要になった。 公式声明時点では侵害箇所と職員情報への影響が未確定であり、実際の被害範囲を確定するための調査が必要だった。

この比較では、確認された被害と、調査中の影響を区別する必要がある。IDC フロンティアの仮想サーバー停止、タイムズカーとローソンの情報流出、大阪公立大学の休講は、具体的な結果として公表されている。一方、佐川急便の情報流出の範囲や、FBI が 9 月 23 日の声明で調査対象としていた侵害箇所については、その時点で確定していない事項があった。公表事実の確実性が異なる以上、六つの事件を同じ条件で発生した被害として扱うことはできない。また、被害規模の数字から、実際の侵入経路やセキュリティ対策の優劣を推定することも適切ではない。

それでも、事件ごとの侵入原因が完全に解明される前から、被害構造について確認できる事実はある。IDC フロンティアでは、共通クラウド基盤への依存によって複数の利用組織が影響を受けた。タイムズカーでは、保管されていた情報の範囲が流出件数に関係した。大阪公立大学では、共通情報基盤の停止が教育活動の中断につながった。これらは攻撃者がどの脆弱性を悪用したかという情報から導かれるものではなく、侵害された資源と、その資源を必要とする活動との関係から説明できる。

六つの事件を比較する際には、少なくとも四つの観点を区別できる。第一は、侵害された資源にどれほどの情報や機能が集中していたかである。第二は、その資源にどのような業務や組織が依存していたかである。第三は、侵害された場所から実際にどこまで影響が及び、誰が被害を受けたかである。第四は、技術的な復旧によって何が回復し、どのような損失が残るかである。これらは相互に関係するが、単一の指標へまとめることは難しい。大量の情報を保存するシステムと、少数の業務を支える基盤では、保存件数、利用者数、業務停止時間のいずれか一つだけで深刻さを比較できるとは限らない。

六つの事件からは、平常時の効率化と侵害時の損失が異なる主体に帰属する場合があることも読み取れる。IDC フロンティアの共通基盤は利用組織の設備運用の負担を減らすが、基盤が停止すれば個々の利用組織が業務再構築を担う。佐川急便の配送システムでは、配送を委託した出荷人や情報の本人が、事業者の管理領域で生じた侵害の影響を受ける可能性がある。こうした分担では、資源を共有する範囲と、その資源を管理する権限の範囲が一致するとは限らない。被害の広がりを判断するには、集中・分散という配置に加えて、侵害された権限から到達できる対象と、そこに依存する主体を特定する必要がある。

復旧を判断する時点にも、管理主体と利用主体の違いが現れる。クラウド事業者がサービスを再開しても、利用企業がデータや設定を復元し、停止中の処理を補完する作業は残り得る。大阪公立大学では、代替手段による対面授業の再開と従来の情報基盤の復旧が別の出来事だった。タイムズカーやローソンでは、事業者側の侵入経路を遮断できても、第三者に取得された情報の機密性は元の状態に戻らない可能性がある。技術的な復旧完了時刻と、利用者に残る損失の解消時点を同一視すると、被害の一部が評価から抜け落ちる。

近年のサイバー攻撃では、生成 AI を用いた偵察や脆弱性探索、攻撃作業の自動化が注目されている。こうした技術は、攻撃者が標的を探索する速度や攻撃を実行するための負担に影響する可能性がある。しかし、攻撃が成立した後に、どの情報が取得され、どの業務が停止し、どれほどの組織や個人が影響を受けるかは、侵害された資源と、その資源への依存関係にも左右される。AI の利用は攻撃能力を分析するうえで重要な要素になり得る一方、それだけで被害の深刻さを説明することはできない。

サイバー攻撃の深刻さは、攻撃技術の高度さだけで決まるものではない。侵害された資源からどこまで影響が届き、その影響を誰が負担し、何を元に戻せるのかによって、同じ侵入でも異なる損失が生じる。IDC フロンティアの基盤停止、タイムズカーの大量情報流出、大阪公立大学の授業中断は、それぞれ異なる形でこの関係を示している。攻撃手法の分析と、被害を生み出す依存構造の分析を区別することで、一つの侵害がなぜ多数の主体にとって回復困難な損失へ転化するのかを、実際の被害に即して説明できる。

参考文献

  1. Google Threat Intelligence Group, GTIG AI Threat Tracker: From Prompting to Autonomy – The Evolution of Adversarial AI（2026-09-08）. https://cloud.google.com/blog/topics/threat-intelligence/from-prompting-to-autonomy-the-evolution-of-adversarial-ai
  2. id774, AI を一つの物語に閉じ込めない（2026-08-09）. https://blog.id774.net/entry/2026/08/09/4974/
  3. IDC フロンティア, 【第2報】当社サービスの一部システムに対する不正アクセスについて（2026-10-07）. https://www.idcf.jp/news/topics/20261007002/
  4. IDC フロンティア, 【第3報】当社サービスの一部システムへの不正アクセスによる障害について（2026-10-08）. https://www.idcf.jp/news/topics/20261008001/
  5. タイムズモビリティ, 「タイムズカーWebシステム」への不正アクセスに関する調査結果および今後の対応について（第2報）（2026-09-28）. https://share.timescar.jp/news/2026/0928/1815.html
  6. タイムズモビリティ, 「タイムズカーWebシステム」への不正アクセスに関する調査結果および今後の対応について（第3報）（2026-09-29）. https://share.timescar.jp/news/2026/0929/1816.html
  7. id774, 正しい数字から間違った結論は作れる（2026-09-23）. https://blog.id774.net/entry/2026/09/23/5721/
  8. ローソン, 第三者による不正アクセスに伴う個人情報漏えいに関するお詫びとお知らせ（2026-10-08）. https://www.lawson.co.jp/contents/cont07/1533174_3310.html
  9. id774, タイタニック号事故から読み解く巨大システム運用の本質（2026-05-02）. https://blog.id774.net/entry/2026/05/02/4656/
  10. Ross, R., Pillitteri, V., Graubart, R., Bodeau, D., and McQuaid, R., Developing Cyber-Resilient Systems: A Systems Security Engineering Approach（2021-12）. https://doi.org/10.6028/NIST.SP.800-160v2r1
  11. 個人情報保護委員会, 個人情報の保護に関する法律についてのガイドライン（通則編）（2016-11）. https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/（2026 年 6 月一部改正版）
  12. 大阪公立大学, 本学情報基盤システムにおける障害の発生について【第4報】対面授業再開のお知らせ（2026-10-08）. https://www.omu.moe/news/2026-10-08-c5873744.html
  13. 佐川急便, 「お荷物問い合わせサービス」への不正アクセスによる個人情報流出の可能性について（第4報）（2026-10-09）. https://www2.sagawa-exp.co.jp/information/detail/426/
  14. Federal Bureau of Investigation, FBI Statement on Compromise of fbijobs.gov Portal and Alleged Impact to FBI Employee PII（2026-09-23）. https://www.fbi.gov/news/press-releases/fbi-statement-on-compromise-of-fbijobsgov-portal-and-alleged-impact-to-fbi-employee-pii
  15. OECD, Digital Security Risk Management for Economic and Social Prosperity: OECD Recommendation and Companion Document（2015-10-01）. https://doi.org/10.1787/9789264245471-en
  16. Boyens, J. et al., Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations（2022-05）. https://doi.org/10.6028/NIST.SP.800-161r1-upd1（2024 年 11 月 1 日更新版）
  17. Buldyrev, S. V. et al., Catastrophic cascade of failures in interdependent networks（2010-04-15）. https://doi.org/10.1038/nature08932
  18. Swanson, M. et al., Contingency Planning Guide for Federal Information Systems（2010-05）. https://doi.org/10.6028/NIST.SP.800-34r1
  19. Joint Task Force Transformation Initiative, Guide for Conducting Risk Assessments（2012-09）. https://doi.org/10.6028/NIST.SP.800-30r1