[Claude] LLMの電子透かし：仕組みと限界

Introduction

先日、Anthropic がサポートページ「How Claude marks AI-generated content」を更新し、
Claude が生成したテキストに機械可読な電子透かしを埋め込む方針を公表し、
国内外でこれについてさまざまな意見が出ています。

公式の説明はシンプルで、以下の2つです。

• テキストへの埋め込み透かし：対応する Claude モデルがテキストを生成するとき、知覚できない透かしをテキストそのものに直接織り込む
  • コピペしても一緒に移動し、軽微な編集を経ても残る（「軽微」がどの程度かは不明）
• 署名付き来歴メタデータ：.svg/.png/.jpg などのファイル生成時に、C2PA 標準に準拠した署名付きメタデータを付与

適用範囲が広く、モデルレベルで適用されるため Claude Platform（API）・Claude・Claude Code・Claude Coworkのすべてが対象、EU 域内に限らず全世界が対象です。
法的なトリガーは EU AI Act 第50条(2)（生成 AI 出力の機械可読なマーキング義務）ですが、
実装は地域で分けないという判断です。

ユーザーの反応

この記事に対して、いろいろと意見が出ています 。

特に以下のような意見が多く見られました。

1. 埋め込みだけ先行して、検出手段が提供されていない。公式も「検出メカニズムの詳細は今後の技術文書で共有する」とあり、現時点で確認する方法がない。
2. 「Claude が処理した」と「Claude が書いた」の区別がつかない。自分で書いた文章を校正・翻訳させただけでもマークが付く。公式自身が「検出されたマークは Claude が処理したというシグナルであって、決定的ではない（"not fully conclusive"）」と明記している。
3. 誤検出の問題。学校の課題や採用選考で「AI 判定」と誤って判断されたら？
4. コードに影響しないのか？Claude Code の出力にも入るなら、生成されたコードに何か混入するのでは？
5. 出力品質が落ちるのでは？生成に手を加える以上、文章が不自然にならないのか？

私も Claude Code を日常的に使っているので、いろいろ気になります。
そこで「そもそも電子透かしとは何か」から整理して、
LLMの透かしがどういう原理で動くのかを確かめてみます。

About Digital Watermark

発想は紙幣のすかしと同じ

電子透かし（Digital Watermark）は、コンテンツそのものに識別情報を埋め込む技術です。
名前のとおり、紙幣を光にかざすと現れる「すかし」が原型になっています。

紙幣のすかしには、次の性質があります。

• 普通に見ている分には気づかない（不可視性）
• 決まった手順（光にかざす）を踏むと取り出せる（検出可能性）
• 折っても、多少汚れても消えない（頑健性）
• 紙そのものに漉き込まれているので、コピー機で複製しても再現されない

電子透かしもまったく同じで、コンテンツに手を加えて、気づかれない印を仕込みます。
媒体ごとに具体的なやり方は違います。

簡単な例：画像の LSB 置換

わかりやすいのは、画像の LSB（Least Significant Bit、最下位ビット）置換です。
画像の1ピクセルは、たとえば赤の成分が 10110101（181）のように8ビットで表されます。
この一番右のビットを書き換えて 10110100（180）にしても、
181 と 180 の色の差は人間の目にはわかりません。

つまり1ピクセルにつき1ビット、こっそり情報を入れることができます。
フルHD 画像なら約207万ピクセル×RGB 3色で約622万ビット、約780KB の情報を
見た目を変えずに隠せます。

元ピクセル:     10110101  10010110  11001011
                 ↓         ↓         ↓     最下位ビットだけ書き換え
透かし入り:     10110100  10010111  11001010
埋め込み情報:          0         1         0

ただし LSB は脆く、JPEG で保存し直すだけで埋め込んだ情報は壊れます。
圧縮は「見た目に影響しない細かい成分」から捨てていくので最下位ビットは優先的に捨てられます。

そこで実用的な手法では、周波数変換したあとの係数に埋め込みます。
ここで直感に反するのが、この分野の古典である
安全なスペクトラム拡散透かしに関する論文 にある主張です。
普通なら「目立たない成分に隠す」と考えるところを、
逆に「知覚的に最も重要な係数にこそ埋め込む」としました。
重要な係数は、画質を保つために圧縮でも捨てられません。
消えては困る場所に隠せば、透かしも一緒に生き残る、という理屈です。

似ているが違う4つの概念

「秘密情報埋め込み」や「識別」に関連する技術を確認しておきましょう。

透かしとステガノグラフィーは技術的に重なりますが、目的が違います。
ステガノグラフィーは「通信の存在自体を隠す」のが目的で容量重視、
透かしは「所有権・来歴の主張」が目的で頑健性重視です。

C2PA は暗号署名付きのメタデータをファイルに添付する方式で、コンテンツ本体は改変しません。
「誰が・いつ・何で作ったか」を証明できますが、ファイルに埋め込まれたメタデータは失われることがあります。
スクリーンショット、SNS へのアップロード、形式変換で消えます。
※C2PA 仕様には
外部マニフェストや、不可視透かしで剥がれた情報を再発見するソフトバインディングも定義されている

今回 Anthropic が「テキストには透かし、ファイルには C2PA」と2つ組み合わせているのは、
この性質の違いによるものです。

トレードオフ

電子透かしには、容量・不可視性・頑健性のトレードオフがあります。
Chen と Wornell（2001）が理論的に定式化したもので、
以下のようになります。

• 強く埋め込めば頑健になるが、品質が落ちる
• 品質を保てば、攻撃に弱くなる
• たくさんの情報を入れれば、その分どちらかを犠牲にする

よくあるコスト・納期・品質の問題と同様に全てを同時に最大化することはできません。
だから「万能&頑健な透かし」は存在しません。
この制約は、後述する LLM の透かしでも同様です。

Digital Watermarks in LLM

テキストには余白がない

画像や音声には人間の知覚がいきとどかない余白がありましたが、
テキストにはこの余白がありません。

「電子透かし」の1文字を変えて「電子透かじ」にしたら、誰でも気づきます。
文章は情報密度が高く、どの文字も意味を担っているので、
画像のようにわからない程度に少しだけ変えることができません。

昔からある手法としては、ゼロ幅スペース（U+200B）などの不可視なUnicode文字を
文中に混ぜてビットを表現する方法があります。
実装は簡単ですが、これは正規化やコピペの経路で簡単に消えますし、
そもそも「不可視文字を全部消す」だけで無効化できるのであまり効果はありません。

発想の転換：「どの語を選んだか」に情報を持たせる

そこで代表的な生成時透かしでは、発想を変えて解決します。
文章を後から加工するのではなく、生成するときの語の選び方に偏りを入れる
というアプローチです。

LLM が文章を作るとき、次の1トークンを選ぶ場面では常に複数の候補があります。

「電子透かしは、コンテンツに情報を（  ）」
   候補: 埋め込む(35%) 仕込む(22%) 織り込む(18%) 入れる(15%) 書き込む(10%)

どれを選んでも文章として自然です。
ここに秘密鍵で決めた偏りを加えるのが、本記事で扱う統計的透かしです。

代表的なものに Kirchenbauer らの green/red リスト方式（ICML 2023, arXiv:2301.10226）があります。
手順は以下。

1. 直前のトークンをハッシュして擬似乱数のseedにする
2. そのseedで語彙全体を green リスト（割合 γ、たとえば25%）と red リスト にランダムに二分する
3. green 側のトークンのスコア（logit）に δ（たとえば 2.0）を足して、選ばれやすくする
4. サンプリングする

こうして生成された文章は、読んでも自然です。
ただし「green に属する語が、偶然にしては多すぎる」という統計的な偏りが残ります。

検出はその逆で、文章のトークンを1つずつ見て
「これは green だったか？」を数えます。

z = (green の個数 − γ×トークン数) / √(トークン数 × γ × (1−γ))

分子が「期待からのズレ」、分母が「偶然でも生じるブレ幅」です（√ は平方根）。
green か red かはコイン投げのようなものなので、
偶然でも生じるブレ幅は √(トークン数 × γ × (1−γ)) で計算できます。

つまりzは、ズレがブレ何個ぶんに相当するかを表しています。
このように「偶然にしては外れすぎでは？」を判定する手続きを
z検定と呼びます。

なお分母が平方根なのでzは文章の長さの平方根に比例して伸びます。
長い文章ほど検出しやすくなるのはこのためです。

γ=0.25 なら、透かしのない文章では、greenは全体の25%前後に収まるはずです。
それが70%もあれば、偶然では説明がつきません。

この検出にモデル本体は必要なく、秘密鍵と本文だけあれば計算できます。
ここが後述する「AI検出ツール」との違いです。

「コピペしても検出できる」の意味

「コピペしてもわかる」と言われると不思議に聞こえますが、
理屈は単純で、「情報がどこにあるか」で決まります。

テキストをコピペしたとき、運ばれるのは文字列（コードポイントの並び）だけです。
なので、

Anthropic の「透かしはテキストの一部なので、コピー＆ペーストで移動しても一緒に移動する」という説明は、
統計的透かしを採用している場合であれば 3行目の性質と整合します
※不可視Unicode文字でもコピペ自体は通過するため、この記述だけで方式を絞り込めない

そして逆も言えます。情報が言葉の選ばれ方にあるので、
言葉を選び直すほど信号は弱まっていきます。
消えるか残るかの二択ではなく、どれだけ言葉を入れ替えたかで連続的に弱まる、という性質です。

実際、The Register の報道でも
「どの言葉やトークンが現れるかを大きく変える書き換え（別の AI モデルに書き直させることを含む）は
透かしの信号を無効化する」と指摘されています。

実例

このような、生成時に統計的な信号を埋め込む方式には、すでに本番投入例があります。
Google DeepMind の SynthID-Text は、green/red リストとは別のトーナメントサンプリングという手法で
Gemini に導入され、
Nature（2024）に論文が掲載されました。

約2000万件の Gemini 応答を対象にした評価で、
ユーザーの thumbs-up/down 率に有意差がなかった(品質を落とさずに透かしを入れられた)と報告しています。
実装はHugging Face Transformersで公開されています。

なお、Claude の方式について、Anthropic はアルゴリズムを一切公表していません。
「テキストそのものに織り込む」「コピペで移動する」「一部の編集に耐える」という記述は
上記の統計的透かしと整合しますが、これは第三者による推論であって、
Anthropic が確認した事実ではないのでご注意ください。

Try

理屈はわかったので、実際に動かして確かめます。
統計的透かしは本当に「自然な文章のまま検出できる」のか、
どれくらいの長さが要るのか、というあたりです。

環境は Node.js v20 + tsx です（npx tsx ファイル名 で TypeScript を直接実行できます）。

検証前に、Claude Codeの出力に不可視Unicode文字が混ざっていないか確認してみました。
※ゼロ幅スペース（U+200B）・ゼロ幅接合子・BOM・異体字セレクタ・タグ文字（U+E0000 ブロック）

約57,000字を走査してみましたが、検出はゼロ件でした。
※Claude の不可視文字を除去すると謳うツールも見かけるので念のため調査

なお、これで方式を特定できたわけではなく、
走査したものが透かし対応モデルの出力なのかを確認できず、対象も限られているので、
「Claude はゼロ幅文字方式ではない」と結論づけることはできないので注意。

ついでに懸念4「コードに影響しないのか」についても触れておくと、
green/red リストのような統計的透かしであれば、
生成後に文字を混入させる方式ではないため、不可視文字がコードに紛れ込むことはありません。
偏りが乗るのは「変数名が userId になるか userID になるか」といった選択のほうです。
ただし Claude の実際の方式は非公開であり、
コード品質や正確性への影響は本記事では検証していません。

統計的透かしを実装する

green/red リスト方式を、サンプルの「言語モデル」の上で再現します。
コードをみてみましょう。
※実際の LLM は使わず、サンプリング層だけを模倣

まずはメインとなる2つの関数です。

• isGreen : ある言葉が green か red かを判定する。
  直前のトークンと秘密鍵をハッシュにかけ、出てきた値が γ（0.25）未満なら green とする。
  鍵が同じなら誰がやっても同じ判定になり、鍵が違えば結果はまったく変わる
• detect : 文章を受け取り、green がいくつあったかを数えて z を計算する。
  ここで使うのは秘密鍵と本文だけで、LLM は登場しない

// greenlist.ts（抜粋）
import { createHash } from "node:crypto";

const GAMMA = 0.25; // 語彙のうち green にする割合
const DELTA = 2.0;  // green の logit に足すバイアス

/** 直前トークンと鍵から、そのトークンが green かどうかを決める */
function isGreen(prev: string, token: string, key: string, gamma = GAMMA): boolean {
  const h = createHash("sha256").update(`${key}|${prev}|${token}`).digest();
  return h.readUInt32BE(0) / 0x1_0000_0000 < gamma;
}

/** 検出: green の出現数をz検定にかける（モデル本体は不要） */
export function detect(tokens: readonly string[], key: string, gamma = GAMMA) {
  let green = 0;
  for (let i = 1; i < tokens.length; i++) {
    if (isGreen(tokens[i - 1], tokens[i], key, gamma)) green++;
  }
  const T = tokens.length - 1;
  const z = (green - gamma * T) / Math.sqrt(T * gamma * (1 - gamma));
  return { T, green, z };
}

透かしを入れる側は、さらに簡単です。
次の言葉の候補を1つずつ見て、green だったものだけスコアを底上げしてから選びます。
base が素のモデルが付けたスコア、DELTA が上乗せ分です。

const logits = new Map<string, number>();
for (const c of candidates) {
  const base = /* 素のモデルのスコア */;
  const boost = watermark && isGreen(prev, c, key) ? DELTA : 0;
  logits.set(c, base + boost);
}
const chosen = sample(logits, rand);

ポイントは、候補を絞り込んだり禁止したりしていないことです。
red の言葉も選ばれる余地は残っているので、文章としては自然なまま、
全体としては green がやや多くなる、という状態を作れます。

意味は同じだが選ばれる言葉だけ違う

まず直感的な確認として、言い回しの選択肢を並べた文で、透かしのオン・オフを比べます。
乱数シードは同一にしてあるので、差は透かしのバイアスだけです。

=== 同じ意味・違う語選択 ===
透かしなし: 電子透かしはコンテンツに知覚できない情報を織り込む技術です。
透かしあり: デジタル透かしはデータに見えない情報を織り込む手法です。

「電子透かしは」→「デジタル透かしは」
「コンテンツに」→「データに」
「知覚できない」→「見えない」
「技術です」→「手法です」

と、4か所で選択が動きました。どちらも自然で、意味も同じです。
これが「品質を落とさずに透かしを入れる」ということで、
懸念5「出力品質が落ちるのでは？」に対する原理的な説明になります。
読んで違和感がないのは、そもそも複数ある自然な選択肢の間でしか動かしていないからです。
ただしこれはサンプル実装の例であり、Claude の出力品質を測ったものではありません。
実モデルでの品質影響については、SynthID-Text が Nature 論文で
約2000万件の Gemini 応答を対象に有意差なしと報告している、という事例が参考になります。

200トークンで検出してみる

次に、語彙4000語の例で200トークンを生成し、検出してみます。

=== 200トークンでの検出 ===
透かしなし: green 48/199 (期待 49.8) → z = -0.29  判定: 判定できず
透かしあり: green 135/199 (期待 49.8) → z = 13.96  判定: 透かしあり

透かしなしでは green が期待どおり約25%（48/199）に収まり、z ≈ 0。
透かしありでは 135/199（68%）まで偏り、z = 13.96 でした。

z = 4 がどれくらいかというと、透かしのない文章を3万本用意しても、
偶然ここまで green に偏るのは1本だけ、という水準です。
※正規分布で近似した片側確率 p ≒ 0.00003

今回の z = 13.96 はこれよりはるかに大きく、偶然ではまず説明がつきません。

どれくらいの長さが必要か確認

「1文だけコピペしたらバレるのか」に直結する部分です。生成する長さを変えて z を測ります。

=== 検出に必要な長さ ===
 10 トークン: z = 1.35  検出できず
 25 トークン: z = 4.24  検出
 35 トークン: z = 4.95  検出
 50 トークン: z = 7.51  検出
100 トークン: z = 9.81  検出
200 トークン: z = 13.96  検出
400 トークン: z = 19.80  検出

10トークンでは検出できず、25〜35トークンあたりで閾値を越えました。
これは Kirchenbauer らの論文の報告（γ=0.25, δ=2 で平均 z>5 を約35トークンで達成、
25トークンが情報理論的な下限）とよく一致しています。
サンプルのモデルでこの一致が出るのは、
透かしの検出力がモデルの賢さではなく純粋に統計の問題だからです。

実務的な含意は、今回の方式・閾値・生成条件では短い抜粋の判定が難しい、ということです。
ただし「1文なら必ず検出できない」と一般化はできません。
必要な長さは方式・パラメータ（γ・δ）・閾値の置き方で変わりますし、
同じ長さでも生成分布のエントロピーに依存します。
次の語がほぼ一意に決まる低エントロピーな箇所（定型句や決まり文句）には透かしがほとんど乗らず、
言い回しの自由度が高い箇所には強く乗ります。
同じ35トークンでも、内容次第で検出できたりできなかったりするわけです。

トークンを書き換えたらどうなる？

透かし入りの400トークンについて、ランダムに一定割合のトークンを別の語に置換して、信号がどう劣化するかを見ます。

=== 一部を書き換える（言い換え攻撃の模擬） ===
  0% 置換: z = 19.80  検出
 10% 置換: z = 15.64  検出
 20% 置換: z = 13.21  検出
 30% 置換: z = 11.13  検出
 50% 置換: z = 5.69  検出
 80% 置換: z = 0.72  検出できず
100% 置換: z = -0.43  検出できず

サンプルモデルのランダム置換では、3割の置換まで検出可能でした。
公式の「軽微な編集を経ても残る場合がある」という記述と方向性は一致します。
一方、8割を置換すると信号は消えました。全体を言い換える・翻訳するというのは、
この「ほぼ全置換」に相当する操作です。

鍵を持たない第三者はAI検出できるか？

=== 鍵を知らない第三者は検出できるか ===
正しい鍵: z = 13.96
違う鍵  : z = -0.12

鍵が違えば green/red の分割が変わるので、まったく検出できません（z ≈ 0）。

本実装のような秘密鍵型の方式では、検出に鍵が必要になります。
そして鍵を広く公開すれば誰でも検証できる一方で、透かしを偽造して「人間が書いた文章をAI製に見せかける」
なりすまし攻撃も可能になります。
透明性と偽造耐性はトレードオフの関係にある、というのがこの方式の性質です。

これが懸念1「検出手段が提供されていない」の背景にある技術的な難しさだと考えられます。
現状ではClaude が秘密鍵型なのか、第三者検証をどう設計するのかは公開されていません。
※検出器を公開する設計もありうるので、技術文書の公開を待つしかない

Summary

Anthropic が Claude の出力に電子透かしを入れると発表したニュースをきっかけに、
そもそも電子透かしとは何かというところから調べてみました。

電子透かしは、人間が気づかないところに印を仕込む技術です。
画像なら目が、音声なら耳が鈍感なところを使いますが、
テキストにはその余地がありません。どの文字も意味を持っているからです。

LLM では、文章を後から加工するのではなく、生成するときの言葉選びに偏りを入れます。
本記事で実装した代表的な統計的透かし（green/red リスト方式）では、
秘密鍵で語彙を green と red に分け、green 側が選ばれやすくなるようにします。
読んでも自然な文章のまま、green が偶然にしては多すぎる状態を作ります。
検出は green の数を z検定にかけるだけで、本文と鍵さえあれば LLM は要りません。
※偏りの入れ方は方式によって違い、SynthID-Text はトーナメント方式を使っています

サンプル実装を動かすと、透かしのオンオフで言葉は変わっても自然な文章のままでした。
ただし検出にはある程度の長さが必要だったり、置換により結果が変わるので注意してください。
また、本実装のような秘密鍵型では、鍵を持たない第三者には何も分かりません。
※Claude の実方式は非公開なので、ここで確認できたのは統計的透かし一般の性質です

残る問題点・懸念点

技術的にはよくできた仕組みですが、気になる点もあります。

いちばんの問題は、陰性が何の情報にもならないことです。
透かしが検出されなくても「AI 生成ではない」とは言えません。
透かし非対応の旧モデル、他社モデル、言い換え、翻訳、短い抜粋、どれでも陰性になります。
Anthropic 自身も「マークが検出されないことは、そのコンテンツが AI 生成でないことを意味しない」
と明記しています。

陽性の場合は何が言えるかというと、「Claude が処理した」までです。
自分で書いた文章を校正させただけでもマークは付くので、著者性の証明にはなりません。

そもそも理論的に、強い透かしは除去できるとされています。
この論文 は「品質を大きく落とさずには除去できない透かし」が
原理的に達成不可能だと論じ、こちら は翻訳を経由する攻撃で
検出精度がランダム推測レベルまで落ちることを示しています。
つまり本気で隠したい人は隠せるので、透かしが効くのは「隠す気のない普通の利用」に対してです。

そして誤用のリスクがあります。
透かしとは別物ですが、事後推測型の AI 検出ツールは偽陽性が深刻で、
ある調査 では7つの検出器が
非ネイティブ英語話者の TOEFL エッセイの平均61.3%を AI 生成と誤判定したと報告されています。
透かしは秘密鍵に基づく検定なので偽陽性率を制御できる点で優れていますが、
世間では両者が混同されがちです。

実務でどうするか

現時点では、Claude の透かしを「AI 使用の証拠」として運用に組み込むのは難しいと思います。
検出手段が提供されておらず、方式も非公開なので、確認しようがないためです。
検出 API と技術文書が公開されてから評価するのが妥当でしょう。

来歴を残したい場合は、ファイルには C2PA、テキストには統計的透かし、という二層で考えます。
ただし、どちらも「無い＝AI 不使用」の証明にはならない点は変わりません。

透かしとは別の話として、不可視 Unicode 文字を使ったプロンプトインジェクションや
データ持ち出し（ASCII Smuggling）には引き続き注意が必要です。
主な経路は AI に読み込ませる外部テキスト（Web ページ、Issue、受信メールなど）ですが、
コードに取り込むテキストは出所を問わずスキャンしておくのが実務的です。

EU 向けにサービスを提供しているなら、第50条の義務は自前で確認する必要があります。
Anthropic の透かしに乗っているだけでは足りません。
ただし、テキストに関する開示義務（第50条(4)）は
「公益に関する事項について公衆に知らせる目的で公開されるテキスト」が主な対象で、
人間のレビューと編集責任がある場合は例外とされています。
該当する公開テキストやディープフェイクを扱うなら、
欧州委員会のガイドライン
で自社の義務を確認しておくとよさそうです。

個人的には、この機能そのものより
「透かしがある世界では、陰性が何も証明しない」という非対称性のほうが気になっています。
検出できたときに言えることは限られ、検出できなかったときに言えることは何もない。
これを理解しないまま「AI 判定」の道具として使われ始めるのが、
現実的なリスクだと思います。

References

一次情報・ニュース

• How Claude marks AI-generated content — Claude Help Center — Anthropic 公式。2つの手法、適用範囲、限界の記述。本記事の引用元
• Anthropic says it will watermark text generated by its AI models — TechCrunch（2026-08-11）
• Anthropic pledges to embed watermarks to help discern AI slop in sop to EU — The Register（2026-08-11） — 書き換えで信号が無効化される点への言及
• Claude will begin digitally watermarking AI-generated text and images — Tom's Hardware
• EU compliance, delivered globally: Anthropic to watermark Claude's output worldwide — Euronews（2026-08-11）
• What exactly is people's problem with text watermarking? — r/ClaudeAI — redditスレッド

LLM テキスト透かしに関する論文

• A Watermark for Large Language Models — Kirchenbauer et al., ICML 2023（arXiv:2301.10226） — green/red リスト方式と z 検定。本記事の実装の元
• Scalable watermarking for identifying large language model outputs — Dathathri et al., Nature 634:818–823（2024） — SynthID-Text。トーナメントサンプリング、Gemini での本番運用
• google-deepmind/synthid-text（GitHub） — SynthID-Text の OSS 実装

攻撃手法などに関する研究

• Can AI-Generated Text be Reliably Detected? — Sadasivan et al.（arXiv:2303.11156） — 再帰的言い換えで TPR が 99.8% → 9.7%
• Can Watermarks Survive Translation? — He et al., ACL 2024（arXiv:2402.14007） — 翻訳攻撃で AUC がランダム推測レベルまで低下。日本語も対象言語に含む
• Watermarks in the Sand: Impossibility of Strong Watermarking for Generative Models — Zhang et al., ICML 2024（arXiv:2311.04378） — 強い透かしの原理的な達成不可能性
• Paraphrasing evades detectors of AI-generated text — Krishna et al., NeurIPS 2023（arXiv:2303.13408） — DIPPER による言い換え攻撃
• GPT detectors are biased against non-native English writers — Liang et al., Patterns 4(7)（2023） — 事後検出器の偽陽性と偏り

電子透かしの関連情報

• Secure Spread Spectrum Watermarking for Multimedia — Cox et al., IEEE TIP 6(12):1673-1687（1997） — スペクトラム拡散法
• Quantization Index Modulation — Chen & Wornell, IEEE TIT 47(4):1423-1443（2001） — QIM と、容量・不可視性・頑健性のトレードオフの定式化
• C2PA（Coalition for Content Provenance and Authenticity） — 来歴メタデータの業界標準
• EU AI Act 第50条（透明性義務） — 機械可読マーキングの法的根拠
• Guidelines on transparency obligations for providers and deployers of AI systems — 欧州委員会（2026-07-20） — 第50条の適用範囲・例外の公式ガイドライン