Claude Codeの使いすぎでBedrock破産しそうな畑野です。
今回は、Amazon Bedrock（以降、Bedrock）経由でClaude Codeを利用する場合に、Bedrock APIキーの発行元IAMユーザーやAssume Role単位でトークン数を集計し、一定数を超過した場合にアラートメールを送付する仕組みを作ってみました。
コード一式はAWS SAMで実装できるようにし、記事の後半に載せています。
- Bedrock経由でClaude Codeを使うときのコスト
- モデル呼び出し制限とアラートメールの検討
- 作った仕組みの全体像
- 実装のポイント
- 通知メールサンプル
- 運用して見えてきた効果
- 今後の改善ポイント
- ソースコード一式
- まとめ
Bedrock経由でClaude Codeを使うときのコスト
Bedrock経由でClaude Codeを利用すると、従量課金であるため、利用量の増加がそのままコスト増につながります。特に複数の利用者が存在する環境では、誰がどの程度トークンを消費しているのかを把握しにくい点が課題です。
Bedrock自体にはリクエスト数や、1 分あたりのトークン数 (TPM)、1 日あたりのトークン数 (TPD)、1 分あたりのリクエスト数 (RPM)などの制限 *1 はありますが、トークン使用量を直接制御する仕組みがなく、コスト管理を運用で補う必要があると考えました。
そこで、トークン使用量を可視化し、しきい値超過時に通知する方法を検討してみました。なお、この集計値は請求上の実トークン使用量の把握には有用ですが、BedrockのTPM/TPD クォータ消費はモデルによっては出力トークンの重み付けやキャッシュの影響を受けるため、クォータ消費量そのものとは一致しない場合があります。*2
モデル呼び出し制限とアラートメールの検討
当初はトークン数超過による自動停止（ハードリミット）も検討しましたが、必要な開発・検証作業まで妨げてしまう機会損失の懸念がありました。そのため今回は、異常な利用増加の早期発見を重視し、しきい値超過時にメール通知する「ソフトリミット型」の仕組みを採用しました。
作った仕組みの全体像
今回構築したのは、発行元IAMユーザーやAssume Role単位で、単位時間あたりのトークン使用量を計測する仕組みです。一定時間内の使用量を集計し、あらかじめ定めたしきい値を超えた場合に、アラートメールを送信します。これにより、利用を止めずにコスト増加の兆候を早期に検知できるようにしました。
実装のポイント
Bedrockのモデル呼び出しログから identity フィールドの arn を識別し、inputTokenCount と outputTokenCount を時間単位で集計できるようにしました。集計結果に対してしきい値判定を行い、条件を満たした場合のみ通知を送ることで、過剰なアラートを防ぐ構成にしています。また、ログはデフォルトでは無効のため、Bedrockの設定から「モデル呼び出しのログ記録」を有効にしておきます。
検証した範囲では、ログ上の identity.arn は認証方法によって見え方が異なりました。
| 発行方法 / 利用形態 | identity.arn の例 |
ARNの見え方 |
|---|---|---|
| A. 短期APIキーをIAMユーザーで発行した場合 | arn:aws:iam::123456789012:user/short_term_api_key |
iam::...:user/... 形式になり、IAMユーザーとして見える |
| B. 短期APIキーをAssume Roleで発行した場合 | arn:aws:sts::123456789012:assumed-role/hatano_test_role/hatano@example.com |
sts::...:assumed-role/... 形式になり、引き受けたロール名とスイッチ元IAMユーザーが見える |
| C. 長期APIキー | arn:aws:iam::123456789012:user/BedrockAPIKey-xxx |
iam::...:user/... 形式になり、IAMユーザーとして見える |
| D. Assume Roleの場合（APIキー未使用） | arn:aws:sts::123456789012:assumed-role/hatano_test_role/botocore-session-xxx |
sts::...:assumed-role/... 形式になり、Assume Role利用として見える |
まず、短期APIキーをIAMユーザーで発行した場合、2つのキーを発行しても、 identity.arn は同一でした。次にAssume Roleで短期APIキーを発行すると、スイッチ元IAMユーザーが表示されました。検証した範囲では、長期APIキーは発行時に BedrockAPIKey-xxx のようなIAM ユーザーが作成され、この情報がログ上でも確認できました。
Assume RoleでClaude Codeを実行した場合は、arn:aws:iam: ではなく、 arn:aws:sts と表示され、STSの一時的認証情報として扱われていました。
それぞれ識別できそうなのですが、短期APIキーはログにはAPIキーを含む情報がなく、AとBはそれぞれ1つの identity.arn に集約されました。*3
Dはセッション情報が変わらない場合、こちらも1つの identity.arn に集約されました。
以上から、APIキーごとの厳密な集計は難しいものの、発行元IAMユーザーやAssume Role単位で運用すれば、個別に集計できそうです。
また実際の運用では可能な限り、短期APIキーやAssume Roleによる一時的認証情報の利用を推奨します。長期APIキーはIAMユーザーの発行を伴うため、認証情報漏洩時のリスクが大きくなります。
通知メールサンプル
検証のため、トークン数のしきい値は低くしています。直近10分間でinputTokenCount と outputTokenCount の合計が100を超えた場合にアラートメールを送信しています。
実際のしきい値は、 Amazon Bedrock pricing を元に検討し、例えば個人開発用途であれば1M（100万）トークンから始める、というのも1つの指標です。
運用して見えてきた効果
本番環境を想定した検証により、利用主体ごとのトークン数が意図した単位時間で集計され、しきい値超過時にのみアラートが発報されることを確認できました。
実際にこの仕組みを運用に載せることで、利用量の急増を早い段階で把握できるようになり、コスト面の不安を減らしながらClaude Codeを活用しやすくなりました。単純な利用停止ではなく通知（ソフトリミット）にしたことで、開発の利便性を落とさずに監視できる点も大きなメリットです。また、発行元IAMユーザーやAssume Role単位でトークン数を可視化できるため、どこで利用が増えているかも追跡できるようになりました。
今後の改善ポイント
現在はトークン数超過後にメールを送信するソフトリミット的な通知にしています。
運用上、厳密にモデル呼び出しそのものを制限する場合は、IAMユーザーやAWS Organizations単位でIAMポリシーやSCPアタッチ・デタッチを含む制御方法や運用負荷を慎重に考える必要があります。
まずは通知による可視化で運用しつつ、必要に応じて制御方法を変えることが望ましいと考えます。
ソースコード一式
今回の仕組みはAWS SAMでデプロイできるようにしています。
詳細は下記リンクをご参照ください。
まとめ
Bedrock経由でClaude Codeを活用する上で、利便性だけでなく、コスト意識も重要です。
今回の仕組みによって、利用を一律に止めることなく、利用主体ごとのトークン使用量を把握し、しきい値超過時に早期検知できるようになりました。
AIの活用を継続していくためにも、使いやすさとコスト管理を両立する仕組みづくりが大切だと考えています。
また、弊社はAnthropic社とリセラー契約を締結しているため、BedrockでのClaudeモデル活用など、ご相談ください。
*1:Amazon Bedrock service quotas
*2:Amazon Bedrock でのトークンのカウント方法
*3:「Amazon Bedrock API キーは、認可ヘッダーとして API リクエストに渡され、ログには記録されません」と記載があります。
