Claude Codeで作業をしていると、ある時から突然こう言われて止まることがあります。
API Error: Claude Code is unable to respond to this request, which appears to
violate our Usage Policy (https://www.anthropic.com/legal/aup).
しかも厄介なのは、一度これが出ると、その後に何を送ってもブロックされ続けることです。ok でも hi でも返ってこない。自分のごく普通のコードを直しているだけなのに、セッションが丸ごと使えなくなる。これは2026年6月に多くの利用者が同時に報告している、利用ポリシーの分類器の誤検知です。
この記事では、なぜ一度のブロックでセッション全体が止まるのか、そして今日できる回復の手順を整理します。実際に報告されている起票（GitHub の anthropics/claude-code）を根拠にしています。
なぜ一度のブロックでセッション全体が止まるのか
分類器は「いま送った1つのメッセージ」だけを見ているのではありません。セッションに溜まっていく文脈の全体を毎ターン読み直して判定しています。だから次のことが起きます。
- どこかのターンで分類器のスコアが閾値を越えてブロックが出る。
- ブロックされたターンを含む文脈が、次のターンでもまた送られる。
- 同じ高スコアの文脈を読み直すので、
okのような無害なメッセージでも再びブロックされる。
つまり**止まっているのは「メッセージ」ではなく「セッション」**です。だから新しいメッセージを工夫しても抜けられません。
2026年6月、範囲が「普通の開発」に広がった
以前はこの誤検知は、ファームウェアの書き込みやセキュリティ監査のような、セキュリティに隣接した語彙の多い作業で起きるものでした。ところが2026年6月（Claude Code の 2.1.161〜2.1.167 付近）では、セキュリティの語彙が一切ない普通の作業でも発火するという報告が相次いでいます。
- 自分の Node/Mongoose の CRUD のバグ修正
- testnet 上の自分のアプリの開発
- ある報告では、
git worktree statusだけのターンや、文字どおり"hi"でも発火
ある利用者が自分の全セッションの記録を監査したところ、ブロックされたイベントはすべて 2.1.161、最も古いもので2026年6月1日でした。Windows・macOS・Linux のどれでも起きており、これはOS や語彙ではなく、サーバー側・モデル側の変化を示しています。
ここが重要な含意です。普通のターンで止まるなら、「セキュリティの語彙を減らす」という対処は減らす対象がありません。 語彙の言い換えで抜けようとしても無駄になります。
まず「どちらの故障モードか」を切り分ける
回復できるかどうかは、状態がどこにあるかで決まります。そして、ただ「新しいセッションを開く」だけでは判別できません。新しいセッションも同じ ~/.claude.json と同じアカウントを使い回すからです。
| 原因 | 見分け方 | 回復 |
|---|---|---|
| ローカルの文脈の再生 |
--continue / --resume で汚染されたセッションを再開した時だけ再発する（問題のターンがそのセッションの記録に残っている） |
本当に新規のセッションを開けば再生されない。記録を問題のターンの手前で切って再開すれば文脈を残したまま回復できる |
| アカウント・サーバー側 | 本当に新規のセッションでも、別の git worktree でも止まったまま | 端末側で消す手段は無い。req_… を添えて上流に報告するしかない |
両者を切り分ける1つのテストは、設定を退避してまっさらな状態で起動することです（消さずにバックアップ）。
mv ~/.claude.json ~/.claude.json.bak
mv ~/.claude ~/.claude.bak # projects/history を含む。消さずに退避
# 再認証し、同じプロジェクトを開いて、無害なターンを1回送る
- まっさらな状態で通る → ローカルの再生が原因。問題のセッションの記録だけを片付け、バックアップは選んで戻せばよい。
- まっさらでも止まる → アカウント・サーバー側。端末側の操作では直らない。
上流に報告するときは request_id が決め手
ブロックされたターンが無害な場合、req_… の request_id が最も役に立ちます。これがあれば、Anthropic 側は中身（無害なターン）と独立に、分類器がどう判定したかを追跡できます。デバッグ・詳細のログに出ます。「フィルタが厳しすぎる」と書くより、「まっさらな設定・新規のアカウントのセッションで、無害なターンが止まった」＋ request_id の組み合わせが、最も再現性の高い報告になります。
同じ症状の人は新規に起票を立てるより、既存の起票にこの request_id と自分の再現を足すほうが、修正を早めます。
まとめ
- このエラーはメッセージではなくセッションが汚染される。だから新しいメッセージの工夫では抜けられない。
- 2026年6月は普通の開発でも発火する。語彙の言い換えは効かない。
- まずまっさらな設定での起動テストで、ローカルの再生かサーバー側かを切り分ける。
- 上流への報告は request_id が決め手。
補足として、私はこの誤検知のクラスタを含む Claude Code の安全運用の無料のまとめを MIT ライセンスで公開しています（cc-safe-setup）。上のセッションの切り分けや回復の手順、関連する起票の追跡をまとめたフィールドガイドが、再検索の手間を減らすのに役立つはずです。ただしこの記事の手順は単体で完結します。要点は、サーバー側の修正を待つ間も、まっさらな起動テストと request_id の取得という1手で前に進めるということです。
この「正当な作業が cyber/Usage Policy の誤検知でブロックされ、セッションごと死ぬ」型は、起票が25件以上ある集積の一つで、Sonnet への切り替えやセッション衛生といった回避と、4本の無料の助言用 hook まで含めて 事故防止本 の第18章（AUP 誤検知の集積）で深掘りしています（第3章まで無料・Kindle Unlimited ならAmazon版で無料）。
この「Usage Policy 違反」の誤検知のように、Claude Code は毎月のように新しい止まり方・事故の型が現れます。その月に報告された事故（誤検知・データ消失・暴走・無断課金など）と回復・予防の手順を一か所にまとめているのが、2026年6月 Claude Code 事故まとめ（無料・毎月更新）です。新しい号の通知は note のゆるくさ のフォロー（無料）で届きます。先月から何が変わったかを毎月まとめて追えます。
ほかにも、800時間の運用データから、トークン消費の削減・複数ベンダー(Claude / Codex / Gemini / Copilot)の並行運用・サブエージェントの沈黙の失敗対策など、テーマ別の手引きを公開しています。気になる人は著者の本の一覧から、価格と評価を見て選べます。