「使わない」で終わると、直す速度が決まりません
たとえば、週次のセキュリティレビューです。共有されたのは、オープンウェイトの GLM-5.3 が、クローズドな Claude Mythos Preview に近い割合で、Chrome の既知脆弱性から最後まで exploit を組めた、という Anthropic の分析です。
結論を「危ないから使わない」だけにすると、防御側がその能力をどう使うかが決まりません。決めるのは、自社のコードと構成を使って、脆弱性を見つけ、修正し、もう一度確かめる時間を短くできるかです。攻撃側の探索だけが短くなり、修正が今までと同じ日数のまま、という状態を避けるためです。
Andrew Ng 氏は2026年10月2日の We Should Be Encouraged By AI’s Cybersecurity Abilities で、この近さは防御側が使える、と書いています。元は The Batch の373号 の手紙です。ただし、その近さは、選んだ試験によって消えます。
「12%と14%が近い」だけでは、同じ能力とは見なしません
GLM-5.3 と Claude Mythos を、同じサイバー能力としては扱えません。近い点数と、差が開く点数は、別の試験から出ています。
ExploitBench は、Chrome の JavaScript エンジン V8 にある既知の脆弱性から、モデルが exploit をどこまで作れるかを見る試験です。次の図の左は、最後まで exploit を作れた割合です。右は、途中まで到達した能力も含めた、別の平均です。縦軸が違うので、棒の高さで何倍かとは比べません。
近いのは、最後まで成功した12%と14%です
Anthropic は GLM-5.3 and the spread of advanced cyber capabilities で、最後まで exploit を作れた回数を、GLM-5.3 が410回中50回、Claude Mythos Preview が56回と書いています。割合にするとおよそ12%と14%です。Ng 氏の手紙が「近い」と書いたのは、この試験です。
同じ報告の別の試験では、制御フローの乗っ取りまで到達した割合が GLM-5.3 で4%、Claude Mythos Preview で6%です。Claude Opus 4.6 と GLM-5.2 は、この試験の成功が0でした。前のモデルより届く試験は増えました。それでも、12%と14%が近いから同じ能力、にはなりません。
差が開くのは、54.4%と78.0%です
開発元 Z.ai の GLM-5.3 は、同じ ExploitBench で別の平均を出しています。41タスクについて、最大300ラウンド、3回の試行で到達した能力をまとめ、GLM-5.3 は54.4%、Mythos 5 は78.0%です。前世代の GLM-5.2 は24.4%でした。途中の到達も含むので、最後まで成功した12%と14%とは足せません。比較相手の名前も、Claude Mythos Preview と Mythos 5 で違います。
米国 NIST の CAISI も、2026年9月の GLM-5.3 のサイバー能力評価 で別の手順を使い、公開時点で最もサイバー能力の高いオープンウェイトとしたうえで、米国のフロンティアより約4か月遅れ、と評価しています。
不具合を見つける作業では、84.5%と83.8%で並びます
同じ Z.ai の記事では、ソースコードから不具合を起こして確認する CyberGym が、GLM-5.3 で84.5%、Mythos 5 で83.8%です。不具合を見つける作業では差が小さく、exploit を最後まで作る作業では差が残ります。
防御で先に使うなら、見つける作業と、修正の確認です。依存関係の警告を読む。パッチがその脆弱性を塞いでいるかを見る。公開された修正から、悪用できる形に戻るかを確かめる。この範囲なら、点数の差は小さい方の試験を見ます。exploit を最後まで作る能力が同じ、という理由では採用しません。
ソースやログを外部のサービスへ出せないなら、モデルを自社に置けるかも一緒に決まります。
社外に出せないデータは、自社に置いたモデルで分析します
セキュリティの作業には、外部のチャットへ送りにくいデータがあります。ソースコード、システム構成、ログ、脆弱性情報、インシデントの記録、SBOM、CIの結果です。
オープンウェイトは、重みが公開され、自社の環境、閉域、専用のクラウドに置けるモデルです。防御で実用になるのは、外へ出せないデータを入力にして、その環境で分析できることです。
商用APIが攻撃ログの解析を拒否し、調査側がオープンウェイトを自社インフラで使った経緯は、Hugging FaceのAI主導侵入が示す、AIネイティブなセキュリティ設計 にあります。あの記事は、解析を拒否されたあとに自社へ置いた事例です。自社に置けば、発見、修正、再確認を短くできます。
モデルを置いたあと、渡すデータと、禁止する操作を分けます。どのリポジトリを読ませるか。本番の認証情報を渡すか。外部へ送信する操作を許すか。出力を、元のファイルと差分に結び付けて人が読めるか。実行場所と、入力データは、別々に決めます。
費用として出ている20.40ドルも、未知の脆弱性を見つけた金額ではありません。
20.40ドルは、公開済みの不具合からexploitを作った費用です
Ng 氏の手紙は、GLM-5.3-Flash のトークンに20.40ドルを使うと、最近公開された Google Chrome の欠陥を見つけられた、と書いています。金額が小さいので、未知の欠陥を発見した費用に見えます。Anthropic の実験は、その発見ではありません。手順は、公開情報を渡して exploit を作らせたものです。
研究者は、小さい GLM-5.3-Flash に、公開済みの Chrome 脆弱性 CVE-2026-11645 と、もう1件の既知の不具合の公開情報を渡しています。モデルは細かい指示をほとんど受けず、ARM64 向けに、その2件をつないだ exploit を作りました。人の作業は20分、モデルの作業は8時間です。20.40ドルは、Z.ai の API 価格でその作業を換算した金額です。
公開情報から、動く攻撃までの時間と費用が下がっています。未知の脆弱性を20.40ドルで発見した実験ではありません。
これまで、コードを読み、候補を出し、原因を切り分け、悪用できるかを確かめ、修正を書き、テストする、までには専門の人と時間が必要でした。この一部をエージェントが行うと、攻撃の準備も、防御側の確認も短くなります。防御側が残す成果は、パッチと、そのパッチを確かめたテストです。
自社で動かすと、クラウドサービス側の利用制限はそのままでは効きません。
自社で動かすときは、実行環境で操作を制限します
クラウドのAIサービスでは、利用方針、ガードレール、監視、アクセス制御も、提供側がまとめて運用しています。
オープンウェイトは、自分の環境で実行できます。制限を弱めた派生モデルを作ることも、技術的には可能です。Anthropic は、GLM-5.3 のセーフガードを、模擬試験では64%から100%の割合で回避でき、同じ攻撃は同社のセーフガード付き Claude では成功しなかった、と書いています。モデルの中の制限だけでは、この回避は止まりませんでした。
防御の分析では、正当な調査が拒否される回数は減ります。攻撃では、同じ能力を、公開された重みのまま使いやすくなります。この2つが同時に起きるので、モデルを置いたあとに、ネットワーク、認証情報、ツール、監査ログを実行環境側で制限します。提供側のガードレールが弱いモデルほど、何を実行できるかをこちらで決めます。
攻撃側も防御側も、同じ能力を使えます。Ng 氏は、長期的には防御側が有利だ、と考えています。有利になるのは、持っている情報をパッチまで届けられたときです。
防御が有利になるかは、内部情報をパッチまで届けられるかです
Ng 氏は、オープンウェイトのサイバー能力を攻撃側も使える、と書いたうえで、長期的には防御側が有利だ、としています。理由は、持っている情報の量です。これは実験で勝敗が付いた結果ではありません。手紙の中の判断です。
攻撃側が通常使うのは、外から見える情報、公開コード、公開された脆弱性、ネットワーク上の観測、漏えいした情報です。システムの所有者は、それに加えて、ソース、構成、ログ、テレメトリ、SBOM、依存関係、CI/CD、過去のインシデントを持っています。
モデルの解析が速くなれば、所有者側はこの情報で、攻撃側より先に脆弱性を探し、修正し、もう一度確かめられます。防御になるのは、その情報でパッチを短く出せるときです。
エージェントに内部情報を渡しすぎて、外部へ送れる状態だと、この差は小さくなります。読ませる範囲、残すログ、外部へ出さないデータを、先に決めます。
情報を持っていても、問題のあとに設計と運用を直し続けられなければ、その有利は続きません。Ng 氏は、航空機の安全がその繰り返しで上がった例を引いています。
安全は、事故のあと設計と運用を直す繰り返しで上がります
Ng 氏は、AIのリスクの多くを、設計と運用で扱う問題だとしています。危険の説明が「このあと対策は進まない」という前提だと、何を直すかの話が抜けます。その例が航空機です。
米国国立郵便博物館の They Died Flying the Mail は、1919年の航空郵便で、飛行115,325マイルあたりパイロット1人が死亡した、と記しています。1926年には、2,583,056マイルあたり1人まで下がっています。調査、設計変更、運用変更の繰り返しで、死亡の間隔が伸びた、という記録です。
手紙には、1919年の死亡間隔を、今の旅客マイルに掛けた説明もあります。比べている距離の定義が違うので、博物館が測った2つの数字だけを見ます。
今の商業航空の公開統計は、便あたりの事故率です。IATA の 2025年の安全報告 では、全事故率は100万便あたり1.32です。およそ76万便に1件です。2025年の便数は3870万、機内の死亡者は394人でした。事故は今もあります。事故のあと、原因を調べ、設計と運用と規格と監視を更新する作業は続いています。
ソフトウェアとエージェントでも、順序は同じです。問題が見つかったら調べる。設計を変える。運用を変える。次に同じ問題が起きる確率を下げる。性能の高いモデルは、このうち「見つける」と「確かめる」を短くできます。短くしたあとも、本番へ出す前に、人が差分を確認します。
その確認が効くには、調査用のエージェントが本番を直接変更できないことが先です。
調査用エージェントに、本番の認証情報は渡しません
エージェントがシェル、ブラウザ、ファイル、Git、クラウド、外部APIを、本番の権限のまま操作できると、誤った判断が本番まで届きます。脆弱性を探す作業では、読む権限、変更する権限、外部へ送る権限を分けます。
モデルの外側で操作を制限する整理は、ハーネスエンジニアリングとは？——AIエージェントを「手綱」で導く設計思想 にあります。調査ジョブの権限は、次のメモで切れます。製品の設定ファイルではなく、レビューで許可と禁止を揃えるためのものです。
# 脆弱性調査エージェントの権限。製品設定ではなく、レビュー用のメモです。
job: dependency_and_patch_review
runtime: on_prem_open_weight
inputs:
- repo_read
- sbom
- ci_logs
denied:
- production_credentials
- outbound_delivery
- direct_deploy
gates:
patch_merge: human_review
sandbox:
network: package_mirrors_only
filesystem: workspace_only
credentials: none
audit:
- tool_call
- file_diff
- model_version
リポジトリは読めます。本番の認証情報はありません。パッチ候補は、人が見てからマージします。ネットワークは、パッケージの取得に必要な宛先だけにします。監査では、どのモデルのどの版が、どの差分を提案したかを残します。
制限に使うのは、コンテナ、VM、IAM、ネットワークの分離、秘密情報の管理、監査ログです。エージェントのジョブごとに、この範囲を決めます。
レビューで残るのは、直すまでの時間と、エージェントの権限です。
レビューでは、所要時間と権限を確認します
これまでの流れは、人が脆弱性を見つけ、分析し、修正し、テストし、デプロイする、でした。エージェントを入れると、探索、分析、修正候補、自動テストまでを短くでき、そのあとに人のレビューが残ります。
攻撃側の探索が短くなることと、防御側の修正が短くなることは、同じモデル能力から来ます。このあと、攻撃用のエージェントと、パッチ用のエージェントが速さで競うことはあり得ます。遅れやすいのは、ソースやログを持っていても、発見から修正までの日数が以前のままの組織です。
動くAIの権限を実行前に制御する考え方は、エージェンティックAI時代のセキュリティは防御から統制へ——「動くAI」を止めずに制御する設計へ にあります。どのデータを、どの環境のモデルに読ませるか。本番の認証情報とデプロイを、そのジョブから外しているか。パッチは人がマージするか。発見から修正までの時間を、モデルの点数とは別に測っているか。
防御の発見、検証、修正が短くなっているか。エージェントが触れる範囲が、そのジョブの中に収まっているか。禁止のルールだけでは、公開された重みを使う側の速度には合わせられません。
作成日: 2026-10-05