WooCommerce 10.9で取引メールログ機能がコアに統合、送信失敗の可視化でトラブル解決が容易に
WooCommerceのメールトラブルシューティング用ドキュメントは、サポート対応の中で常に上位のアクセス数を記録してきた。全サポートやり取りの1%以上で、最終的にこのドキュメントを案内する流れになっているという。こうした状況を踏まえ、WooCommerce開発チームは問題の切り分けに不可欠なログ機能をコアプラグインに組み込む判断を下した。
WooCommerce 10.9では、取引メール（トランザクショナルメール）の送信ログ機能が標準搭載される。店舗運営者はどのメールが正常に送信され、どのメールが失敗したのかをログで一元的に確認できるようになる。失敗時には具体的なエラー理由も記録されるため、従来のように外部のログ取得プラグインを導入する手間が省ける。
取引メールのログ機能の仕組み
このデモ図で示すように、従来はエラーのたびに外部ツールやプラグインを頼っていたが、10.9以降はWooCommerce本体が自動的にメール送信のログを取得する。店舗運営者の負担が一段階減る形だ。
内部設計の要点
新たに導入されるEmailLoggerクラスは、以下の4つのフックに接続される。これにより、メール送信のあらゆる局面を捕捉できる仕組みになっている。
- woocommerce_email_sent：WooCommerceがメールを送信するたびに発火し、成功または失敗の真偽値と
WC_Emailインスタンスを受け取る。 - woocommerce_email_disabled：メール種別が設定で無効化されていて送信が行われなかった場合に発火する。
- woocommerce_email_skipped：受信者が存在しないなどの前提条件を満たさず、送信がスキップされた場合に発火する。短い理由識別子も渡される。
- wp_mail_failed：WordPress全体のメール送信失敗フック。ここから
WP_Errorメッセージを取得し、SMTP接続エラーなどの具体的な原因をログに含める。
いずれの結果も、wc_get_logger()を通じて新しいソース名transactional-emailsの下に書き込まれる。WooCommerce標準のロガーを経由するため、店舗側がすでに設定しているログハンドラ（ファイルまたはデータベース）とログレベルしきい値をそのまま利用できる。
- ログハンドラ：デフォルトは
wp-content/uploads/wc-logs/ディレクトリへのファイル出力だが、WooCommerce ＞ ステータス ＞ ログ画面でデータベース保存に切り替えている場合はそちらが使われる。新たなストレージ層は不要だ。 - ログレベル：送信成功は
INFO、失敗はWARNING、無効化やスキップによる未送信はNOTICEとして記録される。本番環境でエラーレベルのみ取得する設定にしておけば、失敗だけを素早く把握できる。 - 保持期間：他のWooCommerceログと同様に、WooCommerce ＞ ステータス ＞ ログ ＞ 設定から保持ポリシーを管理できる。
ログに記録される情報
各ログエントリは1行で完結し、大量のメールが飛び交う店舗でもストレージへの影響はほとんどない。文脈情報は次のような構造で出力される。
context = [
'source' => 'transactional-emails',
'email_type' => 'customer_processing_order',
'status' => 'sent' | 'failed' | 'disabled' | 'skipped',
'recipient' => 'jdoe' | 'guest' | 'jdoe, guest',
'reason' => 'no_recipient', // スキップ時のみ
'order' => 12345, // 注文ID、状況に応じて'product'や'user'が入る
]ログレベルが3段階に整理されているため、WARNINGなら即座に問題を疑い、NOTICEなら設定通りの挙動であることを確認し、INFOなら正常に送信されたと判断できる。フィルタリングやアラートの仕組みと組み合わせれば、運用の自動化にもつなげやすい。
注文画面での確認
ログとは別に、個々の注文に関連づいたメールの履歴が注文ノートにも表示されるようになった。WooCommerce ＞ 注文から任意の注文を開くと、その注文に対して送信が試みられた取引メールとその成否が一覧できる。
ここで注意したいのは、注文ノートに表示されるのは「実際に送信が試みられたメール」だけという点だ。設定で無効化されているメール種別や、受信者不在でスキップされたものは表示されない。注文ノートを無駄に長くせず、期待される挙動とその結果に焦点を絞る設計思想がうかがえる。
プライバシーと拡張性への配慮
上図のように、メールアドレスが直接ログに書き込まれることはない。プライバシー保護と拡張性の両面に配慮した設計が盛り込まれている。
プライバシー保護の仕組み
受信者のメールアドレスはログに一切出力されない。resolve_recipient()メソッドが各アドレスをWordPressのユーザー名に変換する。アカウントを持たない購入者（ゲスト）の場合は'guest'というラベルに置き換えられる。BCCなどで複数の受信者がいる場合は、カンマ区切りのラベル一覧が記録される。
PHPMailerが返すエラー文字列には、しばしば受信者アドレスが直接埋め込まれているが、これもredact_emails()という正規表現によるスクラブ処理で除去される。この処理はRemoteLogger::redact_user_data()と同等のロジックを採用しており、WooCommerce全体で一貫したプライバシー保護が維持される。
拡張ポイント
WooCommerce 10.9では、メールログの動作をカスタマイズするためのフィルターフックが2つ追加されている。
- woocommerce_email_log_enabled：ログ出力の有効・無効を切り替える。グローバルに無効化したり、
$email_idをチェックして特定のメール種別だけ対象外にできる。 - woocommerce_email_log_context：ログに書き込まれる文脈情報を書き換える。フィルターには書き込み前の配列が渡されるため、項目の追加・削除・変更が自由に行える。
ログ機能そのものは、WooCommerce ＞ ステータス ＞ ログ ＞ 設定タブから管理画面でオフにできる。特定の機能のみを無効にしたい場合は、以下のコードをテーマのfunctions.phpなどに追加する。
add_filter( 'woocommerce_email_log_enabled', '__return_false' );パフォーマンスへの影響を最小限にしたい場合や、すでに別のシステムでメールログを収集している場合は、このフィルターで柔軟に対応できる。
実装上の注意点と今後の展望
ログ機能にはひとつ、既知の制限が存在する。wp_mail_failedはWordPress全体のグローバルなフックであるため、WooCommerceのメール送信処理の直後に別のプラグインが送信に失敗した場合、そのエラーが誤ってWooCommerceのメールに紐づく可能性がある。
$last_mail_errorはWooCommerceのメール送信ごとにクリアされるため、古いエラーが後続の処理に引き継がれることはない。しかし、送信の直後という非常に狭い時間枠では、別のエラーが紛れ込む余地が理論上残る。この事象は実際にはまれであり、影響を受けるのは人間が読むための失敗理由テキストだけだ。email_typeやstatusといった主要な情報は常に正確である。
この取引メールログ機能は、Automatticが実施した「Radical Speed Month」の一環として開発された。まずは診断機能としての土台を固め、次のステップではWooCommerceが自らメールエラーを警告し、修正を支援する能動的なレイヤーの追加を検討しているという。トラブルシューティングにかかる時間をさらに短縮し、より多くの店舗運営者がメール問題に煩わされずに済む未来を描いている。
この記事のポイント
- WooCommerce 10.9から、取引メールのログ機能がコアプラグインに標準搭載される。外部ツール不要で送信の成否と失敗理由を把握できる。
- ログは
INFO（成功）、WARNING（失敗）、NOTICE（未送信）の3段階で出力され、管理画面の注文ノートにも関連メールの履歴が表示される。 - メールアドレスはログに直接記録されず、ユーザー名やゲストラベルに変換される。エラーメッセージ内のアドレス情報も自動で除去される。
- フィルターフックを使ってログ出力の無効化や文脈情報のカスタマイズが可能。パフォーマンスや既存システムとの兼ね合いで柔軟に調整できる。
- 開発チームは今後の展開として、エラーを自動検知して運営者に通知する仕組みの追加を視野に入れている。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験