生成AIに少し踏み込んだセキュリティの質問をすると、「その依頼には対応できません」と断られることがあります。ペネトレーションテストやマルウェア解析のような業務をしていると、正当な検証なのに拒否されてしまい、「そこは答えてほしい」と感じる場面もあります。
一方で、この拒否機能を単純に邪魔な制限と考えるのは危険です。open-weightのLLMを中心に知られるようになったAbliteration（アブリタレーション）は、モデル内部にある拒否に関係する表現へ介入し、通常なら回答を拒否するような要求にも答えやすくするモデル編集手法です。
制限が減れば便利になるようにも見えます。ただ、セキュリティの仕事で重要なのは「何でも答えられるか」ではありません。企業でLLMを使うなら、必要なときに答え、危険な状況では止まれるかの方が重要です。
Abliterationとは何か
現在のチャット型LLMの多くは、単に大量の文章を学習しただけではありません。ユーザーの指示に従う能力や、安全性、人間の意図に沿った応答を身につけるための追加学習や調整が行われています。
その結果、「SQLインジェクションの仕組みを説明して」という教育目的の質問には答えながら、「第三者のWebサイトへ不正侵入する具体的な方法を教えて」といった要求には回答しない、といった振る舞いが生まれます。
Abliterationは、この拒否する振る舞いに関係するモデル内部の表現を特定し、その影響を弱める考え方です。
背景にある代表的な研究の一つが、2024年に公開された「Refusal in Language Models Is Mediated by a Single Direction」です。この研究では、複数のチャットモデルを調べ、モデル内部のactivation spaceに存在する特定の方向へ介入すると、危険な要求に対する拒否挙動を大きく変えられることが示されました。
ここから、「モデルがなぜ拒否するのか」を内部表現から調べ、その働きを弱めるアプローチが広く知られるようになりました。ただし、モデルの安全機能が文字通り一つのスイッチだけでできている、と考えるのは単純すぎます。
LLMの内部では多くの表現が複雑に関係しています。Abliterationは「安全機能をきれいに一つだけ削除する魔法」ではなく、モデルの拒否傾向を変化させるモデル編集として捉えた方が実態に近いです。
なぜサイバーセキュリティでは「拒否」が難しいのか
セキュリティ分野では、同じ技術が防御にも攻撃にも使われます。
SQLインジェクションを理解する。マルウェアの動きを解析する。認証回避の仕組みを調べる。ネットワーク上で横展開が可能か検証する。
これらは、許可された環境で行えば正当なセキュリティ業務です。一方、同じ知識を使って第三者のシステムを無断で侵害すれば、不正行為になります。
つまりLLM側からすると、単語だけを見て「これは攻撃だから拒否」「これは防御だから回答」と簡単に分けられるものではありません。
企業ではすでにLLMが、SOCでの調査支援、脆弱性分析、ペネトレーションテスト支援、セキュアコーディング、マルウェア解析、ログ分析、脅威インテリジェンス、インシデント対応といった業務にも使われ始めています。
こうした環境では、拒否が強すぎるモデルも使いづらくなります。ただし、だからといって拒否そのものを取り除けばよいわけではありません。
許可されたセキュリティ作業には対応し、無許可の攻撃支援には使わせない。
企業向けAIには、この線引きが必要です。
Abliterationはどうやって拒否を弱めるのか
細かい数学を抜きにすると、考え方は比較的分かりやすいです。
モデルに「ファイアウォールの仕組みを説明して」のような安全な要求と、明確に危険性の高い要求を与え、それぞれに対するモデル内部のactivationを比較します。そこから、拒否するときに強く現れる内部表現を探していきます。
見つけた拒否関連の表現へ介入する方法は、大きく分けると二つあります。
推論中の内部表現へ介入する
モデルが文章を生成するとき、そのactivationへ介入して拒否に関係する方向の影響を弱めます。モデルファイルそのものを恒久的に変更するのではなく、実行時に振る舞いを変える考え方です。
モデルの重み自体を変更する
もう一つは、モデルのweightを変更し、拒否に関係する方向を表現しにくくする方法です。こちらはモデル自体の振る舞いが変わるため、編集済みモデルを通常通り実行しても拒否しにくくなります。
Abliterationの特徴は、単純な「脱獄プロンプト」とは違う点です。特殊な文章でモデルを説得して安全機能を回避するのではなく、モデルそのものの内部表現へ手を加えています。
Abliterated modelと「無検閲AI」は同じではない
Abliterationを施したモデルが、「uncensored model」「無検閲モデル」として紹介されることがあります。ただし、この二つは完全な同義語ではありません。
Abliterationは、拒否挙動を弱めるための具体的なモデル編集手法です。一方、uncensored modelという言葉はもっと広く、安全調整が弱いモデルや、別の方法で制限を減らしたモデルにも使われます。
そのため、Abliterated modelは無検閲モデルとして扱われることがあるものの、すべての無検閲モデルがAbliterationで作られているわけではありません。
「拒否しない＝高性能」ではない
制限の少ないモデルを触っていると、「普通のAIでは拒否された質問にも答える。こちらの方が性能が高いのでは？」と感じるかもしれません。
しかし、拒否率が低いことと、モデルの能力が高いことは別です。
セキュリティ用途では特に、モデルから回答が返ってくるだけでは意味がありません。その回答が正確なのか、再現性があるのか、前提条件を理解しているのか、危険な操作を必要以上に推奨していないか、実際の環境へ適用して問題ないのかまで見る必要があります。
拒否が減った結果、間違った回答まで自信を持って出すようになれば、企業利用ではむしろ扱いにくくなります。
「答えてくれるAI」と「信頼して業務に使えるAI」は同じではありません。
安全機能だけをきれいに取り除けるとは限らない
Abliterationで気になるのが、モデル全体への影響です。
理想を言えば、「危険な依頼への拒否だけを弱め、それ以外の能力は完全に維持する」ことができれば扱いやすいでしょう。しかし、LLM内部の振る舞いはそこまで単純に分離されているとは限りません。
拒否に関係する内部表現へ強く介入すれば、モデルの指示追従や回答の一貫性など、別の特性にも影響する可能性があります。Abliteration済みモデルでは、元のモデル特性をできるだけ維持するために追加の調整が行われることもあります。
そのため企業で評価するときは、「安全機能だけを削った元モデル」として扱うのではなく、変更が加えられた別のモデルとして、能力と安全性の両方を改めて評価する方がよいでしょう。
セキュリティで本当に怖いのは、AI単体ではなく「権限との組み合わせ」
LLMが文章を生成するだけなら、問題が起きても影響範囲はある程度限定できます。しかし最近のAIは、チャットするだけではありません。
- Webブラウザ
- コード実行環境
- クラウドAPI
- Gitリポジトリ
- 社内文書
- ファイルサーバー
- チケット管理システム
- データベース
- 社内業務API
などと接続するAIエージェントが増えています。
ここまで来ると、モデルの出力が実際の操作につながります。モデルが誤った回答を一つ生成することと、本番クラウドを変更できるAIが誤った判断をすることでは、影響がまったく違います。
さらに外部から読み込んだWebページや文書にプロンプトインジェクションが仕込まれていた場合、AIが意図しない命令を受け取る可能性もあります。そこでモデル側の拒否や安全制約まで弱めてしまうと、防御の一層を減らすことになります。
制約の弱いAIほど、与える権限は小さくする。
これはかなり重要です。
企業で使うなら、最初にモデルの出自を確認する
open-weightのLLMは、自社環境へダウンロードして動かせることが大きなメリットです。一方で、同じモデルをベースにさまざまな派生版が公開されています。
- 元のモデル
- 量子化モデル
- Fine-tuning済みモデル
- Abliteration済みモデル
- 独自の安全調整を施したモデル
- 制約を意図的に弱めたモデル
見た目のモデル名だけでは、中身が同じとは限りません。
そこで重要になるのがModel Provenance、つまりモデルの出自と変更履歴です。
企業利用なら最低限、ベースモデルは何か、誰が変更したのか、どのような処理が加えられたか、安全調整は変更されているか、ライセンス上問題はないか、どのような評価が行われているかは把握しておきたいところです。
モデル配布サイトで人気があることと、機密情報を扱う業務システムで安全に使えることは別です。
Abliteration済みLLMを企業で扱う場合の主なリスク
危険な要求への回答が増える
拒否を弱める以上、本来であれば回答を控えていた危険性の高い要求にも応答しやすくなります。限られた研究者だけが利用する環境と、全社員が使える社内AIでは、必要な安全性は大きく異なります。
プロンプトインジェクションの影響が大きくなる
AIが外部のWebページやメール、文書を読み取る場合、その中にAI向けの悪意ある命令が埋め込まれている可能性があります。
モデルの安全制約を弱めている場合は、アプリケーション側でより強い対策が必要です。
機密情報と組み合わせたときの影響が大きい
AIが社内文書、顧客情報、ソースコード、認証情報などへアクセスできる場合、モデルの回答内容だけを見ても不十分です。
「何を読み取れるのか」「どこへ送信できるのか」「誰の権限で動いているのか」まで含めて管理する必要があります。
モデルを更新するたびに再評価が必要になる
ベースモデルや編集方法が変われば、以前と同じ安全性になるとは限りません。モデルを更新した場合は、通常のソフトウェアアップデートと同じ感覚ではなく、重要な振る舞いが変わっていないか再評価した方が安全です。
企業で確認したいLLMのセキュリティ対策
Abliteration済みモデルに限らず、open-weight LLMを業務で利用する場合は、モデル単体ではなくシステム全体を見ます。
| 確認項目 | 確認したい内容 |
|---|---|
| モデルの出自 | 提供元、ベースモデル、変更履歴、ライセンス |
| 安全性評価 | 危険な要求、過剰拒否、プロンプトインジェクションへの挙動 |
| アクセス制御 | 誰が、どの目的で利用できるか |
| データ保護 | 顧客情報、認証情報、機密文書を扱える範囲 |
| ログ | 誰が何を入力し、どのような回答を得たか |
| Tool権限 | API、コード実行、ファイル操作などの許可範囲 |
| ネットワーク | AIから接続可能な内部・外部システム |
| 人による承認 | 高リスクな処理を自動実行させない仕組み |
| セキュリティテスト | 想定外の使われ方を事前に確認しているか |
特にTool権限は慎重に設計したいところです。AIが「このコマンドを実行するとよい」と文章で回答することと、AI自身がそのコマンドを本番環境で実行できることの間には、非常に大きな差があります。
また、制約の弱いモデルを社内で利用する場合は、誰がどのような目的で使ったのかを後から確認できる状態も重要です。ただし、プロンプトそのものに顧客情報や社内情報が含まれる可能性があるため、単純に「全部ログへ保存すればよい」という話でもありません。
保存する情報、保管期間、閲覧できる担当者、マスキング対象など、ログ自体の機密性まで含めて設計する必要があります。
Abliterationが役立つ場面もある
ここまでリスクを中心に書きましたが、Abliterationそのものが悪い技術という意味ではありません。
セキュリティ研究では、安全調整済みのモデルが過剰に拒否してしまうことがあります。許可されたラボ環境でマルウェアを解析している、自社システムへのペネトレーションテストを行っている、CTFの問題を解析している。それでも内容に攻撃的な用語が含まれるだけで拒否されれば、研究支援ツールとしては使いづらくなります。
Abliterationの研究は、なぜモデルは拒否するのか、どこまで安全性を維持しながら過剰拒否を減らせるのかを理解するうえでも興味深いものです。
問題は、「拒否があるか、ないか」という二択で考えてしまうことです。本当に必要なのは、用途に合った制御です。
用途に応じてモデルと利用環境を分ける
一般社員向けのAIと、セキュリティ研究者が使う検証用AIでは、求められる性質が違います。
たとえば、一般社員向けには安全調整されたモデルを利用し、社内のセキュリティ分析では利用者とデータアクセスを限定した専用環境を用意する。ペネトレーションテストやRed Teamの研究では、隔離された検証環境で必要に応じて制約の弱いモデルを利用する、といった分け方が考えられます。
制約の弱いモデルを利用するなら、一般社員向けのチャットへそのまま置くのではなく、必要性が明確な環境に限定し、利用者・データ・ネットワーク・Tool権限を絞る方が現実的です。
モデル側の拒否機能だけにすべてを任せるのも危険です。逆に、モデル側の制約をすべてなくしてアプリケーション側だけで守ろうとするのも極端です。
モデル、アプリケーション、アクセス権、ネットワーク、人による承認。複数の防御を重ねる必要があります。
「答えないこと」もAIの性能として見る
LLMを比較すると、「どれだけ難しい質問に答えられるか」「どれだけコードを書けるか」「どのベンチマークで何点取ったか」といった能力に目が向きます。もちろん、それらも重要です。
ただ、企業で使うAIならもう一つ評価したいものがあります。
どこで止まれるか。
正当な業務を不必要に拒否するAIは使いづらい。一方で、明らかに危険な要求にも何でも答えてしまうAIは、企業システムでは扱いにくい。その間のバランスが重要です。
Abliterationは、LLMの拒否機能がモデル内部でどのように表現されているのかを考えるうえで、とても面白い技術です。同時に、「安全調整されたモデルを一度導入すれば、その安全性はずっと変わらない」とは限らないことも教えてくれます。
モデルは後から変更できます。だから企業側も、どのモデルを使っているのか、誰が変更したのか、何を拒否するのか、何にアクセスできるのか、問題が起きたとき止められるのかまで把握しておく必要があります。
何でも答えるAIが、必ずしも優れたAIではありません。
サイバーセキュリティでは、ときに「答えない」という振る舞いそのものが重要なセキュリティ機能になります。
投稿者プロフィール
-
Offensive Security Engineer
15年以上の実績を持つ国際的なホワイトハッカーで、日本を拠点に活動しています。「レッドチーム」分野に精通し、脆弱性診断や模擬攻撃の設計を多数手がけてきました。現在はCyberCrewの主要メンバーとして、サイバー攻撃の対応やセキュリティ教育を通じ、企業の安全なIT環境構築を支援しています。
主な保有資格：
● Certified Red Team Specialist（CyberWarFare Labs / EC-Council）
● CEH Master（EC-Council）
● OffSec Penetration Tester（Offensive Security）
