ClaudeのInfobip MessageでSMSを送る前に宛先と文面を確かめる

Infobip Messageコネクタは、ClaudeからSMS・RCS・MMS・Viberのメッセージを送れる送信系のコネクタです。顧客への案内連絡を会話から出せます。宛先を取り違えた送信は相手に届いてしまうので、送る前の確認を手順として決めておきます。

先に押さえておきたいのは、コネクタのツールが send と check_status の2つだけだという点です。送信前にプレビューを返す専用のツールは一覧にありません。確認は、Claudeの会話の中で「送信案」を作らせて人が読むこと、そして承認画面で止めることで組みます。この記事は、その組み方を順に示します。

Infobip Messageコネクタでできること

Infobip Messageは、Infobipが提供するコネクタです。1回のツール呼び出しでSMS・RCS・MMS・Viberのどれかに送れ、配信レポートを受け取れる可能性があると説明されています。想定用途は注文確認、配送の更新、予約のリマインド、単発の顧客向け通知です。チャネルごとの出し分けをこちらで書かなくてよい設計です。

ディレクトリ上の表示は次のとおりです。

「Anthropic verified」の表示があり、サインインが必須です。ディレクトリ側にはこの注意書きも並びます。開発者がどんなツールを出すかはAnthropicが管理しておらず、想定どおり動く保証も、後で変わらない保証もない、という内容です。送信系は影響が大きいので、この一文は軽く読み流さないほうがよい箇所です。

コネクタ全般の仕組みはClaude Connectorsとはにあります。

プレビュー用のツールがない前提で組む

Infobipの開発者向けドキュメントには、SMS用のMCPサーバーを使ったチュートリアルがあります。その流れでは、AIがまず sms/1/preview でSMSのプレビューを取り、内容が承認されてから sms/3/messages で送ります。文字数や通数もプレビューで確かめられます。

ただし、これはSMS用のMCPサーバー(https://mcp.infobip.com/sms)の話です。ドキュメントのエンドポイント一覧には、SMS・Email・WhatsApp・Viber・RCS・Voiceなどがチャネル別に並び、SMSサーバーの機能として「送信とプレビュー、予約、一括送信、配信レポート」が挙がっています。コネクタのURLは https://mcp.infobip.com/message で、この一覧には出てきません。

つまり、チュートリアルのプレビューや予約がコネクタでも同じ形で使えるとは、ページからは言えません。コネクタのページが示すツールは send と check_status だけです。check_status の中身についても個別の説明はなく、配信レポートを返せる可能性があるという記述が手がかりになる程度です。

だから、確認の層は次のように分けて考えます。

送信前に「送信案」を作らせる

承認画面で見るだけでは足りません。1件ずつ別の文面が出る送信では、画面に並ぶ値が多く、読み飛ばしやすいからです。承認の前に、Claudeに送信案の表を作らせて読む工程を挟みます。

Infobipのチュートリアルには、依頼のコツが3つ書かれています。送信元と宛先を指定すること、予約やURL短縮などの追加機能を指定すること、用途を説明してAIが適切な文面を作れるようにすることです。さらに、通数の制限や個別の情報(URLなど)を入れないと、AIが穴を作り話で埋めると注意しています。送信案を作らせる依頼は、この裏返しで書けます。

Infobip Messageで次のお知らせを送る準備をしてください。まだ送信しないでください。
 
- 用途: 明日の来店予約のリマインド
- チャネル: SMS
- 差出人: 指定の差出人名を使う(私が書いた値以外は使わない)
- 宛先: 下の一覧
- 文面の条件: 1通に収める。予約日時と店名を入れる。URLは私が渡したものだけ
 
出力は次の表にしてください。
| 宛先 | 差出人 | 文面 | 想定通数 | 気になる点 |
 
書かれていない情報は推測で埋めず、空欄にして聞き返してください。
一覧に重複・桁数の異常・国番号の抜けがあれば、表の後に別に列挙してください。
 
[宛先一覧をここに貼る]

これは例の依頼文です。ポイントは3つあります。

• 「まだ送信しない」と明示して、send の呼び出しまで進ませない
• 書かれていない値を推測で埋めさせず、聞き返させる
• 宛先一覧の異常(重複・桁数・国番号)を、文面とは別に列挙させる

チュートリアルの宛先は 447415774332 のように国番号から始まる形で書かれています。日本の電話番号を扱うなら、一覧の側を国番号つきの形にそろえてから渡すと、Claudeが番号の書式を推測する余地が減ります。どの書式が通るかは、少数の自分宛て番号で先に試して確かめるのが確実です。

送信案で読む観点

表ができたら、人が次の点を読みます。

チュートリアルの例文には「Reply STOP to opt out」が入っています。配信停止の案内の要否は用途と送り先の国の規則で変わるので、ここでは例文に入っていたという事実にとどめます。メールの送信同意と表示義務の点検は特定電子メール法の同意を営業メールの送信前にClaudeで点検するが扱っていて、SMSを同じ考え方で見直す際の下敷きにはなります。ただしその記事の対象はメールです。

送信の承認を send で止める

送信案を読み終えたら、次は send の呼び出し自体を止める設定です。

Claudeのコネクタには、ツールごとに「Always allow」「Needs approval」「Blocked」を選ぶ権限設定があります。サポート記事では、TeamとEnterpriseのオーナーが、コネクタの操作を組織全体で制限できると説明されています。例として、メールの検索と要約は許しても送信は禁じる、という使い分けが挙がっています。権限はツールの種類別(たとえば読み取り専用と書き込み・削除)に分類されて表示されます。

Infobip Messageのツールは2つだけなので、設定は単純です。

個人で使う場合は、組織単位の制限は使えません。その場合、Claudeの承認要求が出るたびに内容を読み、信頼できるツールにだけ「Always allow」を使うよう、サポート記事は案内しています。送信系の send をAlways allowにするのは、送信案の工程を人が必ず挟む運用でも、避けたほうがよい選択です。

Infobip側のドキュメントも、送信のような機微な作業ほど権限を絞るよう書いています。常時の無制限な権限だと、予期しない動作やプロンプトインジェクションで人の目を通らずに送られたり、承認の流れを飛ばした自動送信で費用がふくらんだり、規制に合わない文面が出たりしうる、という整理です。最小権限で、必要な期間だけ与える原則が示されています。権限のよくある設定ミスはClaude Connectorsの権限設定でよくある失敗と対策にまとめています。

承認画面では何を見るか

send を承認制にしたら、承認画面は送信案との照合に使います。

1. 宛先の件数と、先頭・末尾の番号が送信案の表と同じか
2. 文面が表で読んだものと1文字も違わないか
3. 差出人が指定した値か
4. 予約を付けた場合は、日時とタイムゾーンが意図どおりか

送信案と画面の値が食い違ったら、承認せず、Claudeに理由を説明させてから送信案を作り直させます。ここで許可すると、読んだ表の意味がなくなります。

まず自分宛てに試す

最初から顧客に送らず、小さな範囲で動きを確かめます。Infobipのドキュメントでは、無料試用のアカウントは、確認済みの番号にしかメッセージを送れません。SMSのチュートリアルでも、試用中の宛先は確認済みの番号に限られ、差出人はテスト用のServiceSMSが使われます。

試験の進め方は次のとおりです。

• 自分の確認済み番号1件だけで、送信案 → 承認 → send までを通す
• 送信案の表と、実際に届いたメッセージが一致するかを見る
• 届かない場合は、番号が有効で到達可能かを先に疑う(ドキュメントのトラブルシューティングの最初の項目)
• 問題がなければ、少件数の宛先に広げる。一覧が大きいほど、1回あたりの件数を小さく区切る

なお、これらの試用の制限は、Infobipのアカウントの状態に紐づく話です。コネクタ経由かどうかで挙動が変わるとは、どのページにも書かれていません。

送信後は check_status で結果を読む

送ったあとの状況は check_status で確かめます。配信レポートを受け取れる可能性があるとコネクタのページに書かれているので、送信後に「配信されたか」を聞くための入り口と考えられます。

予約を付けた場合は注意が要ります。SMSのチュートリアルでは、送信時刻が先の予約だと、実際に送られるまで配信レポートやログは出ないとAIが説明しています。依頼文には、送信後に結果を取るタイミングも書いておきます。

送信が終わったら、check_statusで結果を確認し、次の形で報告してください。
- 成功・保留・失敗の件数
- 失敗した宛先と、返ってきた理由の文言(そのまま)
予約送信の場合は、送信時刻の後に再確認が必要だと伝えてください。

失敗の理由は、返ってきた文言をそのまま出させます。Claudeが言い換えると、原因の切り分けに使えなくなるからです。

つまずきやすい点

メール系のコネクタで同じ「承認を挟む」運用を組んだ例は、ClaudeとMailerLiteを連携する方法にあります。削除系と送信系をどう分けて承認制にするかの考え方は、そちらと共通です。

近くのコネクタとの選び分け

Infobip Messageのページには、関連するコネクタとして、Gmail、Microsoft 365、Bird、Slack、Asana、Miroが並びます。このうち同じ「メッセージを送る」用途に近いのはBirdで、メール・SMS・WhatsAppの送信、通話、ユーザーの本人確認、エージェントの受信箱を扱うと説明されています。

選ぶ軸は、送りたいチャネルと、すでに契約している配信事業者です。Infobipのアカウントがなければ、サインインの先がありません。

手順のまとめ

• コネクタのツールは send と check_status の2つで、プレビュー専用ツールは一覧にない
• 送信前に、宛先・差出人・文面・通数を表にした送信案を作らせ、書かれていない情報は聞き返させる
• send はNeeds approvalにして、承認画面の値を送信案と照合する
• 最初は確認済みの自分の番号1件で通しで試す
• 送信後は check_status の結果を、失敗理由の原文つきで報告させる

送信案、承認、試験送信、結果の確認を会話の型にしておけば、案内連絡が増えても同じ手順で出せます。