AWS の Claude で 400 エラーが出たときの切り分けと対処法

AWS 上の Claude で 400 Bad Request が返ってきても、原因は一つではありません。まず確認するのは、HTTP ステータスだけでなく、エラーコード、エラー本文、実際に呼び出している API です。Claude Code が送った追加フィールドの拒否と、Bedrock のモデル指定やデータ保持設定の不一致では、直す場所が変わります。

Claude Code のエラーに Extra inputs are not permitted が含まれ、beta 機能に由来するフィールドが拒否されているなら、CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 を設定して新しいプロセスを起動する方法が候補になります。一方、model identifier、max_tokens、data retention などが示されている場合は、その対象を先に確認します。同じリクエストを繰り返しても、形式や設定の不一致は解消しません。

以下は 2026 年 9 月 21 日に確認した公式ドキュメントに基づく手順です。コードは説明用の例であり、AWS 環境での実測結果ではありません。

最初にエラー全文と接続先を確認する

調査用に、次の情報を一組で残してください。問い合わせ時にプロンプト全文や認証情報まで共有する必要はありません。

• エラーの Code と Message、HTTP ステータス、リクエスト ID
• 使用中のクライアントとバージョン。Claude Code なら claude --version
• AWS リージョン、指定したモデル ID または推論プロファイル ID
• 呼び出し方式。Converse、InvokeModel、/anthropic/v1/messages、またはゲートウェイ独自の API

AWS SDK から直接呼び出している場合は SDK の例外を、ゲートウェイ経由ならゲートウェイが返す本文と取得可能な上流エラーを確認します。「AWS の Claude を利用している」という情報だけでは、送信する JSON の仕様まで特定できません。

エラー本文を読んだら、まず次の対応先に絞ります。

AWS の ValidationException 解説には、入力形式だけでなくモデル、リージョン、権限、ガードレールなどの例もあります。Converse の API 仕様では ValidationException が 400、AccessDeniedException が 403、ThrottlingException が 429 ですが、400 だから権限は無関係、と判断するのは早計です。AWS の一般的なエラー一覧にも、署名や認可に関する 400 エラーが掲載されています。

Claude Code なら、拒否された追加機能を絞り込む

Claude Code の更新後やモデル変更後に発生した場合でも、まず拒否されたフィールド名を読んでください。バージョンの問題なのか、選択したモデルが設定を受け付けないのかで対応が異なります。

日本語の事例では、2026 年 3 月の Qiita 記事が Sonnet 4.5 と output_config.effort の組み合わせを扱っています。これは当時の環境での報告であり、現在のすべてのモデルで同じ設定を削除すべきだという意味ではありません。エラーに effort が出ているなら、選択モデルとクライアントが送る設定の組み合わせを確認する、という切り分けに役立ちます。

beta 機能のフィールドが拒否される場合

ゲートウェイが anthropic-beta ヘッダーを取り除き、beta 機能専用のフィールドだけを上流へ転送すると、入力が拒否されることがあります。公式のClaude Code エラー解説では、上流が機能をサポートしている場合のヘッダー転送修正、または試験的な機能の無効化が案内されています。

後者を試す場合、macOS／Linux のシェルでは次のように新しい Claude Code を起動できます。

bash
CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 claude

起動済みのプロセスには後から設定しても反映されないため、設定した環境から起動し直します。この変数が変更する範囲は、公式の環境変数一覧で確認できます。

• Anthropic 固有の beta ヘッダーと、ツール定義の beta 用フィールドを取り除きます。
• 標準の name、description、input_schema、cache_control は保持します。プロンプトキャッシュ全体を無効にする設定ではありません。
• MCP のツール検索も無効になり、ツールが最初から読み込まれるようになります。v2.1.227 以降では、管理対象設定によってツール検索を維持できる例外があります。

これで通るようになった場合も、「AWS は beta 機能に一切対応していない」とは結論づけられません。使ったモデル、上流 API、ゲートウェイの転送設定を確認し、必要な機能を戻せるか判断してください。変化がなければ、エラー本文の別の手がかりに戻ります。

会話履歴の不整合は別に扱う

tool_use と tool_result、または thinking ブロックの対応不一致が明示されているなら、単なる非対応フィールドとは異なる問題です。公式では /rewind または Esc キーの 2 回押しで、問題が生じたターンより前へ戻す方法が示されています。履歴の不整合に関する説明を確認し、モデル ID や権限のエラーに対して無関係な履歴削除を試すことは避けましょう。

AWS SDK からの呼び出しは、API ごとの入力形式をそろえる

Claude を呼び出すコードのサンプルは、すべて同じ形式ではありません。別の API 用の JSON を混ぜると、見た目が似ていても拒否されます。

仕様はそれぞれ Converse、InvokeModel の Claude Messages、Anthropic 互換 Messages APIを確認してください。AWS の互換 API は bedrock-runtime と bedrock-mantle のエンドポイントで案内されています。AWS 上の Claude なら必ず JSON に anthropic_version が必要、という説明は正確ではありません。

Converse でもネイティブの Claude Messages でも、システム指示は通常の会話メッセージとは別の system に指定します。また、従来の Text Completions 用の prompt や max_tokens_to_sample を、Messages 用の本文にそのまま流用しないでください。

モデル ID も接続先に合わせる必要があります。Claude Code の Bedrock 設定ガイドでは、Invoke で使う us.anthropic.* などの推論プロファイル ID と、Mantle で使う anthropic.* のモデル ID が区別されています。オンデマンド呼び出し非対応というエラーなら適切な推論プロファイルを確認し、単に us. や global. を付け足して済ませないでください。リージョンのプレフィックスに関する優先設定は、実際の利用可否を保証しません。Claude Code では /status で現在の接続先を確認できます。

最小限の Converse リクエストで疎通確認する

次の Python 例では、画像、ツール、thinking、ガードレールなどを追加せず、短いテキストだけを送ります。AWS_REGION と BEDROCK_MODEL_ID には、そのアカウントとリージョンで利用できる値を設定してください。モデルによって推論プロファイルの指定が必要になるため、記事中のモデル ID を機械的にコピーする方法にはしていません。

python
import os

import boto3
from botocore.exceptions import ClientError

client = boto3.client(
    "bedrock-runtime",
    region_name=os.environ["AWS_REGION"],
)

try:
    result = client.converse(
        modelId=os.environ["BEDROCK_MODEL_ID"],
        messages=[
            {"role": "user", "content": [{"text": "短く挨拶してください。"}]}
        ],
        inferenceConfig={"maxTokens": 128},
    )
    for block in result["output"]["message"]["content"]:
        if "text" in block:
            print(block["text"])
except ClientError as exc:
    error = exc.response.get("Error", {})
    metadata = exc.response.get("ResponseMetadata", {})
    print({
        "code": error.get("Code"),
        "message": error.get("Message"),
        "http_status": metadata.get("HTTPStatusCode"),
        "request_id": metadata.get("RequestId"),
    })
    raise

既存の AWS 認証設定を使う例です。エラー本文にも送信内容が含まれる可能性があるので、ログを他者へ渡す前に機密情報を取り除いてください。また、この例はモデル ID または推論プロファイルでの呼び出しを想定しています。Prompt management のプロンプト ARN には、指定できるリクエスト項目に別の制約があります。

最小構成でも同じエラーが出るなら、モデル指定、リージョン、利用権限、保持設定などを確認します。最小構成が成功するなら、会話履歴、ツール、生成設定などを一つずつ戻してください。初めて失敗した変更が、次に調べる対象です。ただし、Converse で成功したことは、別の API を使うゲートウェイの入力形式が正しいことまで証明しません。

入力の長さと thinking の設定を確認する

長い会話だけが失敗する場合は、入力トークン数に要求した出力分を加えた値と、モデルの上限を確認します。出力上限を大きくするほど安全、という関係ではありません。まず短い新規会話で比較し、不要な履歴や過大な出力要求を減らして切り分けます。

thinking はモデルによって設定方式が異なります。AWS の拡張思考の説明では、Fable 5／5.1 と Mythos 5／5.1 は enabled／disabled の指定を 400 エラーで拒否し、adaptive thinking を使うとされています。したがって、すべての Claude に対して「thinking を disabled にすればよい」とは案内できません。

通常の拡張思考では budget_tokens を max_tokens より小さくする条件がありますが、interleaved thinking には明示的な例外があります。エラーが思考予算を指しているなら、利用モデルとモードの該当箇所を読み、別モデルの設定をそのまま移植していないか確認してください。

データ保持エラーは、アカウントの利用条件を確認してから対処する

data retention や保持モードに関するエラーが出た場合、JSON の書き換えだけでは解決しないことがあります。モデルが必要とする保持条件と、対象アカウントの有効な設定が一致しているかを確認してください。

ここは古い記事との違いに注意が必要です。2026 年 6 月の Zenn の報告は当時の不一致を調べる参考になりますが、現在の設定の意味は AWS のデータ保持ドキュメントを優先します。2026 年 9 月 21 日の確認時点では、次のように説明されています。

• 新しい設定には aws_review を使います。provider_data_share は従来の値として残っていますが、現在はコンテンツをモデル提供者へ送信する設定ではありません。
• レビューは AWS 内で行われます。現行ドキュメントが対象として挙げる Fable モデルでは、最大 30 日間の保持が説明されています。これをすべてのモデルの一律条件と捉えないでください。
• 設定はリージョンごとです。bedrock-runtime ではアカウント単位であり、プロジェクト単位の設定ではありません。
• 明示的に ZDR の承認を受けたアカウントでは、特定モデルで none が認められる場合があります。inherit や既定値だから無条件にゼロ保持になるわけではありません。

対象リージョン、モデルに許可された保持モード、現在の有効設定を管理者と確認し、組織のデータ取扱規程に合うか判断します。アカウント単位の設定を「400 を消すため」だけに変更したり、広い IAM 権限を付与したりする手順にはしないでください。要件を満たせない場合は、利用条件に合うモデルや構成を検討する段階です。

変更後は同じ条件で一度確認し、次の対応を決める

設定を変更したら、同じリージョン、モデル、短い入力で再度確認します。Claude Code の起動時設定なら再起動後に確認し、成功したかどうかは出力の有無だけでなく、エラーが別の種類に変わっていないかも見ます。

疎通が確認できたら、必要な機能を順に戻して通常の処理まで確認します。依然として失敗するなら、エラーコード、本文、リクエスト ID、リージョン、モデル、最小構成での結果をそろえて管理者や利用先のサポートへ渡してください。認証情報や会話全文は送らず、問題が再現する最小限の情報に絞ります。

なお、400 がすべて入力エラーとは限りません。InvokeModel の仕様では、アカウントのクォータ超過を示す ServiceQuotaExceededException も 400 で、時間を置いて再送できる場合があると説明されています。エラーコードを確認してから再送の可否を判断してください。

一方、形式が不正なままの ValidationException に一律の自動リトライを加えると、原因が残ったまま失敗を増やします。429 や一時的な障害への対応は、LLM API のリトライとモデル切り替えの考え方で分けて確認できます。まず今回のエラーを再現する条件と変更箇所を一つに絞ることが、復旧への近道です。