Claude Fable 5のOpus 4.8フォールバックの仕組みを解説

本番APIシステムにおけるClaude Fable 5のセーフガードとOpus 4.8フォールバック動作の連携について詳しく解説します。

By Dora 1 min read

Doraです。本番トラフィックをClaude Fable 5にルーティングして約1週間が経ちました。フォールバック動作が発火するのを観察するには十分な期間であり、何に驚いたかをまだ覚えている程度の短さです。この記事は、Fable 5を統合したばかりで、まったく無害なプロンプトに対してstop_reason: "refusal"が返ってきた方、あるいはこれから統合しようとしていて、午前2時にそれを知りたくない方のために書きました。

短くまとめると:****Claude Fable 5のフォールバックはエラーではありません。これはモデルの出荷仕様として文書化された動作です。安全性分類器がリクエストを拒否した場合、APIはHTTP 200をrefusalのstop_reasonとともに返し、Anthropicはユーザーを失うことなくClaude Opus 4.8でそのリクエストを再試行するための3つの方法を提供しています。これを捕捉すべき例外として扱うと、誤った処理をすることになります。ルーティングの決定として扱えば、きれいに組み込むことができます。

フォールバックを引き起こすものは何か、APIが実際に何を返すか、リトライの実装方法、そして課金への影響について説明します。

Fable 5ルーティングにおけるOpus 4.8の重要性

Fable 5のセーフガードとフォールバック動作

Fable 5はAnthropicが広くリリースした最も高性能なモデルであり、モデルの前段に安全性分類器を搭載して出荷されています。分類器がリクエストにフラグを立てると、Fable 5は回答しません。そのリクエストはClaude Opus 4.8で再実行でき、そのことがユーザーに通知されます。これはAnthropicのClaude Fable 5とMythos 5のアナウンスに文書化されています。

Anthropicは、分類器が発火するのはセッション全体の平均で5%未満と述べています。この数字は私がこれまで見てきたものと一致しています。ほとんどの場合、フォールバックの仕組みが存在することに気づきません。

Mythos 5の制限されたアクセスについて

Mythos 5はFable 5と同じ基盤モデルですが、分類器を除去したものです。一般公開はされていません。アクセスはProject Glasswingを通じて提供されており、現在はサイバーセキュリティパートナーと、別の信頼アクセスプログラムの下にある少数の生物学研究者に限定されています。すでにアクセス権を持っていない場合は、Fable 5をベースに開発することになります。anthropic mythosのブランディングはここで混乱を招きやすいですが——Mythosはモデルクラスであり、Fable 5はそのクラスの公開メンバーです。

この記事の残りの部分では、コードがFable 5を呼び出していると仮定します。

フォールバックが単なるエラーパスではなく製品機能である理由

これが私が理解するのに少し時間がかかった部分です。Opus 4.8は品質の低いエクスペリエンスではありません。前世代のOpusティアであり、依然として高性能で、同じ分類器を実行しません。つまりルーティングロジックはこうなります:まず最強のモデルを試み、分類器が拒否したら、2か月前までフラッグシップだったモデルにフォールスルーする。どちらにしてもユーザーは回答を得られます。それが設計全体の意図です。

フォールバックはバグレポートではありません。コードがユーザーの代わりに行うルーティングの決定です。

フォールバックまたは拒否を引き起こすもの

サイバーセキュリティ、生物学/化学、蒸留カテゴリ

stop_details.categoryフィールドは、どの分類器が発火したかを示します。Fable 5で公開されているカテゴリにはcyberbioreasoning_extractionが含まれます——最後のものは、AnthropicのサービスTermsの下でモデル出力をリバースエンジニアリングまたは蒸留しようとする試みのように見えるリクエストに対するものです。現在のリストと正確な動作はClaude APIドキュメントの拒否とフォールバックのドキュメントにあります。

私はbioが発火するのを見たことがありません。cyberは2回見ました。どちらの場合もプロンプトはセキュリティに隣接していましたが無害なものでした——1つは特定のログフォーマットの構造についての質問で、もう1つは何年も前に完全にパッチが当たったCVEについてでした。どちらも何かをしようとする試みではありませんでした。分類器は表面的なパターンを見て拒否しました。

誤検知と保守的なセーフガード

Anthropicは、分類器が保守的にチューニングされていること——彼ら自身の表現では理想的よりも厳しい——を明示しています。それがトレードオフです。実際の悪用ケースを見逃すよりも、無害なサイバーの質問を拒否してOpus 4.8にルーティングすることを選んでいます。フォールバックが存在するのは、まさに誤検知率が設計上ゼロではないからです。

その前提で構築すれば、驚きはなくなります。拒否がまれな緊急事態だという前提で構築すると、最初の拒否で何かが壊れます。

リクエストが拒否されたときにAPIが返すもの

レスポンスは通常のHTTP 200です。形式はおおよそ次のとおりです:

{
  "role": "assistant",
  "content": [],
  "stop_reason": "refusal",
  "stop_details": {
    "type": "refusal",
    "category": "cyber",
    "explanation": "..."
  },
  "usage": { "input_tokens": 106, "output_tokens": 1 }
}

出力が生成される前に拒否されたリクエストに対しては課金されません。拒否されたターンをリセットせずに同じ会話を続けると、拒否が続きます——Anthropicのストリーミング拒否のドキュメントでこれについて具体的に説明しています。再試行する前にそのターンを削除または書き直してください。

categoryフィールドは情報提供目的です。それに基づいてユーザー向けのコピーを分岐させないでください。バッチ結果を含む一部のサーフェスではnullになる可能性もあるため、stop_reasonを直接確認することで拒否を検出してください。

ビルダーがフォールバックを実装する方法

3つの方法があります。1つを選んでください。重ねて使わないでください。

サーバーサイドフォールバックパラメータ

直接Claude APIまたはAWS上のClaude Platformでの最もきれいなパスは、オプトインのfallbacksパラメータです。現在ベータ版です。リクエストにフォールバックモデルリストを追加すると、Fable 5が拒否した場合、Anthropicがリスト内の次のモデル(起動時はOpus 4.8)でリクエストを再実行し、そのレスポンスを返します。あなたの側からは1回のラウンドトリップです。

Message Batches APIではサポートされておらず、Amazon Bedrock、Vertex AI、Microsoft Foundryでは現在利用できません。それらの場合はSDKミドルウェアを使用してください。

クライアントサイドSDKミドルウェア

AnthropicのSDKには拒否フォールバックミドルウェアが付属しています。フォールバックモデルリストを指定してクライアントを1回設定すると、リトライ、フォールバッククレジット用のベータヘッダー、会話履歴の管理が自動的に処理されます。受け入れモデルはフォローアップターンのために固定されるため、会話の一貫性が保たれます。

私はミドルウェアを使用しました。設定はクライアント構築時の1ブロックで、その後client.beta.messages.createは通常のクライアントとまったく同じように動作します——拒否が自動的にルーティングされることを除いて。Bedrock、Vertex、またはFoundryを使用している場合、または単にどこでも同じコードパスを使いたい場合は、このパスをお勧めします。

機密コンテンツを公開せずに分類器の結果をログに記録する

拒否が発生した場合、デバッグに十分な情報——モデル、タイムスタンプ、カテゴリ——をログに記録しますが、機密性がある可能性のある完全なプロンプトをアプリケーションログに記録しないでください。分類器がすでにフラグを立てています。プロンプトは、オブザーバビリティスタックにインデックスしたいものではなく、処理したいものとして扱ってください。

私はstop_details.categoryのカウンターと、開発環境のみでのフルペイロードのサンプリングレートを維持しています。これにより、コンテンツを漏洩させることなく誤検知のパターンを把握できます。

課金とユーザーエクスペリエンス

サポートされている場合の重複プロンプトキャッシュコストの回避

元のFable 5リクエストが長いキャッシュされたプレフィックスを使用していた場合、Opus 4.8で再試行する際にそのキャッシュ読み取りを2回支払いたくはありません。フォールバッククレジットがこれを処理します。拒否がクレジットを発行すると、レスポンスに不透明なfallback_credit_tokenが含まれ、再試行リクエストにそれを渡すことで重複キャッシュ料金を回避できます。メカニズムとベータヘッダーはAWS BedrockのフォールバッククレジットガイDに文書化されており、SDKミドルウェアがヘッダーを送信します。トークンは5分間有効です。

サーバーサイドのfallbacksパラメータまたはミドルウェアを使用した場合、これは処理されています。手動でリトライする場合は、自分で組み込む必要があります。

フォールバックをエンドユーザーに説明する

フォールバックは失敗ではありません。しかし、ユーザーはレスポンスが別のモデルから来たことを知る必要があります——透明性のためと、Opus 4.8が異なる回答をする可能性があるためです。私は小さなインラインノートを表示しています——「フォールバックモデルで回答されました」のような内容——そしてそれが何を意味するかを説明するヘルプページへのリンクを付けています。謝罪ではありません。ラベルです。

私がしないのは、カテゴリをユーザーに公開することです。文脈のない「cyber」や「bio」は非難のように読めてしまい、ほとんどの場合そうではありません。

安全性の動作を観察可能に保つ

拒否率を通常のSLIとして追跡してください。週ごとに上昇している場合は把握しておきたいものです——使用パターンがフラグの立つカテゴリにシフトしているか、分類器が再チューニングされているかのどちらかです。どちらも運用上興味深いことです。測定しなければどちらも見えません。

よくある質問

なぜFable 5はOpus 4.8にフォールバックするのですか?

Fable 5は、特定のカテゴリ(サイバー、生物学、化学、蒸留)のリクエストを拒否できる安全性分類器を搭載して出荷されているためです。それが発生した場合、Fable 5は回答せず、リクエストはOpus 4.8——同じ分類器を実行しない——で再実行できるため、ユーザーは依然として応答を得られます。

APIチームはどのように拒否レスポンスを処理すべきですか?

例外ではなく、通常のAPIの結果として扱ってください。stop_reason == "refusal"を確認してください。サーバーサイドのfallbacksパラメータ、SDKミドルウェアを使用するか、フォールバッククレジットトークンで手動リトライを実装してください。会話を続ける前に拒否されたターンをリセットしてください。さもなければ拒否が続きます。

フォールバックはリクエストが安全でないことを意味しますか?

いいえ。分類器は保守的にチューニングされているため、隣接するカテゴリの無害なリクエストが時々引っかかることがあります。Anthropicはセッションの5%未満がフォールバックに当たると述べています。拒否をユーザーへの判定ではなく、ルーティングシグナルとして扱ってください。

Opus 4.8をデフォルトモデルにすべき場合はどんな時ですか?

Fable 5の推論能力の上限が必要ではなく、ルーティングロジックを完全に避けたい場合です。Opus 4.8はトークンあたりのコストがおおよそ半分で、同じ分類器を実行しません。ルーティンワークでは、Opus 4.8がより合理的なデフォルトになることが多いです。長期エージェント実行では、フォールバックを設定したFable 5が適切な選択です。

まとめ

Claude Fable 5のフォールバックはエラーではなく、ルーティングイベントです。 分類器は保守的に発火し、APIはきれいな200を返し、Anthropicはリトライ、キャッシュ課金、会話履歴を、多くのコードを書くことなく処理するサーバーサイドパラメータとSDKミドルウェアを提供しています。

実装作業は小さいです。フレーミングのシフトの方が難しい部分です。拒否を例外として扱うのをやめると、残りは自然についてきます。

サイバー分類器が正当な質問に対してどれくらいの頻度で発火するかを引き続き観察しています。あと1週間分のデータがあれば、自分の側で何かチューニングが必要かどうかがわかるでしょう。来週も続けます。

過去の投稿: