Claude Fable 5 API 実装例：リトライ・フォールバック・OpenRouter・Bedrock

API 呼び出しそのものは簡単な部分です。 信頼できる Claude Fable 5 の統合には、プロバイダーの決定、コストの上限、回数を区切ったリトライ、そして明示的なフォールバック経路が必要です。本番環境では、コピー&ペーストしたリクエストボディよりもこの4つの判断の方が重要になります。

まずプロバイダーを決める

Fable 5 は直接 API、AWS Bedrock、あるいは OpenRouter のようなアグリゲーター経由で提供されることがあります。コードを書き始める前に、どのアカウントが請求を負担するのか、どのリージョンやプロバイダーを本番の正とするのかを書き出しておきましょう。

ブログ記事に書かれた model ID をハードコードしないでください。デプロイの時点で、プロバイダーの最新ドキュメントを確認しましょう。

安全なリクエストの形

モデル選択と予算ポリシーはプロンプトの外に置きます。以下はプロバイダー非依存の擬似コードであり、最新の SDK ドキュメントの代わりになるものではありません。

const result = await runWithPolicy({
  primaryModel: 'claude-fable-5',
  fallbackModel: 'claude-opus-4-8',
  maxAttempts: 2,
  timeoutMs: 90_000,
  budget: { maxInputTokens: 120_000, maxOutputTokens: 8_000 },
  task: { kind: 'repository-refactor', id: jobId },
  messages,
});

このポリシーは、実際にどのプロバイダーとどのモデルがタスクを完了したのかを返すべきです。このフィールドが1つあるだけで、後々の課金分析と品質分析で何週間も混乱せずに済みます。

回復しうる失敗だけをリトライする

タイムアウト、短期的なレート制限、プロバイダーの 5xx エラーといった一時的な失敗には、指数バックオフと小さなリトライ予算を組み合わせてリトライしてください。認証エラー、不正な入力、ポリシーによるブロック、すでに支出上限を超えたジョブをやみくもにリトライしてはいけません。

長時間稼働のエージェントでは、ステップを完了するたびにチェックポイントを保存しましょう。リトライは永続化された状態から再開すべきであり、高コストなタスク全体をやり直すべきではありません。

フォールバックはプロダクトの判断として設計する

役に立つフォールバックは「すべてのモデルを順に試す」ことではまずありません。次のように、狭いルールを定義してください。

• リトライのコストが高い、難しく長時間にわたる作業には Fable 5 を使う。
• 定型作業、キャパシティの問題、制約付きのフォールバック経路には Opus 4.8 を使う。
• 主モデル固有の能力や人間の承認が必要なタスクでは、処理を止めてエラーを表面化させる。

2つのモデルのタスク別比較は Fable 5 vs Opus 4.8をご覧ください。また、移植可能なシステムプロンプトはプロンプトジェネレーターで管理しておきましょう。フォールバックモデルは、同じタスクの契約を理解できて初めて役に立ちます。

OpenRouter：不透明さのためではなく、ルーティングのために使う

OpenRouter は、プロダクトが複数のモデルを必要とするときに統合の手間を減らせます。統制された実験や、プロバイダー非依存のルーティング層には適しています。一方、可観測性、プライバシーレビュー、障害対応、最終的な請求を誰が担うのかを決めていない場合には向きません。リクエストごとに、解決されたプロバイダーとモデルをログに記録してください。そうしないと、「Fable 5」というラベルだけではコストもレイテンシーも説明できません。

Bedrock：リージョンとアクセスの差を織り込む

Bedrock では、可用性と承認状況がリージョンやアカウントによって異なることがあります。実際にデプロイするリージョンでアクセスを確認し、代替のモデル経路を用意しておきましょう。運用面のチェック項目は Bedrock アクセスガイドで扱っています。本記事はアプリケーション層のリトライとルーティングに焦点を当てています。

本番前チェックリスト

• デプロイ前に、現行のプロバイダーの model ID と可用性を確認する。
• リクエストがサービスを離れる前に、トークンと金額の上限を強制する。
• 一時的な失敗だけを、上限を区切った予算内でリトライする。
• エージェントのチェックポイントを永続化し、リトライで課金済みの作業をやり直さないようにする。
• 要求したモデル、解決されたモデル、プロバイダー、トークン使用量、レイテンシー、結果をログに残す。
• 障害によってフォールバックが既定になってしまう前に、実際のプロンプトでテストしておく。

トークンコストの試算には料金計算ツールをご利用ください。モデルのスコアを出典まで踏まえて読む方法は Fable 5 のベンチマークの読み方をご覧ください。