blastengineを使い始めて便利だった点

## はじめに

最近、社内のあるアプリケーション内で blastengine を使い始めているので、利用してみて便利だった点を記載します。

私自身メール初心者ですので、メール初心者の方がメールを触ってみるきっかけにでもなれば幸いです。

## blastengineとは

ラクスライトクラウドさんが提供しているメール配信サービスです。  
APIやSMTPリレーでメール配信を行う事が可能です。

https://blastengine.jp/

## blastengineを使い始めた経緯

- 今までは自社のメールサーバを使い運用していたのですが、何か問い合わせがあった際にメール関連の詳細な対応が出来るメンバーが限られており（自分も詳細な対応が出来ない内の一人）、運用に負荷が掛かる状態でした。
- OS やミドルウェアの EoL 対応等、自前での管理から手離れしていこうという事もあり、その移行先として利用し始めたのが blastengine です。
- 現在では、一部アプリケーションから blastengine の SDK を用いてメール送信を行っており、今後の移行を見据えている状況です。

## 便利だった点の紹介

### 直感的にメール情報を閲覧できる点

blastengine の配信コンソール上からは「配信ID、配信日時、最終更新日時、メールアドレス、ステータス、応答コード、応答メッセージ、更新履歴」が見れます。  

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/411902/1425a174-e4b1-50ad-cdae-0303032b5ac8.png)

その中でも、特に便利だなと思ったのは以下。

- 配信ログから「配信日時」をクリックすると「件名、本文」が確認出来ます。
  - 自社メールサーバの場合、複数アプリケーションのメール配信を一手に担っていた関係で「特定のアプリケーションからのメール配信を追跡する」事は少々難しい状況でした。
  - blastengine の場合、各メールに対して配信IDも割り振られるので、配信IDとアプリケーション識別子をDB等に記録しておく事で追跡しやすい状態にする事も可能ですし、その場で「件名、本文」を確認して情報を得ることも出来ます。
  - なので今後はトラブルシュート時に便利そうだという印象を受けました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/411902/146909a9-305d-b542-3a26-7b7dc2560c4c.png)

- 更新履歴から「詳細」を見ると、配信の詳細が確認出来ます。
  - blastengine の場合、たとえば詳細画面からは「配信のリトライ」も見れます。
  - もし仮に配信のリトライがあった場合は「何回かリトライ後に配信された」のか「1回で配信された」のか、詳細が把握出来る点も便利そうだという印象を受けました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/411902/a6960ab0-088d-2dd8-0d1e-91c89a171e37.png)

### 細かく検索条件を絞れる点

- 「特定のエラー、特定のメールアドレス、特定の期間」等、何か問い合わせを頂いた際の絞り込みがスムーズに出来ます。
  - 一度、トラブル発生時にメールログを検索する機会がありましたが、詳細まで絞り込めるので手間なく利用する事が出来ました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/411902/853dc0e9-cf09-3919-67db-2b32f2900bba.png)

- 応答コードによる絞り込みも出来ます。
  - 自社メールサーバの運用だと、開発メンバーは片手間で不達メールの原因究明をする必要があり、メールに不慣れなメンバーの場合は不達メールの原因究明が難しい状況でした。
  - 今後は誰でも原因究明がしやすい状況になりそうなのが非常に嬉しい点です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/411902/4c691242-0153-9299-5b5b-5990c832fb6e.png)

### トライアルプランだと配信可能アドレスが制限されている点

blastengineの場合、トライアルプランだと「配信先のアドレス登録」が必要です。

場合によっては「いちいちアドレスを登録しないといけないので不便」と感じる事もあるとは思います。ただ個人的には、たとえば検証やテスト時に不用意に「メール配信」させたくない時に便利そうだと感じています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/411902/f8bc57bc-9d70-82f9-607b-689ab4aeb137.png)

## 今後検討が必要な点

便利だと思う反面、今後の blastengine 移行や運用の上で、少し注意しないといけないなという点も、実際に使い始める中で見えてきましたので、その紹介です。

### blastengine の Rate Limit

https://blastengine.jp/documents/#tag/Rate-Limit\

Rate Limit が 500req/m となっています。リトライ自体の処理は既に自社アプリケーション上に実装されているのですが、うっかり「メール数百通を一斉送信するような機能を工夫無しに実装」しないように気を付ける必要があります。

具体的な対策として「キューイングする」「処理自体の待ち時間を意図的に生み出す」「アカウントを追加で開設する」等、今後何かしらの対策を実施していく必要があります。

:::note info
2024年3月30日追記：
APIドキュメント上に500req/mを希望する場合は「問い合わせフォームへ」との文言が追加されていました。
![2024-03-30-10-24-54.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/411902/c682f0c8-00b5-6747-a9fe-4b8bda4573f3.png)
:::

### 権限管理

自社メールサーバの場合は、ログインユーザの権限管理を詳細に行うことが出来ましたが、「ログインユーザとパスワードさえ分かれば、誰でも触れる状況になった」事で、それが難しい状況となりました。

とは言っても「メールサーバの各種管理工数削減」のメリットに比べると微々たるデメリットだと思います。なので今後は別途権限管理の仕組みの検討が必要だな、と考えています。

:::note info
2025年6月12日追記：　　
どうやら現在は「ユーザー作成オプション」が追加されているようで、権限管理が可能なようです。
:::

## まとめ

- メールについての知識が浅い私の様な人間でも、直感的に配信ログと blastengine を利用しているアプリケーションログから配信の詳細を追えるようになったので、その点は自社メールサーバよりも運用負荷が低く、便利だなと感じた点でです。
- また、blastengineを触り始めたばかりの頃は「SPF？DKIM？なにそれ美味しいの？」状態でしたが、APIとして気軽に触れる（アカウント開設も簡単！）ので、メールに入門するハードルを下げる事が出来た点は非常に良かったなと、今となっては思います。

## 参考資料

blastengine

https://blastengine.jp/

blastengine SDK

https://github.com/blastengineMania

blastengine API

https://blastengine.jp/documents/