LLMを導入しても、それだけで業務システムが完成するわけではありません。業務AIには、会話だけでなく、業務データとの照合や処理順序の制御、外部システムとの連携が必要です。弊社では、NVIDIA Blueprintsの1つである「Tokkio NVIDIA AI Blueprint (以下、Tokkio)」を活用し、AI受付アバター「Virtual Concierge」を開発・検証しています。本記事では、そのPoCを通じて見えてきた、LLMを業務システムとして成立させるための3つの設計ポイントを紹介します。

　なお、Virtual Conciergeは現在PoC段階にあり、本記事では実運用の成果ではなく、開発・検証を通じて得られた構成上の工夫や課題を共有します。

1. なぜTokkioの基本構成だけでは業務システムにならないのか

　Virtual Conciergeは、来訪者と音声で会話し、受付業務を支援するAIアバターです。

　システムは、主に次の技術を組み合わせて動きます。

• 音声認識（ASR）：人が話した言葉を文字に変換する
• LLM：発言の意味を理解し、回答や次の処理を考える
• 音声合成（TTS）：LLM
  がつくった回答を音声に変換する
• アバター表示：音声に合わせて表情や口の動きを生成する
• 業務システムとの連携：担当者や予定を確認し、通知する

　開発のベースには、対話型AIアバター向けのリファレンス実装であるTokkioを活用しました。

　Tokkioには、人の声を聞き取り、AIが回答を考え、その回答を音声とアバターで表現するための基本的な仕組みが用意されています。発話に合わせてアバターの表情や口元を動かせるため、対話型AIアバターをゼロから開発するよりも効率よく構築できます。一方で、Tokkioの基本構成だけでは、受付業務に必要な処理をすべて行うことはできませんでした。

　受付業務では、来訪者と会話するだけでなく、聞き取った担当者名を社内データと照合し、面会予定を確認したうえで通知する必要があります。

たとえば、来訪者が「田中さんに会いに来ました」と話した場合、システムには次の処理が求められます。

1. 使用する言語を確認
2. 「田中さん」を聞き取り、検索する
3. 「田中さん」という担当者候補を確認する
4. 「田中さん」の予定情報を確認する
5. 「田中さん」へ来訪を通知する

※担当者や予定を確認できない場合は、来訪者に聞き返す

※聞き返しても確認できない場合は、総務へ通知する

　LLMは、来訪者の発言を理解し、自然な文章で回答することを得意としています。しかし受付業務では、「どの順序で処理するか」「どの条件で次に進むか」まで正しく管理する必要があります。

　そこでVirtual Conciergeでは、Tokkioを基盤に、業務データの参照、処理順序の制御、外部ツールとの連携を追加しました。

2. Virtual Conciergeで追加・変更した5つの領域

　Virtual Conciergeでは、TokkioのBlueprintをそのまま使うのではなく、受付業務に必要な要件に合わせ、主に5つの領域を変更・追加しました。

　主な変更点は、次の5つです。

　重要なのは、AIモデルを差し替えるだけでは業務は成立しないという点です。来訪者から聞き取った情報をどのデータと照合するのか、どのタイミングで外部ツールを呼び出すのか、その結果をもとに何を案内するのかまで、システム全体を設計する必要があります。

3. 開発・検証で分かった3つの設計ポイント

3-1. LLMと業務フロー制御の役割を分ける

　1つ目のポイントは、LLMに業務の進行を任せすぎないことです。
　通常のチャットであれば、利用者が質問し、LLMが回答するだけでも成立します。一方で受付業務では、担当者の名前を確認し、担当者候補を特定し、予定情報を確認した上で、その後に通知するといった、決められた順序に沿って処理する必要があります。

　特に今回の検証では、データの安全性や運用上の要件から、ローカル環境で動作するLLMを採用しました。一方、ハードウェアなどの制約により利用できるモデルの規模には限りがあり、高性能なクラウドLLMと比べて、複雑な指示の理解や処理順序の安定性に差が見られました。そのため、プロンプトだけで業務フローを制御しようとすると、想定しない順序で処理が進んでしまう可能性があります。

　例えば、本来は担当者確認の段階にいるにもかかわらず、予定確認や案内へ進んでしまうといったケースです。そこでVirtual Conciergeでは、自然な会話の発話内容の理解はLLMに任せつつ、業務上の進行管理はシステム側で制御する構成としました。

　受付業務を、たとえば次のような状態に分けて管理します。

1. 使用する言語を確認する
2. 担当者名を聞き取り、検索する
3. 担当者候補を確認する
4. 予定情報を確認する

　※担当者を特定できない場合は、再度来訪者へ確認する、または総務部へ引き継ぐ。

　状態ごとに実行できる処理を制限することで、LLMの出力に多少の揺らぎがあっても、想定外の処理へ進むリスクを抑えられます。

　今回の検証から、決められた順序やルールが求められる業務では、LLMに会話を任せつつ、必要な部分はシステム側で管理することが重要だと分かりました。

3-2. AIの出力を、そのまま業務上の事実として扱わない

　2つ目のポイントは、AIの出力だけで業務判断を確定しないことです。
　受付業務で特に難しさが現れたのが、担当者の特定と予定情報の照合です。Virtual Conciergeでは、来訪者から担当者名を聞き取り、必要に応じて部署名なども確認します。しかし、人名の音声認識は周囲の雑音や話し方の影響を受けやすく、一度で正しく取得できるとは限りません。似た名前の担当者がいる場合や、音声認識された表記と予定情報の表記が一致しない場合もあります。そのため、音声認識結果だけで担当者を決定するのではなく、担当者情報や予定情報と照合しながら候補を絞り込みます。

　重要なのは、音声を正しく文字へ変換できるかだけではありません。AIが出力した情報を業務データと照合し、最終的に正しい業務判断につなげられるかという視点が必要です。

　今回の検証から、ASRの認識結果をそのまま正解として扱うのではなく、業務データと照合しながら、正しい担当者や予定を特定する仕組みが重要だと分かりました。

3-3. AI単体ではなく業務全体で評価する

　3つ目のポイントは、AIやツールを個別に評価するだけでなく、業務シナリオ全体で評価することです。

　Virtual Conciergeでは、主に次の要素が連携して動きます。

• ASRが来訪者の音声を文字に変換する
• LLMが発言内容を理解する
• 担当者情報や予定情報を参照するツールを呼び出す
• システムが次に実行する処理を判断する

　それぞれの技術は、単体でも評価できます。例えば、ASRであれば認識精度、LLMであれば回答品質や業務ルールの遵守、ツール連携であれば適切なタイミングで正しいツールを呼び出せているかを確認できます。しかし、実際の受付業務では、これらが連続した一つのシステムとして動作します。ASRの出力はLLMの入力となり、LLMの判断がツール呼び出しにつながり、その結果をもとに次の案内が決まります。そのため、一つの小さな誤りが後続の処理に影響を与える可能性があります。例えば、LLM単体では正しく判断できていても、実際の運用ではASRの誤認識を含む入力が与えられます。その結果、担当者の候補選択やツール呼び出しが変わり、最終的な案内内容に影響することがあります。

　また、各コンポーネントを個別に評価したときは期待通りに動作していても、システムとして接続すると毎回同じ結果になるとは限りません。入力のわずかな違いやAIの出力の揺らぎによって、後続の処理結果が変化するためです。そのため、各モデルの性能だけでなく、「受付業務を最初から最後まで正しく完了できたか」というシナリオ全体で評価する必要があります。問題が発生した場合は、ASR、LLM、ツール呼び出し、外部システム、業務フローのどこに原因があるのかを切り分けながら調整を進めます。

　Virtual Conciergeでは、シナリオ単位での評価と、各構成要素のログ分析を繰り返しながら、システム全体として安定した結果が得られるようチューニングを行いました。この検証から、AIやツールを個別に評価するだけでなく、業務シナリオ全体で成功・失敗を確認し、期待する結果に近づくよう継続的に調整することが重要だと分かりました。

4. まとめ

　AI受付アバター「Virtual Concierge」の開発・検証を通じて、業務AIを成立させるためには、主に3つの設計ポイントが重要だと分かりました。

• LLMに任せる範囲を決め、業務の進行はシステム側で制御する
• AIの出力をそのまま正解とせず、業務データと照合する
• AI単体ではなく、業務シナリオ全体で評価する

　LLMは、自然な会話や発言内容の理解に優れています。しかし、LLMそのものが業務システムになるわけではありません。業務AIで重要なのは、どのLLMを使うかだけではなく、LLMに何を任せ、何をシステム側で保証するのかを設計することです。言い換えれば、LLMに会話を任せ、業務の正しさはシステムで保証することが重要です。

　Virtual Conciergeでは、引き続きPoCを通じて、業務フローの制御、担当者・予定の特定、システム全体の評価方法について検証を進めていきます。

（執筆者：Assawamanachai Napat、藤井 浩　編集者：安田 朋史）