政府が「基本的な対策の不足」を名指し｜国家サイバー統括室の注意喚起を、発注側の仕組みに落とし込む

はじめに
何が発表されたのか
なぜ「基本的な対策」が抜け落ちるのか
発注側コンサルタントはこう考える
まとめ
参考

はじめに

2026年11月5日、内閣官房の国家サイバー統括室が、ウェブサイトやモバイルアプリで個人情報を扱う事業者に向けて、不正アクセス対策の注意喚起を出しました。翌6日には政府が関係閣僚会議を開き、予備費から100億円を使う「サイバーセキュリティ緊急対策パッケージ」を決めています。

この秋は、会員情報やメール配信サービス、採用サービスなど、個人情報の漏えいのニュースが毎日のように続きました。今回の注意喚起は、そうした事案に共通する原因として「基本的な対策が十分でなかった」点を挙げています。

注意喚起そのものは、主にシステムを作る人・運用する人に向けた技術的な内容です。ただ、事業会社の多くはシステムの開発や運用を外部に委託しています。この記事では、発注側を支援するコンサルタントの立場から、「8つの対策を、委託している側としてどう仕組みに落とし込むか」を考えます。

何が発表されたのか

国家サイバー統括室の公表資料と、それを伝えた報道（INTERNET Watch、Impress Watch、ITmedia NEWS、いずれも2026年11月6日）をもとに整理します。

公表日：2026年11月5日。翌6日には総務省も所管の事業者などに同じ内容を周知した
対象：ウェブサイトやモバイルアプリを使った事業を運用し、個人情報を取り扱う事業者と、ITシステム・セキュリティの担当者
背景：最近の漏えい事案では、モバイルアプリ開発時の対策不足、ウェブサイトの設定不備、サポートが終わったソフトウェアや既知の脆弱性が残ったソフトウェアの使用など、基本的な対策が不十分な事例が複数確認されたとしている
具体的な手口：インターネットに公開されたシステム管理画面に対し、推測されやすい認証情報の悪用や総当たり攻撃などで不正アクセスが行われる例を挙げている
AIへの言及：攻撃者が標的の調査や侵入にAIを使っている可能性が高く、攻撃の大規模化が容易になったため、事業の規模に関係なく狙われうると指摘している
対策の枠組み：「運用・管理」「設計・開発」「サプライチェーン」の3つの段階に分け、合計8つの対策を示している

8つの対策は次のとおりです（報道による項目名）。

| 段階 | 対策 |

|—|—|

| 運用・管理 | デジタル資産の適切な把握と脆弱性の解消／アタックサーフェス（外部から攻撃できる入口）の継続的な棚卸しと最小化／AIの活用などによる継続的な脆弱性診断と不審な挙動の監視 |

| 設計・開発 | セキュリティ・バイ・デザインの適用／利用するAPIのセキュリティ対策の強化／公開前の脆弱性診断の実施 |

| サプライチェーン | 委託先のセキュリティ統制と委託先からの接続経路の厳格化／OSSや外部ライブラリなどの適切な管理 |

報道によると、委託先が使うVPNやリモートデスクトップなどの接続経路に多要素認証をかけること、開発を委託するときにSBOM（ソフトウェア部品表）の提出を契約や仕様で定めることなども例として挙げられています。

また、11月6日に決まった緊急対策パッケージは、「AIも活用した基本的な対策の徹底」「情報収集・集約、捜査・分析体制の強化」「サイバー攻撃への対処の戦略的な実施」「被害者支援・被害拡大防止策の強化」の4つの柱からなります。被害を受けた企業などに官民の専門人材を派遣する「官民サイバー救援隊（仮称）」の設置も盛り込まれました。

なぜ「基本的な対策」が抜け落ちるのか

正直なところ、AIの活用などを除けば、8つの対策の大半は目新しいものではありません。脆弱性の管理、公開範囲の最小化、診断、委託先管理。どれもセキュリティの教科書に載っている内容です。それでも抜け落ちるのは、技術の問題というより、組織とお金の流れの問題だと考えています。

一つ目は、誰の仕事なのかが決まっていないことです。システムを作ったときの開発会社、保守を受けている会社、クラウドを契約している部署、サイトを運営している事業部。関係者が多いほど、「脆弱性の情報を見て、対応を決める」役が宙に浮きます。それぞれが「誰かがやっているはず」と思っているうちに、パッチが何年も当たらない状態ができあがります。

二つ目は、予算が「作るとき」にしか付かないことです。新しいシステムを作る予算は通りやすい一方、毎年のバージョンアップや診断の費用は「何も起きていないのに払うお金」に見えて削られがちです。サポートが切れたソフトウェアが動き続けるのは、多くの場合、更新の予算がどこにも組まれていないからです。

三つ目は、全体の一覧がないことです。キャンペーン用に作った小さなサイト、検証用に立てたまま残っているサーバー、昔の委託先が使っていた接続経路。注意喚起が言う「デジタル資産の把握」と「アタックサーフェスの棚卸し」が最初に来ているのは、ここが崩れていると残りの対策が始められないからでしょう。

発注側コンサルタントはこう考える

8つの対策をそのまま委託先に「やってください」と投げても、うまくいきません。委託先は契約に書かれた範囲で動きますし、複数の委託先にまたがる問題は誰も拾わないからです。発注側がやるべきことは、対策を「自社が持つべきもの」と「委託先に求めるもの」に分けて、仕組みにすることだと考えています。

1. 公開資産の台帳は、発注側が持つ

最初にやるべきは、インターネットからアクセスできるもの（サイト、アプリのAPI、管理画面、VPNの入口など）の一覧を、委託先任せにせず自社で持つことです。項目は最低限、次の5つで十分です。

何のシステムか、どのURL・IPか
誰が作り、いま誰が保守しているか（会社名と担当窓口）
主なソフトウェアとバージョン、サポート期限
管理画面や保守用の経路があるか、どこから接続できるか
個人情報を扱っているか、どのくらいの件数か

この一覧があれば、新しい脆弱性が出たときに「うちに関係あるか」を1日で判断できます。逆に、これがないと、毎回委託先に問い合わせて回答を待つことになり、対応が数週間遅れます。

2. 契約と仕様書に「運用中の義務」を書く

注意喚起でも、委託時にセキュリティ要件を契約・調達で明確にすることが挙げられています。ここで大事なのは、開発時の要件だけでなく、運用・保守の期間中に委託先が何をするかまで書くことです。

脆弱性情報の確認頻度と、重大なものが出たときの報告期限（例：把握から2営業日以内に影響有無を報告）
保守対象のソフトウェアの一覧（SBOM）を納品時に提出し、変更時に更新する
委託先から自社環境への接続は、多要素認証と接続元の制限を前提にする
年1回の外部からの脆弱性診断と、結果の共有

既存の契約にこれが書かれていない場合は、次の更新のタイミングで追加の協議をしましょう。費用が増えることもありますが、それは本来かかるべきコストが見えるようになっただけです。開発時のセキュリティ要件の整理の仕方は、基幹刷新プロジェクトにおけるセキュリティ要件の整理でも詳しく書いています。

3. 更新と診断の費用を、毎年の予算に入れておく

「サポート切れのソフトを使い続けていた」という事態を防ぐには、技術よりも予算の仕組みが効きます。私がよく提案するのは、システムごとにサポート期限の一覧と、その更新費用の見込みを中期予算に並べることです。期限の1〜2年前には更新の予算が計上されている状態をつくれば、「お金がないから今年も延命」という判断が減ります。

あわせて、公開前の診断を「リリース判定の条件」に入れておくことも有効です。診断で重大な指摘が残っているなら公開しない、とルールで決めておけば、スケジュールの圧力に負けにくくなります。

4. 「使い終わったもの」を止める担当を決める

キャンペーンサイトや検証環境、契約が終わった委託先のアカウントは、作る人はいても止める人がいないことがほとんどです。台帳に「終了予定日」と「停止の責任者」の欄を設け、四半期に一度、情シスが棚卸しする。それだけで、攻撃者が入れる入口はかなり減ります。

5. 事故が起きたときの初動を、委託先と事前に決めておく

政府は官民サイバー救援隊の設置を打ち出しましたが、最初の数時間に動くのは自社と委託先です。誰が誰に連絡するのか、ログはどこにあり誰が保全するのか、サービスを止める判断は誰がするのか。これを委託先と一緒に1枚にまとめ、年に一度は机上で確認しておきましょう。事故のときに契約書を読み返しても間に合いません。

まとめ

今回の注意喚起と緊急対策パッケージは、「最近の漏えいは、特別な攻撃ではなく基本的な対策の抜けから起きている」という政府の問題意識をはっきり示したものです。そして、その基本的な対策の多くは、委託先の現場で実行されます。

発注側にできるのは、公開資産の一覧を自分で持つこと、運用中の義務を契約に書くこと、更新と診断の予算を毎年組むこと、止める担当と事故時の初動を決めておくことです。どれも地味ですが、「委託しているから大丈夫」という思い込みを、確認できる仕組みに置き換える作業だと考えています。

参考

執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。