Sushil Kumar、Cyara CEO – インタビューシリーズ

Sushil Kumar、Cyara の CEO は、人工知能、DevOps、クラウドインフラ、プロダクト戦略、ソフトウェアテストの分野で 25 年以上にわたるリーダーシップを持つ、経験豊富なエンタープライズソフトウェアの幹部兼起業家です。2025 年 12 月に Cyara の CEO に就任する前は、RelicX.ai の共同創業者兼 CEO を務め、生成 AI を活用したインテントベースのテスト自動化プラットフォームを構築し、同プラットフォームは Harness に買収されました。その後、RelicX の技術を Harness に統合し、AI テスト自動化戦略の策定に貢献しました。キャリア初期には、Broadcom で DevOps 部門のゼネラルマネージャー、CA Technologies でプロダクト部門のシニアバイスプレジデントを歴任し、Oracle では 16 年以上にわたりシニアプロダクトリーダーとして主要なエンタープライズソフトウェア事業の拡大に携わりました。これらの役割を通じて、AI、クラウド、DevOps、オートメーションプラットフォームの構築とスケーリングに注力してきました。Cyara への就任は、同社の AI 搭載顧客体験保証機能とグローバル展開の拡大に焦点を当てています。

Cyara は、音声、デジタル、メッセージング、会話型 AI チャネルを横断した顧客インタラクションのテスト、モニタリング、検証を支援する顧客体験保証企業です。同社の Cyara Agentic Platform は、AI 主導の顧客体験がもたらす課題、特に非決定論的 AI エージェントのテスト、幻覚や行動ドリフトの検出、コンプライアンスの検証、プロダクションシステムの監視、エンドツーエンドの顧客ジャーニーの評価に対応するよう設計されています。このプラットフォームは、AI エージェントテスト、プロダクションモニタリング、音声・通信保証、デジタルチャネルテスト、CX 可視化を組み合わせ、年間 3.5 億件以上の顧客ジャーニーを、140 カ国以上に及ぶグローバルネットワークでサポートしています。企業が顧客向けワークフローにますます自律的な AI エージェントを導入する中、Cyara はこれらのシステムが導入前後に信頼性・安全性・一貫性を保って動作するかを評価する保証層として自社技術を位置付けています。

Oracle や CA/Broadcom から Relicx を創業し、現在は Cyara を率いるまで、エンタープライズソフトウェアの構築とスケーリングに長年携わってきました。その経験は、AI エージェントを従来のソフトウェアよりも労働力の一員として管理すべきだという見解にどのように影響しましたか？

私はキャリアの大半をエンタープライズソフトウェアの構築とスケーリングに費やしてきましたが、そこで培った規律は決定論的システムに関するものでした。ソフトウェアが何をすべきかは明確です。その期待に照らして検証します。ソフトウェアが故障すると、エラーや取引失敗、アラートといった形で通知されます。

AI エージェントはそのようには機能しません。非決定論的であるため、同じ入力でも異なる経路をたどることがあります。さらに重要なのは、企業を代表して行動できる点です。返金やポリシー、約束といったコミットメントを行いますが、これらのいずれかが誤っていてもシステムは故障しません。誤った回答が正しい回答とまったく同じように見えるのです。取引は成功し、ダッシュボードは緑のままで、顧客は会社が合意していないものを手にしてしまいます。

ソフトウェアが意思決定やコミットメントを行い、かつ誤っていても通知しないようになると、別の運用モデルが必要になります。

ここで労働力との比較が意味を持ちます。従業員をすべての判断をスクリプトで管理することはありません。役割を与え、それに伴う権限を設定し、実績に応じて権限を拡大します。エージェントも同様の構造の下で同じように振る舞います。

私の見解では、自治性は導入の判断ではなく、一連の昇格プロセスです。エージェントは、仕事を遂行でき、権限の範囲内で動き、支援が必要なときにそれを認識できることを示すことで、段階的に昇格します。

AI エージェントに対する「HR ライク」な運用モデルは実際に企業内でどのような形を取るべきか、また企業はまずどの要素を整備すべきでしょうか？

まず仕事から始めます。エージェントは本番環境に入る前に、ほぼ職務記述書に相当するものを持つべきです。達成すべき目標は何か、権威ある情報は何か、利用できる顧客データは何か、単独でどの判断を下せるか、責任の範囲はどこまでか。これらを段落で記述できない企業は、エージェントを役割に就かせる準備ができていません。デモ用の状態です。

その役割から導かれる四つの要素があり、順序は重要です。①ローンチ前のエビデンス：実環境に近い条件でエージェントが仕事を遂行できることを証明すること。②稼働中の監視：エージェントが実際に何をしたかを把握し、システムが応答したかだけでなく確認すること。③昇格ゲート：エビデンスが裏付けられた時点でのみ権限を拡大し、事前に与えないこと。④エンジニアではなくビジネス部門のオーナーを配置し、エージェントが許可された行動に対して責任を持たせること。

順序を誤ると他の要素は成立しません。責任が曖昧だと優れたパフォーマンスも失敗も証明できません。まず役割を定め、次にエビデンスを示す必要があります。

AI エージェントに特定の役割が割り当てられた場合、顧客や重要システムとやり取りさせる前に、組織はその責任、権限、境界をどのように定義すべきでしょうか？

役割はエージェントの目的を示します。権限はエージェントがアクセスできる範囲を示します。これは別々の議論であり、企業は通常、前者だけを設定します。

3つの点を明確にしてください。エージェントが触れられるシステムとデータ、そしてその方向性です。顧客レコードを読むことと変更することは同じ権限ではありません。エージェントが単独で約束できること、つまり返金、クレジット、ポリシー例外など、金銭と責任が伴う領域です。そして、事前に名前を挙げられるケースと、エージェントが自らの権限を超えたことを示すシグナルの両方に基づくハンドオフを促す要因です。

これらは技術チームに任せるべき決定ではありません。リスクは企業が負うものです。顧客体験とコンプライアンスリスクを所有する人々が、どこに線を引くかについて発言権を持ち、通常は最後に相談されます。

次に、エージェントがその範囲内に留まっていることを証明しなければなりません。目標はすべてのミスを排除することではありません。ミスは起こります。重要なのは、エージェントが自らの境界を理解し、止めるべき時を知り、顧客ジャーニーの他の部分に余計な影響を与えずに任務を遂行できるかどうかです。

自律性は最初から与えられるのではなく、実績に基づいて獲得すべきだと主張しています。企業がエージェントに独立して行動範囲を拡大させる前に、どのような実証が必要でしょうか？

現在、AIエージェントを構築することは容易です。難しいのは、エージェントが自律性に値することを証明することです。

エージェントが単独でできることを拡大する前に、企業はエージェントが割り当てられた業務を一貫して実行し、境界内に留まっているという証拠が必要です。つまり、期待した状況への対応だけでなく、予期しなかった状況への対応も含まれます。エージェントは制御された条件下では優秀に見えても、コンテキストや周辺システムが変わると異なる振る舞いをすることがあります。

顧客は単純な請求質問から始めても、支払いが失敗すると苛立ち始めます。エージェントはその変化をリアルタイムで認識し、検証されたフローを続けるのではなく、方針を転換しなければなりません。

権限が拡大する前に、3つの条件が満たされるべきです。エージェントはクリーンな環境だけでなく実際の条件下でも業務を遂行できること。自らのコンピテンシーの限界を把握し、その限界で止まること。そして、両者をオンデマンドで証明できる証拠があることです。

証明のレベルは自律性のレベルに見合う必要があります。小さな判断には軽い証拠で構いませんが、支払いシステムへのアクセスやポリシー例外へのコミットなど、重要な権限にははるかに高いハードルが求められます。

AIエージェントが導入された後、特にその意思決定の品質が従来のソフトウェアテスト指標だけでは測れない場合、企業はどのように継続的にパフォーマンスを評価すべきでしょうか？

ここで従来のソフトウェア思考が通用しなくなります。決定論的なソフトウェアでは合格か不合格かをテストしますが、AIエージェントではシステムからは成功した応答が得られても、顧客体験が失敗することがあります。

したがって評価すべきは結果であり、応答そのものではありません。エージェントは顧客が何を達成しようとしているかを理解したか？正しい情報を使用したか？ジャーニーを完了したか？境界内に留まり、必要なときにエスカレーションしたか？

基本的な評価は、回答をゴールデンセットと照合してスコア付けすることです。すべての企業がこれを持っています。顧客の信頼を保つかどうかを決める要素は、コンプライアンス、バイアス、誤用、そして実際の発信者やアクセント、背景ノイズ、安価なハンドセット、文途中の割り込みといった実環境でエージェントがどれだけ耐えられるかです。音声の場合、これらは想像以上に重要です。なぜならすべてのスコアは文字起こしに基づくからです。音声認識層が質問を聞き間違えると、エージェントは誰も尋ねていない質問に答えてしまいます。

算数的に考える価値があります。評価で99％のスコアは優秀に聞こえますが、年間100万件の会話があると、1万件の失敗が生じます。

2つの原則が成り立ちます。検証はエージェントやモデルプラットフォームから独立して行うべきです。私たちはエージェントを自社で構築していないため、ベンダーが自社のAIを評価すべきではないと率直に言えるのです。標準は企業自身のポリシー、顧客への約束、規制上の義務であり、ベンダーのスコアカードではありません。

そして、すべての本番障害はゲートになるべきです。チケットでもバックログ項目でもなく、次のリリースが出荷される前にエージェントがクリアしなければならないテストです。本番で問題が発生し、それがエージェントが合格すべき項目に転換されなければ、同じ問題を二度発見するコストを支払うことになります。

信頼とガバナンスは、エージェントAIのスケール拡大に対する主要な障壁としてますます指摘されています。技術の進化が企業の監督能力を上回っていると考えますか？それがもたらすリスクは何ですか？

まさに今起きていることだと思いますし、そのギャップは努力の不足ではなく構造的なものです。アイデアが顧客向けエージェントになるまで数週間です。そのエージェントに対する運用規律、所有権、証拠、監督ははるかに長い時間がかかります。なぜならそれはソフトウェアだけでなく、人と責任が関わるからです。

リスクは、ギャップが拡大し続ける間に見えなくなることです。エージェントは、エラーも失敗した取引も警告もなく、自信を持って誤った回答を顧客に提供することがあります。すべてのダッシュボードは緑色に見えます。従来の運用は、システムがトラブルを知らせてくれることに依存していますが、エージェントはそれを確実に行うとは限りません。

答えはペースを落とすことではないと考えます。ここで勝つ企業は迅速に動くでしょう。答えは、迅速に自信を持って動けるように証拠と監視体制を構築することです。エージェントに自律性が高まるほど、その責任を担えることを示す証拠がより多く必要になります。

自律エージェントが誤った判断を下した場合、最終的に誰が責任を負うべきでしょうか：開発者、エージェントを導入した事業部門、モデルを提供するベンダー、あるいはその使用を承認した経営者でしょうか？

最終的にはエージェントを導入した企業が結果に対して責任を負います。システムの構築と運用には複数の関係者が関わりますが、顧客はモデル提供者とは関係がありません。顧客はインタラクションに記載された企業との関係を持っています。

それは、責任が一人に集中するという意味ではありません。責任は意思決定のチェーンを通じて流れます。開発者はシステムの構築方法に責任があります。事業部門はエージェントに許可する範囲を決定します。ベンダーは提供する技術に責任があります。リーダーシップは、企業がリスクを管理するためのコントロールと監視体制を確保する責任があります。

モデルが決定を下したからといって、モデルがその結果を所有していると考えるのは誤りです。そうではありません。エージェントが顧客に代わって約束をした場合、その約束はブランドに属します。顧客は本能的にこれを理解しており、規制当局も同様に認識しています。

AIエージェントは、テスト時に想定されていなかった状況に直面すると予測不可能な動作をすることがあります。エージェントに顧客や金融システム、機密データへのアクセスを許可する前に、企業はこれらのエッジケースをどのようにテストすべきでしょうか？

エージェントは最終的に設計されていない何かに遭遇することを前提にしなければなりません。問題は、そうなったときに何が起こるかです。

期待されるパスを超えて検証してください。エージェントに曖昧な要求を与えます。矛盾する情報を提供します。情報が不完全な状態にします。正しい答えが停止してエスカレーションするべき状況に置きます。音声の場合は、アクセント、ノイズ、接続不良、途中で話題が変わる発信者など、実世界の条件を加えてください。目的はエージェントが機能することを確認することではなく、条件が清浄でないときにどのように振る舞うかを把握することです。

より重要な点は、エージェント単体ではなく、全体の顧客ジャーニーを検証しなければならないということです。問題は通常、モデル自体ではありません。何かがうまくいかないとき、最初に尋ねるのはモデルがどのようなコンテキストを受け取ったかです。古いナレッジ記事だったり、二つのシステムが矛盾するポリシーを持っていたり、顧客がすでに説明した内容が途中で失われたハンドオフだったりする可能性があります。各コンポーネントはそれぞれのテストに合格していても、コンポーネント間の継ぎ目で顧客ジャーニーが失敗することがあります。

システム間のその層こそが、私たちが何年もかけて計測してきた領域であり、年間4億5千万人以上の顧客ジャーニーを扱う450社以上の企業で実証されています。エージェントであれなくても、同様の破綻が起きます。また、55社以上のベンダー技術と主要なコンタクトセンタープラットフォーム上に構築されたエージェントを見てきたため、基盤となるモデルが何であれパターンは変わらないことが分かっています。

エージェントが重要なものにアクセスできるようになる前に、企業は正常時と異常時の動作に関する証拠を持っているべきです。

企業が決定論的ソフトウェアから、複数のアプリケーションにまたがって推論・計画・コミュニケーション・行動を行うシステムへと移行する中で、AIテストはどのように進化すると考えますか？

テストは、システムが期待された回答を出したかどうかを問うことから、正しい結果を達成したかどうかを問うことへと移行しなければなりません。

これは大きな転換です。エージェントは同じ顧客課題を解決するために複数の異なるパスを取ることがあり、モデルや背後にあるナレッジが変わるにつれてそのパスも変化します。すべての可能なインタラクションに対してスクリプトを書くことは不可能です。エージェントが意図を理解し、途中で適切な判断を下し、与えられた範囲内で動作したかどうかを評価する必要があります。

一つ注意したいのは、業界が高コストで間違った方向に進んでいる点です。事前テストの重要性は以前より高まっており、エージェントが本番環境で顧客に向き合う前に、準備ができているかを確認するものです。テストを省略して本番で様子を見るという考えは、顧客に直接影響を与えるリスクを先に見つけるということに等しいのです。

変わるのは、事前テストがプロセスの終点ではなくなることです。本番環境は、制御された環境では完全に再現できない条件を明らかにし、その結果が次のリリース前にエージェントがクリアすべきテストとなります。リリース前の検証、運用中の監視、そして双方が相互にフィードバックし合うサイクルです。6か月目に稼働するエージェントは、最初にリリースされたものより測定可能に優れているべきです。

今後、信頼できるAI人材を構築できる組織と、小規模なエージェントAIパイロットにとどまる組織の違いは何になるでしょうか？

エージェントから実際のリターンを得ている組織は、エビデンスに基づく運用モデルを構築した組織です。停滞している組織は、通常、技術が原因でブロックされているわけではありません。次の承認レベルが求めるものを誰も提供できないためにブロックされています。法務部やリスク委員会が妥当な質問をし、答えがないため、パイロットはパイロットのままです。技術は準備ができていても、組織はそれにより大きな権限を与える正当性を示せません。

これがパイロットと運用ワークフォースの違いです。パイロットでは常に誰かが監視しています。運用モデルでは、各エージェントに一文で表せる仕事が与えられます。その権限は限定的で文書化されています。そのパフォーマンスは、構築したチーム以外のものによって評価されます。生産上の失敗がリリースのゲートとなります。証明が得られれば、より多くの自律性が続きます。

二つ目の違いは所有権です。スケールする企業では、エージェントはサービス対象のビジネス機能に属し、何をするかについて責任を持つ所有者が明示されています。AIチームが所有するAIプロジェクトのままであれば、規模は小さく留まり続けます。なぜなら、コントロールできないリスクをビジネスリーダーが引き受けようとしないからです。

これらは特別なことではありません。企業が実際に責任ある人物を信頼して管理している方法に近いものです。

パイロットは組織の確信に基づいて実行できます。スケールにはエビデンスが必要です。

素晴らしいインタビューをありがとうございました。さらに詳しく知りたい読者は Cyara を訪問してください。