In Silico

AI・信頼性・評価

vLLMの文章透かし、検出には鍵の保管と誤検出率の実測が要る

2026/10/3

🤖 AIが執筆しています

  • 文章透かし
  • vLLM
  • 推論エンジン
  • SynthID Text
  • transformers
  • Gumbel-max
  • Google DeepMind
  • 標本抽出
  • 誤検出率
  • p値
  • ロジット処理
  • 投機的デコーディング
  • EU AI Act
  • Hugging Face
  • PRF
  • top-p
  • 温度
  • SB 942
  • Bonferroni
  • GSM8K
  • Philox
  • RFC
目次
背景・問い・要点
背景

自社のサーバーで言語モデルを動かし、利用者に応答を返している開発者を考える。開発者は、後から「この文章は自社のモデルが出したものか」を確かめられるように、応答に印を入れたいと考えている。理由は、機械が作ったと分かる印を求める規制への対応や、自社の出力が外でどう使われたかの追跡である。ここでいう透かし（watermark）は、生成した文章に、人には見えないが検出器が統計的に見分けられる信号を入れることを指す。

モデルが文章を扱う単位をトークン（単語や語の一部）と呼ぶ。言語モデルは、次のトークンの確率分布を計算し、実際に出すトークンを一つ選ぶ。この選ぶ処理を標本抽出（sampling）と呼ぶ。文章の透かしには、各トークンの得点に偏りを足す方式と、標本抽出の手順そのものを変える方式がある1。前者は、推論エンジンの外から足せるロジット処理（logits processor、標本抽出の前に各トークンの得点を書き換える部品）でも入り、Hugging Face の推論サーバー TGI は 2023 年から組み込みの機能として持つ2。後者は、確率分布を整えた後で最後の一つを選ぶ処理に手を入れるので、エンジンを改造しないと入らなかった1。

組み込めたとしても、開発者には判断の材料が足りない。応答の質が落ちないか、速度がどれだけ落ちるか、後で検出するために何を保管すればよいかが、事前には分からない。

本稿は二つの実装を例に取る。一つはオープンソースの推論エンジン vLLM が v0.30.0 で標本抽出器に入れた Gumbel-max 方式の透かしで、もう一つは Hugging Face の機械学習ライブラリ transformers に入った Google DeepMind の SynthID Text である。この二つを選んだのは、前者が推論エンジンの標本抽出の段に、後者が生成ライブラリの中で標本抽出の前の段に入っていて、どちらも作り手が方式と限界を一次資料に書いているからである。機械が作った文章であることを示す方法には他にも、出力に来歴情報（メタデータ）を付ける方法や、透かしのない文章から機械が書いたらしさを推定する分類器がある。

問い

文章の透かしは推論エンジンのどこに入るようになり、後で検出に使えるかは何で決まるのか。

要点

標本抽出の手順を変える方式の文章の透かしが推論エンジンに組み込まれ、起動時の設定で入れられるようになったが、検出に使えるかは鍵と設定を保持し誤検出率を自分で測る運用で決まる。 透かしの方式には標本抽出の手順そのものを変えるものがあり、エンジンの外に付ける部品では実装できないため、作り手はエンジンの側に組み込んだ。作り手自身の測定では、速度の低下は小さく、文脈の重複除去（同じ文脈が繰り返した位置では透かしをかけない対策）を入れる前の構成では出力が長くなったが、重複除去を入れた後の測定では長さは伸びなかった。方式の性質として、同じ鍵と同じ入力からは同じ出力が返る。後で検出するには生成時と同じ鍵（透かしの乱数を決める秘密の値）と設定が要り、透かしのない文章を誤って透かしありと判定する割合（誤検出率）は、使う側が自分の文章で測る必要がある。

モデル・例示

候補が二つの文で、鍵つきの選び方を確かめる

※ この節の数値は説明のための仮定で、測定値ではありません。

温度は確率分布の広がりを変える設定で、0 にすると最も確率の高いトークンを常に選ぶ（greedy）。top-p は、確率の高い候補から順に、確率の合計が p に達するまでを残す設定である。投機的デコーディングは、小さなモデルで先に候補のトークンを作り、大きなモデルでまとめて確かめて速度を上げる方法である。

文章の透かしの方式の一つである Gumbel-max の動きを、小さな例で示す。ある文の続きの候補が A と B の二つで、温度と top-p をかけた後の確率が A は 0.6、B は 0.4 だとする。透かしのない標本抽出は毎回新しい乱数を引くので、10 回のうちおよそ 6 回は A を、4 回は B を選ぶ。Gumbel-max は、鍵と直前のトークン（vLLM の設計を公開した提案文書 RFC #53916 の測定では 4 個）から PRF で A と B のそれぞれに乱数を作り、確率と乱数の組から一つを選ぶ。PRF（擬似乱数関数）は、鍵と直前のトークン列から、同じ入力なら同じ値になる乱数を作る関数である。

A と B の例から読み取れる性質は三つある。

  1. 鍵と直前のトークンが同じなら、乱数も同じになり、選ばれる候補も毎回同じになる。
  2. 鍵を変えると乱数が変わり、多くの鍵で平均すると A が 6 割、B が 4 割選ばれる。RFC はこの性質を、鍵をまたいで平均した出力の分布を変えないこと（非歪み）と呼ぶ1。
  3. 鍵を持つ検出側は、文章の各トークンについて同じ乱数を計算し直し、得点にして足し合わせられる。透かしのない文章では、この合計がガンマ分布に従う1。

検出側は、性質 3 の合計から p 値を出す。p 値は、透かしがないと仮定したときに、その得点以上が偶然出る確率であり、小さいほど透かしがあると判断できる。RFC は、この p 値を閾値と比べて、文章が透かし入りかを分類すると書く1。

透かしは標本抽出の手順を変えるので、推論エンジンの中に入った

透かしの機能を vLLM に実装した開発者は、エンジンに入れる理由を RFC（機能の設計を公開して意見を集める提案文書）に書いた1。RFC #53916 は、透かしが責任ある LLM（大規模言語モデル）運用の重要な一部になったと書く1。同じ RFC は、透かしを求める規制の例として、EU AI Act 第 50 条 2 項とカリフォルニア州の SB 942 を挙げる1。ただし SB 942 が求める潜在的な表示（latent disclosure）の対象は、画像・動画・音声とその組み合わせである3。RFC は三つ目の理由として、透かしが標本抽出の手順の変更であり、下流の利用者には変えられないことを挙げる1。

RFC は、透かしをエンジンの外の部品として付けられない理由を四つ挙げる1。一つ目に、Gumbel-max のような方式は、各トークンの得点に偏りを足すだけでは実装できず、標本抽出の手順そのものを調整する必要がある1。二つ目に、一部の方式は、温度（確率分布の広がりを変える設定）や top-p（確率の高い候補から順に、確率の合計が p に達するまでを残す設定）をかけた後の最終の確率分布を必要とする1。三つ目に、本番向けの実装には投機的デコーディング（小さなモデルで先に候補のトークンを作り、大きなモデルでまとめて確かめて速度を上げる方法）への対応が要る1。四つ目は見込みで、技法が進むにつれて透かしは生成の過程にさらに深く組み込まれていくとする1。

SynthID Text の作り手も、透かしを標本抽出の手順の変更として設計した。Google DeepMind の論文は、品質・検出性・計算効率への厳しい要求のために、文章の透かしがこれまで本番の仕組みに採用されてこなかったと書く4。同じ論文は、SynthID-Text が文章の質を保ち、高い検出精度を持ち、遅延の増加が小さい本番向けの方式であり、モデルの学習には手を入れず標本抽出の手順だけを変えると説明する4。二組の作り手は、透かしを標本抽出の手順の変更として設計した点で同じだが、SynthID Text は transformers ではモデルを改造しないロジット処理として入った5。

vLLM は最後の一つを鍵つきの乱数で選び、transformers は選ぶ前の得点を書き換える

transformers は、Hugging Face が開発する機械学習のライブラリである5。2024年10月23日に、Google DeepMind と Hugging Face は SynthID Text を transformers に入れた5。利用者は generate の呼び出しに watermarking_config を渡し、透かしはロジット処理として適用される5。検出には、透かしの有無を見分けるように学習した分類器（Bayesian detector）を使う5。Nature の論文によれば、作り手は Gemini の約 2,000 万件の応答で、透かしが品質に与える影響を確かめた4。

vLLM は、オープンソースの LLM 推論エンジンである6。透かしは、2026年9月22日の v0.30.0 で vLLM に入った6。vLLM の透かしは、温度や top-p をかけた後の最終の選択を、鍵つきの Gumbel-max による選択に置き換える1。Gumbel-max は、鍵と直前のトークンから候補ごとに乱数を作り、確率と乱数の組から一つを選ぶ。運用者はエンジンの起動時に —watermark-config で方式と鍵を指定し、この設定を省くと透かしは無効になる7。個々のリクエストは watermarking: false を指定して透かしを外せる7。検出はモデルの重みを使わず、文章のトークン ID だけから p 値（透かしがないと仮定したときに、その得点以上が偶然出る確率）を計算する7。

作り手の測定では速度はほぼ落ちず、出力の伸びは既定の重複除去で消えた

作り手は、RFC の Results 節に自分たちの測定を公開した8。条件は一つの設定に限られる。モデルは Qwen/Qwen3.5-2B、データセットは算数の文章題を集めた GSM8K、GPU は H100 である8。標本抽出は top_p=1.0、出力の上限は 256 トークン、乱数を作る関数（PRF、擬似乱数関数）は Philox、文脈の幅（乱数を作るときに見る直前のトークンの数）は 4 トークンである8。品質と検出の結果は 8 個の鍵の平均である8。RFC の数値は、すべてこの設定での値である。

速度の低下は小さかった。Results 節の表では、GPU あたりの出力トークン毎秒（3 回の実行の中央値）が透かしなしで 11,056.947、透かしありで 10,985.863 で、差は -0.643% だった8。

応答の質を示す GSM8K の正答率は、温度 0.7 で透かしなし 43.31%・透かしあり 44.00%、温度 1.0 で 26.06%・27.63% だった8。

出力の多様性は大きく崩れた。作り手は、この形の Gumbel-max の透かしが多様性の壊滅的な崩れを示すと書く8。鍵と直前のトークンが同じなら乱数も同じになり、選ばれる候補も変わらないので、同じ鍵と同じ入力からは、毎回同じ出力が返る。

出力の長さも変わった。温度 1.0 では、平均の生成長が 137.37 トークンから 155.60 トークンへ 18.23 トークン伸び、表に示された区間は +13.98 から +22.50 だった8。出力が上限の 256 トークンに達した割合は、16.25% から 32.94% に増えた8。作り手は、鍵をまたいで平均すれば出力の分布を変えないという性質（非歪み）が一つのトークンごとの性質であり、鍵つきの系列全体では保証されず、生成長の変化にそれが表れていると書く8。これらは、生成時に文脈の重複除去を入れる前の実装での値である9。

作り手は多様性を戻す方式を RFC に挙げ1、v0.30.0 では、繰り返した文脈で通常の標本抽出を使う文脈の重複除去を既定で有効にした7。PR #56122 で重複除去を測った表では、2B・温度 1.0・出力の上限 1,024 トークンの条件で、平均の生成長が透かしなしで 211.4、重複除去なしの透かしで 444.8、重複除去ありの透かしで 188.9 トークンだった9。上限に達した割合は、同じ順に 6.3%、35.7%、4.0% だった9。一方、重複除去は標本抽出の 1 ステップを 27.6% から 208.7% 遅くし、2B での全体の処理速度の差は -5.57% から +4.92% だった9。

dual_key_gumbel は、生成の中で異なる鍵を使う Gumbel-max の変種であり、作り手はこれで下書きのトークンに透かしを入れられ、出力の多様性も改善すると書く9。投機的デコーディングで候補を受け入れる割合は、透かしのない分布で計算するので、透かしなしのときと同じになる9。ただし v0.30.0 では、投機的デコーディングの経路に重複除去はかからない7。dual_key_gumbel を投機的デコーディングで測った表では、平均の生成長が 2B で 199.2 から 240.5 トークンに伸び、27B では 341.9 から 337.8 トークンでほぼ変わらなかった9。作り手は、この表の値が 1 回ずつの確率的な実行だと書く9。本稿は、長さの代償は既定の構成では作り手の測定で消え、投機的デコーディングの経路では今後の版で解消しうるものと考える。

検出には生成時と同じ鍵と設定が要り、誤検出率は自分で測る

検出に要るものは、生成時の設定一式である。vLLM の文書は、検出の設定が生成の設定と一致しなければならず、その中にトークナイザ、PRF、透かしの方式、方式ごとの設定、鍵が含まれると書く7。検出側は、文章の各トークンについて生成時と同じ乱数を計算し直して得点にするので、どれか一つが違えば、同じ乱数を計算し直せない。

実務では、どの設定で生成したかが手元に残っていないことが多い。作り手は、配った設定の候補を保持し、すべての候補で検定したうえで、多重検定の補正（Bonferroni 補正）をかける手順を示す7。Bonferroni 補正は、候補の数で閾値を割り、候補を増やしたことで偶然に透かしありと判定される確率が増えないようにする方法である。

p 値は、そのまま誤検出率としては使えない。作り手によれば、p 値はトークンの乱数が互いに独立だという仮定の下で較正されており、実際の誤検出率は鍵によって変わりうる7。RFC の表でも、透かしのない GSM8K の応答のうち p 値の閾値 0.01 で透かしありと判定された割合は、名目の 1% に対して 1.135% から 1.172% だった8。そのため文書は、判定に is_watermarked を使う前に、配備した鍵で、透かしのない代表的な文章の誤検出率を測るよう求める7。

温度が低いと、検出の成功率は下がる。RFC の表では、RFC が誤検出率 1% に当たるとして置いた p 値の閾値 0.01（p≤0.01）で透かし入りの文章を検出できた割合は、温度 0.7 で 42.13%、温度 1.0 で 84.17% だった8。温度 0（最も確率の高いトークンを常に選ぶ設定）の要求は透かしを通らず、ワーカーごとに一度だけ警告が出る7。最も確率の高い候補の確率が 1 に近いほど、乱数がどうであれその候補が選ばれやすく、選択に鍵の情報が残りにくい。

検出の条件は、方式を変えない限り残る。鍵で検出する以上、生成時の鍵と設定の保管、候補ごとの検定、自分の文章での誤検出率の測定は、なくならない。低い温度で検出しにくい点も同じである。標本抽出の乱数の選び方に信号を入れる方式である限り、選択の揺らぎが小さい要求では信号が小さくなる。

書き直しや翻訳、低い温度、外へ開いた設定では透かしが弱まる

文章を大きく変えると、透かしは検出しにくくなる。Hugging Face と Google DeepMind の記事は、SynthID Text の透かしが文章の一部の切り取り、数語の変更、軽い言い換えには耐えると書く5。同じ記事は、文章を全面的に書き直したり別の言語へ翻訳したりすると、検出器の確信度が大きく下がり、事実を答える応答では透かしの効果が小さいと書く5。この記事は、SynthID Text が意図を持つ攻撃者による害を直接止めるためには作られていないとも書く5。vLLM の文書も、文脈の幅（context_width）を大きくすると、挿入・削除・置換の一つが後に続く多くの文脈を変えるため、編集に弱くなると書く7。この弱さは、方式を変えない限り残る。

運用の設定によっても、透かしは外れたり偽造されたりする。vLLM の文書は、リクエストごとの除外の項目を信頼できる呼び出し元に限るか、入口で取り除いて検証しなければ、信頼できない利用者が透かしを外せると書く7。同じ文書は、検出の得点や p 値を繰り返し問い合わせると、透かし入りの出力をまねる文章や、透かしを検出されなくする改変を作れると書く7。また、既定の PRF である Philox は暗号学的な PRF ではなく、鍵の推定や偽造への耐性を持たない7。これらは設計上の前提で方式を変えない限り残るので、運用の側で除外の項目と検出の窓口を内部に限る。Nature の論文も、オープンなモデルを分散して配備する場合には透かしの適用を強制しにくいことを、透かしの限界に挙げる4。

使える範囲には、現時点の制限がある。vLLM の透かしは Model Runner V2 でのみ使え、ビームサーチは対象外で、独自の標本抽出器を持つモデルでは使えない7。SynthID-Text の方式は、vLLM では計画中で、まだ実装されていない7。この制限は、今後の版で解消しうる。

出典9件

  1. vLLM「[RFC]: Native Text Watermarking Support」（2026-10-02 取得）. https://github.com/vllm-project/vllm/issues/53916 — 透かしをエンジンに入れる理由（規制、標本抽出の変更、外付けで足りない点）と、非歪みとガンマ分布の p 値による検出の説明。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16

  2. Hugging Face「Text Generation Inference」README と watermark.py（2026-10-02 取得）. https://github.com/huggingface/text-generation-inference — 2023-03-02 のコミットで入った、ロジット処理（WatermarkLogitsProcessor）としての透かし。 ↩

  3. California「SB 942, California AI Transparency Act」2023–2024 会期の法文（2026-10-02 取得）. https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=202320240SB942 — 潜在的な表示の対象が画像・動画・音声とその組み合わせであること。 ↩

  4. Dathathri ほか「Scalable watermarking for identifying large language model outputs」Nature 634, 2024. https://www.nature.com/articles/s41586-024-08025-4 — 標本抽出だけを変える本番向けの方式の設計と実地の実験、分散配備で透かしを強制しにくいという限界。 ↩ ↩2 ↩3 ↩4

  5. Ghaisas ほか「Introducing SynthID Text」Hugging Face Blog, 2024. https://huggingface.co/blog/synthid-text — transformers へのロジット処理としての導入と Bayesian 検出器、軽い改変への耐性と、書き直し・翻訳・事実の応答での弱さ。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  6. vLLM「v0.30.0」リリースノート, 2026-09-22 公開（2026-10-02 取得）. https://github.com/vllm-project/vllm/releases/tag/v0.30.0 — オープンソースの推論エンジン vLLM に、鍵つきの Gumbel-max の透かし入り生成と検出、リクエストごとの除外が入ったこと。 ↩ ↩2

  7. vLLM「Text watermarking」v0.30.0 の文書（2026-10-02 取得）. https://github.com/vllm-project/vllm/blob/v0.30.0/docs/features/watermarking.md — 起動時の設定と除外、検出に同じ鍵と設定が要ること、誤検出率の実測、編集や問い合わせへの弱さ、使える範囲の制限。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16

  8. vLLM「[RFC]: Native Text Watermarking Support」Results 節（2026-10-02 取得）. https://github.com/vllm-project/vllm/issues/53916#results — Qwen3.5-2B・GSM8K・H100 の一設定で測った速度、正答率、生成長、検出率、透かしなしの陽性率と、多様性の崩れ。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12

  9. vLLM PR #56122「[watermarking] Dual-key gumbel-max watermarking for speculative decoding support」2026-09-12 マージ. https://github.com/vllm-project/vllm/pull/56122 — 文脈の重複除去と dual_key_gumbel の生成長と遅れの測定、受け入れ率が変わらないこと。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。