公開したあとのシステムで見続けるセキュリティ：国の注意喚起（2026年11月5日）を、開発や保守を外に頼んでいる会社の点検表にする

システムを公開する前には、多くの会社が脆弱性診断を受け、指摘を直してから本番に出します。ところが、公開したあとに同じ熱量で点検を続けている会社は多くありません。開発会社に作ってもらい、保守会社に任せていると、「何かあれば連絡が来るだろう」と考えがちです。

2026年11月5日、内閣官房国家サイバー統括室（NCO）が、事業者向けの注意喚起「個人情報の漏えい等につながる不正アクセスへの対策について ～ウェブサイトやモバイルアプリに関する基本的な対策の徹底～」を出しました。13ページの文書の最初の章は「運用・管理段階におけるセキュリティ対策の徹底」です。この記事では、ここを中心に、公開したあとに見続けることを取り出し、開発や保守を外に頼んでいる中小企業の点検表に置き換えます。

国の注意喚起は、何を理由に出されたか

注意喚起は、冒頭で次のように状況を説明しています。

• 相次いで起きている不正アクセスによる情報漏えいの中に、自組織や委託先の基本的な対策が十分でなかったことが原因とみられる事例が複数ある
• 原因の例は、モバイルアプリの開発時のセキュリティ対策の不足、ウェブサイトなどの設定の不備、サポートが終わったソフトや、既知の脆弱性が直っていないソフトの使い続け
• 攻撃者は、インターネットに公開されている日本のウェブサイトなどを大規模に調べ、侵入の方法が見つかったサイトに入り、個人情報を盗んだとみられる
• 標的の調査や侵入に AI を使っている可能性も高い。これまでの脆弱性診断では比較的低いと評価されたリスクでも、組み合わされることで侵入の原因になった可能性のある事例もある
• 攻撃の大規模化が容易になり、事業規模の大小を問わず、幅広い事業者が攻撃の対象になっていると考えられる

最後の点が、中小企業にとって一番大事なところです。「うちのような小さな会社は狙われない」は、攻撃する側が手作業で標的を選んでいた頃の考え方です。インターネットに出ているサイトを機械的に調べて回る攻撃では、会社の大きさではなく、入れる隙があるかどうかで選ばれます。

文書は3つの章でできています。

なぜ「公開したあと」が危ないのか

注意喚起は、ソフトウェアは導入した時点で脆弱性が見つかっていなくても、運用を始めたあとに新しい脆弱性が見つかり公表されることがある、としています。直接使っている製品だけでなく、その中に組み込まれたオープンソースのソフト（OSS）やライブラリにも脆弱性がありえます。

今週だけでも、例があります。

• 11月11日、Web サーバーのソフト Apache HTTP Server の 2.4.71 が公開され、開発元が深刻度を「重大」とした脆弱性が直りました（「Apache HTTP Server 2.4.71 が公開」）
• 同じ日に、Microsoft の11月の月例の更新が出て、すでに悪用が確認された Outlook の脆弱性が含まれていました（「Microsoft の11月の更新」）

どちらも、公開した日には見つかっていなかった脆弱性です。公開前の診断がどれだけ丁寧でも、こうした脆弱性は防げません。公開したあとに見続ける仕組みがあるかどうかで、知らせが出てから直すまでの日数が変わります。

もう一つの理由は、設定の変更です。注意喚起は、システムの新設や変更、設定の変更にともなって、新しく外に公開される資産や、意図しない公開状態が生じる可能性があるとしています。機能を足す、サーバーを移す、一時的に開発用の画面を開ける。公開したあとの変更のたびに、外から見える所は少しずつ変わります。

公開したあとに見続ける7つのこと

注意喚起の第1章と第3章から、公開したあとに続けることを7つに分けます。各項目の最後に、自社と保守会社のどちらが受け持つことが多いかの目安を添えました。役割の分け方は、注意喚起ではなく、この記事での整理です。

1. 使っている部品と版の一覧を持ち続ける

注意喚起の最初の対策例は「ソフトウェア構成情報の把握・管理」です。新しい脆弱性が公表されたときに、影響があるか、どこまで及ぶかをすぐ特定できるよう、OS、ミドルウェア、フレームワーク、ライブラリについて、製品名・版・使っている場所を把握し、管理するよう求めています。必要に応じて、ソフトウェア部品表（SBOM）やソフトウェア構成解析（SCA）を使い、構成情報を更新し続けるとしています。

中小企業で、いきなり SBOM を作る必要はありません。まず、システムごとに次の表があれば十分です。

この表は、一度作って終わりではありません。部品の版は、更新のたびに変わります。保守会社が更新したら、表も更新してもらう決まりにしておきます。一覧の作り方と、サポートの期限の調べ方は「古いシステムを延命すると決めたら」で詳しく書きました。

受け持ち：表を作って更新するのは保守会社。表を持ち、更新されているかを確かめるのは自社。

2. 脆弱性の知らせを、一覧と照らし合わせる

2つ目の対策例は「脆弱性情報の継続的な収集及び影響確認」です。注意喚起は、米国の CISA が公開している KEV（既知の悪用された脆弱性）カタログに載っているような、実際に悪用が確認されている脆弱性を優先して、自社への影響を確かめるよう求めています。あわせて、製品の会社、NVD、JVN などが出す脆弱性の情報を集め、1の一覧と照らし合わせて、影響の有無と範囲をすぐ特定するとしています。

中小企業が毎日すべての脆弱性情報を読むのは現実的ではありません。次のように分けると回ります。

• 悪用が確認されたものと、深刻度が最も高いもの：IPA の「重要なセキュリティ情報」と JPCERT/CC の注意喚起に出たら、その日のうちに一覧と照らす
• それ以外：保守会社が月に一度まとめて照らし、該当したものを報告する

照らし合わせた結果は、「該当なし」も含めて残します。何も報告がないのが「見ていない」のか「該当しなかった」のかを区別できないと、点検をしていないのと同じになります。

受け持ち：照らし合わせるのは保守会社。悪用が確認された脆弱性の知らせが出たとき、保守会社に確認を求めるのは自社。

3. 直す順番と期限を、先に決めておく

3つ目の対策例は「脆弱性対処の優先順位及び対応期限の決定」です。脆弱性の深刻度、実際に悪用されているか、インターネット経由で悪用できるか、システムの重要度、事業への影響を踏まえた評価の基準をあらかじめ決め、それに基づいて対応の順番と期限を決めるよう求めています。

ここで大事なのは「あらかじめ」です。重大な脆弱性が出てから、直すか、いつ直すか、費用はどうするかを話し合うと、それだけで数日が過ぎます。たとえば、次のような基準を保守会社と決めておきます。期間の数字は一例で、システムの重要度に合わせて決めてください。

4つ目の対策例として、修正をすぐに当てられないときは、影響を受ける機能を止める、アクセスを制限するなどの暫定の緩和策をとり、恒久的な対処が終わるまで確かめ続けることも挙げられています。すでに悪用が確認されている脆弱性については、関連するログを見て、侵入された跡がないかも調べるよう求めています。直して終わりではなく、「直す前に入られていないか」まで見るということです。

受け持ち：基準を決めるのは自社と保守会社で一緒に。期限を守って直すのは保守会社。

4. 外から見える所の一覧を持ち、減らす

注意喚起の第1章（2）は「アタックサーフェスの継続的な棚卸し及び最小化」です。アタックサーフェスは、インターネットに出ていて攻撃の入口になりうる所のことです。

注意喚起は、実際に起きた例として次を挙げています。

• インターネットに公開されたシステムの管理画面に、推測されやすいパスワード、総当たり、認証の脆弱性を使った回避で入られた
• 本来は外に出すつもりのなかったデバッグ用の機能や、システム管理用の窓口に、インターネットから入れる状態になっていた

対策例として、公開している IP アドレス、ドメイン名、サービス、通信のポート、ウェブアプリ、API を洗い出すこと、管理画面・デバッグ用の窓口・開発や検証の環境・データベースの管理機能について、外から入れるか、公開が必要かを点検することが挙げられています。クラウドのストレージの共有設定や、ウェブサーバーで意図しないファイルが公開されていないかも確かめるよう求めています。

発注する側が持っておきたいのは、次の一覧です。

一覧を作ると、「この画面は誰が何のために開けているのか分からない」というものが、たいてい見つかります。それを閉じるだけで、攻撃される入口が減ります。

さらに注意喚起は、システムの変更のたびに新しい公開状態が生じうるとして、外から見える所を続けて点検し、前回の一覧と比べて変化を見つけるよう求めています。外から見える資産を探す ASM（Attack Surface Management）という方法もあります。ASM と脆弱性診断の違いと使い分けは、SucSak の「ASMと脆弱性診断の違い」にまとまっています。

IPA が公開している「安全なウェブサイトの運用管理に向けての20ヶ条」（2019年3月更新）にも、「公開すべきでないファイルを公開していませんか？」「不要になったページやウェブサイトを公開していませんか？」「不要なサービスやアプリケーションがありませんか？」といった項目があります。少し前の資料ですが、今回の注意喚起の参考資料にも挙げられており、点検の項目を作るときの下敷きになります。

受け持ち：一覧を作り、点検するのは保守会社。公開が必要かを決めるのは自社。

5. 診断を続け、大きな変更のたびに点検する

第1章（3）は「AI の活用等による継続的な脆弱性診断及び不審な挙動の監視」です。注意喚起は、ウェブサイトやアプリの公開前だけでなく、認証・認可、API、個人情報の扱いに関わる重要な変更のときと、運用を始めたあとも、リスクに応じて診断、点検、監査を続け、見つかった脆弱性を直したうえで結果を確かめるよう求めています。

また、攻撃する側で AI の活用が進んでいることを踏まえ、守る側でも AI を使った診断のツールなどの活用を検討するよう求めています。ただし、AI による評価の結果は根拠と妥当性を確かめ、最終的な判断は人が行うとしています。

中小企業で決めておきたいのは、次の2つです。

• 定期の診断の間隔：年に1回など。間隔の決め方は SucSak の「脆弱性診断の頻度は？」が参考になります
• 「重要な変更」の線引き：ログインのしかたを変える、外部と API でつなぐ、個人情報の項目を増やす、といった変更のときは、本番に出す前に点検する

2つ目は、保守の契約や、改修を頼むときの進め方に書いておかないと、まず守られません。小さな改修のつもりの変更でも、認可の仕組みに触れていることがあるからです。診断の費用の考え方は「脆弱性診断の費用はどう決まる？」で、診断とペネトレーションテストの違いは「脆弱性診断とペネトレーションテストの違い」で書きました。

受け持ち：間隔と線引きを決めるのは自社。点検をするのは保守会社か、診断の会社。

6. ログで、不審な動きを見る

同じく第1章（3）の対策例は「ログ及びワークロードの継続的な監視・検知」です。ウェブサーバー、API の入口、認証の仕組み、クラウドのサービスのログを取り、不審な認証、権限の不正な使用、大量のデータの取得を続けて監視するよう求めています。SOC による監視や、SIEM によるログの集約と分析、EDR による端末やサーバーの監視も挙げられています。

中小企業が SOC を自前で持つのは難しいですが、最低限、次は決められます。

• どのログを、どれだけの期間残すか（ログインの記録、管理画面の操作、データの書き出し）
• 誰が、どの間隔で見るか
• 何が起きたら知らせるか（同じアカウントへのログインの失敗が続く、深夜に大量のデータが書き出される、など）

ログは、侵入されたかどうかを確かめる唯一の手がかりになることがあります。3で触れた「直す前に入られていないか」を調べるときも、ログが残っていなければ調べられません。残していないログは、あとから取り出せません。

IPA の20ヶ条にも、ウェブアプリケーション、ウェブサーバ、ネットワーク機器のそれぞれについて、「ログを保管し、定期的に確認していますか？」という項目があります。

受け持ち：ログを取り、見張るのは保守会社か監視の会社。何を知らせてほしいかを決め、知らせを受けて判断するのは自社。

7. 委託先の入口と、アカウントを締める

第3章は「サプライチェーンを通じた侵害への対策」です。注意喚起は、業務委託先や保守事業者の環境を足がかりに、発注元のシステムへ侵入される事案が確認されているとしています。委託先が使うリモート接続の環境は、攻撃者にとって「正規の認証情報を使った侵入口」になりえます。そして、その場合でも、サービスの停止や情報漏えいの影響は発注元が負うとしています。

対策例として挙げられているのは次のとおりです。

• 委託先が使う VPN、リモートデスクトップ、保守用の回線などの接続経路を洗い出し、多要素認証を使う
• 多要素認証が難しい経路は、接続元の IP アドレスの制限、作業のときだけ接続を開ける、作業の記録を取る、などで代える
• 作業が終わった委託先のアカウントや、ずっと付いたままの管理者の権限を棚卸しし、無効にする・絞る

最後の点は、発注する側が自分で確かめられます。保守会社が担当者を替えたとき、開発会社との契約が終わったとき、前の人のアカウントが残っていないか。年に一度、アカウントの一覧を出してもらい、一人ずつ確かめるだけでも違います。

また、個人情報の取り扱いを委託する場合、個人情報保護法第25条により、委託先への必要かつ適切な監督が求められていることにも触れています。発注の仕様書や委託の契約に、再委託の手続き、事故が起きたときの通知の義務と連絡先、契約が終わったときのデータの消去を入れることも、対策例に挙がっています。契約の前に開発会社に確かめたい項目は、「開発会社に確認したいセキュリティの項目」にまとめています。

受け持ち：接続経路に多要素認証を入れるのは保守会社。アカウントの棚卸しを求め、結果を確かめるのは自社。

重大な脆弱性が出た日の、初動の手順

第3章（2）の最初の対策例は、「深刻な脆弱性の公表時における初動対応手順の明確化」です。ここには、外に頼んでいる会社にとって一番大事な一文があります。緊急の対処が求められたときに、保守事業者任せにせず、すぐに判断できる手順を先に決めておく、というものです。

挙げられている中身は次のとおりです。

• 開発や保守を頼んでいる主なシステムで、組み込まれている OSS の版とサポートの終了の状況を、平時から把握する
• NVD や JVN などの公開情報をもとに、委託先と一緒に、自社のシステムへの影響の有無をすぐ照らし合わせる
• 影響を調べる責任者、委託先との役割の分担、経営に報告する基準を決める
• 修正を当てるか、WAF で防ぐか、その機能を止めるか、暫定の対策を判断する手順を決める

これを、A4 一枚の手順にしておきます。

重大な脆弱性への備えは、2026年10月の PHP の事例を例に、「PHPの重大な脆弱性はその後どうなったか」の「平時に決めておく5つのこと」でも書きました。

月・四半期・年で回す点検表

ここまでの7つを、間隔ごとにまとめます。間隔は、注意喚起で決められているものではなく、この記事での目安です。システムの重要度や、扱う個人情報の量に合わせて決めてください。

この表を見て「量が多い」と感じたら、まず「知らせが出たとき」と「四半期ごと」の外から見える所の点検の2つから始めてください。部品の一覧と、外から見える所の一覧があれば、残りは少しずつ足せます。

保守の契約で決めておくこと

点検表を回すには、保守会社がどこまで受け持つかを、契約や取り決めで決めておく必要があります。保守の契約は「障害が起きたら直す」ことが中心で、上の点検の多くは書かれていないことがよくあります。

確かめたい項目は次のとおりです。

• 部品と版の一覧を作り、更新して渡してくれるか
• 脆弱性の情報を、どの間隔で、何と照らし、どの形で報告してくれるか（該当なしも報告するか）
• 悪用が確認された脆弱性が出たとき、何時間以内に該当するかを答えてくれるか
• 更新を当てる作業が、月々の保守の範囲か、別の見積もりか
• ログをどれだけ残し、誰が見て、何があれば知らせてくれるか
• 外から見える所の点検と、アカウントの棚卸しをしてくれるか
• 契約が終わるとき、アカウントの無効化と、データの消去をどう確かめるか

注意喚起は、委託先に対策を求めるときは、費用の負担や実施の方法を十分に話し合い、取引上の地位を利用した一方的な押し付けにならないよう求めています。今の保守の金額で全部をやってもらうのは、無理なことが多いはずです。何を今の範囲でやり、何を追加で頼むかを話し合い、書面に残します。保守会社を変えるときに引き継ぐものの一覧は、「システムの保守を引き継いだら、最初にやること」で書いています。

次に作るシステムで、最初から決めておくこと

注意喚起の第2章は、設計と開発の段階の話です。公開したあとの点検を軽くするには、作る段階で決めておくのが一番効きます。注意喚起は、脆弱性や設定の不備がリリースのあとに見つかった場合、あとから直す費用は、設計の段階で防ぐ場合と比べて大幅に増えるとしています。

次にシステムを作るとき、発注の段階で決めておきたいのは次のことです。

• 管理画面や運用の機能を、インターネットに不用意に出さない作りにする
• ログを何のために、どれだけ取るかを、要件として決める
• 使う部品の一覧（SBOM）を、納品物として出してもらう。注意喚起も、開発を委託するときに SBOM の提出を契約や仕様に定め、検収のときに確かめることを挙げています
• 公開の前に診断を受け、決めた基準より危ない指摘が残ったまま本番に出さない

公開の前に確かめる項目は、AI で作るアプリの例ですが「バイブコーディングのデメリットとセキュリティ：公開前に確かめる10項目」にまとめています。

おわりに

国の注意喚起は13ページあり、SOC、SIEM、SBOM、ASM といった言葉が並ぶので、専任のいない会社には遠い話に見えるかもしれません。けれども、書かれていることを一つずつほどくと、「使っている部品を知っておく」「外に出ている所を知っておく」「おかしな動きを見る」「委託先の入口を締める」「出たときの手順を決めておく」の5つに集まります。どれも、発注する側が決めなければ始まらないことです。

公開した日が一番安全な状態で、そこから先は、見続けた分だけ安全が保たれます。まずは、手元に部品と版の一覧があるかを確かめるところから始めてください。

出典（2026年11月12日に確認）

• 内閣官房国家サイバー統括室「個人情報の漏えい等につながる不正アクセスへの対策について ～ウェブサイトやモバイルアプリに関する基本的な対策の徹底～」（2026年11月5日）
• IPA「安全なウェブサイトの運用管理に向けての20ヶ条 〜セキュリティ対策のチェックポイント〜」（2019年3月6日更新）
• JPCERT/CC「Weekly Report 2026-11-11号」
• The Apache Software Foundation「Apache HTTP Server 2.4 vulnerabilities」