機械学習システムは、これまでDeterministic Softwareだけが担っていた意思決定へ深く入り込んでいます。

AI Modelは情報を分類し、不正利用を検知し、Malwareや異常なBehaviorを識別し、コンテンツを生成し、さらにAI Agentを通じてSoftwareやBusiness Workflowへ直接Actionを起こすようになっています。

その結果、攻撃者が狙う対象も変化しています。

Application周辺のAPIやAuthenticationだけではありません。

ModelのDecisionそのもの、学習に使われるData、Knowledge Source、Privacy Boundary、そしてGenerative AI Capability自体がAttack Surfaceになります。

この領域が、**Adversarial Machine Learning（敵対的機械学習 / AML）**です。

現在のNISTベースのAML Taxonomyでは、Predictive AIに対する主要な攻撃としてEvasion、Poisoning、Privacyが整理され、Generative AIではさらにMisuseが加わります。重要なのは、AI SecurityをPrompt Injectionだけで説明できないという点です。

Adversarial Machine Learningとは何か

Adversarial Machine Learningとは、攻撃者がMachine Learning Systemの判断を意図的にManipulateしたり、Learning Processへ影響したり、Modelやその背後にあるDataから情報を引き出そうとする攻撃と、その対策を研究する分野です。

Traditional Software Exploitationでは、Broken Access Control、Memory Corruption、Exposed APIなど明確なImplementation Weaknessを探すことが一般的です。

AMLでは、Softwareそのものが正しく動いていても、ModelのDecision Behaviorを攻撃できる場合があります。

ModelはTraining DataからPatternを学び、Inputを処理してOutputを生成します。

Attackerはその関係を理解し、特定のInputやLearning Sourceを操作することで、自分に有利な結果へModelを誘導しようとします。

Traditional CybersecurityだけではAIを十分に守れない理由

従来のCybersecurityが不要になるわけではありません。

AI ModelもServer上で動きます。

APIにはAuthenticationが必要です。

Cloud InfrastructureにはAccess Controlが必要です。

Applicationには通常のVulnerabilityが存在します。

しかしMachine Learningはもう一つのLayerを追加します。

Traditional ApplicationはDeveloperが明示的に書いたRuleを実行します。

Machine Learning ModelはDataとLearned ParametersからBehaviorを形成します。

つまり、

DataそのものがSecurity Surfaceの一部になります。

Security TeamはApplicationだけではなく、Model Lifecycle全体をThreat Modelする必要があります。

AI LifecycleによってAttack Surfaceが変わる

AMLを理解するうえで重要なのは、AttackerがいつSystemへ影響するかです。

Deployment後のInference TimeでInputを操作する攻撃があります。

TrainingやFine-TuningのDataを事前に汚染する攻撃もあります。

Modelを変更するのではなく、Modelが知っている情報を推測・抽出するPrivacy Attackもあります。

さらにGenerative AIでは、Modelを壊すのではなく、正しく動作するCapabilityを悪意ある目的へ利用するMisuseも重要になります。

Attack Timingが違えばRemediationも変わります。

Inference Inputを除去すれば問題が消える場合もあります。

一方Training DataがPoisoningされていれば、Attacker Accessが消えた後もBehaviorが残る可能性があります。

Evasion Attack：Inference時にModelを誤判断させる

Evasion Attackは、すでにDeploymentされたModelに対し、Inference TimeのInputを操作して誤ったDecisionを引き起こす攻撃です。

Model自体を変更する必要はありません。

Attackerは、Modelが学習したDecision Boundaryを特定し、それをUnexpectedな形でCrossさせるInputを探します。

Softwareは正常に動いている。

ModelもErrorを返していない。

それでも最終的なSecurity Decisionが間違う。

これがEvasionの本質です。

Modelを変更せずInputだけをManipulateする

たとえばMachine Learning ClassifierがIncoming Contentを分類しているとします。

通常は正しくMalicious / Benignを識別します。

しかしAttackerがInputの特徴を慎重に変更し、Modelに別Classとして判断させられれば、Model自体をCompromiseしなくてもSecurity ControlをBypassできる可能性があります。

Traditional PentesterがAuthentication Functionを直接Bypassしようとするのに対し、AML Researcherは、

AuthenticationやDetectionが依存しているModelを誤分類させられないか

を調査します。

Security BoundaryがModel Decisionの中に存在するためです。

EvasionはComputer Visionだけの問題ではない

Adversarial ExampleはImage Classificationと関連付けられることが多いですが、Evasionの概念ははるかに広いものです。

Model Decisionが重要なWorkflowへ影響する場所では、どこでも問題になり得ます。

Fraud Detection。

Spam Filtering。

Malware Classification。

Anomaly Detection。

Content Moderation。

Identity-Related Models。

Generative AI Application。

重要なのは具体的なTechniqueではありません。

ApplicationがModel Outputを絶対に正しいとAssumeしているかどうかです。

Model ConfidenceはSecurityの証明にならない

Modelが99% ConfidenceでDecisionを出したとしても、それはInputがLegitimateであることを証明しません。

ConfidenceはModel内部のPrediction Processを表す指標です。

Attacker-Controlled Inputに対して、Modelが非常に高いConfidenceで間違う可能性もあります。

Security-Sensitive DecisionをMachine Learningへ依存する場合、

Modelが間違ったときでもSystemが安全か

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

これはTraditional Cybersecurityと同じDefense in Depthの考え方です。

Poisoning Attack：Modelが学習する情報を汚染する

EvasionがDeployment済みModelのDecisionを攻撃するのに対し、PoisoningはModel Behaviorを形成するLearning ProcessやTrusted Information Sourceへ影響します。

Attackerの目的は、一回だけModelを騙すことではありません。

将来のBehaviorそのものへ影響することです。

Training DataはSecurity Asset

Modern Machine Learningは大量のDataに依存します。

Security TeamがProduction Modelだけを守り、Training Pipelineを単なるData Engineering Problemとして扱うのは危険です。

AttackerがTraining Data、Fine-Tuning Data、Feedback、その他Learning SourceへInfluenceできれば、Production Modelが学習するBehaviorを変えられる可能性があります。

そのためAI Data PipelineはSoftware Supply Chainに近いものとして扱う必要があります。

どこからDataが来るのか。

誰が変更できるのか。

何がTrusted Sourceなのか。

どのUpdateがReviewされるのか。

これらはSecurity Questionです。

Data Poisoningは大規模でもTargetedでも起こる

Poisoning Attackは必ずしもModel全体のPerformanceを壊す必要はありません。

単純な攻撃ならAccuracyを大きく低下させます。

しかしより高度なPoisoningでは、通常のEvaluationではModelを正常に見せながら、特定のConditionだけでAttackersに有利なBehaviorを引き起こす可能性があります。

これは非常に重要です。

Average Accuracyが高くても、

特定のAttacker-Controlled Scenarioに対するSecurity Robustnessが高いとは限りません。

だからAML TestingではAverage BenchmarkだけでなくThreat Scenarioを見る必要があります。

RAG Knowledge Poisoning

Retrieval-Augmented Generationにも、Poisoningと似たIntegrity Riskがあります。

Foundation Model自体を変更する必要はありません。

AttackerがKnowledge BaseやDocument SourceへMalicious / Misleading Contentを挿入できれば、後のRAG Retrievalを通じてModel Contextへ影響できます。

Userには、

「AIがKnowledge Baseから正しい情報を取得している」

ように見えます。

Securityの観点では、そのKnowledge Base自体がDecision Pipelineの一部です。

RAG Securityでは、Training Dataと同じようにInformation Supply Chainを考える必要があります。

Data Provenanceが重要になる

Poisoning Riskに対する強いDefenseの一つは、DataのOriginを明確にすることです。

どのDatasetがAuthoritativeなのか。

External Sourceを使っているのか。

誰がInternal Dataを変更できるのか。

User Feedbackが自動的にLearningへ入るのか。

RAG Documentを誰がPublishできるのか。

SourceごとにTrust Levelは違います。

Security Architectureでは、それを一つの「Data」としてFlatに扱うべきではありません。

Privacy Attack：Modelが知っている情報を狙う

すべてのAdversarial AttackがModelを誤判断させるわけではありません。

Privacy Attackの目的はInformationです。

Attackerが知りたいのは、

「どうすればPredictionを変えられるか」

ではなく、

「このModelはSensitive Dataについて何を明らかにできるか」

です。

Training Data、Fine-Tuning Information、Runtime Context、Model Behaviorなどが関係します。

Machine LearningがInformation Side Channelになる可能性

UserがTraining Datasetへ直接Accessできないからといって、そのInformationが完全に守られているとは限りません。

ModelとのInteraction自体がInformation Interfaceになる可能性があります。

AttackerはDatabase Credentialを盗まなくても、

Queryを繰り返し、

Responseを比較し、

Model Behaviorを分析することで、

Sensitive Informationに関するSignalを得ようとする場合があります。

FeasibilityはModel Architecture、Attacker Access、Information Typeによって大きく変わります。

したがってPrivacy RiskはAssumeするのではなくThreat Modelするべきです。

Training Data PrivacyとRuntime Data Leakageは別問題

「AI Data Leakage」という一つの言葉で全部をまとめるとRemediationを間違える可能性があります。

Training DataからInformationが推測できる問題。

Prompt、RAG、Connected ToolからRuntime Dataが漏れる問題。

これは違うSecurity Layerです。

たとえばLLM Assistantが別CustomerのRecordをRAG経由で取得して表示した場合、問題のRoot Causeは高度なAML Privacy Attackではなく、

Broken Authorization / Tenant Isolation

かもしれません。

Training PrivacyならData PracticeやModel Developmentを見直します。

Runtime LeakageならApplication Authorizationを修正します。

Privacy Testingは必要最小限のEvidenceで行う

Privacy Testing自体がSensitive Dataを扱う可能性があります。

そのためControlled Scopeが重要です。

Security Assessmentの目的は大量のReal Customer Dataを収集することではありません。

一つのControlled Test RecordでConfidentiality Boundaryの失敗を証明できるなら、それ以上のExtractionは通常必要ありません。

Professional Testingでは、

Impactを証明し、不必要なData Exposureを避ける

という原則が重要です。

Misuse Attack：Modelが正しく動作していても危険になる

Generative AIではMisuseという別のCategoryが重要になります。

MisuseではModelが壊れている必要がありません。

ModelはDeveloperの設計どおり正しく動いている。

問題は、そのCapabilityをUserが悪意ある目的へ利用することです。

MisuseはCapability Governanceの問題

Traditional Cybersecurityでは、

「UserがUnauthorized Operationを実行できるか」

が中心になります。

MisuseではUserがModelへLegitimate Accessを持っていても問題が起こります。

そこで重要なのは、

誰がSystemを使えるか。

どのCapabilityがAvailableか。

ModelがどのDataへAccessできるか。

AgentはどのToolを呼べるか。

どんなMonitoringがあるか。

どのActivity Levelで追加ControlをTriggerするか。

といったCapability Governanceです。

すべてのAI RiskがConventional Vulnerabilityから生まれるわけではありません。

強力なCapabilityが存在すること自体がRiskになります。

MisuseとExcessive Agencyは組み合わせると危険になる

Text-Only ModelのMisuseと、Agentic SystemのMisuseではImpactが違います。

Text ModelはInformationを生成します。

AgentはToolを使ってActionを実行できます。

つまりRiskは、

Model Capability

×

Application Authority

によって増幅されます。

AIに不要なTool、Credential、Permissionを与えると、MisuseのImpactも大きくなります。

したがってSecurity Teamは、

UserはModelを悪用できるか。

そのInteractionからArchitecture上どこまでReachできるか。

を別々に評価する必要があります。

Adversarial MLとPrompt Injectionの違い

Prompt Injectionは非常に重要ですが、AML全体では一部にすぎません。

Prompt Injectionは主に、LLM ApplicationのRuntime BehaviorへAdversarial Instructionで影響する問題です。

Evasionはより広いInference-Time Manipulationです。

PoisoningはLearning / Knowledge Sourceを狙います。

PrivacyはSensitive Informationの抽出・推測を狙います。

MisuseはGenerative Capabilityを望ましくない目的へIntentionalに利用する問題です。

すべてを「Prompt Hacking」と呼ぶと、修正すべきSecurity Controlを間違える可能性があります。

Adversarial MLと通常のVulnerability Exploitation

Traditional ExploitationはImplementation Flawを狙うことが多く、Behaviorは比較的Deterministicです。

同じBroken API Authorization Requestを送れば、毎回別UserのObjectが返る。

AMLではModel Version、Input Variation、System State、Probabilistic BehaviorによってResultが変わる場合があります。

そのため一つのExact Inputだけに過度に依存したTestingは弱い場合があります。

研究者は、

どのSecurity Propertyが壊れているのか

を明確にするべきです。

Attacker KnowledgeでThreat Modelが変わる

Attackerは全員同じ情報を持っているわけではありません。

Internal ResearcherはArchitectureやTraining Procedureを知っている。

External AttackerはAPI Responseしか見えない。

Model ParameterへAccessできるActorもいれば、Repeated QueryだけでBehaviorを推測するActorもいます。

Knowledge LevelによってAttack Feasibilityは変わります。

Security Assessmentは、

「Attackerはすべて知っている」

または

「Attackerは何も知らない」

と極端にAssumeするのではなく、Realistic ActorをModelする必要があります。

Attacker Capabilityも同じくらい重要

KnowledgeだけでRiskは決まりません。

一回しかInputを送れないのか。

Millions of Queriesが可能なのか。

Training Dataを変更できるのか。

RAG DocumentをPublishできるのか。

Authenticated Accessがあるのか。

Confidence Scoreまで見えるのか。

Feedback LoopへInfluenceできるのか。

これらによってAttack Surfaceは大きく変わります。

TestingもReal Attacker Capabilityへ合わせる必要があります。

Adversarial Machine LearningはThreat Modelingの問題

有効なAML Assessmentは、最初から大量のAdversarial Exampleを投げることではありません。

まずArchitectureを理解します。

どのModelを使っているか。

Dataはどこから来るか。

誰がTraining / FeedbackへInfluenceできるか。

どのBusiness DecisionがModelへ依存しているか。

どんなSensitive Dataが関係するか。

Toolへ接続されているか。

Modelが間違ったら何が起こるか。

重要なのは、

Machine LearningがFailureすることを証明することではありません。

複雑なModelは特定条件で必ず失敗します。

Security Assessmentの目的は、

Attackerが意図的にSecurity-Relevant Failureを起こせるか

を確認することです。

Evasion Testingの考え方

Evasion Testingは、まずSecurity-Sensitive Decisionを特定するところから始めます。

Cosmetic UI Classificationが間違うことと、

Fraud DetectionやAccess Decisionが間違うことではImpactが違います。

次に、Authorized Test Environment内でAttacker-Controlled InputがDecisionへSystematicに影響するか確認します。

重要な質問は、

AttackがReliableか。

どのAccessが必要か。

Application側にAdditional Controlがあるか。

Abnormal BehaviorをDetectできるか。

です。

目的はModelを最大限Confuseすることではありません。

Adversarial Input下でSecurity Robustnessを測ることです。

Poisoning Riskの評価方法

PoisoningはLifecycleの前段階を調査します。

誰がTraining Informationを追加できるか。

External Datasetは何か。

Model UpdateはAutomaticか。

Feedback LoopがLearningへ影響するか。

Low-Trust UserがKnowledge Repositoryを変更できるか。

これらが分からなければ、Organizationは自分のAI Supply Chainを十分に理解していない可能性があります。

Conventional PentestとAI Governanceが交わる場所でもあります。

たとえばTraining Pipeline AccountのCompromiseはTraditional Cybersecurity Issueです。

そのAccessを利用してFuture Model Behaviorを変えればAML Problemになります。

Privacy Testingの考え方

Privacy Testingでは、どのSensitive InformationがModelまたはRuntime Environmentと関連するかをMapします。

Training Information。

Application Context。

RAG Data。

Tool Response。

これらを分離して考えます。

Unauthorized Userが何をInferまたはRetrieveできるかを確認します。

Enterprise LLM Applicationでは、Traditional Access Controlが非常に強力なPrivacy Defenseになることも多くあります。

Unauthorized DataがUser Model Contextへ入らなければ、多くのRuntime Disclosure Pathは最初から消えます。

Misuse Riskの評価方法

Misuse AssessmentではCapability Analysisから始めます。

Generative Systemは何を生成できるか。

誰が利用できるか。

User GroupごとにCapability Levelは違うか。

どのExternal SystemがConnectされているか。

Monitoringはどれくらいあるか。

すべてをModel内部のGuardrailだけで解決する必要はありません。

Architectureによっては、

Access Control。

Rate Limit。

Tool Restriction。

User Verification。

Anomaly Monitoring。

Environment Isolation。

の方が効果的な場合があります。

重要なのは、

一つのProbabilistic ModelへSecurity Architecture全体を背負わせないことです。

AMLを一つのMitigationだけで解決できない

Adversarial Machine Learningには万能なDefenseがありません。

Evasion Defenseを強化してもPoisoning Riskは残ります。

Training Data Governanceが強くてもRuntime Privacy Leakageは残る可能性があります。

Prompt-Injection Filterを追加しても、Overprivileged Agent ToolがUnauthorized Actionを実行できるなら問題は残ります。

つまりTraditional Cybersecurityと同様にDefense in Depthが必要です。

Attack SurfaceごとにControlを分ける必要があります。

AI Security TestingはNoveltyではなくImpactを見る

AML Researchでは非常に興味深いModel Failureを発見できます。

しかしSecurity Assessmentではもう一段階必要です。

そのFailureはProductに実際のImpactを与えるのか。

奇妙なClassifier OutputはAcademicには面白くてもSecurity Severityは低いかもしれません。

一方、Security-Critical DetectionをReliableにBypassできるならOperational Impactがあります。

Generative ModelがUnexpected Textを出すだけならLow Severityかもしれません。

Manipulated AgentがPrivileged Toolを使えるならHigh Severityになり得ます。

FindingはNoveltyではなく、

Exploitability。

Attacker Capability。

Business Consequence。

によってPrioritizeするべきです。

AML FindingのRetesting

Remediation後のRetestでは、Exact InputだけをBlockしたかどうかを見るべきではありません。

一つのEvasion SampleだけBlack Listに入れても、Underlying Robustnessが改善していないかもしれません。

Poisoned Documentを一つ削除しても、誰でもKnowledge RepositoryへPublishできる状態ならRoot Causeは残ります。

Broad RAG Authorizationが原因のPrivacy Exposureなら、Promptを変更してもData Access Problemは直りません。

Strong Retestでは、

Original Attacker Capabilityが合理的なVariationを使って同じSecurity Outcomeをまだ起こせるか

を確認します。

Adversarial MLとPenetration Testingは融合していく

AIはProduction Softwareの普通のComponentになりつつあります。

その結果、AMLとTraditional Pentestingを完全に別分野として扱うことは難しくなっています。

Pentesterが、

「このAccess WorkflowはAI Classifierへ依存している」

と発見する。

AML Researcherが、

「ModelをManipulateできるが、実際のImpactを理解するにはAPI Authorizationを確認する必要がある」

と判断する。

LLM Red TeamがAgentをManipulateしても、Tool Callが本当にAuthorizedかをAppSec Perspectiveで確認する。

Attack Pathは複数DisciplineをCrossします。

Modern AI Security Testingでは、

Model-Aware Adversarial Testing + Traditional Application Security

の両方が必要です。

AMLの未来はModel Robustnessだけではない

Adversarial AI Securityは、初期の「小さく加工されたAdversarial Input」の世界から大きく広がっています。

これからSecurity Teamが見る必要があるのは、

Data Integrity。

Model Behavior。

Retrieval。

Privacy。

Tools。

Permissions。

Autonomy。

です。

重要な質問は、

「ModelはRobustか？」

だけではありません。

「Learning Systemの一部が意図的にManipulateされても、AI-enabled Application全体はSecureであり続けるか？」

です。

敵対的機械学習に関するよくある質問

Adversarial Machine Learningとは何ですか？

攻撃者がMachine Learning SystemのBehavior、Learning Process、Data、またはPrivacy Boundaryへ意図的に影響する攻撃と、その対策を扱うSecurity分野です。

主なAML Attackには何がありますか？

Predictive AIではEvasion、Poisoning、Privacyが主要Categoryです。Generative AIではさらにMisuseが加わります。

Evasion Attackとは何ですか？

Deployment済みModelへInference-Time Inputを与え、Model自体を変更せずAttackerに有利なDecisionを引き起こそうとする攻撃です。

Poisoning Attackとは何ですか？

Training、Fine-Tuning、Feedback、Knowledge SourceなどModel Behaviorを形成する情報へInfluenceし、将来のBehaviorをManipulateする攻撃です。

AI Privacy Attackとは何ですか？

ModelやそのInteractionからSensitive Data、Training Information、Runtime InformationなどをInferまたはRetrieveしようとする攻撃です。

Generative AI Misuseとは何ですか？

Modelを壊すのではなく、正しく利用可能なGenerative Capabilityを意図的に望ましくない目的へ使用することです。

Prompt InjectionとAMLは同じですか？

いいえ。Prompt Injectionはより広いAdversarial AI Landscapeの一部です。AMLにはEvasion、Poisoning、Privacy、Misuseなども含まれます。

AML TestingとPentestの違いは何ですか？

Traditional PentestはSoftware、Infrastructure、Authentication、Business LogicなどのWeaknessを中心に検証します。AMLはさらにModel Behavior、Learning Process、Information IntegrityやPrivacyを攻撃者がManipulateできるか評価します。Modern AI Securityでは両者を組み合わせる必要があります。