Gemini画像の可視ウォーターマークとSynthIDを同じ話にしない

Geminiで画像を作って、そのままUIモックや記事サムネに使おうとすると、まず気になるのは画像の隅に入る可視ウォーターマークです。

一方で、最近はGeminiアプリ側でSynthIDの検証もできるようになってきました。ここで少しややこしいのは、どちらも「ウォーターマーク」と呼ばれがちなことです。

でも実務では、ここを同じ箱に入れない方がいいです。

• 可視ウォーターマーク: 見た目の後処理の話
• SynthID: 生成物の来歴確認の話
• metadata / C2PA: ファイルや作成経路を補足する情報の話
• asset log: 自分たちのプロジェクトで判断を残す話

この4つを混ぜると、公開前のワークフローがかなり曖昧になります。画像アセットを扱う側としては、「見た目を整える作業」と「来歴を確認する作業」を分けた方が楽です。

可視ウォーターマークはUIアセットとして普通に邪魔

たとえば個人開発のLPを作っていて、Geminiで以下のような素材を作ったとします。

• ヒーローセクション用の背景画像
• 機能紹介カードのアイコン風画像
• ブログ記事のOGP画像
• READMEに貼るスクリーンショット風の説明画像

このとき、画像の左下や右下に目立つマークが入っていると、単純にデザインとして扱いづらいです。

特にフロントエンドでは、画像をそのまま表示するだけでは終わりません。

export function HeroImage() {
  return (
    <img
      src="/assets/generated-hero.webp"
      alt="AI generated dashboard mock"
      width={1200}
      height={630}
      className="rounded-lg object-cover"
    />
  )
}

この画像がカードの角丸や余白に合わせてクロップされると、ウォーターマークだけ中途半端に残ったり、逆に変な位置で切れたりします。CSSでごまかすほど、あとで別サイズに展開したときに破綻しやすい。

なので可視ウォーターマークについては、公開前のアセット整形ステップとして扱うのが現実的です。

SynthIDは「見えない来歴シグナル」

SynthIDは、画像上に見えるロゴとは別物です。

Googleの説明では、SynthIDはコンテンツに埋め込まれる電子透かしで、ユーザーの目には見えません。Geminiアプリでは、Google AIによって生成または編集された画像、動画、音声かどうかを確認するための検証機能として扱われています。

ここで大事なのは、SynthIDを「邪魔な表示」として見ないことです。

可視ウォーターマークは見た目の問題です。SynthIDは来歴確認の問題です。目的が違う。

自分なら、チーム内の運用ではこう分けます。

レイヤー	何を扱うか	開発者がやること
可視マーク	画像上に見えるロゴやバッジ	必要なら切り出し、差し替え、可視マーク処理
SynthID	Google AI由来の不可視ウォーターマーク	Geminiアプリで検証し、結果をメモする
metadata / C2PA	ファイルや生成元の付加情報	残せるなら残す。公開時の説明にも使う
asset log	自分たちの運用記録	prompt、生成元、加工内容、公開先を書く

メタデータも透明性の材料にはなりますが、画像変換やSNS投稿で失われることがあります。SynthIDとメタデータも、同じものとして扱わない方がいいです。

original/ と publish/ を分ける

Gemini画像をプロダクトや記事素材に使うなら、未加工ファイルと公開用ファイルを分けて置くのが一番わかりやすいです。

public/
  assets/
    generated/
      original/
        hero-2026-05-16.png
      publish/
        hero-2026-05-16.webp
      asset-log.json

original/ には、GeminiやGoogle AI Studioから出した元画像をそのまま置く。publish/ には、リサイズ、トリミング、圧縮、可視マーク処理などを済ませた公開用画像を置く。

ログは小さくていいです。最初から監査システムを作ろうとすると続きません。

{
  "id": "hero-2026-05-16",
  "source": "Gemini / Google AI Studio",
  "prompt": "landing page hero image for a dashboard product",
  "generatedAt": "2026-05-16",
  "original": "assets/generated/original/hero-2026-05-16.png",
  "publish": "assets/generated/publish/hero-2026-05-16.webp",
  "edits": ["resize", "crop", "visible watermark cleanup"],
  "synthIdCheck": {
    "checkedAt": "2026-05-16",
    "result": "detected | not_detected | unclear",
    "note": "not_detected is not proof of non-AI origin"
  }
}

このくらいでも、「この画像は何を加工したんだっけ？」という会話がだいぶ減ります。

可視マーク処理はworkflowの一工程に閉じる

自分が避けたいのは、「ウォーターマークを消す」という言い方だけが独り歩きすることです。

実際の作業としては、公開用の見た目を整える工程に閉じた方がいい。

generate
  -> save original
  -> resize / crop
  -> cleanup visible mark if needed
  -> verify provenance
  -> write asset log
  -> publish

Geminiの出力から可視マークだけを外して社内モックや記事素材に回すなら、ブラウザ内で処理できる Gemini の透かしを削除するオンラインツール のような手段をワークフローの一工程として置くとよいです。

ただし、これは見た目のマークを扱う話です。SynthIDの検証や来歴管理とは別レイヤーです。ここを分けておかないと、ツール選定の話が急に危ない方向へ寄ります。

SynthIDは編集対象ではなく、検証して記録する

SynthID側の作業は、画像編集ではなく確認です。

Geminiアプリの検証機能で確認し、結果をログに残す。検出されたら、Google AI由来の可能性があるものとして扱う。検出されなかった場合も、「AI由来ではない」とは断定しない。

ここは地味ですが大事です。

type SynthIdCheckResult = 'detected' | 'not_detected' | 'unclear' | 'not_checked'

type GeneratedAssetLog = {
  id: string
  source: 'Gemini' | 'Google AI Studio' | 'Other'
  originalPath: string
  publishPath: string
  edits: string[]
  synthIdCheck: {
    result: SynthIdCheckResult
    checkedAt?: string
    note?: string
  }
}

not_detected を真偽値の false にしないのがポイントです。検出できなかったことと、AI由来ではないことは違います。

日本語圏でも、GeminiアプリでSynthID検証を試したときに期待どおり検出できないケースが共有されています。なので、検証はワークフローに入れる価値がありますが、判定を過信しない方がいいです。

公開前チェックリスト

自分なら、公開前にこのくらいを見ます。

[ ] original/ に未加工ファイルを残した
[ ] publish/ に公開用ファイルを書き出した
[ ] 可視マーク処理の有無を asset-log.json に書いた
[ ] SynthID 検証を行い、結果を記録した
[ ] not_detected を「AI由来ではない証明」として扱っていない
[ ] 公開先の規約や表示方針に反していない

すごく地味です。でも、AI画像を「便利な素材」として継続的に使うなら、この地味さが効きます。

画像生成ツールが変わっても、基本の流れはあまり変わりません。元画像を残す。公開用に加工する。来歴確認をする。判断を記録する。

まとめ

Gemini画像のウォーターマーク周りは、言葉が雑だとすぐ混乱します。

自分の整理はこれです。

• 可視ウォーターマークは、見た目の後処理として扱う
• SynthIDは、来歴確認のためのシグナルとして扱う
• metadata / C2PAは、別のprovenanceレイヤーとして扱う
• asset logで、自分たちの判断を残す

生成AIの画像を実務に入れるとき、必要なのは「全部消す」でも「何も触らない」でもないと思っています。

見た目を整える作業と、由来を確認する作業を分ける。これだけで、Gemini画像はかなり扱いやすくなります。

Source notes

• Google Gemini Help: Verify Google AI-generated images, videos, and audio with SynthID
• Google Blog: How we're bringing AI image verification to the Gemini app
• Qiita: GeminiアプリでGoogleのAIが生成した画像かどうかを見分けれるようになったので試す