Claude Platform on AWSの支出上限とメール通知先の設定

Claude Platform on AWSの支出上限は2段あります。ティアに紐づく月間キャップと、自分で置く組織・ワークスペースの上限です。自分の上限を設定するには、先にBillingページのEmail recipientsへ宛先を1件以上登録しておく必要があります。

上限に届くとリクエストは止まります。ただし止まり方は、キャップなら429、自分で置いた上限なら400と違います。しかも使用量の反映に約2時間かかるので、超過分は請求されます。この記事は、設定の順番と、止まったときの見分け方、通知が届く先を扱います。

上限は2種類ある — ティアのキャップと自分の上限

Claude Platform on AWSの組織はStartティアから始まります。Start、Build、Scaleの各ティアには、それぞれ月間の支出キャップが付いています。レート制限とキャップは同じティアに属し、ティアを上げれば両方が上がります。

Customティアにはキャップがなく、上限はアカウント担当チームと取り決めます。キャップの仕組みと引き上げの考え方はClaude APIの月間支出上限の記事にまとめています。ここで押さえておきたいのは、AWS経由では引き上げの入口が違う点です。

自分で置く上限は、そのキャップより下に設定する運用上の安全弁です。置ける場所は2つあります。

• 組織の上限: ConsoleのSettings > Billing
• ワークスペースの上限: Settings > Workspacesでワークスペースを選び、開いたパネルのSpend limits

AWS経由のConsoleでBillingページが担うのは、組織の支出上限の設定までです。AWS経由のBillingページは機能が限られ、請求書はAWS Marketplaceが管理します。費用の内訳はCostページでモデル別・ワークスペース別に見られ、Claude Codeの使用量はUsageページで確かめます。AWS Cost Explorerには、CCUの合計が1行で並びます。

先にEmail recipientsを登録する

自分の上限は、BillingページのEmail recipientsに1件以上の宛先がないと設定できません。上限の画面が開かないときは、まず宛先が空でないかを確かめます。

順番にすると次のとおりです。

ワークスペース単位の上限は、環境ごとに予算を切りたいときに向きます。たとえば検証用ワークスペースだけ低く置けば、本番側の枠を食い潰されません。ワークスペースの作り方はClaude Consoleのワークスペース作成手順にあります。

止まったときのエラーは、キャップか自分の上限かで違う

止まる原因が2種類あるので、エラーで見分けます。

どちらも解除の時刻は決まっています。翌月1日の00:00 UTCまで止まり、それより早く再試行しても成功しません。

翌月を待たずに戻す手段は、止めたものによって違います。自分で置いた上限なら、金額を上げるか上限を外せば戻ります。ティアのキャップは自分では動かせず、Anthropicのアカウント担当者かサポートにティアの引き上げを頼みます。キャップ到達後にアクセスを戻す道もこの依頼です。

注意したいのはキャップ側の429です。レート制限の429と同じrate_limit_errorですが、retry-afterヘッダーが付きません。SDKの自動再試行も失敗し続けるので、再試行ロジックの前に分岐を入れます。次は公式のエラー形に沿った分岐の例です。

import anthropic
 
client = anthropic.Anthropic()
 
try:
    client.messages.create(
        model="<使用するモデルID>",
        max_tokens=256,
        messages=[{"role": "user", "content": "ping"}],
    )
except anthropic.RateLimitError as e:
    body = e.body or {}
    detail = (body.get("error") or {}).get("details") or {}
    if detail.get("error_code") == "enforced_spend_limit_reached":
        # 月間キャップ到達。再試行せず、運用担当へ通知して止める
        raise SystemExit("monthly spend cap reached")
    raise  # 通常のレート制限は、retry-after に従って再試行
except anthropic.BadRequestError as e:
    if "specified" in str(e) and "usage limits" in str(e):
        raise SystemExit("custom spend limit reached")
    raise

この断片は、エラー本文のメッセージ文字列に依存する部分があります。文言は将来変わる可能性があるので、可能ならerror_codeの判定を主にします。自分の上限の400にはerror_codeの記載がなく、メッセージ冒頭で見分けるのが公式の案内です。

約2時間の遅れで、超過分は請求される

使用額はリストプライスで計算され、直近の利用が反映されるまでに約2時間かかります。つまり、上限に達した瞬間にはまだ止まりません。反映されるまでの間に使った分は、キャップや上限を超えても請求されます。

上限は予算を守る柵であって、1円単位で効く遮断器ではない、という理解が安全です。大量のバッチを夜間に流す運用では、上限の手前で自分側のしきい値を持つほうが確実です。

もう一点、計算基準にも差があります。上限判定はリストプライス基準です。AWSの請求はClaude Consumption Unit(CCU)で、時間単位に計測され、月次で後払いされます。CCUは前払いのクレジットではなく、残高も最低利用コミットもありません。割引はCCUへの換算時に適用されるため、Console上の使用額(リストプライス基準)とAWS請求書の数字は一致しないことがあります。CCUへの換算はBedrock・Vertex・Foundryの料金比較で扱っています。

通知が届く先 — ロール宛ては使えない

キャップまたは組織の上限で止まると、Email recipientsに登録したアドレスへメールが届きます。登録先の扱いで、他の経路と違う点が2つあります。

• 「全管理者」のようなロール宛ての受信者は、Claude Platform on AWSでは選べない
• ティアのキャップの通知は、AWS Marketplaceにサインアップしたときのアドレスにも届く

ここから実務上の手当てが決まります。個人の受信箱だけを登録すると、その人が不在のときに誰も気づきません。共有のエイリアスやメーリングリストを個別アドレスとして登録しておくと、ロール宛てが使えない分を補えます。サインアップ時のアドレスが退職者の個人宛てになっていないかも、点検の対象です。

Spend limitsの説明で、メール通知の対象として挙がっているのはティアのキャップと組織の上限だけです。ワークスペースの上限については、通知の記載がありません。ワークスペースの上限は、通知に頼らず、リクエスト側の400を監視する設計にしておくと漏れません。

上限を上げるときの窓口

Claude APIを直接使う場合との違いは、引き上げの入口にあります。

AWS経由ではこのほか、ワークスペースごとのレート制限設定とfast modeも使えません。この差は、止まった後の動きに直結します。直接利用ならキャップ到達後にConsoleから申請できますが、AWS経由では連絡先が人になるため、休日や夜間に止まると戻るまでに時間がかかります。キャップに近づく兆しがあるなら、早めに担当者へ相談しておくと、止まってから待つ時間を減らせます。

依頼するときは、Anthropicのアカウント担当者かサポートへ次の3点を添えます。

• 引き上げたいモデル
• モデルごとの毎分の入力・出力トークンのピーク(日次の合計ではない)
• 入力のうちキャッシュや反復コンテキストが占めるおおよその割合

3点目が要るのは、キャッシュ読み取りがほとんどのモデルで入力トークンの制限に数えられないためです。キャッシュを多用する構成は、同じ入力量でも必要な枠が小さく見積もれます。

AWS Marketplaceの請求書を支払った実績が積み上がると、上位のティアへ自動で移ることもあります。一時的な超過が心配なだけなら、引き上げを頼む前に自分の上限とEmail recipientsを整えておくと、キャップに当たる前に気づけます。Bedrockからの移行で、請求や上限まわりが何に変わるかは移行手順の記事を、Claude Codeを載せる場合の認証はClaude Platform on AWSでClaude Codeを使う記事を参照できます。

まとめ

設定の順番は、Email recipientsの登録、組織の上限、ワークスペースの上限です。止まり方は、キャップが429でenforced_spend_limit_reached、自分の上限が400でspecified始まりのメッセージです。約2時間の反映遅れがあるため、超過分は請求される前提で、上限より手前に自前のしきい値を置く構成が現実的です。

通知先はロール宛てが選べないので、共有アドレスを個別に登録し、サインアップ時のアドレスの持ち主も合わせて確認します。