AWS で AI 生成コンテンツのオーディオ来歴情報を生成元で構築する

この記事は 2026 年 8 月 27 日に公開された Building audio provenance for AI-generated content at the source with AWS を翻訳したものです。

AI 生成オーディオは、世界中のメディア・サプライチェーンにますます組み込まれています。欧州市場向けにこのコンテンツを生成する場合、EU AI 法第 50 条に基づき、2026 年 12 月 2 日までにコンプライアンス要件を満たす必要があります。本記事では、合成の段階で AI 生成オーディオに暗号技術を用いた来歴情報 (プロヴェナンス) の透かしを埋め込み、ライブストリーミングメディアパイプラインを通じて検証可能な管理の連鎖 (チェーン・オブ・カストディ) を保持する、Amazon Web Services (AWS) のパイプライン「SENTINEL」の構築方法について解説します。本記事では、アーキテクチャ、AWS サービスの実装、デプロイ手法、および SENTINEL の構築中に直面したエンジニアリング上のトレードオフについて取り上げます。

なぜ 2026 年に急務になったのか？

• EU AI 法第 50 条は、欧州連合 (EU) で提供される AI 生成コンテンツに対し、機械可読な来歴情報の表示を義務付けています。2026 年 8 月 2 日より後に提供を開始したシステムは、直ちに準拠する必要があります。既存のシステムの期限は 2026 年 12 月 2 日です。違反した場合、最大 1,500 万ユーロまたは全世界売上高の 3% のいずれか高い方の制裁金が科されます。
• Universal Music Group と Warner Music Group による業界の著作権和解は、AI 生成音楽に帰属メタデータが必要であることを示しています。
• 業界では、NextGen TV 放送向けの VP1 透かし形式を規定する ATSC A/334 規格が認知されています。

2026 年 7 月 9 日、欧州委員会は AI 生成コンテンツの透明性に関する行動規範 (Code of Practice on Transparency of AI-Generated Content) を、第 50 条への準拠を示すうえで適切なものとして承認しました。最終版の規範は、プロバイダーに対し、(1) 一般に利用可能な検出ソリューション、(2) 知覚できない透かしを伴うデジタル署名付きメタデータ、(3) 検出のために提出されたコンテンツを保持しない取り扱い (ゼロリテンション)、(4) 2027 年 2 月 2 日を期限とする相互運用性などの最低限の義務を定めています。これらの義務により、オーディオプロバイダーに求められる技術要件は、2025 年 12 月の第 1 次草案で想定されていたものより厳しくなっています。

オーディオの来歴情報に、新しい技術は必要ありません。業界にはすでに必要な要素がそろっており、SENTINEL はそれらを AWS 上で稼働するパイプラインとして組み上げています。AudioSeal は、MIT ライセンスのオープンソースの透かし技術で、堅牢で知覚できないという特長があります。SENTINEL は AudioSeal を使って透かしを生成し、埋め込みを合成の段階に移すことで、ペイロードを生成モデルと、Amazon Bedrock Guardrails による安全ポリシーの評価に結び付けます。C2PA 2.0 は、暗号署名されたオープンなコンテンツクレデンシャルのマニフェストを提供します。SENTINEL はこのマニフェストを作成・署名し、配信チェーン全体に引き継ぎます。さらに、C2PA の「ソフトバインディング」を備えた Durable Content Credentials は、SENTINEL が実装する復元の仕組みそのものを定義しています。これは、途中の処理で埋め込みメタデータが削除された場合に、不可視の透かしを使ってリポジトリからマニフェストを復元する仕組みです。SynthID は、生成時の埋め込みと C2PA を組み合わせる同じ方向性を、単一ベンダーの製品群の中で大規模に実現しています。SENTINEL は、このモデルをサードパーティのあらゆる AWS パイプラインで利用できるようにします。

これらの構成要素を組み合わせたものが、Durable Content Credentials です。これは、署名付きのマニフェストと、処理を経ても残るソフトバインディングで構成されます。AI 生成オーディオがライブ制作パイプラインを流れるとき、オーディオには 2 つの来歴情報のアセットが付随します。C2PA マニフェスト (メディアコンテナに添付される署名付きメタデータ) と、AudioSeal の透かし (オーディオ波形に直接埋め込まれる 16 ビットのペイロード) です。マニフェストは、メタデータのパススルーを実装していないトランスコーダーによって削除されることがよくあります。一方、透かしはオーディオ信号そのものの中にあるため、コーデックのトランスコード、再量子化、±6 dB のゲイン変更、10% へのクロッピングを経ても残ります。ただし、タイムストレッチや中程度の加算ノイズには耐えられません。SENTINEL は、残った透かしをソフトバインディングとして使い、削除されたマニフェストを来歴情報のレジストリから復元します。こうして、ライブオーディオ向けの耐久性のある C2PA コンテンツクレデンシャルを AWS 上で実装しています。

この実装では、AI コンテンツを Amazon Polly (ニューラルエンジン) で合成し、AWS Elemental MediaLive でトランスコードし、AWS Elemental MediaPackage で HTTP Live Streaming (HLS) セグメントに再パッケージします。さらに、AWS Elemental MediaTailor のサーバーサイド広告挿入 (SSAI) で加工し、Amazon CloudFront で配信します。また、Amazon Bedrock Guardrails がポリシーの評価を行います。

ソリューションの概要

SENTINEL は、4 つの機能プレーンにまたがって動作します。

1. 生成 (プレーン 1) – AI による合成の間に、パルス符号変調 (PCM) の生のオーディオに透かしを埋め込む
2. 変換 (プレーン 2) – メディア処理の各段階で、管理の連鎖を示す署名付きアサーションを付与する
3. レジストリ (プレーン 3) – 組織をまたいだアンカリングを備えた、改ざん検知可能な来歴情報のストレージ
4. 復元 (プレーン 4) – キャプチャした 1 秒以上のオーディオから、来歴情報のチェーン全体を再構築するエッジ API

次の図は、生成から復元まで、オーディオが SENTINEL の 4 つのプレーンをどのように流れるかを示しています。

図 1: SENTINEL の 4 プレーンアーキテクチャ

オーディオは合成時に透かしが埋め込まれ (プレーン 1)、メディア処理の各段階でアサーションが付与され (プレーン 2)、来歴情報は改ざん検知可能なレジストリに保存され (プレーン 3)、チェーン全体はエッジで復元できます (プレーン 4)。

共有のコントロールプレーン (Amazon API Gateway、Amazon Cognito、Amazon DynamoDB、Amazon CloudWatch) が、すべてのプレーンに対して認証、API 管理、オブザーバビリティを提供します。

プレーン 1: 合成の時点での透かし

SENTINEL は、オーディオをプレーン 1 から送り出す前に、各合成リクエストに対して次の 4 つの処理を行います。

1. 安全ポリシーの証明 – Amazon Bedrock Guardrails が、ApplyGuardrail API を使用して、設定されたコンテンツポリシーのカテゴリに照らして合成リクエストを評価します。Guardrails は評価結果 (action フィールドと assessments 配列) を返します。これは通常の API レスポンスであり、署名されたアーティファクトではありません。そこで SENTINEL は、暗号による信頼の連鎖を自ら確立します。まず、ガードレールのポリシーハッシュ (ガードレール ID、バージョン、評価結果を含む、シリアライズした ApplyGuardrail レスポンスの SHA-256) を計算し、そのハッシュに AWS Key Management Service (AWS KMS) (ECDSA_SHA_256) で署名します。KMS キーは、FIPS 140-3 セキュリティレベル 3 の検証を受けた HSM で保護されています。署名されたハッシュは透かしのペイロードの一部となり、そのオーディオが特定の安全ポリシー設定のもとで生成されたことを示す、永続的で検証可能な記録になります。改ざん検知性をもたらすのは、Guardrails ではなくこの署名です。
2. 暗号鍵の導出 – AWS KMS が、管理の連鎖のタイムスタンプに対する FIPS 140-3 レベル 3 の署名とあわせて、GenerateDataKey でテナントごとの一時的なデータキーを導出し、マルチテナントでの暗号学的な分離を維持します。
3. オーディオの合成 – Amazon Polly (ニューラルエンジン) が、16 kHz の生の PCM 波形を生成します。
4. ボコーダー層での透かしの埋め込み – 透かしの埋め込み処理は Amazon SageMaker 上で動作し、AudioSeal のジェネレーターを使用します。エンコードやパッケージングの前に、16 ビットのペイロードを生の PCM 波形に埋め込みます。知覚できないこと (不可知覚性) は、AudioSeal が学習した知覚損失と、品質ゲート付きの SENTINEL の適応的な α 探索によって実現しています。安全策として、BS.1387 に由来するマスキング閾値のチェックも実行します。測定した最悪ケースのマージンは +22.3 dB で、467 フレーム中、可聴なフレームは 0 でした (検証済み)。

波形に埋め込まれる透かしは 16 ビットで、アセットの SHA-256 コンテンツハッシュの先頭 2 バイトを、レジストリの検索キーとして保持します。コンテンツハッシュ、モデルの ID、ガードレールのポリシーハッシュ、テナントのキー ID、タイムスタンプ、ナンスを結び付ける来歴情報の 128 ビットの完全なペイロードは、署名付きの C2PA マニフェストに格納され、切り詰めていない完全な値はレジストリに保持されます。透かしは指し示し、マニフェストが証明します。

エンコード前のこの段階で埋め込むことで、オーディオの忠実度が最も高い時点で透かしが組み込まれます。Advanced Audio Coding (AAC) 圧縮から HLS のパケット化、広告挿入まで、その後のすべての処理は、すでに来歴情報のペイロードを含むオーディオに対して行われます。

次の表は、透かし埋め込みのエンジニアリング目標をまとめたものです。

注: これらは、AudioSeal が公表した ICML 2024 の結果とアーキテクチャ上の制約に基づくエンジニアリング目標です。多様な種類のコンテンツで本番環境向けに検証するには、MUSHRA (Multiple Stimuli with Hidden Reference and Anchor) の聴取パネルによる厳密な A/B テストが必要です。

プレーン 2: ライブストリーム全体での管理の連鎖

メディア放送パイプラインの各段階で、AWS Elemental サービスからの Amazon EventBridge イベントが、transformer-signer という AWS Lambda 関数を起動します。この関数は、暗号署名されたアサーションを来歴情報のチェーンに追加します。

1. AWS Elemental MediaLive – インジェストとトランスコードの時点でのアサーション
2. AWS Elemental MediaPackage v2 – HLS、Common Media Application Format (CMAF)、Dynamic Adaptive Streaming over HTTP (DASH) への再パッケージの時点でのアサーション
3. AWS Elemental MediaTailor – SSAI の時点でのアサーション

各アサーションは prev_assertion_id で直前のアサーションを参照し、AWS KMS の非対称キー (ECDSA_SHA_256) で署名されます。その結果、次のような連結されたチェーンが作られます。

{
    "assertion_id": "ast-7f3a9b2c",
    "transform_type": "transcode",
    "created_at": "2026-05-20T14:23:07.442Z",
    "digest": "a8f2e1...",
    "signature": "MGQCMBn...",
    "prev_assertion_id": "ast-2d8e4a1f",
    "sequence_number": 3
}

アサーションの挿入、削除、並べ替えのいずれによる改ざんも、チェーンの暗号上の完全性を損ないます。アサーションの処理に失敗した場合は、Amazon Simple Queue Service (Amazon SQS) のデッドレターキュー (DLQ) に送られ、再試行されます。

プレーン 3: 改ざん検知可能なレジストリ

SENTINEL は、次の表に示す複数の層からなるレジストリに、来歴情報のチェーンを保存します。

プレーン 4: エッジでの復元 API

どの下流プラットフォームも、キャプチャした 1 秒以上のオーディオを、Amazon CloudFront と Lambda@Edge にデプロイされた復元 API に送信し、来歴情報のチェーン全体を受け取ります。処理は、次の 2 つの経路のいずれかをたどります。

1. 主経路 (透かしが残っている場合) – Lambda@Edge が AudioSeal の検出器で 16 ビットのペイロードを抽出し、Aurora でマニフェストを検索します。そして、チェーン全体 (モデルの ID、ガードレールの証明、すべての変換アサーション) を、信頼度スコアとともに C2PA 互換のマニフェストとして返します。
2. フォールバック経路 (透かしが劣化または削除された場合) – システムが、オーディオのフィンガープリントを OpenSearch Serverless の ACR インデックスと照合し、信頼度スコアを下げた確率的な一致結果を返します。この副次的な経路は、コンテンツ配信ネットワーク (CDN) での積極的なトランスコードや敵対的な処理によって、埋め込まれた透かしが劣化した場合に対応します。

目標レイテンシーは、CloudFront のグローバルエッジネットワークを通じて、99 パーセンタイル (p99) で 1 秒未満です。AWS WAF がレート制限とボット対策を、AWS Shield Advanced が DDoS 対策を提供します。次の図は、SENTINEL の実装における機能フローの概要です。

図 2: SENTINEL の機能データAmazon CloudFronフロー

SENTINEL の実装で得られた主な知見は次のとおりです。

• AudioSeal の 16 ビットのメッセージ上限により、マルチフレームのエンコードが必要になる – AudioSeal の事前学習済みモデルは、1 フレームあたり 16 ビットを扱います。128 ビットのペイロードを連続する 8 フレームに分けて埋め込むと、完全に読み取るのに約 8 秒のオーディオが必要になり、順序に依存する壊れやすいデコードになります。ただし SENTINEL は、16 ビットをそのままレジストリの検索キーとして使い、完全なペイロードは署名付きマニフェストに保持します。これにより、復元に必要なオーディオは 1 秒に保たれます。AudioSeal のマルチビット拡張モードやカスタム学習によるキーの拡張は、ロードマップに含まれています。
• ボコーダーの後での埋め込みが、現実的な出発点になる – 改変した HiFi-GAN ボコーダーの内部で透かしを埋め込むと、先行技術との差別化は最も大きくなりますが、Amazon SageMaker の p4d.24xlarge インスタンス (NVIDIA A100 GPU 8 基) で 2〜4 週間のカスタムボコーダー学習が必要です。SENTINEL の現在の実装は、AudioSeal をそのまま使い、ボコーダーの出力直後、かつ非可逆エンコードの前に埋め込みます。ロードマップでは、今後のフェーズでボコーダー内部での埋め込みに移行します。
• Lambda@Edge のコールドスタートには、アーキテクチャでの対策が必要になる – Lambda@Edge 関数は、リージョンの Lambda よりもコールドスタートのレイテンシーが高く、プロビジョニングされた同時実行もサポートしていません。SENTINEL は、CloudFront のキャッシュ優先のアーキテクチャ (透かしのハッシュでマニフェストの検索結果をキャッシュ) と、軽量な関数設計 (最小限の依存関係、重いフレームワークを使わない) によってこれを軽減し、p99 の復元レイテンシーを目標の 1 秒未満に保っています。計算負荷の高い検出 (AudioSeal の推論) は、プロビジョニングされた同時実行を利用できるリージョンの Lambda 関数に転送します。

まとめ

SENTINEL は、後処理のステップとしてではなく、生成の間に透かしを埋め込み、署名付きのアサーションによってあらゆる変換を通じて来歴情報を追跡します。これにより、オーディオと切り離せない管理の連鎖が作られます。このソリューションは、Amazon Bedrock、AWS KMS、AWS Elemental Media Services、Amazon Aurora、Amazon CloudFront などの AWS マネージドサービスで構築されているため、すでに運用しているインフラストラクチャを使ってパイプラインをデプロイできます。

オーディオの来歴情報は、差別化要因ではなくコンプライアンス要件です。EU AI 法の 2026 年 12 月の期限は、2026 年 7 月に最終化された行動規範が一般に利用可能な検出ソリューションとゼロリテンションでの取り扱いを義務付けたことで、さらに厳しくなりました。音楽業界の帰属に関する義務付けや放送規格も、AI オーディオを生成するのであれば、来歴情報は生成元で組み込まなければならない、という点で一致しています。SENTINEL は、後処理のワークフローが追いつくのを待たずに、これらの義務を満たすための設計図を提供します。

SENTINEL のリファレンス実装は、2026 年 10 月に GitHub で公開される予定です。2026 年 12 月 2 日の期限までに AI 生成オーディオに検証可能な来歴情報を組み込めるよう、AWS for Media and Entertainment Blog で最新情報をご確認ください。

参考資料

1. AWS マネジメントコンソールで Amazon Bedrock を使い始める。
2. コンテンツクレデンシャルのマニフェストについては、C2PA 2.0 仕様を参照する。

著者について

Saurav Bhattacharya

Saurav Bhattacharya は、AWS のシニアソリューションアーキテクトで、通信、ブロードバンド、メディアの分野で豊富な経験を持っています。現在は、メディア & エンターテインメント業界の課題の解決に注力し、技術営業を加速するとともに、お客様のデジタルトランスフォーメーションを加速するスケーラブルなソリューションを構築しています。

参考リンク

AWS Media Services
AWS Media & Entertainment Blog　(日本語)
AWS Media & Entertainment Blog　(英語)

AWS のメディアチームの問い合わせ先:awsmedia@amazon.co.jp

※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。

翻訳は SA 金目、SA 石井が担当しました。原文はこちらをご覧ください。