コールセンターシステム開発の外注設計｜CTI・IVRの発注範囲の決め方

同じ要件を伝えたはずなのに、開発会社 3 社から返ってきたコールセンターシステムの見積が、400 万円・1,200 万円・3,000 万円と桁違いに割れている。稟議の期日は迫っているのに、なぜこれほど差がつくのかを説明できない。こうした状況で検索にたどり着く発注担当者は少なくありません。

しかも電話は、社内システムの中でもとりわけ「止められない業務」です。基幹システムなら深夜のメンテナンス停止を告知すれば済みますが、電話は数分つながらないだけで顧客からの苦情に直結します。その業務の基盤を、社内に電話回線や PBX の設計経験者がいない状態で外部に委ねなければならない。判断材料がないまま責任だけが自分に残る感覚は、多くの担当者が抱えるものです。

ただ、見積が読めない原因は担当者の知識不足ではありません。ほとんどの場合、原因は「見積を依頼した時点で、発注範囲が定義されていなかったこと」にあります。範囲が決まっていなければ、各社は自社の得意な構成を前提に見積もります。前提が違うものを並べても、比較にはなりません。

逆に言えば、範囲を自分の側で定義できれば、見積は横並びになり、金額差の理由も説明できるようになります。そのために必要なのは通信技術の専門知識ではなく、コールセンターシステムを構成要素に分解し、それぞれを「誰から買うか」「誰が責任を持つか」に割り当てる作業です。

本記事では、コールセンターシステム開発の外注範囲を回線・PBX・CTI・IVR・CRM の 5 レイヤに分解して決める方法、レイヤごとに SaaS と開発を混在させる考え方、責任分界表の作り方、見積の費用構造と相見積を同じ土俵に乗せる前提条件、そして電話という止められない業務に固有の契約・SLA 条項までを、発注者の視点で順に整理します。最後に、見積依頼前に埋めるチェックリストと段階発注の進め方をまとめます。

コールセンターシステム開発の外注が失敗する原因は「発注範囲の未定義」

「コールセンター 外注」に混在する2つの意味

はじめに、言葉の整理をしておきます。「コールセンターを外注する」という表現には、性質のまったく異なる 2 つの意味が混在しています。

1 つは、オペレーター業務そのものを外部に委託する BPO（ビジネス・プロセス・アウトソーシング）です。受電対応を代行会社に任せ、席数や対応件数に応じた月額料金を支払う形態を指します。もう 1 つは、コールセンターを支えるシステム（CTI・音声応答基盤・顧客管理との連携）の構築を開発会社に委託する形態です。

検索して出てくる「コールセンター 委託 費用 相場」といった情報の多くは前者の BPO を扱っており、席あたり月額いくらという料金体系で語られます。これをシステム開発の予算感と混同すると、見積の妥当性判断が最初からずれます。

本記事が扱うのは後者、つまりシステム開発の委託です。オペレーターの採用・教育を含む BPO の料金比較は対象としません。ただし現実には「システムは自社で持ち、繁忙期のみ受電を BPO に流す」といった組み合わせも起こるため、その場合は 2 つの委託を別々の契約として設計する、とだけ押さえておいてください。

相見積が数倍割れるときに起きていること

相見積の金額が数倍に割れているとき、各社が見ている前提はたいてい次のように食い違っています。

• A 社は、既存のオンプレミス PBX をそのまま活かし、その上に CTI 連携だけを載せる前提で見積もっている
• B 社は、クラウド PBX に全面移行し、回線契約の巻き取りまで含めて見積もっている
• C 社は、基幹 CRM とのリアルタイム双方向連携と、独自の取次フローをスクラッチ開発する前提で見積もっている

3 社とも誠実に見積もっていますが、そもそも作るものが違います。この状態で金額だけを比べても、安い提案は「必要なものが入っていない」だけかもしれず、高い提案は「不要なものまで入っている」だけかもしれません。

この食い違いは、発注者が悪いというより、要件を渡す側が「どこからどこまでを依頼するのか」を示していないときに必然的に起こります。ベンダーは空白を自社の標準構成で埋めるため、標準構成が違えば見積も割れるのです。したがって最初にやるべきは、追加の技術知識を仕入れることではなく、範囲の空白を埋めることになります。

見積依頼の前に決める2つの前提

範囲を定義する前に、発注者側でしか決められない前提が 2 つあります。これはベンダーに聞いても答えが出ません。

1 つ目は、現状の入電構造の可視化です。 月間の入電件数、時間帯別・曜日別のピーク、ピーク時の同時通話数、用件の内訳（問い合わせ・注文・解約・取次）、平均通話時間、現在の応答率と放棄呼率を、数値で押さえます。放棄呼率は「放棄呼数 ÷ 着信件数 × 100」で算出でき、コールセンターの標準的な KPI として広く使われています（DIGINEXT コールセンターKPI一覧）。この数値がないと、後述する同時接続数の要件も IVR の分岐設計も決まりません。

2 つ目は、電話が止まってよい許容時間です。 「絶対に止められない」は要件ではありません。平日日中に何分まで許容するのか、夜間はどうか、止まったときに何を代替手段とするのか（キャリア側の転送で携帯へ逃がす、留守番応答に切り替える等）を決めます。この許容時間が、後で契約に書く復旧目標時間と冗長構成の要否を決め、そのまま金額に跳ね返ります。

あわせて、目標とするサービス品質も決めておくと議論が締まります。コールセンターには、応答率に「応答までの時間制限」を加えたサービスレベル（SL）という指標があり、その設定例として「着信から 20 秒以内で 80%」という水準がよく挙げられます（いわゆる 80/20 ルール）（パーソルビジネスプロセスデザイン コールセンターの応答率）。この水準を狙うのか、まずは放棄呼を減らすところから始めるのかで、必要な席数も自動応答の作り込みも変わります。

この 2 つが決まれば、次の作業に進めます。システムを構成要素に分解し、どこを買い、どこを作るかを線引きする作業です。

コールセンター・CTIシステムを5レイヤに分解して外注範囲を決める

コールセンターシステムの構築は、ひとかたまりの「システム」として捉えると全体像がつかめません。内実は、性質の異なる 5 つのレイヤが積み重なった構造になっており、レイヤごとに調達先も、開発が発生する度合いも異なります。

ここで押さえたいのは、各レイヤが何をするものかを暗記することではなく、「自社の要件のうち、どれがどのレイヤの話なのか」を指させるようになることです。ベンダーとの打ち合わせで用語が飛び交ったときに、それがどの層の話かを地図上で確認できれば、議論に置いていかれることはなくなります。

レイヤ1 回線・電話番号（キャリア領域）

一番下にあるのが、電話回線と電話番号です。固定電話番号（0AB-J 番号）やフリーダイヤル（0120／0800）をどのキャリアと契約し、どの経路で受けるかを扱う層で、原則としてキャリアの領域になります。

発注設計で論点になるのは、既存の代表番号を維持できるかどうかです。番号ポータビリティや転送の可否は、番号の種別・現在の契約形態・移行先の方式によって条件が変わります。ここは開発会社の判断だけでは決められず、キャリアへの確認と手続きに一定のリードタイムを要します。「番号は誰が、いつまでに、どの手続きで移すのか」を早い段階でスケジュールに載せておかないと、開発が終わっているのに切り替えられない事態が起こります。

このレイヤは開発対象ではありません。ただし、後述する責任分界の中で最も曖昧になりやすい層でもあります。

レイヤ2 PBX・ACD（クラウドPBXへの置き換え判断と着信振り分け）

PBX は構内交換機、つまり外線と内線をつなぎ、着信をどの端末に鳴らすかを制御する装置です。従来は自社の設備室に物理機器を置くオンプレミス型が主流でしたが、近年はクラウド PBX への置き換えが選択肢になっています。クラウド PBX を採用すれば、オペレーターは自宅や別拠点からでも同じ内線環境で受電できます。

その上に乗るのが ACD（着信呼自動分配）です。かかってきた電話を、待ち時間・スキル・稼働状況に応じてどのオペレーターに割り振るかを自動で決める機能を指します。「英語対応できる人に優先的に回す」「前回対応した担当者に優先的に回す」といったルールがここに入ります。

このレイヤの発注判断は、既存 PBX を活かすか、クラウド PBX に載せ替えるかです。既存を活かせば初期費用は抑えられますが、リモート対応や柔軟な振り分けに制約が残ります。載せ替えれば柔軟性は上がりますが、回線工事・番号移行・現場の端末入れ替えという別の作業が発生します。金額が割れる相見積の多くは、この判断の違いが原因です。

なお、ACD の振り分けルールが「待ち時間順に均等配分」程度であれば製品の標準機能で足りますが、自社独自の取次フロー（特定の顧客ランクは専任チームへ、契約状態によって窓口を分ける等）を実現しようとすると、この層から開発要素が発生し始めます。

レイヤ3 CTI（電話とコンピュータの連携）

CTI（Computer Telephony Integration）とは、電話システムとコンピュータ上の業務システムを連携させる仕組みのことです。CTI システムとは何かを一言でいえば、「電話の出来事を、画面上の業務データと結びつけるための中間層」です。

具体的には、次のような機能がこの層に属します。

• 着信ポップアップ: 発信者番号をキーに顧客情報を検索し、応答と同時にオペレーターの画面へ表示する
• 通話録音: 通話音声を録音し、通話履歴と紐づけて保存・検索できるようにする
• 通話履歴の記録: 誰がいつ何分対応したか、どの用件だったかを記録する
• 画面と通話の同期: 転送時に顧客情報を引き継ぐ、通話後の後処理時間を管理する

コールセンターシステムを外注する際、開発工数が発生しやすいのがこの層と、さらに上の CRM 連携層です。ポップアップ 1 つを取っても、「発信者番号が顧客マスタと一致しないときにどう振る舞うか」「複数の顧客が同じ番号を持つときにどちらを出すか」「非通知着信のときは何を表示するか」といった分岐を決める必要があり、その分岐の数がそのまま工数になります。

レイヤ4 IVR・音声応答基盤（分岐設計が開発量を決める）

IVR（Interactive Voice Response）は自動音声応答、つまり「ご注文の方は 1 を、その他のお問い合わせは 2 を押してください」と案内し、入力に応じて振り分ける仕組みです。放棄呼の削減や一次受付の自動化に直結するため、コールセンターシステム構築で最初に検討されることの多い機能です。

IVR 開発で費用が動くのは、音声ガイダンスの録音本数ではなく、分岐の構造です。2 段階 3 分岐の単純なメニューと、営業時間・顧客区分・契約状態を外部システムに問い合わせながら動的に分岐するメニューでは、開発量が一桁変わります。また、IVR の中で顧客番号を入力させて基幹システムを照会する、といった要件が入ると、この層は実質的に業務アプリケーションの開発になります。

もう 1 つ、この層で発注者が迷いやすいのが「AI による音声応答まで踏み込むか」です。音声認識で用件を聞き取り自動応答するボイスボットは、プッシュ操作の IVR とは前提が異なり、認識精度の検証・言い直しへの対応・有人転送の設計といった別の論点を伴います。IVR の延長線上で自動的に決まるものではなく、独立した判断として扱うのが安全です。仕組みや精度・費用の考え方はボイスボットとはで整理していますので、検討対象に入っている場合はあわせてご確認ください。

本記事では、まずプッシュ操作型の IVR を前提に発注範囲を固める前提で進めます。

レイヤ5 CRM・業務アプリ（連携本数が費用に直結する層）

最上位が、顧客情報や対応履歴を扱う CRM と、その先にある基幹システム・受注システム・請求システムなどの業務アプリです。CTI と CRM の連携（いわゆる CTI・CRM 連携）は、オペレーターの生産性に最も影響する部分であり、同時に費用が最も読みにくい部分でもあります。

費用に直結するのは、連携する「本数」と「難易度」です。連携先が CRM 1 つで、その CRM が整備された API を公開しているなら、工数は限定的です。一方で、連携先が基幹システム・受注システム・在庫システムの 3 本あり、うち 1 つが API を持たない自社開発の古いシステムだった場合、データ連携の方式設計だけで相当な工数がかかります。

見積を依頼するときは、この連携先の一覧（システム名・保有ベンダー・API の有無・想定する連携方向・リアルタイム性の要否）を必ず添えてください。これが渡されているかどうかで、見積の精度はまったく変わります。

5レイヤのどこに開発が発生するかの見取り図

ここまでの内容を 1 枚に整理すると、次のようになります。

見取り図として押さえておきたいのは、下のレイヤほど買うもの、上のレイヤほど作るものという傾向です。そして相見積が割れる主因は、レイヤ 2 の扱い（既存を活かすか載せ替えるか）とレイヤ 5 の連携本数にほぼ集約されます。この 2 点を発注者側で固定するだけで、見積の比較可能性は大きく上がります。

SaaS・パッケージ・スクラッチのどれで組むか

3方式の違いとコールセンター領域での向き不向き

レイヤの地図が描けたら、次はそれぞれをどの方式で調達するかを決めます。選択肢は大きく 3 つです。

コールセンター領域で注意したいのは、下のレイヤをスクラッチで作る合理性はほとんどないという点です。回線制御や呼の分配は成熟した領域であり、自前で作っても差別化になりません。一方、上のレイヤ（自社の取次フロー、顧客データとの突き合わせ）は自社固有の業務そのものであり、既製品に合わせると現場の運用が壊れることがあります。

方式選定そのものの判断軸をさらに詳しく検討したい場合は、スクラッチ開発の外注判断基準で費用・工期・拡張性の観点から整理していますので、あわせてご覧ください。本記事では、コールセンター固有の判断材料に絞って続けます。

レイヤごとに方式を混在させる考え方

コールセンターシステムの選び方で最も実務的な結論は、全レイヤを同じ方式で揃える必要はないということです。むしろ、混在させるのが標準的な形になります。

たとえば次のような構成です。

• レイヤ 1（回線・番号）: キャリア契約をそのまま維持
• レイヤ 2（PBX・ACD）: クラウド PBX の SaaS を採用し、標準機能で振り分け
• レイヤ 3（CTI）: SaaS の標準機能を使い、ポップアップの照合ロジックのみ追加開発
• レイヤ 4（IVR）: SaaS の GUI で分岐を構成し、外部照会が必要な 1 経路のみ開発
• レイヤ 5（CRM 連携）: 既存 CRM と基幹システムへの接続部分をスクラッチ開発

この構成が意味するのは、「開発会社に依頼するのはレイヤ 3〜5 の一部であり、レイヤ 1〜2 は自社とベンダーの契約で完結する」という発注範囲の宣言です。ここまで書けた状態で見積を依頼すれば、各社の前提はそろい、金額差は工数見積の差だけになります。

逆に、この混在を意識せず「コールセンターシステム一式」で依頼すると、A 社はレイヤ 2 から載せ替える提案を、B 社はレイヤ 5 だけの提案を出してきて、比較のしようがなくなります。

コールセンター固有の判断材料（同時接続数・取次フローの独自性・繁忙期変動）

一般的な方式選定の判断軸（競争力の源泉か／5 年間の総保有コスト／変更頻度）に加えて、コールセンター領域では次の 3 点を必ず判断材料に入れてください。

同時接続数の伸び。ライセンス課金の SaaS は席数に比例して月額が増えるため、席数が増える計画があるなら、3 年後・5 年後の総額で比較する必要があります。逆に席数が横ばいなら、初期投資の大きい構成を選ぶ合理性は下がります。

取次フローの独自性。「一次受付は共通、二次以降は契約種別ごとの専任チーム」といった自社固有のフローがあるなら、それを製品の型に押し込めるかを確認します。押し込めない場合、無理に SaaS の標準機能で運用すると、オペレーターが手作業で補う運用になり、結局は生産性が上がりません。

繁忙期の変動幅。キャンペーン期や年度末に入電が数倍になる事業では、席数を一時的に増減できる調達方式が有利になります。固定的なライセンス契約と従量的な契約では、繁忙期のコスト構造が大きく変わります。

責任分界表で「誰がどこまで持つか」を発注前に固定する

責任分界表の作り方（構築／運用／障害一次受付の3列）

発注範囲が決まったら、次は責任の所在を文書にします。ここが曖昧なまま契約すると、電話が止まったときに各社が互いを指し示し、原因究明の前に時間が過ぎていきます。

作り方は単純です。縦にレイヤ 1〜5 を並べ、横に「構築責任」「運用責任」「障害の一次受付」の 3 列を置き、キャリア／SaaS ベンダー／開発会社／自社の 4 者を当てはめます。

この表は「正解」を写すものではなく、自社の構成に合わせて埋めるものです。重要なのは、空欄と重複を残さないこと、そしてこの表をそのまま契約書または覚書の別紙に添付することです。表に落とした瞬間、「ここは誰も持っていない」「ここは 2 社が持っていることになっている」という穴が可視化されます。

とくに「障害一次受付」の列は、埋めるのが難しく、かつ最も重要です。電話がつながらないという報告を受けたとき、最初に電話をかける先が決まっていなければ、その時点で復旧は遅れます。

分界が曖昧になりやすい3箇所

実務上、責任の境目が曖昧になりやすいのは次の 3 箇所です。発注前にここだけは明文化してください。

回線と PBX の境目。「電話がつながらない」という事象は、キャリア側の障害でも、PBX 側の設定不備でも、同じ症状として現れます。どちらの問題かを切り分ける役割を誰が担うのか、切り分けに必要な情報（呼の記録、疎通試験の手順）を誰が保有するのかを決めておきます。

CTI と CRM の境目。ポップアップが表示されないとき、原因は CTI 側の連携処理かもしれませんし、CRM 側の応答遅延かもしれません。既存 CRM を別ベンダーが保守している場合、この境目は会社間の境目でもあります。連携インターフェースの仕様書を「どちらが書き、どちらが承認するか」まで決めておくと、後の紛争を減らせます。

音声品質。音声が途切れる、遅延するといった品質の問題は、ネットワーク・端末・回線・サービス側のいずれにも原因がありえます。とくに社内 LAN や各オペレーターの在宅回線が絡む場合、自社の責任範囲になることが多いにもかかわらず、契約時に触れられていないケースが目立ちます。「どの区間までの品質をベンダーが保証するのか」を明示的に確認してください。

連携仕様が変わったときの追随責任をどう書くか

見落とされがちなのが、稼働後に連携先の仕様が変わったときの扱いです。CRM ベンダーが API のバージョンを更新した、基幹システムを別製品に入れ替えた、といった変化は数年のうちに必ず起こります。

このとき、CTI 側の連携処理を修正する作業が誰の責任で、どの費用区分から支払われるのかを、契約段階で決めておきます。保守契約の範囲内なのか、都度の個別見積なのかで、数年後の負担はまったく変わります。

契約に書く際は、次の 3 点を分けて記載すると実務が回ります。

1. 通知義務: 連携先の仕様変更を把握した側が、他方に何日前までに通知するか
2. 調査責任: 変更の影響範囲を調査する作業を、どちらが、どの費用区分で行うか
3. 改修責任: 実際の改修作業を、保守範囲として扱うのか、別途見積とするのか

「善意で対応してもらう」ことを前提にした運用は、担当者が変わった時点で機能しなくなります。文書に残すのは、相手を疑うためではなく、数年後の担当者同士が迷わないためです。

CTI開発の費用構造と、相見積を横並びにする読み方

費用の4区分（初期／月額／従量／保守）と見積書の読み替え

コールセンターシステム開発の費用は、次の 4 区分に分けて読むと構造が見えます。見積書の書式は会社ごとに違いますが、どの行がどの区分に当たるかを分類し直せば、各社を横並びにできます。

参考として、クラウド型 CTI の一般的な相場は、初期費用が無料〜20 万円程度、月額はライセンスあたり 5,000 円〜1 万 5,000 円程度とされています（PRONIアイミツ SaaS）。一方でオンプレミス型は初期費用が 100 万円以上とされ、10 名程度の小規模でも初期 100 万円から、100 名以上の規模では 800 万円〜1,000 万円に達するという整理もあります（お名前.com ビジネスコンシェルジュ コールセンターシステムの価格）。導入形態が変わるだけで、費用の構造も桁も変わるということです。

ただし、これらのレンジをそのまま自社の判断材料に使うことはできません。相場情報が示しているのは既製品の導入価格であり、本記事が扱う「既製品の上に自社固有の連携・分岐を開発する」ケースの費用は含まれていないためです。相場は「桁が大きく外れていないか」を確認する程度に使い、判断は次の変動要因で行ってください。

金額を大きく動かす8つの変動要因

相見積の金額差は、ほぼ次の 8 つの要因で説明できます。各社の提案がどの前提に立っているかを、この一覧で確認してください。

1. 既存電話環境を活かすか、載せ替えるか: 既存 PBX の流用可否は、初期費用を最も大きく左右します
2. クラウド PBX・音声 API の採用有無: 採用すると初期は下がりますが、月額と従量が増えます
3. 連携システムの本数と難易度: API を持たない既存システムが 1 本混じるだけで工数は跳ね上がります
4. IVR 分岐の複雑さ: 静的なメニューか、外部照会を伴う動的分岐かで一桁違います
5. 通話録音・ログの保管要件: 保管期間と検索要件がストレージ費と実装工数を決めます
6. レポートの粒度: 標準レポートで足りるか、独自 KPI の集計基盤を作るかで工数が変わります
7. 非機能要件（ピーク同時接続数・冗長構成）: 許容ダウンタイムが短いほど構成が二重化され費用が上がります
8. 保守範囲と対応時間帯: 平日日中のみか 24 時間か、監視を含むかで月額が変わります

見積を受け取ったら、各社に対してこの 8 項目それぞれの前提を確認してください。金額差の理由が、この 8 項目のどれかに必ず紐づきます。逆に、紐づかない差額が残る場合は、見積の粒度が粗すぎる可能性があります。

相見積を同じ土俵に乗せる前提条件シート

前項の裏返しとして、見積依頼書には次の前提条件を必ず明記します。1 ページで足ります。

• 現状の入電数、時間帯別ピーク、ピーク時の同時通話数
• 席数（現在／3 年後の想定）と稼働時間帯
• 既存 PBX の型式・保守期限と、流用希望の有無
• 電話番号の種別と、移行の要否
• 連携先システムの一覧（システム名／保守ベンダー／API の有無／連携方向／リアルタイム性）
• IVR の想定メニュー構造（階層数・分岐数・外部照会の有無）
• 通話録音の保管期間、検索要件、開示請求への対応方針
• 許容ダウンタイム（時間帯別）と、停止時の代替手段
• 求める保守の対応時間帯と、障害時の連絡フロー
• 責任分界表（前章で作成したもの）

このシートを添えて依頼すれば、各社の見積は同じ前提の上に載ります。仮に前提の一部が未確定でも、「未確定」と書いたうえで仮置きの数値を示せば、その仮定に基づく見積が返ってきます。空欄にしたまま渡すよりはるかに比較しやすくなります。

後から出やすい追加費用

稼働後に追加費用として顕在化しやすいのは、次の 3 つです。契約前に扱いを確認しておいてください。

連携先の仕様変更に伴う改修。前章で触れたとおり、保守範囲か個別見積かを明示します。

同時接続数の増加。想定を超える同時通話が発生すると、ライセンス追加だけでなく、回線数や基盤側の増強が必要になる場合があります。増強単位（何席刻みか）と、増強にかかるリードタイムを確認しておきます。

録音データの保管期間延長。監査対応やトラブル対応の必要から、当初 6 か月の想定が 3 年に伸びるといった変更はよく起こります。保管容量の課金体系と、期間延長時の移行方法（安価なストレージへの階層移動が可能か）を確認しておくと、後の交渉が楽になります。

発注先の選び方と、契約・SLAで確認する条項

開発会社の見極め（音声・電話基盤の実績と稼働後の改修体制）

コールセンターシステムの開発会社を選ぶ際、Web システムや業務システムの開発実績だけで判断すると危険です。音声・電話基盤は、Web アプリケーションとは障害の出方も試験の方法も異なるためです。

確認したい観点は次の 3 点です。

音声・電話基盤そのものの実績。CTI や IVR の構築経験があるか、どの規模（席数・同時接続数）まで扱ったことがあるかを、具体的な数字で確認します。「コールセンター系の案件経験あり」という表現だけでは、CRM 画面の開発だけを担当した可能性もあります。

キャリアやクラウド PBX ベンダーとの調整経験。回線・番号の移行は開発会社だけでは完結せず、複数の事業者との日程調整が必要です。この調整を主導した経験があるかどうかで、移行当日の混乱度合いが変わります。

稼働後の改修体制。コールセンターは稼働後に必ず調整が入ります。IVR の文言を変えたい、振り分けルールを変えたい、といった要望に対して、どのくらいの規模の改修を、どの体制で、どの費用区分で受けられるのかを確認します。開発チームが解散する前提の会社と、保守チームに引き継ぐ体制がある会社では、稼働 1 年後の状況が大きく変わります。

止められない業務の契約条項（復旧目標・障害窓口・切り戻し）

電話が止められない業務であることを、契約書の側に反映させます。最低限、次の 4 点を条項または別紙に落としてください。

復旧目標時間。「重度障害（全面的に受電できない）は◯時間以内に復旧を目指す」「軽度障害（一部機能の不具合）は翌営業日以内」といった形で、障害の重大度を定義したうえで目標時間を書きます。重大度の定義がないまま時間だけ書いても運用できません。

障害一次受付の窓口と時間帯。電話番号・メールアドレス・受付時間・時間外の扱いを明記します。責任分界表の「障害一次受付」列と整合しているかを確認します。

切り戻し手段の事前合意。復旧に時間がかかる場合の退避手段を、あらかじめ決めて手順書にしておきます。キャリア側の設定で別番号や携帯へ転送する、留守番応答に切り替える、といった選択肢のうち、どれを誰が実行できるのかを明確にします。実行権限が自社にない手段は、緊急時には使えません。

エスカレーション経路。目標時間内に復旧しない場合に、誰から誰へ連絡が上がるのかを決めておきます。夜間・休日の連絡先を含めて記載します。

負荷試験（ピーク同時接続数）の合格基準を契約に書く

コールセンターシステムで最も痛い失敗は、稼働当日のピーク時に落ちることです。これを防ぐには、負荷試験の実施範囲と合格基準を、契約段階で定義しておく必要があります。

書くべきは次の 3 点です。

• 試験条件: 何呼／時、ピーク時同時通話数いくつまでを想定するか（前提条件シートの数値と一致させる）
• 合格基準: その負荷条件下で、応答遅延・音声品質・録音欠落・連携処理の成功率がどの水準を満たせば合格とするか
• 実施責任と立ち会い: 誰が試験環境を用意し、誰が実施し、自社の誰が結果を確認するか

「負荷試験を実施する」とだけ書かれた契約は、実質的に何も約束していません。想定同時接続数は前提条件シートで自社が提示している数値ですので、それを合格基準としてそのまま契約に転記するのが最も揉めにくい書き方です。

通話録音・個人データを発注要件に落とす（保存期間／開示請求／委託先監督）

通話録音は、法解説として読むだけでは発注設計に落ちません。要件定義書と契約書のどこに何を書くかという形に変換してください。

要件定義書に書く項目は次のとおりです。

• 録音の対象範囲（全通話か、特定の窓口のみか）
• 録音していることの告知方法（IVR の冒頭アナウンスか、オペレーターの口頭案内か）
• 保存期間と、期間経過後の削除方法・削除の自動化有無
• アクセス権限（誰が再生・ダウンロードできるか、操作ログを残すか）
• 開示や照会の求めがあった場合に、対象の録音を特定・抽出する手順

契約書に書く項目として重要なのが、委託先の監督です。個人情報保護法は、個人データの取扱いを委託する場合、委託先に対する必要かつ適切な監督を行うことを委託元に義務づけています。個人情報保護委員会のガイドライン（通則編）では、この「必要かつ適切な監督」を、適切な委託先の選定、委託契約の締結、委託先における取扱状況の把握といった内容で具体化しています（個人情報保護委員会 個人情報の保護に関する法律についてのガイドライン（通則編））。

通話録音は音声という形式であっても、顧客個人を識別できる情報を含む以上、この監督義務の対象になりうるデータです。開発会社が録音データにアクセスできる構成（保守で本番環境に入る、障害調査で録音を再生するなど）を取るのであれば、契約書にアクセス条件・再委託の可否・報告義務・監査の受け入れといった条項を置く必要があります。

なお、保存期間や告知方法の具体的な水準は業種・利用目的によって判断が分かれる部分です。自社の業界規制や既存の個人情報保護方針との整合については、法務部門または専門家への確認を前提にしてください。本記事で示しているのは、発注設計上どの項目を要件として立てておくべきかという枠組みです。

稼働後の運用体制をどう確保するか（社内担当と外部人材の組み合わせ）

最後に見落とされがちなのが、稼働後に社内で誰がこのシステムを見るのかという問題です。導入プロジェクトは開発会社が主導しますが、稼働後の日々の調整（振り分けルールの変更、IVR 文言の修正、レポートの読み解き）を担う担当が社内にいないと、些細な変更のたびに外部への依頼と見積が発生し、改善のサイクルが止まります。

現実的な対処は次の 3 つです。

• 稼働前から社内担当を 1 名アサインし、開発期間中の設計レビューに同席させて仕様を把握させる
• 管理画面から設定変更できる範囲を、要件定義の段階で広めに確保しておく（分岐の文言・営業時間・振り分け条件など）
• 社内で賄えない専門領域は、常勤採用ではなく外部人材の関与で埋める

とくに音声認識や音声処理を含む構成を選んだ場合、その領域を理解している人材を社内に置くのは容易ではありません。プロジェクト期間中と稼働直後だけ外部の専門人材に関与してもらう選択肢もあります。具体的な進め方は音声AIエンジニアを業務委託で確保する方法で解説しています。

発注前チェックリストと、段階的に発注する進め方

見積依頼前に埋めるチェックリスト

ここまでの内容を、見積を依頼する前に埋めるチェックリストとしてまとめます。埋まっている項目が多いほど、相見積は比較しやすくなります。

このうち 1・2・3・4 は発注者にしか決められない項目です。5〜9 はベンダーと相談しながら詰められますが、たたき台は自社で作るべきものです。

要件定義・PoC を分離発注する段階発注の考え方

チェックリストの多くが埋まらない場合、無理に全体を一括発注する必要はありません。要件定義または PoC（技術検証）を分離して発注し、範囲が固まってから本開発を発注する進め方があります。

分けることの利点は 3 つあります。

• 範囲が不確定なまま一括で見積もると、ベンダーは不確実性をリスク費として上乗せするため、総額が膨らみやすい
• 要件定義の成果物（要件定義書・連携仕様・非機能要件）が手元に残るため、本開発フェーズで複数社に相見積を取り直せる
• 既存システムとの連携可否など、技術的に読めない部分を小さく検証してから本発注に進める

注意点もあります。要件定義を担当した会社が本開発でも有利になりやすいため、要件定義の成果物の権利帰属（自社に帰属し、他社への開示が可能か）を契約に明記しておく必要があります。ここを曖昧にすると、実質的に本開発でも同じ会社を選ばざるを得なくなります。

また、フェーズを分けると全体の期間は長くなります。稼働時期に強い制約がある場合は、要件定義フェーズの期間を明示的に区切り、期限までに決まらない項目は仮決めして本開発に進む、という運用ルールを最初に合意しておくと停滞を防げます。

埋まらない項目があるときの Go / No-Go 判断

最後に、発注に進んでよいかの判断基準を示します。

No-Go（発注を保留すべき状態） は、チェックリストの 1・2・4 のいずれかが埋まっていない場合です。入電構造が数値で押さえられていない、許容ダウンタイムが決まっていない、責任分界表に空欄がある。この 3 つはベンダーが代わりに決められない項目であり、埋まらないまま契約すると、稼働後の障害時に必ず問題が表面化します。

条件付き Go は、5〜9 に未確定が残るものの、1・2・3・4 が埋まっている場合です。未確定項目を「仮置きの前提」として見積依頼書に明記し、確定時に金額を再算定する条件を契約に入れれば進められます。この場合、再算定の範囲と上限を先に合意しておくのが安全です。

Go は 10 項目がおおむね埋まっている場合です。この状態であれば、相見積は同じ土俵に乗り、金額差の理由も説明できます。稟議の場で「なぜこの構成なのか、なぜこの金額なのか」を問われても、レイヤ分解と責任分界表を示して答えられるはずです。

コールセンターシステムの外注は、技術の目利きが問われる仕事に見えて、その本質は範囲を決めて文書に落とす仕事です。回線から業務アプリまでを 5 つの層に分け、それぞれを誰から買い、誰が責任を持つかを表にする。この作業さえ済んでいれば、電話という止められない業務を外部に委ねる判断も、根拠を持って下せるようになります。

関連情報

発注前のチェック項目を体系的に整理したい方は、お役立ち資料「システム開発 完全チェックリスト」もあわせてご活用ください。発注前・発注中・完了後の3フェーズで使えるチェック項目をまとめています。

発注範囲の切り分けや要件の整理段階からご相談されたい場合は、お問い合わせフォームからお気軽にご連絡ください。