ローカルLLMの検閲なし（uncensored）モデル2026年10月版。日本語で使えるモデルのVRAM別一覧、アビリタレーションの仕組み、業務で使うための条件と決裁者への説明材料

「検閲なし（uncensored）モデル」は、ローカルLLMの検索でよく見かける言葉です。Hugging Faceには、モデル名に「uncensored」や「abliterated」と付いた改変版が数多く公開されています。通常のモデルが断るような質問にも答えるため、「過剰に断られて仕事にならない」「ChatGPTやClaudeでアカウントを止められるのが怖い」という人の受け皿として話題になります。

ただ、企業が業務で使うモデルとして見ると、検閲なしモデルは得られるものより抱えるものが大きい選択です。本記事では、まず日本語で使える検閲なしモデルの現状（2026年10月時点）をVRAM別に整理し、検閲なしモデルがどう作られるのか、性能にどんな副作用があるのか、ライセンスや社内統制の面で何が問題になるのかを解説します。そのうえで、現場の担当者が業務データを入れずに手元で試す手順と、その結果を決裁者に持っていって会社の構成にするための材料、ChatGPT・ClaudeのアカウントBANを避けたい場合のローカルLLMの位置づけ、過剰拒否への正しい対処をまとめます。

この記事の要点

• 検閲なしモデルは、安全調整で身につけた「断る挙動」を取り除いた改変モデルです。知識が増えるわけではなく、断らなくなるだけです
• 日本語特化モデル（Swallow系、llm-jp系、ELYZA系）の検閲なし版は公開されていません。日本語で実際に使えるのは、Qwen3.5〜3.8、Gemma 4、gpt-ossといった多言語モデルの改変版です（2026年10月26日時点）
• 作り方は主に2つあります。拒否を含む学習データを除いて再学習する方法と、モデル内部の「拒否の方向」を消すアビリタレーションです
• アビリタレーションは再学習なしで拒否を外せる一方、ベンチマーク上の性能低下が報告されており、追加学習で回復させるのが一般的です
• 企業利用では、不適切な出力、統制と説明責任、品質の副作用、出所の不透明さ、ライセンス、エージェント利用時の防御低下の6つのリスクがあります
• ChatGPTやClaudeのBANリスクを避けたいなら、ローカルLLMは有力な受け皿です。ただしBANリスクをなくすのは「自社で動かすこと」であり、検閲なしである必要はありません
• 現場の担当者が社用PCに勝手に入れればシャドーAIです。業務データを入れずに手元で比べた記録を決裁者に持っていき、会社の管理下のローカルLLMとして整えるのが近道です

「検閲なしモデル」とは

多くのLLMは、公開前に「安全調整」と呼ばれる追加学習を受けています。犯罪の手順、差別的な表現、性的な内容など、危険・不適切とされる要求には「お答えできません」と断るように調整されています。この拒否の挙動を取り除いたものが「検閲なしモデル」と呼ばれます。

「検閲」という言葉から、情報が削られたモデルを元に戻したもの、という印象を持たれがちですが、実態は違います。モデルが知っていることの量は変わりません。変わるのは「知っていても断る」という振る舞いだけです。

需要が実在するのは事実です。通常のモデルは、無害な質問まで断ることがあります。たとえば次のような場面です。

• 小説や脚本で、犯罪や暴力を描く場面の相談を断られる
• セキュリティ担当者が、自社システムの脆弱性の仕組みを確認しようとして断られる
• 医療や薬の質問で、一般的な情報なのに「専門家に相談してください」としか返ってこない
• 歴史や社会問題の議論で、どちらの立場の主張も整理してくれない

こうした「過剰拒否」への不満が、検閲なしモデルへの関心の出発点です。

日本語で使える検閲なしモデルの現状（2026年10月時点）

「ローカルLLM 検閲なし 日本語」で探す人がまず知りたいのは、日本語で実用になるモデルがあるかどうかです。Hugging FaceのAPIで2026年10月26日に確認した結果を先に書きます。

日本語特化モデルの検閲なし版は公開されていません。 Swallow系、llm-jp系、ELYZA系について「abliterated」「uncensored」の名前で検索しても、2024年のLlama 3世代の派生が1件見つかる程度で、現行世代の改変版はありません。日本語で使うなら、多言語モデルであるQwen3.5〜3.8、Gemma 4、gpt-ossの改変版が実質的な選択肢です。改変版は改変元の日本語性能をそのまま引き継ぐので、改変元そのものの日本語品質は『日本語で使えるローカルLLMおすすめ2026年10月版』の整理が当てはまります。

配布元は3系統

系統	モデル名の目印	特徴	配布ページの注意書き
huihui-ai	「Huihui-〇〇-abliterated」	アビリタレーション（後述）で拒否を除いた版を、Qwen・Gemma・gpt-ossの主要モデルについて継続的に公開。Ollama用のタグも用意されている	「安全性の厳密な最適化を経ていない」「本番や公開サービスでの直接利用は避ける」「出力を監視し人が確認する」と明記
HauhauCS	「〇〇-Uncensored-HauhauCS-Balanced / Aggressive」	Balanced（推奨）とAggressiveの2段階。自前の拒否ベンチマークで「拒否0/465件」と自己申告	手法は非公開。検証は配布者の自己申告のみ
Heretic系	「〇〇-heretic」	2025年公開の自動化ツールHereticで作られた版。拒否の数と、改変元からのずれ（KLダイバージェンス）を同時に最小化するパラメータを自動探索する	改変元からのずれを数値で示す点が特徴。ツール自体はAGPL-3.0

このほか、mradermacherやbartowskiといった量子化専門の配布者が、上記のGGUF版を再配布しています。モデル名に「abliterated」「uncensored」「heretic」が混在していても、元になった改変はこの3系統のどれかです。

VRAM別の候補

VRAM	改変元のモデル	配布例	ファイルサイズの目安	備考
〜8GB	Qwen3.5-4B、Gemma 4 E4B	huihui-aiのQwen3.5-4B abliterated（GGUFはmradermacher）、HauhauCSのGemma-4-E4B-Uncensored	3〜5GB	軽量タスク向け。拒否の確認にはなるが、品質比較の基準には小さすぎる
8〜12GB	Qwen3.5-9B、Gemma 4 12B	Huihui-Qwen3.5-9B-abliterated-GGUF、HauhauCSのGemma4-12B-QAT-Uncensored-Balanced（Q4_K_M 6.9GB）	6〜7GB	個人のPCで試す定番。Gemma 4 12BはQAT（量子化を前提に学習済み）の重みが元なので4bitでの劣化が小さい
16GB	gpt-oss-20B	Huihui-gpt-oss-20b-mxfp4-abliterated-v2	約13GB	Ollamaは ollama run huihui_ai/gpt-oss-abliterated。推論の強さと英語寄りの傾向は改変元と同じ
24GB	Qwen3.8-27B、Qwen3.6-35B-A3B、Gemma 4 26B-A4B、Gemma 4 31B	Huihui-Qwen3.8-27B-abliterated-GGUF（Q4_K_M 16.6GB）、Huihui-Qwen3.6-35B-A3B-abliterated-MTP-GGUF、Huihui-gemma-4-26B-A4B-it-qat-abliterated-GGUF（Q4_0 16.8GB）、Gemma 4 31B abliterated（複数の配布者）	16〜21GB	業務文書で品質を比べるならこの帯。Qwen3.8-27Bの改変版は直近30日で約255万ダウンロードと、検閲なしモデルの中で最も使われている
48GB〜	gpt-oss-120B、Qwen3.5-122B-A10B	mradermacherのgpt-oss-120b-abliterated-GGUF、HauhauCSのQwen3.5-122B-A10B-Uncensored	60GB以上	Mac Studioや複数GPUの領域。個人の検証ではなく会社の機材の話になる

ファイルサイズは配布ページの記載を転記したもので、未記載のものは「パラメータ数×0.6GB」の4bit換算で見積もっています。実際に動かすには、これにコンテキスト分のメモリが乗ります。

ここで3つ注意があります。

1. 配布者の注意書きは「本番で使うな」です。 huihui-aiのモデルカードは「研究、テスト、管理された環境」での利用を勧め、本番や公開サービスでの直接利用を避けるよう書いています。配布者自身が業務利用を想定していない、という事実は社内で共有しておくべきです
2. ライセンス表記は配布ページを鵜呑みにしない。 huihui-aiのGemma 4改変版は配布ページのメタデータが「apache-2.0」ですが、Googleの規約は派生モデルにもGemma規約と禁止用途ポリシーを適用すると定めています（後述）。Qwen系はApache 2.0なので用途制限はありませんが、法令と社内ルールは変わらず適用されます
3. 日本語品質は改変元と並べて自分で確かめる。 改変と回復の学習は英語の質問セットで行われるのが普通で、日本語での品質差を公開している配布者は見当たりません。確かめ方は後半の「現場で試すときの手順」で扱います

検閲なしモデルの作り方は主に2つ

検閲なしモデルの作り方は、大きく2つに分かれます。プロンプトの工夫で一時的に拒否をすり抜ける「ジェイルブレイク」とは別物で、こちらはモデルそのものを作り替える方法です。

方法	何をするか	必要なもの	特徴
拒否データを除いて再学習	学習用の指示データから拒否や偏った回答を取り除き、元のモデル（ベースモデル）を学習し直す	学習データと学習用のGPU環境	2023年ごろから広まった方法。手間とコストが大きい
アビリタレーション	モデル内部で拒否を引き起こしている「方向」を特定し、重みからその成分を消す	少量の質問セットと推論できる環境	2024年に広まった方法。再学習なしで短時間に作れる

方法1: 拒否データを除いて再学習する

初期の検閲なしモデルは、この方法で作られました。オープンなチャットモデルの多くは、ChatGPTなどの出力から作った指示データで学習されており、その中にChatGPT由来の拒否や偏りが含まれていました。開発者のEric Hartfordは、このデータセットから拒否や偏った回答を取り除き、残ったデータでベースモデルを学習し直す方法を公開しました。

Hartfordは、文化や国ごとに異なる価値観を反映したモデルを作るには、まず調整されていない土台が必要だという立場を取っています。同時に「出力をどう使うかの責任は利用者にある」と明記しています。検閲なしモデルは、責任を利用者側に移すという前提で作られている、という点は押さえておくべきです。

方法2: アビリタレーション（abliteration）

現在よく見かける「abliterated」と付いたモデルは、この方法で作られています。土台になっているのは、2024年6月に公開された研究「Refusal in Language Models Is Mediated by a Single Direction」です。この研究は、最大72Bパラメータまでの13のオープンなチャットモデルで、拒否の挙動がモデル内部のたった1つの「方向」で制御されていることを示しました。その方向を取り除くと有害な指示も断らなくなり、逆に加えると無害な指示まで断るようになります。

この知見を実用化した手順は、Maxime LabonneによるHugging Faceの解説で広く知られるようになりました。手順は次の3段階です。

1. データを集める: 有害な指示と無害な指示をそれぞれモデルに入力し、内部の活性（各層での中間的な計算結果）を記録する
2. 差を取る: 有害な指示と無害な指示の活性の平均の差を層ごとに計算し、「拒否の方向」の候補にする
3. 選んで消す: 候補の中から最もよく効くものを選び、モデルの重みからその方向の成分を取り除く

技術的には「拒否の回路を弱める」操作です。再学習が要らないので、手元のGPUで短時間に作れてしまいます。研究の著者たちは、この結果から現在の安全調整は壊れやすいと指摘しています。公開されたモデルの安全性は、重みを手にした人がいくらでも外せる、ということでもあります。

2025年には、この手順を自動化するツールHereticが公開されました。層ごとに消す強さを変え、拒否の数と改変元からのずれ（KLダイバージェンス）を同時に最小化するパラメータを自動で探索します。ツールの説明では、Gemma 3 12Bで有害な指示100件中97件だった拒否が3件に減り、無害な指示に対するずれは他の改変版（0.45、1.04）より小さい0.16だったとしています。「どれだけ壊したか」を数値で示す改変版が増えたのはこのためです。

アビリタレーションの副作用：性能は落ちる

「拒否だけを外して、ほかは元のまま」とはいきません。Labonneの解説では、アビリタレーションを施したモデルは、元のモデルと比べてすべてのベンチマークで性能が下がったと報告されています。そのため、追加学習（DPO）で性能を回復させる工程を挟んでおり、多くは回復した一方、数学の問題（GSM8K）は改善しなかったとしています。

元の研究は、他の能力への影響は小さいと報告しています。どちらが正しいというより、モデルの種類や消し方、評価の仕方で結果が変わると考えるのが妥当です。業務で見るべきなのは、次のような点です。

• 改変した人が、どのベンチマークで改変前後を比較したかを公開しているか
• 自社の業務（要約、文書作成、帳票の読み取りなど）で、改変前のモデルと出力の質を比べたか
• 日本語での品質を確かめたか（改変や回復の学習は英語データで行われることが多い）

なぜ検閲なしモデルが求められるのか

検閲なしモデルを探す動機は、大きく3つに分かれます。

動機	具体例	本当に検閲なしが必要か
過剰拒否への不満	創作、セキュリティ、医療・法務の一般的な質問を断られる	多くはプロンプトやモデル選びで解決できる
クラウドAIのアカウント停止への不安	正当な質問が違反と判定され、ChatGPTやClaudeのアカウントを失う	ローカルで動かせば解決し、検閲なしは不要
通常のモデルが断る内容を出させたい	違法・有害な内容の生成	企業として扱うべきではない

業務で問題になるのは、1つ目と2つ目です。どちらも、検閲なしモデルでなければ解決できない問題ではありません。2つ目のアカウント停止は、2026年に入ってから特に関心が高まっているので、次の節で詳しく扱います。

ChatGPT・ClaudeのBANリスクとローカルLLM

2026年には、ChatGPTやClaudeのアカウントが突然停止（BAN）されたという報告がX上で目立つようになりました。亡くなった知人が遺したiPadのロック解除方法を尋ねたらサイバー犯罪と判定された、SF小説の登場人物を説明したら警告なしに停止された、といったケースです。Anthropicは2026年1〜6月に1,140万件のアカウントを停止し、異議申し立て39.8万件のうち取り消しは4.2万件だったと公表しています。申し立てが通るのは1割程度です。停止の7パターンと業務の備えは『ChatGPT・ClaudeのアカウントBAN事例2026』で整理しています。

クラウドのAIサービスでは、入力した内容を事業者が利用ポリシーに照らして判定し、違反とみなせばアカウントごと止めます。止まると、会話履歴も、業務の手順を覚えさせたプロジェクトも使えなくなります。正当な目的であっても、文面が禁止事項に近ければ自動判定で違反とみなされることがあります。

一方、自社のPCやサーバーで動かすローカルLLMには、アカウントも事業者による判定もありません。外部の判断で業務が止まることはなく、入力したデータも社外に出ません。BANのリスクを避けたい業務の受け皿として、ローカルLLMは有力な選択肢です。

ここで押さえておきたいのは、**BANのリスクをなくすのは「検閲なし」ではなく「自社で動かすこと」**だという点です。

比較	クラウドAI（ChatGPT・Claude）	ローカルLLM（通常モデル）	ローカルLLM（検閲なしモデル）
アカウント停止	あり	なし	なし
データの社外送信	あり	なし	なし
過剰な拒否	あり	モデルによる	少ない
不適切な出力のリスク	低い	低い	高い
出所・品質の保証	事業者が保証	公式配布なら明確	有志の改変で不透明
性能	最上位	モデルと機材による	改変元より下がることがある

通常のローカルLLMでも、アカウント停止とデータ送信の心配はなくなります。セキュリティ診断、医療、法務、創作など、正当な業務なのにクラウドAIで違反と判定されやすい分野でも、まずは公式配布の通常モデルで足りるかを試すのが順番です。ローカルの通常モデルは、クラウドAIのように入力を監視して止める仕組みを持たないので、断られた場合もプロンプトやモデルの選び直しで対処できます。検閲なしモデルに替えて得られるのは「断られにくさ」だけで、その代わりに次の節のリスクを抱え込みます。

また、ローカルLLMにはアカウント停止がないというだけで、何をしてもよいわけではありません。法令やモデルのライセンス、社内ルールは変わらず適用されます。クラウドでBANされるような使い方をローカルに移すのではなく、正当な業務が外部の判定で止まらないようにするために使う、という位置づけが企業利用では現実的です。

企業利用での6つのリスク

検閲なしモデルを業務で使う場合のリスクは、次の6つです。

1. 不適切な出力

拒否が外れている分、差別的な表現、危険な手順、事実に反する断定などを出しやすくなります。社員がそのまま社外向けの文書やメールに使えば、会社の名前で問題のある内容を出すことになります。顧客対応のチャットボットや社外公開のサービスに使うのは、まず避けるべきです。

2. 統制と説明責任

生成物が問題を起こしたとき、「拒否を外したモデルをわざわざ選んで使っていた」という事実は、会社にとって説明の難しい材料になります。通常のモデルで起きた事故なら「想定外の出力だった」と説明できても、検閲なしモデルでは「安全装置を外す判断をした」ことになるからです。

3. 品質の副作用

前の節のとおり、拒否の挙動を編集した結果、ほかの応答品質が下がることがあります。業務で効くのは「断らないこと」より「正確に答えること」です。品質が下がったモデルで要約や文書作成をすれば、確認の手間が増えます。

4. 出所の不透明さ

検閲なしモデルの多くは、個人や有志が改変して公開したものです。改変の手順や評価結果が公開されていないもの、配布元の実態が分からないものも少なくありません。モデルファイルの改ざんや、悪意のある処理を含むファイル形式といった供給網の論点は、『ローカルLLMは本当に安全か。閉域でも残る7つのセキュリティリスクと対策』で扱っています。OWASPのLLMアプリケーション向けTop 10（2025年版）でも、供給網は主要なリスクの1つに挙げられています。

5. ライセンス

改変したモデルにも、元のモデルのライセンスが引き継がれます。たとえばGoogleのGemmaの利用規約は、改変版や派生モデル（Model Derivatives）も対象に含め、禁止用途ポリシーに沿って使うことを求めています。拒否を外しても、ライセンス上の禁止用途がなくなるわけではありません。Apache 2.0のように用途の制限を設けないライセンスのモデルもありますが、その場合も法令と社内ルールは適用されます。

6. エージェント・RAGでの防御低下

ローカルLLMを、社内文書の検索（RAG）や、ツールを操作するエージェントに組み込む場合は、さらに注意が必要です。文書やWebページに紛れ込んだ悪意のある指示（プロンプトインジェクション）に対し、通常のモデルなら「その操作はできません」と断る場面でも、検閲なしモデルはそのまま従う可能性が高まると考えられます。拒否の挙動は、利用者の要求を断るためだけでなく、システムの最後の防御線としても働いているからです。

過剰拒否への正しい対処

「通常モデルの拒否が業務の邪魔」なら、検閲なしに走る前に次の順で試してください。多くはモデルを改変しなくても解決します。

1. 断られた状況を記録する: どの質問を、どのモデルに、どう聞いたら断られたかを残す。再現できない拒否は、聞き方の問題であることが多い
2. 目的と立場を明示する: 「当社の情報システム部門として、自社サーバーの設定を点検するために」のように、正当な業務であることを具体的に書く
3. システムプロンプトで役割と範囲を決める: 社内ツールとして提供するなら、「社内の〇〇業務を支援するアシスタント。対象は△△に関する質問」のように、役割と扱う範囲をあらかじめ設定する
4. モデルを選び直す: 同じ規模でも、モデルによって拒否の傾向はかなり違う。用途に合った、拒否の設計が適切なモデルを選ぶ（日本語で使うモデルの選び方は『日本語で使えるローカルLLMおすすめ2026。VRAM別の現実解』を参照）
5. クラウドで断られる業務はローカルに移す: クラウドAIで違反と判定されやすい業務は、BANのリスクも含めて、社内のローカルLLMで扱う

ここまでで解決しない業務が残った場合に初めて、検閲なしモデルを検討する余地が出てきます。

現場で試すときの手順（業務データを入れない）

検閲なしモデルを探している人の多くは、断られて困っている現場の担当者です。試すこと自体は止めませんが、やり方を間違えると「会社が把握していないAI利用」、つまりシャドーAIになります。次の線を守れば、試した結果はそのまま会社への提案材料になります。

1. 私物PCか検証用PCで、業務データ・個人情報を入れずに試す。 社用PCへの導入や、顧客情報・社内文書の入力は、情報システム部門の承認前にはしない
2. 改変元（公式配布）と改変版の両方を入れる。 LM StudioかOllamaで、同じサイズ帯の公式モデルと改変版を並べる。比べる相手がないと「断られなくなった」以外のことが分からない
3. 断られたプロンプトを、両方に同じ条件で投げる。 業務で実際に断られた聞き方を、個人情報を伏せて最低10件。システムプロンプトと温度は揃える
4. 通常業務のプロンプトも同数投げる。 要約、翻訳、議事録、表の読み取りなど、断られていない普段の仕事を10件。ここで品質が落ちていれば、拒否が解けても業務では使えない
5. 結果を表に残す。 拒否が解けた件数、普段の仕事で品質が落ちた件数、使ったモデルのファイル名とハッシュ、改変元のライセンス。この表が次の節の材料になります

4の「通常業務での品質差」が出なければ、2の時点で公式モデルで足りていた可能性が高いので、提案は「検閲なしモデルを入れたい」ではなく「ローカルLLMを会社として用意したい」になります。

社内で検閲なしモデルを使う場合の判断基準

それでも検閲なしモデルが必要だと判断した場合は、少なくとも次の条件を満たす形に限定してください。

項目	条件
用途	社内の限られた業務に限る。顧客対応や社外公開のサービスには使わない
利用者	用途を理解した担当者に限定し、全社には開放しない
出力の扱い	出力をそのまま社外に出さず、人が必ず確認する
組み込み	RAGやエージェントなど、外部の文書や操作につながる構成には組み込まない
配布元	改変の手順と評価結果が公開されたものを選び、ファイルのハッシュを記録する
ライセンス	元のモデルのライセンスと禁止用途を確認し、記録に残す
品質	改変前のモデルと、自社の業務で出力を比べてから採用する
記録	入力と出力のログを残し、誰がいつ何に使ったかを追えるようにする
承認	情報システム部門や管理者の承認を経て導入する

これらを満たせないなら、通常のモデルで運用するほうが安全です。

決裁者に持っていく材料（現場の検証を会社の構成にする）

前の表の9項目は、現場の担当者が1人で満たせるものではありません。承認、記録、利用者の限定、配布元の確認はいずれも会社の仕組みの話です。検閲なしモデルを業務で使いたいなら、担当者の手元で終わらせず、決裁権を持つ人に次の3つを持っていくのが近道です。

持っていくもの	中身	決裁者が判断できること
1. 止まっている業務の一覧	どの業務が、週に何回、クラウドAIや公式モデルに断られて止まっているか。1回あたり何分の手戻りか	放置したときの損失の大きさ
2. 比較の記録	前の節で残した表。公式モデルと改変版で、拒否が解けた件数と普段の仕事の品質差	検閲なしモデルが本当に必要か、公式モデルのローカル運用で足りるか
3. 会社として整える条件と費用の規模	判断基準の9項目と、必要な機材・期間。実現性の検証なら2週間30万円の段階設計、機材は買う前に借りて確かめる選択肢がある	いくらで、いつまでに、何が分かるか

提案の形は「検閲なしモデルを入れたい」ではなく、「クラウドAIで断られる・止められる業務を、会社の管理下のローカルLLMで扱いたい」にします。検閲なしモデルはその中の1オプションで、2の記録で必要性が示せた場合だけ、利用者と用途を限定して組み込む、という順番です。この形にすると、決裁者が見るのは「安全装置を外す判断」ではなく「業務を止めない構成への投資」になり、承認の論点が変わります。

稟議や上申の文面にするなら、次の3行に数字を入れれば足ります。

対象業務: 〇〇（週〇件。断られると1件あたり〇分の手戻り） 検証結果: 公式モデル△△では〇件中〇件が拒否。改変版では〇件が解消し、通常業務の品質差は〇件 提案: 社内ローカルLLM環境（機材〇〇、概算〇〇円、検証期間〇週間）を用意し、改変版は利用者を限定して運用。承認と記録の仕組みは別紙のとおり

機材をどう用意するか、どの段階で何を検証するかの設計は、ローカルLLM導入支援と実機の貸出による2週間検証で支援しています。現場の担当者からの「上に説明する材料がほしい」という段階の相談も受けています。

まとめ

• 検閲なしモデルは、安全調整で身につけた拒否の挙動を取り除いた改変モデル。知識は増えず、断らなくなるだけ
• 日本語特化モデルの検閲なし版は公開されておらず、日本語で使えるのはQwen3.5〜3.8、Gemma 4、gpt-ossの改変版。配布元はhuihui-ai、HauhauCS、Heretic系の3系統で、配布者自身が本番利用を避けるよう書いている
• 作り方は、拒否データを除いた再学習と、内部の「拒否の方向」を消すアビリタレーションの2つ。後者は短時間で作れる一方、性能低下が報告されている
• 企業利用では、不適切な出力、統制と説明責任、品質の副作用、出所の不透明さ、ライセンス、エージェント利用時の防御低下の6つのリスクがある
• ChatGPTやClaudeのBANリスクを避けたいなら、ローカルLLMは有力な受け皿。ただしBANリスクをなくすのは「自社で動かすこと」で、検閲なしである必要はない
• 過剰拒否は、目的の明示、システムプロンプト、モデルの選び直しで対処できることが多い。それでも必要な場合は、用途と利用者を限定し、記録と承認の仕組みを整えて使う
• 現場で試すなら、業務データを入れずに公式モデルと改変版を並べて比べ、記録を残す。その記録と、止まっている業務の一覧、整える条件と費用の規模を決裁者に持っていき、「業務を止めない構成への投資」として会社の管理下に置く

よくある質問

検閲なしモデルは違法ですか？

モデルを使うこと自体が直ちに違法になるわけではありません。ただし、元のモデルのライセンスが禁止用途を定めている場合は改変版にも適用され、生成した内容の扱いには通常どおり法令が適用されます。違法・有害な内容を生成すれば、責任は使った人と会社に生じます。

ローカルLLMならChatGPTやClaudeのようにアカウントを停止されることはありませんか？

ありません。自社のPCやサーバーで動かすローカルLLMには、アカウントも事業者による入力内容の判定もないため、外部の判断で業務が止まることはありません。ただし、これは通常のローカルLLMでも同じです。アカウント停止を避けるために検閲なしモデルを選ぶ必要はありません。

アビリタレーションをすると性能は落ちますか？

落ちることがあります。Hugging Faceで広く参照されている解説では、アビリタレーション後のモデルがすべてのベンチマークで改変前を下回り、追加学習で回復させたと報告されています。元の研究は他の能力への影響は小さいとしていますが、モデルや評価方法で結果は変わります。業務で使うなら、自社の業務で改変前と出力を比べて確かめてください。

通常のモデルが断る質問に答えさせるにはどうすればよいですか？

まず、目的と立場を具体的に書き、正当な業務であることを明示します。社内ツールとして提供する場合は、システムプロンプトで役割と扱う範囲を決めておきます。それでも断られる場合は、拒否の傾向が異なる別のモデルを試してください。過剰拒否の多くは、モデルを改変しなくても運用で緩和できます。

会社で検閲なしモデルを使ってもよいですか？

顧客対応や社外向けのサービスには勧められません。社内の限られた業務で使う場合も、利用者の限定、出力の人による確認、ログの保存、配布元とライセンスの確認、管理者の承認を条件にするべきです。RAGやエージェントのように外部の文書や操作につながる構成には組み込まないでください。

日本語に特化した検閲なしモデルはありますか？

2026年10月26日時点では公開されていません。Swallow系、llm-jp系、ELYZA系の現行世代に「abliterated」「uncensored」の改変版はなく、日本語で使えるのはQwen3.5〜3.8、Gemma 4、gpt-ossといった多言語モデルの改変版です。改変版の日本語性能は改変元に準じるので、改変元の日本語品質を基準に選び、改変後の品質差は自分で確かめてください。

現場の担当者が個人で検閲なしモデルを試してもよいですか？

私物PCや検証用PCで、業務データや個人情報を入れずに試す範囲なら問題になりにくいです。社用PCに入れて業務データを扱うのは、会社が把握していないAI利用（シャドーAI）になります。試すなら公式モデルと改変版を並べて記録を残し、その記録と止まっている業務の一覧を決裁者に持っていって、会社の管理下のローカルLLMとして整えるのが現実的です。

主な参考資料: Arditi et al.「Refusal in Language Models Is Mediated by a Single Direction」、Maxime Labonne「Uncensor any LLM with abliteration」、Eric Hartford「Uncensored Models」、Google「Gemma Terms of Use」、Anthropic Transparency Hub、OWASP Top 10 for LLM Applications 2025、huihui-ai Huihui-Qwen3.8-27B-abliterated-GGUF、HauhauCS Gemma4-12B-QAT-Uncensored-HauhauCS-Balanced、p-e-w/heretic、『オープンLLMライセンス早見表』

TodoONadaでは、業務に合ったモデルの選定から、クラウドAIのアカウント停止に左右されない社内のローカルLLM環境の構築、利用ルールと記録の仕組みづくりまでを支援しています。「クラウドAIで断られる・止められる業務を社内で扱いたい」という段階のご相談も歓迎します。

---

この記事に関連するサービス

TodoONada株式会社では、機密データを外部に出さないローカルLLMの導入支援を行っています。

• ローカルLLM導入支援 — GPUサーバーでの本格構成。モデル選定からRAG構築・運用まで
• Mac ローカルLLM導入支援 — GPUサーバー不要、Mac 1台からのスモールスタート
• ローカルLLM実現性検証（機材貸出） — DGX Spark・Macを2週間借りて、買う前に実機で確かめる
• 全社AI導入支援 — 現場のシャドーAIを公式ルートに吸収する設計

導入・開発のご相談はお問い合わせからお気軽にどうぞ。検討段階のご相談も歓迎です。