はじめに
2026年4月20日のアップデートで、音声案内の再生前や再生中にキーパッドで入力した番号を一時的に保存・保持する「タッチトーンバッファリング」機能が追加されました。
これにより、発信者は音声案内が終わる前でも番号を入力でき、早く押しすぎたり連打したりしても入力は失われなくなります。目的の操作へ素早くたどり着けるようになるため、顧客体験の向上が期待できます。
本記事では、この機能を実際にコンタクトフローへ組み込み、動作を確認します。
本記事の情報は 2026 年 6 月時点のものです。
最新情報については公式ドキュメントをご確認ください。
この記事でわかること
- タッチトーンバッファリングで何ができるのか（Before / After）
-
プロンプトの再生/顧客の入力を取得するブロックと連携した際の挙動
先に結論
タッチトーンバッファリングを有効にすると、IVR の入力体験は次のように変わります。
| 観点 | Before（従来） | After（バッファリング有効） |
|---|---|---|
| 早押し・連打 | 入力が失われる可能性あり | 最大 30 桁までバッファに保持される |
| 案内のスキップ | キー割り込みはできるが、案内を飛ばす仕組みはない | バッファされている番号があれば、案内を最後まで再生せず丸ごとスキップできる |
| 発信者情報 | 通話開始後の入力のみ有効 | ダイヤル文字列で事前に受け渡し可能 |
1つ目の「早押し・連打」と 2つ目の「案内のスキップ」は、発信者が通話中に行う入力そのものの改善です。早押ししても入力が失われず、慣れたメニューなら案内を待たずに先へ進めます。
また、3つ目の「発信者情報」は、Web サイトやアプリからの発信（choose-to-call / app-to-call）で効いてくる観点のようです。公式ドキュメントでは次のように説明されています。
タッチトーンバッファリングを使用すると、アプリケーションは会話が始まる前に、既知の発信者コンテキストをフローに渡すことができます。通話選択シナリオやアプリ通話シナリオでは、発信元アプリケーションは顧客識別子、Webセッション参照、またはその他のコンテキストをダイヤル文字列に追加できます。
1. タッチトーンバッファリングとは
以下、公式ドキュメントの抜粋です。ひとことで言うと IVR の「先行入力」を実現する仕組み のようです。
Amazon Connect のタッチトーンバッファリングは、各プロンプトが終了するのを待ったり入力を失ったりすることなく、顧客が完全なメニューパス (1～2～3 を急速な連続で押すなど) または入力識別番号 (アカウント IDsや注文番号など) をすぐに入力できるようにすることで、IVR システムの一般的なフラストレーションを排除します。この「先行型」機能により、通話処理時間が短縮され、セルフサービスの封じ込めが向上します。
概要
- 発信者は
1,2,3のように番号(DTMF)をまとめて先行入力できる - 口座番号・注文番号などの識別番号も、各プロンプトの完了を待たずに入力できる
- 入力された番号は最大30桁の一時バッファに蓄積され、フロー側が必要とするタイミングで消費される
- バッファの番号は処理直後に破棄され、30桁へ達すると空きが出るまで以降の入力は無視される
これにより、通話処理時間の短縮とセルフサービス完結率の改善が期待できる、という位置づけです。
2. 対応チャネル
対応チャネルは音声（Voice）のみです。それ以外はエラーブランチに分岐します。
| チャネル | 対応 |
|---|---|
| Voice | 対応 |
| Chat | 非対応（Error ブランチ） |
| Task | 非対応（Error ブランチ） |
| 非対応（Error ブランチ） |
3. 実際に試してみた
3.1 検証環境
- AWS リージョン: 東京 (
ap-northeast-1)
3.2 検証内容
タッチトーンバッファリング設定の あり / なし で、IVR の入力挙動がどう変わるかを確認します。
| # | 検証項目 | バッファリング | 期待する挙動 |
|---|---|---|---|
| 1 | 「顧客の入力を取得する」ブロック処理中の番号入力 | なし | 入力待ちのブロックなので、案内中に押した番号も受け付けられる（DTMF バージイン。従来から可能） |
| 2 | 「顧客の入力を取得する」ブロック処理中の番号入力 | あり | バッファに番号があれば、発信者へ促さず自動で取り出して次へ進む |
| 3 | 「プロンプトの再生」ブロック処理中の番号入力 | なし | 入力待ちでないため、再生中に押した番号は保持されず失われる |
| 4 | 「プロンプトの再生」ブロック処理中の番号入力 | あり | スキップ設定を入れておくと、バッファに番号が残っている間は案内は丸ごとスキップされる |
| 5 | 複数桁の入力 | なし | 入力ブロックの案内前に押した番号は失われ、案内後に入力し直す必要がある |
| 6 | 複数桁の入力 | あり | 案内の前に押した番号を 「顧客の入力を取得する」ブロックが促しなしで受け取る |
3.3 コンタクトフローの作成
検証用のコンタクトフローを作成します。
全体像は以下の通りです。
計18個のブロックで構成されていますが、重要な①「タッチトーンバッファの動作を設定」ブロックと②「プロンプトの再生」ブロック、③「顧客の入力を取得する」ブロックの設定の詳細を説明します。
3.4 各ブロックの設定
① 「タッチトーンバッファの動作を設定」ブロック
- タッチトーンバッファオプション：
有効
② 「プロンプトの再生」ブロック
- 読み上げるテキスト(プロンプト再生中の入力を検証するために5秒間待機するよう設定)
<speak> プロンプト再生テスト<break time="5000ms"/> 再生終了 </speak> - 次として解釈：
SSML
「タッチトーンバッファ設定 - オプション」を有効化すると、バッファに値が残っていれば再生がスキップされます。デフォルトはOFFのため、必ず聞かせたい案内はチェックを外したままにします。
③「顧客の入力を取得する」ブロック（3カ所）
- 読み上げるテキストを入力：
DTMFテスト - オプション(DTMF)：
1,2,3
4. 動作確認
タッチトーンバッファの あり / なし で、各ブロックの処理中に先行入力した番号が保持・消費されるか、また案内はスキップされるかをテストします。検証フローは、5秒待機させた「プロンプトの再生」のあとに DTMF 1 / 2 / 3 の「顧客の入力を取得する」を3つ並べた構成です。案内の再生中に 1,2,3を先行入力し、各ブロックでの処理を確認しました。
動作確認結果
| # | 検証項目 | バッファリング | 結果 |
|---|---|---|---|
| 1 | 「顧客の入力を取得する」ブロック処理中の番号入力 | なし |
案内中に押した番号も受け付けた ⭕ |
| 2 | 「顧客の入力を取得する」ブロック処理中の番号入力 | あり |
促されず次のブロックへ進んだ ⭕ |
| 3 | 「プロンプトの再生」ブロック処理中の番号入力 | なし |
再生中に押した番号は失われた ⭕ |
| 4 | 「プロンプトの再生」ブロック処理中の番号入力 | あり |
案内がスキップされた ⭕ |
| 5 | 複数桁の入力 | なし |
案内前に押した番号は失われた ⭕ |
| 6 | 複数桁の入力 | あり |
促しなしでバッファの桁を受け取った ⭕ |
テストの結果、タッチトーンバッファリングの効果を以下の観点で確認できました。
- 「顧客の入力を取得する」ブロックでは、バッファに値があれば番号入力を促さず自動で次へ進むこと（
#2） - 「プロンプトの再生」ブロックでは、スキップ設定を入れておけばバッファが残っている間は案内が丸ごとスキップされること（
#4） - 複数桁の先行入力も失われずに受け取れること（
#6）
いずれも無効時には見られなかった挙動のため、先行入力がしっかり機能していることがわかりました。
まとめ
本記事では、タッチトーンバッファリングによる番号の先行入力を試してみました。
バッファありのときだけ、案内中・案内前に押した入力が後続ブロックへ引き継がれると確認できました。
「長文の案内」→「番号聞き取り」を何度も繰り返すようなIVRの構築時には、顧客体験の観点から1度利用を検討してみるのが良いと感じました。