Prince Kohli、Sauce Labs社社長兼CEO – インタビューシリーズ

Prince Kohli、Sauce Labs社の社長兼CEOは、人工知能、エンタープライズソフトウェア、クラウドコンピューティング、オートメーション、ネットワーキング、サイバーセキュリティにわたる広範な経験を持つベテラン技術幹部です。2025年2月にSauce Labsに入社する前は、Automation Anywhereの最高技術責任者（CTO）として6年以上勤務し、大企業向けのAI駆動オートメーション技術の推進に貢献しました。以前はThoughtSpotでエンジニアリング上級副社長を務め、EricssonではグローバルR&D組織（1万人超のエンジニア）を統括するシニアリーダーシップを担いました。また、Citrixで約10年にわたりプラットフォーム、クラウドネットワーキング、エンジニアリング、オペレーションのイニシアチブをリードしました。キャリア初期にはアプリケーションセキュリティ企業Terosを共同設立し、SGIでテクニカルリードとして勤務しました。エグゼクティブとしての役割に加え、KohliはEthical AI Governance Groupを通じた技術ガバナンスイニシアチブに貢献し、以前は世界経済フォーラムのSafe Systems and Technologies作業部会にも参加していました。

Sauce Labsは、ソフトウェア品質と継続的テストを提供する企業で、エンタープライズ向けにブラウザ、OS、仮想環境、実機デバイスを跨いだWebおよびモバイルアプリケーションのテスト用インフラとツールを提供しています。そのプラットフォームは、自動テストと手動テスト、ビジュアルテスト、モバイルアプリ配布、エラーレポート、AI搭載のテスト作成と分析などの機能をサポートし、一般的なCI/CDワークフローと統合します。Sauce Labsは、AIエージェントがテストの生成、実行、分析を支援し、ソフトウェアリリースプロセス全体で人間の監視を保持するAI統合リリース保証プラットフォーム「AURA」を中心に技術を位置付けています。同社によれば、同社のインフラは87億回以上のテスト実行と30万以上のエンタープライズユーザーを支えており、約20年にわたるクロスプラットフォームテストデータに基づいています。

Sauce Labsに入社する前、Automation AnywhereでAI駆動のオートメーションを主導し、EricssonやCitrixなどで大規模なクラウドおよびエンジニアリング組織を管理していました。これらの経験はソフトウェア品質の課題に対する見方にどのように影響しましたか、そしてなぜAIネイティブのリリース保証をSauce Labsの中心的優先事項にすることを決めたのですか？

EricssonとCitrixでは、ソフトウェア欠陥がいかに迅速に拡散し、世界規模のインフラに影響を及ぼし、セキュリティや顧客の業務、信頼、収益に重大なインパクトを与えるかを目の当たりにしました。Automation AnywhereでAIが作業の速度と構造を変える様子を見て、AI生成ソフトウェアのペースに合わせてテストを再構築する必要があると確信しました。Sauce Labsはテスト自動化の先駆者であり、AIネイティブのリリース保証は次に取り組むべき重要課題です。

Sauce Labsの調査によると、組織の80％がAI生成コードに起因する本番インシデント、障害、または顧客に影響を与える欠陥を特定しています。これは主にAIが生成したコードの弱点を示すものですか、それとも企業がテストやガバナンスプロセスを更新せずにAIコーディングツールを採用したことが原因ですか？

80％という数値は、ソフトウェア提供全体に問題があることを示しています。AI業界は1兆ドル以上の民間資本を呼び込み、その多くはAIが企業の生産性を劇的に向上させることを前提としています。しかし、コードを大量に生成しても、企業が本番環境に投入する前にその品質とセキュリティに自信を持てなければ価値は生まれません。

AI生成コードは微妙なバグやセキュリティ問題をもたらす可能性があり、企業はすでに追いつくのが難しかったテストやガバナンスプロセスにそのコードを通すことを余儀なくされています。これにより、数兆ドル規模の実行問題が生じます：AIはソフトウェア開発を加速しますが、リリース保証が近代化されていなければ、欠陥も同様に加速してしまいます。バグは最終的に必ず顕在化するため、企業は顧客や攻撃者に見つかる前に検出する必要があります。

レポートによれば、開発者はコード量を741％増やした一方で、リリース速度は20％未満しか向上していません。検証システムが追いつかない原因は何であり、ソフトウェア開発ライフサイクルの中で最大のボトルネックは通常どこに現れますか？

コード生成はテスト作成、保守、分析よりはるかに先行しています。最大のボトルネックは通常、コードが書かれた後にユーザージャーニーのコンテキストで検証が必要になる段階です。これはしばしばコード自体よりも複雑で、コード機能やオブジェクトを跨ぐエンドツーエンドのパスを考慮しなければならず、ある箇所の意味的な小さな変更が大きな下流効果を生むことがあります。アプリケーションの意図を正確かつ完全に捉えるテストを作成することは従来ほぼ不可能であり、膨大な手作業と保守が必要です。さらに、テスト実行後に失敗が起きた場合、チームはその問題を理解し診断しなければならず、失敗が製品由来か古いテストによるものかを判断しなければなりません。この作業は依然として手動レビューとエンジニアリングコンテキストに大きく依存しています。

調査対象企業の半数以上が重要な欠陥を抱えたままソフトウェアをリリースしたことを認め、66％が期限に間に合わせるために品質やテスト基準を妥協したと回答しました。なぜ組織はこの程度のリスクを受容するのか、そしてソフトウェア品質を最終的なエンジニアリングチェックポイントではなくビジネスレベルの優先事項にするためには何が必要でしょうか？

組織がリスクを受容するのは、リリース目標が顧客、収益、製品の即時コミットメントに直結しており、欠陥コストが後になって複数チームに跨って顕在化するためです。品質がビジネスの優先事項になるのは、リーダーがリリース速度と同時に本番インシデント、顧客影響、セキュリティ露出、再作業コスト、遅延収益を測定したときです。

Sauce LabsはAURAを、各リリースから学習しながらテストを作成・実行・分析するクローズドループプラットフォームとして位置付けています。これはAI支援テスト生成、自己修復テストスクリプト、またはエンジニアリングチームがすでに使用している他の自動化ツールと比べて、技術的・運用的にどのように異なりますか？

ほとんどのAIテストツールはテスト生成や壊れたロケータの修復といった特定タスクに特化していますが、AURAはアプリケーションの意図を理解し、テストを作成・実行し、失敗を分析し、プロダクションの振る舞いを開発にフィードバックすることでプロセス全体を結びつけます。多くの変更を自動で処理し、アプリケーションの意味や期待動作が変化したときに人間を介入させることができます。さらに、生成されたテストは安定しており、アプリケーションやブラウザ、デバイスで意味的な影響を及ぼさない変更があっても修正の必要がありません。最後に、AURAはテスト実行用クラウドを内部に組み込んでいるため、開発者や品質エンジニアリングチームからプロセス全体をオフロードできます。

AURAは「ビジネス意図」に対してソフトウェアを検証するよう設計されています。その意図はどのように定義されテスト可能な要件に変換され、誰が承認し、曖昧・不完全・解釈の余地がある要件はプラットフォームでどのように扱われますか？

ビジネス意図は製品要件、受け入れ基準、ビジネスルール、ユーザージャーニー、そして顧客が実際にアプリケーションを使用する方法から得られます。製品リーダーが期待結果を定義し、エンジニアリングと品質チームがその結果をシステムが検証できる振る舞いに変換します。要件が不完全または曖昧な場合、AURAは不確実性を表面化させ、期待結果を変更する前に人間の承認を求めます。

Sauce Labsは、AURAを使用する企業が本番インシデントを90％削減し、リリースサイクルを47％高速化し、エンジニアリングキャパシティを38％回復したと報告しています。これらの成果はどのように測定され、どの期間のデプロイで得られ、AURAの効果を他の組織的・エンジニアリング的変化と区別するためにどのような独立した検証が行われましたか？

エンタープライズ導入全体で、AURA導入後の本番インシデント数、リリースサイクル速度、エンジニアリングキャパシティの変化を測定しました。その結果、インシデントは90％以上減少し、リリースサイクルは47％高速化、エンジニアリングキャパシティは38％回復し、これらは独立した方法で検証されています。WalmartやKeller Williamsといった顧客も、リリース頻度、テストカバレッジ、サイクルタイムの大幅な向上を報告しています。

調査によれば、インシデントが増加し続ける中で64％の組織が品質保証の人員を増やしました。単にテスターを増やすだけで検証ギャップを解消できない理由は何ですか、またテストがより自律的になるにつれて開発者、品質エンジニア、サイト信頼性チームの役割はどのように変化すると考えますか？

AIはコード量を企業がテスト人員を増やす速度よりはるかに速く増加させ、人数を増やすことはハンドオフや調整を増やすだけです。開発者は意図を明確に定義する必要があり、品質エンジニアはリスク・カバレッジ・ガバナンスに注力し、サイト信頼性チームはプロダクションの振る舞いをリリースプロセスにフィードバックします。エージェントはこの新しい開発モデルが要求する規模で繰り返しの実行と分析を処理できます。

AIエージェントがテストの作成・実行・解釈の責任を拡大するにつれて、人間が意思決定権を保持すべき領域はどこですか？どのような不確実性、セキュリティリスク、または顧客影響の可能性がある場合に、リリースを自動的に停止させるか、人間のレビューをトリガーすべきでしょうか？

判断、顧客影響、ビジネスリスクが関わる場合、最終的なリリース判断は人間が保持すべきです。AIエージェントは煩雑で繰り返し可能な明確に定義されたテストタスクを自動化できますが、コードやテスト結果が完全に理解・説明・再現できない場合は人間が本番リリースを承認すべきです。要件が不明確、セキュリティ脆弱性の可能性がある、サードパーティコンポーネントが十分に検証されていない、または失敗が収益、機密データ、顧客体験、ミッションクリティカルな運用に影響を及ぼす可能性がある場合もレビューは必須です。

このような状況では、説明できない振る舞い、テスト結果の不一致、リリース準備の証拠が不十分な場合は、リリースを自動的に停止すべきです。

顧客の事例では、「フレーク」のように見えるテストが一貫性のない合格を示し、明確な失敗パターンがないために多くの場合無視されていました。しかし、これらの顧客のうち適切にガバナンスされたプロセスを持つ企業は、プラットフォームの支援により、失敗が微妙だが重要なタイミングベースの欠陥に起因することを特定し、リリースされた場合に大きな影響を及ぼす可能性があることを高コストで防止しました。

あなたはEthical AI Governance Groupや世界経済フォーラムのSafe Systems and Technologies作業部会にも関わってきました。AI生成コードと自律テストが深く結びつく中で、企業がソフトウェアの高速生成によって新たなシステム的・セキュリティ的・説明責任リスクを招かないようにするために、どのようなガバナンス基準が必要になるでしょうか？

AIがソフトウェアを高速で生成できるほど、検証とガバナンスの層は強固でなければなりません。この層は多くの要素から成り、エージェントが自律的に判断できる範囲を明確にし、ビジネス意図、セキュリティ、コンプライアンス、意味的な重要変更に不確実性がある場合は人間のレビューを必須とします。また、エージェントが何を、なぜ変更したか、リリース判断を支える証拠が何かを追跡できるトレーサビリティが必要です。最終的に、ガバナンスは本番に到達したものの品質と予測可能性で測定すべきであり、例えばリリース後90日以内に生成コードがインシデントを引き起こす頻度を具体的に追跡し、AIがコードを生成する速さで測るのではなく、こうした指標で評価すべきです。

素晴らしいインタビューをありがとうございました。詳しく知りたい読者はSauce Labsをご覧ください。