Unite AI: Nikunj Bajaj氏（TrueFoundry共同創業者兼CEO） – インタビューシリーズ

Nikunj BajajはTrueFoundryの共同創業者兼CEOであり、信頼性の高いエンタープライズグレードのAIプラットフォーム構築に関する同社のビジョンと戦略を主導しています。テクノロジー製品とチームの規模拡大における経験を活かし、組織がAIシステムを安全かつ効率的に導入・運用できるよう支援することに注力しています。彼はエンタープライズAIの導入、AIプラットフォーム戦略、および本番環境AIにおける新たなトレンドについて執筆しています。

TrueFoundryは、Kubernetesベースの環境（クラウド、オンプレミス、ハイブリッドを問わず）において、強力なガバナンス、セキュリティ、コスト管理のもと、機械学習および生成AIアプリケーションの構築、デプロイ、管理、規模拡大を支援するエンタープライズAIインフラプラットフォームです。モデル、LLM、エージェントワークフローへのアクセスを一元化するAIゲートウェイと、モデルのファインチューニング、デプロイ、監視、オートスケーリングのためのツールを組み合わせることで、MLOpsを簡素化し、データサイエンスおよびエンジニアリングチームの価値実現までの時間を短縮することを目指しています。TrueFoundryの「開発者ファースト」かつ「クラウドに依存しない」アプローチは、エンタープライズコンプライアンスと柔軟性を重視しており、SOC 2、HIPAA、ITARなどの標準を遵守しつつ、ベンダーロックインなしで複雑なAIワークロードを管理することを可能にします。

TrueFoundryを設立される前は、機械学習の研究、Facebookでの本番環境AI、大規模レコメンデーションシステムなど、幅広い分野でご活躍されていました。どのような経験が、エンタープライズAIインフラ企業を立ち上げるきっかけとなり、当時どのような課題が解決されていないと感じていましたか？

Metaでは、機械学習をソフトウェアの特殊なケース、生成AIを機械学習の特殊なケースと捉えていました。その結果、ソフトウェアが最下層、機械学習が中間層、生成AIが最上層という垂直統合型スタックが構築されました。この構成では、機械学習開発者である私が構築するモデルは、他のソフトウェアと同じデプロイパターンに従うため、システムのスケーリングが非常に簡単になります。

しかし、ほとんどの企業は並行スタックをデプロイしており、ソフトウェア、機械学習、生成AIそれぞれに個別のスタックを持っていました。このような並行スタックが存在すると、機械学習とソフトウェア間の引き渡しが必要となるため、スケーリングがより複雑になります。

私たちのチームは常に機械学習モデルの構築と機械学習インフラの構築という両分野にまたがって仕事をしてきたため、同様の垂直統合型スタックを企業に導入し、それぞれの特定の要件に合わせて適応させることができるという独自の視点を持っていました。また、2021年末には、機械学習が転換点に近づいており、そうなれば、より多くの企業がこれらのシステムを効果的にデプロイし、規模を拡大するために垂直統合型スタックを必要とするだろうという仮説を立てていました。これが最終的にTrueFoundryの設立につながり、私たちの仮説は正しかったのです。2022年後半のChatGPTの登場後、AIの導入は加速しました。

AIシステムが実験段階から日常業務へと移行するにつれて、組織が信頼性と障害について考えるべき方法にはどのような変化がありましたか？

生成AIにおけるリスクは、従来の機械学習システムと比較して格段に高くなっています。これらのシステムが本番環境に移行するにつれて、LLMが本質的に確率的であるため、組織ははるかに高いレベルの曖昧さと非決定性に対処することになります。その上に構築されるエージェントシステムは、さらに曖昧さを増幅させます。

さらに、障害はもはや二元的ではありません。システムが単に停止するかしないかではなく、多くの問題は部分的な障害やサイレントな劣化として現れます。システムは時間の経過とともに、より高いレイテンシ、品質の低下、または誤った動作を示す可能性があります。多くの場合、これらの劣化は検出がより困難であり、完全な停止よりもさらに損害が大きいことさえあります。

組織は、信頼性を稼働時間だけでなく、時間の経過に伴うパフォーマンスの劣化という観点からも考慮する必要があります。

TrueFailoverは、注目を集めるクラウドおよびAIサービス障害が相次ぐ中でリリースされました。どのような最近の出来事が、AIの信頼性が「あれば良いもの」から「中核的なアーキテクチャ要件」へと変化したことを明確に示しましたか？

当社の医療分野のお客様の一社で、処方箋に関するリアルタイムかつ時間的制約のある患者リクエストを処理しているのですが、モデル障害による停止の影響を受けました。彼らのワークフローは1秒あたり数千ドルの収益を生み出しており、この停止によって重要なワークフローの一部が中断されました。TrueFailoverの初期のお客様として、私たちは迅速な復旧を支援し、影響を限定的に抑えることができました。

このようなインシデントは、重要な問いを投げかけます。生成AIシステムの重要性が高まり続ける中、なぜ復旧プロセスは依然として大部分が手動なのでしょうか？これは、システムは障害が発生することを前提として構築されるべきであり、自動的に自己修正するように設計されるべきだという考えを裏付けるものでした。信頼性は、AIゲートウェイの使用を通じてAIスタック自体に組み込まれる必要もあります。AIゲートウェイは、プロバイダーを横断した一元的なルーティング、可観測性、ガードレール、インテリジェントなモデル切り替えを提供できます。

多くのAI障害は、いまだに技術的な問題として片付けられています。AIシステムが停止した際に、真の経済的および人的コストはどこから現れ始めるとお考えですか？

エンタープライズAIは、これらの些細な問題がもはや内部ワークフローにのみ影響する段階を超えて進化しました。今日、本番環境でのユースケースが顧客向けになったため、停止や劣化は世間の認識と利益に直接的かつ即座に影響を与えます。内部テストからリスクの高い顧客向けアプリケーションへのこの移行が、経営層の関心と監視への要求が高まっている理由です。

AIシステムが業務ワークフローに深く組み込まれるにつれて、停止はもはや単なる技術的な問題ではありません。それらは、ビジネス、顧客、そして評判に直接的な影響を及ぼすことが増えています。

薬局、医療業務、カスタマーサポートのようなミッションクリティカルな環境において、AIの停止時間はどれほど迅速に運用上または評判上のリスクへとエスカレートする可能性がありますか？

ミッションクリティカルな環境では、これらのシステムがリアルタイムかつ時間的制約のあるワークフローをサポートしているため、エスカレーションはほぼ即座に発生します。たとえ短い中断であっても、重要なプロセスを停止させたり、サービス提供を遅らせたり、その出力に依存する下流システムを中断させたりする可能性があり、組織全体に連鎖的な運用上の影響を生み出します。

医療のような分野では、その影響は運用上の混乱を超えて、顧客体験やサービス結果にまで及びます。患者が時間通りに処方薬を受け取れない場合、現実的な結果が生じる可能性があります。これは患者にとっての問題であるだけでなく、薬局や医療提供者の評判を損なう可能性もあります。信頼が重要な要素となるミッションクリティカルな環境では、システムが稼働し続けることが最も重要です。このため、組織は、AIシステムは障害が発生することを前提として設計されるべきであり、リスクを最小限に抑えるために復旧メカニズムが自動的に作動する必要があることをますます認識しています。

多くのチームが継続性よりも機能性を重視して設計していると述べられました。AIシステム設計において、回復力が歴史的に優先順位が低かったのはなぜだと思いますか？

これは主に、組織内のインセンティブに起因します。新しい機能は目に見え、刺激的です。それらは、リーダーシップ層がすぐに認識できるデモ、機能、製品の可能性を解き放ちます。

継続性は、定義上、物事がうまくいっているときには目に見えません。このため、報酬システムは、何も壊れないことを保証するよりも、新機能をリリースすることに偏りがちです。その結果、組織はレジリエンスエンジニアリングよりも機能開発に不釣り合いなほど投資することがよくあります。

企業が外部モデルやAPIへの依存度を高めるにつれて、リーダー層がまだ十分に認識していない、どのような新たな脆弱性がAIスタックに導入されているのでしょうか？

LLMは根本的に共有リソースであり、企業は従来のインフラストラクチャのようにLLMを所有しているわけではありません。さらに、企業の重要な基幹システムは、十分に検証されていない外部システム上で稼働しています。LLM自体も急速に進化しており、モデルプロバイダーは研究を非常に迅速に繰り返しているため、レイテンシーやモデルパフォーマンスのわずかな低下などについて責任を負うことはできません。

LLMは共有リソースであるため、他のLLM利用者が特定の行動をとることで、レイテンシーが急増する可能性があります。LLMの根本的な性質により、このような障害点が多数発生し、この新しい世界において企業は完全に制御することができません。完全な制御ができない場合、企業ができる最善策は、十分なシステム冗長性を作成し、レジリエントなシステムを設計することです。

特定の製品に焦点を当てることなく、組織は、障害をまれなエッジケースとして扱うのではなく、障害を前提とするようにAIアーキテクチャをどのように再考すべきでしょうか？

組織は、分散システム設計の第一原理に立ち返るべきです。ソフトウェアシステムは、ネットワークコンポーネントやマシンが故障し、地域全体がダウンする可能性があるという前提に基づいて構築されていました。

AIシステムも同様であるべきです。モデルプロバイダーがレイテンシーの問題、性能低下、または停止を経験することを前提とし、異なる障害シナリオにおいてもアプリケーションがレジリエントであり続けるように冗長性を組み込むべきです。

AIのレジリエンスは、アップタイムと冗長性がクラウドインフラストラクチャの決定を形成したのと同様に、プラットフォームやベンダー選定における決定要因になるとお考えですか？

より多くのAIシステムが本番環境に移行するにつれて、レジリエンスは必須条件となるでしょう。ベンダーがアップタイムと全体的なレジリエンスに関するグラフやメトリクスを提示できない場合、検討対象にすらなりません。レジリエンスがベンダー全体で基本的な期待値となれば、決定要因はユーザーエクスペリエンス、パフォーマンス最適化、可観測性、およびより高レベルの製品機能へと移行するでしょう。時間が経つにつれて、AIゲートウェイや自動フェイルオーバー機能などのコンポーネントは、エンタープライズAIインフラストラクチャの核となる基盤要素となるでしょう。

将来を見据えると、AIが時折役立つだけでなく、継続的に利用可能であることが期待される世界において、「本番環境対応」のAIとは一体何を意味するのでしょうか？

本番環境対応のAIシステムは、可観測性、制御可能性、回復可能性を備えている必要があります。これら3つの要素すべてが満たされている必要があります。

本番環境のAIが可観測であるためには、チームはモデルの動作、レイテンシー、エラー率、トークン使用量、ドリフト、障害パターンについて深い可視性を必要とします。強力な可観測性がなければ、ユーザーが気づき始める前に性能低下を検出することは非常に困難になります。

システムが制御可能であるためには、トラフィックシェーピング、レート制限、ガードレール、ポリシー適用、およびモデルとプロバイダー間のインテリジェントルーティングが含まれます。ここでAIゲートウェイが基盤となり、ガードレールを適用し、一貫したガバナンスを提供し、パフォーマンスや信頼性が低下した際に動的なモデル切り替えを可能にする集中制御プレーンとして機能します。

そして最後に、回復可能性に関してですが、システムは、プロバイダーの停止、モデル品質の低下、レート制限、悪意のあるアクターからの予期せぬ入力などにより、コンポーネントが部分的または完全に破損する可能性があるという前提で構築されるべきです。自動フェイルオーバーと自己修復メカニズムは、何かが起こった後に手動でトリガーされるプレイブックではなく、アーキテクチャにネイティブに組み込まれているべきです。

これがTrueFoundryが目指している方向性です。可観測性、集中制御、自動回復を組み合わせることで、このように本番環境対応を定義するベンダーは、長期的な顧客の信頼を獲得し、新たな問題が発生するたびに解決し続けることができるでしょう。

TrueFoundryについて：

TrueFoundryは、LLMゲートウェイ、MCPゲートウェイ、エージェントゲートウェイを包含するエンタープライズグレードのAIゲートウェイを提供し、企業が単一のコントロールプレーンからモデル、ツール、ガードレール、エージェントへのアクセスを安全に接続、監視、管理できるようにします。このAIゲートウェイは、プロバイダー間で統一された構成可能な接続を通じて、安全で効率的、かつ将来にわたって安全なエージェントワークロードを可能にします。

ゲートウェイ層を超えて、TrueFoundryは組織がGPU上でカスタムLLMを展開およびトレーニングし、MCPサーバーをホストし、カスタムエージェントを実行することを可能にします。これらすべてはKubernetesネイティブインターフェースを通じて行われます。AIゲートウェイとデプロイメント環境の両方で、オンプレミスおよびVPCインストールをサポートしています。TrueFoundryは、SOC 2、HIPAA、ITAR標準に準拠したエンタープライズグレードのコンプライアンスを保証します。内蔵のオートスケーリング、キャッシング、リソース最適化により、TrueFoundryは組織がAIシステムを安全かつ効率的に、そして将来にわたって安全なスタック上で構築、展開、管理することを可能にします。詳細については、こちらをご覧ください。 truefoundry.com