Anthropicの新しいClaude Fable 5推論エンジンは、すべてのリクエストで深い思考（Thinking）を常時オンに保ち、その代わりに開発者が推論の深さを上下に調整できるようにしています。従来、大規模言語モデル（LLM）は固定された計算パラメータで動作し、クエリの複雑さに関係なく一定の速度でトークンを生成していました。単純な挨拶文も、高度な数学的証明と同じ処理エネルギーを消費していたのです。Fable 5では、Anthropicは思考が常にアクティブであり、単一のeffort設定を通じてモデルがどれだけ深く処理するかを制御できるハイブリッド推論フレームワークを導入しました。このチュートリアルでは、APIの動作、effortレベルの選び方、そして本番環境のパイプラインにこのアーキテクチャを実装する方法の概要を説明します。
[!WARNING] API制約に関する警告：Fable 5では思考が常時オンになっているため、オフにすることはできません。
thinking: {type: "enabled"}やthinking: {type: "disabled"}を渡したり、budget_tokensの値を指定したりすると、HTTP 400エラーが返されます。これらのパラメータは削除されました。代わりにoutput_config: {effort: "..."}で推論の深さを制御し、effortレベルを高くする場合は最終的な回答のためにmax_tokensに十分な余裕を残してください。主なポイント：
- トグルではなくEffortを調整：
output_config.effortをlow、medium、high、xhigh、maxのいずれかに設定します。オン/オフの切り替えはありません。- 思考は自動：
thinkingを省略するか{type: "adaptive"}を渡します。アダプティブ思考はすべてのリクエストで実行されます。- ストリームの解析：リアルタイムのサーバーストリームで、
thinking_deltaデルタを伴うthinkingコンテンツブロックを処理します。- 請求の管理：システムプロンプトをキャッシュすることで、重複する思考処理サイクルを削減します。
Claudeのハイブリッド推論エンジンの説明
Fable 5の核心的なイノベーションは、最終的な回答を出力する前に問題をじっくり考え抜く能力にあります。これは、モデルがクライアントのリクエストに応答する前に、内部で解決策の論理的な下書きを作成することを意味します。重要なのは、この思考フェーズが常時オンであるという点です。オフにすることはできず、切り替えて入るような別の「スピードモード」も存在しません。
複雑な質問を送信すると、モデルはすぐに次の単語を予測しようとはしません。代わりに、内部の思考トークンを生成し、段階的な推論プロセスをシミュレートします。このアーキテクチャにより、数学、コーディング、および論理的評価の精度が劇的に向上します。
多様なエンタープライズ要件をサポートするため、Anthropicは開発者が単一のeffortコントロールを通じて、その思考の深さをオンデマンドで調整できるようにしています。low（低）effortでは、モデルは短時間だけ思考して素早く回答し、遅延とトークン消費を抑えます。high（高）またはmax（最大）effortでは、はるかに深く推論し、難しい数学、多段階の論理、複雑なコードに必要な追加の計算リソースを費やします。速度と深さのトレードオフは、有効化/無効化のトグルではなく、完全にこのeffortレベルによって表現されます。
Fable 5 APIパラメータの構成
これらの機能をソフトウェアに実装するには、更新されたAnthropic APIスキーマを使用する必要があります。このスキーマにより、クライアントアプリケーションが正しいモデル名と実行パラメータを指定できるようになります。
推論の深さはoutput_configブロックを通じて設定します。その中のeffortフィールドは"low"、"medium"、"high"、"xhigh"、"max"のいずれかを受け付け、この単一の値が従来のトークン予算のダイヤルに取って代わります。シンプルなケースではthinkingブロックをまったく渡す必要はありません。アダプティブ思考が自動的に実行されるためです。以下のJavaScript統合は、このリクエストの構造化方法を示しています。
1import Anthropic from "@anthropic-ai/sdk";
2
3export default {
4 async fetch(request, env) {
5 const anthropic = new Anthropic({ apiKey: env.ANTHROPIC_API_KEY });
6
7 try {
8 const response = await anthropic.messages.create({
9 model: "claude-fable-5",
10 max_tokens: 8192,
11 // Thinking is always on for Fable 5; dial reasoning depth with effort:
12 output_config: { effort: "high" }, // "low" | "medium" | "high" | "xhigh" | "max"
13 messages: [
14 {
15 role: "user",
16 content: "Generate an optimised database migration script for 10 million records."
17 }
18 ]
19 });
20
21 return Response.json(response);
22 } catch (err) {
23 return Response.json({ error: err.message }, { status: 500 });
24 }
25 }
26};
思考を無効にしたりbudget_tokensの値を渡したりしないでください。thinking: {type: "disabled"}、thinking: {type: "enabled"}、およびbudget_tokensフィールドは、Fable 5ではいずれもHTTP 400を返します。これらのパラメータは、このモデル（およびOpus 4.7と4.8）で削除されたためです。速度が必要な場合は低いeffortレベルを、深さが必要な場合は高いeffortレベルを選択し、effortを上げる際は最終的な回答のためにmax_tokensに十分な余裕を残してください。サーバーレスアーキテクチャの詳細については、Cloudflare Workersを使用したサーバーレスAPIの構築
のガイドを参照してください。
ストリームでの思考トークンの処理
チャットインターフェースのようなリアルタイムアプリケーションでは、ストリーミングレスポンスが不可欠です。Fable 5は、思考ステップと最終的なコンテンツの両方をSSE（Server-Sent Events）チャネル経由で出力します。
ストリーム中、思考はthinkingコンテンツブロックとして届き、delta.typeが"thinking_delta"であるcontent_block_deltaイベントを通じて配信されます。テキストはdelta.thinkingから読み取り、最終的な回答は通常のtext_deltaデルタから読み取ります。生の思考連鎖（chain-of-thought）が返されることはありません。読みやすい要約を受け取るには、thinking: {type: "adaptive", display: "summarized"}でオプトインする必要があります。デフォルトの"omitted"では、空の思考テキストがストリーミングされます。最小限のハンドラーは次のようになります。
1const stream = await anthropic.messages.stream({
2 model: "claude-fable-5",
3 max_tokens: 8192,
4 output_config: { effort: "high" },
5 thinking: { type: "adaptive", display: "summarized" },
6 messages: [{ role: "user", content: prompt }]
7});
8
9for await (const event of stream) {
10 if (event.type === "content_block_delta") {
11 if (event.delta.type === "thinking_delta") {
12 process.stdout.write(event.delta.thinking); // summarised reasoning
13 } else if (event.delta.type === "text_delta") {
14 process.stdout.write(event.delta.text); // final answer
15 }
16 }
17}
これらのthinking_deltaチャンクは、折りたたみ可能な「Thinking…」パネルに流し込むこともできますし、破棄して回答のみをレンダリングすることもできます。Anthropic統合に関する詳細なリファレンスについては、Anthropic開発者ドキュメント
を直接参照してください。
トークンの集計は慎重に管理してください。思考トークンはアウトプットAPIの請求対象としてカウントされます。そのため、同じ入力に対して推論サイクルを再実行するのを避けるために、積極的なプロンプトキャッシュを実装してください。本番環境のデプロイを計画する場合、エッジテレメトリ層を介してこれらの指標を追跡することで、思考トークンの使用量が通常のパラメータを超える箇所を特定するのに役立ちます。
ステップバイステップのAPI統合ワークフロー
アプリケーション内に推論エンジンを実装するには、まずローカルパッケージを更新してFable 5の仕様に合わせます。古いSDKバージョンは依然としてbudget_tokensを送信するため、APIシリアル化中にHTTP 400のスキーマエラーが発生するようになりました。
次に、明確な遅延しきい値を定義します。単純な会話の流れや挨拶の場合は、low（低）effortレベルを設定して遅延を抑えます。コード生成や数学などのタスクには、high（高）またはmax（最大）effortを予約しておきます。
さらに、Wranglerなどのツールを使用して、サーバーレス環境のパラメータ内にAPI資格情報を安全に保存します。ストリーム出力イベントを処理するときは、thinking_deltaパケットを除外するための堅牢なフロントエンドハンドラーを作成します。これは、モデルの推論ステップを直接表示する場合を除き必要になります。最後に、プロンプトキャッシュのヒット率を監査して、キャッシュがトークン消費のオーバーヘッドを最小限に抑えていることを確認します。エッジAPIの設計について学ぶには、Cloudflare Workers AIチュートリアル
を探索してください。
Low EffortとHigh Effortの比較一覧
effortレベルの選択は、遅延、コスト、および回答品質のトレードオフです。以下の表は、リクエストの規模を決定する際に最も重要な次元を比較しています。遅延とスループットの数値は例示であり、プロンプトの長さ、負荷、地域によって異なりますが、それらの関係は維持されます。
| 次元 | Low effort（低） | High effort（高） |
|---|---|---|
| 最初のトークンまでの時間 | 1秒未満（例示） | モデルがより深く思考するにつれて増加 |
| リクエストごとのコスト | 思考トークンが少なく、支出が低い | 思考トークンが多く、アウトプット料金で課金 |
| 難関タスクの精度 | 標準レベル | 数学、多段階論理、コードで大幅に向上 |
| トークンの予測可能性 | 厳密で予測が容易 | 変動あり、難しいプロンプトほど大きい |
| 最適なワークロード | チャット、分類、検索フォーマット | デバッグ、証明、計画、複雑な生成 |
| 構成方法 | output_config.effort = "low" | output_config.effort = "high"または"max" |
重要な点は、思考トークンは実際の出力トークンであるということです。low effortのリクエストは短時間だけ思考し、そのほとんどが書き出す回答に対して課金されます。一方、highまたはmax effortのリクエストは、応答の最初の単語が表示される前に大量の思考トークンを生成する可能性があります。思考がオフになることは決してなく、どれだけの量を費やすかを選択しているだけなのです。
各Effortレベルの使い分け
実用的なアプローチは、各タスクタイプをデフォルトのeffortレベルにマッピングし、特定のリクエストが明らかにより多くの余裕を必要とする場合にのみ上書きすることです。誤った回答が後工程での検出コストを高める問題に対しては、highおよびmax effortを予約しておいてください。
| タスクタイプ | 推奨effort |
|---|---|
| 挨拶、FAQ、雑談 | low |
| 意図分類とルーティング | low |
| 短い文書の要約 | low |
| 構造化データの抽出 | lowまたはmedium |
| 複数ファイルにわたるコード生成 | high |
| 財務または数学的推論 | highまたはxhigh |
| 原因究明のためのデバッグ | xhighまたはmax |
low effortレベルを選択すべきケース：応答が短く、大部分が決定論的である場合、最初のトークンまでの時間がユーザー体験を決定する場合（ライブチャット、オートコンプリート、フォーム入力アシスタント）、または追加のアウトプットトークンが数百万回の呼び出し全体で掛け算されるような、大量処理で低マージンのワークロードを実行している場合です。
highまたはmax effortレベルを選択すべきケース：単一の誤った回答が実質的なコスト（壊れた移行スクリプト、誤計算された見積もり、脆弱なコードパスなど）をもたらす場合、またはモデルが相互に依存する複数のステップを一貫して処理する必要がある場合です。これらは、数秒の追加遅延が信頼性の大きな向上をもたらすワークロードです。
具体例：遅延とコストのトレードオフ
1日あたり50,000件のリクエストを処理するサポートアシスタントを想定します。各最終回答は約250トークンであり、low（低）effortレベルではわずかな思考トークンしか追加されず、high（高）effortレベルでは典型的な難しいクエリで約1,500トークンの思考トークンを消費すると仮定します。以下のすべてのトークン価格は例示的なものであり、見積もりとしてではなくモデリングの演習として扱ってください。また、アウトプットレートを100万トークンあたり15ドルと仮定します。
すべてのリクエストをlow effortで実行すると、およそ 50,000 × 250 = 1日あたり1,250万出力トークンが生成され、例示的なレートで約1日あたり188ドルになります。代わりにすべてのリクエストをhigh effortで実行すると、50,000 × (1,500 + 250) = 1日あたり8,750万トークンが請求され、約1日あたり1,313ドルになります。これは7倍高く、その大部分は、本来追加の深さを必要としないクエリの推論に費やされたことになります。
ここで、選択的なルーティングを導入します。安価なlow effortの分類器が、トラフィックの15%のみが真に複雑であると判断したと仮定します。7,500件のリクエストをhigh effortに、42,500件をlow effortにルーティングすると、1,310万 ＋ 1,060万 ≒ 1日あたり2,370万トークンとなり、約1日あたり356ドルになります。これは、すべてをhigh effortで実行する場合と比較して約73%の節約となり、同時に効果を発揮する場所には深い推論を適用し続けることができます。
遅延についても同様の傾向を示します。low effortでは、最初のトークンは通常1秒を大きく下回る時間で表示されます。high effortでは、モデルは回答が始まる前にはるかに大きな推論ドラフトを生成するため、1,500トークンの内部ドラフトを1秒あたり60トークン（例示）の速度で生成すると、表示される応答が約25秒遅れます。thinking_deltaブロックを折りたたみ可能な「Thinking…」パネルにストリーミングすることが、エンドユーザーにとってその待ち時間を許容可能なものにするのです。
移行と総所有コスト（TCO）
固定計算モデルから移行する場合の最大の変化は、推論の深さが呼び出しごとに支払う定額料金ではなく、リクエストごとに設定するダイヤルになることです。請求書に対する最大のレバーは、個々の呼び出しのeffortレベルではなく、そもそもどのリクエストがhigh effortレベルに値するかを決定するルーティング層です。高価なhigh effort呼び出しを制限する、数百トークン程度の軽量なlow effort分類呼び出しは、ほぼ常にそれ自体のコストを回収します。
総所有コストを予測可能に保つための2つの習慣があります。第一に、寛大なグローバルデフォルトを設定するのではなく、各タスククラスを確実に解決する最小限のeffortレベルを設定することです。どこにでもmax effortレベルを適用することが、予期しない請求の最も一般的な原因です。第二に、安定したシステムプロンプトをキャッシュして、推論サイクルごとに重複するコンテキストが再請求されないようにすることです。リクエストごとのルーティングとプロンプトキャッシュを組み合わせることで、支出の大部分を、真にその恩恵を受ける少数のリクエストに集中させることができます。
主なポイント
- Fable 5（
claude-fable-5、100万トークンのコンテキスト、最大128Kの出力）は思考を常時オンに保ちます。切り替えるのではなく、その深さを調整します。 - 推論の深さは
output_config: {effort: "low" | "medium" | "high" | "xhigh" | "max"}で構成します。budget_tokensやthinking.typeの"enabled"/“disabled"は、現在HTTP 400を返します。 thinkingコンテンツブロック（thinking_deltaデルタ）を介して思考をストリーミングし、モデルのステップをエンドユーザーに表示します。読みやすい要約を得るにはthinking: {type: "adaptive", display: "summarized"}でオプトインします。- 実用的な最小限のeffortレベルを選択し、頻繁に使用されるプロンプトをキャッシュすることで、API請求コストを制御します。
- APIミドルウェアをサーバーレスのエッジネットワークにデプロイして、転送遅延を削減します。
よくある質問(FAQ)
Claude Fable 5推論とは何ですか？
Claude Fable 5推論は、最終的な応答を出力する前に、複雑な論理問題を解決するためにモデルが内部の思考トークンを生成する、常時オンの機能です。すぐに次の単語を予測しようとするのではなく、ネットワークは段階的な思考プロセスをシミュレートして、設計、数学、およびコーディングのエラーを解決します。そして、effort設定によってどれだけ深く思考するかを調整します。
APIで推論のeffortを構成するにはどうすればよいですか？
APIリクエストペイロード内でoutput_config: { effort: "low" | "medium" | "high" | "xhigh" | "max" }を渡すことで、推論の深さを構成します。低いeffortレベルは短時間だけ思考し、より少ないトークンで素早く回答します。一方、高いレベルはより深く推論します。従来のbudget_tokensパラメータは削除され、現在Fable 5ではHTTP 400エラーを返します。
推論トークンの課金方法は異なりますか？ いいえ、推論トークンはモデルの標準的な出力トークンレートで課金されます。これらのトークンは出力計算を表すため、APIの請求に直接カウントされます。ソフトウェアの支出を管理するには、プロンプトキャッシュと適切なeffortレベルの設定が不可欠です。
Fable 5をより速く応答させるにはどうすればよいですか？
推論を無効にすることはできません。Fable 5では思考が常時オンであり、thinking: {type: "disabled"}を渡すとHTTP 400エラーが返されます。遅延を減らすには、output_config: { effort: "low" }でeffortレベルを下げます。これにより思考フェーズが短縮され、基本的な会話タスクの最初のトークンまでの時間が最小限に抑えられます。
リアルタイムでSSEストリームから推論トークンを解析するにはどうすればよいですか？
サーバーレスSSEストリーミング中、思考はdelta.typeがthinking_deltaであるcontent_block_deltaイベントを通じてthinkingコンテンツブロックとして届きます。テキストはdelta.thinkingから読み取り、標準のtext_delta出力とは分離します。読みやすい要約を受け取るにはthinking: {type: "adaptive", display: "summarized"}でオプトインし、その後フロントエンドUIの好みに基づいてこれらのトークンをレンダリングまたは破棄します。
コメント