お客様に送信したメールと同等のものを確認する方法を検討してみた

## はじめに
この記事は <a href="https://qiita.com/advent-calendar/2022/trustbank">トラストバンク Advent Calendar 2022</a> の20日目の記事です。
はじめまして。2022年10月からトラストバンクにサーバーサイドエンジニアとしてジョインしました @rfb_hrt です。
初のTech Blog投稿なので、どきどきしますが、同じような課題に直面している方の一助になれればと思います。

今回は過去運営に関わったあるECサイトでのメールにまつわるお話をお送りしたいと思います。

## 目次
<div class="css-38zwww"><ul>
<li>
<a href="#お客様に送信したメールと同等のものを確認したい" class="focus">お客様に送信したメールと同等のものを確認したい</a>
</li>
<li>
<a href="#運用要件" class="">運用要件</a>
</li>
<li>
<a href="#メール共有サービス提供元ベンダーから泣きの連絡" class="">メール共有サービス提供元ベンダーから泣きの連絡</a>
</li>
<li>
<a href="#方針検討" class="">方針検討</a>
<ul>
<li>
<a href="#案メールサーバーのwebメール機能でメールを確認する" class="focus">案①：メールサーバーのWebメール機能でメールを確認する</a>
</li>
<li>
<a href="#案社内で利用しているgoogleworkmailに顧客対応部門用共有アカウントを設けそこに同じ内容のメールを送る">案②：社内で利用しているGoogleWorkmailに顧客対応部門用共有アカウントを設け、そこに同じ内容のメールを送る</a>
</li>
<li>
<a href="#案共用のrdp接続先を用意しそこにメールクライアントソフトを入れ独自ドメインメールで受信する" class="">案③：共用のRDP接続先を用意し、そこにメールクライアントソフトを入れ、独自ドメインメールで受信する</a>
</li>
<li>
<a href="#案amazon-workmailにアカウントを作り受信する" class="">案④：Amazon Workmailにアカウントを作り、受信する</a>
</li>
<li>
<a href="#案amazon-sesで受信しs3にメールを保存" class="">案⑤：Amazon SESで受信し、S3にメールを保存</a>
</li>
</ul>
</li>
<li>
<a href="#切替後のお話" class="">切替後のお話</a>
</li>
<li>
<a href="#おわりに" class="">おわりに</a>
</li>
</ul>
</div>

## お客様に送信したメールと同等のものを確認したい
ECサイト運営において、お客様コミュニケーションはメールが主流となるケースが多いと思います。
一言でメールと言っても、その種類も様々あります。

| 種類 | 例 |
|:-|:-|
| お客様アクションメール | お客様登録完了メール、アカウント情報変更メール、注文完了メール　など |
| 販促メール | キャンペーンメール、新商品お知らせメール　など |
| 業務メール | かご落ちメール、出荷完了メール、ポイント期限お知らせメール　など |

この中でも、お客様アクションメールと業務メールについては、メール1通ごとにその内容は異なってきます。
顧客対応部門への問合せの中には、
「メールの内容が注文した内容と異なっているのですが、、、」
「メールが届いてないけど、どんな内容で送られました？」
などメールに関する問合せも入ってくるため、<strong>お客様に送信したメールと同等のものを確認できるようにしておく必要があります。</strong>

## 運用要件
「お客様に送信したメールと同等のものを確認したい」といった場合の要件について、過去の経験を元にまとめてみます。
* お客様に送信したメールが取りこぼしなく全て確認できること
* 顧客対応担当者が適切な認証後に同時アクセス数を気にせず確認できる環境であること
* 該当のメールにすぐたどり着ける、検索性
* 容量に縛られず、かつ、過去1年分など一定期間分は保持しておけること

これらの要件を満たす方法は様々ありますが、過去取っていた方法が
**お客様へのメール送信時に、クラウドのメール共有サービス向けに、同内容のメールを送信する**
でした。

## メール共有サービス提供元ベンダーから泣きの連絡
ところがある日、利用していたメール共有サービス提供元ベンダーから泣きの連絡がありました。

<strong>「メールの容量が契約容量の10倍近く膨れ上がっています。
他社さんへのサービスレスポンス遅延も発生し得る状況なので、メール整理を進めてもらえないでしょうか。」</strong>

早速顧客対応部門へのヒアリングを行ったところ、業務に追われ、メールの定期的な整理ができていない状況で、今後もそういった時間を運用を組み込むことは難しいという状況だということがわかりました。
ベンダーへ状況を伝え、過去一定期間経過したメールについては自動で削除するようなことはできないのかと相談を持ち掛けたのですが、現状そういった機能は実装されておらず、別途カスタマイズが必要との回答でした。
カスタマイズが必要となれば、費用が発生するわけですが、その分の予算もなく、断念。
新たなメールの流入を抑えられたら、ベンダーの方で一括整理は対応していただけることになりました。

## 方針検討
そういうわけで、クラウドのメール共有サービスに代わるメールの受信環境をメリット/デメリットを挙げながら検討します。
（私見を多分に含みます。）

### 案①：メールサーバーのWebメール機能でメールを確認する

<table>
  <thead>
    <tr>
      <th>メリット</th> <th>デメリット</th>
    </tr>
  </thead>
  <tr>
    <td>
・既に環境は用意されている。<br>
・追加費用かからない。<br>
    </td> 
    <td>
・Webメールの機能に検索機能がなく、該当メールが探せない。<br>
・一定期間経過後のメール自動削除機能がなく、メールサーバー上にメールが残り続け、ディスク容量逼迫の恐れあり。<br>
    </td>
  </tr>
</table>

既にSquirrelMailによるWebメールの環境はあったのですが、検索機能がなく、該当のメールに辿り着けませんでした。
さらに一定期間経過後のメール自動削除の仕組みがなく、結局手動での削除が必要になり、運用を回せませんでした。

→**該当のメールを探せず、運用負担も大きいため、<font color="blue">不採用</font>**

### 案②：社内で利用しているGoogleWorkmailに顧客対応部門用共有アカウントを設け、そこに同じ内容のメールを送る

<table>
  <thead>
    <tr>
      <th>メリット</th> <th>デメリット</th>
    </tr>
  </thead>
  <tr>
    <td>
・追加費用なく実現できる。<br>
・運用担当者も操作に慣れている。<br>
・メールアカウント追加のみで環境構築作業が発生しない。<br>
    </td> 
    <td>
・「<a href="https://support.google.com/a/answer/1366776">Google Workspace における Gmail の受信制限</a>」にひっかかり、メールの受信遅延、取りこぼしが発生。<br>
・制限にひっかかったメールに対して送信側でもリトライキューが蓄積していく。<br>
    </td>
  </tr>
</table>

一時はこの案で試運用をしてみました。
お客様アクションメールだけであれば、一定時間のメール件数はそこまでではないのですが、業務メールは一括での大量送信になるため、短時間に集中してメールを受信することになります。
試運用を開始して間もなく、受信制限のため、メール受信遅延、取りこぼしが発生し、送信サーバー側でもリトライキューが蓄積し続ける状況が発生しました。

→**メールの受信遅延、取りこぼしが発生、かつ、送信サーバー側でもリトライキューが蓄積し続ける悪影響が発生したので、<font color="blue">一時試運用するも、ほどなく切り戻し</font>**

### 案③：共用のRDP接続先を用意し、そこにメールクライアントソフトを入れ、独自ドメインメールで受信する

<table>
  <thead>
    <tr>
      <th>メリット</th> <th>デメリット</th>
    </tr>
  </thead>
  <tr>
    <td>
・シンプル構成のWin環境を構築するだけの容易な環境構築作業。<br>
・追加費用もわずか。<br>
・メールの取りこぼしがない。<br>
    </td> 
    <td>
・RDPの同時接続数に制限があり
    </td>
  </tr>
</table>

RDPでの同時接続数に制限があり、かつ、後勝ちになるため、作業中に後から接続に来た人に取られて、調査中のものが途中で途切れ、再度初めからになる恐れがあります。

→**複数人同時使用も必須要件になるため、<font color="blue">不採用</font>**

### 案④：<a href="https://aws.amazon.com/jp/workmail/">Amazon Workmail</a>にアカウントを作り、受信する

<table>
  <thead>
    <tr>
      <th>メリット</th> <th>デメリット</th>
    </tr>
  </thead>
  <tr>
    <td>
・環境構築が比較的容易。<br>
・費用が1アカウント月額4USDと安価。<br>
・受信制限なし（注）<br>
・一定期間経ったメールは自動削除の設定可能<br>
    </td> 
    <td>
・メールの検索機能はあるが、クセがある
    </td>
  </tr>
</table>

環境構築も比較的容易で、費用も安価で、メールの検索もクセはあるものの、可能ということでこちらの案を採用しました。
メールの検索のクセというのを具体的に言うと、例えば、「hoge.123@fugafuga.com」というメアドのメールを検索したい場合
| 検索ワード | ヒット |
|:-|:-|
| hoge | しない（ヒットすることもある） |
| hoge.12 | しない |
| hoge.123 | する |
| hoge.123@fugafuga.com | する |

といった具合です。
これは、検索が単語単位に対して働くためで、内部的に単語としてヒットした場合のみ検索結果に上がってくるようになっています。
運用としては、メアド全部、お客様名全部を検索ワードにすればよい話なので、ここは運用でカバーいただくことにしました。

「受信制限なし（注）」と記載しましたが、サポートへ問合せたところ、大量のメールを受信するためには作られたおらず、そういった運用をする必要がある場合は、<a href="https://aws.amazon.com/jp/ses/">Amazon SES</a>の利用を推奨との回答でした。
しばらく運用を回してみて、1通あたりの送信間隔を調整し、今は取りこぼしなく運用できているので、このまま様子を見ている状況です。

→**必要要件を満たしているので、<font color="red">採用</font>**

### 案⑤：<a href="https://aws.amazon.com/jp/ses/">Amazon SES</a>で受信し、S3にメールを保存

<table>
  <thead>
    <tr>
      <th>メリット</th> <th>デメリット</th>
    </tr>
  </thead>
  <tr>
    <td>
・環境構築が比較的容易。<br>
・費用が受信1,000件につき0.09USDと安価。<br>
・受信制限なし<br>
    </td> 
    <td>
・S3内から該当メールを容易に検索できず、顧客対応担当者には不向き<br>
・一定期間経過後のメール自動削除の仕組みができるか不明<br>
    </td>
  </tr>
</table>

環境をうまく構築できれば最善案になり得るが、顧客対応担当者が容易に運用できる環境を用意するのに、調査と検証にそれなりの工数が必要で、案④で運用できることを考えると、そこまで工数をかけて用意する必要もないと判断。

→**調査、検証の工数がそれなりにかかるため、<font color="blue">不採用</font>**

## 切替後のお話
今回の運用切替はもはや運用破綻寸前だったこともあり、検討の結果、一旦要件を満たせる「<a href="#案amazon-workmailにアカウントを作り受信する" class="">案④：Amazon Workmailにアカウントを作り、受信する</a>」に着地したという感じです。
切替後、しばらくの間は予想通りというか、検索しても対象のメールが見つからないという問合せがちらほらありましたが、担当者の方もコツを掴んできて、しばらく経つとそういった問合せはなくなってきました。

運用切替後、利用していたメール共有サービスの方への新たな大量メールの流入が止まっていることが確認ベンダーの方でも確認が取れ、過去のメール整理が施され、今はそちらも支障なく運用できています。（今も問合せメールの管理で継続利用中）

ただ、<a href="https://aws.amazon.com/jp/workmail/">Amazon Workmail</a>も大量メールの受信のためには作られていないということもあり、今後メールの件数が増え、送信間隔が短くなってくると、メールの取りこぼしや、Bounce応答などが発生することも否定はできなそうです。
その際は再度「<a href="#Amazon SESで受信し、S3にメールを保存" class="">案⑤：Amazon SESで受信し、S3にメールを保存</a>」への移行も視野に検討していくことになりそうです。

他にも今回案に上がっていないもので、要件を満たせる手法があればコメントにてお教えいただけると助かります。

## おわりに
今回は顧客対応業務に必要な「お客様に送信したメールと同等のものを確認したい」という要件について検討した内容をまとめました。
同じような悩みを抱えて情報を探しに来た方の一助になれたら幸いです。

最後までお目通しいただきありがとうございました。


トラストバンクでは一緒に活躍いただけるエンジニアを募集中です！

https://www.wantedly.com/companies/trustbank/projects