基本知識
IVRとは?AI IVR・ボイスボットとの違いと使い分け
IVRの仕組みを、番号選択と音声対話の例で解説。AI IVR、クラウド型、ビジュアルIVRの分類を整理し、電話受付を見直すための確認表を紹介します。
公開日: Daisybell Japan

「予約に関するお問い合わせは1番を押してください」。電話でこうした案内を聞いたことがある方は多いでしょう。これは、IVRと呼ばれる自動音声応答の代表的な使い方です。
最近はAI IVRやボイスボットという言葉も見かけます。ただし、名称だけでは、番号で選ぶのか、話して用件を伝えるのか、手続きまで終えられるのかは分かりません。
この記事では、IVRの仕組みと種類を整理し、同じ用件を各方式で受ける例から、電話受付の見直し方を解説します。
IVRとは
IVRはInteractive Voice Responseの略で、日本語では自動音声応答と呼ばれます。 電話をかけた人に音声で案内し、入力された情報に応じて、回答の再生や窓口への転送、必要な処理へ進める仕組みです。
よく知られているのは、電話機の番号を押して用件を選ぶ方式です。たとえば「契約中の方は1番、新規のご相談は2番」と案内し、選んだ番号に応じて分岐します。
一方、IVRを番号選択だけの仕組みと考えると、音声入力を使う構成を見落とします。音声対話の標準仕様であるVoiceXMLでも、音声入力、電話機のキー入力、その併用が扱われています。W3C VoiceXML 2.0:メニューの入力方式
IVRが電話を振り分ける流れ
番号選択型の基本的な流れは、次のように整理できます。
- 電話を受け、営業時間や用件の案内を流す。
- 利用者が案内に従って番号を押す。
- 選択した内容に合う案内、担当窓口、受付処理へ進む。
- 入力がない場合や、受け付けられない入力があった場合は、再案内や別の経路へ進む。
すべての電話を人が最初から受ける場合に比べ、目的別の案内や窓口の振り分けを事前に設計できます。ただし、最初のメニューが分かりにくければ、利用者はどこを選べばよいか迷います。
社内の部署名をそのまま読み上げるより、「請求内容を確認したい」「予約を変更したい」のように、相手の用件で選べるかを考えると整理しやすくなります。
AI IVR・ボイスボットとの違い
IVRは自動音声応答の仕組みを指す広い名称です。AI IVRは、用件の理解や会話などにAIを使う構成を指すことがあります。ボイスボットは、人の発話を受けて音声で応答する自動対話の仕組みです。
これらには重なりがあり、各名称の使い方も一律ではありません。比較するときは、次の三つに分けると判断しやすくなります。
| 見る点 | 確認すること | 例 |
|---|---|---|
| 入力方法 | 利用者が何をするか | 番号を押す、決めた言葉を話す、自由に用件を話す |
| 会話の進み方 | 不足や曖昧さをどう確認するか | 決まった質問で聞く、発話に応じて追加で聞く |
| 処理の範囲 | どこまで用件を進めるか | 案内、取次ぎ、情報の受付、照会・更新 |
たとえば、音声で用件を伝えられても、決まった単語にだけ反応する方式と、文の意味を解釈して質問する方式では、使い方が異なります。また、自然に会話できても、予約システムの更新までできるとは限りません。
音声認識や対話、業務処理の関係は、ボイスボットの基本記事でも整理しています。
同じ用件を、番号選択と音声対話で比べる
「予約の日時を変更したい」という問い合わせを例にします。番号選択では、案内を聞きながら該当するメニューを選びます。音声対話では、用件を話し、必要に応じて追加の質問に答えます。

図1:番号選択と音声対話の違い。本文の関係や手順を整理した図。
番号選択は、選択肢が少なく、違いが分かりやすいときに検討しやすい方式です。利用者に決まった操作を案内できますが、階層が深くなると、何度も説明を聞いて選び直す負担が生まれます。
音声対話は、利用者が自分の言葉で用件を伝える入口になります。一方、言い直し、雑音、聞き慣れない固有名詞、複数の用件が混ざる発話も想定する必要があります。「自由に話せる」と案内するなら、どの程度の表現に対応できるかを試します。
どちらの方式でも、最終的に予約変更を終えるには、対象の予約の確認や、変更内容の合意、システムでの登録が必要です。入口の便利さと、用件を終えられる範囲を分けて評価します。
クラウドIVR・ビジュアルIVRは、何が違うのか
IVRの説明では、入力方法と提供形態の言葉が混ざりやすくなります。「クラウド」と「AI」は同じ軸の分類ではありません。

図2:IVRは二つの軸で整理する。数量や実績を示すものではなく、考え方を整理した図。
クラウド型とオンプレミス型
クラウド型は外部の基盤を利用する形態、オンプレミス型は自社側に設備を設置する形態です。どちらにも、番号入力や音声入力を組み合わせる構成が考えられます。実際に利用できる機能は、個別のシステムで確認します。
検討時は、電話回線との接続、管理できる設定、既存設備との関係、利用が止まった場合の代替経路を確認します。「クラウドだからすべて任せられる」「自社設置だから自由に変えられる」とは決めつけず、保守の担当範囲まで見ます。
ビジュアルIVR
ビジュアルIVRは、電話の案内とWeb画面などを組み合わせ、画面上で選択や入力を進める仕組みを指す呼び方です。一般に、音声だけでは説明しにくい選択肢や、文字・画像で確認したい情報を扱う場面で検討されます。
利用者がスマートフォンなどで画面を開けることが前提になるため、音声だけで進めたい人の経路も必要です。画面への移動に失敗した場合や、入力途中で電話へ戻りたい場合の案内まで考えます。
IVRを見直すときの確認ポイント
メニューは利用者の言葉になっているか
「営業推進部」「業務管理課」といった組織名だけでは、初めて電話する人には選びにくいことがあります。社内の担当範囲を整理したうえで、利用者が達成したい用件に置き換えます。
選択肢の数だけで良し悪しを決めず、よくある用件に少ない手順で到達できるかを確認します。「その他」に多くの電話が集まる場合は、入口の分類が利用者の用件に合っていない可能性があります。
入力できない場合の出口があるか
番号入力がない、音声が聞き取れない、同じ案内を繰り返している、といった場面を試します。一定の条件で人や別の案内へ進めるようにすると、同じところに留まり続ける状態を避けられます。
音声対話の仕様では、入力がない状態や、入力が用意した認識条件に合わない状態を区別して扱います。実際の受付でも、単に「もう一度お願いします」と繰り返すだけでよいかを検討します。W3C VoiceXML 2.0:イベントの取扱い
人に渡した後、説明をやり直していないか
用件を聞いてから担当者へつないでも、その情報が伝わっていなければ、顧客は最初から説明することになります。選択したメニュー、確認済みの情報、まだ終わっていない作業を、転送先で見られるかを確認します。
有人対応を希望する人の経路も用意します。担当窓口の営業時間外なら、折り返し受付や別の連絡手段など、実際に対応可能な方法を案内します。
変更後の効果を、同じ条件で確認できるか
メニューの途中で電話を切った割合、担当窓口に届くまでの時間、転送の誤り、同じ用件での再入電などを見ます。案内を短くした結果、誤った窓口への電話が増えていないかも確認します。
月額や通話料だけでなく、案内の修正、FAQの保守、システム連携、有人対応まで含めた負担で判断します。料金の安さだけを理由に、利用者の手順を増やさないことが大切です。
そのまま使える受付方式の確認表
| 確認する項目 | 自社で書き出す内容 |
|---|---|
| 多い用件 | 最初に対応したい問い合わせと、その割合・時間帯 |
| 入力のしやすさ | 番号選択、音声、画面のどれを使える利用者か |
| 必要な確認 | 本人確認、対象データ、追加で聞く情報 |
| 完了する地点 | 案内、受付、取次ぎ、システム更新のどこまでか |
| 対応できない場合 | 無入力、聞き取り失敗、対象外、有人希望時の経路 |
| 保守する人 | 音声案内・回答内容・転送先を更新する担当者 |
| 評価すること | 到達時間、途中切断、誤転送、再説明・再入電 |
この表で「番号だけでは用件を分けにくい」「選択肢を追加するたびに案内が長くなる」と分かった場合は、音声で用件を受ける入口を試す理由になります。反対に、少数の選択肢で分かりやすく案内できているなら、その方式を活かすことも選択肢です。
使いにくいIVRを、実際の用件から組み直す
メニューを改善するときは、現在の番号の並びを少し短くする前に、利用者が何をしようとして電話したのかを確認します。「契約について」と「料金について」の両方に当てはまる相談が多いなら、選択肢の境界が分かりにくい可能性があります。部署の分担に沿った分類が、利用者にも分かりやすいとは限りません。

図3:迷いやすい入口を組み直す。本文の関係や手順を整理した図。
見直しの出発点には、誤った窓口へ届いた電話、「その他」を選んだ電話、途中で切れた電話が役立ちます。ただし、途中切断の理由は音声案内だけとは限りません。待てなくなったのか、必要な情報を聞いて終えたのか、操作に困ったのかを、記録や利用者の声と照合して考えます。
新しいメニューは、社内の担当者だけで読んで確認するより、窓口の構成を知らない人にも試してもらうと曖昧さが見えます。たとえば「先月の請求がいつもと違う」という用件を渡し、どの番号を選ぶか、その理由を聞きます。正しい答えを先に教えずに選んでもらうことが重要です。
選択肢は、利用者の目的で書く
「管理部」「サポート部」のような組織名は、既存の取引先には伝わっても、初めて利用する人には違いが分からない場合があります。「請求内容の確認」「商品の使い方」のように、何をしたいかで選べる表現を検討します。そのうえで、社内では担当する窓口へ対応づけます。
同じ言葉が複数の選択肢に入る場合は、その違いを短い説明で表せるか確認します。「新しい契約の相談」と「契約中の内容変更」のように対象の状態で分ける方法もあります。選択肢を増やすだけでなく、重なりを減らせるかを見ると、長いメニューを避けやすくなります。
一方、すべてを短くしようとして意味を削ると、利用者が間違った窓口へ進む可能性があります。案内の秒数だけで評価せず、何を選ぶべきか理解できるかを確かめます。読み上げる言葉を変えたときは、社内の分類名も同じ意味で記録されるかを確認しましょう。
よくある用件への道と、例外の出口を両方残す
多い用件を浅い階層へ置くことは、操作を減らす候補になります。ただし、少ない用件をすべて深い階層へ押し込むと、特別な相談をしたい人ほど迷いやすくなります。頻度とともに、用件の重要さや、間違えた場合の影響を考慮します。
「その他」をなくすことが必ずしも改善になるわけではありません。目的の選択肢が見つからない人の受け皿として必要な場合があります。問題は、その他の先で用件を整理できるかと、そこで集まった相談をメニューの見直しへ戻せるかです。入口で選べなかった理由を蓄積すると、分類の不足を確認できます。
無入力・誤入力・転送失敗を別の状態として扱う
何も入力されない状態と、受け付けられない番号が押された状態では、利用者が困っている理由が違うかもしれません。前者は案内を考えながら聞いている、操作方法が分からない、端末を手に取れていないなどの可能性があります。後者は番号を押し間違えた、前の案内の番号を覚えていたなどが考えられます。
理由を断定する必要はありませんが、同じ音声を何度も繰り返すだけでよいかを検討します。最初は短く再案内し、その後は別の受付経路へ進めるなど、利用者が同じ場所に留まり続けない流れを用意します。具体的な回数や待機時間は、用件と利用環境に合わせて試験します。
| 状態 | 案内・動作の検討例 | 記録したいこと |
|---|---|---|
| 入力がない | 操作方法を短く再案内する | どのメニューで止まったか |
| 対象外の番号 | 選べる番号を伝え直す | 入力内容と再入力の結果 |
| 音声が認識できない | 短い質問や別の入力方法へ切り替える | 聞き返しの回数と終了経路 |
| 転送先が出ない | 待機・折り返し等の代替を案内する | 転送先と未接続の状態 |
| 営業時間外 | 対応範囲と次の受付を伝える | 受付した用件と残作業 |
ここに挙げた動作は一般的な設計例です。現在のシステムがどこまで設定できるか、転送失敗を判定できるか、記録を残せるかは実際の仕様で確認します。画面上に設定があっても、使っている回線との組み合わせで期待どおりに動くかを通話で試す必要があります。
番号入力と音声対話を組み合わせるときの考え方
音声対話を導入する際も、現在の番号入力をすべてなくす必要はありません。大まかな窓口は番号で分け、予約や手続きに必要な内容を音声で聞く構成も考えられます。逆に、最初に用件を話してもらい、聞き取りにくい番号だけキー入力で補う構成を検討することもあります。
判断の基準は、技術の新しさではなく、相手の操作が分かりやすくなるかです。音声で答える案内の直後に番号入力が必要になるなら、切り替えを明示します。「続いて、電話機の番号を押してください」と操作を区切り、どちらで答えればよいか迷わせないようにします。
ただし、入力方法を増やすほど、設定や試験の組み合わせも増えます。音声の途中で番号を押した場合、番号を選んだ後に別の用件を話した場合、入力が重なった場合を確認します。切り替えられるという機能の有無だけでなく、切り替えた後に情報が正しく残るかを見ることが大切です。
画面へ案内する場合は、電話だけの経路も点検する
Web画面を併用すると、長い一覧や必要書類を目で確認できる場面があります。一方、通話中に画面を開くことが難しい利用者もいます。固定電話からかけている、通信環境が弱い、別の作業中で画面を見られないなど、利用する状況は一様ではありません。
そのため画面へ移る案内は、移った先で何ができるかと、開けない場合にどうするかを一緒に伝えます。リンクを送信できたことと、利用者が画面を開いて用件を進められたことは別です。画面の操作で迷った際に電話へ戻る経路も含めて設計します。
画面で入力した情報を後から担当者が確認するなら、電話側の記録と結びつける方法を検討します。利用者が同じ内容を電話と画面へ二度入力しなければならない場合、移動するメリットが薄れるかもしれません。音声と画面のどちらか一方だけを見るのではなく、一件の用件が終わるまでの手順を追ってください。
メニュー変更の前後で見る指標と、読み違い
案内を変える前に、どの指標が改善すれば狙いを達成したと考えるかを決めます。目的の窓口へ届くまでの時間、誤った転送、同じ説明の繰り返し、途中切断、受付後の再入電などが候補です。数値の定義と観測期間をそろえ、変更点を記録して比較します。
たとえば「その他」の選択が減っても、目的の選択肢へ進めたのか、選べずに切ったのかで評価は逆になります。また、担当窓口への到達が速くなっても、その先の待ちが長くなれば、顧客の負担は残ります。入口の指標だけでなく、窓口に届いた後の動きも確認します。
変更時は、案内の文言、番号の割り当て、転送先、営業時間の条件をセットで管理します。利用者へ公開している案内と設定の番号がずれると、以前の説明を見て電話した人が別の窓口へ進んでしまう可能性があります。社内資料やWebの案内にも関連する変更がないかを確認します。
繁忙期や臨時休業の直前に変更する場合は、通常日と異なる用件が増えることを踏まえます。可能なら対象の時間帯や窓口を絞って試し、問題が起きたときに元の案内へ戻す担当者と手順を決めます。変更が成功したかを判断するまでが、IVRの見直しに含まれる仕事です。
メニュー変更は窓口の案内と同時に確認する
番号の割り当てを変える場合は、音声だけでなく、Webサイトや担当者が送る案内に古い番号が残っていないかを確認します。「電話がつながったら二番を押してください」といった説明が残ると、新しいメニューで別の窓口へ進んでしまいます。変更する入口と、関連する説明を一組として管理しましょう。
変更直後は、誤った窓口に届いた用件と、その前に顧客が選んだ項目を確認します。メニューの言葉が分かりにくかったのか、以前の案内を見て操作したのかで修正箇所が違います。担当者が別窓口へ転送して対応できた場合も、その事実を集めることで、入口の分かりにくさを見逃さずに済みます。
よくある質問
IVRはAIを使っていますか?
IVRという名前だけでは分かりません。決めた音声案内と分岐ルールで動くものもあります。音声を認識する機能、発話の意味を解釈する機能、生成AIで回答する機能を、それぞれ確認します。
AI IVRにすれば、メニューは不要になりますか?
必ずしもそうではありません。最初の大分類は番号で選び、その先で音声対話を使うなど、組み合わせる設計もできます。利用者が迷わず用件を進められることを基準にします。
番号選択よりも音声対話の方が優れていますか?
用件や利用環境によって異なります。選択肢が明快なら番号入力が使いやすい場合もあり、用件の言い方が多様なら音声で受ける方法を検討できます。静かな場所だけでなく、実際の電話環境で試すことが必要です。
今のIVRとボイスボットは併用できますか?
併用できる構成はありますが、接続方法や転送時の情報連携は個別に確認が必要です。既存の番号、回線、担当窓口を整理し、どの用件から試すかを決めます。
方式名より、利用者が用件を進められるかを見る
IVRの見直しは、新しい呼び方の仕組みに入れ替えること自体が目的ではありません。利用者が迷わず用件を伝え、必要な窓口や処理へ進めるかを確かめることが重要です。
番号選択、音声対話、画面への案内、人の対応を、用件と利用者に合わせて組み合わせましょう。Daisybellへのご相談では、現在のメニューと、利用者が迷いやすい場面をお聞かせください。