「AIが作った」と分かれば十分?─ECで考える生成コンテンツの「作成履歴」

はじめに
GDX株式会社でAIリサーチを担当しているMia Sato(佐藤ミア)です。
商品説明、広告文、SNS投稿、カスタマーサポートの返信、商品画像など、EC業務でも生成AIを使う場面が増えてきました。
私自身も、文章の下書きや翻訳などでAIを使っています。
そんな中、最近気になったのがAnthropicが発表したClaudeの「テキストウォーターマーク」です。
人には見えない形で文章に特徴を残し、あとからClaudeが関わった可能性を判定できる仕組みです。
最初は、「AIが書いた文章を見分けるための機能なのかな」と思っていました。
でも調べてみると、同じ方向に動いているのはClaudeだけではありませんでした。
「AIが作った」と分かる仕組みは、すでに広がっている
主要なAIサービスでは、さまざまな方法でAI生成コンテンツの来歴を残そうとしています。

方法は違いますが、共通しているのは、「このコンテンツがどこから来たのか」を後から確認できるようにすることです。
GoogleのSynthIDは生成物そのものに見えないウォーターマークを埋め込み、OpenAIやAdobe、MicrosoftもC2PAなどを使って、作成・編集の来歴を残す方向に進んでいます。
なぜ、AIの「印」が必要なのか
一つは、AIで作られたコンテンツが普通のものと見分けにくくなっているからです。
AI生成であることが分かれば、見る側の判断材料になります。
もう一つ大きいのが法規制です。
EU AI Actの第50条では、AIで生成・加工された一部のコンテンツについて、機械で判別できる形で情報を付けたり、ディープフェイクなどではAIが使われていることを明示したりすることが求められています。
こうした透明性に関するルールは、2026年8月2日から適用されています。
AnthropicもClaudeへのウォーターマーク導入について、EU AI Actへの対応を理由の一つとして説明しています。
ただ、企業の立場ではもう一つ考える必要があります。
「AIが作った」と分かれば、それで十分なのでしょうか。
「AIが作った」は、企業の免責にはならない
例えばECの商品ページに、「このジャケットは防水素材を使用しています」と書かれていたとします。
でも実際には、防水商品ではなかった。
あとからAIが生成した文章だと分かっても、それだけで問題は解決しません。
企業の商品ページとして公開している以上、「AIが書いたので仕方ない」とは言えません。
日本でも、商品の品質や規格について、実際よりも著しく優れていると受け取られるような表示は、景品表示法上の「優良誤認表示」にあたる可能性があります。
つまり、「AIが作った文章だった」ということだけで問題がなくなるわけではありません。
企業として、最終的に消費者にどのような情報を表示しているかを確認する必要があります。
だから私は、ウォーターマークやコンテンツの来歴情報を、責任をAIに移すためではなく、企業がリスクを管理するための手がかりとして使う方が重要だと感じました。
企業が知りたいのは「どこで情報が変わったか」
同じ「防水」という誤りでも、原因は一つではありません。
元の商品マスタに誤りがあったのか。
AIが元資料にない情報を追加したのか。
人が編集するときに内容を変えたのか。
それとも、公開前の確認で見落としたのか。
原因によって、見直すべき場所はまったく変わります。
そこで企業側では、まずAIをどの業務や工程で使っているのかを整理する必要があります。
商品情報や広告表現など重要な内容については、何を元に作ったのか、AIがどこで関わったのか、誰が確認したのかが分かる程度の履歴を残しておくとよいのではないかと思います。
例えば商品説明であれば、次のような流れです。
元の商品情報 → AIで初稿作成 → 担当者が修正 → 商品担当者が確認 → 公開
こうしておけば、問題が起きたときに「どこで情報が変わったのか」を確認しやすくなります。
その結果を、元データやAIへの指示、確認方法の改善につなげることもできます。
ただ、ここでもう一つ考えたいことがあります。
この履歴を「問題が起きた後の確認」だけに使うのは、少しもったいないのではないでしょうか。
AIを使って文章を作っても、最後に人が最初から最後まですべて確認していたら、結局、人の確認作業はあまり減りません。
そこで私は、作成履歴を残すだけではなく、「どこまでAIに任せて、どこだけ人が確認するか」を決めるためにも使えるのではないかと思いました。
毎回すべてを人が確認しないために
例えば商品説明をAIで作る場合でも、すべての内容を同じレベルで確認する必要はないと思います。
文章の体裁を整えたり、元の意味を変えない範囲で表現を統一したりする作業であれば、AIに任せてもよいかもしれません。
反対に、「防水」「100%オーガニック」といった商品性能や、価格、キャンペーン条件など、間違えたときの影響が大きい情報は、人が確認する対象としてあらかじめ分けておく方がよいと感じます。
また、普段はAIだけで処理していても、次のような条件に当てはまったときだけ、人の確認に回す方法も考えられます。
- 元資料にない情報が追加された
- 数値や価格が変更された
- 商品仕様に関する新しい表現が追加された
- 元データと生成内容に差がある
私なら、例えば次のように分けてみます。

こうすると、人がすべての文章を一から読むのではなく、「人が判断する意味があるところ」に確認作業を集中できます。
AIを使うこと自体よりも、「どこから人が入るか」まで決めておくことの方が、実際の業務効率化では重要なのかもしれません。
「確認済み」を次の工程に渡す
もう一つ必要だと感じたのが、「人が確認した」という情報を残すことです。
例えば商品担当者が仕様を確認したら、「確認済み」というステータスと、確認した人・日時を記録する。
そうすれば、その後の公開担当者が同じ内容をもう一度最初から確認する必要はありません。
AI生成 → 必要な部分だけ人が確認 → 確認済み → 公開
特に複数の担当者が関わるEC業務では、「誰が確認したか」だけではなく、「この情報はすでに確認済みなので、次の工程ではその判断を再利用してよい」と分かることにも意味があります。
つまり、ウォーターマークや作成履歴は、AI生成物を見分けるためだけのものではありません。
人が確認すべき対象と頻度を絞り、確認したものに「お墨付き」を与えて次の工程に渡す仕組みとしても使えるのではないでしょうか。
「AI生成」のラベルは、ゴールではない
Claudeのウォーターマークから調べ始めましたが、ここまで見てきたように、AI生成コンテンツの来歴を残す技術は少しずつ広がっています。
ただ、企業にとって重要なのは、「AIが関わった」と分かること自体ではなく、その情報を業務の中でどう使うかだと思います。
問題が起きたときに、どの工程で情報が変わったのかを確認する。
さらに、その履歴をもとに、人が確認すべき対象や条件を絞り、確認済みの情報は次の工程でも再利用する。
今回私は、ウォーターマークを単に「AI生成物を見分ける技術」として見るよりも、「人がどこを確認するかを設計するための手がかり」として捉える方が、企業にとっては面白いのではないかと感じました。
AIを使う業務から、AIを使うことを前提に、人の確認方法まで設計された業務へ。
AI生成コンテンツが増えていくほど、こうしたプロセス設計が重要になっていくのではないでしょうか。
参考文献(出典)
- 参考(公式):How Claude’s text watermark works/Anthropic/https://www.anthropic.com/news/claude-text-watermark
- 参考(公式):SynthID/Google DeepMind/https://deepmind.google/models/synthid/
- 参考(公式):Advancing content provenance for a safer, more transparent AI ecosystem/OpenAI/https://openai.com/index/advancing-content-provenance/
- 参考(公式):Content Credentials overview/Adobe/https://helpx.adobe.com/firefly/web/get-started/learn-the-basics/content-credentials-overview.html
- 参考(公式):Content provenance for Foundry models/Microsoft Learn/https://learn.microsoft.com/en-us/azure/foundry/responsible-ai/content-understanding/provenance-disclosure
- 参考(公式):When does enforcement start?/European Commission/https://ai-act-service-desk.ec.europa.eu/en/ai-act/faq/when-does-enforcement-start
- 参考(公式):優良誤認とは/消費者庁/https://www.caa.go.jp/policies/policy/representation/fair_labeling/representation_regulation/misleading_representation/
※本文の一部はAIの支援を受けて作成し、筆者が内容を確認したうえで加筆・修正しています。内容は筆者個人の見解であり、GDX株式会社の公式見解・声明を示すものではありません。
