インバウンドSMSと双方向メッセージング：プロダクトとサポートが運用できる受信箱パス

アウトバウンドSMSは、本格的なメッセージング製品の半分に過ぎません。顧客が返信できる瞬間 — またはレンタルDIDが通話イベントを受け始める瞬間 — に、プロダクト・サポート・コンプライアンスが守れるインバウンドパスが必要です。双方向メッセージングは「MOを有効にして祈る」ことではありません。受信箱の所有者、受信・送信できる番号、webhookの着地点、合法的に保存できる内容 — それらを定めた運用システムです。

本ガイドは、サポート、OTPフォールバック、コールバック、会話トラフィックのためにビジネス番号をレンタルするB2Bチーム — かつ日常運用を第三者ブランドポータルの中で行うことを拒否するチーム — 向けです。

「インバウンド」が実際に含むもの

多くのプリペイドCPaaS購入者にとって、インバウンドは緑のトグル以上のものです：

送信だけでき、一貫したインバウンドストーリーを示せないプラットフォームでは、メール転送とスクリーンショットで脆い受信箱を自作することになります。

番号購入前に受信箱パスを設計する

プロダクトとサポートは、最初のDIDレンタル前に一つの運用受信箱モデルで合意すべきです：

1. 誰が最初に読むか — エージェントコンソール、チケットシステム、人間エスカレーション付きボット？
2. キーワードの所有者 — マーケキャンペーン vs 規制対象のSTOP / HELP文言？
3. 共有チャネルに決して入れてはいけないもの — 決済、ID、健康データ。
4. 時間外の扱い — 自動確認、キュー、明確な顧客メッセージ付きハードストップ？

white-labelプラットフォームは、自社のブランド関係の下でそのモデルを運用できるべきです — エージェントを他社のops UIに閉じ込めてはいけません。

番号を受信＋送信にリンク（同一の商業アイデンティティ）

受信と送信が無関係なSKUとして扱われると、双方向は破綻します。

真剣な購入者が問う点：

• このDIDはSMS（必要なら音声イベントも）を受信でき、ルールが許す範囲で送信アイデンティティにも使えるか？
• 購入後、番号はアカウントに割り当てられるか — 第三者コンソールで誰かがクリックするまで「浮いた」状態ではないか？
• メッセージングプロファイルとwebhook宛先は、アウトバウンドに既に使うプラットフォームから制御できるか？

IOSORの番号パスはプリペイドでjust-in-time：カバレッジ検索 → 資金ホールド → 購入 → 割当。インバウンド readinessはその割当ストーリーの一部 — 第二ログインが要る謎の第二製品ではありません。

サポートが一文で説明できるキーワード

キーワードはポリシーであり、かわいい自動応答ではありません。

多くのチームに必要な最小セット：

• STOP / 配信停止 — opt-outを速やかに履行し、監査用に記録。
• HELP / 情報 — ブランド向けのクリーンなヘルプパス（時間、チャネル、エスカレーション）で返信。
• キャンペーンまたはロケールコマンド — プロダクトと法務が文言に署名した場合のみ。

所有者を文書化。本番でSTOPが失敗したら、それはコンプライアンスインシデント — 「ボット設定」チケットではありません。

返信には、収集予定のなかったPIIが含まれることが多い：氏名、住所、カード断片、医療文脈。保存はプロダクト判断として扱います。

同意とA2P型ゲートは依然適用：番号開通は全コリドーでの本番会話ボリュームの包括許可ではありません。規制パスを明確なreadiness状態の後ろに置くプラットフォームを選んでください。

インバウンドは「無料ops」ではありません。番号レンタル、MO処理（課金される場合）、キーワードトラフィック、エージェント時間 — すべて実コストです。優先すべきは：

• 本番強度の前にプリペイドウォレット資金調達
• 財務に説明できる可視残高とlow balance挙動
• アカウント維持のためだけの必須プラットフォームサブスクリプションなし
• 番号setup / 月次レンタルとメッセージング単位の明確なlist価格

IOSORではusage-ledパッケージ：ウォレットに資金を入れ、liveチャネルと割当番号を使用。月次プラットフォーム利用が約USD 1,000+に達すると、より深い商業レビューとサポート強度が意味を持ちます — パートナーシップシグナルであり、慎重なパイロットを阻むゲートではありません。

• 日常の返信に第三者ブランドポータルへのログインが必要
• 番号は送信できるがインバウンドwebhookは「フェーズ2」
• STOP / HELP文言が未定義、または誰でも気軽に編集できる
• 受信能力が未証明のまま「Activated」
• 保持・アクセス方針なしでインバウンド本文を保存
• カタログは「グローバル2-way」を謳うが対象国はsetupのまま
• サポートが資金失敗とwebhook誤設定を区別できない

MOメッセージのwebhook（スクリーンショットが失敗する理由）

webhookなしのインバウンドは口伝え知識になります。

要求すべきもの：

• スタックが検証できる認証済み / 署名付きインバウンドイベント
• 冪等処理（リトライは必ず起きる）
• 明確なpayload：from、to、body、timestamp、番号割当ID
• サポートが「顧客は返信したが何も見えない」と言ったとき、最近のMOを再確認する方法

「第三者ポータルを確認」と主デバッグ手段として受け入れないでください。white-labelとは、チームが一つの商業サーフェスに留まることです。

IOSORから始める

借りる前に受信箱を設計する。一つの割当身分で送受信、生きた MO 通知、語の方針、保存。顧客の一件の返信が担当の答えられる一行になることを示す。双方向の運用模型であり、拡声器が返信を受けられないから借りる話でも、STOP/HELP の文言だけでも、無料対地域の等級分けでもない。

関連: 着信自動返信ループ キャリア遅延スパイクに対するインバウンドWebフック処理のバッファリング 初回引き落とし前のプリペイド残高確保.

IOSORの要点

双方向は人を置ける受信箱。受信と送信は一つの番号身分を共有する。

する： 一件の返信が人のいる受信箱に着くことを示す。 しない： 一方通行の From のスイッチとして双方向を売らない。