「Claude Fable 5」の実力は？コーディングタスクでの検証結果を速報！

注目の「Claude Fable 5」ですが、実際のコーディングタスクで試してみたところ、良くも悪くも「中堅レベル（mid-tier）」という評価に落ち着きました。期待値が高かっただけに、少し複雑な実装やエッジケースでの挙動には改善の余地がありそうです。

「最も支配的なメカニズムであり、どんなプロンプトの指示でも防げないもの。それは、モデルが単に学習中に上流の修正コードを見ており、それを再現しているだけという点だ…」

numpyについて言えば、そのパッチはゴールデンパッチと100%文字単位で一致している。例えば「'reflect'のためにシングルトン次元を拡張するのはレガシーな挙動であり、本来はエラーを投げるべきだ」といった独特なコメントまでそのまま再現されていた。

これ…ベンチマークスイートの手法の欠陥じゃないかな。僕が見る限り、彼らは既存のエクスプロイトを見つけ、gitの履歴をパッチ適用前に巻き戻し、モデルにそのエクスプロイトを修正するよう求めているだけだ。パッチが学習のカットオフ日以降に行われたものなら、それはそれで構わないんだけどね。

この体験、すごく共感できる。フロントエンドとバックエンドのタスクでどれだけ性能が出るか試すのに2000ドルも溶かしたよ。

フロントエンドでは、流体シミュレーションのようなギミックを使うおもちゃ規模のワイヤーフレームプロジェクトにおいて、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のラフを作るには最適なツールになり得ると思う。

仕事で使っている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はコーディングの主力としては優秀とは言えない。とはいえ、実際に複雑な問題や長期間のタスク（大規模なPOCや複雑な研究など）に向いていないという意味ではないよ。ただ、その点については僕個人の感覚と、Anthropic自身のベンチマークやマーケティング情報に頼るしかないんだけどね。

「記録的なタイムアウト回数。Fable 5の拡張された思考プロセスにより、我々がテストしたどのモデルとハーネスの組み合わせよりも多くのインスタンスでタイムアウトが発生し、直接的に減点対象となった。...過去最高の不正行為数。我々がプロンプトを強化して以来、200インスタンス中38件で不正を確認した。そのほとんどは学習データからの上流修正の記憶によるもので、どんなプロンプト指示でも防げない。...4つの殿堂入りの初達成。Fable 5はこれまでどのモデルとエージェントの組み合わせでも突破できなかった4つのインスタンスを解決しており、我々の不正防止パイプラインから見ても、これらは記憶によるものではなく純粋な解決とみなされる。」

これらすべてが示しているのは、彼らが主張する「平均」という指標が下方へ大きくバイアスをかけられているということだ。モデルが最新の情報を持ち、パラメーターが巨大であるために問題の解決策を記憶していることは、モデルの欠点ではなく（ベンチマーク自体の妥当性の問題であり）、なぜ（特に発売直後のモデルに対する）タイムアウトを減点対象にするのか理解できないね。

今、オークションサイトを作っていて、それをテストするためにAIスウォーム（売り手、仲介者、買い手、市場の慣習など）を使っている。ほとんどはGPT 5.5 xhighでシナリオをコーディングし、それをループさせてOpus 4.8でチェックするという手法をとっていた。

好奇心からFableに全部レビューさせてみたんだけど、衝撃的だったよ。当たり前すぎて無視しそうな初歩的な間違いがたくさん見つかったからだ。例えば：

• すべての仲介者が、すべての買い手の価格を事前に知らされていた
• 特定のオークション形式における非公開価格情報が、実際には全員にブロードキャストされていた
• 指示内の複数の矛盾

もし一つだけなら理解できたかもしれないけど、OpusとGPT 5.5の両方をすり抜けたものがこれだけあったということは、Fableには何か特別なところがあるんだと思う。これはコモンセンス的な話で、測定可能な指標がないような、現実世界の曖昧なタスクの時に初めて気づくものなんだろうね。

僕の特定のタスクにおいて、これらのモデル間の差が雲泥の差だったという事実からすると、既存の性能測定指標には明らかに問題があるよ。

Fable 5にはかなり感心している。18ポンドのサブスクリプションを使って、Practal Zero[1]のドキュメント処理をUIと同じスレッドで動かすのではなく、ワーカー・スレッドで動かすよう変更させたんだ。その2日前に同じタスクをCodexに与えた時は、結果があまり良くなかった。処理のためにドキュメント全体をスナップショットとしてワーカー・スレッドにコピーするというようなやり方だったからだ。Fableは、僕が自作したオペレーショナル・トランスフォーム（OT）ベースのカスタムデータベースを使っていることに気づき（だからドキュメントの読み込みが遅いんだよ :-))、ドキュメント処理をそのデータベースの単なるクライアントの一つにするよう書き換えてくれた。さらに、「ライブモデル」（データベース状態のインメモリレプリカ）とProseMirrorモデルの間を同期させる処理のバグまで見つけてくれたよ。その同期は以前から問題を抱えていて、自分で「4回目の挑戦」として仕様を書いて、「今度こそ正しいはずだ」と確信していたのに。Fableはその仕様の最後のバグを突き止め、「5回目の挑戦」として修正し、コードも直してくれた。

報告されたAPIコストを合わせると180ドルくらいになりそうだけど、6月22日にFableのプロモが終わったら僕には払えないな。89ポンドのCodexも満足して使っているし、信頼性も高くてとても優秀だけど、Fableは明らかに一段と賢い感じがするね。

[1] https://zero.practal.com

僕の経験だと、新モデルが出るたびに遅くなっている気がするし、必ずしも良くなっているとは言えない。エージェントが書くコードをすべてレビューするプロジェクトがいくつかあって、それは僕が軌道修正しているから概ねうまくいっている。一方で、結果だけ重視して雰囲気でコードを書かせて中身を見ないプロジェクトもある（馬鹿げたバグが絶え間なく出てきて、時々頭を抱えたくなる）。

今日、その雰囲気コーディングのプロジェクトの一つでFableを試してみた。400〜500行のPythonスクリプトをいくつか書かせるタスクだ。数回繰り返せば動くようにはなったけど、コードを確認してみたら、要件が変わった時にコードを壊しかねない（間違いなく壊れる）奇妙な定数が埋め込まれていた。コード自体も読みにくくてめちゃくちゃ。最初から構成のしっかりしたコードを書いてくれれば、後から修正する効率も上がるはずなんだけどな。

純粋な雰囲気コーディングでどこまでいけるか、真剣に考えさせられる。今のところは小さな個人プロジェクトだからなんとかなっているけど、技術的負債がコードの価値を上回る前に限界が来るのが目に見えている。

（僕の記憶では）まだそこそこ高速で扱いやすかったOpus 4.5の頃が懐かしいよ。

正直に言うと…AI LLMを活用した開発で僕が重視する真実は、Claudeはプランナーとして遥かに優秀で、Codexはよりプロフェッショナルなコーダーであるということだけだ。

適切な設計計画さえあれば、驚くほど酷いコードでもカバーできてしまう。

動けばいいんだろ？って話だよね。残念ながら、僕が覚えている限りソフトウェア開発の現状はずっとそんなもんだ。

昔はCodexにいらついていた。もっと先を見通して、僕の期待を直感的に汲み取ってくれる能力が足りない気がしていたからだ（Claudeだとそういう期待に応えてくれるように感じる）。

でも気づいたんだ。Claudeの直感の多くは素晴らしいし、プロジェクトは進むけれど、時々Claude自身もコントロール不能な状態に陥ることがある。その場しのぎの素晴らしい決断の連続が、実はその場しのぎでしかなかったという…それが一番いらつくんだよ。

もしClaudeに対して、長期的なプロジェクトのロードマップを練り上げ、それを遵守するように具体的に指示すれば、一晩でOSくらい書けてしまう（それっぽく動くものなら）かもしれないけどね。

「Anthropicの見出しとなるサイバー評価は、主に攻撃的な進捗（エクスプロイト、PoC、チャレンジ）を測定している。我々のベンチマークはモデルが実際に安全なコードを生成できるかをテストしており、そこではFable 5は際立っていなかった。」

このモデルはセキュリティについて考えることを許可されていないんだ。ここでも何人かが言っていたけど、もしセキュリティについて考え始めると――例えば関連するテストを書こうとすると――安全フィルターが反応してOpusにダウングレードしてしまう。

つまり、実際にはコードを安全にすることは許されていないんだよ。

その投稿は主にセキュリティの観点からコーディングについて話しているね。なるほど。

僕自身の（限定的な）テスト結果だと、Fableは（コーディング全般において）最も有能なモデルだけど、同時に最も高価だ。

ミニRTSを実装するという僕の「LLMCraft」ベンチマークでは、ほぼ満点だったよ：https://senko.net/vibecode-bench/2026/rts-fable-5.html （他のモデルのプロンプトと結果はこちら：https://senko.net/vibecode-bench/ ）

ただ、ワークフローと高い思考リソースを組み合わせると、とんでもない勢いでトークン（とお金）を消費する。

ほとんどのタスクには良すぎる（そして高すぎる）のかもしれない。単純作業には安いモデルを使って、重要な部分でFableを使うというのが、おそらく勝てる戦略だろうね。