Amazon Bedrock で Claude Fable 5.1 が利用可能になったので Converse API から呼び出してみた
はじめに
2026年9月1日、Anthropic の Claude Fable 5.1 が Amazon Bedrock と Claude Platform on AWS で利用可能になりました。
AWS CLI から Converse API と InvokeModel API で Fable 5.1 を呼び出し、事前に必要な設定と返ってきたレスポンスを確認しました。
検証内容
検証は 2026年9月2日に us-east-1 で、AWS CLI 2.36.36 を使って実施しました。このバージョンでは、データ保持モードを確認・変更するコマンドを利用できました。
データ保持モード
Fable 5.1 のモデルカードは、利用にあたって Data Retention API でアカウントのデータ保持モードを aws_review に設定することを求めています。
Fable 5.1 は Covered Model に指定されており、AWS のブログによると、利用にあたっては最大30日のデータ保持と Amazon の担当者によるレビューの対象になります。aws_review は、AWS が安全性審査のためにプロンプトと出力を AWS の境界内で保持するモードです。Fable 5.1 はモデルプロバイダーとの共有を必要としません。
現在の値を読み取ってから切り替えました。
aws bedrock get-account-data-retention
aws bedrock put-account-data-retention --mode aws_review
切り替える前の読み取り結果です。
{
"mode": "provider_data_share",
"updatedAt": "2026-06-09T23:46:41.595000+00:00"
}
切り替えた後の読み取り結果です。
{
"mode": "aws_review",
"updatedAt": "2026-09-01T19:49:15.480000+00:00"
}
変更に必要なパラメータは --mode だけです。モデルIDは指定せず、アカウント単位で設定します。
Converse 呼び出し
Global の推論プロファイルを指定して、Converse API を呼びました。
aws bedrock-runtime converse \
--model-id "global.anthropic.claude-fable-5-1" \
--messages '[{"role":"user","content":[{"text":"こんにちは!あなたのモデル名を教えてください。一言で。"}]}]' \
--inference-config '{"maxTokens":100}'
応答テキストと usage、metrics が返りました。
{
"output": {
"message": {
"role": "assistant",
"content": [
{
"text": "こんにちは!Claudeです。"
}
]
}
},
"stopReason": "end_turn",
"usage": {
"inputTokens": 32,
"outputTokens": 14,
"totalTokens": 46,
"cacheReadInputTokens": 0
},
"metrics": {
"latencyMs": 2062
}
}
この Converse 呼び出しでは、content に text ブロックだけが入り、reasoningContent ブロックは含まれませんでした。思考の内容が返る条件は次の節で扱います。
モデルIDには推論プロファイルを指定します。モデルカードの Programmatic Access では In-Region endpoint URL が N/A です。Geo なら us.anthropic.claude-fable-5-1、Global なら上で指定した global.anthropic.claude-fable-5-1 を指定します。US Geo の推論プロファイルでも、同じプロンプトで応答が返りました。
reasoning effort
思考の深さを指定する effort は output_config の下に置きます。モデルカードには、effort が low / medium / high / xhigh / max の5段階で、既定は high と記載されています。Converse API でも次の形で通りました。
--additional-model-request-fields '{"output_config":{"effort":"max"}}'
指定の効果を数値で見るために、output_tokens_details.thinking_tokens を得られる InvokeModel で計測しました。ネイティブのリクエストボディでは、output_config をトップレベルに置きます。
{
"anthropic_version": "bedrock-2023-05-31",
"max_tokens": 6000,
"messages": [
{
"role": "user",
"content": "ある農場にニワトリとウシがいます。頭の数の合計は30、脚の数の合計は74です。それぞれ何頭ですか。考え方も示してください。"
}
],
"output_config": {
"effort": "max"
}
}
aws bedrock-runtime invoke-model \
--model-id "global.anthropic.claude-fable-5-1" \
--content-type application/json --accept application/json \
--body "fileb://body-effort-max.json" \
05-effort-max.json
effort 未指定側は、このボディから output_config を落としたものです。同一のつるかめ算プロンプトを、effort 未指定と max で各1回ずつ実行しました。次の表の出力トークンと経過時間は1回の実行値であり、同じプロンプトでも実行ごとに変動します。
| effort | output_tokens | thinking_tokens | content ブロック | 実測経過 |
|---|---|---|---|---|
| 未指定(既定 high) | 382 | 0 | text | 8,362 ms |
| max | 956 | 410 | thinking, text | 13,724 ms |
経過時間は date +%s%3N の差分です。InvokeModel のレスポンスには、Converse の metrics.latencyMs に相当するフィールドがありません。
表のとおり、effort によって content ブロックの構成が変わるため、位置は固定できません。AWS のブログのサンプルコードも、固定インデックスではなく type で text ブロックを選ぶ形になっています。
プロンプトキャッシュ
モデルカードでは、1つの cache checkpoint に必要な最小トークン数は 512 です。1リクエストあたりの checkpoint 数は最大4つで、TTL は 5 分と 1 時間です。checkpoint は system、messages、tools に置けます。
system(695 tokens)の末尾に cache checkpoint を置きました。用語集の本文に続けて cachePoint ブロックを並べる形です。次の JSON は用語集の行を途中で省略しています。
[
{"text": "You are a glossary reference. Answer strictly from the glossary below.\n1. The term 'cache checkpoint' is defined in the Amazon Bedrock user guide as a concept used when invoking a model.\n2. The term 'foundation model' is defined in the Amazon Bedrock user guide as a concept used when invoking a model."},
{"cachePoint": {"type": "default"}}
]
aws bedrock-runtime converse \
--model-id "global.anthropic.claude-fable-5-1" \
--system "$(cat system-695.json)" \
--messages '[{"role":"user","content":[{"text":"Reply with the single word: ok"}]}]' \
--inference-config '{"maxTokens":20}'
1回目はキャッシュ書き込みになりました。
{
"usage": {
"inputTokens": 16,
"outputTokens": 4,
"totalTokens": 715,
"cacheReadInputTokens": 0,
"cacheWriteInputTokens": 695,
"cacheDetails": [
{
"ttl": "5m",
"inputTokens": 695
}
]
}
}
約2秒後に同じリクエストを実行すると、695 tokens がキャッシュ読み出しとして計上されました。
{
"usage": {
"inputTokens": 16,
"outputTokens": 4,
"totalTokens": 715,
"cacheReadInputTokens": 695
}
}
続いて、リクエストの形は変えず、system の用語集の行数を減らし、入力全体が最小トークン数 512 を下回る状態にして実行しました。
1回目: {"inputTokens": 377, "outputTokens": 4, "totalTokens": 381, "cacheReadInputTokens": 0}
2回目: {"inputTokens": 377, "outputTokens": 4, "totalTokens": 381, "cacheReadInputTokens": 0}
1回目に cacheWriteInputTokens は付かず、レスポンスでは入力 377 tokens の全量が inputTokens に入りました。
まとめ
データ保持モードを aws_review に切り替え、推論プロファイル付きのモデルIDを指定すれば、公開当日でも Converse API から Claude Fable 5.1 を呼び出せました。
データ保持モードはアカウント単位の設定です。aws_review にすると、そのアカウントから送るプロンプトと出力が保持とレビューの対象になるため、試す前に所属組織のデータ取り扱い方針を確認してください。







