Anthropic、advisor tool の出力上限と API refusal 課金を更新

Anthropic は Claude Platform の 2026年6月2日付リリースノートで、advisor tool に max_tokens パラメータを追加し、API が出力なしの stop_reason: "refusal" を返した場合の課金を変更したと案内しました。長時間エージェントと安全性制御の両方に関係する更新です。

要点

• advisor tool が max_tokens をサポートし、advisor モデルの 1 回あたり出力量を制限できるようになった
• 出力上限により、レイテンシと出力トークンコストを抑えやすくなる
• Claude API が出力なしで stop_reason: "refusal" を返した場合、そのリクエストは課金されない
• refusal の検出やハンドリングには Streaming refusals のドキュメント確認が必要
• 本番エージェントでは advisor 利用回数、出力上限、拒否時の再試行設計を見直したい

今回のリリースノートで語られていること

今回の更新は、Claude をエージェント基盤として使うチームにとって実務的な意味が大きいものです。advisor tool は、実行担当のモデルが難しい判断に当たったときに、より高い知能の advisor モデルへ相談するための仕組みです。すべての手順を高価なモデルに任せるのではなく、普段は executor が進め、難所だけ advisor に助言を求めることで、品質とコストのバランスを取りやすくします。

今回 max_tokens が追加されたことで、advisor の返答を必要な範囲に制限できます。長いエージェントタスクでは、advisor が毎回詳細な説明を返すと、出力トークンが増え、レイテンシも伸びます。一方で、場面によっては「次にどの方針を取るべきか」「この計画を続けるべきか」だけ分かれば十分です。tools[].max_tokens に上限を設定できるようになると、助言の粒度を業務に合わせて調整できます。たとえば、コードレビュー支援では短い判断でよい場面と、設計変更の相談で長い説明が必要な場面を分けられます。

もう一つの更新は refusal 時の課金です。Claude API が、Claude からの出力を生成せずに stop_reason: "refusal" を返した場合、そのリクエストは課金されないと案内されています。安全性上の拒否が発生するワークロードでは、これにより費用の読み方が変わります。ただし、課金されないからといって、拒否を無視してよいわけではありません。アプリケーション側は refusal を検出し、ユーザーへの説明、代替手順、管理者への記録、入力修正の案内を設計する必要があります。

エージェント運用では、この二つの更新が組み合わさります。advisor の出力を短くしすぎると、executor が判断材料を十分に得られず、結果として失敗や再試行が増える可能性があります。逆に長すぎる助言は、コストと遅延を増やします。また、refusal が起きた場合にエージェントが同じ入力を何度も再送すると、ユーザー体験や監査の面で問題になります。今回の更新は、単なるパラメータ追加ではなく、長時間タスクのコスト制御と安全な失敗処理を整えるきっかけとして読むべきです。

実務で確認したいポイント

advisor tool を使っている場合は、ユースケース別に推奨 max_tokens を決めるとよさそうです。短い方針判断、長い設計相談、リスク評価、障害調査などで必要な助言の長さは違います。出力上限を入れた後は、成功率、再試行回数、完了時間、総トークン数を比較してください。

refusal については、API レスポンスの stop_reason を監視し、拒否理由をユーザーにどう伝えるかを決めておく必要があります。特に社内ツールでは、拒否が起きた入力をログに残す範囲、個人情報や機密情報の扱い、再入力を促す文言まで確認したいところです。

結局、この更新をどう見るべきか

2026年6月2日の Claude Platform 更新は、エージェントの運用コストと安全性を現実的に管理するための調整です。advisor tool の出力上限は長時間タスクの効率化に効き、refusal 課金の変更は安全性制御を組み込んだアプリの費用設計を見直す材料になります。