2026年9月2日時点で、Claude Fable 5.1はクラウド4経路（Amazon Bedrock／Google Cloud／Microsoft Foundry／Claude Platform on AWS）すべてで使えます。渡すモデルIDはBedrockだけが anthropic.claude-fable-5-1、残り3つは claude-fable-5-1。ただし「IDを差し替えれば動く」で済むのはここまでで、対応機能・リージョン・βヘッダーの可否はクラウドごとに違います。この記事は公式ドキュメントで一次確認できた事項だけを、確認できなかった事項と分けて並べます。
先に結論だけ言うと、選択を分けるのは性能ではありません。Fable 5.1は同じモデルなので、分岐点は「誰が推論基盤を運用するか」「どの機能が落ちるか」「請求書がどこから来るか」の3つです。とくにMicrosoft FoundryはFable 5.1に限りAzure内ホスティング版が提供されておらず、データゾーン要件がある案件では選択肢から外れます。
結論：Fable 5.1のクラウド選択は判断軸3つで決まる
AnthropicのClaude Fable 5.1 overviewによれば、リリースは2026年9月1日、コンテキストウィンドウ100万トークン、最大出力12万8千トークン、入力$10 / MTok・出力$50 / MTok。これはプラットフォームを問わないモデル自体の仕様です。したがって「どのクラウドが速いか・賢いか」で悩む必要はありません。実際に効いてくるのは次の3軸です。
軸1：誰が推論基盤を運用するか
Amazon BedrockはAWSが推論スタックを運用します。公式ドキュメントは「zero operator access（Anthropicの人員は推論インフラにアクセスしない）」と明記しており、AWSのセキュリティ境界の内側で完結させたい要件に向きます。Google CloudのAgent Platform（Anthropicのドキュメント上はVertex AIのURLで案内されている面）はGoogleが運用します。一方Microsoft Foundryには「Hosted on Azure（Azureインフラ上でAnthropicが運用）」と「Hosted on Anthropic（Anthropicインフラ上で運用）」の2つのホスティング選択肢がありますが、Claude in Microsoft Foundryのモデル表でFable 5.1にチェックが入っているのはHosted on Anthropicの列だけです。Opus 5・Opus 4.8・Sonnet 5・Haiku 4.5は両方に対応しているので、これはFable 5.1固有の制約になります。
軸2：どの機能が落ちるか
同じモデルでも、プラットフォームによって使えない機能があります。Bedrockでは server-side tools（code execution、web search、web fetch、advisor）、Agent Skills、MCP connector、programmatic tool calling、Message Batches API、Files API、Claude Managed Agents、server-side fallback が「Features not supported」として明記されています。Google Cloudは web search tool と structured outputs に対応する一方、code execution・web fetch・advisor・Agent Skills・MCP connector・Message Batches API などは非対応。Microsoft Foundryは Admin API・Advisor・Managed Agents・Compliance API・Models API・Message Batches API・server-side fallback が非対応で、さらに「Hosted on Azure」を選んだ場合だけ code execution・Agent Skills・programmatic tool calling・Files API も落ちます（Fable 5.1はHosted on Anthropicのみなので後者は該当しません）。
軸3：請求書がどこから来るか
BedrockとGoogle Cloudは、それぞれAWS・Googleがネイティブサービスとして課金します。Microsoft FoundryとClaude Platform on AWSはClaude Consumption Unit（CCU）建てで、$0.01 / CCU固定、100 CCUが$1.00 USDに相当し、Azure MarketplaceまたはAWS Marketplace経由で月次請求されます。前払いクレジットではなく後払い、時間単位で計測される点も共通です。既存のクラウドコミット消化やマーケットプレイス調達の都合が効くのはこの軸で、社内稟議の通りやすさが変わります。
プラットフォーム別モデルID一覧（2026年9月2日時点）
公式ドキュメントのSpecifications「Model IDs」表がそのまま答えです。移行時にコピペする値はこれだけです。
| プラットフォーム | モデルID |
|---|---|
| Claude API | claude-fable-5-1 |
| Amazon Bedrock | anthropic.claude-fable-5-1 |
| Google Cloud | claude-fable-5-1 |
| Microsoft Foundry | claude-fable-5-1 |
| Claude Platform on AWS | claude-fable-5-1 |
ポイントは3つあります。第一に、プロバイダプレフィックス anthropic. が付くのはAmazon Bedrockだけです。同じAWS上でもClaude Platform on AWSはプレフィックスなしの claude-fable-5-1 なので、AWS内で2経路を併用しているチームは定数を分ける必要があります。第二に、日付サフィックス（@20250929 のような形）が付きません。Google CloudのモデルID表を見ると、Sonnet 4.5以前は claude-sonnet-4-5@20250929 のように日付付きですが、Fable 5.1・Fable 5・Opus 5・Opus 4.6以降・Sonnet 5などは日付なしのIDになっています。この命名の変化そのものについてはClaudeモデルの日付なしIDとピン留めの考え方で扱いました。第三に、Microsoft FoundryだけはAPIに渡すのがモデルIDではなくデプロイ名です。既定のデプロイ名がモデルIDと同じ文字列になるだけで、ポータルでデプロイ名を変えたらそちらを渡します。
Amazon Bedrockで使う：エンドポイントとリージョンの制約
Claude in Amazon Bedrockのドキュメントは、Opus 4.7以降の新しい統合を扱っています。旧来の InvokeModel／Converse ベースの統合とは別物で、エンドポイントは https://bedrock-mantle.{region}.api.aws/anthropic/v1/messages、リクエストボディの形はAnthropicのファーストパーティAPIと同じ、ストリーミングは標準SSEです。Fable 5.1は「全Amazon Bedrock顧客にopen」と記載されています（AWSコンソールのModel accessで対象モデルを有効化する前提）。
curlで最初の1回を通す
curl https://bedrock-mantle.us-east-1.api.aws/anthropic/v1/messages \
--aws-sigv4 "aws:amz:us-east-1:bedrock-mantle" \
--user "$AWS_ACCESS_KEY_ID:$AWS_SECRET_ACCESS_KEY" \
-H "x-amz-security-token: $AWS_SESSION_TOKEN" \
-H "content-type: application/json" \
-H "anthropic-version: 2023-06-01" \
-d '{
"model": "anthropic.claude-fable-5-1",
"max_tokens": 1024,
"messages": [
{"role": "user", "content": "Hello, Claude"}
]
}'
Python SDK（anthropic[bedrock]）
公式ドキュメントが案内するのは pip install -U "anthropic[bedrock]" と AnthropicBedrockMantle クライアントです。認証情報とリージョンはAWSの標準的な優先順（コンストラクタ引数 → 環境変数 → AWS設定ファイルと認証情報チェーン）で解決されます。
from anthropic import AnthropicBedrockMantle
client = AnthropicBedrockMantle(aws_region="us-east-1")
message = client.messages.create(
model="anthropic.claude-fable-5-1",
max_tokens=1024,
messages=[{"role": "user", "content": "Hello, Claude"}],
)
print(next(block.text for block in message.content if block.type == "text"))
boto3を使いたい場合の扱いは注意が必要です。Claude on Amazon Bedrock（Opus 4.6以前）のページには「Claude Fable 5.1、Claude Fable 5、Claude Opus 5、Claude Sonnet 5、Claude Opus 4.8、Claude Opus 4.7は bedrock-runtime の InvokeModel からも到達でき、これらのリクエストはClaude in Amazon Bedrockのエンドポイントと同じ基盤で処理される」と明記されています。ただし同じ注記が「これらのモデルはARN付きのモデルIDを持たないため、このページのモデルID表からは省いている」とも書いており、InvokeModelに渡す正確な文字列はそのページでは確認できません。ネイティブのリクエスト形と機能パリティが必要なら新しいMessages APIエンドポイントを使う、というのが公式の案内です。
リージョンとクロスリージョン推論
Bedrockのエンドポイント種別は2つです。グローバルは利用可能な全リージョンへ動的ルーティングし、価格の上乗せはありません。リージョナルは指定した単一AWSリージョンに解決され、グローバルに対して10%の価格プレミアムが付きます。Fable 5.1については「グローバルエンドポイントは利用可能」「リージョナルエンドポイントは現時点で us-east-1 のみ」と明記されています。つまり東京リージョンでリージョナル固定するという構成は、2026年9月2日時点のFable 5.1では取れません。地理内（US／EU／JP／AU）で複数リージョンにまたがってルーティングしたい場合は inference profile を使う、という案内も同ページにあります。推論プロファイルの考え方そのものはGPT-5.6のBedrockクロスリージョン推論ガイドで整理した内容がそのまま応用できます。ただしFable 5.1に対してJPプロファイルが利用できるかどうかは、公式ページ上の記載を確認できていません。
クォータは既定で入力200万トークン／分（TPM）、Anthropicの追加承認なしで入力500万TPM・出力50万TPMまで引き上げ申請が可能、RPMの調整はAWSサポート経由と記載されています。ログはCloudWatchとCloudTrailの両方に出力され、30日ローリングでの保持が推奨されています。
Claude CodeをBedrock経由でFable 5.1に向ける場合は、Claude Code 2.1.255以降が必要です（claude update で更新）。この条件はBedrockのページに明記されていますが、Google CloudとMicrosoft Foundryのページには同種のバージョン条件の記載を確認できませんでした。
Google Cloud（Agent Platform）で使う：モデルIDはURLに入る
Google Cloud経路の最大の違いはリクエストの形です。Claude on Google Cloudのドキュメントによれば、(1) model はリクエストボディに入れずエンドポイントURLに含める、(2) anthropic_version をヘッダーではなくボディに入れて vertex-2023-10-16 を指定する、の2点がClaude APIと異なります。この2点を知らずにClaude API用のコードを流用すると、モデルIDの差し替えだけでは通りません。
MODEL_ID=claude-fable-5-1
PROJECT_ID=MY_PROJECT_ID
curl https://aiplatform.googleapis.com/v1/projects/${PROJECT_ID}/locations/global/publishers/anthropic/models/${MODEL_ID}:rawPredict \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
-d '{
"anthropic_version": "vertex-2023-10-16",
"messages": [{"role": "user", "content": "Hey Claude!"}],
"max_tokens": 100
}'
SDKを使う場合は pip install -U "anthropic[vertex]" で AnthropicVertex を使います。事前に gcloud auth application-default login が必要な場合がある、と公式に注記があります。
from anthropic import AnthropicVertex
client = AnthropicVertex(project_id="MY_PROJECT_ID", region="global")
message = client.messages.create(
model="claude-fable-5-1",
max_tokens=100,
messages=[{"role": "user", "content": "Hey Claude!"}],
)
print(message)
Google公式のモデルカードが示す条件
Google Cloud側のClaude Fable 5.1 on Google Cloud（最終更新2026年9月1日）には、Anthropic側ドキュメントにない情報が載っています。モデルIDは claude-fable-5-1、Launch stageはGA、リリース日は2026年9月1日、最大入力1,000,000トークン・最大出力128,000トークン、入力はText／Image／PDF、出力はText。対応機能として Computer use、Web search、Batch predictions、Prompt caching、Function calling、Count tokens が挙げられています。
提供リージョンは「モデル提供＝United States（マルチリージョン）／Europe（マルチリージョン）／Global（グローバルエンドポイント）」「ML処理＝United Statesマルチリージョン、Europeマルチリージョン、Asia Pacificの asia-southeast1」という書き分けになっています。日本リージョン（asia-northeast1）の記載はありません。有効化にはModel GardenでAdvanced AI Safety Addendumへの同意（プロジェクトごとに1回）が必要で、プロンプトとレスポンスは利用規約の悪用監視目的で最大30日保存されます。ペイロードは30MB上限で、大量の画像や長大な文書ではトークン上限より先にこちらに当たることがあります。
見落としやすいのが退役日です。Google Cloud側のページは「Retirement date: No sooner than March 1, 2027」と書いていますが、Anthropic側のoverviewは「Not sooner than September 1, 2027」です。Anthropicのドキュメント自身が「パートナー運用プラットフォームのライフサイクル日程はパートナーが設定し、Claude APIのスケジュールと異なることがある」と注記しているので、これは矛盾ではなく仕様です。クラウド経由で使うなら、退役日はそのクラウドのページで確認するのが正解になります。
もうひとつ、記述が食い違って見える箇所があります。Anthropic側のGoogle Cloudページは「Message Batches API」を非対応機能に挙げていますが、Google側モデルカードは「Batch predictions」を対応機能に挙げています。両者は別のエンドポイント（AnthropicのMessage Batches APIと、Agent Platform自身のバッチ予測）を指していると読むのが自然ですが、その対応関係は公式ページ上に明示されていません。バッチ処理前提の設計をするなら、どちらのバッチを指しているかを先に確定させてください。
Microsoft Foundryで使う：呼ぶのはモデルIDではなくデプロイ名
Foundryはリソースとデプロイの2階層です。リソースがセキュリティと課金の設定を持ち、デプロイがAPIから呼ぶモデルの実体になります。エンドポイントは https://{resource}.services.ai.azure.com/anthropic/v1/messages、認証はAPIキー（api-key または x-api-key ヘッダー）とMicrosoft Entra IDの2方式です。
curl https://{resource}.services.ai.azure.com/anthropic/v1/messages \
-H "content-type: application/json" \
-H "api-key: YOUR_AZURE_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-d '{
"model": "claude-fable-5-1",
"max_tokens": 1024,
"messages": [
{"role": "user", "content": "Hello!"}
]
}'
SDKは AnthropicFoundry クライアントを使います。C#・Java・PHP・Python・TypeScriptが対応で、GoとRubyのSDKは現時点でFoundry非対応と明記されています。環境変数は ANTHROPIC_FOUNDRY_API_KEY、ANTHROPIC_FOUNDRY_RESOURCE、ANTHROPIC_FOUNDRY_BASE_URL の3つが自動で読まれます（リソース名とベースURLは排他）。
import os
from anthropic import AnthropicFoundry
client = AnthropicFoundry(
api_key=os.environ.get("ANTHROPIC_FOUNDRY_API_KEY"),
resource="example-resource", # リソース名
)
message = client.messages.create(
model="claude-fable-5-1", # 既定のデプロイ名。ポータルで変えた場合はそちらを渡す
max_tokens=1024,
messages=[{"role": "user", "content": "Hello!"}],
)
print(message.content)
Foundry固有の注意点を3つ挙げます。ひとつめはデプロイ名がそのままAPIの model 値になること。ポータルで「my-claude-deployment」のような名前を付けたら、リクエストにもその文字列を渡します。デプロイ名は作成後に変更できません。ふたつめはFable 5.1のホスティングがHosted on Anthropicのみであること。Hosted on Azureのデプロイで選べるUS Data Zone Standard（推論を米国内に留める、Claude APIの inference_geo: "us" 相当）は、Fable 5.1では選択できません。みっつめはレート制限ヘッダーが返らないこと。anthropic-ratelimit-* 系のヘッダーはFoundryのレスポンスに含まれないため、429対策のバックオフをヘッダー値に依存させている実装はそのままでは動きません。Azure側の監視ツールで管理する、というのが公式の案内です。
サポートに問い合わせるときは request-id と apim-request-id（Azure API Management側の識別子）の両方を伝えるよう案内されています。Fable 5.1のFoundry提供開始は、Microsoft Foundry Blogの2026年9月1日付の告知でモデルカタログ掲載としてアナウンスされました。AWS側も同日にWhat’s NewでBedrockとClaude Platform on AWSの2経路を案内しています。
3クラウド共通の落とし穴：破壊的変更3点はクラウド経由でも同じ
What’s new in Claude Fable 5.1が挙げる破壊的変更3点は、いずれもモデル側の挙動として書かれており、プラットフォーム別の例外は記載されていません。したがってクラウド経由でも同じ前提で設計します。Claude API直での直し方はClaude Fable 5.1 API移行ガイドにコード付きでまとめてあるので、ここではクラウド固有の効き方だけを補足します。
1. forced tool useが400になる
tool_choice に {"type": "any"} または {"type": "tool", "name": "..."} を渡すと 400 invalid_request_error が返り、エラーメッセージは tool_choice: type "tool" and "any" are not supported for this model. です。{"type": "auto"}（既定）と {"type": "none"} は従来どおり。同じ検証がtoken countingエンドポイントにも適用されます。公式が示す代替は、strict tool use（strict: true）を tool_choice: auto と併用するか、スキーマをstructured outputsへ移すか、プロンプトで「この場合は get_weather ツールを使う」と明示するかの3通りです。
ここでクラウド差が効きます。Bedrockのページは structured outputs を「Features not supported」に挙げているため、代替の1本が使えない可能性があります。Bedrockでforced tool useを外すなら、プロンプトでの明示指示か strict tool use に寄せるのが現実的です（strict tool useの可否については次節の食い違いも参照してください）。
2. thinkingブロックはモデルに紐づく（前方向のみ保持）
thinkingブロックには生成したモデルが記録され、保持は一方向です。Fable 5.1は過去モデルのthinkingブロックを読めますが、過去モデルはFable 5.1のthinkingブロックを読めません。ルーターやフォールバックで会話の途中にモデルを切り替えると、APIはモデルが読めないブロックを見せる前に落とします。落とされたブロックは input_tokens に計上されず課金もされませんが、thinking-binding-controls-2026-08-01 βヘッダーを付けない限りドロップは無言です。
実務的に効くのは、signature 値がプラットフォーム間で互換だという公式記載です。thinkingのドキュメントは「signature値はClaude API、Amazon Bedrock、Google Cloudの間で互換で、一方で生成した値は他方でも動く」と書いています。マルチクラウド構成でフェイルオーバーする設計では、この一文が前提条件になります。
3. 過去ターンの編集でthinkingブロックが無効になる
Fable 5.1のthinkingブロックより前にある要素（system プロンプト、tools 配列、過去メッセージ）を書き換えると、次のリクエストでエラーになるか、オプトインした場合はブロックが落とされます。この検証は2026年8月31日以降に作成されたアカウントでは強制で、それ以前のアカウントでは thinking.block_binding.prefix_mismatch_behavior を設定したときだけ作用します。拒否時のメッセージは The block is bound to a different conversation を含む400です。
無効化を招く典型パターンは、過去ターンの編集・並べ替え・削除、リクエストごとに注入して次で消す注意書き、リクエスト間での system や tools の作り直し、同じURLで別バイトを返す画像や文書です。逆に、先頭から連続するthinkingブロックの削除、サーバー側のcontext editingやcompactionによる履歴の切り詰め、cache_control マーカーの移動、リクエスト間の effort 変更は安全です。会話を追記のみ（append-only）として扱うのが原則で、これはプロンプトキャッシュを温存する条件とも一致します。
βヘッダー機能はクラウドで使えるのか（公式間で記述が食い違う2点）
Fable 5.1の目玉であるβ機能3種（会話途中のeffort変更、ターン限定systemメッセージ、ツール呼び出し間の進捗テキスト）は、クラウド経由でも使えるのか。ここは公式ページ間で記述が一致していない部分がありますので、確認できた記述をそのまま並べます。実装の詳細はClaude Fable 5.1新機能β3種の実装ガイドにまとめてあります。
| 機能／βヘッダー | 公式ページ上の記述（2026年9月2日時点） |
|---|---|
| effort（トップレベル、βヘッダー不要） | Effortページの Compatibility に「Platforms: Claude API, Claude Platform on AWS, Amazon Bedrock, Google Cloud, Microsoft Foundry」と明記 |
会話途中のeffort変更mid-conversation-output-config-2026-07-01 |
What’s newは「Claude Fable 5.1、Claude Mythos 5.1、Claude Opus 5がClaude APIで対応」と書く。クラウド別の可否の記載は確認できていない |
ターン限定systemメッセージmid-conversation-system-clear-at-2026-08-21 |
Mid-conversation system messagesページに「同じモデル・同じプラットフォーム」＝Claude API／Amazon Bedrock／Google Cloud。Microsoft Foundryは列挙されていない |
進捗テキストthinking-display-updates-2026-08-18 |
Thinkingページに「Amazon Bedrock、Google Cloud、Microsoft FoundryではBeta headersの記載どおりbeta値を渡す」 |
thinkingブロック制御thinking-binding-controls-2026-08-01 |
Thinkingページに「Amazon BedrockとGoogle Cloudではbeta名をBeta headersの記載どおり渡す」 |
問題はここからです。Claude Platform on AWSのページにある比較表は、「Beta features」の行でClaude in Amazon Bedrockについて「anthropic-beta ヘッダー非対応」と書いています（Claude Platform on AWSは「anthropic-beta ヘッダーでパススルー」）。上の表の3〜5行目とは正面から食い違います。
もう1点、structured outputsについても同様の食い違いがあります。Bedrockのページは「Features not supported」にstructured outputsを挙げていますが、Features overviewの一覧表ではstructured outputsの行にbedrockがラベルなし（＝安定・本番利用推奨）で並んでいます。web searchについてはFeatures overviewもbedrockを外しており、Bedrockページと一致しているので、全体が古いわけではなさそうです。
どちらが最新かを公式が明示していない以上、取れる判断は決まっています。β機能や structured outputs を前提にした設計は Claude API か Claude Platform on AWS に寄せる。Bedrock／Google Cloud／Foundryで使いたい場合は、本番設計を固める前に最小リクエストを1本投げて400が返るかを実測する。この順序を守れば、ドキュメントの食い違いに実装が引きずられません。
料金の見方：$10／$50はどこまで共通か
モデル自体の価格はAnthropicの料金ページに一覧があります。Fable 5.1は入力$10 / MTok、出力$50 / MTok、5分キャッシュ書き込み$12.50 / MTok、1時間キャッシュ書き込み$20 / MTok、キャッシュ読み取り$0.25 / MTok、Batch APIは入力$5 / MTok・出力$25 / MTok。
注目すべきはキャッシュ読み取りです。他のClaudeモデルは基本入力価格の0.1倍ですが、Fable 5.1とMythos 5.1は0.025倍と明記されています。キャッシュ済みプレフィックスを何度も読み直す長時間のエージェントセッションでは、この差がそのままコスト差になります。キャッシュ書き込み価格と、キャッシュ可能な最小プロンプト長512トークンは変わっていません。
ただしこの表はClaude APIの価格です。AnthropicのページはBedrockとGoogle Cloudについて「公式価格はAmazon Bedrock pricingとGoogle Cloud pricingで確認せよ」と明示的に外部へ案内しています。したがってクラウド経由の実額は各社の価格表で確認してください。本記事ではAWS・Googleの価格ページを一次確認していないため、両クラウドでの実際のトークン単価は記載しません。
クラウド固有の価格構造として確認できるのは次の3点です。第一に、リージョナル／マルチリージョンのエンドポイントはグローバルに対して10%の価格プレミアムが付きます（Claude Sonnet 4.5・Haiku 4.5・Opus 4.5以降のモデルが対象、Bedrockは2種類、Google Cloudは3種類のエンドポイントを提供）。第二に、Microsoft FoundryとClaude Platform on AWSはCCU建てで、トークン利用をUSDで算定→割引適用→$0.01 / CCUでCCUに換算→時間単位でマーケットプレイスへ報告、という流れです。請求書にはCCUの1行が出ます。第三に、FoundryのUS Data Zone Standardは inference_geo: "us" 相当で1.1倍の乗数が付きますが、前述のとおりFable 5.1はHosted on Anthropicのみなのでこの選択肢自体が使えません。
データ保持についても押さえておきます。Fable 5.1とMythos 5.1は30日のデータ保持が付き、Anthropicが明示的に許可した場合を除きゼロデータ保持（ZDR）では利用できません。両モデルはCovered Modelに指定されており、この扱いは提供されるすべての場所に及ぶとAWSの告知にも書かれています。
移行チェックリスト（クラウド別に確認する9項目）
- モデルIDを差し替える：Bedrockは
anthropic.claude-fable-5-1、Google Cloud／Foundry／Claude Platform on AWSはclaude-fable-5-1。AWS内で2経路を併用しているなら定数を分ける。 - Foundryはデプロイ名を確認する：
modelに渡すのは既定ではモデルIDと同じ文字列だが、カスタムデプロイ名を付けていればそちら。 tool_choiceのany／toolを全部外す：残っていると400。strict tool use＋tool_choice: auto、structured outputs、プロンプトでの明示指示のいずれかへ移す。- 履歴の作り方を追記のみに変える：per-turnの注入と削除、
system／toolsの作り直しをやめる。Claude Code、claude.ai、Claude Managed Agents、Claude Agent SDK経由なら自動的に保たれる。 - ルーター／フォールバックの経路を洗う：Fable 5.1から旧モデルへ戻す経路があると、その区間のthinkingが失われる。
thinking-binding-controls-2026-08-01とprefix_mismatch_behavior: "drop_block"でドロップを可視化してから判断する。 - 使う予定の機能がそのクラウドで落ちていないか確認する：Bedrockはserver-side toolsとMessage Batches API、Google Cloudはcode executionとweb fetch、FoundryはModels APIとMessage Batches APIが非対応。server-side fallbackは3クラウドとも非対応でクライアント側フォールバックに置き換える。
- リージョン要件を再確認する：Fable 5.1のBedrockリージョナルエンドポイントは
us-east-1のみ。Google CloudのモデルカードはUS／EUマルチリージョンとグローバル、ML処理にasia-southeast1。 - β前提の機能は実測してから採用する：公式ページ間で
anthropic-betaヘッダーの可否の記述が食い違っている。最小リクエストで400が返るかを確かめる。 - effortを既定値から再調整する：Fable 5.1の既定は
high。低いeffortでは検索や取得ツールの呼び出しが減るという挙動変化が公式に明記されているので、鮮度が要るターンだけ上げる設計にする。
失敗しやすいパターン3つ
パターン1：モデルIDだけ替えて本番投入する。 IDの差し替えは移行の1行目にすぎません。forced tool useが残っていれば即400、履歴を書き換える実装が残っていればthinking無効化の400が後から出ます。しかも後者は2026年8月31日以降に作成したアカウントでのみ強制されるため、古いアカウントの開発環境では再現せず、新しく作った本番アカウントで初めて出るという順序になりがちです。
パターン2：Claude APIのドキュメントだけ読んでクラウドの機能表を見ない。 Bedrockでcode executionやweb searchを前提にしたエージェントを組んでから、非対応に気づくケースです。3クラウドとも「Features not supported」の節を持っているので、着手前にそこだけ先に読むのが安全です。
パターン3：退役日をClaude APIの日付で管理する。 Google Cloud側は2027年3月1日以降、Anthropic側は2027年9月1日以降と、半年ずれています。パートナー運用プラットフォームの日程はパートナーが決めるとAnthropic自身が書いているので、監視対象はそのクラウドのページにしてください。
よくある質問
Claude Fable 5.1はAmazon Bedrockですぐ使えますか？
使えます。公式ドキュメントはFable 5.1を含む主要モデルについて「全Amazon Bedrock顧客にopen」と書いています。AWSコンソールのModel accessで対象モデルのアクセスを有効化したうえで、anthropic.claude-fable-5-1 を bedrock-mantle.{region}.api.aws/anthropic/v1/messages に渡します。
東京リージョン（ap-northeast-1）で使えますか？
Bedrockのリージョン表では ap-northeast-1 は Global／JP／In-region only のエンドポイント種別を持ちますが、Fable 5.1のリージョナルエンドポイントは us-east-1 のみと明記されています。つまり東京でのリージョナル固定は現時点では取れず、グローバルエンドポイント経由になります。Fable 5.1に対してJPの inference profile が使えるかどうかは、2026年9月2日時点で公式ページ上の記載を確認できていません。
boto3の InvokeModel から呼べますか？
公式のlegacyページに「Fable 5.1は bedrock-runtime の InvokeModel からも到達でき、Claude in Amazon Bedrockのエンドポイントと同じ基盤で処理される」と記載があります。ただし同ページは「これらのモデルはARN付きモデルIDを持たないためモデルID表から省いた」とも書いており、InvokeModelに渡す正確なID文字列はそのページからは確認できません。ネイティブのリクエスト形と機能パリティが必要なら新しいMessages APIエンドポイントを使う、というのが公式の案内です。
Claude CodeをBedrock経由でFable 5.1に向けられますか？
できます。Bedrockのページに「Claude Fable 5.1をAmazon Bedrockで使うにはClaude Code 2.1.255以降を使い、claude update で更新すること」と明記されています。またClaude Code内で /claude-api migrate を実行すると、コードベース全体のモデルID差し替えと破壊的パラメータ変更を適用でき、対象クラウドを判別してIDの形式や機能差を調整する、と各クラウドのページに共通の案内があります。
Microsoft FoundryでUS Data Zone Standardを使えますか？
Fable 5.1では使えません。US Data Zone StandardはHosted on Azureのデプロイで選ぶ配置ですが、Foundryのモデル表でFable 5.1にチェックが入っているのはHosted on Anthropicの列だけです。Azure内で推論を完結させる要件があるなら、両ホスティングに対応しているOpus 5・Opus 4.8・Sonnet 5・Haiku 4.5が候補になります。
Claude Mythos 5.1はクラウドで使えますか？
Mythos 5.1はProject Glasswingの参加者のみに提供され、アクセスにはAnthropic、AWS、またはGoogle Cloudのアカウントチームへの連絡が必要と公式に書かれています。BedrockとFoundryのモデル表に載っているのは「Claude Mythos Preview」（招待制）で、これはMythos 5.1とは別の表記です。Mythos 5.1のクラウド別モデルIDは、2026年9月2日時点で公式ページ上の記載を確認できていません。
Bedrockと Claude Platform on AWSはどちらを選ぶべきですか？
公式の整理では、FedRAMP High・IL4・IL5・HIPAA対応が必要、またはAWSを唯一のデータ処理者にする必要がある組織はBedrock。機能をClaude API並みに早く使いたい場合はClaude Platform on AWS（機能提供が「典型的にはClaude APIと同日」、Agent Skills対応、anthropic-beta ヘッダーのパススルー）。両者は別のキャパシティプールを使うため、併用してフェイルオーバーさせることもできると書かれています。
2026年9月2日時点で確認できなかったこと
この記事は公式ドキュメントで裏が取れた範囲に限定しています。以下は「調べたが確認できなかった」項目です。
- Amazon Bedrock・Google CloudにおけるFable 5.1の実際のトークン単価（AnthropicはAWS・Googleの価格ページを見るよう案内しており、本記事では両社の価格ページを一次確認していない）
- Fable 5.1に対するJPの inference profile の利用可否
- legacy
InvokeModel経路でFable 5.1に渡す正確なモデルID文字列 - 会話途中のeffort変更（
mid-conversation-output-config-2026-07-01）のクラウド別可否（What’s newはClaude APIでの対応のみ言及） - Bedrockにおける
anthropic-betaヘッダーと structured outputs の可否（公式ページ間で記述が食い違っており、どちらが最新か明示されていない） - Claude Mythos 5.1のクラウド別モデルID
これらは実機での1リクエストか、AWS・Google・Microsoftの各公式ページで確認してください。ドキュメントが食い違っている領域を「たぶんこうだろう」で埋めると、本番で400を踏みます。
この記事を読んで導入イメージが固まってきた方へ
UravationではAIエージェント導入の研修・コンサルを行っています。クラウド経由でのモデル選定、社内ガイドライン、実装体制の立ち上げまで伴走します。
執筆：佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。著書『AIエージェント仕事術』。本記事の内容は2026年9月2日時点で各社の公式ドキュメントを参照して作成しています。
