アウトバウンドコール & IVRシステム

概要

米国コロラド州の不動産管理会社（管理戸数 約250戸）が、手作業の折り返しワークフローを刷新する必要に迫られていた。リーシングオフィスは毎月何時間もかけて、既存テナントへの同じ家賃サイクルのリマインド電話をかけ、メンテナンスの折り返しに対応していた—相手はすでに賃貸契約を結んだ人々で、番号もテナント自身が提供したものだ。

Asterisk 20 + PJSIP上に、セルフホストのアウトバウンド発信/IVRシステムを構築し、既存の3CX Cloud PBXへブリッジした。キャンペーンはManager Interface経由でAsteriskから発信し、短いIVR（「オフィスと話すには1を押してください」）を再生し、テナントを実オペレーターへホット転送する—オフィス側はダイヤルパッドに一切触れない。

対象は自社テナントの自社コンタクトリストに厳密に限定し、構築前に書面で文書化したTCPA準拠の条件下で運用。コールドコールや第三者リストは一切なし。

主な機能

• Debian 12上のAsterisk 20、発信者と転送先のchan_pjsipエンドポイント
• 3CX Cloud PBXブリッジ — クライアント既存の3CXテナントへのSIPトランク登録、内線をエンドポイントとして登録
• press-1のDTMF転送で実3CX内線へつなぐIVRダイヤルプラン、リトライ判断用のハングアップ原因コード処理
• AMI駆動のキャンペーンランナー：CSVからリードを抽出、同時発信数の上限付きで発信、コール毎にログ記録
• CDRバックエンド（CSV + MySQL）にbillsecとdispositionを保存し、誰に到達したかを監査可能に
• 実トランクに触れず安全にE2Eテストできる仮想発信者ループバックモード
• 冪等な install.sh / teardown.sh — 環境変数駆動で、VPS上の設定を手編集しない

技術的詳細

• PJSIPのtransport-udpで external_media_address / external_signaling_address をVPSのグローバルIPに設定—NAT配下のクラウドインスタンスでは必須で、無いと登録が静かに半壊する
• エンドポイント毎に rewrite_contact=yes + rtp_symmetric=yes でNAT越しの片方向音声を回避
• DTMFモードを rfc4733 に固定—3CXトランク設定と一致させ、press-1が確実に認識されるように
• AMIはループバックのみにバインド（deny=0.0.0.0/0.0.0.0、permit=127.0.0.1）。公開AMIは機能ではなくリモート実行の攻撃面
• 3CX認証はPJSIPの username= フィールドに3CX発行のAuthentication IDを使用—内線番号は装飾であり認証情報ではない
• 段階的デプロイ：ラボ導入 → 仮想発信者E2E → 3CXエンドポイント登録 → 実トランクのライブテスト → 同時数上限付きキャンペーンランナー
• Asterisk SIPスキャン対策のFail2banルール、ファイアウォールでポート5060の送信元IPを既知のキャリアレンジに制限

技術スタック

成果

リーシングオフィスは手作業のリマインド電話をやめた。以前は家賃サイクルに半日を費やしていた同じ2名のスタッフが、今はダッシュボードを見て、テナントが1を押したら転送を受けるだけで、他は何もしない。このスタック自体がFFULBの再利用可能な資産となり—テンプレート化された設定、install/teardownスクリプト、段階的ランブック、QAチェックリスト—次のテレフォニー案件に、NAT越えと3CXブリッジの作業を作り直すことなく投入できる状態になった。