DGX Spark(GB10)を使った顔と声で覚えるローカルAI受付デモが、かなり実用っぽくなってきた
はじめに
ローカルAIデジタルヒューマンの開発を続けています。
最初は、ローカルLLMに音声で話しかけて、アバターが返事をするくらいの仕組みでした。
そこから少しずつ、音声入力、音声合成、カメラ、顔認証、人物別メモリ、受付ナレッジ、取り次ぎ通知などを足してきました。
そして今回、ようやく「受付デモ」として人に見せられる段階に近づいてきました。
今の構成では、GB10 1台とPCまたはノートPCを使って、ローカル環境だけで受付デジタルヒューマンを動かせます。
クラウドに音声や映像や顔情報を出さずに、来客を認識し、会話し、名前を覚え、次回以降はその人として応対する。
まだ製品版ではありませんが、デモとしてはかなり面白いところまで来たと思っています。
何ができるようになったのか
今のVITA Receptionでできることは、だいたい以下のような流れです。
人が来る。
カメラで検知する。
デジタルヒューマンが挨拶する。
顔で誰かを確認する。
会話を始める。
未登録なら名前を聞く。
名乗ったら、その場で顔と声を登録する。
次回以降は、その人として応対する。
単にAIと会話するだけではありません。
「誰が来たのか」を扱います。
「その人と会話が続いているのか」を扱います。
「前に来た人なのか」を扱います。
「その人ごとの履歴やメモ」を分けて扱います。
ここが今回のポイントです。
今までは、AIアバターやAIチャットに近いものでした。
しかし、今はかなり「受付システム」に寄ってきました。
顔だけでなく、声でも会話をつなぐ
今回かなり大きかったのが、声紋による話者継続判定です。
最初に顔で人物を確認します。
たとえば、カメラの前に来た人を顔認証して、「この人は登録済みのAさん」と判断します。
その後、会話が続いている間は、毎回顔認証を走らせる必要はありません。
人間でも、目の前の相手と話している間、毎回「この人は誰だろう」と顔認証しているわけではありません。
一度相手が分かったら、その後は声や会話の流れで「同じ人が話し続けている」と判断します。
VITAでも、それに近い形にしました。
音声ターンごとに声紋を取り、前回と同じ声かどうかを見ます。
同じ声なら、顔認証をスキップして、その人との会話として続けます。
声が変わったり、顔が見えなくなったり、誰か分からなくなった場合は、顔認証や声の照合に戻ります。
つまり、今の識別の流れはこうです。
声が同じなら、その人として会話を続ける。
声が変わったら、顔で確認する。
顔が見えなければ、声で控えめに推定する。
それでも分からなければ、デジタルヒューマン側から名前を聞く。
この流れが入ったことで、かなり人間っぽい受付に近づきました。
未登録でも、その場で覚える
受付デモとして重要なのは、事前登録なしでも動くことです。
あらかじめ管理画面で全員の顔を登録してください、という運用だと、少しデモっぽくなります。
そこで、未登録の人が来た場合は、会話の中で名前を聞きます。
「初めましてですよね。お名前を伺ってもよろしいですか？」
というように、デジタルヒューマン側から聞きます。
ユーザーが名前を答えると、その名前で顔と声を登録します。
この機能で事前の顔登録が不要になりました。
同時に、その人用のカルテも作ります。
これにより、次回以降は登録済みの来客として扱えます。
このあたりは、単なる音声AIではなく、受付らしい体験になってきた部分です。
人物ごとに記憶を分ける
もう一つ重要なのが、人物別メモリです。
受付では、会話履歴が混ざると危険です。
Aさんの話をBさんに出してはいけません。
そのため、VITAでは人物ごとにカルテと会話履歴を分けています。
登録済みの人であれば、その人の過去の会話やメモを使って応対できます。
逆に、誰か分からない場合は、安易に既存人物の履歴を使わないようにします。
ここは地味ですが、受付AIとしてはかなり重要です。
AIが賢く答えることよりも、誰の情報を使っているのかを間違えないことの方が重要な場面もあります。
レイテンシーも、かなり現実的になってきた
音声会話で気になるのは、やはり応答速度です。
現状では、話しかけてから「最初の声が返ってくるまで」が、体感でおおむね約2.5秒くらいです。
処理が全部終わるまでの合計時間ではなく、最初の一言が出始めるまでの時間、という意味です。
もちろん、内容やタイミングによって前後します。
ただ、ローカルでSTT、LLM、TTS、顔認証、声紋処理まで含めてこの体感なら、デモとしてはかなり戦えるレベルになってきました。
ざっくりした内訳は以下です。
音声認識は約0.5〜0.7秒。
声紋処理は約0.22秒。
顔認証は必要な時だけ約0.88秒（会話継続中はスキップ）。
LLMの応答生成は約2秒。
これを単純に足すと2.5秒には収まりません。実際、全部が終わるまでの合計はログで約3.6秒前後になることもあります。ただ、先頭の文ができた時点で順次音声合成して話し始めるので、ユーザーから見ると「返事が始まった」と感じるまでが約2.5秒、という体感になります。
ポイントは、全部が終わるまで待たないことです。裏側で処理が続いていても、ユーザーから見ると「返事が始まった」と感じられます。
受付デモでは、これはかなり大事です。完全な処理時間よりも、最初の反応が返ってくるまでの体感時間の方が印象を左右します。
ログの抜粋ですが、以下のような形で動作しております。
[21:38:59] [api_voice_chat] transcript='私の好きなものはラーメンです。'
[21:38:59] [voice] 同一話者継続 -> 田中太郎 (顔照合スキップ)
[21:38:59] [session] 声継続で維持 -> face:田中太郎
[21:38:59] [api_chat] user_id = local-dev auth_source = local-dev session_id = local-dev:face:田中太郎 mongo_history_messages = 10
[21:39:02] [latency] route=voice_chat stt=0.61 other=3.04 total=3.65s
[21:39:02] [api_tts] style = soft text = ラーメンがお好きなんですね。
styled_text = 🙂ラーメンがお好きなんですね。
[21:39:03] [latency] route=tts tts=1.60 other=0.00 total=1.60s
[21:39:03] INFO: 127.0.0.1:63553 - "POST /api/tts HTTP/1.1" 200 OK
[21:39:04] [api_tts] style = soft text = 承知いたしました。それでは、ソフトウェア開発とラーメンがお好きだという内容でお伝えしておきますね。
styled_text = 🙂承知いたしました。それでは、ソフトウェア開発とラーメンがお好きだという内容でお伝えしておきますね。
[21:39:06] [latency] route=tts tts=2.64 other=0.00 total=2.64sカメラVLMは2台目へ
視覚を使う場合は、2台目のGB10にカメラVLMを載せます。
カメラ側では、人がいるか、何が見えているか、といった情報を扱います。
ただし、受付としての基本機能はGB10 1台でも成立します。
2台目のGB10は、カメラや画面認識を強化するための拡張構成です。
「GB10を2台持ってこないと動かない」ではなく、「基本は1台、視覚を強くしたい時は2台目を足す」という形の設計としました。
視覚以外も機能を持たせるのに使えますが、コアなシステムは1台に押し込んだ形です。
ローカルで動く意味
このシステムの重要なポイントは、ローカルで完結していることです。
音声、映像、顔、声紋、会話履歴をクラウドに出さずに扱えますので、受付用途では、これはかなり大きいと思っています。
クラウドAIは便利です。
しかし、受付や社内空間では、映像や音声や顔情報を外に出しにくい場面があります。
また、常時待機させるAIは、クラウドだとコストや通信やポリシーの問題が出やすいです。
ローカルで動かせるなら、クラウド課金やトークン消費を気にせず、かなり自由に試せます。
もちろん、ローカルだから何でも解決するわけではありません。
運用、保守、アップデート、データ管理、セキュリティ設計は必要です。
それでも、「クラウドに出せないから試せない」で終わっていた領域に、ローカルAIで踏み込める可能性はあります。
これはAIアバターではなく、受付ワークフローになってきた
最初は、AIアバターに近いものでした。
話しかけると返事をして、アバターが動いて、音声で会話できる。
それだけでも面白いのですが、今は少し違います。
顔で誰かを確認する。
声で会話をつなぐ。
人物ごとに履歴を分ける。
分からなければ名前を聞く。
登録すれば次回から覚えている。
必要なら取り次ぎや伝言に回す。
ここまで来ると、アバターは表現手段で、本体が、ローカルAIによる受付ワークフローです。
ここが今回、自分の中ではかなり大きな変化です。
課題
もちろん、まだ完成ではありません。
処理中に無音が続くと、2秒でも長く感じます。
「はい、確認しますね」
「少しお待ちください」
「なるほど、確認します」
のような短い返答をうまく挟めると、体感はもっと良くなるはずです。
また、声紋は便利ですが、本人認証として過信するものではありません。
声は環境やマイクや話し方でブレます。
そのため、現時点では声だけで本人を確定するというより、顔を主、声を補助として使う方針です。顔で本人を確定し、声で会話継続を補助する。
この整理が現実的だと思っています。
まとめ
ローカルAI受付デジタルヒューマンは、かなり面白いところまで来ました。
今できることは、単なるAI会話ではありません。
来客を検知する。
挨拶する。
顔で覚える。
声で会話をつなぐ。
分からなければ名前を聞く。
顔と声を同時に登録する。
人物ごとに会話履歴とカルテを分ける。
必要なら取り次ぎや伝言に回す。
そして、これをローカル環境で動かします。
GB10 1台とPCまたはノートPCがあれば、基本的な受付デモは成立します。
視覚を強化したい場合や、他のLLMを利用するような追加機能は、2台目のGB10を追加します。
まだまだな部分はありますが、そろそろ他の人に見てもらって、実際にどこで、不具合を出すのかを確認する段階には来たと思います。
個人の実験として始めたものが、少しずつ「ローカルAI受付PoCキット」のような形になってきています。
次は、実際に人に触ってもらって、そこで出てきた問題を直せば、さらに実用に近づくはずです。
本日はここまで。
2026/06/14