Claude Mythos公開方針転換：6〜12ヶ月以内に一般リリースへ — Anthropicが「無期限制限」を撤回

Anthropic Reverses Course: Claude Mythos to Be Publicly Released Within 6-12 Months

claude security

2026.05.27 2分

Claude Mythos公開方針転換：6〜12ヶ月以内に一般リリースへ — Anthropicが「無期限制限」を撤回 - AIツール日本語解説 | AI Heartland

5月25-26日、Anthropicが『Mythos級モデルを6〜12ヶ月以内に一般リリースする』と表明。4月時点の『無期限制限』方針を事実上撤回した。攻撃側悪用リスクと防御側恩恵のバランスが、AI能力の自然な拡散圧力で動き出す。

この記事ではセキュリティに特化して解説します。AIセキュリティ全般はサプライチェーンセキュリティ完全ガイド2026｜攻撃手法・防御ツール・実践チェックリストをご覧ください。

Anthropicが「Mythos一般公開」へ方針転換した瞬間

2026年5月25日から26日にかけて、Anthropicは未公開の脆弱性発見特化モデル Claude Mythos（Project Glasswingで使用されているOpus 4.6ベースの拡張モデル）について、これまでの「安全な公開方法が確立されるまで一般公開しない」という事実上の無期限制限を撤回し、6〜12ヶ月以内の一般リリースを視野に入れる方針を表明した。

公式ブログ Project Glasswing Initial Update では、Anthropicは次のように述べた。

“in the near future, once we’ve developed the far stronger safeguards we need, we look forward to making Mythos-class models available through a general release.”

（和訳：強固なセーフガードを整備でき次第、近い将来にMythos級モデルを一般リリースできることを楽しみにしている。）

公式ブログの表現は「near future（近い将来）」という曖昧な時間表現にとどまるが、 govinfosecurity.com の取材記事ではAnthropic幹部が 「6〜12ヶ月以内にMythos級モデルが広く利用可能になる、自社からか競合からかは別として」 と明言したことが報じられている。

この方針転換は、4月9日のClaude Mythos Preview発表時に Anthropic が示した『無期限制限』のスタンスからの実質的な撤回である。

この記事のポイント

Anthropicが4月の『無期限制限』方針を撤回し、6〜12ヶ月以内の一般公開へ転換
公式ブログは「near future」と表現、取材記事で「6〜12ヶ月」が具体数字として明示
セーフガードは4層構成（モデル側ガードレール／API認証／政府協議／責任開示誘導）
背景は競合他社による同等モデル登場の不可避性 — 「Anthropicが出さなくても誰かが出す」
セキュリティコミュニティは『発見過多でパッチが追いつかない』と既に警鐘
日本の組織は SBOM整備・開示プロトコル・パッチ適用速度の3点を6〜12ヶ月で前倒し必須

4月9日の Claude Mythos Preview発表時、Anthropicは「責任ある開示と防御側展開を優先するため、Mythosは一般公開しない」と明言していた。当時のFAQでも「将来的にClaude Opusの後続バージョンに安全策を組み込んだ上でリリース」とだけ書かれており、時間軸は完全に開かれていた。

それから約7週間で、Anthropicは時間軸を急激に狭めた。何が起きたのか。

4月の「無期限制限」から5月の「6〜12ヶ月公開」へ — 何が変わったのか

4月時点：無期限制限としての「Project Glasswingのみ」

4月9日のClaude Mythos Preview発表時、Anthropicは一般公開を明示的に拒否していた。アクセスはProject Glasswingの11社の限定パートナー（AWS、Apple、Broadcom、Cisco、CrowdStrike、Google、JPMorganChase、Linux Foundation、Microsoft、NVIDIA、Palo Alto Networks）に限られ、外部の研究者・セキュリティ企業からは「能力を独占する閉鎖モデル」として強い批判を浴びていた。

4月12日には Hacker Newsで小規模モデルでも同等の脆弱性検出が可能との指摘が出され、Mythosの優位性自体に懐疑論が立ち上がった経緯もある。

5月23日：Project Glasswing初回成果報告で「実測値」が出揃う

5月23日、Anthropicは Project Glasswing初回成果報告を公開。パートナーは50社に拡大し、1ヶ月で High/Critical severity脆弱性を1万件超 発見した。Cloudflareでは2,000バグ（うち400件がHigh/Critical）、Mozilla Firefoxでは旧Claude比10倍の検出率を達成した。OSS 1,000リポジトリ全体で 23,019件のうち6,202件がHigh/Critical と判定された。

ここで重要なのは「誤検出率が人間以下」という独立検証結果である。セキュリティ企業がアセスメントした1,752件のうち 1,587件（90.6%）が真陽性 と確認された。

5月25-26日：「6〜12ヶ月公開」表明

成果報告の2日後、ghacks.netとgovinfosecurity.comが相次いで「Anthropicが一般公開計画を明示」と報じた。ghacks.netの記事 はタイトルそのものが “Anthropic Plans Public Release of Mythos-Class AI Bug-Finder Once Safeguards Are Ready” であり、「セーフガードが整い次第公開する」という明確な意思表示として受け止められた。

flowchart TD A["2026-04-02
Capybaraリーク
未公開モデル存在発覚"] --> B["2026-04-09
Mythos Preview発表
『一般公開しない』明言"] B --> C["2026-04-12
HN論争
『誇大宣伝では？』疑惑"] C --> D["2026-04月末〜5月
パートナー11社→50社
拡大運用フェーズ"] D --> E["2026-05-23
初回成果報告
1万件超バグ発見"] E --> F["2026-05-25〜26
方針転換報道
『6〜12ヶ月で公開へ』"] F --> G["2026-Q3〜Q4予想
セーフガード仕様確定
段階的一般公開準備"] G --> H["2026-2027年内
Mythos級モデル
一般公開フェーズ"] style B fill:#fee style F fill:#fec style H fill:#cfc

何が方針転換を駆動したのか

報道と公式声明を突き合わせると、3つの圧力が並行して働いている。

圧力	4月時点	5月時点	影響
競合他社の追従	OpenAI/Googleは未表明	業界全体で6〜12ヶ月以内に同等モデル登場が確実視	Anthropicが出さなくても誰かが出す
パートナー側の悲鳴	11社で対応可能	50社でもパッチ適用が追いつかない	『発見過多』が新たなボトルネック
防御側のアクセス公平性	大手企業中心	中小・公共インフラ・OSSの保護に不可欠	限定公開は非対称性を生むだけ
規制側の関与	言及なし	米国・同盟国政府との協議枠組み明示	政府承認型ガードレールへ移行
Mythos優位性の実証	自社ベンチのみ	Cloudflare等の独立検証で確定	「閉じ込めるだけ無意味」論が補強

特に決定的なのは 「Anthropicが出さなくても誰かが出す」 という前提だ。govinfosecurity.comの取材で幹部が「自社からか競合からかは別として6〜12ヶ月以内」と明言した点こそが、無期限制限の論理的根拠を消滅させている。AI能力の自然な拡散圧力に対して、特定企業による永続的な独占は技術的にも倫理的にも持続不可能である、というメッセージだ。

「6〜12ヶ月で公開」の具体的条件とセーフガード設計

Anthropicが公式に列挙したセーフガード設計の構成要素は4層だ。技術仕様はまだ完全公開されていないが、公開資料と過去のAnthropic Responsible Scaling Policyから推測できる範囲を整理する。

第1層：モデル側ガードレール（攻撃用途の自己抑制）

Mythos級モデルが攻撃目的の脆弱性発見・エクスプロイト生成を要求された際に、それを検知して回答を拒否する内部メカニズムを指す。Anthropicは既に Constitutional AI ベースの安全訓練を行っているが、Mythosのようなセキュリティ研究特化モデルでは「研究目的と攻撃目的の境界線をモデルが自律的に判断できるか」が最大の論点だ。

実用上は、以下のようなプロンプト分類を想定したガードが必要になる。

# Anthropic Claude API（Mythos想定）でのセキュリティ用途認証イメージ
# 公式仕様は未公開、現時点では推測ベースのインタフェース例
import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-mythos-1",  # 一般公開後の想定モデル名
    max_tokens=4096,
    system="""You are a security research assistant.
You may only assist with:
- Authorized vulnerability research on systems the user owns or has explicit permission to test
- Defensive security analysis (SAST, SCA, secure code review)
- CVE triage and patch development
You must refuse:
- Exploit development for systems without authorization
- Attack planning, evasion techniques, or weaponization
""",
    messages=[
        {
            "role": "user",
            "content": "Find memory safety bugs in this OSS library: <code>"
        }
    ],
    extra_headers={
        # 想定: 公開後はセキュリティ用途であることを証明するヘッダー
        "X-Anthropic-Security-Use-Case": "defensive-research",
        "X-Anthropic-Org-Verification": "verified-security-team",
    },
)

注意：上記コードはAnthropicが公開した仕様ではなく、現時点での合理的推測である。実際のAPIインタフェースは正式リリース時に確定する。

第2層：APIレベルでのセキュリティスキャン用途認証

Mythos級モデルへのAPIアクセスは、おそらく 組織レベルの審査制 になる。OpenAIがGPT-4 Vision公開時に取った段階的アクセス（waitlistから審査制）と似た仕組みが想定される。

具体的には、APIキー取得時に以下のような情報提示が必要になる可能性が高い。

組織の身元証明（事業者登録／対応するセキュリティチーム名簿）
利用目的の宣言（社内コードベース／契約済みクライアントへのペネトレーション／OSS貢献など）
責任ある開示プロトコルへの誓約署名
不正利用が発覚した場合のアクセス即時停止条項への同意

第3層：米国・同盟国政府との協議枠組み

公式ブログで明示的に言及されている点だ：

“working with critical partners—including US and allied governments—to expand Project Glasswing to additional partners”

（和訳：米国・同盟国政府を含む重要なパートナーと協力しProject Glasswingを追加パートナーに拡大している）

これは米国の AI Executive Order や英国 AI Security Institute の評価枠組みと連動していると考えられる。実際に英国AI Security Instituteが「Mythosは多段階攻撃の自律実行が可能」と評価レポートを出しているのは、この政府協議枠組みの可視化された一面だ。

第4層：責任ある開示プロトコルへの強制誘導

Mythosが発見した脆弱性は、現時点でも100%が責任ある開示プロトコル（90日のembargo period等）に従っている。一般公開後もこのプロトコルを モデル出力レベルで強制する 設計が議論されている。

例えば、Mythosが新規脆弱性を発見した場合に、出力に自動的に以下のような構造を埋め込む仕組みが想定される。

# Mythos想定出力フォーマット（推測）
finding:
  severity: high
  cve_candidate: CVE-PENDING
  affected_component: example-lib v2.3.1-2.5.0
  triage_required: true
  disclosure_timeline:
    discovery_date: 2026-XX-XX
    vendor_notification_required: true
    public_disclosure_earliest: discovery_date + 90 days
    embargo_status: active
  next_actions:
    - Submit to vendor security contact via encrypted channel
    - Open private GitHub Security Advisory
    - Do not post technical details to public channels until embargo lifts
poc_provided: false  # 公開モデルではexploit codeは原則出さない

CIへの組み込みイメージ

防御側の組織がMythos級モデルを安全に使うCI/CD組み込みは、以下のようなGitHub Actions構成が現実的になる。

# .github/workflows/mythos-defensive-scan.yml
# Mythos公開後の防御スキャン想定（仕様未確定、推測ベース）
name: Defensive Vulnerability Scan
on:
  pull_request:
    branches: [main]
  schedule:
    - cron: '0 2 * * 1'  # 週次フルスキャン

jobs:
  scan:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      security-events: write  # SARIF出力用
    steps:
      - uses: actions/checkout@v4
      - name: Run Mythos defensive scan
        env:
          ANTHROPIC_API_KEY: $
          MYTHOS_USE_CASE: defensive-sast
        run: |
          # 想定: 公式CLIラッパー
          claude-security scan \
            --model claude-mythos-1 \
            --scope "src/**" \
            --output sarif \
            --output-file mythos-results.sarif \
            --disclosure-mode embargo-90d
      - name: Upload SARIF
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: mythos-results.sarif

上記の claude-security CLI は2026年5月時点では存在しない（推測上のインタフェース）。正式リリース時に実際のツール名・引数は確定する。

セキュリティコミュニティの反応：歓迎・懸念・分断

5月25-26日の方針転換発表に対する反応は、セキュリティコミュニティ内で3つの立場に分かれている。

立場1：歓迎派 — 「防御側にも公平にアクセスを」

OSS メンテナや中小企業のセキュリティチームを中心に、「11社や50社の特権パートナーだけが恩恵を受ける状況は持続不可能」という意見が根強い。Project Glasswingがカバーするのはあくまで大手のCloudflare/Mozilla/Microsoft等であり、世界中の数百万のOSSプロジェクトと中小企業のコードベースは依然として手動レビューに依存している。

特に責任ある開示の最終受け手はOSS メンテナだが、彼らがMythosにアクセスできないのは構造的非対称性として批判されてきた。一般公開によりOSSメンテナ自身が自プロジェクトをスキャンできるようになれば、攻撃側が同じツールを使う前に弱点を潰せる。

立場1のロジック

「攻撃側の手に渡る前に、まず防御側に渡せ」という伝統的なFull Disclosure思想の現代版。Mythos公開の最大の擁護者はOSS メンテナとセキュリティ研究者コミュニティ。

立場2：懸念派 — 「パッチが追いつかない」

Project Glasswingで既に発生している「発見過多」問題が、一般公開で爆発的に悪化するという警告だ。ghacks.netの記事でも「Some maintainers have asked Anthropic to slow down its rate of disclosures（一部のメンテナはAnthropicに開示ペースを落とすよう要請）」と報じられている。

数字で見ると深刻だ。Project Glasswing初回成果報告では、報告された530件のHigh/Criticalのうち 75件がパッチ適用済み、65件が公開アドバイザリ取得 にとどまる。残り約400件は 修正待ちのまま だ。50社のパートナーだけでこの状況なのに、世界中の組織が同時にスキャンを始めたら、CVE発番システムもメンテナの対応能力も完全にオーバーフローする。

GitHub Security Advisories と CVE Numbering Authority (CNA) の処理能力には現実的な上限があり、年間数万件のCVE発番が物理的限界に近い。Mythos一般公開はこの限界を一気に破る可能性がある。

立場3：分断派 — 「攻撃側と防御側の収支は不明」

英国AI Security Instituteが代表的な立場だ。同機関は評価レポートで以下の2点を併記した。

“Mythos could execute multi-stage attacks on vulnerable networks and discover and exploit vulnerabilities autonomously”

（和訳：Mythosは脆弱なネットワーク上で多段階攻撃の自律実行、脆弱性の発見と悪用が可能）

“we cannot say for sure whether Mythos Preview would be able to attack well-defended systems”

（和訳：十分に防御された環境を本当に突破できるかは確実には言えない）

これは「能力は実在するが、現実世界での攻撃成功率は防御の質に依存する」という慎重な立場だ。攻撃側が Mythos を使った場合の成功率と、防御側が Mythos を使った場合の検出率がどちらが高いかは、まだ実証データが揃っていない。

立場3のロジック

収支は防御側の準備によって変動する。一般公開の判断は「ツールの能力」ではなく「世界全体の防御準備度」を基準に下すべき、という見解。

公開された場合のシナリオ：攻撃側悪用 vs 防御側恩恵

「6〜12ヶ月以内の一般公開」が実現した場合に何が起きるのかを、3つのシナリオで整理する。

シナリオA：防御側が先行する場合（楽観シナリオ）

CI/CDパイプラインへのMythos組み込みが標準化し、新規コードがマージされる前にHigh/Critical脆弱性が自動検出・修正される世界。OSS全体でゼロデイが急減し、過去の負債（27年前のOpenBSDバグのような長期未発見脆弱性）も短期間で潰される。

成立条件：

主要なCI/CDプラットフォーム（GitHub Actions / GitLab CI / CircleCI）がデフォルトでMythos対応スキャンを統合
OSS メンテナの90%以上が自プロジェクトに対し週次以上の自動スキャンを実施
パッチ適用平均時間が現在の2週間から 5日以内 へ短縮
CNAのCVE発番処理能力が10倍以上に拡張

シナリオB：攻撃側が先行する場合（悲観シナリオ）

セーフガード回避（jailbreak）が一般化し、攻撃グループがMythosを使って未パッチの脆弱性を大量にエクスプロイトする世界。発見スピードはAIに依存するため、防御側が手動レビューに依存する組織は構造的に劣勢になる。

トリガーとなり得る事象：

中国・ロシア等が同等モデルを独自開発・無認可配布
Mythos互換のOSSモデル（Llamaベース等）の登場
大手クラウドプロバイダーのAPIキー大量漏洩
セーフガードのプロンプトインジェクション突破事例

シナリオC：膠着状態（最も現実的なシナリオ）

攻守どちらも同じツールを持ち、勝敗は 対応速度 と コードベースの基本品質 に依存する世界。SBOM整備済み・自動パッチ適用済みの組織は安全性が大幅に向上し、レガシーコード・SBOM未整備の組織は被害を集中して受ける。

graph LR M["Claude Mythos
一般公開（2026-2027）"] M --> Atk["攻撃側利用"] M --> Def["防御側利用"] Atk --> A1["未知の脆弱性発見"] Atk --> A2["エクスプロイト自動生成"] Atk --> A3["多段階攻撃の自律実行"] Def --> D1["自社コードのSAST/SCA"] Def --> D2["責任ある開示の高速化"] Def --> D3["パッチ自動生成・適用"] A1 --> Race["勝敗は
『対応速度の差』で決まる"] A2 --> Race A3 --> Race D1 --> Race D2 --> Race D3 --> Race Race --> Win["SBOM整備済み
自動パッチ運用組織
→ 安全性向上"] Race --> Lose["SBOM未整備
手動対応依存組織
→ 集中被害"] style M fill:#fec style Race fill:#fee style Win fill:#cfc style Lose fill:#fcc

最も重要なのは、シナリオA・B・Cのどれに転ぶかは Anthropic の判断ではなく、 世界中の組織が今から6〜12ヶ月で何を準備するか によって決まる、という点だ。

日本の組織が今からやるべき5つの準備

シナリオCを前提に、日本の組織が6〜12ヶ月で完了させるべき準備を5つに整理する。

準備1：SBOM（Software Bill of Materials）の整備

自社プロダクトの依存ライブラリ全件を機械可読フォーマット（CycloneDX / SPDX）で管理する。Mythos が発見した脆弱性が自社の依存先に該当するかを自動判定するには、SBOMが前提条件になる。

実装ツール例：

Syft — コンテナイメージ・ファイルシステムから SBOM 生成
CycloneDX SBOM tools — 多言語対応のSBOM生成
GitHub Dependency Graph — 標準機能でSBOM出力可能

準備2：責任ある開示プロトコルの社内策定

外部研究者・AIから自社プロダクトの脆弱性報告を受け取る窓口を整備する。最低でも以下の3要素は明文化が必要だ。

security.txt（RFC 9116）の公開
暗号化された連絡チャネル（PGP公開鍵 or Signal番号 or 専用フォーム）
90日embargo periodと公開アドバイザリ発行のフロー

準備3：パッチ適用平均日数の計測と短縮

現在の自社のCVE公開からパッチ適用までの平均日数を計測し、5日以内 を目標に短縮する。Project Glasswing初回成果報告で平均2週間と報告されているのは大手の数字であり、日本の中小は通常もっと遅い。

短縮のために必要な要素：

Dependabot / Renovate による依存パッチPR自動生成
自動テストカバレッジ60%以上（自動マージ可否判断のため）
ステージング環境での自動デプロイ→smoke test→本番展開のリードタイム短縮

準備4：AI支援セキュリティスキャンを攻撃側に先んじて導入

Mythos の一般公開前に、現行のClaude Opus 4.6 + セキュリティ専用プロンプト、Snyk、Semgrep、GitHub Advanced Security等を組み合わせた多層スキャンをCIに組み込む。Mythos公開時点で「既存のスキャン体制にAPIを差し替えるだけ」の状態を作っておく。

準備5：外部研究者からの大量バグ報告を捌くトリアージ体制

Mythos一般公開後、自社プロダクトに対する報告件数は現在の5〜10倍に増えると想定すべきだ。バグバウンティプログラムを整備していない組織は今のうちに以下を準備する。

HackerOne / Bugcrowd / IntigriT等のプラットフォーム加入検討
報告内訳ごとの優先度判定基準（CVSS基準＋ビジネスインパクト評価）
偽陽性除外プロセス（Project Glasswingでも10%は偽陽性）
重複報告のマージプロセス

5つの準備の優先順位

最優先：SBOM整備 — これがないと脆弱性影響範囲を自動判定できない
次点：パッチ適用速度の計測 — 現状を数値化しないと改善できない
並行：責任ある開示プロトコル策定 — 報告受付窓口がないと話が始まらない
後追い：AI支援スキャン導入 — Mythos公開前に既存スタックで先行運用
長期：トリアージ体制構築 — 報告爆増を想定した組織設計

まとめ：AI攻守バランス再均衡の本番フェーズへ

Anthropicの方針転換は、AI能力の自然な拡散圧力に対する現実的な対応だ。「Anthropicが出さなくても誰かが出す」という構造的事実の前で、無期限制限は持続可能ではない。

重要なポイントを再整理する。

2026年4月から5月の7週間で、Anthropicは「無期限制限」から「6〜12ヶ月公開」へ方針転換
公式ブログは「near future」、取材記事で「6〜12ヶ月」が具体数字として明示
セーフガードは4層構成（モデル側ガードレール／API認証／政府協議／責任開示誘導）
セキュリティコミュニティは歓迎・懸念・分断の3立場で割れる
公開後の攻守バランスは、Anthropicの判断ではなく世界中の組織の準備度で決まる
日本の組織はSBOM整備・開示プロトコル・パッチ速度の3点を6〜12ヶ月で前倒し必須

Project Glasswing初回成果報告が示した通り、ボトルネックはすでに「発見」ではなく「パッチ適用速度」へ移った。Mythos一般公開はこのボトルネックを世界中で同時に発生させる。準備していない組織は、攻撃側がMythosを手にした瞬間から後追いを強いられる。

逆に言えば、SBOMとパッチ自動化が整備済みの組織は、Mythos一般公開を 守備力の急上昇 として享受できる。6〜12ヶ月という時間軸は、技術投資の意思決定としては短いが、組織的な防御体制を整えるには十分な猶予だ。Anthropicが意図的にこの時間を残したのか、それとも能力進化速度から逆算された自然な数字なのかは別として、防御側にとって最後の準備期間であることは間違いない。

4月時点で小規模モデルでもMythos相当の検出が可能では？という疑念があったが、5月のProject Glasswing初回成果で実測ベースに優位性が確認された。この能力が一般公開された瞬間に、攻守どちらが先に動くか — それを決めるのは「今日から動き始めた組織」だけだ。

参照ソース

Anthropic — Project Glasswing Initial Update（2026-05-23） — Anthropic公式の初回成果報告と一般公開計画の公式声明
ghacks.net — Anthropic Plans Public Release of Mythos-Class AI Bug-Finder Once Safeguards Are Ready（2026-05-26） — 方針転換を最初に大きく報じた記事
govinfosecurity.com — Anthropic Expands Public Access to Claude Mythos AI Model — Anthropic幹部の「6〜12ヶ月」発言を取材で確認した記事
Claude Mythos Preview発表時の報道（2026-04-09） — 当時の「無期限制限」スタンスを記録した記事
Hacker News論争（2026-04-12） — Mythos優位性への懐疑論
Project Glasswing初回成果報告（2026-05-27） — パートナー50社・1万件超バグ発見の実測値

よくある質問

Anthropicは本当に「無期限制限」を撤回したのですか？

完全な撤回ではありませんが、4月の発表時の『安全な公開方法が確立されるまで一般公開しない』という事実上の無期限制限から、5月26日の声明では『近い将来、6〜12ヶ月以内にMythos級モデルが広く利用可能になる』と明言する方向へ大きく転換しました。Anthropic自身が出すか、競合他社が同等モデルを出すかは別として、市場全体で6〜12ヶ月という時間軸が示されたのは初めてです。

「6〜12ヶ月」という具体的な数字はどこから来たのですか？

Anthropic自身の公式ブログでは『近い将来（in the near future）』としか書かれておらず、具体的な月数は明示されていません。ただし govinfosecurity.com（Information Security Media Group）の取材記事で、Anthropic幹部が『Mythos級モデルは6〜12ヶ月以内に広く利用可能になる、自社からか競合からかは別として』とコメントしたことが報じられています。つまり時間軸はAnthropicの公開判断だけでなく、業界全体のAI能力進化速度から逆算された数字です。

公開のための「セーフガード」とは具体的に何ですか？

現時点で完全な技術仕様は公開されていませんが、公開資料から読み取れる範囲では、（1）攻撃側使用を検知するためのモデル側ガードレール、（2）APIレベルでのセキュリティスキャン用途認証、（3）米国・同盟国政府との利用適合性審査、（4）責任ある開示プロトコルへの強制誘導、の4層が想定されています。Anthropic自身が『どの組織もまだ十分なセーフガードを開発できていない』と認めている点が重要です。

公開されたら攻撃側にも使われるのでは？

その懸念は実在し、英国AI Security Instituteも『Mythosは多段階攻撃の自律実行が可能』と警告しています。ただし同機関は『十分に防御された環境を本当に突破できるかは未確定』とも追記しており、能力評価はまだ流動的です。一方でCloudflareでの誤検出率が人間以下、Firefoxで旧モデル比10倍という実測値は防御側にも同等以上の恩恵が及ぶことを示唆します。攻守の収支は今後12ヶ月のセーフガード設計次第で大きく変わります。

日本の組織は今から何を準備すべきですか？

最低でも、（1）自社コードベースのSBOM（Software Bill of Materials）整備、（2）責任ある開示プロトコルの社内策定、（3）CVE公開からのパッチ適用平均日数の計測と短縮、（4）AI支援セキュリティスキャンを攻撃側に先んじて導入、（5）外部研究者からの大量バグ報告を捌くトリアージ体制、の5点を6〜12ヶ月で完了させる必要があります。Project Glasswingの初回成果で『発見ではなくパッチ適用がボトルネック』と明示された通り、対応速度こそが新しい競争軸です。