Claude Mythos 騒動を、単に「危険な AI が出た」という物語として読むと、問題の本質を取り逃がす。Anthropic は Project Glasswing と Claude Mythos Preview を、重要ソフトウェアの防御に使う研究プレビューとして位置づけた一方で、その能力が攻撃にも転用されうることを認めている[1][2]。UK AI Security Institute は Mythos Preview の CTF 課題や多段階サイバー攻撃シミュレーションでの能力向上を評価し、欧州委員会や米国政府もこの種のモデル評価に関与し始めている[3][4][5]。したがって、ここで起きているのは、封印された怪物が突然暴れ出したという話ではない。人間社会の観測能力が急上昇したとき、発見、開示、修正、責任、制度をどう再設計するかという問題である。
この構図は GPT-2 の公開時にも先取りされていた。OpenAI は 2019 年に GPT-2 の段階的公開を選び、社会的影響と悪用可能性を評価する時間を設けると説明した[6]。その後、最大 1.5B パラメーター版は段階的公開の最終段階として公開され、OpenAI はその過程を責任ある公開規範の実験として位置づけた[7][8]。当時の主な懸念は大量生成テキストによる情報環境の汚染だったが、Claude Mythos 騒動では焦点がサイバー能力へ移った。能力の種類は違うが、構造は同じである。つまり、モデル公開は単なる技術提供ではなく、社会の脆弱性観測面を変える行為である。
本稿は、CVE-2026-31431、いわゆる Copy Fail を具体例として扱う。既稿ではこの脆弱性を Linux カーネルの AF_ALG、algif_aead、splice、ページキャッシュ、setuid root バイナリの意味境界破綻として詳述した[9]。NVD、Debian Security Tracker、Microsoft、Theori、CERT-EU の情報を総合すると、これはカーネルの暗号サブシステムにおける in-place 操作の設計不備が、ローカル権限昇格へ接続した事例である[10][11][12][13][14]。重要なのは、この事例を「 AI がゼロデイを見つけたから危険だ」という平板な反応で終わらせないことである。Copy Fail が示したのは、読み取り可能なもの、書き込み可能なもの、ページキャッシュ、暗号 API、ゼロコピー、setuid root バイナリ、ファイル完全性検査、実行時状態といった複数の意味境界が、特定条件で接続されると、局所的には正当に見える処理の合成が、全体として不正な経路を生むという構造である。
| 導入で扱う論点 | 表面的な見え方 | 本稿での読み替え | 後続章への接続 |
|---|---|---|---|
| Claude Mythos 騒動 | 危険な AI が登場し、未知の攻撃能力が社会へ出てきたように見える。 | AI によって、既存ソフトウェアや制度の潜在的不整合が従来より速く観測されるようになった出来事として読む。 | 1 章で、騒動が露出させた観測能力の上昇を整理する。 |
| GPT-2 との連続性 | 過去にも AI モデル公開をためらった事例があったという歴史的類似に見える。 | 能力公開が社会の処理速度を超える可能性をどう扱うかという構造的連続性として読む。 | 2 章で、自然文生成からサイバー探索へ移った公開問題を比較する。 |
| CVE-2026-31431 | AI がゼロデイを見つけた危険な事例として見える。 | 複数の意味境界が接続点で破綻し、局所的には正しい処理の合成が全体として不正経路を作る事例として読む。 | 4 章で、Copy Fail を意味境界の破綻として詳述する。 |
| AI による弱点探索 | 攻撃者がより楽に脆弱性を探せるようになる問題に見える。 | 攻撃者にも防御者にも観測能力を与えるデュアルユース能力として読む。 | 5 章と 6 章で、悪意ある利用者と防御者の双方に何が変わるかを分ける。 |
| 修正責任 | 誰が悪いか、誰が AI を止めるべきかという責任追及に見える。 | 観測された不整合を、攻撃履歴へ流す前に修正履歴へ変換する責任配分として読む。 | 24 章以降で、修正責任を数理モデルと構造振動モデルへ接続する。 |
AI による弱点探索が強くなると、この種の意味境界の破綻は、より速く、より広く、より低コストで観測されるようになる。ここで問うべきなのは、AI が世界に新しい脆弱性を作ったのかではない。多くの場合、脆弱性はすでに構造の中に潜在している。AI が変えるのは、その潜在的不整合が発見される速度、候補化される範囲、攻撃または修正へ接続されるまでの時間である。ゼロデイは個別には一回限りのカードだが、発見プロセスそのものは継続的能力になる。したがって、社会は「未知の一件を恐れる段階」から、「継続的に見つかる不整合をどの順番で処理するか」という段階へ移る。
この変化は、攻撃者だけに有利なものではない。AI は攻撃者に探索コストの低下をもたらすが、防御者にも同じく観測能力の向上をもたらす。古いコード、低頻度機能、例外処理、依存関係、仕様差分、権限境界、ログ、設定の不整合を、人間だけでは読み切れなかった範囲まで調べられるようになる。問題は AI の善悪ではない。観測された不整合が、攻撃履歴へ流れるのか、修正履歴へ流れるのかである。AI が出力する候補を、誰が受け取り、誰が検証し、誰が修正し、誰が適用し、誰が説明するのかが決定的になる。
| AI が観測した不整合の流れ先 | 接続先 | 社会的結果 | 本稿での評価 |
|---|---|---|---|
| 攻撃履歴へ流れる | 攻撃者、PoC、exploit chain、権限昇格、横展開。 | 未修正環境で侵害、情報漏洩、業務停止、検知回避が起きる。 | AI の危険性は、観測能力が攻撃工程へ接続されたときに現実化する。 |
| 修正履歴へ流れる | 防御者、CVD、ベンダー、OSS 保守者、パッチ、監視。 | 未発見欠陥が早期に修正され、危険窓が短くなる。 | AI の有用性は、観測能力が修正工程へ接続されたときに現実化する。 |
| 騒動履歴へ流れる | メディア、企業発信、政府発信、SNS、政策議論。 | 危機感、誇張、規制要求、能力宣伝、社会的不安が生じる。 | 騒動強度と実技術リスクを分けなければ、判断を誤る。 |
| 未処理履歴へ残る | 未分類チケット、放置された指摘、未適用パッチ、例外管理。 | 観測だけが増え、修正能力が追いつかず、残存リスクが積み上がる。 | AI 導入だけでは安全にならず、更新可能性の実装が必要になる。 |
本稿では、この問題を三つの層で整理する。第一に、Claude Mythos 騒動を、GPT-2 の段階的公開から続く「能力公開と社会的処理速度」の問題として読む。第二に、CVE-2026-31431 を、意味境界の破綻と局所正当性の合成失敗として読み、AI による弱点探索が何を可視化するのかを確認する。第三に、構造振動モデルへ接続し、脆弱性を潜在振動、AI 探索を観測能力の増幅、CVE やアドバイザリをラベル化、パッチを位相修正、更新適用と監視を履歴固定として捉え直す。
本稿の最終的な結論は、AI 時代の安全性とは、欠陥が存在しないことではなく、観測された不整合を、攻撃履歴へ発散させる前に、修正履歴へ変換し続ける社会的能力である、という点にある。AI は観測能力を上げる。しかし、修正責任を代替しない。見えなかったものが見えるようになった社会では、人間、組織、制度、運用が、見えてしまった不整合をどう受け取り、どう責任を配分し、どう修正し、どう履歴へ固定するかを引き受けなければならない。Claude Mythos が変えたのは、AI が怪物になったという事実ではない。人間社会が、自分たちの脆弱性をより高解像度で見せられる段階に入ったという事実である。
1. Claude Mythos 騒動は何を露出させたのか
Claude Mythos 騒動の中心にあるのは、AI が突然、新しい悪意や攻撃意図を生み出したという話ではない。より正確には、既存のソフトウェア、仕様、依存関係、運用、セキュリティ境界の中に潜在していた不整合を、従来よりも広く、速く、継続的に探索できるようになったことが露出したのである。ソフトウェアの脆弱性は、攻撃者が発見した瞬間に発生するものではない。多くの場合、それは以前からコードや設計や運用の中に存在している。人間が読めなかった、レビューが届かなかった、テストが通らなかった、複数サブシステムの相互作用としてしか表面化しなかったために、観測されていなかっただけである。Claude Mythos 型の AI は、この「まだ観測されていない不整合」へ強い光を当てる装置として現れた。
ここで重要なのは、AI による弱点探索を、単なるコード検索や静的解析の延長としてだけ見ないことである。従来の静的解析は、既知の危険パターン、型、メモリ操作、未初期化変数、境界外アクセス、危険 API の利用などを機械的に検出する性格が強かった。fuzzing は、入力空間を大量に揺さぶることで、クラッシュや未定義動作や異常経路を露出させる方法である。これに対して、高性能な AI モデルによる探索は、コード、仕様、コメント、過去の脆弱性、テスト、依存関係、実行経路、エラー処理、権限境界をまたいで、「この組み合わせなら意味境界が破れるのではないか」という仮説を生成できる。つまり、AI が強くなることで増えるのは、単なる検査量ではなく、構造横断的な仮説生成能力である。
Claude Mythos 騒動が強い反応を招いた理由もここにある。もし問題が「AI がコードを速く読める」だけであれば、それは開発支援ツールの延長で済む。しかし、AI が未知の脆弱性候補を発見し、到達可能性を推定し、既存の攻撃部品と接続し、場合によっては exploit chain の構成まで支援できるなら、話は変わる。この能力は、防御者にとっては未発見の欠陥を攻撃者より先に見つける手段である。一方で、攻撃者にとっては、標的調査、候補探索、PoC 作成、権限昇格、横展開の準備を圧縮する手段になる。同じ能力が、修正にも侵害にも接続する。ここに、AI セキュリティ問題の典型的なデュアルユース性がある。
| 探索手段 | 主に得意なこと | 限界 | Claude Mythos 型 AI が変える点 |
|---|---|---|---|
| 人間レビュー | 設計意図、仕様の不自然さ、権限境界、運用上の危険を文脈込みで読む。 | 時間、専門知識、注意力、担当範囲に限界があり、巨大コード全体を継続的に読むことは難しい。 | 人間が立てるべき仮説の範囲を広げ、見落とされやすい接続点を候補として出せる。 |
| 静的解析 | 危険 API、型不整合、メモリー安全性、既知パターン、設定ミスを広く検出する。 | 仕様横断的な意味境界の破綻や、複数サブシステムの合成失敗は拾いにくい。 | 検出結果の意味づけ、関連コードの要約、脆弱性候補の仮説化を補助できる。 |
| fuzzing | 入力空間を揺さぶり、クラッシュ、未定義動作、境界条件不備を実行時に露出させる。 | 入力生成や harness の設計に依存し、権限境界や運用文脈まで自動で読めるわけではない。 | fuzzing の結果を解釈し、再現手順、影響範囲、修正候補へつなげやすくする。 |
| AI 支援探索 | コード、仕様、コメント、過去 CVE、テスト、依存関係、権限境界を横断して仮説を生成する。 | 誤検知、過信、検証不足、危険出力、攻撃側への転用というリスクがある。 | 単なる検査量ではなく、構造横断的な仮説生成能力を増幅する。 |
ただし、この時点で「AI が自律的に世界中のシステムを破壊し始めた」と考えるのは過剰である。現実の攻撃には、脆弱性候補の発見だけでなく、対象環境への到達、バージョン差分の確認、設定差分の吸収、認証情報の取得、ネットワーク制約の突破、検知回避、永続化、運用上の判断が必要になる。脆弱性候補を発見する能力と、実環境で安定して侵害を成功させる能力は同じではない。この区別を失うと、議論はすぐに「封印された怪物が暴れ出した」という物語へ流れる。しかし、冷静に見るなら、Claude Mythos 騒動の本質は怪物性ではなく、観測能力の上昇である。
観測能力の上昇とは、これまで人間社会が暗黙に依存していた「見つからないことによる安定」が失われることを意味する。巨大なソフトウェアシステムは、完全に正しいから安定しているのではない。多くの場合、未発見の不整合が、たまたま通常入力では露出せず、たまたま攻撃者に見つからず、たまたま運用上の条件と結びつかなかったために、安定しているように見えている。AI による探索能力が上がると、この見かけ上の安定は揺さぶられる。問題が新たに発生したのではなく、問題が観測可能になったことで、社会の側が「知らなかった」と言いにくくなる。
この変化は、セキュリティ実務の責任構造を変える。従来は、既知の CVE を放置すること、公開済みパッチを適用しないこと、明確な advisory を無視することが主な責任問題だった。しかし、AI 支援探索が普及すると、「発見可能だった弱点をなぜ見つけなかったのか」「AI 監査や fuzzing や依存関係確認をなぜ工程に入れていなかったのか」「見つかった候補をなぜ検証しなかったのか」「修正可能だったのになぜ放置したのか」が問われるようになる。責任は、既知脆弱性への反応から、観測可能性を前提にした継続的な修正体制へ移る。
この点で、Claude Mythos 騒動は単なる AI モデル公開問題ではない。問題は、強力な探索能力を誰が持つのか、誰に渡すのか、どの範囲で使わせるのか、出力をどう制限するのか、発見された脆弱性をどの順序で誰へ通知するのか、修正までの間に情報をどう管理するのか、限定提供された能力が漏洩した場合に誰が責任を負うのか、という統治問題である。完全公開すれば攻撃者にも渡る。完全秘匿すれば一部企業や政府だけが高度な探索能力を独占する。したがって、問題は公開か封印かの二択ではなく、監査、アクセス制御、責任ある開示、修正能力、第三者評価を含む中間制度の設計である。
また、メディアや企業発信の強い言葉にも注意が必要である。企業は自社モデルの能力を強調する動機を持つ。政府は安全保障上の懸念を強調する動機を持つ。メディアは「AI がゼロデイを発見した」「攻撃 AI が生まれた」「危険すぎて公開できない」といった強い表現を選びやすい。これらは完全な虚偽ではないとしても、能力の性質、実運用での制約、防御側の利益、開示制度、修正工程を単純化する。冷静に判断するには、脆弱性候補の発見、再現可能なバグ、実際にセキュリティ境界を越える脆弱性、安定した exploit、攻撃チェーンに組み込める部品を分けなければならない。
| 混同されやすい段階 | 実際の意味 | 過剰に読むとどうなるか | 冷静な評価 |
|---|---|---|---|
| 脆弱性候補 | AI や解析手段が、不整合の可能性として提示した段階。 | 候補が出ただけで、即座に重大ゼロデイが発見されたと誤解する。 | 再現性、到達可能性、セキュリティ境界への影響を確認する必要がある。 |
| 再現可能なバグ | 特定条件で不具合や異常動作が確認できる段階。 | すべてのバグを攻撃可能な脆弱性として扱ってしまう。 | 権限、到達性、機密性、完全性、可用性への影響を分けて評価する。 |
| 脆弱性 | 実際にセキュリティ境界を破る、または保護目標を損なう欠陥。 | 脆弱性があるだけで、すでに大規模侵害が起きていると受け取る。 | 悪用可能性、対象範囲、修正状況、既知悪用の有無を確認する。 |
| 安定した exploit | 実環境で再現性高く攻撃へ使える手順やコード。 | 限定的な PoC を、任意環境で使える攻撃兵器のように扱う。 | 環境依存性、成功率、前提権限、検知可能性を評価する。 |
| 攻撃チェーン | 初期侵入、権限昇格、横展開、永続化、目的達成まで接続された流れ。 | 単一の脆弱性を、即座に完全侵害へ直結するものとして煽る。 | 複数条件の連結、運用上の制約、防御側検知、補完統制を含めて見る。 |
したがって、Claude Mythos 騒動が露出させたものは、AI の危険性だけではない。むしろ、人間社会の修正能力の不足である。AI が弱点を見つける速度が上がるほど、発見後のトリアージ、再現確認、影響範囲評価、パッチ作成、テスト、リリース、利用者通知、パッチ適用、再観測の遅さが目立つようになる。観測能力だけが上がり、修正能力が追いつかなければ、社会には未処理の不整合が積み上がる。これは安全性の向上ではなく、不安定性の可視化である。
この章で押さえるべき結論は明確である。Claude Mythos 騒動は、AI が悪意を持って暴れ出したという話ではない。AI によって、ソフトウェアと社会制度の中に潜んでいた不整合が、従来よりも高い解像度で観測され始めたという話である。問題の中心は、観測能力の上昇そのものではなく、その観測結果を人間社会がどのように解釈し、優先順位をつけ、修正し、履歴として固定するかである。つまり、この騒動は「AI を封印するかどうか」ではなく、「観測能力が上がった社会で、人間が修正責任をどう引き受けるか」という問題を露出させたのである。
| 見方 | 内容 | 問題点 | 本稿で採用する見方 |
|---|---|---|---|
| 怪物化モデル | AI が危険な攻撃能力を持ち、封印を解かれると社会へ破壊的影響を与えると見る。 | 脆弱性候補の発見、実環境での悪用、攻撃運用、被害発生を一続きに単純化してしまう。 | AI が悪意を持つのではなく、人間が作った構造の弱点を高解像度で観測する能力が上がったと見る。 |
| 単なるマーケティング騒動モデル | 企業やメディアが AI の能力を誇張し、危機感を煽っているだけだと見る。 | 実際に探索能力が上がり、脆弱性発見や攻撃補助に使える可能性を過小評価してしまう。 | 誇張は割り引くが、弱点探索の限界費用が下がる構造変化は本物として扱う。 |
| 防御ツールモデル | AI を未発見の脆弱性を見つける防御側の監査ツールとして見る。 | 同じ能力が攻撃者にも使えるデュアルユース性を見落としやすい。 | 防御にも攻撃にも接続する能力として扱い、公開範囲、監査、修正能力を問題にする。 |
| 観測能力モデル | AI によって、既存構造に潜在していた不整合が従来より速く、広く、継続的に観測されると見る。 | 観測された問題をどう修正するかまで扱わなければ、単なる発見論で止まる。 | 観測能力の上昇を出発点に、人間社会の修正責任、制度設計、構造振動モデルへ接続する。 |
2. GPT-2 の段階的公開との連続性
Claude Mythos 騒動を考えるうえで、GPT-2 の段階的公開は重要な前史である。ただし、ここで確認すべきなのは、「過去にも AI モデルの公開をためらった事例があった」という単純な類似ではない。重要なのは、GPT-2 と Claude Mythos が、能力の種類は違っていても、同じ公開問題の構造を持っている点である。すなわち、モデルが新しい能力水準に達したとき、その能力をすぐ全面公開してよいのか、段階的に公開すべきなのか、限定された相手にだけ提供すべきなのか、あるいは一定期間秘匿すべきなのかという問題である。この問題は、モデルの性能評価だけでは決まらない。公開された能力を社会側がどう受け止め、どう悪用を防ぎ、どう利益へ変換し、どう責任を分配するかという制度設計の問題だからである。
GPT-2 の場合、中心にあったのは自然文生成能力だった。当時問題視されたのは、もっともらしい文章を大量に生成できるモデルが、偽ニュース、スパム、なりすまし、レビュー操作、世論操作、プロパガンダに使われる可能性である。つまり、GPT-2 が露出させたのは、情報空間における生成能力のリスクだった。ここで問われたのは、「文章生成モデルが一定水準を超えたとき、社会はその生成物をどう検証し、どう流通させ、どう責任を負うのか」である。モデルそのものが悪意を持つわけではない。しかし、モデルが生成する自然文が人間の認知、信頼、報道、政治、広告、コミュニケーションへ流れ込むと、既存の情報検証制度が処理しきれない可能性があった。
Claude Mythos の場合、中心にあるのは自然文生成ではなくサイバー探索能力である。問題は、説得力のある文章を大量に作れることではなく、ソフトウェアの未知の弱点を探索し、脆弱性候補を発見し、到達可能性を推定し、場合によっては exploit chain の構成へ接続できることである。したがって、Claude Mythos が露出させたのは、情報空間ではなく、実システムの攻撃面に対する探索能力のリスクである。GPT-2 では「情報が汚染されるか」が問題だったのに対し、Claude Mythos では「システムの弱点が大量に掘り起こされるか」が問題になる。両者は対象領域が異なるが、能力公開が社会制度の処理能力を上回るかもしれないという構造は共通している。
| 比較軸 | GPT-2 での形 | Claude Mythos での形 | 構造的に共通する点 |
|---|---|---|---|
| 能力の対象 | 自然文、情報流通、説得力、生成物の大量流通。 | コード、仕様、依存関係、実行経路、脆弱性候補。 | 人間社会が従来の速度では処理しきれない出力を生む。 |
| 圧迫される制度 | メディア、プラットフォーム、出所確認、情報検証、モデレーション。 | CVD、CVE 管理、ベンダー修正、OSS 保守、パッチ適用、監視。 | モデル能力より、社会側の受け取り能力が問われる。 |
| 悪用の形 | 偽情報、スパム、なりすまし、レビュー操作、世論操作。 | 脆弱性探索、PoC 作成、攻撃チェーン構成、権限昇格支援。 | 能力そのものではなく、既存の脆弱な制度や環境へ接続されたときに被害が生じる。 |
| 正当利用の形 | 文章作成、要約、翻訳、教育、創作支援。 | 防御的コードレビュー、脆弱性監査、fuzzing 補助、修正支援。 | 利益も大きいため、全面禁止ではなく利用条件と責任設計が必要になる。 |
| 公開判断の難しさ | 公開すれば研究と利用が進むが、偽情報リスクも増える。 | 公開すれば防御能力も上がるが、攻撃側の探索能力も上がる。 | 公開か封印かではなく、段階的公開、限定公開、監査、評価の設計が必要になる。 |
この二つの事例に共通する第一の点は、どちらもデュアルユース能力であることだ。GPT-2 の自然文生成は、要約、翻訳、文章補助、教育、創作に使える一方で、スパム、偽情報、なりすましにも使える。Claude Mythos 型の脆弱性探索は、未発見の欠陥を攻撃者より先に見つけて修正するために使える一方で、攻撃者が侵入経路を探すためにも使える。したがって、単純に「公開すれば善」「秘匿すれば悪」とは言えない。能力の公開範囲、利用条件、監査、出力制約、通報経路、責任主体を設計しなければ、同じ能力が社会的利益にも社会的被害にも接続する。
共通する第二の点は、公開判断が技術的判断だけでは済まないことである。モデルがどれだけ高性能か、ベンチマークでどれだけ強いか、研究としてどれだけ新しいかだけでは、公開範囲は決まらない。公開後に誰が使えるのか、悪用されたときに誰が検知できるのか、被害を受ける側は準備できているのか、制度は追いついているのか、社会は誤用を識別できるのか、といった要素が絡む。GPT-2 では、生成テキストを検証する社会的能力が問われた。Claude Mythos では、発見された脆弱性を受け取り、分類し、修正し、配布し、適用する社会的能力が問われている。
共通する第三の点は、段階的公開や限定公開が、それ自体で新しい統治問題を生むことである。全面公開を避けることには合理性がある。危険な能力を一気に広く配れば、悪用者にも渡るからである。しかし、公開を限定すると、今度は「誰が選ばれるのか」「選ばれた組織だけが能力を独占してよいのか」「評価基準は透明か」「政府や大企業だけが先端能力を持つことは公平か」「外部研究者や OSS 保守者はその能力へアクセスできるのか」という問題が出る。つまり、制限はリスクを下げる一方で、アクセス権の政治を生む。GPT-2 の段階的公開も、Claude Mythos の限定提供も、この緊張を共有している。
ただし、両者の違いも大きい。GPT-2 の主なリスクは、情報環境の信頼性を下げることだった。偽情報やスパムは社会的被害を生むが、多くの場合、その被害は認知、信頼、政治、メディア流通を介して間接的に現れる。これに対して、Claude Mythos 型のリスクは、実システムの侵害に直接接続し得る。脆弱性探索が成功すれば、権限昇格、認証回避、データ流出、横展開、サービス停止、サプライチェーン侵害へ進む可能性がある。したがって、Claude Mythos の方が、情報空間だけでなく、計算機システム、企業運用、金融、医療、公共インフラに近い場所で問題を起こし得る。
この違いから、GPT-2 との比較によって言えるのは、「今回も昔と同じ騒ぎだから大したことはない」ということではない。むしろ、GPT-2 のときに現れた公開規範の問題が、より実システムに近い領域へ移動した、と見るべきである。GPT-2 は、生成能力が情報制度の処理能力を超えるかもしれないという問題を示した。Claude Mythos は、探索能力がセキュリティ制度の処理能力を超えるかもしれないという問題を示している。つまり、比較から見えるのは、AI の能力公開問題が、文章生成から脆弱性探索へ、情報空間から実システムへ、認知的被害から運用的被害へ拡張しているという流れである。
さらに、この比較は「社会の受容能力」という観点を明確にする。技術の危険性は、能力単体では決まらない。社会がその能力を検証し、制御し、修正し、説明し、被害を回復できるかによって決まる。GPT-2 の場合、社会の受容能力とは、生成物の検証、プラットフォームのモデレーション、出所確認、メディアリテラシー、悪用検知だった。Claude Mythos の場合、社会の受容能力とは、脆弱性開示、CVE 管理、パッチ作成、ディストリビューション更新、再起動計画、OSS 保守者支援、企業のパッチ適用能力である。能力公開の是非は、この受容能力との関係で考えなければならない。
したがって、GPT-2 と Claude Mythos の類似から導ける結論は、AI の公開問題は毎回「危険か安全か」の二分法では解けないということである。正しく問うべきなのは、「その能力はどの社会的処理能力を圧迫するのか」「公開範囲をどう設計すれば利益を最大化し、悪用を抑えられるのか」「限定公開によって新たに生まれる権力差をどう監査するのか」「公開後に社会が修正・検証・回復できるのか」である。GPT-2 が生成情報の流通制度を問い直したように、Claude Mythos は脆弱性発見と修正の制度を問い直している。
この章の結論は、次のように整理できる。GPT-2 と Claude Mythos は、能力の対象が違う。前者は自然文生成であり、後者はサイバー探索である。リスクの現れ方も違う。前者は情報空間の信頼を揺らし、後者は実システムの安全性を揺らす。しかし、両者は、AI の能力が社会制度の処理速度を上回る可能性を露出させた点で同型である。そこから言えるのは、AI 時代の公開判断は、モデルの性能だけではなく、社会がその能力を受け止め、悪用を抑え、発見された問題を修正履歴へ変換できるかによって決まる、ということである。
| 観点 | GPT-2 の段階的公開 | Claude Mythos 騒動 | 比較から言えること |
|---|---|---|---|
| 中心能力 | 自然文を大量に生成し、人間が書いたように見える文章を作る能力。 | コード、仕様、依存関係、実行経路を横断し、未知の脆弱性候補や攻撃経路を探索する能力。 | 問題は AI 一般の危険性ではなく、各時代に社会制度を圧迫する能力の種類が変わることである。 |
| 主な影響領域 | ニュース、SNS、広告、レビュー、メール、政治的言説などの情報空間。 | OS、ブラウザー、クラウド基盤、OSS、企業ネットワーク、金融、医療、公共インフラなどの実システム。 | GPT-2 では情報の信頼性が揺らぎ、Claude Mythos ではシステムの安全性と修正体制が揺らぐ。 |
| 正当利用 | 文章作成支援、要約、翻訳、教育、創作、対話補助。 | 脆弱性監査、コードレビュー、fuzzing 補助、CVD 支援、OSS や基盤ソフトウェアの防御。 | どちらも社会的利益が大きいため、単純な禁止ではなく、利用条件と統治設計が問題になる。 |
| 悪用可能性 | 偽情報、スパム、なりすまし、レビュー操作、世論操作。 | 脆弱性探索、PoC 作成、exploit chain 構成、権限昇格、横展開、標的調査。 | 悪用は能力そのものから自動的に発生するのではなく、既存の社会的・技術的脆弱性へ接続されたときに発生する。 |
| 公開方式 | 小さいモデルから順に公開し、影響を観察しながら最大モデルへ進む段階的公開。 | 一般公開を避け、選定された企業・組織・防御関係者へ限定提供する形。 | 全面公開を避ける判断には合理性があるが、限定公開はアクセス権の政治と透明性の問題を生む。 |
| 社会側の処理能力 | 生成物の真偽確認、出所確認、プラットフォーム moderation、メディアリテラシー、悪用検知。 | 脆弱性トリアージ、CVE 管理、パッチ作成、リリース、更新適用、インシデント対応、OSS 保守支援。 | 公開判断はモデル性能ではなく、社会側が出力を処理し、被害を抑え、修正できるかで決まる。 |
| 制度的な問い | 生成 AI の公開規範、偽情報対策、プラットフォーム責任、生成物の検証。 | 高能力サイバー AI のアクセス制御、CVD、監査ログ、第三者評価、政府・企業・OSS の責任分担。 | AI 公開問題は「研究成果を出すかどうか」ではなく、能力が社会制度に入った後の責任設計である。 |
| 構造的な類似 | 生成能力が情報制度の処理能力を上回る可能性を示した。 | 探索能力がセキュリティ制度の処理能力を上回る可能性を示した。 | 両者は、AI 能力の公開速度と社会の受容・修正速度の不一致を露出させた点で同型である。 |
3. ゼロデイは一回限りのカードか
ゼロデイは、狭い意味では一回限りのカードに近い。ゼロデイとは、ベンダーや防御側がまだ把握しておらず、修正も検知ルールも十分に整っていない脆弱性である。したがって、その価値は「知られていないこと」に依存する。攻撃者にとって重要なのは、単に脆弱性が存在することではない。標的環境に到達でき、再現可能で、検知されにくく、攻撃目的に接続でき、なおかつ防御側がまだ対処していないことである。この条件がそろっている間、ゼロデイは高い攻撃価値を持つ。
しかし、ゼロデイは使われた瞬間から劣化し始める。実環境で使えば、ログ、クラッシュ、異常挙動、EDR の検知、ネットワーク痕跡、被害報告、研究者の解析を通じて、存在が露出する可能性が高まる。いったんベンダーに報告され、CVE 番号が付与され、パッチが公開され、ディストリビューションやクラウド基盤やセキュリティ製品が対応すれば、その脆弱性はゼロデイではなくなる。もちろん、パッチ未適用環境では引き続き悪用可能だが、その段階では「未知のカード」ではなく「既知だが残存している攻撃面」へ変わる。
| 段階 | 状態 | 攻撃者にとっての価値 | 防御側にとっての課題 |
|---|---|---|---|
| 未発見段階 | 脆弱性はコードや設計や運用の中に潜在しているが、攻撃者にも防御者にも観測されていない。 | まだ攻撃カードとしては使えないが、探索対象として潜在価値を持つ。 | レビュー、fuzzing、静的解析、AI 支援探索によって先に発見できるかが重要になる。 |
| 攻撃者先行段階 | 攻撃者が脆弱性を発見し、防御側はまだ把握していない。 | 最も価値が高い。標的環境で安定して使えるなら、侵入、権限昇格、横展開に接続できる。 | 異常検知、挙動監視、侵害痕跡分析によって、未知の攻撃を早く観測する必要がある。 |
| 限定共有段階 | 発見者、ベンダー、調整機関など一部の関係者が脆弱性を把握している。 | 情報が漏れれば攻撃価値は残るが、修正が進むほど価値は低下する。 | 責任ある開示、 embargo、パッチ準備、影響範囲確認、利用者通知の設計が重要になる。 |
| 公表段階 | CVE、advisory、パッチ、回避策などが公開される。 | ゼロデイとしての価値は落ちるが、パッチ未適用環境への攻撃価値は残る。 | 更新適用、再起動、影響資産の特定、検知ルール展開を急ぐ必要がある。 |
| パッチ普及後 | 主要環境では修正が進み、検知・監視も整う。 | 広範な攻撃カードとしての価値は下がるが、古い環境、放置機器、組み込み機器では残存価値がある。 | 長期未更新資産、レガシー環境、サプライチェーン内の残存リスクを管理する必要がある。 |
この表から分かるように、ゼロデイは「公表されると完全に無価値になる」わけではない。価値の種類が変わる。未知性に依存する高価値カードから、未更新環境を狙う既知脆弱性へ移るのである。攻撃者にとって、ゼロデイは最初の一撃として価値が高い。しかし、パッチが出た後でも、現実には更新されないサーバー、古いアプライアンス、サポート切れソフトウェア、組み込み機器、再起動できない業務システムが残る。したがって、ゼロデイは一回限りのカードであると同時に、パッチ適用の遅れによってワンデイ、エヌデイ攻撃へ変換される。
さらに重要なのは、ゼロデイが一つ見つかると、その脆弱性だけでなく、構造上の弱点も見えることである。たとえば、ある API 境界で権限モデルが破れていた場合、その具体的なバグを直しても、同じ設計思想、同じデータ経路、同じ例外処理、同じ互換性維持のための分岐に、類似した不整合が残っている可能性がある。一つのゼロデイは、単なる攻撃カードではなく、そのコードベースがどのような場所で壊れやすいかを示す地図でもある。
この点で、AI による弱点探索はゼロデイの意味を変える。人間だけで探索していた時代には、希少なゼロデイを見つけること自体が大きな価値を持った。発見には専門知識、時間、対象コードへの深い理解、偶然、粘り強い検証が必要だったからである。しかし、AI がコード、仕様、過去脆弱性、実行経路、テスト、ログを横断して仮説を出せるようになると、価値の中心は「この一枚のカードを持っていること」から、「次のカードを継続的に見つけられる探索能力」へ移る。
| 観点 | 個別カードとしてのゼロデイ | 継続探索能力としてのゼロデイ | AI 時代に重要になること |
|---|---|---|---|
| 価値の源泉 | まだ誰にも知られておらず、修正も検知もされていない特定の脆弱性を保有していること。 | 未知の脆弱性候補を継続的に見つけ、検証し、攻撃または修正へ接続できること。 | 個別 exploit の秘匿価値だけでなく、探索パイプラインそのものの能力が価値を持つ。 |
| 寿命 | 公表、悪用検知、パッチ配布、検知ルール整備によって価値が短くなる。 | 一つの脆弱性が潰れても、同じ探索能力で次の候補を探せるため継続性がある。 | 防御側も単発監査ではなく、継続的監査と継続的修正を前提にする必要がある。 |
| 攻撃者の行動 | 価値が高い間に慎重に使い、検知されないよう温存する。 | 探索、検証、使い捨て、次候補探索のサイクルを速く回す。 | 攻撃は職人芸的な一点突破から、探索工程を含む運用プロセスへ近づく。 |
| 防御者の行動 | 報告を受けてパッチを作り、既知脆弱性として対応する。 | 攻撃者より先に候補を見つけ、優先順位をつけ、修正キューへ投入する。 | 観測能力と修正能力の両方を継続運用に組み込む必要がある。 |
| 社会的論点 | ゼロデイを公開すべきか、秘匿すべきか、誰へ報告すべきかが問題になる。 | 高能力探索モデルを誰が使い、発見結果を誰が受け取り、どの速度で修正するかが問題になる。 | 公開規範だけでなく、修正能力、OSS 支援、パッチ適用体制、監査ログが重要になる。 |
この比較から言えるのは、AI 時代にはゼロデイの議論が「一つの危険な弾を誰が持っているか」から、「危険な弾を継続的に発見できる探索機構を誰が持つか」へ移るということである。これは、ゼロデイの価値が消えるという意味ではない。むしろ、最上位の攻撃者や防御者にとっては、発見能力、検証能力、攻撃連鎖構成能力、修正能力を統合したプロセス全体の価値が高まる。
この変化は、防御側にとっても厳しい。個別のゼロデイなら、発見、CVE 化、パッチ、通知、更新という一連の対応で処理できる。しかし、AI によって脆弱性候補が大量に出るようになると、発見後の工程が詰まる。すべての候補を深く検証することはできない。すべてのバグに CVE を付けることもできない。すべての patch を即時リリースすることもできない。したがって、重要になるのは、候補を分類し、到達可能性を評価し、深刻度と悪用容易性を見積もり、限られた修正能力をどこへ投じるかを決めるトリアージである。
攻撃側から見ても、防御側から見ても、ゼロデイの価値は時間とともに変化する。攻撃者にとっては、防御側に知られる前の時間が価値である。防御者にとっては、攻撃者に使われる前に観測し、修正し、展開する時間が価値である。このため、AI 時代のゼロデイ問題は、脆弱性の有無だけでなく、発見時刻、悪用時刻、修正時刻、適用時刻の競争として理解すべきである。
W(v) = \max(0, T_p(v) – T_e(v))
\]
ここで、\(W(v)\) は脆弱性 \(v\) の危険窓である。\(T_e(v)\) は攻撃者が実用的に悪用可能になった時刻、\(T_p(v)\) は防御側の修正が実際に適用された時刻である。もし \(T_p(v)\) が \(T_e(v)\) より後なら、その差分が攻撃可能な期間になる。逆に、防御側が先に発見し、悪用可能化される前に修正を適用できれば、危険窓は 0 に近づく。この式は単純だが、AI 時代のゼロデイ問題の本質をよく表す。重要なのは、脆弱性を見つけたかどうかだけではなく、攻撃者の悪用可能化より前に修正履歴へ変換できるかである。
したがって、「ゼロデイは一回限りのカードか」という問いへの答えは二層になる。個別のゼロデイは、未知性に依存するため、一回限りのカードに近い。公表され、修正され、検知されれば、そのカードの価値は落ちる。しかし、ゼロデイを発見する探索能力は一回限りではない。AI によって探索能力が上がると、個別カードの寿命は短くなり、継続的な発見、検証、修正、または悪用のプロセスが中心になる。ここから、社会の関心は「ゼロデイを持っているか」から「ゼロデイが継続的に見つかる社会で、どれだけ速く修正履歴へ変換できるか」へ移る。
個別のゼロデイは一回限りのカードに近い。しかし、AI 時代に本当に価値を持つのは、そのカードを継続的に発見する探索能力である。ゼロデイ問題は、未知の脆弱性の保有問題から、観測された不整合をどれだけ速く修正履歴へ変換できるかという時間競争へ変わる。
4. CVE-2026-31431 が示した意味境界の破綻
CVE-2026-31431 の重要性は、単に Linux カーネルにローカル特権昇格脆弱性があったという点に尽きない。もちろん、一般ユーザー権限から root 権限へ到達できる可能性がある脆弱性は、それだけでも十分に重大である。しかし、この事例を AI 時代の弱点探索という文脈で見るなら、より本質的なのは、複数の技術レイヤーがそれぞれ別の意味を持っていたにもかかわらず、特定の処理経路を通じて、それらの意味境界が破綻した点である。ここでいう意味境界とは、あるデータ、 API、権限、キャッシュ、ファイル、実行経路が「何を変更してよいのか」「何を変更していないと見なすのか」「どの主体がどの権限で触れているのか」を分ける境界である。
Copy Fail の構造を粗く言えば、読み取り可能なファイル、ページキャッシュ、暗号 API、splice によるデータ経路、setuid root バイナリという、本来は別々の責務を持つ要素が、特定条件のもとで接続されてしまった事例である。ディスク上のファイルそのものを通常の書き込み権限で変更したわけではない。それにもかかわらず、実行時に参照されるページキャッシュ側の内容へ制御された変更が入り、結果として setuid root バイナリの実行意味が変わり得る。これは、「ファイルは書き換えられていない」というファイルシステム上の意味と、「実行される内容は変化している」という実行時の意味が分離してしまった状態である。
| 要素 | 本来の意味 | この事例で問題になる点 | 意味境界としての重要性 |
|---|---|---|---|
| 読み取り可能なファイル | 通常のユーザーが内容を読むことはできるが、書き込み権限がなければ内容を変更できない対象。 | 読み取り可能であることが、別経路を通じた実行時内容の改変へ接続してしまう。 | 「読める」と「書ける」は本来別の権限であり、この境界が安全性の前提になっている。 |
| ページキャッシュ | ディスク上のファイル内容をメモリ上に保持し、読み取りや実行を高速化するカーネル内部の仕組み。 | ディスク上のファイルを直接変更しなくても、実行時に参照される内容へ影響できる経路が成立する。 | 「保存されている内容」と「実行時に参照される内容」が一致するという暗黙前提が崩れる。 |
| 暗号 API | 暗号処理や認証付き暗号などを、カーネル内部またはユーザー空間から利用するためのインターフェース。 | 暗号処理の入出力経路が、想定外のメモリ書き換えや in-place 操作の問題へ接続する。 | 暗号 API はデータ変換の道具であり、権限境界を破る書き込み経路であってはならない。 |
| splice | ユーザー空間へのコピーを避け、ファイル記述子間でデータを効率的に移動するゼロコピー系の仕組み。 | 効率化のためのデータ経路が、通常の読み書きモデルとは異なる形でページキャッシュやカーネル内部処理へ接続する。 | 性能最適化の経路は、しばしば権限や所有権の意味を見えにくくするため、境界不整合が起きやすい。 |
| setuid root バイナリ | 一般ユーザーが実行しても、特定条件下で root 権限を持って動作する実行ファイル。 | 実行内容が意味上変更されると、通常ユーザーの操作が root 権限の動作へ接続し得る。 | 読み取り専用に見える対象の実行意味が変わると、権限モデル全体が破れる。 |
この表から分かるように、CVE-2026-31431 は、どこか一箇所に明白な「危険 API 呼び出し」があったというより、複数の正常そうに見える要素が結びついた結果として危険な意味を持った事例である。読み取り可能ファイルは、それ自体では危険ではない。ページキャッシュも、それ自体では通常の性能最適化である。暗号 API も、splice も、setuid root バイナリも、それぞれ単独では Linux の通常機能である。しかし、これらが特定の順序と条件で接続されると、読み取り可能性が実行時改変へ、実行時改変が権限昇格へ、権限昇格がシステム全体の支配へ接続する。このように、局所的には正当に見える処理の合成が、全体として危険な意味を持つことがある。
ここでいう「意味境界の破綻」は、単なるメモリ破壊とは異なる。典型的なバッファオーバーフローであれば、境界外書き込みや制御フロー破壊のように、比較的分かりやすい不正操作が中心になる。しかし Copy Fail 型の問題では、より抽象的な意味のずれが問題になる。ファイルシステム上は変更されていない。権限上は読み取りしか許されていない。暗号 API はデータ変換をしているだけに見える。splice は効率的なデータ移動に見える。ところが、それらが合成された結果、実行時に root 権限で解釈される内容が変わり得る。これは、「どのレイヤーで何が同一と見なされるか」という意味の同一性が破れた事例である。
| 境界 | 通常の前提 | 破綻した場合に起きること | CVE-2026-31431 から読める教訓 |
|---|---|---|---|
| 読み取りと書き込みの境界 | 読めることは変更できることを意味しない。 | 読み取り経路が別の内部処理を通じて実質的な変更へ接続する。 | 権限モデルは API 表面だけでなく、内部データ経路まで含めて検証する必要がある。 |
| ディスク上の内容とメモリ上の内容の境界 | 実行時に参照される内容は、正規のファイル内容と整合している。 | ディスク内容は変わっていないのに、実行時の意味が変化する。 | 完全性は保存媒体上の一致だけではなく、実行時に参照される表現まで含めて考える必要がある。 |
| 性能最適化と権限制御の境界 | ゼロコピーやキャッシュは性能改善であり、権限意味を変えない。 | 効率化された経路が、通常の検査やコピー時の前提を迂回する。 | 最適化経路は、標準経路と同じ安全性不変条件を保つか検証する必要がある。 |
| データ変換と副作用の境界 | 暗号 API は入力を処理し、想定された出力を返すだけである。 | in-place 操作やバッファ共有により、想定外の対象へ副作用が伝播する。 | データ変換 API では、入力、出力、所有権、書き込み可能性を厳密に分ける必要がある。 |
| ユーザー権限と root 権限の境界 | 一般ユーザーの操作は、明示された制約の範囲内でしか root 権限の動作へ影響しない。 | setuid root バイナリの実行意味が変わることで、一般ユーザーの操作が root 権限の制御へ接続する。 | 権限昇格は単一の root 書き込みではなく、実行意味の改変を通じても成立する。 |
このような脆弱性が人間のレビューで見逃されやすい理由は、各レイヤーが局所的には正しく見えるからである。ファイルシステムを担当する人は、ファイルの読み書き権限を見ている。暗号 API を担当する人は、暗号処理の入力と出力を見ている。splice やページキャッシュを担当する人は、データ移動や性能最適化を見ている。setuid の文脈では、実行ファイルの所有者や権限ビットを見ている。しかし、攻撃はそれらの局所境界を順番に横断し、最後に「一般ユーザーの操作が root 権限の実行意味を変える」という全体効果へ到達する。局所的正当性の合成が、全体的安全性を保証しないのである。
ここが AI 支援探索と接続する。高性能な AI モデルが脆弱性探索で有用になり得るのは、単に危険な関数名を grep するからではない。コード、仕様、コメント、過去の脆弱性、データフロー、制御フロー、権限境界、実行時の意味をまたいで、「この経路とこの経路が接続すると、本来分かれているはずの意味が混ざるのではないか」という仮説を作れるからである。CVE-2026-31431 のような事例は、まさにその種の構造横断的な仮説生成が価値を持つ領域である。
したがって、Copy Fail は特殊な一事件として閉じるべきではない。むしろ、複雑なソフトウェアシステムが持つ一般的な危険を代表している。現代のシステムは、ファイルシステム、メモリ管理、暗号、権限、キャッシュ、ネットワーク、コンテナー、仮想化、クラウド、CI/CD、サプライチェーンが重なり合っている。各部品が局所的に正しくても、部品間の意味接続が壊れれば、全体として脆弱になる。AI が弱点探索を強めると、こうした「レイヤー間の意味不整合」がより多く可視化される。
この章の結論は、CVE-2026-31431 が単なる Linux カーネルの特権昇格脆弱性ではなく、意味境界の破綻を示す教材であるということだ。読み取りと書き込み、保存と実行、性能最適化と権限制御、データ変換と副作用、ユーザー権限と root 権限の境界が、特定条件で接続されると、局所的には正しい処理が全体として危険な意味を持つ。AI 時代の弱点探索が露出させるのは、まさにこの種の構造的不整合である。だからこそ、この事例は Claude Mythos 騒動と接続する。問題は、AI が突然脆弱性を作ることではない。AI によって、これまで人間のレビューでは見落とされていた意味境界の破綻が、より高い解像度で観測されるようになることである。
CVE-2026-31431 は、単一部品の破綻ではなく、複数レイヤーの局所的正当性が合成された結果、全体として危険な意味を持った事例である。AI 支援探索が強くなると、危険な関数名や既知パターンだけでなく、レイヤー間の意味境界が破れる経路を探索できるようになる。
5. 悪意ある利用者にとって何が変わるのか
悪意ある利用者にとって AI が変えるのは、攻撃意図ではなく探索と準備の限界費用である。攻撃者がシステムを侵害しようとする動機は、AI がなくても存在する。金銭目的、情報窃取、妨害、政治的目的、内部不正、研究を装った悪用など、攻撃意図そのものは人間側にある。AI が変えるのは、その意図を実行可能な手順へ変換するまでの摩擦である。従来、深い脆弱性探索には、対象領域の専門知識、長いコード読解時間、再現環境の構築、デバッガー操作、既存 CVE の知識、類似バグの記憶、攻撃チェーンを組む経験が必要だった。AI が支援すると、これらの一部が圧縮される。
ここで重要なのは、「AI が攻撃者を生む」のではなく、「既存の攻撃者の作業効率を上げる」という見方である。AI は、コードを読み、仕様の矛盾を探し、過去の脆弱性と似た構造を抽出し、到達可能性の仮説を並べ、検証手順の骨格を提案し、関連する既存ツールや既存研究を結びつけることができる。これは、攻撃者にとっては調査時間の短縮であり、経験の浅い攻撃者にとっては不足知識の補助であり、熟練攻撃者にとっては探索範囲の拡張である。したがって、AI の悪用リスクは、万能な自動攻撃ロボットの出現ではなく、攻撃準備工程の産業化として見るべきである。
| 攻撃工程 | 従来必要だった能力 | AI が下げるコスト | なお残る制約 |
|---|---|---|---|
| 対象調査 | 対象ソフトウェア、バージョン、公開情報、過去脆弱性、構成差分を調べる能力。 | 公開情報、ドキュメント、リリースノート、過去 CVE、コード差分を横断して整理する時間を短縮する。 | 実際の標的環境の構成、非公開設定、ネットワーク到達性、運用制約は外部から完全には分からない。 |
| コード読解 | 対象コードベースの構造、関数呼び出し、データフロー、権限境界を読み解く能力。 | 広いコード範囲の要約、関連箇所の抽出、危険そうな経路の候補提示を高速化する。 | AI の読解は誤ることがあり、実際の実行経路、ビルド条件、設定差分を確認する必要がある。 |
| 脆弱性仮説の生成 | 過去事例と現在の実装を比較し、どの境界が破れそうかを推測する能力。 | 類似パターン、境界条件、例外処理、型変換、権限遷移、キャッシュや最適化経路を候補化しやすくする。 | 仮説は仮説であり、再現性、到達可能性、影響範囲の確認なしには攻撃にも防御にも使えない。 |
| 再現環境の構築 | 対象バージョン、依存ライブラリ、ビルド条件、カーネル設定、実行環境をそろえる能力。 | 必要な環境、ビルド手順、検証観点を整理する補助にはなる。 | 実機差分、カーネル設定、ディストリビューション差、ハードウェア差、コンテナー制約は人間が検証する必要がある。 |
| PoC 骨格の作成 | 脆弱性候補を最小再現コードや検証手順へ落とす能力。 | 検証コードの構成、入力条件、呼び出し順序、ログ確認の骨格を作りやすくする。 | 危険な実行、実環境での悪用、安定化、検知回避には追加の技術判断が必要になる。 |
| 攻撃チェーン構成 | 初期侵入、権限昇格、認証情報取得、横展開、永続化を組み合わせる能力。 | 既存知識の接続、候補経路の列挙、手順の整理を補助する。 | 標的固有の制約、検知回避、認証情報、ネットワーク分離、運用判断は自動化しにくい。 |
| 運用と継続 | 検知を避け、安定してアクセスし、目的を達成し、痕跡を管理する能力。 | ログや挙動の読み方、一般的な注意点の整理は支援できる。 | 現実の侵害運用はリスクが高く、状況依存性が大きく、AI の一般的助言だけでは成立しない。 |
この表から分かるように、AI が特に効くのは、対象調査、コード読解、仮説生成、候補整理、手順化の部分である。これらは、従来なら人間の経験、記憶、時間、粘り強さに強く依存していた。AI がこの部分を補助すると、攻撃者はより多くの対象を同時に調べられる。見慣れないコードベースにも入りやすくなる。過去の脆弱性パターンを別のコードへ移植して考えやすくなる。これは、トップレベル攻撃者だけでなく、中位の攻撃者にも影響する。高度な攻撃能力が完全に民主化されるわけではないが、探索工程への入口は広がる。
一方で、AI が苦手または不確実な部分も明確に残る。実際の標的環境に到達できるか、どのバージョンが動いているか、どの設定が有効か、パッチが適用済みか、ネットワーク的に届くか、EDR や監視がどう反応するか、攻撃が安定して再現するかは、文脈依存である。ローカル権限昇格、リモートコード実行、サンドボックス脱出、認証回避、サプライチェーン攻撃は、それぞれ成立条件が異なる。AI は探索の摩擦を下げるが、攻撃の全工程を自動的に成功させるわけではない。
| 攻撃種別 | AI による支援が効きやすい部分 | AI だけでは越えにくい部分 | 冷静な評価 |
|---|---|---|---|
| ローカル権限昇格 | カーネル、setuid バイナリ、権限境界、ファイルシステム、IPC、名前空間の不整合を探す部分。 | 対象環境での再現性、カーネル設定差分、ディストリビューション差、安定した実行条件。 | AI 支援探索と相性はよいが、実用化には環境依存の検証が必要である。 |
| リモートコード実行 | 入力処理、パーサー、認証前処理、シリアライズ、プロトコル実装、境界条件の調査。 | 外部から到達できるか、WAF やレート制限があるか、クラッシュせず制御できるか。 | 発見価値は高いが、安定 exploit 化の難度も高い。 |
| サンドボックス脱出 | ブラウザー、コンテナー、仮想化、権限分離、IPC 境界のコード読解と仮説生成。 | 複数段階の exploit chain、環境差分、検知回避、タイミング依存の挙動。 | AI は候補探索に効くが、実戦的連鎖には高度な専門性が残る。 |
| 認証回避 | 状態遷移、セッション管理、権限チェック漏れ、API 経路差分、設定ミスの候補抽出。 | 実サービス固有の設定、運用フロー、外部 ID 基盤、ログ監視。 | コードと仕様の差分を読む能力が効くが、標的固有情報が必要になる。 |
| サプライチェーン攻撃 | 依存関係、CI/CD、署名、パッケージ設定、保守者権限、公開設定の弱点整理。 | 実際の権限獲得、信頼関係の悪用、組織的運用、検知回避。 | AI は構造分析に効くが、攻撃成立には社会的・運用的要素が大きい。 |
悪意ある利用者にとって最も大きい変化は、探索対象の拡大である。従来は、十分な専門知識を持つ攻撃者だけが、Linux カーネル、ブラウザー、暗号ライブラリ、仮想化基盤、複雑な OSS の深い部分を調べられた。AI 支援が入ると、攻撃者は、自分の専門外のコードベースにも入りやすくなる。もちろん、AI の出力を検証できなければ実用にはならないが、候補を得るだけでも攻撃者の探索空間は広がる。これは、防御側から見れば、これまで見逃されていたニッチな機能、古い互換経路、低頻度 API、設定依存の経路も攻撃対象になりやすいということである。
もう一つの変化は、攻撃の量的増加である。AI は一つの対象だけを深く読むのではなく、多数の対象に対して候補を出せる。これにより、攻撃者は「大当たりのゼロデイ」を一つ探すだけでなく、中程度の脆弱性、設定ミス、既知 CVE の未適用、古い依存関係、誤った公開設定、CI/CD の抜け穴を組み合わせる戦術を取りやすくなる。現実の侵害は、しばしば一つの巨大な脆弱性ではなく、複数の小さな不備の連鎖で成立する。AI はこの連鎖候補を整理する能力を高める。
ただし、ここでも過剰な恐怖は避けるべきである。AI が出す脆弱性候補には誤検知がある。到達できない経路、既に修正済みのバージョン、設定依存で成立しない条件、机上では危険だが実運用では影響しない経路も多い。攻撃者にとっても、AI の出力を検証する能力がなければ、ノイズに埋もれる。つまり、AI は低品質な攻撃者を一瞬で熟練者にするというより、検証能力を持つ攻撃者の探索効率を上げる。中位の攻撃者にとっては能力を底上げし、熟練攻撃者にとっては探索範囲を広げる。この差を正確に見る必要がある。
この変化は、攻撃者の経済性にも影響する。攻撃者は、費用、時間、成功確率、検知リスク、得られる利益を見て行動する。AI によって探索時間が短くなり、候補生成が安くなれば、これまで費用対効果が合わなかった対象も調べる価値を持つ。特に、広く使われている OSS、更新が遅い企業システム、古いアプライアンス、放置された WordPress プラグイン、設定が複雑なクラウド環境、CI/CD 周辺は、攻撃者にとって探索対象になりやすい。これは、個々の攻撃能力よりも、探索市場全体のコスト構造が変わるという問題である。
したがって、悪意ある利用者にとっての変化は、三層に分けて理解できる。第一に、読解と調査の補助により、対象理解が速くなる。第二に、脆弱性候補と攻撃経路の仮説生成により、探索空間が広がる。第三に、既存ツールや既存知識との接続により、攻撃準備が手順化されやすくなる。一方で、実環境での安定攻撃、検知回避、運用継続、標的固有の判断は、依然として高度な専門性と状況判断を要求する。
| 変化の層 | 何が変わるか | 悪意ある利用者への効果 | 防御側が見るべき点 |
|---|---|---|---|
| 読解コストの低下 | コード、仕様、過去 CVE、設定、ログの理解が速くなる。 | 専門外の対象へ入りやすくなり、調査対象が広がる。 | 古いコード、低頻度機能、境界条件、例外経路も監査対象に含める必要がある。 |
| 仮説生成コストの低下 | どこが壊れそうか、どの経路が危険かを候補化しやすくなる。 | 攻撃者は多数の候補を並べ、検証すべき場所を絞り込める。 | AI 支援レビューや fuzzing を使い、防御側も先に候補を発見する必要がある。 |
| 手順化コストの低下 | 検証手順、既存ツール、既知パターン、攻撃段階を整理しやすくなる。 | 中位の攻撃者でも、より複雑な工程を組み立てやすくなる。 | 単一脆弱性だけでなく、複数不備の連鎖を前提に防御する必要がある。 |
| 探索対象の拡大 | 人間だけでは読みにくかった広いコードベースや周辺領域も候補に入る。 | ニッチな OSS、古い API、社内ツール、設定ミス、CI/CD 周辺が狙われやすくなる。 | 主要製品だけでなく、周辺依存、内部ツール、保守が薄い領域を可視化する必要がある。 |
この章の結論は、AI によって悪意ある利用者が突然万能になるということではない。より正確には、AI によって攻撃準備の摩擦が下がり、探索できる対象が増え、脆弱性候補を見つける速度が上がり、複数の小さな不備を攻撃チェーンとして結びつける可能性が高まるということである。だからこそ、防御側は AI を恐れるだけでは足りない。攻撃者が AI で観測能力を上げるなら、防御側も観測能力を上げ、その結果を修正能力へ接続しなければならない。
AI は攻撃意図を作るのではなく、攻撃工程のうち、読解、仮説生成、探索、既存知識の接続、候補整理、手順化のコストを下げる。だが、現実環境での到達、検証、運用、検知回避、継続的侵害は依然として人間側の判断や環境条件に依存する。AI は悪意を作るのではなく、悪意を実行可能な探索・検証・手順化へ変換するコストを下げる。本当に危険なのは、攻撃者の観測能力だけが上がり、防御側の修正能力が追いつかない状態である。
6. 防御者にとって何が変わるのか
防御者にとっても、AI が最初に変えるのは探索コストである。これまで予算、人員、時間、専門知識の制約によって十分に読めなかった古いコード、低頻度にしか使われない機能、互換性維持のために残された分岐、性能最適化の経路、例外処理、エラー処理、権限境界、依存ライブラリ、CI/CD 設定、コンテナー設定、クラウド権限を、AI 支援で広く点検できるようになる。重要なのは、AI を攻撃者の道具としてだけ見ないことである。脆弱性は、攻撃者が発見した瞬間に発生するものではない。多くの場合、それはすでにコード、仕様、設定、運用、依存関係の中に存在している。防御者が先に観測できれば、その不整合は攻撃履歴ではなく修正履歴へ変換できる。
ただし、防御側の変化は「AI で脆弱性を見つけられるようになる」という単純な話ではない。むしろ、AI によって発見能力が上がるほど、防御側の本当の弱点が露出する。見つかった候補を誰が読むのか。再現性を誰が確認するのか。誤検知と真の脆弱性をどう分けるのか。どのバージョンが影響を受けるのか。パッチを誰が書くのか。回帰テストをどう行うのか。利用者へいつ通知するのか。再起動できない本番環境へどう適用するのか。これらが詰まれば、観測能力の上昇は安全性の向上ではなく、未処理リスクの可視化にとどまる。
| 防御工程 | 従来の制約 | AI が支援できること | AI だけでは解決しないこと |
|---|---|---|---|
| 対象把握 | 資産、依存関係、バージョン、設定、公開面、内部ツールが十分に棚卸しされていない。 | リポジトリ、設定ファイル、依存関係、ドキュメント、ログから対象範囲を整理する。 | 実際にどのシステムが稼働しているか、どの資産が重要か、どの停止が許容されるかは組織側が決める必要がある。 |
| コード監査 | 古いコード、低頻度機能、例外経路、互換性分岐、性能最適化経路まで人間が読み切れない。 | 危険そうな経路、境界条件、過去 CVE と似た構造、権限境界の不整合を候補として提示する。 | 候補の正しさ、実行可能性、影響範囲は人間の検証と実環境での確認が必要になる。 |
| トリアージ | 大量の警告や脆弱性候補が出ても、どれを先に直すべきか判断する人員が不足しやすい。 | 深刻度、到達可能性、悪用容易性、影響範囲、類似事例を整理し、優先順位付けを補助する。 | 事業影響、停止リスク、顧客影響、規制要件、保守計画を含む最終判断は組織が引き受ける必要がある。 |
| 再現確認 | 報告された候補が本当に成立するか、どの条件で再現するかを確認する手間が大きい。 | 再現手順、テスト観点、必要な環境、関連ログ、失敗時の確認点を整理する。 | 危険な PoC の実行、隔離環境の構築、本番との差分確認は慎重な人間判断を要する。 |
| パッチ作成 | 局所修正が副作用を生み、互換性、性能、既存テスト、依存先に影響する可能性がある。 | 修正案、テスト追加、影響箇所の洗い出し、類似箇所の確認を支援する。 | 安全性不変条件、互換性判断、リリース責任、メンテナンス方針は保守者が判断する必要がある。 |
| リリースと適用 | パッチが存在しても、利用者環境で適用されるまで危険窓が残る。 | 影響範囲、更新手順、回避策、リリースノート、利用者通知の作成を補助する。 | 再起動計画、業務停止調整、互換性検証、パッチ適用率の追跡は組織運用に依存する。 |
| 再観測 | 修正後に本当に問題が消えたか、類似箇所が残っていないかを継続確認する必要がある。 | 類似パターン探索、回帰テスト、ログ確認、設定差分確認を継続的に支援する。 | 修正を組織の標準、テスト、設計指針、運用ルールへ反映しなければ再発する。 |
この表が示すように、防御側にとって AI は「発見装置」ではあるが、それだけでは足りない。防御の実体は、発見された候補を修正可能な単位へ変換することである。AI が多数の候補を出しても、トリアージされず、再現確認されず、修正されず、リリースされず、利用者に適用されなければ、安全性は改善しない。むしろ、未処理の警告が増えることで、現場は疲弊し、重要な警告が埋もれ、説明責任だけが重くなる可能性がある。
防御側で特に重要になるのは、観測能力と修正能力を分けて考えることである。観測能力とは、潜在的不整合を発見する能力である。修正能力とは、発見された不整合を分類し、検証し、パッチ化し、リリースし、適用し、再発防止へ落とす能力である。この二つは一致しない。AI によって観測能力だけが急増しても、修正能力が増えなければ、未処理キューが増えるだけである。したがって、防御者が本当に強化すべきなのは、AI を導入すること自体ではなく、AI が発見したものを受け止める修正パイプラインである。
| 防御側の能力 | 内容 | AI による変化 | 成熟した運用で必要なこと |
|---|---|---|---|
| 観測能力 | 脆弱性候補、設定不備、依存関係リスク、異常ログ、攻撃兆候を発見する能力。 | 広い対象を継続的に調べ、従来見落とされていた境界条件や低頻度経路を発見しやすくなる。 | AI 支援レビュー、fuzzing、静的解析、ログ監視、依存関係監査を組み合わせる必要がある。 |
| 解釈能力 | 発見された候補が本当に危険か、どの条件で成立するか、どの資産に影響するかを判断する能力。 | 関連情報や過去事例の整理は速くなるが、誤検知や文脈誤りも混じる。 | 人間の専門判断、再現確認、資産重要度、運用文脈を組み合わせる必要がある。 |
| 修正能力 | パッチ作成、テスト、リリース、適用、回避策、再発防止を実行する能力。 | 修正案やテスト案の作成は支援されるが、実際の変更責任は人間と組織に残る。 | 保守者、レビュー体制、CI、リリース計画、パッチ適用運用を強化する必要がある。 |
| 説明能力 | なぜその問題を先に直すのか、どの問題を後回しにするのか、どのリスクが残るのかを説明する能力。 | 説明資料や影響整理は支援できるが、説明責任の主体にはなれない。 | 利用者、経営層、規制当局、OSS コミュニティへ説明できる判断記録を残す必要がある。 |
防御者にとってもう一つ重要なのは、AI が発見する対象が、自組織のコードだけに限られないことである。現代のシステムは、自社コード、OSS、ディストリビューション、コンテナーイメージ、クラウドサービス、CI/CD、認証基盤、監視基盤、IaC、外部 API、サードパーティ SDK の集合である。したがって、防御側の観測能力は、単一リポジトリのコードレビューでは足りない。依存関係、構成、ビルド、デプロイ、実行時設定、ログ、運用権限を含む全体構造を観測する必要がある。
この変化は、OSS 保守者への負荷も増やす。AI によって脆弱性候補が大量に報告されるようになると、OSS 保守者は、真の脆弱性、誤検知、重複報告、再現不能な報告、影響の小さい報告をさばかなければならない。善意の報告であっても、質が低ければ保守者の負担になる。したがって、防御側の AI 活用では、報告品質、再現手順、影響範囲、修正案、責任ある開示手順が重要になる。AI が見つけた候補をそのまま投げるだけでは、社会の修正能力を上げるどころか、保守者の処理能力を圧迫する。
防御者の観点では、AI 支援探索は「早く見つけるための技術」であると同時に、「早く直すための制度」を要求する技術である。たとえば、AI が CI 上で潜在的な脆弱性候補を見つけても、その結果が backlog に積まれて放置されるなら意味がない。重大候補には SLA を設定し、到達可能性を評価し、修正担当者を割り当て、テストを追加し、リリース判断へ接続する必要がある。ここまで行って初めて、AI の観測能力は防御力へ変わる。
この点を数理的に言えば、防御側の安全性は観測能力 \(O_t\) だけでは決まらない。観測されたリスク量に対して、単位時間あたりに修正できるリスク量が追いついているかで決まる。仮に AI によって \(O_t\) が急上昇しても、修正能力 \(F_t\) が同じなら、未処理リスク \(K_t\) は増える。防御者にとって重要なのは、AI を入れることではなく、\(O_t\) の上昇に合わせて \(F_t\) を上げることである。
K_{t+1} = K_t + B_t – X_t
\]
ここで、\(K_t\) は時刻 \(t\) における未処理の脆弱性候補または未修正リスクのキューである。\(B_t\) はその時刻に新たに観測された問題集合であり、\(X_t\) は実際に修正または適切に処理された問題集合である。AI によって \(B_t\) が増えること自体は悪ではない。しかし、\(X_t\) が増えなければ、\(K_t\) は増え続ける。これが、観測能力だけを強化した防御組織が陥る典型的な失敗である。
したがって、防御者にとっての本質的変化は、脆弱性を見つける能力が上がることではなく、見つかった脆弱性を処理する組織能力が試されることである。AI は、古いコード、低頻度経路、複雑な依存関係、設定ミス、例外処理、性能最適化の副作用を可視化する。だが、それを安全性へ変えるのは、トリアージ、再現、修正、レビュー、リリース、適用、説明、再観測である。AI 時代の防御とは、観測された不整合を、未処理キューではなく修正履歴へ変換し続ける運用である。
防御側にとって AI は、発見装置である以上に、修正パイプラインの弱さを露出させる装置である。AI によって防御者の観測能力が上がっても、修正能力が追いつかなければ安全性は上がらない。むしろ、未処理リスクが増える。
7. 騒ぎはどこで誇張されるのか
Claude Mythos 騒動のような話題では、誇張は単純な嘘として発生するとは限らない。むしろ、誇張は事実の断片を起点として発生する。AI がコードを読める、脆弱性候補を発見できる、攻撃手順の一部を整理できる、政府機関が評価した、企業が限定公開した、メディアが危険性を報じた。これらの個別事実は、それぞれ単独では完全な虚偽ではない。しかし、それらが一列につながれ、「AI がゼロデイを自律的に発見し、すぐに世界中のシステムを攻撃できる」と読まれると、事実の射程を超える。誇張とは、事実がないところに物語を作ることだけではなく、事実の一部を過剰に連結し、能力、到達範囲、悪用可能性、社会的影響を連続的に拡大して読むことである。
騒ぎが誇張される第一の地点は、発見能力と攻撃能力の混同である。脆弱性候補を発見すること、再現可能なバグを確認すること、セキュリティ境界を越える実脆弱性として成立させること、PoC を書くこと、実環境で安定した exploit にすること、攻撃チェーンへ組み込むこと、検知を避けて目的を達成することは、それぞれ別の段階である。AI が前半を支援できることは重要だが、それをもって後半まで自動的に成立すると見るのは飛躍である。特に、現実の攻撃では、対象環境のバージョン、設定、ネットワーク到達性、防御製品、ログ監視、権限、業務運用が関係する。発見能力の向上は危険であるが、発見能力そのものを即座に実戦攻撃能力と同一視してはいけない。
第二の地点は、研究プレビュー、限定提供、政府評価、商用利用、犯罪利用が一列に並べられることである。研究プレビューとして高能力モデルを評価すること、選定された防御関係者へ限定提供すること、政府機関が安全性を評価すること、企業が商用利用すること、犯罪者が悪用することは、すべて異なる段階である。これらを区別せずに並べると、「政府が評価したほど危険なモデルが、すぐ犯罪者にも使われる」という印象になる。しかし、実際にはアクセス制御、利用規約、監査ログ、出力制限、提供先審査、モデルカード、評価環境、法的責任が間に入る。もちろん、それらの制御が十分かどうかは別途検討すべきだが、制御が存在すること自体を無視してはいけない。
第三の地点は、企業発信が安全性説明と能力宣伝を兼ねることである。企業が「このモデルは高度なサイバー能力を持つため慎重に提供する」と説明するとき、その発言は安全対策の説明であると同時に、自社モデルの能力の強調でもある。モデルが危険であるほど、自社の技術力が高いようにも見える。逆に、競合企業は、その公開方針を安全性の問題、独占の問題、透明性の問題として批判する動機を持つ。政府は安全保障上の懸念を強調する動機を持ち、メディアは強い言葉で読者の注意を引く動機を持つ。したがって、この種の騒動では、技術的リスク、企業戦略、規制政治、報道上の演出が混ざる。
| 誇張が起きる地点 | 実際にある事実 | 誇張された読み方 | 冷静な読み方 |
|---|---|---|---|
| 発見能力と攻撃能力の混同 | AI はコード読解、脆弱性候補の抽出、類似パターンの発見、手順整理を支援できる。 | AI が脆弱性候補を見つけられるなら、すぐ任意環境で安定した攻撃ができると読む。 | 候補発見、再現、実脆弱性化、exploit 化、攻撃運用は別段階として評価する。 |
| 限定公開と犯罪利用の短絡 | 高能力モデルが選定された企業、政府、研究者、防御関係者へ限定提供される場合がある。 | 限定提供された能力が、そのまま犯罪者へ広く拡散する前提で語る。 | アクセス制御や監査の有無を評価しつつ、漏洩・転用・内部不正のリスクを別に検討する。 |
| 企業発信の能力宣伝化 | 企業は安全性上の理由からモデル能力や制限方針を説明する。 | 企業の安全説明を、そのまま客観的な危険度評価として受け取る。 | 安全説明、能力宣伝、競争戦略、規制対応が混ざっている可能性を前提に読む。 |
| 政府評価の権威化 | 政府系機関がモデルのサイバー能力やリスクを評価する。 | 政府が評価したという事実だけで、破局的危険が確認されたかのように読む。 | 評価対象、評価条件、評価環境、成功基準、公開範囲を確認して読む。 |
| メディア表現の単純化 | AI がゼロデイ探索や攻撃支援に使える可能性がある。 | 「攻撃 AI」「危険すぎるモデル」「封印された能力」のような物語として読む。 | 強い見出しを割り引き、能力の段階、制約、実務上の接続を分解する。 |
この表から分かるように、誇張は「事実か虚偽か」の二分法では捉えにくい。多くの場合、出発点には実際の能力向上がある。AI がコードを読めるようになっていること、脆弱性探索を支援できること、防御者にも攻撃者にも有用なこと、限定公開や政府評価が必要になるほどデュアルユース性が高いことは、無視できない事実である。しかし、その事実から「AI が自律的に世界中のシステムを破壊する」「すぐ全犯罪者が高度なゼロデイ探索能力を持つ」「公開された瞬間に防御不能になる」と結論するなら、そこには飛躍がある。冷静な判断では、危険の実在と物語の過剰を分ける必要がある。
誇張を見抜くには、能力の段階を分解する必要がある。脆弱性候補を発見する能力、再現条件を作る能力、悪用可能性を確認する能力、実環境で安定動作させる能力、攻撃チェーンに組み込む能力、検知を避ける能力、侵害後の目的を達成する能力は、それぞれ異なる。AI がどの段階をどれだけ支援するのかを見なければ、危険性は評価できない。特に Claude Mythos 型の話では、モデルが CTF や評価環境で高い成績を示すことと、現実の複雑な標的環境で継続的侵害を実現することを区別しなければならない。
| 能力段階 | 意味 | 誇張されやすい点 | 評価で確認すべき点 |
|---|---|---|---|
| 候補発見 | コードや仕様から、脆弱性になり得る箇所を見つける。 | 候補が出ただけで実脆弱性が確定したように扱われる。 | 再現性、到達可能性、影響範囲、既存修正の有無を確認する。 |
| 再現確認 | 特定条件で問題が実際に発生するか検証する。 | 評価環境での再現が、あらゆる実環境での成立と混同される。 | バージョン差、設定差、ビルド条件、権限条件、運用条件を確認する。 |
| 実脆弱性化 | セキュリティ境界を越える実害ある脆弱性として成立する。 | 単なるクラッシュや不具合が、即座に重大侵害として語られる。 | 機密性、完全性、可用性、権限境界、データ影響を分けて確認する。 |
| exploit 化 | 実用的な攻撃手順や PoC として利用できる形にする。 | PoC の存在が、安定した攻撃運用の成立と混同される。 | 成功率、安定性、前提条件、検知可能性、対象範囲を確認する。 |
| 攻撃運用 | 標的環境で目的達成まで攻撃を運用する。 | 単一脆弱性の発見が、完全な侵害能力と同一視される。 | 初期アクセス、権限、横展開、検知回避、永続化、目的達成までを分けて評価する。 |
一方で、誇張があるから問題がない、という結論にもならない。これは非常に重要である。強い見出し、企業の能力宣伝、政府の安全保障言説、SNS 上の不安増幅を割り引いた後にも、なお残る事実がある。高度な AI モデルは、コード理解、脆弱性候補の探索、過去事例との照合、攻撃経路の仮説生成、検証手順の整理において、実務上有用な水準へ近づいている。これは防御者にとって有益であると同時に、攻撃者にとっても有益である。つまり、誇張を批判することは、危険性を否定することではない。
ここで必要なのは、恐怖でも嘲笑でもなく、分解である。「危険だ」という言葉を、どの能力が、どの条件で、誰に渡り、どの標的に対し、どの工程まで支援し、どの制度で抑制され、どの修正能力で吸収されるのかへ分解する。逆に、「大したことはない」という言葉も、どの条件では成立し、どの条件では成立しないのかへ分解する。AI セキュリティの議論で危険なのは、強い危機感だけではない。過剰反応への反発から、実在する構造変化まで否定してしまうことも危険である。
この章の結論は、Claude Mythos 騒動を読むときには、誇張を取り除いた後に残る構造を見なければならないということである。残る構造とは、AI によって弱点探索の限界費用が下がり、観測される不整合が増え、発見後のトリアージ、修正、開示、適用、説明の負荷が増えるという変化である。したがって、正しい態度は、怪物物語に飲み込まれることでも、マーケティング騒動として切り捨てることでもない。観測能力の上昇を事実として受け入れ、その観測結果を人間社会がどの制度と運用で修正履歴へ変換するかを考えることである。
誇張は、事実がないところに生まれるのではなく、事実の一部を過剰に連結し、能力・到達範囲・悪用可能性を拡大して読むことで生まれる。誇張を取り除いても、AI によって弱点探索の限界費用が下がり、社会の修正能力が問われるという構造変化は残る。
8. 弱点探しが網羅化すると社会はどう変わるか
弱点探しが網羅化すると、社会は「安全なものを選んで使う」段階から、「常に欠陥が見つかるものを更新し続ける」段階へ移る。これは悲観的な見方ではなく、複雑な人工物を扱う社会では避けられない前提である。巨大なソフトウェア、クラウド基盤、OS、ブラウザー、暗号ライブラリ、医療システム、金融システム、行政システム、交通システムは、完全に欠陥のない完成物として存在しているわけではない。多数の部品、依存関係、設定、運用手順、人間判断、例外処理、互換性維持、歴史的経緯が重なって、一時的に安定している。AI による弱点探索が広がると、この一時的安定の内部にある不整合が、従来よりも多く、速く、継続的に観測される。
ここで重要なのは、問題が急に増えるのではなく、見える問題が増えるという点である。これまでも欠陥は存在していた。古い API の境界条件、低頻度にしか使われない機能、暗黙の前提に依存した設定、ドキュメント化されていない互換経路、依存ライブラリの未更新、権限境界の曖昧さ、ログにしか出ない異常は、以前から存在していた。しかし、人間のレビュー能力、監査予算、テスト時間、専門知識、観測範囲には限界があったため、それらの多くは見逃されていた。AI による網羅的探索は、この見逃し領域を狭める。
その結果、社会の安全性の定義が変わる。安全とは、欠陥が一切存在しない状態ではなくなる。むしろ、欠陥が観測されたときに、短時間で分類し、影響範囲を特定し、優先順位をつけ、隔離し、修正し、配布し、適用し、再観測できる状態が安全と呼ばれるようになる。これは、医療において「病気が存在しない社会」を前提にするのではなく、検査、診断、治療、経過観察、再発予防の仕組みを整えるのに近い。観測能力が上がる社会では、異常が見つからないことではなく、異常が見つかった後に回復できることが安全性の中心になる。
| 領域 | 従来の前提 | 弱点探しが網羅化した後の変化 | 新たに重要になる責任 |
|---|---|---|---|
| ソフトウェア開発 | 主要機能を実装し、既知の不具合や脆弱性を修正すれば十分と考えられやすい。 | 低頻度経路、例外処理、依存関係、古い互換コード、境界条件まで継続的に観測される。 | AI 支援レビュー、fuzzing、静的解析、テスト追加、修正履歴化を通常工程へ組み込む責任が増す。 |
| OSS | 善意の保守者が報告を受け、可能な範囲で修正する構造に依存している。 | AI 生成の脆弱性候補や低品質報告が増え、保守者のトリアージ負荷が増大する。 | 報告品質、再現手順、資金支援、保守者負担の軽減、調整機関の支援が重要になる。 |
| 企業システム | 重要システムを安定稼働させ、必要時にパッチを適用する運用が中心になる。 | 古い社内ツール、未管理サーバー、クラウド設定、CI/CD、認証基盤も観測対象になる。 | 資産棚卸し、SBOM、依存関係管理、パッチ適用計画、再起動可能性の確保が重要になる。 |
| 金融・医療・行政 | 停止できない重要サービスとして、安定性と継続性が優先されやすい。 | 停止できないことが、パッチ適用遅延やレガシー依存として弱点化する。 | 安全性と継続性を両立する更新計画、代替手段、段階的適用、説明責任が必要になる。 |
| クラウド・インフラ | 大規模基盤は専門事業者によって管理され、利用者は設定責任を負う。 | IAM、ネットワーク公開範囲、コンテナー、IaC、シークレット管理、ログ設定の不備が広く可視化される。 | 責任共有モデルの明確化、設定監査、最小権限、継続的コンプライアンス確認が重要になる。 |
| 政府・規制 | 重大インシデントや既知脆弱性への対応を中心に制度を設計する。 | AI による発見速度が上がり、CVD、CVE、KEV、パッチ期限、報告義務の処理量が増える。 | 開示制度、評価機関、標準化、基盤 OSS 支援、重要インフラの更新能力確保が重要になる。 |
この表が示すように、弱点探しの網羅化は、単にセキュリティ部門の仕事を増やすだけではない。開発、運用、調達、法務、経営、規制、OSS コミュニティ、利用者のすべてに影響する。これまで「専門家がときどき監査するもの」だった脆弱性管理は、「システムを使い続ける限り常に発生する更新責任」へ変わる。特に重要なのは、脆弱性の発見数が増えるほど、発見そのものよりも、分類と優先順位付けが重要になる点である。すべての警告を同じ重さで扱えば、現場は破綻する。逆に、重要な警告を軽視すれば、重大事故へつながる。
この変化は、運用文化を大きく変える。パッチ適用は例外対応ではなく、通常業務になる。再起動は避けるべき非常事態ではなく、計画的に実施できる運用能力になる。SBOM は形式的な成果物ではなく、影響範囲を素早く調べるための索引になる。依存関係管理は開発者の細かい作業ではなく、事業継続性の前提になる。ログは後から見る記録ではなく、未知の攻撃や異常を早く観測するためのセンサーになる。インシデント演習は形式的な訓練ではなく、観測から修正までの遅延を測る実験になる。
| 安全性の前提 | 従来の見方 | 網羅的観測社会での見方 | 実務上の帰結 |
|---|---|---|---|
| 欠陥の存在 | 十分に検査されたシステムは安全であり、重大欠陥は例外的に見つかる。 | 複雑なシステムには未発見欠陥が残る前提で運用する。 | 一回限りの監査ではなく、継続的な観測と更新を前提にする。 |
| 安全性の定義 | 欠陥がないこと、または既知欠陥が少ないことを安全性と見なす。 | 欠陥が見つかったときに短時間で処理し、被害を限定できることを安全性と見なす。 | MTTD、MTTR、パッチ適用率、再起動可能性、回避策展開能力が重要になる。 |
| 脆弱性管理 | 公開 CVE やベンダー advisory に反応する業務として扱う。 | AI 支援探索、依存関係監査、設定監査、ログ監視を含む継続工程になる。 | 発見、分類、修正、適用、再観測を一つのパイプラインとして管理する。 |
| 責任の所在 | 脆弱性を作った開発者や、パッチを出すベンダーに責任が集中しやすい。 | 発見者、保守者、ベンダー、利用者、運用者、規制当局の連鎖的責任になる。 | 誰が何をいつまでに行うかを、CVD、SLA、運用手順で明確化する必要がある。 |
| 説明責任 | 重大事故後に、原因と対応を説明するものになりやすい。 | 未修正リスク、優先順位、回避策、適用計画を継続的に説明する責任になる。 | 判断記録、リスク受容、例外管理、残存リスクの明示が重要になる。 |
この変化は、組織の「見たくないものを見ない」構造を維持しにくくする。弱点が観測されにくい社会では、組織は「知らなかった」「報告がなかった」「問題は起きていない」と言いやすい。しかし、AI によってコード、設定、ログ、依存関係、過去事例との類似性が広く観測されるようになると、知らなかったこと自体が問い直される。もちろん、すべてを事前に発見することは不可能である。しかし、重要資産について観測手段を持たず、報告経路を整えず、発見後の修正能力も持たないなら、それは単なる不運ではなく、修正責任の欠落として評価されるようになる。
一方で、弱点探しの網羅化には副作用もある。第一に、誤検知が増える。AI が出した候補のすべてが本当の脆弱性ではない。第二に、報告量が増える。特に OSS では、低品質な AI 生成報告が保守者の時間を奪う可能性がある。第三に、優先順位付けが難しくなる。すべての問題に即時対応しようとすれば、重要な修正に集中できない。第四に、組織が防御のための観測結果を十分に管理できなければ、その情報自体が攻撃者にとって有用な地図になる。したがって、網羅的観測は、それだけで安全性を高めるわけではない。観測結果を扱う制度、権限、ログ、秘匿、開示、修正能力が必要になる。
| 副作用 | 何が起きるか | 放置した場合の問題 | 必要な対策 |
|---|---|---|---|
| 誤検知の増加 | AI が危険そうに見えるが実際には到達不能な候補を多数出す。 | 現場が疲弊し、重要な警告がノイズに埋もれる。 | 再現性、到達可能性、資産重要度を使ったトリアージを行う。 |
| 保守者負荷の増大 | OSS や社内基盤へ、低品質な AI 生成報告が大量に届く。 | 保守者の時間が奪われ、重要修正が遅れる。 | 報告テンプレート、再現手順、影響説明、重複確認、調整機関を整える。 |
| 優先順位の混乱 | 多数の問題が同時に可視化され、何から直すべきか分からなくなる。 | 重大リスクが後回しになり、軽微な問題に修正資源を浪費する。 | 深刻度、悪用容易性、到達可能性、社会的重要度、修正コストで優先順位を決める。 |
| 観測結果の漏洩 | 未修正の弱点リストや解析結果が外部に漏れる。 | 防御のための情報が攻撃者の地図になる。 | アクセス制御、監査ログ、情報分類、開示手順、修正前の秘匿管理を行う。 |
したがって、弱点探しの網羅化は、社会を自動的に安全にするのではない。それは、社会の潜在的不整合を見えるようにする。見えるようになった不整合を修正できる社会では、安全性は上がる。見えるようになった不整合を処理できない社会では、不安、責任回避、未処理リスク、攻撃可能性が増える。つまり、網羅的観測社会の成否は、観測能力ではなく、観測結果を修正履歴へ変換する能力に依存する。
この章の結論は、守るとは隠すことではなく、発見から修正までの遅延を短くすることだ、という点にある。欠陥が見つかること自体を失敗と見なす文化では、網羅的観測社会には適応できない。むしろ、欠陥が見つかったときに、速く、正確に、説明可能な形で修正できることが成熟した安全性になる。AI によって弱点探しが網羅化する社会では、脆弱性管理は特殊業務ではなく、文明の通常運転になる。
弱点探しが網羅化すると、社会の安全性は、欠陥の不存在ではなく、欠陥が発見される前提での観測・分類・修正・適用・説明・再観測の能力によって決まるようになる。弱点探しが網羅化した社会では、安全とは欠陥が見つからないことではなく、欠陥が見つかった後に短時間で修正履歴へ変換できることである。観測が網羅化するほど、責任は「知らなかった」から「見つかったものをどう扱ったか」へ移る。
9. 観測能力の上昇と修正責任
観測能力が上がると、責任の性質が変わる。従来、脆弱性や不具合に関する責任は、「誰がその欠陥を作ったのか」「なぜ設計時に防げなかったのか」「なぜレビューで見落としたのか」という原因責任として語られやすかった。もちろん、原因責任は重要である。設計不備、実装ミス、テスト不足、レビュー不足、運用上の放置が重大事故につながるなら、その原因を分析しなければならない。しかし、AI によって観測能力が上がる社会では、原因責任だけでは足りない。問題は、「欠陥がなぜ生じたのか」だけでなく、「見えてしまった欠陥を、誰が、どの順序で、どの速度で、どの説明責任のもとに修正するのか」へ移る。
ここで重要になるのが、修正責任である。修正責任とは、欠陥の発生原因を作った主体だけに負わせる責任ではない。むしろ、観測された不整合を、被害拡大を抑えながら、検証し、分類し、修正し、配布し、適用し、再観測する責任である。たとえば、脆弱性を作ったのが過去の開発者であっても、現在それを保守している主体には報告を受け取り、影響範囲を調べ、必要に応じて修正する責任がある。利用者にも、更新可能な運用を維持し、パッチを適用できる余地を残す責任がある。発見者にも、未修正利用者を危険にさらさない形で報告する責任がある。観測能力が上がる社会では、責任は一点に集まるのではなく、更新連鎖全体に分散する。
| 責任の種類 | 問う内容 | 典型的な対象 | AI 観測社会での変化 |
|---|---|---|---|
| 原因責任 | なぜ欠陥が生じたのか、誰の設計・実装・運用判断が原因だったのかを問う。 | 開発者、設計者、レビュー担当者、運用担当者、組織。 | 欠陥の発生原因を分析する責任は残るが、それだけでは発見後の被害拡大を防げない。 |
| 観測責任 | 重要な対象について、欠陥を発見するための妥当な手段を持っていたかを問う。 | ベンダー、企業、重要インフラ運用者、保守者、監査主体。 | AI 支援レビュー、fuzzing、依存関係監査、ログ監視を行うべき対象範囲が広がる。 |
| 応答責任 | 発見された欠陥に対して、どのように反応し、誰へ通知し、どう優先順位をつけたかを問う。 | 発見者、ベンダー、CVD 調整機関、利用組織。 | 「知らなかった」ではなく、「知った後に何をしたか」が中心的に問われる。 |
| 修正責任 | 欠陥を検証し、修正し、リリースし、適用し、再発防止へ落としたかを問う。 | 保守者、ベンダー、ディストリビューション、運用者、利用者。 | 観測量が増えるほど、修正能力と優先順位付け能力が安全性の中心になる。 |
| 説明責任 | なぜその対応を選び、何を後回しにし、どの残存リスクを受け入れたのかを説明できるかを問う。 | 企業、政府機関、重要インフラ運用者、OSS プロジェクト、利用組織。 | すぐ直せない場合でも、判断根拠、回避策、期限、残存リスクを説明する必要が増す。 |
この表が示すように、観測能力が上がる社会では、責任は「作った者が悪い」という単純な形では終わらない。もちろん、欠陥を生んだ設計や実装は検証されるべきである。しかし、現代のソフトウェアは、多数の開発者、OSS、ディストリビューション、クラウド、利用組織、設定、運用、依存関係の上に成立している。欠陥がどこかで生まれたとしても、それが社会的被害になるかどうかは、発見後の応答、修正、配布、適用に大きく左右される。したがって、修正責任は原因責任の後に付け足されるものではなく、AI 観測社会における安全性の中心になる。
この段階で、脆弱性開示の制度が重要になる。CISA の Coordinated Vulnerability Disclosure、CERT/CC の CVD ガイド、ISO/IEC 29147 は、発見者、ベンダー、調整機関、利用者の間で、情報をどの順番で共有し、どの時点で公開し、どのように修正を促すかを扱う枠組みである[15][16][17]。AI によって発見速度が上がるほど、開示制度は単なるマナーではなく、社会の安全弁になる。なぜなら、発見された情報は、防御者にとっては修正の材料だが、攻撃者にとっては攻撃の地図にもなるからである。
CVD が重要なのは、脆弱性情報を隠すためではない。むしろ、修正へ接続するためである。発見者がいきなり詳細な exploit 情報を公開すれば、未修正利用者を危険にさらす可能性がある。一方で、ベンダーが報告を握りつぶし、長期間放置すれば、発見者や利用者の信頼を損ない、結果として無秩序な公開を招く。調整機関は、発見者とベンダーの間に入り、再現確認、影響範囲、公開時期、修正状況、利用者通知を調整する。つまり、CVD は秘密保持の仕組みではなく、観測された不整合を修正履歴へ変換するための時間管理と責任分配の仕組みである。
| 主体 | 主な責任 | 責任を果たせない場合に起きること | AI 観測社会で重要になる点 |
|---|---|---|---|
| 発見者 | 脆弱性候補を検証し、再現手順、影響範囲、必要な証拠を添えて適切な相手へ報告する。 | 未検証報告が保守者を圧迫する。過度に早い公開が未修正利用者を危険にさらす。 | AI 生成の候補をそのまま投げず、再現性と影響説明を整える必要がある。 |
| ベンダー・保守者 | 報告を受け取り、再現し、深刻度を評価し、修正し、公開方針を決める。 | 放置や不透明な対応により、信頼低下、無秩序な公開、利用者被害が発生する。 | 報告量が増えるため、受付体制、優先順位付け、修正 SLA、低品質報告への対応基準が必要になる。 |
| 調整機関 | 発見者、ベンダー、利用者、関係プロジェクトの間で情報共有と公開時期を調整する。 | 関係者間の不信、公開時期の混乱、修正前の情報拡散が起きやすくなる。 | 複数ベンダー、OSS、ディストリビューション、クラウドにまたがる脆弱性で重要性が増す。 |
| ディストリビューション・クラウド事業者 | 上流修正を取り込み、自環境の利用者へ安全な形で配布・展開する。 | 上流では修正済みでも、利用者環境に届かず危険窓が残る。 | 大規模展開、互換性確認、ロールバック、利用者通知、マネージド環境での自動適用が重要になる。 |
| 利用組織 | 自組織の影響範囲を調べ、パッチ、回避策、監視強化、再起動を実施する。 | パッチが公開されても適用されず、既知脆弱性として攻撃され続ける。 | 資産管理、SBOM、依存関係把握、停止計画、例外管理、適用率追跡が必要になる。 |
| 規制当局・政府 | 重要インフラ、開示制度、最低限の安全基準、支援策、悪用情報共有を整える。 | 重大リスクが個別組織の判断に閉じ、社会全体の修正速度が上がらない。 | AI による発見量増加に対応するため、制度、標準、支援、評価機関を整備する必要がある。 |
このように、修正責任は連鎖的である。発見者が正しく報告しても、ベンダーが受け取らなければ止まる。ベンダーが修正しても、ディストリビューションやクラウドへ届かなければ止まる。パッチが配布されても、利用組織が適用しなければ止まる。利用組織が適用しようとしても、資産管理が不十分で影響範囲が分からなければ止まる。どこか一箇所が詰まると、観測された不整合は修正履歴へ変換されず、未処理リスクとして残る。
AI によって発見速度が上がると、この連鎖の弱い部分が露出する。発見者が増え、報告が増え、候補が増え、ノイズも増える。すると、ベンダーや OSS 保守者の受付能力、再現能力、優先順位付け能力が問われる。修正が増えると、レビュー、テスト、リリース、互換性確認が問われる。パッチが増えると、利用組織の適用能力、再起動計画、業務停止調整が問われる。つまり、観測能力の上昇は、単に脆弱性を見つける力を増やすだけでなく、社会全体の修正連鎖を負荷試験する。
この変化により、「知らなかった」という免責は弱くなる。もちろん、すべての欠陥を事前に知ることは不可能である。未知の脆弱性が存在すること自体を、直ちに責任として扱うべきではない。しかし、重要資産について妥当な観測手段を持たず、報告経路もなく、発見後の対応手順もなく、パッチ適用計画もない場合、それは単なる無知ではなく、修正責任の欠落として見られるようになる。AI 観測社会では、「知らなかった」よりも「知ろうとする仕組みを持っていたか」「知った後に何をしたか」が問われる。
ここで、修正責任は全件即時対応を意味しないことも明確にしておく必要がある。観測される問題が増えれば、すべてを即時修正することは不可能である。だからこそ、優先順位付けが責任になる。深刻度、悪用容易性、到達可能性、社会的重要度、修正コスト、代替策、公開状況、悪用確認の有無を踏まえて、どの問題を先に処理し、どの問題を後回しにするかを決める必要がある。責任ある組織とは、すべてを直ちに直せる組織ではなく、限られた資源の中で、優先順位と残存リスクを説明できる組織である。
| 観測後の状態 | 望ましい扱い | 不適切な扱い | 責任上の意味 |
|---|---|---|---|
| 重大で悪用容易な脆弱性 | 最優先で再現確認し、緊急修正、回避策、利用者通知、監視強化へ進める。 | 通常 backlog に積み、期限や担当者を決めずに放置する。 | 既知の高リスク放置として重い責任が生じる。 |
| 重大だが成立条件が限定的な脆弱性 | 影響範囲を絞り、該当環境へ優先通知し、修正または緩和策を用意する。 | 重大という言葉だけで全環境へ過剰対応を強いる。 | 過小評価も過剰反応も避け、条件付きリスクとして説明する責任がある。 |
| 再現不十分な候補 | 追加情報を求め、再現条件、影響範囲、到達可能性を確認する。 | 根拠なく無視する、または未検証のまま重大脆弱性として扱う。 | 観測結果を適切に解釈する責任が問われる。 |
| 軽微な不備 | 通常の保守計画、設計改善、将来リリース、テスト追加に組み込む。 | 重大リスクと同列に扱い、修正資源を浪費する。 | 限られた修正能力を適切に配分する責任がある。 |
| 誤検知 | 判断理由を記録し、類似報告への対応基準を改善する。 | 報告者を一律に拒絶する、または誤検知処理を記録しない。 | 低品質報告への対応も、修正連鎖を維持するための制度設計になる。 |
この表が示すように、観測後の責任は、単に「直すか直さないか」ではない。重大度と成立条件に応じて、緊急修正、回避策、通知、監視、追加検証、将来修正、誤検知処理を使い分ける必要がある。ここで重要なのは、判断を記録し、説明可能にしておくことである。後から事故が起きたときに、なぜその問題を後回しにしたのか、どの情報に基づいて軽微と判断したのか、どの代替策を取ったのかを説明できなければ、修正責任を果たしたとは言いにくい。
したがって、AI による観測能力の上昇は、社会に二つの要求を突きつける。第一に、見つかった問題を受け止める制度である。CVD、CVE、advisory、パッチ配布、利用者通知、規制報告、監査ログがここに含まれる。第二に、見つかった問題を処理する能力である。トリアージ、再現、修正、テスト、リリース、適用、再観測、説明がここに含まれる。この二つがそろって初めて、観測能力は安全性へ変わる。どちらかが欠ければ、観測能力は未処理リスクと社会不安を増やすだけになる。
この章の結論は、観測能力が上がるほど、責任は原因責任から修正責任へ重心を移すということである。欠陥がなぜ生じたかを問うことは必要だが、それだけでは不十分である。AI が潜在的不整合を高解像度で観測する社会では、見えた問題をどう扱うか、どの順序で直すか、直せない場合にどう説明するかが中心になる。つまり、AI 時代の責任とは、欠陥の存在を責めることではなく、観測された不整合を修正履歴へ変換する責任である。
観測能力が上がるほど、責任は「欠陥を作った責任」から「見えてしまった欠陥をどう扱うか」という修正責任へ重心を移す。修正責任は、発見者、保守者、ベンダー、調整機関、利用者、規制当局の連鎖責任として成立する。
10. KEV、CVE、NVD、CVSS は何を担うか
AI によって脆弱性候補の発見数が増える社会では、脆弱性情報を整理するための参照座標が重要になる。脆弱性は、単に「危険なバグ」として存在しているだけでは実務で扱いにくい。どの製品の、どのバージョンに、どのような条件で、どのような影響を与え、既に悪用されているのか、修正はあるのか、回避策はあるのか、どの程度急ぐべきなのかを、複数の組織が共通の言葉で扱える必要がある。CVE、NVD、CVSS、KEV は、このための制度的な座標系である。
まず、CISA の KEV は、既に悪用が確認された脆弱性を優先対応対象として示す実務リストである[18]。CVE は公開された脆弱性へ共通識別子を与える仕組みである[19]。CVE があることで、ベンダー、ディストリビューション、クラウド事業者、セキュリティ製品、利用組織、研究者が、同じ脆弱性について同じ名前で議論できる。NVD は、CVE に対して標準化された脆弱性管理データを付与するデータベースである[20]。CVSS は、脆弱性の深刻度を一定の観点から数値化する枠組みである[21]。これらはそれぞれ役割が違う。混同すると、脆弱性管理はすぐに誤る。
| 仕組み | 主な役割 | 提供するもの | 提供しないもの | 実務上の使い方 |
|---|---|---|---|---|
| CVE | 公開脆弱性に共通識別子を与える。 | 脆弱性を一意に参照するための ID と基本的な説明。 | 必ずしも詳細な深刻度判断、悪用状況、各組織での優先順位を直接与えるわけではない。 | 同じ脆弱性を、ベンダー、利用者、ツール、レポート、パッチ情報の間で対応付けるために使う。 |
| NVD | CVE 情報へ標準化された脆弱性管理データを付与する。 | 説明、影響製品、CPE、CVSS、参照リンクなどの管理用情報。 | 自組織で実際に影響があるか、今すぐ止めて直すべきかまでは決めない。 | 脆弱性管理ツール、依存関係監査、影響範囲調査の基礎データとして使う。 |
| CVSS | 脆弱性の技術的深刻度を数値化する。 | 攻撃元区分、攻撃複雑性、必要権限、利用者関与、機密性・完全性・可用性への影響などに基づくスコア。 | 実際の悪用有無、自組織の露出面、資産重要度、パッチ適用可能性までは反映しきれない。 | 初期優先度付けの材料として使い、自組織文脈で補正する。 |
| KEV | 既に悪用が確認された脆弱性を示す。 | 実際に悪用されている脆弱性のリストと対応期限の目安。 | KEV に載っていない脆弱性が安全であることは意味しない。 | 優先対応リストとして扱い、該当資産があれば迅速に確認・修正する。 |
この表から分かるように、CVE、NVD、CVSS、KEV は同じものではない。CVE は名前であり、NVD は管理データであり、CVSS は深刻度評価であり、KEV は悪用確認済みリストである。つまり、CVE が付いたから重大とは限らず、CVSS が高いから必ず最優先とも限らず、KEV に載っていないから安全とも限らない。これらは判断を代替するものではなく、判断を始めるための参照点である。
AI 時代には、この参照座標の重要性が増す。理由は単純である。発見数が増えるほど、個々の脆弱性を人間が直感で見て優先順位を決めることが難しくなるからである。AI 支援探索によって、脆弱性候補、設定不備、依存関係リスク、類似バグ、到達可能な危険経路が大量に提示されるようになると、組織はそれらを名前、影響範囲、深刻度、悪用状況、修正可用性、資産重要度へ変換しなければならない。ここで共通識別子と標準指標がなければ、組織間で同じ対象を議論できない。
ただし、標準指標は万能ではない。たとえば、CVSS が高い脆弱性でも、自組織の環境では該当機能を使っていない、外部から到達できない、補完統制が効いている、対象バージョンが存在しない、という場合がある。逆に、CVSS が中程度でも、インターネットへ露出した重要資産に存在し、悪用コードが公開され、パッチ適用が難しく、攻撃者に広く狙われているなら、実務上は高優先度になる。CVSS は技術的性質を整理するが、組織固有の露出面、資産価値、運用制約、悪用状況を完全には表さない。
| 判断層 | 見る情報 | 代表的な参照先 | 実務判断で追加すべき情報 |
|---|---|---|---|
| 識別 | どの脆弱性か。 | CVE。 | 自組織の資産台帳、依存関係、パッケージ名、製品名との対応。 |
| 説明 | 何が起きる脆弱性か。 | NVD、ベンダー advisory、ディストリビューション情報。 | 自組織で該当機能を使っているか、設定条件が一致するか。 |
| 深刻度 | 技術的にどの程度深刻か。 | CVSS。 | インターネット露出、認証要否、攻撃容易性、補完統制、重要資産かどうか。 |
| 悪用状況 | 既に実際の攻撃で使われているか。 | KEV、ベンダー情報、脅威インテリジェンス、セキュリティ製品の検知情報。 | 自組織への攻撃兆候、ログ、EDR、WAF、IDS、外部公開面。 |
| 修正可用性 | パッチや回避策が存在するか。 | ベンダー advisory、ディストリビューション、クラウド事業者、OSS リリース。 | 適用可能なメンテナンス窓、互換性、再起動可否、ロールバック手段。 |
| 優先順位 | いつ、どの順番で対応するか。 | CVSS、KEV、ベンダー緊急度、社内リスク基準。 | 資産重要度、業務影響、停止許容度、攻撃兆候、残存リスクの説明可能性。 |
この流れで見ると、脆弱性管理は単なるデータベース照会ではない。CVE で名前を得る。NVD やベンダー情報で内容を知る。CVSS で技術的深刻度を見る。KEV や脅威情報で悪用状況を見る。自組織の資産情報で影響範囲を確認する。パッチや回避策の有無を見る。最後に、業務影響と修正可能性を踏まえて優先順位を決める。つまり、標準指標は入口であり、最終判断は自組織の文脈と結合して初めて成立する。
AI 時代に危険なのは、指標を過信することである。たとえば、AI が大量の脆弱性候補を出し、それに自動で CVSS 風のスコアを付けたとしても、その点数だけで修正順序を決めるのは危険である。AI が影響範囲を誤読することもある。到達不能な経路を危険と判断することもある。逆に、組織固有の重要資産や特殊な設定を見落とすこともある。脆弱性管理では、標準化されたスコアと、組織固有の文脈を分けて扱う必要がある。
| 誤用 | 何が起きるか | なぜ危険か | 適切な扱い |
|---|---|---|---|
| CVSS だけで優先順位を決める | 高スコアの脆弱性だけに対応し、中スコアや低スコアを放置する。 | 実際には外部露出や悪用状況によって、中スコア脆弱性の方が危険な場合がある。 | CVSS に加えて、KEV、露出面、資産重要度、パッチ可用性を見る。 |
| KEV に載っていないものを軽視する | 悪用未確認の脆弱性を後回しにする。 | KEV は既知悪用リストであり、未掲載が安全を意味するわけではない。 | KEV は優先度上げの強いシグナルとして扱い、未掲載脆弱性も文脈で評価する。 |
| CVE がない候補を無視する | 未採番、未公開、設定依存、社内固有の弱点を見落とす。 | CVE が付く前の段階でも、実害ある脆弱性や設定不備は存在し得る。 | CVE の有無と実リスクを分け、社内リスクや未公開報告も管理する。 |
| NVD 情報だけを見る | ベンダー固有情報、ディストリビューションの backport、影響バージョン差を見落とす。 | NVD の情報だけでは、自環境における修正状態や影響範囲を誤ることがある。 | ベンダー advisory、ディストリビューション情報、実際のパッケージバージョンを確認する。 |
| AI の自動評価をそのまま採用する | 誤検知や文脈誤読を含む評価が、修正計画へ直接入る。 | 限られた修正資源を誤った対象へ使い、重要リスクを見落とす可能性がある。 | AI 評価は一次整理として使い、人間のトリアージ、再現確認、資産文脈で補正する。 |
この表が示すように、KEV、CVE、NVD、CVSS は、それぞれ強力な補助線である一方、単独では実務判断を完結させない。特に、AI によって発見量が増えると、組織は自動化されたスコアリングに頼りたくなる。しかし、自動化は判断を支援するだけであり、責任を消すものではない。どの脆弱性を先に直すか、どの資産を一時隔離するか、どのリスクを例外として受け入れるか、どの利用者へ通知するかは、最終的には組織の判断として残る。
また、これらの制度的指標は、分散した組織の同期装置でもある。ある脆弱性について、上流 OSS、Linux ディストリビューション、クラウド事業者、セキュリティベンダー、企業ユーザー、政府機関が別々の名前で呼んでいれば、修正状況や悪用状況を共有できない。CVE は対象をそろえる。NVD は管理データをそろえる。CVSS は深刻度の言語をそろえる。KEV は悪用確認済みという優先シグナルをそろえる。これにより、分散した社会が同じリスクを同じ対象として扱えるようになる。
ただし、AI 観測社会では、これらの制度にも負荷がかかる。AI 支援探索によって脆弱性候補が増えれば、CVE 採番、NVD 登録、CVSS 評価、ベンダー advisory、ディストリビューション修正、KEV への反映までの処理量が増える。制度的座標系が追いつかなければ、脆弱性情報は断片化し、同じ問題が複数名で呼ばれ、重複報告が増え、利用者は何を直せばよいか分からなくなる。つまり、AI による観測能力の上昇は、脆弱性情報インフラそのものの処理能力も試す。
したがって、この章の結論は、KEV、CVE、NVD、CVSS を「正解を出す装置」としてではなく、「分散社会が脆弱性を同じ対象として扱うための座標系」として理解すべきだということである。AI 時代には、脆弱性候補が増え、判断対象が増え、修正キューが増える。そのとき必要なのは、点数だけを見て機械的に動くことではない。識別、説明、深刻度、悪用状況、修正可用性、自組織の資産文脈を重ね合わせ、観測された不整合をどの順序で修正履歴へ変換するかを決めることである。
KEV、CVE、NVD、CVSS は脆弱性管理の答えではなく、分散した組織が同じ脆弱性を同じ対象として扱うための参照座標である。AI によって観測量が増えるほど、脆弱性情報を識別し、優先順位をつけ、修正工程へ流す制度的インフラの処理能力が問われる。
11. 修正責任はソフトウェア開発工程へ戻る
発見後の対応だけでは限界がある。AI によって脆弱性候補が大量に見つかる社会では、発見されたものをすべて後工程で処理する運用は破綻する。なぜなら、後工程での修正には、再現確認、影響範囲調査、パッチ作成、レビュー、回帰テスト、リリース、利用者通知、適用確認が必要であり、発見量が増えれば、そのすべてがボトルネックになるからである。したがって、修正責任は、インシデント発生後や advisory 公開後にだけ生じるものではない。設計時に安全な境界を作り、実装時に危険な API や曖昧な所有権を避け、テスト時に異常経路を揺さぶり、リリース時に依存関係を可視化し、運用時に更新可能性を維持する責任として、開発工程全体へ戻ってくる。
ここで重要なのは、セキュリティを「最後に検査するもの」として扱わないことである。従来型の発想では、機能を作り、リリースし、後から脆弱性診断を行い、見つかったものを修正するという流れになりやすい。しかし、AI が弱点探索を加速すると、この後工程集中モデルはすぐに詰まる。大量の候補が後から見つかり、修正担当者が不足し、互換性確認が遅れ、パッチ適用が進まず、未処理キューが積み上がる。つまり、セキュリティを後工程へ押し込めるほど、AI 観測社会では修正不能な backlog が増える。
| 開発工程 | 従来の失敗パターン | AI 観測社会で必要になる責任 | 実務上の意味 |
|---|---|---|---|
| 設計 | 機能要件を優先し、権限境界、信頼境界、データ所有権、失敗時の挙動を曖昧にしたまま実装へ進む。 | どの主体が何を読めるのか、何を書けるのか、どの境界を越えてはいけないのかを設計時点で明示する。 | 後から見つかる意味境界の破綻を減らすため、設計段階で安全性不変条件を定義する。 |
| 実装 | 局所的に動くコードを優先し、危険 API、曖昧なバッファ共有、例外的な権限経路、暗黙の前提を残す。 | 安全な API 選択、入力検証、所有権の明確化、エラー処理、権限チェック、ログ記録を実装責任として扱う。 | レビュー時に「動くか」だけでなく「どの境界を守っているか」を確認する。 |
| テスト | 正常系、主要ユースケース、既知バグの再発確認に偏る。 | 異常入力、境界条件、権限違反、競合、低頻度経路、依存先の失敗を継続的に揺さぶる。 | fuzzing、プロパティテスト、回帰テスト、AI 支援テスト生成を通常工程に組み込む。 |
| 依存関係管理 | ライブラリやコンテナーイメージを導入した後、どのバージョンがどこで使われているか追えなくなる。 | 構成要素、バージョン、ライセンス、脆弱性影響範囲を追跡可能にする。 | SBOM、lockfile、依存関係スキャン、更新方針を整備し、影響範囲評価を短縮する。 |
| リリース | パッチが作られても、利用者が影響範囲や更新手順を理解できない。 | 修正内容、影響範囲、回避策、互換性、更新手順、緊急度を説明可能にする。 | advisory、リリースノート、セキュリティ通知、署名、配布経路を整える。 |
| 運用 | 本番環境を止められず、パッチ適用、再起動、ロールバック、監視強化が遅れる。 | 更新できる構成、段階的適用、ロールバック、監視、例外管理を運用設計に含める。 | 修正が存在するだけでなく、実際に適用できる状態を維持する。 |
この表が示すように、修正責任は、脆弱性が発見された後に突然発生するものではない。後で直せるかどうかは、設計時、実装時、テスト時、リリース時、運用時にすでに決まっている。たとえば、依存関係が把握できていなければ、ある CVE が出ても影響範囲を調べられない。再起動できない本番環境なら、パッチが出ても適用できない。回帰テストがなければ、安全に修正できない。権限境界が設計文書に残っていなければ、何が破れているのか判断できない。したがって、修正責任とは、事後に謝罪する責任ではなく、変更可能性を維持する設計責任である。
NIST SSDF は、この考え方を開発工程側から整理する枠組みである。SSDF は、セキュアな開発環境の準備、ソフトウェアの保護、脆弱性の特定と修正、セキュアな実装と検証を含む実践を整理している[22]。これは、脆弱性を見つけてから場当たり的に直すのではなく、開発工程そのものにセキュリティを埋め込む発想である。AI によって観測量が増えるほど、SSDF 的な考え方は重要になる。なぜなら、後から大量に見つかる欠陥をすべて個別対応するより、欠陥が入り込みにくく、見つかったときに直しやすい工程を作る方が持続可能だからである。
SBOM は、修正責任を実行可能にするための索引である。ソフトウェアは、自社コードだけで成立していない。OSS、パッケージ、ライブラリ、コンテナーイメージ、ビルドツール、生成物、トランジティブな依存関係の集合である。ある依存先に脆弱性が見つかったとき、どの製品、どのサービス、どの環境、どのコンテナー、どのビルドが影響を受けるのかを調べられなければ、修正責任は実行できない。SBOM は、その構成要素を可視化し、影響範囲評価を速くするための基盤である[23][24]。
OSS-Fuzz、OpenSSF Scorecard、SLSA は、修正責任をさらに別の角度から開発工程へ押し戻す。OSS-Fuzz は継続的 fuzzing によって、異常入力や境界条件の問題を早期に発見する[25]。OpenSSF Scorecard は、オープンソースプロジェクトの保守状態、セキュリティ実践、依存関係、ブランチ保護、CI、署名などを評価する補助線になる[26]。SLSA は、ビルドや成果物の由来、改ざん耐性、サプライチェーン完全性を段階的に高める枠組みである[27]。これらはすべて、脆弱性が発見された後に慌てて対応するのではなく、発見、修正、配布、信頼性確認を開発工程の中に埋め込むための仕組みである。
| 枠組み | 担う領域 | 修正責任との関係 | AI 時代に重要になる理由 |
|---|---|---|---|
| NIST SSDF | セキュアソフトウェア開発の実践全体。 | 設計、実装、検証、脆弱性対応を開発工程の責任として整理する。 | 発見後対応だけでなく、欠陥が入り込みにくく直しやすい工程を作る必要が増す。 |
| SBOM | ソフトウェア構成要素と依存関係の可視化。 | 脆弱性が見つかったとき、影響範囲を短時間で調べるための基盤になる。 | AI によって発見数が増えるほど、影響範囲評価の速度が重要になる。 |
| OSS-Fuzz | OSS に対する継続的 fuzzing。 | 異常入力や境界条件の欠陥を早期に発見し、修正工程へ流す。 | 人間が見逃す低頻度経路や入力依存の不具合を継続的に観測できる。 |
| OpenSSF Scorecard | OSS プロジェクトのセキュリティ実践評価。 | 依存先の保守状態やリスクを把握し、導入・更新判断の材料にする。 | AI が依存関係リスクを可視化するほど、依存先の状態を定量的に把握する必要が増す。 |
| SLSA | ソフトウェア成果物のサプライチェーン完全性。 | ビルド、署名、由来、改ざん耐性を管理し、修正済み成果物を信頼できる形で届ける。 | 脆弱性修正だけでなく、修正済み成果物が正しく作られ配布されたことの保証が必要になる。 |
この表から分かるように、各枠組みは単独で万能ではない。SSDF は開発工程全体の原則を与えるが、具体的な依存関係の一覧を自動で作るわけではない。SBOM は構成要素を可視化するが、脆弱性を自動で修正するわけではない。OSS-Fuzz は入力空間を揺さぶるが、すべての設計不備や権限境界の破綻を見つけるわけではない。Scorecard はプロジェクト状態を評価するが、安全性を保証するわけではない。SLSA はサプライチェーンの完全性を高めるが、アプリケーションロジックの正しさを保証するわけではない。重要なのは、これらを組み合わせ、観測から修正までの工程を短くすることである。
AI によって弱点探しが網羅化すると、開発者は未処理指摘の洪水に沈みやすくなる。AI は、潜在的な危険箇所、過去 CVE と似た構造、古い依存関係、設定不備、テスト不足、権限境界の曖昧さを大量に指摘できる。しかし、それらの指摘が、設計判断、 issue、修正、テスト、レビュー、リリースへ流れなければ意味がない。むしろ、ノイズだけが増え、開発者は重要な指摘を見失う。したがって、AI 支援レビューは、開発工程の外側に置かれた検査装置ではなく、開発工程内の判断、修正、記録へ接続されなければならない。
| AI 支援で増えるもの | そのまま放置した場合 | 開発工程へ戻す方法 | 期待される効果 |
|---|---|---|---|
| 脆弱性候補 | 誤検知と真のリスクが混ざり、開発者が処理しきれない。 | 再現性、到達可能性、影響範囲、資産重要度でトリアージする。 | 修正すべき候補を優先順位付き backlog へ変換できる。 |
| 設計上の不整合 | 個別バグ修正だけで済ませ、同じ構造の問題が残る。 | 安全性不変条件、権限境界、データ所有権、失敗時動作を設計文書へ戻す。 | 同種の脆弱性を構造的に減らせる。 |
| 依存関係リスク | 影響範囲が分からず、パッチ適用判断が遅れる。 | SBOM、依存関係スキャン、更新方針、例外管理へ接続する。 | 脆弱性発見後の影響範囲評価を短縮できる。 |
| テスト不足 | 修正の副作用が怖く、パッチ適用やリリースが遅れる。 | 回帰テスト、fuzzing、異常系テスト、境界条件テストを追加する。 | 安全に変更できる範囲が広がり、修正速度が上がる。 |
| サプライチェーン上の弱点 | 修正済み成果物の由来や完全性を確認できない。 | 署名、ビルド由来、成果物管理、SLSA 的な段階的保証へ接続する。 | 修正済みソフトウェアを信頼できる形で配布できる。 |
ここで本質的なのは、修正責任を「後から直す責任」としてだけ捉えないことである。後から直すためには、後から直せる構造が必要である。コードが理解不能で、テストがなく、依存関係が不明で、リリース手順が属人化し、ロールバックできず、利用者が更新できないなら、どれほど脆弱性を発見しても修正は進まない。逆に、設計境界が明確で、テストがあり、依存関係が追跡でき、CI/CD が整い、署名と配布が管理され、利用者が更新可能なら、脆弱性が見つかっても短時間で修正履歴へ変換できる。
したがって、修正責任はソフトウェア開発工程へ戻る。安全な設計をすること、危険な実装を避けること、異常系をテストすること、依存関係を可視化すること、成果物の由来を保証すること、パッチを安全に出せること、利用者が更新できるようにすること。これらはすべて、発見後の対応を速くするための前提である。AI 観測社会では、脆弱性を見つける能力だけでなく、見つかった脆弱性を変更可能な工程へ流し込む能力が問われる。
この章の結論は、セキュリティを後工程の検査に閉じ込めてはいけないということである。AI が弱点を大量に見つける社会では、検査だけを増やすと、開発者は未処理指摘の洪水に沈む。必要なのは、設計時の境界確認、実装時の安全な API 選択、テスト時の異常経路探索、リリース時の依存情報公開、運用時の更新可能性確保を一つの連鎖にすることである。修正責任とは、障害発生後の謝罪ではなく、観測された不整合を短時間で修正履歴へ変換できる開発工程を維持する責任である。
AI が脆弱性候補を大量に見つける社会では、修正責任は事後対応ではなく、後で直せる構造をあらかじめ作る開発工程上の責任になる。AI リスク管理も同じで、モデル単体を危険視するのではなく、能力をどの工程・制度・責任構造へ接続するかが問われる。
12. AI リスク管理の位置づけ
AI リスク管理は、AI を禁止するための枠組みではない。むしろ、AI の便益と危険を、利用文脈、利用者、アクセス条件、出力範囲、監査、責任分担、更新手順に応じて扱うための枠組みである。Claude Mythos のようなサイバー能力を持つモデルを考えるとき、問題を「危険だから封印する」か「便利だから公開する」かの二択にすると、本質を取り逃がす。なぜなら、同じモデル能力であっても、防御目的で管理された環境に置かれる場合と、匿名利用者が外部ネットワークへ接続できる状態で使う場合では、リスクがまったく異なるからである。
NIST AI RMF は、AI システムのリスクを Govern、Map、Measure、Manage の機能で扱う枠組みを示している[28]。AI RMF Playbook は、それを実務行動へ落とす補助線を提供する[29]。ここで重要なのは、AI リスクをモデル内部の性能値だけで評価しないことである。モデルが何をできるかは重要だが、それだけでは十分ではない。そのモデルを誰が使うのか、どの対象に使うのか、どのツールへ接続されるのか、結果がどう監査されるのか、危険な出力が出たときに誰が止めるのか、発見された脆弱性がどの開示制度へ流れるのかまで含めて、初めてリスク管理になる。
| AI RMF の観点 | 一般的な意味 | Claude Mythos 型サイバー AI での意味 | 本稿での位置づけ |
|---|---|---|---|
| Govern | AI リスクを管理する組織方針、責任、手続き、監督体制を整える。 | 誰に高能力サイバー AI を使わせるのか、利用資格、禁止用途、監査責任、停止権限を定める。 | モデル能力を社会へ接続する前に、責任主体と統治構造を決める段階である。 |
| Map | AI が使われる文脈、利用者、影響範囲、リスク源を把握する。 | 防御監査、OSS 保守、政府評価、企業診断、研究、商用利用、攻撃的利用の違いを分ける。 | 同じモデルでも、利用文脈が違えばリスクが変わることを明示する段階である。 |
| Measure | AI の性能、限界、失敗、悪用可能性、影響を評価する。 | 脆弱性発見能力、誤検知率、exploit 支援能力、制約回避、危険出力、評価環境と実環境の差を測る。 | 「危険そう」という印象ではなく、どの能力がどの段階まで届くかを測る段階である。 |
| Manage | 測定されたリスクを低減し、監視し、必要に応じて更新する。 | アクセス制御、出力制約、監査ログ、CVD 接続、利用停止、再評価、インシデント対応を運用する。 | 観測されたリスクを制度と運用で吸収し、修正責任へ接続する段階である。 |
この表が示すように、AI リスク管理は「モデルを危険視すること」ではない。モデル能力を、どの統治構造、利用文脈、評価手法、運用制御へ接続するかを決めることである。Claude Mythos 型のモデルでは、この点が特に重要になる。サイバー能力はデュアルユース性が高い。脆弱性を探す能力は、防御者にとっては修正のための観測能力であり、攻撃者にとっては侵害経路を探す能力である。したがって、リスク管理では、能力そのものを単独で見るのではなく、その能力がどの行為連鎖へ接続されるかを見なければならない。
この観点から見ると、AI サイバー能力の問題は、モデル単体の問題ではなく、利用環境の問題である。同じモデルでも、公開範囲、ツールアクセス、ネットワーク到達性、ログ、審査、出力制約、利用者資格、通報経路が違えば、リスクは変わる。たとえば、ネットワーク接続のない隔離環境で、認証された防御担当者が、監査ログ付きで、対象リポジトリに限定して、発見結果を CVD フローへ流す場合と、匿名利用者が外部ホストへ到達できるツール付きで、攻撃手順の詳細を得られる場合では、同じモデルでも社会的意味が異なる。AI の能力だけを取り出して危険度を語るのは、ナイフの鋭さだけで外科手術と暴力を同一視するようなものである。
| リスク要素 | 低リスク寄りの構成 | 高リスク寄りの構成 | 管理上の要点 |
|---|---|---|---|
| 利用者資格 | 本人確認済みの防御担当者、OSS 保守者、研究者、企業セキュリティチームに限定する。 | 匿名または低審査の利用者へ高能力サイバー機能を広く提供する。 | 誰に使わせるかは、モデル能力と同じくらい重要なリスク要因である。 |
| 対象範囲 | 自組織、自社製品、許可された OSS、検証環境に限定する。 | 第三者システム、外部ネットワーク、実運用環境への無断調査に使える。 | 正当な監査対象と無許可の攻撃対象を明確に分ける必要がある。 |
| ツールアクセス | 読み取り中心、隔離環境、限定リポジトリ、ログ付き実行に制限する。 | 外部スキャン、exploit 実行、認証試行、横展開補助に接続できる。 | モデル出力だけでなく、モデルが使える道具を管理する必要がある。 |
| 出力制約 | 脆弱性の説明、影響範囲、修正案、検証観点、CVD 報告形式を中心にする。 | 攻撃手順、安定 exploit、検知回避、永続化、横展開の詳細を出せる。 | 防御に必要な情報と攻撃に直結する情報の境界を設計する必要がある。 |
| 監査ログ | 誰が、いつ、何を対象に、どの出力を得たかを記録する。 | 利用履歴が残らず、誤用や漏洩後の追跡ができない。 | 高能力サイバー AI では、監査可能性そのものが安全機能になる。 |
| 発見後の接続先 | CVD、社内セキュリティチーム、OSS 保守者、ベンダー報告窓口へ接続する。 | 発見結果が利用者の手元に残り、未修正のまま攻撃情報として滞留する。 | 観測結果を修正履歴へ流す制度がなければ、発見能力は安全性へ変わらない。 |
この表から分かるように、AI サイバー能力のリスクは、モデルの能力値だけでは決まらない。むしろ、利用者、対象、ツール、出力、監査、報告経路の組み合わせによって変わる。高能力モデルでも、利用範囲が明確で、監査され、修正フローへ接続されていれば、防御力を高める方向へ使える。一方で、中程度のモデルでも、外部スキャン、攻撃手順、認証試行、検知回避、匿名利用が組み合わされば、実害に近づく。したがって、AI リスク管理は、モデル単体ではなく、モデルを含む利用システム全体の設計問題である。
ここで「公開か封印か」という二択は不十分である。全面公開は、能力を広く民主化し、防御者や研究者にも届かせる一方で、悪用者にも届く。完全封印は、悪用可能性を下げるように見える一方で、大企業や政府だけが高能力探索手段を持つ不透明な状態を作る。限定公開は、その中間に見えるが、誰が選ばれるのか、基準は透明か、OSS 保守者や小規模組織はアクセスできるのか、監査は十分かという問題を生む。したがって、問うべきなのは「出すか出さないか」ではなく、「どの能力を、どの利用者に、どの対象範囲で、どの監査と責任の下に使わせるか」である。
| 公開方式 | 利点 | リスク | 必要な補完策 |
|---|---|---|---|
| 全面公開 | 研究者、防御者、OSS、教育、小規模組織にも能力が届きやすい。 | 悪用者にも同じ能力が届き、攻撃準備のコストを下げる可能性がある。 | 安全評価、利用ガイド、危険機能制限、悪用監視、段階的公開が必要になる。 |
| 完全封印 | 短期的には広範な悪用リスクを抑えられる可能性がある。 | 防御側の広範な利用も阻害され、能力が一部組織に集中し、不透明性が増す。 | 独立評価、公共的監査、代替防御支援、封印期間と再評価条件が必要になる。 |
| 限定公開 | 防御者や選定組織へ能力を届けつつ、広範な悪用を抑制しやすい。 | アクセス権の政治、不透明な選定、漏洩、内部不正、OSS 保守者の排除が問題になる。 | 選定基準、監査ログ、利用目的制限、CVD 接続、第三者評価が必要になる。 |
| 段階的公開 | 能力の影響を観察しながら、公開範囲や機能を徐々に広げられる。 | 評価が遅れれば防御側の利用も遅れ、逆に緩すぎれば悪用リスクが増える。 | 公開段階ごとの評価指標、事故時停止条件、フィードバック回路が必要になる。 |
この整理から分かるように、AI リスク管理は単なるブレーキではない。ブレーキだけなら、すべてを止めればよい。しかし、AI サイバー能力は防御にも有用である。OSS の弱点を早期に見つける。古いコードを読む。設定不備を検出する。CVD 報告を整える。修正案やテスト案を作る。利用者通知を分かりやすくする。これらの便益を捨てることも、社会的損失である。したがって、リスク管理の目的は能力を消すことではなく、能力を攻撃履歴ではなく修正履歴へ流すことである。
この点で、AI リスク管理は前章までの修正責任と接続する。高能力サイバー AI が脆弱性を発見したとしても、その結果が孤立した利用者の手元に残れば危険である。逆に、その結果が再現確認、影響範囲評価、CVD、パッチ作成、テスト、リリース、利用者通知へ流れれば、防御力になる。つまり、モデル能力は、それ自体では善でも悪でもない。問題は、その能力がどの制度的経路へ接続されるかである。
また、リスク管理は一度決めれば終わるものではない。AI モデルの能力は更新される。攻撃者の使い方も変わる。防御者の運用も変わる。評価環境での成績と実環境での影響もずれる。したがって、アクセス制御、出力制約、監査、CVD 接続、利用者資格、危険行為の検知は、継続的に再評価されなければならない。AI RMF が示すように、リスク管理は静的な許可・禁止表ではなく、運用しながら測定し、見直し、管理する循環である。
| 管理対象 | 一度だけ決める場合の問題 | 継続管理で行うこと | Claude Mythos 型モデルでの意味 |
|---|---|---|---|
| モデル能力 | 初期評価時より能力が上がり、想定外の使い方が可能になる。 | 定期的なレッドチーム評価、ベンチマーク更新、実利用ログからの再評価を行う。 | 脆弱性探索、攻撃手順化、制約回避能力が変化していないか確認する。 |
| 利用者 | 正当利用者が転職、権限変更、内部不正、漏洩を起こす可能性がある。 | 資格確認、権限見直し、利用目的確認、異常利用検知を行う。 | 高能力機能を使える主体を継続的に管理する。 |
| 出力 | 当初安全と見なした出力形式が、悪用手順として再利用される可能性がある。 | 危険出力のフィードバック、ポリシー更新、段階的な出力制限を行う。 | 防御に必要な説明と攻撃に直結する詳細の境界を更新する。 |
| ツール接続 | 新しいツール連携により、読み取り専用だった利用が実行可能な攻撃へ近づく。 | ツール権限、ネットワーク到達性、実行権限、隔離環境を見直す。 | モデルが外部スキャンや exploit 実行へ接続しないよう管理する。 |
| 発見後フロー | 脆弱性発見結果が滞留し、修正へ接続されない。 | CVD、社内チケット、OSS 報告、ベンダー連絡、修正 SLA へ接続する。 | 観測能力を修正能力へ変換する経路を維持する。 |
この表が示すように、AI リスク管理は、静的な許可リストや禁止リストでは不十分である。モデル能力、利用者、出力、ツール、発見後フローは変化する。特にサイバー能力では、モデルが直接危険な出力を出さなくても、他のツール、外部情報、利用者の知識と組み合わされることで、攻撃に近づくことがある。したがって、管理すべき対象はモデル単体ではなく、モデルを中心にした行為連鎖である。
この章の結論は、Claude Mythos 型の AI を考えるとき、問うべきなのは「危険な能力を持つか」だけではないということである。もちろん能力評価は必要である。しかし、同じ能力でも、誰が、何に、どの範囲で、どのツールとともに、どの監査の下で、どの報告経路へ接続して使うかによって、社会的意味は変わる。AI リスク管理とは、能力を封印するか解放するかの二択ではなく、能力を修正責任の制度へ接続し、悪用へ流れる経路を狭め、防御へ流れる経路を太くする設計である。
AI リスク管理とは、モデル能力そのものを善悪で裁くことではなく、その能力がどの利用文脈、アクセス条件、監査構造、責任分担、修正工程へ接続されるかを管理することである。
ここまでで、観測能力、悪用可能性、修正責任、制度的制御を整理した。次に、これらを数理モデルとして記述する。
13. 数理モデル化の出発点
ここから、これまでの議論を数理モデルへ移す。ただし、ここで行う数理モデル化は、現実の脆弱性管理を完全に予測するための精密モデルではない。目的は、Claude Mythos 騒動を通じて見えてきた構造、すなわち、観測能力の上昇、悪用可能性、修正責任、社会的被害の関係を、最小限の変数で整理することである。したがって、このモデルは、個別製品の脆弱性数を正確に予測するものではなく、社会がどの条件で安全側へ動き、どの条件で不安定側へ動くのかを理解するための構造モデルである。
まず、対象となる社会を、時間とともに更新される脆弱性管理システムとして考える。時刻 \(t\) において、ソフトウェア、設定、依存関係、運用、サプライチェーンの中には、まだ観測されていない潜在的不整合が存在する。それらの一部は脆弱性として成立し、一部は単なる品質問題であり、一部は特定条件でのみ危険化する。AI による弱点探索が強まると、この潜在的不整合の一部が観測される。観測された不整合は、防御者によって修正されれば安全性の更新へ変わるが、攻撃者によって悪用されれば被害へ変わる。したがって、モデル化すべき中心は、脆弱性の存在そのものではなく、潜在状態から観測状態へ、観測状態から修正または悪用へ移る流れである。
この流れを記述するために、まず五つの基本量を置く。潜在脆弱性集合を \(V_t\)、観測能力を \(O_t\)、攻撃者の悪用能力を \(A_t\)、防御者の修正能力を \(R_t\)、残存リスクを \(H_t\) とする。ここで \(V_t\) は集合であり、単純な数値ではない。なぜなら、脆弱性は一つひとつ深刻度、到達可能性、悪用容易性、影響範囲、修正難度が異なるからである。一方、\(O_t\)、\(A_t\)、\(R_t\)、\(H_t\) は、モデルを単純化するために、時刻 \(t\) における集約量として扱う。
| 記号 | 名称 | 意味 | 現実で対応するもの | 注意点 |
|---|---|---|---|---|
| \(V_t\) | 潜在脆弱性集合 | 時刻 \(t\) に存在するが、まだ十分に処理されていない潜在的不整合の集合。 | 未発見バグ、権限境界の不整合、古い依存関係、設定ミス、サプライチェーン上の弱点。 | 単なる件数ではなく、各要素ごとに深刻度や到達可能性が異なる集合として扱う。 |
| \(O_t\) | 観測能力 | 潜在的不整合を発見し、脆弱性候補として可視化する能力。 | AI 支援レビュー、fuzzing、静的解析、ログ監視、依存関係監査、人間のコードレビュー。 | 観測能力が高いこと自体は安全でも危険でもない。観測結果の行き先が重要である。 |
| \(A_t\) | 悪用能力 | 観測された弱点を攻撃、侵害、権限昇格、情報窃取、サービス妨害へ接続する能力。 | exploit 作成能力、攻撃チェーン構成、標的調査、検知回避、攻撃運用能力。 | 脆弱性候補の発見能力とは異なる。発見できても、必ず悪用できるとは限らない。 |
| \(R_t\) | 修正能力 | 観測された弱点を分類し、再現し、修正し、配布し、適用し、再観測する能力。 | トリアージ、パッチ作成、テスト、リリース、CVD、パッチ適用、運用更新、説明責任。 | 修正能力はコードを書く能力だけではなく、組織的・制度的な処理能力を含む。 |
| \(H_t\) | 残存リスク | 時刻 \(t\) に社会の中に残っている、未修正または未処理の危険量。 | 未修正 CVE、未適用パッチ、未検証報告、放置された設定不備、悪用可能な既知弱点。 | 脆弱性件数そのものではなく、深刻度、露出面、悪用容易性、資産重要度を含む重み付き量として考える。 |
この表で最も重要なのは、\(O_t\)、\(A_t\)、\(R_t\) を混同しないことである。観測能力 \(O_t\) は、弱点を見つける力である。悪用能力 \(A_t\) は、見つけた弱点を攻撃へ変える力である。修正能力 \(R_t\) は、見つけた弱点を安全性の更新へ変える力である。Claude Mythos 騒動で問題になっているのは、AI が \(O_t\) を上げるだけでなく、利用文脈によっては攻撃者側の \(A_t\) も上げ、防御者側の \(R_t\) を試すという点である。
次に、潜在脆弱性集合 \(V_t\) の各要素を少しだけ細かく見る。ある脆弱性候補を \(v \in V_t\) とする。この \(v\) には、少なくとも深刻度、到達可能性、悪用容易性、修正難度、資産重要度のような属性がある。たとえば、同じ脆弱性でも、インターネットへ露出した認証前 RCE と、内部ネットワークの限定機能にしか影響しない不具合では、社会的リスクがまったく異なる。したがって、\(V_t\) を単純な個数だけで扱うと、重要な差を失う。
v = (s_v, e_v, x_v, c_v, m_v)
\]
この式は、脆弱性候補 \(v\) を、五つの属性を持つ要素として表している。\(s_v\) は深刻度であり、悪用された場合にどれほど大きな影響が出るかを表す。\(e_v\) は露出度または到達可能性であり、外部からその脆弱性へどれだけ到達しやすいかを表す。\(x_v\) は悪用容易性であり、攻撃者がその脆弱性を実用的な攻撃へ変換しやすいかを表す。\(c_v\) は修正コストであり、パッチ作成、テスト、リリース、適用にどれほど負担がかかるかを表す。\(m_v\) は資産重要度であり、その脆弱性が存在する対象が社会や組織にとってどれほど重要かを表す。
| 属性 | 意味 | 大きい場合に何が起きるか | 具体例 |
|---|---|---|---|
| \(s_v\) | 深刻度。 | 悪用された場合の被害が大きい。 | root 権限取得、認証前 RCE、重要データ漏洩、サービス全停止。 |
| \(e_v\) | 露出度・到達可能性。 | 攻撃者がその脆弱性へ到達しやすい。 | インターネット公開サービス、認証不要 API、広く配布されたクライアント。 |
| \(x_v\) | 悪用容易性。 | 攻撃コード化しやすく、再現性が高い。 | PoC が存在する、入力条件が単純、環境依存が小さい。 |
| \(c_v\) | 修正コスト。 | 直すまでに時間がかかり、危険窓が長くなりやすい。 | 互換性破壊、広範な回帰テスト、再起動困難、複数ベンダー調整。 |
| \(m_v\) | 資産重要度。 | 同じ脆弱性でも社会的・事業的影響が大きくなる。 | 金融、医療、行政、認証基盤、クラウド制御プレーン、広く使われる OSS。 |
このように属性を分けると、残存リスク \(H_t\) は、単なる未修正件数ではなく、各脆弱性候補の重み付き合計として考えられる。最小形式では、未処理の脆弱性集合に含まれる各 \(v\) について、深刻度、露出度、悪用容易性、資産重要度を掛け合わせ、修正済みかどうかで重みを下げる。
H_t = \sum_{v \in V_t} s_v e_v x_v m_v \cdot (1 – f_v(t))
\]
この式で、\(H_t\) は時刻 \(t\) に残っているリスク量である。総和記号 \(\sum_{v \in V_t}\) は、潜在脆弱性集合 \(V_t\) に含まれる各脆弱性候補 \(v\) について足し合わせることを意味する。\(s_v e_v x_v m_v\) は、その脆弱性が持つ危険の重みである。深刻で、外部から到達しやすく、悪用しやすく、重要資産に存在する脆弱性ほど、この値は大きくなる。\(f_v(t)\) は、時刻 \(t\) における修正・緩和の進捗を表す値であり、\(0\) なら未修正、\(1\) なら十分に修正または緩和済みである。したがって、\((1 – f_v(t))\) は、まだ残っている危険の割合を表す。
この式の意味は直感的である。危険な脆弱性が存在しても、修正が進めば残存リスクは下がる。逆に、深刻度が高く、露出しており、悪用しやすく、重要資産に存在し、なおかつ修正されていなければ、残存リスクは大きくなる。ここで重要なのは、脆弱性の「数」だけではなく、どの脆弱性がどこに残っているかが安全性を決めるという点である。
次に、観測能力 \(O_t\) を考える。観測能力は、潜在脆弱性集合 \(V_t\) の中から、どれだけ多く、どれだけ重要な候補を見つけられるかを表す。AI の導入は、一般に \(O_t\) を増加させる。なぜなら、AI はコード読解、仕様差分の確認、過去脆弱性との照合、異常経路の仮説生成、テスト観点の抽出を支援できるからである。ただし、観測能力の上昇は、発見される候補数を増やす一方で、誤検知も増やし得る。したがって、\(O_t\) は単純な検出件数ではなく、有効な観測を生み出す能力として扱う必要がある。
B_t = O_t(V_t)
\]
この式は、時刻 \(t\) に観測される脆弱性候補集合を \(B_t\) と置いている。\(O_t(V_t)\) は、観測能力 \(O_t\) が潜在脆弱性集合 \(V_t\) に作用し、その一部を観測済み候補として取り出すことを意味する。ここで \(B_t\) は、真の脆弱性だけを含むとは限らない。誤検知、再現不能な候補、影響の小さい不備も含み得る。したがって、防御側では \(B_t\) をそのまま修正するのではなく、トリアージによって重要なものを選別する必要がある。
攻撃者側では、観測された候補 \(B_t\) の一部が悪用へ向かう。攻撃者の悪用能力 \(A_t\) が高いほど、候補を再現し、PoC 化し、攻撃チェーンへ接続する速度が上がる。一方、防御者側では、修正能力 \(R_t\) が高いほど、候補を分類し、再現し、パッチ化し、配布し、適用する速度が上がる。したがって、社会の安全性は、単に \(O_t\) が高いかどうかではなく、\(A_t\) と \(R_t\) のどちらへ観測結果がより速く流れるかで決まる。
| 流れ | 数理的な見方 | 現実の意味 | 安全性への影響 |
|---|---|---|---|
| 潜在状態 | \(V_t\) | まだ十分に処理されていない潜在的不整合が存在する。 | 見えていないだけで、危険がないとは限らない。 |
| 観測 | \(B_t = O_t(V_t)\) | AI、人間、fuzzing、監視によって候補が可視化される。 | 観測結果が増えるが、誤検知や未処理候補も増える。 |
| 悪用 | \(A_t(B_t)\) | 攻撃者が候補を攻撃手順へ変換する。 | 悪用が修正より速ければ被害が増える。 |
| 修正 | \(R_t(B_t)\) | 防御者が候補を修正、緩和、隔離、適用へ変換する。 | 修正が悪用より速ければ残存リスクは下がる。 |
| 残存リスク | \(H_t\) | 未修正または未処理として社会に残っている危険量。 | 安全性は \(H_t\) をどれだけ低く保てるかで決まる。 |
ここで、AI の効果を最小限に書くなら、AI は観測能力 \(O_t\) を増やす。ただし、それだけではない。攻撃者が AI を使えば、悪用能力 \(A_t\) も増える。防御者が AI を使えば、修正能力 \(R_t\) の一部も増える。したがって、AI の社会的影響は、単純に「AI によって危険が増える」でも「AI によって安全になる」でもない。AI がどの主体に、どの条件で、どの工程へ接続されるかによって、\(O_t\)、\(A_t\)、\(R_t\) の増え方が変わる。
O_t = O_t^{human} + O_t^{AI}
\]
この式は、観測能力 \(O_t\) を、人間による観測能力 \(O_t^{human}\) と AI による観測能力 \(O_t^{AI}\) の和として表している。人間による観測能力には、コードレビュー、設計レビュー、運用経験、インシデント対応、専門家の直感が含まれる。AI による観測能力には、広範なコード読解、類似パターン抽出、仕様差分確認、テスト観点生成、ログや依存関係の整理が含まれる。AI の導入によって \(O_t^{AI}\) が増えると、全体の観測能力 \(O_t\) は増える。
しかし、この式だけを見ると誤解が生じる。観測能力が増えることは、直ちに安全性向上を意味しない。観測された候補が攻撃者へ流れれば、悪用可能性が上がる。防御者へ流れても、修正能力が不足していれば未処理キューが増える。したがって、\(O_t\) の増加は、安全性の必要条件ではあっても十分条件ではない。安全性を決めるのは、観測結果をどれだけ速く、正しく、修正履歴へ変換できるかである。
この点を最小モデルとして書くと、残存リスク \(H_t\) の変化は、リスクの流入量と処理量の差で表せる。
H_{t+1} = H_t + I_t + E_t – M_t
\]
この式で、\(H_{t+1}\) は次の時刻の残存リスクである。\(H_t\) は現在の残存リスクである。\(I_t\) は新たに発生または導入されるリスクであり、新機能、依存関係追加、設定変更、運用変更、サプライチェーン変化によって増える。\(E_t\) は観測されたリスクが悪用可能性や攻撃活動によって社会的危険として顕在化する増分である。\(M_t\) は修正、緩和、隔離、パッチ適用、設定変更、監視強化によって除去または低減されたリスクである。
| 項 | 意味 | 増える要因 | 減らす方法 |
|---|---|---|---|
| \(H_t\) | 現在残っている未処理リスク。 | 過去の未修正脆弱性、未適用パッチ、放置された設定不備。 | 継続的な修正、緩和、適用、再観測によって減らす。 |
| \(I_t\) | 新たに導入されるリスク。 | 新機能、依存関係追加、設定変更、運用変更、急いだリリース。 | SSDF、設計レビュー、SBOM、テスト、サプライチェーン管理で抑える。 |
| \(E_t\) | 悪用や露出によって顕在化する危険増分。 | 攻撃者の悪用能力上昇、PoC 公開、KEV 掲載、外部露出、パッチ遅延。 | アクセス制御、監視、緩和策、検知、迅速なパッチ適用で抑える。 |
| \(M_t\) | 修正や緩和によって除去されるリスク。 | トリアージ、パッチ作成、リリース、適用、設定変更、隔離、回避策。 | 修正能力 \(R_t\) を高めることで増やす。 |
この式の読み方は単純である。残存リスク \(H_t\) は、何もしなければ自然に消えるとは限らない。新しい変更によって \(I_t\) が増え、攻撃活動によって \(E_t\) が増え、修正によって \(M_t\) が増える。安全側へ進むには、少なくとも長期的に \(M_t\) が \(I_t + E_t\) を上回る必要がある。逆に、AI によって観測量が増えたにもかかわらず、修正能力が不足し、\(M_t\) が増えなければ、残存リスクは下がらない。
このモデルで Claude Mythos 騒動を読むと、問題の焦点が明確になる。AI によって \(O_t\) が上がること自体は、良いとも悪いとも言えない。攻撃者側で \(A_t\) が上がり、悪用増分 \(E_t\) が増えれば危険である。防御者側で \(R_t\) が上がり、修正量 \(M_t\) が増えれば安全性は高まる。社会制度が弱く、観測結果が修正へ流れず、未処理キューとして滞留すれば、\(H_t\) は増える。つまり、AI 時代の安全性は、観測能力単体ではなく、観測結果をどちらの流れへ接続するかで決まる。
この章の結論は、数理モデルの出発点として、脆弱性探索社会を「潜在脆弱性、観測能力、悪用能力、修正能力、残存リスク」の相互作用として捉えることである。安全性は、脆弱性が少ないかどうかだけでは決まらない。観測速度、悪用速度、修正速度の関係で決まる。AI はこの関係に介入し、\(O_t\)、\(A_t\)、\(R_t\) のすべてを変え得る。したがって、以後の章では、観測された不整合が、攻撃履歴へ流れるのか、修正履歴へ流れるのかを、時間発展モデルとして記述していく。
14. 観測、悪用、修正の三速度モデル
前章では、脆弱性探索社会を、潜在脆弱性集合 \(V_t\)、観測能力 \(O_t\)、悪用能力 \(A_t\)、修正能力 \(R_t\)、残存リスク \(H_t\) の相互作用として整理した。ここでは、その関係を時間の競争として捉え直す。なぜなら、脆弱性の危険性は、脆弱性が存在するかどうかだけでは決まらないからである。同じ脆弱性でも、防御者が先に発見して修正できれば被害は出にくい。攻撃者が先に悪用可能化し、修正適用が遅れれば被害は大きくなる。つまり、重要なのは、発見、悪用、修正がどの順序で、どの速度で進むかである。
ある脆弱性候補を \(v\) とする。この \(v\) について、三つの時刻を定義する。第一に、発見時刻 \(T_d(v)\) である。これは、防御者、攻撃者、研究者、AI システム、監視機構のいずれかが、その脆弱性候補を観測可能な形で発見した時刻を表す。第二に、悪用可能化時刻 \(T_e(v)\) である。これは、その脆弱性が実用的な攻撃手順、PoC、exploit chain、または攻撃運用へ接続可能になった時刻を表す。第三に、修正適用時刻 \(T_p(v)\) である。これは、単にパッチが作られた時刻ではなく、対象環境に修正または十分な緩和策が実際に適用された時刻を表す。
| 記号 | 名称 | 意味 | 注意点 |
|---|---|---|---|
| \(T_d(v)\) | 発見時刻 | 脆弱性候補 \(v\) が観測され、何らかの形で認識可能になった時刻。 | 発見者が防御者か攻撃者かで意味が変わる。発見されたが報告されない場合もある。 |
| \(T_e(v)\) | 悪用可能化時刻 | 脆弱性 \(v\) が攻撃者にとって実用的に使える状態になった時刻。 | 単なる候補発見とは異なる。再現性、到達可能性、攻撃手順、環境条件が必要になる。 |
| \(T_p(v)\) | 修正適用時刻 | 脆弱性 \(v\) に対する修正、緩和、隔離、設定変更が対象環境へ実際に適用された時刻。 | パッチ公開時刻ではない。利用者環境へ適用されるまで危険窓は残る。 |
この表で特に重要なのは、\(T_p(v)\) を「パッチ作成時刻」や「advisory 公開時刻」と混同しないことである。現実には、ベンダーがパッチを作っても、ディストリビューションへ取り込まれ、利用者へ配布され、運用環境で適用され、必要なら再起動されるまでには時間がかかる。したがって、社会的リスクを考えるなら、修正が存在するだけでは不十分である。修正が実際に対象環境へ届き、危険な状態が解消されて初めて \(T_p(v)\) に到達したと考える。
この三つの時刻を使うと、脆弱性 \(v\) の危険窓を次のように表せる。
W(v) = \max(0, T_p(v) – T_e(v))
\]
この式で、\(W(v)\) は脆弱性 \(v\) の危険窓である。\(T_e(v)\) は攻撃者がその脆弱性を実用的に悪用できるようになった時刻であり、\(T_p(v)\) は防御側の修正または緩和が対象環境へ適用された時刻である。差 \(T_p(v) – T_e(v)\) は、悪用可能な状態が修正適用よりどれだけ先行したかを表す。もし \(T_p(v)\) が \(T_e(v)\) より後なら、その差分だけ攻撃可能な期間が生じる。逆に、防御側の修正適用が悪用可能化より早ければ、\(T_p(v) – T_e(v)\) は負になる。この場合、危険窓を負の値として扱うのではなく、\(\max(0,\cdot)\) によって \(0\) とする。つまり、防御が先行できた場合、その脆弱性による実用的な危険期間は 0 に近づく。
| 時刻関係 | 数式上の状態 | 現実の意味 | 安全性への評価 |
|---|---|---|---|
| 防御が先行する | \(T_p(v) \leq T_e(v)\) | 攻撃者が実用的に悪用する前に、修正または緩和が適用されている。 | \(W(v) = 0\)。理想的な状態であり、観測能力が修正能力へ接続された結果である。 |
| 攻撃が短期間だけ先行する | \(0 < T_p(v) - T_e(v) \ll 1\) | 悪用可能な期間は存在するが、修正適用が早く、危険窓は短い。 | 被害は起き得るが、迅速な対応によって拡大を抑えられる。 |
| 攻撃が長期間先行する | \(T_p(v) – T_e(v) \gg 1\) | 悪用可能な状態が長く続き、攻撃者が広く利用できる。 | 被害拡大、KEV 化、ワンデイ攻撃、エヌデイ攻撃へ接続しやすい。 |
| 修正が存在しても適用されない | \(T_p(v)\) が実質的に遠い | パッチは公開されているが、利用環境では未適用のまま残る。 | 既知脆弱性として攻撃され続ける。修正能力ではなく適用能力がボトルネックになる。 |
この危険窓モデルの要点は、発見時刻 \(T_d(v)\) が式の中に直接入っていない点である。これは、発見が重要でないという意味ではない。むしろ逆である。発見は、悪用と修正のどちらへ流れるかを決める入口である。しかし、社会的被害を直接左右するのは、最終的には悪用可能化 \(T_e(v)\) と修正適用 \(T_p(v)\) の差である。早く発見しても、修正へ流れず、攻撃者側で先に exploit 化されれば危険窓は広がる。遅く発見しても、攻撃者がまだ悪用可能化しておらず、修正が速ければ危険窓は小さくできる。
したがって、防御側にとっての目標は、単に \(T_d(v)\) を早めることではない。防御側の本当の目標は、発見された脆弱性を迅速に修正工程へ流し、\(T_p(v)\) を \(T_e(v)\) より前、または十分近くへ移動させることである。これが、観測能力と修正能力を分けて考える理由である。観測能力 \(O_t\) が上がると \(T_d(v)\) は早まりやすい。しかし、修正能力 \(R_t\) が上がらなければ \(T_p(v)\) は十分に早まらない。結果として、発見だけが増え、危険窓は縮まらない。
ここで、三つの速度を定義する。観測速度を \(\lambda_d(t)\)、悪用速度を \(\lambda_e(t)\)、修正速度を \(\lambda_p(t)\) とする。観測速度は、潜在脆弱性が発見される速さである。悪用速度は、観測された脆弱性候補が実用的な攻撃へ変換される速さである。修正速度は、観測された脆弱性候補が修正、緩和、適用へ変換される速さである。
| 記号 | 名称 | 意味 | 主に影響する能力 |
|---|---|---|---|
| \(\lambda_d(t)\) | 観測速度 | 潜在脆弱性が候補として発見される速さ。 | 観測能力 \(O_t\)。AI 支援レビュー、fuzzing、静的解析、人間の調査。 |
| \(\lambda_e(t)\) | 悪用速度 | 発見された候補が PoC、exploit、攻撃チェーンへ変換される速さ。 | 悪用能力 \(A_t\)。攻撃者の技術力、AI 支援、標的調査、既存ツール。 |
| \(\lambda_p(t)\) | 修正速度 | 発見された候補が再現、修正、リリース、適用、緩和へ変換される速さ。 | 修正能力 \(R_t\)。トリアージ、保守者、CI、リリース、適用運用、CVD。 |
この三速度モデルで見ると、AI の効果は単純ではない。AI が防御側で使われれば、\(\lambda_d(t)\) が上がり、同時に修正案生成やテスト支援によって \(\lambda_p(t)\) も上がり得る。この場合、観測された脆弱性は修正履歴へ流れやすくなり、危険窓 \(W(v)\) は短くなる。一方、AI が攻撃側で使われれば、\(\lambda_d(t)\) も上がり、さらに exploit 化や攻撃チェーン構成の支援によって \(\lambda_e(t)\) も上がり得る。この場合、修正が追いつかなければ \(W(v)\) は長くなる。
この関係を最小形式で書くなら、防御側にとって安全側へ進む条件は、長期的に修正速度が悪用速度を上回ることである。
\lambda_p(t) > \lambda_e(t)
\]
この不等式は、脆弱性候補が観測された後、防御者が修正適用へ進む速度 \(\lambda_p(t)\) が、攻撃者が悪用可能化へ進む速度 \(\lambda_e(t)\) を上回ることを意味する。この条件が満たされるなら、多くの脆弱性について \(T_p(v)\) は \(T_e(v)\) より早く、または近くなり、危険窓 \(W(v)\) は短くなる。逆に、\(\lambda_e(t) > \lambda_p(t)\) なら、攻撃者が先に実用化し、防御者の修正適用が遅れやすくなる。このとき危険窓は広がり、残存リスク \(H_t\) は増えやすくなる。
ただし、この不等式は平均的な傾向を表すだけである。現実には、脆弱性ごとに深刻度、露出度、悪用容易性、修正コストが異なる。したがって、すべての脆弱性について常に \(\lambda_p(t) > \lambda_e(t)\) を満たす必要があるわけではない。重要なのは、深刻度が高く、露出しており、悪用しやすく、重要資産に存在する脆弱性について、優先的に修正速度を上げることである。つまり、防御側の目標は、全件均等な高速処理ではなく、重み付きリスクに対する選択的な高速処理である。
そこで、脆弱性 \(v\) ごとの重み付き危険窓を定義できる。
D(v) = w(v) \cdot W(v)
\]
ここで、\(D(v)\) は脆弱性 \(v\) が社会へ与える危険量である。\(W(v)\) は先ほど定義した危険窓であり、悪用可能化から修正適用までの期間を表す。\(w(v)\) は脆弱性の重みであり、深刻度、露出度、悪用容易性、資産重要度などを含む。たとえば、前章の記号を使えば、単純化して \(w(v) = s_v e_v x_v m_v\) と置ける。つまり、同じ危険窓でも、重要資産にある深刻な脆弱性の方が、軽微で到達困難な脆弱性よりも大きな危険量を持つ。
| 式 | 意味 | 読み方 | 実務上の対応 |
|---|---|---|---|
| \(W(v) = \max(0, T_p(v) – T_e(v))\) | 脆弱性 \(v\) の危険窓。 | 悪用可能化から修正適用までの時間差。 | 悪用より前に修正するか、少なくとも差を短くする。 |
| \(w(v) = s_v e_v x_v m_v\) | 脆弱性 \(v\) の危険重み。 | 深刻で、露出し、悪用しやすく、重要資産にあるほど大きい。 | 優先順位付けで使う。高重みの脆弱性を先に処理する。 |
| \(D(v) = w(v) \cdot W(v)\) | 脆弱性 \(v\) の重み付き危険量。 | 危険な脆弱性が長く未修正で残るほど大きい。 | 単に件数を減らすのではなく、重み付き危険量を減らす。 |
この重み付き危険窓の考え方を使うと、なぜ CVSS だけで優先順位を決めるのが不十分なのかも分かる。深刻度 \(s_v\) が高くても、露出度 \(e_v\) が低く、悪用容易性 \(x_v\) も低く、重要資産 \(m_v\) に存在しないなら、直ちに最優先とは限らない。逆に、深刻度が中程度でも、外部公開され、悪用が容易で、重要資産に存在し、修正適用が遅れているなら、重み付き危険量 \(D(v)\) は大きくなる。防御者は、脆弱性の抽象的な深刻度だけでなく、危険窓と資産文脈を組み合わせて優先順位を決める必要がある。
社会全体の危険量は、各脆弱性の重み付き危険窓を足し合わせることで表せる。
D_t = \sum_{v \in V_t} w(v) W(v)
\]
この式で、\(D_t\) は時刻 \(t\) における社会全体の危険量である。総和記号 \(\sum_{v \in V_t}\) は、時刻 \(t\) に存在する脆弱性集合 \(V_t\) の各要素について足し合わせることを意味する。\(w(v)\) はその脆弱性の危険重み、\(W(v)\) はその脆弱性の危険窓である。したがって、社会全体の危険を下げるには、二つの方法がある。第一に、危険重み \(w(v)\) の大きい脆弱性を優先的に処理すること。第二に、危険窓 \(W(v)\) を短くすること。つまり、重要で悪用されやすい脆弱性を早く修正することが、最も効率よく \(D_t\) を下げる。
このモデルは、AI 導入の評価にも使える。AI によって観測速度 \(\lambda_d(t)\) が上がったとしても、修正速度 \(\lambda_p(t)\) が上がらず、攻撃者側の悪用速度 \(\lambda_e(t)\) だけが上がれば、危険窓 \(W(v)\) はむしろ広がる可能性がある。逆に、防御側が AI を使って観測、トリアージ、修正案作成、テスト、リリース判断を高速化し、\(\lambda_p(t)\) を上げられれば、危険窓は短くなる。したがって、AI の安全性評価は、モデルが何を発見できるかだけではなく、その発見がどの速度で修正へ流れるかを含めて評価すべきである。
| AI の使われ方 | \(\lambda_d(t)\) への影響 | \(\lambda_e(t)\) への影響 | \(\lambda_p(t)\) への影響 | 危険窓への影響 |
|---|---|---|---|---|
| 防御側の監査に使われる | 上がる。 | 直接は上がらない。 | トリアージや修正案生成に接続すれば上がる。 | 修正へ接続されれば \(W(v)\) は短くなる。 |
| 攻撃側の探索に使われる | 上がる。 | PoC 化や攻撃チェーン構成に接続すれば上がる。 | 上がらない。 | 修正が追いつかなければ \(W(v)\) は長くなる。 |
| 防御側で発見だけに使われる | 上がる。 | 直接は上がらない。 | 上がらない。 | 未処理候補が増え、\(W(v)\) は十分に短くならない。 |
| CVD と修正工程へ接続される | 上がる。 | 情報管理により抑制される。 | 報告、再現、修正、適用が高速化される。 | \(W(v)\) が短くなり、重み付き危険量 \(D_t\) が下がる。 |
この表が示すように、AI の効果は、どの速度を上げるかによって意味が変わる。観測速度だけを上げても、安全性は自動的には上がらない。悪用速度が上がれば危険は増す。修正速度が上がれば危険は下がる。したがって、社会的に重要なのは、AI を観測能力だけではなく、修正能力へ結合することである。防御側が AI を導入するときも、脆弱性候補を出すだけの運用では不十分であり、候補を優先順位付けし、修正し、適用し、再観測する工程まで設計しなければならない。
この章の結論は、脆弱性管理を三速度の競争として見ることである。観測速度 \(\lambda_d(t)\)、悪用速度 \(\lambda_e(t)\)、修正速度 \(\lambda_p(t)\) の関係によって、危険窓 \(W(v)\) が決まる。AI は観測速度を上げるが、利用文脈によって悪用速度も修正速度も上げ得る。したがって、AI 時代の安全性は、単に早く見つけることではなく、悪用可能化より早く修正適用へ到達すること、そして重み付き危険窓 \(D(v)\) を小さくすることによって決まる。
15. 一回限りのカードから発見プロセスの競争へ
前章では、脆弱性の危険性を、発見時刻 \(T_d(v)\)、悪用可能化時刻 \(T_e(v)\)、修正適用時刻 \(T_p(v)\)、危険窓 \(W(v)\) によって記述した。このモデルをゼロデイの問題へ適用すると、従来の「ゼロデイは一回限りのカードである」という見方を、より正確に言い換えられる。個別のゼロデイは、たしかに一回限りのカードに近い。なぜなら、その価値は、まだ知られておらず、まだ修正されておらず、まだ検知されにくく、標的環境で実用的に使える期間に依存するからである。いったん公表され、CVE が付与され、パッチが配布され、検知ルールが整備され、主要環境へ適用されれば、その脆弱性は未知性に依存する高価値カードではなくなる。
しかし、AI によって弱点探索の限界費用が下がると、問題の中心は個別カードの保有から、カードを継続的に発見できるプロセスへ移る。これは重要な転換である。従来は、希少なゼロデイを一つ見つけ、秘匿し、価値が高い間に慎重に使うことが大きな意味を持った。だが、AI 支援によって観測速度 \(\lambda_d(t)\) が上がると、個別のゼロデイはより早く見つかり、より早く共有され、より早く修正対象になる可能性が高まる。その結果、個別ゼロデイの寿命は短くなり、代わりに、次の候補を継続的に見つけ、検証し、悪用または修正へ流せる探索プロセスの価値が上がる。
| 観点 | 一回限りのカードとしてのゼロデイ | 発見プロセスとしてのゼロデイ | AI 時代の変化 |
|---|---|---|---|
| 価値の源泉 | 特定の未知脆弱性を保有していること。 | 未知脆弱性候補を継続的に発見できること。 | 個別 exploit の秘匿価値に加えて、探索パイプラインの価値が上がる。 |
| 寿命 | 公表、検知、パッチ、適用によって短くなる。 | 一つの候補が潰れても、次の候補を探索できる限り継続する。 | 個別カードの寿命は短くなり、発見能力の持続性が重要になる。 |
| 攻撃者の戦術 | 高価値のゼロデイを温存し、発覚しないよう慎重に使う。 | 探索、検証、短期悪用、検知後の乗り換えを繰り返す。 | 一点突破型から、継続的な探索運用型へ寄る。 |
| 防御者の戦術 | 報告を受け、個別脆弱性を修正する。 | 継続的に観測し、優先順位を付け、修正し、再観測する。 | 一回の監査ではなく、継続的な観測と修正の運用が必要になる。 |
| 制度的課題 | 個別ゼロデイを公開するか、秘匿するか、誰へ報告するか。 | 継続的に出てくる候補を、どの制度で受け取り、分類し、修正するか。 | CVD、CVE、KEV、SBOM、パッチ適用運用の処理能力が問われる。 |
この表から分かるように、AI 時代のゼロデイ問題は、「危険な一枚を誰が持っているか」という問いだけでは捉えられない。もちろん、個別のゼロデイは依然として危険である。特に、外部から到達可能で、悪用が容易で、重要資産に存在し、修正が難しい脆弱性は大きな危険を持つ。しかし、構造的により重要なのは、一枚のカードそのものではなく、カードを見つけ続ける能力、すなわち観測速度 \(\lambda_d(t)\) と、その後の悪用速度 \(\lambda_e(t)\) または修正速度 \(\lambda_p(t)\) の関係である。
攻撃者側では、AI 支援によって探索が継続プロセス化する。攻撃者は、希少なゼロデイを長期間温存するだけではなく、多数の候補を探索し、再現可能なものを選別し、短い危険窓の中で悪用し、検知や修正が進めば次の候補へ移る戦術を取りやすくなる。このとき攻撃者にとって重要なのは、個別ゼロデイの寿命を最大化することだけではない。観測速度 \(\lambda_d(t)\) と悪用速度 \(\lambda_e(t)\) を高め、修正適用時刻 \(T_p(v)\) より前に攻撃可能化へ到達することである。
防御者側でも、発想を変える必要がある。一回の監査、一回の脆弱性診断、一回のパッチ適用で安全が確定するわけではない。AI によって潜在的不整合が継続的に観測されるなら、防御者も継続スキャン、継続レビュー、継続テスト、継続修正、継続適用、継続再観測へ移る必要がある。つまり、防御側の目標は、すべてのゼロデイを事前に消すことではなく、観測された候補を攻撃者より速く修正履歴へ変換し、重み付き危険窓 \(D(v) = w(v)W(v)\) を小さく保つことである。
P_{defense}(t) = \lambda_d^{def}(t) \cdot \lambda_p(t)
\]
この式は、防御側の継続処理力を単純化して表している。\(P_{defense}(t)\) は時刻 \(t\) における防御側の発見から修正までの処理力である。ここで \(\lambda_d^{def}(t)\) は防御者側の観測速度、\(\lambda_p(t)\) は修正速度である。防御側が AI を使って多くの候補を発見しても、\(\lambda_p(t)\) が低ければ、発見は修正へ接続されず、未処理キューが増える。逆に、観測速度と修正速度がともに高ければ、発見された不整合は短時間で修正履歴へ変換される。
P_{attack}(t) = \lambda_d^{atk}(t) \cdot \lambda_e(t)
\]
この式は、攻撃側の継続処理力を単純化して表している。\(P_{attack}(t)\) は時刻 \(t\) における攻撃側の発見から悪用までの処理力である。ここで \(\lambda_d^{atk}(t)\) は攻撃者側の観測速度、\(\lambda_e(t)\) は悪用速度である。攻撃者が AI によって候補を多く見つけ、さらに PoC 化、exploit chain 化、標的環境への適用を速くできるなら、\(P_{attack}(t)\) は上がる。これは、個別ゼロデイの価値よりも、探索と悪用を継続的に回す能力が重要になることを意味する。
| 状態 | 数理的な見方 | 現実の意味 | 社会的帰結 |
|---|---|---|---|
| 防御優位 | \(P_{defense}(t) > P_{attack}(t)\) | 防御側が、攻撃側より速く候補を修正履歴へ変換できる。 | 危険窓は短くなり、ゼロデイの社会的被害は抑えられる。 |
| 攻撃優位 | \(P_{attack}(t) > P_{defense}(t)\) | 攻撃側が、修正より速く候補を悪用へ変換できる。 | 危険窓は長くなり、被害、未処理リスク、既知脆弱性攻撃が増える。 |
| 観測過多 | \(\lambda_d^{def}(t)\) は高いが \(\lambda_p(t)\) が低い | 防御側は多くを見つけるが、処理しきれない。 | 未処理キューが増え、現場疲弊と優先順位混乱が起きる。 |
| 修正遅延 | \(\lambda_p(t)\) が低く、\(T_p(v)\) が遠い | パッチ作成、配布、適用、再起動、回帰テストが詰まる。 | ゼロデイは公表後もワンデイ、エヌデイ攻撃へ変換される。 |
この整理により、ゼロデイをめぐる社会的争点は明確になる。恐れるべきなのは、単に未知の脆弱性が存在することではない。複雑なソフトウェア社会では、未知の不整合が残ること自体は避けにくい。本当に恐れるべきなのは、攻撃側の発見・悪用プロセスが継続的に高速化し、防御側の発見・修正プロセスがそれに負け続ける構造である。したがって、この章の中心命題は、ゼロデイの本質的価値が「一回限りのカード」から「継続的な発見プロセスの速度差」へ移る、という点にある。
この転換は、ゼロデイを軽視することを意味しない。むしろ逆である。個別ゼロデイは依然として危険だが、その危険を制御するには、個別カードを恐れるだけでは足りない。重要なのは、観測、悪用、修正のプロセス全体を見て、攻撃側の \(P_{attack}(t)\) が防御側の \(P_{defense}(t)\) を上回らないようにすることである。そのためには、防御側の AI 利用、CVD、トリアージ、パッチ作成、テスト、リリース、適用運用、SBOM、依存関係管理、ログ監視を、継続的な修正パイプラインとして統合する必要がある。
この章から次章へ進むために重要なのは、ゼロデイ問題が単発の攻防ではなく、継続的な更新過程として見えてきたことである。個別脆弱性は発見され、悪用され、修正され、履歴へ固定される。さらに、その履歴は次の探索、次の防御、次の制度設計に影響する。したがって、次章では、この継続的な発見、悪用、修正の循環を、システム全体のフィードバック構造として整理する。つまり、ゼロデイの議論は、発見プロセスの競争を経て、観測と修正が相互に影響し合うフィードバックモデルへ接続される。
16. メディア誇張をモデル上で扱う
前章では、ゼロデイの価値が一回限りのカードから、継続的な発見プロセスの速度差へ移ることを整理した。ここでは、その技術的変化が社会にどう認知されるかをモデル化する。Claude Mythos 騒動のような事例では、実際の技術リスクと、社会が感じ取る騒動強度は一致しない。ある脆弱性や AI 能力が実際に危険であっても、報道されなければ広く認知されないことがある。逆に、実技術リスクが限定的であっても、企業発信、政府評価、メディア見出し、SNS 拡散、競合企業の批判、規制政治が重なると、社会的には非常に大きな危機として認知されることがある。したがって、数理モデルには、実技術リスクそのものだけでなく、それが社会的認知へ変換される過程も入れる必要がある。
ここで、時刻 \(t\) における社会的認知または騒動強度を \(C_t\)、実技術リスクを \(H_t\)、増幅係数を \(\beta_t\)、ノイズ項を \(\epsilon_t\) とする。\(H_t\) は前章までと同じく、未修正脆弱性、悪用可能性、露出面、資産重要度、危険窓を含む実質的なリスク量である。一方、\(C_t\) は、人々、組織、政策担当者、メディア、市場、SNS がそのリスクをどれほど大きな問題として認知しているかを表す。両者は関係しているが、同一ではない。
C_t = \beta_t H_t + \epsilon_t
\]
この式は、社会的認知 \(C_t\) が、実技術リスク \(H_t\) に増幅係数 \(\beta_t\) を掛けたものと、ノイズ項 \(\epsilon_t\) の和として表せることを示している。\(H_t\) が大きければ、実際に危険な状態が存在するため、社会的認知も大きくなりやすい。しかし、\(H_t\) だけでは \(C_t\) は決まらない。企業や政府が強い言葉で発信し、メディアが危機的見出しを付け、SNS で断片的情報が拡散され、専門外の解釈が重なると、増幅係数 \(\beta_t\) やノイズ項 \(\epsilon_t\) が大きくなり、実リスク以上に騒動が大きく見える。逆に、実リスク \(H_t\) が大きくても、専門家コミュニティ内部に閉じていたり、報道されなかったり、影響が遅れて現れたりすれば、社会的認知 \(C_t\) は小さいままになることがある。
| 記号 | 名称 | 意味 | 現実で対応するもの |
|---|---|---|---|
| \(C_t\) | 社会的認知・騒動強度 | 社会がその技術リスクをどれほど大きな問題として認識しているか。 | 報道量、SNS 拡散、政策議論、企業声明、市場反応、一般利用者の不安。 |
| \(H_t\) | 実技術リスク | 実際に存在する未修正リスク、悪用可能性、危険窓、被害可能性。 | 未修正 CVE、KEV 掲載、PoC 公開、外部露出、攻撃観測、修正遅延。 |
| \(\beta_t\) | 増幅係数 | 実リスクが社会的認知へ変換されるときの増幅率。 | 企業発信、政府声明、メディア見出し、規制政治、競合企業の批判、安全保障文脈。 |
| \(\epsilon_t\) | ノイズ項 | 実リスクとは独立に騒動強度を上下させる誤差や外部要因。 | 誤解、専門外解釈、SNS の切り取り、商業的宣伝、陰謀論、過去事件との連想。 |
この表で重要なのは、\(C_t\) と \(H_t\) を分けることである。社会的認知 \(C_t\) が大きいからといって、実技術リスク \(H_t\) が必ず大きいとは限らない。また、社会的認知 \(C_t\) が小さいからといって、実技術リスク \(H_t\) が小さいとも限らない。これは、技術リスクが社会へ伝わる過程で、増幅、抑制、誤解、宣伝、政治化、商業化が入るからである。Claude Mythos 騒動を冷静に読むには、まず \(C_t\) と \(H_t\) を切り分ける必要がある。
増幅係数 \(\beta_t\) は、単なるメディアの煽りだけを意味しない。企業が「このモデルは危険なほど高性能である」と説明するとき、その発信は安全性説明であると同時に能力宣伝でもある。政府が「重要なサイバーリスク」として評価するとき、その発信は公共安全のためであると同時に、規制や安全保障の文脈を強める。メディアが「封印された AI」「危険すぎるモデル」「ゼロデイを発見する怪物」という見出しを付けるとき、事実の断片は物語へ変換される。これらはすべて \(\beta_t\) を上げる要因になる。
| 増幅要因 | \(\beta_t\) への影響 | 起きること | 冷静な読み方 |
|---|---|---|---|
| 企業の能力発信 | 上がる。 | 安全性説明が、同時に「自社モデルは非常に高性能である」という宣伝にもなる。 | 能力説明、安全対策、競争戦略を分けて読む。 |
| 政府・規制機関の発信 | 上がる。 | 公共安全や安全保障の文脈が付与され、危機認知が強まる。 | 評価対象、評価条件、評価基準、政策目的を確認する。 |
| メディア見出し | 大きく上がる。 | 複雑な技術論点が、怪物、封印、破局、暴走の物語へ圧縮される。 | 見出しではなく、本文で示された具体的能力と制約を見る。 |
| SNS 拡散 | 不安定に上がる。 | 一部の事実、スクリーンショット、断片的引用が文脈を失って拡散される。 | 一次情報、評価条件、反証、専門家の冷静な解説を確認する。 |
| 競合・業界政治 | 上がることがある。 | 安全性論争が、企業間競争、規制誘導、市場ポジションの争いと混ざる。 | 発言主体の利害を確認し、技術的根拠と戦略的発信を分ける。 |
一方で、ノイズ項 \(\epsilon_t\) は、実技術リスク \(H_t\) と直接対応しない揺らぎを表す。たとえば、過去の AI への不安、サイバー攻撃事件の記憶、国家安全保障への恐怖、雇用不安、企業不信、専門用語の誤解が重なると、同じ技術発表でも社会的反応は大きく変わる。これは、技術リスクの評価において無視できない。なぜなら、社会的認知 \(C_t\) が過剰に高まると、規制、投資、公開方針、研究方向、企業行動が実技術リスク以上に大きく動くからである。
ここで、いくつかの典型的な状態を整理できる。
| 状態 | 数理的な見方 | 現実の意味 | 判断上の注意 |
|---|---|---|---|
| 実リスクも認知も高い | \(H_t\) が大きく、\(C_t\) も大きい。 | 実際に重大な危険があり、社会もそれを大きく認識している。 | 誇張を除いても対応が必要であり、冷静な緊急対応が求められる。 |
| 実リスクは高いが認知が低い | \(H_t\) が大きいが、\(C_t\) は小さい。 | 危険は存在するが、報道されず、利用者や組織が十分に認識していない。 | 最も危険な状態の一つであり、静かな未対応リスクとして残る。 |
| 実リスクは低いが認知が高い | \(H_t\) は小さいが、\(\beta_t\) または \(\epsilon_t\) が大きく、\(C_t\) が大きい。 | 実際の危険よりも騒動が大きくなっている。 | 冷笑ではなく、どの部分が誇張で、どの部分が実リスクかを分ける必要がある。 |
| 実リスクも認知も低い | \(H_t\) も \(C_t\) も小さい。 | 実害も騒動も限定的である。 | 監視は続けるが、過剰対応は避ける。 |
この分類から分かるように、騒動強度 \(C_t\) だけを見て判断するのは危険である。騒動が大きいからといって、必ずしも実リスクが最大であるとは限らない。逆に、騒動が小さいからといって、安全とは限らない。実務上必要なのは、\(C_t\) を見て社会的反応を理解しつつ、別途 \(H_t\) を評価することである。つまり、報道量、企業発信、政府発信、SNS 反応を観測することと、実際の悪用可能性、修正状況、露出面、資産重要度を評価することを分けなければならない。
この章の中心命題は、メディア誇張とは実技術リスクの有無ではなく、実技術リスク \(H_t\) が社会的認知 \(C_t\) へ変換される過程で生じる増幅とノイズである、という点にある。したがって、誇張を見抜くことは、危険を否定することではない。むしろ、危険を正しく扱うために、実リスク、増幅、ノイズを分ける作業である。Claude Mythos 騒動を「ただの煽り」と切り捨てれば、実際に上がっている AI の観測能力を見失う。逆に「封印された怪物が暴れ出す」と受け取れば、能力の段階、アクセス制御、修正責任、CVD、運用制約を見失う。
このモデルの利点は、冷笑と恐怖の両方を避けられる点にある。冷笑は、\(\beta_t\) や \(\epsilon_t\) が大きいことだけを見て、\(H_t\) まで小さいと誤解する。恐怖は、\(C_t\) が大きいことを見て、\(H_t\) も同じだけ大きいと誤解する。どちらも、社会的認知と実技術リスクを混同している。冷静な評価では、「何が観測された事実か」「何が技術的に成立しているか」「何が推測か」「何が能力宣伝か」「何が規制政治か」「何が修正要求か」を分ける必要がある。
C_t – H_t = (\beta_t – 1)H_t + \epsilon_t
\]
この式は、社会的認知 \(C_t\) と実技術リスク \(H_t\) のずれを表している。左辺の \(C_t – H_t\) は、社会が認知している騒動強度と実際の技術リスクとの差である。右辺の \((\beta_t – 1)H_t\) は、実リスクがどれだけ増幅されているかを表す。もし \(\beta_t > 1\) なら、実リスクは社会的認知へ変換されるときに拡大されている。もし \(\beta_t < 1\) なら、実リスクは過小認知されている。さらに \(\epsilon_t\) は、実リスクとは別の誤解、宣伝、政治的文脈、SNS 増幅によるずれを表す。この式により、騒動が実リスクより大きく見える場合も、実リスクが騒動より大きい場合も、同じ枠組みで扱える。
| 判断項目 | 対応する変数 | 確認すべきこと | 誤った判断 |
|---|---|---|---|
| 実際の危険 | \(H_t\) | 悪用可能性、影響範囲、修正状況、露出面、攻撃観測を確認する。 | 騒動の大きさだけで危険度を決める。 |
| 増幅の強さ | \(\beta_t\) | 企業発信、政府発信、メディア表現、競合利害、安全保障文脈を見る。 | 強い言葉をすべて客観的リスク評価として受け取る。 |
| ノイズの内容 | \(\epsilon_t\) | 誤解、切り取り、専門外解釈、SNS 拡散、過去事件との連想を分ける。 | 断片情報をそのまま全体像として扱う。 |
| 必要な対応 | \(H_t\)、\(\beta_t\)、\(\epsilon_t\) の分解結果 | 技術対策、説明、制度設計、誤解訂正を分ける。 | 技術対策が必要な問題を広報だけで済ませる、または誤解だけの問題に過剰な技術対策を投入する。 |
したがって、Claude Mythos 騒動をモデル上で扱うとき、重要なのは、騒動を消すことではない。騒動は、社会が何かを観測した結果でもある。問題は、その観測が実技術リスクをどの程度反映しているのか、どの程度増幅されているのか、どの程度ノイズを含んでいるのかを分けることである。誇張を批判するだけでは、修正責任へ進めない。逆に、騒動に飲み込まれるだけでも、実務上必要なトリアージ、CVD、パッチ適用、AI リスク管理へ進めない。
この章から次章へ進むために重要なのは、社会的認知もまたフィードバックを持つという点である。騒動が大きくなれば、企業は安全対策を強調し、政府は規制を検討し、研究者は評価を進め、利用者は不安を持ち、防御者は優先順位を変える。つまり、\(C_t\) は単なる観測結果ではなく、次の時刻の制度、投資、公開方針、修正能力 \(R_t\) に影響する。次章では、この社会的認知、観測能力、修正能力、悪用能力が相互に影響し合う構造を、フィードバックモデルとして整理する。
17. 構造振動モデルへの接続
前章では、実技術リスク \(H_t\) が社会的認知 \(C_t\) へ変換される過程を、増幅係数 \(\beta_t\) とノイズ項 \(\epsilon_t\) を用いて整理した。ここまでで、脆弱性探索社会は、潜在脆弱性、観測能力、悪用能力、修正能力、残存リスク、社会的認知が相互に影響する動的な系として見えてきた。ここから、この系を構造振動モデルへ接続する。構造振動モデルでは、構造は静的な配置ではなく、複雑化、揺らぎ、観測、削減、履歴固定、再安定化を繰り返す動的過程として扱われる[30]。哲学を構造の揺れとして数理化する議論、抽象哲学を運用可能なモデルへ変換する議論は、今回の問題を扱うための基礎になる[31][32]。
この接続で重要なのは、脆弱性を単なる「バグ」としてではなく、構造内部の潜在的不整合として見ることである。大規模ソフトウェア、OS、クラウド、OSS、サプライチェーン、運用制度は、多数の部品、仕様、権限境界、設定、互換性、性能最適化、歴史的変更の重なりとして成立している。その構造は、表面的には安定して動作していても、内部には未観測のずれを含む。読み取り可能なものと書き込み可能なもの、キャッシュと永続化、権限境界と実行時状態、仕様と実装、上流と下流、修正と適用、発見と公開の間には、微細な不整合が潜在する。構造振動モデルの語彙で言えば、脆弱性とは、構造内部に残る潜在的不整合振動である。
| 構造振動モデルの概念 | 脆弱性管理での対応 | 本稿の数理記号 | 意味 |
|---|---|---|---|
| 構造 | ソフトウェア、設定、依存関係、運用、制度、利用者環境の全体。 | \(V_t\) を含む対象系。 | 単一コードではなく、実行時環境、配布、適用、制度まで含む複合系である。 |
| 潜在的不整合振動 | 未発見の脆弱性、境界条件、仕様差分、権限不整合、設定不備。 | \(v \in V_t\) | まだ明示的な事件や修正対象にはなっていないが、条件がそろうと危険化する揺らぎである。 |
| 観測 | AI 支援探索、人間レビュー、fuzzing、静的解析、ログ監視、脅威インテリジェンス。 | \(B_t = O_t(V_t)\) | 潜在的不整合を、扱える候補として可視化する操作である。 |
| 増幅 | 脆弱性候補が PoC、報告、advisory、報道、SNS、政府評価へ拡大する過程。 | \(\beta_t\)、\(\epsilon_t\)、\(C_t\) | 技術的差分が社会的認知へ変換される過程である。 |
| 削減 | トリアージ、再現確認、影響範囲評価、優先順位付け。 | \(R_t\) の前段階。 | 多数の候補から、修正すべき対象を選別する操作である。 |
| 履歴固定 | 攻撃として記録されるか、修正として記録されるか。 | \(T_e(v)\)、\(T_p(v)\)、\(W(v)\) | 観測された不整合が、被害履歴または修正履歴として不可逆に残る過程である。 |
| 再安定化 | パッチ適用、回避策、設定変更、テスト追加、制度更新、再観測。 | \(H_t\) の低下。 | 不整合を処理し、構造を次の安定状態へ移す過程である。 |
この対応関係によって、ここまでの議論は構造振動モデルの内部に自然に配置できる。潜在脆弱性集合 \(V_t\) は、構造内部に存在する潜在的不整合振動の集合である。観測能力 \(O_t\) は、その振動を可視化する能力である。悪用能力 \(A_t\) は、観測された振動を攻撃手順へ接続する能力である。修正能力 \(R_t\) は、観測された振動を修正、緩和、隔離、再設計へ接続する能力である。残存リスク \(H_t\) は、まだ再安定化されずに残っている不整合振動の重み付き量である。社会的認知 \(C_t\) は、その振動が技術共同体や社会全体にどれほど強く伝播したかを表す。
この観点から見ると、AI は怪物ではない。AI は、構造内部の潜在的不整合振動を観測可能な差分へ増幅する観測器である。ただし、それは単なる中立的観測器でもない。望遠鏡が天体を観測するだけでなく、観測された天体の意味を科学制度へ接続するように、AI は脆弱性候補を発見し、それを説明、再現手順、修正案、攻撃手順、報告文書、検証コード、リスク評価へ変換し得る。したがって、AI は観測したものを、攻撃履歴にも修正履歴にも接続できる能動的観測器である。
B_t = O_t(V_t)
\]
この式は、構造振動モデルの観点では、潜在的不整合振動 \(V_t\) が観測能力 \(O_t\) によって候補集合 \(B_t\) として可視化されることを意味する。ここで重要なのは、観測によって不整合が新しく作られるわけではないという点である。多くの場合、不整合は観測以前から構造内部に存在している。AI はそれを発生させるのではなく、見える形へ引き出す。ただし、見える形へ引き出された瞬間から、その不整合は社会的経路へ入る。攻撃者が見れば攻撃候補になり、防御者が見れば修正候補になり、メディアが見れば騒動になり、政府が見れば規制課題になる。
したがって、構造振動モデルに接続すると、AI による弱点探索とは、構造内部の潜在的不整合振動を観測可能な差分へ増幅し、それを攻撃履歴または修正履歴へ固定する過程である。この中心命題に立つと、Claude Mythos 騒動を「封印された怪物が暴れ出す話」として読む必要はない。より正確には、これまで見えにくかった構造内部の不整合を、高い解像度で観測できる装置が現れ、その観測結果をどの履歴へ固定するのかを社会が問われている、という問題である。
| 観測後の経路 | 履歴固定の種類 | 数理モデル上の対応 | 社会的意味 |
|---|---|---|---|
| 攻撃者が利用する | 攻撃履歴へ固定される。 | \(T_e(v)\) が \(T_p(v)\) より先行し、\(W(v)\) が大きくなる。 | 不整合が侵害、権限昇格、情報漏洩、妨害、被害として記録される。 |
| 防御者が処理する | 修正履歴へ固定される。 | \(T_p(v)\) が \(T_e(v)\) より先行または近接し、\(W(v)\) が小さくなる。 | 不整合がパッチ、設定変更、回避策、テスト追加、設計改善として記録される。 |
| 報道や政治で増幅される | 認知履歴へ固定される。 | \(C_t = \beta_t H_t + \epsilon_t\) | 不整合が社会不安、政策課題、企業宣伝、規制論争として記録される。 |
| 放置される | 未処理振動として残る。 | \(H_t\) が下がらず、次時刻へ持ち越される。 | 不整合が未修正リスクとして残り、後の攻撃や騒動の材料になる。 |
この表が示すように、観測された不整合は、そのままでは安全にも危険にもならない。重要なのは、どの経路で履歴固定されるかである。攻撃履歴へ固定されれば、社会はその不整合を被害として知る。修正履歴へ固定されれば、社会はその不整合を改善として知る。認知履歴へ固定されれば、社会はその不整合を騒動、規制、企業発信、メディア物語として知る。放置されれば、不整合は未処理振動として残り、次の時刻のリスク \(H_{t+1}\) を押し上げる。
ここで、構造振動モデルの「振動」という語は、単なる詩的比喩ではない。脆弱性管理では、同じ構造が繰り返し揺れる。新機能を追加すれば新しい不整合が生じる。観測能力が上がれば不整合が見える。見えた不整合は攻撃または修正へ流れる。修正すれば構造は一時的に安定する。しかし、次の機能追加、依存関係更新、環境変化、攻撃手法の変化によって、また別の不整合が生じる。つまり、ソフトウェア社会は、固定された完成物ではなく、揺れ、観測され、削減され、再安定化される更新過程である。
S_{t+1} = \operatorname{Stabilize}(S_t, R_t(O_t(V_t)))
\]
この式は、構造振動モデルにおける再安定化を簡略化して表している。\(S_t\) は時刻 \(t\) における社会技術構造である。\(V_t\) はその内部にある潜在的不整合集合である。\(O_t(V_t)\) は観測によって可視化された候補集合である。\(R_t(O_t(V_t))\) は、その候補集合に対して修正能力が作用し、パッチ、緩和、隔離、テスト追加、制度更新へ変換する過程である。最後に \(\operatorname{Stabilize}\) は、その修正結果を構造 \(S_t\) に取り込み、次の時刻の構造 \(S_{t+1}\) として再安定化する操作を表す。
この式で注意すべきなのは、\(S_{t+1}\) が完全な安全状態を意味しない点である。再安定化とは、すべての不整合が消えることではない。ある時点で観測され、処理された不整合を構造へ反映し、よりましな安定状態へ移ることである。その新しい構造 \(S_{t+1}\) もまた、新しい依存関係、新しい設定、新しい運用、新しい攻撃面を含む。したがって、構造振動モデルでは、安全性は静的な完成状態ではなく、観測、修正、再安定化を継続できる動的能力として理解される。
| 段階 | 構造振動モデル上の意味 | 脆弱性管理上の意味 | 失敗した場合 |
|---|---|---|---|
| 複雑化 | 構造が部品、依存関係、機能、制度を増やす。 | 新機能、ライブラリ追加、クラウド移行、設定変更、サプライチェーン拡大。 | 潜在的不整合 \(V_t\) が増える。 |
| 振動 | 構造内部の不整合が潜在的な揺らぎとして残る。 | 未発見脆弱性、設定ミス、権限境界の曖昧さ、互換経路の副作用。 | 見えないリスクとして蓄積する。 |
| 観測 | 揺らぎが差分として可視化される。 | AI 支援探索、fuzzing、レビュー、ログ監視、CVD 報告。 | 観測不足なら「知らなかった」状態が続く。観測過多なら未処理候補が増える。 |
| 削減 | 観測された差分を意味ある処理対象へ絞る。 | トリアージ、再現確認、影響範囲評価、優先順位付け。 | 誤検知に埋もれる、重大候補を見逃す、保守者が疲弊する。 |
| 履歴固定 | 差分が攻撃、修正、認知、放置のいずれかとして記録される。 | 攻撃被害、パッチ、advisory、報道、backlog。 | 攻撃履歴や未処理リスクとして残る。 |
| 再安定化 | 処理結果を構造に取り込み、次の安定状態へ移る。 | パッチ適用、テスト追加、設計改善、制度更新、運用改善。 | 同種の問題が再発し、修正が構造へ定着しない。 |
この整理により、Claude Mythos 騒動の位置づけはさらに明確になる。問題は、AI という外部の怪物が突然社会へ侵入したことではない。すでに複雑化していた社会技術構造の内部に、潜在的不整合振動が多数存在していた。AI は、それを高い解像度で観測し、候補として取り出し、場合によっては攻撃手順にも修正手順にも変換できるようにした。したがって、争点は AI の存在そのものではなく、AI によって可視化された構造振動を、どの制度、どの責任、どの速度、どの履歴へ固定するかである。
この章から次章へ進むために重要なのは、観測された不整合が一つの経路に決まっているわけではないという点である。同じ脆弱性候補でも、攻撃者が先に利用すれば攻撃履歴になり、防御者が先に処理すれば修正履歴になり、メディアが先に増幅すれば認知履歴になり、誰も処理しなければ未処理振動として残る。次章では、この履歴固定の分岐を、攻撃履歴と修正履歴という二つの更新経路として整理する。これにより、AI 時代の安全性を、観測された構造振動がどちらの履歴へ流れるかという問題として扱えるようになる。
18. 世界を構造として見ると何が見えるか
前章では、Claude Mythos 騒動と AI による弱点探索を、構造振動モデルの中に位置づけた。そこでは、脆弱性を構造内部の潜在的不整合振動として捉え、AI をその不整合を観測可能な差分へ増幅する能動的観測器として整理した。本章では、さらに一段広い視点から、世界を物体の集合ではなく構造として見ると何が見えるのかを考える。世界を構造として見る立場では、個々の物体、個々のプログラム、個々の脆弱性は、孤立した実体ではなく、関係、境界、依存、更新、観測、履歴の中で成立するものとして扱われる[33]。
この視点に立つと、脆弱性は単独のバグではない。もちろん、実装上は特定の関数、特定の条件分岐、特定の API 呼び出し、特定のメモリー操作、特定の設定ミスとして現れる。しかし、その本質は、多くの場合、複数構造の接続点に生じる位相ずれである。仕様上は読み取り専用と見なされるもの、実行時には変更可能なもの、キャッシュ上でのみ変化するもの、権限境界を越えてはいけないもの、互換性のために残された経路、性能最適化のために導入された経路が、ある条件で接続される。その接続点で、各構造の意味がわずかにずれる。このずれが、条件次第で脆弱性として現れる。
| 通常の見方 | 構造として見る見方 | 脆弱性管理上の意味 |
|---|---|---|
| 脆弱性はコード中のバグである。 | 脆弱性は、仕様、実装、権限、状態、運用、依存関係の接続点に生じる位相ずれである。 | 単一箇所の修正だけでなく、境界条件と接続構造を確認する必要がある。 |
| 安全性は、危険なバグがない状態である。 | 安全性は、不整合が観測されたときに、構造を再安定化できる状態である。 | 欠陥ゼロではなく、観測、修正、適用、再観測の能力が重要になる。 |
| AI は脆弱性を見つける道具である。 | AI は、構造内部の潜在差分を社会的に扱える情報状態へ変換する観測器である。 | 発見結果を攻撃へ流すか、修正へ流すかが社会的争点になる。 |
| 観測は、外界にあるものをそのまま写すことである。 | 観測は、対象構造と観測主体の内部状態を同時に更新する操作である。 | 脆弱性情報は、受け取る主体によって攻撃知識にも防御知識にもなる。 |
この表が示すように、世界を構造として見ると、脆弱性の意味は変わる。脆弱性は、物体の中に埋まっている傷のようなものではない。それは、複数の構造が接続されたときに、ある前提が別の前提と噛み合わなくなる現象である。たとえば、ある機能が単独では仕様通りに動き、別の機能も単独では仕様通りに動いている場合でも、両者が特定の経路で接続されると、全体として権限境界が破れることがある。これは、局所正当性の合成が全体正当性を保証しないという問題である。
観測者を含む確率モデルや、観測を情報更新として扱う宇宙論では、観測とは外界の単純な写像ではなく、内部状態の更新である[34][35]。この観点をセキュリティへ置き換えると、AI が脆弱性を発見するとは、ソフトウェア構造の潜在差分を、社会が扱える情報状態へ変換することである。発見された瞬間、その差分は単なる潜在的不整合ではなくなる。報告書になり、PoC になり、パッチ案になり、advisory になり、CVE になり、KEV になり、メディア記事になり、SNS 上の騒動になる。つまり、観測は対象の意味を更新し、同時に観測者と社会の状態も更新する。
| 観測前の状態 | 観測操作 | 観測後の情報状態 | 起こり得る履歴固定 |
|---|---|---|---|
| 構造内部に潜在的不整合がある。 | AI、人間、fuzzing、監視が差分を検出する。 | 脆弱性候補として認識される。 | トリアージ対象、攻撃候補、報告候補になる。 |
| 脆弱性候補の影響が不明である。 | 再現確認、影響範囲調査、到達可能性評価を行う。 | 実脆弱性、軽微不具合、誤検知、条件付きリスクに分類される。 | 修正、保留、棄却、追加調査へ分岐する。 |
| 修正前の脆弱性情報が存在する。 | 発見者、ベンダー、攻撃者、メディア、政府が情報を受け取る。 | 主体ごとに異なる意味を持つ情報へ変換される。 | 攻撃履歴、修正履歴、認知履歴、制度履歴へ分岐する。 |
| 修正または悪用が行われる。 | パッチ適用、exploit 実行、報道、規制、運用変更が行われる。 | 構造の履歴が更新される。 | 被害、改善、規制、教訓、再発防止として残る。 |
この変換は、必ずしも善ではない。観測された差分は、防御者の内部状態を更新する一方で、攻撃者の内部状態も更新する。防御者にとっては、それは修正対象であり、影響範囲評価の材料であり、パッチ作成の入口である。攻撃者にとっては、それは侵入経路であり、標的選定の材料であり、exploit chain の部品である。メディアにとっては、それは物語であり、政府にとっては規制や安全保障の課題であり、企業にとっては能力説明や信頼維持の材料である。したがって、観測の社会的意味は、誰が、いつ、どの粒度で、どの修正経路とともにその情報を受け取るかに依存する。
この点を数理モデルへ戻せば、観測とは \(V_t\) から \(B_t\) への写像である。
B_t = O_t(V_t)
\]
この式で、\(V_t\) は時刻 \(t\) における潜在脆弱性集合であり、構造内部に存在する潜在差分の集合である。\(O_t\) は観測能力であり、AI、人間、fuzzing、静的解析、ログ監視、依存関係監査などを含む。\(B_t\) は観測された候補集合である。この式の重要な点は、\(B_t\) が単なる「真実の写し」ではないことである。観測能力 \(O_t\) の性質によって、何が見え、何が見えず、何が誤検知され、何が過大評価されるかが変わる。したがって、観測結果は外界の完全なコピーではなく、観測器の能力と制約を通じて形成された情報状態である。
| 観測主体 | 同じ \(B_t\) をどう読むか | 接続されやすい経路 | 社会的意味 |
|---|---|---|---|
| 防御者 | 修正すべき候補、影響範囲、緩和策、テスト観点として読む。 | トリアージ、CVD、パッチ、設定変更、監視強化。 | 観測結果が修正履歴へ流れる。 |
| 攻撃者 | 侵入経路、権限昇格経路、標的選定、攻撃チェーンの材料として読む。 | PoC、exploit、横展開、検知回避、短期悪用。 | 観測結果が攻撃履歴へ流れる。 |
| 保守者 | 再現確認、修正可否、互換性影響、リリース判断として読む。 | issue、patch、release、advisory、backport。 | 観測結果が保守履歴へ流れる。 |
| 利用組織 | 自組織への影響、パッチ適用要否、停止計画、残存リスクとして読む。 | 資産棚卸し、SBOM、適用計画、例外管理、監査記録。 | 観測結果が運用履歴へ流れる。 |
| メディア・社会 | 危機、物語、企業責任、政府対応、AI 脅威として読む。 | 報道、SNS、政策議論、世論形成。 | 観測結果が認知履歴へ流れる。 |
この表から分かるように、同じ観測結果であっても、主体が異なれば意味が変わる。これは、観測を単なる写像ではなく、内部状態の更新として捉える理由である。防御者の内部状態が更新されれば、修正計画が変わる。攻撃者の内部状態が更新されれば、攻撃計画が変わる。保守者の内部状態が更新されれば、リリース判断が変わる。利用組織の内部状態が更新されれば、パッチ適用計画が変わる。社会の内部状態が更新されれば、規制や報道や不安が変わる。観測とは、対象の情報を取り出す操作であると同時に、観測した主体の未来の行動を変える操作である。
したがって、世界を構造として見ると、AI による脆弱性発見とは、物体の中に隠れていた欠陥を掘り出すことではなく、複数構造の接続点に潜在していた位相ずれを、社会が扱える情報状態へ変換する操作である。この中心命題に立つと、Claude Mythos 騒動の焦点は、AI が欠陥を「作った」のかどうかではなく、AI が観測した差分を社会がどのように受け取り、どの履歴へ固定するのかに移る。差分が攻撃者へ先に届けば攻撃履歴になり、防御者へ適切に届けば修正履歴になり、制度へ届けば開示・規制・評価の履歴になり、社会へ届けば認知履歴になる。
この視点は、セキュリティだけに閉じない。金融、医療、行政、交通、AI、クラウド、OSS、サプライチェーン、報道制度も、すべて複数構造の接続として成り立つ。どの領域でも、問題は単独の物体に埋まっているのではなく、関係の中に潜在する。たとえば、医療システムでは診断、記録、保険、薬剤、患者行動が接続し、金融システムでは市場、規制、アルゴリズム、信用、決済が接続し、クラウドでは API、権限、ネットワーク、監査、課金が接続する。弱点は、しばしばその接続点に現れる。AI は、その接続点を高速に観測する装置になりつつある。
| 領域 | 構造の接続点 | 位相ずれとして現れる問題 | AI 観測の意味 |
|---|---|---|---|
| ソフトウェア | 仕様、実装、権限、依存関係、実行時状態。 | 脆弱性、権限昇格、情報漏洩、整合性破壊。 | 潜在的不整合を脆弱性候補として可視化する。 |
| クラウド | IAM、ネットワーク、API、ログ、マネージドサービス。 | 過剰権限、公開範囲ミス、監査不能、設定不備。 | 設定と権限の組み合わせリスクを発見する。 |
| OSS | 上流、下流、保守者、利用者、ディストリビューション。 | 未修正、backport 差分、保守者負荷、報告処理遅延。 | 依存関係と保守状態の不整合を可視化する。 |
| 金融 | 市場、信用、規制、決済、アルゴリズム、利用者行動。 | 連鎖的損失、流動性不足、モデル誤差、制度抜け穴。 | 異常パターンや構造的脆弱性を早期に観測する。 |
| 社会制度 | 企業、政府、メディア、利用者、規制、技術基盤。 | 責任の空白、過剰反応、対応遅延、説明不足。 | 制度的な処理遅延や責任分散を可視化する。 |
このように見ると、AI による弱点探索は、サイバーセキュリティだけの特殊問題ではなく、構造化された世界全体に起きている観測能力の上昇の一例である。世界が複雑な構造として成立している以上、接続点には潜在的な位相ずれが生じる。AI は、その位相ずれを高解像度で観測し、情報状態へ変換する。問題は、その情報状態を誰が受け取り、どの制度へ流し、どの速度で修正し、どの履歴として固定するかである。
この章から次章へ進むために重要なのは、情報状態への変換が中立的に終わらないという点である。観測された差分は、必ず何らかの履歴へ向かう。攻撃者の行動を変えれば攻撃履歴になる。防御者の行動を変えれば修正履歴になる。企業や政府やメディアの行動を変えれば認知履歴や制度履歴になる。次章では、この情報状態への変換が、なぜ攻撃履歴と修正履歴という二つの履歴固定へ分岐するのかを整理する。これにより、AI による観測能力の上昇を、世界の構造更新の問題としてより明確に扱えるようになる。
19. 時間、観測、履歴固定
前章では、AI による脆弱性発見を、複数構造の接続点に潜在していた位相ずれを、社会が扱える情報状態へ変換する操作として整理した。本章では、この情報状態への変換を、時間と履歴固定の問題として捉え直す。時間を、単なる時計の目盛りではなく、参照可能な履歴が増える過程として見るなら、脆弱性対応とは、潜在的不整合を発見し、分類し、修正し、社会の運用履歴へ固定する過程である[36]。この視点に立つと、セキュリティ対応は単なる作業チケットの処理ではない。未発見の可能性構造を、攻撃履歴へ固定される前に、修正履歴として固定する時間的競争である。
ここで、量子観測、デコヒーレンス、多世界解釈、ボルン則をめぐる議論との抽象的な接続が見えてくる。これらの議論で扱ってきたのは、可能性、観測、記録、安定化、そして履歴がどのように成立するかという問題である[37][38][39][40]。もちろん、ソフトウェア脆弱性は量子現象ではない。脆弱性はコード、設定、権限、運用、依存関係の中に生じる社会技術的な不整合であり、量子状態の重ね合わせや物理的デコヒーレンスと同一視してはならない。しかし、可能性構造が観測され、記録され、以後の状態を制約する履歴として固定されるという抽象構造には共通点がある。
| 抽象構造 | 量子観測の議論での意味 | 脆弱性対応での意味 | 注意点 |
|---|---|---|---|
| 可能性構造 | 測定前に複数の可能な結果が理論上存在する状態。 | 未発見の不整合が、攻撃にも修正にもまだ固定されていない状態。 | 物理的な重ね合わせと、社会技術的な未処理可能性を混同しない。 |
| 観測 | 可能性の一部が記録可能な結果として現れる過程。 | AI、人間、fuzzing、監視によって脆弱性候補が可視化される過程。 | 脆弱性観測は、物理測定ではなく情報処理と制度的認識である。 |
| 記録 | 結果が環境や観測者に残り、参照可能になること。 | CVE、advisory、issue、patch、ログ、報道、インシデント記録として残ること。 | 記録は中立ではなく、攻撃にも防御にも使われ得る。 |
| 履歴固定 | 以後の状態が、記録された結果を前提として進むこと。 | 脆弱性が攻撃履歴、修正履歴、認知履歴、制度履歴のいずれかとして残ること。 | どの履歴へ固定されるかによって社会的意味が変わる。 |
| 再安定化 | 観測後の状態が、以後の時間発展の基準になること。 | パッチ適用、設定変更、テスト追加、制度更新により、次の安定状態へ移ること。 | 再安定化は完全な安全ではなく、次の更新状態への移行である。 |
この表が示すように、ここで使っているのは物理現象としての同一性ではなく、抽象構造としての類比である。量子論では、可能性、観測、記録、履歴の関係が問題になる。脆弱性対応でも、未発見の不整合、観測された候補、記録された報告、固定された攻撃または修正の履歴が問題になる。両者は対象もスケールも異なるが、「まだ履歴になっていない可能性が、観測と記録を通じて履歴へ変わる」という構造を共有している。
未発見の欠陥は、社会の運用履歴にはまだ現れていない可能性構造である。それは、攻撃者によって先に発見されれば侵害の可能性を持ち、防御者によって先に発見されれば修正の可能性を持つ。発見前の段階では、その不整合は社会的にはまだ明示的な事実ではない。しかし、AI や人間の観測によって候補として可視化され、再現され、CVE が付与され、advisory に記録され、パッチが作られ、運用環境に適用されると、その不整合は「修正された事実」として社会の履歴に組み込まれる。逆に、攻撃者が先に exploit 化し、侵害や漏洩や権限昇格として記録されれば、その不整合は「被害を生んだ事実」として履歴に固定される。
| 段階 | 履歴固定前の状態 | 履歴固定後の状態 | 社会的意味 |
|---|---|---|---|
| 未発見 | 構造内部に潜在的不整合として存在する。 | まだ社会の明示的履歴には現れていない。 | 危険は存在し得るが、処理対象としては認識されていない。 |
| 発見 | AI、人間、攻撃者、監視機構が差分を観測する。 | 脆弱性候補として記録可能になる。 | 攻撃にも修正にも向かい得る分岐点になる。 |
| 分類 | 候補の意味が未確定である。 | 実脆弱性、誤検知、軽微不具合、条件付きリスクへ分類される。 | 以後の対応優先度が決まる。 |
| 攻撃 | 悪用可能性が存在する。 | 侵害、漏洩、権限昇格、妨害として記録される。 | 不整合が攻撃履歴へ固定される。 |
| 修正 | 修正または緩和の余地がある。 | patch、advisory、設定変更、テスト追加、運用更新として記録される。 | 不整合が修正履歴へ固定される。 |
このように見ると、脆弱性対応は、単に問題を見つけて直す作業ではなく、可能性構造をどの履歴へ固定するかという時間的な操作である。同じ不整合でも、攻撃者が先に利用すれば攻撃履歴になり、防御者が先に処理すれば修正履歴になる。メディアや政府が先に増幅すれば認知履歴や制度履歴になる。どの履歴へ固定されるかによって、その不整合が社会に残す意味は変わる。したがって、脆弱性対応とは、潜在的不整合を発見し、攻撃履歴へ固定される前に、修正履歴として社会の時間構造へ固定する過程である。
この考え方は、前章までの三速度モデルとも接続する。発見時刻 \(T_d(v)\)、悪用可能化時刻 \(T_e(v)\)、修正適用時刻 \(T_p(v)\) は、いずれも履歴固定に関係する時刻である。\(T_d(v)\) は、潜在的不整合が観測可能な候補として履歴に現れ始める時刻である。\(T_e(v)\) は、その不整合が攻撃可能性として履歴に固定され始める時刻である。\(T_p(v)\) は、その不整合が修正済みまたは緩和済みとして履歴に固定される時刻である。危険窓 \(W(v)=\max(0,T_p(v)-T_e(v))\) は、攻撃履歴へ固定され得る期間が、修正履歴によって閉じられるまでの幅として読める。
| 時刻 | 時間論的な意味 | セキュリティ上の意味 | 履歴固定の方向 |
|---|---|---|---|
| \(T_d(v)\) | 可能性構造が観測可能な差分として現れ始める時刻。 | 脆弱性候補が発見される時刻。 | 攻撃履歴、修正履歴、認知履歴の分岐点になる。 |
| \(T_e(v)\) | 差分が攻撃可能性として具体化する時刻。 | PoC、exploit、攻撃チェーンへ接続可能になる時刻。 | 攻撃履歴へ固定される可能性が高まる。 |
| \(T_p(v)\) | 差分が修正済み状態として構造に取り込まれる時刻。 | パッチ、緩和、設定変更、適用完了の時刻。 | 修正履歴へ固定される。 |
| \(W(v)\) | 攻撃履歴へ固定され得る未閉鎖の時間幅。 | 悪用可能化から修正適用までの危険窓。 | 短いほど修正履歴が攻撃履歴に先行しやすい。 |
この対応により、AI による観測能力の上昇が時間構造に与える影響も明確になる。AI は \(T_d(v)\) を早める。つまり、潜在的不整合をより早く履歴の入口へ引き出す。しかし、それだけでは安全にはならない。発見された不整合が攻撃者側で \(T_e(v)\) へ早く進めば、攻撃履歴が先に固定される。防御者側で \(T_p(v)\) へ早く進めば、修正履歴が先に固定される。したがって、AI 時代の安全性は、可能性構造を早く観測することだけでなく、その観測結果をどの履歴へ固定するかによって決まる。
この章から次章へ進むために重要なのは、履歴固定には分岐があるという点である。観測された不整合は、自動的に修正履歴へ入るわけではない。攻撃者が先に利用すれば攻撃履歴になる。防御者が先に処理すれば修正履歴になる。制度や報道が先に反応すれば認知履歴や制度履歴になる。次章では、この履歴固定を、攻撃履歴と修正履歴という二つの分岐としてさらに明確化する。これにより、AI による観測能力の上昇を、単なる発見能力の問題ではなく、社会の時間構造をどの方向へ固定するかという問題として扱えるようになる。
20. 創発、意味、環世界
前章では、脆弱性対応を、潜在的不整合が観測され、攻撃履歴または修正履歴へ固定される時間的過程として整理した。本章では、その観測された情報が、なぜ主体ごとに異なる意味を持つのかを考える。AI による弱点探索は、単なるビット列処理ではない。もちろん、計算機の内部では、コード、ログ、設定、パッチ、PoC、CVE、advisory、依存関係情報は、最終的にはビット列として保存され、処理される。しかし、それらが人間社会の中で意味を持つのは、ビット列そのものとしてではない。コードが仕様と照合され、ログが異常兆候として読まれ、PoC が悪用可能性を示し、CVE が共通識別子になり、パッチが修正履歴になり、運用判断がリスク受容や適用計画になるとき、下位の情報要素は相互作用し、上位構造としての意味を生成する。
創発論では、下位要素の単純な総和では説明しきれない上位構造が、要素間の相互作用から安定的に現れることを扱う[41]。水は水素原子と酸素原子の単なる並置ではなく、分子構造と相互作用によって液体としての性質を示す。脳はニューロンの単なる集まりではなく、結合、発火、可塑性、身体、環境との相互作用によって認知を成立させる。社会は個人の単なる集合ではなく、制度、言語、信頼、規範、記録、メディアによって上位構造を形成する。同様に、脆弱性情報も、単なる文字列や識別子ではない。コード、仕様、環境、攻撃手順、修正能力、制度、主体の目的が結合することで、初めて社会的意味を持つ。
| 下位要素 | 相互作用 | 創発する上位意味 | 脆弱性管理での例 |
|---|---|---|---|
| コード断片 | 仕様、権限境界、入力条件、実行時状態と結び付く。 | 安全な処理、危険な処理、境界破綻の候補として意味を持つ。 | 単独では普通の処理に見える関数が、特定条件で権限昇格経路になる。 |
| ログ | 時間、アクセス元、認証、既知攻撃パターン、運用知識と結び付く。 | 通常運用、異常兆候、攻撃痕跡、誤検知として意味を持つ。 | 単なるエラー行が、特定の CVE 悪用試行の兆候として読まれる。 |
| CVE | 製品情報、バージョン、CVSS、KEV、advisory、資産台帳と結び付く。 | 共通参照点、優先対応対象、影響範囲調査の入口として意味を持つ。 | 同じ CVE が、自組織の該当資産と結び付くことで緊急対応対象になる。 |
| PoC | 対象環境、攻撃者能力、検知状況、修正状況と結び付く。 | 再現確認手段、攻撃手順、危険度上昇シグナルとして意味を持つ。 | 防御者には検証材料だが、攻撃者には実用化の足場になる。 |
| パッチ | リリース、互換性、テスト、適用計画、再起動、ロールバックと結び付く。 | 修正履歴、運用変更、残存リスク低下として意味を持つ。 | 公開されたパッチが、本番適用されて初めて危険窓を閉じる。 |
この表が示すように、脆弱性情報の意味は、情報単体では決まらない。同じコード断片でも、仕様と照合されなければ危険かどうかは分からない。同じ CVE でも、自組織に該当資産がなければ優先度は低い。同じ PoC でも、防御者が隔離環境で再現確認に使えば修正に向かい、攻撃者が標的環境に合わせて調整すれば攻撃に向かう。同じパッチでも、適用されなければ残存リスクは下がらない。意味は、情報、主体、環境、目的、行為可能性の結合から創発する。
ここで環世界の概念が重要になる。世界が意味を持つのは、差異が主体の更新に寄与するときであり、環世界は主体ごとに異なる意味空間を形成する[42][43]。同じ外界であっても、主体が持つ感覚器、能力、目的、制約、行為可能性が異なれば、見えている意味空間は異なる。セキュリティに置き換えれば、同じ脆弱性情報でも、攻撃者、防御者、ベンダー、OSS 保守者、利用組織、メディア、規制当局にとって意味は異なる。それぞれが異なる環世界の中で、その情報を別の行為可能性として読むからである。
| 主体 | 環世界 | 同じ脆弱性情報の意味 | 接続される行為 |
|---|---|---|---|
| 攻撃者 | 侵入経路、標的、検知回避、権限拡大、収益化可能性を中心に世界を見る。 | 脆弱性情報は、攻撃経路、PoC 化対象、標的選定材料、攻撃チェーンの部品になる。 | 再現、exploit 化、標的調査、検知回避、短期悪用。 |
| 防御者 | 資産、露出面、ログ、検知、緩和策、パッチ適用、被害抑制を中心に世界を見る。 | 脆弱性情報は、修正対象、監視対象、影響範囲評価、優先順位付けの材料になる。 | トリアージ、隔離、監視強化、パッチ、CVD、再観測。 |
| ベンダー | 製品品質、互換性、責任、信頼、リリース管理、利用者通知を中心に世界を見る。 | 脆弱性情報は、修正責任、信頼維持、advisory、リリース判断の課題になる。 | 再現確認、修正、テスト、リリース、通知、説明。 |
| OSS 保守者 | 限られた時間、報告品質、再現性、コミュニティ信頼、互換性を中心に世界を見る。 | 脆弱性情報は、処理すべき issue、保守負荷、支援要求、リリース判断になる。 | 報告整理、修正、レビュー、backport、公開調整。 |
| 利用組織 | 自組織資産、業務影響、停止可能性、監査、残存リスク、説明責任を中心に世界を見る。 | 脆弱性情報は、更新判断、業務調整、例外管理、リスク受容の材料になる。 | 資産照合、パッチ適用、再起動計画、回避策、監査記録。 |
| メディア | 社会的関心、読者理解、物語性、危機性、企業責任を中心に世界を見る。 | 脆弱性情報は、ニュース、警告、企業批判、AI 脅威の物語になる。 | 報道、見出し化、専門家コメント、SNS 拡散。 |
| 規制当局 | 公共安全、重要インフラ、報告義務、標準化、市場規律を中心に世界を見る。 | 脆弱性情報は、制度設計、規制強化、報告基準、支援策の材料になる。 | ガイドライン、義務化、監督、情報共有、支援制度。 |
この表が示すように、同じ脆弱性情報は、主体ごとに異なる意味を持つ。これは、誰かが事実を歪めているという単純な話ではない。主体ごとに、見ている行為可能性が違うのである。攻撃者は「どう侵入できるか」を見る。防御者は「どう塞ぐか」を見る。ベンダーは「どう修正し信頼を保つか」を見る。利用組織は「自分たちの環境に影響するか」を見る。メディアは「社会にどう伝わるか」を見る。規制当局は「制度として何を変えるべきか」を見る。意味は情報そのものに固定的に内在するのではなく、主体の環世界と行為可能性の中で立ち上がる。
この点を数理モデルへ戻すと、同じ観測候補集合 \(B_t = O_t(V_t)\) は、主体 \(i\) ごとに異なる意味関数を通じて解釈されると書ける。
Meaning_i(B_t) = \Phi_i(B_t, G_i, C_i, K_i, P_i)
\]
この式で、\(Meaning_i(B_t)\) は主体 \(i\) にとっての観測候補集合 \(B_t\) の意味である。関数 \(\Phi_i\) は、主体 \(i\) が情報をどのように解釈するかを表す。\(G_i\) は目的であり、攻撃、修正、保守、報道、規制、利用継続などを含む。\(C_i\) は制約であり、予算、時間、権限、法的責任、停止許容度、情報アクセスを含む。\(K_i\) は知識であり、専門性、過去事例、対象システム理解、攻撃手法、運用知識を含む。\(P_i\) は行為可能性であり、その主体が実際に何をできるかを表す。つまり、同じ \(B_t\) でも、\(\Phi_i\) が異なれば意味は異なる。
| 記号 | 意味 | 脆弱性情報の解釈に与える影響 |
|---|---|---|
| \(B_t\) | 観測された候補集合。 | AI、人間、監視、fuzzing によって可視化された脆弱性候補や不整合情報である。 |
| \(G_i\) | 主体 \(i\) の目的。 | 攻撃したいのか、守りたいのか、修正したいのか、報道したいのか、規制したいのかで意味が変わる。 |
| \(C_i\) | 主体 \(i\) の制約。 | 時間、予算、権限、法的責任、停止可能性、公開範囲によって意味が変わる。 |
| \(K_i\) | 主体 \(i\) の知識。 | 専門性や対象理解があるかどうかで、同じ情報を攻撃経路にも誤検知にも修正対象にも読める。 |
| \(P_i\) | 主体 \(i\) の行為可能性。 | 実際に exploit できるのか、patch できるのか、適用できるのか、報道できるのかで意味が変わる。 |
| \(\Phi_i\) | 主体 \(i\) の意味変換関数。 | 観測候補を、その主体にとっての行動可能な意味へ変換する。 |
この式の重要な点は、意味を情報量だけに還元しないことである。大量の情報があっても、主体にそれを扱う知識 \(K_i\) がなければ意味は立ち上がりにくい。知識があっても、行為可能性 \(P_i\) がなければ、情報は行動へ接続されない。目的 \(G_i\) が異なれば、同じ情報は別の方向へ読まれる。制約 \(C_i\) が厳しければ、重要な情報でもすぐには処理できない。したがって、意味とは、情報と主体の関係から創発する更新可能性である。
この観点から見ると、AI の役割も変わって見える。AI は単にビット列を処理するだけではなく、主体の意味変換関数 \(\Phi_i\) を補助する。防御者にとって AI は、ログを異常として読む、コードを脆弱性候補として読む、CVE を自組織資産と対応付ける、パッチの影響を整理する、報告文を作る、といった意味変換を支援する。攻撃者にとっても、AI は同じように、コードを攻撃経路として読む、PoC を標的環境へ合わせる、既知パターンから次の候補を探す、といった意味変換を支援し得る。したがって、AI は意味生成を加速する装置でもある。
ここで重要なのは、意味生成が必ずしも安全側へ向かうとは限らないことである。脆弱性候補が防御者の環世界で読まれれば、修正対象として意味を持つ。攻撃者の環世界で読まれれば、攻撃経路として意味を持つ。メディアの環世界で読まれれば、騒動や物語として意味を持つ。規制当局の環世界で読まれれば、制度設計や監督対象として意味を持つ。つまり、観測された情報は、主体ごとの意味空間を通じて、異なる履歴へ流れる。
| 意味生成の方向 | 主体の環世界 | 生成される意味 | 固定される履歴 |
|---|---|---|---|
| 攻撃方向 | 侵入、権限、標的、検知回避を中心に構成される。 | 脆弱性情報が攻撃可能性として意味を持つ。 | 攻撃履歴、被害履歴、侵害記録。 |
| 防御方向 | 資産、露出、修正、監視、緩和を中心に構成される。 | 脆弱性情報が修正対象として意味を持つ。 | 修正履歴、パッチ履歴、運用改善履歴。 |
| 保守方向 | 互換性、リリース、レビュー、利用者通知を中心に構成される。 | 脆弱性情報が保守判断として意味を持つ。 | リリース履歴、advisory、backport、issue。 |
| 認知方向 | 社会不安、ニュース価値、企業責任、規制論争を中心に構成される。 | 脆弱性情報が騒動や公共問題として意味を持つ。 | 報道履歴、世論、政策議論。 |
| 制度方向 | 公共安全、重要インフラ、標準化、監督責任を中心に構成される。 | 脆弱性情報が制度改善の材料として意味を持つ。 | 規制履歴、ガイドライン、報告義務、標準。 |
この章の中心命題は、脆弱性情報の意味は情報そのものに固定的に内在するのではなく、その情報を受け取る主体の環世界、目的、能力、責任、行為可能性との関係で創発する、という点にある。この命題に立つと、Claude Mythos 騒動の意味もより明確になる。AI が弱点を発見すること自体が、直ちに善でも悪でもない。問題は、その発見がどの主体の環世界へ入り、どの意味として読まれ、どの行為へ接続され、どの履歴として固定されるかである。攻撃者の環世界では攻撃経路が創発し、防御者の環世界では修正対象が創発し、社会の環世界では騒動や制度論点が創発する。
この視点は、AI リスク管理にも直結する。AI の出力を単に制限するだけでは不十分である。重要なのは、AI が生成した情報が、どの主体の意味変換関数 \(\Phi_i\) へ入るのかを管理することである。認証された防御者、OSS 保守者、社内セキュリティチーム、CVD 調整機関へ接続されれば、同じ情報は修正意味を持ちやすい。匿名の悪用者、外部スキャンツール、検知回避手段へ接続されれば、攻撃意味を持ちやすい。したがって、AI リスク管理とは、情報そのものだけでなく、その情報が入る環世界と行為可能性を設計する問題でもある。
この章から次章へ進むために重要なのは、意味生成には認知資源が必要だという点である。主体は、観測された情報を無限に処理できるわけではない。攻撃者、防御者、保守者、利用組織、規制当局、メディアには、それぞれ注意、時間、専門知識、判断能力、処理能力の制約がある。AI は、この認知資源の配分を変える。次章では、この主体ごとの意味分岐をさらに進め、AI によって人間の認知資源と社会的判断構造がどのように再配分されるかを整理する。
21. 意識、主観、心のモデルから見た AI 騒動
前章では、脆弱性情報の意味が、情報そのものに固定的に内在するのではなく、その情報を受け取る主体の環世界、目的、能力、責任、行為可能性との関係で創発することを整理した。本章では、この議論を、意識、主観、心のモデルへ接続する。ただし、この接続は慎重に限定しなければならない。ここで問題にするのは、AI に意識があるか、AI が不安を感じるか、AI が主体として世界を経験しているか、という話ではない。Claude Mythos 騒動を考えるうえで重要なのは、AI の内面ではなく、AI による観測結果を受け取った人間社会が、自己モデル、危機感、責任帰属、行為選択をどのように更新するかである。
意識、クオリア、主観、心に関する一連の議論では、観測者を、外界から情報を受け取るだけの受動的容器ではなく、自己参照的に更新される構造として扱ってきた[44][45][46][47]。人間の主観は、単に外界のデータを写し取るのではない。身体状態、記憶、期待、恐怖、注意、目的、過去の経験、他者からの情報を統合し、「いま何が起きているのか」「自分は何をすべきか」という自己モデルを更新する。この構造を社会へ拡張すると、社会もまた、観測された事実を取り込み、自己記述を更新し、次の行為を変える構造として読める。
| 接続する対象 | 個人の意識・主観モデルでの意味 | 社会に拡張した場合の意味 | Claude Mythos 騒動での対応 |
|---|---|---|---|
| 観測 | 外界や身体状態の変化を取り込む。 | 技術的出来事、企業発信、政府評価、報道、専門家解説を取り込む。 | AI が脆弱性探索能力を持つという情報が社会へ入る。 |
| 統合 | 感覚、記憶、期待、目的を統合し、状況理解を作る。 | 企業、政府、研究者、利用者、メディアの解釈が重なり、社会的理解を作る。 | 「AI は危険か」「防御に使えるか」「公開すべきか」という争点が形成される。 |
| 自己モデル | 自分が置かれている状態、自分にできる行為、自分の危険を推定する。 | 社会が、自分たちの技術基盤、安全性、制度、責任能力をどう見るかが更新される。 | 社会は「既存制度で AI 時代の脆弱性探索を処理できるのか」と自問する。 |
| 情動・危機感 | 不安、警戒、期待、恐怖が注意配分と行動を変える。 | 世論、不安、規制圧力、企業説明責任、投資判断が変わる。 | 「封印された危険なモデル」という物語が、社会的危機感を増幅する。 |
| 行為選択 | 逃避、接近、修正、探索、学習などの行動を選ぶ。 | 規制、公開制御、CVD、AI リスク管理、セキュア開発、パッチ運用が選ばれる。 | 社会は、AI を止めるのか、限定公開するのか、防御工程へ接続するのかを判断する。 |
この表で示したいのは、社会をそのまま一個の人間と同一視することではない。社会には単一の意識も、単一のクオリアも、単一の主体経験もない。したがって、「社会が感じる」「社会が怖がる」という表現は、厳密には比喩である。しかし、社会には、情報を取り込み、解釈し、共有し、制度化し、次の行為を変える構造がある。企業声明、政府評価、メディア報道、SNS、専門家解説、利用者の反応、規制議論は、社会全体の状態を更新する回路として働く。この意味で、社会は自己参照的な情報更新構造を持つ。
Claude Mythos 騒動は、社会が AI をどう見るかという自己モデルを更新する出来事である。従来、AI は文章生成、コード補助、検索、要約、チャット、創作支援の道具として理解されることが多かった。しかし、AI が高度な脆弱性探索や攻撃手順化に近い能力を持つと見なされると、社会の自己モデルは変わる。問題は「便利な AI をどう使うか」だけではなく、「AI によって自分たちのソフトウェア基盤の弱点がどれほど可視化されるのか」「その可視化を自分たちは処理できるのか」「攻撃者に先行されないのか」「責任は誰が負うのか」へ移る。
ここで重要なのは、AI を人間のような主体として過剰擬人化しないことである。AI は不安を感じて脆弱性を探しているわけではない。AI は怒り、恐怖、好奇心、悪意、倫理的責任を内面経験として持っているとは言えない。少なくとも、本稿で扱っている問題はそこではない。Claude Mythos 型の AI を考えるとき、焦点は AI の主観ではなく、AI が生成した観測結果が、人間社会の主観的危機感、意味生成、責任帰属、制度更新をどのように揺らすかである。
| 誤読 | なぜ誤りか | 本章で扱う正しい接続 |
|---|---|---|
| AI が人間のように怖がって脆弱性を探している。 | AI の出力を人間の情動や内面経験として読んでいる。 | AI は観測・生成システムであり、人間社会の危機感を揺らす情報を出力する。 |
| AI に主観があるから危険である。 | サイバーリスクの焦点を、能力、アクセス、ツール、責任から逸らしている。 | 問題は AI の主観ではなく、AI の能力が攻撃経路または修正経路へ接続されることにある。 |
| 社会には一つの意識がある。 | 社会を個人の主観と同一視している。 | 社会は単一の意識ではないが、情報を取り込み自己記述を更新する分散的構造を持つ。 |
| 騒動はただの感情反応であり無視してよい。 | 社会的認知が制度、投資、公開方針、規制を変えることを見落としている。 | 危機感は誇張を含み得るが、社会的行為を変える実在的な更新要因である。 |
この区別を置くことで、意識論との接続は過剰な擬人化を避けられる。AI 騒動において問うべきなのは、AI が何を「感じているか」ではない。問うべきなのは、人間社会が AI の出力をどう感じ、どう意味づけ、どう責任を割り当て、どう制度を変えるかである。つまり、AI の内面ではなく、AI をめぐる人間側の主観構造が問題になる。技術的には、AI が脆弱性候補を出す。社会的には、その出力が不安、期待、警戒、規制要求、防御投資、企業説明責任を生成する。この二層を分けなければならない。
この点を数理モデルとして簡略化するなら、社会の自己モデルを \(S_t^{soc}\)、AI から入力される観測情報を \(B_t\)、社会的認知を \(C_t\)、制度的応答を \(G_t\) と置ける。
S_{t+1}^{soc} = U(S_t^{soc}, B_t, C_t, G_t)
\]
この式で、\(S_t^{soc}\) は時刻 \(t\) における社会の自己モデルである。ここでいう自己モデルとは、「AI はどの程度危険か」「自分たちの制度は対応できるか」「誰が責任を負うか」「どの程度公開すべきか」「何を規制すべきか」「防御側は何を整備すべきか」といった社会的理解の集合である。\(B_t\) は AI や人間の観測によって得られた脆弱性候補や能力情報である。\(C_t\) は前章で扱った社会的認知・騒動強度である。\(G_t\) は政府、企業、標準化団体、コミュニティ、利用組織による制度的応答である。関数 \(U\) は、それらを取り込み、次の時刻の社会的自己モデル \(S_{t+1}^{soc}\) へ更新する操作を表す。
| 記号 | 意味 | Claude Mythos 騒動での例 |
|---|---|---|
| \(S_t^{soc}\) | 時刻 \(t\) における社会の自己モデル。 | AI は便利な道具だが、サイバー能力の扱いには制度的管理が必要だという理解。 |
| \(B_t\) | 観測された技術情報。 | AI が脆弱性候補を発見できる、攻撃手順化に近い支援が可能である、という情報。 |
| \(C_t\) | 社会的認知・騒動強度。 | メディア報道、企業発信、政府評価、SNS 拡散によって高まる危機感。 |
| \(G_t\) | 制度的応答。 | AI リスク管理、公開制御、CVD 接続、サイバー安全評価、規制議論、社内利用ルール。 |
| \(U\) | 社会的自己モデルの更新関数。 | 技術情報、騒動、制度応答を統合し、次の社会的理解を形成する過程。 |
この式は、社会に単一の意識があるという意味ではない。むしろ逆である。社会は、多数の主体、組織、制度、メディア、専門家、利用者の分散的な更新過程として動く。その分散的更新の結果として、「AI はどう扱うべきか」という社会的自己記述が変わる。たとえば、ある騒動の前には「高性能 AI を公開するかどうか」が主論点だったものが、騒動の後には「高性能 AI をどのアクセス制御、監査、CVD、修正工程へ接続するか」が主論点になる。この変化が、社会的自己モデルの更新である。
この章の中心命題は、Claude Mythos 騒動を意識論・主観論へ接続するとは、AI の内面を想定することではなく、AI による観測結果を受け取った人間社会が、自己モデル、危機感、責任帰属、行為選択を更新する構造を見ることだ、という点にある。AI は主体として恐怖しているわけではない。しかし、AI の出力は、人間主体と社会制度の意味生成を揺らす。その結果、社会は「AI とは何か」「何が危険か」「誰が責任を負うか」「何を修正すべきか」という自己記述を変える。
この理解に立つと、Claude Mythos 騒動は、封印された怪物の物語ではなく、社会の自己認識が更新された出来事として読める。AI が高度な弱点探索を行い得るという情報は、社会に対して、「既存のソフトウェア基盤はどれほど脆弱なのか」「発見された不整合を処理する能力は足りているのか」「防御者と攻撃者のどちらが先に履歴固定するのか」という問いを突きつける。この問いによって、人間社会の危機感、責任帰属、制度設計、技術投資が変わる。ここに、意識・主観・心のモデルとの構造的接続がある。
この章から次章へ進むために重要なのは、社会的な自己モデル更新が、人間の認知資源と判断構造の配分を変えるという点である。AI が観測結果を大量に出すと、人間はすべてを直接読むことができない。何を AI に任せ、何を人間が判断し、どこで責任を引き受けるのかが問題になる。次章では、この社会的な自己モデル更新を、人間と AI の役割分担、すなわち認知資源の再配分として整理する。
22. 知能、文脈、人生への接続
前章では、Claude Mythos 騒動を、AI の内面ではなく、AI による観測結果を受け取った人間社会が自己モデル、危機感、責任帰属、行為選択を更新する構造として整理した。本章では、この議論を、知能、文脈、人生という三つの軸へ接続する。ただし、ここでも接続範囲を明確に限定する必要がある。知能論との接続は、AI を人間のような主体として扱うためではない。文脈論との接続は、AI サービスの使い方の話に矮小化するためではない。人生論との接続は、セキュリティ問題を情緒的な自己啓発へ置き換えるためではない。ここで扱うのは、人間が外部化した知能が、人間社会自身の制度、運用、責任、意味生成を再観測するようになったという構造である。
まず、知能との接続を確認する。知能を、散逸を時空間的に拡張する予測制御機構として見るなら、知能とは単に問題を解く能力ではない。環境の変化を観測し、未来の状態を予測し、行為を選択し、エネルギー、時間、注意、労力、リスクをより広い範囲で配分する機構である[48]。人間は、道具、言語、記録、計算機、組織、制度を通じて、自分の知能を外部へ拡張してきた。AI による脆弱性探索は、その延長にある。人間がすべてのコードを直接読み、すべての依存関係を追い、すべての異常経路を想像することはできない。AI は、その探索、比較、要約、仮説生成、検証補助を外部化する装置である。
| 接続軸 | 通常の理解 | 本章での理解 | Claude Mythos 騒動での意味 |
|---|---|---|---|
| 知能 | 問題を解く能力、推論能力、学習能力。 | 観測、予測、制御、行為選択を外部環境へ拡張する機構。 | AI が人間のコード読解、弱点探索、修正案生成を外部化する。 |
| 文脈 | 会話履歴、設定、プロンプト、作業条件。 | 判断基準、責任境界、作業規則、評価軸を持ち運ぶ構造。 | AI を単発の応答装置ではなく、制度的判断を支える作業環境として扱う必要がある。 |
| 人生 | 個人の経験、記憶、選択、物語。 | 経験、記録、行為、責任が意味を生成する更新過程。 | 社会も、脆弱性発見、修正、失敗、制度化を通じて自己物語を更新する。 |
この表が示すように、三つの接続軸は別々に見えるが、共通しているのは更新である。知能は、環境を観測し、予測し、行為を更新する。文脈は、判断基準と作業規則を保存し、次の判断へ持ち越す。人生は、経験と記憶を統合し、次の行為と自己物語を更新する。Claude Mythos 騒動でも、同じ構造が現れている。AI が弱点を観測し、その観測結果が人間社会へ戻り、社会は自分たちの安全性、制度、責任、公開規範を更新せざるを得なくなる。
次に、AI に自身の文脈を持ち運ぶ議論との接続を考える。AI に文脈を持ち運ばせるとは、単に会話履歴を保存することではない。作業規則、判断基準、禁止事項、優先順位、文体、責任範囲、検証手順を外部化し、AI サービスを越えて再利用可能にすることである[49]。この観点から見ると、サイバー AI のリスク管理でも同じ問題が生じる。モデル単体の性能だけでは不十分であり、そのモデルがどの文脈、どの権限、どの対象範囲、どの報告経路、どの監査規則、どの修正工程の中で使われるかが重要になる。
| 文脈として外部化されるもの | 一般的な AI 利用での意味 | サイバー AI での意味 | 外部化されない場合の問題 |
|---|---|---|---|
| 判断基準 | 何を良い回答、正しい作業、望ましい出力とするか。 | どの脆弱性候補を重大とみなし、何を誤検知として扱うか。 | 大量の候補が出ても、優先順位が不安定になる。 |
| 作業規則 | どの順序で調査、生成、検証、修正を行うか。 | 発見、再現、影響範囲評価、CVD、パッチ、テスト、適用の流れ。 | AI の出力が修正工程へ接続されず、未処理情報として滞留する。 |
| 権限境界 | 何にアクセスでき、何を実行でき、何を出力してよいか。 | 対象リポジトリ、外部ネットワーク、スキャン、exploit 実行、ログ閲覧の制限。 | 防御支援が攻撃支援へ転化しやすくなる。 |
| 責任範囲 | AI が補助し、人間が判断する境界。 | AI が候補を出し、人間が再現性、影響、公開、修正、適用を判断する境界。 | 誤検知、過剰公開、危険出力、修正漏れの責任が曖昧になる。 |
| 検証手順 | 出力をどのように確認し、誤りを取り除くか。 | PoC 再現、回帰テスト、環境差分確認、修正後再観測。 | AI のもっともらしい指摘が、そのまま事実として扱われる。 |
この表から分かるように、AI を安全に使うとは、モデルの能力を単独で評価することではない。モデルを、どの文脈に置くかを設計することである。Claude Mythos 型のサイバー能力では、文脈設計の重要性はさらに大きい。なぜなら、同じ脆弱性情報でも、防御文脈では修正対象になり、攻撃文脈では侵入経路になるからである。したがって、AI リスク管理とは、モデルがどのような文脈を持ち、どの文脈へ出力を流し、どの文脈では出力を制限するかを設計する作業でもある。
さらに、人生を意味生成の構造として見る議論との接続がある。人生を意味生成の構造として見ると、意味は出来事そのものに固定されているのではなく、経験、記憶、自己物語、行為、責任の連鎖の中で形成される[50]。ある出来事が失敗として残るか、学習として残るか、転機として残るか、傷として残るかは、その後にどう解釈され、どう行為が変わり、どのような履歴として固定されるかに依存する。これは、社会の脆弱性対応にもそのまま当てはまる。ある脆弱性が単なる被害として残るのか、修正履歴として残るのか、制度改善として残るのか、公開規範の更新として残るのかは、その後の処理によって変わる。
| 人生論での構造 | 社会的脆弱性対応での構造 | 意味生成の方向 |
|---|---|---|
| 経験 | 脆弱性発見、インシデント、騒動、公開、修正。 | まだ意味が確定していない出来事として現れる。 |
| 記憶 | CVE、advisory、postmortem、報道、ログ、リリースノート。 | 出来事が参照可能な記録として残る。 |
| 自己物語 | 企業、OSS、政府、業界が「何を学んだか」を説明する。 | 出来事が失敗、教訓、改善、責任、転換点として解釈される。 |
| 行為 | パッチ、テスト追加、制度改正、AI 利用制御、CVD 改善。 | 解釈が次の行動へ変わる。 |
| 責任 | 誰が修正し、誰が公開し、誰が適用し、誰が説明するか。 | 意味生成が倫理と制度へ接続される。 |
この接続により、Claude Mythos 騒動は単なるセキュリティ事件ではなくなる。もちろん、技術的にはサイバー能力と脆弱性探索の問題である。しかし、より広く見れば、人間が外部化した知能によって、自分たちの制度、運用、責任構造を再観測させられている出来事である。AI が見つけるのはコードの欠陥だけではない。人間社会の修正能力、説明能力、責任分担、公開規範、運用余力、制度的処理能力の欠陥も同時に見つけてしまう。
この章の中心命題は、Claude Mythos 騒動とは、人間が外部化した知能によって、コードの欠陥だけでなく、人間社会の修正能力、説明能力、責任分担、公開規範そのものが再観測される出来事である、という点にある。AI は、人間の外側に置かれた道具であると同時に、人間社会自身を映し返す観測器でもある。脆弱性探索の結果として見えてくるのは、ソフトウェアの弱点だけではない。どの組織が更新できないのか、どの制度が報告を受け止められないのか、どの利用者がパッチを適用できないのか、どの企業が能力宣伝と安全説明を混同しているのか、どの社会が恐怖と冷笑の間で判断を失うのかも見えてくる。
この意味で、AI による弱点探索は、人間文明の外部化された知能が、人間文明の未処理構造を照らし返す現象である。人間は、知能を外部化することで、より広い範囲を観測できるようになった。しかし、観測範囲が広がるほど、見つかった不整合を処理する責任も増える。これは、個人の人生において、気づかなかった問題に気づいた後は、以前と同じ無自覚な状態には戻れないことに似ている。気づきは自由を増やすが、同時に責任も増やす。社会も同じである。AI によって脆弱性や制度的欠陥が観測された後、社会は「知らなかった」状態へ戻れない。
この章から次章へ進むために重要なのは、再観測された責任構造を、最終的に人間が引き受けなければならないという点である。AI は候補を出せる。AI は説明を補助できる。AI は修正案やテスト案を作れる。しかし、何を公開するか、何を修正するか、どのリスクを受け入れるか、誰に知らせるか、どの制度を変えるかを決めるのは、人間と組織である。次章では、この再観測された責任構造を、人間がどのように引き受けるべきか、すなわち観測能力が上がった社会における修正責任の倫理として整理する。
23. 自己、クオリア、AI 感情論をどこまで入れるべきか
前章では、Claude Mythos 騒動を、人間が外部化した知能によって、コードの欠陥だけでなく、人間社会の修正能力、説明能力、責任分担、公開規範そのものが再観測される出来事として整理した。本章では、そこからさらに一歩進めて、自己、クオリア、AI 感情論をどこまでこの議論に入れるべきかを限定する。結論から言えば、今回の主題はサイバー能力であり、AI が主観を持つかどうかではない。したがって、自己論やクオリア論は、AI の内面を論じるためではなく、AI を過剰に擬人化せず、機能、主観、責任を切り分けるための補助線として使うべきである。
自己を構造として定義する議論、クオリアの説明限界、AI の感情概念に関する議論は、AI をどう擬人化し、どこで機能と主観を分けるべきかを考える補助線になる[51][52][53]。AI が脆弱性を探すとき、そこに悪意、不安、野心、好奇心、恐怖、責任感があると考える必要はない。あるのは、入力、内部表現、探索、推論、出力、ツール利用、評価、フィードバックの連鎖である。もちろん、その連鎖が社会に与える影響は大きい。しかし、影響が大きいことと、AI が人間のような主観的意図を持つことは別である。
| 論点 | 混同した場合の誤り | 本稿での扱い | Claude Mythos 騒動での意味 |
|---|---|---|---|
| 探索能力 | AI が「悪意を持って」脆弱性を探していると読む。 | 入力とモデル能力とツール利用による機能的探索として扱う。 | 問うべきなのは、探索能力を誰が、どの権限で、どの対象に使うかである。 |
| 悪用可能性 | AI そのものが攻撃者であると読む。 | AI の出力が攻撃者の行為可能性を高め得る問題として扱う。 | 責任は、モデル、利用者、提供者、運用、制度の接続に分散する。 |
| 感情 | AI が不安、野心、敵意、快楽を持って行動していると読む。 | 感情語は、人間側の受け取り方や擬人化傾向を分析するために限定して使う。 | 「怖い AI」という物語が、能力、アクセス制御、修正責任の議論を曇らせる。 |
| 主観 | AI に主観があるかどうかを、サイバーリスク評価の中心に置く。 | 今回の主題からは切り離し、AI の内面ではなく社会的影響を見る。 | AI が何を感じるかではなく、人間社会が AI の出力をどう扱うかが問題である。 |
| 責任 | AI を責任主体のように扱い、人間と組織の責任を曖昧にする。 | 責任主体は、人間、組織、制度、運用、公開判断、アクセス設計に置く。 | AI を責めるのではなく、AI を組み込んだ社会技術システムを設計し直す必要がある。 |
この表で重要なのは、AI の機能的能力と人間的主観を分けることである。AI が高度な脆弱性候補を出せるとしても、それは AI が「攻撃したい」と感じていることを意味しない。AI が危険な手順を生成し得るとしても、それは AI が「敵意」を持つことを意味しない。AI が人間の不安を強く刺激するとしても、それは AI 自身が不安を持つことを意味しない。ここを混同すると、議論はすぐに「AI が目覚めた」「AI が敵意を持った」「封印された怪物が暴れ出した」という物語へ流れる。
しかし、Claude Mythos 騒動で現実に必要なのは、AI の主観を裁くことではない。必要なのは、人間が設計し、訓練し、提供し、接続し、利用する探索能力を、どの制度、どの権限、どの監査、どの修正工程へ接続するかを決めることである。AI が内面で何を感じているかではなく、AI がどの入力を受け、どの対象へアクセスし、どのツールを使い、どの出力を返し、その出力が誰の行為可能性を高めるかが問題である。
この意味で、AI 感情論をこの議論に入れる意義は、AI に主観を認めるためではなく、探索能力、悪用可能性、責任帰属を人間的感情の物語から切り離すためである。AI を「悪意ある主体」として描くと、責任の所在が曖昧になる。なぜなら、実際に設計したのは人間であり、公開範囲を決めるのは企業であり、利用規約とアクセス制御を定めるのは提供者であり、CVD やパッチ適用を担うのは組織であり、運用上の更新責任を持つのは利用者だからである。AI を怪物化すると、これらの具体的な責任構造が見えにくくなる。
| 物語化の方向 | 表面的には分かりやすい点 | 失われる論点 | 本稿で採用する整理 |
|---|---|---|---|
| AI が悪意を持った | 危険の原因を一つの主体へ集約できる。 | 設計、提供、利用、アクセス制御、監査、責任分担が見えなくなる。 | 悪意ではなく、能力と接続先を評価する。 |
| AI が不安定に暴走した | 予測不能な恐怖として表現しやすい。 | 実際のツール権限、出力制約、運用条件、評価環境が曖昧になる。 | 暴走物語ではなく、利用文脈と制御構造を見る。 |
| 危険な AI を封印すればよい | 対応策が単純に見える。 | 防御側の利用可能性、透明性、限定公開、CVD 接続、監査設計が抜け落ちる。 | 封印か公開かではなく、能力をどの責任構造へ接続するかを見る。 |
| AI はただの道具だから問題ない | 過剰な恐怖を抑えられる。 | 道具であっても探索コストを下げ、攻撃者と防御者の能力差を変える点を見落とす。 | 擬人化は避けるが、能力の社会的影響は過小評価しない。 |
したがって、この章で自己論、クオリア論、AI 感情論を扱う目的は、AI を人間化することではない。むしろ逆である。AI を人間化しすぎると、AI の能力を制度へどう接続するかという実務問題から遠ざかる。一方で、AI を単なる計算機として軽視しすぎると、AI が人間社会の意味生成、危機感、責任帰属、行為可能性を大きく変える点を見落とす。必要なのは、AI の主観を想定せずに、AI の出力が人間社会の主観構造を揺らすという二層構造を保つことである。
この二層構造を数理的に簡略化すれば、AI の機能的出力と社会の主観的反応を分けて書ける。
Y_t = F(X_t, K_t, T_t)
\]
この式で、\(Y_t\) は時刻 \(t\) における AI の出力である。\(X_t\) は入力であり、コード、ログ、仕様、依存関係、プロンプト、検証環境などを含む。\(K_t\) はモデル内部に蓄積された知識や表現能力であり、学習済みパターン、推論能力、コード理解能力を含む。\(T_t\) は利用可能なツールであり、検索、実行環境、静的解析、リポジトリアクセス、ネットワーク到達性などを含む。関数 \(F\) は、入力、内部表現、ツール利用から出力を生成する過程である。この式は、AI の出力を機能的連鎖として扱うためのものであり、ここに悪意や不安や野心を仮定する必要はない。
C_{t+1} = Q(C_t, Y_t, S_t^{soc})
\]
この式で、\(C_{t+1}\) は次の時刻における社会的認知または危機感である。\(C_t\) は現在の社会的認知であり、\(Y_t\) は AI の出力、\(S_t^{soc}\) は社会の自己モデルである。関数 \(Q\) は、AI の出力が社会に受け取られ、報道、企業発信、政府評価、専門家解説、SNS、利用者不安を通じて、次の社会的認知へ変換される過程を表す。ここで主観的に揺れるのは AI ではなく、人間社会である。AI の出力は機能的連鎖として生成されるが、その出力を受け取った人間社会は、不安、期待、警戒、責任追及、制度更新を生じさせる。
| 層 | 数理的表現 | 扱う対象 | 誤って混同すると何が起きるか |
|---|---|---|---|
| AI の機能層 | \(Y_t = F(X_t, K_t, T_t)\) | 入力、内部表現、ツール利用、出力生成。 | AI の出力を悪意や感情の表現として読んでしまう。 |
| 社会の主観層 | \(C_{t+1} = Q(C_t, Y_t, S_t^{soc})\) | 危機感、意味づけ、責任帰属、制度更新。 | 人間社会の不安や責任問題を、AI の内面の問題にすり替えてしまう。 |
この整理により、Claude Mythos 騒動を過剰な擬人化から切り離せる。AI の出力は、機能層では入力、内部表現、ツール、評価の結果である。しかし、その出力は社会の主観層へ入り、人間の不安、期待、責任追及、制度設計を更新する。したがって、問題は AI が「何を感じたか」ではなく、AI の出力によって人間社会が何を感じ、何を意味づけ、何を修正し、誰に責任を割り当てるかである。
この章から次章へ進むために重要なのは、責任主体を AI に置かないことである。AI を怪物化しても、実際の修正責任は消えない。AI を道具として軽視しても、探索能力の社会的影響は消えない。責任主体は、人間、組織、制度、運用である。次章では、この責任帰属の整理を踏まえ、観測能力が上がった社会で、人間がどのように修正責任を引き受けるべきかを具体化する。
24. 修正責任の数理モデル
前章では、AI を過剰に擬人化せず、探索能力、悪用可能性、責任帰属を人間的感情の物語から切り離す必要があると整理した。ここから、観測能力が上がった社会で、人間、組織、制度がどのように修正責任を引き受けるべきかを数理モデルとして表す。ただし、ここでいう責任は、個人や組織を機械的に断罪するための道徳点数ではない。扱うのは、観測された不整合を、誰が、どの範囲で、どの速度で、どの程度修正履歴へ変換する責務を持つかという、修正責任の割当構造である。
まず、責任という語を分解する必要がある。脆弱性対応における責任には、少なくとも四つの層がある。第一に、問題を知り得たかという観測責任である。第二に、実際に修正、隔離、緩和、通知、適用を行えたかという実行責任である。第三に、その判断が利用者や社会へどれほど影響したかという影響責任である。第四に、何を知り、何を判断し、何を行い、何を行わなかったかを説明する説明責任である。これらを区別しないまま「責任がある」とだけ書くと、責任主体が曖昧になり、AI、利用者、ベンダー、保守者、政府、メディアのどこに何を求めているのかが見えなくなる。
| 責任の層 | 意味 | 対応する問い | Claude Mythos 型の問題での例 |
|---|---|---|---|
| 観測責任 | 問題を知り得る立場にあったか。 | その主体は、脆弱性候補、攻撃観測、修正情報、影響範囲を把握できたか。 | ベンダーが報告窓口を持つ、利用組織が資産台帳を持つ、防御者がログを監視する。 |
| 実行責任 | 修正、隔離、緩和、通知、適用を行える立場にあったか。 | その主体は、実際に変更する権限、能力、手段、時間を持っていたか。 | 保守者がパッチを出す、運用者が適用する、クラウド事業者が設定を変更する。 |
| 影響責任 | その主体の判断が他者や社会へどれほど影響したか。 | 放置、遅延、過剰公開、説明不足が、どの範囲に影響したか。 | 広く使われる OSS、重要インフラ、クラウド基盤、認証基盤の判断は影響が大きい。 |
| 説明責任 | 判断過程と対応状況を説明する責務。 | 何を知り、何を確認し、何を直し、何を保留し、なぜそうしたのか説明できるか。 | advisory、CVE、リリースノート、postmortem、利用者通知、監査記録を出す。 |
この分解を踏まえると、各主体 \(i\) の修正責任量を \(D_i\) と置ける。ここで \(D_i\) は、道徳的非難の総量ではなく、観測された不整合を修正履歴へ変換するうえで、その主体にどれだけ責任を割り当てるべきかを表す抽象量である。責任量 \(D_i\) は、観測可能性 \(o_i\)、修正可能性 \(r_i\)、影響範囲 \(s_i\)、対応遅延 \(l_i\)、情報制約 \(c_i\) に依存する。
D_i = \alpha o_i + \beta r_i + \gamma s_i + \delta l_i – \eta c_i
\]
この式で、\(D_i\) は主体 \(i\) の修正責任量である。\(o_i\) は観測可能性であり、その主体が問題を知り得た程度を表す。\(r_i\) は修正可能性であり、その主体が修正、緩和、隔離、通知、適用を行えた程度を表す。\(s_i\) は影響範囲であり、その主体の判断が利用者、依存先、社会基盤へ及ぼす範囲を表す。\(l_i\) は対応遅延であり、発見、報告、修正、通知、適用までに生じた遅れを表す。\(c_i\) は情報制約であり、その主体が十分な情報を得られなかった、権限がなかった、依存関係が不透明だった、更新手段を与えられていなかったといった制約を表す。係数 \(\alpha,\beta,\gamma,\delta,\eta\) は、それぞれの項をどれだけ重く見るかを表す重みである。
| 項 | 意味 | 責任判断での役割 | 具体例 |
|---|---|---|---|
| \(o_i\) | 観測可能性。 | その主体が問題を知り得たなら、放置した場合の責任は重くなる。 | 報告を受けていた、ログに兆候があった、KEV に載っていた、advisory を把握できた。 |
| \(r_i\) | 修正可能性。 | 実際に修正、隔離、緩和、通知、適用できた主体ほど責任は重くなる。 | ベンダーがパッチを作れる、運用者が設定変更できる、利用組織がパッチ適用できる。 |
| \(s_i\) | 影響範囲。 | 判断が広範囲に影響する主体ほど説明責任と修正責任は重くなる。 | 広く使われる OSS、クラウド基盤、OS、認証基盤、重要インフラ。 |
| \(l_i\) | 対応遅延。 | 知っていた、直せた、影響が大きかったにもかかわらず遅れた場合、責任は重くなる。 | 報告後の放置、パッチ公開の遅延、利用者通知の遅延、適用計画の遅延。 |
| \(c_i\) | 情報制約。 | 知らされていない、権限がない、更新手段がない主体に過大な責任を負わせないための補正になる。 | 依存関係が不透明、ベンダー情報が不足、利用環境でパッチが提供されていない。 |
この式の意味は、責任を機械的に計算することではない。むしろ、責任判断で何を見落としてはいけないかを明示することにある。見えていたのに放置した主体、直せたのに直さなかった主体、影響範囲が大きい主体、対応を遅らせた主体は、修正責任が重くなる。一方で、情報を得られなかった主体、修正権限を持たない主体、更新手段を提供されなかった主体、依存関係を外部から把握できなかった主体に、同じ責任を負わせるのは不合理である。
ただし、この線形式には限界がある。現実の責任は、単純な足し算だけでは決まらない。特に重要なのは、観測可能性 \(o_i\) と修正可能性 \(r_i\) が、責任成立の前提条件に近いことである。問題を知ることが原理的に不可能であり、修正する権限も手段もなかった主体に、高い修正責任を課すのは不合理である。逆に、問題を知り得て、修正できて、影響範囲も大きかった主体には、強い修正責任が生じる。この点をより厳密に書くなら、責任量を次のように前提条件付きで表せる。
D_i = g(o_i, r_i) \cdot (\gamma s_i + \delta l_i) – \eta c_i
\]
この式では、\(g(o_i, r_i)\) が観測可能性と修正可能性をまとめた責任成立係数である。\(g(o_i, r_i)\) が小さい場合、その主体は問題を知り得ず、または修正し得なかったため、影響範囲や遅延だけを理由に強い責任を課すべきではない。反対に、\(g(o_i, r_i)\) が大きい場合、その主体は問題を知り得て、かつ対応する能力や権限を持っていたため、影響範囲 \(s_i\) や対応遅延 \(l_i\) が大きいほど責任量 \(D_i\) は増える。
責任成立係数 \(g(o_i, r_i)\) の最小形は、積で表せる。
g(o_i, r_i) = o_i r_i
\]
この式では、観測可能性 \(o_i\) と修正可能性 \(r_i\) の両方が大きいとき、責任成立係数 \(g(o_i, r_i)\) は大きくなる。どちらか一方が小さい場合、責任成立係数は小さくなる。これは直感に合っている。問題を知っていても、修正権限がまったくなければ、直接の修正責任は限定される。修正権限があっても、情報がまったく届かなければ、発見直後の責任は限定される。ただし、後述するように、情報が届かない構造を自ら作っていた場合、その情報制約は単純な免責にはならない。
| 状態 | \(o_i\) | \(r_i\) | \(g(o_i,r_i)\) | 責任判断 |
|---|---|---|---|---|
| 知っていて直せる | 高い。 | 高い。 | 高い。 | 修正責任は重い。遅延や放置の説明が必要になる。 |
| 知っているが直せない | 高い。 | 低い。 | 低いから中程度。 | 直接修正責任は限定されるが、通知、回避策、エスカレーション責任は残る。 |
| 知らないが直せる | 低い。 | 高い。 | 低いから中程度。 | 発見前の責任は限定されるが、観測体制を整える責任は別途問われる。 |
| 知らず直せない | 低い。 | 低い。 | 低い。 | 直接の修正責任は小さい。過大な責任帰属は不合理である。 |
この整理によって、責任を単純な非難ではなく、能力と権限に応じた割当として扱える。たとえば、一般利用者がパッチ情報を知らされず、更新手段も提供されていなかったなら、その利用者に強い修正責任を負わせるのは不合理である。一方、ベンダーが報告を受け、再現でき、修正可能で、利用者への影響が大きいにもかかわらず対応を遅らせたなら、責任量は大きくなる。OSS 保守者の場合はさらに複雑で、修正可能性はあるが人的資源が限られるため、責任は保守者個人だけでなく、依存している企業、ディストリビューション、利用組織、支援制度へ分散する。
ここで、情報制約 \(c_i\) の扱いには注意が必要である。情報制約は、原則として免責方向に働く。知らされていない、見えない、把握できない、権限がない、更新経路がない主体へ、過大な責任を負わせるべきではない。しかし、情報制約がその主体自身の設計や運用の結果として生じている場合、それは単純な免責理由にはならない。たとえば、資産台帳を持たない、依存関係を管理しない、ログを保存しない、パッチ適用計画を持たない、報告窓口を用意しない、SBOM を整備しないといった状態は、情報制約であると同時に、観測責任の不履行でもある。
そのため、情報制約 \(c_i\) は二種類に分ける必要がある。外部制約としての \(c_i^{ext}\) と、自己形成制約としての \(c_i^{self}\) である。
c_i = c_i^{ext} – c_i^{self}
\]
この式で、\(c_i^{ext}\) は主体 \(i\) の外部から与えられた情報制約である。たとえば、ベンダーが詳細を公開していない、上流から情報が届かない、契約上の制約で詳細を得られない、修正パッチがまだ提供されていないといった場合である。これは責任を軽減する方向に働く。一方、\(c_i^{self}\) は主体自身が作った情報制約である。資産管理を怠った、監視を切っていた、依存関係を把握していなかった、報告窓口を放置していた、更新手順を作っていなかったといった場合である。これは本来、免責ではなく責任増加要因として扱うべきである。
| 制約の種類 | 意味 | 責任への影響 | 具体例 |
|---|---|---|---|
| \(c_i^{ext}\) | 主体の外部から与えられた情報制約。 | 責任を軽減する方向に働く。 | ベンダーが詳細を未公開、上流から通知が来ない、修正パッチがまだ存在しない。 |
| \(c_i^{self}\) | 主体自身の設計・運用により生じた情報制約。 | 責任を軽減せず、むしろ観測責任の不履行として責任を増やし得る。 | 資産台帳がない、SBOM がない、ログがない、報告窓口がない、更新手順がない。 |
この区別を入れると、修正責任モデルはより現実に近づく。情報を得られなかった主体を一律に免責するのではなく、なぜ情報を得られなかったのかを見る必要がある。外部から情報が与えられなかったのか。情報を受け取る仕組みを持っていなかったのか。依存関係を把握する努力をしていなかったのか。ログや監査証跡を残していなかったのか。観測能力が上がった社会では、「知らなかった」は常に免責にはならない。「知り得る構造を作っていたか」が問われる。
ここまでを統合すると、より精密な修正責任モデルは次のように書ける。
D_i = o_i r_i(\gamma s_i + \delta l_i) – \eta c_i^{ext} + \theta c_i^{self}
\]
この式では、\(o_i r_i\) が観測可能性と修正可能性を組み合わせた責任成立係数である。\(\gamma s_i + \delta l_i\) は、影響範囲と対応遅延によって責任量が増える部分である。外部情報制約 \(c_i^{ext}\) は、主体の責任を軽減するため、\(- \eta c_i^{ext}\) として引かれる。一方、自己形成情報制約 \(c_i^{self}\) は、主体自身の観測体制不備として責任を増やし得るため、\(+ \theta c_i^{self}\) として加えられる。この式は、単純な非難ではなく、観測可能性、修正可能性、影響範囲、遅延、情報制約の性質を分けて責任を割り当てるための整理式である。
| 式の部分 | 意味 | 責任判断での読み方 |
|---|---|---|
| \(o_i r_i\) | 観測可能性と修正可能性の組み合わせ。 | 知り得て、直し得る主体ほど、修正責任の前提が強くなる。 |
| \(\gamma s_i\) | 影響範囲による加重。 | 影響が広い主体ほど、対応と説明の責任が重くなる。 |
| \(\delta l_i\) | 対応遅延による加重。 | 対応が遅れ、その間に危険窓が広がった場合、責任が重くなる。 |
| \(- \eta c_i^{ext}\) | 外部情報制約による軽減。 | 主体の外部要因により情報や手段が得られなかった場合、責任を軽減する。 |
| \(+ \theta c_i^{self}\) | 自己形成情報制約による加重。 | 情報が見えない構造を自ら作っていた場合、責任を増やす。 |
このモデルを使うと、責任主体ごとの違いも整理できる。AI 提供企業、モデル利用者、脆弱性を含むソフトウェアのベンダー、OSS 保守者、利用組織、クラウド事業者、政府、メディアは、それぞれ \(o_i\)、\(r_i\)、\(s_i\)、\(l_i\)、\(c_i^{ext}\)、\(c_i^{self}\) の値が異なる。したがって、同じ事件に関与していても、同じ責任を負うわけではない。
| 主体 | 主な責任 | 責任が重くなる条件 | 責任が限定される条件 |
|---|---|---|---|
| AI 提供企業 | 能力評価、アクセス制御、監査、危険出力制御、利用規約、報告経路設計。 | 高リスク能力を把握しながら制御せず、危険な文脈へ接続し、監査や停止手段を持たない場合。 | 限定公開、監査ログ、CVD 接続、悪用検知、利用資格管理を整備している場合。 |
| モデル利用者 | 許可された対象で使う、危険出力を悪用しない、発見結果を適切に報告する。 | 無許可対象へ使い、攻撃手順へ接続し、報告せず悪用した場合。 | 権限内で防御目的に使い、再現確認と CVD に接続した場合。 |
| ソフトウェアベンダー | 報告受付、再現確認、修正、advisory、利用者通知、パッチ提供。 | 報告を受けながら放置し、修正可能なのに遅延し、影響範囲を説明しない場合。 | 情報不足や再現困難がありつつも、調査状況と緩和策を適切に共有した場合。 |
| OSS 保守者 | 報告整理、修正判断、リリース、コミュニティ調整。 | 広範に使われる重要プロジェクトで、報告を無視し、修正可能性があるのに放置した場合。 | 人的資源が限られ、利用企業から支援がなく、修正負担が過大な場合。 |
| 利用組織 | 資産把握、影響評価、パッチ適用、回避策、監視、例外管理。 | KEV や advisory を把握できたのに、資産台帳や更新手順の不備で放置した場合。 | ベンダーから情報やパッチが提供されず、現実的な回避策もなかった場合。 |
| 政府・調整機関 | CVD、情報共有、重要インフラ支援、標準化、優先度提示。 | 重大リスクを把握しながら共有や調整を怠り、混乱や遅延を拡大した場合。 | 権限や情報が限定され、民間側から必要情報が提供されなかった場合。 |
| メディア | 事実、推測、宣伝、対策要求を分けて伝える。 | 断片的事実を煽り、能力宣伝や恐怖物語として拡大し、修正行動を妨げた場合。 | 一次情報、制約、対策、専門家解説を整理し、社会的認知を適切に補助した場合。 |
この表が示すように、修正責任は一点に集中しない。AI 提供企業だけが責任を持つわけでも、利用者だけが責任を持つわけでも、ベンダーだけが責任を持つわけでもない。観測能力が上がった社会では、責任は、観測、報告、修正、適用、説明、制度化の連鎖全体に分散する。重要なのは、責任を曖昧に分散させることではなく、それぞれの主体がどの段階で何を引き受けるべきかを明確にすることである。
ここで、前章までの危険窓モデルとも接続できる。ある脆弱性 \(v\) の危険窓は \(W(v)=\max(0,T_p(v)-T_e(v))\) で表された。修正責任モデルでは、各主体の対応遅延 \(l_i\) が、この危険窓を広げる方向に働く。したがって、責任は単なる過去の非難ではなく、危険窓をどの主体のどの遅延が広げたのかを分析する手段でもある。
W(v) = \max(0, T_p(v) – T_e(v))
\]
この式に戻ると、修正責任の焦点は明確になる。\(T_e(v)\) は悪用可能化時刻であり、攻撃者側の速度によって早まる。\(T_p(v)\) は修正適用時刻であり、防御者、ベンダー、保守者、利用組織の処理速度によって早まる。各主体 \(i\) の対応遅延 \(l_i\) が積み重なると、\(T_p(v)\) は遅れ、危険窓 \(W(v)\) は広がる。したがって、修正責任とは、単に「誰が悪いか」を問うことではなく、「誰のどの遅延を短縮すれば、次回の \(W(v)\) を小さくできるか」を問うことである。
| 遅延の種類 | 主な主体 | \(T_p(v)\) への影響 | 短縮する方法 |
|---|---|---|---|
| 報告遅延 | 発見者、AI 利用者、研究者、攻撃観測者。 | ベンダーや保守者が問題を知る時刻が遅れる。 | CVD、報告テンプレート、窓口整備、報告者保護を整える。 |
| 再現遅延 | ベンダー、保守者、セキュリティチーム。 | 修正判断と影響範囲評価が遅れる。 | 再現環境、テスト、ログ、AI 支援解析、報告品質改善を整える。 |
| 修正遅延 | ベンダー、保守者、開発チーム。 | パッチや緩和策の作成が遅れる。 | セキュア開発、CI、レビュー体制、保守者支援、backport 体制を整える。 |
| 配布遅延 | ベンダー、ディストリビューション、クラウド事業者。 | 修正が利用者環境へ届く時刻が遅れる。 | リリース工程、パッケージ配布、advisory、更新チャネルを整える。 |
| 適用遅延 | 利用組織、運用チーム、エンドユーザー。 | 実環境で危険状態が残る。 | 資産管理、パッチ適用計画、再起動計画、例外管理、監視強化を整える。 |
| 説明遅延 | 企業、政府、メディア、調整機関。 | 利用者が適切な判断をできず、対応が遅れる。 | 影響範囲、緩和策、優先度、既知悪用、適用手順を明確に伝える。 |
このように、修正責任は危険窓を短くする責任として定義できる。観測能力が上がると、発見される不整合は増える。しかし、それだけでは安全にはならない。報告、再現、修正、配布、適用、説明の各段階で遅延が生じれば、観測された不整合は修正履歴へ固定されず、攻撃履歴や未処理リスクとして残る。したがって、修正責任とは、観測された不整合を、できるだけ短い危険窓で修正履歴へ変換する責任である。
この章の中心命題は、AI 時代の修正責任とは、AI の出力を誰かの非難材料にすることではなく、観測された不整合を攻撃履歴へ固定される前に修正履歴へ変換するため、各主体の観測可能性、修正可能性、影響範囲、遅延、情報制約に応じて責任を配分することである、という点にある。この命題に立つと、責任論は感情的な犯人探しではなく、次回の危険窓を短くするための制度設計になる。
この章から次章へ進むために重要なのは、修正責任が一度の事件対応では終わらないという点である。観測能力が上がる社会では、脆弱性、不整合、制度欠陥、運用遅延は継続的に見つかる。したがって、修正責任は単発の謝罪やパッチではなく、継続的な観測、優先順位付け、修正、適用、再観測の運用能力として実装されなければならない。次章では、この修正責任を、継続的な社会的更新プロセスとして整理する。
25. 構造振動としての脆弱性対応
前章では、修正責任を、観測可能性、修正可能性、影響範囲、対応遅延、情報制約に応じて配分するモデルとして整理した。そこで見えてきたのは、責任とは単なる非難ではなく、危険窓 \(W(v)\) を短くし、観測された不整合を修正履歴へ変換するための制度設計だという点である。本章では、この責任モデルを構造振動モデルへ接続する。脆弱性対応を構造振動として見るとは、未発見の不整合をゼロにすることではなく、観測された振動を攻撃履歴へ発散させず、修正履歴へ減衰・固定し、構造を次の安定状態へ更新することである。
まず、脆弱性対応における各段階を、構造振動モデルの語彙へ対応させる。未発見欠陥は、構造内部に残る潜在振動である。AI 探索は、その潜在振動の振幅を増幅し、観測可能な差分として取り出す操作である。CVE 付与は、その差分へ社会的に共有可能なラベルを与える観測ラベル化である。パッチは、構造の位相ずれを補正する位相修正である。更新適用は、その修正を実環境の履歴へ固定する操作である。監視は、修正後にも残る残留振動や新たに生じた振動を再観測する操作である。
| 脆弱性対応の段階 | 構造振動モデルでの意味 | 前章までの数理モデルとの対応 | 実務上の意味 |
|---|---|---|---|
| 未発見欠陥 | 潜在振動。 | \(v \in V_t\) | 構造内部に存在するが、まだ処理対象として観測されていない不整合である。 |
| AI 探索 | 振幅増幅。 | \(B_t = O_t(V_t)\) | 潜在的不整合を候補集合として可視化する。 |
| CVE 付与 | 観測ラベル化。 | \(T_d(v)\) 以後の共有可能状態。 | 不整合を、組織や制度が同じ対象として参照できるようにする。 |
| PoC 化・悪用可能化 | 攻撃方向への位相固定。 | \(T_e(v)\) | 観測された不整合が攻撃手順へ接続される。 |
| パッチ作成 | 位相修正。 | \(R_t(O_t(V_t))\) | ずれていた構造関係を補正し、破綻経路を閉じる。 |
| 更新適用 | 修正履歴への固定。 | \(T_p(v)\) | 修正が実環境へ入り、危険窓 \(W(v)\) を閉じる。 |
| 監視・再検証 | 残留振動の再観測。 | \(H_{t+1}\) の評価。 | 修正後の再発、回避、未適用環境、新たな不整合を確認する。 |
この対応関係で重要なのは、脆弱性対応を一回のイベントではなく、振動の処理過程として見る点である。脆弱性は、ある瞬間に突然無から発生するのではない。多くの場合、それは仕様、実装、権限境界、依存関係、設定、運用、互換性、性能最適化、歴史的変更の重なりの中に、潜在的不整合として残っている。その不整合は、通常運用では表面化しないことがある。しかし、AI、人間レビュー、fuzzing、攻撃者の探索、ログ監視によって観測されると、潜在振動は可視化された差分へ変わる。
このとき、AI 探索は単なる発見ではなく、振幅増幅として働く。振幅増幅とは、これまで人間の注意や既存ツールでは小さすぎて見えなかった差分を、意味のある候補として取り出すことである。コード片、コメント、仕様、コミット履歴、既知 CVE、テスト不足、境界条件、権限モデルのわずかなずれが、AI によって結び付けられると、脆弱性候補として立ち上がる。これは防御にとって有用だが、同時に攻撃にも利用され得る。したがって、振幅増幅された差分をどの履歴へ流すかが問題になる。
B_t = O_t(V_t)
\]
この式は、構造内部の潜在振動集合 \(V_t\) が、観測能力 \(O_t\) によって候補集合 \(B_t\) として可視化されることを表す。ここで \(O_t\) は AI だけではない。人間レビュー、静的解析、fuzzing、ログ監視、脅威インテリジェンス、CVD 報告も含む。しかし、Claude Mythos 騒動で問題になっているのは、AI によって \(O_t\) が急激に上がり、従来より多くの潜在振動が短時間で候補化される可能性である。
候補化された \(B_t\) は、そのまま安全にも危険にもならない。防御者へ届き、再現され、優先順位付けされ、パッチや緩和策へ接続されれば、修正履歴へ向かう。攻撃者へ届き、PoC 化され、標的環境へ適用されれば、攻撃履歴へ向かう。メディアや政府発信を通じて増幅されれば、認知履歴や制度履歴へ向かう。放置されれば、未処理振動として残り、次の時刻の残存リスク \(H_{t+1}\) を押し上げる。
| 候補化後の経路 | 振動モデルでの解釈 | 履歴固定 | 結果 |
|---|---|---|---|
| 修正へ接続される | 振動が減衰し、構造が再安定化する。 | 修正履歴。 | 危険窓 \(W(v)\) が短くなり、残存リスク \(H_t\) が下がる。 |
| 攻撃へ接続される | 振動が破壊的に発散する。 | 攻撃履歴。 | 侵害、権限昇格、情報漏洩、業務停止として記録される。 |
| 報道・政治へ接続される | 振動が社会的認知へ伝播する。 | 認知履歴・制度履歴。 | 騒動、規制、企業説明責任、公開方針の変化が生じる。 |
| 放置される | 振動が未処理のまま残る。 | 未処理履歴。 | 将来の攻撃、再発、技術負債、制度不信の材料になる。 |
ここで、24 章の修正責任モデルと接続できる。観測された振動を修正履歴へ流すためには、主体ごとの観測可能性 \(o_i\)、修正可能性 \(r_i\)、影響範囲 \(s_i\)、対応遅延 \(l_i\)、情報制約 \(c_i^{ext}\)、自己形成情報制約 \(c_i^{self}\) を見なければならない。つまり、構造振動は自然に減衰するのではない。誰かが観測し、誰かが分類し、誰かが修正し、誰かが適用し、誰かが説明し、誰かが再観測することで、初めて減衰する。
D_i = o_i r_i(\gamma s_i + \delta l_i) – \eta c_i^{ext} + \theta c_i^{self}
\]
この式は、主体 \(i\) が構造振動の減衰に対してどれだけ修正責任を持つかを表している。観測可能性 \(o_i\) が高く、修正可能性 \(r_i\) が高く、影響範囲 \(s_i\) が大きく、対応遅延 \(l_i\) が長い主体は、振動を放置した場合の責任が重くなる。外部情報制約 \(c_i^{ext}\) は責任を軽減し得るが、自己形成情報制約 \(c_i^{self}\)、つまり資産台帳がない、SBOM がない、ログがない、報告窓口がない、更新手順がないといった状態は、むしろ振動を観測できない構造を自ら作った責任として加算される。
この接続により、修正責任は構造振動の減衰責任として理解できる。責任を持つとは、単に謝罪することではない。潜在振動を観測可能にし、候補を選別し、修正対象へ落とし込み、危険窓を短縮し、修正履歴へ固定し、残留振動を再観測することである。したがって、責任主体は、AI 提供企業、モデル利用者、ベンダー、OSS 保守者、利用組織、クラウド事業者、政府、メディアに分散する。ただし、分散しているから曖昧でよいのではない。各主体が、どの振動をどの段階で減衰させる責任を持つかを明示する必要がある。
この動的過程は、次のように表せる。
S_{t+1} = \operatorname{Stabilize}(S_t, R_t(O_t(V_t)))
\]
この式で、\(S_t\) は時刻 \(t\) における社会技術構造である。\(V_t\) はその内部にある潜在的不整合、すなわち潜在振動の集合である。\(O_t(V_t)\) は、観測能力によって可視化された候補集合である。\(R_t(O_t(V_t))\) は、その候補集合に修正能力が作用し、パッチ、緩和、設定変更、通知、制度更新、テスト追加へ変換される過程である。\(\operatorname{Stabilize}\) は、それらの修正結果を構造に取り込み、次の時刻の構造 \(S_{t+1}\) として再安定化する操作である。
この式で注意すべきなのは、\(S_{t+1}\) が完全な無欠陥状態ではないことである。再安定化とは、すべての振動が消えることではない。観測された振動を処理し、破壊的発散を抑え、次の運用状態へ移ることである。新しい構造 \(S_{t+1}\) には、新しいコード、新しい依存関係、新しい設定、新しい攻撃面、新しい制度的制約が含まれる。そのため、次の時刻には新しい \(V_{t+1}\) が生じ得る。複雑系では、振動が完全に消えることはない。
ここで、安全性の定義を修正する必要がある。従来の直感では、安全とは脆弱性が存在しない状態のように見える。しかし、複雑な社会技術構造では、未発見欠陥、設定差分、依存関係の変化、運用ミス、環境変化、攻撃手法の進化が常に生じる。したがって、安全性とは、振動がゼロになることではない。安全性とは、振動が破壊的発散へ進まず、観測と修正によって許容範囲に減衰することである。
\limsup_{t \to \infty} H_t \leq H_{\mathrm{max}}
\]
この式は、安全性を、残存リスク \(H_t\) が長期的に許容上限 \(H_{\mathrm{max}}\) を超え続けない状態として表している。\(\limsup\) は、時間が進んだ先での上側の限界を意味する。ここで言いたいのは、一時的にリスクが上がることが絶対にない、ということではない。新しい脆弱性が発見されれば \(H_t\) は一時的に上がる。攻撃観測や PoC 公開があれば、社会的緊張も上がる。しかし、観測、修正、適用、再観測の仕組みが機能していれば、残存リスクは許容範囲へ戻る。安全性とは、この復元力を持つことである。
| 状態 | 振動モデルでの意味 | セキュリティ上の意味 | 望ましい対応 |
|---|---|---|---|
| 安定振動 | 振動は存在するが、許容範囲内に収まっている。 | 脆弱性は見つかるが、修正と適用が追いついている。 | 継続監視、定期更新、通常のパッチ運用を維持する。 |
| 増幅振動 | 観測能力の上昇により、候補が急増する。 | AI 探索、fuzzing、スキャンにより、未処理指摘が増える。 | トリアージ、優先順位付け、誤検知除去、修正能力の増強を行う。 |
| 発散振動 | 修正より攻撃や混乱への接続が速い。 | PoC 公開、悪用、パッチ遅延、報道増幅により危険窓が広がる。 | CVD、緊急緩和、隔離、監視強化、説明、適用支援を行う。 |
| 減衰振動 | 観測された不整合が修正履歴へ流れていく。 | パッチ、設定変更、ロールバック、監視追加により残存リスクが下がる。 | 修正適用を完了し、再発防止と再観測を行う。 |
| 残留振動 | 修正後にも未適用環境、派生問題、制度的遅延が残る。 | エヌデイ攻撃、未更新環境、例外管理、レガシー資産が残る。 | 例外管理、資産棚卸し、長期的廃止計画、監視を続ける。 |
この表により、構造振動モデルは抽象論ではなく、実務の状態分類として使える。AI によって観測能力が上がると、増幅振動が生じる。候補が増え、報告が増え、脆弱性情報が増え、社会的認知も上がる。この段階で修正能力が追いつかなければ、振動は発散し、攻撃履歴、未処理 backlog、騒動、制度不信へつながる。逆に、トリアージ、CVD、パッチ、適用、監視が機能すれば、振動は減衰し、構造は再安定化する。
この対応関係は、ソフトウェアだけでなく社会制度にも当てはまる。制度もまた、観測された不整合を取り込み、自分のルール、期限、予算、役割分担、説明手順を更新することで安定化する。たとえば、CVD が機能しなければ、発見者とベンダーの間で情報が滞留する。CVE や KEV の優先度付けが不十分なら、利用組織は何から直すべきか分からない。SBOM や資産台帳がなければ、影響範囲が見えない。パッチ適用運用が弱ければ、修正済みのはずの問題が現場では残り続ける。これらはすべて、制度側の残留振動である。
| 制度上の不整合 | 構造振動モデルでの見方 | 社会的リスク | 再安定化の方向 |
|---|---|---|---|
| 報告窓口がない。 | 観測された振動を受け取る経路がない。 | 発見者が報告できず、公開や悪用へ流れやすい。 | CVD 窓口、security policy、報告テンプレートを整える。 |
| 資産台帳がない。 | 振動が自組織に届いているか判定できない。 | 該当有無の判断が遅れ、適用漏れが起きる。 | 資産管理、SBOM、依存関係管理を整える。 |
| パッチ適用手順がない。 | 位相修正を履歴固定できない。 | パッチは存在しても、現場の危険窓が閉じない。 | 適用計画、再起動計画、ロールバック、例外管理を整える。 |
| 説明責任が曖昧である。 | 認知振動が整理されず、騒動として増幅する。 | 利用者が判断できず、不安、誤解、過剰反応が増える。 | 影響範囲、緩和策、優先度、既知悪用状況を明示する。 |
| 保守者支援が不足している。 | 修正振動を減衰させる能力が足りない。 | 広く使われる OSS の修正が遅れ、社会的危険窓が広がる。 | 資金、人員、企業支援、レビュー体制、長期保守体制を整える。 |
この制度側への拡張によって、Claude Mythos 騒動の本質がさらに明確になる。AI による弱点探索は、単にコードの潜在振動を増幅するだけではない。社会制度の潜在振動も増幅する。どこに報告すればよいのか。誰が受け取るのか。どの程度公開するのか。どの環境へ適用するのか。誰が説明するのか。どこまで AI に任せ、どこから人間が判断するのか。これらの問いが一斉に表面化する。つまり、AI が照らすのはソフトウェアの不整合だけではなく、制度の不整合でもある。
この章の中心命題は、脆弱性対応を構造振動として見るとは、未発見の不整合をゼロにすることではなく、観測された振動を攻撃履歴へ発散させず、修正履歴へ減衰・固定し、構造を次の安定状態へ更新することだ、という点にある。これにより、安全性は静的な無欠陥状態ではなく、観測、削減、修正、履歴固定、再観測を継続する動的安定性として理解される。
この章から次章へ進むために重要なのは、構造振動モデルが単なる説明枠組みではなく、運用原則へ変換できるという点である。振動があるなら、観測しなければならない。観測したなら、削減しなければならない。削減したなら、修正へ接続しなければならない。修正したなら、履歴固定しなければならない。履歴固定したなら、残留振動を再観測しなければならない。次章では、この構造振動モデルから、AI 時代の社会が採るべき実務的な運用原則を整理する。
26. 実務へ落とすと何をすべきか
前章では、脆弱性対応を構造振動として捉え、未発見の不整合をゼロにすることではなく、観測された振動を攻撃履歴へ発散させず、修正履歴へ減衰・固定し、構造を次の安定状態へ更新することが重要だと整理した。本章では、この抽象モデルを実務へ落とす。ここで確認すべきなのは、実務対策の中心が AI 導入そのものではないという点である。AI は観測能力を上げる。しかし、AI が上げるのは主に \(O_t\)、すなわち潜在的不整合を候補として見つける能力である。発見された候補を評価し、優先順位を付け、修正し、配布し、適用し、再観測する能力 \(R_t\) が弱ければ、AI は安全性を高めるどころか、未処理候補、現場疲弊、誤検知、過剰反応、責任不明瞭化を増やす。
したがって、AI 時代の実務対策の中心は、AI を導入することではなく、観測された不整合を短い危険窓で修正履歴へ変換できる更新可能性を組織に実装することである。この中心命題を外すと、対策は簡単にずれる。AI ツールを入れたが、資産台帳がない。脆弱性候補は増えたが、誰が見るのか決まっていない。CVE は監視しているが、自組織に該当するか分からない。パッチは出ているが、再起動できない。PoC は確認したが、CVD の経路がない。これでは、観測能力だけが上がり、修正能力が追いつかない状態になる。
| 実務領域 | 構造振動モデルでの意味 | 目的 | 失敗した場合 |
|---|---|---|---|
| 資産管理 | どの構造が存在するかを把握する。 | 脆弱性情報が自組織に関係するか判断できるようにする。 | CVE や advisory が出ても該当有無を判断できない。 |
| 依存関係管理 | 構造間の接続を把握する。 | 上流、下流、ライブラリ、コンテナ、パッケージの影響を追えるようにする。 | 自分で書いていない部品の脆弱性が見えない。 |
| 観測 | 潜在振動を候補として可視化する。 | AI 支援レビュー、fuzzing、静的解析、ログ監視で未発見不整合を見つける。 | 攻撃者が先に観測し、攻撃履歴へ固定される。 |
| トリアージ | 観測された振動を処理可能な対象へ削減する。 | 重大度、悪用可能性、露出面、資産重要度から優先順位を決める。 | 未処理指摘が積み上がり、重大問題が埋もれる。 |
| 修正 | 位相ずれを補正する。 | パッチ、設定変更、隔離、緩和策、設計変更で破綻経路を閉じる。 | 発見だけ増え、危険窓 \(W(v)\) が閉じない。 |
| 適用 | 修正を履歴へ固定する。 | 本番環境へ反映し、危険状態を実際に閉じる。 | パッチは存在しても、現場では未修正のまま残る。 |
| 再観測 | 残留振動を確認する。 | 修正漏れ、未適用環境、回避、再発、派生問題を検出する。 | 修正済みと思い込んだまま、エヌデイ攻撃を受ける。 |
第一に行うべきことは、重要資産と露出面の整理である。これは、セキュリティ対策の基本であると同時に、構造振動モデルでいえば、対象構造 \(S_t\) を定義する作業である。何を守るのか、どこが外部へ開いているのか、どのシステムが認証、決済、顧客情報、業務継続、管理権限を担っているのかを把握しなければ、脆弱性情報を受け取っても優先順位を決められない。すべてを同じ重要度で扱う組織は、結局、何も優先できない。
| 確認項目 | 見るべき内容 | 実務上の判断 |
|---|---|---|
| 重要資産 | 認証基盤、管理画面、顧客情報、決済、業務停止時に影響が大きいシステム。 | 重要資産に関係する脆弱性は、CVSS だけでなく業務影響で優先度を上げる。 |
| 外部露出 | インターネット公開、VPN、リモート管理、API、メール、ファイル共有、CI/CD。 | 外部から到達可能な脆弱性は、危険窓を短くする必要がある。 |
| 権限境界 | 管理者権限、setuid、クラウド IAM、サービスアカウント、sudo、秘密情報。 | 権限昇格や境界突破につながる問題は、局所不具合として軽視しない。 |
| 業務停止許容度 | 再起動可能時間、メンテナンス窓、停止時影響、代替手段。 | パッチ適用の遅延要因になるため、事前に停止計画を持つ。 |
| 管理責任者 | システム所有者、運用担当、開発担当、セキュリティ担当、意思決定者。 | 責任者が不明な資産は、脆弱性対応で必ず滞留する。 |
第二に、SBOM と依存関係を整備する必要がある。AI が脆弱性候補を見つけても、自組織がその部品を使っているか分からなければ意味がない。依存関係が分からない組織では、CVE、KEV、ベンダーアドバイザリ、ディストリビューション情報が入ってきても、影響範囲評価が遅れる。これは、24 章で述べた自己形成情報制約 \(c_i^{self}\) に当たる。つまり、情報が見えないことは常に免責ではない。見える構造を作っていなかった責任が問われる。
| 管理対象 | 具体例 | 目的 | 最低限の運用 |
|---|---|---|---|
| OS とパッケージ | Debian、Ubuntu、RHEL、AlmaLinux、コンテナベースイメージ、apt、dnf、pip、npm、gem。 | ディストリビューションやパッケージ単位の脆弱性影響を判断する。 | バージョン、リポジトリ、サポート期限、更新状況を一覧化する。 |
| アプリケーション依存関係 | ライブラリ、フレームワーク、プラグイン、WordPress テーマ、CI/CD ツール。 | 上流脆弱性が自アプリケーションへ影響するか判断する。 | 依存ロックファイル、SBOM、更新履歴を保存する。 |
| コンテナとイメージ | ベースイメージ、ミドルウェア、ランタイム、ビルド成果物。 | イメージ内に含まれる古い部品や既知脆弱性を追跡する。 | ビルド時点、ベースイメージ、再ビルド手順を管理する。 |
| クラウド設定 | IAM、セキュリティグループ、公開バケット、KMS、監査ログ、マネージドサービス。 | コード以外の構成不備を脆弱性として扱えるようにする。 | IaC 化、設定差分レビュー、権限棚卸しを行う。 |
| レガシー資産 | 古い OS、保守切れミドルウェア、更新不能アプリケーション、属人運用。 | 修正できない構造を例外管理し、隔離または廃止計画へつなげる。 | 例外期限、補完統制、廃止予定、責任者を明記する。 |
第三に、KEV、CVE、NVD、CVSS、ベンダーアドバイザリ、ディストリビューション情報を監視する。ただし、監視は「情報を購読している」だけでは足りない。重要なのは、自組織の資産、露出面、業務重要度へ結び付けることである。CVSS が高くても該当資産がなければ優先度は下がる。CVSS が中程度でも、外部公開された重要資産に存在し、PoC があり、KEV に載り、パッチ適用が遅れているなら優先度は上がる。指標は判断を置き換えるものではなく、判断を開始する座標である。
| 情報源 | 見る目的 | 実務上の使い方 | 注意点 |
|---|---|---|---|
| KEV | 既に悪用が確認された脆弱性を把握する。 | 該当資産があれば優先対応候補にする。 | KEV にないから安全とは限らない。 |
| CVE | 脆弱性の共通識別子を把握する。 | ベンダー情報、パッチ、検知ルール、資産台帳と紐付ける。 | CVE 番号だけでは深刻度や自組織影響は決まらない。 |
| NVD / CVSS | 標準化された説明と深刻度の目安を得る。 | 初期トリアージの参考にする。 | 自組織の露出面、補完統制、業務重要度で補正する。 |
| ベンダーアドバイザリ | 製品固有の影響、回避策、修正バージョンを確認する。 | 実際の適用判断に使う。 | ベンダーの説明は過不足があり得るため、必要に応じて検証する。 |
| ディストリビューション情報 | OS やパッケージの backport、修正済みバージョンを確認する。 | ソースバージョンだけでなく、配布元の修正状況を見る。 | 上流バージョンとディストリビューションの修正状態は一致しないことがある。 |
第四に、AI 支援レビューや fuzzing を導入する。ただし、これは「AI に脆弱性を全部探してもらう」という意味ではない。AI は、人間の注意が届きにくいコード、仕様差分、境界条件、古い互換経路、エラー処理、設定の不整合を洗い出す補助として使うべきである。fuzzing は、入力空間や異常経路を機械的に揺さぶり、実行時の不整合を見つける。静的解析は、既知パターンや危険 API の使用を広く拾う。AI は、それらの結果を要約し、再現手順や修正候補を整理し、コードレビューの観点を増やす。重要なのは、これらを単独ツールとして使うのではなく、トリアージと修正工程へ接続することである。
| 観測手段 | 向いている対象 | 得られるもの | 接続すべき次工程 |
|---|---|---|---|
| AI 支援コードレビュー | 仕様差分、境界条件、例外処理、権限判断、複雑な実装。 | 脆弱性候補、設計上の疑問、テスト観点、修正案。 | 人間レビュー、再現確認、テスト追加、パッチ作成。 |
| fuzzing | 入力処理、パーサー、プロトコル処理、画像・圧縮・暗号関連処理。 | クラッシュ、未定義動作、境界条件不備、異常経路。 | 最小再現、原因分析、回帰テスト、修正。 |
| 静的解析 | 危険 API、型不整合、メモリー安全性、認証・認可漏れ、設定ミス。 | 広範囲の候補とパターン検出。 | 誤検知除去、優先順位付け、セキュアコーディング改善。 |
| 依存関係スキャン | OSS ライブラリ、パッケージ、コンテナ、プラグイン。 | 既知脆弱性、更新候補、保守切れ部品。 | 更新計画、互換性検証、例外管理、廃止計画。 |
| ログ監視 | 攻撃試行、異常アクセス、権限昇格、失敗ログ、WAF・EDR イベント。 | 実際の悪用兆候、攻撃観測、環境固有リスク。 | 隔離、検知ルール調整、インシデント対応、事後分析。 |
第五に、見つかった指摘を放置せず、トリアージ、修正、リリース、再起動、監視までの経路を短くする必要がある。ここが実務上の核心である。AI によって候補が増えると、組織は「見つかったものをどう扱うか」で詰まる。重大度が曖昧な指摘、再現できない報告、影響範囲が不明な CVE、パッチはあるが適用できないシステム、再起動できない本番環境、担当者不在の古いシステムが積み上がる。これを避けるには、候補が出た後の流れを標準化する必要がある。
| 工程 | 目的 | 判断項目 | 出力物 |
|---|---|---|---|
| 受付 | 脆弱性候補やアラートを処理対象として登録する。 | 報告元、対象資産、再現情報、既知 CVE、添付情報。 | チケット、issue、インシデント候補、調査タスク。 |
| 一次判定 | 明らかな誤検知、重複、対象外を除く。 | 該当資産の有無、バージョン、露出面、既知修正状況。 | 棄却、保留、調査継続、緊急対応候補。 |
| 影響評価 | 自組織での実際の危険度を決める。 | 悪用可能性、権限、データ影響、外部露出、補完統制、KEV 掲載。 | 優先度、期限、関係者、暫定緩和策。 |
| 修正計画 | 危険窓を閉じる手順を決める。 | パッチ可用性、互換性、テスト、再起動、ロールバック、例外。 | 適用計画、変更申請、テスト計画、ロールバック計画。 |
| 適用 | 修正を実環境へ反映する。 | 作業時間、依存サービス、監視、利用者影響。 | 適用記録、変更履歴、再起動記録、確認結果。 |
| 再観測 | 危険窓が閉じたか確認する。 | バージョン確認、設定確認、スキャン再実行、ログ監視、検知ルール。 | 完了判定、残課題、例外登録、再発防止策。 |
第六に、公開前調整と利用者通知を制度化する。AI 支援探索で脆弱性候補が見つかるほど、公開の扱いが重要になる。未修正の詳細を不用意に広く出せば、攻撃者へ先に届く。逆に、利用者へ必要な情報を出さなければ、利用者はパッチ適用や回避策を判断できない。したがって、公開は、隠すか全部出すかの二択ではない。発見者、ベンダー、保守者、利用組織、調整機関が、誰に、いつ、どの粒度で、何を伝えるかを設計する必要がある。
| 公開・通知項目 | 含めるべき内容 | 含め方の注意 |
|---|---|---|
| 影響範囲 | 対象製品、対象バージョン、対象構成、影響を受ける条件。 | 利用者が自環境の該当有無を判断できる粒度にする。 |
| 深刻度 | CVSS、悪用可能性、権限、到達性、データ影響、既知悪用状況。 | 数値だけでなく、実務上の優先度判断を補助する説明を入れる。 |
| 修正方法 | 修正バージョン、パッチ、設定変更、回避策、再起動要否。 | 適用手順が曖昧だと、利用者側の \(T_p(v)\) が遅れる。 |
| 緩和策 | 一時的な無効化、アクセス制限、監視強化、WAF ルール、権限削減。 | パッチ適用までの危険窓を短縮するために使う。 |
| 検知方法 | ログ指標、IoC、攻撃試行の特徴、監視すべきイベント。 | 過度に攻撃手順を詳述せず、防御に必要な観測情報を出す。 |
| 公開範囲 | 限定共有、関係者共有、一般公開、段階的公開。 | 修正前の詳細公開が攻撃履歴へ流れないよう調整する。 |
第七に、パッチ適用を通常業務として扱う。観測能力が上がる社会では、脆弱性対応は例外的な緊急作業ではなくなる。毎月、毎週、場合によっては毎日、何らかの更新判断が必要になる。したがって、更新は「時間があるときにやる作業」ではなく、システム運用の中核業務である。再起動できない本番環境、検証環境のないサービス、属人化した変更手順、ロールバックできない構成は、すべて修正責任を阻害する構造的問題である。
| 更新可能性の要素 | 必要な実務 | 欠けた場合の問題 |
|---|---|---|
| 検証環境 | 本番に近い環境でパッチ、設定変更、依存更新を試せるようにする。 | 更新のたびに本番障害を恐れ、適用が遅れる。 |
| 再起動計画 | メンテナンス窓、冗長化、停止影響、利用者通知を事前に決める。 | カーネル、ミドルウェア、ランタイム更新が長期間残る。 |
| ロールバック | 更新後に問題が出た場合、戻せる手順を用意する。 | 失敗時の恐怖が強くなり、更新を避ける文化になる。 |
| 例外管理 | 更新できない資産には期限、補完統制、廃止予定を付ける。 | 「今は無理」が永久例外になり、残留振動が蓄積する。 |
| 変更履歴 | 何を、いつ、誰が、なぜ変更したかを記録する。 | 再発時に原因追跡できず、同じ問題を繰り返す。 |
第八に、AI 支援を入れる場合は、利用範囲、権限、ログ、レビュー、人間判断を明確にする。AI にコード、ログ、設定、脆弱性情報を与えるなら、その入力自体が機密情報を含み得る。AI に実行環境やネットワーク到達性を与えるなら、防御支援と攻撃支援の境界が曖昧になり得る。AI に修正案を出させるなら、その修正が本当に正しいか、人間が検証しなければならない。AI は候補生成と整理を速くするが、責任判断を代替しない。
| AI 利用設計 | 決めるべきこと | 理由 |
|---|---|---|
| 対象範囲 | どのリポジトリ、どの環境、どのログ、どの設定を AI に扱わせるか。 | 機密情報や対象外システムへの不適切なアクセスを防ぐため。 |
| 実行権限 | AI がコマンド実行、スキャン、外部通信、ファイル変更をできるか。 | 観測支援が攻撃支援や破壊的変更へ転じないようにするため。 |
| 出力制御 | PoC、exploit、検知回避、詳細手順をどの粒度で扱うか。 | 防御に必要な情報と悪用容易化の境界を管理するため。 |
| 監査ログ | 誰が、いつ、何を入力し、AI が何を出したかを記録する。 | 責任追跡、再検証、誤出力対応、悪用検知のため。 |
| 人間レビュー | AI の指摘、修正案、影響評価、公開判断を誰が確認するか。 | AI の誤検知、過信、危険な提案をそのまま運用へ入れないため。 |
第九に、責任分担を文書化する必要がある。脆弱性対応で最も危険なのは、「誰かが見ているはず」「誰かが適用するはず」「誰かが通知するはず」という状態である。観測能力が上がるほど、候補は増える。候補が増えるほど、責任境界が曖昧な組織では滞留が増える。したがって、発見、受付、判断、修正、適用、通知、説明、再観測の各工程について、責任者と期限を決める必要がある。
| 工程 | 責任者を決める理由 | 決めるべき内容 |
|---|---|---|
| 発見・受付 | 報告が迷子になると \(T_d(v)\) から対応開始までが遅れる。 | 窓口、チケット化手順、一次対応者、営業時間外対応。 |
| 影響評価 | 自組織影響が決まらないと優先順位を付けられない。 | 評価担当、資産照合方法、緊急度基準、期限。 |
| 修正判断 | 修正、緩和、受容、例外の判断には責任が必要である。 | 意思決定者、承認フロー、リスク受容基準。 |
| 適用作業 | パッチが存在しても適用されなければ \(T_p(v)\) は到来しない。 | 作業者、作業手順、メンテナンス窓、ロールバック。 |
| 通知・説明 | 利用者や関係者が判断できなければ、対応が遅れる。 | 通知先、内容、タイミング、問い合わせ対応。 |
| 再観測 | 修正完了を確認しなければ、残留振動が残る。 | 確認方法、スキャン、ログ監視、例外リスト更新。 |
第十に、運用指標を持つべきである。実務では、「ちゃんとやっている」という主観ではなく、危険窓を短くできているかを測る必要がある。測るべきものは、発見数そのものではない。AI を入れれば発見数は増えるかもしれないが、それは安全性向上を意味しない。重要なのは、発見から一次判定までの時間、一次判定から修正判断までの時間、修正判断から適用までの時間、適用後の再観測完了率、例外の期限管理、重大脆弱性の未処理数である。
| 指標 | 測るもの | 改善したい構造 |
|---|---|---|
| 受付までの時間 | 脆弱性情報や AI 指摘が処理対象になるまでの時間。 | 報告遅延、窓口不備、チケット化漏れを減らす。 |
| 一次判定までの時間 | 該当有無、重複、誤検知、対象外を判定するまでの時間。 | 未処理候補の滞留を減らす。 |
| 修正判断までの時間 | 修正、緩和、例外、受容を決めるまでの時間。 | 責任者不在や判断停止を減らす。 |
| 適用完了までの時間 | パッチや緩和策が本番環境へ反映されるまでの時間。 | \(T_p(v)\) を早め、危険窓 \(W(v)\) を短くする。 |
| 再観測完了率 | 修正後に本当にリスクが下がったか確認した割合。 | 修正漏れ、未適用環境、残留振動を減らす。 |
| 期限切れ例外数 | 例外扱いのまま期限を過ぎた脆弱性や資産の数。 | 永久例外化とレガシー残留を防ぐ。 |
このように実務へ落とすと、Claude Mythos 騒動から得るべき教訓は明確になる。AI を恐れるだけでは足りない。AI を導入するだけでも足りない。AI によって観測能力が上がるなら、組織はその観測結果を受け取る構造、評価する構造、修正する構造、適用する構造、説明する構造、再観測する構造を持たなければならない。これはセキュリティ部門だけの問題ではない。開発、運用、法務、広報、経営、調達、利用部門が関わる更新可能性の問題である。
したがって、この章の中心命題は、AI 時代の実務対策の中心は AI 導入ではなく、観測された不整合を短い危険窓で修正履歴へ変換できる更新可能性を組織に実装することだ、という点にある。AI を入れても、古い構成が残り、再起動できず、検証環境がなく、依存関係が不明で、責任者が曖昧で、公開前調整も利用者通知も制度化されていないなら、安全性は上がらない。AI は観測能力を上げるが、修正責任を代替しない。
この章から次章へ進むために重要なのは、実務原則が最終的に人間の判断へ戻るという点である。AI は候補を出し、情報を整理し、修正案を支援できる。しかし、何を重要資産と見るか、どの危険を許容しないか、どの順序で直すか、どこまで公開するか、どの例外を認めるか、どの制度を変えるかは、人間と組織が決める。次章では、この実務原則を踏まえ、Claude Mythos 騒動を封印された怪物の物語ではなく、人間の修正責任を再設計する出来事として最終評価する。
27. 冷静な判断
前章では、AI 時代の実務対策の中心が、AI 導入そのものではなく、観測された不整合を短い危険窓で修正履歴へ変換できる更新可能性を組織に実装することだと整理した。本章では、ここまでの議論を踏まえ、Claude Mythos 騒動に対して冷静な判断を下す。冷静に判断すれば、Claude Mythos 騒動は、封印された怪物が世界を壊し始めた話ではない。より正確には、人間社会が作ってきた巨大なソフトウェア構造の潜在的不整合を、AI がより速く、広く、低コストで照らし始めた話である。その光は攻撃者にも防御者にも届く。だから危険であり、同時に有用である。
この判断で最初に避けるべきなのは、二つの単純化である。一つは、AI を悪意ある主体や封印された怪物として描く単純化である。AI が脆弱性候補を出すとき、そこに不安、敵意、野心、好奇心があると考える必要はない。あるのは、入力、内部表現、探索、推論、ツール利用、出力、評価の連鎖である。もう一つは、AI を単なる道具だから問題ないとする単純化である。道具であっても、弱点探索のコストを下げ、発見速度を上げ、攻撃者と防御者の行為可能性を変えるなら、社会的影響は大きい。したがって、冷静な判断は、擬人化による恐怖と、道具論による過小評価の両方を退けるところから始まる。
| 態度 | 一見もっともらしい点 | 見落とすもの | 本稿で採る判断 |
|---|---|---|---|
| 怪物化 | 危険性を強く伝えられる。 | 能力、アクセス制御、修正経路、責任主体の具体的設計が見えなくなる。 | AI の内面ではなく、AI の観測能力がどの履歴へ流れるかを見る。 |
| 全面禁止 | 危険な利用を抑える方針に見える。 | 防御者側の観測能力、早期修正、CVD 接続、研究利用まで失われる。 | 能力の種類、利用者、対象、権限、公開範囲ごとに制御する。 |
| 無邪気な解放 | 技術発展と防御利用を促進できる。 | 攻撃者への能力移転、PoC 化、検知回避、未修正利用者への危険を軽視する。 | 防御利用を促進しつつ、危険出力と高リスク文脈を管理する。 |
| 冷笑 | メディア誇張や企業宣伝を相対化できる。 | 誇張を取り除いた後に残る実務的リスクまで軽視する。 | 騒動強度と実技術リスクを分け、残るリスクを処理する。 |
| 実務的判断 | 能力、制度、運用、責任を分けて扱える。 | 単純な物語にはなりにくい。 | 観測能力を修正能力へ接続し、危険窓を短くする。 |
GPT-2 の段階的公開との連続性も、この冷静な判断を支える。GPT-2 で問題になったのは、自然文生成能力が情報環境の処理能力を上回る可能性だった。Claude Mythos 騒動で問題になっているのは、脆弱性探索能力がセキュリティ制度と運用の処理能力を上回る可能性である。対象は偽情報からサイバー探索へ移ったが、構造は似ている。能力そのものより、公開された能力が社会の受容、評価、制御、修正の速度を超えるかどうかが問題なのである。したがって、公開をめぐる判断は、単に「出すか出さないか」ではなく、「どの能力を、誰へ、どの権限で、どの監査と修正経路に接続して出すか」として設計しなければならない。
ゼロデイについても、冷静な判断が必要である。個別のゼロデイは、確かに一回限りのカードに近い。発見され、公表され、修正され、検知されれば、その特定経路の価値は下がる。しかし、AI によって変わるのは、個別カードの価値だけではない。変わるのは、カードを見つけるプロセスである。個別ゼロデイの寿命は短くなり、継続探索能力の価値が上がる。したがって、恐れるべきなのは特定の一件だけではなく、発見、悪用、修正、適用の速度差である。防御側が発見と修正を先行させれば安全性は上がり、攻撃側が悪用を先行させれば危険窓は広がる。
CVE-2026-31431 のような事例が示したのは、単なる「危険なバグ」の存在ではなく、意味境界の破綻である。読み取り可能なもの、書き込み可能なもの、ページキャッシュ、暗号 API、ゼロコピー、setuid バイナリ、ファイル完全性検査、実行時状態といった複数の意味境界が、特定条件で接続されると、局所的には正当に見える処理の合成が、全体として不正な経路を生む。AI の弱点探索が強くなると、このような合成境界の破綻がより見つかりやすくなる。ここから言えるのは、ソフトウェアの安全性を個々の部品の正しさだけで保証する時代はさらに難しくなる、ということである。境界、接続、履歴、実行時状態を含めて見る必要がある。
| ここまでの論点 | 冷静な評価 | 実務上の帰結 |
|---|---|---|
| GPT-2 との連続性 | 能力公開が社会の処理速度を超えるかが問題である。 | 公開範囲、アクセス制御、評価、監査、段階的展開を設計する。 |
| ゼロデイ | 個別カードより、発見プロセスと速度差が重要になる。 | 発見から修正適用までの危険窓 \(W(v)\) を短くする。 |
| CVE-2026-31431 | 複数構造の意味境界が接続点で破綻する事例として読む。 | 局所仕様だけでなく、実行時状態、権限、キャッシュ、運用を含めて検証する。 |
| 悪意ある利用 | 攻撃意図ではなく、探索コストと手順化コストが下がる。 | 高リスク出力、ツール権限、対象範囲、利用資格を管理する。 |
| 防御側利用 | AI は未発見不整合を早く見つける防御手段にもなる。 | AI 支援レビュー、fuzzing、静的解析をトリアージと修正工程へ接続する。 |
| メディア誇張 | 騒動強度と実技術リスクは一致しない。 | 事実、推測、宣伝、対策要求を分けて読む。 |
| 構造振動モデル | 脆弱性は潜在的不整合振動であり、AI はそれを増幅する観測器である。 | 観測された振動を攻撃履歴へ発散させず、修正履歴へ減衰させる。 |
この表から分かるように、Claude Mythos 騒動の本質は、AI が突然外部から危険を持ち込んだことではない。危険の多くは、もともとソフトウェア、制度、運用、依存関係、公開規範、責任分担の中に潜在していた。AI はそれを速く見つけ、広く候補化し、説明し、手順化し、場合によっては攻撃にも修正にも接続できるようにした。したがって、AI を止めれば根本問題が消えるわけではない。逆に、AI を無制限に使えば安全になるわけでもない。必要なのは、AI によって増幅された観測能力を、人間社会の修正能力へ接続することである。
この点で、メディアや企業発信、政府発信の強い言葉は慎重に扱う必要がある。強い言葉は、危機感を形成し、予算を動かし、規制や対策を促す力を持つ。一方で、強い言葉は、能力宣伝、政治的主張、企業イメージ、読者獲得、政策誘導の道具にもなる。したがって、騒動を読むときは、「何が観測された事実か」「何が推測か」「何が能力宣伝か」「何が安全対策か」「何が規制要求か」を分けなければならない。騒ぎが誇張されているから無視してよいのではない。誇張を取り除いた後に残る実務的リスクを処理することが重要である。
この判断は、16 章で扱った社会的認知モデルとも接続する。騒動強度 \(C_t\) は、実技術リスク \(H_t\) に増幅係数やノイズが重なって形成される。したがって、社会が強く反応しているからといって、常に技術リスクが同じ強さで存在するとは限らない。しかし、社会が反応していること自体は、制度、投資、公開方針、利用者判断を変える実在的要因である。冷静な判断とは、騒動を笑い飛ばすことではなく、騒動の中から実技術リスクと制度課題を分離することである。
構造振動モデルで言えば、Claude Mythos 騒動は、潜在振動の増幅イベントである。ソフトウェア内部の不整合だけでなく、社会制度の不整合も増幅された。どのモデルを公開するのか。誰に使わせるのか。どの出力を制限するのか。防御研究へどう接続するのか。発見された脆弱性をどの CVD 経路へ流すのか。利用者へどの粒度で通知するのか。メディアはどこまで説明するのか。企業は能力宣伝と安全説明をどう分けるのか。これらの問いが同時に立ち上がった。その意味で、この騒動は AI の危険性だけでなく、人間社会の制度的未整備も照らした。
ここで採るべき態度は、過剰な禁止でも、無邪気な解放でもない。能力を評価し、アクセスを制御し、開示を調整し、修正速度を上げ、運用の更新可能性を高めることである。危険な能力を誰にでも無制限に渡すべきではない。しかし、防御者がその能力を使えない状態にしても、攻撃者だけが非公式に利用する非対称性が残る。したがって、必要なのは、能力を防御文脈へ流し、攻撃文脈へ流れにくくする制度設計である。具体的には、利用者資格、対象範囲、監査ログ、CVD 接続、危険出力制御、人間レビュー、修正工程への接続が必要になる。
| 判断対象 | 避けるべき極端 | 現実的な判断 | 目標 |
|---|---|---|---|
| モデル公開 | 全面封印または全面解放。 | 能力、利用者、対象、権限、監査に応じた段階的公開。 | 防御利用を可能にしつつ、悪用容易化を抑える。 |
| AI 支援探索 | 禁止または無制限利用。 | 許可された対象、明確な権限、ログ、レビュー、報告経路を持たせる。 | 観測能力を修正工程へ接続する。 |
| 脆弱性情報公開 | 詳細隠蔽または即時全面公開。 | 修正状況、利用者保護、攻撃容易性を見て段階的に共有する。 | 攻撃履歴へ流れる前に修正履歴へ固定する。 |
| メディア報道 | 煽りまたは冷笑。 | 事実、推測、影響範囲、対策、未確定点を分けて説明する。 | 社会的認知を修正行動へつなげる。 |
| 組織運用 | ツール導入で満足する。 | 資産管理、SBOM、トリアージ、パッチ適用、再観測を整備する。 | 危険窓 \(W(v)\) を短くする。 |
このように考えると、冷静な判断とは、AI を封印された怪物として恐れることでも、単なる便利な道具として軽視することでもなく、観測能力の上昇を前提に、攻撃履歴へ流れる経路を狭め、修正履歴へ流れる経路を太くする制度と運用を作ることである。AI が可視化する不整合は、放置すれば攻撃、騒動、制度不信、未処理リスクへ流れる。しかし、適切に受け止めれば、修正、監視、設計改善、公開規範、責任分担、更新可能性の強化へ流せる。分岐点は AI そのものではなく、人間社会の受け皿にある。
最終的に、社会の成熟は、危険を見ないことではなく、見えた危険を修正履歴へ変換する速度で決まる。これは、セキュリティに限らない。複雑な文明は、常に不整合を抱える。技術、制度、運用、法律、報道、組織、個人の判断は、完全には同期しない。AI によって観測能力が上がると、その非同期性がより速く見えるようになる。問題は、見えたものに驚くことではない。見えたものを、誰が受け取り、誰が直し、誰が説明し、誰が再観測するかを決めることである。
この章から次章へ進むために重要なのは、ここまでの評価を結論として束ねることだ。Claude Mythos 騒動は、AI の危険性だけを示した出来事ではない。人間社会が、自分たちのソフトウェア基盤、開示制度、修正速度、責任分担、メディア認知、AI 利用規範を見直す契機である。次章では、ここまでの議論を総括し、AI 時代の安全性を、欠陥の不在ではなく、観測された不整合を修正履歴へ変換し続ける社会的能力として定義し直す。
28. 結論――観測能力が上がった社会で、人間は修正責任を引き受ける
本稿の結論は明確である。AI による弱点探索の本質は、世界に新しい脆弱性を作ることではなく、既存構造の潜在的不整合を高速に観測することである。Claude Mythos 騒動は、封印された怪物が突然暴れ出した出来事ではない。より正確には、人間社会が長年積み上げてきたソフトウェア、依存関係、権限境界、運用、公開制度、責任分担の中に残っていた潜在的不整合を、AI がより広く、速く、低コストで照らし始めた出来事である。この照明は攻撃者にも防御者にも届く。だから危険であり、同時に有用である。
この構図は、GPT-2 の段階的公開と連続している。GPT-2 では、自然文生成能力が情報環境の処理能力を超える可能性が問題になった。Claude Mythos 騒動では、脆弱性探索能力がセキュリティ制度と運用の処理能力を超える可能性が問題になっている。対象は偽情報からサイバー探索へ移ったが、根本構造は同じである。能力そのものより、公開された能力が、社会の評価、制御、修正、説明、制度化の速度を上回るかどうかが問題なのである。したがって、問うべきことは単純な公開可否ではない。どの能力を、誰に、どの権限で、どの監査と修正経路に接続して使わせるかである。
ゼロデイについても、同じ転換が起きている。個別のゼロデイは、発見され、公表され、修正され、検知されれば価値が下がる。その意味では、一回限りのカードに近い。しかし、AI が変えるのは個別カードだけではない。変わるのは、カードを継続的に見つけるプロセスである。個別ゼロデイの寿命は短くなり、継続探索能力の価値が上がる。したがって、社会の問題は、カードを隠すか公開するかだけではなく、継続的に発見される不整合を、どの順番で、誰が、どの責任で、どの速度で修正するかである。
CVE-2026-31431 のような事例が示すのは、単なる危険なバグの存在ではない。そこにあるのは、意味境界の破綻である。読み取り可能なもの、書き込み可能なもの、ページキャッシュ、暗号 API、ゼロコピー、setuid バイナリ、ファイル完全性検査、実行時状態といった複数の構造が、特定条件で接続されると、局所的には正当に見える処理の合成が、全体として不正な経路を生む。これは、局所正当性の合成が全体正当性を保証しないという問題である。AI による弱点探索は、このような意味境界のずれを、従来より高解像度で観測する。
| 本稿で扱った論点 | 最終的な整理 | 結論への接続 |
|---|---|---|
| GPT-2 との連続性 | 能力公開が社会の処理速度を超える問題である。 | 公開可否ではなく、能力をどの制度へ接続するかが重要になる。 |
| Claude Mythos 騒動 | AI が脆弱性を作ったのではなく、潜在的不整合の観測能力を上げた。 | 怪物論ではなく、観測能力上昇への制度対応として読むべきである。 |
| ゼロデイ | 個別カードより、継続的な発見プロセスが重要になる。 | 危険窓を短くする運用能力が安全性の中核になる。 |
| CVE-2026-31431 | 複数構造の意味境界が接続点で破綻する事例である。 | 単一箇所のバグではなく、境界、接続、履歴、実行時状態を見る必要がある。 |
| 悪意ある利用 | 攻撃意図ではなく、探索コストと手順化コストが下がる。 | AI の善悪ではなく、出力が攻撃履歴へ流れる経路を狭める必要がある。 |
| 防御側利用 | AI は未発見不整合を早く見つける防御手段にもなる。 | 観測能力を修正工程へ接続すれば、安全性向上に使える。 |
| メディア誇張 | 騒動強度と実技術リスクは一致しない。 | 恐怖でも冷笑でもなく、事実、推測、宣伝、対策要求を分ける必要がある。 |
| 構造振動モデル | 脆弱性は潜在振動であり、AI 探索は観測能力の増幅である。 | 観測された振動を攻撃履歴へ発散させず、修正履歴へ減衰させることが中心になる。 |
| 実務対策 | AI 導入ではなく、更新可能性の実装が中心である。 | 資産管理、SBOM、トリアージ、パッチ適用、再観測、責任分担が必要になる。 |
この整理から、AI 時代の安全性を定義し直せる。AI 時代の安全性とは、欠陥が存在しないことではなく、観測された不整合を、攻撃履歴へ発散させる前に、修正履歴へ変換し続ける社会的能力である。これは静的な安全観ではない。複雑な社会技術構造では、欠陥、設定差分、依存関係の変化、権限境界のずれ、運用遅延、制度不備は常に生じる。したがって、安全とは、すべての振動が消えた状態ではなく、振動が発生しても観測、削減、修正、適用、説明、再観測を通じて許容範囲へ戻せる状態である。
数理モデルで言えば、潜在脆弱性集合 \(V_t\) は、観測能力 \(O_t\) によって候補集合 \(B_t = O_t(V_t)\) として可視化される。可視化された候補は、そのままでは安全にも危険にもならない。攻撃者の悪用能力 \(A_t\) へ接続されれば攻撃履歴へ流れ、防御者の修正能力 \(R_t\) へ接続されれば修正履歴へ流れる。脆弱性 \(v\) の危険窓は \(W(v)=\max(0,T_p(v)-T_e(v))\) と表せる。ここで重要なのは、\(T_e(v)\)、すなわち悪用可能化時刻より前、または十分近い時点へ \(T_p(v)\)、すなわち修正適用時刻を近づけることである。安全性は、発見数そのものではなく、この危険窓をどれだけ短くできるかに依存する。
修正責任のモデルも、ここで結論へ接続する。各主体 \(i\) の修正責任量 \(D_i\) は、観測可能性 \(o_i\)、修正可能性 \(r_i\)、影響範囲 \(s_i\)、対応遅延 \(l_i\)、外部情報制約 \(c_i^{ext}\)、自己形成情報制約 \(c_i^{self}\) によって整理できる。見えていたのに放置した主体、直せたのに直さなかった主体、広い影響範囲を持ちながら説明を怠った主体、対応を遅らせて危険窓を広げた主体には、重い修正責任が生じる。一方で、情報が届かなかった主体、修正権限を持たなかった主体、更新手段を提供されなかった主体に同じ責任を負わせるのは不合理である。ただし、資産台帳がない、SBOM がない、ログがない、報告窓口がない、更新手順がないといった自己形成情報制約は、免責ではなく、観測責任の不履行として扱うべきである。
構造振動モデルに接続すれば、全体像はさらに明確になる。脆弱性とは構造の潜在振動であり、AI 探索とはその観測能力の増幅であり、CVE やアドバイザリは振動のラベル化であり、PoC 化は攻撃方向への位相固定であり、パッチは位相修正であり、更新適用は修正履歴への固定であり、再起動と監視は履歴固定後の再観測である。この対応関係に立つと、セキュリティは「欠陥をなくす」作業ではなく、「振動を破壊的発散へ進ませず、許容範囲へ減衰させる」継続的な構造更新になる。
| 構造振動モデルの語彙 | 脆弱性対応での対応 | 結論上の意味 |
|---|---|---|
| 潜在振動 | 未発見欠陥、意味境界のずれ、制度上の不整合。 | 欠陥は観測前から構造内部に存在し得る。 |
| 振幅増幅 | AI 探索、fuzzing、静的解析、監視による候補化。 | 観測能力が上がるほど、未処理の不整合が見えるようになる。 |
| 観測ラベル化 | CVE、advisory、issue、報告書、チケット。 | 社会が同じ不整合を共有可能な対象として扱えるようになる。 |
| 位相修正 | パッチ、設定変更、緩和策、設計変更、制度更新。 | ずれていた構造関係を補正する。 |
| 履歴固定 | 本番適用、リリース、再起動、監査記録、postmortem。 | 修正を実環境と社会的記録へ固定する。 |
| 再観測 | スキャン再実行、ログ監視、適用確認、残課題管理。 | 残留振動や新しい不整合を検出し、次の更新へ接続する。 |
ここで重要なのは、AI を責任主体として扱わないことである。AI が脆弱性候補を出したとしても、AI が道徳的責任を負うわけではない。AI が攻撃手順に近い出力を生成し得るとしても、そこに人間的な悪意や野心を仮定する必要はない。責任主体は、人間、組織、制度、運用である。AI を設計する者、公開範囲を決める者、アクセス権を与える者、監査する者、利用する者、報告を受ける者、修正する者、適用する者、説明する者が責任を持つ。AI を怪物化すると、この具体的な責任構造が見えなくなる。逆に、AI を単なる道具として軽視すると、探索コストを下げる社会的影響を見落とす。
したがって、本稿が採る判断は、過剰な禁止でも、無邪気な解放でもない。危険な能力を誰にでも無制限に渡すべきではない。しかし、防御者が使える観測能力まで封じると、攻撃者だけが非公式な手段で先行する非対称性が残る。必要なのは、能力を防御文脈へ流し、攻撃文脈へ流れにくくする制度設計である。具体的には、利用者資格、対象範囲、権限境界、監査ログ、CVD 接続、危険出力制御、人間レビュー、トリアージ、修正工程、利用者通知、再観測を一つの連鎖にする必要がある。
実務に落とせば、結論はさらに具体的になる。第一に、重要資産と露出面を把握する。第二に、SBOM と依存関係を整備する。第三に、KEV、CVE、NVD、CVSS、ベンダーアドバイザリ、ディストリビューション情報を監視する。第四に、AI 支援レビュー、fuzzing、静的解析、依存関係スキャン、ログ監視を導入する。第五に、見つかった候補を放置せず、受付、一次判定、影響評価、修正計画、適用、再観測へ流す。第六に、公開前調整と利用者通知を制度化する。第七に、パッチ適用、再起動、ロールバック、例外管理を通常業務にする。第八に、AI 利用の対象範囲、権限、ログ、人間レビューを明確にする。第九に、責任分担を文書化する。第十に、危険窓を短くできているかを運用指標で測る。
この実務原則の中心は、AI 導入ではない。中心は更新可能性である。AI を導入しても、古い構成が残り、再起動できず、検証環境がなく、依存関係が不明で、責任者が曖昧で、公開前調整も利用者通知も制度化されていないなら、安全性は上がらない。AI は観測能力を上げるが、修正責任を代替しない。AI が増やすのは、見えるものの量である。その見えたものを、何から直し、どこまで公開し、どの環境へ適用し、どの履歴へ固定するかは、人間と組織が決めなければならない。
Claude Mythos 騒動をめぐる言葉は、今後も揺れるだろう。企業は能力を強く見せたいかもしれない。政府は安全保障上の懸念を強調するかもしれない。メディアは危険な物語を好むかもしれない。批判者は誇張を笑うかもしれない。しかし、騒動強度と実技術リスクは同じではない。強い言葉を取り除いた後にも、観測能力の上昇という事実は残る。誇張を笑った後にも、修正責任の問題は残る。封印された怪物の物語を退けた後にも、人間社会が自分たちの制度と運用を更新しなければならないという課題は残る。
本稿全体を一文でまとめるなら、Claude Mythos 騒動とは、AI が世界に新しい怪物を放った出来事ではなく、人間社会が作ってきた構造の潜在的不整合を、AI という外部化された知能によって再観測させられた出来事である。そこで問われているのは、AI が主観を持つか、AI が悪意を持つか、AI を封印すべきかという単純な話ではない。問われているのは、観測能力が上がった社会で、人間が見えてしまった不整合をどのように受け取り、どのように責任を配分し、どのように修正し、どのように履歴へ固定するかである。
最終的に、人間は「知らなかった」という状態へ戻れない。AI によって、見えなかった脆弱性、見えなかった制度不備、見えなかった責任の空白、見えなかった運用遅延が見えるようになる。見えた以上、それをどう扱うかが問われる。見えたものを攻撃履歴へ流すのか。騒動として消費するのか。制度不信として放置するのか。それとも、修正履歴へ変換し、次の安定状態へ更新するのか。ここに、人間の修正責任がある。
したがって、結論は次の一点に集約される。観測能力が上がった社会で、人間は修正責任を引き受ける。AI は観測する。AI は候補を出す。AI は整理し、比較し、説明し、修正案を支援する。しかし、何を危険と見なし、何を先に直し、誰に知らせ、どこまで公開し、どの例外を許し、どの制度を変え、どの履歴へ固定するかを決めるのは人間である。AI 時代の成熟とは、危険を見ないことではない。見えた危険を、できるだけ短い危険窓で、攻撃履歴ではなく修正履歴へ変換し続けることである[54]。
参考文献
- Anthropic, Project Glasswing: Securing critical software for the AI era. https://www.anthropic.com/project/glasswing
- Anthropic Red Team, Claude Mythos Preview. https://red.anthropic.com/2026/mythos-preview/
- UK AI Security Institute, Our evaluation of Claude Mythos Preview’s cyber capabilities. https://www.aisi.gov.uk/blog/our-evaluation-of-claude-mythos-previews-cyber-capabilities
- Reuters, European Commission is in contact with Anthropic on Mythos, Dombrovskis says. https://www.reuters.com/world/european-commission-is-contact-with-anthropic-mythos-dombrovskis-says-2026-05-04/
- Reuters, Microsoft, Google and xAI to give US government early access to AI models for security checks. https://www.reuters.com/legal/litigation/microsoft-xai-google-will-share-ai-models-with-us-govt-security-reviews-2026-05-05/
- OpenAI, Better language models and their implications. https://openai.com/index/better-language-models/
- OpenAI, GPT-2: 1.5B release. https://openai.com/index/gpt-2-1-5b-release/
- OpenAI, Release Strategies and the Social Impacts of Language Models. https://cdn.openai.com/GPT_2_August_Report.pdf
- id774, CVE-2026-31431 について徹底的に考える（2026-05-06）. https://blog.id774.net/entry/2026/05/06/4730/
- NVD, CVE-2026-31431 Detail. https://nvd.nist.gov/vuln/detail/CVE-2026-31431
- Debian Security Tracker, CVE-2026-31431. https://security-tracker.debian.org/tracker/CVE-2026-31431
- Microsoft Security, CVE-2026-31431: Copy Fail vulnerability enables Linux root privilege escalation. https://www.microsoft.com/en-us/security/blog/2026/05/01/cve-2026-31431-copy-fail-vulnerability-enables-linux-root-privilege-escalation/
- Theori / Xint, Copy Fail: 732 Bytes to Root on Every Major Linux Distribution. https://xint.io/blog/copy-fail-linux-distributions
- CERT-EU, High Vulnerability in the Linux Kernel (Copy Fail). https://cert.europa.eu/publications/security-advisories/2026-005/
- CISA, Coordinated Vulnerability Disclosure Program. https://www.cisa.gov/resources-tools/programs/coordinated-vulnerability-disclosure-program
- CERT Coordination Center, CERT Guide to Coordinated Vulnerability Disclosure. https://certcc.github.io/CERT-Guide-to-CVD/print_page/
- ISO, ISO/IEC 29147 Vulnerability disclosure processes. https://www.iso.org/standard/92945.html
- CISA, Known Exploited Vulnerabilities Catalog. https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- CVE Program, Overview About the CVE Program. https://www.cve.org/about/overview
- NIST, National Vulnerability Database. https://nvd.nist.gov/
- FIRST, Common Vulnerability Scoring System v4.0 Specification Document. https://www.first.org/cvss/specification-document
- NIST, Secure Software Development Framework (SSDF) Version 1.1. https://csrc.nist.gov/pubs/sp/800/218/final
- CISA, Software Bill of Materials (SBOM). https://www.cisa.gov/sbom
- NTIA, The Minimum Elements For a Software Bill of Materials (SBOM). https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom
- Google, OSS-Fuzz: Continuous Fuzzing for Open Source Software. https://google.github.io/oss-fuzz/
- OpenSSF, Scorecard. https://openssf.org/projects/scorecard/
- SLSA, Supply-chain Levels for Software Artifacts. https://slsa.dev/
- NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0). https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10
- NIST, AI RMF Playbook. https://www.nist.gov/itl/ai-risk-management-framework/nist-ai-rmf-playbook
- id774, 構造振動モデルを数理モデルとして定義する（2026-04-05）. https://blog.id774.net/entry/2026/04/05/4318/
- id774, 哲学はなぜ構造の揺れを数理モデルで説明できるのか（2026-04-06）. https://blog.id774.net/entry/2026/04/06/4328/
- id774, 抽象哲学を運用可能なモデルへ変換する（2026-04-07）. https://blog.id774.net/entry/2026/04/07/4335/
- id774, 宇宙を構造として再定義する（2026-03-27）. https://blog.id774.net/entry/2026/03/27/4171/
- id774, 観測者を含む宇宙論の確率モデルの統一的定式化（2026-03-28）. https://blog.id774.net/entry/2026/03/28/4219/
- id774, 観測を情報更新として定式化する宇宙論（2026-03-30）. https://blog.id774.net/entry/2026/03/30/4239/
- id774, 時間はなぜ一方向に進むのか（2026-04-26）. https://blog.id774.net/entry/2026/04/26/4613/
- id774, 量子観測はどこまで説明できるのか（2026-04-24）. https://blog.id774.net/entry/2026/04/24/4597/
- id774, 多世界解釈とユニタリー発展の構造（2026-04-29）. https://blog.id774.net/entry/2026/04/29/4638/
- id774, デコヒーレンスは何を説明し、何を説明しないのか（2026-04-28）. https://blog.id774.net/entry/2026/04/28/4632/
- id774, 量子確率はなぜボルン則に従うのか（2026-04-25）. https://blog.id774.net/entry/2026/04/25/4607/
- id774, 創発とは何かを考える（2026-05-03）. https://blog.id774.net/entry/2026/05/03/4671/
- id774, なぜ世界は意味を持つのか（2026-01-02）. https://blog.id774.net/entry/2026/01/02/3191/
- id774, 人間と環世界（2026-01-26）. https://blog.id774.net/entry/2026/01/26/3371/
- id774, 意識の定義を数理モデルで記述する（2026-04-02）. https://blog.id774.net/entry/2026/04/02/4269/
- id774, クオリアを構造振動として記述する（2026-04-22）. https://blog.id774.net/entry/2026/04/22/4582/
- id774, 観測者と主観はなぜこの量子系列だけを見るのか（2026-04-27）. https://blog.id774.net/entry/2026/04/27/4627/
- id774, 心とは何かを構造から再定義する（2026-04-10）. https://blog.id774.net/entry/2026/04/10/4391/
- id774, 知能はどこから来てどこへ行くのか（2026-04-11）. https://blog.id774.net/entry/2026/04/11/4396/
- id774, AI に自身の文脈を持ち運ぶ（2026-05-04）. https://blog.id774.net/entry/2026/05/04/4675/
- id774, 人生を意味生成の構造として定義する（2026-05-05）. https://blog.id774.net/entry/2026/05/05/4722/
- id774, 自己を「構造」として定義し直す（2026-03-25）. https://blog.id774.net/entry/2026/03/25/4103/
- id774, クオリアはなぜ説明できないのか（2026-04-03）. https://blog.id774.net/entry/2026/04/03/4275/
- id774, AI は感情を持つのか（2026-04-13）. https://blog.id774.net/entry/2026/04/13/4418/
- id774, タイタニック号事故から読み解く巨大システム運用の本質（2026-05-02）. https://blog.id774.net/entry/2026/05/02/4656/