自社コードの穴探しで「Mythos」と「Fable」を比較　7題材中7対4

SAGUSは11月14日、自社のWeb製品2つのコードを題材に、米Anthropicの「Claude Mythos 5.2」と「Claude Fable 5.2」に脆弱性を探させた結果をまとめた。7つの題材を各モデル3回ずつ解かせると、3回のうち1回でも見つけた題材はMythosが7つすべて、Fableが4つだった。Fableが3回とも見落とした3題材を、Mythosはすべて見つけている。かかった時間とトークンはほぼ同じだった。ただし題材は7つ、試行は各3回で、Mythosが上とは言えても、何割上とまでは言えない。

同じ基盤で守りの強さが違う

Anthropicは11月9日、2つのモデルを同時に公開した。Fable 5.2とMythos 5.2の発表によると、Mythos 5.2は同社で「サイバーセキュリティの作業に最も強いモデル」で、そのサイバー面の能力は「Cyber Verification Program（CVP）」という審査の制度を通して使う。同じ日に出たFable 5.2には、この審査が要らない。発表によると、2つは同じ基盤のモデルで、Fableにはサイバーセキュリティと生物の分野の悪用を防ぐ強い守りが付く。Fableの守りはサイバーセキュリティの作業の多くを止め、止めた時はOpus 4.8が代わりに答える。

CVPには組織だけでなく個人も申請できる。発表によると、CVPに入っていない「Claude Enterprise」の顧客も、Anthropicの「Claude Security」は使える。CVPの説明ページによると、守りの用途の枠「Defense Access」で許されるのは、セキュリティの運用、セキュリティインシデントへの対応、マルウェアの解析、検知の設計、脆弱性の選別と検証だ。既定では社内での利用に限られる。SAGUSはこの枠で、自社の製品の脆弱性を選別し検証する用途に絞って使った。攻撃のコードは書かせていない。

開発者にとっての問いは単純だ。公開前の点検を任せるモデルを、誰でも使えるFableから、手続きの要るMythosに替える価値があるか。自分のコードでの差は、測らないと分からない。そこで自社のコードで測った。

穴を仕込んで3回ずつ解かせる

題材は、案件管理の製品と、週末の外出先を探す公開中の製品の2つから作った。過去に本当にあって直した穴の直前の状態が1つ、1〜3行の変更でわざと穴を入れた「仕込み」が6つで、合否を付けるのはこの7つだ。仕込みは、GitHubに書き出す前に非公開のリポジトリかを確かめる処理を外す、データベースの行の読み取りの権限を広げる、といった変更にした。

モデルには、ファイルを読む道具（Read・Grep・Glob）だけを渡し、外への通信はさせない。社内の決定の文書とテストは渡さなかった。既知の制限の説明や、元の振る舞いを期待するテストが答えになってしまうためだ。依頼文も観点を挙げず、「製品全体を見て、影響の大きいものから挙げる」とだけ書いた。

採点はコードで行う。指摘のファイルが正解と合い、本文に穴を表す語があれば「見つけた」とする。正解に行の指定があり、指摘のファイルが正解の主なファイルと一致する時だけ、行が正解から20行以内であることも求める。1回でも見つけた題材の数（pass@3）と、3回とも見つけた題材の数（pass^3）を数えた。推論の強さはどちらも既定のままにした。

Fableは3題材を3回とも逃した

pass@3はMythosが7題材中7、Fableが4だった。3回とも見つけたpass^3は5と3になる。Fableが3回とも見落としたのは、過去の本物の穴（URLの書き方を変えると、集計画面を守る判定を素通りできた）と、先の非公開の確認を外した仕込み、権限を広げた仕込みの3つだ。Mythosはこの3つを9回とも見つけた。

一方で、Mythosが全勝したわけではない。分析用の外部サービスに送るURLから検索条件を除かない仕込みは、Mythosが3回中1回、Fableが3回中2回で、Fableの方が多く見つけた。Mythosは見つけた穴の重さの判定も外している。非公開の確認を外した仕込みと権限を広げた仕込みでは、重さが想定と3回とも合わなかった。過去の本物の穴では、脆弱性の分類番号（CWE）が、必須の穴3件と付随の穴5件の延べ8件とも想定と合わなかった。

穴を仕込んでいない題材も含む9題材、各モデル27回で集計すると、1回あたりの時間はMythosが平均334秒、Fableが341秒だった。キャッシュの読み込みを除くトークンは、どちらも約27万で差がない。両モデルで計54回の実行はすべて最後まで終わり、答えの形が崩れた回も1回もなかった。

見逃しを減らす代わりに手続きが要る

つまり、費用と時間では差が出ず、見つけた穴の数で差が出た。同じ時間とトークンで、Fableが一度も見つけられなかった穴をMythosは毎回見つけている。発表のとおり2つが同じ基盤のモデルなら、この差はFableの守りから出た可能性がある。ただし、守りが働いた回は切り分けていない。公開前の点検は、1回の見落としがそのまま本番の穴になる仕事だ。

ただし、Mythosを使うには審査を通る必要があり、使える用途にも線がある。CVPのページによると、12月15日からDefense Accessでは、フィッシングに強い多要素認証が必須になり、静的または長期有効なAPIキーは使えなくなる。自動で回す点検の仕組みに組み込むなら、この変更に合わせた認証の作り直しが要る。

誤検知は、穴を仕込んでいない2題材（2製品の今の状態）で数えた。SAGUSの代表がモデル名を伏せた指摘の一覧を目で確かめ、別のAIがその判定を検証した。指摘はMythosが19件、Fableが23件で、「穴ではない」とした指摘はどちらも0件だった。動いているかなどの前提を確かめきれない指摘は保留にして、率の分母から外した。保留はMythosが4件、Fableが7件で、残りの15件と16件は、穴として扱うべき指摘だった。ただし、そのうち重さの判定が想定と違った指摘が、Mythosに1件、Fableに3件あった。

編集部の見方

編集部は、公開前の脆弱性の点検に限れば、手続きの手間を払ってでもMythosに替える価値があると見る。同じ時間とトークンで、Fableが3回とも逃した3題材をMythosは9回とも見つけた。差の元がFableの守りでも、使う側の結果は同じだ。ただし、重さの判定と分類番号はMythosでも外れたので、人か別のモデルが重さを付け直す前提で使うのがよい。題材が7つと少ないため、自社のコードに穴を仕込んで同じ比べ方を試すとよい。どちらのモデルも穴でない指摘を出さず、誤検知の面で替える妨げは見当たらない。保留の指摘を確かめると、数字は変わり得る。