Anthropic MythosとProject Glasswing:Frontier AIは防御型サイバーセキュリティをどう変えるのか

Anthropic MythosとProject Glasswing:Frontier AIは防御型サイバーセキュリティをどう変えるのか

サイバーセキュリティは長い間、一つの希少なリソースによって制限されてきました。

高度な専門知識を持つセキュリティ研究者の時間です。

現代のソフトウェアには、数百万行規模のコード、大量の依存関係、クラウドインフラ、API、認証システム、サードパーティ統合、そして継続的なアップデートが含まれています。

経験豊富な脆弱性研究者であっても、そのすべてを深く調査することはできません。

Frontier AIは、この構造を変え始めています。

AnthropicのClaude MythosシリーズとProject Glasswingは、高性能AIを単なるCoding Assistantとしてではなく、実際の脆弱性発見、セキュリティ検証、パッチ支援、リリース前レビューに利用する方向性を示す代表的な事例です。

ShabuShabuの元記事では、Claude Mythos PreviewとProject Glasswingが2026年4月7日に発表され、その後Mythos 5へ発展した流れを、防御型サイバーセキュリティの大きな転換点として扱っています。

重要なのは、一つのAIモデルの性能だけではありません。

AIがこれまで人間の研究者に大きく依存していたSecurity Reasoningへ参加できるようになると、脆弱性研究そのものの経済性が変わります。

Bugを見つける速度が上がる。

しかし同時に、新しい問題が生まれます。

そのFindingは本物なのか。

実際に攻撃可能なのか。

誰が検証するのか。

Maintainerへどう伝えるのか。

Patchをどう作るのか。

修正後のAttack Pathを誰がRetestするのか。

Discoveryが速くなれば、ValidationとRemediationも同じ速度で進化しなければなりません。

Claude Mythosとは何か

Claude Mythosは、Anthropicが高度なサイバーセキュリティ能力をTrusted Accessのもとで提供するために開発しているFrontier Model系統です。

元記事によると、最初に公に説明されたClaude Mythos Previewは2026年4月に登場し、特にVulnerability DiscoveryやSecurity Researchにおいて非常に強い能力を持つモデルとして位置付けられました。

ここで重要なのは、Mythosを単純なAutomated Vulnerability Scannerとして理解しないことです。

従来型Scannerの多くは、

既知のSignature、

危険なPattern、

特定CVEに関連するVersion、

事前定義されたWeakness Class

を探します。

Frontier Modelが興味深いのは、それより広いReasoningへ参加できる可能性がある点です。

未知のCodebaseを読む。

Function間のRelationを追跡する。

Developerが暗黙的に信頼しているAssumptionを見つける。

複数Componentを横断してAttack Pathを考える。

一見安全に見える処理が、別のWorkflowからBypassできないか調査する。

これはScannerというより、Security ResearcherのWorkflowに近いものです。

Mythosが一般公開型Cybersecurity Modelではない理由

高度なサイバー能力には明確なDual-Use Problemがあります。

Defenderが未知のVulnerabilityを理解するために役立つ能力は、Attackerが同じVulnerabilityをExploitするためにも利用できます。

Security ResearcherがAttack Pathを再現するためのReasoning Capabilityは、悪意あるActorが攻撃を構築する際にも利用できます。

そのためAnthropicはMythos級のCapabilityを、通常のGeneral-Purpose Modelと同じ形で無制限公開するのではなく、Trusted-Access Programの中で扱う方向を採用しています。

元記事では、2026年8月19日時点でMythos 5は一般的なUnrestricted Public Modelではなく、限定されたTrusted Cybersecurity Users向けとして説明されています。

これはFrontier Cybersecurity AI全体にとって重要なテーマです。

Capabilityが高まるほど、

Model-Level Safeguardだけでなく、

Identity Verification、

Access Control、

Monitoring、

Capability Restriction、

Disclosure Governance

も重要になります。

Project Glasswingとは何か

Project Glasswingは、Anthropicが高度なAI Cybersecurity Capabilityを実際の防御へ利用するために立ち上げたInitiativeです。

目的は単純なBenchmark競争ではありません。

Frontier Modelを実際の大規模Softwareへ適用した場合、何が起きるのかを検証することです。

Real SoftwareはSecurity Benchmarkより複雑です。

Codebaseは巨大です。

Documentationは不完全です。

Legacy Assumptionが残っています。

複数Dependencyが複雑にInteractionします。

一つのSuspicious Functionが実際にはReachableではないこともあります。

逆に、一つずつ見ると安全な複数Componentが組み合わさったときだけCritical Attack Pathが生まれることもあります。

Glasswingが重要なのは、AI CybersecurityをSynthetic EvaluationからReal Vulnerability Researchへ近づけている点です。

Mythos PreviewからMythos 5へ

AnthropicのCybersecurity Programは2026年春から急速に進展しました。

元記事では、Mythos Previewの発表後、6月9日にClaude Mythos 5が発表され、Project GlasswingやTrusted Access Programを通じて限定的に提供される形へ進んだ流れを説明しています。

このEvolutionは、Frontier Cybersecurity Modelにおける非常に重要な問題を示しています。

モデルの能力が高まるほど、防御価値も上がります。

同時にMisuse Potentialも上がります。

つまり将来のAI Cybersecurityでは、

「どのモデルが最も強いか」

だけではなく、

「誰が、どの条件で、そのCapabilityへアクセスできるか」

がSecurity Architectureの一部になります。

Frontier AIが脆弱性発見に重要な理由

Software Vulnerabilityは、

「ここが脆弱です」

とLabelされているわけではありません。

Researcherは、

Programが本来どう動くべきか、

実際にはどう動くか、

Attackerがその差をSecurity Impactへ変えられるか

を推論しなければなりません。

あるComponentはInput Validationを別Layerへ依存しているかもしれません。

Authorization Checkは存在するが、すべてのExecution PathをCoverしていないかもしれません。

Memory SafetyのAssumptionが特定Sequenceでだけ壊れる場合もあります。

一つのFunctionだけを見るとSecureでも、別WorkflowからPrivilege Boundaryを迂回できる可能性もあります。

こうした問題は、単純なPattern Matchingでは十分に扱えません。

Contextual Reasoningが必要です。

Frontier AIがCybersecurityで重要になるのは、このLayerへ参加し始めているからです。

AIは人間だけでは調査できない量のCodeを探索できる

非常に優秀なSecurity Researcherでも、一日に使える時間は有限です。

一方、大企業やOpen-Source Ecosystemには膨大な量のSoftwareがあります。

重要なDependencyでも、何年も深いSecurity Reviewを受けていない場合があります。

AIはこのScaleを変えられます。

大量のCode Pathを確認する。

Candidate Vulnerabilityを生成する。

Suspicious Assumptionを比較する。

その中からHuman Researcherが優先的に調査すべきCandidateを提示する。

元記事では、Project Glasswingの初期結果について、Anthropicとおよそ50の初期PartnerがMythos Previewを利用し、重要なSoftware全体から1万件を超えるHighまたはCritical Severity CandidateをSurfaceしたと報告された点を取り上げています。

同時にAnthropicは、Human VerificationとRemediationが新たな制約になったことを強調しています。

重要なのは、

「AIが1万件見つけたから1万件すべて本物」

ということではありません。

むしろ逆です。

Candidate Generationが高速になるほど、Triage Qualityが重要になります。

Candidate VulnerabilityとConfirmed Vulnerabilityは違う

Responsible AI Security Researchで最も重要な原則の一つです。

AIがSuspicious Patternを見つけても、それだけでReal Vulnerabilityとは言えません。

Affected FunctionがExternal InterfaceからReachできないかもしれない。

別Authorization LayerがAttackをBlockしているかもしれない。

ConfigurationによってVulnerable Conditionが発生しないかもしれない。

ModelがImplementationを誤解しているかもしれない。

そのためHuman Validationが必要です。

元記事では、AnthropicのCoordinated Vulnerability Disclosure Processでも、Mythos CandidateをExternal Security ResearcherがReviewし、人間による確認を経たFindingをMaintainerへのDisclosureへ進める仕組みが説明されています。

AIがDiscoveryをScaleさせる。

ResearcherがRealityを確認する。

この役割分担が重要です。

ボトルネックはDiscoveryからVerificationへ移る

長い間、Cybersecurityでは、

「十分なVulnerabilityを見つけられない」

ことが大きな問題でした。

Frontier AIが強くなると、その問題は変わります。

Candidateを作ること自体は容易になる。

しかし、それを誰が処理するのか。

Reachableか。

Reproducibleか。

Exploitableか。

Business Impactは何か。

Disclosureすべきか。

Fixは正しいか。

こうした確認が新しいBottleneckになります。

つまり、AIによってDiscovery Capacityだけを増やしても、Security Program全体が自動的に良くなるわけではありません。

Validation。

Disclosure。

Patching。

Retesting。

これらが同じようにScaleしなければ、BottleneckがDownstreamへ移動するだけです。

Discoveryが安くなるほどVerificationの価値が高くなる

Candidate Vulnerabilityが豊富になるほど、Experienced Researcherの価値は下がるのではなく変化します。

以前は多くの時間をFinding Searchに使っていました。

将来は、

Candidateが本物か確認する。

必要条件を理解する。

Attack Pathを再現する。

Real User Impactを評価する。

False Positiveを素早く排除する。

といった仕事の比重が増えるでしょう。

AI Security Programに必要なのは単なるCandidate Countではありません。

高品質なValidation Pipelineです。

Coordinated Vulnerability Disclosureはより重要になる

未知のVulnerabilityは非常にSensitiveな情報です。

Patchが存在する前にTechnical Detailを公開すれば、UserがRiskにさらされる可能性があります。

一方で、永遠にPrivateにすればMaintainerは修正できません。

そこで必要になるのがCoordinated Vulnerability Disclosureです。

AIによってCandidate Volumeが増えれば、DisclosureをAd-HocなEmail Processだけで処理するのは難しくなります。

FindingのValidation。

Maintainerへの通知。

Patch Development。

Advisory。

User Update。

Retesting。

これらを支えるInfrastructureもDiscovery Speedに合わせてScaleする必要があります。

Frontier AIはPatch Developmentも支援できる

防御型Cybersecurityでは、Vulnerabilityを見つけるだけでは意味がありません。

最終的にはSoftwareを直す必要があります。

Project Glasswingでは、Mythos PreviewがFinding Discoveryだけでなく、Patch作成支援やPre-Release Security Checkにも利用されていると元記事は説明しています。

理想的なWorkflowは、

AIが数千件Reportを投げる。

Engineering Teamが処理できずBacklog化する。

という形ではありません。

より良いFlowは、

AIがCandidateを発見する。

Human ResearcherがValidateする。

AIがAffected Codeの理解を支援する。

EngineeringがFixを作る。

AIがRelated Code Pathを探す。

Security TeamがRetestする。

というClosed Defensive Loopです。

AIはSecurityをDevelopmentの早い段階へ移せる

最も価値の高いFrontier Cybersecurity AIの使い方は、ProductionでVulnerabilityを見つけることではないかもしれません。

Release前に見つけることです。

Pre-ReleaseでArchitecture Problemを発見できれば、修正は比較的簡単です。

同じ問題をProduction Launch後に発見すると、

Emergency Patch。

Customer Communication。

Incident Investigation。

Migration。

Backward Compatibility。

などのOperational Costが増えます。

AI-Assisted ReviewによってSecurity ReasoningをDevelopment Lifecycleの早い段階へ入れることは、長期的に非常に大きな価値があります。

AI-Assisted Penetration Testing

Mythos級のModelはAuthorized Penetration Testingでも活用できます。

Large Applicationの構造を理解する。

Suspicious Attack Surfaceを探す。

複数FindingのRelationを考える。

CodeとRuntime Behaviorを比較する。

しかしAIを使うからといってRules of Engagementが変わるわけではありません。

Authorizationは必要です。

Scopeは必要です。

Third-Party Systemを無断でTestしてはいけません。

Production Safetyも必要です。

必要十分なEvidenceが得られた時点で停止する判断も必要です。

AIはAnalysisのSpeedとBreadthを変えます。

Testing Permissionを拡張するものではありません。

Mythos級Cybersecurity AIがDual Useである理由

CybersecurityではDefenseとOffenseのSkillが大きく重なります。

Vulnerabilityを理解する能力はDefenderのPatchに役立ちます。

同じ理解はAttackerのExploitにも使えます。

Compromised EnvironmentでAttack Pathを再現するSkillはBlue TeamにもRed Teamにも利用できます。

だからこそ、Capability Governanceが重要になります。

高度なCybersecurity AIを安全にDeploymentするには、

Model Safeguard。

User Verification。

Access Control。

Monitoring。

Capability Restriction。

Disclosure Process。

を組み合わせる必要があります。

一つのRefusal Behaviorだけに依存する設計では不十分です。

Deployment PolicyもFrontier AI Securityの一部

元記事では、Mythos 5へのAccessが2026年6月に一時停止され、その後7月1日に承認された米国組織向けへ復旧した経緯も扱っています。

この事例は、Frontier AIのAvailabilityが純粋なTechnical Readinessだけでは決まらないことを示しています。

Regulation。

Export Control。

Access Policy。

Safety Requirement。

User Verification。

これらもDeployment Modelに影響します。

将来のCybersecurity AIでは、Capability ManagementとPolicy Managementがますます密接になるでしょう。

Project Glasswingが示すSecurity Researchの未来

Glasswingで最も興味深いのは、一つのModelよりWorkflowです。

AIがCandidate Weaknessを大量に探す。

Human ResearcherがValidateする。

MaintainerへCoordinated Disclosureする。

AIがPatch作成を支援する。

Release前にもSecurity Checkを行う。

Modelが単体Scannerではなく、より大きなSecurity Infrastructureの一部になる。

この方向性は、従来のVulnerability Managementを大きく変える可能性があります。

将来の問題はVulnerability Throughputになる

Security Teamはこれまで、

「何件のVulnerabilityを見逃しているか」

を気にしてきました。

Frontier AIは別の質問を生みます。

「何件のVulnerabilityを現実的に処理できるか?」

AIが数千件Candidateを発見しても、

ResearcherがTriageする必要があります。

Maintainerが理解する必要があります。

DeveloperがPatchする必要があります。

CustomerがUpdateする必要があります。

DiscoveryだけをScaleしてもDefenseは完成しません。

Vulnerability Lifecycle全体をScaleする必要があります。

Human Researcherの重要性はむしろ高くなる

強力なAI Modelが登場すると、

「Pentesterは不要になる」

と考えたくなるかもしれません。

実際にはRoleが変わります。

Candidateが少ない時代にはResearcherが長時間Searchします。

Candidateが大量にある時代には、

Realか。

Reachableか。

どのPermissionが必要か。

別UserへImpactするか。

Minimal Evidenceは何か。

どうDisclosureするか。

Patchで本当にAttack Pathが消えたか。

を判断する仕事が増えます。

これにはSecurity Judgmentが必要です。

Frontier AIでもFalse Positiveはなくならない

Reasoning Capabilityが高くても、ModelはPerfectではありません。

Codeを誤解する。

存在しないAttacker Controlを推論する。

Configuration Restrictionを見落とす。

実行不可能なAttack Pathを非常に説得力のある文章で説明する。

こうしたことは起こり得ます。

そのためRaw AI OutputをそのままCustomer-Facing Pentest Reportへ入れるべきではありません。

Discovery Methodが、

Manual、

Conventional Automation、

AI-Assisted

のどれであっても、

Evidence Standardは同じであるべきです。

Severityは実際のImpactで決める

AIが面白いSecurity Conditionを見つけたとしても、Severityは実際の結果で決まります。

Highly Privileged Local AdministratorだけがReachできるBugと、

Unauthenticated Remote Userが利用できるBugではRiskが違います。

Minor Information Disclosureと、

Cross-Tenant Customer Account AccessでもRiskが違います。

Modelは分析を支援できます。

Final SeverityはApplication Contextに依存します。

Open-Source Securityへの大きな可能性

Open-Source SoftwareはAI-Assisted Securityの大きなOpportunityです。

広く利用されている一つのLibraryが、何百万ものDownstream Productへ組み込まれている場合があります。

一方Maintainerは少人数かもしれません。

AIによって、これまでSecurity Reviewを受けられなかったProjectへより深いAnalysisを提供できる可能性があります。

しかしDiscoveryだけ大量に増やしてMaintainerへReportを投げ続ければ逆効果です。

必要なのは、

Usable Report。

Patch。

Prioritization。

Validation。

UserがUpdateできる時間。

です。

Open-Source Securityの未来も、Model CapabilityだけでなくRemediation Infrastructureに依存します。

Frontier AIはDefenderの時間的優位を短くする可能性がある

AI CapabilityはDefenseだけのものではありません。

長期的にはAttackerも同種のReasoning能力へアクセスする可能性があります。

Software Release後のCode Analysis。

Patch Diff。

Vulnerability Hypothesis。

Attack Path Construction。

こうした作業が高速化すれば、

「複雑だからすぐにはExploitされない」

という考え方は弱くなります。

だからこそSecure DevelopmentとPre-Release Testingの価値が上がります。

AIが強くなるほどSecure-by-Designが重要になる

将来AIがVulnerabilityをすべて探してくれるから、

Architectureを完璧にする必要はない

と考えるのは危険です。

良い戦略は逆です。

Strong Authorization。

Least Privilege。

Input Validation。

Explicit Security Boundary。

Dependency Maintenance。

High-Risk ReleaseのAdversarial Testing。

こうした基本へAI-Assisted Detectionを組み合わせるべきです。

AIはMistakeを見つける可能性を高めます。

良いArchitectureは、そもそもMistakeの数を減らします。

Patch CapabilityもScaleしなければならない

未来のCybersecurity AI Systemは、

「Vulnerabilityを見つけました」

だけでは終わらない可能性があります。

Validated Analysis。

Related Code Identification。

Remediation Suggestion。

Candidate Patch。

Automated Test。

Maintainer向けEvidence Package。

まで支援できるようになるでしょう。

最終判断はHuman Security ProfessionalやMaintainerが行います。

しかし一件あたりのMechanical Workを大きく減らせます。

AI CybersecurityはContinuousになる

Traditional Security Assessmentは特定Momentで行われます。

Launch前のPentest。

Major Release前のReview。

定期Vulnerability Scan。

AIはContinuous Security Reasoningをより実用的にします。

New CodeがCommitされたら分析する。

Security-Sensitive ChangeだけDeep Reviewする。

既知のVulnerability FamilyをCodebase全体から探す。

以前のFindingに似たPatternを継続的にSearchする。

そしてHuman Researcherは最も価値の高いCandidateへ集中する。

SecurityはPoint-in-Time AssessmentからContinuous Investigationへ近づきます。

MythosがTraditional Pentestingを不要にするわけではない

強力なCode Analysis ModelでもProduction Environmentのすべてを知るわけではありません。

Runtime Configuration。

Authentication State。

Cloud Architecture。

Real User Permission。

Business Logic。

Third-Party Integration。

DevelopmentとProductionのDifference。

これらは実際のSecurity Impactへ大きく影響します。

Source Code上ではCriticalに見えてもProductionではReachできない場合があります。

逆にSourceだけでは見えないAttack Pathが複数System間のInteractionから生まれることもあります。

そのためAI Vulnerability DiscoveryとTraditional Penetration Testingは競合ではなく補完関係です。

AIはCoverageを増やす。

Runtime TestingはOperational Truthを提供する。

Responsible Disclosureはさらに重要になる

AIが大量の未知Vulnerabilityを発見できるようになれば、それに伴う責任も大きくなります。

Patch前にTechnical Detailを公開するべきではありません。

Maintainerには現実的な修正時間が必要です。

UserにもUpdate時間が必要です。

AIはResponsible Disclosureを不要にしません。

むしろDiscoveryのVolumeとSpeedが増えるほど重要にします。

Mythos級AIがPenetration Testingをどう変えるか

将来のPentestはHybrid Modelへ近づく可能性があります。

AIがAttack Surface Analysisを行う。

大量のCodeを読む。

RoleやWorkflowを比較する。

Vulnerability Hypothesisを作る。

Related Attack Pathを探す。

Human Researcherは、

どのPathがCredibleか判断する。

Active TestingをControlする。

ExploitabilityをValidateする。

十分なEvidenceが得られたか決める。

Business ImpactをInterpretする。

Remediationを伝える。

AIによってProfessional Penetration Testingが消えるのではありません。

Repeating Analytical Workの割合が下がり、Researcherが高価値な判断へ集中するようになります。

Security Teamが今から学べること

Mythos 5へのAccessがなくても、Project Glasswingから学べることは多くあります。

Vulnerability Discoveryは速くなる。

Candidate Volumeは増える。

Human Validationを効率化する必要がある。

Disclosure InfrastructureをScaleする必要がある。

Remediation Automationが重要になる。

Pre-Release Security Reviewの価値が上がる。

AIを使ってもAuthorizationとRules of Engagementは変わらない。

これらは特定Modelだけの話ではありません。

Softwareを作るすべてのOrganizationに関係します。

Defensive AIの価値は攻撃側が同じ能力を持つ前に生まれる

Project Glasswingの戦略的価値は時間にあります。

高度なCybersecurity Capabilityが出現している。

それは永遠に少数のDefenderだけのものではない。

だからこそDefenderは早い段階で利用し、

将来Attackerが発見する可能性のあるWeaknessを先に見つけ、

先にPatchする必要があります。

VulnerabilityがDefensive Findingであるうちに見つける。

Attacker Knowledgeになる前に修正する。

これがFrontier Defensive AIの重要な目標です。

防御型Cybersecurityの未来は速くなるが、人間の判断は残る

Claude MythosとProject Glasswingが示しているのは、AIがCoding Assistanceからより高度なSecurity Researchへ進んでいることです。

Large Codebaseを分析する。

Candidate Vulnerabilityを生成する。

Penetration Testingを支援する。

Patch Developmentを支援する。

Pre-Release Reviewへ参加する。

これはDefense Capacityを大きく増やす可能性があります。

しかしCybersecurityの基本要件は消えません。

Authorization。

Human Validation。

Real Impactに基づくSeverity。

Coordinated Disclosure。

Patching。

Retesting。

強いSecurity Programが問うべきなのは、

「AIはSecurity Researcherを置き換えるのか?」

ではありません。

「AIを使ってより多くのSoftwareを調査しながら、Security Researchを信頼できるものにしているValidation Standardをどう維持するか?」

です。

それがMythos級Cybersecurity AIの本当の可能性です。

Anthropic MythosとProject Glasswingに関するよくある質問

Claude Mythosとは何ですか?

Anthropicが高度なFrontier AI CapabilityをCybersecurityなどの分野でTrusted Accessのもと提供するために開発しているModel系統です。元記事ではMythos Previewが2026年4月、Mythos 5が同年6月に登場した流れを説明しています。

Project Glasswingとは何ですか?

高度なAI Cybersecurity Capabilityを実際のSoftware Securityへ利用し、Vulnerability Discovery、Validation、Remediation、Pre-Release Reviewを支援するAnthropicの防御型Initiativeです。

Mythos 5は誰でも利用できますか?

元記事では、2026年8月19日時点でUnrestricted Public Accessではなく、限定されたTrusted-Access Arrangementで提供されていると説明されています。

Mythosは本当にSoftware Vulnerabilityを発見できますか?

AnthropicはMythos Previewを利用してReal Software上から大量のCandidate Vulnerabilityが発見されたと報告しています。ただしCandidateはHuman ResearcherによるTriageとValidationを経る必要があります。

AIが見つけたFindingはすべて自動的に報告されますか?

いいえ。元記事では、Candidate FindingをHuman ResearcherがReviewし、確認されたHigh / Critical Severity IssueをCoordinated Disclosureへ進める仕組みが説明されています。

MythosはPatch作成にも使えますか?

Project GlasswingではVulnerability DiscoveryだけでなくPatch DevelopmentやPre-Release Security Checkへの利用も報告されています。

なぜMythosへのAccessは制限されているのですか?

高度なCybersecurity CapabilityはDefenseとAttackの両方へ利用可能なDual-Use Technologyだからです。

Frontier AIはPentesterを置き換えますか?

完全な置き換えより、Hybrid Workflowへ進む可能性が高いでしょう。AIが広範なAnalysisを支援し、人間がValidation、Active Testing、Business Impact、Disclosure、Retestingを担います。

Project GlasswingからSecurity Teamが学べる最も重要なことは?

DiscoveryだけをScaleしても十分ではないという点です。Verification、Disclosure、Patching、Retestingまで同時に高速化する必要があります。