AIが作った仕組みの穴を塞ぐ5工程｜脆弱性管理を回す順番

「毎月、対応が必要だという指摘が数百件届きます。全部は直せません」「危険度が高いものから順に直しているのに、いつまでも件数が減りません」——この2つは、対応にあたっている部門からほぼ必ず対で届きます。件数は実際に増えていて、2025年に公表され国内でも広く引用された調査では、生成AIに一般的な開発作業をさせたところ、出来上がったコードのおよそ45パーセントに、代表的な危険類型に当たる欠陥が含まれていたと報告されています。ただし、件数が減らない原因は直す速さではありません。本当の原因は、直す順番を決める基準が危険度の点数しか無いことです。この記事では、洗い出す、危険度を付ける、直す順を決める、直す、確かめて記録する、という5つの工程で脆弱性管理を回す順番を整理します。

件数が減らない原因は、直す速さではない

対応が追いつかないという相談を受けると、多くの場合、話は人手の不足に向かいます。担当が2人しかいない、他の業務と兼務している、専門の道具を入れる予算がない。どれも事実ではあるのですが、人を倍にしても件数はあまり減りません。理由は単純で、件数を減らしているのは「直した数」ではなく「直さなくてよいと判断できた数」だからです。

届く指摘のうち、実際に自社に関係するものは一部です。自社が使っていない機能に関するもの、社内からしか触れない仕組みに関するもの、既に別の方法で塞がっているもの。ここを切り分けられれば、対応すべき件数は大きく減ります。切り分けの基準が無いまま全部を等しく扱うから、着手する前の段階で列が詰まります。最初に作るべきなのは、直す速度ではなく、直さない理由を書ける基準です。

公的な整理でも、この領域の位置づけは動いていません。情報処理推進機構が2026年1月29日に公表した「情報セキュリティ10大脅威 2026」では、組織向けの4位に「システムの脆弱性を悪用した攻撃」が入り、6年連続9回目の選出となりました。手口は2つに分けて説明されています。穴の情報が公表された後、修正を当てていない仕組みを狙う形と、対応策が広く公表される前に悪用する形です。前者は、運用の速さで防げる範囲です。

脆弱性管理とは何か。1回の対応ではなく、回し続ける運用

言葉の整理から始めます。脆弱性管理とは、自社が動かしている仕組みに空いた穴を見つけ、危険度を付け、直す順を決め、直し、直ったことを確かめて記録するまでを、繰り返し回す運用のことです。1件ごとの対応作業を指す言葉ではありません。ここを取り違えると、「今回は対応が終わりました」という報告で会話が終わり、次の月に同じ状態から始めることになります。

運用である以上、評価されるのは1件の速さではなく、回り続けているかどうかです。実務で見るのは3つの数字だけで足ります。未着手のまま30日を超えた件数、外から触れる仕組みで未対応のまま残っている件数、そして直したのに再び同じ指摘が出た件数。この3つが動いていれば、総件数が多くても運用は健全です。逆に総件数だけを追うと、指摘を出す仕組みの設定を緩める方向に力が働きます。

もう1つ、最初に決めておくことがあります。対象の範囲です。自社で作った仕組み、買ってきた製品、外部のサービス、委託先が動かしているもの。このうちどこまでを自分たちの管理下と呼ぶかを書いておかないと、工程1の一覧づくりが終わりません。範囲を決めずに一覧を作り始めると、作業は必ず途中で止まります。

穴の出どころが変わった。AIが書いたコードと、AIにつないだ道具

従来、穴の出どころは大きく2つでした。自社で書いたコードの中の作り込みの誤りと、買ってきた製品や取り込んだ部品の中に見つかった欠陥です。ここに、この数年で2つ目の系統が加わりました。AIに書かせたコードと、AIを業務につなぐために増えた接続です。前者はコードの中の穴、後者は経路の穴で、性質がまったく違います。

前者について、2025年に公表され国内でも広く引用された調査では、生成AIに一般的な開発作業をさせたところ、出来上がったコードのおよそ45パーセントに、代表的な危険類型に当たる欠陥が含まれていたと報告されています。同じ報告では、使うモデルを変えても出力の傾向がほとんど変わらないという指摘も出ています。この数字は調査の条件で変わるため、自社の数字として持ち出さず、目安として扱ってください。

実務で効くのは、割合そのものより傾向が揃うという性質のほうです。人が書くコードの誤りは書き手ごとにばらつきますが、機械が書くコードの誤りは同じ形で量産されます。1つ見つかったら、同じ形が他の場所にも並んでいる可能性が高い。だから対応は1件ずつではなく、同じ形をまとめて探す形に変わります。見つけた欠陥の形で全体を検索する、という手順を工程に組み込みます。

5工程の全体像。順番を入れ替えると必ずどこかで詰まる

進め方を5つの工程に分けます。この順番は入れ替えられません。一覧が無いまま危険度を付けると、点数は付いても自社に関係するかどうかが判定できません。順番を決めずに直し始めると、手を付けやすいものから消えていき、外から触れる危険なものが最後まで残ります。

実務で詰まるのは、真ん中の「直す」ではありません。1工程目と5工程目です。一覧が無いから毎回ゼロから調べ、記録が無いから前回と同じ議論をやり直す。直す速さを上げる投資より、この2つを整える投資のほうが、件数に効きます。

工程1：洗い出す。直す前に、何が動いているかの一覧を作る

一覧に載せる項目は5つで足ります。名前、版、置き場所、外から触れるかどうか、そして誰が面倒を見ているか。最後の項目が最も重要で、ここが空欄の行は、以後の全工程で止まります。担当が決まっていない仕組みは、危険度を付ける人も、直す人も、直ったことを確かめる人もいないからです。

一覧づくりが終わらない典型的な理由は、完璧を目指すことです。すべてを網羅してから次へ進もうとすると、作っている間に前半が古びます。実務では、外から触れる仕組みだけを先に一覧化して、次の工程へ進むのが現実的です。外から触れない範囲は、四半期に1回の棚卸しで少しずつ埋めます。

AIを使って作った仕組みには、特有の見落としがあります。試しに作った小さな仕組みが、そのまま業務で使われ続けている場合です。作った本人は試作のつもりなので、一覧にも申告しません。試作として作られ、そのまま使われているものが最も見つかりません。探し方は、通信の記録と、少額の継続決済の記録の2つです。どちらも既に社内にあります。

工程2：危険度を付ける。点数は入口であって答えではない

公表される穴には、共通の物差しで点数が付いています。この点数が何を表しているかを正確に押さえておくことが、この工程の要点です。ある解説では、この点数について「攻撃を受けた場合の影響度を示すもので、攻撃のしやすさや発生頻度についての指標は含まれていない」と明記されています。つまり点数は、突かれたときにどれだけ困るかであって、突かれやすさではありません。

突かれやすさを見るには、別の材料が要ります。実務でよく使われるのは2つです。1つは、実際に悪用が確認された穴を集めた一覧で、米国の政府機関が公表しています。これは過去から現在の事実を示すものです。もう1つは、その穴が近い将来に悪用される確率を推定して公表している指標で、こちらは予測です。事実と予測を混ぜないことが、この工程での注意点になります。

見るもの	何を表しているか	時間の向き	この材料だけで決めるとどうなるか
公表されている危険度の点数	突かれたときの困り方の大きさ	その穴の性質。時間の概念は無い	社内にしか無い仕組みの高得点が、外から触れる中得点より先になる
悪用が確認された穴の一覧	実際に悪用された事実があるかどうか	過去から現在	まだ悪用されていないが確実に狙われるものが、後ろに回る
悪用される確率の推定値	近い将来に悪用される見込み	これから	推定が外れたときに、根拠を説明できない。参考値として扱う
外から触れる場所にあるか	攻撃する側が到達できるかどうか	現在の構成	自社の構成が変われば結論も変わる。構成変更のたびに見直しが要る

4つを別々の列として持つのが実務の型です。1つの合成点にまとめたくなりますが、まとめるとなぜその順番になったのかを後から説明できなくなります。説明できない順番は、業務を止める判断を求められたときに通りません。

点数だけで順番を決めると外れる理由

ここが、この記事で最も伝えたい部分です。点数の高い順に並べた列は、直感的には正しく見えます。しかし実際に狙われるのは、点数の高いものではなく、外から到達できるものです。攻撃する側は、まず到達できる先を探し、そこに使える穴があるかを確かめます。到達できない場所にどれだけ大きな穴があっても、その穴は使われません。

具体例で考えます。社内の限られた人しか使わない仕組みに、点数の高い穴が見つかったとします。一方、誰でも見られる問い合わせフォームを載せている仕組みに、点数が中程度の穴が見つかったとします。点数順なら前者が先ですが、実務では後者が先です。到達できるかどうかは、点数と掛け算ではなく、順番の前提として先に効きます。

ある解説でも、優先順位の正解は組織ごとにあってひとつではない、と述べられたうえで、判断の軸として「実際に使用しているソフトウェアか」「修正を当てたときの業務への影響の有無」「インターネットに公開されているかどうか」が挙げられています。3つとも、自社の状況を知らないと答えられない項目です。だから外部の点数だけでは順番が決まりません。

工程3：直す順を決める。4つの条件で並べ替える

並べ替えの基準を、文書として1枚にしておきます。その場の判断で決めていると、担当が変わった時点で再現できなくなり、経営層に説明を求められたときにも答えられません。基準に使う条件は4つです。外から触れるか、悪用の事実があるか、点数がどれくらいか、修正を当てたときに業務が止まるか。

並べ方の型はこうです。まず、外から触れる場所にあり、かつ悪用の事実があるものを最上位に置きます。次が、外から触れる場所にあって点数の高いもの。3番目が、外から触れないが悪用の事実があるもの。以下、点数の順です。最初の2段で全体の1割から2割に収まるのが健全な形で、ここが半分を超えるなら、外から触れる範囲を減らす設計の話に戻ります。

4つ目の条件は、順番ではなく段取りに効きます。修正を当てると業務が止まるものは、止められる時間帯を先に確保しないと着手できません。順位が高くても、確保が取れていなければ着手日は決まらない。優先順位と着手日は別々に管理します。同じ表で管理すると、止められないものが永久に最上位に居座り続けます。

工程4：直す。修正を当てる以外の選択肢を先に書いておく

直すという言葉は、修正を当てることだけを指していません。取れる手は4つあります。パッチを当てる、その機能を止める、外から到達する経路を遮る、直さずに監視を厚くして残す。この4つを最初から選択肢として持っておかないと、パッチが出ていない穴や、当てると業務が止まる穴の前で、対応が完全に止まります。

4つ目の「直さずに残す」を、正式な選択肢として認めておくことが実務では重要です。ただし条件を付けます。決めた人の名前、残す理由、代わりに何をするか、いつ再検討するかの4つを記録に残すこと。この4つが書かれていない先送りは、単なる放置と区別できません。放置と、記録された先送りを分けるのは、この4項目の有無だけです。

• パッチを当てる前に、当てた後の動作確認の手順を書いておく。確認できないものは当てられない
• 当てられない理由が「怖いから」の場合は、試す環境が無いことが本当の問題。環境の用意を先に片付ける
• 機能を止める選択肢は、止めたときに困る部署を先に特定してから提示する。事後に伝えると次から相談されなくなる
• 経路を遮る手を取ったときは、遮った設定そのものを一覧に載せる。載せないと数年後に誰も理由が分からなくなる
• 直さずに残すと決めたものは、再検討の日付をこよみに登録する。表に書いただけでは見返されない

同じ形の欠陥が並んでいる場合は、1件ずつ直すより、形で検索してまとめて直すほうが速く終わります。AIに書かせたコードでは、この形がそろいやすい。1件目を直したところで、同じ書き方が他に何か所あるかを必ず数えます。数えずに1件だけ直すと、同じ指摘が翌月にまた出ます。

工程5：確かめて記録する。記録が無いと同じ議論を毎回やり直す

最後の工程が、いちばん省略されます。直したという実感があるので、確認と記録が後回しになる。しかしこの工程を飛ばすと、次の月に同じ指摘が届いたときに、前回どう判断したかが分からず、最初から調べ直すことになります。運用が回らない会社では、この再調査に毎月の工数の大半が消えています。

記録に残す項目は6つです。対象、判断した日、判断した人、選んだ手、確認の方法、再検討の日付。文章で書く必要はなく、表の1行で足ります。直さないと決めたものこそ、記録の価値が高くなります。直したものは動作で確かめられますが、直さないと決めたものは記録以外に痕跡が残らないからです。

確認の方法にも1つ条件を付けます。直した本人以外が確かめること。同じ人が直して確認すると、直した前提で見るため、当て漏れに気づけません。人数が足りない場合は、確認を翌週に回して、日を空けてから見るだけでも効果があります。加えて、修正を当てた後に元の指摘が消えているかを、指摘を出した仕組み側で再度見ます。

AIが書いたコードで増える穴と、増えない穴

AIに書かせたコードで何が増え、何が増えないのかを分けておきます。増えるのは、定型的な作り込みの誤りです。入力の確かめ方が甘い、権限の確認が抜けている、秘密の値がコードの中に直接書かれている。どれも古くからある型で、目新しい穴ではありません。新種の穴が増えるのではなく、既知の型が量産されるという理解が正確です。

増えないのは、その会社固有の業務の作り込みに関する誤りです。誰にどこまで見せてよいか、どの承認を通すべきか、といった判断は、そもそもコードの外側にあります。ここは人が設計する部分なので、書き手が機械に変わっても増減しません。逆に言えば、この部分の設計を渡すと、正しさを確かめる手立てが無くなります。

実務の対応は2つです。1つは、量産される既知の型を機械的に検査する仕組みを、書く工程の中に入れること。書き終えてから人が読む形では追いつきません。もう1つは、同じ形の欠陥が見つかったときに、全体を検索する手順を決めておくこと。同じ癖の間違いは、同じ癖のまま他の場所にも入っています。

AIにつないだ道具が増やす経路。鍵と権限の棚卸し

もう1つの系統が、経路の穴です。AIを業務に組み込むと、外部の仕組みとの接続が増えます。接続には認証のための鍵と、相手側で何ができるかという権限が要ります。この2つは、コードの穴と違って、検査の道具では見つかりません。動いている間は正常だからです。

棚卸しで見る項目は4つです。誰が発行したか、何のために発行したか、権限の範囲はどこまでか、有効期限はいつか。実務で最も多い問題は、権限を広く取りすぎていることと、期限を切っていないことの2つです。使わなくなった接続の鍵が、失効されないまま何年も生きているという形で残ります。

この領域は、脆弱性管理の一覧と別の表で管理されがちですが、同じ表に載せるほうが実務は楽になります。理由は、事故が起きたときに見る順番が同じだからです。何が動いていて、外から触れる場所はどこで、そこに渡した鍵は何か。表を分けると、事故のときに2つの表を突き合わせる作業が発生します。夜間にその作業をする余裕はありません。

AIの使いどころ。知らせの一次仕分けと、影響範囲の下書き

この運用のどこにAIを入れるかは、はっきり決められます。向いているのは、量が多くて判断の幅が狭い作業です。逆に、判断の幅が広く、外したときの説明が要る作業には向きません。具体的には次の3か所です。

1. 公表された知らせの一次仕分け：届いた知らせと自社の一覧を突き合わせ、関係しそうなものだけを残す。人が全部読むと、月の前半が読む作業で終わる
2. 影響範囲の下書き：関係ありと判定されたものについて、どの仕組みのどの部分に影響しそうかを下書きさせる。人はその下書きを確かめる側に回る
3. 同じ形の欠陥の洗い出し：1件見つかった欠陥の形を渡し、コード全体から同じ書き方をしている箇所を挙げさせる。網羅性は人が別の手段で確かめる

1つ目には条件が付きます。関係なしと判定したものも、件数と判定理由を残させることです。外した側を読まないままだと、仕分けが甘くなっても誰も気づけません。関係ありだけを残す運用は、見逃しの件数がゼロに見えるだけで、実際にゼロなのかは分かりません。月に1回、関係なしの中から無作為に10件を人が読む、という手順を入れておきます。

2つ目には別の条件が付きます。下書きに、参照した情報の出どころを必ず添えさせること。出どころのない影響範囲の説明は、確かめようがないため使えません。根拠を書かせて、人がその根拠を当たってから動きます。この一手間を省くと、下書きの誤りがそのまま報告書に載ります。

直す順を決めるのは人。AIに渡してはいけない判断

渡してはいけないのは3つです。直す順を決めること、直さないと決めること、業務を止めてよいかを判断すること。理由は能力の問題ではありません。この3つは、自社の業務の重みと、止まったときに誰が困るかを知らないと決められないからです。外部の情報だけで組み立てられる判断ではありません。

順番の判断を機械に委ねた場合の実害は、間違いそのものより説明の不能にあります。経営層に「なぜこの穴を先月直さなかったのか」と問われたときに、根拠を示せない。脆弱性管理は、事故が起きた後に判断の記録を読まれる前提の運用です。読まれて困る記録しか残っていない状態を作らないことが、この線引きの目的になります。

実務での線の引き方は単純です。候補を並べるところまでは機械、そこから順番を決めるのは人。そして決めた理由を1行で残す。理由が1行で書けない順番は、たいてい根拠が弱い。書けないと気づいた時点で、判断をやり直す合図になります。この1行が、翌年の担当者に引き継がれる唯一の資産になります。

情報システムの専任がいない会社で、教科書と変わるところ

一般的な解説は、専任の担当が複数人いて、検査の道具も導入済みの環境を前提に書かれています。BtoBの事業会社、特にマーケティング部門が自分たちで仕組みを持っている場合は、前提が3つ違います。担当が兼務であること、対象の件数が少ないこと、そして修正のために業務を止められる時間帯が限られていることです。

担当が兼務であるという前提からは、周期の設計が変わります。毎日見る運用は続きません。外から触れる仕組みだけを週1回、それ以外は月1回という2段構えにして、対象を絞ります。件数が少ないことは有利に働きます。一覧が数十行なら、道具を買わなくても表計算で回ります。

止められる時間帯が限られている点は、逆に有利です。件数が少ないので、月に1回の作業枠を決めてしまえば、そこにまとめて当てられます。決めておかないと、毎回関係部署との調整から始まって着手が遅れます。作業枠を先に取るだけで、着手までの日数は目に見えて縮みます。委託先が動かしている仕組みについては、この枠を契約に書いておきます。

実務仕様と、よくある失敗の型

脆弱性管理を回す形と、途中で止まる原因を並べます。この5工程は一度組めば終わりではなく、知らせが届き続ける前提で持ち場を決め直す必要があります。

• 一覧の更新は、仕組みを作った側の作業手順に組み込む。管理側が後から聞いて回る形にすると必ず古びる
• 週1回の確認は30分に固定する。時間を決めないと、忙しい週から順に飛ばされる
• 判断の記録は6項目の表1枚に統一する。文書を分けると、事故のときに探す時間が生まれる
• 月次で見る数字は3つだけにする。未着手30日超、外から触れる未対応、再発の件数
• 年に1回、直さないと決めたものだけを通しで読み直す。1件ずつの再検討では全体の傾きが見えない

• 点数の高い順に並べて上から着手する——外から触れる中程度のものが後回しになり、実際に狙われる先が残る
• 総件数を減らすことを目標にする——指摘を出す仕組みの設定を緩める方向に力が働き、見えなくなるだけになる
• 一覧を完璧に作ってから次の工程へ進む——作っている間に前半が古びる。外から触れる範囲だけで先へ進む
• 直した本人が確認する——直した前提で見るため、当て漏れに気づけない。日を空けるだけでも効果がある
• 直さないと決めた理由を残さない——放置と区別できなくなり、事故のときに説明できない
• 接続の鍵を脆弱性の一覧と別の表で管理する——事故のときに2つの表を突き合わせる作業が増える

3つの失敗に共通しているのは、目標の置き場所です。数えやすい数字が、そのまま目標になっています。総件数、対応の速さ、一覧の網羅率——どれも報告には使えますが、狙われる入り口が実際に塞がったかどうかは表しません。見る数字を絞るときは、塞がった箇所の割合のように、対処の結果が動いたときだけ動く数字を選びます。

まとめ

脆弱性管理は、届いた指摘を順番に処理する作業ではなく、洗い出す、危険度を付ける、直す順を決める、直す、確かめて記録する、の5工程を回し続ける運用です。件数が減らないとき、原因は直す速さではありません。直さなくてよいと判断できる基準が無いために、着手する前の段階で列が詰まっています。詰まるのは真ん中の工程ではなく、1工程目の一覧づくりと5工程目の記録です。

順番を決めるときに、危険度の点数だけを見てはいけません。点数が表しているのは突かれたときの困り方であって、突かれやすさではないからです。外から触れる場所にあるか、実際に悪用の事実があるか、修正で業務が止まるか。この3つを別々の列として持ち、合成点にまとめないこと。まとめた瞬間に、なぜその順番になったのかを説明できなくなります。

穴の出どころは変わりました。AIに書かせたコードでは、新種の穴が増えるのではなく、既知の型が同じ形で量産されます。だから1件見つけたら、同じ形を全体で数えます。AIにつないだ道具では、鍵と権限という検査で見つからない経路が増えます。だから同じ表に載せます。そしてAIには、知らせの一次仕分けと影響範囲の下書きまでを任せ、直す順を決める判断と、その理由を1行で残す仕事は人が持ちます。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。