インドのレガシーコンタクトセンターをクラウドへ移行する

インドのオンプレミス型レガシーコンタクトセンターは限界に達しています。物理的なPRI回線とローカルのPBXハードウェアを維持し続ける限り、最新のエージェント向け生産性ツールを展開できません。とはいえ、クラウドコンタクトセンターソフトウェアへの移行は単純なリフト＆シフトではありません。TRAIの厳格なトールバイパス規制を正しく読み解き、レイテンシが顧客体験を損なわないようSIPトランクのルーティングを最適化する必要があります。企業はレガシー環境をそのままパブリッククラウドへ移植するのではなく、インフラ層そのものを作り直さなければなりません。

クラウド移行に潜むTRAIトールバイパスの罠

米国や欧州の標準的なクラウドアーキテクチャは、PSTNとVoIPのネットワークを論理分離せずに混在させるため、インドの電気通信規制に違反します。インド電気通信規制庁（TRAI）のガイドラインでは、国内または国際の長距離通話料を回避する目的で、公衆PSTN通話をインターネット経由で社内IPネットワークに接続することは違法とされています。クラウドコンタクトセンターソフトウェアが、ゲートウェイレベルでの厳密な論理分割を行わないまま、管理されていない公衆インターネット回線を通じてインド国内のPSTN通話をエージェントのソフトフォンへルーティングしていれば、重いコンプライアンス上の制裁と即時のトランク停止を招きかねません。

国内トラフィックを合法的にルーティングするには、AudioCodesやRibbonといったベンダーのローカルSBC（セッションボーダーコントローラー）を用いたハイブリッドアーキテクチャが必要です。これらの物理または仮想アプライアンスはオンプレミスのデータセンターまたはローカルVPC内に配置し、インド通信事業者の物理PRI回線やローカルSIPトランクを終端したうえで、クラウドとの間にセキュアかつ論理的に分離された接続を確立します。

設計の甘いSBCアーキテクチャは、SIPシグナリングとメディアを遠方のクラウドリージョン経由で流し、最大150msのレイテンシを上乗せします。この遅延は、自動音声認識エンジンなどリアルタイム型のエージェント支援ツールの性能を直接損ない、会話の被りや高い放棄率につながります。

SIPトランキングの真のコスト：Twilio対ローカルキャリア

インド国内の音声トラフィックをTwilioのようなグローバルアグリゲーター経由で流すと、Tata CommunicationsやAirtelといったローカルのTier-1キャリアに比べて大幅なコスト上乗せとレイテンシの悪化を招きます。グローバルアグリゲーターは米ドル建ての料金を適用するため、国内発・国内着の通話をルーティングすると通信費が300%も膨らむことがあります。さらに、こうしたアグリゲーターはメディアを海外POP経由で流すことが多く、パケットロスとジッターによって通話品質が低下します。

ローカルのLCR（最小コストルーティング）エンジンを導入すれば、地域ごとのレイテンシ指標と分単位の課金刻みに応じて、システムが動的にキャリアを切り替えられます。たとえば北インドの通話はAirtel、南インドの通話はTata Communications経由にすることで、コストと通話品質の両方を最適化できます。

インドのキャリアは既定で60秒パルス課金です。ローカルのTier-1キャリアと1秒または30秒の課金パルスを交渉するLCRを導入すれば、大量発信を行う環境では月間の通信費を最大22%削減できます。

ローカルSIP終端を持たない海外製のクラウドコンタクトセンターソフトウェアに依存すると、通信費が読めなくなり、通話が切断され、音質の低下が顧客とエージェントの双方を苛立たせる結果になります。

エージェント向け生産性ツールでElasticSearchがリレーショナルデータベースに勝る理由

最新のデジタル顧客エンゲージメント基盤のデータ層を設計する際、エンジニアリングチームはリレーショナルデータベースと検索インデクサーのどちらを選ぶかを迫られます。リレーショナルスキーマは、複数のデジタル顧客接点にまたがる非構造の通話文字起こし、チャットログ、メタデータをインデックス化しようとするとスケールしません。数百万行に対して複雑なJOINクエリを実行して顧客の過去の対応履歴を探せば、データベースロックが発生し、クエリ時間は2.5秒を超えます。

ElasticSearchは、非構造の対応ログをドキュメントストアへフラット化することでこのボトルネックを解消します。これにより、リアルタイムのエージェント支援ツールが履歴データを即座に照会し、通話がエージェントのヘッドセットへルーティングされている最中に文脈を提示できます。

{
  "query": {
    "bool": {
      "must": [
        { "match": { "customer_id": "9845012345" } }
      ],
      "filter": [
        { "range": { "interaction_timestamp": { "gte": "now-90d" } } }
      ]
    }
  },
  "sort": [{ "interaction_timestamp": { "order": "desc" } }],
  "size": 3
}

専用のhot/warmノードでElasticSearchクラスターを構成し、上記のクエリで顧客レコードをインデックス化すれば、過去の顧客コンテキストを100ms未満でエージェントに提示できます。この即時のコンテキスト参照は初回接触解決率を高める主要因です。エージェントが通話冒頭の30秒を、顧客に用件を繰り返させるために浪費せずに済むからです。

エージェント用ダッシュボードの複数行レンダリングバグを解決する

エージェント向けハイブリッドモバイルアプリに残る旧世代のWebKitレンダリングエンジンでは、テキスト選択やレンダリングの不具合が頻発します。複数行のテキストエリアで顧客情報、住所、取引IDをコピー＆ペーストしようとすると、UIがフリーズしたりテキストを選択できなかったりします。原因は、CSSのwebkit-user-selectプロパティと、CRM画面の仮想化DOMリストとの相性の悪さです。

解決するには、以下のCSSとJavaScriptの回避策を実装し、UIのメインスレッドをブロックせずにタッチターゲットとテキスト境界を正しく計算するようレンダリングエンジンに強制します。

.agent-dashboard-input-field {
  -webkit-user-select: text !important;
  user-select: text !important;
  transform: translate3d(0, 0, 0);
  will-change: transform;
}

document.querySelectorAll('.agent-dashboard-input-field').forEach(element => {
  element.addEventListener('touchstart', (e) => {
    e.stopPropagation();
  }, { passive: true });
});

こうしたフロントエンドの小さなレンダリング遅延を潰すことは決して些末ではありません。取引情報のコピーに1.2秒かかる遅延は、1日1万件の通話に掛け合わせると平均処理時間（AHT）を12秒押し上げ、運用コストを膨らませてコンタクトセンター全体の需要対応力を削いでいきます。

インド企業が物理PRI回線から離れていくなかで、勝者となるのはレガシーPBXを単にクラウドでホストする企業ではなく、低レイテンシのエージェント支援ツールを支えるためにルーティングエンジンを作り直す企業です。デジタル顧客エンゲージメントの次の段階は、通信インフラをコードとして扱う組織のものになります。