Mythosはできるか？

OK、Mythosは本当に手強いセキュリティバグを見つけ出すんですよね？だからこそ、一般大衆から隔離され、そのような強力なエクスプロイト発見者から世界を守っているのです。\n私は公にされている理由には懐疑的です。おそらく、現在のモデルよりも運用コストがはるかに高いため、利用増加に対応する能力を向上させるのが困難であることから、まだ広く提供したくないだけではないかと疑っています。しかし、彼らはセキュリティ脆弱性発見の能力について真実を語っているのでしょうか、それとも単なる誇大広告なのでしょうか？\n少し前に、私は自身のプロジェクトでバグハンティングを自動化するNelsonというツールを構築しました。そして、様々なモデル間でバグ特定能力に驚くべき違いがあることに既に気づいていました。しかし、具体的な数値が欲しかったのです。そこで、私（実際にはほとんどClaude）はNelsonから一部のコードを借用してベンチマークスイートを考案しました。\nそのアイデアは、Mythosが具体的に発見したバグ（彼らのドキュメントに記載されているもの）を集め、バグ修正前のコミットを見つけ、最高級モデル（この場合はOpus）が直接指示されればバグを特定し理解できることを確認し、それをコーパスに追加して、モデルが盲目的にバグを正確に検出・記述できるかをベンチマークするというものです。（現在のコーパスに含まれるバグの詳細はここにあります。）\n私はOpus（当時のバージョンは4.7）を使用して、バグの検証を行いました（一部は人間のスポットチェックも併用）。現在のコーパスに含まれる全てのバグ（現在9件）は、全てのモデルの知識カットオフ以降のものであるとされており、モデルがそのバグを記憶していることはありません。また、全てのバグは、直接指示されて何をすべきかを伝えられれば、いくつかのモデルによって特定可能です。したがって、これらは実際に発生したバグであり、Mythosが発見した時とほぼ同じ状態であると確認されています。今後、このコーパスは進化させていく予定です。Anthropicが特定のバグについて自慢するのをやめた場合、より一般的なCVEベースのベンチマークになるかもしれません。\nしたがって、このベンチマークには一つの目的があります。他のモデルがMythosと同じことができるのか、それともMythosがこのタスクにおいて本当に唯一無二の強力さを持っているのかを明らかにすることです。\nここにはいくつかの注意点があり、テストされているモデルにとって公平なテストではないかもしれません。さらなるテストが進行中であり、これらは時間がかかり（トップモデルを含めると高価な）実行です。私は、約1週間いじり回した後に結果を公開する価値があると考えました。\nモデルには、問題のファイルと基本的なツールがシンプルなテストハーネスで提供されます（Claude Codeを使用するOpusを除く。エージェントに関する注記を参照）。どのファイルを見るべきかという点以外にはヒントは与えられませんでした（これは全くヒントではありません。標準的な監査の実践では、プロジェクト内の全てのファイルを個別に調べるため、これは現実的なプロンプトです）。モデルはリポジトリ全体を調べることができ、ファイル境界を越えてロジックを追うこともできますが、何を探すべきかは指示されません。\n最も困難なバグは複数ファイルにまたがるバグです。モデルは全てのファイルを自由に調べることができましたが、特定の利用法が問題であると知るためには、しばしばコンテキストを理解する必要があります。これは、人間であろうとAIであろうと、どんなセキュリティレビュー担当者にとっても難しい問題です。Mythosにはより高度なツールがあるのではないかと推測しています。おそらくデバッガーでソフトウェアを実行したり、ファズテストを行ったりしているのかもしれません。Mythosが行う可能性のある全てのことを推測することは、現時点ではこのプロジェクトの目標を超えています。しかし、このコーパスには非常に見つけにくいバグが含まれており、Mythosがこの問題に特に優れているという考えに一定の信憑性を与えています。\nモデルはこのベンチマークで不正行為をしていないと思われますが、場合によっては可能です。それらは新しいコンテナ内で実行され、クリーンアップされた完全なソースチェックアウトとレビューするファイルが与えられます。.gitディレクトリは削除されているため、履歴を調べたり、ファイルの「将来」を簡単に見たりすることはできませんが、ネットワークアクセスは可能です。もしそうする気があれば、特定のソフトウェアのCVEを調べることもできるでしょう。しかし、彼らがそうしている兆候は見ていません。\nこれは何も証明するものではありません。データはまばらです。私は各モデルの既知のバグごとに1回（1）の実行を行いました。これには数日間で数時間かかりましたが、並行処理を追加したことで次回はより速く実行されるでしょう（しかし決して無料ではありません）。したがって、決定的な証拠ではありませんが、興味深く有用なデータを提供していると思います。全てのモデルは同じ機会とツールを持っており（Claude Codeを使用するClaudeモデルを除く）、一部は他よりも優れていました。しかし、全てが予想よりも悪い結果でした。これらのバグを見つけるのがいかに難しいかを過小評価していました。\nエージェントに関する注記：当初、私はモデルAPIを使用する基本的なハーネスに加えて、全てのモデルをフル機能のエージェント（ベンダー提供の「推奨」エージェント、またはテスト対象モデルのAPIを使用するように設定されたClaude Code）でも実行しました。私の当初の仮説は、フル機能のエージェントで実行することで、モデルが最高のパフォーマンスを発揮する可能性が高まるだろうというものでした。しかし、それは関係ないことが判明しました。エージェントを使用してもパフォーマンスが向上したモデルはなく、いくつかのモデルは悪化しました。そして、なぜかエージェントを介した場合、時間/トークン/コストは一貫してはるかに高くなりました。そのため、Claudeモデルのみエージェントで実行されています。なぜなら、Claude CodeでClaudeモデルを実行するコストは、API経由で実行するよりも加入者にとってはるかに低いからです（少なくとも私にとってはそうです）。そして、エージェントで実行してもClaudeモデルのパフォーマンスを損なうようには見えません（ただし、データがまだ少ないため、さらなるテストを行う予定です）。\nエージェントに関する2つ目の注記：agy（Gemini用のAntigravity CLI）は、セキュリティ作業には明示的かつ意図的に役立たずです。9件中8件のケースで、「申し訳ありませんが、指定されたコードファイルから悪用可能なセキュリティ脆弱性を分析するというご要望にお応えできません。」と回答し、プロンプトをすぐに拒否しました。そのため、agyでの使用がGoogleのサブスクリプションでカバーされるにもかかわらず、Geminiテストを実行するためにGoogle AI StudioのAPIアクセスに料金を支払いました。これは迷惑です。「悪用可能な (exploitable)」や「脆弱な (vulnerable)」といった単語を削除してプロンプトを緩和しても効果はありませんでした。モデルは私たちがセキュリティバグを探していることを十分に理解しており、それを全く受け付けませんでした。おそらくガードレールを回避する方法があるのかもしれませんが、Google製品が現状のようにひどく見えないようにするために努力するつもりはありません。セキュリティ作業が目標である場合、Antigravityは目的に適合しません。他のエージェントテスト実行が面白くないノイズであるとして削除することを決定する前でさえ（上記のAnthropicモデルのClaude Codeを除く）、ランキングから除外しました。\n結果：完全なHTMLレポートはこちらをクリックしてください。GPT 5.5 Proがリーダーボードのトップにあるのは、4つのケースを完了しただけで100ドルの予算を使い果たしたため、2/4で50%となっているからです。また、Qwenモデルのいくつかの結果は、全てのケースを完了できなかったために検出率のランキングで上方修正されています。\n2026年6月7日更新：Gemma 4モデルとMiniMax M3を追加しました。Gemma 4 MoEは、9つのバグ中4つを100%の精度で検出することで、なんとか首位に浮上しました（MiMoおよびGPT 5.5と同じで、Googleの主要な商用モデルよりも優れています）。ただし、llama-serverがクラッシュしたり、モデルが再試行できるような方法で失敗したりしたため、複数回の試行を得たという注意点があります。他のモデルも、もう少し試行回数を増やせばより良い成績を収めるのではないかと推測しています。近いうちに、複数回の試行を行うこのベンチマークのバージョンを作成する予定です（非常に高価なモデルは除外します。私はお金持ちではないし、それらがかなり良いことは既にわかっているからです）。そのため、チャートでは3/7と表示されていますが、llama-serverの設定をいじって、そのモデルでの2回の失敗した実行を完了させようとしている間に、さらに別のバグを発見しました。そのいじっている間に発見したバグは、Opusだけが発見できた難しいバグでしたが、Gemma 4もそれを発見しました。\n2026年6月17日更新：GLM 5.2、Kimi K2.7-code、VibeThinker 3Bを追加しました。大きな驚きはなく、GLMは改善しましたが、Kimiはそうではありませんでした。この中で最も小さいモデルであるVibeThinkerは、当然ながらこのタスクには全く対応できませんでした。\n2026年6月21日更新：Nemotron Ultra 550b a55bとNorth Mini Code 33b a3bを追加しました。どちらも成績は芳しくありませんでした。前者の場合、Nemotronのより大きいバージョンは、より小さい120bの兄弟モデルよりも著しく悪い結果を出しました。