Customer × Fabbi · AI First Support 24/7
AI Voice サポートセンターは
どうやって動いているのか
電話の向こうで「聞く・調べる・判断する・つなぐ」を 1 人でこなす AI オペレーター。その構成と、人間の担当者との役割分担を、専門用語なしで説明します。
§ 01 · たとえ話
24 時間起きている受付係と、その後ろの専門家チーム
ホテルのフロントを想像してください。受付係はお客様の話を聞き、手元のマニュアルを引き、自分で答えられることはその場で答え、答えられないことは適切な担当者に「引き継ぎメモ」を付けて回します。AI Voice サポートセンターはこの受付係を AI にしたものです。違いは、24 時間眠らず、日本語・英語・ベトナム語を聞き分け、電話を切った瞬間にチケットと記録が残っていることです。
ひとことで言うと: AI は「一次受付」を担当し、人間 (L1 Fabbi Da Nang / L2 Customer 専門担当) は「AI が解決できなかった案件だけ」を受け取ります。AI が人を置き換えるのではなく、人の前に立つ仕組みです。
§ 02 · 具体例
1 本の電話を最初から最後まで追う
デモで使っている実際のケースです。北斗フーズ株式会社 (プレミアムプラン・24/7 契約) の高橋様から「Outlook にサインインできない」という電話が入ったとします。
- 受付 (聞き取り)「北斗フーズの高橋です。Outlook にサインインできなくなりました」record_understanding → identify_customer(会社名) → 契約 C-2024-0117 / プレミアム / 24 時間対応 を確認
- 内容理解AI は分からない点を 1 つだけ確認します。「高橋様お一人だけでしょうか、それとも複数の方でしょうか」
- Knowledge 検索お客様の言葉を日本語キーワードに直して社内ナレッジを検索。複数ユーザーの症状なら Microsoft 365 の障害情報も同時に確認search_knowledge("Outlook サインイン パスワード") → KB 記事 + 推奨アクション / check_service_status()
- 判断とチケット起票ナレッジの推奨アクションに従い、自動回答か、L1 / L2 / 営業へのエスカレーションかを決め、話す前にチケットを作成create_ticket(...) → CS-0825-0001 / escalate_ticket(L1 / L2 / SALES)
- 回答生成「パスワードをリセットしてから再度サインインをお試しください。チケット番号は CS-0825-0001 です。解決しましたか」
画面で見えるもの: デモ画面の中央には通話ログ、右側には AI が呼んだツールと判断、チケット一覧と KPI (受付件数 / 自動解決 / エスカレーション / AI 解決率) がリアルタイムで表示されます。「AI が何を聞き取り、何を根拠に判断したか」がすべて見える設計です。
§ 03 · 構成
システム構成図
4 つの層で構成されています。お客様の声はブラウザ (将来は電話回線) から音声のまま AI に流れ、AI は「ツール」と呼ばれる窓口を通じて業務システムを読み書きします。
お客様側音声フロントエンドAI Agent業務データ / 自動解決人間へのエスカレーション
各層の役割
| 層 | 役割 | 今回のデモでの実装 |
|---|---|---|
| ① お客様 | 電話または Web ブラウザのマイクで話す | ブラウザ (PC / スマホ)。電話回線 (PSTN / SIP) 接続は次フェーズ |
| ② 音声フロントエンド | 音声を AI に届け、返答音声を再生。認証キーを守る | Cloudflare Pages + Functions。API キーはサーバー側のみ、ブラウザには 1 回限りの短命トークンだけ渡す |
| ③ AI Agent | 音声を直接理解し、ルールに従って調べ・判断し、音声で返答 | Google Gemini Live (ネイティブ音声モデル)。日本語優先、英語・ベトナム語対応 |
| ④ 業務システム | 契約情報、ナレッジ、チケット | デモ用データ (架空 3 社・FAQ 14 記事)。本番では Customer の CRM / ナレッジ / チケットシステムに接続 |
| ⑤ 振り分け | AI 解決 / L1 / L2 / 営業 | ナレッジ記事ごとの推奨アクションで決定。セキュリティ・全社障害は即 L2 |
技術メモ: AI は「音声 → 文字 → 回答文 → 音声」という 3 段変換ではなく、音声を直接入力・出力する
native audio モデルを使います。そのため応答が速く、言い直しや相づちに自然に反応します。画面の字幕は補助的な別サービスで、AI の理解そのものは record_understanding ツールで AI 自身が書き出したものを表示しています。§ 04 · 判断
AI Agent はどう判断しているのか
AI は自由に振る舞うのではなく、「必ずこの順番で、これらの道具を使う」という運用ルール (システム指示) の中で動きます。判断の根拠はナレッジ記事に書かれた推奨アクションで、AI が勝手に手順や番号を作ることは禁止しています。
自動回答で解決パスワードリセット、Teams の通知設定、OfficeHub の基本操作など、ナレッジに手順がある定型問い合わせ。チケットを起票してクローズ。
L1 · Fabbi Da Nang手順を試しても解決しない、ナレッジに該当なし、端末個別の設定など。24 時間体制で 15 分以内に折り返し。
L2 · Customer 専門担当複数ユーザーに影響する障害、不審メール開封・乗っ取りなどセキュリティ事案 (priority=urgent)、契約・請求は営業へ翌営業日。
AI が守っている「絶対ルール」
| ルール | なぜ必要か |
|---|---|
| 回答の前に必ずナレッジを検索する | AI の記憶ではなく、Customer が管理する情報だけを根拠にするため |
| チケット番号はシステムが発行したものだけを読み上げる | AI が番号を「それらしく」作ってしまう事故を防ぐため |
| 確認は 1 問まで、1 回の発話は 3 文以内 | 電話らしいテンポを保ち、お客様を待たせないため |
| 分からないことは正直に伝えてエスカレーション | 無理に解決しようとして誤案内するより、人に渡す方が安全 |
| 聞き取った内容を毎回記録する | 「AI が何を理解したか」を画面と記録で検証できるようにするため |
ここが重要: ナレッジ記事を増やす・直すだけで AI の対応範囲が広がります。プログラムの変更は不要で、Customer 側で運用しながら育てられます。
§ 05 · Fabbi の研究
「話せる AI コールセンター」の 4 つの作り方
Fabbi は 2026 年に入ってから、音声 AI エージェントの主要な実装方式を実際に構築・検証してきました。方式の違いは、突き詰めると一つの問いに集約されます。お客様の声を 1 つの AI モデルに直接入れるのか、それとも「聞く → 考える → 話す」の 3 段階に分けて処理するのか。この選択が、会話の自然さ・対応言語・業務連携・運用コストのすべてを決めます。
結論を先に: Customer の 24/7 一次受付には、方式 A (クラウドのネイティブ音声モデル) が現時点で最もバランスが良く、本デモもこの方式です。方式 C (STT + LLM + TTS の組み合わせ) は、音声データを特定ベンダーに出せない場合や日本語音声品質を最優先する場合の有力な代替案として Fabbi が実装済みです。方式 B (オープンモデル自社ホスト) は会話の自然さでは最高ですが英語のみ、方式 D (SaaS 型プラットフォーム) は最速で電話番号を立ち上げられる代わりにコストとデータの主導権を手放します。
図 2 · 4 つの作り方を同じ流れ (お客様 → 音声の入口 → AI の頭脳 → 業務ツール) で並べたもの。太枠が各方式の「頭脳」で、会話の自然さと業務連携の可否はここで決まる。
デモ画面で実際に話してみる →
方式 A · ネイティブ音声方式 B · 全二重 自社ホスト方式 C · STT+LLM+TTS / 業務ツール方式 D · SaaS 基盤 / 制約
方式 Aクラウドのネイティブ音声モデルGoogle Gemini Live · OpenAI Realtime · Amazon Nova Sonic
1 つのモデルが音声を直接聞き、直接話す。文字変換を介さないため声の調子やためらいまで理解し、同時に業務ツール (契約照会・ナレッジ・チケット) を呼び出せる。
- 強み: 日・英・越が最初から使える、音声サーバー不要で運用が最軽量、ツール連携が標準
- 弱み: 発話の切れ目を待つため 0.4〜0.9 秒の「間」が出る、音声データがクラウド事業者を経由する
- Fabbi の実績: 本デモ (このページのシステム) を構築・公開中
方式 Bオープンモデルの自社ホスト (全二重)NVIDIA PersonaPlex · Kyutai Moshi
「話す番・聞く番」の概念が無く、人のように相づちを打ち、被せて話し、割り込みに 0.2 秒で反応する。モデルは自社 GPU 上で動き、音声データは社外に出ない。
- 強み: 会話の自然さは 4 方式で最高、データ主権を完全に確保
- 弱み: 現行版は英語のみ、業務ツール呼び出し機能が無い (通話後に文字起こしから処理)、GPU を常時稼働 (通話が無くても費用発生)
- Fabbi の実績: 技術評価済み。多言語版の登場を追跡中
方式 CSTT + LLM + TTS の組み合わせLiveKit Agents · Pipecat などのフレームワーク
音声認識 (STT)、思考 (LLM)、音声合成 (TTS) を別々の部品として組み合わせる。各部品を最適なベンダーから選び、いつでも差し替えられる。
- 強み: 日本語専用の高品質 STT / TTS を選べる、最も賢い LLM を使える、ベンダーに縛られない、電話回線 (SIP) 連携が標準
- 弱み: 3 段階の遅延が積み重なり 0.5〜0.9 秒、文字にした時点で声の調子が失われる、運用する部品が増える
- Fabbi の実績: 2026 年 4 月にこの方式の MVP を構築・稼働済み。同じ業務ツールとナレッジを流用可能
方式 DSaaS 型ボイスエージェント基盤Vapi · Retell · ElevenLabs Agents · Google CCAI
管理画面で STT / LLM / TTS をメニューから選び、プロンプトとナレッジを登録すれば電話番号付きで動く。業務連携は Webhook。
- 強み: 1〜2 日で実電話番号まで立ち上がる、録音・分析・有人転送が最初から揃う
- 弱み: 基盤利用料 + モデル料の二重課金で最も高い、プロンプト・ナレッジ・通話ログが基盤側に置かれる、深いカスタマイズが難しい
- Fabbi の見解: 短期トライアル向け。本番の中核には推奨しない
Customer の要件で採点する
上の 3 行は Customer / 一次受付の必須条件 (満たさなければ候補から外れる)、それ以下は方式の得手不得手です。
| 評価軸 | A · ネイティブ音声 | B · 全二重 自社ホスト | C · STT+LLM+TTS | D · SaaS 基盤 |
|---|---|---|---|---|
| 日本語 · ベトナム語 | 対応 本デモで稼働中 | 不可 現行版は英語のみ | 最良 日越専用エンジンを選択可 | 要確認 日本語は多い、越は基盤次第 |
| 業務ツール連携 (契約 · ナレッジ · チケット) | 対応 音声と並行して 6 ツール稼働中 | 不可 通話後の後処理のみ | 対応 LLM 標準のツール呼び出し | 対応 Webhook (基盤の制約あり) |
| 運用負荷 | 最軽量 サーバー不要 | 重い GPU 常時稼働 + 自社更新 | 中 エージェントサーバー + 3 ベンダー | 軽い 代わりに依存が強い |
| 会話の自然さ | 良: 声の調子を理解、ただし 0.4〜0.9 秒の間 | 最良: 被せ発話、0.2 秒で反応 | やや劣る: 声の調子が失われ、遅延が積む | C と同等 (選ぶエンジン次第) |
| 判断の賢さ | 音声モデルの性能に依存 | 7B 級で限定的、知識はプロンプト内 | 最良: 最強の LLM を選べる | 良: メニューから LLM 選択 |
| 電話回線 (実番号) | Twilio 等を組み合わせて構築 | A と同様 + 中継サーバー | 標準機能 (SIP) | 管理画面で番号購入 |
| データ主権 · ベンダー自由度 | 音声がクラウド事業者を経由 | 完全自社内 | 部品ごとに選択、囲い込み無し | プロンプト · ナレッジ · ログが基盤側 |
| 変動コスト | 通話分数に比例 (音声トークン) | GPU 時間課金 (通話ゼロでも発生) | 3 社請求、大量通話では A より安くなりやすい | 最も高い (基盤料 + モデル料) |
| Fabbi の実装状況 | 稼働中 本デモ | 技術評価のみ | MVP 稼働済 2026 年 4 月 | 未着手 (必要性低) |
数値の根拠: 方式 A の数値は本デモの実測と設定値。方式 B の反応速度はモデル提供元の公開仕様。方式 C の遅延は業界一般の経験値で、Customer 環境での実測ではありません。GPU 費用と基盤利用料は概算であり、正式見積ではありません。
§ 06 · 選び方
ユースケース別: どの課題にどの方式か
「一つを選んで他を捨てる」必要はありません。Fabbi が推奨するのは 主軸を 1 つ、代替を 1 つ、実験枠を 1 つ 持つ構成です。業務ツールとナレッジは方式に依存しない共通部品として作るため、音声の層だけを後から差し替えられます。
| お客様の状況 · 解きたい課題 | 推奨方式 | 理由と留意点 |
|---|---|---|
| 24 時間 365 日の一次受付を AI に任せ、契約確認 · ナレッジ回答 · チケット起票まで自動化したい (Customer の AI First Support) | A ネイティブ音声 | 日英越 + ツール連携 + 最軽量運用を今すぐ満たす唯一の方式。本デモがそのまま PoC の土台になる。自然さは切れ目待ち時間の調整でさらに改善可能。 |
| 音声データを特定クラウド事業者に出せない (社内規程 · 顧客契約 · 金融 / 医療系の要件) | C STT+LLM+TTS 完全オンプレなら B (英語限定) | 各部品を国内 / 自社指定ベンダーから選べる。日本語対応が必須なら B は現時点で不可。 |
| 日本語の音声品質を最優先 (ブランドボイス · IVR 置き換え · 高齢の利用者が多い) | C STT+LLM+TTS | 日本語専用の高品質 TTS / STT を選択できる。遅延 0.5〜0.9 秒は許容範囲か PoC で確認。 |
| 複雑な判断や長い規約の参照が中心 (契約 · 請求 · 法務寄りの問い合わせ) | C 最上位 LLM または A + 即エスカレーション | 思考部分に最も賢い LLM を使える。一次受付は A のまま、複雑案件だけ人 (L2 / 営業) に渡す設計でも十分な場合が多い。 |
| 数日以内に実電話番号でトライアルしたい、社内デモや効果測定が目的 | D SaaS 基盤 | 最速。ただしコストとデータ主権を手放すため、本番の中核には移行計画を前提に。 |
| 英語のみで、人と区別がつかない自然さを見せたい (海外拠点 · 営業デモ) | B 全二重 自社ホスト | 「未来の会話体験」を示す実験枠。業務連携は後処理になるため本番運用には不向き。多言語版が出れば主軸候補に昇格。 |
| 通話量が非常に多く、分単位のコストを最優先したい | C STT+LLM+TTS | 部品ごとに安価なベンダーを選べ、大量通話では A より有利になりやすい。まずは A で実通話量を把握してから判断。 |
| 既存の電話回線 · PBX に組み込むことが必須 | A + 音声ゲートウェイ または C (SIP 標準) | A は Twilio 等のゲートウェイを追加、C はフレームワークが SIP を標準搭載。どちらも Phase 2 で対応可能。 |
Customer への Fabbi の提案
主軸 · 方式 A本デモの Gemini Live を本番仕様へ。切れ目待ち時間の短縮と日本語向け音声の最適化で自然さを向上。電話回線は音声ゲートウェイで接続。
代替 · 方式 CFabbi の MVP を Customer 向けに再構成。データ要件や日本語音声品質で A が不適となった顧客に提供。ツール · ナレッジは主軸と共通。
実験枠 · 方式 B英語圏向けデモとして全二重体験を提示。多言語対応の進展を Fabbi が継続監視し、日本語対応時点で Customer に再提案。
ここが重要: どの方式でも「契約照会 · ナレッジ検索 · チケット起票 · エスカレーション」の業務ロジックは同じものを使います。方式の選択は音声の入口の選択であり、Customer の業務資産 (ナレッジ · 判断ルール) は方式を越えて蓄積されます。
§ 07 · 導入
導入ステップ (提案)
Phase 1 · PoC今日のデモ → 数週間
- Customer の実ナレッジ (FAQ / 手順書) を 20〜50 件投入
- Web ブラウザ経由で社内評価
- 聞き取り精度・判断精度を実通話ログで確認
Phase 2 · パイロット限定顧客 · 営業時間外
- 電話回線 (PSTN / SIP) 接続
- チケットシステム・CRM と本接続
- L1 Fabbi Da Nang との引き継ぎ運用を確立
Phase 3 · 本番 24/7全顧客 · 全時間帯
- KPI ダッシュボードで AI 解決率を継続監視
- ナレッジ改善サイクル (未解決案件 → 記事追加)
- 多言語 (英語 · ベトナム語) 対応の本格運用
本番接続で必要になるもの: CRM / チケットシステムの API (参照 + 起票)、ナレッジのエクスポート (テキストで可)、電話回線側の音声ゲートウェイ、通話録音とログの保管ポリシー。AI 部分は Google Cloud (Gemini) 上で稼働し、データは Customer 指定の環境に保存する構成が可能です。
§ 08 · 数字
数字で見る現在のデモ
3対応言語 (日 · 英 · 越)
14ナレッジ記事 (デモ用)
15 分L1 折り返し目標
30 分L2 折り返し目標
デモ画面右側の KPI (受付件数・自動解決・エスカレーション・AI 解決率) は、通話のたびにチケットから自動集計されます。本番ではこの数字が「AI がどれだけ一次対応を吸収したか」の月次指標になります。
数字の読み方: AI 解決率は「自動回答でクローズしたチケット ÷ 受付件数」です。ナレッジが充実するほど上がる指標で、導入初期は低く、運用で育てるものです。目標値は PoC の実ログを見てから一緒に決めます。
§ 09 · 限界
正直な限界と対策
- 聞き取り精度: 短い一言や強い訛りでは言語判定を誤ることがあります。対策として日本語固定モード、フルセンテンスでの発話案内、AI 自身による「聞き取り内容」の表示を入れています。
- 接続の安定性: AI 側のセッションがまれに切れることがあります。デモでは自動再接続 (最大 3 回) と会話履歴の引き継ぎで対応しています。
- 電話回線はまだ: 現在はブラウザ経由です。実際の電話番号での受付は Phase 2 で接続します。
- ナレッジ依存: AI はナレッジに無いことを答えません (答えさせません)。裏を返すと、ナレッジの品質がそのままサービス品質になります。
- これが最終形か: いいえ。まだ PoC です。実通話ログを見ながら、判断ルールとナレッジを Customer と一緒に育てていく前提です。