保留中 vs 送信済み：IOSORにおける単一のメッセージパス

保留中 vs 送信済み：IOSORにおける単一のメッセージパス。

保留中と送信済みのための単一状態マシン

SMSやOTPのペイロードをE.164宛先に送信するAPIリクエストがプラットフォームに到着した際、プロダクトチームと財務チームはまったく同じライフサイクル状態を参照する必要があります。従来のホワイトレーベル構成では、プロダクト側が'保留中'(queued)をエンジニアリング上の状態として扱い、財務側は月次明細を待っていました。IOSORは単一の確定的な状態マシンを運用することで、この解離を解消します。HTTPリクエストが検証されると、メッセージは直ちに queued 状態に移行します。この状態は取引ログに明示的なエントリを作成し、ルートレートを確定させ、クライアントのプリペイドウォレットに対してクレジット仮押さえを適用します。

キュー投入時の資金保留と最終決済

queued 状態に入ると、エンジンは即座に残高確認を実行します。プラットフォームの健全性を維持するため、送信トラフィックがパイプラインに入る前に、アカウントは USD 20 のプリペイド下限を維持する必要があります。キュー投入中、SMSセグメントの予想コストが一時保留されます。メッセージが queued から sent に遷移すると、この仮押さえは最終的な残高引き落としに変換されます。メッセージの検証に失敗した場合、仮押さえは即座に解除されます。月間トラフィックが USD 1,000/月 のレビュー基準に近づくにつれ、台帳の並行処理機能が高スループット時の残高ズレを防止します。

状態遷移トリガー：API受信からハンドオフまで

queued と sent の境界は厳密です。Queued は、ペイロードが検証され、料金が計算され、確保された資金とともに送信キューに割り当てられたことを意味します。Sent は、エッジゲートウェイがPDUをネットワークインターフェースに送信し、中間確認応答を受信したことを示します。このミリ秒単位のタイミングで、システムは状態を queued から sent に更新し、非同期の Webhook イベントを発行します。番号は JIT 割当を用いてプロビジョニングされ、投機的な予約を行うことなく E.164 ルーティングと月額費用の会計処理が実現されます。

財務監査と配信レポートの照合

DLRの遅延が発生すると、財務監査とエンジニアリングログの間で不一致が生じることがあります。IOSORでは、sent ステータスが最終デビット確定の会計ポイントとなります。DELIVERED や UNDELIVERED といった DLR ステータスは運用メトリクスを更新するのみであり、最初の取引台帳を変更することはありません。受信 STOP コマンドを受信した場合、その E.164 アドレスに対する後続のリクエストは、資金保留が発生する前に Verify OK ステータスで API 境界にて拒否されます。

運用プレイブックと関連アーキテクチャ

エンジニアリングと財務運用の整合性を維持するために、キュー処理、Webhook の冪等性、ウォレットメカニクスに関する以下のコアリファレンスガイドを参照してください：

• 大量トラフィックにおけるWebhookコンシューマー運用
• ウォレット運用初週：本番トラフィックにおける仮押さえと実売上の真実
• 冪等・再試行と資金

IOSORで始める

IOSOR コンソールを開き、ライフサイクルステートマシン設定に移動して、送信フックを単一の「キューから送信完了まで」のパイプラインに同期させます。下流キャリアの配信レポート（DLR）を待つのではなく、送信完了状態を最終的な引き落とし確定の信頼できる基準として認識するように元帳連携を設定します。テストディスパッチを実行し、エンジニアリングのウェブフックと財務ログの間で統合トランザクション状態 ID を監査して、設定を検証します。

IOSORの要点

このガイドでは、プロダクトのテレメトリーと課金を単一のステートマシンを中心に統合することで、エンジニアリング部門と財務部門の間の運用上の摩擦が解消されることが証明されました。キュー投入時に資金を留保し、ゲートウェイが送信イベントを発行したときに最終的な引き落としを確定させることで、遅延や欠落した配信レポートの影響を受けない、決定論的な会計モデルが構築されます。

会計上の決済トリガーは送信完了の遷移にのみ紐付け、配信レポートは運用品質の指標として厳密に限定してください。非同期の配信レポートに元帳の調整や引き落としの確定を紐付けると、会計上のズレや監査の突合における競合が発生するため避けてください。