Fable 5 を動かしたので OTel のデータを Grafanaで可視化してみた話

Claude Fable 5 が出てきたので、Claude Code の OpenTelemetry（OTel）を Grafana Cloud に流して眺めていた自分のダッシュボードを開いてみました。4 モデルが並ぶ景色を見ながら、それぞれをどう使い分けると良さそうか、軽く考えたことをまとめておきます。

4 モデルが並ぶダッシュボード

Grafana Cloud には Claude Code の OTel をそのまま流していくつかのデータを試しに可視化しています。

Fable 5なども使ってしばらく試した後にチェックすると、過去 6 時間で API コストが約 $59.8、Active Time は 46.1 分、コミットは 13.7、Pull Request は 3.18 という数字が出ていました。

API Cost by Model のパネルには、これまでの opus-4-8 / sonnet-4-6 / haiku-4-5 に加えて、fable-5 が混ざるようになっています。

GrafanaのAIアシスタントがデータの分析レポートもしてくれるので聞いてみました。Grafana のAIが言うところには、「fable-5 は単価が最も高くコスト効率が低い」「opus-4-8 はコストの 56% を占めるが、キャッシュヒット率 95% でトークン単価は中程度」「haiku-4-5 は単価最安だが Output / Input 比が低く単純タスク向き」とのことです。この辺りは、自分のプロンプトやタスクの種類に左右される可能性もあるかなとは思いますので、あくまで参考値程度かなと思います。

Fable 5 の使い所

Fable 5 の使用感は今のところ不満なく、さすが最高位だなと印象です。ただ、こうやってダッシュボード上で数値化されると、相応の値段であり使い所を限定する必要があるなとも思わされます。

生成する文字の単価が高いことから、「価値の高い文字や文章」を作らせたくなります。そのためパッと思いつく範囲では、例えば長期的なプランニングや四半期・半年スパンのパフォーマンスレビューのような領域での、スポット利用が現実的なところかなという気がしています。

Sonnet での生成品質を高めるために何ができるか

そうなると、「標準・汎用タスク向けとされている sonnetシリーズの生成精度をどう高めるか」、という話に行き着く気がしています。Sonnet を中心軸に置いて、その精度を補うために Fable や Opus をどう使うか、Haiku に任せる単純作業はどう判断するのか、etc..

使う側にまわっていてあまり意識していませんでしたが、そろそろモデルのルーティングなどについても調べる必要が出てきたのかもしれません。

まとめ

OTel を流して眺める習慣を作っておくと、fable-5 のような新しいモデルが増えてきても、景色の変化として捉えられて、使い分けを考える材料になります。

セットアップを試したい方は Claude Code Monitoring（公式） を、各モデルの単価が気になる方は Anthropic Pricing を参照してください。