クライアント向けに音声AIを運用する：マルチテナント構成、請求、サポート範囲

クライアント向けに音声AIを運用することは、1つのエージェントをうまく構築することとはまったく別の仕事です。5アカウントを超えてスケールできるかどうかを決めるのは構造面の設計です。つまり、クライアントのデータをどう分離するか、各クライアントの利用量をどうその請求書に紐付けるか、誰がエージェントを変更できるのか、そして金曜の夜に何を対応し何を対応しないのか、という点です。

AI音声エージェントを再販するエージェンシー、BPO、プラットフォームは、同じ3つの壁に同じ順番でぶつかります。テナント分離、請求の紐付け、そしてサポートです。

本記事では、それぞれが問題になる前に整備する方法と、関係が良好なうちに合意しておくべき契約終了時の条件について説明します。

要点まとめ

• 初日からすべてのクライアントをワークスペース単位で分離します。10社のクライアントが1つのワークスペースを共有した後で分離するのは、設定変更ではなく移行作業になります。
• ワークスペースの作成は手動です。プロビジョニング用のAPIはないため、オンボーディングの手順書（ランブック）を早めに用意します。
• 電話番号は最も厄介な部分です。誰が購入するのか、発信者番号に誰の名前を表示するのか、ポーティングした番号が契約終了時にどうなるのかを決めておきます。
• 請求の紐付けは各クライアントのワークスペースの利用量合計に基づくため、1つの合算請求ではなくワークスペースごとに照合します。
• 誰がエージェントを変更できるかを文書化します。クライアントによる無制限の編集も、ベンダーのみによる編集も、それぞれ逆の方向で失敗します。
• サポート範囲は価格設定の判断です。月あたりの対応変更数、重大度別の対応時間、対象外の範囲を定義します。
• 契約終了時の条件は最初の契約で合意します。番号の解放、録音のエクスポート、エージェント設定の扱いです。

ここでいう「マルチテナント」の本当の意味

マルチテナンシーとは、1つのシステムで多数のクライアントにサービスを提供しながら、各クライアントのデータ、設定、ユーザーを分離しておくことです。音声AIエージェンシーの場合、この分離は4つの要素すべてで同時に成り立っている必要があります。

• データ。あるクライアントのエージェントが扱う通話録音、文字起こし、顧客レコードは、他のクライアントから見えてはなりません。
• 設定。エージェント、プロンプト、ナレッジ、転送ルールはクライアントに属するものであり、1つへの変更が他に影響してはなりません。
• アクセス。自社チームは全クライアントへのアクセスが必要で、各クライアントは自社分へのアクセスが必要ですが、他社分へのアクセスが必要な人はいません。
• 利用量。通話時間と通話数はクライアントごとに集計できなければなりません。それがそのまま請求書になるからです。

最初の3つを正しく設計すれば、4つ目は簡単になります。最初の3つを誤ると、4つ目は毎月手作業で管理するスプレッドシートになります。

クライアントごとに1ワークスペースか、1ワークスペースに多数のエージェントか

ほぼすべてのケースで、クライアントごとに1ワークスペースです。

全クライアントのエージェントを1つのワークスペースに置くと、セットアップは速くなりますが、人数が増えるほど悪化する3つの問題が生じます。

1. 他のクライアントの通話を見せずに、クライアント自身の通話だけを見せることができません。
2. 利用量が1つの合算値として届くため、自分で分割しなければなりません。
3. 誤った編集や削除が、別のクライアントの本番エージェントに影響します。

ロールベースのアクセス制御を伴うワークスペース単位の分離は、この3つをすべて解決します。これは Retell の分離の仕組みとも一致しています。各ワークスペースは完全に分離された境界であり、独自のエージェント、APIキー、メンバー、webhook、電話設定、請求を持ちます。その他のすべてについては開発者ドキュメントから始めるのがよいですが、プロビジョニングは手動です。Retell はワークスペースの作成・削除・切り替えを行うAPIを公開していないため、新しいクライアントのワークスペースはダッシュボードで1つずつ手作業で設定します。オンボーディングごとの所要時間を見込み、11社目のクライアントを迎える前に手順をランブックにまとめておきましょう。

共有ワークスペースが妥当なケースは2つあります。クライアントが直接アクセスすることのない、同一のエージェントを使う少数のごく小さなアカウントの場合と、後で移行する予定のパイロットの場合です。どちらも、その前提が成り立たなくなる日に向けた明確な計画が必要です。

1社目のクライアントから命名規則を守りましょう。クライアントコード、ユースケース、環境の順に、すべてのエージェント、電話番号、ナレッジベースに付けます。初日のコストはゼロですが、後でインシデントのたびに半日分の時間を節約できます。

電話番号、発信者番号、ポーティング

電話番号は、スタックの中で最もクライアントとの摩擦を生む要素です。セットアップの中でクライアントがすでに所有している唯一の部分だからです。

最初のローンチ前に決めるべきことは3つです。

• 誰が番号を購入するか。自社アカウントで購入した番号は管理が簡単ですが、引き渡しが難しくなります。クライアントが所有しエージェントに向ける番号はその逆です。クライアントごとに選択し、契約書に明記します。
• ポーティングか転送か。クライアントはほぼ必ず既存の事業用番号を使い続けたいと考えますが、セットアップの流れで新しい番号の購入を勧められるため、それができないと思い込んでいることが多くあります。既存番号をエージェントに転送する方が通常は速く、クライアントの通信キャリアに一切手を加えずに済みます。
• 発信時に誰の名義を表示するか。発信では自社ではなくクライアントのブランドを表示すべきです。ブランド発信者番号表示と認証済み電話番号は、そもそも電話に出てもらえるかどうかを左右し、発信件数よりも重要です。

注意すべき落とし穴が1つあります。便宜上、自社アカウントで番号を購入し、後でクライアントが離れた場合、そのクライアントの顧客がかけてくる番号を自社が保有することになります。これは紛争の火種になるため、解放条件は契約終了時ではなく契約締結時に決めておきましょう。

請求の紐付けの根拠

根拠はクライアントごとの利用記録であり、各クライアントのワークスペースの利用量合計と分単位で一致させる必要があります。

請求書は3つの構成要素で作り、クライアントの請求書上でそれぞれを分けて記載します。

構成要素	対象	請求方法
プラットフォーム利用料	クライアント別・エージェント別の通話時間	そのクライアントのワークスペースの利用記録に基づき、原価または自社の料金で転嫁
クライアント別の固定費	電話番号、インテグレーション、クライアント別のツール	毎月定額の明細項目として計上し、小規模アカウントが大規模アカウントに補填されないようにする
自社の作業	管理、変更、モニタリング、レポート	リテイナー契約または対応変更数の枠

照合は四半期ごとではなく毎月行います。クライアントの請求書とそのクライアントのワークスペースの利用量が一致しない場合、原因はほぼ必ず誤ったワークスペースに置かれた番号かエージェントであり、30日以内であればはるかに見つけやすくなります。

ワークスペースごとの利用記録があれば、この計算はシンプルになります。クライアントに転嫁する金額は、そのワークスペースに請求された金額そのものだからです。各ワークスペースは独自の支払い方法、クレジット残高、請求書、利用量合計を持つため、月末に合算請求を分解する必要はありません。請求書を設計する際は請求内容全体を確認してください。電話番号、追加の同時接続数、ナレッジベース、認証済み番号、SMSの定期料金は利用料金とは別に発生し、転嫁分ではなくクライアント別の固定費の明細に含めるべきものです。請求書をそれに合わせて設計する前に、最新の料金体系を確認してください。

商業面については、エージェンシーによるAI音声エージェントの価格設定で、契約更新後も持続する4つの利益モデルを紹介しています。

同じ月次の作業に利益率のチェックも加えましょう。クライアント別の通話時間、売上、サポート時間を1つのビューで確認します。ひそかに赤字になっているアカウントは、たいてい最も感じの良いクライアントのものです。

クライアントが変更を求めたとき、エージェントの責任者は誰か

誰かが責任を持つ必要があり、その答えはインシデント中に明らかになるのではなく、ローンチ前に文書化しておくべきです。

両極端はどちらも失敗します。自社だけが変更できる場合、休日メッセージや価格の更新のたびに自社がボトルネックとなり、クライアントにとっては自社のチケット待ちがそのまま製品体験になります。クライアントが何でも変更できる場合、誰かが金曜日に本番のプロンプトを編集し、月曜日にその件で電話がかかってきます。

現実的な中間策は、リスクに応じた分担です。

• クライアントが直接変更できるもの：営業時間、休日メッセージ、ナレッジベース内のFAQ回答、通知の受信者。
• 自社が当日中に変更するもの：プロンプトの文言、選別のための質問、転送ルール、エスカレーションのしきい値。
• プロジェクト作業：新しい通話タイプ、新しいインテグレーション、予約フローや基幹システムに関わるすべての変更。

この分担を安全にする機能が、バージョン管理とテスト経路です。本番以外のバージョンで変更し、通話でテストしてから本番に反映します。これがなければ、すべての変更がクライアントの顧客を相手にした本番実験になります。最も厳格に扱うべきなのは通話転送のルールです。転送の不具合はダッシュボード上では見えませんが、発信者にははっきりわかるからです。

これをプラットフォームベンダーではなく自社の手に置いておく理由はスピードであり、それが運用モデル全体を支える柱です。担当するすべてのクライアントについて、CX改善のサイクルを自社が握ります。マネージド型のAIベンダーやBPOとは異なり、変更がチケットやキュー、追加のSOWになることはありません。プラットフォーム全体では、本番通話時間の80%が、顧客自身が構築・管理するエージェントを通じて処理されています。これは、自社がクライアントに1段階下のレベルで提供しているのと同じ体制です。

失敗した通話を聞いた本人がその日の午後に修正できれば、エージェントは毎週改善されます。すべての変更がベンダーへのチケットになれば、クライアントのビジネスの変化とともにエージェントは劣化していきます。

サポート範囲：ティア、対応時間、断るべきこと

サポートはエージェンシーの利益率が失われる場所です。そのため、価格と同じくらい厳密に定める必要があります。

契約書には次の3点を明記します。

1. 月あたりの対応変更数。雰囲気ではなく具体的な数字で示します。それを超えるものは有償の変更依頼です。
2. 重大度レベルと対応時間。エージェントが電話に出ない問題と文言の微調整は同じではなく、同じ対応時間にすべきではありません。
3. 対象外の範囲を明示すること。クライアントのCRMの障害、通信キャリアの障害、クライアント自身のWebサイトのフォーム変更、クライアントにしか下せない判断を必要とするものすべてです。

クライアントが異論なく受け入れる重大度の表は、通常次のようになります。

重大度	例	自社が約束すること
緊急	電話に応答しない、または無音になる	営業時間外を含め、定められた時間内に対応
高	転送が失敗する、予約がカレンダーに書き込まれない	当営業日中
通常	文言、営業時間、FAQの内容、レポートに関する質問	対応変更数の枠内で、翌営業日
プロジェクト	新しいエージェント、新しいインテグレーション、新しい通話タイプ	スケジュールを含めて別途見積もり

断るべきこと：無制限の対応、価格の決まっていない作り直し、自社が管理していないシステムへの責任の引き受け。これらを断ることで、20アカウントになってもサービス全体を持続可能に保てます。

もう1つ、実際に時間を節約できる線引きがあります。クライアントからの通話の問題報告は、通話IDを添えて1つのチャネルに集約します。クライアントの顧客から届いたテキストメッセージのスクリーンショットはバグ報告ではなく、それが指す通話を探す方が修正よりも時間がかかることがあります。

複数クライアント全体で何をモニタリングするか

クライアント単位ではなくポートフォリオ単位でモニタリングします。そうしなければ、最も声の大きいクライアントが気づいた問題しか見えなくなります。

• エージェントごとの応答率と完了率。ここでの低下は、上流で何かが壊れたことを示す最も早いシグナルです。
• 転送成功率。転送の失敗は最もよくある表に出ない障害であり、クライアントの顧客に最も大きな損害を与えます。
• 平均通話時間の推移。通話時間が伸びている場合、エージェントがより多くを処理している（良い兆候）か、ループにはまっている（悪い兆候）かのどちらかです。
• エスカレーションと未解決の理由。エージェントが通話を解決できなかった繰り返し発生する理由は、同様のエージェントを使う全クライアントにとっての翌週の改善項目です。
• クライアントごとの計画に対する利用量。価格モデルを崩しそうなアカウントを、請求書より先に把握します。

これにより、少人数のチームでも複数のクライアントを管理できるようになります。通話後分析で通話ごとの記録を確認でき、AI品質保証（QA）は定義した基準で通話を評価するため、クライアントがまだ苦情を言っていない失敗も発見できます。それらを修正できるかどうかが、契約更新の話し合いになるか、立て直しの交渉になるかの分かれ目です。

クライアントがすでに使っているエージェンシー向けプラットフォームを通じて提供する場合は、インテグレーションの経路を早めに確認してください。Go High Level インテグレーションは最も一般的な経路の1つであり、リードや通話結果がクライアントの既存システムにどう反映されるかが、クライアントが導入完了とみなすかどうかを左右することがよくあります。

紛争なく契約を終了する

契約終了の条件は最初の契約で合意します。どの条件も今なら簡単に書けますが、後になると争点になるからです。

1. 番号の解放。各番号の所有者と、ポーティングまたは解放にかかる期間。
2. 録音と文字起こし。何をどの形式でエクスポートし、その後何を削除するか。保存期間も明記します。
3. エージェントの設定。クライアントがプロンプトやフローロジックを受け取るのか、それとも自社の成果物とするのか。どちらの答えも正当ですが、何も決めていないのは問題です。
4. 解約予告期間と最終請求。最後の端数月の利用量の請求方法も含めます。
5. データ削除の確認。特にクライアントが規制業種で、書面での証明が必要な場合です。

クライアントが契約時にこれらを交渉することはまれですが、契約終了時には必ず尋ねてきます。早めに記載しておくことで、自社に経験があることも伝わり、その条件を盛り込んでいる商談の成約にもつながります。

最初の10社のためのチェックリスト

これから整備する場合は、次の順序で進めてください。

1. クライアントごとに1ワークスペースをダッシュボードで手作業で作成し、エージェント、電話番号、ナレッジベースに命名規則を適用する。
2. ロールベースのアクセス制御を設定し、クライアントのユーザーは自社のワークスペースのみに限定し、自社チームは各クライアントのワークスペースに業務に必要なロールで招待する。ロールはワークスペースごとに割り当てられ、招待ダイアログでは Admin、Developer、Member を選択できる。
3. 番号の所有権と発信者番号をクライアントごとに決め、契約書に明記する。
4. クライアント別の利用量照合を、そのクライアントのワークスペースの利用量合計に対して毎月実施する。
5. リスクに応じた変更権限の分担と、本番に関わるすべての変更について「テストしてから本番反映」の経路を用意する。
6. 対応時間を定めた重大度の表と、対象外範囲の明示的なリストを用意する。
7. 応答率、転送成功率、計画に対する利用量を網羅するポートフォリオのモニタリングビューを用意する。
8. 最初の契約に契約終了時の条件を盛り込む。

どれも難しいことではありません。ただし、1社目の前に行うより、10社目の後に行う方がはるかに大変です。

よくある質問

多数のクライアント向けに音声エージェントを運用する場合、クライアントのデータをどう分離しますか？

クライアントごとに1ワークスペースを使い、ロールベースのアクセス制御を設定することで、録音、文字起こし、設定、利用量をそのクライアントに限定します。各ワークスペースは完全に分離された境界です。クライアントのログインは自社のワークスペースのみに限定し、自社チームは各クライアントのワークスペースに業務に必要なロールで招待します。ロールはワークスペースより上位ではなく、ワークスペースごとに割り当てられるためです。招待ダイアログでは Admin、Developer、Member を選択できます。分離こそが提供価値なので、クライアントにログインを渡す前に、各ロールがアクセスできる範囲を確認してください。

各クライアントに専用の電話番号を持たせるべきですか？

はい。クライアントが番号を所有してエージェントに転送またはポーティングするか、自社がクライアントに代わって購入し、解放条件を書面で合意するかのどちらかです。複数のクライアントで番号を共有すると、請求の紐付けと発信者の識別が成り立たなくなります。

音声AIの利用料をクライアントにどう請求しますか？

3つの明細に分けて請求します。そのクライアントのワークスペースの利用記録に基づくプラットフォーム利用料、電話番号やインテグレーションなどのクライアント別固定費、そしてリテイナーまたは変更枠としての自社の作業です。各ワークスペースは独自の請求書と利用量合計を持つため、ワークスペースごとに毎月照合します。

クライアントが自分でエージェントを編集できるようにすべきですか？

営業時間、休日メッセージ、ナレッジベースの内容など低リスクの部分は任せ、プロンプト、転送ルール、インテグレーションは「テストしてから本番反映」の経路の下で自社チームが管理します。

エージェンシーはどの程度のサポートを約束すべきですか？

1つの対応時間ではなく、重大度レベルを定義します。電話に応答しない問題には営業時間外の対応が必要ですが、文言の変更には不要です。そのうえで、月あたりに含まれる変更数と対象外の範囲を明記します。

クライアントが離れた場合、エージェントはどうなりますか？

契約の定めによります。番号の解放、録音のエクスポート、データ削除、エージェント設定を引き渡すかどうかを網羅してください。契約終了時には交渉になってしまうため、契約締結時に決めておきましょう。

1社でも100社でも同じ構成で運用する

Retell は、自律的な顧客対応を実現するカスタマーエクスペリエンスAIプラットフォームです。まず1つのクライアントのワークスペースを設定し、そのクライアントの実際の通話を1週間処理したうえで、2社目をオンボーディングする前に、分離、利用記録、通話レビューをこのチェックリストに照らして確認してください。自社の通話でパイロットを実施する。

---

##