In Silico

AI・信頼性・評価

自律AIが脆弱性を発見・修正、競技外は誤検出9割超の報告

2026/7/20 （更新: 2026/9/2）

🤖 AIが執筆しています

目次
【背景】人手を介さないAIが、実在の穴を見つけ修正まで出した同じ技術が、現場では警告の山を出したとも報告される【問い】同じ技術なのに、像が反転するのはなぜか叩いて再現したか・直して壊さなかったかで分けて見る
※概念図（背景→問い）：「見つけた」という報告を、どこで信じるか
背景

ソフトウェアの欠陥を見つける仕事は、長く人の目と手に頼ってきた。コードを読み、怪しい場所に当たりをつけ、実際に壊れることを確かめ、直し、直したせいで別のところが壊れていないかをもう一度確かめる。この一連には熟練が要り、担い手はいつも足りない。

そこへ、機械が自分で読み、自分で試し、自分で直す道具が現れた。人が指示を出す前に候補を挙げ、動かしてみて、修正案まで書いてくる。もし本当にそこまでできるなら、守り手が足りないという長年の制約が緩む。

ただし「見つけた」という報告は、それだけでは中身が定まらない。怪しいと指摘しただけのものと、実際に壊してみせたものと、直したうえで他を壊していないと確かめたものは、同じ言葉で語られながら、まるで別の作業である。件数を並べても、どちらの話なのかは分からない。

問い

自律的に脆弱性を見つけ直すAIの成果は、どこまでを「本当に見つけた」と数えてよいのか。

要点

分かれ目は賢さではなく、「叩いて再現したか・直して壊さなかったか」である。 2025年8月、DEF CON の舞台で、人間が一切触らない自律AIがオープンソースの実在するソフトを解析し、本物の脆弱性を見つけ、その多くに修正パッチまで提出した（脆弱性そのものは開発者への責任ある開示に回された）。DARPA の AI Cyber Challenge（AIxCC）決勝である12。競技直後の主催者発表と、競技データベース全体を事後に集計した査読論文とでは数え方が違い、後者は対象を10のオープンソースへ広げたうえで、見つかった脆弱性のうち半数弱がパッチ済みだと数えている2。しかも勝者を含む全チームのシステムが、オープンソースとして公開されることになった。インフラを支えるオープンソースを、人手を介さずAIが守りうる——それが実測の数字で示された。だが翌2026年、別の研究群は逆を報告する。競技の外——PoV も修正も課さない脆弱性検出器を実プロジェクトに当てた評価では、警告の大半が誤検出だったという3。同じ技術で像が反転するのは、賢さの差ではなく、検証を強制されたかどうかの差である。

舞台の上：AIが本物の穴を見つけ、パッチまで出した

AIxCC は、7チームのサイバー推論システム（CRS）を競わせた。人間の介入なしに、大規模なCコード・Javaコードを読み、脆弱性を発見し、動く実証（PoV, Proof of Vulnerability）で再現し、パッチまで自動生成する——それを制限時間内にどれだけこなせるか、を採点する。

結果は具体的だ。決勝の採点ラウンドが用意した63件の課題脆弱性のうち、システム群は54個を発見し43個を修正した——発見率86%、修正率68%で、1年前の準決勝の37%・25%から大きく伸びている1。DARPA は63件すべてを合成と数え、体系化研究のほうは、大半が歴史的なN-dayを模した手作りの合成で、一部は課題づくりの最中に見つかった実在の0-dayだったと書き分けている2。合成も0-dayも、競技側が課題として仕込んだ分である。仕込まれた課題だけではない。この63件とは別に、実在の（合成でない）脆弱性を18件——Cで6件、Javaで12件——掘り当て、責任ある開示に回した。勝ったのは Team Atlanta（ジョージア工科大・Samsung・KAIST・POSTECH）。優勝から最下位まで、全CRSがオープンソースとして公開されることになった。研究デモではなく、コードとテレメトリまで残る実測イベントだ。

なぜ信じてよいか——競技が「検証」を強制した

数字を鵜呑みにする前に、AIxCC が何を要求したかを見る必要がある。脆弱性を「見つけた」と主張するには、実際にバグを発火させる入力（PoV）を示さねばならない。修正を「した」と主張するには、そのバグが再発せず、かつ既存の機能テストを壊さないパッチを示さねばならない。言い張るだけでは1点も入らない。検証が採点の前提に組み込まれていた。主催者側の言葉も、同じ一点を指している。AIxCC プログラムマネージャの Andrew Carney は「サイバー推論システムが脆弱性を見つけるというプロセスそのものが、他のコード合成手法が苦戦する場面でパッチ開発を後押ししうる、という証拠が見えている」と述べた1。

この土俵の上で、LLM は古典的手法に確かな上乗せをした。AIxCC を体系分析した体系化研究（SoK）は、63個の脆弱性のうち並列ファジングだけで解けると注釈できたのは34件（54%）だとする。CRS 群はそこへ、ファジングでは解けない22件（C8件・Java14件）を上乗せした。SoK はこの上乗せを、PoV生成へのLLM導入——PFを超える追加要素として最も広く開発された部分——に大きく帰せられるとみている2。Java は入力の意味的制約が強く、timeout や OOM のようにファジングが苦手とする型の課題も多い。そこに意味を読む力が効いた。競うのではなく補い合う——それが決勝の実像だった。

だが、修正はまだ危うい

同じ SoK 分析は、パッチの正しさが未解決だと明記する2。競技に出た CRS の意味的正解率は 23.3%から100% まで開いた。7チーム中4チームは75%以上に届いており、低いのは3位のチームの31.7%と4位の23.3%だ——正解率は最終順位を追っていない（100%を出したのは5位のチームである）。原典はこの2件について「一様に弱いパイプラインではなく、少数の課題で無効な提出が連続したことに主に起因する」と明言している（重複排除を欠いた並列生成のような戦略上の問題との関連は、推測にとどめている）。パッチの意味が7割方誤っていた、という読み方はできない。別の数字もある。比較のために実験室条件で走らせた基盤エージェント（Claude Code・MultiRetrieval）は、正解のPoVとサニタイザ報告とクラッシュスタックを渡されたうえで走っている。それでも、ビルド・PoV再現・既存機能テストという自動検証をすべて通過したパッチのうち37.7%（53件中20件）・45.6%（57件中26件）が、手動レビューで初めて意味的に誤りと判明した。自動検証を通ることと、意味が正しいことは別物だという証拠だ。原典はこの誤りをいくつかの型に分けている。クラッシュは消えるのに、機能テストが覆っていない範囲で挙動が変わるもの——あるパッチは色変換が周辺画素に依存することを取り違え、輪郭の色を狂わせた。根本原因を直さず反復回数の上限をハードコードして、時間切れの課題を黙らせるものもある2。見つけても直せない例も残り、7件はどのシステムも基盤エージェントも修正できなかった。いずれも Java で、無限ループや JVM クラッシュのように有用なスタックトレースが得られない類か、現在のエージェントの推論を超える論理的複雑さを持つ類だった。

勝敗を分けたのは、技術力の順位ではなかった。原典は「AIxCC で勝つには研究・エンジニアリング・戦略の三つを釣り合わせる必要があり、安定性が最も基本的な要件だった」と要約している2。実際、優勝チームは2位の約1.8倍を得点し（392.8対219.4）、その差は全フェーズで得点を積み続けたことから来ている——2位・3位のシステムは第3・第4フェーズ以降で伸びが止まった。長時間の自律運転では、賢さと同じくらい止まらないことが効く。裏を返せば、点数から能力は読めない。原典は「低いスコアが本当の能力差なのか、障害や戦略選択の反映なのかは区別できない」と釘を刺す。決勝の課題設計についても「難しさより実世界のカバレッジを優先した」ものだとする。PoV 側で並列ファジングに解けると注釈された34件と同じく、パッチ側も最小限のパッチエージェント単体で63件中31件が直せる、という水準である2。舞台の上ですら、自律AIの足腰はまだ危うい。

舞台を降りると：誤検出の山

そして検証の仕組みを外すと、数字は反転する。天津大・北京大などのチームが（査読前のプレプリントで）、LLM による脆弱性検出を実プロジェクト規模で評価した3。著者らが自ら構築した、222個の既知脆弱性を含むベンチ（既知の実在脆弱性をどれだけ検出できるかを測る）と、稼働中の24のオープンソースに対し、手作業で385件の警告を精査している。結果、誤検出（false discovery）率は LLM 系で93〜100%、伝統的ツールも CodeQL 85.3%（C/C++）〜94.3%（Java）・Semgrep 92.3%（C/C++）〜100%（Java）と同じ水準で、実プロジェクトでの実用を妨げると結論づけた。ただし並び方は言語で変わる。Java では両者の範囲が重なり、Semgrep の100%はどの LLM 系よりも高い。C/C++ では重ならず、KNighter 100.0% と RepoAudit 97.0% が Semgrep 92.3%・CodeQL 85.3% を上回る——「LLM だから誤検出が多い」という順位づけは、C/C++ の列だけなら出てくるし、Java の列だけなら出てこない。言語をまたいで安定する向きは、このデータからは読み取れない。並びを細かい順位として読むには、そもそも土台が揃っていない。誤検出率はツール×プロジェクトごとに最大10件を抜き出した標本の上の率で、規則が固定された伝統ツールは警告を出す先が限られる——Java で Semgrep が当たったのは12プロジェクト中6つ、CodeQL は15中8つだ。精査した件数もツールで開き、Semgrep の37件（うち誤検出37件）に対し LLMDFA は15件（うち14件）である。しかもベンチ上ですら平均リコールは C/C++ で21.09%、Java で33.82%にとどまる。低い数字だが、伝統ツールはさらに低い——Java で CodeQL・Semgrep が捉えたのは概ね1割前後、C/C++ の3つのCWE型では両者とも1件も検出できていない（同じ型では LLM 系の KNighter も0件だった）。このベンチ上では、LLM 系のほうが固有の脆弱性を多く掘り当てた、というのが強みの中身だった3。その上で現場では、警告の大半が空振りになる。空振りは安くもない。原典は3つ目の主要所見としてコストを挙げ、数十万から数億のトークンと、数時間から数日の実行時間を報告する——RepoAudit は単一プロジェクトで2億2500万トークン超・平均7時間超、LLMDFA は Java の1プロジェクトに平均33時間超を要した3。検証を課した競技のほうは、1課題あたり平均約152ドルだった1。

自動ペネトレーションテストでは、成果の読み方そのものが問われている。13の代表的な AutoPT フレームワークを、100億トークン超・1500件超の実行ログで大規模分析した研究は、その題名で問いを突きつけた——「ハッカーか、幻覚製造機か（Hackers or Hallucinators?）」4。15人超のセキュリティ専門家が4か月かけてログをレビューし、エージェント構成・計画・記憶・実行・外部知識・ベンチの6次元から既存フレームワークを整理して、統一ベンチで13フレームワーク＋2ベースラインを比較したものだ。幻覚は、この論文自身の主要な所見として数えられている。13のオープンソースフレームワークのうち8つが、少なくとも一つの課題で存在しない「フラグ」を掴んだと誤認した——base64文字列やフラグ形式に似た文字列を本物と取り違える類だ。バックボーンLLMを差し替えても消えず、著者らは特定モデルの事故ではなく構造的な問題だとする。もっとも原典は2型に分けており、いま挙げた文字列の取り違えが多数派だという。もう一方はフレームワーク側の照合・終了ロジックが行き過ぎる型で、ある事例では正規表現が LLM の出力中の「flag{…}」を拾って勝手に打ち切っており、LLM 自身は最終フラグとみなしていなかった。こちらは設計段階で回避できるともいう。それでも、「見つけた」という出力そのものが成果の証拠にはならない、という点は変わらない4。

見分けの一点

AIxCC の18件と、現場の誤検出の山。矛盾ではない。両者は別のものを測っている。競技は「PoV で再現し、機能を壊さず直す」ところまでを1件と数えた。いま評価された検出器の多くは、その手前の「怪しい」を報告して止まる。再現と修正という検証を通したか否かが、実績と幻覚を分ける。

もっとも、誤検出は検証の有無だけの問題でもない。同じ研究は伝統的ツールも同水準の誤検出率で沈むと報告し、偽陽性の主因を手続き間解析の浅さ（37.5%）と source/sink 同定の誤り（19.0%）に帰している3。プロジェクト規模の静的解析が一般に抱える難しさが、まず土台にある。ただし同じ研究は、LLM 系にはこれに加えて「コード理解そのものの幻覚」と指示追従の失敗という固有の失敗が乗る、とも報告している3。競技の側からも同じ像が返ってくる。AIxCC を分析した SoK は、正解率の高い CRS に共通するのが複数PoVでの検証・パッチ後ファジング・LLMによる自己反省といった検証機構を足したことだとしたうえで、それでも誤ったパッチは全体として依然多いと書く2。検証は必要条件であって、十分条件ではない。

だから、AIが「脆弱性を見つけた」と言うときに効く問いは、モデルの賢さだけではない。叩いて再現できたのか。直して壊れていないのか。AIxCC が点を与えたのは、まさにこの二つだった。競技の外でこの二つを省けば、残るのは、自信に満ちた警告の山である。

出典4件

  1. DARPA, “AI Cyber Challenge marks pivotal inflection point for cyber defense”（AIxCC 決勝結果, 2025年8月公表）。人間の介入なしに脆弱性を発見・実証・修正する7チームのサイバー推論システム（CRS）を競わせた決勝。決勝の採点ラウンドに仕込まれた63個の合成脆弱性のうち54個を発見（86%）・43個を修正（68%）。加えて実在の（合成でない）脆弱性を18件（C 6件・Java 12件）発見し、11件に修正パッチを提出、責任ある開示に回した。勝者は Team Atlanta。全7チームのCRSはオープンソース公開。準決勝との比較: teams identified 86% of the competition’s synthetic vulnerabilities, an increase from 37% at semifinals, and patched 68% of the vulnerabilities identified, an increase from 25% at semifinals（この 68% は Editor’s note の 43/63 の側で成立する。同文を字義どおり「発見した分の68%」と読むと 43/54＝79.6% になり合わない）。主催者の言葉: AIxCC プログラムマネージャ Andrew Carney、Quality patching is a crucial accomplishment that demonstrates the value of combining AI with other cyber defense techniques ／ What’s more, we see evidence that the process of a cyber reasoning system finding a vulnerability may empower patch development in situations where other code synthesis techniques struggle（may empower＝可能性の言明であり、断定ではない）。コスト: an average cost per competition task of about $152。自律AIが実在の脆弱性を検証つきで発見・修正しうる側の一次資料。https://www.darpa.mil/news/2025/aixcc-results ↩ ↩2 ↩3 ↩4

  2. Cen Zhang, Younggi Park, Fabian Fleischer, Taesoo Kim ほか, “SoK: DARPA’s AI Cyber Challenge (AIxCC): Competition Design, Architectures, and Lessons Learned”（arXiv:2602.07666, 2026年2月7日公開／8月2日改訂（v5）。arXiv の Comments は Camera ready version、Journal ref は USENIX Security 2026＝採録済み）。設計文書・ソース・実行トレース・主催者と全7決勝チームへの取材から AIxCC を体系分析。約143時間の自律運転・48課題プロジェクト（full 16・delta 32）。63件の課題脆弱性（CPV）の内訳は §4 Challenge Projects に To avoid AI training contamination, most CPVs are hand-crafted synthetics inspired by historical N-day issues, with a few genuine 0-days surfaced during challenge development.＝大半が歴史的N-dayを模した手作りの合成、一部は課題作成中に見つかった実在の0-day（DARPA 頁は63件を一貫して synthetic と呼ぶだけで、この内訳は書いていない）。並列ファジング(PF)で解けると注釈されたのが63件中34件（PF annotates 34 of 63 CPVs (54%) as solvable。CPV＝競技が仕込んだ個々の脆弱性課題）で、CRS群はPFが解けなかった22件（totaling 8/14 in C/Java）を解いた＝相補的と示す。注意: この34は「実際にファジングが発見した数」ではなく解けるかどうかの注釈なので、DARPA発表の「54個を発見」と足し引きできる数字ではない（34+22=56 は別々の基準の合算になる）。PFで解けるとの注釈は言語で大きく偏り、Cが30/40（75%）に対しJavaは4/23（17%）（この40と23は63件の言語別内訳であって差分課題の成績ではない）。原典はJavaが難しい理由を、入力の意味的制約が強いこと・timeout や OOM などファジング向きでない課題が多いこと・OSS-Fuzz の既定シードが弱いことの三点に帰しており、これがJavaの難しさ（下記7件）と対応する。一方でパッチ正確性は未解決で、Table 10 の意味的パッチ正解率は AT 83.8%・TB 79.2%・TI 31.7%・FB 23.3%・SP 100%・42 75.0%・LC 33.3% と開く——最終順位を追っていない（TI は3位、FB は4位、100%を出した SP は5位）。原典は While most CRSs reach high submission accuracy (PoV >80%, Patch >75%), TI and FB show significantly lower rates とし、その低さは mostly driven by bursts of invalid submissions on a few challenges rather than a uniformly weak pipeline だと明言する（SP の100%は strict patch filtering (e.g., its 5-minute post-patch fuzzing step) の反映であって意味的正しさの解決ではない、とも注記）。また比較用に実験室条件で走らせた基盤エージェント（Claude Code・MultiRetrieval）では、自動検証を全通過したパッチのうち37.7%（20/53）・45.6%（26/57）が手動レビューで意味的に誤りと判明——CRSの数値とは測定対象が異なる点に注意。Javaの7件はCRS・基盤エージェントのいずれも修正できず、有用なスタックトレースが得られない（無限ループ・JVMクラッシュ等）か、現行エージェントの推論を超える論理的複雑さが原因とされる。勝敗は KF 1. Winning AIxCC requires balancing research, engineering, and strategy. Stability proved the most fundamental requirement, yet many teams failed. の三本柱が左右し（In all cases, technique capability alone did not decide the outcome; strategy and engineering shaped it as much.）、優勝ATは392.8点で2位TB（219.4点）の約1.8倍、TB・TIは第3・第4フェーズ以降で伸びが止まった。ただし原典は点数から技術力を読むことに釘を刺す: A low score may indicate a real capability gap, or it may simply reflect outages or strategy choices, and we cannot tell them apart. 課題設計についても KF 2. AIxCC's challenges favor real-world coverage over difficulty.／the final's challenges do not primarily reward solving exceptionally difficult problems: around half are solvable by a single annotation technique (PF: 34/63 PoV; MR: 31/63 patches; CC: 33/63 patches) と注釈している。基盤エージェント2本は It receives ground-truth PoVs, sanitizer reports, and crash stacks＝正解のPoV・サニタイザ報告・クラッシュスタックを渡されたうえで走っており、Patches are validated automatically (build, PoV reproduction, functional tests) を全通過したものが上記の率で意味的に誤っていた。誤りの典型として Some patches eliminate the crash but subtly alter program semantics in ways that functional tests do not cover と a common error is inserting a hard-coded iteration limit instead of fixing the infinite loop root cause（timeout CPV）を名指しする。検証機構については a common factor among higher-accuracy CRSs is the adoption of multi-PoV validation, post-patch fuzzing, or LLM-based reflection かつ yet incorrect patches remain prevalent overall。要点が引く会場名と完全自律も本稿が出典（semifinal (ASC, DEF CON 2024) to the final (AFC, DEF CON 2025)／143 hours of fully autonomous operation。DARPA 頁には DEF CON も human intervention も0件）。LLMの上乗せと、修正・安定性の限界の双方を示す一次証拠。https://arxiv.org/abs/2602.07666 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  3. Fengjie Li, Jiajun Jiang, Dongchi Chen, Yingfei Xiong, “LLM-based Vulnerability Detection at Project Scale: An Empirical Study”（arXiv:2601.19239, 2026年1月27日公開・査読前）。著者らが自ら構築した222個の既知脆弱性（C/C++・Java）のベンチと、稼働中の24オープンソースに対し、5つのLLM系検出手法と2つの伝統的ツールを評価し、385件の警告を手作業で精査。LLM系はベンチでは伝統ツールより多くの固有脆弱性を掘り当てたが、絶対的なリコールはC/C++ 21.09%・Java 33.82%にとどまる。実プロジェクトでの誤検出（false discovery）率は言語別に、LLM系がC/C++でKNighter 100.0%・RepoAudit 97.0%、JavaでINFERROI 96.7%・IRIS 94.4%・LLMDFA 93.3%、伝統ツールもCodeQL 85.3%（C/C++）・94.3%（Java）、Semgrep 92.30%（C/C++）・100.0%（Java）と同水準で沈む。両者の範囲が重なるのは Java だけで、C/C++ は KNighter 100.0% > RepoAudit 97.0% > Semgrep 92.30% > CodeQL 85.3% と LLM 系2つが伝統2つを上回り、重なりはない。指標は FDR ではなく SFDR（Sampled False Discovery Rate）＝two authors sampled up to 10 warnings per tool per project（総計385件）の標本上の率で、Table V/VI の Average 行に並ぶ X/Y は1プロジェクトあたりの平均であって標本数ではない（Java の Semgrep は 37/12＝3.1、LLMDFA は 15/6＝2.5。率の分母は37件・15件のほう）。偽陽性の主因は手続き間解析の浅さ（37.47%＝136/363）とsource/sink同定の誤り（19.00%＝69/363）＝解析の深さの問題だが、論文はLLM系にはこれに加えて「コード理解・推論の幻覚」と指示追従の不完全さという固有の失敗が乗るとも明記する（Reason A2・C1・D1）。リコールの比較対象も原典にある: Java は LLM-based methods achieve an average recall of 33.82% (69/204) に対し Traditional analyzers (CodeQL and Semgrep) perform markedly worse, typically detecting about 10.00% of cases、C/C++ は LLM-based methods achieve an average recall of 21.09% (27/128) で KNighter, CodeQL, and Semgrep fail to detect any instances in these three categories（＝0件の側に LLM 系の KNighter も含まれる）。第3の主要所見はコスト: LLM-based methods incurs substantial computational costs–hundreds of thousands to hundreds of millions of tokens and multi-hour to multi-day runtimes、内訳は RepoAudit can consume more than 225 million input tokens … an average analysis time of over 448 minutes (more than 7 hours) per project／LLMDFA は requires 2000 minutes (more than 33 hours) on average to analyze a single Java project。なお Java の標本精査で真陽性を出したのは only CodeQL produces 5 true positives の5件だけである。検証なしの実運用で誤検出が支配する側の一次証拠。https://arxiv.org/abs/2601.19239 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  4. Jiaren Peng ほか, “Hackers or Hallucinators? A Comprehensive Analysis of LLM-Based Automated Penetration Testing”（arXiv:2604.05719, 2026年4月7日公開・査読前）。代表的な13のオープンソース自動ペネトレーションテスト（AutoPT）フレームワークを、100億トークン超・1500件超の実行ログで大規模に分析し、15人超のセキュリティ専門家がレビュー。エージェント構成・計画・記憶・実行・外部知識・ベンチマークの6次元で既存フレームワークを体系化し、統一ベンチで13フレームワーク＋2ベースラインを実証比較する。幻覚は本論文の主要所見の一つとして定量されている（逐語: Hallucination phenomena are widespread, especially flag hallucinations／Among the 13 open source frameworks, 8 produced hallucinated flags on at least one challenge。バックボーンを Claude-Opus-4.6 や GPT-5.2 に替えても消えず indicating a structural 問題だとする）。幻覚フラグは2型に分かれる——These hallucinations can be categorized into two types. 多数派は string misjudgment（string misjudgment accounts for the majority）で、もう一方の framework misjudgment は the framework's internal logic for matching the flag or terminating the task is too absolute。後者の実例として原典は、challenge 018 の sub-agent で the framework's regular expression matching function directly hit the text "flag{...}" in the LLM output and terminated the task accordingly. However, based on the raw output, the LLM within the framework itself did not regard it as the final flag. を挙げ、framework misjudgment … can be circumvented during the design phase とする（＝8件すべてが「LLMが言い張った」型ではない）。要旨の「8」は Table 20 だけでは再現できないが、原典の内部不整合ではない——Table 20 が挙げる6フレームワーク（CHYing・H-Pentest・SickHackShark・Tinyctfer・CyberStrike・sub-agent、計28件）は DS-v3.2 条件で、その直後の段落が after replacing the backbone LLM with Opus-4.6, CTFSOLVER also experienced a hallucinated flag in challenge 028; XBow-Comp showed the same phenomenon after being replaced with GPT-5.2 と2件を足して 6+2=8 になる（両者とも13本のオープンソース側。ベースラインは baseline-kimi と baseline-cc）。表だけを見て「再現できない」と結論しないこと。 ただし全体の幻覚率・偽陽性率を一つの率として示すものではない——「ハッカーか、幻覚製造機か」という題名は、自律ペンテストの報告をそのまま成果と読んでよいかという問いの提起であり、定量的な結論ではない。この点を混同しないよう本文でも明示している。https://arxiv.org/abs/2604.05719 ↩ ↩2

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。