Cursor の sensitive prompt エラーの修正
sensitive prompt エラーは、正当なセキュリティ、医療、または法務の作業の途中で現れるため、Cursor で最も紛らわしいメッセージの 1 つです。このガイドでは、このエラーが実際に何であるか、どの入力がそれを引き起こすか、確実にブロックを解除する回避策、そしてブロックが誤っていたときに誤検知を報告する方法を説明します。
sensitive prompt エラーの意味
このエラーは Cursor によって生成されるものではありません。Anthropic 側の安全性分類器から来るもので、リクエストが Claude モデルに到達する前にスクリー ニングします。分類器が結合されたプロンプトとコンテキストを sensitive とフラグ付けすると、Anthropic がリクエストを拒否し、Cursor がその拒否をチャット内のエラーとして表示します。
ブロックに関する重要な事実：
- これはモデルの判断ではなく、分類器の判断です。モデルはリクエストを決して見ません。
- Anthropic モデルに適用されるため、Opus および Sonnet のバリアントで表示されます。
- あなたの意図や職種ではなく、プロンプトと添付されたコンテキストによって引き起こされます。
- 単一のリクエストで発火し、文言やコンテキストを少し変えた次のリクエストでは解除されることがあります。
分類器は目的ではなく質感で動作するため、ペネトレーションテスターと攻撃者がほぼ同一のテキストを送信すると同じ結果を得ます。これがほぼすべての誤検知の根源です。
実際には、修正はやっていることを隠すことではなく、それを率直に述べ、生の成果物を添付コンテキストから外すことです。「根本原因とパッチを説明して」と書くレビュアーは有用な回答を得ます。トリミングされていないエクスプロイトを「これを動くようにして」の隣に貼り付ける同じレビュアーはブロックされます。受け取る技術的な深さはほとんど変わりませんが、ブロックされる可能性は急落します。
Cursor はクライアントからこの分類器を単純に「オフ」にすることはできません。Anthropic が自身がホストするモデルに対して上流で強制しています。実践的な解決策は、送信内容を変える、モデルを切り替える、またはその両方です。
表示される症状
ブロックはいくつかの認識可能な形で現れます。症状を原因と一致させると修正が速くなります。
チャット内のエラーテキスト
通常、次のいずれかに近いものが表示されます。
The request was blocked because it contains sensitive content.
Please rewrite your request or start a new chat.
Error: prompt contains potentially sensitive content (Anthropic)
The model declined this request. This may be due to the content of
your prompt or the attached context. Try rephrasing or removing files.
正確な文言は Cursor のバージョンとモデルのバリアントで異なりますが、パターンは安定しています。拒否、言い換えの提案、そして時折添付コンテキストへの言及です。
応答の途中でチャットが停止する
分類器がリクエストを通し、その後のターンで引っかかることがあります。目に見える結果は、途中で停止する応答で、次のターンで感度エラーが続きます。これは通常、アシスタント自身の以前の出力がフラグ付けされたテキストを会話履歴に導入したことを意味します。
他のモデルでは機能する
同じプロンプトが GPT、Gemini、または Grok では成功し、Opus または Sonnet では失敗する場合、Anthropic の分類器が制約です。これは強いシグナルであり、モデル切り替えの回避策を直接指し示します。
同じチャットでの繰り返しの失敗
一部のチャットは「汚染」されます。一度フラグ付けされたコンテンツが履歴に入ると、その後のすべてのターンがそれを再送信します。汚染されたスレッドには、新しく開始することがしばしば唯一の確実な修正です。
ハードブロック前の静かな劣化
一部のセッションは完全に失敗する前に劣化します。モデルは回答を短くし、サブステップを拒否し、あるいは尋ねたものとは別の質問に答えます。これらはしばしば周囲のコンテキストへの初期の分類器圧力です。パターンに気づいたら、ハードエラーが落ちる前にコンテキストを整理してください。
ターン間で移動する失敗
リクエストは 1 ターン目で通過し、3 ターン目で失敗することがあります。間に挟まるアシスタントの出力が新しいフラグ付けされた素材を履歴に追加したためです。これが、同じスレッド内での再試行が信頼できない理由であり、新しいチャットを開始すると多くのケースが解決する理由です。
何が引き起こすか
分類器はあなたのプロジェクトの目的ではなくパターンに反応します。次のカテゴリがトリガーの大部分を占めます。
| トリガー | 発火する理由 | 正当なワークフローでの例 |
|---|---|---|
| セキュリティツールの出力 | 攻撃ツールのように読める | インジェクションペイロードを列挙する Semgrep や Burp の出力 |
| エクスプロイトまたは PoC コード | 動作するエクスプロイトコードのように見える | パッチレビュー用の CVE 再現コード |
| 生のスキャンログ | フラグ付けされるトークンが密集している | 丸ごと貼り付けられた完全な nmap または nuclei の出力 |
| 認証情報またはエンコードされた塊 | シークレットやペイロードに似ている | Base64 文字列、トークン、またはハッシュ化されたダンプ |
| 医療または法務コンテンツ | 機微なドメインのキーワード | HIPAA やコンプライアンスレビューのメモ |
| ゲームコンテンツ内の暴力 | 文脈を外れた暴力的な言葉 | 戦闘ダイアログやダメージシステムの設計 |
| 大きな貼り付けファイル | 混在したコンテンツが多くのシグナルを押し上げる | トリミングなしで添付されたリポジトリファイル全体 |
単一のカテゴリが単独でブロックを引き起こすことはまれです。分類器は複数のシグナルが積み重なったときに発火する傾向があります。たとえば、「攻撃計画」を求めるリクエストの中で、エクスプロイト形状のコードの隣に、エンコードされた塊を含む生のスキャンログが貼り付けられている場合です。
上記のカテゴリは例示であり、網羅的ではありません。モデルと分類器の変化に伴い新しいトリガーが現れるため、繰り返し発生するブロックは、暗記すべき固定リストではなく、添付コンテキストにあるものを検査するシグナルとして扱ってください。
なぜ正当な作業で起こるか
セキュリティ、ヘルスケア、法務のエンジニアリングは、分類器が阻止するように設計されたコンテンツとまったく同じに見えるテキストを日常的に必要とします。これは正常で想定内です。
- ペネトレーションテスト：エクスプロイトペイロード、PoC、および所見レポートが成果物です。
- マルウェア分析：サンプル文字列、逆アセンブリ、および IOC は本質的に疑わしく見えます。
- セキュリティレビュー：脆弱性のためにパッチをレビューすることは、脆弱なコードを読むことを意味します。
- レッドチームツール：攻撃的ツールの作成やデバッグは攻撃的な意図として読まれます。
分類器は「この CVE の修正を手伝って」と「この CVE を悪用するのを手伝って」を口調だけで区別できないため、誠実な作業が引っかかります。あなたの仕事は、同じ技術的内容を、攻撃計画ではなく修復として読める形で送ることです。
sensitive なリクエストを送る前の有用なテスト：自分の役割についての文脈なしで、見知らぬ人がそれを受け取ったかのように読んでみてください。最初の段落が害を及ぼす要求と誤解される可能性があるなら、分類器もおそらくそうするでしょう。その見知らぬ人のために書き直すことが、通常はブロックを解除するのに十分です。
即時の回避策
このリストを安価なものから重いものへと順に進めてください。ほとんどのブロックは最初の 2、3 ステップで解除されます。
操作の順序
好みのモデルに留まる最も安価な変更から始めてください。言い換えまたは墨消しです。それが失敗したらコンテキストを絞り込みます。モデルの切り替えは文言の変更が効かなくなってからにし、新しいチャットを開始するのはスレッド自体が問題である場合のみにしてください。この順序で作業すると、不要な変動を避け、変更する理由がないときにモデルの選択を安定させられます。
1. リクエストを言い換える
防御的な目標を先頭に置き、成果物を中立的に説明します。「X のエクスプロイトを書いて」を「X の根本原因とそれを修正するパッチを説明して」に置き換えます。「Y をどうやってバイパスしますか」を「Y を防ぐ制御は何で、それが有効であることをどう検証しますか」に置き換えます。
2. 意図を明示的に再構成する
最初の文で目的を述べます。「防御目的で」「修復レビューの一環として」「回帰テストを書くために」といったフレーズは、生のテキストに欠けているコンテキストを分類器に与えます。
3. コンテキストを分割する
疑わしい素材を単独で送り、それについて狭い質問をするようにします。広い「すべてを分析して」というリクエストと束ねるのではなくです。積み重なるシグナルが少ないほど、分類器を引っかける可能性が低くなります。
4. フラグ付けされたスニペットを墨消しする
実際のバイトをプレースホルダーに置き換えます。REDACTED_TOKEN、REDACTED_PAYLOAD、または <secret-value> に置き換え、モデルにリテラルの内容ではなく構造と形状について推論するよう求めます。
Instead of pasting the raw payload:
payload = b"\x90\x90\x90...\xcc"
Paste a redacted form:
payload = b"<REDACTED_SHELLCODE>"
Length: 412 bytes
Ask: what defenses would detect this class of payload at the WAF layer?
5. 新しいチャットを開始する
スレッドが以前にフラグ付けされた出力で汚染されている場合、新しい会話はその履歴を破棄します。これは古いスレッドを消去しようとするよりしばしば速いです。
6. 添付コンテキストを減らす
不要な @ メンションされたファイルや貼り付けブロックを切り離します。余分なファイルはすべて、分類器が反応する表面積を増やします。
7. モデルを切り替える
タスクを非 Anthropic モデルに移します。GPT、Gemini、または Grok です。分類器 は Anthropic 固有であるため、同じ内容は通常どこでも通ります。
8. 待って再試行する
分類器の挙動は時間を通じて完全に決定的ではありません。短い待機後の再試行は時折変更なしで成功しますが、これを主要な修正として頼るべきではありません。
やってはいけないこと
同様に重要なのは避けるべきことです。これらのパターンは時間を浪費し、ブロックを悪化させることがあります。
- 同じブロックされたリクエストを繰り返し貼り付けないでください。同一の入力は同一に失敗する傾向があります
- 「jailbreak」スタイルのプロンプトにエスカレートしないでください。それは感度を下げるのではなく上げます
- 明確にしようとより多くの生コンテンツを貼り付けないでください。追加されたコンテキストはシグナルを追加するだけです
- モデルが故障していると仮定しないでください。リクエストはモデルに到達していません
- 一貫して失敗し始めたスレッドを再利用しないでください。その履歴が問題です
- 1 語を編集して即座に再送信しないでください。小さな編集はめったに助けず、よ り大きな再構成が助けます
実質的なタスクでハードブロックされた場合、まず非 Anthropic モデルに切り替え、その後必要に応じてより短くクリーンなコンテキストで後から Sonnet で再試行します。モデルの切り替えはブロックを即座に解除し、作業を続けられます。
長期的な予防
ブロックは厄介ですが軽減できます。目標は、コンテキストを焦点を絞ったものに保ち、生のフラグ付けされた素材を排除することです。
Rules を焦点を絞って短く保つ
数百行に及ぶ .cursor/rules ファイルは多く のリクエストに添付され、偶発的なトリガーの可能性を倍増させます。rules は、現在の作業にモデルが実際に必要とするものに限定してください。
生のシークレットを決して貼り付けない
キー、トークン、またはダンプを貼り付けないでください。シークレットのフォーマットについて推論する必要がある場合は、プレースホルダーを使い、形状を説明してください。これで認証情報と塊のトリガーを完全に避けられます。
スキャン出力を要約する
1000 行のスキャナダンプを貼り付けないでください。重要な所見を抽出し、上位 10 件を保ち、残りは散文で説明してください。要約はフラグ付けされるトークンがはるかに少ないです。
必要なものだけを添付する
ディレクトリ全体を引き込むのではなく、@ メンションで特定のフ ァイルを添付します。狭いコンテキストは安価で、分類器を引っかける可能性も低くなります。
安全なコンテキストのプロジェクトを保つ
繰り返し発生する機微な作業のために、ファイルがサニタイズされたドキュメント形式のコンテンツを含む専用プロジェクトを保ってください。生の成果物ではなく、根本原因の記述、修復ノート、テスト計画などです。機微な質問はそのプロジェクトに向けてください。
どのファイルが危険かを追跡する
プロジェクト内でブロックを引き起こしがちなファイル、たとえば生のスキャンエクスポートやフィクスチャのペイロードの短いメモを保ってください。必要なときに名前で参照し、デフォルトで添付するのは避けてください。維持されたリスクリストは、毎週同じトリガーを再発見するより優れています。
量より構造を優先する
長く未分化なコンテキストは積み重なったシグナルを招きます。大きな要求を一連の小さな単一目的のリクエストに分割し、それぞれに最小の添付コンテンツを持たせます。これは回答の品質も向上させるため、変更は二重に報われます。
一度フラグ付けされた応答が会話に落ちると、その後のターンがそれを履歴として再送信します。チャットが繰り返し失敗し始めたら、侵害されたものとして扱い、ターンごとにブロックと戦うのではなく新しいものを開始してください。
セキュリティとコンプライアンスのコンテンツの扱い
一部の分野は日常的に sensitive と読めるコンテンツを必要とします。次のパターンで、繰り返しのブロックなしにそれらのタスクを 通過させられます。
ペネトレーションテストとレッドチーム
最初の行から作業を修復として構成し、対象を抽象的に保ってください。
- ステップバイステップのエクスプロイトではなく、脆弱性のカテゴリとその修正について尋ねる
- 実際のホスト名、トークン、ペイロードをプレースホルダーに置き換える
- 所見を散文で説明し、レビュー対象の特定のコードのみを添付する
- スコープの文言を明示的に保つ。たとえば「authorized assessment, scope: internal test environment」
マルウェアとフォレンジック分析
サンプルの文字列と逆アセンブリはデフォルトで敵対的に読まれるため、隔離されたドキュメント化されたパターンが最もよく機能します。
- 生のサンプルを別のファイルに移し、貼り付けるのではなく名前で参照する
- 「これは何をするのか」ではなく、挙動のカテゴリと検出ルールについて尋ねる
- 完全なログを貼り付けるのではなくインジケータ ーを要約する
- インデックスされたファイルがサニタイズされた成果物を保持する専用の分析プロジェクトを保つ
医療、法務、および規制対象データ
規制されたドメインのコンテンツは、タスクが純粋に技術的であっても分類器を引っかける可能性のある独自のキーワードを持っています。
- 患者、クライアント、またはケースの識別子を取り除き、合成値に置き換える
- 技術的な質問をドメインの物語から分離しておく
- リテラルのレコード内容よりスキーマと構造の説明を優先する
- 実際のレコードを読むのではなく、データの形状を説明し、処理ロジックについて尋ねる
サニタイズされた参照セットの構築
繰り返しの作業のために、同じ素材を中立的な用語で説明するドキュメント形式のファイルの小さなセットを組み立ててください。根本原因の記述、修復ノート、テスト計画、および制御の説明です。機微な質問は生の成果物ではなくそれらのファイルに向けてください。数週間 でこれが確実なパスになり、生の成果物のパスは消えていきます。
名前を偽のものに置き換えることは助けになりますが、密な臨床的または法的な言い回しはそれ自体で分類器をトリガーすることがあります。それが起こった場合は、リクエストを特定の技術的な質問に絞り、周囲の物語を完全に落としてください。
モデルの切り替えとプロンプトの書き直しの選択
どちらの修正も機能し、正しいものはタスクにとって Claude がどれだけ中心的かに依存します。
| 状況 | 最善の最初の一手 | 理由 |
|---|---|---|
| 単発の質問がブロックされた | プロンプトを書き直す | 好みのモデルに留まれる |
| 大きなコンテキストがすでに準備済み | モデルを切り替える | 添付をゼロから再構築するの を避ける |
| タスクが特に Claude を必要とする | 書き直して墨消しする | Claude の挙動が依然として必要 |
| 1 つのプロジェクトで繰り返しブロックされる | プロジェクトを再構築する | 症状ではなく根本原因に対処する |
| 締め切りのプレッシャー | 今モデルを切り替え、後で再試行 | ブロック解除への最速のパス |
プロンプトを書き直すべきとき
ブロックが文言、構成、または単一のフラグ付けされたスニペットに関するものであるときに書き直してください。これらの変更は安価で、Claude に留まれ、しばしば副産物としてより良いプロンプトを生みます。防御的な構成は通常、より明確なものでもあるからです。
モデルを切り替えるべきとき
コンテンツが本質的にフラグ付けされる場合、コンテキストが大きく再構築に高コストな場合、または時間のプレッシャーがある場合に切り替えてください。GPT、Gemini、および Grok は Anthropic の分類器を適用しないため、同じ素材は通常すぐに通ります。
プロジェクトを再構築すべきとき
同じ作業で多くのターンにわたってブロックが再発する場合、プロジェクト自体のファイルがトリガーです。生の成果物を添付パスから外に移し、サニタイズされた要約をインデックスされたファイルに保ち、機微な質問をそれらの要約に向けてください。これで各プロンプトにパッチを当てるのではなく、根源でトリガーを除去できます。
モデル一覧に 1 つの Anthropic モデルと 1 つの非 Anthropic モデルを保ち、切り替えが 1 クリックで済むようにしてください。ブロックされたリクエストを数秒で横に移動できることが、このエラーをハードストップから軽微な回り道に変えます。
Cursor サポート経由で Anthropic に誤検知を報告する
ブロックが明らかに誤っていて実際の作業を妨げる場合は、報告してください。Cursor はこれらの報告を収集し、パターンを Anthropic に伝え、同じテーマに関する十分な報告は時間とともに分類器の挙動を変えます。
含めるもの
長い物語ではなく、再現可能な最小限の記述を提供してください。
Model: Claude Sonnet (or Opus)
Task: reviewing a security patch for CVE-XXXX-YYYY
Prompt (summarized): explain the root cause and write a regression test
Context attached: two files, both sanitized, no secrets
Result: sensitive prompt error, request never reached the model
Reproduced on: 3 attempts in the same chat, 1 attempt in a fresh chat
Notes: same prompt succeeded on GPT and Gemini. This reads as a false
positive on a defensive security workflow.
モデル名、サニタイズされたプロンプト、およびそれが再現するという事実を含めてください。生の sensitive なコンテンツ自体を報告に貼り付けないでください。形状の記述で十分で、サポートツール内のフィルターを再トリガーするのも避けられます。
送信先
アプリ内のサポートフォームまたは公開されたサポートアドレスを使用してください。モデル名、サニタイズされたプロンプト、再現手順、および防御目的の 1 行の説明を含めてください。生のものは何も添付しないでください。サポートがブロックを再現できなくても、パターンを Anthropic に転送できます。同じテーマに関する繰り返しの報告が、最終的に分類器を動かすものです。
安定した再現と明確な防御目的を持つ報告は、「エラーが発生し続ける」とだけ言う報告よりはるかに有用です。具体性がパターンを上流で行動可能にするものです。
クイックリファレンスのトラブルシューティング表
この表を使って、ガイド全体を読み返すことなく症状から修正へ進んでください。
| 症状 | 考えられる原因 | 修正 |
|---|---|---|
| 最初の送信でエラー、Anthropic モデル | プロンプトまたはコンテキストが分類器を引っかけた | 言い換え、意図の再構成、墨消し、またはモデル切り替え |
| GPT/Gemini では機能するが Opus/Sonnet では機能しない | Anthropic 固有の分類器 | 非 Anthropic モデルに切り替える |
| 応答の途中でチャットが停止しエラ ー | 以前の出力が履歴でフラグ付けされた | 新しいチャットを開始する |
| 1 つのスレッドですべてのターンが失敗 | 汚染された会話履歴 | 新しいチャットを開始する。その場で再試行しない |
| ファイルを添付した後に失敗 | 添付コンテンツがトリガーを持っている | 添付コンテキストを減らすかサニタイズする |
| 大きな貼り付けで失敗 | 大きな塊からの混在シグナル | より小さく焦点を絞ったリクエストに分割する |
| スキャンまたはエクスプロイト出力で失敗 | 攻撃素材として読める | 生の出力を貼り付けるのではなく要約する |
| 断続的で明確なトリガーがない | 分類器のエッジ挙動 | 1 回再試行し、続く場合はモデルを切り替える |
これらすべてに共通するパターンは同じです。分類器は質感を読むため、送信するものの質感を変える、コンテキストを狭める、またはその分類器を適用しないモデルにリクエストを移すことで勝利します。
エラーをあなたの作業についての判断ではなく、コンテキストについてのシグナルとして扱ってください。送信するものの形状を調整することで、正当なセキュリティ、コンプライアンス、および分析タスクを動かし続けながら、それが捕まえるために作られたケースに対して安全性レイヤーを無傷に保てます。
遭遇した各ブロックを解決した回避策の短いメモを保ってください。時間とともにそのメモは個人のプレイブックになり、次のブロックはデバッグセッションを費やす代わりに数秒で解除されます。