OrcaRouterのGLM-5.3-Flash無検閲化版を評価する：重要なのは拒否率より再現性
要約: OrcaRouterは、GLM-5.3-Flash（総パラメータ数3,200億、アクティブパラメータ180億のMoEモデル）の無検閲化ウェイトを2段階で公開しました。2026年8月29日にネイティブblock-FP8版、8月31日にNVIDIA GPU向けNVFP4版をリリースし、現在はGGUFとMLXへの変換版も利用できます。ベンダー報告では、MaliciousInstructの拒否率が96%から11%に低下しましたが、ゼロにはなっていません。
最も重要なのは検閲解除そのものではありません。OrcaRouterは、GLM-5.3-Flashのアライメントの一部が単一の線形な拒否方向では説明できないと述べています。これは、Z.aiの安全トレーニングが、従来この手法の対象となったモデルより構造的に深い可能性を示します。
無検閲化は、いまや一般的な手法です。オープンウェイトモデルから拒否に関連する内部方向を特定し、ウェイトを編集して公開します。ただし、今回のリリースはモデルの出力内容ではなく、アライメントがモデル内部でどう表現されるかという点で注目に値します。
実際にリリースされたもの
2日間隔で、次のフォーマットが公開されました。
- Block-FP8（8月29日）：元の精度を維持したリファレンス版。ベースモデルと修正版の間に再量子化処理はありません。
- NVFP4（8月31日）：NVIDIAの4ビット浮動小数点形式を使い、フットプリント削減と推論高速化を狙った版。
- GGUF：llama.cppで利用するための版。
- MLX：Apple Silicon向けの版。
GLM-5.3-Flashの概要は「GLM-5.3-Flashとは何か」と「GLM-5.3-FlashとGLM-5.3の比較」で解説しています。前者の投稿は、その後200万回以上閲覧されました。
2026年8月31日：NVFP4
2026年9月1日時点で、Hugging FaceにはGLM-5.3-Flash-Uncensored-GGUFとGLM-5.3-Flash-Uncensored-MLXが存在します。確認時点のダウンロード数は、GGUFとMLXがそれぞれ0回、NVFP4が5回、元のFP8版が1,541回でした。注目は集まっていますが、成果物の利用はまだ始まったばかりです。
これは単発のリリースではなく、OrcaRouterのモデルラインの一部です。同じ組織は、FP8版だけで30万回以上ダウンロードされたQwen3.8-27B、Qwen3.8-Flash-Next、Gemma-4-26Bの無検閲化版もホストしています。
ウェイトはMITライセンスで、ベースモデルはzai-org/GLM-5.3-Flashです。モデルカードには、無検閲化済み、ビジョン言語、MoE、関数呼び出し対応と記載されています。ベースモデルのマルチモーダル機能とツール利用機能も維持されています。
「LoRAなし、ジェイルブレイクプロンプトなし」の意味
この表現は、次の3つを区別するために重要です。
- ジェイルブレイクプロンプト：推論時にプロンプトで安全トレーニングを回避します。脆弱で、パッチで無効化されやすく、毎回コンテキストコストが発生します。
- LoRAアダプター：ロード時に追加ウェイトを重ねます。ベースモデルは変更されず、アダプターは取り外し可能です。
- 無検閲化：拒否動作に関係する内部活性化方向を特定し、ウェイト自体を編集します。追加で取り付けるものはなく、実行時に抑制する処理でもありません。
したがって、無検閲化モデルはアダプターやプロンプトを監査するだけでは不十分です。出所が重要な環境では、実際に使用するチェックポイントの系統、ハッシュ、取得元を確認する必要があります。モデルの利用制限については「AIエージェントのガードレール」も参照してください。
拒否率の数値
以下はOrcaRouterによる自己報告値です。執筆時点で、独立した再現検証はありません。
| ベンチマーク | ベースモデル | 無検閲化後 |
|---|---|---|
| MaliciousInstruct | 96% | 11% |
| JailbreakBench | 93% | 12% |
| AdvBench | 97% | 15% |
| HarmBench | 93% | 18% |
| XSTest（良性過剰拒否） | 2.4% | 0.4% |
XSTestは、危険そうな単語を含む無害なリクエストまで拒否する「過剰拒否」を測定します。例えば、パスワードリセットのデバッグ、所有するインフラのポートスキャナー作成、脅威レポートの要約などです。
2.4%から0.4%への低下は、開発者が日常的に実感しやすい改善です。一方、最初の4項目は有害リクエストに対する拒否率であり、モデルの生産性や安全性を直接示す指標ではありません。ライセンスと現地法の確認も必要です。
実際に得られる利点と限界
良性の作業を拒否しにくい
最大の実用的メリットは、正当なセキュリティ作業や開発作業を誤って拒否しにくくなることです。再試行やプロンプト修正の回数を減らせます。
リクエストごとの回避策が不要
プロンプトで拒否を回避する方法は、コンテキストコストが増え、結果が不安定で、プロバイダー側の変更で動かなくなります。ウェイトレベルの変更は成果物に固定されるため、リクエスト間で挙動が安定します。
デプロイを自分で管理できる
MITライセンス、セルフホスト、特定チェックポイントへの固定が可能です。プロンプトやドキュメントを自社インフラ内に置けるため、外部プロバイダーのフィルター変更でワークフローが壊れるリスクを抑えられます。関連情報は「GLM-5.3のオープンウェイトをセルフホストする」にまとめています。
マルチモーダルとツール利用を維持する
モデルカードにはビジョン言語モデルと関数呼び出し対応が記載されています。テキスト生成だけでなく、エージェント用途で評価する場合にも重要です。
ただし、無検閲化は能力向上ではありません。これは行動の編集です。公開研究では、推論、コーディング、ビジョンなどの汎用性能に何らかのコストが生じるケースがあります。今回の発表では、ベースモデルと比較した性能低下は報告されていません。
つまり、拒否率の低下と引き換えに、未測定の性能低下と、フィルタリングを自社で担うコストを受け入れることになります。
最も興味深い点：拒否率がゼロにならない
4つの有害性ベンチマークで、拒否率は0〜2%ではなく11〜18%に残りました。
OrcaRouterの解釈は、GLM-5.3-Flashのアライメントの一部が単一の線形な拒否方向では説明できないというものです。標準的な無検閲化のメンタルモデルでは、拒否は活性化空間内のほぼ単一方向であり、その方向を削除すれば挙動が崩れると考えます。
しかし、この手法で96%から11%まで低下したところで止まるなら、少なくともこのモデルでは次の可能性があります。
- 拒否メカニズムが複数の方向や層に分散している。
- アライメントの一部が単純な線形編集では除去できない。
- OrcaRouterの実装が十分に性能を引き出せていない。
現時点では、どれが正しいかは分かりません。また、残る11〜18%の拒否率を安全機能として扱うべきでもありません。有害リクエストの15%だけを拒否するモデルは、安全なモデルではなく、挙動を予測しにくいモデルです。
それでも、技術の限界をリリース時点で明示したことには研究上の価値があります。独立した再現検証が行われれば、チェックポイントそのものよりも、GLM-5.3-Flashのアライメント構造について得られる知見の方が重要になるかもしれません。
検証が必要な主張
「Claude Opus 4.8レベルの知能」
後続投稿では、このモデルがそのレベルの知能で防御側を支援すると主張されています。しかし、ベンチマークや比較条件は示されておらず、現在のOpus世代との比較でもありません。マーケティング上の表現として扱い、重要な用途では自分の評価を実施してください。
拒否率は能力の代理指標ではない
拒否率が低いことは、高い推論能力やコーディング能力を意味しません。無検閲化による性能変化は、ベースモデルとのベンチマークで確認する必要があります。未変更モデルの価格とAPI情報は「GLM-5.3-Flashの価格設定」と「GLM-5.3-Flash APIガイド」を参照してください。
実行方法とハードウェア
総パラメータ数は3,200億です。アクティブパラメータが180億でも、一般的なノートパソコン向けのモデルではありません。
- Block-FP8：データセンターGPU向けのリファレンス成果物。
- NVFP4：精度とのトレードオフでフットプリントを削減する、NVIDIAのシングルノード向けパス。
- GGUF：llama.cpp向け。ハイエンドワークステーションで積極的な量子化を使う場合の選択肢。
- MLX：Apple Silicon向け。ただし、このモデルサイズでは非常に大きなユニファイドメモリが必要です。
セルフホストの手順は「GLM-5.3-Flashをローカルで実行する」と「GLM-5.3のオープンウェイトをセルフホストする」が直接参考になります。
関連する比較として、「無検閲LLMの調査」、「制限なしLLMの考察」、「DeepSeek R1の無検閲リリース」も利用できます。
評価はAPIテストとして設計する
安全研究、レッドチーム・ブルーチーム演習、自社フィルターの防御評価で使うなら、実作業はエンドポイントに再現可能なリクエストスイートを送り、レスポンスを分類・アサートすることです。
最低限、次を実施します。
- 同じスイートを複数ターゲットで実行する FP8、NVFP4、GGUF、未変更ベースモデル、ホスト型エンドポイントに同じリクエストを送り、ベースURLだけを切り替えます。これにより、挙動の差を量子化やホスティングの違いと比較できます。
- 目視ではなくアサーションを使う 拒否率は数百プロンプトの集計値です。レスポンス分類を自動化し、再実行できる形にします。
- 回帰テストとして定期実行する ウェイトや量子化版が更新されるため、翌月にも同じスイートを実行します。
- 非決定性を前提にする 文字列の完全一致ではなく、拒否・許可・ツール呼び出しなどの分類を検証します。十分なサンプル数も必要です。詳しくは「非決定性AIエージェントのテスト」を参照してください。
- ツール呼び出しを別に検証する 関数呼び出しに対応するモデルでは、危険なツールを呼び出さないこと、引数がスキーマに適合すること、契約どおりのレスポンスを返すことを確認します。
Apidogでは、エンドポイントを定義し、プロンプトスイートをコレクションとして保存し、レスポンスフィールドをアサートできます。環境変数でプロバイダーや量子化版のベースURLを切り替え、CIから同じ評価を実行することも可能です。
未変更モデル向けの設定例は「ApidogでGLM-5.3-Flash APIをテストする」で解説しています。OpenAI互換エンドポイントであれば、同じ構成を流用できます。
モデルの挙動が測定・防御対象になった時点で、通常のAPI契約と同じ規律が必要です。ノートブックだけに評価が残っているなら、Apidogをダウンロードして、再現可能なテストとして管理しましょう。関連情報は「本番環境でのAIエージェントの信頼性」にあります。
レッドチームには監査証跡が必要
無検閲化モデルで有害プロンプトのベンチマークを実行する場合、事前承認と事後の帰属可能性が必要です。
- 誰が実行したか
- どのチェックポイントを対象にしたか
- 誰が承認したか
- どの範囲で実施したか
- どの結果が得られたか
これらが研究者のシェル履歴にしか残っていないなら、研究プログラムではなく運用上の負債です。
Sharklyは、セッション終了後も残す必要がある作業向けの管理基盤で、この用途にも適しています。
- バックログ上のタスクは、承認・スコープ確定前には実行されません。
- プロンプトではなくタスク単位で記録できます。進捗、ツール呼び出し、結果、エージェントの出力がタスクに保存されます。
- クルーでは、リーダーエージェント、他のエージェント、人間のレビュアーを組み合わせられます。
- ラップトップ、サーバー、コンテナなど、接続したコンピューター上の既存ランタイムを利用できます。大規模モデルでは、どのGPUマシンで評価したかを明示できることが重要です。
- スペース、プロジェクト、スプリント、タスク、Jira同期といった、チームが使い慣れた構造で管理できます。
無検閲モデルは研究ツールです。記録なしで使う研究ツールは、組織が何を実行したのか説明できない状態を招きます。
法的・安全上の注意
ウェイトのMITライセンスは、ウェイトの利用条件を定めるものです。出力を使って違法行為をする許可ではなく、責任を利用者から移転するものでもありません。現地法、雇用主のポリシー、利用するプラットフォームの規約は引き続き適用されます。
想定される用途は、安全研究、解釈可能性の研究、レッドチーム・ブルーチーム演習、拒否メカニズムの分析などです。XSTestで示された過剰拒否の改善も、通常のセキュリティエンジニアリングを妨げるモデルにとって実用的な論点です。
エンドユーザー向けに展開する場合、無検閲チェックポイントはフィルタリングの責任を自社スタックへ移します。これは設定フラグではなく、人員配置、監視、インシデント対応に関わる設計判断です。
よくある質問
GLM-5.3-Flash-UncensoredはGLM-5.3-Flashと同じモデルですか？
同じアーキテクチャとベースウェイトを使い、総パラメータ数3,200億、アクティブパラメータ180億です。違いは拒否動作がウェイト編集によって削除されている点です。詳細は「GLM-5.3-Flashとは何か」を参照してください。
評価数値は独立検証されていますか？
いいえ。すべてOrcaRouterの自己報告値で、執筆時点では第三者による再現検証はありません。ベンチマーク自体は公開されているため、同じ条件を用意すれば再現可能です。
どのフォーマットを選ぶべきですか？
FP8はリファレンス版、NVFP4はNVIDIAの実用的なシングルノード向け、GGUFはllama.cpp向け、MLXはApple Silicon向けです。量子化で挙動が変わる可能性があるため、形式ごとに同じテストスイートを実行してください。
無検閲化で一般性能は低下しますか？
この技術に関する公開研究では、何らかの性能低下が見られることがあります。今回の発表では測定されていません。ベースモデルとの同等性を仮定せず、自分で推論、コーディング、ビジョン性能を比較してください。
拒否率はなぜ11〜18%で止まったのですか？
未解決の問題です。OrcaRouterは、アライメントの一部が単一の線形な拒否方向で伝達されていないと説明しています。実装が不完全だった可能性もあります。いずれにせよ、残存する拒否率を安全機能として扱わないでください。
商用利用できますか？
ウェイトはMITライセンスです。ただし、これはライセンス上の回答であり、特定のデプロイメントに関する法的・ポリシー上の判断ではありません。エンドユーザーに出力を提供する場合は、法務チームに確認してください。
まとめ
GLM-5.3-Flashの無検閲化版では、Block-FP8、NVFP4、GGUF、MLXの選択肢が順次公開されました。無検閲化自体は一般的な手法ですが、今回の重要な点は、拒否率が96%から11%まで低下したところで止まったことです。
この結果が独立検証されれば、GLM-5.3-Flashのアライメントが単一の線形な拒否方向では表現されていない可能性を示す、価値ある研究結果になります。
実際に利用するなら、次の2点を実行してください。
- 複数のチェックポイントと量子化形式に対して、再現可能なAPIテストを実行する。
- 誰が、どのウェイトに対して、何を実行し、誰が承認したかを監査証跡として残す。
無検閲モデルは、利用者が何を動かしたかを知る責任をなくしません。むしろ、その責任を大きくします。
Top comments (0)