音声AIデータマップ：録音、文字起こし、API、CRMへの書き戻し

音声AIデータマップとは、通話によって生成されるすべてのデータについて、保存場所、保存期間、プラットフォームからの取り出し方法、そして最終的にどのシステムに届くかを一覧にした1枚の資料です。セキュリティ部門は契約前にこれを求め、IT部門や運用部門は連携の計画に活用します。

本ガイドでは、Retellのドキュメントに基づいてRetell AIのデータマップを作成します。ドキュメントに記載がない点については、何を確認すべきかを示します。

1回の音声AI通話でどんなデータが生成されるのか？

Retellで接続された通話は7種類のデータを生成し、すべてcall_idで識別される1つの通話オブジェクトにまとめられます：

• 録音。WAV形式の音声です。全話者をまとめたシングルチャネルのファイルと、各話者を個別のチャネルに分けたマルチチャネルのファイルがあります。
• 文字起こし。プレーンテキスト、タイムスタンプ付きの発話リスト、そしてすべてのツール呼び出しとその結果を織り込んだバージョンがあります。
• 通話後分析。組み込みフィールド（call_summary、user_sentiment、call_successful、in_voicemail）に加え、boolean、テキスト、数値、セレクターとして定義できるカスタムフィールドがあります。
• ログ。LLMのリクエストとレスポンスの公開ログに加え、エージェントがナレッジベースを使用する場合はその検索ログがあります。
• 変数とメタデータ。通話時に渡された、または通話中に収集された動的変数と、独自IDを格納できる自由形式のmetadataオブジェクトです。
• 電話番号。着信通話の発信者番号と、発信通話でダイヤルした番号です。
• 運用フィールド。タイムスタンプ、通話時間、ステータス、切断理由、転送先、レイテンシ、コストです。

これらの多くは通話終了後にのみ取得でき、接続されなかった通話ではカスタム分析フィールドは空のままです。

各データはどこに保存され、どう取り出すのか？

すべてのデータはRetellワークスペース内の通話レコードに保存され、webhook、API、ダッシュボードのCSVエクスポートという3つの経路で取り出せます。

連携を構築する際に重要なポイントは次の4つです：

• List Callsはレスポンスを小さく保つため、文字起こしとrecording_urlを省略します。そのため一括バックフィルでは、call_idごとにGet Callと組み合わせて使用します。
• webhookは10秒でタイムアウトし、最大3回再試行されるため、call_idで重複排除してください。
• 各webhookにはAPIキーで検証するx-retell-signatureヘッダーが含まれ、Retellは許可リスト登録用のIP（100.20.5.228）を公開しています。
• CSVエクスポートはダッシュボード上で適用中のフィルターに基づいて作成され、1週間保持されます。List Export Requests（GET /v2/list-export-requests）は各エクスポートのステータスとダウンロードURLを返します。

Retellは通話データをどのくらい保持し、保存をオフにできるのか？

デフォルトでは、Retellは通話データを無期限に保持します。この設定はエージェントごとにSecurity & fallback settingsで変更できます。

保持期間。1、3、7、30、60、90、180、365、730日、または無期限から選択できます。APIではdata_storage_retention_daysを設定します。期限切れのデータは毎日完全に削除され、対象は録音、文字起こし、ログ、動的変数、メタデータです。Retellは一部の基本メタデータを内部的に保持しますが、その通話は履歴やAPIレスポンスに表示されなくなります。

保存モード。次の3つから選択します：

• Everything（すべて）。文字起こし、録音、ログが保存されます。
• Everything except PII（PII以外すべて）。選択したPIIカテゴリを除去した状態でコンテンツが保存され、元の生データは削除されます。
• Basic Attributes Only（基本属性のみ）。文字起こし、録音、ログは保存されず、Get Callはそれらを含まない通話データを返します。

保存をオプトアウトした場合でもwebhookには文字起こしと録音が含まれますが、録音リンクはwebhook到着から10分で失効します。切り替える前にwebhook受信側を構築しておいてください。

Update Callのdata_storage_settingでは、個別の通話をより厳格な設定にすることはできますが、緩めることはできません。権限のあるダッシュボードユーザーは通話の機密データを削除したり、通話自体を削除したりでき、Delete Call（DELETE /v2/delete-call/{call_id}）を使えばAPIで同じ操作が可能です。いずれも元に戻せません。

録音とログのURLはデフォルトでは失効しません。Opt In Secure URLs（opt_in_signed_url）を有効にすると、リクエストした各URLは署名付きとなり、24時間後、または1分から7日の範囲で設定した期間の経過後に失効します。

PII秘匿化で実際に何が除去されるのか？

Everything except PIIでは、Retellは通話後に選択されたカテゴリを検出し、該当箇所を[email 1]のような番号付きプレースホルダーに置き換えます。13のカテゴリは、氏名、住所、メールアドレス、社会保障番号（SSN）、パスポート、運転免許証、クレジットカード、銀行口座、パスワード、PIN、医療ID、生年月日、顧客アカウント番号です。

スクラビングの対象は文字起こしだけではありません。録音（PII部分はビープ音に置き換え）、公開ログ、動的変数、メタデータ、通話サマリーとカスタム分析データ、ツール呼び出しの引数と結果も対象です。いずれかのカテゴリが有効な場合、DTMFの数字は[PII INFO]になります。

phone_numberを選択すると、通話レコード自体から顧客の電話番号（着信ではfrom_number、発信ではto_number）が削除されます。下流のシステムがその番号で照合している場合は、オフのままにしてください。

一部のフィールドは一切スクラブされません。call_id、agent_id、タイムスタンプ、ステータス、切断理由、call_successful、user_sentiment、コスト、カスタム属性などです。これらも除外したい場合は、Basic Attributes Onlyまたは保持期間を使用してください。

アクセスはロールベースです。Memberロールはスクラブ済みの履歴のみを閲覧でき、AdminとDeveloperは生の文字起こしと録音を閲覧できます。

データはどこでホストされ、セキュリティ部門は何を確認すべきか？

Retellのコンプライアンスドキュメントには、RetellがHIPAAおよびGDPRに準拠し、SOC 2 Type 1およびType 2の認証を取得していること、GDPR準拠のデータ処理補遺（DPA）を備えたAWSを利用することでGDPRに対応していること、そして現在EU域内ではサービスを運用していないことが記載されています。BAAとDPA（EU標準契約条項付き）は追加料金なしでセルフサインでき、証明書とレポートはCompliance Trust Centerで確認できます。

公開ドキュメントには、データごとの保存リージョンや基盤となるストレージサービス名は記載されていないため、推測で判断しないでください。Retellに書面で確認し（support@retellai.comがセキュリティレビュー、ベンダー評価、サブプロセッサー一覧に対応しています）、自社の設定も確認しましょう：

• 通話音声はどこで処理され、表内の各データはどこに保存されるか？
• 音声、文字起こし、分析を扱うサブプロセッサーはどこか？
• 本番環境の各エージェントの保持期間と保存モードは自社のポリシーに合致しているか？
• セキュアURLは有効で、有効期限は許容できる範囲か？
• 自社ユーザーのうち、AdminまたはDeveloperロールを持ち、生データを閲覧できるのは誰か？
• webhook受信側は署名を検証し、保持期間による削除の前に必要なデータを保存しているか？

契約面（BAAとDPAの違い、データ所在地に関する障壁、調達の各段階）については、音声AIを導入する前にエンタープライズの購買担当者が知っておくべきことをご覧ください。

CRMには何が、どの経路で届くのか？

経路によって異なります。Salesforce、HubSpot、Microsoft Dynamics 365、GoHighLevel、Zoho CRMとのRetellのネイティブ連携では、連絡先をインポートし（2026年8月時点で5分ごと）、通話後分析フィールドを連絡先フィールドにマッピングし、フィールドの変更をCRMに反映し、各通話をアクティビティとして記録します。たとえばSalesforceのTaskには、通話時間、サマリー、会話ID、電話番号、切断理由が含まれます。アウトバウンド同期は、Create new contacts in CRMを有効にしない限り既存レコードのみを更新し、アクティビティは接続されたCRMからインポートされた連絡先についてのみ記録されます。

録音と完全な文字起こしがCRMに届くのは、HubSpot Marketplaceアプリの通話ログや自社のwebhook書き込み処理のように、その経路がこれらのデータを運ぶ場合のみです。トリガーから書き戻しまでの仕組みについてはCRMと音声AIのワークフローをご覧ください。ネイティブに接続できるサービスは連携ディレクトリに掲載されています。

通話前の読み取りと通話後の書き込みを、テスト可能な1つのループにするには？

連携が完成したと言えるのは、1回の通話が開始前に正しいレコードを読み取り、通話中に予約を取り、終了後に技術者向けメモを書き込むという一連の処理を、すべて同じレコード上で行えたときです。RetellのエージェントのWorkflowページでは、これを1つのグラフとしてモデル化します。フィールドサービスの窓口を例にすると：

1. 通話前の読み取り。通話前関数がCRMで{{user_number}}を検索し、レコードIDを変数にマッピングします。着信通話では最大1分間これを待機し、発信通話ではダイヤル前に5分間の猶予があります。
2. 通話中の予約。エージェントはカレンダーツール（Cal.com、Calendly、GoHighLevelのカレンダー）、またはスケジューリングシステムのAPIを呼び出すカスタム関数で予約を取ります。このAPIではX-Retell-Signatureヘッダーを検証できます。予約IDは変数に格納されます。
3. 通話後の書き込み。通話後関数がメモを作成します。Salesforce、Dynamics 365、Zohoのツールはメモを作成し、Zendeskは非公開メモを追加し、それ以外はカスタム関数で対応します。通話前に取得したレコードIDを再利用して{{call_summary}}やaccess_instructionsなどのカスタムフィールドを書き込み、予約変数が存在する場合にのみ実行されるよう条件が設定されます。通話後関数は5分で停止します。

検索に失敗した場合、それに依存するすべての関数はスキップされるため、レコードIDなしでメモが書き込まれることはなく、通話自体はそのまま進行します。プラットフォームチーム向けの制約が1つあります。ワークフロー関数はダッシュボードでのみ設定でき、公開APIには含まれていない（2026年8月時点）ため、Infrastructure as Codeでは管理できません。

ループは2段階でテストします：

• モックを使ったシミュレーションテスト。すべてのカスタム関数とカレンダーツールをモック化します。モック化されていない関数は実際のendpointを呼び出し、実際の予約を作成してしまう可能性があります。
• サンドボックスレコードに対する1回の実通話。Webまたは電話でテスト通話を行い、通話履歴で開きます。通話前関数はBefore call、通話後関数はCall endedの下に、送信された引数と返されたレスポンスとともに表示されます。予約が存在し、メモが同じレコード上にあり、受信側がそのcall_idについてcall_analyzedイベントを1件記録していれば合格です。

パイロット計画全体については、本番稼働前に音声エージェントプラットフォームを評価する方法をご覧ください。通話前関数と通話後関数の仕組みについては、Retell Workflowsをご覧ください。

データマップを活用する

エージェントごとに表を埋めてセキュリティ部門の回答を添付すれば、1枚の資料でレビュー、連携計画、監査証跡をまかなえます。Retellが各通話から何を抽出し、それがどのように自社システムへ流れるかを確認するには、まずRetellの通話後分析をご覧ください。