Claudeは、生成するテキストに 透かし（ウォーターマーク） を埋め込むようになった（2026年8月2日以降にリリースされたモデルから順次）。読者に見た目の違いはなく、追加コストもない。EU AI法への対応として、他の主要AIプロバイダーと足並みを揃えて導入されたものだ。本記事では公式発表の内容を整理しつつ、要所ごとに技術的な補足推論を挟んでいく。

何が変わり、何が変わらないか

概要（利用者への影響）

出力品質・創造性・読みやすさへの影響：なし

見た目の違い：読者には区別不可能

個人特定情報：含まれない（ユーザー・組織・チャットの特定は不可能）

適用範囲：Claude固有ではなく、Code of Practiceに署名した主要AI各社が同様に対応

opt-outは不可：地域を区切る技術的な手段がないため、EU域外を含めグローバル一律で適用中

対応モデルの詳しい範囲や今後の見通しは、次の「導入の背景」「導入状況とロードマップ」で扱う。

内部処理・技術的な仕組み

追加される文字・隠し文字は一切なし：透かしは本文に新しい文字を足すのではなく、もともと存在する「候補間で優劣がほぼない選択」のパターンそのものに宿る
速度・コストへの影響なし：追加トークンを生成しないため課金・レイテンシは変化しない。Nature論文の実測値では、30層のトーナメント方式でもレイテンシ増加はわずか0.57%（比較対象のGumbel samplingは0.26%、Soft Red Listは0.28%）
コピー&ペーストしても残る：透かしは本文の単語選択そのものに埋め込まれているため、コピー先に貼り付けても引き継がれる。軽い編集ではおおむね残るが、全文書き換えや大幅な言い換えでは失われうる（メタデータ方式のC2PAとはこの点で耐性が異なる）

導入の背景

採用されている手法は、Google DeepMindが2024年にNature誌で発表したSynthID-Textをベースにしたものであり、そのルーツは2022年のScott Aaronsonの提案にさかのぼる。透かし自体は決して新しいアイデアではなく、EU規制がその実装を後押しした形だ。

導入状況とロードマップ

すべてのモデルに一斉導入されたわけではなく、モデルのリリース時期で対応状況が分かれている。2026年8月17日時点で確認できている情報は以下の通り。

既に入っているもの：2026年8月2日以降にリリースされたモデルは、Claude本体・API・Claude Code・Claude Cowork・Claude Tag・AWS/Google Cloud/Microsoft Foundry経由など、全提供経路でリリース時点から対応済み
まだ入っていないもの：8月2日より前のモデル（旧モデル）は経過措置の範囲内で今後対応予定だが、具体的な日程は未公表
opt-outは不可：地域を区切る技術的な手段がまだないため、EU域外も含めグローバル一律で適用されている
透かし検出ツール・技術文書についても「後日提供予定」のまま、詳細はまだ出ていない

透かしの仕組み

このブログの図版に入っている © dekinai.net のような表示は、いわば 「見える透かし」 だ。Claudeの透かしはこれとは全く別物で、まず両者を並べて感覚をつかんでおく。

© dekinai.net は誰が見ても「あ、透かしだ」と分かる。一方Claudeの透かしは、この記事の本文を含めどれだけ眺めても、どこにも「それらしきもの」は見えない。見えないことこそが仕様であり、鍵を持つ者だけが後から統計的に検証できる、という発想がここから先の話の土台になる。

LLMは1単語ずつ生成し、複数の候補から次の単語を選ぶ。多くの場面で候補同士は「どちらでも自然」であり、その選択は本来ランダムに決まる（例：「今日の天気は寒くて…」の続きが "overcast" でも "grey" でも意味はほぼ変わらない）。

透かし技術は、この低リスクな選択を利用する。通常は乱数生成器が選択を決めるところを、鍵（key）と直前の単語列から計算した擬似乱数に置き換える。単語自体はやはりランダムに見えるが、鍵を持つ者だけが「Claudeが選びそうな選び方と一致しているか」を後から検証できる。

重要なのは、透かしが常に特定の単語（例えば "overcast"）を選ばせるわけではない点だ。文脈次第でgreyが選ばれることもある。また、Claudeが普段まず使わない単語（記事中の例では "nubilous" という難解な同義語）を無理に選ばせることもない。

トークンとベクトルで見る内部処理

公式発表は一般読者向けに「単語（word）」という表現で説明しているが、実際のLLM内部はトークン単位で動いている。ここでは公式発表を踏まえつつ、より技術的な粒度でSynthID-Text系の透かしの内部処理を補足する（以下は一般に知られているLLMのサンプリング機構をもとにした技術的推論であり、Anthropicの内部実装の詳細を保証するものではない）。

擬似乱数を使って「特定の鍵に紐づく再現可能なランダム性」で1トークンを選ぶ、という発想の原型はGumbel-Maxトリックにある。

通常、カテゴリ分布（確率ベクトル）から1つをサンプリングするには乱数が必要になる
Gumbel-Maxトリックでは、各候補のlogit（対数確率）に独立なGumbelノイズを1つずつ加算し、最大値を取る候補を選ぶだけで、元の確率分布に忠実なサンプリングが再現できる
このGumbelノイズは一様乱数 $u$ から $-\log(-\log(u))$ という変換で作れるため、$u$ を「鍵＋直前トークン列のハッシュ値」から決定的に生成すれば、ランダムに見えて実は鍵で再現・検証できる選択が可能になる
Scott Aaronsonが2022年に提案した方式（exponential-minimum sampling）は、この発想に近い数学的性質を持つ最小構成の透かしだったとされる

ただし、SynthID-Textが採用しているのは、単発のGumbel-Maxよりも精緻な Tournament sampling（トーナメント方式） だ。両者は独立した2手法ではなく、「鍵由来の擬似乱数で分布保存サンプリングを行う」という共通の性質を持つ手法群の中で、単層と多層という関係にある。系譜を整理するとこうなる。

単発のGumbel-Maxが「1回のノイズ付与で決着」するのに対し、トーナメント方式は同じ土俵（分布保存型）の中で、勝ち抜き戦をm回（論文ではm=30）繰り返すという一般化になっている。層を重ねるたびに、勝ち続けた候補の採用確率が指数的に上がっていく再帰的な構造だ。Nature論文の比較実験でも、非歪曲型のGumbel samplingよりSynthID-Textのほうが検出精度で優位という結果が報告されている。もう一方の系統である「歪曲型（Soft Red List）」は品質を犠牲にして検出力を上げる方式であり、SynthID-Textが分布保存型を選んでいる点が、公式発表の「品質に無影響」という主張の技術的な裏付けになっている。

実際に動かして体感する：簡易実装

言葉で説明するよりも、動くコードを見たほうが早い。以下はGumbel-Maxトリックの核心部分だけを取り出したおもちゃの実装であり、実際のSynthID-Text（多層トーナメント、実モデルのlogits）そのものではないが、「鍵で決定的なランダム性を作る」という原理はそのまま体感できる（下記コードは実行して動作を確認済み）。

import hashlib
import math
import random

# 候補同士の確率が拮抗している例（透かしが機能しやすい場面）
vocab_probs = {
    "overcast": 0.26,
    "grey":     0.25,
    "cloudy":   0.25,
    "windy":    0.23,
    "sugary":   0.01,  # 文脈的に不自然な候補（確率が低い）
}

WATERMARK_KEY = "anthropic-secret-key-2026"  # 実際は非公開の鍵

def seeded_uniform(key: str, context: str, token: str) -> float:
    """鍵+文脈+候補トークンから、決定的な0〜1の擬似乱数を作る"""
    h = hashlib.sha256(f"{key}|{context}|{token}".encode()).hexdigest()
    return int(h, 16) / (16 ** len(h))

def gumbel_noise(u: float) -> float:
    """一様乱数をGumbelノイズに変換（Gumbel-Maxトリックの核心）"""
    return -math.log(-math.log(u))

def generate_next_token(context: str, probs: dict, key: str | None = None) -> str:
    """key=None なら普通のランダム生成。keyを渡すと透かし付き生成になる"""
    scores = {}
    for token, p in probs.items():
        u = seeded_uniform(key, context, token) if key else random.random()
        scores[token] = math.log(p) + gumbel_noise(u)  # logit + Gumbelノイズ
    return max(scores, key=scores.get)  # スコア最大のトークンを選択

def detect_watermark(context: str, chosen_token: str, probs: dict, key: str) -> bool:
    """鍵を使って、同じトークンが再現されるかを検証する"""
    return generate_next_token(context, probs, key=key) == chosen_token


# --- 実行例 ---
context = "The weather today was cold and"

print("通常の生成      :", generate_next_token(context, vocab_probs))
watermarked = generate_next_token(context, vocab_probs, key=WATERMARK_KEY)
print("透かし付き生成   :", watermarked)
print("正しい鍵での検出 :", detect_watermark(context, watermarked, vocab_probs, WATERMARK_KEY))
print("違う鍵での検出   :", detect_watermark(context, watermarked, vocab_probs, "another-key"))

実際に実行した出力（WATERMARK_KEYと文脈が同じなら、透かし付き生成の結果は毎回再現される）:

通常の生成      : windy         ← 実行のたびに変わりうる
透かし付き生成   : windy         ← 同じ鍵・同じ文脈なら常にこの結果
正しい鍵での検出 : True
違う鍵での検出   : False

ここで体感できるのは3点。

鍵が違うだけで結果が変わる：WATERMARK_KEYを別の文字列に変えると、選ばれるトークンも変わる。これが「鍵を知らない第三者には検出できない」理由の最小構成
確率の低い候補は選ばれにくい：sugaryは確率が低い（0.01）ため、Gumbelノイズを足しても他の候補に負けやすい
検出は生成と同じ計算をやり直すだけ：detect_watermarkは新しく何かを解析しているわけではなく、generate_next_tokenをもう一度同じ鍵で呼んで一致するか確認しているだけ。これが「鍵さえあれば誰でも検証できる」仕組みの正体

おまけ：確率が偏っていると「違う鍵」でも一致してしまう

上のコードのvocab_probsを、最初の例のような確率が偏った語彙（overcast: 0.35など1つが突出）に差し替えて同じ実験をすると、面白いことが起きる。間違った鍵でも「一致」と判定されてしまうことがあるのだ。

これは実装のバグではなく、むしろ本記事で繰り返し説明してきた 「エントロピーが低い（確信度が高い）場面では透かしの影響力が弱まる」という性質そのもの を体感させてくれる。確率が1つの候補に強く偏っていると、どんな鍵を使ってもGumbelノイズだけではその優勢を覆せず、結果として「誰の鍵でも同じ答えに辿り着いてしまう」＝統計的に区別がつかない、という状態になる。実際のSynthID-Textが長い文章全体で確信度を積算する設計になっているのは、まさにこの「1トークンだけでは偶然の一致と区別できない」問題に対処するためだ。

実際のSynthID-Textはこれを1トークンではなく文章全体（数百〜数千トークン）に対して行い、さらに単発のGumbel-Maxではなくm層のトーナメント方式でスコアリングすることで検出精度を上げている。だが、「鍵→決定的な擬似乱数→確率の高い候補ほど選ばれやすい」という骨格は、このおもちゃの実装と変わらない。

トークン列とベクトルの役割

logitsベクトル：モデルが1ステップ推論するたびに出力する、語彙サイズ分の実数ベクトル。値が大きいほど「その次のトークンらしさ」が高い
softmax後の確率分布：logitsを合計1になる確率分布に正規化したもの。この分布の エントロピー（散らばり具合） が、透かしの介入余地をそのまま表す指標になる
エントロピーが高い＝低リスクな選択：候補トークンの確率が拮抗している状態。ここに鍵由来の擬似乱数を組み合わせても、モデルの「もっともらしさ」を大きく損なわない
エントロピーが低い＝高リスクな選択：1つのトークンが確率の大半を占めている状態（固有名詞の続き、数式の答えなど）。ここでは擬似乱数を混ぜても最尤トークンが選ばれ続けるため、事実上透かしが乗らない

鍵とハッシュ化の位置づけ

透かし鍵そのものは、単一の固定値というよりも、直前の数トークンの並び（コンテキストウィンドウの一部）をハッシュ関数に通すためのシードとして機能していると考えるのが自然だ。この設計であれば、同じ鍵でも文脈が変われば疑似乱数の出方が変わる（＝特定の単語に固定的に偏らない、という公式発表の説明と整合する）。検出側がこのシードをどう利用するかは、後述の「検出の仕組み」で扱う。

なお、Claude・GPT系のトークナイザーは英語で1単語=1〜数トークンに分割されることが多く、日本語のような言語では1文字が複数トークンに分かれることもある。透かしの「候補の自由度」は単語単位ではなくトークン単位で発生するため、言語やトークナイザーの粒度によって透かしの密度が変わりうる、という点も技術的には無視できない要素だろう。

検出の仕組み

検出は「鍵を使って、生成された単語列が鍵の予測パターンと一致しているか」を事後的に照合する作業になる。

公式発表では、モノポリーのたとえ話が使われている。サイコロの代わりに円周率の数字列で移動マスを決めても、プレイヤーにとってはただのランダムな移動に見える。しかし後から「円周率の値」を知っていれば、そのゲームが本当に円周率を使っていたかどうかを検証できる。透かしも同じ発想で、生成そのものの体験を変えずに、事後検証だけを可能にしている。

なぜ短い文章では検出精度が落ちるのか

検出は、鍵さえ持っていれば任意の文章に対して「各トークン位置で、鍵とその時点までの文脈から計算される擬似乱数スコアが、実際に選ばれたトークンの確率順位とどれだけ一致するか」を再計算する作業になる。この一致度合いを文章全体で積算すると統計的な検定量になり、これが「文章が長いほど確信度が上がる」という挙動の裏付けになる。

理由を情報理論的に補うと理解しやすい。透かしが機能するのは「選択の自由度がある単語（トークン）」だけであり、短い文章ではそうした選択の回数（＝証拠となるビット数）が少ない。1つ2つのトークン選択だけでは、たまたま鍵のパターンと一致しているのか、本当にClaudeが生成したのかを統計的に区別しづらい。文章が長くなるほど、トークン単位の弱い証拠が積み上がり、確信度が指数的に高まっていく、という理解で公式説明と整合する。

透かしの濃淡：効きやすい場面と効きにくい場面

透かしは「どちらを選んでも同程度に正しい」場面でのみ機能するため、選択の余地が少ない文章では自然と弱くなる。

コードについても同様の理屈が当てはまる。「動作するために正解が一意に決まる」箇所（構文、変数名の制約がある箇所など）には透かしが乗りにくく、逆にコメントのような自由記述には乗る余地がある。結果として、コード全体としては他の文章形式より透かしが薄くなる。

ファイル・画像への適用（C2PA）

テキストの透かしとは別の仕組みとして、Claudeが生成・処理した画像やファイルにはC2PA規格のメタデータが付与される。

両者の違いは明確で、C2PAメタデータはファイルに追加される「ラベル」であり、透かしのようにコンテンツ自体に隠れて埋め込まれるものではない。

LSBステガノグラフィ・EXIF・C2PAの違い

画像の「見えない情報埋め込み」と聞くと、古典的なLSB（最下位ビット）ステガノグラフィを連想する人も多いだろう。C2PAはこれとは全く異なるアプローチであり、両者を対比すると位置づけがはっきりする。

手法	埋め込み場所	耐性	改ざん検知
LSBステガノグラフィ	各ピクセル値の最下位ビットに直接データを埋め込む	再圧縮・リサイズ・スクリーンショットで容易に破壊される	埋め込まれた情報の有無しか分からず、改ざん検知の仕組みはない
EXIF	JPEGなどのメタデータ領域（撮影日時・機種名・GPS等）	メタデータを削除するだけで簡単に消える	署名がなく、誰でも自由に書き換え可能
C2PA	メタデータ領域だが、暗号署名付きのマニフェスト（来歴チェーン）として格納	メタデータごと削除されれば失われる点はEXIFと同じ	署名により改ざんの有無は検証可能（削除は防げないが、改ざんは検知できる）

LSBはピクセルデータそのものに手を加える「ステガノグラフィ（隠蔽）」であり、原理上はテキストの透かしに近い発想だが、非可逆圧縮（JPEG化など）や単純なリサイズで簡単に破壊されるという弱点がある
EXIFはあくまで撮影・生成条件を記録する慣習的なメタデータ規格で、暗号学的な保証は一切ない
C2PAはEXIFと同じ「メタデータに書き込む」方式を踏襲しつつ、そこに デジタル署名の連鎖（Content Credentials） を持たせることで、「誰がいつどう処理したか」の来歴を暗号学的に検証可能にしている

つまりC2PAは、LSBのような「ピクセルへの耐性ある埋め込み」ではなく、EXIFの発想を暗号署名で強化したものと理解するのが正確だ。そのため公式発表にもある通り、メタデータを丸ごと削除されれば証明手段は失われる。これはテキストの透かし（本文そのものに残るため、コピペしても消えにくい）との耐性面での明確な非対称性であり、画像・ファイルの真正性を担保する仕組みとしては相対的に弱いと言える。

よくある質問

質問	回答
速度やコストに影響する？	いいえ。追加トークンなしのため同じ速度・同じ価格
自分や組織を特定できる？	いいえ。個人情報は一切含まれない
編集すれば透かしを消せる？	軽い編集では消えにくいが、全文書き換えなら消える（その場合AI生成と呼べるか自体が疑問）
透かしは何を証明する？	Claudeが「関与した」可能性のみ。「書いた」のか「大幅編集した」のかは区別できない
翻訳にも適用される？	される（すべての単語をClaudeが選ぶため）
旧モデルにも適用される？	2026年8月2日以前にリリースされたモデルには経過措置があり、今後数カ月かけて順次対応予定
Pangramなど既存のAI検出ツールとの違いは？	検出ツールは鍵を持たないため、言い回しの統計的な「らしさ」から推測する方式。透かし検出とは根本的に異なる
所有権や法的責任は変わる？	変わらない。透かしは関与可能性を示すのみで、著作権や利用規約上の権利には影響しない

まとめ

以下は公式発表そのものではなく、内容を踏まえた補足的な考察になる。

透かしの技術設計自体は堅実で、「品質に影響を与えない」「コストが変わらない」という主張は、選択の自由度がある箇所だけに介入するという仕組み上、technically筋が通っている。一方で公式発表も認めている通り、この仕組みには構造的な限界がある。

短文・事実文・コードでは検出力が弱い。悪用を懸念する文脈では、まさに「悪用されやすい短い扇動的な文章」ほど検出しにくいという非対称性がある
透かしは「誰が書いたか」ではなく「Claudeが関与したか」しか示せない。人間が下書きしてClaudeが軽く手を入れたケースと、Claudeがゼロから書いたケースを区別できない
地域を区切る手段がまだないため、EU域外にもグローバルに（opt-outなしで）適用される。これはAnthropicの意図というより技術的制約から来ている

規制対応としては合理的な一手である一方、「透かしがあること」自体が広く一般に認知されるまでは、実運用上の効果は限定的だろう。EU域内のみならず主要各社が同時期に同様の対応を始めている点は、業界横断の透明性基盤づくりという意味で注目に値する動きと言える。

出典

How Claude's text watermark works（Anthropic, 2026年8月14日）

Claudeのテキスト透かし機能を技術的に読み解く - WaterMark