AWS の Claude 400 エラー、メッセージ別の対処法

AWS 上の Claude から 400 が返ってきても、ステータスコードだけでは直す場所は決まりません。決め手はエラー本文の英文です。Extra inputs are not permitted なら途中のゲートウェイかフィールドの互換性、data retention mode 'default' is not available for this model ならアカウントの設定、Input is too long for requested model. なら会話の量と、同じ 400 でも担当者も手順もまったく違います。

最初に確かめるのは2点です。Claude Code から呼んでいるのか、自分のコード（InvokeModel、Converse、Bedrock 上の Messages API）から呼んでいるのか。そして、エラー本文の中心にある英文は何か。この2つが分かれば、下の早見表で該当する行を探し、対応する節に進めば足ります。バージョン番号とモデル ID は2026年9月25日時点の Anthropic と AWS の公式ドキュメントに基づきます。コマンドとコードも同じドキュメントに沿った例で、実際の AWS アカウントでの実行結果ではありません。

Claude Code か自前のコードかで、見る場所が変わる

Claude Code を Bedrock につないでいる場合（CLAUDE_CODE_USE_BEDROCK=1）、Claude Code は Bedrock の Invoke API（InvokeModel / InvokeModelWithResponseStream）だけを使い、Converse API には対応していません。そのため、Converse の inferenceConfig や additionalModelRequestFields を直す解説は、Claude Code の 400 には当てはまりません。Claude Code の利用者が手を入れられるのは、Claude Code のバージョン、環境変数、モデル ID とプレフィックス、会話履歴、途中のゲートウェイ、そして AWS アカウント側の設定です。

Claude Code がいま使っている接続先は /status に出ます。Amazon Bedrock なら Invoke API への直結、Amazon Bedrock (Mantle) なら Mantle エンドポイントで、モデル ID の書き方が変わります。ANTHROPIC_BASE_URL で社内ゲートウェイやプロキシ、外部の中継サービスを経由しているなら、途中でヘッダーが落ちていないかが最初の確認点です。設定の優先順位ごと確かめたいときは「Claude Code API 設定：キー、settings.json、モデル、ゲートウェイの確認手順」が使えます。

自分のコードから呼んでいる場合は、送っている本文がどの API の形式に合わせたものかが最初の分岐です。InvokeModel 向けの JSON を Converse に渡す、あるいはその逆は、見た目が似ていても 400 になります。

ステータスが 400 でなければ、別の問題です。

• 403：認証情報の期限切れか IAM 権限の不足（AccessDeniedException）。Claude Code では「AWS authentication failed」として表示されます。モデル ID へのアクセスがないという 403 なら、そのアカウントとリージョンでモデルを有効にします。
• 404 FTUFormNotFilled：Anthropic のユースケースフォームが未提出です。
• 429 ThrottlingException、503 ServiceUnavailable、529 overloaded_error：リクエストの形は正しく、量や混雑の問題です。どの上限に当たっているかは「Claude の Rate Exceeded: 再試行前に制限元を切り分ける」の手順で見分けられます。

エラー本文から原因を引く早見表

エラー本文の一部を表の左列で探してください。英文は原文のまま載せているので、ログとそのまま照合できます。

Claude Code で出やすい 400

Bedrock 共通、自前コードで出やすい 400

両方の表を通して、同じ本文のまま時間をおいて送り直す意味があるのは ServiceQuotaExceededException だけです。AWS はこのコードについて「後で再送できる」と説明しています。それ以外は、本文か設定かアカウントを変えない限り、何度送っても同じ 400 が返ります。

Claude Code の 400 を直す

Extra inputs are not permitted：途中でヘッダーが落ちていないか

Claude Code は context_management や effort といった beta 専用のフィールドを、それを有効にする anthropic-beta ヘッダーと一緒に送ります。社内ゲートウェイ、プロキシ、中継サービスが本文だけを転送してヘッダーを落とすと、受け手はそのフィールドを知らないものとして扱い、400 を返します。Anthropic のドキュメントが挙げる典型例は次の2つです。

API Error: 400 ... Extra inputs are not permitted ... context_management
API Error: 400 ... Unexpected value(s) for the `anthropic-beta` header

根本的な直し方は、ゲートウェイの設定で anthropic-beta ヘッダーを転送させることです。ゲートウェイに手を入れられない場合の代替策が CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 で、Claude Code を起動する前に環境変数として設定するか、settings.json の env に書きます。起動後にシェルで設定しても、動いているプロセスには反映されません。

export CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1
claude

{
  "env": {
    "CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS": "1"
  }
}

この変数は、Anthropic 固有の anthropic-beta ヘッダーと、defer_loading や eager_input_streaming といった beta 用のツール定義フィールドを取り除きます。name、description、input_schema、cache_control などの標準フィールドは残るので、プロンプトキャッシュは止まりません。

代わりに、MCP のツール検索が無効になり、すべての MCP ツールの定義が最初から読み込まれます。自分で ENABLE_TOOL_SEARCH を設定していても無視されます（v2.1.227 以降は管理設定でツール検索を残せます）。MCP サーバーを多くつないでいるとコンテキストが圧迫され、次に説明する Input is too long for requested model. に近づきます。サーバーの絞り込み方は「Claude Code の MCP コンテキスト圧迫：サーバーを増やしすぎた時の選び方と圧縮方法」を参照してください。

ゲートウェイを通していないのに effort が拒否されることもあります。2026年3月には、GitHub の claude-code-action の issue と Qiita の記事に、Bedrock のアプリケーション推論プロファイル経由で Sonnet 4.5 を使ったときの API Error: 400 output_config.effort: Extra inputs are not permitted が報告されています。issue のコメントでは、Sonnet 4.6 や Opus 4.6 に切り替えたら解消したという声が出ています。いずれも利用者の報告で公式の説明ではありませんが、ヘッダーの問題ではなく、選んだモデルとエンドポイントの組み合わせがそのフィールドを受け付けていない可能性を示しています。直結でこの文字列が出たら、beta 無効化の変数を入れる前にモデルの選択を見直してください。

なお、この変数はフィールドの互換性を調整するだけです。モデル ID、IAM、クォータ、データ保持が原因の 400 は、設定しても消えません。

thinking 関連の 400：バージョンと思考予算

次のエラーは、Claude Code のバージョンが選んだモデルの最低要件より古いことを示します。

API Error: 400 ... "thinking.type.enabled" is not supported for this model. Use "thinking.type.adaptive" and "output_config.effort" to control thinking behavior.

新しいモデルは従来の thinking.type: "enabled" を受け付けず、適応型思考（adaptive thinking）と output_config.effort を前提にしています。古い Claude Code は旧形式で送ってしまうため、claude update を実行して再起動すれば直ります。2026年9月25日時点の最低バージョンは次のとおりです。

社内の配布ポリシーなどで更新できない場合は、/model で Opus 4.6 か Sonnet 4.6 を選べば動きます。Agent SDK で同じエラーが出たときは SDK パッケージを更新します（Opus 5.5 なら TypeScript SDK v0.3.280 以降）。新しいモデルでは thinking 以外のリクエスト規則も変わっており、Opus 4.7 の例は「Claude Code で top_p deprecated? まず Opus 4.7 の新しい request rule を確認」で扱っています。

もう1つの thinking 関連エラーは思考予算です。

API Error: 400 ... max_tokens must be greater than thinking.budget_tokens

Anthropic の API に直接つないでいれば Claude Code が値を自動調整しますが、Bedrock や Google Cloud では、MAX_THINKING_TOKENS がプロバイダーの出力上限より大きいとき、あるいはプランモードが予算を引き上げたときにこのエラーになります。MAX_THINKING_TOKENS を下げるか、CLAUDE_CODE_MAX_OUTPUT_TOKENS を予算より大きくしてください。

Bedrock などのサードパーティプロバイダーでは、MAX_THINKING_TOKENS=0 にすると thinking パラメーター自体が送られなくなります。ただし Opus 5.5 と Fable 系のモデルは思考をオフにできないので、この設定で思考を止めることはできません。

Input is too long for requested model.：コンテキストの超過

Bedrock はコンテキスト超過を Input is too long for requested model.（ValidationException）と表現します。AWS の説明では、上限の対象は入力トークンだけでなく、入力と要求した出力枠の合計です。

Claude Code は v2.1.217 から、この Bedrock の文言を Prompt is too long と同じものとして扱います。それより前のバージョンでは自動コンパクトが働かず、/compact も同じエラーで失敗していました。まず claude --version でバージョンを確かめ、古ければ更新します。

そのうえで、次の順に空きを作ります。

1. /context で、何がコンテキストを埋めているかを見る。
2. 会話を続けたいなら /compact、区切ってよいなら /clear。
3. 使っていない MCP サーバーを /mcp disable <name> で止める。
4. 大きな CLAUDE.md を削る。

CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 を入れた直後にこのエラーが増えたなら、MCP ツールが最初から全部読み込まれるようになったことが効いています。

会話履歴の不整合：/rewind で戻る

次のような 400 は、会話履歴にある tool_use、tool_result、thinking のブロックの並びが、API の期待する形と合わなくなったことを意味します。ツール呼び出しの途中で中断したときや、ストリーミング中にターンを編集したときに起きやすく、Bedrock に限った問題ではありません。

API Error: 400 due to tool use concurrency issues. Run /rewind to recover the conversation.
API Error: 400 orphaned tool_result in conversation history. Run /rewind to recover the conversation.
API Error: 400 duplicate tool_use ID in conversation history. Run /rewind to recover the conversation.
API Error: 400 ... unexpected `tool_use_id` found in `tool_result` blocks
API Error: 400 ... thinking blocks ... cannot be modified

壊れた履歴を毎回そのまま送っているので、再送しても直りません。/rewind を実行するか Esc を2回押し、壊れたターンより前のチェックポイントまで戻ってから続けます。Opus 4.7 か Opus 4.8 を使っていて Claude Code が v2.1.156 より古い場合は、先に claude update をしてください。これらのバージョンでは通常のツール使用中にもこのエラーが起き、/rewind でも解消しません。

モデル ID、プレフィックス、Mantle

Bedrock のモデル ID まわりの 400 は、Claude Code がどの ID を組み立てて送ったかを知ると切り分けやすくなります。

モデルを固定していない場合、2026年9月25日時点の既定はメインが Opus 5.5（us-* リージョンなら us.anthropic.claude-opus-5-5）、軽量タスク用が Sonnet 4.5（us.anthropic.claude-sonnet-4-5-20250929-v1:0）です。v2.1.280 より前はメインの既定が Opus 5 でした。エイリアスはアカウントでまだ有効になっていないモデルに解決されることがあり、固定していなければ Claude Code は起動時にそのセッションだけ別のモデルに切り替えます。挙動を安定させるには、ANTHROPIC_DEFAULT_OPUS_MODEL、ANTHROPIC_DEFAULT_SONNET_MODEL、ANTHROPIC_DEFAULT_HAIKU_MODEL、または ANTHROPIC_MODEL で、自分のアカウントで有効なモデル ID に固定します。

export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=us-east-1
export ANTHROPIC_DEFAULT_OPUS_MODEL=us.anthropic.claude-opus-4-8
export ANTHROPIC_DEFAULT_SONNET_MODEL=us.anthropic.claude-sonnet-4-6

上の ID は Anthropic のドキュメントにある例です。どのアカウント・リージョンでも使えるとは限らないので、aws bedrock list-inference-profiles --region <リージョン> で自分の環境に存在するものを確かめてから指定してください。

プレフィックスはリージョンから決まります。us-gov-* なら us-gov.、us-* なら us.、eu-* なら eu.、ap-* なら apac.、それ以外は global. です。v2.1.224 以降は ANTHROPIC_BEDROCK_REGION_PREFIX（us、eu、apac、jp、au、global）で優先するプレフィックスを変えられますが、あくまで優先であって保証ではありません。

見落としやすいのが権限との関係です。Claude Code はアカウント内の推論プロファイルを一覧できないと、プレフィックスを確認なしに付けて送ります。そのプレフィックスのプロファイルがアカウントで有効でなければ、リクエストは 400 になります。IAM ポリシーに bedrock:ListInferenceProfiles と bedrock:GetInferenceProfile を含めておくと、Claude Code は利用可能なプロファイルを確かめたうえで ID を選べます。GetInferenceProfile はアプリケーション推論プロファイルの ARN から元のモデルを割り出すのにも使われます。一方、自分で設定したプロファイル ID や ARN を Claude Code が書き換えることはありません。400 が出たからといって us. や global. を闇雲に付け替えるのではなく、一覧で存在を確かめてから選んでください。

on-demand throughput isn't supported と返ってきた場合は、推論プロファイル経由でしか呼べないモデルを素のモデル ID で指定しています。推論プロファイル ID で指定し直します。

CLAUDE_CODE_USE_MANTLE で Mantle を使っている場合、モデル ID は anthropic. で始まりバージョン接尾辞のない形（例：anthropic.claude-sonnet-5）です。us.anthropic.claude-sonnet-4-6 のような Invoke 用の推論プロファイル ID は Mantle では使えず、モデル ID を名指しした 400 は「そのモデルは Mantle で提供されていない」という意味です。Mantle 形式の ID に直すか、Invoke API と Mantle の両方を有効にして、モデルごとに提供されている側へ振り分けさせます。有効な認証情報なのに Mantle が 403 を返すなら、アカウントにそのモデルへのアクセス権がありません。

Fable 5 と Fable 5.1 の 400 はデータ保持モード

モデル ID を Fable 5 に変えた途端に 400 になり、設定を変えようとすると今度は 403 が返る。この流れは AWS のデータ保持（data retention）の仕組みで説明できます。

2026年6月に Claude Code の GitHub issue へ報告された実際の文言は次のとおりです（Claude Code 2.1.170、モデル global.anthropic.claude-fable-5）。

API Error: 400 data retention mode 'default' is not available for this model

AWS のデータ保持モードは none < default < aws_review < provider_data_share の順に並んでいます。Claude Fable 5 と Fable 5.1 は aws_review 以上を必要とし、実効モードが none か default だと、bedrock-runtime では ValidationException、bedrock-mantle ではモデルが unavailable（理由は This model is not available under data retention mode 'default'.）になります。

直すには、呼び出しているリージョンのアカウント設定を aws_review にする必要があります。ここで知っておくべき点は次のとおりです。

• 範囲はアカウント単位、リージョンごと。bedrock-runtime にはプロジェクト単位の設定がなく、変更するとそのリージョンのアカウント全体に効きます。
• コンソールに設定画面はありません。コントロールプレーン API（GET / PUT https://bedrock.{region}.amazonaws.com/data-retention）か SDK で操作します。
• 必要な IAM アクションは、確認が bedrock:GetAccountDataRetention、変更が bedrock:PutAccountDataRetention です。設定しようとして 403 になるのは、この変更権限がないためです。
• aws_review の意味：入力と出力は AWS の中で最大30日間保持され、AWS がレビューすることがあります。モデルのプロバイダーとは共有されません。provider_data_share は旧来のモードで、現在は aws_review と同じ動作です（プロバイダーとの共有は行われません）。
• 他のモデルへの影響：Opus 4.8 のように none を許可しているモデルは、アカウント設定を緩めてもデータが保持されることはありません。
• 組織の制約：SCP で none 以外への変更が禁止されている場合があります。

現在の設定の確認は、AWS のドキュメントでは次のような形で示されています。

curl https://bedrock.us-east-1.amazonaws.com/data-retention \
  -H "Authorization: Bearer $AWS_BEARER_TOKEN_BEDROCK"

変更は同じエンドポイントへの PUT で、本文は {"mode": "aws_review"} です。ただし、これはリージョン全体のデータの扱いを変えるコンプライアンス上の判断なので、開発者が手元で済ませる修正として扱うべきではありません。AWS アカウントの管理者やセキュリティ・コンプライアンスの担当者に、エラー本文とリージョン、使いたいモデルを添えて相談してください。ゼロデータ保持（ZDR）が必要な組織が保持を求めるモデルを使いたい場合は、AWS のアカウントマネージャーを通じて、アカウントとモデルごとに個別に検討されます。

Fable 5 より前に公開された Claude モデルには、データ保持に関する変更はありません。Fable への移行そのものを料金面から判断したい場合は「Claude Fable 5.1とOpus 5の料金比較：実コストの判断基準」が参考になります。

自分のコードから呼ぶとき：API ごとの本文の形

自前のコードで出る 400 の多くは、呼び出し方式と本文の形の食い違いです。Bedrock で Claude を呼ぶ方式は3つあり、よく似た JSON でもそのまま使い回すことはできません。

取り違えが多いのは2つのバージョン値です。InvokeModel の本文に入れる anthropic_version は bedrock-2023-05-31 で、2023-06-01 は Messages API のヘッダーに使う値です。InvokeModel の本文に 2023-06-01 を入れたり、model や modelId を本文に書いたりすると、形式違いの 400 の原因になります。Converse でプロンプト管理の ARN を modelId に渡しているときは、additionalModelRequestFields、inferenceConfig、system、toolConfig を送れない点にも注意してください。

Messages API のエンドポイントは、bedrock-runtime の https://bedrock-runtime.{region}.amazonaws.com/anthropic（AWS が新規アプリに推奨）と、bedrock-mantle の https://bedrock-mantle.{region}.api.aws/anthropic/v1/messages の2つです。モデル ID の例は前者が us.anthropic.claude-sonnet-5、後者が anthropic.claude-sonnet-5 で、互いに入れ替えられません。

messages の中に system ロールを入れて拒否された場合の直し方は「API 400 の role 未対応エラーを、システム指示を壊さず直す」で扱っています。

thinking を使うコードは、モデルの系統で書き方が分かれます。Claude Fable 5.1、Mythos 5.1、Mythos 5、Fable 5 は従来の拡張思考に対応しておらず、thinking.type に "enabled" や "disabled" を送ると 400 になります。{"type": "adaptive"} と output_config.effort に置き換えるか、thinking 自体を省きます。従来の拡張思考を使うモデルでは、budget_tokens を1,024以上かつ max_tokens 未満にします（ツールと併用するインターリーブ思考の beta は例外）。

最小構成の例を2つ示します。モデル ID とリージョンはアカウントによって変わるので、環境変数で渡しています。

import json
import os

import boto3

region = os.environ["AWS_REGION"]
model_id = os.environ["BEDROCK_MODEL_ID"]  # 推論プロファイル ID など
client = boto3.client("bedrock-runtime", region_name=region)

# InvokeModel: モデルは modelId、本文は Anthropic の Messages 形式
body = {
    "anthropic_version": "bedrock-2023-05-31",
    "max_tokens": 256,
    "messages": [
        {"role": "user", "content": [{"type": "text", "text": "こんにちは"}]}
    ],
}
res = client.invoke_model(modelId=model_id, body=json.dumps(body))
print(json.loads(res["body"].read())["content"][0]["text"])

# Converse: content は {"text": ...}、出力上限は inferenceConfig
res = client.converse(
    modelId=model_id,
    messages=[{"role": "user", "content": [{"text": "こんにちは"}]}],
    inferenceConfig={"maxTokens": 256},
)
print(res["output"]["message"]["content"][0]["text"])

本文の形が正しいのに 400 が続くなら、早見表の後半に戻ります。The provided model identifier is invalid はモデル ID とリージョンの組み合わせを疑うのが先ですが、AWS Marketplace のパートナーやソリューションパートナー経由のアカウントでは、リセラーが Anthropic のパートナープログラムか Amazon Bedrock Authorized Reseller Program に加入していないことが原因の場合もあります。これはアカウントの前提条件なので、コードや IAM を直しても、通常のモデルアクセス申請をしても解決せず、リセラー側の手続きが必要です。Access to Anthropic models is not allowed from unsupported countries, regions, or territories も、アカウントの税務上の住所や請求先住所、呼び出し元の場所が判断材料になるため、リージョンを切り替えただけでは直りません。

最小リクエストで切り分け、直ったことを確かめる

エラー本文を読んでも原因が絞れないときは、リクエストを最小まで削って送り、1つずつ戻していきます。

1. 短いテキスト1つだけのリクエストを送る。Claude Code なら新しいセッションで短い質問を1つ、自前コードなら上の最小構成の例に相当します。
2. 失敗した場合、問題はリクエストの中身ではなく土台にあります。モデル ID とリージョン、推論プロファイルの有無、IAM とアカウントの前提（リセラー、国・地域）、Fable ならデータ保持モードを確認します。
3. 成功した場合、会話履歴、ツール定義、生成設定（max_tokens、thinking、effort など）を1つずつ戻し、どの変更で 400 に変わるかを見ます。Claude Code なら、履歴は /rewind の前後、ツールは MCP サーバーの有効・無効、生成設定は環境変数の有無に当たります。

直ったことの確認は、元の作業をもう一度通すところまで行います。Claude Code では /status で接続先とリージョンが意図どおりかを見てから、エラーが出た操作を再実行します。環境変数を変えた場合は、Claude Code を起動し直していないと反映されていません。自前コードでは、最小リクエストの成功だけで終わらせず、本番と同じ履歴やツール定義を含むリクエストで確かめてください。

再送するかどうかの判断も、エラー本文で決まります。ServiceQuotaExceededException は時間をおいた再送で通る可能性がありますが、形式、モデル ID、権限、データ保持が原因の 400 は、同じリクエストを何度送っても結果は変わらず、自動リトライに乗せるとログと費用が膨らむだけです。429 や 529 を含め、再試行・別モデルへの切り替え・停止の分け方は「LLM API は再試行かフォールバックか：切り替える前の5項目」を参照してください。