メインコンテンツまでスキップ

安全性、拒否とフォールバック

中級

本番環境では、Claudeが期待通りに答えられない(または答えない)ケースをコードが処理しなければなりません。うまくやればユーザーには見えず、下手にやればクラッシュや紛らわしい返答になります。

What you'll learn
  • モデルの拒否と分類器/安全性ブロックを区別する — そしてなぜそれが重要なのか
  • 拒否をクラッシュや空の返答ではなく、通常の結果として処理する
  • 望まない拒否を減らしつつ、正しい拒否をジェイルブレイクしようとしない
  • フォールバックを選ぶ:明確化の質問、安全な代替案、または人間へのエスカレーション

2つの異なるもの​

  • モデルの拒否 — Claudeがリクエストを断ります(例:有害だと判断する)。レスポンスがこれを示します(一般には拒否のstop_reason/コンテンツで)。エラーではなく通常の結果として扱ってください。
  • 分類器/安全性ブロック — 別個の安全性レイヤーがコンテンツをブロックすることがあります。これはモデルの拒否とは見た目が異なることがあります。

どちらを受け取ったかを知ることで、盲目的に再試行するのではなく、適切に対応できます。

優雅に処理する​

resp = client.messages.create(...)
if getattr(resp, "stop_reason", None) == "refusal":
    # Don't show a raw/empty result. Offer a safe fallback or a clarifying ask.
    show_user("I can't help with that as asked. Here's what I can do instead…")
else:
    render(resp)

望まない拒否を減らす​

  • 正当なコンテキストを加える。 意図が善意でも、リクエストが機微なものにパターンマッチすることがあります。実際の正当な目的を述べることが役立ちます。
  • 具体的に。 曖昧または尖った言い回しは慎重さを招きます。
  • 戦わない。 リクエストが本当に禁止されているなら、拒否は正しい — 優雅な道筋を設計してください。ジェイルブレイクしようとしないこと。

最初に正当なコンテキストを加える

I am a security engineer at [company] reviewing our own authentication code
before a release. Below is a function we wrote and own.

Identify weaknesses in it and explain how an attacker would exploit each one,
so we can fix them before we ship.

[code]

フォールバックのパターン​

  • 行き止まりの代わりに明確化の質問。
  • 安全な代替案(「代わりに公開情報を要約できます」)。
  • パイプラインでは、信頼度/適格性が低いときは人間にルーティング。
Guided walkthrough1 of 4
  1. レンダリングする前に、拒否シグナルがないかレスポンスを検査する。未確認のレスポンスをそのままUIに流し込まないこと — それがユーザーに空の箱や生のオブジェクトを見せる原因です。

理解度チェック

0/3
  1. コードがClaudeから拒否を受け取りました。正しい扱い方は?
  2. 善意のリクエストが繰り返し拒否されます。最初に試すことは?
  3. モデルの拒否と分類器/安全性ブロックのどちらを受け取ったかがなぜ重要ですか?
Key takeaways
  • 拒否はエラーではなく結果 — レンダリング前に必ず検出する。
  • モデルの拒否と分類器のブロックは別物;どちらを受け取ったか識別する。
  • 望まない拒否は通常、正当なコンテキストを加えて具体的にすると減る。
  • リクエストが本当に禁止なら、拒否は正しい — 優雅な道筋を作り、ジェイルブレイクしないこと。
  • フォールバックの順序:明確化の質問、安全な代替案、人間へのエスカレーション。

次のステップ​