先日参加したJAWS DAYSでTwilioUGの方々とお話する機会があって、
TwilioのCopilotの事例がまだ少ないとのことだったので、書いてみる。
ブログでは、Twilioの話題を出したことは無いんですが、
Twilioを使ったSMS配信サービスと音声発信のサービスやってます。
SMSだけで言えば毎月5,000 ~ 7000件くらい、
音声発信もだいたい5,000件くらいでしょうか。
当初、SMS配信サービスを作った時に、
SMSのfromをTwilioで購入した電話番号にしていました。
利用数が増えるにつれ、「fromを文字列にしたい」という要望が出てきました。
他サービスでは、fromを番号ではなく英文字の送信者番号として送信しているものがあり、
どうしたら良いのかと考えていました。
SMSには「Alphanumeric Sender ID」というものがあり、これを使えば
実現できるものだと分かったため、さっそく実装を始めました。
これが2017年3月くらいだったかな。
テストの段階で気づいたんですが、Alphanumeric Sender IDだと受信できない端末？キャリア？も多く、
APIでPOSTするタイミングで、エラーコードの「21612」が返されることがありました。
Alphanumeric Sender IDで送りたいのだけれど、
SMS配信のサービスやってるのに
相手に届かないのはサービスとして困るので
英文字の送信者番号で送れなかった場合は、
Fromを番号で送信リトライするという処理も入れていました。
リトライを処理を入れてから、
数ヶ月様子を見てどれぐらいエラーコード「21612」が返されてるかを確認していました。
下記は、とある1ヶ月間での統計です。
SMSをAlphanumeric Sender IDで送信できた数 : 3500件
SMSを電話番号で送信できた数 : 1500件 (リトライ処理で送信した数)
この数字を見ると、だいたい30%近くのリトライ処理をやっています。
キャリア別で見ると、リトライ処理をしている番号は
auと沖縄セルラーの番号が半数超えていました。
auと沖縄セルラーが多いのは地域事情だと思いますが、
それにしても他キャリアに比べてSender IDで送れない場合が多かった。
1500件のリトライ処理もそこそこ多くて、この辺りをなんとかしたいなあと思ってました。
真面目に自分で実装するなら、Alphanumeric Sender IDで送信できなかったものをDBなりでリスト化しておいて
送信のたびにリストをチェックして、番号で送るかAlphanumeric Sender IDを利用するかを決定すれば実装できそうです。
ToとFromをマッピングしたテーブルを用意しておく感じですね。
ただ、日に日に増えてくるデータからマッピングを自分たちでやるのはヤダなあという感じもしてて、
どこかに任せたいと考えていたところ、Copilotに出会いました。
Copilotは、複数の番号をまとめて管理しSMSを効率良く配信できる機能を備えています。
サービスとして特にリアルタイム性を求める配信はしてないのでそこに魅力を感じてはなかったんですが、
Alphanumeric Sender IDと番号を登録しておけば、
SMS送信時に優先的にAlphanumeric Sender IDで送ってくれますし、できなければ番号で送ってくれます。
Copilotの固定送信者番号を使用すると、ToとFromの電話番号のマッピングを維持するようになります。
この機能を利用すれば、自前でToとFromをマッピングする機能を実装しなくてもよくて、全部Twilioに任せるとこができますし
エラーコードの21612が発生したときに、番号で送り返すリトライ処理も大幅に減ります。
実際に利用してみたところ、リトライ処理は無くなり、
送信ログを見てたらSMSをAlphanumeric Sender IDで送るか、電話番号で送るかの自動判別もTwilio側でやられていました。
こうして無事、Alphanumeric Sender IDを使いつつも、リトライを削減できました。
Twilioネタ、もう1件あるのでそのあたりも気が向いたら書きます。