SMSセグメント会計：1通が1明細にならない理由

ユーザーは1通打っただけなのに、前払いウォレットは3ユニットを引き落としました。これは不具合ではなくセグメント会計です。GSM-7とUCS-2、マルチパート連結を理解しない財務チームは、設計どおり動く請求エンジンにチケットを切ります。本ガイドは、前払いホワイトラベルのメッセージングを運用し、支出を「請求書を信じる」ではなく説明可能にしたい財務・プロダクト責任者向けです。

IOSORは各SMS支出行をセグメント数・エンコーディング・宛先まで再構成可能として扱います——不透明なプラットフォーム料金ではありません。月間プラットフォーム利用がUSD 1,000+付近では、セグメント規律がきれいな月次突合と「なぜ高かった」繰返しエスカレーションを分けます。

なぜ1通のSMSが1明細にならないか

GSM-7 vs UCS-2：文字セットが計算を変える理由

• GSM-7は限られたラテン文字と小さな記号集合をカバーし、文字あたりの「セグメント予算」が低い
• UCS-2（GSM-7外の文字——絵文字、大半の非ラテン文字、一部句読点）はメッセージ全体をより広いエンコーディングへ押し、セグメントあたり上限が下がる
• 「見えない」1文字（文書から貼ったスマートクォート、チェックマーク、絵文字）が静かにGSM-7からUCS-2へ全体を切り替えることがある

マルチパート分割と連結オーバーヘッド

単一セグメント上限を越えても「きれいに切り上げ」されません——メッセージは複数セグメントに割れ、各セグメントが連結オーバーヘッドを持ち、それに応じて再請求されます。

セグメント数が隠れる場所

• コンポーザプレビューは「1メッセージ」なのに実エンコーディングは2–3請求セグメント
• 一部受信者だけ長さを境界越えさせるテンプレ変数
• ある言語のQAは通るが別言語ではコストを倍増させるロケール固有文字（アクセント、非ラテン文字）

各デビット行は宛先・メッセージ長・検出エンコーディング・セグメント数・単価を示すべきであり、混ぜた「SMS料金」だけであってはいけません。財務がウォレット引落しをこの5フィールドに写せないなら、台帳は突合可能ではなく信仰で信じている状態です。

1. ウォレットが請求する同じ規則で、送信前にエンコーディングとセグメント数を見積もる
2. テンプレ編集がセグメント境界を越えるとき警告する——黙って許可しない
3. コンポーザに文字数だけでなくエンコーディングを表示する
4. 執筆言語だけでなく実受信者ロケールでテストする

セグメント数、エンコーディング、宛先ゾーン、単価——API呼び出し、一括キャンペーン、workshopテストのいずれから来ても一貫して提示。前払い台帳が「SMS」と合計だけなら、領収書の皮を被ったブラックボックスです。

危険信号

• コンポーザやAPI応答がセグメント数ではなくメッセージ数を返す
• 特定送信で使われたエンコーディングが見えない
• サポートが「エンコーディング問題は稀なので心配無用」と言う
• 長さ・エンコーディング・宛先へ遡れない台帳行
• 一括送信がフラット見積もりで請求され、月末にしか突合せない

IOSORで始める

大量送信を行う前に、IOSORコンソールで送信テンプレートのペイロードを確認してください。APIの検証ゲートを設定し、1セグメントを超えるものや、GSM-7からUCS-2エンコーディングへ予期せず切り替わるペイロードを検知できるようにします。また、配信レポートのウェブフックでは、抽象的なメッセージ数ではなく、正確な課金セグメント数に紐付けて残高引き落としが行われるようにしてください。

• プリペイドのホールド予備金：高コンカレンシー下での有効ウォレット残高の計算
• 価格請求週：見積り行と実請求行の照合
• キャンペーン途中の文字コード切り替えによるサイレント引き落としの防止

IOSORの要点

1件の送信テキストが、そのまま1件のコスト項目になるとは限りません。GSM-7とUCS-2のエンコーディングの選択や、マルチパート結合によるヘッダーのオーバーヘッドを考慮すると、動的テキストのわずかな違いや1文字の特殊文字によって、受信者あたりの請求額が容易に倍増してしまいます。

送信作成の段階で、厳格な文字エンコーディングのチェックとテンプレートの長さに制限を設けてください。エンコーディングの切り替えや複数セグメントによる課金のペナルティを見落とすような、大まかなメッセージ数のプレビューや追跡不可能な台帳データに頼らないようにしましょう。