NATOとAISLE、CVE脆弱性IDの割り当て権限を取得
NATOは、その技術機関がソフトウェア脆弱性を命名する正式な権限を得たことでGoogle Newsに取り上げられた。この役割はこれまで、他のCVE組織を通じて担われてきた。NATO Communications and Information Agency（NCI Agency）は、AIセキュリティスタートアップAISLEとともに、新たなCVE Numbering Authorityとなった。この資格により、両組織は承認された適用範囲内で標準化された識別子を割り当て、対応する脆弱性レコードを公開できる。
この指定は事務的なものに聞こえるかもしれないが、特定のセキュリティ上の欠陥について、最初の公開記録を誰が管理するかを変えるものだ。CVE識別子は、研究者、ベンダー、政府機関、セキュリティ製品に対し、同じ脆弱性を指す共通の名称を与える。これがなければ、報告はアドバイザリ、スキャナー、リポジトリ、非公開の連絡の間で断片化しかねない。
したがって中心的な緊張関係は、NATOと競合するセキュリティ企業との対立ではない。より迅速で分散型の脆弱性公開と、グローバルなカタログに求められる一貫性との両立である。組織が増えれば開示ワークフローを短縮できる一方、権限主体が増えるごとに、適用範囲、根拠、レコード品質を管理すべき場所も増える。
NATOとAISLEが実際にできるようになったこと
新たな権限は脆弱性レコードに関するものであり、グローバルCVEカタログを無制限に管理する権限ではない。
CVE Numbering Authority（CNA）とは、合意された適用範囲内でCVE識別子を割り当て、CVEレコードを公開する権限を持つ組織である。この識別子は、開示された一つの欠陥に対し、CVE-2026に一意の番号が続くような永続的なラベルを付与する。レコードにはその後、説明、影響を受ける製品、参照情報、その他の構造化された情報を記載できる。
CNAが、見つけたすべての弱点に識別子を割り当てる包括的な許可を受けるわけではない。各機関は、CVE階層における上位組織が承認した境界の中で活動する。その境界は、CNA自身の製品、協調的に報告された事案、特定の研究活動、または別途定義された領域を対象とし得る。
AISLEは2026年7月22日に指定を発表した。同社が公開したCNA指定によると、自社製品で発見された脆弱性に対して識別子を割り当てられる。この文言が重要なのは、同社のAIシステムが検出するすべての脆弱性に対する権限よりも狭いからだ。
NCI Agencyの役割は、異なる制度上の意義を持つ。同機関は、NATO全体で使用される通信・情報システムを提供、維持、保護している。その参加により、承認された運用上の適用範囲に含まれる脆弱性を扱う、より直接的な経路が生まれる。
この指定は、NATOが既存の欠陥を改名したり、他のCNAの判断を覆したり、通常のソフトウェア不具合を一方的にグローバルな脆弱性として扱ったりできることを意味しない。CVEの規則は、権限主体が識別子を予約し、重複割り当てを避け、開示を調整し、公開済みレコードを修正する方法を定めている。
両組織は、CVE階層においてEuropean Union Agency for Cybersecurity（ENISA）の配下にある。ENISAは2025年11月にRootとなった。Rootは、その適用範囲内にあるCNAを支援・監督し、プログラム規則の実施を後押しする。
この階層は、運用上の公開とプログラムのガバナンスを分けている。CNAは識別子を割り当て、レコードを公開する。RootはCNAの参加を受け入れ、支援し、調整上の問題に対処するとともに、参加組織が共通の手順に従うよう支援する。
CVE Programは、2026年3月末時点で参加組織が502に達したと報告した。プログラム更新によると、この時点でネットワークには499のCNAと3つのCNA of Last Resortが含まれていた。追加の組織が参加するにつれ、総数は引き続き変動している。
この拡大が、Google Newsの見出しの背景にある。NATOとAISLEは中央の脆弱性窓口を置き換えるのではない。製品や開示に最も近い組織への依存を強める、連邦型のシステムに加わるのである。
防御側にとっての直接的な利点は、発見から認知された識別子までの道筋が明確になることだ。対象となる欠陥を報告する研究者は、影響を受ける環境に精通していない遠隔の調整役だけに全面的に依存する必要がない。責任を持つCNAが、その適用範囲内でレコードを管理できる。
この利点は、インシデント時に具体的な意味を持つ。軍事システムの運用者、ソフトウェアベンダー、請負業者、国家対応チームは、同じ欠陥に異なる内部名称を使う場合がある。CVE識別子は、それぞれのアラート、資産一覧、チケット、緩和策のガイダンスに共通の参照先を与える。
この共通参照だけでパッチが適用されるわけではない。しかし、それがなければ異なるツールや報告体制を使う組織間で困難になる調整を可能にする。NATOの新たな権限が価値を持つのは、そのシステムがまさにこうした制度上の境界をまたいでいるためだ。
Google Newsがガバナンスの変化を取り上げる理由
この話題が今浮上しているのは、脆弱性の発見が加速する一方、開示を処理する機関への圧力が高まっているためだ。
AIシステムは、研究者によるソースコードの調査、テストケースの生成、安全でないデータフローの追跡、疑わしい欠陥の再現を支援できる。こうしたシステムが検証の必要性をなくすわけではない。しかし、保守担当者や開示調整役に届く潜在的な発見の数を増やすことはできる。
この増加は、発見後の段階でボトルネックを生む。疑われる弱点は、検証し、重複と切り分け、影響を受けるバージョンに対応付け、責任あるベンダーと調整し、正確に記述しなければならない。初めて、有用な公開レコードが生まれる。
CVE Programは、第1四半期に予約された識別子の急増を、AI主導の脆弱性発見に伴う需要の増加と結び付けた。四半期報告は、脆弱性エコシステム全体で高まる圧力を説明しており、解決済みの自動化問題を示すものではない。
NISTは別の立場から、同じ量に直面している。National Vulnerability Database（NVD）は、多くのセキュリティ製品や政府のワークフローで利用される追加分析でCVEレコードを充実させる。NVD自体がすべてのCVE識別子を割り当てるわけではない。
2026年4月、NISTは年初3カ月間の提出件数が、2025年の同時期をほぼ3分の1上回ったと述べた。また、2025年には約42,000件のCVEを拡充し、これは過去のどの年よりも45%多かったとしている。
こうした増加でも、流入量には追い付かなかった。NISTは拡充の優先順位を変更し、CISAのKnown Exploited Vulnerabilities Catalogに含まれる脆弱性、連邦政府のソフトウェア、重要ソフトウェアの脆弱性に集中することにした。その他のレコードもデータベースには残るが、直ちに拡充されない可能性がある。
この区別は不可欠だ。公開されたCVEは、完全なNVD分析がなくても存在し得る。両ソースを交換可能なものとして扱う組織は、拡充フィールドの欠落を脆弱性そのものの欠落と誤認する恐れがある。
CNAが増えれば、識別子の割り当てをベンダー、研究者、調整役に近付けることで、このシステムの一部を軽減できる。このモデルは、すべての報告を一つの組織に通すのではなく、作業を分散する。NATOとAISLEは現在、この分散型公開レイヤーに参加している。
ただし、分散化は責任も外側へ移す。各CNAは報告を調査し、適用範囲を正しく適用し、開示を調整し、下流の利用者が解釈できるレコードを作成しなければならない。影響を受けるバージョンを誤記したり、有用な参照情報が欠けたりするなら、割り当ての迅速化に価値はほとんどない。
AISLEのAIへの注力は、この課題を特に見えやすくする。AIはコードを探索し、根拠の整理を助けられるが、モデルの出力が自動的に確認済みの脆弱性になるわけではない。ツールは到達不能なコードをフラグ付けしたり、セキュリティ境界を誤解したり、代替的な統制を見落としたりする可能性がある。
偽陽性には現実的なコストが伴う。保守担当者は報告を調査する必要があり、セキュリティチームは不要なインシデント対応を開始するかもしれず、顧客には実際の露出がないにもかかわらず不安を招くアラートが届く可能性がある。重複した割り当てにより、同じ根本的な欠陥を説明するレコード間で議論が分断されることもある。
偽陰性は反対のリスクを生む。自動化システムは、状況に依存する認可の欠陥を見落としたり、通常とは異なる構成を必要とする悪用経路を退けたりする可能性がある。悪用可能性はアーキテクチャ、展開方法、意図された信頼境界に左右されることが多いため、人によるレビューは依然として必要だ。
だからこそ、Google Newsの枠組みを「AIが脆弱性に名前を付けられるようになった」と単純化すべきではない。AISLEは、CVEの手順によって統制される制度上の役割を得た。重要なのは、AI支援型のセキュリティ業務と公開レコードに対する正式な責任が組み合わさったことだ。
NATOの参加も注目を集める別の理由となる。同盟の技術は、国境、請負業者、ミッションネットワーク、異なるセキュリティ分類にまたがって運用されている。欠陥が複数の組織に影響する場合、協調された命名は曖昧さを減らせるが、公開開示は依然として運用上のセキュリティを尊重しなければならない。
結果としてこれは、規模に対するガバナンス上の対応である。脆弱性の発見は加速しやすくなっている。検証、調整、信頼できる公開には、依然として多くの労力が必要だ。
分散型CVE権限は速度と一貫性を引き換えにする
中央集権型の処理ではすべての開示を吸収できないためCVEシステムは拡大しているが、連邦化はレコード品質を共有リスクにする。
CVE Programは、単一の普遍的な割り当て窓口ではなく、階層構造を採用している。Boardが戦略的方向性を定め、Secretariatが運営とインフラを支援する。Top-Level Roots、Roots、CNAs、CNAs of Last Resortが監督と運用業務を分担する。
プログラムが公開している組織構造によると、識別子の割り当てとレコード公開はこの階層を通じて行われる。CNAが運用業務を担い、Rootは配下の組織を管理し、プロセス上の問題の解決を支援する。
この設計には明確な利点がある。ソフトウェアベンダーは、一般的な調整役よりも自社のリリース履歴をよく理解している。国家対応チームは、地域の報告関係を理解している。NATOの技術機関は、承認された自らの適用範囲に含まれるシステムと組織を理解している。
地域や組織に根差した知識は、基本的な判断を短縮できる。CNAは適切な製品責任者を特定し、報告を別の組織に回すべきか判断し、修正を開発できる人々と公開を調整できる。これにより、検証済みの報告から有用な公開識別子までの遅延を減らせる可能性がある。
このモデルは、一つの機関を恒久的な世界的ボトルネックにすることも避ける。CVEネットワークは、2016年の23 CNAから、2026年3月までに500を超える参加組織へと成長した。プログラムによると、カタログは2025年中に30万件のレコードを超えた。
とはいえ、連邦化はばらつきを生む。CNAごとに、人員、技術的専門性、開示量、経験は異なる。ある機関は詳細なバージョン範囲と修正に関する参照情報を公開するかもしれない。別の機関は当初、求められる最低限の情報しか提供しない可能性がある。
スコープもまた摩擦の原因となる。ある企業が発見した脆弱性が、別ベンダーの依存関係に影響する場合がある。発見組織はその案件を移管し、別のCNAと調整し、またはどのレコードが根本的な問題を最も適切に表すかを判断する必要がある。
現代のソフトウェアでは、その境界を引くことがさらに難しくなっている。アプリケーションは、オープンソースのパッケージ、商用ライブラリ、クラウドサービス、生成コード、社内コンポーネントを組み合わせている。ある製品で表面化した障害が、別の場所で保守されている依存関係に起因することもある。
AI生成の発見結果は、保守担当者が調査できる速度を上回って届く可能性があるため、負荷を高める。多数のリポジトリをスキャンするシステムは、短期間に複数のCNAスコープにまたがる報告を生成できる。割り当てプロセスでは、依然として重複を防ぎ、ベンダー間の調整を尊重しなければならない。
このトレードオフは、分散型の権限を否定する理由にはならない。任命発表ではなく、レコードの結果によってシステムを評価すべき理由である。読者は、正確な影響対象バージョンのデータ、適時の更新、明確な参照情報、可視化された修正を確認すべきだ。
NCIAは、透明性と防衛セキュリティの間でさらに緊張関係に直面する。公開された脆弱性レコードは、ベンダーと防御側の連携を支援する。一方で、詳細な開示は、慎重な取り扱いが必要なシステム、構成、運用上の依存関係に関する情報を明らかにする可能性もある。
CNAプロセスはすでに、あらゆる詳細を即時公開するのではなく、協調開示を前提としている。CNAは、影響を受ける組織が修正を開発している間に識別子を予約できる。その後、公開レコードをアドバイザリや緩和策と併せて公開できる。
それでも、軍事的な文脈では判断がより慎重さを要する。レコードは、防御側が行動するために十分な情報を提供しつつ、任務固有の詳細を不必要に露出させてはならない。そのバランスを自動化モデルに全面的に委ねることはできない。
AISLEは、民間部門の側から関連する信頼性の試練に直面している。同社の事業はAIネイティブの脆弱性管理と結び付いており、自動化はそのアイデンティティの中核にある。同社のCNAとしての成果は、AI支援ワークフローが保守担当者やセキュリティチームに信頼されるレコードを生み出せるかどうかを示すことになる。
同社が現在公表しているスコープも、この指定が何を証明するかを限定している。AISLE自身の製品における脆弱性への権限は、無関係なソフトウェアで見つかった欠陥に対する一般的な管轄権を意味しない。それを、AIスキャナーがCVEを発行するための世界的なライセンスとして提示すべきではない。
この制約は健全である。CNAスコープは、すべての参加者に無制限の割り当て権限を与えずにネットワークを拡大する手段となる。AIセキュリティベンダーが自社製品の外でより多くの欠陥を発見するようになったとき、こうした境界が理解可能なまま保たれるかが問われる。
ここではENISAの立場が重要となる。ENISAは、その権限範囲内でCNAを特定し、オンボーディングし、支援できるようにRootとなった。その役割には、参加組織がCVE手順に従うための支援と、階層全体での運用上の調整支援が含まれる。
したがって、NATOとAISLEの参加を最も強く解釈するなら、制度的な意味合いである。欧州は、世界的に認知された識別子システムを通じて脆弱性開示を処理する能力を高めている。最も弱い解釈は、2つの組織がレコードの品質を何ら変えないバッジを受け取ったというものだ。
証拠は公開された実務から得られる。任命は権限を生む。一貫して有用なレコードは信頼を生む。
脆弱性に名前が付いた後にこそ、難しい部分が始まる
CVE識別子は命名の問題を解決する一方、優先順位付け、修正、悪用分析は依然として別の仕事である。
セキュリティチームはしばしば、CVEを完全なリスク評価として扱う。しかし、そうではない。識別子は、複数の関係者が同じ脆弱性について話していることを示す。組織が影響を受けるコンポーネントを稼働させているか、あるいは攻撃者がそれに到達できるかを自動的に示すものではない。
有効な対応は、資産の文脈から始まる。チームは、どの製品バージョンを使用しているか、それらの製品がどこで稼働しているか、どのデータを扱うか、そしてどのような制御が周囲にあるかを把握しなければならない。正確なレコードでも、不完全なソフトウェア資産台帳を補うことはできない。
深刻度スコアリングは別の層を加える。Common Vulnerability Scoring System、すなわちCVSSは、定義された特性を用いて技術的な深刻度を推定する。すべての組織の露出度、事業への影響、現在の脅威活動を捉えるものではない。
実際の悪用に関する証拠は、高い理論上のスコアより重要になる場合がある。CISAのKnown Exploited Vulnerabilities Catalogは、活発な悪用の証拠がある欠陥を特定する。NISTが2026年に行った優先順位付けの変更は、これらのレコードをエンリッチメントキューの先頭に置くことで、この違いを反映している。
パッチの可用性も対応を変える。ベンダー修正がない名前付きの脆弱性では、構成変更、ネットワーク制限、機能停止、または一時的な監視が必要になる可能性がある。信頼できる修正がある低深刻度の欠陥は、サポートされていないシステム内の重大な問題よりも解決しやすい場合がある。
NATO環境では、依存関係と相互運用性に関する懸念も加わる。1つのコンポーネントを置き換えたり更新したりすると、複数の組織が運用するシステムに影響する可能性がある。標準的な企業導入で機能するパッチでも、任務ネットワークでは追加のテストが必要になる場合がある。
CNAの指定は、調整の初期段階を改善できる。NCIAは識別子を予約し、関連当事者と協力し、そのスコープ内でレコードを公開できる。この共通ラベルは、参加組織がアドバイザリ、修正作業、内部追跡を整合させる助けとなる。
ただし、ローカルでの評価の必要性をなくすことはできない。NATOの各機関、加盟国政府、請負業者、サプライヤーは、それぞれ異なる資産と運用上の制約を抱えている。同じCVEでも、ある環境では緊急対応を要し、別の環境では通常の保守で済む場合がある。
AISLEの課題も同様に実務的だ。AIは、コードの証拠収集、バージョン比較、構造化されたレコード項目の準備を支援できる。それでも、人間は報告された挙動が有効なセキュリティ境界を越えていること、そして同社のCNAスコープに含まれることを確認する必要がある。
検証基準は、もっともらしいモデル出力より高くあるべきだ。発見には、再現可能な挙動、影響対象バージョンの分析、明確なセキュリティ上の結果が必要である。報告では、脆弱な製品と安全でない導入選択も区別すべきだ。
AIシステムは、ソースコードに完全な運用文脈がほとんど含まれていないため、こうした境界の扱いに苦労する可能性がある。認可はインフラストラクチャのポリシーに依存する場合がある。悪用可能性は、ビルドフラグ、ネットワーク配置、外部IDプロバイダーに依存することもある。
生成された報告は、その証拠が裏付ける以上に確実そうに聞こえることもある。流暢な説明が、データ制御や攻撃者アクセスに関する無効な前提を隠している可能性がある。CNAレビュー担当者は、文章の確信度ではなく、根底にある経路を確認する必要がある。
これがGoogle Newsの記事の懐疑的な視点である。新たな割り当て権限は管理上の遅延を減らせるが、AIが発見したすべての問題を有効化するわけではない。一般の人々は、レコード作成の高速化を脆弱性インテリジェンスの向上と同一視すべきではない。
レコードの品質は時間をかけて評価すべきだ。有用な指標には、公開済みエントリに正確なバージョン情報がどれほど速く追加されるか、参照先が実行可能なアドバイザリを指しているか、そしてレコードに重要な修正がどの程度必要になるかが含まれる。
重複の扱いにも同等の注意が必要である。異なる研究者が同じ欠陥を発見することがある一方、1つの弱点が、依存関係を共有する複数の製品を通じて現れることもある。成熟したCNAは、同一の欠陥に対して競合する識別子を公開するのではなく、調整しなければならない。
開示のタイミングも別の試験となる。あまりに早く公開すると、修正が利用可能になる前に利用者を露出させる可能性がある。待ちすぎると、攻撃者が同じ弱点を独自に見つけている間、防御側が認識できないままとなる場合がある。CNAステータスは、組織に対してスコープ内でこのプロセスを管理する権限を与えるが、判断を不要にする公式は存在しない。
より広いエコシステムには、重複するデータサービスも存在する。CVE Listは標準化されたレコードを提供し、NVDは分析を追加する。ENISAはEuropean Vulnerability Databaseを運用し、CISAは悪用済み脆弱性カタログを維持している。ベンダーやセキュリティ企業も独自のインテリジェンスを追加している。
これらの情報源は相互補完するべきだ。スキャナーが、出所を説明せずに識別子、スコア、またはエンリッチメント項目を提示すると問題が生じる。チームは、主張が割り当てCNA、政府データベース、ベンダー、自動推論のいずれに由来するかを知る必要がある。
Google News経由でこの記事にたどり着いた読者にとって、これが実務的な要点である。NATOとAISLEは現在、特定の欠陥の命名に直接参加できる。どちらの組織も、単なる識別子を完全な運用ガイダンスに変えることはできない。
Google Newsの見出しが薄れた後に注目すべきこと
これらの任命が脆弱性調整を強化するのか、それとも単にCNA名簿を拡大するだけなのかを示すシグナルは3つある。
最初のシグナルは、NCIAとAISLEが公開する初期レコードの品質である。最初期のエントリは、実務を通じて各組織のスコープを明確に示すべきだ。明確な製品名、影響対象バージョン、簡潔な説明、有用な参照情報は、分散型権限の根拠を支えるだろう。
修正も重要となる。脆弱性に関する知識は公開後に発展することが多いため、更新されたレコードが必ずしも失敗を示すわけではない。重要なのは、修正が透明性をもって行われ、さらなる混乱を生むことなく曖昧さを解消するかどうかだ。
重大な誤りは信頼を損なう。これには、重複した割り当て、不正確な影響対象バージョン、技術的な証拠に裏付けられないセキュリティ影響を主張する説明が含まれる。スコープに関する争いが繰り返されるなら、オンボーディングで運用上の境界が定まっていないことを示すだろう。
2つ目のシグナルは、ENISAが拡大するRootとしての責任をどのように管理するかである。ENISAは2025年11月にRootとなり、その役割には追加のCNAの特定、オンボーディング、支援が含まれると述べた。また、CVE階層が運用上の問題を調整するCouncil of Rootsにも参加した。
NCIAとAISLEは単独で行動するのではなく、より広い欧州の構造に加わる。ENISAのRoot responsibilitiesには、パートナーの支援と、CVEガイドラインが確実に遵守されるための支援が含まれる。そのCNA全体で一貫したレコードが作られれば、地域的な監督が世界的な能力を高めるという主張を強化するだろう。
逆の結果は、同じRootを共有する組織間での実務の分断である。スコープの説明が依然として解釈しにくい、またはレコード品質に大きなばらつきがある場合、ENISAはより強力なオンボーディング指針と品質レビューを必要とするかもしれない。
欧州の報告要件が成熟するにつれ、このシグナルはさらに重要になる。EU Cyber Resilience Actは、デジタル要素を含む製品に関する義務を定めている。製造者は、ENISAのインフラを通じて、積極的に悪用されている脆弱性や重大なインシデントを報告するプロセスを必要とする。
ENISAは、そのreporting platformを、製造者が同じ報告を複数の国家当局へ個別に提出することを防ぐための単一窓口として説明している。規制報告、協調開示、CVE割り当て、公開データベースの相互作用が、利用者の体験を形作ることになる。
十分に接続されたシステムであれば、重複作業を減らせる。製造者は必要なチャネルを通じてインシデントを報告し、修正を調整し、適切な場合には標準化された脆弱性レコードの公開を支援できる。
接続が不十分なシステムでは、期限、定義、対象読者が異なる並行提出が発生する可能性がある。それは、防御側が利用できる情報を改善することなく、管理上の負荷を増やすことになる。
第三のシグナルは、AI支援による発見が、単なる報告件数ではなく、検証済みの成果を改善するかどうかだ。AISLEの記録は目に見える一つの試金石となるが、この問題は業界全体に及ぶ。セキュリティチームには、自動化が再現可能な発見と正確な記録の作成に役立つことを示す証拠が必要だ。
有用なパフォーマンス指標には、メンテナーによって確認された報告の割合、検証から協調公開までの時間、影響を受けるバージョンが正確に記載された記録の比率が含まれる。訂正率と重複率は、重要な失敗モードを明らかにするだろう。
生の発見件数は、それほど参考にならない。AIシステムは、信頼度の閾値を下げることで、多数の候補となる発見を生成できる。追加された報告が検証済みで実行可能な脆弱性につながらない限り、これはレビュー担当者の作業を増やすだけだ。
NATOの成果は、別の主張を検証できる。その価値はスキャン規模よりも、複雑な制度環境における調整にある。機関、サプライヤー、各国チーム間の連携が迅速化されれば、NCIAをCNAネットワークに迎え入れる判断を裏付けることになる。
軍事組織はすべての運用詳細を開示できないため、公開される証拠は必然的に不完全なものとなる。それでも、NCIAの公開範囲における記録の品質と適時性は、この指定が対外的な調整を改善するかどうかを示し得る。
今回の任命は、より広範なCVEネットワークとの比較にも値する。すでに500を超える参加組織が、分散型の割り当てが確立された方針であることを示している。NATOとAISLEが注目されるのは、このモデルの中で防衛、欧州のガバナンス、AI支援セキュリティを結び付けているためだ。
両者の参加によって、CVEシステムの将来をめぐる議論に決着がつくわけではない。このネットワークは依然として、増加する提出件数、不均一な情報拡充、資金面の懸念、迅速な公開と一貫したデータの間の緊張という課題に直面している。
ただし、機関がどこに賭けているかは示している。脆弱性の命名を単一の中央機関の周りで再構築しようとするのではなく、階層構造の下で説明責任を負う発行者を追加することで、規模への対応を図っているのだ。
最初の記録、ENISAの監督、そして検証済みの発見と自動生成された報告の比率に注目してほしい。これらのシグナルは、Google Newsの一過性の話題より長く意味を持つ。より迅速な命名が、より明確なセキュリティ判断を生むのか、それとも負荷過多の防御担当者が処理すべき識別子を増やすだけなのかを明らかにするだろう。
