COLUMN

コラム

2026年10月30日

検知だけでは守れない。パッチなき老朽システムの脆弱性を"直し続ける"AI駆動開発の実装力

実写写真: サーバールームまたはセキュリティ監視センターで、エンジニアがモニターを前に作業している様子。暗めのトーンでプ…

脆弱性診断ツールを導入し、毎日スキャンを回しているのに、情報漏えい事故のニュースは一向に減らない——そんな違和感を抱いたことはないだろうか。デジタル庁の発表によれば、2026年6月、政府共通のITサービス基盤であるガバメントソリューションサービス(GSS)がVPN機器の脆弱性を突かれて不正アクセスを受け、氏名・メールアドレス・電話番号など最大約24.6万件の情報が漏えいした可能性があるという。政府機関ですら脆弱性対応を完結できなかったこの事案は、「検知」と「対策完了」の間に大きな溝があることを物語っている。

本記事では、脆弱性対応をめぐる「検知はできているのに、なぜ直らないのか」という構造的な問題を整理し、そのボトルネックを解くカギとなるAI駆動開発の実装力について解説する。

「検知」はすでにコモディティ化した市場である

棒グラフ: IPA「情報セキュリティ10大脅威2026」組織編の上位5脅威(ランサムウェア1位、サプライチェーン攻撃2位…

脆弱性を継続的に検知するためのツールは、いまや珍しいものではない。海外ではQualys、Tenable(Nessus)、Wiz、Snykといったサービスが定番となり、国内でもAeyeScanやAikido Securityなど、クラウド型で常時スキャンできるサービスが普及している。IPAが公表した「情報セキュリティ10大脅威 2026」組織編でも、「システムの脆弱性を悪用した攻撃」は第4位にランクインしており、ランサムウェア攻撃(11年連続1位)と並んで企業が意識すべき脅威の定番になっている。

加えて、見つかった脆弱性への対応を自動化する「パッチ管理ツール」も存在感を増している。Ivanti Patch for Endpoint ManagerやNinjaOneなどがその代表例だ。だが、これらの仕組みにはある共通の前提がある。OS・ミドルウェア・市販のサードパーティ製品に対して、ベンダーが公式に配布するパッチを自動適用する仕組みだという点だ。

言い換えれば、検知も自動パッチ適用も、「ベンダーが面倒を見てくれるソフトウェア」が対象になって初めて機能する。ここに、多くの企業が見落としがちな死角がある。

こうした死角を自社の環境でどう埋めるかという論点は、AI-SecBoxのような、検知から修正検証までを社内完結で回す仕組みが近年注目され始めている背景でもある。

自社独自に構築したシステムには、そもそも「当てるパッチ」が存在しない

老朽化した自社独自開発のレガシーシステム、いわゆるスクラッチ開発の基幹システムには、そもそも適用できる「ベンダー公式パッチ」が存在しない。IPAの注意喚起によると、2025年10月にサポートが終了したWindows 10では、新たに見つかった脆弱性に対するセキュリティ更新プログラムがもう提供されない。米国ではCISAの是正指令(BOD 26-02)が、2026年2月、サポート終了したルーターやファイアウォール等のエッジ機器を連邦機関に12〜18か月以内で是正・交換するよう義務付けた。冒頭で触れたGSSの事案も、NTT-ATの調査が指摘するように、VPN装置がランサムウェアの主な侵入口になっている実態と地続きの問題だ。

横棒グラフ: 企業の未適用パッチ理由(複数回答)の割合(資産管理不足38.1%、テスト環境なし30.6%、人手不足29.…

問題は、サポート切れの機器やソフトウェアだけではない。自社で開発した独自アプリケーションそのものが抱えるリスクも大きい。企業の脆弱性管理に関する実態調査では、自動更新されないソフトウェアや自社開発アプリケーションに「未適用のパッチがある」と回答した企業が61.1%にのぼった。理由の内訳を見ると、資産管理の不足(38.1%)、テスト環境の欠如(30.6%)、人手不足(29.4%)が上位を占める。見つかった脆弱性を直すには、結局は誰かがコードを書いて修正するほかなく、多くの企業でこの工程が開発リソース不足とレビュー速度の限界によってボトルネックになっているのだ。

「検知」は飽和した市場になった一方で、ベンダー管理外のレガシー資産を「直す」仕組みは、驚くほど手つかずのまま残されている。

「検知+AIによる自動修正」はすでに始まっている。ただし対象が違う

実写写真: エンジニアがノートPCでコードレビューをしている様子、画面にプルリクエストらしきものが映っている

ここで公平を期すために触れておきたいのは、「検知した脆弱性をAIが修正する」という発想自体は、すでに実用化が進んでいるという事実だ。GitHubは2024年、コードスキャンで検出した脆弱性をAIが修正案として提示する「Copilot Autofix」を正式リリースした。GitHubの公式発表によると、SQLインジェクションなどの修正にかかる時間を手動対応の3倍以上に短縮できたという。国内でもGMO Flatt Securityのセキュリティ診断AIエージェント「Takumi byGMO」が2026年2月、検出から修正パッチ生成、Pull Request作成までを一貫して行う自動修正機能を発表しており、ScanNetSecurityの報道が伝えている。

ただし、これらのサービスには共通点がある。対象の多くが、GitHub上で管理されたソースコードや、OSSライブラリの依存関係といった「ベンダー・プラットフォームの管理下にあるコード」だという点だ。老朽化した自社独自の基幹システム全体を、検知から修復・適用まで一気通貫で扱う仕組みとは、前提が異なる。「検知+AI修正」という発想そのものは珍しくなくなった一方で、ベンダー管理外のレガシー資産に対してその仕組みを構築するという課題は、依然として残されたままだ。この空白を埋める位置づけにあるのが、AI-SecBoxのような、自社独自システムを前提に設計されたアプローチだ。

AIに直させて終わり、ではない。「検証」まで含めた一気通貫の仕組みが必要

棒グラフ: 1Passwordの調査によるAI生成パッチの結果内訳(完全解決26.0%、部分的成功20.1%、失敗53.…

もう一つ注意すべきなのは、AIに修正を任せれば自動的に安全になるわけではないという点だ。1Passwordの調査によると、ChatGPTやClaudeなどのAIモデルが生成した脆弱性修正パッチのうち、脆弱性が未解決だったり新たな脆弱性を生んだりしたケースが53.9%にのぼり、完全に問題を解決できたのはわずか26.0%だった。多くの「成功した」パッチも、脆弱性の根本原因を取り除くのではなく、特定の攻撃パターンを塞ぐだけの対症療法に留まっていたという。

この結果が示すのは、AIによる修正案の生成は出発点に過ぎず、人間によるレビュー・検証・適用・再テストまでを含めた一気通貫の仕組みがなければ、「直したつもり」で終わってしまうリスクがあるということだ。実際、NRIセキュアの発表でも、AIが生成するコードの脆弱性確認や権限管理といった、従来とは異なる管理ニーズに対応する「AI駆動開発向けセキュリティ支援サービス」が2026年に登場しており、AI駆動開発とセキュリティ対応を組み合わせた支援は市場として立ち上がり始めている。

検知→正規化→トリアージ→AIによる修正案生成→レビュー→検証→適用→再テストという一連の流れを、人の目と自動検証の両方で貫く設計こそが、ベンダー管理外の老朽化システムに対して本当に機能する仕組みといえる。こうしたワークフローを社内完結型で提供するのが、先述したAI-SecBoxのようなアプローチだ。

「直す力」を持つ組織をどうつくるか

結局のところ、脆弱性対応のボトルネックは「検知の有無」ではなく、「コードを書いて直せる開発力が組織にあるかどうか」に帰着する。どれだけ精度の高いスキャンツールを導入しても、見つかった問題を安全かつ迅速に修正できる実装力がなければ、脆弱性は「見つかったまま」放置され続ける。経済産業省は2019年公表の調査で、国内のIT人材が2030年に最大で約79万人不足すると試算しており、ITmediaの報道によれば、この予測を現場のエンジニア・ITエンジニアの87%が認識しているという。脆弱性修正を担う開発リソースそのものが、構造的に不足していく前提で組織づくりを考える必要がある。

この「直す力」は、一朝一夕に身につくものではない。AIを活用したコーディング・レビュー・検証のワークフローを実務の中で練習し、組織としてのAI駆動開発力を底上げする機会が必要になる。例えばAI駆動開発セミナーのような、一社貸切・実務課題ベースの伴走型研修は、架空の演習ではなく自社の実際のシステム課題を題材に、AIを活用した開発・修正のスキルをチームで定着させる機会になる。SIerや情報システム部門への研修実績を持つこうした取り組みは、検知した脆弱性を自組織で迅速に直せる開発力を育てる位置づけとして、技術リードにとって検討の価値がある選択肢だ。

まとめ

脆弱性診断ツールの普及によって「見つける」工程はすでにコモディティ化し、多くの企業が何らかの形で検知の仕組みを持つ時代になった。しかし、ベンダー公式パッチが存在しない自社独自のレガシー基幹システムにとって、本当の壁は「見つけた後にどう直すか」にある。GitHub Copilot AutofixやTakumi byGMOのような「検知+AI修正」の取り組みがすでに実用化されている一方で、それらの多くはベンダー管理下のコードが対象であり、自社独自に構築した基幹システム全体を一気通貫で扱う仕組みは依然として手薄な領域だ。

AIに修正を丸投げするだけでは、1Passwordの調査が示すように半数以上が未解決か新たな脆弱性を生む結果に終わりかねない。検知から修正案生成、人によるレビュー、検証、適用、再テストまでを一つのループとして設計し、それを実行できる「直す力」を組織に根付かせることが、次の防御ラインになる。

機密性の高いコードや脆弱性情報を外部に出さずに検査・修復・検証まで完結させたい企業には、AI-SecBoxのような、社内設置型の検査・修正検証環境という選択肢もある。自社の脆弱性対応に「見つける」から「直し続ける」までの一気通貫の仕組みを整えたい方は、まず無料相談から相談してみてはどうだろうか。

こちらの記事もあわせてお読みください

役に立ったら、記事をシェアしてください