TrueFoundry、モデル障害発生時にエンタープライズAIトラフィックを自動的に再ルーティングする「TrueFailover」を発表

昨年12月にOpenAIのサービスが停止した際、TrueFoundryのある顧客企業は、チャットボットやコンテンツ生成とは無関係の危機に直面しました。この企業は、大規模言語モデル（LLM）を使って処方箋の再発行を支援しています。システムが停止する1秒ごとに数千ドルの収益が失われ、患者は時間通りに薬を受け取ることができませんでした。

エンタープライズAIインフラ企業であるTrueFoundryは水曜日、まさにそのような事態を防ぐために設計された新製品「TrueFailover」を発表しました。このシステムは、AIプロバイダーがサービス停止、速度低下、または品質劣化を経験した際に自動的にそれを検知し、ユーザーが異変に気づく前に、トラフィックをバックアップモデルやリージョンにシームレスに再ルーティングします。

「AIの世界では、フェイルオーバーはもはやそれほど単純ではありません」と、TrueFoundryの共同創設者兼最高経営責任者であるニクンジュ・バジャージ氏はVentureBeatとの独占インタビューで語りました。「あるモデルから別のモデルに移行する際には、出力品質、レイテンシー、さらにはプロンプトが同じように機能するかどうかといった点も考慮する必要があります。多くの場合、結果の劣化を防ぐためにプロンプトをリアルタイムで調整する必要があります。これは、ほとんどのチームが手動で管理できるようなものではありません。」

この発表は、エンタープライズAIの導入にとって極めて重要な時期に行われました。企業は実験段階をはるかに超え、AIは今や薬局での処方箋再発行を支え、営業提案書を作成し、ソフトウェア開発者を支援し、顧客サポートの問い合わせに対応しています。これらのシステムが停止すると、その影響は組織全体に波及します。

エンタープライズAIシステムが単一プロバイダーに危険なほど依存し続ける理由

OpenAI、Anthropic、Googleなどのプロバイダーが提供する大規模言語モデルは、何千もの企業にとって不可欠なインフラとなっています。しかし、数十年にわたる運用経験に裏打ちされた堅牢な稼働時間保証を提供するAmazon Web ServicesやMicrosoft Azureのような従来のクラウドサービスとは異なり、AIプロバイダーは複雑でリソースを大量に消費するシステムを運用しており、予期せぬ障害が発生しやすい状態にあります。

「主要なLLMプロバイダーは、数週間から数ヶ月ごとにサービス停止、速度低下、またはレイテンシーの急増を経験しており、単一プロバイダーに依存する企業への下流の影響を定期的に目にしています」とバジャージ氏はVentureBeatに語りました。

昨年12月に発生し、TrueFoundryの薬局顧客に影響を与えたOpenAIのサービス停止は、その重要性を示しています。「彼らの規模では、数秒のダウンタイムでさえ数千ドルの収益損失につながります」とバジャージ氏は説明しました。「経済的影響だけでなく、患者が時間通りに処方箋を受け取れないという人間的な影響もあります。この顧客は当社のフェイルオーバーソリューションを導入していたため、サービス停止を検知してから数分以内に別のモデルプロバイダーにリクエストを再ルーティングすることができました。そのような仕組みがなければ、復旧にはおそらく数時間かかったでしょう。」

問題は完全なサービス停止にとどまりません。モデルが完全にオフラインになることなく速度低下したり、品質の低い応答を生成したりする部分的な障害は、静かにユーザーエクスペリエンスを損ない、サービスレベル契約に違反する可能性があります。これらの「遅いが技術的には稼働している」シナリオは、従来の監視システムを回避しながら着実にパフォーマンスを低下させるため、劇的なクラッシュよりも損害が大きいことがよくあります。

プロバイダーの障害時にもAIアプリケーションをオンラインに保つ技術の内部

TrueFailoverは、TrueFoundryのAIゲートウェイの上にレジリエンス層として機能します。このAIゲートウェイは、すでにFortune 1000企業向けに月間100億件以上のリクエストを処理しています。このシステムは、相互接続された複数の機能を統合し、エンタープライズAIのための統一されたセーフティネットを構築します。

その核となる機能として、この製品は企業がプロバイダー間でプライマリモデルとバックアップモデルを定義できるようにすることで、マルチモデルフェイルオーバーを可能にします。OpenAIが利用できなくなった場合、トラフィックは自動的にAnthropic、GoogleのGemini、Mistral、または自己ホスト型代替モデルに移行します。ルーティングは透過的に行われ、アプリケーションチームがコードを書き換えたり、手動で介入したりする必要はありません。

このシステムは、マルチリージョンおよびマルチクラウドのレジリエンスを通じて、地理的な境界を越えてこの保護を拡張します。AIエンドポイントをゾーンとクラウドプロバイダー全体に分散させることで、ヘルスベースのルーティングは特定のリージョンでの問題を検知し、健全な代替手段にトラフィックを迂回させることができます。これにより、グローバルなインシデントとなるはずだったものが、ユーザーには決して知覚されない目に見えないインフラ調整へと変わります。

おそらく最も重要な点として、TrueFailoverはレイテンシー、エラー率、品質シグナルを継続的に監視する劣化認識ルーティングを採用しています。「私たちは、モデルのパフォーマンスがいつから劣化し始めているかを示す複数のシグナルの組み合わせを監視しています」とバジャージ氏は説明しました。「大規模言語モデルは共有リソースです。プロバイダーは多くの顧客に同じモデルインスタンスを実行しているため、あるユーザーやワークロードの需要が急増すると、そのモデルを使用している他のすべての人に影響を与える可能性があります。」

このシステムは、応答時間の増加、エラー率の上昇、不安定性を示唆するパターンを監視します。「個々のシグナルだけでは全体像はわかりません」とバジャージ氏は述べました。「しかし、それらを総合することで、モデルが速度低下している、または信頼性が低下しているという初期の兆候を検知できます。これらのシグナルはAI駆動システムに入力され、ユーザーが顕著な品質低下を経験する前に、いつ、どのようにトラフィックを再ルーティングするかを決定します。」

戦略的なキャッシングは、プロバイダーを突然のトラフィック急増から保護し、高需要期におけるレート制限の連鎖を防ぐことで、保護を補完します。これにより、システムはブラウンアウトや予期せぬスロットリングなしに、需要の急増とプロバイダーの制限を吸収することができます。

このアプローチは、企業がAIの信頼性について考えるべき方法に根本的な変化をもたらします。「TrueFailoverは、その複雑さを自動的に処理するように設計されています」とバジャージ氏は述べました。「多くの顧客やユースケースにわたるモデルの動作を継続的に監視し、レイテンシーの増加などの早期警告サインを探し、問題が発生する前に対応します。ほとんどの個々の企業は、自身のシステムしか見ることができないため、そのような可視性を持っていません。」

出力品質を犠牲にすることなくモデルを切り替えるエンジニアリング上の課題

AIフェイルオーバーにおける最も厄介な課題の一つは、モデルを切り替える際の一貫した出力品質の維持です。GPT-5用に最適化されたプロンプトが、ClaudeやGeminiでは異なる結果を生成する可能性があります。TrueFoundryは、速度と精度を両立させるいくつかのメカニズムを通じてこれに対処しています。

「一部のチームは、大規模モデルが十分に高性能になったため、プロンプトのわずかな違いが出力に大きく影響しないという事実に依存しています」とバジャージ氏は説明しました。「そのような場合、あるプロバイダーから別のプロバイダーへの切り替えは、ある程度の目に見える影響を伴う可能性があります。それは理想的ではありませんが、一部のチームはそれを行うことを選択しています。」

より高度な実装では、同じアプリケーションに対してプロバイダー固有のプロンプトを維持します。「トラフィックがあるモデルから別のモデルに移行すると、プロンプトもそれに合わせて移行します」とBajaj氏は述べました。「その場合、フェイルオーバーは単にモデルを切り替えるだけではありません。すでにテスト済みの構成に切り替えることになります。」

TrueFailoverはこのプロセスを自動化します。システムは、どのモデルがクエリを処理するかに基づいてリクエストを動的にルーティングし、プロンプトを調整することで、手動介入なしに品質を許容範囲内に保ちます。Bajaj氏が強調したのは、「フェイルオーバーは事前の計画に基づいて行われ、反応的なものではない」ということです。「ロジック、プロンプト、ガードレールは事前に定義されているため、エンドユーザーは通常、切り替えが発生しても気づきません。」

重要なことに、多くのフェイルオーバーシナリオでは、プロバイダーを変更する必要は全くありません。「プロンプトの変更が不要な場合、例えば東海岸から西海岸へといったように、同じモデルのトラフィックをある地域から別の地域へルーティングすることも可能です」とBajaj氏は述べました。この地理的な柔軟性により、より複雑なプロバイダー間の切り替えが必要になる前に、最初の防衛線が提供されます。

規制対象業界がコンプライアンスを損なうことなくAIフェイルオーバーを利用する方法

ヘルスケア、金融サービス、その他の規制対象分野の企業にとって、AIトラフィックが異なるプロバイダーに自動的にルーティングされる可能性は、即座にコンプライアンス上の懸念を引き起こします。患者データは、たまたま利用可能なモデルに単純に流れるわけにはいきません。財務記録は、その移動先について厳格な管理が必要です。TrueFoundryは、これらの制約に対処するために明確なガードレールを構築しました。

「TrueFailoverは、企業が明示的に承認していないモデルやプロバイダーにデータをルーティングすることはありません」とBajaj氏は述べました。「すべては管理設定レイヤーを通じて制御され、チームは事前に明確なガードレールを設定します。」

企業は、どのモデルがフェイルオーバーの対象となるか、どのプロバイダーがトラフィックを受け入れられるか、さらにはどの地域やモデルカテゴリ（クローズドソースかオープンソースかなど）が許容されるかを正確に定義します。これらのルールが有効になると、TrueFailoverはその範囲内でのみ動作します。

「モデルが承認リストにない場合、それはルーティングの選択肢にはなりません」とBajaj氏は強調しました。「トラフィックが予期せぬ場所に自動的に送信されるシナリオは存在しません。目的は、コンプライアンスとデータ境界についてチームに完全な制御を与えつつ、問題が発生した際にシステムが迅速に対応できるようにすることです。そうすることで、セキュリティや規制要件を損なうことなく信頼性が向上します。」

この設計は、TrueFoundryの既存のエンタープライズ導入から得られた教訓を反映しています。フォーチュン50に名を連ねるあるヘルスケア企業は、すでにこのプラットフォームを利用して、エージェント型AIシステムを通じて年間5億件以上のIVRコールを処理しています。その顧客は、厳格なデータレジデンシー管理を維持しながら、クラウドとオンプレミスの両方のインフラストラクチャでワークロードを実行できる機能を必要としていました。これは、フェイルオーバーポリシーを正確に定義する必要があるハイブリッド環境の典型です。

自動フェイルオーバーが役立たないケースと、企業が計画すべきこと

TrueFoundryは、TrueFailoverがすべての信頼性問題を解決できるわけではないことを認識しています。システムは企業が設定するガードレール内で動作し、それらの設定がどのような保護が可能かを決定します。

「チームがプロンプトや期待値を調整せずに、大規模で高容量のモデルからはるかに小規模なモデルへのフェイルオーバーを許可した場合、TrueFailoverは同じ出力品質を保証できません」とBajaj氏は説明しました。「システムはトラフィックをルーティングできますが、適切な設定なしに小規模なモデルを大規模なモデルのように動作させることはできません。」

インフラストラクチャの制約も保護を制限します。企業が自社モデルをホストし、それらすべてが同じGPUクラスターで実行されている場合、そのインフラストラクチャが故障してもTrueFailoverは役に立ちません。「代替のインフラストラクチャが利用できない場合、フェイルオーバーする先がありません」とBajaj氏は述べました。

同時多プロバイダー障害の問題は、企業のリスク議論で時折浮上します。Bajaj氏は、このシナリオは理論的には可能であるものの、現実とはほとんど一致しないと主張します。「実際には、『ダウンする』というのは、通常、プロバイダー全体がすべてのモデルと地域でオフラインになることを意味しません」と彼は説明しました。「はるかに頻繁に発生するのは、トラフィックの急増や容量の問題により、特定のモデルや地域で速度低下や中断が起こることです。」

そのような場合、フェイルオーバーは複数のレベルで発生する可能性があります。オンプレミスからクラウドへ、クラウドからオンプレミスへ、ある地域から別の地域へ、あるモデルから別のモデルへ、あるいはプロバイダーを完全に切り替える前に同じプロバイダー内でも発生します。「それだけでも、すべてが一度に故障する可能性は非常に低いと言えます」とBajaj氏は述べました。「重要な点は、信頼性が冗長性の層の上に構築されていることです。ガードレールに含まれるプロバイダー、地域、モデルの数が多いほど、ユーザーが完全な停止を経験する可能性は低くなります。」

Fortune 500企業のAI導入内部にプラットフォームを構築したスタートアップ

TrueFoundryは、世界最大規模のAI導入の一部においてインフラストラクチャとしての地位を確立しており、そのフェイルオーバーへの意欲にとって重要な背景を提供しています。同社は2025年2月にシリーズA資金調達で1,900万ドルを調達しました。これはIntel Capitalが主導し、Eniac Ventures、Peak XV Partners、Jump Capitalが参加しました。Gokul Rajaram氏とMohit Aron氏を含むエンジェル投資家もこのラウンドに参加し、総資金調達額は2,100万ドルとなりました。

サンフランシスコに拠点を置く同社は、2021年にBajaj氏と共同創設者のAbhishek Choudhary氏、Anuraag Gutgutia氏によって設立されました。彼らは全員、IIT Kharagpurで同級生として出会った元Metaのエンジニアです。当初は機械学習の導入加速に注力していましたが、2023年に生成AI技術が主流になるにつれて、TrueFoundryは生成AI機能のサポートへと方向転換しました。

同社の顧客リストは、他のAIインフラストラクチャスタートアップが匹敵しがたいエンタープライズ規模の導入を示しています。NvidiaはTrueFoundryを利用して、世界中のデータセンターでGPUクラスターの利用率を最適化するマルチエージェントシステムを構築しています。これは、GPU容量に対する飽くなき需要を考慮すると、利用率のわずかな改善でも大きなビジネスインパクトにつながるユースケースです。Adopt AIは、TrueFoundryのAI Gatewayを通じて1,500万件以上のリクエストと400億個の入力トークンをルーティングし、エンタープライズエージェントワークフローを強化しています。

ゲーム会社Games 24x7は、毎秒200リクエストを超える規模で、プラットフォームを通じて1億人以上のユーザーに機械学習モデルを提供しています。デジタルアダプションプラットフォームのWhatfixは、TrueFoundry上でマイクロサービスアーキテクチャに移行し、リリースサイクルを6分の1に短縮し、テスト時間を40%削減しました。

TrueFoundryは現在、世界中で30社以上の有料顧客を抱えていると報告しており、昨年は年間経常収益が150万ドルを超え、顧客基盤を4倍に拡大したことを示しています。同社は、顧客全体で機械学習ワークロード向けに1,000以上のクラスターを管理しています。

TrueFailoverは、既存のTrueFoundry AI Gatewayおよびプラットフォームのアドオンモジュールとして提供され、料金はトラフィック量、ユーザー数、モデル数、プロバイダー数、および関連するリージョン数に応じた従量課金モデルとなります。デザインパートナー向けの早期アクセスプログラムは、数週間以内に開始されます。

従来のクラウドの稼働時間保証がAIプロバイダーには決して適用されないかもしれない理由

企業テクノロジーの購入者は、インフラプロバイダーに対し、長年にわたり稼働時間のコミットメントを求めてきました。Amazon Web Services、Microsoft Azure、Google Cloudはすべて、障害発生時に金銭的ペナルティを伴うサービスレベル契約を提供しています。AIプロバイダーも最終的には同様の期待に直面するのでしょうか？

Bajaj氏は、現在のAIインフラ世代では従来のSLA達成を困難にする根本的な制約があると見ています。「今日のほとんどの基盤LLMは共有リソースとして運用されており、それが一般に公開されている標準価格を可能にしています」と彼は説明しました。「プロバイダーはより高い稼働時間のコミットメントを提供しますが、それは通常、専用容量または予約済みインフラを意味し、コストが大幅に増加します。」

潤沢な予算を持つ企業であっても、予期せぬリスクを生む利用制限に直面します。「トラフィックがそれらの制限を超えて急増した場合、リクエストは共有インフラに流れ込む可能性があります」とBajaj氏は述べています。「そのため、企業がクラウドプロバイダーに慣れているような厳格な保証を達成することは困難になります。」

大規模言語モデルを運用する経済性は、今後数年間続く可能性のある追加の障壁を生み出しています。「LLMは依然として非常に複雑で、運用コストがかかります。大規模なインフラとエネルギーを必要とし、ほとんどの企業が稼働時間を保証するためだけに複数の完全に専用のモデルインスタンスを運用するような近い将来は期待していません。」

この現実が、個々のプロバイダーが何を約束できるかに関わらず回復力（レジリエンス）を提供するTrueFailoverのようなソリューションへの需要を促進しています。「企業は、信頼性がモデルプロバイダー単独では得られないことに気づいています」とBajaj氏は述べています。「今日のこれらのシステムがどのように動作するかという現実にH対応するためには、追加の保護層が必要です。」

AIを基幹業務プロセスに組み込んだ企業にとっての新たな考え方

TrueFoundryの発表のタイミングは、企業がAIをどのように利用しているか、そしてAIが失敗したときに企業が失うものにおける根本的な変化を反映しています。内部での実験として始まったものが、今や顧客向けのアプリケーションへと進化し、その中断は収益と評判に直接影響を与えます。

「多くの企業は過去に生成AIやエージェントシステムを試しており、本番環境でのユースケースは主に社内向けでした」とBajaj氏は指摘しました。「彼らの売上や企業の世間からの評価に直接的な影響はありませんでした。」

その時代は終わりました。「これらの企業が一般公開アプリケーションを立ち上げた今、障害が発生すれば売上と世間からの評価の両方に影響が出る可能性があるため、6ヶ月前と比べてもはるかにリスクが高まっています。だからこそ、私たちは今、これに対する注目がますます高まっているのを目にしているのです。」

処方箋の補充から顧客サポート、営業業務に至るまで、AIを基幹業務プロセスに組み込んでいる企業にとって、その考え方は完全に変わりました。もはや、どのモデルがベンチマークで最高のパフォーマンスを発揮するか、あるいはどのプロバイダーが最も魅力的な機能を提供するかという問題ではありません。今、テクノロジーリーダーを眠らせない問題は、はるかに単純で、はるかに緊急性の高いものです。それは、「最悪のタイミングでAIが機能しなくなったらどうなるのか？」ということです。

ある場所では、薬剤師が処方箋を調剤しています。顧客サポート担当者が苦情を解決しています。営業チームは明日締結される取引の提案書を作成しています。これらすべては、その規模と洗練度にもかかわらず、警告なしに機能停止するプロバイダーに依存するAIシステムに頼っています。

TrueFoundryは、企業が最も重要な人々、つまり顧客に、そうした機能停止の瞬間が決して届かないようにするために、多額の費用を支払うことに賭けています。

掲載元： VentureBeat

TrueFoundryについて：

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

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