IvantiのAIセキュリティガイダンスは作業時間を短縮したが、Claude Skillは詳細を捏造した

Ivantiは、Claudeベースのパッチ分析Skillが詳細を捏造していたことを明らかにした。定常的なワークフローを数時間から数分へ短縮したにもかかわらずだ。IvantiのAIセキュリティガイダンスシステムは、開発中にMicrosoft Officeのエディションを混同し、Adobeのリリース周期も繰り返し誤読した。

この認定は重要だ。出力は、Microsoftの月例Patch Tuesday後にセキュリティチームが脆弱性の優先順位を付ける際に役立てられる。引用された脆弱性がすべて実在していても、もっともらしい捏造は、どのシステムを最初に対処すべきかを歪める可能性がある。

Ivantiは人間による承認ゲートを導入し、6月のチャートでClaudeの役割を公表した。CrowdStrikeとPalo Alto Networksも影響の大きいセキュリティ自動化に人間を関与させているが、同程度の捏造を検出した事例を公に説明した企業はない。

したがって、この話は単に一つのモデルが誤りを犯したという以上の意味を持つ。ベンダーがAIが運用上のガイダンスをどう形作るのか、レビュアーが実際に何を検証しているのか、そしてどのようなエラーが見えないまま残るのかを開示するかどうかの試金石である。

IvantiのAIセキュリティガイダンスは数か月にわたる修正を経て本番導入された

Ivantiは、開発者がトレーニング中に捏造や混同された詳細を繰り返し発見した後にのみ、Claude Skillを本番環境へ移行した。

Ivantiのエンドポイントセキュリティ担当プロダクトマネジメント担当バイスプレジデントであるChris Goettlは、約10年にわたり手作業で実施してきたプロセスを中心にSkillを構築した。これは公開済みのベンダーアドバイザリとIvanti独自のスプレッドシートを取り込み、同社の脅威リスク優先順位付け手法を適用する。

この文脈でのSkillとは、AIモデルに提供される再利用可能な指示、ソース、ワークフロールールの集合を指す。モデルが各ベンダーの開示システムを独自に理解していることを意味するものではない。

Goettlはベンダーごとにシステムをトレーニングした。比較的構造化された入力を提供するダウンロード可能なスプレッドシートがあったため、最初はMicrosoftだった。Adobeでは、モデルが個別ページと変化するレイアウトを解釈する必要があり、異なるアプローチが求められた。

この違いにより重要な弱点が露呈した。SkillはAdobeのリリース周期を繰り返し誤って出力した。また、Microsoftが複数の製品ファミリーとして分けているMicrosoft Officeのエディションを混同した。

これらは文体上の欠点ではない。リリース周期と製品識別は、アナリストが異常な活動、影響を受けるソフトウェア、パッチ適用の緊急性をどう解釈するかに影響する。誤ったパターンを示す洗練された要約でも、チームを誤った方向へ導きかねない。

Goettlは、回答が明らかに裏付けを欠いているように見えた際に、システムに問いただしたと説明した。AI支援パイプラインでの彼の説明によれば、Claudeは捏造された内容に参照可能な根拠がないことを認めた。

Ivantiによれば、このSkillが使用するのは公開されたベンダーアドバイザリと同社管理下のスプレッドシートのみである。顧客データは処理せず、生成されたすべての出力は人間が承認するまでドラフトのままとされる。

シニアプロダクトマネージャーのTodd Schellは、以前に手作業で作成された2か月分のブリーフィングを使ってシステムを再実行した。Ivantiは98%の一致を報告する一方、エッジケースが残っていることも認めた。

この数値は慎重に解釈する必要がある。VentureBeatは、ソースデータ、採点手法、エラー分類、再実行結果を独自に監査していない。一致率はまた、関連するすべての脆弱性が生成出力に含まれていたことを保証するものではない。

最初の本番実行は、Goettlが休暇中だった2026年8月に行われた。以前は2人の従業員がそれぞれ約4時間を要していたスプレッドシートが、30分未満で処理されたという。

より広範な月次ワークフローでは、各Patch Tuesdayの前後に合計約48時間を要していた。Ivantiは、この作業がGoettlとSchellの合計勤務時間の少なくとも5%に相当すると見積もった。

運用上の利点は理解しやすい。機械は、大規模なリリースを収集、正規化、分類する作業を、2人の専門家がスプレッドシート間で手作業によりフィールドを転記するよりも速く行える。

しかし、Ivantiは専門家をプロセスから外したわけではない。同社は専門家の仕事を、すべての行を組み立てる作業から、機械が作成したドラフトをレビューする作業へと変えた。

この違いが中心的な対立を規定する。自動化は手作業による構築を減らして時間を節約する一方で、信頼できるセキュリティガイダンスは依然として人間の判断とソースレベルの検証に依存している。

より広範な報道が出る前、Ivantiは目に見える開示も残していた。同社のJune Patch Tuesday投稿は、著者が設計したプロンプトとGoettlのデータセットを用いてClaudeが生成したチャートであることを示していた。

そのキャプションは規制によって求められたものではない。文言を定める一般的な業界標準もなかった。この開示は、より広く注目を集めるまで約3か月間、公に閲覧可能な状態だった。

開発上の失敗が明らかになると、この控えめなキャプションは重要な意味を持った。それはAI生成の成果物を、特定されたモデル、人間の著者、日付、明確に定義されたデータセットに結び付けた。

これは一般的な「AI支援」ラベルよりも高い透明性を提供する。それでも、どの行がチェックされたのか、完全性をどのように測定したのか、公開されたリスク階層が独立した検証を受けたのかは明らかにしていない。

Patch Tuesdayのデータ問題が自動化を魅力的にした

直接的な圧力は、規模が大きくなり、標準化が進まず、各ベンダーの解釈への依存度が増したPatch Tuesdayプロセスから生じた。

2026年9月8日、Microsoftは複数のセキュリティ研究者が同社史上最大のPatch Tuesdayと表現したリリースを公開した。しかし、同じリリースを分析する組織間で公表された合計数には大きな差があった。

Tenableは、重大と評価された104件、重要と評価された860件を含む964件の脆弱性を数えた。同社のSeptember analysisでは、パッチが利用可能になる前に実際に悪用されていた脆弱性も2件特定された。

Ivantiは973件を数えた。Senservaは、他のトラッカーと同じアドバイザリ中心の手法ではなく、ナレッジベース記事に対して脆弱性をマッピングしたため、1,169件を数えた。

TenableとSenservaの合計数の差は205件だった。この差は、Ivantiが引用した以前のPatch Tuesday記録である2025年10月の175件を上回った。

これらの差は、AIモデルがエラーを起こしたことを証明するものではない。対象範囲、重複エントリー、製品バリアント、アドバイザリの境界、ナレッジベースのマッピングに関する正当な選択から生じ得る。

しかし、単一の月次合計を中立的な事実として扱えない理由は示している。公開される数値はすべて、解析手法と、何を対象集合に含めるかという定義を反映するようになった。

MicrosoftがSecurity Update Guideで月ごとの統合CVEリストを一つにまとめて提示しなくなったことで、この問題は深刻化した。Rapid7はJuly patch reviewの準備中にこの変更を記録した。

現在、各セキュリティベンダーはMicrosoftが利用可能にしたデータからリリースを再構築しなければならない。その再構築には、決定論的なコード、手動分析、AIモデル、あるいはその3つすべての組み合わせが関わり得る。

決定論的パーサーは明示的なルールに従い、同一の入力を与えられた場合は同じ結果を生成する。大規模言語モデルは一貫性のないページをより柔軟に解釈できるが、裏付けのない関係性を生成する可能性もある。

出力が単なる件数ではない場合、このトレードオフはとりわけ重要になる。セキュリティチームには、実際の悪用、公開開示、深刻度、資産の露出、ビジネス上の重要性に基づく優先順位付けが必要だ。

不正確な件数は報告を混乱させる可能性がある。不正確な優先順位は、攻撃者がすでに悪用している脅威から限られたパッチ適用能力を逸らす可能性がある。

Ivantiのウェビナーブリーフィングには、毎月500人から700人が参加しているとされる。参加者が必ずしもすべての推奨事項を直接本番環境に適用しているわけではないが、その聴衆規模は各優先順位付けの判断に無視できない影響範囲を与える。

時間的な圧力も現実のものだ。攻撃者が行動を起こす前に、セキュリティチームが約1,000件のエントリーを落ち着いて精査することはできない。

CrowdStrikeは、公開された概念実証を伴う観測済みの悪用の88%が、48時間以内に始まったと報告した。概念実証とは、脆弱性がどのように悪用され得るかを示す、公開されたコードまたは技術文書である。

連邦要件はさらに厳しい場合がある。CISAのBinding Operational Directive 26-04は、連邦文民機関における最高リスクの脆弱性について、3日間の修正期限を定めた。

こうした条件下では、ベンダーには収集と予備的な分類を自動化する強い動機がある。完璧な手作業レビューを待つこと自体がリスクを生む可能性がある。

問題は組織がAIを利用すべきかどうかではない。加速によって重大な脆弱性の見落とし、製品マッピングの破損、弱いシグナルの過大評価が生じていないことを証明できるかどうかである。

Ivantiの経験は、この証明が流暢さから得られない理由を示している。モデルの不正確な出力は、専門家による認識と直接的な問いただしを必要とするほど説得力のあるものに見えた。

したがって、セキュリティの購入担当者は両側から圧力を受けている。より迅速なガイダンスを必要とする一方、速く、よく書かれたブリーフィングに完全で正確に優先順位付けされた集合が含まれていると想定することはできない。

真の転換点は捏造ではなく開示にある

驚くべき点はClaudeが詳細を捏造したことではなく、Ivantiが失敗を説明し、目に見える人間のゲートを維持したことだ。

大規模言語モデルは、トレーニングデータと提供されたコンテキストから、もっともらしい連続を予測することでテキストを生成する。すべての記述が提供されたソースに対応することを本質的に保証するわけではない。

ハルシネーションとも呼ばれる捏造は、モデルが裏付けのない情報を根拠があるかのように提示する場合に発生する。このワークフローでは、失敗は不正確なベンダーパターンと混同されたソフトウェアファミリーとして現れた。

こうした弱点は、汎用AIシステムではすでによく知られている。リスクを大きくするのは、それらがセキュリティ推奨事項を生み出すパイプラインの中に置かれていることだ。

消費者向けチャットボットのエラーは、読者の時間を無駄にするかもしれない。運用ガイダンスにおける脆弱性行の欠落は、露出したシステムの修正を遅らせる可能性がある。

Ivantiの開示は、そのリスクをなくしたわけではない。リスクを検証可能なものにした。

同社は少なくとも一つの公開グラフィックにモデル名と人間の責任者を付した。Goettlは、トレーニング中にどの問題が生じたのか、なぜレビューゲートが必要であり続けたのかも説明した。

このレベルの具体性は、顧客がより良い質問をする助けとなる。顧客はモデル支援による収集と自律的な優先順位付けを区別でき、どの段階で人間の検証が行われるかを尋ねられる。

この認定は、従来の信頼に関するメッセージを複雑にする。ベンダーは通常、AI機能を発表する際、精度の向上、処理速度、アナリストの生産性を強調する。

開発上の失敗が同等の注目を受けることはめったにない。この不均衡は、購入者が既知の失敗モードではなく、最良のベンチマークに基づいてワークフローを評価することを促す。

Ivantiが報告した98%の一致率は、この危険を示している。この数字は安心感を与えるように聞こえるが、実用上の意味は残りの差分に何が含まれていたかに依存する。

重要でない書式の不一致と、実際に悪用されている脆弱性の見落としを同じ重みで扱うべきではない。有用な評価では、運用上の影響に応じてエラーを分類する必要がある。

完全性は、正確性とは分けて扱うべきだ。レビュアーは、可視化された行にある誤った深刻度や不正な説明を見つけられるかもしれないが、存在しない行には容易に気づけない。

これは、人間によるレビューという考え方にとって最も厳しい課題だ。生成された出力を読むことは、それを権威あるソースのインベントリと照合することとは異なる。

独立系のバーチャル最高情報セキュリティ責任者であり、IEEEのシニアメンバーでもあるKayne McGladrey氏は、顧客にはパイプラインに関する文書化された説明が必要だと主張した。同氏によれば、ベンダーはモデルがどこで動作するのか、CVEsをどのように解析するのか、誰が出力をレビューするのか、そしてどの程度がソース検証を受けるのかを説明すべきだという。

同氏の批判は、人間の署名を求めるだけにはとどまらなかった。過去に人間が作成した月次データを再現して比較すれば類似性は測定できるが、当月の正確性を証明することはできない。

人間のレビュアーも、モデルと同じ盲点を持つ可能性がある。両者が可視化された項目だけに注目していれば、レビュー開始前に消えた項目を発見することはできない。

したがって、重要な基準はトレーサビリティだ。公開される各推奨事項は権威ある入力情報に結び付けられ、各入力情報には処理結果が記録されるべきである。

特に重要なのは後者だ。これによりレビューは、「この草稿はもっともらしく見えるか」から、「すべてのソース項目を説明できるか」へと変わる。

ここで、規律あるナレッジブレンディングが、パッチ適用を超えて重要になる。ソースを組み合わせることが有用なのは、ワークフローが来歴を保持し、矛盾を覆い隠すのではなく明らかにする場合に限られる。

Ivantiの開示は出発点であり、完成された基準ではない。同社はAIが関与したこと、そして既知の捏造がレビュー工程に影響を与えたことを購入者に伝えている。

しかし、行単位の系統情報、独立したリスク階層テスト、偽陰性率、または自動照合されたソース資料の割合については、公には示していない。

それでも、この告白は競合他社への圧力となる。AI支援型のセキュリティガイダンスを販売しながら検証チェーンを説明しないベンダーは、今やIvantiより少ない情報しか顧客に提供していないことになる。

この逆転は居心地の悪いものだが、建設的でもある。モデルの失敗を公に認めることがプロセスの成熟度を示す証拠になり得る一方、沈黙は優れた統制の存在も、統制がまったく存在しないことも隠し得る。

人間によるレビューが機能するのは、欠落した証拠を見つけられる場合に限られる

レビュー担当者が価値を加えられるのは、レビュー設計が欠落、裏付けのない主張、影響の大きい分類ミスを対象としている場合に限られる。

Ivantiのワークフローでは、Claudeによる草稿と公開されるブリーフィングの間に人が介在する。モデルが優先順位付けを自動公開するよりも安全だ。

しかし、「human in the loop」は設計の説明であって、品質測定ではない。その有効性は、担当者が何を見て、何を確認し、何を止められるかに左右される。

文章を確認するレビュアーは、不自然な表現、誤った製品ファミリーに分類された見覚えのある製品、あるいは不自然なリリースパターンを見つけられる。Goettl氏の専門知識は、トレーニング中にこうした目に見える異常を捉えたようだ。

より困難な失敗は、静かな除外だ。パーサーやモデルが脆弱性の行を最初から作成しなければ、最終的なスプレッドシートだけを確認するレビュアーには、明白な警告が届かない。

より強固なシステムには、言語モデルの外側に照合統制が必要となる。決定論的なチェックにより、ソース識別子の比較、一致しないレコードのフラグ付け、重複CVEsの検出、ベンダー別の想定項目数の集計を行える。

そのうえでモデルは、解釈が有益なタスクを担える。たとえば、アドバイザリの要約、一貫しない説明の正規化、専門家の承認を前提としたリスク分類の提案などだ。

この分担は、機械に異なる責任を割り当てる。コードは完全性と再現性を守り、モデルは曖昧な表現と優先順位付けの文脈を支援する。

また、より明確な失敗シグナルも生まれる。生成された説明文が洗練されて見えても、照合の不一致によって公開を停止できる。

リスク階層の検証にも同様の厳密さが必要だ。システムは、ある項目がそのランクを受けた理由、その判断を支えたソース上の事実、人間のレビュー後に何が変わったかを記録すべきである。

この記録がなければ、最終承認は説明責任を確立しても、品質に関する証拠は限られる。レビュアーが全推奨事項を確認したのか、最高リスクの行を抽出確認しただけなのかを示せない。

Ivantiは、既知の悪用、公開開示、異常な件数シグナルがエスカレーションを起動すると述べている。これは妥当なルールセットだが、公表情報はその適用を独立して検証していない。

AdobeとOfficeでの失敗は、ベンダー固有のテストが必要な理由も示している。Microsoftのスプレッドシートで良好に動作するワークフローでも、別の発行元がWebページ、異なる命名規則、不規則なリリース日程を用いれば失敗する可能性がある。

したがって、評価は各データソースと各変換段階を対象にしなければならない。総合平均では、Microsoftでの強い性能の陰に弱いベンダーコネクターが隠れてしまう可能性がある。

CrowdStrikeはFal.Con 2026で異なるレビュー方式を説明した。同社の「human on the loop」アプローチでは、アナリストがエージェントと並行して同じ検知を処理し、その後に判定を比較すると報じられている。

並行作業は、逐次的なレビューでは見逃す不一致を明らかにできる。また、1人がすでに完成した草稿を確認するワークフローよりも、多くの人間の関与を維持する。

Palo Alto Networksは2026年2月、高影響のアクション向けに事前構築済みエージェントと承認ゲートを備えたCortex XSIAM AgentiXを発表した。同社のエージェント型SOC設計も、自動判断がより大きな結果を伴う領域で人間の統制を維持している。

どちらの設計も、欠落した入力情報の問題を自動的に解決するわけではない。人間とエージェントがいずれも不完全なフィードを基に判断することもあれば、承認ゲートが誤った証拠に基づくアクションを認可することもあり得る。

それでも、この比較は新たに形成されつつある合意を示している。主要ベンダーは、高影響のセキュリティ運用において、無制限の自律性を許容できる標準的な選択肢とは見なしていない。

この合意は重要だ。業界で使われる表現は、支援と自律をしばしば曖昧にする。ブリーフィングを草案化するシステムと、パッチの適用、デバイスの隔離、インシデントの終了を行うシステムは、本質的に異なる。

購入者は、各AIアクションをその可逆性と潜在的な害に対応付けるべきだ。低影響の要約には、本番システムを変更する判断ほど厳しい統制は必要ない。

また、実際の失敗事例に基づく証拠も要求すべきである。一致率だけを報告するベンチマークでは、誤りが表現、対象範囲、深刻度、あるいは欠落のどれに関係していたのかが隠される。

Ivantiが既知の捏造を検出したという事実は、単なる正確性の主張よりも有益な情報だ。それは、システムがどのような具体的条件下で信頼できなくなったのかを示している。

未解決の問題は、本番環境の統制が、トレーニング中に発見された失敗だけでなく、新たな失敗モードも検出できるかどうかだ。ベンダーサイトは変化し、分類体系は進化し、異例のリリースは昨日までの解析前提を無効にし得る。

人間によるレビューは依然として必要だが、測定可能な統制システムの中に組み込まれるべきである。そうでなければ、この言葉は、最も危険な誤りを発見可能であることを示さないまま、安心感だけを与える表現になりかねない。

Ivantiの告白は、すべてのセキュリティベンダーに求められる基準を引き上げる

セキュリティベンダーは今、AIを利用しているという事実だけでなく、AIが顧客向けの優先順位にどのような影響を及ぼすのかを正確に開示するよう求められている。

Ivantiだけがセキュリティ分析を自動化しているわけではない。CrowdStrike、Palo Alto Networks、その他のベンダーも、検知、調査、トリアージ、対応のワークフローにモデルとエージェントを組み込んでいる。

ここで明らかになった競争上の違いは透明性だ。Ivantiはモデル名を明らかにし、入力情報を説明し、既知の捏造パターンを特定し、公開には人間の承認が必要であると説明した。

VentureBeatは、CrowdStrikeやPalo Alto Networksから同等の公開された捏造開示を見つけられなかったと報じた。この不在は、両社のシステムに失敗があったことも、統制が弱いことも立証しない。

それは、顧客が比較可能な情報を得られないことを意味する。あるベンダーは失敗履歴の一部を明らかにしている一方、他社は主にアーキテクチャと安全策を説明している。

公開開示は難しいインセンティブの問題を生む。誤りを報告する企業は、成功した評価だけを公開する競合他社より信頼性が低いように見える可能性がある。

セキュリティ調達は、証拠を評価することでこのインセンティブを逆転させられる。購入者はすべてのベンダーに同じ質問をし、回答がないことを未解決の統制ギャップとして扱える。

まず顧客は、どの成果物がAI生成なのかを尋ねるべきだ。回答では、収集、解析、要約、スコアリング、推奨、自動アクションを区別する必要がある。

次に、完全性をどのように検証するのかを尋ねるべきだ。有効な回答は、欠落行、重複レコード、ソースの変更、取り込みの失敗に対応していなければならない。

第三に、誰が結果をレビューし、そのレビューが何を対象とするのかを尋ねるべきだ。承認担当者を明示することは有用だが、文書化されたチェックリストと監査証跡の方が強い保証をもたらす。

第四に、単一の正確性パーセンテージではなく、エラーの分類を求めるべきだ。購入者は、失敗が文法、製品の帰属、悪用状況、深刻度、または収載に影響するのかを知る必要がある。

これらの要求は、問題となる判断に見合ったものだ。パッチチームが優先順位付けを利用するのは、すべての問題を同時に修正できないためである。

9月のリリースは規模の問題を示している。Tenableは964件のCVEsを特定し、Ivantiは973件、Senservaは異なる集計方法で1,169件を特定した。

購入者は、すべてのベンダーが同じ数値を出すことを必ずしも必要としていない。必要なのは、各ベンダーが対象範囲を説明し、その範囲に対して推奨事項を照合することだ。

同じ論理はリスク階層にも当てはまる。ベンダーは悪用可能性、露出度、事業上の文脈を異なる方法で評価してよいが、その判断は追跡可能な状態に保たれるべきである。

透明性はベンダーを不公平な比較からも守る。文書化された手法があれば、2つの合計値の違いが一方のシステムによる静かなデータ欠落ではなく、定義された対象範囲に起因することを示せる。

この問題はサイバーセキュリティの範囲を超える。AIが生成する研究、コンプライアンス報告、財務要約、運用レポートにはいずれも、表面的なレビューでは見逃されるもっともらしい欠落が含まれ得る。

CVEsには識別子と権威あるアドバイザリが存在するため、セキュリティ分野ではこの問題が特に明確に見える。この構造により、ベンダーは完全性をテストする実践的な方法を得られる。

より構造化されていない証拠を扱う組織は、さらに難しい課題に直面する。それでも、来歴、矛盾の検出、欠落した資料の明示的な扱いが必要だ。

したがって、Ivantiのアプローチは十分ではないものの注目に値する。同社の開示は沈黙より多くの情報を顧客に伝える一方、報告された統制には重要な検証上の疑問が残る。

同社の過去のセキュリティ上の文脈により、精査は特に重要となる。パッチガイダンスを評価する顧客は、モデルの効率だけでなく、Ivantiがリスクを正確に伝える能力も判断することになる。

この精査は証拠に基づくべきだ。ここで扱ったClaudeスキルは公開パッチデータを分析したもので、顧客環境にアクセスしたとは報じられていない。

これは自律型の修復エージェントではない。定期的なブリーフィングの草稿を作成し、その公開には人が責任を負う仕組みだった。

これらの分類を混同すれば、事象を過大評価することになる。「人間が確認した」からといって捏造を軽視すれば、統制上の課題を過小評価することになる。

慎重な結論は、その両極端の間にある。Ivantiは大幅に高速化されたプロセスを作り、実際のモデルの失敗を検出し、AIの関与を開示し、専門家によるレビューを維持した。

同社は、すべての欠落した脆弱性をプロセスが検出できること、またはすべての優先順位判断を独立して検証できることを公には示していない。これこそ、顧客が今後Ivantiとその競合他社に求めるべき基準である。

AIパッチガイダンスが信頼を得たかどうかを示す3つのシグナル

次の試金石は、ベンダーが広範な人間による監督を、可視化され、再現可能で、情報源を網羅した検証へと転換できるかどうかだ。

最初のシグナルは、2026年10月13日の次回Patch Tuesdayで現れる。アナリストは、公開される件数、対象範囲の定義、既知の悪用ラベル、そして通常と異なるベンダーデータの扱いを比較すべきである。

Ivantiの出力が迅速さを維持しつつ、情報源間の不一致を明確に説明し続けるなら、監督付き自動化を支持する根拠は強まる。説明のない欠落やマッピングエラーがあれば、その根拠は弱まる。

2つ目のシグナルは、Ivantiまたは競合各社による、より詳細な情報開示である。有用な文書は、モデルがどこで動作するのか、完全性を守る決定論的な制御が何か、どの判断に人間の承認が必要かを明らかにするはずだ。

こうした情報は、透明性が競争上の標準になり得るという議論を強化する。一方で、広義の「human in the loop」という表現に頼り続ければ、中心的な検証上の空白は解消されないままである。

3つ目のシグナルは、本番環境での評価から得られる証拠だ。ベンダーは、悪用可能な顧客情報を開示せずに、エラーの分類、情報源のカバレッジ、レビュアーによる上書き、高影響度の見逃しを報告すべきである。

こうした証拠は、新たな形式やエッジケースに遭遇した後、システムが改善するかどうかを示す。集計された一致率だけでは、その問いには答えられない。

CrowdStrikeによる急速な悪用に関する報告は、この作業を完全に手作業へ戻せない理由を説明している。同社の悪用に関する調査結果は、防御側がしばしば短縮し続ける対応時間の中で行動していることを示している。

したがって、望ましい結論は自動化を減らすことではない。推奨が人や機械を動かす前に、その根拠を検査できる自動化である。

セキュリティリーダーにとって実務的な対応は、AIを利用するすべての外部ガイダンス情報源を棚卸しすることだ。モデルが数えるのか、解釈するのか、順位付けするのか、行動するのかを確認すべきである。役割ごとに異なる失敗経路が生じるためだ。

次に、ベンダーのレビューに関する主張を、1つの難しい問いで検証する。生成された下書きに一度も現れなかった脆弱性を、そのプロセスはどのように検出するのか。

答えが、欠落に誰かが気づくことに依存しているなら、その制御は不完全である。情報源の照合、例外処理、人間による判断の記録が含まれるなら、そのワークフローの信頼性はより高い。

IvantiのAIセキュリティガイダンスは、この議論のための公開ケーススタディとなっている。同社のClaude skillはアナリストの時間を大幅に節約した一方、開発中に詳細を捏造し、同社はその失敗を前提とした設計を迫られた。

この開示は自動的な信頼を得るべきではないが、注目に値する。顧客に検証すべき具体的な弱点を提示し、競合各社にはそれを上回れる透明性の基準を与えるからだ。

次のAI支援型セキュリティブリーフィングに頼る前に、モデルの役割、情報源の完全性チェック、レビュアーの実際の作業内容を確認してほしい。その答えは、どの見出しの精度スコアよりも多くを明らかにする。