ボイスボットとは？電話AIの仕組みと発注前に確認する精度・費用

「AIで電話対応を減らせ」と指示され、ベンダー資料を並べてみたものの、どの資料にも「認識率99%」「対応時間◯割削減」と書いてあるだけで、その数字がどんな条件で測られたのかは書かれていない。費用も「要問い合わせ」ばかりで全体像がつかめない。稟議の1行目を書こうとして手が止まる、という状況は珍しくありません。

この行き詰まりの正体は、情報が足りないことではありません。ベンダーが提示する数字を「自社の電話ではどうなるか」に翻訳する物差しを持っていないことです。物差しがないまま導入を決めると、精度が出なかったときに「なぜこのベンダーを選んだのか」という問いが、選定を任された自分ひとりに返ってきます。多くの担当者が本当に恐れているのは、AIの性能そのものよりもこの構図のほうです。

ただ、この物差しは発注前に自分で作れます。ボイスボットの精度は「音声認識」「意図理解」「業務完了」という3つの層に分解でき、ベンダーの数字がどの層のものかを問い直すだけで、比較の土俵がそろいます。費用も、公開されている相場レンジに加えて「見積書に現れにくいコストがどこに積み上がるか」を知っていれば、見積を受け取った時点で膨らむ場所を検知できます。

本記事では、ボイスボットとは何かという定義とIVR・チャットボットとの違いから始め、仕組みを3層に分解して整理します。その上で、発注前に確認すべき精度の検証手順（ベンダーへの質問と自社データでの測定方法）、費用相場と見積書の内訳、SaaS単体で足りるか連携開発が必要かの判定軸、そして発注前チェックリストまでを、特定製品に寄らない中立の視点で解説します。読み終えたときに、稟議とベンダー質問票にそのまま転記できる判断材料が手元に残ることを目指します。

—Free Download / 資料ダウンロード

はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ

この資料でわかること

AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。

こんな方におすすめです

• AI導入を検討しているが、何から始めればよいか分からない
• ベンダーの選び方や費用感がつかめず、判断できない
• 社内でAI導入の稟議を通すための資料が必要

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

ボイスボットとは？電話対応をAIが代行する仕組み

ボイスボットの定義と、電話業務のどこを代替するのか

ボイスボットとは、かかってきた電話（または発信した電話）の音声をAIが認識し、内容を解釈して自動で応答・処理まで行う仕組みです。ポイントは「応答」だけでなく「処理」まで含む点にあります。単に音声ガイダンスを流すのではなく、顧客が話した内容から必要な情報（氏名・予約日・注文番号など）を聞き取り、システムに登録したり、担当者へ転送したりするところまでを担います。

電話業務を「受電 → 用件の聞き取り → 情報の照会・登録 → 完了またはエスカレーション」という流れで分解すると、ボイスボットが代替できるのは主に前半の「受電」と「用件の聞き取り」、そして定型的な「情報の登録」までです。判断を伴う照会や、例外処理、感情的な対応が必要な場面は、後述のとおり有人対応に残すのが基本設計になります。

つまりボイスボットは「オペレーターの代わりに全部やってくれるもの」ではなく、「入電の一部を、条件を満たす範囲で切り出して自動処理するもの」です。この認識のずれが、後の「精度が出ない」というトラブルの入口になりやすいため、最初に押さえておく必要があります。

IVR・チャットボットとの違い（操作方法・入力形式・分岐設計）

社内説明でつまずきやすいのが、既存のIVR（自動音声応答）との違いです。IVRは「ご予約の方は1を、変更の方は2を押してください」というように、あらかじめ用意した番号メニューをプッシュ操作でたどらせる仕組みです。一方ボイスボットは、顧客が自然な言葉で用件を話すと、その内容から意図を判別して処理を進めます。

3つの観点で整理すると次のようになります。

IVRの構造的な弱点は、メニューが複雑・長大になるほど顧客が目的にたどり着けず、オペレーターにつながる前に切ってしまう「放棄呼」が増える点にあります。ガイダンスが長い場合や選択肢が複雑な場合、また待ち時間が長い場合に放棄呼が増えやすいことは、コールセンター運用の一般的な課題として指摘されています（Helpfeel「コールセンターの放棄呼とは？」）。ボイスボットは「用件を話せば分岐する」ことで階層を浅くできるため、この離脱を減らす狙いで検討されることが多い技術です。

なお、既存IVRを全面的に置き換える必要はありません。「番号選択で十分な分岐はIVRに残し、自由入力が必要な部分だけボイスボットに渡す」という併存設計も一般的で、後述する連携要否の判断にも関わってきます。

ボイスボットの仕組み — 音声認識・対話制御・音声合成の3層

ボイスボットの内部は、大きく3つの処理が連鎖する構造になっています。この3層構造は、後段で扱う精度の検証フレームの前提になるため、順を追って押さえてください。

第1層：音声認識（ASR / Automatic Speech Recognition） 電話回線から入ってきた音声を、テキストに変換する処理です。「明日の14時に予約を変更したいのですが」という発話を、そのまま文字列に起こします。ここでの誤りは以降のすべての処理に波及するため、ボイスボットの精度を左右する最大の要因になります。

第2層：対話制御（NLU＋シナリオ／対話管理） 文字起こしされたテキストから「顧客が何をしたいのか（意図）」と「処理に必要な情報（日時・氏名・番号などのエンティティ）」を抽出し、次に何を尋ねるか・どのシステムを呼ぶかを決める処理です。「予約変更」という意図を判定し、必要な項目が足りなければ聞き返し、そろえば基幹システムへ登録する、といった制御を担います。

第3層：音声合成（TTS / Text to Speech） 返答テキストを音声に変換して顧客に読み上げる処理です。聞き取りやすさや不自然な間（ま）は顧客体験に直結しますが、業務が完了するかどうかへの影響は前2層より小さい層です。

重要なのは、「精度が悪い」という現象が、この3層のどこで起きているかによって打ち手がまったく違うという点です。第1層の問題であればマイク品質・回線・専門用語の辞書登録が対象になり、第2層の問題であれば意図の設計やシナリオの分岐が対象になります。ベンダーの提示する数字がどの層のものかを見分けられないままだと、この切り分けができません。

生成AI搭載型とシナリオ型で何が変わったか

近年のボイスボットは、対話制御の部分に大規模言語モデル（LLM）を組み込んだ製品が増えています。従来型（シナリオ型）と生成AI搭載型の違いは、おおむね次のように整理できます。

• シナリオ型：想定される用件ごとに、聞き取る項目と分岐をあらかじめ設計します。挙動が決定的で検証しやすく、コストも抑えやすい一方、想定外の言い回しには弱く、業務変更のたびにシナリオ改修が発生します。
• 生成AI搭載型：表現のゆれを吸収しやすく、聞き返しや言い換えが自然になります。一方で応答内容が確率的に変動するため、事実と異なる回答（ハルシネーション）を防ぐ制御や、応答ログの継続的な検証が必要になります。

どちらが優れているかではなく、「用件が定型で誤りが許されない業務ほどシナリオ型寄り、問い合わせの幅が広く一次受付に留める業務ほど生成AI型寄り」という使い分けになります。シナリオ型とAI型で精度・運用がどう変わるかという比較の考え方は、テキストチャネルを題材にしたAIチャットボットと従来型の違いでも整理しています。音声の場合は、ここに第1層の音声認識誤りが上乗せされる点だけが異なります。

AI電話自動応答で任せられる業務・任せてはいけない業務

ボイスボットで「精度が出ない」と評価される案件の多くは、モデルの性能そのものより、対象業務の選び方に原因があります。自動化する範囲を決めることは、技術選定より先に行うべき作業です。

自動化に向く電話業務の3条件

AI電話自動応答に任せてよい業務かどうかは、次の3条件で判定できます。3つすべてを満たすものから着手するのが安全です。

1. 用件が定型であること：かかってくる電話の目的が、少数のパターン（予約・変更・キャンセル・在庫確認など）に収束していること。「何を聞かれるか分からない総合窓口」は最初の対象に向きません。
2. 入力項目が有限であること：処理に必要な情報が、日時・数量・番号・氏名など、あらかじめ列挙できる項目に限られること。項目が確定していれば、聞き返しの設計と検証がしやすくなります。
3. 完了判定が機械的にできること：「予約が登録された」「注文が確定した」のように、成功・失敗をシステム上のデータで判定できること。これができない業務は、後述するPoCのKPIが設定できず、効果を証明できません。

3条件目は見落とされがちですが、稟議上は最も重要です。完了判定がデータで取れない業務を選ぶと、導入後に「役に立っているのか分からない」という状態になり、次の投資判断ができなくなります。

有人対応を残すべき業務と、その線引き

一方で、次の性質を持つ業務は自動化の対象から外し、有人対応に残す判断が基本になります。

• 感情対応が中心の入電：クレーム・トラブル報告など、顧客が不満や不安を抱えている状態での応対。自動応答が「聞き返し」を繰り返すと、不満が増幅します。
• 複合的な相談：ひとつの電話に複数の用件が混在し、状況に応じて判断が変わるもの。意図の分類が安定しません。
• 本人確認を伴う高リスク処理：契約解約・金銭に関わる変更・個人情報の開示など。音声認識の誤りがそのまま事故になる領域です。
• 例外処理・イレギュラー対応：件数が少なく、パターン化できないもの。シナリオ設計のコストが効果を上回ります。

線引きの実務的なコツは、「自動化する業務」を決めるのではなく、「自動化しない業務を先に決める」ことです。除外リストを先に確定させると、残った領域が自然にスコープになり、範囲を広げすぎる失敗を構造的に防げます。電話対応の自動化範囲をより体系的に切り分けたい場合は、AIコールセンター導入の判断基準で扱っている層別の判断フレームも参考になります。

ボイスボットの活用事例から読む適用範囲

ボイスボットの活用事例としてよく挙げられるものを、先の3条件と照らして見ると、なぜその業務が選ばれているのかが分かります。

いずれも「用件が絞れていて、聞き取る項目が数個で、システム上に結果が残る」という共通点があります。逆に言えば、自社の入電を分類したときにこの型に当てはまる業務が見つからない場合、ボイスボットの導入時期としてはまだ早い可能性があります。まずは入電ログを用件別に集計し、上位の用件が全体の何割を占めるかを確認するところから始めるのが現実的です。

発注前に確認すべきボイスボットの精度

ここからが本記事の核心です。ベンダー資料に並ぶ「認識率99%」という数字を、自社の電話業務に当てはめてよいかを判断するための手順を扱います。

「認識率99%」を鵜呑みにしない — 測定条件を問う4つの質問

音声認識の精度は、測定条件によって大きく変動します。専門用語が多い、訛りが強い、周囲の騒音が大きいといった環境では精度が落ちうることは、音声認識技術の一般的な前提として知られています（ElevenLabs「ワードエラー率（WER）とは？」）。つまり「99%」という数字は、それ自体では意味を持たず、どの条件で測ったかとセットで初めて比較可能になります。

ベンダーに投げるべき質問は、次の4つに集約できます。いずれも見積依頼と同時に質問票として渡せる粒度にしてあります。

1. その数字は何のデータで測りましたか：スタジオ収録の読み上げ音声か、実際の電話回線を通した通話音声か。電話回線は帯域が狭く、読み上げ音声での測定値はそのまま再現しません。
2. どんな指標で測りましたか：単語誤り率（WER）か、文字誤り率（CER）か、それとも「正しく処理できた通話の割合」か。WERは（置換＋削除＋挿入）÷正解単語数で算出される単語レベルの指標で、業務が完了したかどうかとは別物です。
3. 難条件を含んでいますか：背景騒音（屋外・店舗内）、方言・アクセント、高齢者の発話、固有名詞や型番の読み上げが評価データに含まれているか。含まれていない場合、自社の入電で再現する保証はありません。
4. 自社データで再測定できますか：PoC時に自社の通話ログ（または模擬通話）で同じ指標を測り直せるか。ここを断るベンダーは、条件付きの数字しか出していない可能性を考慮する必要があります。

この4問に答えられるベンダーとそうでないベンダーを分けるだけで、比較検討の精度は大きく上がります。

音声認識の精度は3層に分けて確認する（ASR精度／意図理解精度／業務完了率）

多くの資料で「精度」と一括りにされている指標は、先に整理した3層構造に対応して分解できます。この分解が、本記事で最も持ち帰っていただきたい枠組みです。

この3層に分けると、ベンダーの数字の読み方が変わります。たとえば「認識率99%」が第1層の値であっても、第2層の意図理解で誤りが積み重なり、第3層の業務完了率は70%前後にとどまる、という構造は十分に起こりえます。発注判断で本当に見るべきは第3層の業務完了率であり、第1層の数字は必要条件にすぎません。

逆に、第3層の数字だけを見て「完了率が低いからAIが悪い」と判断するのも誤りです。第1層が良好で第3層が低い場合、原因はシナリオ設計や対象業務の選定にあり、製品を変えても改善しません。3層に分けて計測することは、責任の所在を技術と設計に切り分けるための手順でもあります。

自社の通話条件で検証する手順（難条件セットの作り方）

ベンダーの数字を確かめるには、自社の条件で測り直すのが最短です。次の手順は、PoCの前段として発注前に実施できます。

手順1：実通話ログをサンプリングする 直近の入電から、用件別に各30〜50件程度を無作為に抽出します。ここで重要なのは「きれいな通話」を選ばないことです。抽出は無作為に行い、聞き取りにくいものを除外しないでください。

手順2：難条件セットを作る 抽出した通話を、次の観点でタグ付けし、条件別の小さな評価セットを作ります。

• 背景騒音の有無（屋外・車内・店舗内・自宅）
• 話者の属性（高齢者・早口・小声）
• 方言・アクセントの有無
• 固有名詞の含有（商品名・型番・地名・氏名）
• 発話の長さ（一文が長い／短い、途中で言い直す）

各タグにつき10件程度あれば、条件ごとの得手不得手は十分に見えます。

手順3：3層それぞれで測定する 第1層は文字起こし結果と正解テキストを突き合わせて誤り率を出します。第2層は意図の分類結果を人手で正誤判定します。第3層は「その通話で用件が完了したか」を人手または業務データで判定します。件数が少なくても、条件別に数字が割れているかどうかが分かれば発注判断には十分です。

手順4：条件別に「捨てる範囲」を決める すべての条件で高い精度を狙う必要はありません。たとえば「背景騒音が大きい通話は最初から有人転送に回す」という設計にすれば、その条件の精度は問題になりません。精度を上げる代わりに範囲を狭めるという選択肢を持てることが、この検証の実務的な価値です。

PoCで測るKPIと合格ラインの決め方

PoCで見るべき指標は、業務完了率を中心に4つに整理できます。IVRの運用でも、メニュー別の選択率・途中離脱率・オペレーター希望のプッシュ率・転送成功率といった指標をダッシュボードで確認することが重要とされており（モビルス「コールセンターのIVRとは」）、ボイスボットでも考え方は共通します。

合格ラインの決め方には、絶対値の目標を先に置く方法と、現行運用との比較で置く方法があります。稟議で説明しやすいのは後者です。たとえば「対象業務の入電のうち、業務完了率がX%に達すれば、その分のオペレーター工数が削減できる」という形で、削減できる工数と費用が投資回収の条件を満たす水準を逆算し、それをX%として設定します。この置き方であれば、合格・不合格の判断が費用対効果の議論と直結します。

同時に、失格ライン（撤退条件）も先に決めておくことを推奨します。「再入電率が現行比で悪化したら本番展開しない」「途中離脱率が◯%を超えたら対象業務を絞り直す」といった条件を事前に合意しておけば、結果が芳しくなかった場合でも「事前に決めた基準に従った」という説明ができます。これは、冒頭で触れた「精度が出なかったときに自分が責任を問われる」という不安に対する、最も実務的な備えです。

なお、自動化率（自動応答できた割合）だけをKPIにするのは危険です。自動応答率が上がっても顧客満足度が下がり有人対応の負荷が増えるケースがあることは、導入企業の課題として指摘されています（岩通ソリューション「ボイスボット導入の失敗を防ぐ有人連携・システム連携」）。必ず離脱・再入電とセットで見てください。

ボイスボットの費用相場と、見積書で確認すべき内訳

精度と並んで稟議を止めるのが費用の不確実性です。相場のレンジだけでなく、「どこで膨らむか」を先に知っておくことで、見積を受け取った時点で確認すべき質問が具体化します。

料金体系は従量課金型と月額固定型の2つ

ボイスボットの料金は、大きく2つの体系に分かれます。

• 従量課金型：応答1件（1コール）あたりの単価で課金される方式。入電数の変動が大きい業務や、特定期間だけ入電が集中する業務に向きます。入電が想定を超えると費用も比例して増えるため、上限の設定有無を確認する必要があります。
• 月額固定型：一定のコール数まで定額で利用できる方式。入電量が安定しており、予算を固定したい場合に向きます。上限コール数を超えた分の超過料金の単価と、上限の引き上げ条件を確認してください。

選定時のポイントは、「どちらが安いか」ではなく「自社の入電量の変動幅で、どちらが予算のブレを抑えられるか」です。月別の入電数を12ヶ月分並べ、最繁忙月と最閑散月の両方で試算すると、体系の向き不向きが明確になります。

ボイスボットの費用相場（初期費用・月額・1応答あたり単価）

公開されている相場情報を整理すると、次のレンジが目安になります。

（出典：アイミツSaaS「ボイスボットの費用相場は？」）

同記事では、多くのサービスが「要問い合わせ」であり、実際の初期費用・月額料金は相場より高くなる傾向があるとも指摘されています。つまり、このレンジは下限の目安として読み、上振れ前提で予算を組むのが安全です。

1応答50〜200円という単価は、有人対応との比較で意味を持ちます。月間3,000コールのうち5割を自動化できた場合、1,500コール × 100円で月15万円という試算になります。この金額が削減できるオペレーター工数の人件費を下回るかどうかが、投資判断の基礎になります。なお、テキストチャネルを含めて自動応答全体の費用構造を比較したい場合は、AIチャットボット開発の費用相場で扱っている見積書の内訳の考え方が、音声チャネルでもそのまま応用できます。

見積書に現れにくい4つのコスト

相場レンジに含まれない費用が、予算超過の主因になります。見積書のどこを見れば検知できるかとあわせて整理します。

1. シナリオ設計・改修費 初期のシナリオ設計費が初期費用に含まれているか、別建てかを確認します。より重要なのは改修費です。業務変更や商品追加のたびにシナリオを直す必要があり、「年間◯回まで無償」「1回あたり◯万円」といった条件が見積書のどこかに書かれているはずです。記載がない場合は、改修の依頼手順・費用・リードタイムを質問してください。運用開始後に最も頻繁に発生する費用です。

2. 既存システム連携の開発費 CRM・基幹システム・PBXとの連携は、標準機能で完結する場合と個別開発が必要な場合があります。見積書に「API連携」「初期設定」としか書かれていないときは、どのシステムと、どの項目を、どちらの向きに連携するのかを明細レベルで確認します。ここが曖昧なまま契約すると、後から追加の開発費が発生します。

3. 通話料 ボイスボットの利用料とは別に、電話回線の通話料が発生します。着信課金（フリーダイヤル）を採用している場合は、ボイスボットが応答している時間もすべて自社負担です。自動応答は有人対応より通話時間が長くなる場合がある（聞き返しが入るため）点に注意が必要で、想定通話時間 × 単価で試算しておくべき項目です。発信型（アウトバウンド）で使う場合はさらに影響が大きくなります。

4. 運用工数（社内の人件費） 応答ログの確認、誤認識の傾向分析、辞書の更新、シナリオの改善といった作業は、導入後に継続的に発生します。これは見積書には現れませんが、実質的なコストです。月あたり何時間を誰が担当するのかを決めずに導入すると、改善が止まり、精度が上がらないまま費用だけが継続します。

有人対応コストとの損益分岐をどう置くか

稟議で最も説得力を持つのは、1コールあたりの単価比較です。次の式で両者をそろえます。

• 有人対応の1コール単価 ＝（オペレーター人件費＋管理費＋設備費）÷ 月間処理コール数
• ボイスボットの1コール単価 ＝（月額費用＋従量課金＋通話料＋按分した初期費用＋運用工数の人件費）÷ 月間自動処理コール数

ここで重要なのは、分母に**「自動処理できたコール数」だけを入れる**ことです。有人転送されたコールは、ボイスボットの費用と有人対応の費用が二重にかかっています。この二重コスト分を無視すると、損益分岐点を実態より楽観的に見積もることになります。

初期費用は導入から回収を見込む期間（12ヶ月または24ヶ月）で按分します。この試算をPoC前に置いておくと、前段で述べた「業務完了率の合格ライン」を逆算できます。完了率が何%を超えれば、有人対応より1コール単価が安くなるか——この1点が、稟議に書くべき数字です。

SaaSをそのまま使うか、連携開発が必要か（ボイスボットの選び方）

ボイスボットの選び方でつまずきやすいのが、「SaaSを契約すれば済むと思っていたら連携開発が必要になり、予算が足りなくなる」というパターンです。これは発注前に判定できます。

SaaS単体で足りるかを判定する3軸

次の3軸で自社の状況を評価すると、SaaS単体導入とカスタム連携開発のどちらに寄せるべきかが見えます。

3軸すべてが左側であれば、SaaS単体で始めるのが合理的です。ひとつでも右側に該当する場合、その項目について**「標準機能で対応できるか」をベンダーに書面で確認する**ことが、見積の精度を上げる最短の手段になります。

連携開発が必要になる典型ケース

具体的に、次のようなケースでは個別の連携開発が発生しやすくなります。

• 顧客情報の照会：発信者番号や顧客番号から、CRM上の契約状況・過去の問い合わせ履歴を参照して応答内容を変える場合。読み取り方向のAPI連携が必要です。
• 基幹システムへの登録：予約・注文・変更をその場で基幹システムに書き込む場合。書き込み方向の連携は、エラー時のリトライ・整合性担保の設計が加わるため、読み取りより工数が大きくなります。
• 既存IVRからの分岐移譲：現行のIVRメニューの一部だけをボイスボットに渡す構成。PBX側の設定変更と、転送時の情報引き継ぎ設計が必要になります。
• 有人転送時のデータ引き継ぎ：ボイスボットが聞き取った内容をオペレーターの画面にポップアップさせる構成。これを省くと、顧客が同じ説明を二度する状態が生まれます。

特に最後の項目は、導入失敗の代表例として挙げられています。ボイスボットが取得した内容が引き継がれていないと、オペレーターは改めて状況を確認する必要があり、顧客は説明を最初から繰り返すことになるため、顧客満足度の低下と通話時間の増加を招くと指摘されています（岩通ソリューション）。有人転送は「逃げ道」ではなく、設計対象として扱う必要があります。

導入・運用に必要な社内体制と外部人材の使いどころ

体制の観点では、次の3つの役割が必要になります。担当者を空欄のまま稟議を通すと、導入後に改善が止まります。

1. 業務オーナー：対象業務の範囲を決め、シナリオの内容に責任を持つ役割。カスタマーサポート部門の実務者が担うのが自然です。
2. 運用担当：応答ログを定期的に確認し、誤認識の傾向を拾って辞書やシナリオの改善要求を出す役割。月数時間から始められますが、担当を決めることが必須です。
3. 技術窓口：CRM・PBXなど既存システムとの接続を担当する役割。社内に該当者がいない場合、この部分だけを外部のエンジニアに委託する選択肢があります。

連携開発が必要と判定された場合、SaaSベンダーが連携部分まで請け負うか、別途開発会社に委託するかで費用と責任範囲が変わります。「ベンダーの標準機能の範囲」と「自社側で用意すべき範囲」の境界線を、見積段階で文書化しておくことが、後の追加費用を防ぐ最も有効な手段です。

そして、3軸の判定結果と費用試算を突き合わせた結果、投資回収の見通しが立たない場合は「今は導入しない」という結論も正当な選択肢です。入電の用件が分散していて自動化対象が切り出せない、対象コール数が少なく初期費用を回収できない、といった状況であれば、入電ログの整理と用件の標準化を先に進めるほうが、結果的に導入コストを下げることにつながります。

ボイスボット導入の失敗パターンと発注前チェックリスト

最後に、ここまでの内容を発注前の確認項目の形にまとめます。そのままベンダー質問票や稟議の添付資料に転記できる粒度で整理しています。

ボイスボット導入でよくある失敗パターン5つ

1. 対象範囲を広げすぎる 「せっかく入れるなら全部の入電を」と範囲を広げた結果、意図の分類が安定せず、どの業務でも完了率が上がらない状態になります。対策は、前述の3条件を満たす業務に絞り、除外リストを先に確定させることです。

2. CRM・FAQとの連携を後回しにする 顧客情報を参照できないため、応答が一般的な内容にとどまり、結局オペレーターに回ることになります。連携の要否は、導入判断と同時に決めるべき項目です。

3. PBX・既存IVRとの設計が分断される ボイスボットを既存の電話フローに組み込まないまま導入すると、顧客がどの窓口にかけても目的にたどり着けない構造になります。既存フローのどこに差し込むかを図で描いてから発注してください。

4. 有人転送時の情報引き継ぎを設計しない 顧客が同じ説明を繰り返す状態を生み、顧客満足度の低下とオペレーターの通話時間増加を同時に招きます（岩通ソリューション）。要約の受け渡し方法を仕様に含めます。

5. 改善体制を用意しない／自動化率だけを見る 運用担当が決まっていないとログが分析されず、精度が上がりません。また自動化率だけを追うと、離脱や再入電の悪化を見落とします。KPIは業務完了率・途中離脱率・有人転送率・再入電率のセットで設定します。

スモールスタート → PoC → 本番の3フェーズ設計

失敗を避ける進め方は、フェーズを分けて「引き返せる状態」を保つことです。

フェーズ1：スモールスタート（対象業務の切り出し） 入電ログを用件別に集計し、上位の用件から3条件を満たすものを1〜2種類選びます。この段階の成果物は「自動化する業務」と「自動化しない業務」のリスト、そして現行の有人対応1コール単価です。

フェーズ2：PoC（限定運用と測定） 選んだ業務・限定した時間帯や回線でボイスボットを稼働させ、業務完了率・途中離脱率・有人転送率・再入電率を測定します。合格ラインと撤退条件は稼働前に文書化します。難条件セットでの3層測定もこの段階で行います。

フェーズ3：本番展開（範囲の段階的拡大） 合格ラインを満たした業務から順に、対象時間帯・対象回線を広げます。同時に、シナリオ改修のサイクル（誰が・どの頻度で・どの費用で）を運用ルールとして定めます。範囲を広げるたびに、KPIが維持されているかを確認します。

各フェーズの区切りで「次に進む／範囲を絞る／中止する」を判断できる状態にしておくことが、責任を個人に集中させない進め方です。

発注前チェックリスト（精度・費用・連携・運用体制）

精度

• ベンダーの提示数値が、読み上げ音声ではなく実通話（電話回線経由）での測定値であることを確認したか
• その数値が音声認識精度・意図理解精度・業務完了率のどの層のものかを特定したか
• 評価データに難条件（騒音・方言・高齢者・固有名詞）が含まれているかを確認したか
• 自社の通話ログでPoC時に再測定できることを合意したか
• 業務完了率の合格ラインと、撤退条件を数値で文書化したか

費用

• 従量課金型・月額固定型のどちらが自社の入電変動に適するかを、12ヶ月分の入電数で試算したか
• シナリオ改修費の条件（無償回数・単価・リードタイム）が見積書または契約書に明記されているか
• 連携開発の範囲が明細レベル（対象システム・項目・連携方向）で記載されているか
• 通話料を想定通話時間 × 単価で試算し、予算に含めたか
• 有人対応の1コール単価とボイスボットの1コール単価を、同じ計算式でそろえて比較したか

連携

• 顧客情報の照会・基幹システムへの登録の要否を判定したか
• 既存IVR／PBXのどこにボイスボットを差し込むかをフロー図で描いたか
• 有人転送時に、聞き取った内容をオペレーターへ引き継ぐ方法が仕様に含まれているか
• ベンダーの標準機能の範囲と、自社側で用意すべき範囲の境界線を文書化したか

運用体制

• 業務オーナー・運用担当・技術窓口の3役割に、それぞれ担当者名を割り当てたか
• 応答ログの確認頻度と、改善要求を出す手順を決めたか
• KPI（業務完了率・途中離脱率・有人転送率・再入電率）を継続的に取得できる仕組みがあるか
• 運用工数を月あたりの時間で見積もり、費用試算に含めたか

まとめ｜ボイスボットの精度と費用は発注前に確かめられる

ボイスボットとは、電話の音声をAIが認識し、内容を解釈して応答・処理まで自動で行う仕組みです。内部は音声認識・対話制御・音声合成の3層で構成され、この構造を理解していることが、ベンダーの提示する数字を読み解く前提になります。

発注判断で押さえるべき点は、次の3つに集約されます。

精度は3層に分解して、測定条件を問う。 「認識率99%」は測定条件とセットでなければ比較できません。実通話での測定か、どの指標か、難条件を含むか、自社データで再測定できるか——この4問で土俵をそろえた上で、本当に見るべき業務完了率を確認します。

費用はレンジと隠れコストの両方を見る。 従量課金型で1件50〜200円程度、月額固定型で初期10万円〜・月額1万〜35万円程度というレンジは下限の目安であり、シナリオ改修費・連携開発費・通話料・運用工数が上乗せされます。有人対応との1コール単価比較を、同じ計算式でそろえて置くことが稟議の芯になります。

範囲は狭く始め、引き返せる状態を保つ。 用件が定型・入力項目が有限・完了判定が機械的にできる業務に絞り、合格ラインと撤退条件を稼働前に文書化する。この進め方であれば、結果が想定に届かなかった場合でも「事前に決めた基準に従って判断した」という説明が成立します。

判断できないのは情報が足りないからではなく、物差しがなかったからです。3層のフレームと発注前チェックリストを手元に置けば、ベンダーの数字に依存せず、自社の条件で「導入する／範囲を絞る／今は見送る」を根拠付きで決められる状態に移行できます。

AIの活用可否を社内でどう判断するかを体系的に整理したい方に向けて、対象業務の選び方から効果測定までの進め方をまとめた「中小企業のためのAI導入ガイド」をご用意しています。本記事で扱った対象業務の切り出しやKPI設計を、AI活用全般に広げて検討する際の参考資料としてご利用いただけます。

既存のCRM・基幹システムとの連携要否の判断や、SaaS導入と個別開発の切り分けについて相談先をお探しの場合は、お問い合わせフォームからご連絡ください。要件の整理段階からご相談いただけます。

—Free Download / 資料ダウンロード

はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ

この資料でわかること

AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。

こんな方におすすめです

• AI導入を検討しているが、何から始めればよいか分からない
• ベンダーの選び方や費用感がつかめず、判断できない
• 社内でAI導入の稟議を通すための資料が必要

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。