DEV Community

Cover image for AI画像検出が失敗する理由と代替手段
Akira
Akira

Posted on • Originally published at apidog.com

AI画像検出が失敗する理由と代替手段

今日、ほとんどの「AI画像検出器」に写真をアップロードすると、94%人間、88%AIのような自信のある判定が返ってきます。しかし、その数値を最終判断として扱うのは危険です。事後検出、つまり生成済み画像を後から分類器で判定する方法には、対象モデルが変化し続け、攻撃者や生成者が常に回避できるという構造的な限界があります。

今すぐApidogを試す

コンテンツの整合性は、いまやプロダクトに組み込むべき機能です。たとえば、操作された画像を拒否するアップロードAPI、合成メディアにフラグを立てるモデレーションパイプライン、監査証跡を残すコンプライアンスチェックなどです。

💡 これらはAPI設計の問題です。Apidogは、画像検証ロジックを担うAPIを設計、デバッグ、テストするためのワークスペースです。AI検出ステップをパイプラインに組み込む前に、そのステップが何を保証でき、何を保証できないのかを明確にしておく必要があります。

要約（TL;DR）

アップロード画像を「AI」または「人間」と判定する事後AI画像検出は、単独の防衛線としては信頼できません。

主な理由は次のとおりです。

  • 新しい生成モデルが登場するたびに検出精度が劣化する
  • 未知の生成器に一般化しにくい
  • 人間の作品をAI生成と誤判定する誤検知が起きる
  • トリミング、再圧縮、スクリーンショットで信号が壊れる
  • 視覚的な「AIっぽさ」はモデル改善で消えていく

より堅牢な基盤は、事後推測ではなくプロベナンス（来歴）です。

実装方針としては、C2PAコンテンツクレデンシャル、SynthIDのような透かし、分類器スコア、アカウント情報、人間レビューを組み合わせ、どれか1つを最終判定にしない多層防御にするべきです。

事後検出が失敗し続ける理由

検出器は無価値ではありません。明らかな合成画像のトリアージや、モデレーションキューの優先順位付けには使えます。

問題は、検出器の出力を「真実」として扱うことです。

AI画像検出の限界

1. 軍拡競争に終わりがない

AI画像検出器は、過去の生成画像から特徴を学習します。

たとえば次のような特徴です。

  • 周波数アーティファクト
  • 色分布の癖
  • ノイズパターン
  • 不自然なテクスチャ
  • 特定モデル固有の生成ミス

しかし、検出器が出荷された時点で、それは過去の生成モデルに対する分類器です。新しい画像生成モデルは、より自然で、より検出されにくい画像を生成する方向に改善されます。

つまり、検出器は常に後追いになります。

2. 分類器は未知のモデルに一般化しにくい

ある生成器で作られた画像を使って訓練された検出器は、別系統の生成器に対してうまく機能しないことがあります。

例：

  • 古いGAN画像で訓練された検出器が、拡散モデル画像を見落とす
  • 昨年の拡散モデルで訓練された検出器が、今年のモデルで精度を落とす
  • ベンダーのベンチマークでは高精度でも、実運用では低下する

分類器が学習しているのは「AIであること」そのものではなく、訓練データに含まれていた生成器の痕跡です。

そのため、未知の生成器、編集済み画像、再圧縮画像では精度が大きく落ちます。

3. 誤検知は本物の人間の作品を傷つける

検出器には2種類の失敗があります。

種類 内容 影響
偽陰性 AI画像を人間作と判定する 合成画像がすり抜ける
偽陽性 人間の作品をAI画像と判定する 無実のユーザーを誤って非難する

特に危険なのは偽陽性です。

たとえば、アップロードAPIで「AIと判定された画像は自動拒否」という実装をすると、本物の写真家、デザイナー、顧客の作品を誤って拒否する可能性があります。

数%の誤検知率でも、アップロード数が多ければ数千件の誤判定になります。

開発者向けの実践的な結論は明確です。

検出スコアは事実ではなく、弱い証拠の1つとして扱う。

検出器で何ができ、何ができないかを理解したい場合は、画像がAI生成であるかを確認する方法も参考になります。

4. トリミングや再圧縮で信号が壊れる

多くの検出器は、ピクセルレベルの微細な統計パターンに依存しています。

しかし、その信号は非常に脆弱です。

次のような一般的な操作だけで、検出結果が変わることがあります。

  • JPEGとして再保存する
  • 画像を10%トリミングする
  • リサイズする
  • 軽いノイズを追加する
  • スクリーンショットを撮る
  • SNSやメッセージアプリにアップロードする

これは特殊な攻撃ではありません。通常の共有プロセスで起きることです。

実運用では、ユーザーがアップロードする画像は「生成器から直接出力された綺麗なファイル」ではなく、何度も圧縮・編集・転送された画像であることが多いです。

つまり、検出器が最も苦手なケースが、実際には最も一般的なケースになります。

5. 視覚的な手がかりは消えていく

以前は、AI画像には分かりやすい特徴がありました。

  • 指が6本ある
  • 文字が崩れている
  • 背景が溶けている
  • 宝飾品が皮膚に融合している
  • 反射や照明が不自然

しかし、これらはモデルのバグです。そしてバグは修正されます。

画像生成モデルが改善されるほど、視覚的な「AIっぽさ」に依存する検出は陳腐化します。

誤った検出設計が生む実運用コスト

検出器の不正確さは、単なる品質問題ではありません。プロダクト上の責任になります。

たとえば次のようなケースです。

  • ストックフォトマーケットプレイスが本物の写真をAI画像として拒否する
  • ニュースや保険のワークフローが合成画像を「本物」と誤認する
  • 採用・学術プラットフォームがポートフォリオをAI製と誤判定する
  • 支払い、削除、BANなどの判断が確率スコアだけで実行される

検出器の出力は「証拠」ではありますが、「証明」ではありません。

特に次の場合は弱い証拠になります。

  • 画像が編集されている
  • 再圧縮されている
  • スクリーンショット化されている
  • 検出器が未学習のモデル由来である
  • メタデータが失われている

単一の分類器スコアを最終判定にするシステムは、単一障害点を持つシステムです。

代わりに使うべきもの：プロベナンスファースト

検出器は「この画像はAI生成に見えるか？」と推測します。

プロベナンスは、より実装しやすく検証可能な問いを扱います。

この画像の履歴は何か？

その履歴は暗号学的に検証できるか？

ピクセルから後追いで推測するのではなく、作成・編集・配布の過程で検証可能な情報を付加します。

プロベナンスの考え方

C2PAコンテンツクレデンシャル：署名付き来歴メタデータ

コンテンツプロベナンスと認証のための連合（C2PA）は、Adobe、Microsoft、Google、BBC、カメラメーカーなどが支援するオープンスタンダードです。

C2PAでは、画像に「マニフェスト」と呼ばれる来歴情報を付加します。

マニフェストには次のような情報を含められます。

  • どこで作成されたか
  • どのツールで作成・編集されたか
  • どの変更が加えられたか
  • 誰またはどの組織が署名したか
  • 署名が有効かどうか

エンドユーザーはこれをコンテンツクレデンシャルとして確認できます。

C2PAの利点は、分類器のように「見た目」から推測しないことです。作成時点で署名された記録を検証します。

ただし、制限もあります。

  • C2PAはオプトインである
  • 作成ツールや編集ツールが対応している必要がある
  • メタデータはSNSやCDNの再圧縮で削除される可能性がある
  • メタデータがないことは「AI生成」の証明にはならない

したがって、C2PAは強力な基盤ですが、それだけで完結するものではありません。

SynthID：生成時の透かし

C2PAメタデータはファイルから分離される可能性があります。

一方、Google DeepMindのSynthIDのような透かしは、画像の内部に機械検出可能な信号を埋め込みます。

SynthIDは、次のような一般的な変換に耐えるように設計されています。

  • スクリーンショット
  • トリミング
  • 色調整
  • 再圧縮
  • 軽微な編集

C2PAと透かしは競合しません。補完関係です。

層 役割
C2PA 詳細な署名付き履歴を提供する
SynthIDなどの透かし メタデータが失われても残る可能性のある信号を提供する

ただし、透かしも万能ではありません。対応している生成器から出力された画像にしか適用されません。

自分のシステムでも署名付きパイプラインを作る

プロベナンスは、外部標準だけの話ではありません。自社システム内でも実装できます。

たとえば、画像アップロードAPIでは次の情報を記録できます。

  • アップロードしたユーザーID
  • アカウントの認証状態
  • アップロード時刻
  • 元ファイルのハッシュ
  • 変換後ファイルのハッシュ
  • 実行した処理
  • 検証結果
  • 人間レビューの有無
  • 決定理由

例として、検証APIのレスポンスを次のように設計できます。

{
  "image_id": "img_123",
  "status": "unknown",
  "signals": {
    "c2pa": {
      "present": false,
      "valid": null
    },
    "watermark": {
      "provider": "synthid",
      "detected": false
    },
    "classifier": {
      "provider": "example-detector",
      "score_ai": 0.71,
      "confidence": "low"
    },
    "account": {
      "uploader_verified": true,
      "account_age_days": 340
    }
  },
  "decision": {
    "action": "manual_review",
    "reason": "classifier_score_is_not_sufficient_for_auto_rejection"
  }
}
Enter fullscreen mode Exit fullscreen mode

重要なのは、status に unknown を許容することです。

良いAPI設計では、次の3状態を明示します。

type VerificationStatus = "verified" | "conflict" | "unknown";
Enter fullscreen mode Exit fullscreen mode

避けるべき設計は、すべてを ai / human の二値に押し込むことです。

// 悪い例
type ImageDecision = "ai" | "human";
Enter fullscreen mode Exit fullscreen mode

不確実性を表現できないAPIは、誤った自動判断を生みやすくなります。

また、署名キーや検証キーの管理も重要です。クライアントコードや拡張機能にAPIキーを置かないのと同じように、プロベナンスに使う署名キーも厳密に保護する必要があります。関連する実装上の注意点は、クライアントコードや拡張機能からAPIキーを遠ざけるでも解説されています。

業界はプロベナンスファーストに向かっている

これは周縁的な考え方ではありません。

2026年5月、OpenAIはコンテンツプロベナンスのためにC2PAとSynthIDを採用すると発表しました。

ChatGPT、Codex、OpenAI APIからの画像は、C2PAメタデータとSynthIDウォーターマークを携行するようになり、OpenAIはアップロード画像のプロベナンス信号を確認するVerifyツールもリリースしました。

注目すべきなのは、アーキテクチャです。

OpenAIは「より高精度な事後分類器だけで解決する」とは言っていません。署名付きメタデータと耐久性のあるウォーターマークを組み合わせ、その上に検証を構築しています。

実装方針：多層防御にする

実用的な画像整合性パイプラインは、単一の判定器ではなく、複数の弱い信号を組み合わせます。

基本フローは次のようになります。

flowchart TD
  A[画像アップロード] --> B[C2PA検証]
  B --> C[透かし検証]
  C --> D[分類器スコア取得]
  D --> E[アカウント・コンテキスト確認]
  E --> F{リスク判定}
  F -->|低リスク| G[自動承認またはラベル付け]
  F -->|不明| H[追加確認]
  F -->|高リスク| I[人間レビュー]
Enter fullscreen mode Exit fullscreen mode

1. C2PAを検証する

まず、C2PAコンテンツクレデンシャルの有無と署名の有効性を確認します。

{
  "c2pa": {
    "present": true,
    "signature_valid": true,
    "issuer": "example-camera-or-tool",
    "assertions": [
      "created",
      "edited",
      "exported"
    ]
  }
}
Enter fullscreen mode Exit fullscreen mode

有効なC2PAマニフェストは強い証拠です。

ただし、C2PAが存在しない場合でも、それは「偽物」や「AI生成」の証明ではありません。単に「来歴が見つからない」だけです。

2. 透かしを検証する

次に、SynthIDなどの透かしを確認します。

{
  "watermark": {
    "checked": true,
    "provider": "synthid",
    "detected": true
  }
}
Enter fullscreen mode Exit fullscreen mode

透かしが検出されれば、有力な信号になります。

ただし、透かしが検出されない場合も、すべての生成器が透かしを埋め込んでいるわけではないため、決定的ではありません。

3. 分類器は弱い信号として扱う

分類器を使う場合は、トリアージ用の低重みの入力にします。

{
  "classifier": {
    "score_ai": 0.82,
    "score_human": 0.18,
    "use": "triage_only"
  }
}
Enter fullscreen mode Exit fullscreen mode

避けるべき実装：

if (classifier.score_ai > 0.8) {
  rejectUpload();
}
Enter fullscreen mode Exit fullscreen mode

より安全な実装：

if (classifier.score_ai > 0.8 && hasNoProvenance && isHighRiskFlow) {
  routeToManualReview();
}
Enter fullscreen mode Exit fullscreen mode

分類器スコアだけで、拒否、削除、BAN、支払い停止などの判断を自動実行しないでください。

4. コンテキスト信号を加える

画像そのもの以外の情報も判断材料になります。

  • アップロード履歴
  • アカウント年齢
  • 本人確認状態
  • 過去の違反履歴
  • デバイス情報
  • キャプチャメタデータ
  • 位置・時刻の一貫性
  • 同じ画像が他サイトに存在するか

これらも単独では決定打になりません。しかし、複数の信号を組み合わせることで、より安全な判断ができます。

5. 高リスク判断には人間レビューを入れる

次のような判断は、人間レビューを挟むべきです。

  • アカウント停止
  • 収益化停止
  • 支払い拒否
  • コンテンツ削除
  • 不正行為の告発
  • 公開コンテンツへのラベル付け
  • 法務・保険・報道用途での真正性判断

モデルの出力は補助情報であり、最終判断者にするべきではありません。

事後検出とプロベナンスの比較

側面 事後検出（分類器） プロベナンスとウォーターマーキング
主な問い 「これはAI生成に見えるか？」 「この画像の署名付き履歴は何か？」
時間経過に伴う信頼性 新しい生成器が登場するたびに劣化する 暗号署名はモデル改善の影響を受けにくい
新しいモデルへの一般化 弱い 特定モデルの指紋に依存しない
必要な協力 画像作成者の協力なしに実行できる 生成・編集ツール側の対応が必要
無力化される要因 トリミング、再圧縮、スクリーンショット、未知のモデル C2PAはメタデータ除去に弱い。透かし除去はより困難だが不可能ではない
誤検知リスク 高い 欠落は「不明」であり「偽物」ではない
失敗モード 自信があるが間違っている 決定的ではないが正直
最適な役割 トリアージ、弱い補助信号 存在する場合の主要な検証層
業界の方向性 単独回答としての依存度は低下 C2PA、SynthIDなどの採用が進んでいる

結論として、分類器の役割はトリアージです。プロベナンスは基盤です。そして、どちらも完全ではないため、コンテキスト情報と人間レビューを組み合わせる必要があります。

API設計で押さえるべきポイント

画像検証機能をAPIとして実装する場合は、次のような契約にします。

エンドポイント例 

POST /v1/images/verify
Content-Type: multipart/form-data
Authorization: Bearer <token>
Enter fullscreen mode Exit fullscreen mode

レスポンス例 

{
  "request_id": "req_abc123",
  "image_id": "img_123",
  "verification_status": "unknown",
  "risk_level": "medium",
  "signals": {
    "c2pa": {
      "present": false,
      "valid": null,
      "reason": "no_manifest_found"
    },
    "watermark": {
      "checked": true,
      "detected": false,
      "provider": "synthid"
    },
    "classifier": {
      "score_ai": 0.67,
      "confidence": "low"
    }
  },
  "recommended_action": "manual_review"
}
Enter fullscreen mode Exit fullscreen mode

状態は3つ以上にする

最低限、次の状態を持たせます。

type VerificationStatus =
  | "verified"
  | "conflict"
  | "unknown";
Enter fullscreen mode Exit fullscreen mode

より細かくする場合：

type VerificationStatus =
  | "verified_human_origin"
  | "verified_ai_origin"
  | "verified_edited"
  | "conflict"
  | "unknown"
  | "unsupported";
Enter fullscreen mode Exit fullscreen mode

自動判断の条件を明示する

ポリシーをコードに埋め込まず、設定として管理すると保守しやすくなります。

{
  "policy": {
    "auto_reject": false,
    "manual_review_threshold": {
      "classifier_score_ai": 0.8,
      "requires_missing_provenance": true,
      "applies_to": ["payments", "public_distribution"]
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

これにより、標準やツールが変化しても、API全体を作り直さずにポリシーを更新できます。

プロセスとポリシーの制御

技術レイヤーだけでは不十分です。プロダクトとして、不確実性をどう扱うかを決める必要があります。

「不明」を第一級の状態にする

多くのシステムは、本物か偽物かの二択を強制します。

しかし、実際の検証結果は次の3つです。

  • 検証済み
  • 矛盾あり
  • 不明

オープンなインターネット上の多くの画像は「不明」になります。これはエラーではなく、正常な結果として扱うべきです。

リスクに応じて対応を変える

低リスクな用途では、自動チェックだけで十分な場合があります。

一方で、次のような高リスク用途では、人間レビューを入れるべきです。

  • 支払い
  • 出版
  • アカウント停止
  • 不正告発
  • 法的・保険的判断

1つの検出アーキテクチャで、すべてのリスクレベルを処理しようとしないでください。

ユーザーに根拠を表示する

ユーザーに結果を表示する場合は、根拠を明確に分けます。

良い表示：

コンテンツクレデンシャルが検証されました。
Enter fullscreen mode Exit fullscreen mode 
AI分類器は、この画像をAI生成である可能性が高いと推定しています。ただし、この結果は最終判定ではありません。
Enter fullscreen mode Exit fullscreen mode

悪い表示：

この画像はAIです。
Enter fullscreen mode Exit fullscreen mode

分類器の推定と、暗号学的に検証されたプロベナンスを同じ強度の主張として扱わないでください。

自分の出力にはプロベナンスを書き込む

自社サービスが画像を生成または編集する場合は、出力にコンテンツクレデンシャルや透かしを付加することを検討してください。

下流のユーザーやプラットフォームが、推測ではなく記録に基づいて判断できるようになります。

検証レイヤーをモジュール化する

C2PA、SynthID、OpenAI Verifyのようなツールは進化します。

そのため、検証ロジックはモジュール式にしておくべきです。

interface VerificationProvider {
  name: string;
  verify(input: ImageInput): Promise<VerificationSignal>;
}
Enter fullscreen mode Exit fullscreen mode 
const providers = [
  c2paProvider,
  synthIdProvider,
  classifierProvider,
  accountSignalProvider
];

const signals = await Promise.all(
  providers.map((provider) => provider.verify(image))
);
Enter fullscreen mode Exit fullscreen mode

こうしておけば、新しい透かし検出器やプロベナンスソースを追加しやすくなります。

結論

事後AI画像検出は詐欺でも無用でもありません。ただし、単独で最終判定を任せられるツールではありません。

開発者向けの実践的な推奨事項は次のとおりです。

  • プロベナンスファーストで設計する
  • C2PAコンテンツクレデンシャルを検証する
  • SynthIDなどの透かしを確認する
  • 分類器スコアは低重みのトリアージ信号として扱う
  • unknown を正常な状態としてAPIに組み込む
  • 高リスク判断では人間レビューを入れる
  • 署名キーと検証キーを厳密に保護する
  • 検証レイヤーをモジュール化し、標準の変化に追従できるようにする

画像整合性チェックは、「AIか人間か」を当てるゲームではありません。検証可能な記録、弱い信号の組み合わせ、明示的な不確実性管理によって構築するAPI設計の問題です。

💡 Apidogは、本番環境に到達する前に、こうした検証エンドポイントを設計、モック、テストするための単一ワークスペースを提供します。推測に依存するのではなく、検証可能な記録に基づいた整合性レイヤーを構築してください。

Top comments (0)