AIテキスト電子透かしの仕組み｜EU AI Act第50条と各社の対応の現在地

こんにちは、株式会社TIMEWELLの濱本です。

最近、「Claudeがスカッシュを入れた」という話をよく聞きます。音声入力だと「透かし」が「スカッシュ」になりやすい。たぶん電子透かしの話でしょう。画面には何も出てこない。なのに、コピーして別の場所へ持っていくと、機械だけが読める印がついて回る。そういう仕組みが、2026年8月からClaudeの新しいモデルに入り始めました¹。

正直なところ、私も最初は「画像の透かしと同じものを、文章にも重ねたのか」と思いました。違います。文章の透かしは、ロゴを薄く置く話ではありません。次の一語を選ぶときのサイコロの目に、ごく小さな偏りを仕込む話です。今日はその偏りがどう作られ、なぜ今になって実装が一気に動いたのか、そしてChatGPTやGrokの出方が遅れた理由を、研究側の一次情報も踏まえて書きます。

自社が生成AIをどこまで使いこなせているかを先に棚卸ししたい方は、AIリテラシー診断で現在地を見てから読むと、後半の「現場で何を信じるか」が自分の話として立ち上がります。

初版（8月13日）から変わったこと

2026年11月6日に読み直し、次の点を更新しました。ひとつ目は、OpenAIの動きです。2026年10月5日に、EU向けのChatGPTとCodexへテキスト透かしを入れると発表しました。8月時点ではChatGPTのテキスト透かしは未導入でしたが、いまは「EU向けに順次開始」へ変わっています。ただし実際に各ユーザーへ届いているかは、本稿では確認できていません。

ふたつ目は、Claudeの検出器です。広く公開されたわけではなく、非公開プレビューの段階です。みっつ目は、EUの行動規範の署名者ページが9月24日に更新され、9月からタスクフォースが動き出した点です。既存モデルの猶予期限（2026年12月2日）は変わらず、残り1か月を切っています。

この記事は技術と公開情報の整理であり、法律上の助言ではありません。自社の義務は、法務や専門家に確認してください。

きっかけはClaude。背景はEUの透明性義務

Anthropicのヘルプセンターは、かなりはっきり書いています。2026年8月2日以降に欧州へ投入するClaudeの新モデルは、初日時点で機械可読なマークを付ける。生成テキストには埋め込み透かしを、対応するファイルにはデジタル署名付きの来歴メタデータを付ける。対象はClaude本体だけでなく、API、Claude Code、Claude Cowork、Claude Tag、クラウド経由まで。地域も欧州限定ではなく、Claudeが提供される場所すべてです¹。同ページの注記には、Amazon Bedrockでの展開が11月10日までに完了する予定であること、Sonnet 4.6では温度などのサンプリング設定を既定から変えると、透かしが確実に載らない場合があることも書かれています。

既存モデルには猶予があります。2026年8月2日より前に市場へ出ていた生成AIは、機械可読マーキングの適用が2026年12月2日まで延びています。Anthropic自身も、古いモデルへの後付けを進めていると書いています¹。この猶予は、EUのAI Actを簡素化する改正（Digital Omnibus）で決まったと解説されています。官報の原文は今回確認できていないため、期限は公式の説明と複数の解説で読み取った範囲です。改正の中身は、Digital Omnibusの整理にまとめています。

なぜこの日付なのか。答えはEU AI Act（規則2024/1689）第50条です。第50条(2)は、音声・画像・映像・テキストを合成するAIシステムの提供者に対して、出力を機械可読な形式でマークし、人工的に生成または改変されたものとして検出可能にすることを求めています。2026年8月2日から適用です²。日本企業が域外適用される条件そのものは、EU AI Actの一般適用日に向けた整理に書きました。今日は、そのうち「マークせよ」という一文が、技術の世界で何を動かしたかに絞ります。

ここで大事なのが、条文は「透かしを入れよ」とは書いていないこと。技術中立です。前文133項は、透かし、メタデータ識別子、来歴証明のための暗号技術、ログ、フィンガープリントなどを例示しています。求められるのは「技術的に実行可能な範囲で、有効・相互運用可能・堅牢かつ信頼できる」こと。攻撃耐性の完全性までは求めていません²。

2026年6月10日には、欧州委員会とAI Officeが「AI生成コンテンツの透明性に関する行動規範」の最終版を出しました。7月末までに約190の組織が署名しています。第1部（提供者側）の例として名前が出ているのは、Aleph Alpha、Anthropic、Black Forest Labs、Cohere、Google、Meta、Microsoft、Mistral、OpenAI、Synthesiaなどです。xAIの名前は、2026年9月24日更新の同ページにも見当たりません³。署名者は9月から、ベストプラクティスの共有などを行う2つのタスクフォースに参加できます。署名は任意です。第50条の義務は、署名しなくても残ります。

制裁金の話も、条文を分けて読む必要があります。AI Act全体の上限は3,500万ユーロまたは全世界売上高の7%ですが、第50条クラスの義務は第99条の中段、1,500万ユーロまたは3%のほうです⁴。どちらにせよ、研究テーマだった透かしが、2026年夏に「出荷項目」へ格上げされた事情は、ここにあります。

見えない透かしは、次の一語の選び方に仕込む

AI生成文を見分ける方法は、大きく3つしかありません。Google DeepMindのSynthID-Text論文が、この整理をはっきり書いています⁵。

ひとつ目は検索です。サービス側が生成した文を全部保存しておき、あとから照合する。確実ですが、全ユーザーのやり取りを残す前提なので、プライバシーのコストが大きい。ふたつ目は事後検出です。統計や分類器で「AIっぽさ」を測る。DetectGPT系がこれです。生成側に手を入れなくてよい代わりに、英語を母語としない人の文章をAIだと誤判定しやすい、というバイアスが繰り返し報告されてきました。モデルが上手になるほど、人間との差も縮みます。この「AIっぽさ」で判断する難しさは、AI文章の「きもい」問題でも書きました。

三つ目が透かしです。生成の瞬間に信号を埋め込む。介入が必要な代わりに、検出は統計として説明できます。モデル本体を渡さなくても、秘密鍵とトークナイザがあれば第三者が検証できる設計もあります。

2023年のKirchenbauerらの論文が、いまの実務語彙をつくりました。LLMは次のトークン（語の破片）を選ぶとき、語彙全体に確率を付けます。そこで直前のトークンと秘密鍵のハッシュを乱数の種にして、語彙をグリーンリストとレッドリストに分けます。グリーン側のトークンの点数を、ほんの少しだけ底上げしてからサイコロを振る。検出する側は同じ鍵でリストを再現し、グリーンが何個入っているかを数えます。透かしがなければグリーンの割合はだいたい半分。入っていれば有意に増える。この差をz統計量として出せるので、「AIっぽさ80%」ではなく「これが偶然である確率は100万分の1未満」と言える、というのが設計の売りです⁶。

比喩をひとつ。文章の透かしは、紙に薄いロゴを刷る作業ではありません。カジノのサイコロに、目に見えない偏りを仕込む作業です。1回では分かりません。何十回も振ると、6の目が多すぎることに気づく。検出器はその偏りを数えているだけです。

だから、次の語がほぼ1つに決まる場所には埋められません。論文が挙げる例が分かりやすくて、「Barack」の次はほぼ確実に「Obama」です。ここを無理に別の語へ寄せると、文が壊れます。透かしはモデルの「迷い」に寄生します。迷いが少ないほど、信号は弱くなる。この制約を、論文はスパイクエントロピーという指標で定式化しています⁶。コードや固有名詞の連続、短い挨拶文が弱いのは、このせいです。

Google DeepMindのSynthID-Textは、同じ乱数源の上でサンプリングのやり方を変えています。トーナメント方式です。語彙の中から候補を何回も出し、秘密の採点関数で勝ち抜き戦を繰り返す。勝ち残った語は、秘密の点数が高い傾向がある。検出側はその平均を見ます。標準設定は30層です。Geminiの本番トラフィック約2,000万件で、サムズアップ率の差は0.01%、レイテンシの増加は0.57%。品質をほぼ落とさずに大規模へ載せられる、というのがこの論文の本丸です⁵。

BerkeleyのMark My Wordsは、方式を品質・検出に必要な長さ・改変耐性の3軸で殴っています。実務でよく使う温度の範囲なら、Kirchenbauer型がいちばん強く、英語でおよそ40語、50〜60トークンあれば検出できる。一方でコード生成では正答率が落ち、検出も不安定になる。GPT-3.5による言い換えは、最良の方式でも6割以上の確率で透かしを落とす、という数字も出ています⁷。

Anthropicが採用したアルゴリズムの中身は、本稿執筆時点では公開されていません。グリーンリストなのかトーナメントなのか、別の方式なのか。ヘルプは「テキストそのものに織り込む」「意味や品質は変えない」「コピーしても残ることがある」としか書いていません¹。ただ、2023年以降の研究が共有している骨格は同じです。特殊文字を隠すのではなく、語の選び方の統計に信号を持たせる。

ファイル側は別物です。Claudeが出力するSVG、PNG、JPGなどには、C2PAという業界標準の署名メタデータが付きます¹。これはテキスト透かしではなく、ファイルの封筒に来歴を書く方式です。画像をスクリーンショットすると落ちやすい。だから二層にする、というのが欧州の行動規範の読みでもあります。

ChatGPTとGrokは、なぜ遅れたのか

8月時点では「ChatGPTは入れていないのに、Claudeだけ先に出した」と読まれがちでした。善悪の話にすると見誤ります。各社が抱えている制約が違う、というのが一次情報から読める範囲です。

OpenAIは2024年5月の公式ブログで、テキスト透かしの手法をすでに持っていると書いています。8月の追記では、局所的な言い換えには強い一方、翻訳、別の生成モデルでの書き直し、単語のあいだに特殊文字を挟んで後から消す、といった全体改変には弱い、と認めています。悪意ある相手には簡単に外せる、という評価。もうひとつ、英語を母語としない人が作文の補助として使うケースを、透かしが不当に汚名にする恐れがある、とも書いています⁸。優先順位は当時、偽情報がより危険と見られていた画像と音声でした。

2026年8月時点のヘルプでは、画像はC2PAメタデータとSynthID透かしの両方、音声はSynthID、テキストは「すべてのモダリティへ広げるのが目標」と書いてあるだけで、出荷の記述はありませんでした⁹。ここまでが初版の内容です。

その後、状況が動きました。OpenAIは2026年10月5日、EU向けのChatGPTとCodexで生成されるテキストに、目に見えない透かしを入れると発表しました。方式の名前はtextGrainで、モデルの語の選び方に統計的な信号を持たせます。ChatGPTとCodexは全プランの対象ユーザーに今後数週間かけて順次で、EUのみです。APIは、対象モデルについて世界中の開発者が選択して有効にでき、初期状態はオフ。少なくとも発表時点では、全世界の既定にはしないとしています¹⁰。

限界も、OpenAI自身が先に書いています。透かしが示せるのは「OpenAIのシステムがその文章の一部を生成または処理した」ことまでで、利用者の特定、人の貢献の度合い、著作権、内容の正確さは示せません。透かしがないからといって、人が書いた証明にもなりません。短い文章や、あとからの編集で検出は不安定になります。検出器は当面、承認された研究者と専門組織に限って提供されます¹⁰。報道では、OpenAIの試験で単語の1割を類義語に置き換えると、検出率が約92%から約66%に下がったとされています¹¹。

私は、これでAnthropicとの違いがはっきりしたと思います。Claudeは全世界で入れました。OpenAIはEUのChatGPT・Codexに限り、APIは選択式にしました。どちらが正しいという話ではなく、規制の求める範囲をどこまでと読むか、非EUの利用者にどう説明するかの設計差です。OpenAIが2024年に懸念した「英語を母語としない人への汚名」にどう向き合ったかは、発表の全文が取得できなかったため、本稿では判断しません。

提供者ごとに印の有無や範囲が違うと、社内の線引きも揃わなくなります。「どのAIに何を入れてよいか」を決める作業は、シャドーAIを前提にした社内ポリシー設計が出発点になります。

なお、署名と実装は別の話です。OpenAIは行動規範の署名者でもあります³。第50条は技術中立なので、透かし以外の機械可読な手段も認められています。「テキスト透かしを入れない＝違法」とも、「入れた＝規制を満たした」とも書けません。

Googleは2024年の時点で、SynthID-TextをGeminiに載せて論文まで出しています⁵。実装はオープンソースで、Hugging Face Transformersのv4.46.0以降で使え、検出器は「透かしあり・なし・不確か」の3値で返します。Googleの開発者向け文書も、事実関係の回答は語の選択の余地が小さく効きにくいこと、大幅な言い換えや翻訳で検出の確度が大きく下がること、意図を持った攻撃者を直接止めるための仕組みではないことを明記しています¹²。テキスト透かしの本番運用は、実はClaudeが世界初ではありません。大規模に載せて数字を公開したのはGoogleのほうが先です。2026年8月に話題になったのは、対話型アシスタントとして日本でも日常使いされているClaudeが、チャットの本文そのものに印を入れ始めた、という体感のほうだと思います。

Grok側は、公式の説明がまだ薄い。欧州委員会の署名者ページ（2026年9月24日更新）にxAIの名前は見当たりません³。Anthropicのような「テキストに埋め込み透かしを入れる」ヘルプも、本稿執筆時点では見当たりません。ここから先は推測を混ぜないほうがいい。未署名だから義務がない、わけではありません。EU向けに生成AIを出していれば第50条は残ります。署名は「適合を示しやすい道」であって、義務そのものの免除ではありません。xAIが別の手段でマークしているのか、既存モデルの猶予期間を使っているのか、これから出すのか。公開情報だけでは切り分けられません。

私の見立てでは、OpenAIが2024年に見送った本体は「技術が未完成」ではなく、「テキストは画像より嘘をつきにくい」ことです。画像の透かしは画素に信号を散らせます。テキストは語の選択肢そのものが狭く、言い換え一発で統計が崩れます。OpenAIが2024年に書いた懸念は、2024年のMark My Wordsや透かし窃取の論文と、方向が同じです。Jovanovićらは、公開APIを限られた回数叩くだけで秘密の透かし規則を近似でき、費用は50ドル未満、除去成功率は80%超まで跳ね上がると示しました¹³。Zhangらは、自然な仮定の下では強い意味での透かしは不可能だ、と証明しています¹⁴。

だから「先に出した会社が正しく、出していない会社が怠慢」という構図は、私は取りません。先に出した会社は規制カレンダーに合わせ、限界の説明までセットで出している。遅れて出した会社は、壊れ方を知ったうえで、範囲を絞った出し方を選んだように見えます。いずれも、公開情報の範囲では説明として成立します。

透かしが消える場所、効かない場所

Anthropic自身が、限界を先に書いています。検出されても、Claudeが原著者だとは限らない。校正、翻訳、要約、ファイル変換だけ頼んでも印が付く。検出されなくても、AI生成ではないとは限らない。古いモデル、大幅な編集、翻訳、別の文章との混合、短すぎる文、ファイルメタデータの剥離。どれも「印なし」になります¹。

研究側の地図と重ねると、現場で効かない場所はかなりはっきりします。短文。コード。固有名詞の連続。構造化されたJSON。決意した攻撃者による言い換え。オープンウェイトモデルをローカルで回した出力。後者には、原理的に提供者の透かしを強制する手段がありません。SynthID-Textの論文自身が、この限界を認めています⁵。

逆に、効く場所もあります。カジュアルなコピペの抑止。プラットフォーム側での大規模な自動振り分け。自社が自社モデルの出力を後から拾う来歴管理。機械可読マーキングを実装する具体策のひとつ、という使い方。宿題を楽したい学生が、翻訳して別モデルで書き直して特殊文字を挟む、という手数を踏む動機は薄い、というのがMark My Wordsの割り切りです⁷。完全な防御ではありません。摩擦としては働きます。

透かし窃取の論文が厄介なのは、除去となりすましが同時に可能になる点です。攻撃者がヘイトスピーチに「その会社の透かし」を付けて流せば、提供者へ責任が誤帰属されます¹³。透かしは本人確認ではありません。シートベルトに近い、と私は思っています。事故を防ぐ装置ではないのです。なければ被害が確実に大きくなる種類の仕組みでしょう。

日本語の文章では、英語の研究数字をそのまま信じすぎないほうがいい、とも感じています。トークン化の単位が違う。助詞ひとつで区切りが変わる。50〜60トークンで検出できる、という英語の数字が、日本語で何文字に相当するのかは、公開ベンチマークがまだ薄い。Claudeの検出器が出てくるまで、現場は「長い本文ほど残りやすく、短い返信ほど消える」くらいの粒度で見るのが誠実だと思います。

現場が持つべき期待値は「シートベルト」

では、企業の側はどう構えるか。私なら、透かし単体を監査の根拠にしない、から始めます。採用書類、論文、プレス、顧客向け文書。どれも「検出器が反応した／しなかった」だけで人事や法務の結論を出すべきではありません。短文は反応しない。校正しただけでも反応する。両方とも公式に書いてあることです¹。

代わりに持つべきは二層です。テキスト側の統計的な印と、ファイル側の署名メタデータ（C2PA）。欧州の行動規範が推しているのも、この重ね方です。画像や資料を社外へ出す経路では、スクリーンショットや再保存でメタデータが落ちないかを先に見たほうがいい。テキストは、どのモデルで、いつ、どのプロンプトで出したかを、社内のログとして残す。透かしはその補助です。主記録ではありません。

生成AIの文章が「AIっぽい」かどうかで判断する時代は、すでに終わりつつあります。先に触れたとおり、上手なモデルほど人間との差は縮みます。事後検出器の誤判定が、英語非母語話者を傷つけてきた歴史もあります。だから提供者側が生成時に印を入れる方向へ動いた。その判断自体は、私は妥当だと思っています。ただし印の意味を過大評価すると、次の事故が起きます。透かしがある文章を「悪い文章」として扱う空気です。OpenAIが2024年に恐れたのは、まさにそこです⁸。

個人的には、2026年後半の焦点は「誰が先に透かしを入れたか」ではなく、「検出結果を誰が、何に使ってよいか」の合意形成だと思っています。大学、採用、報道、プラットフォーム。用途ごとに偽陽性のコストが違います。行動規範のタスクフォースは、2026年9月から動き始めています³。そこに実務の言葉を乗せる側に、日本企業も立ったほうがいい。日本では、総務省と経済産業省の「AI事業者ガイドライン」が2026年3月に第1.2版へ改定されたと報じられています。ただ、透かしや来歴の扱いが本文でどう書かれているかは、今回確認できていません。自社の方針を決める際は、原文で確かめてください。

生成AIの出力を社内でどう扱い、どこまで人間が責任を持つか。そこの設計が、透かしより先に要る仕事です。TIMEWELLのWARPでは、モデルの選定やプロンプトの話だけでなく、出力の来歴を残す運用、社内ルール、人材側のリテラシーまで含めて伴走しています。「検出器を入れれば終わる」話ではない、と感じている方は、個別相談から話してください。

見えない印は、これから普通のインフラになります。普通になったあとで効くのは、印そのものより、印をどう読むかの作法のほうです。

参考文献

Footnotes

1. Anthropic, How Claude marks AI-generated content（Claude Help Center） ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

2. Regulation (EU) 2024/1689, Article 50 / Recital 133 ↩ ↩²

3. European Commission, Strong backing for the Code of Practice on Transparency of AI-generated Content（2026-07-31公表、2026-09-24更新） ↩ ↩² ↩³ ↩⁴

4. Regulation (EU) 2024/1689, Article 99 ↩

5. Dathathri, S. et al. (2024). Scalable watermarking for identifying large language model outputs. Nature 634, 818–823. DOI: 10.1038/s41586-024-08025-4 ↩ ↩² ↩³ ↩⁴

6. Kirchenbauer, J. et al. (2023). A Watermark for Large Language Models. ICML 2023. arXiv:2301.10226 ↩ ↩²

7. Piet, J. et al. (2025). Mark My Words: Analyzing and Evaluating Language Model Watermarks. IEEE SaTML 2025. arXiv:2312.00273 ↩ ↩²

8. OpenAI, Understanding the source of what we see and hear online（2024-05-07、2024-08-04更新） ↩ ↩²

9. OpenAI Help, Provenance signals (Content Credentials, SynthID) in OpenAI-generated content ↩

10. OpenAI, Our approach to EU text provenance rules（OpenAI Developer Community、Announcements、2026-10-05）。openai.com 上の本文は取得できなかったため、公式フォーラムの投稿で確認した ↩ ↩²

11. TechCrunch, OpenAI will start watermarking ChatGPT's text in the EU（2026-10-05）。類義語置換の数字は報道が伝えるOpenAIの試験結果で、一次資料では確認していない ↩

12. Google AI for Developers, SynthID Text ↩

13. Jovanović, N., Staab, R., & Vechev, M. (2024). Watermark Stealing in Large Language Models. ICML 2024. arXiv:2402.19361 ↩ ↩²

14. Zhang, H. et al. (2024). Watermarks in the Sand: Impossibility of Strong Watermarking for Generative Models. ICML 2024. arXiv:2311.04378 ↩