Skip to Content
Docs06. セキュリティ生成物の来歴と検出

この記事の音声は準備中です。

音声の一覧・再生リストへ

生成物の来歴と検出

この記事の目的

「AI 製かどうか」を扱う 2 つのアプローチ — 来歴(作成時に証明を付ける)と検出(後から判定する)— の仕組みと限界を理解し、組織の運用を設計できるようになります。来歴標準(C2PA / Content Credentials)と電子透かしの仕組み・剥がれ方、検出の限界(「検出器で断定しない」原則)、組織での運用(自社生成物への来歴付与・受け入れコンテンツの検証)を持ち帰れる状態を目指します。標準・各社機能は変化が速いため、本記事は仕組みと限界の読み方に徹します。

対象読者

  • 生成 AI を使う組織で、生成物の透明性・来歴表示の運用を設計するセキュリティ・ガバナンス担当
  • 「AI 検出ツール」の導入を検討していて、その限界を正しく踏まえたいテックリード

前提知識

本文

概要: 来歴と検出は「別レイヤー」

「このコンテンツは AI 製か」を扱う手段は 2 つあり、まったく別のものです。混同すると設計を誤ります。

アプローチ何をするかいつ
来歴(provenance)作成・編集の履歴を証明として付ける作成時(前もって)
検出(detection)AI 由来かを後から推定する事後(あとから)
  • 来歴は「履歴の検証」: 誰が・どのツールで・どう編集したかの履歴を、検証可能にします。「AI 生成か否かそのもの」を証明するのではありません
  • 検出は「AI 由来かの推定」: できあがったコンテンツから AI 由来かを推定します。後述のとおり限界が大きい手段です
  • 両者は別レイヤーで、来歴があっても検出の代わりにはならず、逆もまた然りです

最終確認日: 2026-09-10。 本記事で触れる来歴標準の版・各社の透かし機能・検出ツールの提供状況は変化が速いため、ISO の段階と Claude の追加例は「2026-09-10 時点」のスナップショットとして読み、採用時は各標準団体・各社の公式ページで再確認してください(後述の「変わりやすい項目」)。

来歴の仕組み: コンテンツ資格情報と電子透かし

来歴を実現する仕組みは、大きく 2 種類 — 付随メタデータ型と信号埋め込みテキストや画像を、意味的な近さが距離に対応する数値ベクトルに変換したもの。RAG・記憶・分類の土台で、「何が近いか」はモデルで変わるため自社データで評価して選ぶ。モデル変更は全チャンクの再インデックスを伴う。型です。

  • コンテンツ資格情報(C2PA / Content Credentials): 来歴(provenance) を記録する業界標準です。作成・編集の履歴を署名付きのメタデータ(マニフェスト)として記録し、暗号署名で改ざん検知可能にします。公式は「デジタルの栄養成分表示ラベル」と説明します(仕様の公開と ISO 国際規格の成立は別段階です)。ただし後述のとおり剥がれます
  • 電子透かし(watermarking): 電子透かし(watermark) は、コンテンツの信号そのものに情報を埋め込みます。人に見える可視透かし(ロゴ等)と、人には知覚できない不可視透かしがあります。信号に埋め込むため、メタデータ剥離や再エンコードに相対的に強いとされます(ただし堅牢性の主張はベンダーの自己申告で、除去不能を保証するものではありません)
  • 補完関係: メタデータ型(改ざん検知が強いが剥がれやすい)と信号埋め込み型(剥離に強いが堅牢性は自己申告)は競合でなく補完です。両者を冗長に組み合わせる方向(耐久性を高めた来歴)が進んでいます

2026-09-10 の ISO 公式表示は ISO/CD 22144、Under development、stage 30.99(CD approved for registration as DIS) です。これは DIS 登録に向け承認された委員会原案(CD)の段階で、発行済み国際規格ではありません。段階履歴の 2024-10-28 を今回の確認日と混同しないようにします。

具体例として、Anthropic は 2026-09-01、Claude Fable 5.1 / Mythos 5.1 の生成テキストに自社のテキスト透かしが付くと公表しました。一方、コード実行ツールが生成した対応する画像・動画・音声ファイルには、Claude API の Files API で取得したとき C2PA Content Credentials が付きます。テキスト透かしとファイルの C2PA は異なる方式であり、全生成物に C2PA が付くと一般化しません。

採用時は「媒体・生成モデル/ツール・取得 API・後工程」を表にして、対象の経路で来歴が付与されるかを確認します。さらに変換・保存・配信後の成果物で署名を検証し、付与時点だけで確認を終えないようにします。

来歴の剥がれ方

来歴運用で最も重要な理解は、来歴は失われることです。「来歴を付けたから安全」ではありません。

  • メタデータは除去される: 付随メタデータは、意図的にも偶発的にも除去されます。スクリーンショット・画面の再撮影・再エンコード・プラットフォームへのアップロードで、埋め込まれた情報が剥がれることがあります
  • 編集で無効になる: 対応ツールで再署名しない編集をすると、来歴が正しく引き継がれず無効になります
  • 冗長化が対策: この脆さを補うため、メタデータ + 電子透かし + 指紋(コンテンツ自体から生成する知覚的なコード)を組み合わせて冗長化し、一部が失われても来歴に辿れるようにする方向があります
  • 設計への含意: 「来歴が付いている = 信頼できる」でも「来歴が無い = 偽物」でもありません。来歴が無いことは、剥がれただけかもしれない。来歴の有無を単独の判断根拠にしないことが肝心です

検出の原理と限界

「AI 検出ツール」への期待は大きいですが、限界を正面から理解する必要があります。

  • 検出は確率的: 検出器は「AI 由来らしさ」を推定するもので、誤判定を伴います。偽陽性(人間の制作物を AI 製と誤判定)と偽陰性(AI 製を見逃す)が起きます
  • 偽陽性が特に危険: 偽陽性は、実在の人間の制作物・本人を「AI 製/偽物」と誤って断罪するリスクです。学生の作文・従業員の成果物を誤って AI 製と判定すれば、重大な不利益を与えます
  • 回避との軍拡: 検出器は回避手法(テキストの言い換え、画像・音声への微小な改変・再エンコード等)といたちごっこの関係にあります。生成が高度化するほど検出は難しくなります
  • 「単一の万能策はない」: 公的な技術指針(NIST の合成コンテンツに関する報告など)も、単一の万能策は存在せず、技術・人的監督・規範・リテラシーを組み合わせた多層的な対処が要ると整理しています。開発元自身が自社の AI テキスト検出器を精度不足で撤回した例もあります
  • 検出器で断定しない: 以上から、検出結果を「AI 製である/でない」の断定に使わないのが原則です。検出は確率的な補助シグナルとして扱い、来歴・文脈・別チャネルの検証と併用します(検出ツールの「精度◯%」という性能主張は、ベンダーの自己申告として受け取ります)

組織での運用

来歴と検出を、組織の運用に落とし込みます。限界を踏まえた現実的な設計です。

  • 自社生成物への来歴付与: 自社が生成する画像・動画・音声・文書に、来歴(Content Credentials)や透かしを付与します(画像生成のプロダクト組み込み・動画生成・理解の概観の来歴と同じ論点)。「生成物であること」を示す責任を果たします
  • 受け入れコンテンツの検証プロセス: 外部から受け入れるコンテンツの真偽が重要な場面では、来歴の確認・別チャネルでの裏取りをプロセスにします。検出ツール 1 つに依存しない設計です
  • 規制上の表示義務との接続: 生成物の表示義務(AI 製であることの明示など)が課される場合、来歴付与の運用を規制要件と接続します(コンプライアンスとガバナンス)。義務の有無・内容は地域・用途で異なり変化も速いため、規制の入口(業界別規制マップ)で確認します
  • 断定でなくプロセスで: なりすまし・偽情報への対処は、検出での断定でなくプロセス(来歴の確認・別チャネル検証・人の判断)で守ります(ディープフェイク・なりすましへの防御)

変わりやすい項目(定点観測)

本記事のうち、次は変化が速く、四半期ごと(および改訂時)の再確認が必要です。

  • 来歴標準(C2PA / Content Credentials)の版・国際標準化の状況
  • 電子透かしの対象拡大・堅牢性の主張(2026-07 時点で不可視透かしの提供例がある。堅牢性はベンダー自己申告)
  • 耐久性を高めた来歴(メタデータ + 透かし + 指紋)の対応範囲
  • 検出ツールの提供状況・精度主張(常にベンダー自己報告として扱う)
  • 規制上の表示義務の新設・改定

調査メモ research/trust/provenance.md(2026-09-10 更新)に、この定点観測の詳細と出典を記録しています。

実務での注意点

アンチパターン

  • 来歴と検出を混同する → 「来歴があれば AI 生成かが分かる」と誤解する → 来歴は履歴の検証、検出は AI 由来の推定と別レイヤーで扱う
  • 来歴の有無を単独の判断根拠にする → 剥がれただけの生成物を「本物」と誤認する → 来歴が無いことは剥離の可能性を含むと理解し、単独判断にしない
  • 検出ツールの結果で断定する → 偽陽性で人間の制作物・本人を誤って断罪する → 検出は補助シグナルとし、断定に使わない
  • 検出ツールの精度主張を鵜呑みにする → ベンダーの自己申告を実力と誤認する → 精度主張は自己報告として受け取り、複数手段で検証する
  • 自社生成物に来歴を付けない → 生成物であることの透明性の責任を果たせない → 自社生成物に来歴・透かしを付与する

チェックリスト

  • 来歴(履歴の検証)と検出(AI 由来の推定)を別レイヤーとして区別している
  • 来歴は剥がれうると理解し、有無を単独の判断根拠にしていない
  • 検出結果を「AI 製である/でない」の断定に使っていない
  • 検出ツールの精度主張をベンダー自己報告として扱っている
  • 自社生成物の媒体・生成経路・取得 API ごとの来歴/透かし対応を確認し、変換・保存・配信後も検証している
  • 受け入れコンテンツの検証を、検出単独でなくプロセス(来歴確認・別チャネル)にしている
  • 規制上の表示義務を確認し、来歴運用と接続している

関連トピック

参考資料

TODO・未確認事項