# メールエラーイベントテーブル

メールキャンペーンの成功を監視し、問題をトラブルシューティングするために、Engage Studioはメールタスクに関連するさまざまなイベントを自動的に記録します。
開封、クリック、配信などの標準的なイベントは「events」テーブルにキャプチャされますが、一部の重要なエラーは、Engage Studio内でメールがAWS SESに正常に送信される_前_に発生する可能性があります。
このドキュメントでは、**「error_events」テーブル**について説明します。これは、Engage Studioがこれらのメール送信前の失敗イベントを記録する専用の場所です。

Error Eventsテーブルは、Engage Studio内でAWS SESへのリクエストが正常に送信される前に発生する**Engageタスクの失敗イベントを記録する**ために設計された特定のテーブルです。標準のメールイベントパイプラインは、メールレンダリングやキューイングなどの内部処理中に発生するエラーをキャプチャできません。この専用テーブルにより、これらのタイプの失敗を可視化できます。

# どのようなタイプのエラーが記録されますか？

このテーブルには主に2つの特定のタイプのエラーイベントが保存されます。

1. **メール処理失敗エラーイベント：** これらは、即時メール処理キューに関連付けられたメール処理を通じてキャプチャされる「ランタイムエラー」です。
2. **レンダリングエラーイベント：** これらは、メールコンテンツ自体を生成するプロセス中に発生する「レンダリングエラー」/「検証エラー」です（注：「Rendering Failure」はAWS SESによって予約されており、これらの内部エラーには使用されません）。


# このデータはどこで見つかりますか？

エラーイベントは、専用のTreasure Dataデータベースに保存されます。

* データベースの名前は`delivery_email_{DOMAIN_NAME}.events`で、`{DOMAIN_NAME}`は特定のメールドメインであり、特定の記号はアンダースコアに置き換えられます。
* このデータベース内で、メールイベントは通常`events`テーブルに保存されますが、ここで説明する失敗イベントは特に`error_events`テーブルに保存されます。


これらのイベントを確認できることを意図しています。

# Error Eventsテーブルにはどのような情報が含まれていますか？

`error_events`テーブルには、失敗した各メールタスクに関する詳細情報が含まれています。スキーマは、トラブルシューティングのためのコンテキストを提供するように設計されています。
`error_events`テーブルで見つかる主要な列は次のとおりです。

* `timestamp` (string): イベントが発生した時刻。メール処理エラーの場合、これは元のリクエストが行われた時刻です。レンダリングエラーの場合、これはエラーが発生した時刻です。これはISO8061形式で、ミリ秒精度とUTCの「Z」サフィックス付きです（例：`2025-03-17T05:37:25.436Z`）。
* `time` (bigint): `timestamp`列に対応するUNIXタイムスタンプ（秒単位）。
* `email_domain` (string) & `email_domain_id` (string UUID): タスクに関連付けられたメールドメインを識別します。
* `email_sender_id` (string UUID): メールに使用された特定の送信者を識別します。
* `email_template_id` (string UUID): 使用された特定のメールメッセージまたはテンプレートを識別します。
* `custom_event_id` (string): メール送信リクエストで設定した任意のカスタムID。
* `to_plain_address` (string): 元々表示名が含まれていた場合でも、シンプルな形式の受信者のメールアドレス。
* `from` (string): 設定されている場合は表示名を含む可能性がある送信者のメールアドレス。
* `to` (string): 設定されている場合は表示名を含む可能性がある受信者のメールアドレス。
* `subject` (string): メールの件名。
* `error_type` (string): 失敗のタイプを示します。これはメール処理イベントの場合は**「Runtime Error」**、レンダリング失敗の場合は**「Rendering Error」**になります。
* `error_message` (string): エラーの理由を英語で説明するテキスト。
* `error_timestamp` (string): メール送信が失敗したタイムスタンプ。レンダリングエラーの場合、これは通常`timestamp`列と同じです。これは`timestamp`と同じISO8061形式を使用します。
* `error_time` (bigint): `error_timestamp`に対応するUNIXタイムスタンプ（秒単位）。レンダリングエラーの場合、これは通常`time`列と同じです。


# これらのイベントはどのように記録されますか？

これらのイベントを記録するプロセスは、バックグラウンドで自動的に動作します。タスクがAWS SESに到達する前に失敗した場合（レンダリング中またはキュー処理中）、失敗イベントはDead Letter Queueを含む専用のシステムパイプラインによってキャプチャされ、最終的にデータベースのError Eventsテーブルにデータをストリームします。特定のエラーメッセージや時刻などの追加の詳細もキャプチャされ、テーブルに記録されるデータに含まれます。

# `td_log_`プレフィックスによる非PIIカスタム識別子列

`error_events`テーブルも`td_log_`プレフィックスによる非PIIカスタム識別子列をサポートしています。アクティベーションで出力列名が`td_log_`で始まるアウトプットマッピング（例：`td_log_member_id`）を定義すると、その列が`error_events`テーブルに自動的に追加され、該当アクティベーションから発生する各エラーイベントに対して値が入力されます。

これにより、生のメールアドレスに依存せずに送信前の失敗イベントを顧客レコードに紐付けることができ、`events`テーブルや`subscription_events`テーブルで使用しているものと同じ非PII識別子（内部会員ID、CRM ID、ハッシュ化されたIDなど）でエラーイベント分析が可能になります。

設定手順、制限（1アクティベーションあたり最大5個、ASCII文字のみの列名、列名256文字制限）、PIIを`td_log_*`にマッピングしないための注意事項については、[メール配信イベントテーブル](/ja/products/marketing-cloud/engage-studio/channels/email/email-delivery-events-table)を参照してください。