MENU
DX推進、IoT、AI、リスキリングで御社人材のキャリアアップを実現
  1. ホーム
  2. 11.セキュリティ・倫理
  3. クラウドは止まる前提で備える。自治体サイト停止から学ぶ集中リスクとBCP

クラウドは止まる前提で備える。自治体サイト停止から学ぶ集中リスクとBCP

11.セキュリティ・倫理
クラウドは止まる前提で備える。自治体サイト停止から学ぶ集中リスクとBCP
CONCEPT
クラウドは止まる前提で備える。自治体サイト停止から学ぶ集中リスクとBCP
クラウドも止まることを前提に、依存関係、分離バックアップ、代替発信、復旧判断、訓練を整える。五つの視点と十の確認質問から、重要業務を続けて立て直すBCPを考えます。
5つ
BCPの視点
依存・退避・発信・判断・訓練
10問
組織での確認
継続と復旧の備えを点検
3日間
停止を想定
最低限続ける方法を考える
原文公開：2026年10月12日 ／ 転載・編集：2026年10月19日
note原文を読む
この記事でわかること
  • クラウドに潜む依存関係と集中リスク
  • BCPを具体化する五つの視点
  • 十の確認質問と小さく始める事業継続の備え
目次

〖記事概要〗

クラウドを使えば、システムは止まらない。
クラウドを使えば、システムは止まらない。大手事業者へ任せれば、セキュリティも安心できる。そんな期待を持ちたくなります。しかし、複数の自治体サイトが同時に閲覧できなくなった出来事は、便利さの裏にある「集中リスク」を私たちへ突きつけました。サイバー攻撃を完全に防ぐことはできません。だからこそ、重要なのは防御を諦めることではなく、守りながら、止まった後もサービスを続けられる設計へ変えることです。本稿では、クラウド時代の責任分界、BCP、バックアップ、代替連絡手段、個人と組織が持つべき心構えを整理します。安全を「何も起きないこと」ではなく、「起きても立て直せること」と捉え直すための記事です。

〖本文〗

自治体のホームページが見られないと聞くと、広報ページが一時的に消えただけだと思う人もいるかもしれません。

自治体のホームページ停止は、単なるWeb障害ではない

自治体のホームページが見られないと聞くと、広報ページが一時的に消えただけだと思う人もいるかもしれません。
自治体のホームページが見られないと聞くと、広報ページが一時的に消えただけだと思う人もいるかもしれません。しかし、いまの自治体サイトは、イベント案内を載せる掲示板ではありません。災害情報、避難所、行政手続き、子育て支援、税、医療、福祉、入札、採用など、住民と行政をつなぐ入口です。
平常時なら、数時間見られなくても大きな問題にならないページもあります。けれども、豪雨、地震、感染症、停電などが重なれば話は変わります。住民が最も情報を必要とする瞬間に入口が閉じると、電話や窓口へ問い合わせが集中し、別の業務まで止まります。デジタルの障害が、現実の混乱を増幅させるのです。
企業でも同じです。コーポレートサイト、EC、予約、採用、問い合わせ、会員サービスが止まれば、売上だけでなく、顧客からの信頼や将来の機会を失います。サイト停止の損失は、復旧費用だけでは測れません。利用者が必要な行動を取れなかった時間まで含めて考える必要があります。

クラウドは「雲」ではなく、誰かが運営する現実の設備である

クラウドという言葉には、どこにでもあり、壊れず、必要なときに自動で使える印象があります。
クラウドという言葉には、どこにでもあり、壊れず、必要なときに自動で使える印象があります。しかし実体は、データセンター、サーバー、ネットワーク、電源、運用担当者、ソフトウェア、契約の組み合わせです。物理的な設備と人の仕事によって成り立っています。
音声配信では、クラウドをマンションにたとえました。一つの建物の中に多数の部屋があり、企業や自治体がそれぞれの部屋を借りるイメージです。この仕組みは効率的です。利用者は建物そのものを建てずに、必要な分だけ使えます。専門家による監視や更新も受けられます。
一方で、建物の入口や共用設備に問題が起きれば、複数の部屋へ同時に影響が広がります。クラウドの価値である「集約」は、そのまま障害時の「集中」にもなります。これはクラウドが危険だという話ではありません。効率化によって何を一カ所へ集めたのかを把握し、そこが止まったときの逃げ道を設計しなければならないという話です。

便利さの裏側にある集中リスク

一つのクラウド事業者へ多くのシステムを集約すると、調達、運用、監視、費用管理を効率化できます。
一つのクラウド事業者へ多くのシステムを集約すると、調達、運用、監視、費用管理を効率化できます。共通の基盤を使えば、セキュリティ対策や更新を標準化しやすくなります。小さな組織が自前ですべてを守るより、専門事業者へ任せた方が安全になる場面も多くあります。
ただし、同じ事業者、同じ地域、同じアカウント、同じネットワーク、同じ認証基盤へ依存しすぎると、一つの事故が広い範囲へ波及します。多数の自治体サイトが同時に止まった事例から学ぶべきなのは、攻撃手法の細部だけではありません。依存関係が連鎖していると、個別組織の備えだけでは復旧できない場合があることです。
集中リスクは、クラウド事業者だけの問題でもありません。ドメイン管理、DNS、認証、メール、決済、バックアップ、外部委託先など、見えにくい共通部品にも存在します。本番環境を二重化していても、管理者アカウントが一つなら同時に奪われます。データを別の場所へコピーしていても、同じ認証情報で削除できるなら安全な退避とは言えません。

サイバーリスクはゼロにできない

セキュリティ対策では、侵入を防ぐことが大切です。
セキュリティ対策では、侵入を防ぐことが大切です。更新、脆弱性管理、多要素認証、権限分離、監視、教育を重ねることで、攻撃の成功確率を下げられます。しかし、対策を増やせばリスクが完全に消えるわけではありません。
攻撃者は新しい弱点を探し続けます。人は間違えます。機器は故障します。委託先や利用中のサービスで事故が起きることもあります。生成AIによってプログラム作成や情報収集が容易になり、防御側だけでなく攻撃側の速度も上がっています。守る側は、既知の攻撃だけでなく、未知の事態にも向き合わなければなりません。
「絶対に漏れない」「絶対に止まらない」と説明するほど、事故後の判断は遅れます。起きるはずがない前提では、誰が止めるのか、何を優先して復旧するのか、利用者へどう知らせるのかが決まっていないからです。リスクと付き合うとは、事故を容認することではありません。不確実性を認めた上で、被害を小さくし、早く戻す準備をすることです。

セキュリティをコストではなく継続能力への投資と考える

セキュリティは売上を直接増やさないため、長く「やらなければならないコスト」と見られてきました。
セキュリティは売上を直接増やさないため、長く「やらなければならないコスト」と見られてきました。新機能や広告には成果が見えますが、事故を防いだ成果は見えにくいからです。何も起きなかった年ほど、予算の価値が疑われます。
しかし、事業や行政サービスがデジタルへ依存するほど、セキュリティは継続能力そのものになります。認証が止まれば働けない。データが使えなければ判断できない。Webサイトが止まれば利用者へ伝えられない。守る対象はサーバーではなく、組織の役割と社会からの信頼です。
投資判断では、「事故が起きる確率」だけを見るのではなく、「止まったときに何が失われるか」「何時間までなら耐えられるか」を考えます。売上、住民サービス、法令対応、信用、職員の負荷を具体化すると、必要な備えを経営課題として話せるようになります。

BCPは災害対策だけではない

BCPはBusiness Continuity Plan、事業継続計画です。
BCPはBusiness Continuity Plan、事業継続計画です。地震や台風への備えとして知られていますが、対象は自然災害に限りません。サイバー攻撃、クラウド障害、通信断、停電、感染症、主要取引先の停止、人材不足など、重要業務が続けられなくなる事態を扱います。
BCPで最初に決めるのは、すべてを同時に復旧する方法ではありません。何を最優先で続けるかです。自治体なら災害情報や緊急連絡、企業なら受注、決済、顧客対応など、組織の使命に直結する業務を選びます。優先順位がなければ、事故直後に声の大きい要望へ引っ張られます。
次に、目標復旧時間と許容できるデータ損失を決めます。数分で戻す必要があるのか、翌日でもよいのか。直前までのデータが必要なのか、数時間前へ戻ってもよいのか。要求水準が高いほど費用も複雑さも増えます。すべてを最高水準で守るのではなく、業務の重要度に応じて設計することが現実的です。

クラウド時代のBCPを作る五つの視点

どのサービスが、どのクラウド、ネットワーク、認証、DNS、外部API、委託先に依存しているかを一覧にします。

第一に、依存関係を見える化する

どのサービスが、どのクラウド、ネットワーク、認証、DNS、外部API、委託先に依存しているかを一覧にします。
どのサービスが、どのクラウド、ネットワーク、認証、DNS、外部API、委託先に依存しているかを一覧にします。契約書や構成図だけでなく、現場が実際に使っているツールも確認します。担当者しか知らない自動処理や、個人アカウントで動く仕組みは大きなリスクになります。
一つの障害からどこまで影響が広がるかを線で結ぶと、共通の弱点が見えます。重要なのは製品名の一覧ではなく、「これが止まると何ができなくなるか」を業務の言葉で示すことです。

第二に、バックアップを本番と切り離す

ランサムウェア対策では、バックアップがあっても、それを攻撃者に暗号化または削除されれば復旧できません。
ランサムウェア対策では、バックアップがあっても、それを攻撃者に暗号化または削除されれば復旧できません。本番環境と異なる権限、異なる保管先、変更できない保存方式などを組み合わせます。バックアップの存在ではなく、実際に戻せることが重要です。
定期的に復元テストを行い、必要な時間、手順、担当者、失敗箇所を記録します。バックアップは保険証券ではありません。使える状態を確認して初めて備えになります。

第三に、代替の情報発信手段を持つ

公式サイトが止まったとき、どこで正しい情報を伝えるかを事前に決めます。
公式サイトが止まったとき、どこで正しい情報を伝えるかを事前に決めます。別系統の簡易サイト、SNS、防災メール、電話案内、報道機関、庁舎や店舗での掲示など、利用者層に合わせて複数の経路を用意します。
代替手段が同じ認証基盤や同じ担当者へ依存していないかも確認します。緊急時の発信文面、承認者、更新頻度を雛形にしておけば、混乱の中でも速く伝えられます。沈黙は不安と誤情報を増やします。

第四に、復旧の優先順位と権限を決める

事故が起きてから全員で相談すると、初動が遅れます。
事故が起きてから全員で相談すると、初動が遅れます。システムを停止する判断、外部機関へ連絡する判断、代替運用へ切り替える判断を誰が下すか決めておきます。不在時の代理者も必要です。
復旧順序は、技術的に戻しやすいものではなく、社会や事業への影響が大きいものから決めます。住民への緊急情報と職員向けの勤怠では、同じ停止でも優先度が異なります。経営と現場が一緒に決めるべき領域です。

第五に、訓練して計画を更新する

計画書を作って保管するだけでは動けません。
計画書を作って保管するだけでは動けません。担当者が変わり、サービス構成が変わり、連絡先も変わります。少なくとも定期的に、クラウド停止、認証停止、データ破損などの場面を想定した机上訓練を行います。
訓練では、正解を当てることより、判断に必要な情報が足りるかを確かめます。連絡網が古い、代替サイトへログインできない、復元に想定以上の時間がかかるといった発見こそ価値があります。失敗を本番前に経験し、計画を現実へ近づけます。

クラウド事業者へ任せても、利用者の責任はなくならない

クラウドでは、事業者と利用者が責任を分担します。
クラウドでは、事業者と利用者が責任を分担します。データセンターや基盤を守るのは事業者でも、アカウント、権限、設定、保存するデータ、業務継続の判断は利用者側に残ることが一般的です。契約によって範囲は異なりますが、「クラウドだから全部お任せ」は成り立ちません。
利用者は、サービスレベル、障害時の連絡方法、データの保管場所、バックアップ範囲、復旧支援、ログ提供、再委託先などを確認します。契約時だけでなく、更新時にも見直します。技術部門だけでなく、法務、調達、広報、経営が関わる必要があります。
また、複数クラウドを使えば自動的に安全になるわけでもありません。構成が複雑になり、監視や運用の穴が増える場合があります。重要なのは、流行の方式を採用することではなく、自組織の優先業務に必要な回復力を、運用できる形で持つことです。

情報漏洩を前提に、個人ができる備え

私たちは、サービスを利用するたびに氏名、住所、連絡先、決済情報などを預けます。
私たちは、サービスを利用するたびに氏名、住所、連絡先、決済情報などを預けます。すべての漏洩を個人の努力で防ぐことはできません。それでも、被害の連鎖を小さくすることはできます。
最も基本的なのは、パスワードを使い回さないことです。一つのサービスから認証情報が漏れても、別のサービスへ侵入されにくくなります。多要素認証を使い、重要なアカウントの通知を有効にします。不要になったサービスは退会し、保存された情報を減らします。
不審な連絡が来たときは、メールやSMSのリンクから急いで手続きせず、公式アプリや登録済みのURLから確認します。事故直後は、不安につけ込む偽の案内も増えます。「漏れたかもしれない」という情報を、次の詐欺へつなげさせない意識が必要です。

中小企業は何から始めればよいか

大規模な二重化や専門チームをすぐに持てない組織でも、できることはあります。
大規模な二重化や専門チームをすぐに持てない組織でも、できることはあります。まず、止まると困る業務を三つに絞ります。その業務で使うシステム、担当者、データ、取引先、連絡方法を書き出します。
次に、「明日の朝から三日間使えない」と仮定し、紙、電話、別の端末、別の拠点などで最低限続ける方法を考えます。完璧な代替ではなく、顧客や利用者へ約束した価値を失わない最低線を決めます。
そして、管理者アカウントの多要素認証、端末とソフトウェアの更新、重要データの分離バックアップ、緊急連絡網の更新、年一回の復元テストから始めます。高価な製品を買う前に、責任者と手順を明確にするだけでも初動は変わります。

「防ぐ組織」から「立て直せる組織」へ

セキュリティの議論は、攻撃を受けたか、受けなかったかの二択になりがちです。
セキュリティの議論は、攻撃を受けたか、受けなかったかの二択になりがちです。しかし現実には、侵入を早く見つける力、影響範囲を限定する力、正しく伝える力、復旧する力も安全の一部です。
事故が起きた組織を責めるだけでは、他の組織は学べません。何が止まり、どの判断が難しく、どの備えが役立ったかを共有することで、社会全体の回復力が高まります。隠すほど同じ失敗が繰り返されます。
クラウドを使うことも、デジタル化を進めることも止めるべきではありません。便利さを享受しながら、その便利さが失われる瞬間にも役割を果たせるようにする。これがクラウド時代の成熟した向き合い方です。

マインド・トランスフォーメーションとしてのBCP

BCPは技術部門だけの計画ではありません。
BCPは技術部門だけの計画ではありません。平常時の効率だけを最大化する発想から、変化や事故の中でも価値を届け続ける発想への転換です。これは、技術導入ではなく人と組織の前提を変えるマインド・トランスフォーメーションでもあります。
「任せたから安心」ではなく、任せた先を含めて依存関係を見る。「障害は起きない」ではなく、起きたときに何を守るか決める。「失敗を隠す」ではなく、次の備えへ変える。この三つの転換が、サイバーリスクと付き合う土台になります。
私の著書『マインド・トランスフォーメーション AI時代の思考革命』でも、新しい技術を生かすには、道具だけでなく人間の判断基準や組織のあり方を更新する必要があると述べています。

今日から確認したい十の質問

最後に、組織で確認するための質問を挙げます。
最後に、組織で確認するための質問を挙げます。重要業務は何か。何時間の停止まで耐えられるか。どのサービスへ依存しているか。管理者は誰か。代理者はいるか。バックアップを最後に復元したのはいつか。公式サイトが止まったときの発信先はどこか。利用者への第一報を誰が承認するか。委託先の障害時連絡先は最新か。次の訓練日は決まっているか。
この十問に答えられなければ、製品を追加する前に、関係者で一時間話す価値があります。全部を一度に解決する必要はありません。最も重要な業務を一つ選び、その業務が止まった場面から始めます。
サイバーリスクをゼロにすることはできません。しかし、被害を受けたときの混乱、停止時間、失うデータ、利用者の不安は減らせます。備えとは、不安におびえることではなく、次に取る行動を決めておくことです。
株式会社サートプロでは、DX・AX推進、生成AI活用、サイバーセキュリティ、人材育成について初回無料のコンサルティングを行っています。技術導入だけでなく、止まったときにも現場が判断し、立て直せる仕組みを一緒に考えます。

〖重要なキーワード解説〗

複数の業務や組織が同じ事業者、設備、認証、ネットワークなどへ依存し、一つの障害が広い範囲へ同時に影響するリスクです。

集中リスク

複数の業務や組織が同じ事業者、設備、認証、ネットワークなどへ依存し、一つの障害が広い範囲へ同時に影響するリスクです。
複数の業務や組織が同じ事業者、設備、認証、ネットワークなどへ依存し、一つの障害が広い範囲へ同時に影響するリスクです。

BCP

災害やサイバー攻撃などが起きても、重要な業務を継続し、許容時間内に復旧するための事業継続計画です。
災害やサイバー攻撃などが起きても、重要な業務を継続し、許容時間内に復旧するための事業継続計画です。

責任共有モデル

クラウド事業者と利用者が、基盤、設定、アカウント、データなどの保護責任を分担する考え方です。
クラウド事業者と利用者が、基盤、設定、アカウント、データなどの保護責任を分担する考え方です。境界はサービスと契約で異なります。

RTOとRPO

RTOは目標復旧時間、RPOは許容できるデータ損失の時間幅です。
RTOは目標復旧時間、RPOは許容できるデータ損失の時間幅です。業務の重要度に応じて水準を決め、バックアップや復旧方式を設計します。

サイバーレジリエンス

攻撃を防ぐだけでなく、検知し、影響を抑え、業務を続け、復旧し、学びを次の対策へ反映する組織の回復力です。
攻撃を防ぐだけでなく、検知し、影響を抑え、業務を続け、復旧し、学びを次の対策へ反映する組織の回復力です。

〖参考情報〗

自治体サイト停止とクラウド事業者へのサイバー攻撃に関する参考記事。

〖著者紹介〗

■株式会社サートプロ 代表取締役CEO。
近森満
IT・DX・IoT・AI分野の人材育成、資格・検定制度の企画、現場実装支援に取り組んでいます。
■所属・役職

〖音声配信〗

日々の気づきやDX・AX・MX、AI時代の人材育成、仕事と経営の変化について音声でお届けしています。
日々の気づきやDX・AX・MX、AI時代の人材育成、仕事と経営の変化について音声でお届けしています。

よくあるご質問

重要業務を続け、障害後に立て直すための考え方を原文に沿って確認します。
クラウドなら、システム停止を心配しなくてよいですか？
クラウドも設備、ネットワーク、電源、ソフトウェア、人の運用で成り立つため、停止の可能性があります。共通基盤への集約は効率化に役立つ一方、一つの障害が複数の業務へ同時に広がる集中リスクも生みます。利用をやめるのではなく、何を一カ所へ集めたかを把握し、そこが止まった際の逃げ道を設計することが重要です。クラウド事業者だけでなく、認証やDNS、委託先などの依存関係も確認します。
BCPでは、最初に何を決めますか？
最初に決めるのは、すべてを同時に復旧する方法ではなく、何を最優先で続けるかです。自治体の緊急情報や企業の受注、決済、顧客対応など、組織の使命に直結する重要業務を選びます。その上で、何時間までの停止に耐えられるか、どの時点までのデータが必要かを整理します。要求水準が高ければ費用や複雑さも増えるため、すべてを最高水準にせず、業務の重要度に応じて設計する考え方です。
バックアップがあれば、必ず復旧できますか？
バックアップが存在するだけでは十分ではありません。本番と同じ権限で削除できたり、攻撃者に暗号化されたりすれば、復旧に使えない場合があります。本文では、本番とは異なる権限や保管先、変更できない保存方式などを組み合わせる視点を示しています。さらに、定期的に復元テストを行い、必要な時間、手順、担当者、失敗箇所を記録します。保存した事実ではなく、実際に戻せる状態を確認することが備えになります。
サイト停止中の情報発信は、どう備えますか？
公式サイトが止まったときの正しい発信先を事前に決めます。別系統の簡易サイト、SNS、メール、電話、掲示などを、利用者層に合わせて用意する考え方です。代替経路が同じ認証基盤や同じ担当者だけに依存していないかも確認します。緊急時の文面、承認者、更新頻度を雛形にし、不在時の代理者も決めます。混乱の中で一から相談するのではなく、誰が判断し、どこで知らせるかを共有しておきます。
小規模な組織は、何から始めればよいですか？
まず止まると困る業務を三つに絞り、使うシステム、担当者、データ、取引先、連絡方法を書き出します。次に三日間使えないと仮定し、電話や紙、別の端末などで最低限続ける方法を考えます。本文では、多要素認証、更新、分離バックアップ、緊急連絡網の更新、復元テストから始める例を示しています。高価な製品を追加する前に、責任者と手順、守るべき最低線を明確にすることが初動につながります。
止まっても立て直せる現場を考える

自社の課題や育成の進め方について、サートプロへご相談ください。

お問い合わせ
11.セキュリティ・倫理
生成AI
気に入ったらシェアしてください！
  • URLをコピーしました！

関連記事