Fable 5.2を難しいアルゴリズム改善に投入したら、3時間の停滞が数分で解決した話

出たばかりのFable 5.2を、Sonnet 5.5のワーカーが3時間かけても合格できなかったアルゴリズムの性能改善タスクに投入したところ、数分で一発合格しました。そのときの様子と、使ってみて分かった注意点をお話しします。

この記事で分かること

本日たまたま難しい課題が出たので、出たばかりのFable 5.2を使って実装してみた話をしたいと思います。

私はClaude CodeのUltraプランに入っています。普段は、前回お話しした構成でパイプラインを組んでいます。

変更前

変更後

イメージとしてはこのような感じです。私がいつもしているのはシステム開発なので、その点はご留意ください。

用語メモ: オーケストレーター 作業を工程表に分解してタスクを管理し、各エージェントに指示を出す役割のエージェントです。

難しい設計・実装・テストは、Opus 5.5のCTOに出してレビューさせ、合格に達したものだけを次の工程に流してよい、というルールにしています。工程表に分解してタスクを管理しているオーケストレーターの指示のもとで、作業を進めているわけです。

今日は、かなり難しい改善作業が入っていました。

とあるアルゴリズムの実装だったのですが、どうしても製品目標の実行速度に到達できませんでした。そこで、アルゴリズムの改善を調査・分析させたうえで実施させていたのですが、3回作り直してCTOレビューに出しても、不合格ばかりが出ていました。

CTOは、指摘したポイントと修正案を出しています。しかし、Sonnet 5.5のワーカーはどうしてもその指摘どおりに設計することができず、4回目も突き返されてしまいました。時間とトークンだけが無駄に消費されるような状態です。

時間もばかにならず、3時間ほどたっても前に進まない状態でした。

そこで、Opus 5.5のワーカーに交代させてみようかと思ったのですが、ちょうどFable 5.2が出たところでした。試しに交代させてみたところ、数分でスパーンッと小気味よく一発合格しました。

冗談抜きで、少し驚きました。あれ、こんなに違うのかと。

それで、今日だけは性能改善のタスクを、すべてFable 5.2に振ってみることにしました。

Fable 5.2のワーカーも、基本的に自己レビューを最大3回繰り返して完璧に仕上げる、というルールは変えていません。

実はこのルールはとても効率がよく、キャッシュにもヒットするのでトークンを抑えられ、かつレビュー精度もかなりよかったりします。

一般的には、コンテキストを完全にリセットした状態のエージェントにレビューを頼んだほうが、効果が高いといわれています。しかし、私の環境での実測では、同じモデルにレビューさせて訂正させたほうが、精度もトークンも良い結果でした。

その後、CTOのレビューを受けさせても、スパスパ合格します。性能はOpus 5.5より良いはずですから、当然かもしれません。

ただ、一度だけ「観点が抜けている」とOpus 5.5のCTOから指摘をもらって訂正させていたので、Opusだからといってばかにできません。Opusも性能は良いです。

オーケストレーターから「このタスクは数日かかります」と言われてドキドキしていたのですが、数分です。

すかさず「ガバガバじゃないか、見積りが!早いじゃん!」とオーケストレーターに突っ込みを入れたところ、「そうですね、私も驚きですよ」と答えてきました(笑)。

ただ、一つだけ言わせてください。

トークン消費量が50%抑えられている今のFable 5.2でも、ゴリゴリにトークンが消費されます。Ultraプランでもグングン減っていくので、怖いです。

今はキャンペーン中なので気軽に使えますが、仕事で使っていても、かなり気を使います。

相当難しい課題以外はOpusで事足りると思うので、パイプラインにそのまま組み込むことはできません。今回のような、難しいアルゴリズムの改善などが使いどころでしょうか。

一般的なシステム開発では、このような課題はあまり出ないと思いますが、いざというときにとても役に立ちます。

触る機会があれば、一度試してみてください。そのときは、ぜひ難しいタスクを振ってみてください。XなどのSNSでは動画の比較のようなものが多く見られますが、正直なところ、もったいない使い方だと感じます。

ただし、トークンを大量に消費するので、モニターしながら適切に使ってください。そうしないと、リセットされるまで待つはめになります。

ちなみに、今はキャンペーンで、無料でリセットできるボタンが付いてきます。ガシガシ試して、100%になったらリセットして再開させましょう。