2026年8月14日、中国の Z.ai（Zhipu AI）が新しいコーディング特化モデル GLM-5.3 を公開しました。ベンチマークの数字も派手ですが、エンジニアとして目が止まるのは発表に添えられた一文のほうです。このモデルを使って、269 のオープンソースプロジェクトから 2,436 件の脆弱性を検出した——Z.ai はそう発表しています。

見つかること自体は、悪い話ではありません。脆弱性は「見つかったから生まれる」のではなく、もともとそこにあったものが可視化されるだけです。問題は、可視化の速度が上がったときに、直して利用者に届けるまでの経路が同じ速度で回るのかという一点にあります。

そして、その経路をつくり直す動きは、実はこの発表より前から始まっていました。Linux Foundation が 2026年6月25日 に発足させた Akrites です。この記事では、GLM-5.3 が何をしたのかを一次情報で整理したうえで、オープンウェイト・協調的脆弱性開示（CVD）・SIRT という前提知識を押さえ、守り側の設計としての Akrites までをつなげて読みます。

⚠️ この記事の扱い方針

本記事は、個別の脆弱性の技術的詳細・悪用手順・検証コードを一切扱いません。公表されている件数・プロセス設計・組織の枠組みのみを扱います。セキュリティ記事における当サイトの従来方針です。

🔍 1. 何が起きたのか — GLM-5.3 と 2,436 件

まず発表の骨子です。数値はいずれも Z.ai 自身の発表・公式ドキュメントに基づくもので、第三者による独立検証を経た値ではありません。

項目 内容
公開日 2026年8月14日
ベースモデル GLM-5.2 と同一。性能向上はすべて事後学習（post-training）由来（公式ドキュメント）
コンテキスト長 1M トークン／最大出力 128K トークン（公式ドキュメント）
提供形態 GLM Coding Plan・ZCode で利用可。汎用 API は「coming soon」
オープンウェイト公開 安全性評価とハードニングの完了後、公開の約2週間後（8月下旬）を予定
脆弱性検出 中国のセキュリティチームとの協働で、269 プロジェクト・2,436 件（うち critical / high が 1,097 件）
開示状況 公開時点で 53 件が CVE 付きで公表済み・2,383 件が禁輸（embargo）中

ベンチマークについては、Z.ai の公式ドキュメントが GLM-5.2 との比較値を出しています。

ベンチマーク GLM-5.2 → GLM-5.3（Z.ai 公表値）
Terminal-Bench 3.0 4.6 → 28.3
DeepSWE v1.1 46.2 → 66.9
Agents’ Last Exam（CLI） 23.8 → 28.5
CyberGym（脆弱性発見） 77.2% → 84.5%
ExploitBench 24.4% → 54.4%

長い工程を最後まで走り切る種類のタスク（Terminal-Bench 3.0）で伸び幅が最も大きい、という形をしています。ソフトウェアの脆弱性探索は、まさにこの「長い工程を粘り強く回す」タイプの作業です。

対象になったプロジェクトには、システムカーネル・OS・ブラウザエンジン・ネットワークプロトコルといった、インターネットの土台側が含まれるとされています。Z.ai は公開の追跡台帳（Security Disclosure Ledger）を用意し、直近の公開例として Linux カーネル・WebKit・FreeBSD の各件を挙げています。

見つかったコードの古さについては、報道の記述に幅があります。「最も古いもので 1981 年に混入したコードに由来する（およそ45年前）」とする記事と、「最大で40年前ほど」とする記事があり、Z.ai 公式ブログは JavaScript 描画のため本文を機械的に取得できず、どちらの表現が原文かを確定できませんでした。ここでは「40年以上前に書かれたコードにまで遡る」という、両方の報道が共通して支える範囲だけを採ります。

もうひとつ、Z.ai 自身が「意図して訓練したものではない」と述べている点があります。複数段階のエクスプロイトを横断して推論し、一貫した攻撃連鎖の計画を組み立てる挙動が出てきた、というものです。公式ブログのタイトルが “Frontier Coding with Emergent Cyber Capabilities”（創発的なサイバー能力）となっているのは、この趣旨でしょう。オープンウェイトの公開を約2週間遅らせて安全性評価に回した判断も、ここと地続きに読めます。

🧭 2. 前提の整理 — オープンウェイト・CVD・SIRT

ここから先を読むために、3つの言葉を押さえておきます。どれもニュースでは説明抜きで使われがちですが、意味が分かると話の構造が一気に見えます。

2-1. オープンウェイトとは — 「オープンソース」とは別物

オープンウェイト（open-weights） とは、学習済みモデルの 重み（パラメータ）のファイルが配布されることを指します。ダウンロードすれば、自分の GPU やサーバーで、外部のAPIを一切叩かずにモデルを動かせます。

混同されやすいのが「オープンソース」です。ソフトウェアの世界でオープンソースと言えば、ソースコードが公開され、改変・再配布の自由がライセンスで保証されていることを意味します。ところが LLM の場合、公開されるのはたいてい重みだけで、学習に使ったデータも、学習を再現するコードも公開されないのが普通です。つまり「レシピは非公開のまま、完成品だけを持ち帰れる」状態で、伝統的なオープンソースの定義には届きません。ライセンスも OSI 承認のものとは限らず、用途制限が付くことがあります。

オープンソース（従来のソフトウェア） オープンウェイト（LLM）
公開されるもの ソースコード一式 学習済みの重みファイル
再現できるか ビルドすれば同じ物ができる 学習データ・手順は非公開で再現不可が通例
自由の範囲 ライセンスが改変・再配布を保証 独自ライセンスで用途制限が付く場合がある

重みが手元に来ると何ができるか。社内の閉じたネットワークで動かせる、ファインチューニングで自分のドメインに寄せられる、そして——ここが今回の論点ですが——提供元が課したガードレールを外側から取り外す改変も、技術的には可能になります。だからこそ Z.ai は、サイバー能力が想定外に伸びたこのモデルについて、重み公開を安全性評価の後ろに置いたわけです。オープンウェイトのライセンス条件そのものについては、Kimi K3 の記事で詳しく掘っています。

2-2. 協調的脆弱性開示（CVD）とは — 「直ってから公表する」ための手順

CVD（Coordinated Vulnerability Disclosure／協調的脆弱性開示） は、脆弱性を見つけた人がいきなり世界に公表するのではなく、まず開発側に非公開で伝え、修正が用意できてから足並みを揃えて公表するという手順の総称です。

なぜ順番が重要なのか。攻撃者にとって、修正パッチが存在しない脆弱性（ゼロデイ）は武器になります。逆に、修正が先に出回っていれば、同じ発見は「更新すれば終わる既知のバグ」に変わります。同じ発見でも、公表の順番だけで意味が正反対になるわけです。

この手順を回すために、業界共通の道具立てが使われます。脆弱性に一意の識別子を振る CVE、深刻度を数値化する CVSS、情報をどこまで共有してよいかを色で示す TLP（TLP:RED は「受け取った本人限り」）、悪用されやすさを推定する EPSS などです。用語がやたら多く見えますが、やっていることは「誰に・どこまで・いつ話すかを、関係者全員で同じ定義に揃える」ことに尽きます。

2-3. SIRT とは — 報告を受け止める常設の窓口

SIRT（Security Incident Response Team） は、セキュリティ上の報告や事案を受け付け、切り分け、対応をまとめる常設のチームです。大企業なら自前で持っていますが、OSS プロジェクトの多くは事情が違います。

現実の OSS は、週末に無償で保守している個人が支えている部分が非常に大きい。そこへ複数の研究者・複数の企業から、形式もばらばらな脆弱性報告が個別に飛んできます。しかも近年は AI が生成した精度の低い報告（いわゆるスラップ報告）も混ざる。受け取る側にとっては、まず「本物かどうか」を判定する作業だけで消耗するという構図です。

SIRT を共有するというのは、この受け口を 1つにまとめてしまうという発想です。ここが Akrites の設計の中心にあります。

⚙️ 3. 「事後学習だけで伸びた」は何が面白いのか

技術的にいちばん興味深いのは、GLM-5.3 が 新しく事前学習をやり直していないことです。

大規模モデルの作り方は、大きく2段階に分かれます。膨大なテキストを読ませて土台の言語能力を作る 事前学習（pre-training）、そのあとに人間の好みや道具の使い方、長い作業の進め方を教え込む 事後学習（post-training） です。従来、「性能を上げる」といえば事前学習をやり直す——より大きなモデル、より多いデータ、より多い計算——という話になりがちでした。

GLM-5.3 は、公式ドキュメントによれば GLM-5.2 と同じベースモデルを使い、改善はすべて事後学習に由来するとされています。伸ばした先は、タスク環境の種類と数、そして学習の長さです。パラメータ規模については、GLM-5.2 のベースが 743B クラス（Mixture-of-Experts でトークンあたりの活性は約 40B）と報じられていますが、GLM-5.3 単体のモデルカードは公開されておらず、この数値はベース側の情報からの推定であることに注意が必要です。

ここから読み取れることが2つあります。ひとつは前向きな話で、能力の伸びしろが「全部学習し直す」以外の場所にもあるということ。事前学習の計算資源を持てるプレイヤーは世界に数えるほどしかいませんが、事後学習の工夫はもう少し多くの手に届きます。

もうひとつは、慎重に扱うべき話です。ベースが同じでも能力の質が変わりうるなら、「土台が同じだから性質も同じはず」という前提で安全性を評価することはできないことになります。Z.ai が重み公開を後ろ倒しにしたのは、この理屈と噛み合います。ここは筆者の読みであって、Z.ai がそう説明しているわけではありません。

🛡️ 4. 守り側の再設計 — Akrites の3つの仕組み

さて、本題の後半です。AI が脆弱性を大量に見つけられるようになると、受け止める側が詰まります。2,383 件が禁輸中という数字は、裏を返せば「これから順次、修正と公表の工程を通る必要がある案件が 2,383 件ある」という意味でもあります。

Linux Foundation が 2026年6月25日に発足させた Akrites は、まさにこの詰まりを解くための枠組みです。名前はビザンツ帝国の辺境守備兵 Akritai（脅威が最初に到達し、防御が最も薄い場所に立った兵）に由来します。創設メンバーには Anthropic・AWS・Google・IBM・Microsoft/GitHub・NVIDIA・OpenAI・Red Hat・Rust Foundation・Cisco・Citi・JPMorganChase・Ericsson・Vodafone・Zscaler など20組織が名を連ねています。

仕組みは3つです。

仕組み 何をするか 解こうとしている問題
共有 SIRT 報告を1か所で受け、重複排除・妥当性検証・深刻度評価を行ってから上流のメンテナへ渡す 個人メンテナに、形式もばらばらな報告が各所から直接飛んでくる
統一 CVD CVE・TLP・CWE・CVSS・EPSS・SSVC・VEX・VINCE に基づく単一の開示手順。全員が同じ開示ウィンドウに入る 参加者ごとに開示のタイミングと基準が違い、誰かが先に走ると他が危険にさらされる
最後の砦としてのメンテナ 重要なのに保守されていないパッケージについて、Akrites 側が保守責任を引き受ける 直す人がいないパッケージは、脆弱性が判明しても修正が永遠に出ない

3つ目が個人的にはいちばん重い項目です。「重要だが誰も面倒を見ていない依存パッケージ」は、脆弱性が見つかった瞬間に手詰まりになります。 報告先も、パッチを書く人も、リリースする権限を持つ人もいない。ここに「最後の砦」を置くという発想は、技術というより制度の設計です。

公開されている CVD の流れは4段階です。図にすると、AI が効いてくるのが左端だけではないことが見えてきます。

graph LR
    A["発見
研究者・AIによる探索"] --> B["Intake
TLP:RED で受付"]
    B --> C["SIRT が
重複排除・検証"]
    C --> D["修正
メンテナ／不在なら Akrites"]
    D --> E["同期開示
CVE 付与・一斉公表"]
    E --> F["利用者へ
アップデートとして到達"]

左端（発見）は AI ですでに加速しました。GLM-5.3 の 2,436 件は、その速度を数字にしたものです。一方で、真ん中の3工程——重複排除・修正・同期開示——は人と組織の仕事であり、ここが詰まれば全体のスループットは上がりません。Akrites は、発見の加速に合わせて 中間工程を作り直す動きだと読めます。

運営は Linux Foundation の指定基金 Alpha-Omega のシード資金で始まっています。会費は Premier 25万ドル／General 20万ドルという水準で、OSS 財団やプロジェクト側は Associate として無償（理事会からの招待制）。負担する側と守られる側を分けた設計になっている点は、素直に理にかなっています。

💡 ワード解説：TLP（Traffic Light Protocol）

受け取った情報をどこまで再共有してよいかを、色で示す共通ルールです。TLP:RED は「この場にいる本人限り、転送禁止」、TLP:CLEAR は「制限なし」。脆弱性の情報は修正が出るまで TLP:RED で扱われ、同期開示のタイミングで一斉に公開側へ移ります。組織をまたいで秘密を扱うとき、言葉の解釈でズレないようにするための約束事です。

🤝 5. 攻めと守りが同時に動いている夏

この2つのニュースは、単独で見るより並べて見るほうが立体的になります。

攻め側では、OpenAI が GPT-5.6-Cyber で Chrome の V8 のゼロデイを先に発見し、Google が修正した例が8月に出ていますし、Black Hat / DEF CON 34 では自律AIエージェントによる攻防が正面のテーマになりました。実害の側でも、npm を襲った自己増殖ワーム ChainDrop のように、供給網（サプライチェーン）を直接狙う攻撃が現実に走っています。AWS が北朝鮮系の脅威アクターによる OSS ライブラリへの標的化を特定して公表したのも、同じ流れの中の出来事です。

守り側にも、実際に金と人が入り始めています。AWS・Anthropic・Google・Microsoft・OpenAI の5社は、Linux Foundation と共同で 総額1,250万ドル（うち AWS が250万ドル）の拠出を発表しました。使途は「メンテナが正当な脆弱性を素早く検証して修正できるようにし、低品質な報告をふるい落とすためのツール・自動化・リソース」とされています。

🗓️ 拠出先について（正確を期すために）

この1,250万ドルは、AWS の公式ブログでは Alpha-Omega および OpenSSF への拠出として説明されており、Akrites への出資とは明記されていません。Akrites のシード資金が同じ Alpha-Omega から出ているため関係は近いのですが、「AWS が Akrites に1,250万ドルを出した」という書き方は正確ではないため、本記事では分けて記載しています。

同じ AWS の記事には、Anthropic の Claude Opus 4.6 が調査の中で 500件を超える高深刻度の脆弱性を発見・検証したという記述もあります。GLM-5.3 の 2,436 件と合わせて眺めると、「AI がバグを見つけること」はもはや一社の主張ではなく、複数のベンダーで同時に起きている現象だと分かります。

面白いのは、この現象が オープンウェイトの側でも起きていることです。オープンウェイトのモデルが商用のコーディング支援の一等地に入り始めたことは、GitHub Copilot に Kimi が採用された件でも見た通りで、GLM-5.3 の重みが8月下旬に公開されれば、手元のマシンで動く脆弱性探索器という選択肢が現実味を帯びます。これは防御側にとっても大きな話で、社外に出せないコードを外部APIに投げずに監査できる、という使い方が開けます。

📌 筆者の見方

筆者はセキュリティの専門家ではなく、ESP32 のファームウェアを書いて基板を起こし、KiCad と ESP-IDF を日常的に触っている側の人間です。その立場でいちばん刺さったのは、2,436 件でも 84.5% でもなく、Akrites の「最後の砦としてのメンテナ」でした。

正直に書くと、筆者は自分のプロジェクトが依存しているライブラリについて、最後のコミットがいつだったかを数えたことがありません。Arduino のライブラリマネージャや ESP-IDF のコンポーネント、Hugo のツールチェーンで入ってくる npm パッケージまで含めれば、名前も覚えていない依存が相当数あるはずです。「使えているから問題ない」で通してきました。今回の件で、その前提が 見つかっていなかっただけ かもしれないと突きつけられた感覚があります。

そのうえで、これは意見ですが、この状況は悲観する話ではないと受け止めました。2,383 件の禁輸案件は、いずれ修正として降りてきます。降ってきたときに受け取れる状態でいるかどうかが、個人の側でできる備えのほぼすべてです。ここで組み込みが厄介なのは、更新経路が最初から存在しない機器が多いこと。手元の試作は書き込み直せばいいとしても、人に渡した基板やケースに封じた個体は、そもそもファームを更新する手段を用意していなければ直せません。まずやることは決まりました——依存の棚卸しと、次に作る物に OTA か少なくとも書き込み口を残しておくこと。派手ではありませんが、「見つける速度」の話に個人が追いつく道は、たぶんそこしかありません。

まとめ

  • Z.ai は 2026年8月14日に GLM-5.3 を公開しました。公式ドキュメントによれば GLM-5.2 と同じベースモデルを使い、性能向上はすべて事後学習に由来します。コンテキストは 1M トークンです。
  • Z.ai の発表によれば、このモデルを使って 269 のオープンソースプロジェクトから 2,436 件の脆弱性（うち critical / high が 1,097 件）を検出。公開時点で 53 件が CVE 付きで公表済み・2,383 件が禁輸中です。いずれも第三者の独立検証を経た数値ではありません。
  • オープンウェイト（重みの配布）は、ソースコードと学習手順まで公開する従来のオープンソースとは別物です。重みが手に入るとガードレールの除去も技術的に可能になるため、Z.ai は公開を安全性評価の後（8月下旬予定）に置いています。
  • 見つかった脆弱性を実際に直して届ける側の枠組みが、Linux Foundation が 2026年6月25日 に発足させた Akrites です。共有 SIRT・統一 CVD・最後の砦としてのメンテナの3本柱で、20組織が創設メンバーに名を連ねています。
  • 発見の速度が上がることは、それ自体は防御側の前進です。詰まるとすれば 重複排除・修正・同期開示という中間工程であり、そこを作り直す動きが同じ年に始まっている——これがこの夏の構図です。

よくある質問（FAQ）

Q. GLM-5.3 は今すぐ手元にダウンロードして使えますか？

A. 執筆時点では使えません。Z.ai は公開時に、安全性評価とハードニングの完了後、約2週間後（2026年8月下旬）に重みを公開する予定と発表しています。それまでは GLM Coding Plan や ZCode 経由での利用になります。汎用 API は公式ドキュメント上で「coming soon」の扱いです。

Q. 「オープンウェイト」と「オープンソース」は何が違うのですか？

A. オープンウェイトは学習済みの重みファイルだけが配布されることを指します。学習データや学習を再現するコードは通常公開されないため、ソースコード一式が公開され改変・再配布の自由がライセンスで保証される従来のオープンソースとは別物です。ライセンスも OSI 承認のものとは限らず、用途制限が付くことがあります。

Q. 協調的脆弱性開示（CVD）とは何ですか？

A. 脆弱性を見つけた人がいきなり公表せず、まず開発側に非公開で伝え、修正が用意できてから足並みを揃えて公表する手順のことです。修正パッチが存在しない状態で情報が出ると攻撃に使われてしまうため、公表の順番そのものが防御の一部になります。CVE・CVSS・TLP といった共通の道具立てを使い、関係者の定義とタイミングを揃えて運用します。

Q. 2,436 件という数字はそのまま信じてよいのですか？

A. Z.ai 自身の発表値であり、独立した第三者による検証を経た数値ではありません。専門家によるレビュー・スクリーニング・重複排除を通したものとされていますが、本記事ではその旨を明示したうえで紹介しています。同じ性質の数値として、Claude Opus 4.6 が500件超の高深刻度脆弱性を発見・検証したという AWS 公式ブログの記述もあります。

Q. Akrites に個人開発者は参加できますか？

A. Akrites の会員は Linux Foundation の会員であることが前提で、Premier が25万ドル、General が20万ドルという水準です。ただしオープンソース財団やプロジェクトは Associate として無償（Governing Board からの招待制）で参加できる枠が用意されています。個人開発者が費用を払って参加する枠組みではなく、自分が依存しているプロジェクトが守られる形で恩恵が届く設計です。

Q. 個人開発者や趣味の電子工作をしている側は、何をすればよいですか？

A. 特別な対応は不要ですが、更新を受け取れる状態を保つことが実質的にすべてです。ライブラリやツールチェーンを最新に保つこと、依存パッケージの保守状況を一度棚卸ししてみること、そして自作の機器についてはファームウェアを後から書き換える手段（OTA や書き込み口）を残しておくこと。修正が出ても、届く経路がなければ意味がありません。

Q. AI が脆弱性を大量に見つけると、かえって危険なのではないですか？

A. 見つかった脆弱性は「AI が作った」のではなく、もともと存在していたものが可視化されただけです。危険が増すとすれば、可視化された情報が修正より先に攻撃側へ渡る場合で、だからこそ協調的開示の手順と、それを回す組織（SIRT）が重要になります。今回 Akrites を並べて読んだのは、この点が両輪だからです。

参考

関連記事