合成音声クローンを見破る：セキュリティチームと報道機関がResemble Detectで録音・通話の真正性を検証する方法

生成AIによる音声クローニング技術の進化に伴い、人間の耳だけで本物の肉声とAI合成音声を識別することは事実上不可能になりました。セキュリティ運用センター（SOC）やメディアのファクトチェック部門では、役員になりすまして不正送金を指示する電話詐欺（ビッシング：Vishing）や、政治家・著名人の発言を偽造した音声流出など、現実の脅威が急増しています。攻撃者はわずか数秒のリファレンス音声から、感情豊かで極めて自然な偽造音声を生成できます。

こうした課題に対し、Resemble AIはエンタープライズ向けディープフェイク検出プラットフォーム Resemble Detect を提供しています。深層ニューラルネットワークによる微細な音響アーティファクト（歪みや不自然さ）の検出、不可視ニューラル電子透かしの検証、そして低遅延ストリーミング処理を組み合わせることで、保存された録音メディアのフォレンジック鑑定と、通話中のリアルタイム詐欺検知の双方に対応します。

本稿では、Resemble Detectの技術的メカニズムと、録音ファイル検証およびライブ通話保護における実践的な導入ワークフローを解説します。

Resemble Detect の検出メカニズムとスコアリング設計

人間の聴覚は自然な抑揚やイントネーションに惑わされやすい一方、生成モデルがデジタル音声をレンダリングする過程には物理的・数学的な特異点が生じます。Resemble Detectは多層的な検出エンジンでこれらの痕跡を特定します。

1. ディープニューラルネットワークによる音響アーティファクト解析

拡散モデル（Diffusion）、自己回帰トランスフォーマー、あるいはニューラルボコーダーのいずれであっても、合成音声には次のような微細な異常が現れます：

音素遷移における位相の不連続性とマイクロジッター；
高周波数帯における不自然なエネルギー分布と過剰なスペクトル平滑化；
呼吸や声帯微動など、人間の生体力学（バイオメカニクス）から乖離したリズム；
リアルタイム音声変換（RVC）やテキスト読み上げ（TTS）特有のボコーダー再合成痕跡。

Resemble Detectはジェネレーター非依存（Generator-agnostic）の深層学習モデルを採用しています。特定の合成エンジンに特化して過学習することなく、ElevenLabs、Resemble AI、オープンソースモデルなど、多様なアーキテクチャで生成された偽造音声を横断的に識別可能です。

2. 詳細なスコアリング体系

Resemble Detectは単なる真偽判定だけでなく、多角的な評価指標を返します：

label：総合判定（real 本物、または fake 偽造）；
aggregated_score：0.0〜1.0で正規化された集計スコア。数値が高いほど合成の兆候が強いことを示します；
score 配列：1秒刻みで算出される時系列スコア。音声の一部だけが改ざん・挿入されたスプライシング攻撃を特定できます；
consistency：有効な発話区間におけるスコアの一貫性指標。全編が合成音声か、人間とAIが混在しているかの判別に役立ちます。

3. 来歴検証：PerThニューラル透かしとC2PA

音響分析は確率論的アプローチですが、電子透かしとコンテンツ認証は確定的な証明をもたらします：

PerThニューラル電子透かし（v1およびv2）：Resemble独自の技術であり、人間の耳には聴こえない機械可読データを波形内に直接埋め込みます。MP3やOpusなどの非可逆圧縮、ノイズ混入、トリミング耐性を備えています；
SynthID対応：Google DeepMindが開発したSynthID透かしの有無を並行してスキャンします；
C2PA Content Credentials：メディアファイル内に埋め込まれたC2PAメタデータ（c2pa_manifest）を検査し、正規の録音機器や編集ツールからの真正なエクスポート履歴を確認します。

シナリオA：保存済み録音メディアのフォレンジック検証

報道機関、ファクトチェッカー、インシデント調査チームは、主にファイル形式の録音メディア（SNSで拡散されたリーク音声、内部通報の録音、法的証拠など）を取り扱います。

1. 検証ワークフローの設計

静的ファイルに対しては、REST API（POST https://app.resemble.ai/api/v2/detect）または一括バッチエンドポイント（POST /api/v2/detect/batch）を利用します：

セキュアなメディア取り込み：3つの入力方式に対応しています。直接ファイルアップロード（multipart/form-data、最大150 MB）、公開HTTPS URLの指定、またはセキュアアップロードAPI（POST /api/v2/secure_uploads）です。セキュアアップロードでは1時間有効なJWTトークン（media_token）が発行されるため、機密音声をインターネット上に公開することなく渡せます。
精密パラメータの設定：
- frame_length：スライディングウィンドウのフレーム長（1〜4秒、デフォルトは2秒）；
- start_region / end_region：疑わしい時間帯に解析を絞り込み、処理を高速化；
- detect_watermark: true：PerTh v1、PerTh v2、SynthIDの検出を同時実行；
- intelligence: true：話者属性、音響異常、文脈行動のインテリジェンス分析を実行；
- visualize: true：スペクトログラムのヒートマップ画像を生成し、異常箇所を視覚化。
ゼロデータ保持（Zero Retention Mode）：告発者のプライバシー保護や機密訴訟案件では、zero_retention_mode: true を指定します。ファイル名がトークン化され、レスポンス内のURLが墨消し（null）され、処理完了と同時にサーバー上の音声データが完全消去されます（file_deleted_at に記録）。

2. cURLリクエスト例

curl --request POST 'https://app.resemble.ai/api/v2/detect' \
  -H 'Authorization: Bearer YOUR_API_TOKEN' \
  -H 'Prefer: wait' \
  -H 'Content-Type: application/json' \
  --data '{
    "url": "https://storage.enterprise.internal/evidence/audio_leak.wav",
    "intelligence": true,
    "detect_watermark": true,
    "audio_source_tracing": true,
    "zero_retention_mode": true
  }'

3. レスポンス結果の読み解き

{
  "success": true,
  "item": {
    "uuid": "det_9b83f124_9341_40c7_9c49_8119c8d500ab",
    "status": "completed",
    "media_type": "audio",
    "duration": "14.2",
    "metrics": {
      "label": "fake",
      "aggregated_score": "0.94",
      "consistency": "0.91",
      "score": ["0.92", "0.95", "0.96", "0.94", "0.93"]
    },
    "watermark": {
      "status": "completed",
      "metrics": {
        "overall_status": "absent",
        "has_watermark": { "channel_0": false },
        "synthid": false
      }
    },
    "audio_source_tracing": {
      "label": "ElevenLabs",
      "error_message": null
    },
    "c2pa_manifest": {
      "validation_state": "NotPresent"
    },
    "zero_retention_mode": true,
    "file_deleted_at": "2026-10-10T10:15:20Z"
  }
}

このレポートでは、音声全体の偽造スコアが0.94と極めて高く、電子透かしは存在せず、さらに音声ソース追跡（Audio Source Tracing）によって商用生成エンジンElevenLabs由来であることが示唆されています。

シナリオB：リアルタイム電話・コンタクトセンターの防衛

金融機関のコールセンターや社内ヘルプデスクでは、通話中の**ビッシング（音声フィッシング）**攻撃が深刻化しています。通話終了後のバッチ検証では金銭被害を防げないため、会話の進行中にリアルタイムで偽造音声を検知する必要があります。

1. WebSocket低遅延ストリーミングアーキテクチャ

Resemble Detectは、リアルタイムサーバー間連携用に最適化されたWebSocketエンドポイントを提供しています：

wss://stream.resemble.ai/api/v1/detect/audio

伝送仕様：モノラル（1チャンネル）、16,000 Hzサンプリングレート、16ビットリトルエンディアン符号付きPCM。接続後の最初のバイナリフレームで標準WAVヘッダーを送信し、以降は約100ミリ秒ごとのPCMバイナリフレームを連続送信します。
ウィンドウ分割：サーバー側で受信音声を約4秒ごとのスライディングウィンドウにグループ化。
超低遅延判定：各ウィンドウの検出結果は300ミリ秒未満でクライアントに返却されます。
音声活動検知（VAD）の統合：無音区間や環境雑音、発話の合間を自動判定します。十分な発話エネルギーがない区間は chunk_label: "skipped" となり、無駄な課金を抑えつつ、環境ノイズによる誤検知を防ぎます。

2. PBX・CTIおよびSOCとの統合フロー

企業は、テレフォニー基盤（FreeSWITCH、Asterisk、Twilio Media Streams、WebRTCゲートウェイなど）とResemble WebSocketを中継するサーバープロキシを構築します：

認証管理：プロキシから Authorization: Bearer <API_KEY> ヘッダーを付与して接続します（ブラウザクライアントで直接APIキーを保持してはいけません）。
通話メタデータの紐付け：接続時に ?extra_params={"call_id":"call_9481","agent_id":"agent_04"} などのパラメータを付与し、社内SIEMのイベントログと整合性を保ちます。
即時アラート対応：プロキシは受信する chunk メッセージを監視します。chunk_aggregated_score が設定閾値（例：連続2ウィンドウで0.80以上）を超えた場合、自動的に防御アクションを発動します：
- オペレーター画面に「ディープフェイクの疑い」の警告バナーを表示；
- 送金やパスワードリセットの操作を一時凍結し、アウトオブバンド認証（SMS OTPやハードウェアトークン）を要求；
- 不正対策の専門デスクへ通話をエスカレーション。
セッション終了：終話時にクライアントから {"type":"end"} を送信し、通話全体の総合判定を含む final メッセージを受信した後にソケットを正常切断します。

3. リアルタイムWebSocketチャンクのペイロード例

{
  "type": "chunk",
  "stream_id": "str_f241df9c_4738_48f8_8098_34e712e63bd1",
  "label": "fake",
  "aggregated_score": 0.884,
  "score": [0.85, 0.89, 0.91, 0.88],
  "consistency": 91.2,
  "extra_params": {
    "call_id": "trans_94812",
    "channel": "inbound_customer_support"
  },
  "chunk_info": {
    "chunk_id": 2,
    "total_chunks": -1,
    "begin_timestamp_s": 4.0,
    "end_timestamp_s": 8.0,
    "chunk_aggregated_score": 0.895,
    "chunk_label": "fake",
    "chunk_consistency": 92.4
  }
}

アーキテクチャ比較：録音メディア検証 vs ライブ通話保護

比較項目	録音メディアのフォレンジック検証	ライブ通話のリアルタイム保護
主要インターフェース	REST API（`/api/v2/detect`、`/detect/batch`）	WebSocket（`wss://stream.resemble.ai/api/v1/detect/audio`）
音声データ形式	マルチパートアップロード；公開URL；JWTトークン	16 kHz 16ビットモノラルPCMバイナリフレーム（約100ms）
解析の粒度	音声全体のタイムライン；1〜4秒のフレーム設定	約4秒のスライディングウィンドウ；約300ms以内の判定
電子透かし・C2PA	PerTh v1/v2、SynthID、C2PAマニフェスト完全対応	非対応（音響アーティファクトの高速判定に特化）
無音・背景ノイズ処理	指定リージョン全体の特徴量を分析	VAD統合；発話不足ウィンドウは `skipped` と判定
データ保持方針	ジョブ履歴を永続化；Zero Retentionによる即時消去可	一時的ストリーム；終了後にジョブUUIDは永続化されない
主な利用者	報道機関；ファクトチェッカー；インシデント調査官	コンタクトセンター；不正防止システム；認証ゲートウェイ

運用上の留意点とベストプラクティス

Resemble Detectを本番環境で運用するにあたっては、以下の設計指針が推奨されます：

1. 単一判定に依存せず「トラストスタック（Trust Stack）」を構築する

攻撃側と防御側のいたちごっこが続く中、生成モデルは今後もボコーダー特有のノイズを低減させていきます。Resembleは多層防御アプローチを推奨しています：

音響検出：透かしのない未知の音声クローンを検知；
声紋認証（Identity API）：役員や重要顧客の声紋を事前登録し、「名乗っている本人か」を照合；
能動的電子透かし（PerTh）：公式発表の音声に生成段階で電子透かしを埋め込み、正当性を瞬時に証明；
コンテキスト分析：Detect Intelligenceで会話内容の不自然さや詐欺シナリオの兆候を評価。

2. 電話回線の圧縮ノイズを考慮した閾値調整

公衆交換電話網（PSTN）の音声コーデック（G.711やAMRなど）は帯域が狭く、高域成分がカットされ量子化歪みが発生します。通話監視においては：

単一の4秒ウィンドウの fake 判定だけで即座に通話を切断しない；
「2回以上連続で異常スコア（0.80以上）を記録した場合」に多要素認証を要求するなどの段階的ポリシーを適用する；
導入前に自社通話網の通常音声でベースラインを測定し、誤検知率を把握する。

3. ストリーミングログの社内保管

WebSocketセッションの判定結果はResembleのサーバー側には履歴として保存されません。コンプライアンスや事後監査のために、中継プロキシ経由で stream_id、チャンク判定、および final メッセージを社内のSIEM（SplunkやDatadogなど）に自動保存するパイプラインを構築してください。

合成音声クローンを見破る：セキュリティチームと報道機関がResemble Detectで録音・通話の真正性を検証する方法

あなたの AI で 365 Wiki を使う

365Wiki Skill

Resemble Detect の検出メカニズムとスコアリング設計

1. ディープニューラルネットワークによる音響アーティファクト解析

2. 詳細なスコアリング体系

3. 来歴検証：PerThニューラル透かしとC2PA

シナリオA：保存済み録音メディアのフォレンジック検証

1. 検証ワークフローの設計

2. cURLリクエスト例

3. レスポンス結果の読み解き

シナリオB：リアルタイム電話・コンタクトセンターの防衛

1. WebSocket低遅延ストリーミングアーキテクチャ

2. PBX・CTIおよびSOCとの統合フロー

3. リアルタイムWebSocketチャンクのペイロード例

アーキテクチャ比較：録音メディア検証 vs ライブ通話保護

運用上の留意点とベストプラクティス

1. 単一判定に依存せず「トラストスタック（Trust Stack）」を構築する

2. 電話回線の圧縮ノイズを考慮した閾値調整

3. ストリーミングログの社内保管

参考文献

合成音声クローンを見破る：セキュリティチームと報道機関がResemble Detectで録音・通話の真正性を検証する方法

Resemble Detect の検出メカニズムとスコアリング設計

1. ディープニューラルネットワークによる音響アーティファクト解析

2. 詳細なスコアリング体系

3. 来歴検証：PerThニューラル透かしとC2PA

シナリオA：保存済み録音メディアのフォレンジック検証

1. 検証ワークフローの設計

2. cURLリクエスト例

3. レスポンス結果の読み解き

シナリオB：リアルタイム電話・コンタクトセンターの防衛

1. WebSocket低遅延ストリーミングアーキテクチャ

2. PBX・CTIおよびSOCとの統合フロー

3. リアルタイムWebSocketチャンクのペイロード例

アーキテクチャ比較：録音メディア検証 vs ライブ通話保護

運用上の留意点とベストプラクティス

1. 単一判定に依存せず「トラストスタック（Trust Stack）」を構築する

2. 電話回線の圧縮ノイズを考慮した閾値調整

3. ストリーミングログの社内保管

参考文献

取り上げた製品