はじめに
このところ、クラウドサービス側の侵害や、ランサムウェアで業務が止まる事案が続けて報じられています。私が伴走している自治体でも、幹部や首長から「対策はどうなっているのか」と問われ、情報政策部門として何から答えればよいか、という相談が増えました。
報道のたびに「大丈夫です」と答え続けるわけにもいきませんし、かといってすべてを一度に固める予算も人も、ありません。そこで今回は、幹部から対策を求められている情報政策部門の方々に向けて、nice2haveとしてこの状況をどう捉えているかを書きます。結論を先に言えば、まず庁内全体の情報システムを洗い出して状況を把握し、それを一度きりでなく続く取り組みにすること。そのうえで、自分たちで変えられる範囲を押さえ、事業者側の侵害は起こりうるものとして復旧の備えを持つこと、です。
最初にやるのは、庁内全体の洗い出しと、把握を続ける仕組み
対策の話に入る前に、どうしても先に置きたいことがあります。庁内にどんな情報システムがあり、誰が運用し、どんなデータを持ち、いまどの状態にあるのかを、庁内全体で洗い出して把握することです。情報政策課が管理しているシステムだけでなく、各課が個別に契約しているクラウドサービスや、検証のために立てたまま残っている環境まで含めて、です。
この洗い出しは、一度やって終わりにすると意味が薄れます。担当者が異動すれば引き継がれず、台帳は作った年だけ最新になりがちです。パッチの適用状況を追うにも、多要素認証の漏れを探すにも、漏洩時に説明するにも、バックアップの対象を決めるにも、この把握が土台になります。だからこそ、更新し続ける運用にしておくことが、この話の出発点だと考えています。
国の側でも動きが続いている点は、押さえておきたいところです。2026年5月には内閣官房や総務省など14の府省庁が連名で「AI性能の高度化を踏まえたサイバーセキュリティ対策の強化について」を出し、より高速かつ大量に脆弱性が発見・修正されることを前提とした対策強化を求めました。8月には総務大臣から全国の知事・市区町村長に宛てた書簡が出て、首長自らが先頭に立って対策を強化するよう要請しています。幹部や首長から対策を問われる場面は、この先も増えるはずです。庁内に何があるかの把握は、その問いに答えるための土台になります。
次に、変えられるものと変えられないものを分ける
洗い出したシステムは、大きく2つに分かれます。
1つは、SaaSのように第三者に運用を委ねているクラウドサービスです。クラウドサービスは本来、パッチマネジメントを確実に、高い頻度で回す運用が事業者側で立てつけられているはずのものです。そのぶん、事業者側に侵害が起きた場合、自治体側から直接手を打てる余地は正直なところ小さいと考えています。契約で求められる対策水準や報告義務はあっても、日々の脆弱性対応そのものは事業者の手の中にあるからです。
もう1つは、自分たちで運用しているシステムです。庁舎内のサーバーなど非クラウド型のシステムはもちろん、クラウド上でもIaaSを使って構築したシステムであれば、OSやミドルウェアのパッチ適用は自分たちの範疇になります。クラウドサービスなら事業者側に備わっているはずの高頻度のパッチ運用を、ここでは自前で実現していかなければなりません。やれば効く領域であり、同時に、やらなければ誰もやってくれない領域でもあります。
この切り分けをせずに「セキュリティ対策」とひとくくりにすると、手が届かない部分への不安に引きずられて、手が届く部分の対策が後回しになりがちです。幹部に説明するときも、この2つを分けて示すと話が通りやすくなります。
自分たちの範疇では、パッチの頻度を相当上げる
自分たちで運用しているシステムについて、やるべきことははっきりしています。パッチを当てること、そして当てる頻度を相当に上げることです。はっきりしているからといって楽なわけではなく、対象の数が増えるほど、台帳と手順と人手がそろっていなければ回らなくなります。
強調しておきたいのは、頻度の水準がこれまでとは変わっているという点です。脆弱性の公表から悪用までの間隔は、AIを使った攻撃の広がりとともに短くなり、攻撃の量も増えました。セキュリティ研修でもお見せしている数字ですが、侵入から横展開の開始までの平均時間は29分、最速では27秒、検知された攻撃の82%はマルウェアを使っていません（CrowdStrike グローバル脅威レポート2026／WEF Global Cybersecurity Outlook 2026）。脆弱性が見つかってから悪用されるまでの期間も、2022年の約8.6か月から2025年には約21日半へ縮み、2026年には公表前に悪用される例まで出ています（野溝のみぞう氏「サイバー捜査員研修」、Zero Day Clock）。年に1回のまとめ適用や、四半期ごとの定期作業では追いつきません。月次を基本に、重大な脆弱性が公表されたときは臨時で当てる、という頻度を前提に運用を組み直す必要があると考えています。そのためにも、どのシステムのパッチを誰が担い、最後に当てたのがいつかを、洗い出した台帳で追えるようにしておきたいところです。
もう1つ、多要素認証についても触れておきます。導入済みの団体は多いと思いますが、施してあれば必ず安全になるものでもありません。実際、多要素認証を導入していながら不正アクセスを受けた組織は珍しくなく、2026年10月に公表されたMicrosoft 365の運用担当者1,002人への調査（アクト「Microsoft 365 セキュリティ運用の実態 2026」）では、不正アクセスやその疑いがあった組織のおよそ9割が多要素認証を適用済みでした。被害を受けたアカウントの状況として最も多かった回答は「適用していたが、対象アカウントでは一時的に無効化・除外されていた」で、43%にのぼります。私が気にしているのは、まさにこの「施されていないまま残っているもの」のほうです。
退職した職員のアカウントが、そのまま残っている
検証のために作ったアカウントを、消し忘れていた
使われなくなったシステムのログイン口が、まだ開いている
こうしたものに多要素認証が施されていないまま残っていることが、侵入経路になります。多要素認証そのものは手段の1つにすぎませんが、「導入したか」ではなく「すべてに施されているか、漏れているものを見つけ出して正常な状態に戻せているか」という観点を持つこと。ここが、庁内でできる対策を考えるときの肝だと思っています。
αとβをどう考えるか ― 分離で脅威を減らすのも合理的
三層分離の見直しにあたって、αモデルとβモデルのどちらに進むかは、多くの団体で論点になっているところです。βのほうがクラウドサービスへのアプローチがしやすいという利点があることは、念頭に置いておく必要があります。それを踏まえたうえでも、私はαでも十分に合理的な選択だと考えています。
理由は、βに寄せるほど「やらなければならない運用」が増えるからです。βでは、業務端末がインターネットに近づくぶん、EDRなどを導入して端末の挙動を常時監視することが前提になるでしょう。しかも最近の攻撃は、マルウェアを持ち込むのではなく、もともと端末に入っている正規のツールや管理機能を使って進めるものが目立ちます。これを捉えるには、EDRを入れて終わりではなく、常時監視を続け、普段と違う動きを判断できる体制まで含めて運用することが要ります。端末も通信も無条件には信用せず、普段と違う動きがないかを常に確かめ続ける。これを恒常的にやっていくことが、ゼロトラストと呼ばれる考え方の中身です。
AIを使った攻撃が多様化し、量も増えている状況では、この体制を庁内に持つことは簡単ではありません。βに踏み込むのであれば、ツールの導入だけでなく、セキュリティに対する組織の考え方をゼロトラストの側へ変えることとセットになります。そこまで考えを大きく転換できず、財政的にコストがかかる方法に舵を切れないのであれば、分離した構成のままにして、そもそも考えなければならない脅威の数を減らしておく。これは守りに入った判断ではなく、現在の攻撃環境を踏まえた上での、理にかなった選択だと思います。
αのままでも、クラウドサービスが使えないわけではありません。ローカルブレイクアウトのように、特定のクラウドサービスへの通信だけを分離の外へ逃がす構成は、既に多くの団体で使われています。分離の考え方を保ったまま、クラウドサービスとうまく付き合っていく。βへ全面的に寄せる以外にも、αの中で取れる手はあると考えています。
事業者側の侵害は起こりうるものとして、2つの備えを持つ
ここまでは自分たちの範疇の話でしたが、冒頭の話に戻ると、どのクラウドサービスも侵害の可能性を最小化する努力をしているはずです。その質や水準には事業者ごとに差がありますが、どこであっても可能性がゼロになることはありません。この前提に立つと、自治体側で考えておくべきことは2つに絞られると考えています。
1つは、情報が漏れたときにどう考えるかです。どの情報がどのサービスにあり、漏れた場合に誰に何を説明するのか。ここは第三者に委ねているサービスでは検討しづらい部分ですが、少なくとも「どこに何があるか」が分かっていなければ、説明の初動すら切れません。
もう1つは、データが使えなくなったときに、どうやって迅速に戻すかです。こちらは自治体側で打てる手があります。そのクラウドサービスの外側にバックアップを取り、別の場所で復旧できる体制を整えておくことです。ランサムウェアで暗号化されたり、アカウントごと操作できなくなったりすれば、リージョンを分けて複製を持っていても、どのリージョンのデータにも手が届かなくなります。クラウドサービス側が侵害される事案が現実に起きている以上、「同じクラウドの中で複製を持っている」だけでは備えとして足りません。別の場所、別のアカウント、できれば別の事業者で戻せる準備を、平時のうちに済ませておく必要があります。
すべての出発点は、庁内に何があるかの把握
ここまでに書いたことを振り返ると、パッチの頻度を上げるにも、多要素認証の漏れを探すにも、漏洩時に説明するにも、外側にバックアップを取るにも、すべて冒頭の洗い出しに戻ってきます。庁内にどんなシステムがあり、誰が運用し、どんなデータを持ち、いまどの状態にあるかを把握し、それを続けていること、です。
洗い出して把握を続け、変えられる範囲を押さえ、戻せる備えを持つ。
幹部への説明も、この順番で組み立てられます。
幹部や首長から対策を問われているいまは、この土台を早急に整える機会でもあるはずです。台帳があれば、「どこまでが自分たちの範疇で、そこは押さえている」「事業者側で何かあっても、ここから戻せる」と、根拠を持って説明できるようになります。
GovLensで、洗い出しと更新を続く仕組みにする
この「洗い出して、更新し続ける」を人手だけで回すのが難しいことは、私自身が多くの自治体で見てきました。そこで作ったのがGovLensです。調達文書や仕様書をアップロードすると、AIが読み解いて情報資産台帳に起こす仕組みになっています。人が確認して採用する流れなので「AIが全部やる」わけではありませんが、いちばん重い読み解きと転記が消えるだけで、棚卸しは単発のイベントから続く仕組みに変わるはずです。
台帳の基本項目には、パッチの適用者（アプリ・ミドルウェア・OS）、最新の適用年月、適用頻度といった脆弱性管理に必要な項目を標準で持たせています。Excelに出力して国から求められる点検様式に合わせられるので、報告への対応と日々の運用は同じ台帳で回せる形です。ダッシュボードでは契約満了や更新の状況が一覧になり、全文検索やAIへの質問で「このシステムの保守契約はどこまでか」といった確認もその場でできます。
おわりに
セキュリティの話は、不安が先に立つと手が広がりすぎるものです。まず庁内全体を洗い出して把握を続け、自分たちで変えられる範囲を押さえ、変えられない範囲については戻せる備えを持つ。この順番で進めれば、幹部への説明も現場の作業も、現実的な量に収まると考えています。
庁内のシステムの洗い出しから始めたい、あるいは幹部向けの説明をどう組み立てるか相談したいという方は、どうぞ遠慮なくお声がけください。
「うちは大丈夫なのか」に、根拠を持って答えられる状態をつくりませんか
庁内にどんなシステムがあり、誰がパッチを担い、いまどの状態か。GovLensは調達文書から情報資産台帳を起こし、脆弱性管理に必要な項目を基本項目として持つ台帳です。国から求められる点検様式へのExcel出力にも対応しています。
貴団体のシステム構成と課題に合わせたご相談から。所要1時間程度のオンライン打ち合わせも承ります。
