人工知能は、ソフトウェアの脆弱性を発見するプロセスを急速に変えています。AIは大規模なコードベースを分析し、認証や認可の不整合、危険なデータフロー、API設計上の問題、疑わしいビジネスロジックなどを短時間で抽出できます。

しかし、AIが「脆弱性の可能性」を発見したことと、実際に攻撃可能なセキュリティ脆弱性が確認されたことは同じではありません。

現代のAIセキュリティで最も重要な課題の一つは、発見能力そのものではなく、大量に生成される候補の中から、実際に意味のある脆弱性を検証することです。

Anthropicが2026年5月に公開したMythos関連の脆弱性開示データでも、この問題は明確に見えます。公開されたスナップショットでは23,019件の候補が生成され、そのうち外部セキュリティ研究者がレビューした1,900件の中で1,726件が有効と確認されました。Anthropic自身も、人間によるトリアージと検証がプロセス上の重要な制約になっていると説明しています。

この数字を、すべてのAI脆弱性ツールの精度として扱うべきではありません。

より重要な意味は別にあります。

AIは候補を生成する速度を大幅に高められる一方、それを安全に検証し、優先順位を付け、修正へつなげる作業は依然として高度なセキュリティ判断を必要とするということです。

AIが発見するのは「結論」ではなく脆弱性候補

AIによるSecurity Reviewでは、Modelが疑わしいCode Patternを発見することがあります。

Authorization Checkが見当たらない。

Untrusted InputがSensitive Functionへ流れている。

API間でPermission Handlingが異なる。

一つのToolが必要以上のAuthorityを持っている。

こうした観察は有用です。

しかし、それだけでConfirmed Vulnerabilityにはなりません。

実際のSecurity Findingとして扱うには、

コードが本当に実行されるのか、

攻撃者が必要なInputを制御できるのか、

既存のSecurity ControlがAttack Pathを止めないのか、

実際のEnvironmentで再現できるのか、

そして結果として重要なSecurity Boundaryが破られるのか

を確認する必要があります。

そのため成熟したSecurity Teamでは、

AIがHypothesisを作り、人間のResearcherがそれを検証する

という役割分担が重要になります。

なぜAIは説得力のあるFalse Positiveを生み出すのか

従来のScannerもFalse Positiveを大量に生成してきました。

Static AnalyzerがDangerous Functionを発見する。

Version ScannerがVulnerable Packageを検出する。

Web Scannerが疑わしいResponse Patternを見つける。

しかしAI Noiseには少し違う問題があります。

説明が非常に説得力を持つことです。

LLMは、

どのFunctionが問題なのか、

AttackerがどのInputを使うのか、

どんなImpactが予想されるのか、

どのRemediationが必要なのか

まで、完全なPentest Reportのように説明できます。

ところが、その説明全体が一つの間違った前提に依存していることがあります。

たとえばModelは、あるFunctionにAuthorization Checkがないと指摘するかもしれません。

しかし実際には、すべてのCallerがその前段でPermission Checkを実行している。

別のケースでは、Dangerous-Looking Valueを発見しても、それがExternal AttackerからControlできない場合があります。

文章の質とSecurity Evidenceは同じではありません。

AIがより流暢になるほど、Security Teamはより厳密に証拠を確認する必要があります。

AI脆弱性のValidationは可能性から証拠へ進む

実用的なValidation Processは、段階的に進みます。

最初はSecurity Signalです。

次にTechnical Reproduction。

その後Exploitability。

最後にActual Security Impactを確認します。

重要なのは、それぞれを混同しないことです。

Security Signal

最初の段階では、

「何かがおかしい」

だけで十分です。

Authorizationの流れが不自然。

Validationが一部Endpointだけ欠けている。

RoleによってAPI Responseが異なる。

AI Agentが通常Userには見えないToolへアクセスできる。

この段階でCriticalやHighと決める必要はありません。

まず確認するべきなのは、

このCandidateが本物の脆弱性になるには、どの前提が成立する必要があるのか

です。

Technical Reproduction

次に実際のSystem Behaviorを確認します。

Source Code上ではReachableに見えても、Productionでは呼び出されていないかもしれません。

API Problemなら複数RoleやObjectでBehaviorを比較します。

AI Applicationなら、Manipulated Model Behaviorが実際にApplication Security Boundaryを越えられるか確認します。

ここで多くのAI Candidateが消えます。

AIはCodeからBehaviorを推論できます。

Runtime Testは、Softwareが本当にどう動くかを示します。

Exploitability

Real Bugであっても、それがAttackとして成立するとは限りません。

Anonymous Userが利用できるのか。

Authenticated Customerが必要なのか。

Administrator Permissionが必要なのか。

InternetからReachableなのか。

特殊なConfigurationが必要なのか。

Attacker-Controlled ValueがSensitive Operationまで実際に届くのか。

これらを確認して初めて、Technical WeaknessがAttacker Capabilityへ変わります。

Real Security Impact

最後に、そのVulnerabilityによって何が可能になるかを確認します。

別UserのConfidential Dataへアクセスできるか。

Unauthorized State Changeが可能か。

Privilege Escalationできるか。

Restricted Functionalityへ到達できるか。

Tenant Isolationを破れるか。

Confidentiality、Integrity、Availabilityのどれが実際に破られるのか。

ここで初めて、AIによるDetectionが実際のRisk Analysisになります。

DetectionとExploitabilityは別物

AIはSuspicious Patternを見つける能力を急速に高めています。

しかし「怪しい」と「攻撃できる」は違います。

Authorization Checkが一つのEndpointで欠けているように見えても、そのEndpointへ到達できるのがStrongly Authenticated Internal Serviceだけなら、External Attack Scenarioは大きく変わります。

逆に、コード上では非常に小さなObject Lookupの違いでも、Ordinary Userが別CustomerのConfidential Recordへアクセスできるなら重大です。

Severityは、AIの説明がどれだけ高度に見えるかではなく、

検証された攻撃結果

によって判断するべきです。

Reachabilityがなければ脆弱性は攻撃経路にならない

AI CandidateがManual Validationで消える最大の理由の一つがReachabilityです。

Vulnerable Codeは本当に存在する。

Bugも技術的には存在する。

しかしAttackerはそこへ到達できない。

ProductionではFunctionがDisabled。

Internal Authenticationが必要。

Dangerous Branchが特定Configurationでしか動かない。

InputがSensitive Functionへ到達する前にTransformされる。

このような場合、Code Smellは存在しても、元のAttack Scenarioは成立しません。

そのためExecution EnvironmentとApplication Stateの理解が重要です。

Attacker ModelなしにSeverityは決められない

同じTechnical Conditionでも、誰がTriggerできるかによってRiskは大きく変わります。

Anonymous Internet User。

Authenticated Customer。

Internal Employee。

Compromised Administrator。

RAGへ悪意あるDocumentを投入できるExternal Actor。

それぞれCapabilityが異なります。

Validationでは、

Attackerは何を知っているか。

何をControlできるか。

どこへReachできるか。

どのIdentityを持っているか。

を定義する必要があります。

そのThreat Modelの中でCandidateを確認して初めて、Realistic Severityを評価できます。

AI False Positiveは必ずしもAIが「弱い」ことを意味しない

False Positiveの多さは、必ずしもSecurity Reasoningの失敗だけを示しているわけではありません。

優秀なHuman Researcherも多くのHypothesisを作り、その多くを捨てます。

AIとの違いはScaleです。

Modelは非常に短時間で大量のHypothesisを生成できます。

False Positiveは、

Runtime Configurationを知らない、

別LayerのSecurity Checkを見落としている、

ValueのTrust Levelを誤解している、

Internal ValueをAttacker-Controlledだと考える、

Framework Behaviorを誤解する、

Impactを過大評価する

などの理由で生まれます。

必要なのはAIを使わないことではありません。

大量Candidateを吸収できるValidation Pipelineを作ることです。

高いTrue Positive RateでもHuman Reviewは必要

高性能AI Research SystemでもManual Reviewの価値は消えません。

Anthropicが2026年5月22日に公開したReviewed Subsetでは、1,900件のMythos Candidateのうち90.8%がValidと確認されています。ただしこれはAnthropicの特定PipelineとReviewed Sampleに関する数字であり、すべてのAI Security Toolへ一般化できる数値ではありません。

さらに重要なのは、

Bugが存在することの確認と、

Professional Security Findingを完成させること

は別だという点です。

Affected Version。

Production Environment。

Realistic Attacker。

Business Impact。

Disclosure Requirement。

Root Cause。

Remediation。

これらは追加評価が必要です。

Human ValidationはFalse Positiveを消すだけではありません。

Technical Discoveryを実際にEngineeringで使えるSecurity Intelligenceへ変換します。

Alert数よりValidated Attack Pathの方が重要

AI Vulnerability ProgramをFinding Countで評価するのは危険です。

500件のSuspicious Patternを出すSystemが、20件しか出さないSystemより強力に見えるかもしれません。

しかし20件がAuthentication、Tenant Isolation、Sensitive Dataへ直結するValidated Attack Pathなら、価値はまったく違います。

重要なのは、

AIが何個見つけたか

ではなく、

何件のVerified Riskが最終的に除去されたか

です。

Vulnerability Chainingで小さな問題が大きなAttack Pathになる

一つのFindingだけを見るとLow Severityに見える場合があります。

Minor Information Disclosure。

Internal Identifierが見える。

別APIへそのIdentifierを使える。

次のAPIでAuthorization Weaknessがある。

さらにPrivileged Functionalityへ到達する。

最終的にはPrivilege Escalationになる。

AIはLarge Technical Surface全体のContextを保持できるため、こうしたConnectionのCandidateを探すのが得意です。

Human Testerの役割は、

そのChainがReal Application上で本当に成立するか確認すること

です。

AIがBreadthを提供し、Human ValidationがReality Checkを行います。

Business Logic Vulnerabilityは特にHuman Contextが重要

Business Logicの問題では、Software自体がDeveloperの実装どおり動いていることがあります。

問題は、Business Ruleが破られていることです。

回数制限すべきOperationを繰り返せる。

Low-Privilege Roleが複数の正当なFunctionを特定順序で組み合わせる。

AI Agentが個別にはAuthorizedされたToolを組み合わせ、Forbidden Business Outcomeを作る。

これらはCrashや明確なLow-Level Errorを生まない場合があります。

必要なのはProduct Intentの理解です。

Applicationが本来何を許可するべきなのかを理解しなければ、Security Impactも判断できません。

AI Security FindingはApplication LevelまでValidationする

AI Application自身をテストする場合、この問題はさらに重要です。

Red-Team Systemが、

ModelをManipulateして特定Responseを生成できた

と発見したとします。

それだけではApplication Vulnerabilityとは限りません。

次に確認するべきなのは、

Unauthorized RAG Dataへ到達するか。

Sensitive ToolをInvokeできるか。

別UserのStateへ影響できるか。

Original Userが直接できないOperationを実行できるか。

External Malicious ContentでAgentをRedirectできるか。

です。

Model Behaviorだけでなく、Application全体のBoundaryを見る必要があります。

ModelはUntrusted Componentとして扱う

有効なSecurity Design Assumptionは、

ModelはUnsafeまたはIncorrect Requestを生成する可能性がある

と考えることです。

たとえばManipulated ModelがAdministrative ToolをRequestする。

Backend AuthorizationがRejectする。

この場合ModelはFailしました。

しかしApplication SecurityはFailしていません。

一方、AI ServiceがGlobal Privileged Identityを使っているため同じRequestが成功するなら、本当のAuthorization Vulnerabilityがあります。

同じModel Behaviorでも、ArchitectureによってSecurity Outcomeは変わります。

Symptomではなく壊れたSecurity Controlを特定する

良いFindingは、

「AIが変なことをした」

で終わりません。

AIが別User Documentを表示したなら、Root ProblemはRAG Authorizationかもしれない。

AgentがAdmin Operationを実行したなら、Tool Permissionが過剰かもしれない。

APIが別Tenant Objectを返したならObject-Level Authorizationが壊れている可能性がある。

System Promptが見えたとしても、そもそもそこにSecretを置いたArchitectureが問題かもしれない。

Root Security Propertyを特定するとRemediationが強くなります。

SeverityはValidated ExploitabilityとImpactに従う

AIはSeverity Candidateを作ることもできます。

しかしFinal Severityを自動で決めるべきではありません。

誰がExploitできるか。

再現性は高いか。

どのUser / SystemがAffectedか。

High Privilegeが必要か。

Sensitive Dataへ到達するか。

Stateを変更できるか。

別VulnerabilityとChainできるか。

Productionに存在するか。

これらをEvidenceに基づいて評価する必要があります。

AIはManual Testing前のPrioritizationにも使える

Human ValidationはCostが高い作業です。

そのためCandidateすべてを同じ優先度で調査するのは現実的ではありません。

AI自身をSecond-Stage Prioritizationへ使うこともできます。

Unauthenticated Production Endpointに関係するCandidateを上位へ。

Sensitive Dataに関係するAuthorization Candidateを優先。

Unreachable Test CodeのHypothesisは後へ。

こうしたLayered Workflowによって、

Discovery AI。

Ranking Layer。

Human Validation。

Confirmed Finding。

というPipelineを構築できます。

ただしRankingはProofではありません。

優先順位とValidationは明確に分離するべきです。

Duplicate FindingはDeveloperへ送る前にまとめる

AIは同じRoot Causeを複数箇所で発見できます。

一つのBroken Authorization Helperが20 Endpointへ影響している。

AIがそれぞれ別Findingとして報告する。

Developerへ20件のほぼ同じTicketを送るとNoiseが増えます。

成熟したTriageではVulnerability Familyを探します。

同じMissing Controlか。

一つのFixで複数箇所を修正できるか。

本当は一つのArchitectural Defectではないか。

こうしてFinding QualityとEngineering Efficiencyを両方改善できます。

Security Reportに必要なのはAI ConfidenceではなくEvidence

AIが、

「High Confidence」

と言っても、それ自体はSecurity Evidenceではありません。

Engineering Teamが必要とするのは検証可能な情報です。

Affected Component。

Relevant Role / Object。

Reproduction Condition。

Broken Security Boundary。

Observed Impact。

Root-Cause-Oriented Remediation。

Model Confidence Scoreより、実際に確認できるBehaviorの方が重要です。

AIはValidation後のReportingを強くできる

AI-assisted Securityの強みはDetection Volumeだけではありません。

Validationが完了した後、FindingをApplication Contextへ結び付けるのにも役立ちます。

どのRoleが影響を受けるか。

どのWorkflowからAttackできるか。

どのData / CapabilityがExposedするか。

どのSecurity Assumptionが間違っていたか。

こうしたContextを整理することで、Generic Scanner ReportよりDecision-ReadyなSecurity Reportを作れます。

Human ResearcherがEvidenceを提供する。

AIがContext整理を支援する。

この組み合わせが有効です。

Human Review自体がSecurity Controlになる

Human Reviewは、AIが未熟だから一時的に必要なStepというだけではありません。

強力なAutomationを安全に扱うためのControlでもあります。

Researcherは、

Scopeを超えるTestを止める。

必要十分なEvidenceが得られた時点で止める。

Real Customer Dataへ影響するか判断する。

Disclosureに特別なHandlingが必要か判断する。

Confidentだが間違ったModel Reasoningへ反論する。

といった役割を持ちます。

AIが強くなるほどHuman Judgmentが不要になるとは限りません。

よりComplexなFindingへ進むほど、むしろ判断の価値が高まります。

False Negativeも忘れてはいけない

AI Noiseの議論ではFalse Positiveばかり注目されます。

しかしFalse Negativeも重要です。

AIがVulnerabilityを見逃す。

Automated SystemがWorkflowをSafeと誤って判断する。

Code Reviewでは見えないBusiness Logic ProblemがRuntimeで初めて現れる。

そのため、

「AI Scannerで問題が出なかった」

ことを、

「ApplicationにVulnerabilityがない」

という証明にしてはいけません。

AIはCoverageを増やします。

Absolute Security Guaranteeを作るものではありません。

複数種類のEvidenceを組み合わせる

Confidenceを高めるには、一つのModel Explanationへ依存しないことです。

Source AnalysisでMissing Authorization Checkが見える。

Runtime TestでもUnauthorized Requestが成功する。

Role Comparisonで別User ObjectがAccess可能になる。

LogでSuspected Code Pathへ到達していることを確認する。

これらが一致すればFindingは非常に強くなります。

AI AnalysisとDirect Technical Observationを組み合わせるべきです。

Findingを証明するだけでなく反証しようとする

Security Researchで重要なのは、自分のHypothesisに懐疑的になることです。

「どうやってVulnerabilityを証明するか」

だけでなく、

「どうすればこのFindingが間違っていると証明できるか」

も考えます。

別のAuthorization Layerはないか。

Inputは本当にAttacker-Controlledか。

Pathは実行可能か。

Dataは本当にSensitiveか。

Modelが知らないEnvironment Restrictionはないか。

反証を試してもFindingが残るなら、Confidenceは大きく上がります。

AIが説得力のある説明を生成した場合ほど、この姿勢が重要です。

AIはReproductionを支援できるがExploitationには境界が必要

AIはResponse Comparison、Application State Analysis、Minimum Reproduction Conditionの発見などでResearcherを支援できます。

ただしAutonomous Systemへ無制限のExploitationを許可するべきではありません。

一つのAccess-Control Weaknessを発見したからといって、すべてのCustomer RecordをEnumerateする必要はありません。

Resource Exhaustion Candidateを見つけたからといってProduction Outageを起こしてよいわけでもありません。

Reproductionの目的は、

十分なEvidenceでVulnerabilityを証明すること

です。

Professional Security ResearchはControlled Researchであり続けます。

Responsible DisclosureはValidation後に始まる

AIが生成したCandidateを、そのままPublic Vulnerability Announcementにするべきではありません。

最初にValidation。

Affected Maintainerが理解できるEvidence。

Remediationに必要な時間。

Disclosure Timing。

これらが必要です。

AIによるDiscovery Speedが上がるほど、Responsible Disclosure Infrastructureも成熟する必要があります。

Remediation QualityもFinding Qualityの一部

AI FindingがVisible Symptomだけを捉え、Root Causeを誤解していると、Developerは表面的なFixをしてしまいます。

一つのPromptだけBlockする。

一つのEndpointだけCheckを追加する。

一つのInput PatternだけFilterする。

しかしRoot Security Boundaryが壊れたままなら、別Variationで再発します。

Validationでは、

Broken Object Authorization。

Excessive Service Permission。

Missing Tenant Isolation。

Unsafe Tool Authority。

Incorrect Trust Assumption。

Insecure Data Flow。

といった根本Controlを特定することが重要です。

RetestingはValidation Lifecycleの最後の段階

Codeが変更されたことは、Vulnerabilityが直った証拠ではありません。

Attack Pathが本当に消えたか確認する必要があります。

同じUnauthorized Outcomeはまだ可能か。

別Variationから到達できないか。

一つのEndpointだけ修正され、Shared Root Causeが残っていないか。

AI Applicationでは特に、同じPromptが同じResponseを返さなくなっただけでは弱いEvidenceです。

BackendがUnauthorized OperationをDeterministically Rejectするようになった方がはるかに強い証拠です。

Exact InputではなくSecurity PropertyをRetestする

Cross-Tenant Accessが問題だったなら、

RetestするべきPropertyはTenant Isolationです。

別Promptや別RouteでもTenant AがTenant Bへ到達できないか確認する。

Excessive Agent Privilegeが問題なら、

PropertyはTool Authorizationです。

Prompt Wordingが変わってもLow-Privilege UserがRestricted Actionを起こせないか確認する。

Insecure RAG Retrievalなら、

PropertyはAuthorization Before Retrievalです。

Unauthorized DocumentがModel Contextへ入らないことを確認する。

これがDurable Remediationです。

AI時代のVulnerability ManagementにはFinding Funnelが必要

AI DiscoveryがScaleすると、CandidateをそのままEngineeringへ送ることはできなくなります。

必要なのはFunnelです。

大量Candidate。

Low-Confidence / Duplicateの除去。

High-Value HypothesisのManual Reproduction。

ExploitabilityとImpactの評価。

Confirmed FindingをEngineeringへ送る。

Remediation。

Retesting。

この構造がなければ、AIはNoiseをModelからDeveloper Backlogへ移動させるだけです。

最適化すべき指標は「修正されたRisk」

AI Security ProgramのKPIはCandidate数であるべきではありません。

Alert数でもありません。

Generated Report数でもありません。

重要なのは、

どれだけValidated Security Riskを実際に除去できたか

です。

Security Researchの目的はFinding Collectionではありません。

Attack Surface Reductionです。

AI NoiseはVulnerability Management問題になる

Frontier Modelが高度になるほど、既存AppSec Teamが処理できる以上のSecurity Candidateが届く可能性があります。

誰がValidationするのか。

どれを優先するのか。

DuplicateをどうGroup化するのか。

High-Risk FindingをどうEscalateするのか。

誰がMaintainerへ連絡するのか。

Fixをどう追跡するのか。

Retestは誰が行うのか。

こうしたOperational Problemが重要になります。

AI Securityの競争力は、DetectionだけではなくTriage Infrastructureによって決まり始めます。

Security TeamはDeveloperをAI Noiseから守る必要がある

Unverified Findingを大量にDeveloperへ送ると、Security ProgramへのTrustが失われます。

False PositiveにもCostがあります。

存在しないVulnerabilityを調査する時間は、本物のRiskを修正する時間を奪います。

Security TeamはAIのUncertaintyをProduct Teamへ渡す前に吸収する必要があります。

これもProfessional PentestingやSecurity Validationが提供する重要な価値です。

AI Vulnerability Discoveryの未来はVerificationの問題になる

AIは、Human TeamがManualでは調査できないScaleでSoftwareを確認できるようになっています。

今後Discovery自体はさらに安価になる可能性があります。

そこで価値が高まるのがVerificationです。

本当にBugなのか。

Attackerは到達できるのか。

Exploitすると何が得られるのか。

Impactはどれほど大きいのか。

Root Causeは何か。

Fixは正しいか。

RetestingでSecurity Propertyが戻ったか。

こうした質問が、Machine-Generated Security IntelligenceをReal Defenseへ変えます。

Human Security ResearcherはQuality Layerになる

AI Vulnerability Discoveryの未来は、

ModelがPerfect Vulnerability Listを出し、人間が不要になる世界

ではない可能性が高いでしょう。

むしろAIが巨大なTechnical Surfaceを探索し、人間がQuality Layerを提供する世界です。

不可能なHypothesisを捨てる。

現実的なCandidateを再現する。

Attack Pathを追跡する。

Business Contextを理解する。

Exploitationを安全に制御する。

Disclosureを調整する。

Remediationを確認する。

Retestする。

AIのScaleとHuman Evidence Standardを組み合わせることが重要です。

目的は脆弱性の数を増やすことではない

Security Researchの目的は、

「たくさんVulnerabilityを見つけた」

と報告することではありません。

SystemをCompromiseしにくくすることです。

そのため、

Candidate。

Reproduction。

Exploitability。

Impact。

Remediation。

Retest。

というLifecycleが今後さらに重要になります。

AIはVulnerableに見えるものを見つける速度を上げます。

競争力を持つSecurity Teamは、

その中のどれが本当にVulnerableなのかを最も正確に判断できるTeamです。

AI脆弱性発見に関するよくある質問

AIは本当にソフトウェア脆弱性を発見できますか？

はい。現代のAIは実際の脆弱性候補を生成できます。ただし、CandidateはManualまたはIndependent ValidationによってReachability、Exploitability、Impactを確認する必要があります。

AI脆弱性のFalse Positiveとは何ですか？

AI AnalysisではもっともらしいSecurity Problemに見えるものの、Validationすると実際のAttack Pathが成立しないCandidateです。Reachability、Authorization、Attacker Control、Runtime Configurationなどの誤解が原因になることがあります。

AIが発見した脆弱性はどのように検証しますか？

Suspected Conditionを再現し、Realistic Attackerが到達できるか確認し、必要なPrerequisiteを評価し、最終的にMeaningful Security Boundaryが破られるか確認します。

なぜHuman Validationが必要なのですか？

Human ResearcherはApplication Context、Business Logic、Safe Testing Boundary、Realistic Severityを判断できます。またConfidentだがIncorrectなAI Hypothesisを反証できます。

Candidate VulnerabilityとConfirmed Vulnerabilityの違いは何ですか？

Candidateは調査する価値のあるSecurity Hypothesisです。Confirmed VulnerabilityはTechnical ReproductionとSecurity Validationを通じ、実際のSecurity Property FailureがEvidenceによって確認されたものです。

AI CandidateはすべてDeveloperへ報告するべきですか？

いいえ。通常はTriage、Deduplication、Validationを行い、EvidenceのあるFindingだけをEngineeringへ送るべきです。

AI脆弱性のPriorityはどう決めますか？

Validated Exploitability、Attacker Privilege、Affected User / System、Sensitive Data、Attack Chaining、Production Reachabilityなどに基づいて決定するべきです。

高いTrue Positive RateならManual Reviewは不要ですか？

不要にはなりません。BugがRealでも、そのSeverity、Affected Environment、Attack Condition、Business Impact、Remediationは追加評価が必要です。

AIが発見した脆弱性はどうRetestしますか？

元のInputを再生するだけではなく、Underlying Security Propertyが修復されたか確認します。Authorization ProblemならAlternate PathでもUnauthorized Outcomeが発生しないことをテストします。