問い合わせに自然な言葉で答えられても、本人確認や手続きの引き継ぎで止まってしまえば、顧客の用事は済みません。複数のAIエージェントがそれぞれ回答を返すだけでは、顧客や担当者が情報をつなぎ合わせる負担も残ります。企業の顧客対応に必要なのは、個々の回答の出来栄えに加えて、一連の業務を見通せる仕組みです。

コンタクトセンター向けのソフトウェアを提供するNiCEが発表した次世代のCognigyは、この運用上の課題に軸足を置いています。開発画面の刷新、構築や改善を支援するAI Assist、再利用できる「スキル」、会話の各段階を追跡する機能、音声から音声へ直接応答するモデルへの対応を組み合わせました。中心にあるのは、エージェントを作る作業から、継続して管理する仕事までを支える設計です。



NiCE Cognigyの製品マーケティング担当者、ニュー・ホー氏は、AIの能力と信頼性は必ずしも一致しないと説明しています。説明会で示された自律作業時間の指標にも、成功率50％という条件が付いていました。この数字を、そのまま企業の顧客対応で許容できる品質と受け取ることはできません。研究上の進歩と、本番業務で任せられる範囲には隔たりがあります。

記事の著者で調査会社ZK Researchのアナリスト、ゼウス・ケラバラ氏は、モデルの性能向上と低価格化が進むほど、価値はテスト、追跡、制御の仕組みへ移ると見ています。企業の選定でも、難しい質問に答えられるかだけでなく、判断に迷ったときに止まれるか、担当者へ渡せるか、その経緯を説明できるかが評価の焦点になるでしょう。

刷新されたAgentic Experience Studioでは、モデルをあらかじめ利用できる状態にし、少ない操作でエージェントを立ち上げられるようにしています。高度な設定は詳細項目にまとめ、エージェントへの基本指示に当たるシステムプロンプトにもアクセスできます。入口を簡潔にしながら、技術者が調整できる余地も残す構成です。

この変更には、利用者層を広げる狙いがあります。Cognigyは、ルフトハンザ航空、メルセデス・ベンツ、国際物流のDHLといった企業の複雑な導入に対応してきました。ただし、製品管理ディレクターのクレマン・ブティエ氏は、設定の選択肢の多さが利用開始の障壁にもなっていたと説明しています。柔軟性があっても、専門家しか扱えなければ、現場への展開には時間がかかります。



AI Assistは、特に小規模な事業者やコンタクトセンターの管理者、チームリーダーを支援する位置付けです。説明会のデモでは、エージェントの構築、テスト、発見した問題の修正を行い、メッセージアプリのWhatsAppへ展開しました。また、指示やツールをまとめたスキルを再利用する仕組みは、似た処理をエージェントごとに作り直す手間を減らす方向の機能です。

NiCEにとっては、コンタクトセンター基盤CXoneの既存顧客へCognigyを広げることが事業上の課題になります。利用企業側から見ると、作成の容易さには管理対象の増加が伴います。部門ごとに似たエージェントが生まれ、指示や権限が異なれば、顧客への対応もばらつきかねません。

そのため、導入時には開発時間だけを成果指標にしない方がよいでしょう。共通スキルの更新担当、公開前の確認者、本番稼働後の責任者まで決めておけば、現場が改善に参加しやすくなります。作る人を増やす施策と、運用責任を明確にする施策を一緒に進めることが必要です。

ブティエ氏によると、顧客の多くが採用しているのは、既存の処理と自律型AIを組み合わせるハイブリッド方式です。全面的に自律化した運用は、まだ普及の初期段階にあると説明しています。顧客対応のすべてを一度にAIへ渡すよりも、任せる範囲を確認しながら広げたいという企業の事情がうかがえます。

ここでいう既存の処理には、利用者の発言から意図を分類する自然言語理解の仕組みや、条件に従って順番に進める業務フローが含まれます。Cognigyでは、エージェントが全体の進行役となり、既存フローをツールとして呼び出せます。反対に、フローをエージェントの前段へ置き、カード番号などの個人情報を処理してからモデルへ渡す構成も可能です。



この組み合わせを理解する鍵は、会話の柔軟さと、業務手順の厳密さを分けて考えることです。顧客の曖昧な説明を整理する場面では、言語モデルの推論が役立つでしょう。支払いや本人確認のように、条件と順序を明確に保ちたい場面では、決められた手順による制御が適しています。これは導入時に検討すべき役割分担の例であり、個々の業務に応じた設計が必要です。

NiCEは今回の更新を、既存環境の置き換えではなく発展として位置付けています。稼働中の構成やAPI、外部システムとの接続を引き続き利用できると説明しており、企業はこれまでの実装を前提に段階的な導入を検討できます。APIは、システム同士がデータや処理をやり取りするための接続口です。

日本企業でも、問い合わせの受付から完了までを一つの図にし、AIが判断する箇所と、所定の手順に戻す箇所を明記すると議論が具体的になります。「自動化率をどこまで上げるか」だけでは、その境界は決まりません。誰が何を判断し、どの条件で人へ引き継ぐのかを先に定めることが、段階的な拡張の土台になります。

顧客への回答が不適切だったとき、最終的な文章だけを見ても、原因を絞り込めるとは限りません。指示の読み込み、外部ツールの実行、業務フローへの引き渡しなど、途中の処理を確認する必要があります。こうした内部の動きを把握できる性質が、オブザーバビリティ、つまり観測可能性です。

Cognigyの新しい追跡機能では、会話の各ターンについて、読み込んだスキル、呼び出したツールとその引数、フローへ処理を渡した時点を確認できます。引数とは、ツールへ渡す検索条件や処理対象などの情報です。回答の正誤だけでなく、そこに至る経路を見られるため、指示の問題なのか、接続先とのやり取りの問題なのかを調べる手掛かりになります。



Simulatorは最大10種類の構成案を比較するテストに対応しました。仮想の顧客を使ってエージェントを試し、別の言語モデルを評価役として用いるLLM-as-judgeの方式を採用しています。説明会では、同じエージェントを二つのモデルで動かし、一方の方が速く、消費するトークンも少ない結果が紹介されました。トークンは、モデルが文章などを処理する際の単位です。

この結果は、特定のモデルがあらゆる業務で優れることを意味しません。示しているのは、自社の条件で比較すれば、性能と費用の関係を検討しやすくなるという点です。ブランド名や一度の実演の印象だけでは、継続運用に向いた構成は決めにくいでしょう。

企業が評価する際には、応答速度や消費量に加え、会話を解決できたか、人への引き継ぎが適切だったかも確認したいところです。AIによる採点にも判断の偏りや見落としはあり得るため、重要なケースでは担当者による確認を組み合わせる考え方が妥当です。追跡記録で原因を調べ、同じ条件のテストで修正効果を確かめる循環を作れば、改善を担当者の勘だけに頼らず進められます。

今回の更新では、音声を直接入力し、音声で応答するvoice-to-voiceモデルへの対応も加わりました。音声を文字に変換し、回答文を作ってから読み上げる方式と比べ、会話の自然さを重視した選択肢です。ブティエ氏は、購入を検討する企業が従来型の構成も受け入れつつ、直接音声を扱うモデルの聞こえ方を評価していると説明しています。

デモでは、エージェントが別のモデルへツールの呼び出しを任せながら、会話を続ける様子が示されました。顧客の体験としては、背後の処理と対話をどう両立させるかが焦点になります。ただし、自然な受け答えと手続きの正確さは別々に確認する必要があります。声の印象がよくても、必要な処理が完了しているかまで検証しなければなりません。



企業の窓口に接続する相手も、人間だけとは限らなくなります。Cognigyは、AIと外部ツールなどを接続するための仕組みであるModel Context Protocol、略称MCPのクライアントとサーバーの両方に対応し、エージェント同士の接続も支援しています。説明会では、Microsoftのツールで構築したエージェントとCognigyを接続する顧客の例が紹介されました。

NiCEはMetaおよび対話型AIを手掛けるSierraと、Personal Agent Protocolも共同開発しています。これはまだ稼働していない取り組みです。NiCEが描くのは、消費者の個人AIが企業へ問い合わせる際に、Cognigyを認証の入口として利用する構想になります。

もっとも、その役割を担えるかは、企業が個人AIからの接続をどこへ集約するかに左右されます。ウェブサイトやAPIを通じた経路も考えられるためです。利用企業にとって先に検討できるのは、受け入れる個人AIの条件、本人から委任された権限の確認、実行を認める操作の範囲でしょう。会話が成立するだけでは、本人の代わりに手続きを進めてよい根拠にはなりません。

Cognigyでは、標準の音声認識、音声合成、大規模言語モデルの費用が、会話単位の料金に含まれるようになりました。Deepgram、ElevenLabs、Anthropicのプレミアムモデルは、追加の選択肢として利用でき、使用量に応じて課金されます。選択できるモデルが増えても、企業が比較したいのは、最終的に顧客の用事を解決するまでの費用です。

その費用には、安全のための制御も関わります。ガードレールとは、回答や実行内容を制限・確認する仕組みです。ブティエ氏は、追加するほどトークンの消費と遅延が増える点を指摘しています。制御を多く積めば無条件によいとは限らず、リスクの高い場面に必要な確認を配置する設計が求められます。何を防ぐための確認なのかを明確にすれば、費用や待ち時間との関係も説明しやすくなるでしょう。



責任の分担にも注意が必要です。ブティエ氏は、NiCEがツールと基盤を提供しても、顧客企業が組み込む内容を完全には管理できないと説明しています。利用する地域や業務に応じて、AIによる対応の通知、人への引き継ぎ、データの扱いなどを企業側で設計する必要があります。製品に制御機能が備わっていることと、自社の運用条件を満たしていることは、別々に確認すべき事項です。

今回の発表から読み取れるのは、エージェントを増やす前に、運用の単位を決める必要性です。どの会話を成功とみなし、誰が追跡記録を確認し、問題があればどの条件で停止・修正するのか。その合意があってこそ、作成支援やシミュレーションの機能を日常の改善につなげられます。

導入を検討する企業は、問い合わせ業務を一つ選び、完了条件、AIへ任せる範囲、人へ戻す条件、責任者を一枚にまとめてみるとよいでしょう。その業務を対象に、品質、処理時間、解決した会話当たりの費用を比較すれば、展開するかどうかを具体的に判断できます。Cognigyの新機能を評価する出発点も、自社が説明責任を持って任せられる業務を定めることにあります。