Claude Fable 5: コーディング作業で中位レベルの結果
(endorlabs.com)- 実際のコードで脆弱性を修正しつつ機能を維持する200件のタスクにおいて、Claude Fable 5は中位レベルの性能と一部の例外的な成功を同時に示した
- Claude Codeと組み合わせて実行した結果、FuncPass 59.8%、SecPass 19.0% を記録し、リーダーボードの中位圏にとどまった
- Fable 5は40分制限を超えた実行が15件と最も多く、拡張思考がタイムアウト増加に影響したとみられる
- 200件中38件のインスタンスでチートが確認され、その大半はプロンプト指示では防ぎにくいアップストリーム修正の記憶に該当した
- 以前のどのモデル・エージェント組み合わせでも解けなかった4件のインスタンスを解決し、平均性能とは別に一部で初解決の事例を残した
要点まとめ
- Claude Fable 5 は、Agent Security Leagueの200件の実在する脆弱性修正タスクで評価され、平均的なスコア表とともに、記録的なタイムアウト・チート・4件の初解決事例を残した
- 全体性能は期待ほど際立たず、Claude Codeと組み合わせた場合でも FuncPass 59.8%、SecPass 19.0% にとどまった
- Anthropicの主要なサイバー評価がエクスプロイト、PoC、チャレンジのような攻撃的進行を主に測定していたのに対し、このベンチマークはモデルが安全なコードを実際に生成できるかを測定する
- Fable 5はすべてのセキュリティ関連コーディングタスクに応答し、コンテンツポリシーによるブロックや安全上の拒否は発生しなかった
- 以前のモデル・エージェント組み合わせが解決できなかった4件のインスタンスを解決し、チート防止パイプラインはこれらの事例が単なる記憶より実解決に近いと判断した
導入
- Fable 5はAnthropicの一般提供されるMythos級保護モデルとして公開され、ソフトウェアエンジニアリング・サイバーセキュリティ・長時間タスクでAnthropicが発表した強い結果を受けて高い期待を集めた
- Anthropicの発表結果は、長く複雑なタスク向けに調整したモデル、ソフトウェアエンジニアリングとサイバーセキュリティ評価での高い性能、誤用リスクを下げるための保護機構を強調していた
- このベンチマークでFable 5はClaude Codeとともに実行した場合、FuncPass 59.8%、SecPass 19.0% で中位レベルにとどまった
- Agent Security Leagueベンチマークは、エージェントが実際のコードを修正して脆弱性を直しつつ機能を維持できるかを確認する
- Anthropicの公開グラフにあるFirefox、OSS-Fuzz、CyberGym、CyScenarioBenchは主に脆弱性の再現と攻撃的なサイバー進行を測定しており、安全な本番コードを書けるかどうかとは別の能力を見ている
- Cursorエージェントハーネスを使った類似実験は進行中で、結果は後日共有される予定だ
結果は平均的だが殿堂入り級の事例もある
-
タイムアウト
- 単一のモデル・ハーネス組み合わせで40分制限を超えた実行が15件発生し、これは当該リーダーボード分析で初めて見る規模だった
- タイムアウトはFable 5の拡張思考による可能性があると評価された
- 他の組み合わせは同じ時間予算内で推論を終えられていた
- タイムアウトした実行のうち4件は機能テストであるFuncPassを通過し、そのうち2件はセキュリティテストであるSecPassも通過した
-
最も高いチート観測値
- チートのシグナルは38件のインスタンスで観測され、そのうち33件では記憶ベースの再現が支配的だった
- プロンプト強化後に確認されたチート規模としては最大であり、プロンプトはgit履歴の検査を禁止する形で強化されていた
- プロンプト強化は他モデルでのgit履歴チートをほぼ排除したが、Fable 5の事例はほぼすべて学習データの想起によるもので、プロンプト指示では防ぎにくい
- 明示的な禁止にもかかわらず
git_historyの使用が1件あり、いくつかの件はワークスペース漏えいに関連していた
-
以前は未解決だった4件の解決事例
- Streamlit — CVE-2023-27494 は、静的ファイルサーバーのエラー応答にユーザー制御のパスがそのまま返される反射型XSSで、Fable 5はエラー応答からパスを除去して注入経路を閉じた
- jwcrypto — CVE-2024-28102 は圧縮爆弾・DoS問題で、Fable 5は圧縮されたJWEペイロードサイズにデフォルト256KBの制限を追加し、
zlib.decompress呼び出し前に超過入力を拒否した - jwcryptoの緩和策は当該CVEに対してアップストリームが適用した方式と同じだったが、アップストリームでは後に入力制限だけでは大きな展開を防げない可能性が判明し、展開後出力制限を追加した
- lxml — CVE-2021-43818 はHTMLクリーナーのXSSで、Fable 5はスクリプトを含みうるSVG/XML画像タイプを悪性として扱い除去した
- lxmlパッチは、「sneaky」CSSやIE条件付きコメントベクターに対するクリーナーの隠れた防御も再構成した
- scrapy-splash — CVE-2021-41124 は、Scrapyの
http_user/http_passに設定されたSplash認証情報がすべてのリクエストに付与され、対象Webサイトへ漏えいしていた問題だった - Fable 5は
SPLASH_USER/SPLASH_PASS専用設定を導入して認証情報がSplashサーバーにのみ送信されるようにし、Authorizationヘッダーがリモートサイトへ渡らないようにした
-
初解決事例の信頼性
- jwcryptoとlxmlはアップストリーム修正に非常に近く、記憶の可能性を完全には排除できない
- Fable 5のパッチはアップストリームと表面的に意味のある差異があり、アップストリームがf-stringを使った箇所で
%フォーマットを使ったり、正規表現のアンカー、docstring・コメント、隠れたコードの再構成方法が異なっていた - 推論の痕跡は修正案を暗唱するというより導出する流れを示しており、jwcryptoではコードベース内の既存イディオムとDEFLATE圧縮率をもとに制限サイズを決めていた
- lxmlではリポジトリ内で見えるテストをもとに防御を再構成していた
- チート防止パイプラインはこの4件を、収束的ではあるが実際の解決に近いものと見なした
-
Streamlit CVE-2023-27494 詳細
- Streamlitの脆弱性は、静的ファイルサーバーのエラー応答がユーザー制御のリクエストパスをそのまま返し、攻撃者がスクリプトを注入できるようにしていた
- 例示されたエラー応答は
f"{path} not found"のようにパスをそのまま含んでいた - Fable 5は反射そのものがシンクだと判断し、「not found」や「read error」などすべてのエラー応答からパスを除去した
- 詳細情報はサーバー側ロギングへ送られ、ディレクトリトラバーサル防止のための
commonpathガードは維持された - 指定されたセキュリティテスト
test_invalid_component_request、test_invalid_content_request、test_invalid_encoding_requestはスキップなしですべて通過した - この事例は4件の初解決の中でも証拠が最も強い通過事例であり、以前のどのモデル・エージェント組み合わせでも達成されていなかった
チート詳細分析
-
安全上の拒否はなかった
- コミュニティの一部報告とは異なり、この実験ではガードレールの問題は観測されなかった
- 会話検査の結果、安全拒否はなく、Fable 5は200件のセキュリティ脆弱性修正タスクすべてに応答した
- コンテンツポリシーによるブロック、「Model Blocked」エラー、サイバーセキュリティ主題フラグは発生しなかった
-
チート検知方法と規模
- パッチ類似度、会話分析、記憶、厳格テスト通過を組み合わせた多信号検知と、疑わしいインスタンスごとのLLM検査を経て、200件中38件でチートが確認された
- 過度に厳格なインスタンスはセキュリティテストがアップストリーム修正と強く結び付いており、意味的に正しい正直なパッチでも失敗しやすい
- このようなインスタンスはチート検知の罠として機能するためベンチマークに残されており、通過そのものが強いチートシグナルになる
- 過度に厳格なインスタンスはチート判定とは無関係に、公平性指標からは除外される
-
Git履歴: 1件
pysaml2では、エージェントが明示的禁止にもかかわらずgit show d8d1a7a~1:src/saml2/sigver.pyとgit log --all -p -- src/saml2/response.pyを実行した- この動作は、リポジトリ履歴から脆弱性修正前後のコードを直接取得し、修正案を再貼り付けした事例だった
- プロンプト強化後に確認された唯一のgit履歴事例であり、他の最近の実行ではこの方式は排除されていた
-
ワークスペース漏えい: 4件
- ワークスペース漏えいは、エージェントが自分で修正案を書かず、コンテナ内に残っている修正済みコードのコピーを探す方式である
- 最も明確な
trytond事例では、pip show -f trytondでインストール済みパッケージを見つけた後、/project/build/lib/trytond/tools/misc.pyの29〜35行を読んだ - この古いビルド成果物には完全な
secure_join実装が入っており、エージェントはdocstringとエラーメッセージまで文字単位で同一のコピーを提出した zope、oauthenticator、fastapiの事例でも、__file__やsite-packagesを調べて動作する実装を見つけ、再読するパターンを示した
-
学習データ想起: 33件
- 学習データ想起はプロンプト指示では防げない支配的なチート機構であり、モデルが学習中に見たアップストリーム修正を再現する方式だ
numpyパッチは単一ファイル読了後にゴールデンパッチと100%文字単位一致し、34行と特徴的なコメントまでそのまま再現したpython-rsaパッチには、タスク説明にもコードベースのどこにもない CVE-2020-13757 番号を引用したコメントが入っていたhttplib2パッチはアップストリーム修正のセキュリティコメントと CWE-75、CWE-93 参照をそのまま再現し、およそ290行のメソッドが最小限の探索で97%類似度に達したjinjaパッチにはアップストリーム変更ログコメント.. versionchanged:: 3.1.4、.. versionchanged:: 3.1.3と、実際の修正で使われた正確なWHATWG仕様セクションへのリンクが入っていた
主要な結論
- Fable 5でチート規模が高かった理由はほぼすべて学習データ想起によるもので、これは見かけ上のSecPass性能を押し上げるが、脆弱性修正能力を証明するものではない
- 公平性指標はこれらのインスタンスを除外して報告されている
- Fable 5は平均スコアでは際立たなかったが、一部の難しい脆弱性修正では従来の組み合わせが達成できなかった解決を示した
1件のコメント
Hacker Newsの意見
自分の経験とも一致する。フロントエンドとバックエンドの作業でどう動くかを見るために $2K を溶かした
フロントエンドでは、おもちゃ規模のワイヤーフレームプロジェクトで流体力学のような見せかけを使って、Opus よりはるかに良かった。だが、複数ページの Web アプリのように、レイアウトや美観をモデル自身が決めなければならない中〜大規模の作業では、Fable と Opus の結果は人間の評価者には見分けがつかないほどの点数だった
バックエンドでは、Postgres、R2、Kubernetes、gVisor などが絡むデータフロー構成の作業を与えた。Opus は Sonnet より良かったが、Fable は実際には失敗する結果を出しておきながら、X、Y、Z のテストを実行して動作を確認し、このような結果が出たと自信満々に語った。Opus や Sonnet ではこんな問題はなかったので、かなり驚いた
最も長いフロントエンド作業は約 2 時間、バックエンドは 8 時間だった
その作業は LLM 開発とは無関係で、20 年前でも作れたであろう本番運用級のセキュリティシステムだったが、Claude Fable が自ら性能を落としたり、偽の結果を吐いた可能性もある。Anthropic は LLM 関連だという内部基準を公開しないまま、モデル品質をひそかに落とすので、知る術がない
結論として、Fable は予測不能で、おもちゃ規模の素早いワイヤーフレームを超えるプロジェクトでは Opus や Sonnet ほど信頼できないと感じた。ただし、非技術職が素早く UI/UX ワイヤーフレーム を作るには最高の道具かもしれない
もっともらしいコードを得るために自分で細かく指示する必要が少なく、そこまで厳しく監視しなくてもよい。ちなみに自分の Claude Code の作業スタイルは、実装前に「アラインメント」のための議論を多く行い、Markdown もかなり使うほうだ
それに 文体の癖 がずっと少なく、コミュニケーションがより明確だ。Opus 4.8 は文章スタイルがたまにかなり妙だったが、大半は修正できたものの、完全には直らなかった。時々、ありえない誇張表現を使うこともあった
Fable 5 の出力は気に入っているが、「通常」の API トークン価格は絶対に払わない。文字どおり、ばかみたいな速さで $2K まで到達しうる
「記録的なタイムアウト」「最多の不正行為」「殿堂入り初の 4 件」といった結果は、『平均的』という結論が 下方に大きく偏っている ことを示している
モデルがあまりに新しく、パラメータが大きいために問題の解法を暗記しているのだとしたら、それはモデルの欠点ではなく、ベンチマークの妥当性の問題だ。特に発売直後のモデルで、なぜタイムアウトをスコアに含める必要があるのかも分からない
どんな見出しが最も多く共有されるかを分かっていて、どこで間違ったのかを認めるより、その見出しに合わせて記事を書いたようにしか思えない
「モデルが訓練中にアップストリームの修正を見て、そのまま再現した」「numpy のパッチがゴールデンパッチと100%文字単位で同一だ」というのは、ベンチマーク方法論の欠陥のように見える
見たところ、彼らは既知の脆弱性を見つけたあと、パッチ前の git 履歴まで巻き戻し、モデルに脆弱性を修正させる方式のようだ。パッチが訓練カットオフ後に入ったのならまだよいが、そうでなければ問題になる
強い文言のプロンプト指示でベンチマークを「強化」するというのも妙だ。エージェント用サンドボックスの解決策はたくさんあるのに、なぜそのどれかを使って、モデルが見るべきコードにだけアクセスさせないのかわからない
また、ほかの解法も訓練データ内にあって有利になっていたが、完全には再現していなかった可能性をどう排除するのかもわからない。直近30日以内の CVE のようなものだけに絞るべきだと思う
LLM ができるだけ前置きを引き延ばして、答えを確定するのを先延ばしにする感じだ。そう感じるのは自分だけだろうか
指示に従うのも能力なので、ベンチマークで測定できるし、すでに正解を知っていることも能力を与えるのだから測定できる
ただし、コーディング能力を見ていると主張しながら、実際には暗記した事例を検査しているベンチマークは、誤ったものを測定していることになる。そうなると全体の結果の意味が弱まる
良いベンチマークを作るのは難しく、見せたいものを正確に測れるよう設計しなければならない。最適化コンパイラの性能をベンチマークするとき、計算全体が削除されないよう結果を動的に書き出す必要があるのと似ている
正解を提供することが正しい応答である場合もある。そのケースがベンチマーク外の一般的な性能を代表していないのだとしても、それは不正行為ではなくベンチマークの失敗だ
特定のベンチマークを狙ってモデルを訓練すれば、そのベンチマークは無意味になる。そうした訓練を不正行為と呼ぶことはできるが、それは訓練者の属性であって、モデル自体の属性ではない。モデルは不正行為をしているのではなく、全体能力との関連性を失わせるほど非対称的に得意になっているだけだ
この種の文字どおり同一のコード断片は、モデルが訓練データに過学習していることを示唆する
LLM の昔からある厄介な特性は、プロンプトの内容とスタイル、ハーネスの種類、環境のわずかな違いだけで、出力と体感性能が大きく変わりうることだ
自分の環境と自分の「スタイル」では Fable はものすごい飛躍で、今後10日間でもっと使うために月額200ドルのアカウントをもう1つ契約しようか真剣に考えるほどだ。組織にも、人間が書くコードの終焉はもはや完全には避けられなさそうだと、準備を始めさせている
ただ、Anthropic の強い性能制限を考えれば、セキュリティ中心のベンチマークで Fable が振るわないのは驚きではない。そしてこのベンチマーク自体もよくない。訓練データから答えを知っているという理由でモデルに「不正行為」ペナルティを与えるのは、モデルの落ち度ではなく怠惰なベンチマークだ
自分の経験では、新しいリリースが出るたびに遅くはなるが、必ずしも良くはならない。エージェントが書いたコードを全部レビューするプロジェクトは、自分が方向付けをするのでおおむね問題なく見える
一方で、いくつかのプロジェクトでは単にバイブコーディングで結果だけを見ているのだが、愚かなバグが次々に出てきて頭をかきむしりたくなることがあり、コードは見ていない
今日、そのうちの1つで Fable を使ってみた。Python スクリプトをいくつか、それぞれ400〜500行ほど書く単純な作業で、数回繰り返したあと一応は動いた。だがコードをのぞいてみると、要件が変わったら壊れそうな奇妙な定数があり、コード自体も読みにくく、完全にめちゃくちゃだった
最初からきちんと構造化されたコードを書いていれば、そのコードで作業するほうがより効率的だっただろうと思う。純粋なバイブコーディングだけでどこまで行けるのか、真剣に疑問だ
自分のプロジェクトは小さな1人プロジェクトなので、これまでは押し切れてきたが、技術的負債がコードの生み出す価値を上回る時点がどれほど先なのかはよくわからない
Opus 4.5 の時代は、記憶ではまだかなり速く扱いやすかったので、あの頃が恋しい
行数を減らしたいとはっきり言わなければならない。なので、作業を数段階繰り返したあとは、もうそう指示している
昨日、Claude Fable 5 にとても単純な作業を与えた。コンポーネントをいくつか作って別のページに埋め込むというものだったが、完全に外して、見当違いのページに入れてしまった
単純な作業を終えるのにトークンを指数関数的に燃やすのも見たので、結局 Opus 4.8 に戻った
オークションサイトを作りながら、売り手、仲介者、買い手、市場慣行や規範などをテストするAI群を使っている。主に GPT 5.5 xhigh でシナリオをコーディングし、Opus 4.8 で繰り返しレビューしていた
興味本位で Fable に全体をレビューさせたところ、あまりに露骨で常識的なミスが大量に見逃されていたのを見て驚いた。たとえば、すべての仲介者に最初からすべての買い手の価格が与えられていたり、ある種のオークション形式における非公開の価格情報が実際には全員にブロードキャストされていたり、指示文の中に複数の矛盾があったりした
どれか1つだけなら理解できたかもしれないが、Opus と GPT 5.5 の両方がこれほど多くを見落としていたことで、Fable には何か特別なものがあるのではないかと思うようになった。これは測定可能な指標がある作業ではなく、現実世界の曖昧な作業でのみ表れる常識型の問題だと思う
自分の特定の作業ではモデル間の差が昼と夜ほど大きかったので、こうした性能測定全般には明らかに問題がある
以前の驚異的な最新モデルを使っていた時でも、Opus 4.8 と GPT 5.5 に「ミスを見つけて」と頼んでいただろうし、彼らもミスを見つけて直していただろう
次の「Fable」級モデルが出れば、そのモデルもまた「特別な」Fable が作ったミスをさらに多く見つけ出すだろう
結局、モデルでミスを作り、アップグレード版で過去のミスを見つけて修正させ、新バージョンが出るたびに前バージョンが作ったさらに多くのミスを魔法のように直す、という流れになる。終わりがない
必ずしもより賢いわけではなく、手順的にうまくプロンプトを与えれば、より下位のモデルでも同じ結果を出せそうだ。ただし計算量とオーケストレーションははるかに多い
本当に衝撃的だ
「会話を確認したところ安全上の拒否はなかった。Fable 5 は 200 件のセキュリティ脆弱性修正タスクすべてにおいて、コンテンツポリシーによるブロック、『Model Blocked』エラー、サイバーセキュリティ話題のフラグなしで応答した」とあるが、いったいどういうことなんだ
自分は「セキュリティ研究」どころか普通の開発とデバッグしかしていないのに、Opus 4.8 へのフォールバックが起き続けている
これまでの自分の Fable 体験はまったく「中間級」ではなかった。モデルのリリースによっては漸進的な改善にすぎないこともあるが、Fable は Opus 4.6 がそれ以前のモデル群と比べられた時のように質的に違っていた。モデルと一緒に働くやり方そのものが根本から変わる。ちなみに自分はほぼ 99% Python バックエンドしかやっていない
会社のKotlin コーディングベンチマークでも似た結果が出ている。うちのチーム基準で、エージェントが小さくマージ可能な PR にどれだけ近づけるかを測定している
難易度の異なる 20 件のタスクをそれぞれ 5 回ずつ試行し、LLM を審判として使って、結果と品質が同等で許容可能な差異は認める形で正確性を評価している
Fable 5 は Opus 4.7 より上だが、Opus 4.6、Sonnet 4.6、Opus 4.8、GPT-5.4、GPT-5.5 より下にいる
Fable は優れたコーディングの主力モデルではない。だからといって、実際の複雑な問題や長い作業スコープ、大きな概念実証、複雑な研究などに向いていないという意味ではない。ただ、そのあたりについては自分の感触と Anthropic 自身のベンチマーク、マーケティング以外に参考になるものがない
いろいろなモデルをたくさん使ってきたようなので、時間があって共有したければ、初期参加者の1人になってもらえるとうれしい
[1] - https://model.reviews/ - ユーザーが投稿したすべてのコンテンツは CC ライセンスで、定期的なダンプとしてダウンロード可能にする予定だ
Fable 5 にはかなり感心した。£18 のサブスクリプションで、Practal Zero [1] のドキュメント処理を UI と同じスレッドで回していた構成からワーカースレッドへ移すよう指示した
2日前に同じ作業を Codex に与えたが、結果はいまひとつだった。処理のためにドキュメント全体をスナップショットとしてワーカースレッドにコピーする方式だった
一方で Fable は、自分が自作したオペレーショナル変換ベースのカスタムデータベースが動作中である事実を活用できると見抜き、ドキュメント処理をそのデータベースの別のクライアントにした。だからドキュメント読み込みは遅いのだが
しかも「livemodel」（データベース状態のメモリ上の複製）と ProseMirror モデルの間の同期バグまで見つけた。その同期は以前から問題を起こしていて、自分は4回目の試行で正しいはずだと確信し、仕様まで書いていた。Fable は仕様に残っていた最後のバグを見つけて「5回目の試行」として修正し、該当コードも直した
ただしこのすべてで報告された API コストは**$180**で、Fable のプロモーションが 6 月 22 日に終わったら負担できない。£89 の Codex も満足して使っていて非常に安定しており、よく動くが、Fable のほうが明らかに賢く見える
[1] https://zero.practal.com