Anthropicが投入した最上位AIモデル「Fable」をめぐり、セキュリティ研究者たちから「ガードレール（安全制限）が厳しすぎて、サイバーセキュリティの仕事にまったく使えない」という不満の声が上がっているとTechCrunchが報じました。攻撃と防御の両面でAI活用が当たり前になりつつある今、この「安全性と実用性のせめぎ合い」は、セキュリティに関わるすべてのエンジニアに直結する問題です。
この記事のポイント
- Anthropicの新モデルFableは、サイバーセキュリティ関連のリクエストに対する制限（ガードレール）が従来より大幅に強化されている
- 正当な脆弱性調査・ペネトレーションテスト・マルウェア解析など「防御側の業務」でも拒否されるケースが多いと研究者が指摘
- 攻撃者は制限の緩いモデルやオープンソースモデルに流れるため、「守る側だけが不便になる」という構造的ジレンマが浮き彫りに
背景 / なぜ重要か
この問題を理解するには、Anthropicが置かれている状況を知る必要があります。同社は「AI Safety」を企業アイデンティティの中核に据えており、モデルの能力レベルに応じて安全対策を段階的に強化する「Responsible Scaling Policy（責任あるスケーリング方針）」を運用しています。モデルが強力になるほど、サイバー攻撃や生物兵器などの「破滅的リスク」につながる出力を防ぐ仕組みが厳格化される設計です。
実際、Anthropicは近年のモデルから、サイバーセキュリティ領域のリクエストをリアルタイムで検知・遮断する専用のセーフガードをAPIレベルで組み込んでいます。APIレスポンスには拒否理由を示す「refusal」という停止理由と、「cyber（サイバー関連）」というカテゴリ分類が構造化データとして返る仕様が存在しており、サイバー領域が特別扱いされていることは仕様からも読み取れます。最上位モデルであるFableは能力が高いぶん、この種の制限が最も強くかかる対象になったと考えられます。
一方で、セキュリティ研究の現場では、エクスプロイトコードの解析、攻撃手法の再現検証、CTF（セキュリティ競技）、ペネトレーションテストなど、「攻撃の知識を扱うこと自体が仕事」という場面が日常的にあります。攻撃を知らずに防御は設計できない──この大原則と、AIベンダーの安全方針が正面衝突しているのが今回の構図です。
何が起きているのか：研究者の不満の中身
TechCrunchの報道によれば、セキュリティ研究者たちはFableのガードレールが「あらゆるサイバーセキュリティ業務に対して厳しすぎる」と訴えています。ポイントは、悪意ある攻撃支援を断られているのではなく、正当な業務上の依頼まで広範に拒否されている、という点です。
AIモデルの安全フィルタは一般に「過剰拒否（over-refusal）」と「過小拒否（under-refusal）」のトレードオフの上に成り立ちます。攻撃コードの生成を確実に防ごうとすれば、判定の網を広く張るしかなく、結果として「自社システムの脆弱性診断スクリプトを書いてほしい」「このマルウェア検体の挙動を説明してほしい」といった防御目的のリクエストまで巻き込まれます。Fableは最高性能モデルであるがゆえに悪用時のリスク評価も高く、Anthropicが判定の閾値を安全側に大きく倒した結果、誤検知の被害を最も受けたのがセキュリティ研究者だった、という見立てが自然でしょう。
さらに皮肉なのは、Anthropic自身がClaudeをセキュリティ防御に活用する動き（脆弱性発見やコード監査へのAI適用）を推進してきたことです。「セキュリティにAIを使え、ただしセキュリティの質問には答えない」という状態は、ユーザーから見れば矛盾と映ります。
実務への示唆 / 読者にとっての意味
サーバ運用や開発に携わる読者にとって、この問題は他人事ではありません。
第一に、AIをセキュリティ業務に組み込んでいる場合は「拒否される」前提の設計が必要になります。たとえばCI/CDに組み込んだAIコードレビューや、ログ解析の自動化パイプラインで、セキュリティ関連の内容だけ処理が失敗する事態が起こり得ます。APIの停止理由（refusal）をハンドリングし、拒否時のフォールバック（別モデル・人間へのエスカレーション）を用意しておくべきです。
第二に、用途ごとのモデル使い分けが現実解になります。一般的なコーディングや文書処理は最上位モデル、セキュリティ検証は制限の緩いモデルやローカルで動くオープンウェイトモデル、という構成は今後ますます一般化するでしょう。
第三に、より大きな視点では、「守る側がAIを使えず、攻める側は使い放題」という非対称性が業界全体のリスクになります。攻撃者は規約もガードレールも無視できる立場にあり、制限のないモデルを選べばよいだけです。ベンダーの安全対策が防御側の生産性だけを削る構図が固定化すれば、セキュリティ格差はむしろ拡大します。Anthropicをはじめ各社が「認証済みセキュリティ専門家向けの緩和枠組み」のような仕組みを整備できるかが、今後の焦点になるでしょう。
知っておくと便利なTips
- AIにセキュリティ関連の依頼をする際は、「自社環境の診断」「CTF演習」「защ防御目的」など正当な文脈・権限を明示すると拒否率が下がる傾向があります。文脈なしの「エクスプロイトを書いて」は最も拒否されやすい形です
- AnthropicのAPIでは拒否時に stop_reason が「refusal」となり、カテゴリ情報が付与されます。自動化パイプラインではこのフィールドを監視し、拒否を「エラー」ではなく「分岐」として扱う設計にしておくと運用が安定します
- 機密性の高い検体解析やペネトレーションテスト関連の作業は、そもそも外部APIに送ること自体のリスク（情報漏えい・規約違反）も検討が必要です。ローカルLLMの選択肢を持っておくと判断の幅が広がります
まとめ
Fableをめぐるセキュリティ研究者の不満は、単なる「使い勝手の問題」ではなく、AI時代のセキュリティ研究をどう成立させるかという構造的な課題を映しています。モデルが強力になるほど安全制限は厳しくなり、その影響を最初に受けるのは、攻撃知識を正当に扱う防御側の専門家です。読者としては、(1) AI拒否を前提としたワークフロー設計、(2) 用途別のモデル使い分け、(3) Anthropicが研究者向けの例外的なアクセス枠組みを打ち出すかどうか──この3点を注視しておくとよいでしょう。安全性と実用性のバランスをどこに引くか、業界全体の議論はまだ始まったばかりです。
関連記事
- JR東日本がAI窓口とQRきっぷを本格始動──磁気乗車券の終わりとレガシー刷新の現在地
- AppleがWWDC26で「Siri AI」発表──刷新の狙いと、開発者・エンジニアが今から押さえるべき視点
- Notionが「Anthropic接続障害」から復旧──SaaSがLLMに依存する時代のリスクを読み解く
📎 元記事: techcrunch.com
