AI が脆弱性を見つけても、安全になるとは限らない

by

ソフトウェアの安全性について考えるとき、最初に注目されやすいのは、脆弱性を見つける能力である。脆弱性とは、プログラム、設計、設定、運用のどこかにある弱点であり、悪用されると情報漏えい、権限昇格、サービス停止、なりすましなどにつながりうる。したがって、脆弱性を早く見つけることは重要である。未知の弱点が残ったままであれば、利用者は危険にさらされる。問題が早く見つかれば、修正、回避策、利用者への通知、影響範囲の確認を早く始められる。ここまでは直感的に理解しやすい。

しかし、脆弱性を見つけることは、セキュリティ対応の入口でしかない。見つかった候補は、ただちに安全性へ変わるわけではない。その候補を読み、再現し、仕様と照合し、実際に悪用可能な弱点なのか、通常の不具合なのか、想定された挙動なのかを判断しなければならない。さらに、本当に脆弱性であれば、影響を受けるバージョンを特定し、修正を作り、既存機能を壊していないかを確認し、公開時期を調整し、利用者が理解できる形で説明する必要がある。つまり、脆弱性対応は「発見」だけで完結せず、「検証」「認定」「修正」「公開」という工程を通って初めて意味を持つ。

AI を使ったコード解析や報告文の作成が広がると、この工程の前半だけが急速に拡張される。AI は、多くのコードを読み、危険に見える箇所を拾い、長い説明文を作り、報告の形に整えることができる。これにより、脆弱性の候補は以前より多く、速く、詳しく提出されるようになる。直接の原因は、問題を見つける側の作業量が下がり、候補を作る速度が上がることである。もう一段下の原因は、報告者側の能力は道具によって増やせる一方で、受け取る側の検証能力は、プロジェクトの設計、履歴、仕様、過去の判断を理解している人間に強く依存することである。

この不均衡を具体的に示しているのが、curl プロジェクトの脆弱性報告受付をめぐる一連の動きである。curl は、ネットワーク上でデータを転送するために広く使われるソフトウェアであり、多くのシステム、製品、開発環境、運用基盤の内部で使われている。curl そのものを直接意識していない利用者でも、curl または libcurl を組み込んだ別のソフトウェアを通じて、その安全性の影響を受けることがある。そのため、curl の脆弱性報告は、単なる一つの開発プロジェクト内の連絡ではなく、広い利用者に影響しうる安全性情報として扱われる。

本稿では、この事例を、単なる「AI による迷惑報告」の話としては扱わない。たしかに、AI によって低品質な報告が増える問題は存在する。存在しない弱点をもっともらしく書く報告、再現手順が不十分な報告、影響を過大に見せる報告は、受け手の時間を消費する。しかし、それだけを問題の中心に置くと、より重要な構造を見落とす。AI によって生じる負荷は、低品質な報告だけから生まれるのではない。詳細で、もっともらしく、検証する価値がある報告も、大量に届けば処理能力を圧迫する。

ここで問うべきなのは、AI が脆弱性候補を見つけられるかどうかではない。より重要なのは、見つかった候補を安全性へ変換する工程が、どこで詰まるのかである。候補を見つける段階では、AI は作業を速くする。しかし、候補を採用する段階では、人間が責任を持って判断しなければならない。候補を修正する段階では、既存利用者への影響を考えなければならない。候補を公開する段階では、早すぎる公開が攻撃の手がかりになり、遅すぎる公開が利用者の防御を遅らせる。このように、脆弱性対応では、発見後の工程にこそ判断が集中する。

本稿の中心命題は、次の一点である。AI 時代のセキュリティで問われるのは、脆弱性を見つける能力だけではない。見つかったものを、誰が検証し、どの基準で採用し、どの責任で修正し、どの手順で公開するのかである。AI が発見を速くするほど、この問いは軽くならない。むしろ、発見の量と速度が増えることで、検証、判断、修正、公開の責任はより重くなる。

1. 脆弱性報告を止めるとは、何を止めることなのか

curl プロジェクトは、2026 年 7 月のあいだ、脆弱性報告を受け付けず、処理もしないと告知した。開始は 2026 年 7 月 1 日 00:00 CEST、再開は 2026 年 8 月 3 日 09:00 CEST とされている。これは、HackerOne の投稿フォームを止め、セキュリティ用の連絡先でも報告を処理しないという意味である[1]。curl の公式な脆弱性開示方針でも、2026 年 7 月中は脆弱性報告を受け付けず、8 月 3 日に再開すると明記されている[2]。

この措置は、curl の開発そのものを止めるという意味ではない。通常の不具合報告、機能追加、修正提案、開発上の議論がすべて閉じられるわけでもない。止められたのは、脆弱性報告という、特に重い処理を必要とする入口である。脆弱性報告は、通常の不具合報告とは扱いが異なる。内容が公開されると攻撃に使われるおそれがあるため、受け取った側は、公開せずに確認し、影響範囲を調べ、修正を準備し、どの時点でどの情報を出すかを判断しなければならない。

ここで重要なのは、「報告を受け付ける」という言葉の中に、複数の作業が含まれている点である。報告を読むだけなら、単なる連絡の受領に見える。しかし、脆弱性報告では、読むことは処理の始まりでしかない。報告に書かれた条件で本当に再現するかを確認する必要がある。再現したとしても、それが攻撃可能な弱点なのか、仕様上の制約なのか、通常の不具合なのかを分けなければならない。脆弱性だと判断した場合は、修正の準備、公開文書、影響を受ける利用者への説明まで続く。

観点 止めたもの 止めていないもの
受付入口 脆弱性報告の投稿フォームとセキュリティ用連絡先での処理を一時停止した。 通常の開発活動や一般的な不具合報告の入口を全面的に閉じたわけではない。
処理対象 非公開で扱い、影響範囲、悪用可能性、修正、公開時期を検討する必要がある報告を止めた。 公開の場で扱える通常の修正提案や開発上のやり取りまで同じ扱いにしたわけではない。
目的 保守者が脆弱性報告の処理から一時的に離れ、判断と修正に必要な余力を守ることを目的とした。 curl の安全性そのものを軽視したわけではない。
期間 2026 年 7 月中という期間を区切った一時措置である。 恒久的に脆弱性報告を拒否する制度変更ではない。

この表から分かるように、受付停止の意味は、単純な拒絶ではない。脆弱性報告は、受け取った時点で保守者に一連の責任を発生させる。第一に、その報告が本物かどうかを判断する責任である。第二に、本物であれば、利用者を守る形で修正と公開を進める責任である。この二段階の責任があるため、入口を開き続けることは、単に情報を受け取ることではなく、保守者の判断帯域を使い続けることを意味する。

判断帯域とは、ここでは、限られた時間と知識を使って、どの問題を本物として扱い、どの問題を後回しにし、どの問題を却下するかを決める能力を指す。これは単なる作業時間ではない。脆弱性対応では、コードを読めるだけでは不十分である。過去の設計判断、互換性、利用者への影響、公開時期、修正の副作用を同時に考える必要がある。したがって、報告の件数が増えると、読む時間だけでなく、判断の質を保つための負荷も増える。

脆弱性報告の受付停止を、怠慢や防御放棄として読んではならない理由はここにある。入口を開けば情報は増える。しかし、情報が増えることと、安全性が増すことは同じではない。直接の原因としては、報告の増加が保守者の処理時間を圧迫する。さらに背後の原因として、脆弱性対応にはプロジェクト固有の知識と公開責任が必要であり、その能力は AI による候補生成のようには増えない。したがって、入口を一時的に閉じることは、情報の流入を拒む行為ではなく、処理できない情報によって判断の質が落ちることを防ぐ制御として理解できる。

この章で確認したことは、本稿全体の前提になる。脆弱性報告は、送信された時点で価値になるのではない。報告が価値になるのは、受け手がそれを検証し、脆弱性として認定し、修正し、利用者が行動できる情報として公開できたときである。次に見るべきなのは、なぜ curl のような基盤的なソフトウェアに、これほど重い報告処理が集中するのかである。

2. curl はなぜ脆弱性報告を集めるのか

curl は、HTTP、FTP、SMTP など、さまざまな通信方式でデータを転送するためのコマンドラインツールであり、同時に libcurl というライブラリでもある。コマンドラインツールとは、画面上のボタン操作ではなく、文字による命令で実行する道具である。一方、ライブラリとは、他のソフトウェアから呼び出して使われる部品である。つまり curl は、人間が直接使う道具であると同時に、多くのソフトウェアの内部に組み込まれる部品でもある。curl の公式サイトは、curl と libcurl を、数百億規模のインストールで使われるインターネット転送エンジンとして説明している[3]。

この二重の性格が、curl に脆弱性報告を集める第一の理由である。curl が単独の道具として使われるだけなら、影響範囲は比較的見えやすい。しかし libcurl として別のソフトウェアに組み込まれると、利用者は curl を直接意識しないまま、その機能に依存することになる。開発者が使うツール、サーバー上で動く処理、組み込み機器、業務システム、運用自動化の仕組みなど、さまざまな場所で通信処理の部品として使われる可能性がある。したがって、curl の弱点は、curl を直接起動する人だけでなく、curl を内部で使う別のソフトウェアの利用者にも影響しうる。

ここで重要なのは、基盤ソフトウェアでは、不具合の影響がコードの行数や機能の見た目だけでは測れないという点である。単独のアプリケーションに閉じた不具合であれば、影響範囲はそのアプリケーションの利用者に限られやすい。ところが、広く使われる部品に弱点があれば、それを組み込んだ製品、サーバー、機器、開発ツール、運用基盤へ影響が広がる可能性がある。直接の原因は、その部品が多くのソフトウェアから呼び出されていることである。さらに背後の原因は、現代のソフトウェアが、単独で完結する製品ではなく、多数の部品を組み合わせた依存関係の上に成立していることである。

観点 単独のアプリケーション 基盤ソフトウェア
利用のされ方 利用者がそのアプリケーションを直接選び、直接使う場合が多い。 他のソフトウェアに組み込まれ、利用者が存在を意識しないまま使われる場合がある。
影響範囲 不具合の影響は、そのアプリケーションの利用範囲に比較的閉じやすい。 不具合の影響は、それを組み込んだ複数の製品やシステムへ連鎖しうる。
報告が集まる理由 そのアプリケーションの利用者や開発者が問題を見つける。 利用者、配布元、組み込み先、研究者、セキュリティ担当者など、複数の立場から問題が報告されうる。
保守者の負荷 主に自分たちの利用者と機能範囲を前提に判断すればよい。 幅広い利用形態、互換性、配布経路、下流の影響を考慮して判断する必要がある。

curl の CVE 一覧には、これまで公開された curl と libcurl の脆弱性が整理されており、継続的に修正と公開が行われてきたことがわかる[4]。CVE とは、公開された脆弱性を識別するための共通番号である。この番号は、脆弱性に名前を付けるためだけのものではない。配布元が修正を追跡し、運用者が自分の環境への影響を確認し、監視システムが警告を出し、利用者が更新の優先順位を決めるための共通の目印になる。

したがって、CVE が付くことの意味を、単に「重大な問題として認められた」という印象だけで理解してはならない。もちろん、CVE が付いた問題は外部から追跡可能な脆弱性として扱われる。しかし、本稿でより重要なのは、CVE が、発見された問題を社会的に処理可能な単位へ変換する役割を持つことである。番号が付くことで、その問題は、開発者の内部判断だけでなく、配布、更新、監査、利用者通知、リスク管理の流れに接続される。番号は記号にすぎないが、その記号によって、修正すべき対象、影響を確認すべき範囲、対応を急ぐべき順序が共有される。

この構造を踏まえると、curl のような基盤ソフトウェアに報告が集まる理由は、単に有名だからではない。そこに問題があれば、多くの人に影響する可能性があり、その問題を見つけることに社会的な意味があるからである。報告者から見れば、curl の弱点を見つけることは、広い範囲の安全性に関与する行為になる。配布元や運用者から見れば、curl の脆弱性情報は、自分たちのシステムを更新するかどうかを判断するための材料になる。保守者から見れば、一件の報告は、単なる指摘ではなく、広い利用者への説明責任を伴う処理対象になる。

つまり、報告が集まること自体は悪いことではない。むしろ、多くの人が調べ、問題を見つけ、直すことは、オープンソースの強みでもある。コードが公開されているからこそ、外部の研究者、利用者、企業、個人開発者が問題を発見できる。利用範囲が広いからこそ、修正されたときの効果も大きい。この意味で、脆弱性報告の増加は、安全性を高める可能性を持っている。

しかし、その可能性が実際の安全性へ変わるには、報告を処理する工程が必要である。報告が多いほど、見つかる問題も増えるかもしれない。だが同時に、誤報、重複報告、影響範囲の不明な報告、仕様との区別が難しい報告も増える。第一段階では、広く使われる基盤ソフトウェアであることが、報告者の関心と報告件数を増やす。第二段階では、その報告件数の増加が、保守者による確認、分類、修正、公開調整の負荷を増やす。ここで問題になるのは、報告が集まることそのものではなく、入口から入ってくる量と、保守者が責任を持って処理できる量の釣り合いである。

この章で確認したことは、curl の事例を読むうえで重要である。curl に報告が集まるのは、curl が弱いからではない。むしろ、広く使われ、外部から調べる価値があり、修正されれば多くの利用者に利益があるからである。だからこそ、脆弱性報告の問題は、報告者の善悪だけでは説明できない。基盤ソフトウェアであることが報告を呼び込み、報告が増えることで保守者の処理能力が問われる。この構造を踏まえなければ、次に見る報奨金制度の成功と限界も、AI による報告増加の意味も正しく理解できない。

3. 報告量の増加は、単なる件数の問題ではない

Daniel Stenberg は、2026 年 5 月の時点で、curl に届く脆弱性報告の速度が大きく上がっていると説明している。2024 年と比べて 4 倍から 5 倍、2025 年と比べても 2 倍ほどであり、平均すれば 1 日 1 件を超える報告が届く状態になっていたという。さらに重要なのは、その報告が単に雑になったのではなく、長く、詳細で、品質も高くなっていると述べられている点である[5]。

この事実は、報告量の増加を単純な件数の問題として扱ってはいけないことを示している。件数だけを見れば、1 日 1 件の報告は、それほど多くないように見えるかもしれない。しかし、脆弱性報告は通常の問い合わせではない。一件ごとに、内容の理解、再現、仕様との照合、影響範囲の確認、修正方針の検討、公開時期の判断が発生する。つまり、一件の報告は、一件の文章ではなく、一つの調査案件として保守者の前に現れる。

ここには、直感に反する構造がある。低品質な報告が増えれば、保守者が疲弊することは理解しやすい。存在しない問題、再現できない問題、仕様を誤解した問題、AI が作ったようなもっともらしい文章は、読むだけで時間を奪う。だが、今回のより深い問題は、高品質な報告であっても、大量に届けば負荷になるという点にある。質が高い報告は、却下しにくい。検証する価値があるからこそ、読み飛ばせない。読み飛ばせないからこそ、保守者の時間と判断力を消費する。

報告の種類 一見した印象 保守者に発生する処理 負荷が生まれる理由
低品質な報告 誤報や思い込みが多く、早く却下できそうに見える。 本当に誤報かどうかを確認する必要があり、確認だけで時間を消費する。 誤報であることを判断するにも、最低限の再現確認と仕様確認が必要になる。
高品質な報告 詳細で有用に見え、修正につながりやすそうに見える。 内容が深いほど、再現、仕様確認、影響評価、修正方針の検討に時間がかかる。 有望な報告ほど、安易に却下できず、慎重な判断が必要になる。
重複した報告 同じ問題なら処理しやすそうに見える。 同じ問題か、似ている別問題かを照合する必要がある。 表面的に似ていても、発生条件、影響範囲、修正箇所が異なる可能性がある。
AI 支援の報告 説明が整っていて、技術的に見える。 文章の整い方と事実の正しさは別なので、検証の手間は残る。 もっともらしい説明が、正しい因果関係や実際の悪用可能性を保証しない。

この表で確認できるのは、報告の質と処理負荷が単純な反比例の関係にはないということである。低品質な報告は、誤りを見抜くために時間を使わせる。高品質な報告は、検証する価値があるために時間を使わせる。重複した報告は、重複かどうかを判断するために時間を使わせる。AI 支援の報告は、文章として整っているため、かえって見かけと実態を分けて確認する必要がある。

第一段階の因果関係は、報告の量が増えることで、保守者が処理すべき案件数が増えるという単純なものである。報告が 2 倍になれば、少なくとも読むべき入口は 2 倍になる。報告が 4 倍から 5 倍になれば、優先順位を付ける前の段階で、保守者の注意がより多くの候補へ分散する。この段階では、問題は主に時間配分の問題として見える。

しかし、第二段階では、問題は単なる時間配分を超える。報告が増えると、どの報告を先に扱うべきか、どの報告を却下してよいか、どの報告を本物の脆弱性として扱うべきかという判断が増える。ここで消費されるのは、作業時間だけではない。保守者の注意、集中力、設計理解、過去の判断との整合性、公開責任が消費される。つまり、報告量の増加は、作業量の増加であると同時に、判断負荷の増加でもある。

この区別は重要である。単なる作業量であれば、人数を増やせば解決するように見える。しかし、脆弱性報告の処理では、人数を増やすだけでは解決しない部分が残る。curl の設計、過去の修正履歴、仕様上の意図、互換性への配慮、公開時期の判断を理解していなければ、報告を読んでも正しく分類できないからである。脆弱性対応では、作業を分担するためにも、まず何を分担できる問題として切り出すかを判断しなければならない。

このため、報告量の増加は「件数が増えた」というだけでは説明できない。報告が長く、詳細になれば、読む時間も増える。再現手順が複雑になれば、検証環境を作る時間も増える。影響範囲が広そうに見えれば、過去の修正、仕様、利用条件、互換性まで確認する必要がある。情報が多いことは助けになる一方で、処理する側には別の負荷を生む。情報が豊富であることと、判断が容易であることは同じではない。

ここに、AI 時代の脆弱性報告を考えるうえでの核心がある。AI は、候補を見つける作業、説明を整える作業、報告の体裁を作る作業を速くする。その結果、報告者側の入口は広がる。しかし、報告を受ける側では、候補が本物かどうかを判断する工程、修正する工程、公開する工程が残る。発見の速度が上がっても、認定と修正の速度が同じように上がるとは限らない。むしろ、発見の速度だけが上がることで、認定と修正の工程が新しい詰まりどころになる。

したがって、報告量の増加を評価するときには、単に「多くの問題が見つかってよいことだ」とも、「迷惑報告が増えて悪いことだ」とも言い切れない。報告が多いことは、安全性を高める可能性を持つ。同時に、処理しきれない報告は、安全性を高める前に保守者の判断能力を圧迫する。問題は、報告の量そのものではなく、報告を検証可能で、修正可能で、公開可能な知識へ変換する工程が追いつくかどうかである。

4. 報奨金制度は成功し、同時に限界を露呈させた

curl は、かつて脆弱性発見への報奨金制度を運用していた。一般に bug bounty と呼ばれる制度であり、脆弱性を見つけて報告した人に報奨金を支払う仕組みである。この制度は、外部の調査者に明確な動機を与える。通常の利用や開発のなかでは見落とされる弱点を、外部の目で調べてもらうことができるからである。実際、curl の報奨金制度は、複数年にわたって確認済みの脆弱性発見に貢献した。しかし、2026 年 1 月、curl はこの制度を終了すると発表した。理由として、報奨金が、十分に調査されていない報告や、脆弱性に見せかけた問題の投稿を誘発していたことが説明されている[6]。

この経緯は、報奨金制度が失敗だったことを意味しない。むしろ重要なのは、制度が一定の成功を収めたからこそ、その副作用も大きくなったという点である。報奨金制度は、脆弱性発見を偶然や善意だけに任せず、外部の調査者が時間をかける理由を作る。その結果、本物の脆弱性が見つかりやすくなる。ここまでは制度の第一段階の効果である。しかし第二段階では、報奨金を得ること自体が目的化し、十分に確認されていない候補や、脆弱性に見えるが実際には成立しない問題も提出されやすくなる。制度が発見を促すと同時に、発見らしきものを増やしてしまうのである。

観点 制度が狙った効果 実際に生じうる副作用 AI によって強まる部分
動機づけ 外部の調査者が時間を使ってコードを調べる理由を作る。 報奨金を得ることが目的化し、十分に確認されていない報告が増える。 候補探しや報告文作成の手間が下がり、提出までの心理的・作業的な障壁が下がる。
発見能力 保守者だけでは見落とす問題を外部から見つけてもらう。 仕様誤読、重複、影響の誇張、再現不能な指摘も混じる。 もっともらしい説明や長い根拠を短時間で作れるため、見かけ上は技術的な報告が増える。
保守者の負荷 有効な報告を受け取り、修正につなげる。 本物かどうかを確認するための検証作業が増える。 文章の整い方と事実の正しさを切り分ける必要があり、確認作業が軽くならない。
制度の信頼性 発見者、保守者、利用者のあいだで脆弱性対応を促進する。 低品質な投稿が増えると、報告全体への信頼が下がる。 大量の候補が流れ込むことで、有効な報告と無効な報告の選別が難しくなる。

この表で確認できるように、報奨金制度の問題は、単に「お金を出したから悪い報告が増えた」という単純な話ではない。第一に、報奨金は発見行動を増やす。これは制度の目的にかなっている。第二に、発見行動が増えると、報告のなかに、本物の脆弱性、通常の不具合、仕様の誤解、再現できない問題、影響を誇張した問題が混在するようになる。第三に、その混在をほどく作業は、報告者ではなく保守者の側に発生する。ここで、制度の成功がそのまま保守者の負荷増加へつながる。

Stenberg は 2025 年の時点で、AI 生成の低品質な脆弱性報告が curl の保守者を消耗させていると述べていた[7]。ここでいう低品質とは、単に文章が下手という意味ではない。むしろ、問題は逆である。文章は整っている。専門用語も並んでいる。危険そうな因果関係も書かれている。しかし、内容が再現できない、仕様を誤読している、影響を誇張している、報告者自身が問題の意味を理解していない、といった形で破綻する。AI は文章の外形を整えることができるため、読み手は、まずその説明が現実のコード、仕様、利用条件と合っているかを確認しなければならない。

この点で、AI 支援の報告は、従来の低品質な報告より扱いが難しい場合がある。従来の雑な報告であれば、前提の誤りや情報不足が表面に出やすい。ところが、AI によって整えられた報告は、文章としては一見すると自然で、技術的な構造を持っているように見える。そのため、保守者は、文章の完成度ではなく、事実関係を一つずつ確認する必要がある。直接の負荷は、再現確認や仕様確認の時間として現れる。さらに深い負荷は、もっともらしい説明を安易に信じず、しかし有効な報告を見落とさないという判断の緊張として現れる。

したがって、報奨金制度の終了は、AI を使うこと自体への拒絶ではない。より正確には、報奨金という動機づけと、AI による候補生成・文章生成が組み合わさることで、保守者の検証資源が過剰に消費される構造への対応である。報奨金は報告者の行動を増やす。AI は報告を作るコストを下げる。この二つが重なると、報告者側の提出能力は大きくなる。一方で、保守者側の検証能力、修正能力、公開判断能力は同じ速度では増えない。

ここから導かれる帰結は、制度設計に関するものである。セキュリティを高める制度は、単に報告件数を増やせばよいわけではない。報告の入口を広げるなら、その後段にある選別、検証、修正、公開の工程も同時に設計しなければならない。入口だけが強化されると、制度は有効な脆弱性発見を促す一方で、保守者の判断帯域を消耗させる。制度が行動を生む以上、制度は望ましい行動だけでなく、望ましくない行動も設計してしまう。

この前史を踏まえると、curl の問題は、2026 年 7 月の受付停止だけを見ても理解できない。報奨金制度は、本物の脆弱性発見に貢献した。しかし同時に、報告を増やす制度が、検証する側の資源をどのように消費するかを明らかにした。ここで見えた構造は、次の段階でさらに強く現れる。すなわち、報奨金がなくなっても、AI によって候補生成と報告作成のコストが下がれば、報告の流入そのものは増え続けうるという構造である。

5. 問題は低品質な AI 支援報告だけではない

ところが、2026 年春以降の問題は、低品質な報告だけでは説明できなくなる。Stenberg は、「ほとんどのセキュリティ報告で AI が何らかの形で使われている」と述べたうえで、以前との違いとして、報告の多くが高品質になっていると説明している[8]。これは、議論の焦点を変える重要な観察である。AI が関与した報告を、単に雑で迷惑なものとして扱うだけでは、現在起きている負荷の性質を捉えられない。

もし問題が低品質な報告だけであれば、対策は比較的単純に見える。明らかな誤報を弾く。報告書式を厳しくする。報告者に再現手順を求める。報奨金を止める。これらは一定の効果を持つ。実際、再現できない報告や、仕様を誤解した報告や、影響を過大に見せる報告に対しては、入口で条件を厳しくすることが有効に見える。第一段階の対策としては、報告の最低基準を上げれば、粗い報告は減らせるからである。

しかし、高品質な報告が増えた場合、状況は別である。質が高い報告は無視しにくい。内容を読む価値がある。実際に修正につながる可能性がある。既知の問題に似ていても、発生条件が違うかもしれない。影響範囲が狭く見えても、別の利用条件では重大になるかもしれない。したがって、保守者は、単に弾くのではなく、読まなければならない。再現しなければならない。仕様と照合しなければならない。修正するかどうかを判断しなければならない。

ここで生じているのは、「高品質な混乱」である。混乱という語は、内容が無価値だという意味ではない。むしろ、価値のある候補が大量に届くために、処理順序、優先順位、重複確認、影響範囲、修正方針を判断する負荷が増すという意味である。質の低い入力は、雑音として判断を妨げる。質の高い入力は、処理すべき仕事として積み上がる。どちらも、処理能力を超えればシステムを詰まらせる。

段階 見えている問題 背後にある問題 保守者に発生する負荷
低品質報告の段階 存在しない脆弱性や誇張された報告が届く。 報告の信頼性を見極めるために保守者の時間が消費される。 誤報であることを確認するために、最低限のコード確認、仕様確認、再現確認が必要になる。
高品質報告の段階 実際に検討する価値のある報告が大量に届く。 有用な報告ほど、読む、再現する、影響を調べる、修正するという実作業が増える。 安易に却下できないため、報告ごとに優先順位と対応方針を判断する必要がある。
重複・近似報告の段階 似たような問題が複数の経路から報告される。 同じ問題なのか、似ているだけの別問題なのかを切り分ける必要がある。 過去の報告、修正履歴、影響範囲を照合し、対応済みかどうかを確認しなければならない。
制度疲労の段階 報告入口を開き続けること自体が負担になる。 開放性と持続可能性の釣り合いを取り直す必要が生じる。 保守者が通常開発、修正、公開調整、報告対応を並行して抱え、判断の余力を失いやすくなる。

この構造を見落とすと、議論は「AI の報告は迷惑か、有用か」という二択に縮んでしまう。実際には、その両方が起こりうる。AI は誤った報告を増やすこともあるが、有用な発見を増やすこともある。問題は、AI が有用か無用かという単純な評価ではない。より重要なのは、有用な発見が増えたとき、それを処理できるだけの制度と人間の判断能力があるかどうかである。

第一段階では、AI によって報告の作成コストが下がる。コードの危険箇所を探す、説明を組み立てる、影響を推測する、報告文を整えるといった作業が速くなる。その結果、報告者側の提出能力が増える。第二段階では、提出された報告を受け取る側の負荷が増える。保守者は、文章が整っているかではなく、現実のコードで再現するか、仕様上の問題なのか、実際に悪用可能なのか、修正すべきかを判断しなければならない。ここで、報告者側の能力拡張と、保守者側の判断帯域の差が表面化する。

この差は、AI の性能が上がれば自然に消えるものではない。むしろ、AI がより正確に候補を見つけ、より自然な文章で説明できるようになるほど、保守者は報告を読み飛ばしにくくなる。明らかに粗い報告なら早い段階で退けられる。しかし、検討する価値がある報告は、価値があるからこそ処理対象になる。ここに、高品質な報告が保守者を助ける面と、保守者の負荷を増やす面が同時に存在する。

これは、セキュリティに限らない一般的な構造でもある。監視システムで有用な警告が増えれば、対応すべき警告も増える。医療検査で多くの異常候補が見つかれば、診断すべき所見も増える。品質管理で検出精度が上がれば、修正すべき可能性のある箇所も増える。観測能力が高まることは重要である。しかし、観測されたものを分類し、優先順位を付け、実際の対応へつなげる工程が追いつかなければ、観測能力の向上はそのまま安全性の向上にはならない。

したがって、curl の事例から読み取るべきなのは、AI 支援報告の善悪ではない。AI によって発見と報告の入口が広がる一方で、検証、認定、修正、公開という後続工程が相対的に狭いまま残るという構造である。低品質な報告は、誤りを見抜くために保守者を消耗させる。高品質な報告は、処理する価値があるために保守者を忙しくする。どちらの場合でも、最後に問われるのは、報告を検証し、修正し、公開する処理能力である。

6. 脆弱性は発見されるだけでなく、認定される

AI がコードを読み、脆弱性候補を見つけることは、すでに現実のものになっている。Stenberg は、Mythos による curl の解析事例を取り上げ、AI を使ったコード解析が従来の静的解析よりも有効に問題を見つけうることを認めている。一方で、その事例では、ツール側が確認済みとした複数の指摘のうち、curl チームが確認済み脆弱性と判断したものは一部に限られた[9]。

この差は、本稿の中心にある。脆弱性候補を見つけることと、それを脆弱性として認定することは違う。候補を出す段階では、コードのある挙動が危険に見える、境界条件が怪しい、入力検証が弱そうだ、過去に似た修正があった、といった指摘ができる。しかし、脆弱性として認定するには、それだけでは足りない。その挙動が仕様どおりなのか、想定外なのか、本当に悪用可能なのか、どの条件で再現するのか、どの利用者に影響するのか、どの程度深刻なのかを確認しなければならない。

ここでいう認定とは、単に「危なそうだ」と判断することではない。プロジェクトとして、その問題を脆弱性として扱い、修正し、公開し、利用者に対応を求めるだけの根拠を持つことである。脆弱性として認定すれば、修正作業、公開文書、CVE、配布元への通知、利用者の更新判断が連鎖する。逆に、誤って脆弱性と扱えば、不要な混乱を生む。誤って脆弱性ではないと扱えば、利用者を危険に残す。このため、認定は候補発見よりも責任の重い工程である。

第一段階では、AI は候補を増やす。コードの形、過去の脆弱性との類似、危険そうな入力経路、境界条件の不整合を探し、報告の形に整える。これにより、保守者の前に現れる問題候補は増える。第二段階では、その候補を受け取った保守者が、仕様、実装、再現条件、利用形態、影響範囲を照合する。ここで初めて、その候補が脆弱性なのか、通常の不具合なのか、仕様の誤解なのか、単なる誤検知なのかが分かれる。

工程 AI が助けやすい部分 人間が引き受ける部分 判断を誤った場合の帰結
候補発見 コードの怪しい箇所、境界条件、過去の修正との類似を見つけやすくする。 その候補が実際の設計意図や利用条件に照らして問題かどうかを判断する。 候補を過大評価すれば誤報が増え、過小評価すれば本物の問題を見落とす。
再現確認 再現手順や入力例の作成を補助できる。 実際に再現し、環境依存、設定依存、誤検知、仕様上の挙動を切り分ける。 再現性を確認しないまま扱えば、存在しない問題を脆弱性として処理してしまう。
仕様照合 関連するコード、文書、過去の変更履歴を探す手助けができる。 その挙動が仕様に反するのか、仕様どおりだが危険なのか、仕様自体を見直すべきなのかを判断する。 仕様との関係を誤れば、通常の挙動を脆弱性と誤認するか、危険な設計を見逃す。
影響評価 関連箇所、過去の事例、似た条件での不具合を探索できる。 どの利用者にどの程度の影響があるかを、実際の利用条件に照らして責任ある形で判断する。 影響を過大に見れば不要な混乱を生み、過小に見れば利用者の対応が遅れる。
修正と公開 修正案や説明文の下書きを作れる。 互換性、テスト、公開時期、勧告内容、下流への影響を決定する。 修正が不十分なら問題が残り、公開が不適切なら攻撃者または利用者のどちらかに不利になる。

この表が示しているのは、AI が役に立たないということではない。むしろ、AI は候補発見、関連情報の探索、再現手順の整理、説明文の下書きにおいて有効に働きうる。問題は、AI が補助しやすい工程と、プロジェクトが責任を持つ工程が一致しないことである。AI は候補を出せるが、その候補を採用するかどうかは、プロジェクトが判断する。AI は説明を作れるが、その説明が利用者に出せる内容かどうかは、人間が確認する。AI は修正案を提案できるが、その修正を取り込んだ結果に責任を持つのは保守者である。

Stenberg は別の文脈で、AI による補助を全面否定するのでも、AI にすべてを任せるのでもなく、人間が管理し、理解し、責任を持つべきだと述べている[10]。この姿勢は、脆弱性報告にもそのまま当てはまる。AI が候補を出すことはできる。だが、その候補を採用し、修正し、公開し、下流の利用者へ影響を伝えるのは、人間とプロジェクトの責任である。

この違いを見落とすと、AI 時代のセキュリティは誤って理解される。AI が脆弱性候補を見つけたという事実だけを強調すると、発見された時点で安全性が高まったように見える。しかし実際には、発見された候補が未検証のまま積み上がれば、それは安全性ではなく未処理の負荷になる。候補が検証され、脆弱性として認定され、修正され、利用者が適切に更新できる状態になって、初めて安全性へ変換される。

したがって、発見と認定の違いを分けないと、本稿の問題は理解できない。AI は発見の幅を広げる。だが、認定には、仕様理解、再現確認、影響評価、公開責任が必要である。発見の速度が上がるほど、認定の工程は軽くなるのではなく、むしろより多くの候補をさばく必要に迫られる。ここに、AI 時代の脆弱性報告が抱える根本的な非対称性がある。

7. 良い報告とは、保守者に判断可能な形で渡すことである

脆弱性報告は、送れば自動的に貢献になるわけではない。報告は、受け手が検証し、分類し、修正し、公開できる形になって初めて、セキュリティ対応の入口として機能する。Stenberg は、良い脆弱性報告には、短く明確な説明、再現できる手順、影響の説明、必要な環境情報、修正に向けた対話への参加が必要だと述べている[11]。ここで求められているのは、長い文章や専門用語の量ではない。保守者が判断できる形に、問題を整理して渡すことである。

この点は、前章で確認した「発見」と「認定」の違いに直結する。報告者は、危険に見える挙動を見つけることができる。AI は、その発見を文章に整え、関連しそうなコードや過去の事例を示すこともできる。しかし、保守者が必要としているのは、危険そうに見える説明ではない。必要なのは、その挙動が実際に再現し、仕様と照らして問題であり、安全性上の影響を持つと判断できる材料である。報告の価値は、情報量の多さではなく、判断に使える形に整理されているかどうかで決まる。

Linux カーネルのセキュリティ報告文書にも、AI 支援で見つけた問題について注意が示されている。AI を使った報告は、広く利用可能な自動探索に近い性質を持つ場合があり、秘密の脆弱性として扱うべきかどうか、報告の出し方、再現性、説明責任を慎重に考える必要がある[12]。これは curl だけの問題ではない。大規模なオープンソース・プロジェクトでは、AI が作る報告をどう扱うかが、すでに運用課題になっている。

ここで重要なのは、AI 支援の報告を排除すべきだという話ではない。AI を使って問題を見つけること自体は、調査の補助になりうる。問題は、AI が出した候補を、報告者自身が理解しないまま保守者へ渡す場合である。第一段階では、AI が候補を見つけ、文章を整えることで、報告者は少ない労力で報告を作れる。第二段階では、その報告を受け取った保守者が、報告者の理解不足まで含めて検証しなければならなくなる。つまり、報告者側で省略された理解の負荷が、保守者側へ移される。

良い報告とは、保守者の仕事をゼロにする報告ではない。最終判断は保守者が行う。プロジェクトの仕様、設計意図、過去の修正履歴、互換性、公開時期を踏まえて脆弱性かどうかを判断する責任は、保守者側に残る。しかし、報告者は、その判断に必要な材料を整理できる。何を入力すると何が起きるのか。期待される挙動と実際の挙動はどう違うのか。どの版で再現するのか。どの環境で確認したのか。安全性上の影響は何か。単なる異常終了なのか、情報漏えいなのか、権限の境界を越えるのか。この区別があるだけで、保守者が最初に行うべき切り分けは大きく変わる。

報告の要素 必要な理由 不足した場合の負荷 判断への影響
短い要約 保守者が問題の輪郭を素早く把握するために必要である。 長文を最初から精読しなければならず、優先順位をつけにくくなる。 何を先に確認すべきかが不明確になり、初動の判断が遅れる。
再現手順 報告された現象が実際に起きるかを確認するために必要である。 保守者が推測で環境を作り、報告者の意図を探ることになる。 再現不能な問題と、本物だが条件が不足している問題を区別しにくくなる。
環境情報 問題が版、設定、実行環境、依存する部品に左右されるかを確認するために必要である。 保守者が複数の条件を手探りで試すことになり、検証範囲が無駄に広がる。 特定環境だけの問題なのか、広く影響する問題なのかを判断しにくくなる。
期待される挙動との差 仕様どおりの挙動なのか、想定外の挙動なのかを分けるために必要である。 仕様の誤解なのか、実装上の不具合なのかを保守者が最初から確認することになる。 通常の不具合、仕様上の制約、脆弱性候補の区別があいまいになる。
影響範囲 通常の不具合なのか、脆弱性なのかを判断する材料になる。 深刻度の判断ができず、過大評価または過小評価につながる。 修正の優先順位、公開時期、利用者への説明方針を決めにくくなる。
対話への参加 追加確認や修正方針の検討に必要である。 報告が投げっぱなしになり、保守者だけが不確かな材料を抱える。 確認不足のまま却下するか、保守者側で過剰に調査するかの二択になりやすい。

この表から分かるように、良い報告は、保守者の判断を代行するものではない。良い報告は、保守者が判断できる材料を不足なく、過剰でもなく渡すものである。短い要約は、問題の入口を示す。再現手順は、報告が現実の現象に対応していることを確認する。環境情報は、影響範囲を狭める。期待される挙動との差は、仕様と不具合を分ける。影響範囲は、脆弱性として扱うべきかどうかの材料になる。対話への参加は、報告後の不確実性を減らす。

この順序が重要である。まず、何が起きるのかを示す。次に、それがどの条件で起きるのかを示す。さらに、それが期待される挙動とどう違うのかを示す。最後に、それが安全性上どのような意味を持つのかを示す。この階段を踏むことで、報告は、単なる「危なそうな指摘」から、保守者が検証可能な案件へ変わる。反対に、この階段が欠けている報告は、どれほど文章が整っていても、保守者に推測と確認の負荷を渡すことになる。

AI が報告文を整えるほど、この点はむしろ重要になる。文章が滑らかであることは、報告者が問題を理解していることを意味しない。専門用語が多いことも、影響評価が正しいことを意味しない。長い説明があることも、再現性があることを保証しない。保守者にとって必要なのは、流暢な説明ではなく、検証可能な情報である。報告は、情報を増やす行為ではなく、判断可能な形に整える行為でなければならない。

この点を誤ると、報告者は貢献したつもりでも、実際には保守者の負荷を増やすことになる。報告者が AI の出力を理解せず、再現せず、影響を確認せずに提出すれば、保守者は候補の真偽だけでなく、報告者が何を主張しているのかまで解釈しなければならない。第一段階では、報告者側の作業が省略される。第二段階では、省略された作業が保守者側の検証、質問、再現、却下判断として現れる。ここに、AI 支援報告が持つ負荷移転の構造がある。

したがって、良い報告とは、保守者に多くの情報を渡すことではない。保守者が最短距離で判断できるように、必要な情報を整理して渡すことである。脆弱性報告は、発見者の成果発表ではなく、修正と公開へつなぐための共同作業の入口である。その入口で必要なのは、もっともらしい説明ではなく、再現可能性、影響の切り分け、確認可能な事実、そして追加の問いに応答する姿勢である。

8. 脆弱性開示は、報告ではなく工程である

脆弱性対応は、報告を受け取って終わるものではない。報告は、工程の開始点であって、対応の完了ではない。一般に、脆弱性開示は、報告者と保守者が協力し、事実確認、修正、公開時期、利用者への通知を調整する工程として扱われる。GitHub の文書でも、脆弱性開示は報告者とリポジトリ保守者の協調的な取り組みだと説明されている[13]。また、GitHub には、公開リポジトリの保守者へ非公開で脆弱性を報告する仕組みがあり、リポジトリのセキュリティ勧告を通じて修正や公開を管理できる[14][15]。

この「非公開」という点は重要である。通常の不具合であれば、公開された課題管理の場で議論し、修正方針を相談し、変更履歴を残すことができる。しかし、脆弱性の場合は、詳細を早く公開しすぎると、修正が利用者に届く前に悪用の手がかりを与えることがある。反対に、公開を遅らせすぎると、利用者は自分の環境が危険かどうかを判断できず、必要な更新もできない。したがって、脆弱性開示では、秘密にすることと知らせることの釣り合いを取らなければならない。

OpenSSF の協調的脆弱性開示ガイドは、オープンソース・プロジェクトが報告を受け取り、調整し、公開するための手順や考慮点を整理している[16]。FIRST の複数当事者間の脆弱性調整ガイドラインも、脆弱性対応が単一の開発者と報告者だけで完結しない場合を扱っている[17]。HackerOne の開示ガイドラインも、報告者にはルールの尊重、利用者データへの配慮、依頼に応じた説明、害を与えない行動が求められるとしている[18]。これらの文書が共通して示しているのは、脆弱性対応が個人の善意や一通の報告だけで成立するものではなく、複数の当事者が関わる管理された工程だということである。

ここで見えるのは、脆弱性対応が一連の工程であるという事実である。脆弱性候補が届く。保守者が確認する。必要なら報告者に追加情報を求める。修正方針を決める。修正を作る。テストする。CVE 番号を割り当てるか、割り当てを依頼する。勧告文を書く。公開時期を決める。影響を受ける利用者が更新できるようにする。場合によっては、配布元、下流プロジェクト、製品ベンダーとも調整する。つまり、脆弱性対応は、発見された弱点を、利用者が行動できる情報と修正済みの版へ変換する過程である。

第一段階の因果関係は、報告が届くことで確認作業が発生するというものである。報告が増えれば、保守者はより多くの候補を読み、再現し、分類しなければならない。第二段階の因果関係は、確認された候補が修正、公開、配布、更新の工程を発生させるというものである。脆弱性として認定された問題は、単にコードを直せば終わるわけではない。利用者が何をすべきかを理解できるようにし、配布元や下流の利用者が対応できる形に整えなければならない。したがって、報告の増加は、受付担当者の負荷だけでなく、修正、文書化、調整、公開判断の負荷を増やす。

CVE 番号の割り当ても、単なる事務処理ではない。CVE Program では、CNA と呼ばれる番号割り当て機関が、担当範囲の中で脆弱性へ CVE ID を割り当てる[19]。米国 NIST の NVD は、CVE などの脆弱性情報を機械処理しやすい形で提供する基盤であり、脆弱性管理や優先順位づけに使われる[20]。つまり、CVE 番号は、脆弱性を外部から追跡し、配布し、管理するための識別子である。番号があることで、開発者、配布元、運用者、監視システム、利用者が同じ問題を指して話せるようになる。

ここで注意すべきなのは、CVE 番号が付くことと、脆弱性対応が完了することは同じではないという点である。番号は、問題を社会的に扱える単位へ変換するための重要な道具である。しかし、番号だけでは修正は利用者に届かない。勧告文が必要である。修正版が必要である。影響を受ける版の整理が必要である。配布経路ごとの更新が必要である。運用者が自分の環境で対応の要否を判断できる情報も必要である。脆弱性は、発見された瞬間に社会的に処理可能になるのではない。番号、勧告、修正、配布、更新確認という経路に乗って、初めて多くの利用者が扱える情報になる。

工程 内容 詰まりやすい理由 詰まった場合の帰結
受付 報告者から脆弱性候補を受け取る。 量が増えると、読むだけで保守者の時間を使う。 重要な報告が埋もれ、初動の優先順位づけが遅れる。
確認 再現性、影響、仕様との関係を調べる。 報告の見た目が整っていても、事実確認は省けない。 誤報を脆弱性として扱うか、本物の問題を見落とす危険が生じる。
認定 通常の不具合か、脆弱性かを判断する。 設計意図、利用条件、攻撃可能性を理解している人が必要になる。 分類を誤ると、公開判断、修正優先度、利用者への説明がずれる。
修正 安全性を高めつつ既存の利用者を壊さない変更を作る。 局所修正に見えても、互換性や副作用を確認しなければならない。 不完全な修正が残るか、別の不具合を生む可能性がある。
識別 CVE 番号や勧告によって、外部から追跡できる単位にする。 影響範囲、対象版、深刻度、修正状況を整理する必要がある。 配布元や運用者が、同じ問題を正しく追跡しにくくなる。
公開 CVE、勧告、リリース、更新通知をそろえる。 早すぎる公開は悪用を助け、遅すぎる公開は利用者を危険に残す。 攻撃者に情報を先に与えるか、利用者の防御を遅らせることになる。
配布 修正版や情報が、下流の配布元、製品、利用者へ届くようにする。 基盤ソフトウェアでは、利用経路が多く、更新の届き方も一様ではない。 上流で修正されても、利用者の環境には未修正の状態が残りうる。

この表から分かるように、脆弱性対応の負荷は、受付の瞬間だけに発生するわけではない。受付は、工程全体を起動する入口である。確認が詰まれば、脆弱性かどうかを判断できない。認定が詰まれば、修正優先度を決められない。修正が詰まれば、公開しても利用者を守れない。公開が詰まれば、利用者は何を更新すべきか分からない。配布が詰まれば、上流で修正済みであっても、下流の環境には危険が残る。

このため、脆弱性報告の受付停止が重い意味を持つ理由も明確になる。止まったのは、単なるメールの受信ではない。候補を修正と公開へつなぐ工程への入口である。入口に流れ込む量が工程全体の処理能力を超えれば、確認、認定、修正、公開、配布のどこかで詰まりが起きる。第一段階では、報告件数の増加が受付と確認を圧迫する。第二段階では、その圧迫が修正と公開判断の遅れに波及する。したがって、入口の制御は、報告を拒絶するためではなく、工程全体の判断品質を守るための措置として理解できる。

脆弱性開示を工程として捉えると、AI による報告増加の意味も変わる。AI は、候補発見と報告作成を速くする。しかし、脆弱性開示の工程全体を同じ速度で進めるわけではない。受付、確認、認定、修正、識別、公開、配布の各段階には、人間の判断、責任、調整が残る。したがって、AI によって入口が広がるほど、後続工程の設計が重要になる。安全性を高めるのは、候補の数ではなく、候補を修正済みで利用者が行動できる情報へ変換する工程の強さである。

9. オープンソースの開放性には、応答能力という条件がある

オープンソースは、誰でもコードを読める。誰でも問題を見つけられる。誰でも報告し、修正を提案できる。この開放性は、ソフトウェアの安全性を高める重要な条件である。コードが閉じられていれば、問題を見つけられる人は限られる。コードが開かれていれば、利用者、研究者、企業のセキュリティ担当者、個人開発者が、それぞれの観点から弱点を見つけられる。多くの目が入ることは、見落としを減らす可能性を持つ。

しかし、開放性は、無制限の受付義務を意味しない。誰でも報告できることと、保守者が無限に報告を処理できることは別である。報告を受け取る側には、時間、集中力、専門知識、責任の限界がある。特に脆弱性報告では、受け取った情報をそのまま公開できない場合がある。非公開で確認し、必要なら修正を作り、影響を受ける利用者が対応できるように公開時期を調整しなければならない。したがって、入口が開いていることは、対応能力が十分であることを保証しない。

ここで必要なのは、開放性を「いつでも何でも受け取ること」としてではなく、「受け取ったものに責任を持って応答できること」として考え直すことである。応答とは、単に返信することではない。報告を読み、再現し、仕様と照合し、脆弱性かどうかを判断し、必要な修正を作り、利用者が行動できる情報として公開することである。この一連の応答が成立して初めて、外部からの報告は安全性の向上へつながる。

第一段階では、開放性が報告の量を増やす。コードが読めるため、外部の人が問題を探せる。報告窓口があるため、見つけた問題を保守者へ届けられる。これはオープンソースの強みである。第二段階では、その報告量が保守者の処理能力を超える可能性が生じる。報告が増えるほど、読むべき候補、確認すべき条件、判断すべき優先順位が増える。ここで応答能力が不足すると、開放性は安全性を高める力ではなく、保守者の判断帯域を消費する力にもなる。

観点 開放性がもたらす利点 応答能力が不足した場合の問題 必要になる設計
コードの公開 外部の利用者や研究者が問題を発見できる。 発見された候補が増え、保守者が処理しきれない可能性がある。 報告の形式、再現情報、影響説明を求める基準が必要になる。
報告窓口 見つかった問題を保守者へ届ける経路を用意できる。 適切でない経路に投稿されると、公開前に調整すべき情報が漏れる可能性がある。 非公開報告の手順、対象範囲、連絡後の流れを明示する必要がある。
外部参加 保守者だけでは見つけにくい問題を外部から補える。 報告者が問題を理解していない場合、保守者が前提の確認から引き受けることになる。 報告者に再現性、環境情報、追加確認への協力を求める必要がある。
修正提案 問題の指摘だけでなく、修正案まで受け取れる場合がある。 修正案が局所的には正しく見えても、互換性や副作用を壊す可能性がある。 レビュー、テスト、公開判断を保守者側で維持する必要がある。

この表が示しているのは、開放性そのものが問題なのではなく、開放性を支える後続工程が必要だということである。コードを公開すれば、外部から問題が見つかる可能性は高まる。報告窓口を設ければ、問題を受け取る経路は整う。修正提案を受け入れれば、改善の速度が上がる可能性もある。しかし、それらはすべて、受け取った情報を評価し、選別し、統合し、公開する能力を前提としている。前提となる応答能力が不足すれば、開放性は制度として機能しにくくなる。

この構造は、オープンソース全体の脆弱性報告経路にも現れている。GitHub 上のオープンソース・プロジェクトを対象にしたプレプリントでは、報告経路や安全性方針の整備状況に差があり、非公開報告の仕組みを推奨していても、公開の場に脆弱性が投稿されることがあるとされている[21]。これは、報告窓口の有無だけでは問題が解決しないことを示している。報告者がどこへ出すのかを理解していなければ、脆弱性情報は不適切な場所に出る。保守者がどう受け取るかを決めていなければ、報告は処理待ちとして積み上がる。公開前にどう調整するかが定まっていなければ、修正と通知の順序が乱れる。

脆弱性開示は、入口を用意すれば自然に回るわけではない。報告先を明示する。何を報告すべきかを説明する。どの情報が必要かを示す。報告後にどのような確認が行われるかを共有する。公開までの流れを設計する。必要なら、下流の配布元や製品ベンダーと調整する。これらの工程があって初めて、外部からの報告は安全性の改善へ接続される。

ここでも、因果関係は二段階で考える必要がある。第一段階では、報告経路の不整備が、公開場所の誤り、情報不足、重複報告、確認不能な報告を生む。第二段階では、それらの不整備が、保守者の追加確認、公開調整、優先順位づけの負荷を増やし、結果として重要な問題への対応を遅らせる。つまり、報告経路の問題は、単なる手続き上の不便ではない。安全性を高めるための情報が、処理可能な形で流れないという構造的な問題である。

したがって、開放性には応答能力という条件がある。外から見える入口があるだけでは足りない。そこへ届いた情報を読み、判断し、必要な関係者へつなぎ、修正と公開まで運ぶ能力が必要である。この能力が不足すると、報告の入口は安全性の入口ではなく、保守者の負荷を増やす入口になる。開かれていることは重要である。しかし、開かれているだけでは不十分である。開かれた入口を、安全性へつなぐ処理工程まで含めて設計しなければならない。

この観点から見ると、curl が脆弱性報告の受付を一時停止したことは、開放性の否定ではない。むしろ、応答能力を超えた開放性が、保守者の判断力を損ない、結果として安全性を支える工程を弱めることへの対応である。無制限に受け付け続けることが、常に利用者を守るわけではない。処理できない量を抱え込めば、確認が遅れ、修正が遅れ、公開判断が遅れる。開放性を維持するためにも、保守者が責任を持って応答できる範囲を守る必要がある。

ここで得られる一般化は、オープンソースに限らない。どのような制度でも、入口を広げるだけでは機能しない。相談窓口、通報制度、監視システム、検査体制、品質管理の仕組みは、いずれも情報を受け取る入口を持つ。しかし、受け取った情報を分類し、判断し、対応へつなぐ能力がなければ、入口は問題解決の装置ではなく、未処理案件を積み上げる装置になる。curl の事例は、AI 時代のセキュリティにおいて、この条件がより鋭く問われるようになったことを示している。

10. 誤報であっても、確認には本物の労力がかかる

脆弱性報告の負荷を考えるとき、誤報は軽く見られがちである。誤報ならすぐに却下すればよい、と考えたくなる。しかし、実際には、誤報かどうかは確認して初めて分かる。報告を読んだ瞬間に、それが本物の脆弱性なのか、通常の不具合なのか、仕様の誤解なのか、完全な誤りなのかを判断できるとは限らない。特に、報告文が長く、技術的に見え、もっともらしい因果関係を含んでいる場合、保守者は一目で捨てることが難しくなる。

Linux カーネルの不具合報告を対象にしたプレプリントでは、誤検知の不具合報告が開発者の労力を消費し、本物の不具合と同程度の議論や終了までの時間を必要とする場合があると示されている[22]。これは、誤報が「何も起こさない報告」ではないことを意味する。誤報は、結果としては修正不要であっても、その結論に到達するまでに、読み取り、再現確認、仕様確認、過去の報告との照合、却下理由の説明を必要とする。

この知見は、curl の事例を理解するうえでも重要である。報告が誤りであったとしても、その誤りを確認するまでは、保守者にとって未処理の仕事である。しかも、AI が作成した報告は、文章が整っているため、一目で誤報と断定しにくい。表面上の説得力が高いほど、保守者は丁寧に検証せざるを得ない。ここで生じる負荷は、報告が本物だった場合だけに発生するのではない。報告が誤りだった場合にも、誤りだと確定するための負荷が発生する。

第一段階の因果関係は、報告の増加が確認対象の増加を生むというものである。報告が本物か誤報かは、確認前には分からない。そのため、保守者は一定の範囲で、すべての候補を読む必要がある。第二段階の因果関係は、確認対象の増加が、判断の遅れと優先順位づけの難しさを生むというものである。本物の脆弱性、通常の不具合、仕様誤解、重複報告、完全な誤報が混ざるほど、保守者は、何を先に扱い、何を後回しにし、何を却下するかを判断しなければならない。

報告の状態 外から見える印象 確認に必要な作業 保守者に残る負荷
本物の脆弱性 実際に安全性へ影響する問題である。 再現条件、影響範囲、深刻度、修正方針、公開時期を確認する必要がある。 修正と公開まで進める責任が発生する。
通常の不具合 問題は存在するが、脆弱性とは限らない。 安全性上の影響があるか、単なる機能上の不具合かを切り分ける必要がある。 脆弱性対応から通常の不具合対応へ分類し直す判断が必要になる。
仕様の誤解 報告者には危険に見えるが、設計上は想定された挙動である。 仕様、過去の設計判断、利用条件を確認し、なぜ脆弱性ではないかを説明する必要がある。 却下する場合でも、根拠を整理する時間がかかる。
重複報告 既知の問題と似た内容が新しく届く。 既存報告と同じ問題か、似ているだけの別問題かを照合する必要がある。 重複確認、報告者への説明、既存対応との結び付けが必要になる。
完全な誤報 文章上は脆弱性に見えるが、実際には成立しない。 再現不能であること、前提が誤っていること、影響が存在しないことを確認する必要がある。 修正不要という結論に至るまで、確認コストが発生する。

この表から分かるように、誤報は無負荷ではない。誤報であることを確定するためには、少なくとも一定の調査が必要になる。特に、AI によって報告文が整えられている場合、報告の外形だけでは判断できない。文章が自然であること、専門用語が使われていること、危険そうな説明があることは、問題が実在することを保証しない。したがって、保守者は、文章の完成度ではなく、実際のコード、仕様、入力条件、利用環境に照らして確認しなければならない。

さらに、脆弱性対応は修正すれば終わりでもない。Linux カーネルの不完全なセキュリティ修正を扱ったプレプリントでは、セキュリティ不具合の修正が不完全で、元の問題を十分に直せなかったり、新しい問題を生んだりする場合があると分析されている[23]。これは、修正工程が単純な作業ではないことを示している。脆弱性候補の発見が自動化されても、修正が正しく、十分で、副作用を持たないかを確認する工程は残る。

ここにも二段階の因果関係がある。第一段階では、脆弱性として認定された問題に対して修正が作られる。しかし、修正はコードの一部を書き換えるだけでは終わらない。既存の利用者を壊さないか、別の条件で同じ問題が残っていないか、回避したつもりの入力経路が別の場所に残っていないかを確認する必要がある。第二段階では、不完全な修正が、新しい判断負荷と追加対応を生む。修正後に同種の問題が残れば、再び報告、確認、修正、公開の工程が発生する。

誤解 実際に必要な処理 本稿での意味 帰結
誤報はすぐ捨てられる 誤報だと確認するための調査が必要である。 誤りであっても、確認コストは実在する。 誤報が増えると、本物の報告を扱う時間も圧迫される。
本物なら修正すれば終わる 修正の完全性、互換性、副作用を確認する必要がある。 発見よりも修正後の安定化が難しい場合がある。 不完全な修正は、追加の報告と再対応を生む。
AI が見つければ人間は楽になる 候補の量が増えるほど、人間の確認対象も増える。 AI は検出を助けるが、判断の負荷を消すとは限らない。 発見能力だけが上がると、確認と修正の工程が詰まりやすくなる。
文章が整っていれば信頼できる 説明の流暢さとは別に、再現性、仕様との関係、影響範囲を確認する必要がある。 AI 時代には、文章の完成度と事実の正しさを分けて扱う必要がある。 もっともらしい誤報ほど、確認に時間を使わせる。

このため、AI による脆弱性候補の増加は、単純に「より安全になる」とは言えない。安全になるためには、候補が正しく選別され、修正され、公開される必要がある。誤報を減らす仕組み、再現性を高める報告様式、重複をまとめる仕組み、修正の完全性を確かめる工程がなければ、発見能力の増加は処理待ちの増加になる。

ここで重要なのは、AI を使うこと自体を否定することではない。AI は、候補発見、類似箇所の探索、再現手順の整理、修正案の検討に役立ちうる。しかし、それらは確認と修正の責任を消すものではない。AI が候補を増やせば、保守者はより多くの候補を評価する必要がある。AI が修正案を出せば、保守者はその修正案が正しいか、副作用がないか、公開できる水準かを確認する必要がある。つまり、AI は工程の一部を速くするが、工程全体の責任をなくすわけではない。

この章で確認したことは、本稿全体の論理を補強する。報告が本物であっても、誤報であっても、保守者の確認作業は発生する。本物なら、修正と公開まで進める必要がある。誤報なら、誤報であることを確認する必要がある。修正した場合でも、その修正が十分かどうかを確認する必要がある。したがって、脆弱性報告の問題は、単に「正しい報告を増やせば解決する」というものではない。正しい報告を安全性へ変換し、誤った報告を適切に退ける処理能力こそが、AI 時代のセキュリティ運用で問われている。

11. AI は発見を民主化し、責任を集中させる

AI の重要な効果は、発見の民主化である。ここでいう民主化とは、専門性が不要になるという意味ではない。高度なコード読解、過去事例の探索、異常な入力条件の検討、報告文の整理といった作業に、より多くの人が参加しやすくなるという意味である。以前なら、長い経験、深いコード理解、専用の解析環境がなければ到達しにくかった候補にも、AI の補助によって近づける場合がある。これは、セキュリティにとって明らかに良い面を持つ。見落とされていた箇所が調べられ、手作業では試しにくい条件が探索され、基盤ソフトウェアの弱点が早く見つかる可能性がある。

しかし、発見の民主化は、責任の民主化を自動的には意味しない。報告者は候補を提出できる。AI は説明を整えられる。危険そうな入力経路、境界条件、過去の脆弱性との類似を示すこともできる。だが、その候補を脆弱性として受け入れるか、通常の不具合として扱うか、仕様上の挙動として退けるか、修正をどう作るか、公開時期をいつにするかを決める責任は、プロジェクト側に集中する。ここに、AI 時代の非対称性がある。

この非対称性は、単に「報告者が多く、保守者が少ない」という人数の差だけではない。報告者は、候補を出すところで役割を終えることができる場合がある。しかし保守者は、候補を受け取ったあとに、コード、仕様、互換性、過去の修正、利用者への影響、公開時期までを考えなければならない。まず、AI によって候補を出す側の作業量が下がる。次に、その候補を採用するかどうかを判断する側の責任が相対的に重くなる。発見の入口が広がるほど、認定と公開の出口に判断が集まるのである。

側面 AI によって広がるもの 広がりにくいもの 責任が集中する理由
調査 より多くの人がコードを読み、怪しい箇所を探せる。 プロジェクト固有の設計意図を理解する力は簡単には増えない。 危険そうに見える挙動が、本当に設計上の問題なのかを判断するには、長期の文脈理解が必要になる。
報告 長く詳細な報告文を作りやすくなる。 報告者自身が問題を理解し、対話に参加する力は自動化されない。 説明が整っていても、追加確認に答えられなければ、保守者が不確実性を引き受けることになる。
候補生成 脆弱性らしい箇所を大量に提示できる。 本当に脆弱性かどうかを認定する責任は保守者に残る。 認定すれば修正、勧告、公開、利用者対応が発生するため、安易に採用できない。
修正 修正案や説明文を補助的に作れる。 互換性、再発防止、公開判断を含む責任は人間が負う。 修正を取り込んだ結果に責任を持つのは、提案者ではなくプロジェクトである。
公開 勧告文の下書きや影響説明の整理を補助できる。 何をいつ、どの範囲へ公開するかの判断は自動化しにくい。 早すぎる公開は悪用を助け、遅すぎる公開は利用者を危険に残すため、判断には責任が伴う。

この表が示しているのは、AI によって広がる工程と、広がりにくい工程がずれているということである。AI は、探索、要約、比較、文章化を助ける。これらは、候補を作り、報告を増やす方向に働く。一方で、設計意図の理解、影響範囲の確定、互換性の判断、公開時期の決定は、プロジェクト固有の責任に深く結び付いている。そこでは、単に情報を多く持っているだけでは足りない。どの情報を採用し、どのリスクを引き受けるかを決める必要がある。

ここで、責任という語を曖昧に使ってはならない。本稿でいう責任とは、道徳的な非難を受ける立場という意味に限らない。修正を取り込む責任、利用者へ説明する責任、誤った分類による混乱を避ける責任、公開時期を誤らない責任、既存の利用者を壊さない責任を含む。脆弱性対応では、判断の結果が、下流の配布元、製品、運用環境、利用者の更新判断へ波及する。だからこそ、候補を見つけることと、その候補を採用することの間には大きな段差がある。

この段差は、AI が高性能になれば消えるものではない。むしろ、AI がより多くの候補を見つけ、より説得力のある説明を作るほど、保守者はより多くの候補について採否を判断しなければならなくなる。直接には、AI が報告者側の生産性を上げる。さらに、その結果として生産された候補が保守者側の検証待ちとして積み上がる。ここで、発見の民主化が、判断責任の集中へつながる。

この構造は、単に保守者が忙しくなるという話ではない。責任が集中する場所では、判断の誤りが大きな影響を持つ。誤報を本物の脆弱性として扱えば、不要な警告、更新、混乱を生む。本物の脆弱性を通常の不具合として扱えば、利用者を危険に残す。修正を急ぎすぎれば互換性を壊す可能性がある。公開を遅らせすぎれば、利用者は防御できない。このように、AI によって候補が増えるほど、保守者は単に多くの作業を抱えるだけでなく、より多くの判断分岐を抱えることになる。

したがって、AI 時代のセキュリティを、発見技術の進歩だけで語ってはならない。AI は、問題を見つける人数を増やし、候補を作る速度を上げる。しかし、最終的な安全性は、候補を採用する人間と制度の側にかかっている。候補が増えても、検証されなければ安全性にはならない。検証されても、修正されなければ安全性にはならない。修正されても、利用者が更新できる形で公開されなければ安全性にはならない。

ここを見落とすと、AI の導入は保守者の負担を減らすどころか、責任をさらに集中させる。発見の民主化は重要である。しかし、それを利用者を守る対応へつなげるには、報告様式、再現性、重複管理、認定基準、修正工程、公開調整を含む制度が必要である。AI が広げるのは入口であり、入口が広がったぶん、出口である判断と公開の工程を強くしなければならない。

12. これはセキュリティだけの問題ではない

curl の事例は、セキュリティ固有の問題であると同時に、より一般的な構造を示している。観測できるものが増えると、判断すべきものも増える。検査できる項目が増えると、解釈すべき結果も増える。通報窓口を広げると、対応すべき申し立ても増える。監視を強化すると、警告も増える。ここで重要なのは、情報が増えることと、理解が増えることは同じではないという点である。情報は、受け取られ、分類され、意味づけられ、対応へつながって初めて、実際の改善に変わる。

この構造は、これまで見てきた脆弱性報告の問題と同型である。AI によって候補発見が速くなると、脆弱性らしいものは多く見つかる。だが、候補が多く見つかることは、脆弱性対応が多く完了することを意味しない。発見された候補は、再現され、仕様と照合され、影響を評価され、修正され、公開されなければならない。第一段階では、観測能力の向上が候補の量を増やす。第二段階では、その候補の量が、解釈、選別、優先順位づけ、対応の負荷を増やす。つまり、観測能力が強くなるほど、判断能力と処理能力が次の制約として現れる。

分野 増える観測 必要になる判断 処理能力が不足した場合の問題
セキュリティ 脆弱性候補、異常な入力条件、危険そうなコード経路が増える。 本当に脆弱性か、通常の不具合か、仕様上の挙動かを判断する必要がある。 誤報の確認に時間を使い、本物の脆弱性への対応が遅れる可能性がある。
医療 検査で見つかる所見、数値の異常、画像上の変化が増える。 治療すべき病気か、経過観察でよい所見か、偶然見つかった変化かを判断する必要がある。 過剰診断や不要な不安が生じる一方で、本当に重要な所見が埋もれる可能性がある。
行政 通報、相談、申し立て、市民からの情報提供が増える。 緊急性、公共性、法的対応の必要性、優先順位を判断する必要がある。 対応待ちが積み上がり、重要な案件への初動が遅れる可能性がある。
品質管理 検査項目、不具合候補、異常値、テスト失敗の記録が増える。 修正すべき欠陥か、許容範囲のばらつきか、測定条件による異常かを判断する必要がある。 修正すべき箇所が不明確になり、改善活動が検査結果の処理に追われる可能性がある。
監視運用 警告、ログ、異常検知、通知が増える。 本当に対応すべき障害兆候か、ノイズか、一時的な変動かを判断する必要がある。 重要でない通知に埋もれ、重大な障害の兆候を見落とす可能性がある。

医療を例にすると、この構造は分かりやすい。検査技術が高精度化すれば、以前なら見えなかった小さな変化や数値のずれが見つかる。これは早期発見につながる可能性がある。しかし、見つかった所見のすべてが治療すべき病気とは限らない。放置してよいもの、経過を観察すべきもの、追加検査が必要なもの、すぐに治療すべきものを分けなければならない。観測が増える第一段階では、見落としが減る可能性がある。解釈が追いつかない第二段階では、過剰診断、不必要な不安、医療資源の消費が生じる可能性がある。

行政の通報窓口でも同じことが起こる。窓口を広げれば、市民の声は届きやすくなる。これ自体は望ましい。これまで見えなかった困りごと、危険、制度の穴が把握される可能性がある。しかし、通報が増えれば、職員は緊急性、事実関係、管轄、対応可能性を判断しなければならない。第一段階では、入口の拡大によって情報が集まる。第二段階では、その情報を処理する体制が不足すると、対応待ちが増え、本当に急ぐべき案件が埋もれる。入口の民主化は、応答能力の拡張を伴わなければ、制度の信頼を損なう。

システム監視でも、警告を増やせば安全になるとは限らない。監視項目を増やし、しきい値を細かくし、異常検知を強化すれば、障害の兆候を早く拾える可能性は高まる。しかし、警告が多すぎれば、運用者はどれが重要なのかを判断し続けなければならない。重要でない警告が繰り返されれば、警告そのものへの注意が下がる。第一段階では、監視の強化が検出数を増やす。第二段階では、検出数の増加が注意力を消費し、重大な兆候への反応を遅らせる。これは、脆弱性報告で誤報や重複報告が保守者の判断帯域を消費する構造と同じである。

この意味で、curl の脆弱性報告受付停止は、特定プロジェクトの特殊な事情に留まらない。観測能力が増えたシステムでは、次に問題になるのは、解釈能力、判断能力、処理能力である。AI は観測と候補生成を強化するが、判断の責任を消すわけではない。むしろ、候補が増えたぶん、どれを扱い、どれを退け、どれを修正し、どれを公開するのかという判断が前面に出る。

ここで誤ってはならないのは、観測を増やすこと自体を否定しないという点である。脆弱性候補が見つからないより、見つかるほうがよい。医療上の重要な所見が見落とされるより、検出されるほうがよい。障害の兆候が監視されないより、警告されるほうがよい。問題は、観測が増えることではない。観測されたものを処理可能な単位に分け、優先順位を付け、対応へつなぐ仕組みが追いつかないことである。

したがって、AI 時代に必要なのは、単に検出能力を高めることではない。検出された候補を、誰が、どの基準で、どの順序で、どの責任で扱うのかを設計することである。セキュリティでいえば、報告様式、再現手順、重複管理、脆弱性認定、修正方針、公開調整が必要になる。医療でいえば、検査結果の解釈、追加検査の基準、治療開始の判断が必要になる。監視運用でいえば、警告の重要度、対応手順、抑制条件、エスカレーションの設計が必要になる。分野は違っても、観測を対応へ変換する工程が必要である点は共通している。

curl の事例が示している一般構造は、ここにある。AI は、見えるものを増やす。だが、見えるものが増えれば、判断すべきものも増える。判断すべきものが増えれば、処理能力の限界が表面化する。したがって、安全性や信頼性を高めるには、観測能力と同時に、解釈し、選別し、対応する能力を設計しなければならない。発見が増えることは出発点であり、結論ではない。

13. 既稿との接続 ―― AI の出力は、採用されたときに責任になる

本稿で扱ってきた curl の事例は、既稿で整理してきた AI 利用の問題と強く接続している。既稿では、AI に任せる前に、人間が問いの切り方、判断軸、優先順位、任せない領域を決める必要を論じた[24]。これは、抽象的な心得の話ではない。AI によって出力されるものは、問いの立て方、与えた前提、判断基準の置き方に強く依存する。したがって、人間側が何を調べたいのか、何を危険とみなすのか、どの条件を満たせば採用するのかを決めていなければ、AI の出力は判断材料ではなく、未整理の候補の束になる。

本稿の事例は、この議論をセキュリティ運用へ移したものとして読める。脆弱性報告でも、AI に候補を出させること自体が問題なのではない。問題は、どの候補を脆弱性として扱い、どの候補を通常の不具合として扱い、どの候補を仕様の誤解や誤報として退けるのかである。まず、AI が候補を増やす。次に、その候補を人間が分類し、検証し、採用または却下する。この第二段階の基準がなければ、AI の出力は安全性を高める材料ではなく、保守者の判断帯域を消費する入力になる。

既稿の論点 本稿での対応 接続する構造
AI に任せる前の判断軸 脆弱性候補をどう分類し、どこから人間が判断するかを決める必要がある。 AI の出力は、事前に設定された問いと基準があって初めて処理可能な材料になる。
AI の答えと採用責任 AI が出した候補をプロジェクトが脆弱性として受け入れた時点で、その判断はプロジェクトの責任になる。 出力の生成と、出力の採用は別工程であり、責任は採用側に発生する。
AI の業務実装 候補発見だけでは安全性にならず、報告、再現、修正、公開、通知の運用へ接続する必要がある。 AI の価値は、モデル性能ではなく、実際の工程に組み込まれたときに決まる。
CVE と制度的処理 脆弱性は、見つけられたあと、名づけられ、修正され、公開され、更新されることで社会的に扱える情報になる。 技術的な弱点は、制度的な処理経路に乗って初めて利用者の行動へ接続される。

また、既稿では、AI の答えは採用されたときに責任になると論じた[25]。本稿の文脈では、AI が出した脆弱性候補は、報告者の手元ではまだ候補である。危険そうに見えるコード経路、境界条件、入力検証の弱さ、過去の脆弱性との類似は、いずれも検討材料にすぎない。それをプロジェクトが脆弱性として受け入れ、CVE として扱い、修正し、公開したとき、その候補はプロジェクトの判断になる。つまり、AI が見つけたという事実ではなく、人間とプロジェクトが採用したという事実が、責任の発生点になる。

この点は、誤報の場合にも変わらない。AI がもっともらしい誤報を出した場合でも、それを受け取った側は、誤報だと確認するまで責任ある判断を求められる。報告者が理解しないまま提出した候補であっても、保守者は、再現するか、仕様と合っているか、影響があるかを確認しなければならない。直接には、AI の出力が報告者の作業を軽くする。さらに、その軽くされた作業の一部が、保守者側の検証負荷として現れる。ここに、AI 出力の採用責任だけでなく、AI 出力の未採用を判断する責任も生じる。

さらに、既稿では、生成 AI の競争軸がモデル性能そのものから業務実装へ移るという仮説を整理した[26]。脆弱性報告でも同じことが言える。AI が候補を見つける能力だけでは、実際の安全性にはならない。報告様式、非公開連絡、再現手順、修正レビュー、CVE、勧告、リリース、下流利用者への通知という運用に接続されて初めて、AI の発見は実際の防御に接続される。モデルがどれほど多くの候補を出せても、それらを処理する工程がなければ、候補は修正済みのソフトウェアにも、利用者の更新判断にもならない。

ここでも、因果関係は二段階で捉える必要がある。まず、AI が発見、整理、文章化を支援し、候補の提出を増やす。次に、その候補が既存の運用工程に流れ込み、受付、確認、認定、修正、公開、配布の負荷を発生させる。AI の価値は、第一段階だけでは決まらない。第二段階で、候補がどれだけ処理可能な形に整えられ、実際の修正と公開へつながるかによって決まる。

セキュリティ系の既稿では、CVE を単なる番号ではなく、観測、修正、制度、責任をつなぐ接点として扱った[27]。本稿も同じ方向にある。脆弱性は、コードの中に潜む弱点であると同時に、それを見つけ、名づけ、直し、公開し、更新する社会的な工程でもある。CVE はその工程の一部であり、問題を外部から追跡し、配布元や運用者が対応できる単位へ変換する役割を持つ。したがって、脆弱性とは、単に発見される技術的対象ではなく、制度によって扱える形に整えられる対象でもある。

これらの既稿との接続から見えてくるのは、AI の問題を「使うか、使わないか」という二択で捉えてはならないという点である。AI は、発見を補助できる。報告を整えられる。修正案を作れる。説明文の下書きも作れる。しかし、それらをどの基準で採用し、どの工程へ接続し、どの責任で公開するかは、人間と制度の側に残る。AI の出力が増えるほど、問いの設定、採用基準、責任分界、運用工程の設計が重要になる。

したがって、本稿は既稿の議論を、セキュリティ運用という具体的な現場で確認する位置にある。AI に任せる前に人間が判断軸を持つ必要がある。AI の出力は、採用されたときに責任になる。AI の価値は、実際の業務工程に接続されて初めて成立する。CVE は、技術的な弱点を社会的に処理可能な単位へ変換する。これらの論点は、curl の脆弱性報告をめぐる事例で一つにつながる。AI は入口を広げる。しかし、入口から入ってきたものを修正と公開へつなぐのは、人間の判断と制度の工程である。

14. 結論 ―― 見つける技術より、受け止める制度が問われる

curl の脆弱性報告受付停止から読み取るべきことは、AI が悪いという単純な結論ではない。AI を使った報告には、低品質な誤報もある。存在しない弱点をもっともらしく説明する報告、再現できない現象を脆弱性のように見せる報告、仕様上の挙動を攻撃可能性として誤解する報告は、保守者の時間を消費する。しかし、それだけを問題の中心に置くと、より重要な構造を見落とす。AI は、実際に有用な脆弱性候補を見つける能力も高めている。問題は、発見能力が高まったとき、それを受け止める側の検証、認定、修正、公開の能力が追いつくかどうかである。

本稿で見てきたように、脆弱性対応は、候補を見つける工程だけでは成立しない。候補が報告される。保守者が読む。再現する。仕様と照合する。通常の不具合なのか、脆弱性なのか、仕様の誤解なのかを分ける。脆弱性であれば、影響範囲を確認し、修正を作り、互換性を壊していないかを調べる。さらに、CVE や勧告として外部から追跡できる形にし、利用者が更新できる状態へつなげる。この一連の工程を通って初めて、発見された候補は安全性へ近づく。

ここで重要なのは、発見能力と処理能力が同じ速度で増えるわけではないという点である。AI は、候補探索、文章作成、類似事例の検索、修正案の下書きを速くする。これは報告者側の能力を拡張する。まず、報告の作成コストが下がり、脆弱性らしい候補が多く提出される。次に、その候補を受け取る保守者が、真偽、再現性、影響、修正方針、公開時期を判断しなければならない。発見の入口だけが広がれば、後続工程の狭さが表面化する。

工程 AI によって増えやすいもの 人間と制度に残るもの 詰まった場合の帰結
発見 脆弱性候補、危険そうなコード経路、過去事例との類似が増える。 候補が本当に問題かどうかを確認する基準が必要になる。 候補が未処理のまま積み上がり、重要な問題が埋もれる。
報告 長く詳細で、技術的に見える報告文が作られやすくなる。 再現手順、環境情報、影響範囲、報告者自身の理解が必要になる。 文章は整っていても、保守者が前提確認から引き受けることになる。
認定 脆弱性らしい候補が増える。 通常の不具合、仕様上の挙動、誤報、本物の脆弱性を分ける判断が必要になる。 誤った分類により、不要な混乱または対応遅れが生じる。
修正 修正案や説明文の下書きが作られやすくなる。 互換性、副作用、再発防止、修正の完全性を確認する必要がある。 不完全な修正や新しい不具合が発生し、追加対応が必要になる。
公開 勧告文や影響説明の下書きを作りやすくなる。 公開時期、対象範囲、下流利用者への影響を判断する必要がある。 早すぎる公開は悪用を助け、遅すぎる公開は利用者を危険に残す。

この表が示しているのは、AI が工程全体を等しく軽くするわけではないということである。AI は、入口側の発見と報告を強くする。だが、出口側の認定、修正、公開には、プロジェクト固有の知識と責任が残る。候補が増えるほど、どれを扱うかを選ばなければならない。報告が詳細になるほど、どの部分が事実で、どの部分が推測なのかを分けなければならない。修正案が出されるほど、それを取り込んだ結果に責任を持てるかを確認しなければならない。

脆弱性は、見つかった時点で安全性になるわけではない。候補として報告され、保守者が読み、再現し、仕様と照合し、影響を判断し、修正し、CVE や勧告として公開し、利用者が更新できる状態になって、初めて安全性へ近づく。そこには、時間、知識、責任、制度が必要である。AI が発見の速度を上げても、この時間と責任が消えるわけではない。むしろ、発見される候補が増えることで、どの候補を実際の防御へつなげるのかという判断がより重要になる。

したがって、AI 時代のセキュリティを、発見技術の進歩だけで語ってはならない。発見技術は重要である。未知の弱点が見つからないまま残るより、見つかるほうがよい。だが、発見だけでは利用者を守れない。まず、AI が観測と候補生成を強化する。次に、その候補を検証し、採用し、修正し、公開する制度が問われる。この第二段階が弱ければ、発見の増加は安全性の増加ではなく、未処理案件の増加になる。

本稿の最終命題は、次の通りである。AI 時代のセキュリティで問われるのは、脆弱性を見つける能力だけではない。見つかったものを、誰が検証し、どの基準で採用し、どの責任で修正し、どの制度で公開するのかである。発見する技術が進むほど、受け止める制度の重要性は増す。これは、AI を否定する結論ではない。AI を安全性へ接続するには、AI が増やした候補を処理可能な形に整える制度が必要だという結論である。

その制度は、抽象的な理念だけでは成り立たない。報告を短く明確にする。再現手順を示す。環境情報を添える。期待される挙動と実際の挙動を分ける。影響を誇張しない。重複を整理する。報告者が対話に参加する。保守者が休める余地を残す。修正、検証、CVE、勧告、リリース、下流利用者への通知を接続する。これらは地味な設計である。しかし、この地味な設計がなければ、AI によって増えた発見は、安全性ではなく処理負荷として積み上がる。

curl の事例が示しているのは、開かれたプロジェクトが弱いということではない。むしろ、広く使われ、外部から調べる価値があり、多くの報告を受け取るからこそ、発見と応答の釣り合いが問題になるということである。オープンソースの開放性は、安全性を高める条件である。しかし、その開放性が機能するには、受け取った報告に応答できる処理能力が必要である。入口を広げるだけでは足りない。入口から入ってきた情報を、実際の防御へつなぐ工程を守らなければならない。

AI は、見つける力を広げる。だが、見つかったものを安全性へ変えるのは、検証し、判断し、修正し、公開する人間と制度である。したがって、本稿で扱った問題の核心は、AI が脆弱性を見つけるかどうかではない。AI が見つけた後に、その候補を誰が受け止め、どの基準で扱い、どの責任で社会へ出すのかである。見つける技術が進むほど、受け止める制度が問われる。

参考文献

  1. Daniel Stenberg, curl summer of bliss（2026-06-15）. https://daniel.haxx.se/blog/2026/06/15/curl-summer-of-bliss/
  2. curl project, Vulnerability Disclosure Policy. https://curl.se/dev/vuln-disclosure.html
  3. curl project, curl. https://curl.se/
  4. curl project, curl CVEs. https://curl.se/docs/security.html
  5. Daniel Stenberg, The pressure（2026-05-26）. https://daniel.haxx.se/blog/2026/05/26/the-pressure/
  6. Daniel Stenberg, The end of the curl bug-bounty（2026-01-26）. https://daniel.haxx.se/blog/2026/01/26/the-end-of-the-curl-bug-bounty/
  7. Daniel Stenberg, Death by a thousand slops（2025-07-14）. https://daniel.haxx.se/blog/2025/07/14/death-by-a-thousand-slops/
  8. Daniel Stenberg, High-Quality Chaos（2026-04-22）. https://daniel.haxx.se/blog/2026/04/22/high-quality-chaos/
  9. Daniel Stenberg, Mythos finds a curl vulnerability（2026-05-11）. https://daniel.haxx.se/blog/2026/05/11/mythos-finds-a-curl-vulnerability/
  10. Daniel Stenberg, A human in control（2026-06-10）. https://daniel.haxx.se/blog/2026/06/10/a-human-in-control/
  11. Daniel Stenberg, Do excellent vulnerability reports（2026-06-29）. https://daniel.haxx.se/blog/2026/06/29/do-excellent-vulnerability-reports/
  12. Linux kernel documentation, Security bugs. https://docs.kernel.org/process/security-bugs.html
  13. GitHub Docs, Coordinated disclosure of security vulnerabilities. https://docs.github.com/en/code-security/concepts/vulnerability-reporting-and-management/coordinated-disclosure
  14. GitHub Docs, Privately reporting a security vulnerability. https://docs.github.com/en/code-security/how-tos/report-and-fix-vulnerabilities/report-privately
  15. GitHub Docs, Repository security advisories. https://docs.github.com/en/code-security/concepts/vulnerability-reporting-and-management/repository-security-advisories
  16. OpenSSF, Guide to coordinated vulnerability disclosure for open source projects. https://github.com/ossf/oss-vulnerability-guide/blob/main/maintainer-guide.md#readme
  17. FIRST, Guidelines and Practices for Multi-Party Vulnerability Coordination and Disclosure. https://www.first.org/global/sigs/vulnerability-coordination/multiparty/guidelines-v1.1
  18. HackerOne, Vulnerability Disclosure Guidelines. https://www.hackerone.com/terms/disclosure-guidelines
  19. CVE Program, CVE Numbering Authorities. https://www.cve.org/programorganization/cnas
  20. NIST, National Vulnerability Database. https://nvd.nist.gov/
  21. Sushawapak Kancharoendee, Thanat Phichitphanphong, Chanikarn Jongyingyos, Brittany Reid, Raula Gaikovina Kula, Morakot Choetkiertikul, Chaiyong Ragkhitwetsagul, Thanwadee Sunetnanta, On Categorizing Open Source Software Security Vulnerability Reporting Mechanisms on GitHub（2025）. https://arxiv.org/abs/2502.07395
  22. Jiashuo Tian, Dong Wang, Chen Yang, Haichi Wang, Zan Wang, Junjie Chen, Characterizing and Mitigating False-Positive Bug Reports in the Linux Kernel（2026）. https://arxiv.org/abs/2605.07678
  23. Qiang Liu, Wenlong Zhang, Muhui Jiang, Lei Wu, Yajin Zhou, Characteristics, Root Causes, and Detection of Incomplete Security Bug Fixes in the Linux Kernel（2025）. https://arxiv.org/abs/2511.17799
  24. id774, AI に任せる前に、人間が残すべき判断（2026-06-21）. https://blog.id774.net/entry/2026/06/21/4912/
  25. id774, AI の答えは、採用されたときに責任になる（2026-06-26）. https://blog.id774.net/entry/2026/06/26/4925/
  26. id774, 生成 AI の競争軸は、モデルから業務実装へ移る（2026-06-25）. https://blog.id774.net/entry/2026/06/25/4922/
  27. id774, CVE-2026-31431 について徹底的に考える（2026-05-06）. https://blog.id774.net/entry/2026/05/06/4730/