文字起こしツールの暗号化、その主張を読み解く

転写サービスのマーケティングで謳われる暗号化の主張のほとんどは、どのまともなクラウドサービスにも当てはまる2つの保護、つまり転送中のTLSと保存時のAES-256を指している。 それぞれが実際に何をカバーし、どこで止まるのかを理解すれば、プロバイダーを正直に評価でき、的外れな質問に労力を費やさずに済む。

2つの層、2つの脅威モデル

どのクラウド転写サービスでも、暗号化はデータの旅路の2つの異なる地点で機能する。

転送中の暗号化は、音声があなたのデバイスからプロバイダーのサーバーへ移動する間、それを保護する。プロトコルはTLS（Transport Layer Security）だ。TLS 1.3が現在の標準で、SSL Pulseの追跡によると2025年半ば時点で主要ウェブサイトの約75%が採用している。TLS 1.2も暗号学的には許容範囲だ。TLS 1.0と1.1は時代遅れで、どこにも存在すべきではない。

保存時の暗号化は、音声と転写テキストがプロバイダーのディスクに保存されている間、それを保護する。標準はAES-256（256ビット鍵のAdvanced Encryption Standard）だ。CATTが使用するCloudflare R2は、Cloudflareが内部で管理する鍵を使ったAES-256-GCMを実装している。Otter.aiなどが使うAWS S3も、サーバーサイド暗号化で同じアルゴリズムを提供する。

この2つの保護は、異なる問題を解決する。転送中の暗号化は、公共WiFi、ISP、中間ルーターでのネットワーク盗聴を防ぐ。保存時の暗号化は、物理ディスクを盗んだり、ストレージ基盤への不正アクセスを得たりする者を防ぐ。

どちらの保護もカバーしないもの: プロバイダー自身のアプリケーションだ。これはデータを処理するために透過的に復号化する。ここが、ほとんどのマーケティング資料が静かにスキップする限界点だ。

TLSの転送中保証が実際に意味すること

ファイルをアップロードすると、TLSはブラウザやアプリとプロバイダーのサーバーの間に暗号化トンネルを作る。信頼できないネットワーク上でも、受動的な傍受者は暗号化された無意味な文字列しか見えない。

TLSが具体的に保証するのは3つのことだ:

• 機密性: 第三者がネットワーク上で内容を読み取れないこと
• 完全性: データが転送中に改ざんされていないこと
• 認証: 接続先サーバーが証明書に記載された本人であること

TLSの品質は、ssllabs.com/ssltestで自分で確認できます。このツールは、サポートされるプロトコルバージョンや有効な暗号スイートを含む全設定を評価します。AまたはA+の評価を探し、TLS 1.0や1.1をまだサポートしているものは要注意です。

2026年に文字起こしサービスでTLS 1.2はまだ許容されるか？

はい、TLS 1.2は暗号学的に許容範囲ですが、現在はTLS 1.3が推奨基準です。TLSが保護しないもの: すでにデバイスを侵害された攻撃者、侵害されたサーバー、またはプロバイダーがデータ到着後に内容を読むケース。TLSはサーバーで終了します。その後、データはアプリケーション内で平文になります。

AES-256による保存時暗号化が実際に保証すること

AES-256による保存時暗号化は、ストレージ層がディスク上のデータを暗号化することを意味します。CloudflareのR2に関するドキュメントには、すべてのオブジェクトとそのメタデータがAES-256-GCMで暗号化されると明記されています。Amazon S3はSSE（サーバー側暗号化）でAES-256を使用しており、Otter.ai、Descript、その他多くの文字起こしサービスはAWSのストレージ層からこれを継承しています。

AES-256暗号化は、文字起こしプロバイダーがファイルを読めないことを意味するか？

いいえ。保存時暗号化は、データセンターからの物理ディスク盗難、適切に消去されずに廃棄されたハードウェア、マルチテナントクラウド環境でのインフラレベルでのクロステナントアクセスを特に防ぎます。

防げないもの:

• アプリケーションサーバーが通常のコード経路でデータを読み取る場合（復号キーを保持し、自動的に使用する）
• アプリケーションレベルのアクセス権を持つプロバイダー従業員
• 侵害されたキー管理システム
• ストレージバケットを公開状態にしてしまうアクセス制御の設定ミス（これにより暗号化が完全に迂回される）

プロバイダーにはアクセス権がある。それは実装の欠陥ではない。サーバーサイド暗号化が設計上そうなっているだけだ。

クラウドASRで真のエンドツーエンド暗号化が不可能な理由

文字起こしツールが「エンドツーエンド暗号化」を謳うとき、それは何を意味するのか？

Signalの文脈でのエンドツーエンド暗号化（E2EE）は、プロバイダーが暗号的にロックアウトされていることを意味する。たとえ強制されても、彼らはあなたのデータを復号できない。秘密鍵はあなたのデバイスから決して離れない。

これはクラウド音声認識では実現不可能であり、そう主張するベンダーは慎重に検討する価値がある。 AIモデルは文字起こしを生成するために平文の音声を処理する必要がある。処理層で暗号化されたままの音声を文字起こしすることはできない。

文字起こしベンダーが「エンドツーエンド暗号化」という言葉を使うとき、通常は次の2つの弱い意味のいずれかを指している。

アップロード前のクライアントサイド暗号化。 ユーザーのデバイスがサーバーに送信する前に音声を暗号化する。サーバーはそれを復号し、モデルを実行し、文字起こしを再暗号化して送り返す。プロバイダーは文字起こし処理中に平文へのアクセス権を持つ。これにより露出時間は制限されるが、完全には排除されない。

機密コンピューティングエンクレーブ。 サーバー側の処理は、ハードウェアで隔離されたエンクレーブ（Intel SGX、AMD SEV、Intel TDX）内で行われます。プロバイダーのコードが実行されているにもかかわらず、プロバイダーのオペレーターはメモリを検査できません。Azureは、AMD SEV-SNPを使用した機密コンテナ内でWhisper文字起こしを提供しています。これにより、露出面は大幅に狭まりますが、モデルがエンクレーブ内で平文にアクセスする必要は依然としてあります。保証されるのはハードウェアの隔離であり、暗号化によるロックアウトではありません。

音声に対する準同型暗号化の研究は、復号化なしで暗号文に対して計算を行うもので、活発に進められていますが、実運用にはまだ程遠い状態です。2025年の量子化近似信号処理に関する論文では、完全準同型暗号化を使用した最初の安全な生音声パイプラインが実現されました。ベンチマーク結果は、Apple M2上で64ミリ秒の音声ウィンドウをFHEで計算するのに12,970秒かかりました。平文では0.004秒です。これは研究の方向性であり、ベンダーの機能ではありません。

現在、真にプロバイダーがアクセスできない文字起こしを実現する唯一の方法は、セルフホスティングです。自分のハードウェアでWhisperを実行すれば、音声を露出させるプロバイダーは存在しません。

主要な文字起こしサービスが実際に開示している内容

主要なプロバイダーが暗号化の姿勢について公開している内容を、ベンダーのドキュメントと照合して以下に示します。

出典：各ベンダーのセキュリティページと公開ドキュメント（2026年7月確認）。BAAの提供はエンタープライズ契約が必要な場合が多い。最新の条件は各ベンダーに確認すること。

プロバイダーがこれらの詳細を一切公開していない場合、それは重要なシグナルと捉えるべきです。ベースラインの基準を実装していないか、セキュリティ意識の高い顧客向けのドキュメント整備に投資していないかのどちらかです。

顧客管理暗号化キー（CMEK）が重要になるケース

標準的なデプロイではプロバイダー管理キーを使用します。ベンダーのシステムがデータを暗号化し、キーを保持します。あなたの側でキーをローテーションしてアクセスを失効させることはできません。

顧客管理暗号化キー（CMEK）はこの仕組みを逆転させます。キー管理サービス（AWS KMS、Google Cloud KMS）を通じて自前のキーを持ち込み、プロバイダーのストレージはあなたのキー基盤が応答しない限りデータを復号できません。キーを無効化すればアクセスを失効させられます。また、キーの使用ごとに監査証跡が残ります。

AWS Transcribeは出力暗号化にKMS管理キーをサポートしています。Google Cloud Speech-to-Text v2は全リソースとバッチ文字起こしジョブでCMEKをサポートしています。どちらも各社の開発者向けリファレンスに記載されています。

CATTはCMEKを提供していません。ファイルはCloudflare R2上に保存され、キーはCloudflare管理となります。キーの所有権と失効性をセキュリティ要件に含むお客様には、音声認識API料金比較に基づき、AWS TranscribeまたはGoogle Cloud STT v2が適切な選択肢です。

暗号化が解決しないこと

これは、暗号化が解決することと同じくらい重要です。

プロバイダーによるアクセス。 TLSとAES-256は、プロバイダー自身のアプリケーションがお客様のデータにアクセスするのを防ぎません。ここで重要となるのは、内部アクセス制御、最小権限ポリシー、監査ログです。従業員が顧客の音声にアクセスできるか、どのような状況でアクセスするか、アクセスが記録されるかを確認してください。

アカウントの乗っ取り。 ログイン認証情報が盗まれた場合、攻撃者はお客様として認証され、通常のアプリケーション経路を通じてアクセスします。暗号化はここでは何の保護も提供しません。アカウントの多要素認証は、暗号化アルゴリズムよりも重要です。

エンドポイントの侵害。 アップロード前にノートパソコンが侵害された場合、音声は暗号化チャネルに入る前にデバイス上で読み取られます。エンドポイントセキュリティは、転送中および保存中の暗号化とは別の領域です。

アクセス制御の設定ミス。 パブリック読み取りに設定されたストレージバケットは、AES-256に関係なくデータを露出させます。アクセスポリシーの正しい設定は、暗号化と並行して必要です。プロバイダーが公開露出のインシデントを経験したかどうかを確認してください。

AIトレーニングデータ。 プロバイダーが顧客の音声をモデルのトレーニングや改善に使用する場合、暗号化は保存中のデータを保護しますが、モデルがそれを処理する際に何が起こるかには対処しません。音声がトレーニングに使用されるかどうかを明示的に尋ね、契約に盛り込んでください。例えばFireflies.aiは、文字起こしベンダーとの間で0日データ保持ポリシーを公開しており、これがこの点に具体的に対応しています。

完全なセキュリティ体制は、暗号化にアクセス制御、認証、監査ログ、ベンダー管理、明確なデータ利用ポリシーを重ね合わせたものです。暗号化はその一層に過ぎず、全体の答えではありません。

データ処理全体の状況についてはAI文字起こしはプライベートかを、欧州の規制枠組みについてはGDPR準拠の文字起こしを参照してください。

契約前にベンダーへ確認すべきこと

ほとんどのビジネスユースケースでは、この5つの質問で基準はカバーできます。

1. サポートしているTLSバージョンと暗号スイートは何ですか（SSL LabsでA/A+がベンチマークです）
2. 保存データは暗号化されていますか、またどのアルゴリズムを使用していますか
3. 暗号鍵は誰が保持し、自前の鍵を持ち込めますか
4. バックアップとログも暗号化されていますか
5. 顧客の音声をモデルのトレーニングや改善に使用していますか

医療など規制産業向けの暗号化オプションは何がありますか

最も重要な文書は暗号化仕様ではなく、プロバイダーとの署名済みビジネスアソシエイト契約（BAA）です。BAAがない場合、AES-256の主張に関係なく、保護された健康情報（PHI）を文字起こしサービスで扱うとHIPAA違反になる可能性があります。Rev、Otter.ai、Fireflies.ai（エンタープライズ層）はBAAの提供有無を公開しています。鍵の完全な管理が必要なら、AWS TranscribeとGoogle Cloud Speech-to-Text v2はどちらも各KMSサービス経由で顧客管理暗号鍵（CMEK）をサポートしています。

規制産業の場合は、次の質問も追加してください。

6. HIPAA用の署名済みビジネスアソシエイト契約（BAA）はありますか
7. GDPR用のデータ処理契約（DPA）はありますか
8. SOC 2 Type II監査を受けていますか、またその報告書を見せてもらえますか
9. 顧客管理の暗号鍵をサポートしていますか
10. 鍵のローテーションとインシデント対応はどのように行っていますか

コンプライアンス表記に関する注意点。 ツールが「HIPAA準拠」や「GDPR準拠」である、という言い方は不正確です。コンプライアンスは、特定の導入環境とベンダーとの間で結ぶ契約に帰属するものであり、ツールが単独で持つバッジではありません。HIPAAに関しては、適切な技術的統制を持つプロバイダーと署名したBAAが重要です。GDPRに関しては、適切なデータ取り扱いのコミットメントを盛り込んだ署名済みDPAが重要です。バッジではなく、文書を求めましょう。

CATTに関する正直な開示

CATTが行うこと:

• 転送中のTLS 1.2以上、Cloudflareのエッジネットワーク経由で提供
• 保存時のAES-256-GCM、Cloudflare R2上でCloudflare管理の鍵を使用
• R2のデフォルト保護から継承される暗号化バックアップ
• アプリケーション内でのロールベースのアクセス制御

CATTが行わないこと:

• 顧客管理の暗号化キー（CMEK）
• ハードウェアセキュリティモジュール（HSM）の統合
• FIPS 140-3認定の鍵管理（注: FIPS 140-2の認証は2026年9月に失効）
• 処理のための機密コンピューティングエンクレーブ
• アップロード時の真のクライアントサイド暗号化

ほとんどのビジネスおよび個人向け文字起こしのユースケースでは、最初のリストで十分です。2番目のリストが必要な場合、あなたはエンタープライズまたは規制産業の文脈で運用しており、おそらく別のプロバイダーやセルフホスティングが必要です。ミーティングボットや複雑なコンプライアンスのオーバーヘッドなしに、クリーンで高速な文字起こしが必要なら、CATTの音声からテキストへのツールがサインアップなしで直接処理します。

文字起こし後のデータフットプリントを減らす実践的な手順については、文字起こしファイルの自動削除を参照してください。

出典

• Cloudflare R2 データセキュリティドキュメント - 保存時はAES-256-GCM、転送時はTLS、Cloudflare管理の鍵
• Otter.ai プライバシーとセキュリティページ - AWS SSEによるAES-256、SOC 2 Type II
• Descript セキュリティページ - 保存時AES-256、転送時TLS 1.2、SOC 2 Type II
• Fireflies.ai セキュリティページ - 保存時AES-256、転送時TLS、SOC 2 Type II、エンタープライズ向けHIPAA-BAA
• Google Cloud Speech-to-Text CMEKドキュメント - 顧客管理の暗号化鍵、v2 API
• AWS Transcribe データ暗号化ドキュメント - 出力暗号化のためのKMS統合
• Qualys SSL Labsサーバーテスト - TLS設定の評価ツール
• SSL Pulse TLS 1.3採用状況トラッキング - 2025年半ば時点で主要ウェブサイトの75%がTLS 1.3を採用
• FHEオーディオ向け量子化近似信号処理（2025年プレプリント） - 準同型暗号による音声処理のベンチマーク
• Rev.com HIPAAセキュリティページ - BAAの利用可能性とHIPAAティアの詳細