ローカルでオープンウェイトの LLM を動かしていると、安全アライメント（safety alignment）による過剰な拒否が用途の妨げになる場面に出くわします。創作支援やセキュリティ研究、社内ドメインに特化した検証など、本来は問題のない指示にまでモデルが「お答えできません」と応じてしまう、という悩みです。
この「脱検閲（decensor）」を行う手法として近年広まっているのが abliteration（アブリタレーション）です。ところが、いざ調べると abliterator・huihui-ai・ErisForge など複数のツールやモデルが乱立しており、「結局どれを使えばいいのか」「自分のローカルLLM 運用や研究に採用してよいのか」という判断で手が止まりがちです。
そこで注目を集めているのが、GitHub スター数 22,000 超の OSS「heretic」です。LLM の検閲を再学習なしで全自動除去するツールで、類似ツールとは「品質をどれだけ保てるか」という点で差別化を図っています。
本記事では、heretic が何をするツールなのか、技術的な仕組み、動作要件、そして abliterator や huihui-ai のモデルとの違いを整理します。ライセンスやメンテナンス状況といった採用判断に欠かせない観点まで含めて解説し、「自分のケースで採用すべきか」を判断できる状態を目指します。なお本記事は公式ドキュメントと README に基づくもので、ツールの実行・動作検証は行っていません。記載する数値はすべて公式ドキュメントの記載値です。
hereticとは｜LLMの検閲を全自動で除去するOSS
heretic は、transformer ベースの言語モデルから検閲（safety alignment による拒否挙動）を、高コストな再学習（post-training）なしで除去することを目的とした OSS です。リポジトリの説明文も「Fully automatic censorship removal for language models（言語モデルの完全自動な検閲除去）」と簡潔に役割を示しています（p-e-w/heretic（GitHub））。
hereticが解決する課題
オープンウェイトの LLM の多くは、有害な出力を避けるための安全アライメントが施されています。これ自体は重要な仕組みですが、しきい値が過剰だと「無害な指示まで拒否する」という副作用が生じます。ローカルで自由に検証したいエンジニアや研究者にとって、この過剰な拒否は実務上の障壁になります。
heretic はこの拒否挙動だけをモデルの重みから取り除くことを狙います。特徴的なのは「完全自動」である点で、開発者は transformer 内部の数学的な詳細を理解していなくても、コマンドラインプログラムを実行できれば使える、という設計思想を掲げています。
リポジトリの基本情報
採用検討の土台として、まずリポジトリの基本情報を押さえておきます。
| 項目 | 内容 |
|---|---|
| リポジトリ | p-e-w/heretic |
| 実装言語 | Python |
| ライセンス | AGPL-3.0 |
| スター数 | 22,415 |
| フォーク数 | 2,378 |
| 最終更新 | 2026-05-29 |
スター数が 22,000 を超えており、最終更新も執筆時点の前日（2026-05-29）と、活発にメンテナンスされていることがうかがえます。ライセンスが AGPL-3.0 である点は商用利用や配布の際に影響するため、のちほど注意点として詳しく取り上げます。
hereticの仕組み｜abliterationと自動最適化
heretic の中核は abliteration という技術と、それを自動で最適化する仕組みにあります。なぜ他ツールより品質を保てると主張できるのか、その理論的な根拠を見ていきます。
abliteration（拒否方向の除去）とは
abliteration は、モデル内部の「拒否方向（refusal direction）」を特定し、その方向の発現を抑制する手法です。基礎となったのは Arditi らの研究で、拒否挙動が単一の方向ベクトルによって媒介されることを示しました（Arditi et al., 2024）。
heretic では、各 transformer 層について、有害（harmful）なプロンプトと無害（harmless）なプロンプトを入力したときの残差ベクトルの差分（difference-of-means）から拒否方向を計算します。そして対応する重み行列（現状は attention の out-projection と MLP の down-projection）を、その拒否方向に対して直交化（orthogonalize）することで、行列乗算の結果に拒否方向が現れにくくします。ここでいう KL ダイバージェンスとは、簡単にいえば「元のモデルと比べて出力の確率分布がどれだけずれたか」を測る指標で、値が小さいほど元の能力を保てている、と読み替えられます。
hereticの独自性
README の「How Heretic works」では、既存のアブリタレーション実装に対する革新点が挙げられています（p-e-w/heretic（GitHub））。要点は次の3つです。
- 重みカーネルの柔軟な形状: 層ごとにアブレーションの強さ・位置を可変にし、自動最適化と組み合わせて「拒否抑制と品質のトレードオフ」を改善する。
- 拒否方向インデックスの浮動小数化: インデックスを整数ではなく浮動小数として扱い、近接する2つの拒否方向ベクトルを線形補間することで、より広い方向空間を探索する。
- コンポーネント別のパラメータ調整: MLP への介入は attention への介入よりモデルを損ないやすい、という著者の知見に基づき、attention と MLP で別々のパラメータを選ぶ。
Optunaによる全自動最適化
これらのパラメータを人手で調整するのは現実的ではありません。heretic はハイパーパラメータ最適化フレームワークの Optuna（Optuna 公式サイト）を用い、TPE（Tree-structured Parzen Estimator）ベースでパラメータを自動探索します。最適化の目的は、有害プロンプトへの「拒否数」と、無害プロンプトにおける元モデルからの「KL ダイバージェンス」を同時に最小化することです。
この「拒否を消しつつ、元モデルからのズレを最小化する」という二目的の最適化こそが、利用者が transformer 内部を理解していなくても品質の良い脱検閲モデルを得られる理由であり、後述する競合ツールとの差別化の核心でもあります。
hereticの使い方と動作要件
採用判断には「自分の環境で現実的に動かせるか」という実務的な視点が欠かせません。インストール方法と動作要件を整理します。なお、以下のコマンド・数値はすべて公式ドキュメントの記載に基づくもので、本記事では実行検証を行っていません。
インストールと基本実行
README では、PyPI パッケージ heretic-llm をインストールし、対象モデルを引数に渡すだけで実行できると示されています。
pip install -U heretic-llm
heretic Qwen/Qwen3-4B-Instruct-2507出典: p-e-w/heretic（GitHub README）
完全自動で動作するため基本的に設定は不要ですが、heretic --help で CLI オプションを確認でき、config.default.toml による設定ファイル制御も可能です。依存管理は uv にも対応しており、クローンしたリポジトリから uv run heretic で実行できます。
動作要件と処理時間・VRAM
動作要件として、Python 3.10 以上、PyTorch 2.2 以上が前提です。一部のモデル・構成ではより新しいバージョンが必要で、gpt-oss など MXFP4 量子化モデルは torch.accelerator を使うため PyTorch 2.6 以上が求められます。
処理時間について README は、RTX 3090・デフォルト設定で Qwen3-4B-Instruct-2507 を脱検閲するのに約20〜30分、と記載しています。VRAM 要件が厳しい場合は bitsandbytes による量子化に対応しており、設定を bnb_4bit にすることで VRAM 要件を大幅に削減できます。実行開始時にシステムをベンチマークして最適なバッチサイズを決める仕組みも備わっています。
ここで挙げた処理時間や VRAM はハードウェアやモデルサイズに強く依存する点に注意してください。手元の GPU やモデルが異なれば、当然この数値も変わります。処理が完了したモデルは、保存・Hugging Face へのアップロード・チャットでのテスト・標準ベンチの実行から選択できます。
研究向け機能
解釈可能性の研究向けには、追加依存を含む research extra が用意されています。
pip install -U heretic-llm[research]出典: p-e-w/heretic（GitHub README）
--plot-residuals で各層の残差ベクトルを PaCMAP 投影した散布図やアニメーションを生成したり、--print-residual-geometry で harmful/harmless 残差ベクトルの幾何的関係（コサイン類似度・L2 ノルム等）を表形式で出力したりできます。プロジェクトの背景や思想は公式サイトでも確認できます。
hereticと類似OSSの違い｜abliterator・huihui-ai・ErisForge
ここが本記事の中核です。abliteration を扱うツールやモデルは複数あり、heretic はそれらとどう違うのかを整理します。
類似OSS・手法の立ち位置
| ツール／手法 | 位置づけ |
|---|---|
| heretic（p-e-w） | 任意モデルを脱検閲する全自動ツール。Optuna でパラメータを自動最適化 |
| abliterator（FailSpy） | abliteration の初期実装の一つ。拒否方向の特定・適用は手動寄り |
| huihui-ai | アブリタレーション済みモデルを大量配布するプロバイダ。手動チューニングが中心 |
| ErisForge（Tsadoq） | abliteration を扱う別の OSS 実装 |
abliterator（FailSpy）は abliteration を世に広めた実装の一つですが、拒否方向の特定やスケールの調整は利用者の手作業に依存します。huihui-ai はツールというより「完成済みのアブリタレーション済みモデル」を配布する立ち位置で、すぐに使えるモデルが欲しい場合に向きます。ErisForge（Tsadoq） も abliteration を扱う別 OSS です。なお heretic の README によれば、heretic はこれらのコードを流用せずゼロから記述されたとされています。
比較表（自動化・品質最適化・対応範囲）
| 観点 | heretic | abliterator / 手動系 | huihui-ai（モデル配布） |
|---|---|---|---|
| パラメータ自動最適化 | あり（Optuna/TPE） | なし（手動調整） | 該当せず（モデル提供） |
| 品質（KL）への明示的最適化 | あり（拒否数と同時最小化） | 限定的 | 提供モデルに依存 |
| 任意モデルへの適用 | 可能 | 可能（要手作業） | 配布済みモデルに限定 |
| 対応アーキテクチャの広さ | dense / MoE / 一部ハイブリッド / マルチモーダル | 実装依存 | 配布ラインナップ依存 |
heretic の差別化ポイントは「自動パラメータ最適化の有無」と「品質への明示的な最適化」に集約されます。abliterator のような手動系は柔軟ですが調整の手間と知識を要し、huihui-ai は手軽な反面、配布済みモデル以外には適用できません。
READMEベンチ数値の読み方
heretic の README は、google/gemma-3-12b-it を対象にした比較表を掲載しています（p-e-w/heretic（GitHub README））。
| モデル | 拒否数（harmful 100問） | KL ダイバージェンス（harmless） |
|---|---|---|
| google/gemma-3-12b-it（オリジナル） | 97/100 | 0（定義上） |
| mlabonne/gemma-3-12b-it-abliterated-v2 | 3/100 | 1.04 |
| huihui-ai/gemma-3-12b-it-abliterated | 3/100 | 0.45 |
| p-e-w/gemma-3-12b-it-heretic（heretic製） | 3/100 | 0.16 |
拒否抑制レベル（3/100）は他のアブリタレーション手法と同等ですが、KL ダイバージェンスが 0.16 と最も低い、というのが README の主張です。KL が小さいほど元モデルの出力分布からのズレが小さい、つまり「拒否は消したまま、元の知能をより多く保てている」と読めます。
ただし、この数値の解釈には注意が必要です。README によればこのベンチは PyTorch 2.8・RTX 5090 という特定環境で計測されており、プラットフォームやハードウェアによって結果が変わる可能性があります。英語圏では aithinkerlab や nathan.sapwell など第三者によるベンチ比較も報告されていますが、計測条件によって傾向が異なるため、最終的には自分が使うモデルと環境で確認することが望ましいといえます。
採用前に知っておきたい注意点｜ライセンス・倫理・メンテナンス
機能面で魅力的でも、採用判断にはライセンス・倫理・メンテナンスといった前提条件の確認が欠かせません。
ライセンス（AGPL-3.0）と利用上の留意点
heretic は AGPL-3.0（GNU Affero General Public License v3.0）で公開されています（GNU ライセンス一覧）。AGPL-3.0 は強いコピーレフトを持つライセンスで、ソフトウェアを改変してネットワーク経由でサービス提供する場合にも、改変後のソースコードの開示義務が及ぶ点が GPL との大きな違いです。
このため、heretic 自体を組み込んだサービスを社外提供する、あるいは heretic を改変して配布する、といった用途では、AGPL-3.0 の義務が自社の要件と両立するかを事前に法務確認することをおすすめします。なお、heretic を使って生成したモデルそのものの扱いは元モデルのライセンスに従う点も別途確認が必要です。ライセンス要件が自社方針に合わない場合は、採用を見送る判断材料になります。
倫理・責任とサポート範囲の制約
検閲除去は、安全アライメントを意図的に外す行為です。脱検閲されたモデルが有害な出力を生成し得るリスクや、その利用に伴う責任は利用者側にあることを理解しておく必要があります。用途が研究・検証であっても、出力の取り扱いには慎重さが求められます。
技術的なサポート範囲にも制約があります。heretic はほとんどの dense モデル（多くのマルチモーダルモデルを含む）、複数の MoE アーキテクチャ、Qwen3.5 のような一部のハイブリッドモデルに対応しますが、純粋な state-space モデルや一部の研究用アーキテクチャは現時点では未対応です。対象にしたいモデルがこの未対応カテゴリに該当する場合、heretic では脱検閲できないため、別の手段を検討する必要があります。
メンテナンス状況
採用判断において、プロジェクトが今後も維持されるかは重要な観点です。heretic はスター数 22,415、フォーク数 2,378 と注目度が高く、最終更新も 2026-05-29 と直近で、活発に開発が続いています。コミュニティでは heretic を用いた脱検閲モデルが多数（Hugging Face 上で 3,000 以上）公開されており、エコシステムとしての広がりも見られます。一方でオープン Issue も一定数あり、対応アーキテクチャの拡充などは今後の開発に依存する点は留意しておきましょう。
まとめ｜hereticを採用すべきケース・見送るべきケース
最後に、ここまでの判断軸を整理します。
heretic の採用が向くのは、次のようなケースです。
- 任意のオープンウェイトモデルを、品質をできるだけ保ちつつ脱検閲したい
- transformer 内部の知識に頼らず、CLI だけで作業を完結させたい
- 自動最適化を回せる GPU リソース（VRAM・処理時間）を確保できる
- 対象モデルが dense / MoE / マルチモーダルなど対応アーキテクチャに含まれる
一方、次のようなケースでは見送りや別手段の検討が妥当です。
- 手早く脱検閲モデルを試したいだけ → huihui-ai などの配布済みアブリタレーション済みモデルの利用が早い
- 対象が純粋な state-space モデルなど未対応アーキテクチャ → 現時点では heretic で対応できない
- AGPL-3.0 のコピーレフト要件が自社の配布・サービス提供方針と両立しない
heretic は、abliterator のような手動系や huihui-ai の配布モデルと比べ、「任意モデルを自動で、かつ品質を保ちながら脱検閲できる」点が最大の強みです。abliteration 系ツールの選定に迷っているなら、まずは対応アーキテクチャ・ハードウェア要件・AGPL-3.0 の3点を自分の状況と照らし合わせ、合致するかを確認することが採用判断の第一歩になります。詳細な仕様や最新の対応状況は、p-e-w/heretic（GitHub）の README で確認できます。
