Bedrock content-typeエラーの原因と対処 — Claude Code

「Bedrock streaming response has an unexpected content-type」というエラーの見分け方はシンプルです。Claude CodeとAmazon Bedrockの間にあるゲートウェイやプロキシが、ストリーミング応答の本文やヘッダーを書き換えていることを示しています。Bedrockはストリーミング応答をバイナリのevent-stream形式で返しますが、その形式を中継が壊すとClaude Codeは読めないボディをデコードせずに拒否します。恒久対処はゲートウェイ側の設定変更で、応急処置として専用の環境変数も用意されています。

このエラーが意味すること

Amazon Bedrockは、ストリーミング応答をapplication/vnd.amazon.eventstreamというバイナリのcontent-typeで返します。Claude Codeはこの形式を前提にレスポンスを読み取っており、届いたcontent-typeが想定と違えば、デコードできないボディを無理に処理せずエラーとして拒否します。企業のBedrock導入では、認証や監査ログのためにゲートウェイを一枚挟む構成が珍しくないため、遭遇頻度自体は低くても、そうした構成のチームには再現性の高い症状です。

エラーメッセージには、実際に届いたcontent-typeの値が名指しで含まれます。

Bedrock streaming response has content-type "text/event-stream"; expected "application/vnd.amazon.eventstream". A gateway or proxy between Claude Code and Bedrock is likely transforming the response body — Bedrock's binary event-stream format must be passed through unmodified. Set CLAUDE_CODE_DISABLE_BEDROCK_CONTENT_TYPE_GUARD=1 to suppress this check while the gateway is being fixed.

原因はClaude Code側にもBedrock側にもなく、その間に挟まったゲートウェイやプロキシです。よくあるパターンは、Amazon API GatewayとLambdaを組み合わせた構成が、Bedrockのバイナリevent-streamをサーバー送信イベント(SSE)として再送信し直してしまうケースです。この場合、届くcontent-typeはtext/event-streamになり、エラーメッセージにもその値がそのまま表示されます。Bedrockのバイナリ形式をいったんテキストベースのプロトコルに変換する中継は、便利さと引き換えにこの不一致を生みやすい構成だといえます。

Claude Codeが厳格にcontent-typeを確認するのは、読めない形式のボディを無理にデコードして誤った結果を返すより、失敗として明示するほうが安全だからです。ネットワーク経路のどこかで応答が壊れているのに、Claude Codeが気づかず処理を続けてしまう方が、実運用では発見が遅れて厄介です。

Converse APIへの切り替えでは回避できない

Claude CodeはAmazon BedrockのInvoke API(InvokeModelWithResponseStream)を使っており、Converse APIには対応していません。Bedrock側でConverse APIを有効にしても、Claude Codeが呼び出すエンドポイントは変わらないため、このエラーの回避策にはなりません。対処の的はあくまでゲートウェイが返すレスポンスの形式です。

社内でBedrockゲートウェイを構築しているチームほど、「APIの種類を変えれば直るのでは」という仮説に時間を使ってしまいがちです。切り分けの最初の一歩は、ゲートウェイのログでどのエンドポイントを中継しているかを確認することです。InvokeModelWithResponseStream宛てのリクエストを、途中でSSE形式に変換していないかを見れば、原因の所在がすぐに分かります。

バージョンで見え方が変わる

v2.1.208より前と以降で、同じ誤設定でも表示されるエラーが違います。

v2.1.208以降のほうが原因の切り分けは速くなります。受信したcontent-typeの値がそのままメッセージに出るため、「ゲートウェイが何に書き換えているか」を推測せずに特定できます。このエラーは自動リトライの対象外でもあります。ゲートウェイやプロキシが応答を書き換えている以上、同じリクエストを再送しても同じ書き換えが起きるだけだからです。この扱いにはv2.1.208以降が必要です。

対処 — ゲートウェイ側の設定を直す

正しい対処は、ゲートウェイにInvokeModelWithResponseStreamのレスポンスボディとContent-Typeヘッダーの両方を無加工で通過させることです。SSEとして再送信し直す中継や、レスポンスを一度バッファリングしてから転送する構成は、ボディかヘッダーのどちらか、あるいは両方を壊しがちです。プロキシやゲートウェイ経由のネットワーク設定全般はClaude Codeプロキシ設定ガイドも参照してください。

ゲートウェイがヘッダーだけを書き換えていて、バイナリのボディ自体は無加工で通っている場合に限り、チェックを一時的に無効化できます。

export CLAUDE_CODE_DISABLE_BEDROCK_CONTENT_TYPE_GUARD=1

この環境変数はv2.1.208以降が必要です。設定してもエラーが「content-type不一致」から「Truncated event message received」に変わっただけなら、ヘッダーではなくボディ自体がゲートウェイで壊れていると判断できます。

似た配信エラーとの違い

Bedrock経由の接続エラーには、content-type不一致以外にもいくつか種類があり、症状が似ているため混同しやすいところです。

content-type不一致は「応答の形式そのものが違う」という即座に分かる失敗であるのに対し、ストールは「接続は保たれているのにデータが来ない」という別種の症状です。Bedrockのvnd.amazon.eventstream応答は既定でバイト単位の監視対象に入っていないため、ゲートウェイ環境でストールが疑われる場合はCLAUDE_ENABLE_BYTE_WATCHDOG_BEDROCK=1を検討します。Bedrock連携では過去にも認証まわりのリグレッションが修正された例があり、Bedrock特有の不具合はバージョンアップだけで解消することも珍しくありません。BedrockのClaude料金を検討する段階でゲートウェイ構成もあわせて設計しておくと、後からこの種の書き換え問題を踏みにくくなります。

よくあるつまずき

• 症状が断続的にしか出ないときは、ロードバランサ配下の一部のノードだけがレスポンスを変換している可能性があります。全ノードで同じゲートウェイ設定になっているかを確認します
• ローカルのcurlテストでは正常に見えても、Claude Codeが送るリクエストヘッダーの違いでゲートウェイ側のルーティングが変わることがあります。テストは実際のクライアントに近い条件で行います
• Bedrockのモデルアクセス権やリージョン設定自体は正常なのに、このエラーだけが出ているなら、調査すべきはゲートウェイの設定でありAWS側の権限ではありません。切り分けを先に済ませてから時間を使います

よくある質問

直接AnthropicのAPIを使う場合もこのエラーは出ますか

出ません。このチェックはAmazon Bedrockのバイナリevent-stream形式に固有のもので、モデルプロバイダーとしてBedrockを使っているときだけ働きます。

CLAUDE_CODE_DISABLE_BEDROCK_CONTENT_TYPE_GUARD=1を設定すれば安全ですか

一時的な回避策としては安全ですが、根本対処ではありません。ヘッダーだけの書き換えであれば動きますが、ボディ自体が変形されている場合は別のエラーに変わるだけなので、いずれにせよゲートウェイの設定は直す必要があります。

このエラーは自動でリトライされますか

されません。ゲートウェイやプロキシが応答を書き換えている限り、同じリクエストを再送しても同じ書き換えが起きるだけだからです。v2.1.208以降でこの扱いに変わりました。

v2.1.208より前のバージョンで同じ問題が起きたらどう見えますか

応答全体がバッファリングされた後にAPI Error: Truncated event message receivedという、原因の分かりにくいエラーになります。まずclaude updateでバージョンを上げると、切り分けが格段に楽になります。

AWS側の設定を見直すべきポイントはどこですか

Amazon API GatewayとLambdaを組み合わせた構成では、Lambda側の統合設定でレスポンスをSSEとして再送信していないかを確認します。素のInvokeModelWithResponseStreamのレスポンスをそのまま透過させる設定に直すのが最短です。

自前のゲートウェイを挟んでいなくても起きますか

Bedrockに直接つないでいて、独自のゲートウェイやプロキシを一切挟んでいない構成なら、通常はこのエラーの対象になりません。原因は必ず「Claude CodeとBedrockの間で応答を書き換える何か」なので、心当たりがない場合は社内ネットワーク側にTLS検査プロキシやセキュリティアプライアンスが暗黙に挟まっていないかを確認します。気づかないうちに通信を中継している構成は珍しくありません。

まとめ

Bedrock content-typeエラーは、Claude Code自体ではなく間に挟まったゲートウェイやプロキシがバイナリのevent-stream応答を書き換えていることが原因です。恒久対処はゲートウェイ側でボディとヘッダーを無加工で通すことで、CLAUDE_CODE_DISABLE_BEDROCK_CONTENT_TYPE_GUARD=1はあくまで一時回避と診断材料として使います。エラーメッセージに表示されるcontent-typeの値をそのまま手がかりに、ゲートウェイの設定を1つずつ確認していけば、原因の特定にそれほど時間はかかりません。