AIの利用料が急に増えたとき、最初に疑われるのはプロンプト量やモデル選択です。ところが、原因がネットワーク側にあることもあります。Claude Code v2.1.239では、Bedrock経由のストリーミング通信で、プロキシがレスポンスのContent-Typeヘッダーを削ると、同じターンを非ストリーミングで再実行し、API呼び出しが二重になる不具合が修正されました。
画面上は普通に回答が返るため、利用者は気づきにくい。企業でAIを運用するなら、回答品質だけでなく「1回の依頼が何回APIに届いたか」まで見ないと、コスト異常の原因を取り逃がします。
何が変わったか
Anthropicが2026年8月21日に公開したClaude Code v2.1.239には、多数の修正が含まれています。業務運用で特に見ておきたいのは次の点です。
- Bedrockのストリーミング通信でContent-Typeが欠けた場合、同じターンを非ストリーミングで再実行してAPI呼び出しが二重になる問題を修正
- BedrockとSSOを使う環境で、認証確認がHTTPS_PROXYを認識せず起動時に止まる問題を修正
- 一時的な5xxで失敗したリモートMCPサーバーが、その後も失敗状態に残る問題を修正
- 長時間のバックグラウンド作業を確認する間隔を、30分、1時間、その後2時間ごとに広げるよう変更
ここまでは公式リリースに書かれた事実です。以下は、この修正を小さな会社の運用へ置き換えた私の解釈です。
プロキシは「通ったか」だけでは足りない
社内ネットワーク、VPN、クラウドの出口制御を入れると、AIへの通信は複数の機器やサービスを通ります。HTTPステータスが200で、回答が表示されれば正常に見えます。しかし、途中でヘッダーが変わると、クライアント側の再試行条件が意図せず成立することがあります。
今回の不具合は修正済みです。ただし、同じ種類の問題は別のSDKやゲートウェイでも起こり得ます。請求額だけを月末に見る運用では遅い。APIのリクエスト数、モデル別トークン、再試行回数を日単位で記録し、通常値から外れたら止められる形が必要です。
小さな会社で効く確認項目
まず、AIの通信経路を1枚にします。端末から直接APIへ出ているのか、社内プロキシ、VPN、クラウドゲートウェイを通るのか。BedrockやVertex AIを使う場合は、認証更新の経路も別に書きます。
次に、同じ短い依頼を数回実行し、クライアントの履歴とプロバイダー側の利用記録を照合します。1回の操作に対して想定外の複数リクエストが出るなら、プロキシログと再試行設定を確認します。確認用の依頼は固定し、毎回条件を変えない方が比較しやすいです。
最後に上限を置きます。Claude Codeには--max-budget-usdがあり、v2.1.239では米国内推論の追加料金もコスト見積もりへ反映されました。組織全体の請求上限とは別に、定期処理や長時間ジョブごとの予算を決めておくと、異常を小さく止められます。
そのまま真似ると危ない点
「最新版に上げればコスト問題は終わり」と考えるのは危険です。今回直ったのは特定条件での再実行です。プロンプトの肥大化、無制限のサブエージェント、失敗時の独自リトライなど、別の増加要因は残ります。
監視を請求額だけに寄せるのも不十分です。少額の二重実行でも、外部サービスへの書き込みやメール送信が重なると、金額以上の事故になります。API回数と一緒に、外部操作の重複がないかも確認対象に入れます。
最初にやるなら
Claude CodeをBedrockや社内プロキシ経由で使っている会社は、v2.1.239への更新後、固定したテスト依頼を3回だけ実行してください。端末の実行履歴、プロキシログ、Bedrock側の呼び出し記録が3回で揃うかを見ます。数が合わなければ、本番の自動処理を増やす前に通信経路を切り分けるべきです。
AIに仕事を委譲すると、目に見えるのは最終結果だけになります。だからこそ、途中の呼び出し回数と再試行を記録する。地味ですが、これがAIを実験から日常業務へ移すときの手綱です。