Fable 5.2 API の接続方法：モデル ID・応答確認・料金計算

Fable 5.2 を新しく接続する場合は、正確なモデル ID で小さなリクエストを送り、返されたテキストと停止理由を確認してから、ツールの追加や既存会話の移行に進みます。Ofox のカタログ ID は anthropic/claude-fable-5.2、Claude API では claude-fable-5-2 です。それぞれ対応するプロバイダーの設定で使います。

この記事では、公開されたモデルの仕様、Ofox の現行カタログ、アプリケーション側の検証を区別します。文書、カタログ、小規模なネイティブプロトコルの API テストは 2026 年 11 月 10 日に確認しました。下記の cURL リクエスト本文は実際に試しています。SDK のコードは同等の接続方法を示す例であり、個別にサービスへ接続して検証したものではありません。この記事の発行元である Ofox は、紹介するゲートウェイの提供元でもあります。

エンドポイントと正確な ID を組み合わせる

公式概要では、コンテキストウィンドウは 1M トークン、最大出力は 128K トークンです。これは上限であり、通常のリクエストに推奨するサイズではありません。機密情報を含まない短い入力と、上限を設けた出力から始めてください。

Ofox のモデルページと公開カタログには Anthropic と OpenAI の両プロトコルが掲載され、5.2 の現行プロバイダー種別は aws_bedrock となっています。プロトコルの表示だけでは、すべての経路が Anthropic のすべてのベータ機能をそのまま転送するとは確認できません。依存する前に、必要な機能を個別に検証します。

間違えやすいのが別名です。今回の日付付きカタログスナップショットでは、claude-fable-latest はまだ 5.1 のエントリーに属しています。導入テストでは正確な 5.2 の ID を使い、応答のモデル名とリクエスト ID を記録してください。新バージョンが出たからといって、別名も移ったとは限りません。

小さなネイティブリクエストを送る

Ofox の認証手順で API キーを作成し、普段のシークレット管理方法で OFOX_API_KEY に読み込みます。公開するブラウザーコードに入れず、サーバーかローカル開発環境で実行してください。以下の本文は、サンプリング、強制ツール選択、任意のベータ制御を意図的に省いています。

curl --fail-with-body --max-time 180 \
  https://api.ofox.ai/anthropic/v1/messages \
  -H "x-api-key: $OFOX_API_KEY" \
  -H 'anthropic-version: 2023-06-01' \
  -H 'content-type: application/json' \
  --data '{
    "model": "anthropic/claude-fable-5.2",
    "max_tokens": 4096,
    "output_config": {"effort": "low"},
    "messages": [{
      "role": "user",
      "content": "A synthetic order contains 3 units at USD 12 each. Return the total and one calculation line. Do not use tools."
    }]
  }' > response.json

期待する計算結果は 36 米ドルです。実際の応答は金額と計算過程を返し、HTTP 200、stop_reason: "end_turn"、入力 46 トークン、出力 32 トークンでした。この合成入力による 1 回のリクエストが確認するのは、この限定的なケースだけです。すべての本番ワークフローを保証しません。次に進む前に、自分の response.json を確認します。HTTP 成功だけでは、回答が返ったこと、タスクに従ったこと、出力上限内で完了したことは分かりません。

最初のコンテンツブロックがテキストだと決めつけないよう、次の小さな検査スクリプトを使います。

import json
from pathlib import Path

response = json.loads(Path("response.json").read_text())
if "error" in response:
    raise RuntimeError(response["error"])
text = "\n".join(
    block.get("text", "") for block in response.get("content", [])
    if block.get("type") == "text"
)
print("model:", response.get("model"))
print("stop_reason:", response.get("stop_reason"))
print("usage:", response.get("usage"))
print(text)
if response.get("stop_reason") != "end_turn" or not text.strip():
    raise SystemExit("Not a completed text answer; inspect before continuing.")

このツールなしのテストでは、完了したテキスト回答を必須とし、計算を手で確認します。本番では、その出力に適した独立した検証器に置き換えてください。36 を含むかどうかだけでは不十分です。「合計は 36 ではない」という回答も同じ文字列を含みます。

ネイティブ Messages の文書には、エンドポイントと認証形式が記載されています。Chat Completions を使う場合は、messages、応答、ツール結果の形式を最後までそちらに統一します。OpenAI 形式の会話にネイティブの tool_result ブロックを貼り付け、アダプターが元の状態を復元すると想定しないでください。

思考と回答の両方に出力枠を確保する

Fable 5.2 は適応型の思考を常時有効にします。output_config.effort は思考の強さを制御し、1 トークン当たりの価格は変えません。この小さなテストでは単純な計算への投入を抑えるため low を使っています。難しいリポジトリ修正や多段階の分析にも推奨する設定ではありません。

実務では文書にある既定値 high から始め、合格条件のあるケースで低い effort と比較します。Anthropic の effort ガイドは、追加の思考が役立つタスクに高い設定を使うことを勧めています。文章の見栄えだけでなく、総トークン数と完了状況を測ってください。

max_tokens は思考と応答出力を合わせた枠です。小さすぎると、thinking ブロックの後に stop_reason: "max_tokens" となり、表示できる回答がない場合があります。これは 400 リクエストエラーとは別です。停止理由を調べ、意図的に上限を増やすか effort を下げます。同じ小さな上限で何度も再試行し、その支出をモデル価格の比較と扱わないでください。

ストリーミング後の最終メッセージを失わない

公式 Python SDK を使う場合、ストリーミング後に組み立てられたメッセージを保存します。以下は、文書の output_config フィールドに対応した比較的新しい SDK 向けのテンプレートです。アプリケーションで検証した SDK バージョンを記録し、固定してください。

import os
import anthropic

client = anthropic.Anthropic(
    api_key=os.environ["OFOX_API_KEY"],
    base_url="https://api.ofox.ai/anthropic",
    max_retries=0,
    timeout=180.0,
)
with client.messages.stream(
    model="anthropic/claude-fable-5.2",
    max_tokens=4096,
    output_config={"effort": "low"},
    messages=[{"role": "user", "content": "Calculate 3 times 12."}],
) as stream:
    for text in stream.text_stream:
        print(text, end="", flush=True)
    final_message = stream.get_final_message()
print(final_message.stop_reason, final_message.usage)

テキストストリームは表示用です。後続のツールターンで保存すべき完全なメッセージではありません。完了前に接続が切れたら、その試行を未完了とし、部分的な表示テキストを有効な assistant 応答として保存しないでください。thinking の署名を調べる記事で、テキストだけの収集によって失われるフィールドを説明しています。

副作用のある操作の前に読み取り専用ツールを追加する

最初のツールには、合成在庫レコードを返すものが向いています。文字列の SKU を必須にした入力スキーマで lookup_stock を定義し、tool_choice を auto に設定して DEMO-001 を調べさせます。実行前に、生成されたツール名と引数を許可リストに照らして検証します。

完全に実行できる別例として、読み取り専用の在庫ランナーとチェックポイントモジュールを用意しています。この版は 3 行のテストデータ全体を取得する read_stock を定義し、初回リクエスト、ツール検証、実際の結果メッセージ、継続、最終引き継ぎの検査まで含みます。手順記事では、ローカル検査と明示的な有料実行を分けています。

ネイティブプロトコルでは、返された assistant の全内容をそのまま追加します。次に、実際の結果と一致するツール ID を含む user メッセージを追加します。

# response is the completed SDK response; tool is one validated tool_use block.
messages.append({
    "role": "assistant",
    "content": [b.model_dump(exclude_none=True) for b in response.content],
})
messages.append({"role": "user", "content": [{
    "type": "tool_result",
    "tool_use_id": tool.id,
    "content": '{"sku":"DEMO-001","available":7,"source":"synthetic fixture"}'
}]})

この断片は継続の形式を示すもので、複数ツール対応の完全なランナーではありません。複数の呼び出しが返ったら、すべての ID を処理してそれぞれの実際の結果を報告します。失敗したツールにはエラー結果が必要であり、成功レコードを作ってはいけません。tool_result 不足のガイドでは対応付けエラーを、5.2 の移行診断ではバージョン固有の制限を扱います。

auto は「ツールが必ず動く」という意味ではありません。検索が必要なタスクにテキストだけが返ったら、アプリケーションが検出して完了扱いを拒否する必要があります。まず読み取り専用のテストデータを使えば、デバッグ時の再試行で注文やメッセージを二重送信せずに済みます。

トークンの種類を分けて料金を計算する

11 月 10 日に確認した標準料金です。単位は 100 万トークン当たりの米ドルです。

出典は Anthropic の料金表、Ofox のモデルページ、日付付きカタログスナップショットです。Ofox のリポジトリは該当フィールドを 1 トークン当たりの米ドルとして定義しているため、表では 100 万倍しています。コードは動的なモデルデータを読むので、Git のソース自体が現行料金表ではありません。5.2 のスナップショットに独立した provider_price オブジェクトはありません。これは仕入れ価格データの欠落であり、仕入れコストがゼロ、または割引確認済みという意味ではありません。

非キャッシュ入力 20,000 トークンと、課金対象出力 4,000 トークンを仮定すると、次の計算になります。

20,000 × $8 / 1,000,000 + 4,000 × $40 / 1,000,000 = $0.32

キャッシュ読み取り 19,000 トークン、非キャッシュ入力 1,000 トークン、同じ出力を仮定した場合は次のとおりです。

19,000 × $0.20 / 1,000,000 + 1,000 × $8 / 1,000,000
+ 4,000 × $40 / 1,000,000 = $0.1718

2 番目の例には、その前にキャッシュを書き込んだリクエストを含めていません。セッション全体の見積もりには追加します。入力分類は重複させず、キャッシュ書き込みトークンを非キャッシュ入力にもう一度足さないでください。課金される推論出力、再試行、別料金のツールも含めます。これは計算例であり、実際の請求書ではありません。バッチや高速モードの料金は利用条件と経路を別途確認する必要があり、ここでは適用していません。

実際の API 応答を使い、ローカルで表示した英語のテスト記録です。Ofox の製品画面を撮影したものではありません。

接続を運用に使えるか判断する

追加のネイティブプロトコルテストでは、ストリーミングのテキスト応答と、読み取り専用ツールの往復が完了しました。不適合なパラメーターを意図的に送った 2 件も 200 でした。1 件は thinking: {"type":"disabled"}、もう 1 件はツールなしで計算する指示を残したまま lookup_stock を強制しました。後者はツールを呼ばずテキストを返しました。どちらも、その制御が機能した証明にはなりません。400 記事の経路別結果で、アプリケーション側の受け入れ検査が必要な理由を説明します。

トラフィックを移す前に、完了したテキストリクエスト、完全なストリーム、正しい ID を使った読み取り専用ツール往復、履歴を変えずに復元した既存の複数ターン会話、の 4 つを確認します。各ケースのリクエスト ID、正確なモデル、effort、使用量、停止理由、SDK バージョン、検査結果を保存してください。

400 は同じ内容で再試行せず、本文を診断します。過負荷には回数を制限した再試行を使い、Claude 529 ガイド（英語）を参照します。モデル変更時は、チェックポイントの手順で、アプリケーションの事実と不透明な推論を分けて保存します。5.2、5.1、Opus 5.5 の比較は費用と移行の判断に使えます。

関連文書：API 認証、ネイティブ Messages、プロバイダー経路。データ保持の要件は実際にデータを処理するサービスに確認してください。Anthropic は 5.2 固有の保持要件を定めており、Ofox のプロトコル対応表示はプライバシーの保証ではありません。