Email Reportで処理の通知を楽に！！

「最後のひと手間」も自動化に

こんな依頼、受けたことはありませんか？

「昨日取り込めなかったレコードの一覧、毎朝メールで送ってくれる？」

「月次の売上サマリ、経理にも CSV で回してほしいんだけど」

データは既にXplentyのパイプラインを通じで流れていた。しかし、受け取る側はBIツールにログインしたくないし、S3のバケットも見に行かない。結局、誰かが手でクエリを流してExcelに貼り付けてメールする。

そんな運用が残っているチームは意外と多いはずです。

Email Report デスティネーション は、この 「最後のひと手間」 をパイプラインの中に組み込むためのコンポーネントです。パイプラインの出力を、そのまま受信者のメールボックスに届けます。

何ができるコンポーネントなのか

Email Reportデスティネーションは、パイプラインの終端に置くコンポーネントです。上流から流れてきたレコードを、次の 3 つの形でメールに載せて送信します。

出力形式	内容	イメージ
テキスト添付	レコードをタブ区切りのテキストファイルとして添付
本文の表	レコードをHTMLの表としてメール本文に描画
CSV添付	レコードをCSVファイルとして添付

「概要は本文で見せて、明細は CSV で渡す」といった使い方ができます。ただしCSV添付とテキスト添付のどちらか一方だけを選びます。

要点の通知が主な目的

ここが一番大事なポイントです。Email Reportはダイジェストと通知のためのコンポーネントであり、大量データのエクスポート用ではありません。

出力にははっきりとした上限があります。

出力	上限
メール本文の表	最大 1,000 行
CSV／テキスト添付	最大 500,000 行、かつ 20 MB

つまり「異常データ 20 件を担当者に知らせる」「日次 KPI を 1 行で送る」「例外リストを 300 行の CSV で渡す」——こういった用途にはぴったりです。
一方、「全顧客マスタ 800 万行を毎日送る」といった要件には向きません。データセットそのものを渡したいときは、S3 や Snowflake などのファイル／ウェアハウス系のデスティネーション・コンポーネントを使い、Email Report は 「処理が終わったこと」と「要点」を知らせる役割に留めるのが定石 です。

設定してみる

パッケージ画面で Email Reportコンポーネントを配置し、上流のコンポーネント（変換や集計の出力）と接続したら、設定画面を開きます。設定は 3 つのセクションに分かれています。

1. Recipients & Message（宛先とメッセージ）

項目	説明
Send to	受信者のメールアドレス。カンマ区切りで複数指定できます。
Subject	件名。${variable} 形式の変数参照が使えます。
Intro text（任意）	表の上に表示される本文テキスト。プレーンテキストでも HTML でも記述でき、こちらも変数参照が使えます。

件名と本文で変数が使える、というのがこのコンポーネントの地味に効くポイントです。変数は実行時に解決されるので、

件名: [日次チェック] 取り込みエラー $_JOB_SUBMISSION_TIMESTAMP

のように書いておけば、実行ごとに日時の入ったユニークな件名になります。受信トレイでスレッドが1本にまとまってしまう問題を避けられますし、後から「どの実行のメールか」を追いやすくなります。

利用できる変数は、下記の2種類です。

項目	説明
ユーザ定義変数	パッケージ変数として定義した値。たとえば $client に得意先名を入れておけば、件名: $client 様向け 月次レポートのように差し込める
事前定義変数	$_JOB_ID（ジョブ識別子）、$_JOB_SUBMISSION_TIMESTAMP（ジョブ投入時刻の UTC・ISO-8601 形式）など

事前定義変数の一覧は ETL: System and Pre-Defined Variables を参照してください。

Intro text には「このレポートは自動送信です」「件数が 0 件の場合は異常ありません」といった受信者向けの前置きを入れておくと、問い合わせがぐっと減ります。HTML が使えるので、<b> で強調したり、社内 Wiki へのリンクを張ったりもできます。

2. Email Contents（メールの中身）

ここで先ほどの 3つの出力形式を選びます。最低１つは選択が必要です。また、選択可能な添付ファイルは１種類だけです。

• Preview the rows as a table in the email body

  • レコードをHTMLの表として本文に描画（最大 1,000 行）

• Attach the rows as a CSV file

  • CSV として添付。ファイル名を指定可能（既定 report.csv）

• Attach the rows as a text file

  • タブ区切りテキストとして添付。ファイル名を指定可能（既定 report.txt）

ファイル名は既定のままでも動きますが、report.csv が毎日届くとダウンロードフォルダで衝突します。daily_errors.csv のように用途が分かる名前に変えておくことをおすすめします。

3. Delivery Options（配信オプション）

• Fail the job if the report email cannot be sent

  • 既定で有効で、メールを送信できなかった場合にジョブを失敗させます

• When the input is too large for one email

  • Truncate and send（既定・データをサンプリングして送信）
  • Fail the job（ジョブを停止）から選択します

1 つ目のオプションは、既定の有効のままにしておくのが基本です。これを無効にすると、メールが届かなくてもジョブは「成功」として終わります。通知が届かなかったことに誰も気づかない、という一番まずい状態になりかねません。「届かなかった」をジョブ失敗として可視化する、という設計思想です。

2 つ目は、データが上限を超えたときの挙動です。「件数が多いこと自体が異常のサイン」であれば Fail the job、「上位数百件だけ見えれば十分」であれば Truncate and send を選びます。

実践: 「注文失敗を通知する」パッケージ

最小構成で動かしてみましょう。注文データの取り込みでバリデーションに引っかかったレコードを、注文担当にメールする、というシナリオです。

パッケージ構成

[Database Source: staging_orders]
        │
        ▼
[Filter: status = 'failed']
        │
        ▼
[Select: order_id, customer_id, error_reason, created_at]
        │
        ▼
[Email Report Destination]

設定内容

セクション	設定
Send to	[e-mail], [e-mail]
Subject	[Daily_report]Failed order list(${_JOB_SUBMISSION_TIMESTAMP})
Intro text	<p><b>失敗した注文処理一覧</b>です。対応手順は社内ウィキをご確認ください。</p>
Email Contents	本文の表 ✅ ／ CSV 添付 ✅（ファイル名 failed_orders_report.csv）
Delivery Options	送信失敗時にジョブを失敗させる: 有効 ／ 入力が大きすぎる場合: Truncate and send

受け取るメールのイメージ

ここでポイントになるのが、手順 3 の Select で列を絞っているところです。Email Report は上流から来た列をそのまま出力するので、絞り込みをしないと内部 ID やハッシュ値まで並んだ、読みづらい表がそのまま届きます。「メールに載せる直前に整える」——この一手間が、レポートの読みやすさを決めます。

差出人アドレスを自社ドメインにする

既定の差出人は [e-mail] です。社内向けの通知ならこのままでも実用上は困りませんが、顧客にレポートを送る用途では自社ドメインにしたくなります。

その場合は Settings > Account Settings > Email Sender で設定します。

項目	説明
From address	送信元アドレス
From name（任意）	受信者に表示される表示名
Reply-to（任意）	返信先アドレス

なお、カスタムドメインの利用にはアカウントの承認が必要です。利用を予定している場合は、早めにサポートへ申請しておきましょう。あわせて、そのドメインで SPF / DKIM などの送信ドメイン認証を設定しておくと、迷惑メール判定を受けにくくなります。

つまずきやすいポイントと運用のコツ

1. 上流で絞る。メールで絞らない。
Email Report には「先頭 N 件だけ送る」という設定はありません。件数のコントロールは、上流の Filter や集計（Aggregate）で行うのが前提です。「本文の表は 1,000 行まで」という上限は、その設計思想の表れでもあります。

2. 「0 件のときも送るか」を決めておく。
エラー通知の場合、0 件なら送らない方が親切に見えますが、「今日は届かなかった」が「異常なし」なのか「ジョブが動かなかった」なのか区別できなくなります。0 件でも送る（Intro text に「0 件＝異常なしです」と明記しておく）方が、運用上は安全です。

3. 件名は必ず変数で一意にする。
毎日同じ件名のメールは、メールクライアント側で 1 スレッドに畳まれてしまいます。${_JOB_SUBMISSION_TIMESTAMP} を件名に入れておくだけで、この問題は避けられます。

4. 送信失敗時のジョブ失敗は、有効のままにする。
既定で有効になっている理由を尊重しましょう。「通知が届かないこと」に気づける仕組みは、通知そのものと同じくらい重要です。

5. 機微なデータを本文に載せない。
メールは転送されますし、受信者の端末にも残ります。個人情報や決済情報を扱うパイプラインでは、メールには「件数と概要」だけを載せ、明細は S3 などの安全な場所に出力して、そのリンクだけを Intro text に書く、という設計を検討してください。

まとめ

Email Report Destination は、派手な機能ではありません。けれど「データは出ているのに、見てほしい人に届いていない」という、データ基盤でよく起きる最後のギャップを埋めてくれます。

• 通知・ダイジェスト向け。大量エクスポートには使わない（本文 1,000 行 / 添付 500,000 行・20 MB）
• 件名と本文で変数が使えるので、実行ごとに文脈のあるメールを送れる
• 送信失敗をジョブ失敗として扱える（既定で有効）ので、通知の不達に気づける
• 読みやすさは上流の Filter / Select で決まる

まずは、既存のパッケージの終端に 1 つ足してみるところから。所要時間は 10 分もかかりません。