はじめに
こんばんは、mirukyです。
前回に引き続き、今回もAWS End User Messaging SMSを取り扱います。
業務で使用した際にそれがAWSマネコン上で手軽にSMS送信テストが行えたので、その方法を共有します。
この方法を試せば、文字エンコードのされ方であったり、メッセージが分割されるかどうか一目でわかるとても便利な機能となっています。
加えて、LambdaのPythonコードでSMS送信テストを行う手順も解説します。
目次
1.AWSマネコンでテストを行う手順
2.Lambdaでテストを行う手順
3.おわりに
AWSマネコンでテストを行う手順
下記の前提で進めます。不明な用語がある場合は、ぜひ前回の#1の記事をご覧ください。
送信者ID or ショートコード:送信者ID
送信者ID:TESTSMS
送信元:日本
送信先:日本
1.AWSマネジメントコンソール上でAWS End User Messaging SMSの画面を開き、左のペインから送信者IDをクリックする
2.画面右上の「リクエスト発信者」をクリック
3.送信先の国で「japan」を選択し、「次へ」をクリック
4.下記の通り選択し、「次へ」をクリック
番号機能:テキストメッセージ(SMS)
1ヶ月あたりの推定メッセージ量(オプション):5000未満
会社の本社(オプション):ローカル
双方向SMSメッセージング:いいえ
双方向SMSメッセージングですが、送信者IDは元々双方向に対応していないので、「いいえ」でお願いします。
5.下記の通り選択し、「次へ」をクリック
発信者タイプ:送信者ID
送信者ID:TESTSMS
リソースポリシー:Amazon Pinpointキャンペーンオーケストレーション、Amazon Simple Notification Service
リソースポリシーで上のAmazon Pinpointを許可しないと、マネコン上で送れません。今後SNSで用いる可能性も加味して、今回はSNSにもチェックをつけています
6.確認とリクエスト画面を確認し、「リクエスト」をクリック
これで送信者IDの発行完了です。
つづいて、マネコン上でSMS送信テストを行います。
7.左側のペインにある「概要」をクリックし、その後の画面で「テストメッセージを送信」をクリック
8.一番上の項目で、送信者IDと、先程作成した送信者ID名を選択する
9.送信先番号で認証済み番号をクリックし、ドロップダウンの確認済みの送信先番号を管理をクリックした後、新しい番号を確認をクリック、自分の電話番号を登録する。その後、確認済みの送信先番号から今追加した番号を選択する
送信先の電話番号に自分の電話番号を追加し、検証コードを送信、送られてきた検証コードをAWSマネコン上に入力することによって、確認済み電話番号を登録できる

この時に追加する番号ですが、090や080、070の最初の0を+81として+8190(090)、+8180(080)、+8170(070)と登録してください。この形態の番号を「E.164形式の電話番号」と言い、国際的に番号を一意に特定するために使われる形態です。AWS End User Messaging SMSはこの形式で無いと送信できません。
10.下記の通り選択し、メッセージ本文を入力し、テストメッセージを送信をクリック
設定セット:空白
保護設定:空白
メッセージ本文:これはテストです。
設定セットとは
設定セットは、SMS送信時に適用されるルールの集合です。
役割:メッセージ送信時のイベントルーティング・保護設定の適用
イベント送信先:配信成功/失敗などのイベントを CloudWatch, Kinesis, SNS 等に転送
保護設定との紐づけ:1つの設定セットに対し、1つの保護設定を関連付け可能
主な使い方
[設定セット] ── イベント送信先(CloudWatch 等)
│
└── 保護設定(Protect Configuration)
・送信APIで 作成した設定セット名を指定するだけで、紐付けたルールが一括適用される
・用途ごと(認証コード用、マーケティング用など)に設定セットを分けるのがベストプラクティス
参考: AWS End User Messaging SMS の設定セット - AWS
保護設定とは
保護設定は、不正送信・AIT(人為的トラフィック水増し)を防ぐための国別フィルタリング機能です。公式ドキュメントでは、下記の記載があります。
AWS End User Messaging SMS でメッセージを送信できる送信先の国を制御するには、保護設定を使用します。メッセージの送信を許可する国を制御することにより、メッセージ料金が高い国や事業を展開していない国への送信を回避できます。各保護設定には、SMS、MMS、音声の個々の許可国ルールとブロック国ルールが含まれています。メッセージングのユースケースごとに個別の保護設定を作成して、検出精度を向上させます。マーケティング通知などのユースケースをログイン/サインアップから分離すると、より正確なリスク評価が可能になります。さらに、あるユースケースが AIT に直面しても、他のユースケースはメッセージのフィルタリングなしでメッセージを配信し続けます。
メッセージ本文のエンコーディング形式について
SMS本文は、使用する文字によって 自動的に エンコード形式が選択されます。
エンコード形式の比較
| GSM | UCS-2(Unicode) | |
|---|---|---|
| 対応文字 | 英数字・一部記号のみ | 日本語・絵文字・多言語対応 |
| 1通あたりの文字数 | 160文字 | 70文字 |
| 日本語利用 | 不可 | 可 |
| 絵文字利用 | 不可 | 可 |
出典:SMS 文字制限
ポイント
・日本語を含む場合は自動的に UCS-2 になる : 1通あたり70文字に制限
・1文字でも GSM範囲外の文字が含まれると、メッセージ全体が UCS-2 になる
・課金はパート単位 : 文字数が多いと複数パート=複数通分の料金が発生
コンソール上で試してみます。

本文が英語の時、エンコーディング形式はGSMになりました。

一方、本文が日本語の時、エンコーディング形式はUCS-2になります。

文字数に対するメッセージパーツ(分割数)ですが、GSMは160文字まで1通換算です。

一方、日本語が含まれた場合のUCS-2形式の場合70文字まで1通換算でした。
このように、コンソール上でエンコーディング形式、メッセージパーツの個数を確認することができます。
11.SMS送信がされていることを確認する

送信者ID:TESTSMS
メッセージ本文:これはテストです。
どちらも問題ないことを確認できました!
Lambdaでテストを行う手順
マネコンに続き、Lambda(Python)からもSMS送信テストを行います。
1. Lambda関数を作成する

AWSマネジメントコンソールで Lambda を開き、「関数の作成」をクリックします。
関数名:sms-send-test
ランタイム:Python 3.14
アーキテクチャ:x86_64(デフォルト)
2. IAMロールに権限を追加する
Lambda関数に自動作成されたIAMロールに、SMS送信用のポリシーをアタッチします。

Lambda関数の「設定」タブをクリックし、「アクセス権限」リストをクリック画像のロール名のリンク部分(スクショでは写していません)をクリック

IAMコンソールで許可ポリシーの「インラインポリシーを作成」をクリック

サービスで「End User Messaging SMS」をクリックし、「SendTextMessage」を検索窓から検索し、チェックマークをつける。

もしくは、インラインポリシー設定画面にJSONタブがあるため、そちらに下記のJSONを設定する
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sms-voice:SendTextMessage"
],
"Resource": "*"
}
]
}

ポリシー名は sms-send-policy 等、任意の名前をつけて保存します。
本番環境では Resource を送信者IDのARNに絞り、最小権限の原則に従ってください。今回はテスト目的のため "*" としています。
3. Lambda関数にコードを入力する

「コード」タブの lambda_function.py を以下の内容に置き換えます。
import boto3
def lambda_handler(event, context):
client = boto3.client("pinpoint-sms-voice-v2")
response = client.send_text_message(
DestinationPhoneNumber="[確認済み電話番号]", # E.164形式(例:+8190XXXXXXXX)
OriginationIdentity="TESTSMS", # 作成した送信者ID
MessageBody="Lambdaからのテスト送信です。",
MessageType="TRANSACTIONAL", # TRANSACTIONAL or PROMOTIONAL
)
print(response)
return {
"statusCode": 200,
"body": {
"MessageId": response["MessageId"],
"Message": "SMS送信が完了しました。"
}
}
DestinationPhoneNumber:コンソール上でSMSテストを行った際に確認した電話番号
OriginationIdentity:コンソール上でSMSテストを行った際に作成した送信者ID
MessageBody:メッセージ本文。任意のメッセージで構いません。
MessageType:送信するSMSのタイプ
MessageTypeについて
前回の記事でも少し触れていますが、SMSには下記の2タイプがあります。
| タイプ | 用途 |
|---|---|
TRANSACTIONAL |
ワンタイムパスワード、注文確認など即時性の高い通知 |
PROMOTIONAL |
キャンペーン、マーケティングなどの販促メッセージ |
日本国内の送信ではどちらでも動作しますが、用途に応じて適切なタイプを選択してください。
入力後、「Deploy」をクリックしてコードをデプロイします。
4. テストイベントを作成して実行する

「テスト」タブをクリックし、以下の設定でテストイベントを作成します。
| 項目 | 値 |
|---|---|
| イベント名 | sms-test |
| テンプレート | hello-world(デフォルト) |
イベントJSONはそのままで構いません(今回のコードでは event を使用しないため)。
「テスト」ボタンをクリックして実行します。
5. 実行結果を確認する
テスト実行が成功すると、以下のようなレスポンスが返ります。
{
"statusCode": 200,
"body": {
"MessageId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"Message": "SMS送信が完了しました。"
}
}
スマートフォンに「Lambdaからのテスト送信です。」というSMSが届いていれば成功です。

テストが失敗する場合、以下を確認してください。
- IAMロールに
sms-voice:SendTextMessageの権限があるか - 送信先番号がE.164形式(
+81始まり)になっているか - 送信者IDが正しく登録・承認されているか
- Lambdaのリージョンと送信者IDのリージョンが一致しているか
終わりに
ここまでお読みいただきありがとうございます。
今回の内容は、いかがだったでしょうか。
次回のEnd User Messaging SMS記事では、より実用的にAWSアーキテクチャを作成し、実演してみようと思います。
では、またお会いしましょう。










