過剰拒否（Over-Refusal）とは、LLMやAIエージェントが安全対策（アライメント）の副作用により、本来は無害・正当なプロンプトを誤って有害と判定し、回答やタスク実行を拒否してしまう現象を指す。安全性を高めるための訓練が、かえってAIの実用性を損なうという逆説的な課題として、AI研究コミュニティおよびOpenAI・Anthropic・Google・Metaなどの主要AI開発企業の間で広く認識されている。
概要
過剰拒否は、LLMが有害情報の生成を防ぐためにRLHFやConstitutional AIなどの安全訓練を受ける際、有害なプロンプトと「見かけ上は似ているが無害なプロンプト」を十分に区別できず、特定のキーワードや文脈に過剰反応することで発生する。医療情報の照会、法律手続きの確認、防御目的のセキュリティ教育といった正当な用途でも、誤ってブロックされる。
AIエージェントにおける過剰拒否は、基盤となるLLMの欠陥をそのまま引き継ぐ形で発現する。チャットボットであれば影響はテキスト回答の拒否に留まるが、自律的な計画やツール使用能力を持つエージェントの場合、コードの修正・API連携・セキュリティ調査といった実務的なワークフローが途中でブロックされ、業務上の破綻に直結する点が本質的に異なる。
なお、語感が似るOWASP Top 10 for LLMにおける「Excessive Agency（LLM06）」とは別概念であり、こちらはエージェントに必要以上の権限・自律性を付与することで生じるセキュリティリスクを指す。
仕組み・ポイント
発生のメカニズム
安全訓練の過程で、モデルは有害な文脈と関連するキーワードや表現パターンを学習する。その結果、同様のキーワードを含む無害なプロンプトに対しても拒否がトリガーされる。
安全性と実用性のトレードオフ
安全性を強化すると過剰拒否が増加し、過剰拒否を抑制しようとすると有害な要求への拒否率が低下するという構造的なトレードオフが存在する。エージェントはさらに、過剰拒否とは対極にある「有害な積極性（Toxic Proactivity）」や「過小拒否（Under-Refusal）」というリスクも抱えており、このトレードオフが一層複雑になる。
主な軽減技術
- TBR（Think-Before-Refusal）：拒否の前に内容を一度推論・吟味させるアプローチ
- 表現エンジニアリング（Representation Engineering）：モデルの活性化空間で「拒否方向」を特定し制御する技術（ACTOR手法など）
- 構造化推論（Chain-of-Thought）：明示的な推論プロセスを挟み、安全な文脈と有害な文脈を正確に区別させる
- Safe Completion（安全な完遂）：単純拒否ではなく、安全な代替回答や軌道修正を行う設計
評価・測定ツール
過剰拒否を定量的に測定するためのベンチマークとして、2024年5月発表の「OR-Bench」（Cuiら）、初期のデータセット「XSTest」（Röttgerら）、構造化推論を活用した「FalseReject」などが研究コミュニティで開発されている。
なぜ今注目されているのか
AIエージェントの業務利用が拡大する中、過剰拒否はもはや「不便さ」の問題ではなく「企業リスク」として位置づけられつつある。2026年7月のHugging Faceへの侵入事案では、米国の主要商用モデルがセキュリティ調査という正当な目的のクエリをハッキング関連と誤判定して拒否し、防御側の調査に支障をきたした事例が報告されている。
また、エージェント評価フレームワーク（Strands Agentsの「Refusal Evaluator」など）において、正当な要求への不適切な拒否を監視・評価する機能が組み込まれ始めるなど、業界としての対応が具体化している。研究面でも、業務AIエージェントの過剰拒否を定量化した評価基準論文が登場するなど、測定・比較の基盤整備が進んでいる段階にある。
日本企業への示唆
AIエージェントを業務ワークフローに組み込む際、過剰拒否の発生頻度と影響箇所を事前に評価することが実装品質の重要な指標となる。特にセキュリティ部門・法務・医療関連の業務では、正当な調査や情報収集がブロックされるリスクを考慮したモデル選定とプロンプト設計が求められる。一方で、過剰拒否を抑制しすぎると有害要求への応答リスクが高まるトレードオフがあるため、用途ごとに許容水準を定める運用設計が必要になる。OR-BenchやXSTestといった評価ベンチマークを活用し、導入前にモデルの拒否特性を定量的に把握するアプローチが有効だ。
※ 本ページはAI News JAPAN編集部が最新の動向を踏まえて解説したものです。内容は随時見直します。
