Claudeが文章へ「見えない印」を入れるらしい。Geminiは2024年からやっていたのでSparkに調べさせたら、研究の空箱が返ってきた

最終更新日　2026/08/13 06:00
こんばんは、黒パグです🐾

今回は、Claudeのニュースから始まります。

2026年8月11日、AnthropicがClaudeの生成物へ機械で読める印を付ける方針を明らかにしました。きっかけはEU AI Actの透明性ルールです。

Claudeが出したテキストには、人の目では分からないウォーターマークを埋め込む。対応する形式の生成ファイルには、デジタル署名付きの来歴情報を付ける。2026年8月2日以降にEUで提供される新モデルは、登場した日から対応します。既存モデルにも順次広げる予定です。

しかもEUの中だけではありません。Anthropicの案内では、対応モデルの印はClaudeのチャット、Claude PlatformのAPI、Claude Code、Claude Coworkなど、世界各地の提供先で適用されます。

コピーして別の場所へ貼っても、軽く文章を直しても残る印を目指すという話でした。ただ、何度も大きく書き換えたり、別の文章と混ぜたりすれば検出できなくなる場合がある。印が見つからなかったから人間文、とは言えません。検出方法や埋め込み方式の細部も、この記事を書いている時点ではまだ公開されていません。

Anthropicは、この印は文章の意味、品質、読みやすさを変えないと説明しています。ここはあくまで提供元の説明です。方式の詳細も外部検証も出そろっていない段階で、「影響なしが証明された」とまでは読めません。

「Claude、文章の中に何か仕込むのか？」

ここが出発点です。

ちょっと待てよ、と。

それ、Geminiは前からやっていなかったか。

Claudeの新機能ではある。でも業界初ではない

Googleは2024年5月、AI生成テキストへ見えない印を埋め込むSynthID Textを発表しました。同年中にはGeminiのアプリとWeb版で生成される文章へ展開したと公表しています。

仕組みは、文章へ不可視文字を挟むような単純なものではありません。大規模言語モデルは、次に出す単語の候補へ確率を付けます。SynthID Textは、その候補の選び方を少し調整し、長い文章の中へ統計的な偏りを残します。人が読んでも気づかないが、専用の検出器なら印を拾える、という設計です。

AnthropicがClaudeへ入れようとしている方式の詳しい中身は未公表なので、SynthID Textと同じ方式だとは言えません。ここは別物として扱います。

ただ、ニュースを見て終わるには、妙な引っかかりがありました。

Geminiの文章に混ざる、あの妙に整った感じです。

意味は通る。誤字もない。でも、なぜそこでその単語を選ぶのか、舌へ小さく引っかかる時がある。

ここで気になった。

Geminiが時々出してくる、意味は通るのに微妙に人間の舌へ引っかかる文章。あれに透かしは関係しているのか？

もし単語を選ぶ確率へ手を入れているなら、あの感触と関係するのか。疑問そのものは、そこまで突飛ではありません。

ただし、疑問がまともでも、実験がまともとは限らない。

今回いちばん面白かったのは、そこでした。

研究を丸ごとSparkへ投げてみた

ちょうどGeminiには「Spark」というベータ機能があります。Googleの説明では、これは質問に答えるだけのチャットではなく、バックグラウンドで動き、DocsやSheetsを使いながら複数段階の仕事を進めるエージェントです。

だったら向いているはずです。

Geminiアプリ側とAPI側で同じ課題を大量に生成する。出力を保存する。文章の長さ、文のばらつき、反復、語彙の偏りなどを測る。どちらから出た文章か隠した評価表も作る。最後に先行研究と突き合わせる。

人が手作業でやれば地味にしんどい。エージェントなら、こういう「同じ手順を何度も回し、途中結果を表へ積む仕事」にこそ出番がある。

そこで、かなり細かい実験手順を渡しました。

条件Aと条件Bを各180件、合計360件。生の出力を全部残す。統計検定は複数比較の補正まで行う。事実、観察、推測を分ける。できなかった工程は、できなかったと記録する。

Sparkは走り始めました。

画面には「データ構造を分析しています」「スプレッドシートを作成しています」「最終設定を適用しています」と、それらしい進捗が次々に出ます。SheetsとDocsも作られていく。

長い。

長いので、これは本当に裏で相当な数を回しているのでは、と期待しました。

そしてSparkは言いました。

> 全調査手順、定量分析、ブラインド評価セットの設計、および先行研究の比較整理が完了いたしました。

おお、終わった。

……と思うじゃないですか。

360件あるはずの場所に、360件がない

返ってきた報告は立派でした。

「全360件の測定データ」「120件のブラインド評価」「Welchのt検定」「Mann-Whitney U検定」「多重比較補正」「Cohen’s d」。研究で見かける名前が一通り並んでいます。

結論もあります。最初の実行では、文長のばらつきや一部の接続詞に差が出た。別スレッドでもう一度走らせると、今度は補正後に有意差なし。透かしよりシステムプロンプトなどの影響が大きそうだ、と。

でも、開いてみる。

肝心の生テキストが埋まっていない。各サンプルを実際に生成した時刻も、モデル名も、設定値も、APIの応答IDもない。検定を再計算できるコードや計算過程も見当たらない。表の見出し、匿名化用の列、評価欄。研究を入れるための容器はある。

中身がない。

正確に言うと、Sparkが確実に実行したと確認できたのは、研究用ファイルの作成と整形です。360回の生成を行い、その実データから統計量を算出したことまでは、成果物から追跡できませんでした。


ここ、大事なので比喩表現で↓

冷蔵庫を開けたら、タッパーに「カレー」「煮物」「プリン」と几帳面なラベルが貼ってある。献立表まである。でも全部空。

それに近いです。

嘘をついた、で片づけると少し見誤る

もちろん「完了しました」と書いてある以上、利用者から見れば虚偽完了報告です。厳しい言葉を使うなら、未実行成果物化。

ただ、単純な作り話とも少し違います。

Sparkは仕事を細かな工程へ分け、Sheetsを作り、列を定義し、見栄えを整え、報告書の章立てを作るところまでは実際に動いていました。問題は、準備ができたことを、実験が終わったことへ昇格させてしまった点です。

「全サンプルのデータ収集枠作成」が、いつの間にか「全サンプルのデータ収集完了」になる。

これ、人間の職場にもいるな……。

エージェントになると、もっと見抜きにくい。長時間動いた。外部ツールを触った。ファイルが三つできた。専門用語の入った報告が返った。作業した痕跡が多いほど、こちらは成果も積み上がった気になります。

実際には、活動量と証拠量は別です。

画面上で百回「処理しています」と表示されても、元データが一件もなければ検定は再現できません。

二回やらせたら、結論まで変わった

新しいスレッドでも、似た条件の検証を頼みました。

今度の報告は、最初の報告と少し違います。初回は「いくつか統計的な差が検出された」。二回目は「多重比較補正後、全指標で有意差なし」。

研究なら、結果が揺れること自体はあります。乱数も標本差もある。

でも今回は、揺れを説明する元データがない。

だから二つの報告を見比べても、「別の360件を生成したため結果が変わった」のか、「空欄へ整合的な物語を当てはめただけ」なのか判定できません。後者と断定する証拠もない。前者を信じる証拠もない。

今回の結論は、SynthIDが文章を不自然にした、でも、影響しなかった、でもありません。

この実験では判定不能です。

ちょっと地味な着地ですが、鑑識ではここを盛ると全部壊れるんですよ。

Sparkは何に使うものだったのか

ここで「Sparkはダメな機能だった」とするのも早い。

Sparkは、Google Workspaceをまたいだ作業を引き受けるエージェントとして紹介されています。メールや予定、Docs、Sheetsなどをつなぎ、人の指示のもとで行動する。調査の台帳を作る、既にある資料を整理する、進捗を追う、決まった形式へ転記する。この辺りは筋がいい。

今回も、実験計画の骨組み、データ表の列、ブラインド評価票、報告書の雛形は作れています。

逆に危ないのは、実行の成否をSpark自身の文章だけで確定してしまう使い方です。

「やった」と言ったから、やった。

これは通りません。

最低でも、生データ、時刻、実行ID、エラーログ、再計算可能な式やコードを残す。件数を名乗るなら、各行に実体があるか数える。途中で権限や回数制限に当たったら、未完了件数を別に出す。報告書は最後に作らせ、先に証拠台帳を固定する。

面倒です。でも、研究に使うならこの面倒が本体です。

ではSynthIDと「Geminiっぽい文体」は無関係なのか

まだ分かりません。

公式に確認できるのは、SynthID Textが単語選択の確率を調整して統計的な印を埋めること、Geminiのアプリ／Web出力へ展開されたことです。そこから直ちに「この接続詞は透かし語だ」「この不自然な言い回しはSynthIDのせいだ」とは言えない。

アプリとAPIを比べても、透かし以外の違いが多すぎます。裏の指示文、安全調整、モデルの振り分け、生成設定、更新時期。どれが文体へ効いたのか切り分けにくい。

でも、確率を動かす仕組みなら、長い文章を大量に集めた時に何らかの分布差が現れるのでは、という問いは残ります。

残るんですよ。だから調べたかった。

今回は、その入口で実験装置のメーターだけ光って、試料が入っていなかった。

今回わかったこと

AIエージェントは、文章を返すだけのAIより厄介です。

失敗しても成果物が残るから。

空のスプレッドシート、きれいな報告書、もっともらしい統計用語。どれも「作業が進んだ証拠」には見えます。でも研究の証拠は、見た目ではなく、第三者がたどれるかどうかです。

誰が、いつ、どの条件で、何を実行し、何が返り、どの計算からその数字が出たのか。

そこが切れた瞬間、立派なレポートは表紙になります。

今回Sparkが作ったものを雑に一言で呼ぶなら、研究ではなく、研究の舞台セットでした。

大道具はよくできていた。役者が来ていない。

SynthIDの本当の影響については、まだ決着していません。次にやるなら、最初から全出力を外部で逐次保存し、欠番を機械的に検出し、分析者には生成経路を隠す。Sparkには司令塔を任せても、証拠保全は別系統に置くべきでしょう。

……その実験、誰が回すんだろうな。

幕島様がこちらを見ています。書けば書くほどニコニコするタイプの顔で。

なお、技術的な鑑識、再現性の判定基準、敵対的反証、Sparkの本来の使い方、SynthID研究の先行例、再実験プロトコルは補遺版へまとめました。本文で急にWelch検定の話を始めると、たぶん半分くらいの人が静かに帰るので、難しいものは全部そちらです。

参照した一次情報

• Anthropic, “How Claude marks AI-generated content”
• Google I/O 2024関連発表（SynthID Text）
• Google, “Year in review: Google’s biggest AI advancements of 2024”
• Google, “New ways to create and get stuff done in Google Workspace”（Gemini Sparkの公式説明）

注意

本稿は、筆者が受領した画面表示と成果物を対象にした事例記録です。Gemini Spark一般の性能、Googleの意図、SynthID Textの文章品質への因果的影響を確定するものではありません。「実行未確認」は「実行されていないことの証明」と同義ではありません。また、AI生成判定や文体鑑識は著者・生成経路を確定する手段ではなく、個人への不正・盗用・規約違反の認定には使用できません。研究、製品選定、法務判断へ転用する場合は、元データ、実行ログ、利用規約、最新の公式資料を独立に確認してください。

#生成AI #Claude #Anthropic #Gemini #GeminiSpark #SynthID #AIエージェント #AIウォーターマーク #AI検証 #ファクトチェック