事前準備

本章では、開発を進めるにあたって予め実施すべき事項を明らかにします。実装作業そのものに着手する以前に「ゴールとプロセスを明確化する営み」に重きを置いた内容となります。

通信の可視化

まず最初に、通信の "姿" (繋がりたい相手、伝えたい内容、等々) を可視化しましょう。可視化の考え方、進め方、具体例は以下のとおりです。

考え方

可視化をするにあたって考えるべき事項は以下のとおりです。

• 通信に関わる "人/モノ" を明確にする
  • 人の例: 顧客、エンドユーザ、業務委託先
  • モノの例: スマートフォン、固定電話、PC、サーバー、アプリケーション
• 人/モノの "行動" を明確にする
  • 例: 通話発信、APIリクエスト、自動音声再生
• 行動の "トリガー" を明確にする
  • 例1: 定期 (平日10時、毎週月曜、毎月15日)
  • 例2: 随時 (通話着信後、通話終了後、任意のタイミング)
• 通信の "UX" を明確にする
  • 例1: "050番号から着信"
  • 例2: "応答後に自動音声聴取"
  • 例3: "自動的に切断"

進め方

前章で述べた考え方に基づいて通信を可視化してみましょう。例として "クイックスタート" の章で実現した通信を取り上げます。

• "人/モノ" を明確にする (四角形で示す各要素)
• "行動" を明確にする (各要素を結ぶ矢印)
• "トリガー" を明確にする ("お客様" に対するフキダシ)

• "UX" を明確にする ("エンドユーザ" に対するフキダシ)

  

具体例

前章で可視化した姿は、クイックスタートを目的とした非常にシンプルなものです。更に実用的な通信の姿を可視化したものの具体例を以下に記します。これらをご参考の上で、ご自身のケースの可視化を進めてください。

• アンケート収集

  

• 問合せ窓口

  

• その他のカスタム構成 (例 : 多種多様なノードとの連携)

  

可視化に基づくアクション

開発に関すること

通信方向の見極め

ここまでに可視化した通信の姿のうち、"音声通話の発信" にあたる矢印に注目してください。その矢印の方向が "NTT CPaaS から外側" の場合は アウトバウンドコール と、"外側から NTT CPaaS" の場合は インバウンドコール と呼び分けます。この考え方は、今後の作業を進めるにあたって重要なポイントになりますので、事前準備の段階で正しく見極めをしましょう。以下に見極めの例を示します。

• アウトバウンドコール
  前述した可視化の具体例 : アンケート収集 (NTT CPaaS から外側へ通話発信) が該当します。

  

• インバウンドコール
  前述した可視化の具体例 : 問合せ窓口 (外側から NTT CPaaS へ通話発信) が該当します。

  

トライアルから本申込へのアップグレード検討

• NTT CPaaS の申し込み状況が "トライアル" の場合、アウトバウンドコールの仕様や回数に制限があります。詳細は トライアルの利用条件 > Voice を参照してください。
• 今後の開発を進める中でアウトバウンドコールを試行しているうち、やがて該当の制限に触れる時期が到来することをご考慮の上、頃合いを見て "本申込" へのアップグレードが必要になることをお含み置きください。
• また、インバウンドコールは "トライアル" における提供対象外の機能です。通信方向の見極めをした結果インバウンドコールとみなされている場合、開発着手の前に "本申込" へアップグレードして頂くことを推奨します。
• "本申込" の詳細については次章をご覧ください。

本申込の内容確定

必要となる本申込の内容は、可視化した通信方向 (アウトバウンド/インバウンド) やUX (着信番号/発信番号) に応じて異なります。また、場合によってはサポート対象外となることもあります。この章では、可視化した通信のサポート可否を診断し、サポート可能な場合に必要な本申込の内容や、追加で実施すべき事項の有無を明確化するフローチャートをご案内しますので、こちらに従って本申込をしてください。本申込の具体的な操作方法は サービスのご利用申し込みについて をご覧ください。

• アウトバウンドコール用のサポート可否診断フロー

  • 前提 : 通信方向とUXのイメージ

    

• チャート

  

※1 「特定番号通知」の申込は弊社担当営業までご連絡ください。ご不明の場合はNTT CPaaSサポートデスクまでご相談ください。
※2 「レンタル番号の紐づけ」とは、NTTCPaaSのレンタル050番号を、お客様がすでにご契約されている0120/0800/0570番号の着信先番号（裏番号）として登録することです。なお、登録手続きはお客様ご自身にて、0120/0800/0570番号のご契約先通信事業者（キャリア）へのお手続きを実施してください。詳細は ご利用条件について の 【お客様持込み電話番号】 をご参照ください。

• インバウンドコール用のサポート可否診断フロー

  • 前提 : 通信方向とUXのイメージ

    

• チャート

  

※1 「レンタル番号の紐づけ」とは、NTTCPaaSのレンタル050番号を、お客様がすでにご契約されている0120/0800/0570番号の着信先番号（裏番号）として登録することです。なお、登録手続きはお客様ご自身にて、0120/0800/0570番号のご契約先通信事業者（キャリア）へのお手続きを実施してください。詳細は ご利用条件について の 【お客様持込み電話番号】 をご参照ください。
※2　「裏番号」とは、お客様が所有している0120/0800/0570番号の着信先番号を意味します。

本番運用に関すること

アウトバウンドコール用APIのfromパラメーターの設定

アウトバウンドコール用APIを利用する際、NTT CPaaSのレンタル番号をfromパラメーターに設定してください。

発信先に通知したい番号と、その際の設定値（fromパラメーター）の関係は以下の通りです。

• レンタル050番号（例：050-1111-1111）を通知したい場合

"from": "815011111111"

• レンタル0120番号（例：0120-222-222）を通知したい場合

  • まず、該当番号の裏番号を以下の手順で確認します

    1. NTT CPaaSマイページのトップ →「ご利用サービス」→「電話番号」→C該当番号をクリックします。
    2. 「電話番号詳細」の画面にて「契約番号」の050番号を確認します（下図の例では050-3333-3333）

    

  • Fromパラメーターの設定値

"from": "815033333333"

• 持ち込み（所有済み）の0120/0800/0570番号を通知したい場合
  • 前提 : 「特定番号通知」の申込が完了していること。
  • 設定操作 : 該当番号の裏番号（事前に紐づけ設定を行ったレンタル050番号（例：050-4444-4444））をfromの値にしてください。

"from": "815044444444"

各種制限をふまえた通信量設計

NTT CPaaS には、サービスの安定性や信頼性の維持を目的とした各種制限が存在します。それらをふまえた上で、本番運用時の通信量を設計してください。詳細は以下のとおりです。なお、下記制限を超えてご利用されたい場合は、必ず事前に営業担当あるいはNTT CPaaSサポートデスクまでご相談ください。

• スループットの制御

  • 制限値: アウトバウンドコールの最大発信可能数は、1時間あたり3,600件（ベストエフォート）です。なお、本サービスはマルチテナント型（複数のお客様で環境を共有する形態）での提供となるため、お客様専用のスループットを保証するものではありません（ベストエフォート型でのご提供となります）。あらかじめご了承ください。
  • 設計のポイント: 大量の配信を行う場合は、上記制限を超えないよう、お客様側のシステムでリクエストを制御してください。

• 同時通話接続数の制御

  • 制限値: 発着信合わせて最大100チャネル（ベストエフォート）となります。 なお、本サービスはマルチテナント型（複数のお客様で環境を共有する形態）での提供となるため、お客様専用の同時通話接続数を保証するものではありません（ベストエフォート型でのご提供となります）。あらかじめご了承ください。
  • 設計のポイント: 1件あたりの通話時間が長い場合、同時通話接続数が制限に達して後続の通話が繋がらなくなる可能性があります。
  • 想定される平均通話時間に基づき、同時通話接続数が制限を超えないよう通信量を設計してください。

• 同一番号への連続送信の制御（スパム防止）

  • 制限の仕組み: 同じ宛先に対して短時間に連続してアウトバウンドコールを送信すると、スパムとみなされプラットフォーム側でリクエストが拒否されます（拒否されたリクエストは課金対象外です）

  • 制限のしきい値:

    条件	上限	備考
    同一メッセージ	1 時間以内に 6 通 まで（7 通目でエラーとなります）
    異なるメッセージ	1 時間以内に 20 通 まで（21 通目でエラーとなります）	通話の作成等のメッセージ内容を持たないAPIもこちらに該当します

• 設計のポイント: 制限の判定はリクエスト時点から遡った「直近1時間」の累積数で行われます。再送（リトライ）を実装する場合は、このしきい値に抵触しないよう、少なくとも1時間以上の間隔を空ける運用を推奨します。