SynthID-Textとは何か
「この文章、AIが書いたのでは？」という疑いが日常的に生まれるようになりました。しかし、疑いを確かめる方法はというと、意外なほど心もとないのが実情です。
そこで登場したのが、SynthID-Textという技術です。Google DeepMindが開発したもので、大規模言語モデル（LLM）が出力した文章に、人間が読んでも気づかない形で「印」を埋め込んでおく仕組みです。あとから機械にかければ、その印を検出できる。紙幣の透かしを、文章に対してやろうという発想だと考えるとイメージしやすいかもしれません。
2024年10月にNature誌で技術の詳細が公表され（Dathathri et al., Nature 634, 2024）、それと同時にHugging Face Transformers v4.46.0へ本番利用可能な実装が組み込まれる形でオープンソース化されました。論文と動くコードが同時に出てきたわけで、この分野では珍しい進み方です。
ただし、この技術には「できること」と「できないこと」の線引きが、かなりはっきりあります。そしてその線引きは、世間で語られている内容とだいぶズレています。本記事では、公式ドキュメントで確認できる範囲に絞って、その輪郭を整理していきます。
テキストの透かしはオープン、画像・動画・音声はクローズド
SynthIDにはテキスト以外に画像・動画・音声向けの実装もありますが、公開されているのはテキスト版だけです。画像・動画・音声のエンコーダとデコーダはGoogleが手元に置いており、検証はGoogle自身の検出ツールを通す必要があります。
なぜテキストだけ公開できたのでしょうか。これには設計上の理由があります。テキスト透かしは鍵（キー）に依存する方式だからです。鍵を使う金庫の構造を公開しても、鍵そのものを配らなければ中身は守られます。それと同じで、アルゴリズムを開示しても各組織の鍵までは公開されないため、安全性が損なわれない構造になっているのです。
画像向けSynthIDとはアプローチが根本的に違う
画像向けのSynthIDは、ピクセル値をごくわずかに操作して透かしを埋め込みます。写真は微細なノイズを加えても人間の目には同じに見えるので、そこに情報を隠す余地があるわけです。
ところがテキストは事情が違います。文章は離散的な記号の列であり、一文字変えるだけで意味がひっくり返ることさえあります。「気づかれない程度の微小なノイズ」を加えるという発想が、そもそも成立しません。
そのためテキストでは、出来上がった文章に手を加えるのではなく、文章を作っている最中のプロセスそのものに介入するという方法が採られています。ここがSynthID-Textを理解する上での出発点になります。
AI生成テキストを見分ける3つのアプローチ
SynthID-Textの位置づけをはっきりさせるために、AI生成テキストを識別する手段を整理しておきましょう。大きく3系統に分かれます。
| 方式 | 仕組み | 弱点 |
|---|---|---|
| メタデータ付与 | ファイルや通信ヘッダにモデル情報を記録する（C2PAなど） | コピー＆ペーストや再保存であっさり消える |
| 事後的な統計解析 | 語彙や文体のパターンを機械学習で判別する（いわゆるAI検出ツール） | 偽陽性が多く、非ネイティブ話者の文章を誤判定する問題が報告されている |
| 生成時ウォーターマーキング | トークンを選ぶ段階に介入し、統計的に検出できる信号を仕込む。SynthID-Textはここ | 生成する側が実装していなければ、そもそも何も入っていない |
1つ目は「あとから貼るシール」、3つ目は「布に織り込む糸」といったところでしょうか。シールは剥がれますが、織り込まれた糸はコピーしても一緒についてきます。ただし織り込む作業は、布を織っている本人にしかできません。この最後の一点が、後半で効いてきます。
技術原理：トーナメントサンプリング
では、生成プロセスへの介入とは具体的に何をしているのでしょうか。
LLMが文章を書くとき、モデルは一語ずつ「次に来る単語の候補」に確率スコア（ロジット）を割り当て、そこから1つを選び出しています。この選択を延々と繰り返すことで文章ができあがる。SynthID-Textは、まさにこの選択の瞬間に立ち会います。
生成の最終工程に立つ「係員」
Googleの公式ドキュメントによれば、SynthID-TextはTop-KおよびTop-Pの後に、モデルの生成パイプラインへ適用されるロジットプロセッサです。疑似乱数のg関数（g-function）を使ってモデルのロジットを拡張し、テキストの品質に大きな影響を与えないまま透かし情報をエンコードします。
工場のラインにたとえるなら、候補を絞り込む工程（Top-K・Top-P）のすぐ後ろに立っている係員のようなものです。絞り込みが終わって最終候補が並んだところで、係員が秘密のルールブックに従ってどれを通すかを決める。そんなイメージです。
ここで一点、正確に押さえておきたいことがあります。SynthID-Textが採用しているのはトーナメントサンプリングであって、グリーンリスト／レッドリスト方式ではありません。両者はよく混同されるのですが、系統がまったく違います。
| 方式 | 仕組み | 代表 |
|---|---|---|
| グリーンリスト方式 | 語彙をグリーン／レッドに分け、グリーン側のロジットにバイアスを加算する。確率分布そのものを歪める | Kirchenbauerら（2023） |
| トーナメントサンプリング | 確率がほぼ拮抗した候補トークン同士を、鍵由来の疑似乱数によるトーナメントで勝ち抜かせる | SynthID-Text |
なぜ文章の質が落ちないのか
透かしを入れると文章が不自然になるのでは、と心配になるところです。ここがトーナメント方式のうまいところで、介入する場面を「ほぼ互角の候補どうしの選択」に限っているのです。
モデルが「ここは絶対にこの単語だ」と強く判断している場面では、その判断を覆しません。手を出すのは、たとえば「しかし」と「ただし」のどちらでも文意が変わらないような、実力伯仲の場面だけ。そこで秘密の乱数に従って一方を選びます。
甲乙つけがたい候補が並んだときだけ、審判がこっそり持っているルールブックで勝敗を決める。決着がついている勝負には口を出さない。だから読み手には違和感が生じませんし、意味的な優先順位も保たれたままです。
それでいて、この「甲乙つけがたい場面での選択」が文章全体で何百回も積み重なると、鍵を知る者だけが読み取れる統計的な偏りが浮かび上がってきます。しかもこの仕組みは、モデルを追加で学習させる必要が一切ありません。既存のモデルにそのまま乗せられるのです。
鍵はどの単位で共有されるのか
透かしの根幹を担うのは、秘密の鍵（watermarking configuration）です。実装するうえで知っておくと役立つのが、同じトークナイザを使うモデル同士なら、透かし設定と検出器を共有できるという性質です。
ただし条件があって、検出器の学習データに、透かしを共有するすべてのモデルの出力例が含まれている必要があります。社内で複数のモデルを運用している場合、この点が設計の分かれ目になります。
検出の仕組みと、その限界
埋め込む話が済んだので、次は読み取る側です。ここには実務上、知っておくべき仕様がいくつかあります。
2種類の検出器
Hugging Face Transformersおよびリファレンス実装には、性格の異なる2つの検出器が用意されています。
- Weighted Mean検出器：学習が不要で、すぐ使えます。手軽な反面、精度は限定的です。トークン長の異なるテキストにまたがって使う場合は、目的とする偽陽性率における閾値を経験的または理論的に算出することが推奨されています
- Bayesian検出器：学習が必要な分、精度は上がります。透かし付きテキストの例で学習させ、訓練済みの検出器をプライベートなHugging Face Hubにアップロードして組織内で共有する、といった運用ができます
判定は白黒ではなく、3つ目の答えがある
ここは見落とされがちですが、実務ではかなり重要な仕様です。
Bayesian検出器が返してくるのは、「透かしあり」「透かしなし」「不確定（uncertain）」の3状態です。2つの閾値を設定することで、目的とする偽陽性率・偽陰性率に合わせて挙動を調整できます。
健康診断の結果に「異常なし」「要再検査」「精密検査」があるのと似ています。グレーゾーンを無理に白黒に振り分けず、「わからない」という答えをきちんと用意している。これは、この技術が本質的に確率的なものであることを、設計者が正直に織り込んでいる証拠と言えるでしょう。
運用する側も、この3つ目の答えが返ってくる前提で仕組みを組んでおく必要があります。
透かしが機能しなくなる条件
透かしは万能ではありません。以下のような場面では、検出が難しくなります。
- 短文：統計的な有意差が生まれるほどトークンが積み上がらず、信号がノイズに埋もれてしまいます。これは手法の構造上の制約であり、実装を改良して解決する種類の問題ではありません
- パラフレーズ：別のLLMで言い換えるとトークン列が再サンプリングされ、信号が薄まります。ただし完全に消えるわけではなく、より多くのトークンを観測すれば検出できる場合もあります
- 翻訳・大幅な書き換え：トークン空間そのものが変わるため、検出器の信頼度スコアが大きく低下します。GoogleおよびHugging Faceの説明でも、翻訳や徹底的な書き換えによって検出信頼度が大きく下がるとされています。多言語で運用する場合は無視できない制約です
- 削除・改変：長文なら影響は限定的ですが、短文では検出力を著しく下げます
鍵の管理と、リファレンス実装の落とし穴
透かしの強度は、結局のところ鍵をどれだけ厳密に守れるかに直結します。鍵が漏れれば、攻撃者は透かしの構造を把握でき、除去も偽装も理論上は可能になってしまいます。
もう一点、実装を選ぶ際の注意があります。GitHubで公開されているリファレンス実装（google-deepmind/synthid-text）について、Google自身が「研究の再現性を目的としたものであり、本番システムでの使用を想定していない」と明記しています。さらにG値の計算に使われるaccumulate_hash()関数は、暗号学的な安全性を一切保証しないとまで注記されています。
本番で使うなら、Hugging Face Transformersの実装を選んでください。ここは間違えると根本から意味がなくなります。
実装状況：どこで使えて、どこで使えないのか
さて、ここからが本記事でいちばん誤情報の多い領域です。
「Vertex AIのAPIパラメータで透かしをオンにできる」「検証エンドポイントにPOSTすれば判定結果が返ってくる」といった解説を目にすることがありますが、テキストに関しては、これらはいずれも存在しません。おそらく画像向けSynthIDの仕様と混ざってしまったものと思われます。
実際の使い方は、自分のパイプラインに組み込むこと
SynthID-Textは、APIのオプションとして提供されているものではありません。開発者が自分のモデルの生成パイプラインに適用するロジットプロセッサです。
Googleの公式ドキュメントの記述は明快で、透かし付きテキストの生成に追加学習は不要、必要なのはモデルの.generate()メソッドに渡す透かし設定（watermarking configuration）だけとされています。Hugging Face Transformers v4.46.0以降でSynthIDTextWatermarkingConfigを使う形です。
対象は自社でホストするモデルで、GemmaでもLlamaでも構いません。本番利用可能な実装はHugging Face Transformers側にある、という点は前述の通りです。
Googleのモデルを使う場合は、話がややこしくなります
ではGemini APIやVertex AI経由で生成したテキストはどうなのか。ここは2026年時点で情報が錯綜しており、公式ドキュメントに明確な記載がない状態が続いています。
2026年8月、Google AI Developers Forumで、EU AI Act第50条(2)への対応を検討していた開発者がこの点を直接質問しました。当初、Googleの担当者は「APIから生成されたテキストにSynthID透かしは付与されておらず、機械可読な来歴シグナルもない。ネイティブなテキスト透かしの予定もない」と回答しています。
ところがその2週間後、同じ担当者が「チームに確認した結果、Gemini API経由で生成されたテキストは実際にSynthIDで透かしが付与されている」と訂正しました。Google AI StudioおよびAntigravity経由の出力も同様とのことです。
Google社内でも認識が揃っていなかったわけで、外部から把握するのが難しいのも無理はありません。実務上の含意を整理すると、次のようになります。
- Gemini API経由のテキストには、透かしが入っている可能性が高い
- ただしこの事実は公式ドキュメントに記載されておらず、コンプライアンス文書で引用できる一次情報が存在しない
- そして利用者側には、それを検証する手段がない
SynthID Detectorのテキスト対応は、公開情報そのものが食い違っている
Googleは検証用にSynthID Detectorを提供しています。ただしテキストを扱えるかどうかについて、Google自身の公開情報に食い違いがあります。
- 2025年5月のSynthID Detector発表時：画像・音声・動画に加えてテキストもアップロードして検出できると明記されていました
- 現在のGoogle DeepMindのSynthIDページ：Detectorが受け付けるものとしてimage, video, audioのみが挙げられ、テキストは記載されていません
どちらが現行の仕様なのか、外部から確定させる材料がありません。加えてDetectorはウェイトリスト制なので、思い立ってすぐ試せるものでもありません。
こうした状況を踏まえると、SynthID Detectorを「一般のユーザーが任意のテキストを安定して検証できる公開サービス」として位置づけるのは、現時点では難しいと考えるのが無難でしょう。実際、Googleはテキスト透かしを検出するための公開APIを提供しておらず、前述のフォーラムでも過去に同趣旨の回答がなされています。
規制対応や社内ルールの根拠として、この検証経路を前提に設計するのは避けたほうが安全です。
| 経路 | 透かしの埋め込み | 検出 |
|---|---|---|
| 自社ホストのモデル （HF Transformers） |
自分で設定して有効化できる | 自分の鍵で検出できる。Bayesian検出器は要学習 |
| Gemini API Google AI Studio |
付与されているとされるが公式文書に記載なし。開発者が制御することはできない | 手段なし |
| 他社モデルの出力 | 各社の実装次第 | 鍵がなければ検出できない |
ただし「実用されていない技術」ではありません
ここまで読むと、まだ研究段階の話に聞こえるかもしれません。それは誤解です。
Nature論文には、SynthID-TextがGeminiおよびGemini Advancedで実際に本番運用されたことが記載されています。技術としては、すでに大規模に稼働しています。
整理すべきなのは主語のほうです。開発者が自由にSynthID-Textを組み込み、透かしを自分で管理するという意味では、自分で管理するモデルや生成パイプラインへの実装が基本になります。「Googleのサービス経由で生成された文章に透かしが入っているかどうか」と、「それを自分で制御・検証できるかどうか」は、まったく別の話なのです。
そして後者、つまり他人が生成したテキストを自分で判定するという用途については、現時点で一般に使える手段が存在しません。ここが期待とのいちばん大きなギャップになります。
活用シナリオと、現実的な制約
ここまでの整理を踏まえて、実際に何ができるのかを具体的に見ていきましょう。
いちばん素直に成立するのは「自社出力の来歴管理」
現実的なユースケースは、思ったより絞られます。中心になるのは、自社でLLMを運用していて、その出力が後から自社由来のものかを確認したいというケースです。
たとえば、自社サービスが生成した文章が外部に流出したときの追跡。社内で生成AIを使って作ったコンテンツの棚卸し。モデル出力の不正利用の検知。いずれも鍵を自分で持っていることが前提になります。逆に言えば、鍵さえ手元にあれば、これらはきちんと機能します。
教育現場での利用は、条件が揃いません
「学生のレポートがAI生成かどうかを判定したい」という期待は、この技術に対してもっとも多く寄せられるものでしょう。しかし残念ながら、現状では条件が揃いません。
- 学生が使うのはGeminiやChatGPTといった外部サービスであり、鍵は学校側にない
- Gemini出力に透かしが入っていたとしても、それを検出する手段が一般には提供されていない
- 短いレポートでは検出感度が下がる
- そもそも透かし非対応のモデルを使われれば、原理的に検出できない
そして何より重要なのが、この非対称性です。「透かしが検出されなかった」ことは、「人間が書いた」証拠にはなりません。
空港の金属探知機にたとえるなら、鳴った人は何か持っている可能性が高い。しかし鳴らなかったからといって、その人が探知機を通っていない可能性もある。この違いを理解せずに運用すると、誤った評価につながります。口頭確認や独自の設問との組み合わせは、引き続き必要です。
報道・出版：C2PAとの役割分担
来歴確認の実務では、透かしとメタデータを組み合わせる構成が現実的です。C2PA（Coalition for Content Provenance and Authenticity）は、暗号署名付きの生成履歴をファイルに付与する業界標準で、透かしとはちょうど弱点が補い合う関係にあります。
- 透かし：コピー＆ペーストしても残るが、改変で減衰し、第三者が検証するには鍵が要る
- C2PA：公開鍵で誰でも検証でき偽造にも強いが、スクリーンショットや再保存で消える
片方だけでは穴が残るので、両方を重ねる。これが現在の業界的な落としどころです。
EU AI Act対応で注意すべきこと
EU AI Act第50条(2)は、合成コンテンツを生成するAIシステムの提供者に対し、出力が人工的に生成されたものであることを機械可読な形式でマーキングする義務を課しています。この義務は2026年8月2日から適用が始まっています。
ただし経過措置があります。2026年7月27日の改正により、2026年8月2日より前に市場投入された生成AIシステムについては、第50条(2)の機械可読マーキング義務に2026年12月2日までの猶予が設けられました。すでにサービスを運用している事業者にとっては、こちらが実務上の期限になります。
ここで気をつけたいのは、透かしを埋め込むこと自体が義務の履行を意味するわけではないという点です。さらに、モデル提供者側のマーキングに依拠しようとする場合、その事実を示す一次情報が必要になります。
前述の通り、Gemini APIのテキスト透かしについては公式ドキュメントに記載がなく、コンプライアンス文書で引用できる根拠が乏しい状態が続いています。規制対応の文脈でGoogleのマーキングに依拠する設計は、現時点ではかなり危ういと言わざるを得ません。
この分野の技術全般については、LLMウォーターマーキング完全解説でも整理していますので、あわせてご覧ください。
まとめ
- SynthID-TextはNature誌（2024年10月）で公表され、Hugging Face Transformers v4.46.0で本番利用可能な形でオープンソース化されています。公開されているのはテキスト版だけで、画像・動画・音声はクローズドです
- 採用しているのはトーナメントサンプリングで、グリーンリスト方式とは別系統です。確率が拮抗した候補間の選択にだけ介入するため、品質の劣化が小さく抑えられています
- 実装はAPIパラメータではなくロジットプロセッサ。
.generate()に透かし設定を渡す形で、追加学習は不要です - 検出器は学習不要のWeighted Meanと、高精度なBayesianの2種類。判定は「あり／なし／不確定」の3状態で、2つの閾値でFPR・FNRを調整します
- Gemini API経由のテキストには透かしが付与されているとGoogle担当者がフォーラムで述べていますが、公式ドキュメントに記載がなく、検証手段も提供されていません
- SynthID Detectorのテキスト対応については、Google自身の公開情報が食い違っています。2025年5月の発表ではテキストも対象とされていましたが、現在のDeepMindのページには記載がありません。ウェイトリスト制でもあり、任意のテキストを安定して検証できる公開サービスとは言いがたい状況です
- 技術としてはGemini／Gemini Advancedで本番運用された実績があります。ただし開発者が透かしを自分で制御・管理するという意味では、自分で管理するモデルや生成パイプラインへの実装が基本になります
- 短文では検出力が大きく下がり、翻訳や大幅な書き換えでは検出信頼度が大きく低下します。そして陰性は、人間が書いた証拠にはなりません
SynthID-Textは、他人の文章を判定するためのツールではなく、自分が生成した文章に印を付けて管理するための仕組みです。技術としてはすでに大規模に稼働していますが、それを自分で制御・検証できるかどうかは別問題です。この2つを混同してしまうと、期待外れに終わるか、もっと悪い場合には誤った判断の根拠にしてしまうことになります。
正体を正しく理解したうえで、使える場面に使う。地味ですが、それがこの技術との一番賢い付き合い方だと思います。
自社での生成AI活用にあたって、出力の管理や開示方針をどう設計するか。お悩みでしたらご相談ください。状況に合わせてご提案します。
【参考】Dathathri et al., “Scalable watermarking for identifying large language model outputs”, Nature 634（2024年10月）／Google AI for Developers「SynthID: Tools for watermarking and detecting LLM-generated Text」（Responsible Generative AI Toolkit）／Hugging Face Blog「SynthID Text」／GitHub google-deepmind/synthid-text／Google AI Developers Forum（2026年8月）／欧州連合 AI Act（規則(EU) 2024/1689）第50条。仕様・提供状況は変更される可能性があります。
