拒否されても課金される場合がある。カテゴリで分かれる

Claude Platform の拒否レスポンスについて、課金ルールが明文化されている。拒否されたのに課金される場合がある。

まず、拒否はエラーではない

拒否は、stop_reason: "refusal" を伴う成功した HTTP 200 レスポンスである。

content は空で、stop_details.category がポリシー領域を示す。HTTPステータスだけを見ている監視では、拒否は成功として素通りする。

どのカテゴリが課金されるか

`category`	出力前の拒否が課金されるか
`cyber`	いいえ
`bio`	はい
`frontier_llm`	はい
`reasoning_extraction`	はい
`general_harms`	いいえ

ドキュメントの説明はこうである。

大規模に安全策を回避しようとする試みを妨げるため、出力前に届いた拒否は、stop_details.category が "bio"・"frontier_llm"・"reasoning_extraction" のときに課金される。これらは Anthropic が偽陽性を低い量で計測しているカテゴリである（2026年9月時点）。

課金はそのモデルの通常レートで行われ、content は空のまま、トークン数は usage に出る。レート制限にも通常どおり計上される。

ストリーミング中の拒否は別で、入力トークンと、既に流れた出力が通常レートで課金される。

善意でも引っかかる3つ

ドキュメントは、各カテゴリについて「良性の作業でも発火しうる」と明記している。

cyber — 良性のセキュリティ業務でも発火しうる（課金はされない）
bio — 有益なライフサイエンスの業務でも発火しうる（課金される）
frontier_llm — 良性の機械学習の業務でも発火しうる（課金される）

reasoning_extraction が実務ではいちばん近い。モデルに思考過程を出力させるプロンプトが原因になる。<thinking> や scratchpad のセクションを本文中に書かせる形は、典型例として挙げられている。

で、SEの実務ではどう使うか

「拒否は失敗だから課金されない」という前提は置けない。

コストを見積もるときに効く点が3つある。

監視が拒否を数えているか。 HTTP 200 で返るので、エラー率には出ない。stop_reason を見ていなければ、拒否は「正常に空のレスポンスが返った」として処理される。 件数が見えなければ、課金の説明もつかない。

reasoning_extraction は自分たちのプロンプトで作り込める。 「考えた過程も出力して」という指示は、説明可能性のために入れたくなる。それが課金対象の拒否を生む。思考を構造化された形で得たいなら、出力に書かせるのではなく専用の仕組みを使うとドキュメントは案内している。

フォールバックの設計が要る。 fallbacks を "default" にすると、拒否されたリクエストを推奨の代替モデルで自動的に再試行する（ベータ）。ただしカテゴリによっては推奨の代替が無く、拒否がそのまま確定する。

稟議やコスト見積もりに書くなら「拒否は HTTP 200 で返り、3カテゴリは課金される。監視は stop_reason を見る」の2行になる。エラー率だけを見ている監視だと、請求と手元の数字が合わなくなる。

引用はすべて Claude Platform のドキュメントに記載されているものである。