摘要

  • Prosimo は 2019 年設立。2021 年のシリーズ A と 2022 年のシリーズ B で少なくとも 5,500 万米ドルを調達。監査済み収益、評価額、買収価格はいずれも非公開。
  • AXI は、一元的なインテント・トポロジー・分析レイヤーと分散エッジを組み合わせ、クラウド資産の検出、アプリケーション接続、セキュリティサービスの挿入、テレメトリー収集を行うが、物理バックボーンは所有しない。
  • 2024 年 6 月に発表された VM-Series 統合は、Prosimo が 2025 年 2 月頃に Palo Alto Networks に統合されるよりも前に行われた。正確な日付、価格、現在の製品マッピングは公開情報からは確認できない。
  • コントロールは引き続き、企業、オーケストレーション・ソフトウェア、クラウドプロバイダー、Palo Alto Networks の間に分散しており、トポロジー、クレデンシャル、ポリシー、ルーティング権限の移行可能性が顧客にとって最も重要な検証ポイントとなる。

会社は消えても、問題は消えない

Prosimo を 2026 年時点で独立して運営されているベンダーと表現するのは正確ではない。公開されている経歴情報によると、創業者と複数の従業員は 2025 年 2 月前後に Palo Alto Networks に移っている。Prosimo の企業ページは買収済みと表示され、元 CTO の Nehal Bhau 氏は後に、同社の技術が Palo Alto Networks の製品に統合されたと発言している。これらの証拠は、支配権が変更され、技術には引き続き価値があることを確認するのに十分だが、契約締結日、クロージング日、法的形態、取引価格を確定するものではない。

この事実は冒頭で明確に述べなければならない。なぜなら、すべての製品説明で使用する時制がそれによって決まるからだ。AXI、Network Transit、App Transit、Application-driven Intelligent Results、Nebula は、いずれも Prosimo が独立していた時期に十分に文書化された機能である。Palo Alto Networks が現在の製品とサポートのマッピングを公表するまでは、これらを Prosimo ブランドで現在も販売されている現行製品として記述すべきではない。歴史的なアーキテクチャは、買収後に組み込みコード、共有サービス、製品モジュール、または内部エンジニアリング資産として存続する可能性があり、その形態は同一ではない。

ブランドの消滅は、根底にある問題が時代遅れになったことを意味しない。企業は引き続き、ワークロードを Amazon Web Services、Microsoft Azure、Google Cloud、プライベート・データセンター、コロケーション施設、SaaS プラットフォーム、リモートユーザーに分散させる。各環境には独自のルーティング、ゲートウェイ、プライベートエンドポイント、アイデンティティ管理、セキュリティサービス、クォータ、課金ルールが存在する。すべてのアカウントを所有していても、リクエストがこれらの環境間をどのように流れるかを説明できる統一されたビューを持っているとは限らない。Prosimo の重要性は、まさにこのビューを掌握しようとした点にある。

したがって、買収は結末の注釈ではなく、この記事全体の中心テーマである。Prosimo は、資産を発見し、アプリケーションコンテキストを解釈し、トラフィックをセキュリティサービスに誘導できる、クラウド横断的なコントロール層を構築した。Palo Alto Networks は当初、その VM-Series ファイアウォールをこれらの経路に挿入できるテクノロジーパートナーとして登場したが、後にその技術の所有者となった。ルーティングオーケストレーションとディープインスペクションの間にあった境界は、単一のネットワークセキュリティプラットフォームの内部に移されたのである。

マルチクラウドルーティングが奪い合うのはコンテキスト

ルーティングテーブルは、特定のプレフィックスが特定のネクストホップを経由して到達可能かどうかを示すことはできる。しかし、ユーザーがアクセスしたいアプリケーションはどれか、リクエスト元は信頼できるか、トラフィックは検査を経由すべきか、プライベートエンドポイントは利用可能か、あるクラウドパスは高コストか、パケットが到着してもトランザクションが失敗する理由は何か、といった問いには答えられない。マルチクラウド運用は、こうした問題を共有コントロールの課題に変える。

Prosimo の判断は、ルーティング権限をレイヤー3 到達可能性のみに基づかせるべきではない、というものだった。同社は、クラウド資産インベントリ、ネットワーク状態、アプリケーションアイデンティティ、ユーザーアイデンティティ、リスク、パフォーマンス、トランザクションテレメトリーを組み合わせようとした。このコンテキストは、アプリケーションへの接続、セグメントの隔離、入口地点の選択、特定トラフィックのファイアウォール経由といった、より具体的なポリシーを支えることができる。価値は新たな光ファイバーパスを作ることにあるのではなく、既存のパスとサービスをどう組み合わせるかを決定することにある。

これが、Prosimo が「アプリケーション体験インフラストラクチャ（application experience infrastructure）」という表現を用いる理由でもある。アプリケーションリクエストは、個々のネットワークオブジェクトの上位に置かれる。VPC、VNet、サブネット、トランジットハブ、プライベートリンクは、管理の最終目的ではなく、エンドツーエンドパスを構成する一要素に過ぎない。このアプローチは、製品をクラウドネットワーキング、アプリケーションデリバリー、ゼロトラストアクセス、ネットワークアシュアランス、コスト最適化、セキュリティサービス挿入という、複数の市場に同時に位置づけることにもなる。

機能の幅広さは機会をもたらす一方で、曖昧さも生む。複数のチームにまたがるプラットフォームは、単一のチームが責任を持てない調整の失敗を解決できるが、ネットワーク、セキュリティ、クラウド、アプリケーション、財務の各チームが異なる成功基準を用いるため、評価も難しくなる。Prosimo は、統合モデルが運用を改善し、高い権限を持ち一つのミスが全環境に影響を及ぼす集中型レイヤーにならないことを証明しなければならなかった。

Prosimo とは何だったのか、そして今何が残っているのか

Prosimo は、2019 年に設立され、サンフランシスコ・ベイエリアに本社を置く非公開のクラウドネットワーキングソフトウェア企業である。Ramesh Prabagaran 氏が独立運営期間中に共同創業者兼 CEO を務め、Nehal Bhau 氏が共同創業者兼 CTO を務めた。公開経歴では、Linus Aranha 氏や Pradeep Aragonda 氏も創業または上級エンジニアリングリーダーとして関連付けられているが、正確な役職は具体的な日付のプロファイルに基づくべきである。

主要プラットフォームは Application eXperience Infrastructure、略称 AXI であった。AXI は、中央ソフトウェア層を通じてインテント、トポロジー、分析、オーケストレーションを管理し、分散型 AXI Edge をクラウドリージョン、コロケーション施設、または近接するオンプレミスインフラに展開する。その後、同社は Full-Stack Cloud Transit として製品構成を再編し、Network Transit と App Transit が異なる種類の接続を処理した。AIR はテレメトリーを分析して運用インサイトを生成し、Nebula は 2024 年に自然言語インタラクションを追加した。

Prosimo はクラウドオペレーターではなく、全リージョンを接続するグローバル光ファイバーバックボーンを所有していたわけでもない。経路は、クラウドプロバイダーのバックボーン、公共インターネット、Direct Connect や ExpressRoute、コロケーションリンク、キャリア回線、企業ネットワークを経由していた。また、Palo Alto Networks と同種のファイアウォールベンダーでもなかった。2024 年の統合では、Prosimo が検出、セグメント化、トラフィック誘導を担当し、VM-Series がディープセキュリティ検査を担った。

買収後の最も無難な呼び名は「テクノロジー系統」である。その後の統合声明では、マルチクラウド資産検出と、ソフトウェアファイアウォールのイングレス、イグレス、東西トラフィックへの展開迅速化が強調された。これは、Prosimo の重要なコンポーネントが存続していることを示すが、歴史上の完全な AXI 製品カタログ、商用パッケージング、サポートモデルがすべてそのまま継続していることの証明にはならない。

SD-WAN の後に現れた新たな難題

創業チームは、大規模ネットワーク、アプリケーションデリバリー、クラウドインフラストラクチャにおける幅広い経験を有していた。Prosimo はまた、Viptela に関連する広範な創業者・エンジニアのエコシステムに属していた。Viptela は SD-WAN をエンタープライズ市場における明確なカテゴリーとして確立することに貢献した企業である。しかし、その後の課題は異なっていた。SD-WAN は支店とネットワークまたはアプリケーションとの関係をシンプルにすることはできても、複数のパブリッククラウドにまたがる統一運用モデルを自動的に確立するわけではない。

マルチクラウドアプリケーションは、ある環境の Web エンドポイント、別の環境のデータベースやマネージドサービス、そのどちらでもない場所のアイデンティティプロバイダー、データセンターに接続するプライベートリンク、特定の境界に展開されたセキュリティ検査に依存することがある。これらの依存関係は、それぞれ異なるクラウドネイティブオブジェクトとして表現されうる。ネットワークチームにはプレフィックスとトランジットハブが見え、クラウドチームにはアカウントとリソースが、アプリケーション担当者にはドメイン名とトランザクションが、セキュリティチームにはゾーンと検査ポリシーが見える。

Prosimo は支店ではなく、リクエストを起点とした。真の問いは、ユーザーやワークロードが、許容可能なセキュリティ、パフォーマンス、可用性、コストでアプリケーションにアクセスするにはどうすべきか、である。これにより、ルーティングの対象は宛先プレフィックスから、アイデンティティとアプリケーションコンテキストを伴うトランザクションへと拡大する。プラットフォームは従来のルーターよりもはるかに多くの情報を収集し、維持しなければならない。

市場のタイミングも追い風だった。AWS、Azure、Google Cloud は、ネイティブなトランジットサービスやプライベート接続サービスを拡充していた。企業は単一クラウド内で複雑なネットワークを構築できるが、API、オブジェクト、ポリシーモデルは依然としてベンダーごとに異なる。Prosimo の機会は、それらをプライベートバックボーンで置き換えることではなく、これらのクラウドネイティブ機能を調整することにあった。

2019 年の設立から 2021 年の正式発表まで

Prosimo は 2019 年に設立されたが、正式な公開発表が行われたのは 2021 年 4 月 6 日だった。General Catalyst が発表時に 2,500 万ドルのシリーズ A ラウンドをリードした。投資家はこの機会を、クラウドを横断してアプリケーション体験を提供するものと位置づけ、これは創業チームが従来の支店接続を超えて新たなカテゴリーを構築するというビジョンと合致していた。

発表当時の市場は、混雑していると同時に未定義だった。クラウドプロバイダーはネットワークサービスの利用障壁を下げ、SD-WAN や SASE ベンダーはクラウドへのポリシー拡張を進め、アプリケーションデリバリーベンダーはリクエストの最適化を、セキュリティベンダーはトラフィック検査を行っていた。Prosimo は、これらの能力をクラウド指向のアーキテクチャ上で連携させつつ、周囲のシステムをすべて置き換えると主張しないことを証明しなければならなかった。

調達した資金により、統合機能、ソフトウェア Edge、分析システム、営業チーム、パートナーチャネルの開発が可能になった。しかし、調達自体は製品市場適合、収益規模、長期的な差別化を証明するものではない。入手可能な資料には、監査済み収益、年間経常収益、総顧客数、評価額は示されていない。調達の記録は、投資家がある市場判断に賭けたことを証明するものであり、完全な運営成績表ではない。

2022 年、Prosimo は超過応募となったとされる 3,000 万ドルのシリーズ B ラウンドを完了した。明確に特定された 2 回のラウンドを合計すると、確認された累計額は少なくとも 5,500 万ドルとなる。一部のデータベースでは、発表の重複記録や関連エントリーにより、より高い数字が示される場合がある。基礎となるイベントを照合する前に、そうした数字を使用すべきではない。

AXI はポリシーをクラウドの上に置き、実行はワークロードの近くに配置する

AXI アーキテクチャは、中央のコントロール・分析層と、分散されたソフトウェア Edge に役割を分割する。中央層はアプリケーションとネットワークのインテントを保持し、資産を発見し、トポロジーを組み立て、アイデンティティを接続し、テレメトリーを分析し、変更をオーケストレーションする。AXI Edge はワークロードやユーザーの近くに展開され、ポリシーが遠隔の物理的中心に依存して実行される必要をなくす。

この分離は他のソフトウェア定義システムと類似しているが、クラウドネイティブでアプリケーションセマンティクスを持つオブジェクトを扱う点が異なる。コントローラーはクラウドアカウントと API へのアクセスを必要とし、Edge はネイティブトランジットサービス、ワークロードネットワーク、プライベートエンドポイント、または外部経路への接続を必要とする。プラットフォームの力は、ふたつのビューの組み合わせに由来する。すなわち、クラウドの上に立つグローバルなインテントと、トラフィックに近いローカルな実行である。

アーキテクチャはまた、具体的な展開境界をもたらす。各 Edge はクラウドリソースを消費し、高可用性設計を必要とし、アップグレード、監視、保護されなければならない。コントロール層は、資産を発見しネットワーク状態を変更するために十分な権限を必要とする。企業は統一されたワークフローを得る一方で、その可用性と正確性が本番到達性に影響を与える管理システムを追加することになる。

Prosimo は時に「自律型クラウドネットワーク」という表現を使用した。エビデンスは自動化、提案、API 駆動のオーケストレーションを裏付けるが、人間のポリシー、クラウドサービス、アンダーレイトランスポートから独立して動作するネットワークを裏付けるものではない。運用担当者は依然として、インテントを定義し、アクセスを承認し、例外を処理し、結果に対する責任を負わなければならない。

AXI Edge は場所の選択であり、汎用仮想アプライアンスではない

AXI Edge は、クラウド VPC や VNet、コロケーション環境、あるいは近隣のインフラストラクチャに展開可能である。AWS の技術ドキュメントでは、Edge VPC が Transit Gateway を介してワークロード VPC に接続し、オプションでファイアウォールを直列に配置し、同時にオンプレミスサイトやリモートユーザーに接続する構成が示されている。実行ポイントはクラウドトポロジーの内部にあり、遠く離れたエンタープライズ境界ではない。

場所が影響するのはレイテンシーだけではない。それは、トラフィックがどこでポリシードメインに入るか、クラウドバックボーンまたはインターネットパスのどの部分が使用されるか、暗号化と検査がどこで行われるか、そしてプラットフォームがどのテレメトリーを可視化できるかを決定する。不適切な場所は迂回やコストをもたらし、適切な場所はパスを短縮し、トラフィックをワークロードに近づける可能性がある。

分散展開は故障ドメインを増やす。異なるリージョンでは、容量、ソフトウェアバージョン、アベイラビリティゾーン設計、ルーティング収束、アクセス権限が異なりうる。高可用性とは単に2つのインスタンスを稼働させることではない。コントローラー、クラウドルーティングテーブル、セキュリティサービス、リターンパスも、フェイルオーバー状態について一貫した判断を下さなければならない。

したがって、Edge はより大きな運用システムの一部である。その価値は、資産発見、トポロジー、ポリシー、分析が、周囲のクラウド環境と整合しているかどうかに依存する。これを独立した仮想アプライアンスと見なすと、Prosimo が実際に販売していたアーキテクチャを見失うことになる。

基盤となる転送は常に他の参加者に属する

Prosimo は転送を調整するが、物理パスを所有しているわけではない。アプリケーショントラフィックは、AWS や他のクラウドプロバイダーのバックボーン、公共インターネット、Direct Connect、ExpressRoute、コロケーション接続、キャリア回線、または企業独自のネットワークを使用する可能性がある。プラットフォームは利用可能な選択肢の中から選択しオーケストレーションできるが、これらのプロバイダーに起因するレイテンシー、パケットロス、故障ドメイン、課金ルールを排除することはできない。

この境界は、パフォーマンスに関する約束を理解する上で極めて重要である。コントローラーは観測されたより良いパスを選択したり、入口をユーザーにより近く配置したりできるが、キャリアが故障しないことや、クラウドリージョンが停止しないこと、外部依存が常に高速応答することを保証することはできない。アプリケーション体験は DNS、サーバー処理、ストレージ、ブラウザの挙動、サードパーティーサービスにも影響を受けるが、これらはネットワークコントローラーが完全に支配できるものではない。

プライベートバックボーンを所有しないことは、単なる弱点ではない。Prosimo は企業が既に調達しているインフラストラクチャを活用し、クラウドプロバイダーの投資から利益を得ることができた。光ファイバーを敷設することなくより多くのリージョンに進出したり、AWS Cloud WAN のようなネイティブシステムを調整したりすることも可能だった。その代償は、API の安定性、サービスクォータ、商用条件、各ベンダー固有のセマンティクスへの依存である。

したがって、Prosimo の主張は物理的所有権ではなく、運用上のコントロールである。同社は、異種混合のアンダーレイを統一された管理モデルの下で動作させつつ、それぞれのネイティブな利点を保持しようとした。この抽象化がロックインを低減するのか、それともロックインをコントローラーに移すだけなのかは、ポリシー、トポロジー、Edge 展開の移植性にかかっている。

Network Transit はネットワークオブジェクト間の到達性を扱う

Network Transit は VPC、VNet、サブネット、リージョン、サイト、セグメントを対象とする。クラウドネイティブなトランジットハブとルーティングオブジェクトを調整し、チームがクラウドごとに個別に操作するのではなく、統一されたワークフローで接続を確立できるようにする。これは、特定の送信元やセグメントが、許可されたパスを通じて宛先に到達しなければならないという、古典的なネットワーク要件を解決するものだ。

これはクラウド間の差異がなくなることを意味しない。AWS、Azure、Google Cloud は異なるオブジェクト、クォータ、ルーティング動作を公開している。アドレスの重複、非対称パス、プライベートエンドポイント、ベンダー固有のサービス制限は、依然としてエンジニアリングによる対処を必要とする。Prosimo は一般的な操作を標準化し、関係を可視化できるが、基盤となるシステムは独自の制約を保持し続ける。

Network Transit はセグメンテーションも担当する。ルーティングドメインとポリシーは、環境を隔離したり、到達性を制限したりできる。コントローラーは、特定のセグメントが複数のクラウドでどのように存在するか、そしてネイティブオブジェクトがこの境界をどのように実施するかを理解する必要がある。単一の統一ポリシーが、複数組のベンダー固有の変更に変換される可能性がある。

統一されたインテントインターフェースは利点だが、変換はリスクである。宣言されたポリシーと実際のクラウド設定が乖離した場合、企業はあるセグメントが保護されていると信じながら、実際の状態はそうでない可能性がある。調整、監査、明確な障害状態は、初期設定と同じくらい重要である。

App Transit はアプリケーション自体をルーティングの対象にする

App Transit はモデルをサブネットからアプリケーションへと拡張する。アプリケーションのドメイン名、アイデンティティ、リクエストの種類、トランザクションの健全性、リスク、パフォーマンスに基づいて、ユーザーやワークロードがサービスにどのようにアクセスすべきかを決定できる。これは、Prosimo が従来のクラウドルーターと最も明確に異なる点のひとつである。

アプリケーションの視点が価値を持つのは、現代のサービスが必ずしも静的なアドレスに対応するわけではないからだ。マネージドプラットフォーム、SaaS エンドポイント、分散コンポーネントは変化しうるが、アプリケーションアイデンティティには依然として意味がある。サービスやユーザーを対象とするポリシーは、アドレスとポートだけに基づいて記述されたルールよりも長持ちする可能性がある。

このモデルは正確な検出に依存する。コントローラーは、どのドメイン名とエンドポイントがアプリケーションに属するか、どの依存関係が必須か、アイデンティティプロバイダーのどのクレームが信頼できるかを把握していなければならない。古いマッピングは、リクエストを誤ったパスに導いたり、間違ったポリシーを適用させたりする可能性がある。アプリケーションの抽象化は、ネットワーク状態の理解を不要にするのではなく、その上に意味層を追加するものだ。

Network Transit と App Transit の組み合わせは、企業にふたつのタイプのシステムが共存していることを認識している。従来の IP ワークロードとプライベートサブネットは依然として存在し、新しいアプリケーションはドメイン名、アイデンティティ、マネージドサービスに依存している。Full-Stack Cloud Transit の意義は、どちらか一方に置き換えを強いるのではなく、両方のモデルを同一の運用フレームワークに置くことにある。

アイデンティティはルーティング判断を拡大し、信頼境界も拡大する

アプリケーションを意識したアクセスには、アイデンティティの統合が必要になる。プラットフォームは、ユーザーやワークロードのコンテキストに基づいて、接続を確立するかどうか、どのパスを使用するかを決定できる。これは、場所だけではアクセス権を証明するのに不十分であるという、ゼロトラスト型のポリシーをサポートする。

アイデンティティはポリシーの精度を高める一方で、新たな依存関係を持ち込む。ルーティングやアプリケーションポリシーは、今やアイデンティティプロバイダー、そのクレーム、セッション状態、グループデータに依存する。ルーターや Edge が健全でも、認証サービスが利用不能になったり、属性が変更されたりすると、パス障害が発生しうる。トラブルシューティングは、ネットワークとアイデンティティ運用の境界を越えなければならない。

また、コントローラーは機密性の高いコンテキストを集中管理することになる。トポロジー、アプリケーション関係、ユーザー属性、リスクシグナル、ポリシーの結果を保持する可能性がある。これらのデータは診断や最適化に役立つが、不正アクセスの影響をより深刻にもする。最小権限、保持期間、監査、職務分掌は、したがってアドオンの管理作業ではなく、アーキテクチャ上の要件である。

Prosimo は、より広範なインフラストラクチャの変化を反映している。ルーティングとアクセスポリシーは、ますますアイデンティティとアプリケーションセマンティクスに依存するようになっている。プラットフォームが把握するコンテキストが増えれば増えるほど、判断の価値は高まる可能性があるが、その特権もまた、より厳格なガバナンスを必要とする。

資産発見が、後続のすべての決定が依存するマップを構築する

クラウドを跨ぐコントローラーは、可視化できないオブジェクトを管理することはできない。Prosimo は、VPC、VNet、サブネット、アプリケーション、接続、セキュリティ関係を表現するクラウド資産の発見とマッピングを開発した。これらのビューは、オンボーディング、設計、トラブルシューティング、ポリシー設定に使用される。

発見機能が重要なのは、クラウド環境がしばしば中央のネットワーク変更プロセスの外部で変化するからだ。アプリケーションチームは独自の自動化を通じて、アカウント、ネットワーク、エンドポイント、マネージドサービスを作成できる。手動で維持される図面はすぐに陳腐化する。API 駆動のインベントリは通常は高頻度で更新されるが、完全性はアカウントのカバレッジ、権限、解析ロジック、クラウド API に依存する。

このマップは文書化のためだけでなく使用される。ルーティング、セグメンテーション、サービス挿入、最適化は、これに基づいて計算される可能性がある。ひとつの資産や依存関係を見落とせば、上位の結論を歪めかねない。したがって、トポロジーは来歴情報を保持しなければならない。すなわち、いつ収集されたか、どのアカウントからか、どのリージョンをカバーするか、リクエストの失敗はあったか、である。

これは買収の説明にも役立つ。Palo Alto Networks は、ワークロードとトラフィックパスがどこにあるかを把握して初めて、セキュリティ機能をより効果的に展開できる。クラウド資産を発見し、ルーティングを変更できるシステムは、ソフトウェアファイアウォールを購入してから正しい場所に配置するまでの距離を短縮できる。Bhau 氏のその後の声明は、まさに資産検出とソフトウェアファイアウォール展開の迅速化を強調している。

AIR は Edge のテレメトリーを運用上の推奨に変換する

Application-driven Intelligent Results（AIR）は、AXI Edge が収集したテレメトリーを分析する。AWS の技術ドキュメントには、ラウンドトリップ時間、処理時間、アプリケーション応答時間、トランザクションタイプ、リスク、ポリシー結果が挙げられている。プラットフォームは、単に独立したデバイスカウンターを表示するのではなく、ユーザー、ネットワーク、アプリケーションの観測結果を関連付けることができる。

この相関が対象とするのは、一般的な運用課題だ。トランザクションの低速化の原因は、ユーザーパス、Edge、クラウドバックボーン、セキュリティサービス、あるいはアプリケーション自体にあるかもしれない。レイヤーを横断するビューは、複数の独立したコンソールよりも迅速に調査範囲を絞り込み、パス、場所、リスク、コストに関する推奨を提示できる。

推奨の質は、テレメトリーのカバレッジと解釈モデルに依存する。Edge は自身を通過するトラフィックしか見ることができず、外部アプリケーションの依存関係やクラウドプロバイダー内部の状態は可視化できない可能性がある。したがって、推奨は方向性としての価値を持ちうるが、必ずしも根本原因を証明するとは限らない。

テレメトリーにはガバナンス上の価値もある。履歴データは、特定のルーティングやポリシーがなぜ変更されたのかを説明できるが、機密性の高いアプリケーションの使用状況やユーザーの行動を露呈する可能性もある。公開情報は、データ保持や買収後のデータガバナンスについて完全には説明しておらず、これらの点は顧客のデューデリジェンス範囲に残る。

AWS が公開情報の中で最も明確な実装事例を提供している

Prosimo と AWS の協業は、最も強力な公開技術エビデンスを形成している。同社は AWS Transit Gateway、Cloud WAN、PrivateLink、Marketplace for Containers Anywhere と統合した。AWS は、AXI Edge の配置、アプリケーションアクセス、アイデンティティ、セキュリティ、最適化のプロセスを公開している。

AWS Cloud WAN は特に重要だ。これはクラウドネイティブなバックボーンとセグメンテーション機能を提供し、Prosimo はこれを置き換えるのではなく、オーケストレーションする。両者の役割分担は明確である。AWS はネイティブネットワークとグローバルインフラストラクチャを所有し、Prosimo はクラウド横断的なインテント、アプリケーションコンテキスト、Edge ソフトウェア、分析を提供する。

Marketplace のワークフローは Day-1 の展開を簡素化するが、アカウント権限、ルーティング設計、高可用性、キャパシティ、長期的な運用課題を排除するわけではない。Day-0 の自動化は導入の摩擦を低減できるが、継続的なガバナンスの代わりにはならない。

Prosimo の資料は、Flexport の顧客の声を引用し、AWS Cloud WAN のユースケースを裏付けている。これは、ある企業顧客がこのアーキテクチャを推奨する意思を示しているが、展開規模、コスト削減、可用性に関する独立した監査ではない。顧客の声は、普遍的なパフォーマンスの証明ではなく、採用事例と見なすべきである。

Azure と Google Cloud がマルチクラウドの主張を完成させる

Prosimo は Microsoft Azure と Google Cloud もサポートしていた。製品資料は、Azure Virtual WAN や Google Cloud のネットワーキングおよびプライベートサービスオブジェクトを中心としたオーケストレーションを説明している。目標は、各クラウドのネイティブネットワークを保持しながら、統一された運用モデルを提供することである。

サポートが機能の完全な同等性を意味するわけではない。クラウド API は異なる速度で進化し、類似した製品名が異なるセマンティクスを隠蔽している可能性がある。ルーティング、セグメンテーション、プライベートエンドポイント、サービス挿入には、ベンダー固有の処理が必要になるかもしれない。既存の証拠は、すべてのリージョンとバージョンを網羅した機能比較表を再構築しているわけではない。

したがって、マルチクラウドの抽象化は、むしろ翻訳システムに近い。共通のインテントとワークフローを正規化できるが、セキュリティ、コスト、障害に影響を与える差異を保持しなければならない。インターフェースが統一されているように見えながら、実装の違いが運用者に見えない場合、抽象化は危険になる。

これは買収後も同様である。Palo Alto Networks は統一されたマップを使用してセキュリティをクラウド横断的に配置できるが、クラウドプロバイダーは依然として実装パスを構成するネイティブオブジェクトを管理している。オーケストレーション層を所有することは、クラウドのアンダーレイを所有することと同じではない。

製品は接続から運用ライフサイクル全体へと拡張された

2023 年までに、Prosimo は製品を、単なるトンネルやゲートウェイではなく、マルチクラウドネットワークの設計、構築、トラブルシューティング、管理をサポートする完全なワークフローとして説明するようになっていた。資産検出が設計を支え、オーケストレーションが接続を作成し、マップとテレメトリーが診断に使われ、ポリシーと履歴状態が継続的な管理を支える。

このポジショニングは潜在的なバイヤー層を拡大した。ネットワークチームはトポロジーとパス分析を使用し、クラウドプラットフォームチームはアカウントとサービスに接続し、セキュリティチームはセグメンテーションと検査パスをチェックし、移行チームは変更を計画し、FinOps チームは下り（egress）コストとパスを評価する。複数のチームが同じエビデンスを共有するとき、プラットフォームの価値は増大する。

しかし、エビデンスの共有はガバナンス上の対立も引き起こす。中央プラットフォームは、クラウドチームのネイティブ設定が企業ポリシーと矛盾していることを発見するかもしれない。組織は、どのシステムが信頼できる唯一の情報源（source of truth）であるか、誰が修正を承認できるかを決定しなければならない。ソフトウェア自体が、この制度的な問題を解決することはできない。

ライフサイクルの物語は、スイッチングコストも引き上げる。いったんコントローラーが資産マップ、ポリシー、テレメトリー、Edge の配置、自動化統合を保持すると、それを交換することは単に回線を移すだけでなく、運用モデルをエクスポートするか再構築することを意味する。Prosimo はクラウドの断片化を解決する一方で、コントローラーへの依存も生み出しうる。

セグメンテーションはレイヤー3 の到達性からレイヤー7 のアプリケーションポリシーへと拡張される

Prosimo はセグメンテーションをレイヤー3 からレイヤー7 までカバーすると説明していた。ネットワーク層では、ルーティングドメインとセグメントが、どのサブネットやサイトが通信できるかを決定する。より上位層では、アプリケーションアイデンティティ、ユーザーコンテキスト、トランザクション属性が、ルールをさらに詳細に規定できる。

このモデルは、ネットワークゾーンとアプリケーションポリシーの間の距離を縮めうる。特定のビジネスサービスは許可される一方、広範なサブネット間通信は依然としてブロックされる。逆に、ネットワークパスが到達可能であっても、アイデンティティやアプリケーションコンテキストが一致しなければ拒否される可能性がある。

これは Prosimo を完全な次世代ファイアウォールに変えるものではない。2024 年の Palo Alto との統合では、役割分担が明確だった。Prosimo がトラフィック誘導、セグメンテーション、サービス挿入を担当し、VM-Series がディープインスペクションを担当した。ポリシーに基づく誘導とセキュリティの実施は、異なる故障モードを持っており、混同してはならない。

セグメンテーションは、関連するすべてのパスが表現されている場合にのみ有効である。未知のルート、クラウドネイティブの例外、失敗したサービス挿入は、いずれも制御を迂回する可能性がある。保証のためには、宣言されたポリシー、実際のクラウド状態、観測されたトラフィックを相互に検証することが必要であり、コンソール上の設定を信頼するだけでは不十分である。

サービス挿入はルーティング制御とファイアウォールの経済性を結びつける

クラウドセキュリティの設計では、検査をどこで行うかを決定しなければならない。集中型ファイアウォールはポリシーを簡素化し、インスタンス数を削減できるが、トラフィックの引き戻し（tromboning）、集中リスク、キャパシティへの負荷を生む可能性がある。分散型ファイアウォールはワークロードの近くに配置されるが、展開、ライセンス、アップグレード、ポリシー運用の数を増やす。

Prosimo の VM-Series 統合は両方のモードをサポートする。ポリシーは、特定のトラフィックを中央の検査ポイントに誘導することも、アプリケーション VPC 内の分散ファイアウォールに誘導することもできる。Prosimo が周囲のルーティングを変更し、Palo Alto Networks が検査機能を提供する。

このアーキテクチャにより、ルーティングオーケストレーションがセキュリティベンダーにとって商業的な価値を持つようになる。ソフトウェアファイアウォールは、そこを通過しないトラフィックを保護することはできない。検出、場所の選択、ルーティングの更新は、セキュリティ機能を購入してから実際に本番パスに組み込むまでの距離を縮めることができる。これは、Palo Alto Networks が Prosimo の技術を買収した合理的な戦略的動機のひとつである。

同時に、コントローラーの故障半径も拡大する。誤ったポリシーは、検査を迂回させたり、ループを形成したり、非対称ルーティングを引き起こしたり、アプリケーションを停止させたりする可能性がある。ヘルスチェック、段階的な変更、シミュレーション、監査、ロールバックは、サービス挿入の誤りがネットワーク上の出来事であると同時にセキュリティインシデントでもあるために、必要不可欠である。

2024 年の協業を買収完了の証拠とみなすことはできない

Prosimo と Palo Alto Networks は、2024 年 6 月 12 日に VM-Series 統合を発表した。発表は共同の技術的・商業的ソリューションを説明するものであり、Palo Alto Networks が Prosimo を買収したとは主張していなかった。この協業を所有権の証拠として扱うことは、ふたつの異なる出来事を混同することになる。

協業は確かに橋渡しとなった。Prosimo は、自社のルーティングとポリシーシステムが VM-Series のクラウド横断展開をいかに簡素化するかを示すことができ、Palo Alto Networks は実際の統合の中で技術を評価することができた。公開情報は買収プロセスを説明していないため、この協業が正式な買収前のステップであったと推測することはできない。

2025 年初頭までに、創業者と従業員の経歴に変化が生じ、企業ページにはその後「買収済み」と表示されるようになり、2025 年末には Bhau 氏は技術は完全に統合されたと述べた。これら 3 種類の証拠を合わせると、買収の結論を支持するのに十分だが、依然として法的な取引の詳細は埋められない。

この時系列は顧客にとっても重要である。協業は、2 つのベンダー、2 つのサポート体制、明確な統合境界を意味する。買収は、ロードマップ、データ、契約、権限を 1 つの企業に移管する可能性がある。技術的な経路が表面的に似ていても、ガバナンス上の意味合いは変化している。

Nebula はトポロジーマップを会話型インターフェースに変える

Prosimo は 2024 年 2 月、マルチクラウドネットワーキング向け AI Suite の一部として Nebula を発表した。これは、アドレスの重複、コスト、ルーティングの健全性、セキュリティポリシー違反などに関する質問に、自然言語で回答するよう設計されており、これらの質問はすべてプラットフォームのマップとテレメトリーに依存している。

本当に価値のある資産は、言語インターフェースそのものではなく、基盤となる構造化されたコンテキストである。汎用モデルは、可視化できないプライベートルートを診断することはできない。Nebula は、Prosimo がすでに収集した資産、トポロジー、ポリシー、観測データを呼び出すことができるため、統一マップへのそれまでの投資が AIOps の基盤となったのである。

会話型アクセスは、より多くの運用担当者が複雑なデータを利用できるようにする一方で、誤った自信を生む可能性もある。回答は、サポート対象外の資産を除外していたり、質問を誤解していたり、推奨を承認済みのアクションであるかのように提示しているかもしれない。リスクの高い変更には、依然として確定的な制御、権限境界、人間によるレビューが必要である。

Prosimo は、平均修復時間（MTTR）を 60～80% 削減し、クラウドネットワーキングコストを 60% 以上削減できる可能性があると主張していた。これらの数字はベンダーの製品発表に基づくものであり、その普遍的な適用可能性を証明する独立した方法論や顧客ベースラインは存在しない。これらは Prosimo が掲げた目標として引用することはできるが、実証された業界の事実として扱うことはできない。

AI ワークロードは新しいユースケースだが、新しい市場が確立された証拠ではない

同じ 2024 年の発表では、Prosimo のアーキテクチャが AI ワークロードにも適していると説明された。分散 AI システムは、プライベートデータアクセス、クラウドとデータセンター間の接続、コンプライアンス制御、アプリケーションを意識したルーティングを必要とする場合がある。これらの要件は、既存の資産、ポリシー、パスモデルと合致する。

「AI」というラベルがアンダーレイを変えるわけではない。Prosimo は依然としてクラウドネットワーク、通信事業者、顧客のインフラストラクチャに依存しており、GPU コンピュートやモデル開発ソフトウェアを提供するわけではなかった。その潜在的な役割は、分散されたデータとサービスの周囲に接続性とセキュリティを提供することである。

このポジショニングは、データとサービスが分散しているほど、クラウド横断的なトポロジーが価値を持つため、戦略的には理にかなっているが、これは同社が独立した運営を終了する直前に導入されたマーケティングカテゴリーでもあった。既存の証拠には、独立した AI 収益、名前の挙がった本番展開、監査済みの結果は含まれていない。

持続可能な結論は、マルチクラウドのテレメトリーが機械支援運用のインプットになりうるということである。今日の問題は、Palo Alto Networks がこれらのコンテキストを保持しているかどうか、そしてどのようにケイパビリティを顧客に公開するかである。公開情報はこれに完全には答えていない。

ビジネスモデルは他者のインフラの上でソフトウェアを販売するものだった

Prosimo の独立した事業は、通信事業者モデルではなく、ソフトウェアのサブスクリプションとサービスモデルだった。顧客は自社環境に AXI Edge を展開し、クラウドアカウントをコントロール層に接続する。収益はライセンスもしくはサブスクリプション、サポート、プロフェッショナルサービス、チャネルから得ていたと考えられるが、入手可能な資料には具体的な価格や契約指標は示されていない。

このモデルでは、光ファイバーを所有することなくスケールすることが可能だった。ひとつのプラットフォームで、多数のリージョンや顧客環境をコーディネートできる。しかし、粗利益をアーキテクチャから推測することはできない。ベンダー API、Edge のライフサイクル、セキュリティ統合、エンタープライズ展開の継続的なサポートは高コストになりうるし、Edge が消費するクラウドリソースは顧客が直接負担していた可能性がある。

Prosimo は、クラウドマーケットプレイス、インテグレーションパートナー、チャネル、顧客事例を活用してエンタープライズ市場に参入した。異なる関係を同一視することはできない。マーケットプレイスへの掲載は調達・展開チャネルの存在を証明する。技術統合は、特定の条件下で 2 つのシステムが連携できることを証明する。顧客の声は参考情報を提供する。いずれか単独では、有料顧客数や経常収益を証明することにはならない。

製品の幅広さは販売の難易度を高める可能性もある。ネットワーク、セキュリティ、クラウド、アプリケーションの各チームが恩恵を受ける可能性があるが、予算の帰属が不明確である。Prosimo は、各チームが分散した運用を続けるのではなく、共通のコントロール層に対して支払う意思のあるバイヤーを必要としていた。

パートナー、顧客、投資家は異なる役割を果たす

AWS は、基盤となるインフラストラクチャプロバイダーであると同時に、マーケットプレイス統合パートナーでもある。Azure と Google Cloud はサポート環境である。アイデンティティプロバイダーは認証コンテキストを提供する。ファイアウォールベンダーは検査を提供する。コロケーション事業者や通信事業者は Edge をホストまたは接続する。チャネルパートナーは展開を設計し、代行運用することができる。

Flexport は、AWS Cloud WAN の資料で言及されている有名な顧客リファレンスである。これはエンタープライズ顧客がこのアーキテクチャに関心を持っていることを示すが、展開の全範囲、期間、商業的価値を示すものではなく、総顧客規模の代わりにはならない。

General Catalyst はシリーズ A をリードし、投資ガバナンスに関与した。企業資料には WRVI / Celesta に関連する投資家も登場し、その後の情報では BlackRock に関連する著名な参加が言及されているが、調査では具体的な投資ビークルを特定できなかった。これらの情報は、資金調達ネットワークが強固であることを示しているが、完全な株式資本構成表ではない。

Palo Alto Networks が最も重要な関係である。同社は 2024 年のセキュリティパートナーから、2025 年初頭には買収者へと変わった。このプロセスは、エコシステムパートナーが自社製品への経路にあるコーディネーションソフトウェア層を買収する際に、技術的依存が支配関係に転化しうることを示している。

確認された調達額は少なくとも 5,500 万ドル、イグジットの経済性は依然として不明

確認された調達ラウンドは、2021 年 4 月の 2,500 万ドルのシリーズ A と、2022 年の 3,000 万ドルのシリーズ B である。入手可能な資料には、監査済みの株式資本構成表、評価額、負債による資金調達、その後の資金調達は示されていない。

買収対価は開示されておらず、独立した検証も行われていない。価格がなければ、結果を「戦略的プレミアム」「通常の技術買収」「アクハイヤー」「ディストレスト取引」のいずれかに責任を持って分類することはできない。技術が統合され続けていることはその価値を示しているが、投資家や創業者の実際のリターンを示すものではない。

また、Palo Alto Networks の収益や市場規模を Prosimo のものとみなすことはできない。買収後、Prosimo はもはや単独で観察可能な経済単位ではなく、分析可能な独立した収益、利益、顧客セグメントは存在しない。より大きな所有者は、技術の利用範囲を拡大する一方で、その単体の経済性をより不透明にする可能性がある。

正式な買収発表がないこと自体も重要な事実である。通常、顧客、従業員、研究者は発表を利用して、タイミング、サポート、戦略的論理を判断する。ここでは、経歴情報、企業ステータスの表示、創業者のその後の声明から状況を再構築しなければならない。これは企業としての同一性を修正するには十分だが、取引条件をでっち上げるには不十分である。

競合は専門プラットフォーム、クラウドネイティブサービス、企業内製から生じる

Prosimo は、Aviatrix や Alkira といった専門のマルチクラウドネットワーキングプラットフォーム、エンタープライズネットワーキングや SASE ベンダー、そして AWS、Azure、Google Cloud のネイティブサービスと競合した。また、Infrastructure as Code、クラウドトランジットサービス、ルーティングテーブル、ファイアウォールを直接使用する企業の内製アプローチとも競合した。異なる代替手段は、同じ問題の異なる部分を解決する。

専門コントローラーはクラウド横断的な統一トポロジーとポリシーを提供する。クラウドネイティブな設計はサードパーティー依存を減らし、単一ベンダーへの密着度を高める。通信事業者サービスは物理転送を提供する。SASE やセキュリティプラットフォームは接続と実施を組み合わせる。内製エンジニアリングは、人件費と統合コストと引き換えに制御を得る。

Prosimo の差別化要因は、アプリケーションおよびネットワークトランジット、分散 Edge、クラウドネイティブオーケストレーション、トポロジー、テレメトリー、サービス挿入の組み合わせだった。同じ幅広さが比較を難しくもする。バイヤーは、実際に使用しているクラウドサービス、ルーティング、アイデンティティ、セキュリティパターンに照らしてテストする必要があり、カテゴリー名だけで比較すべきではない。

買収は競争の枠組みを変える。Prosimo はもはや独立企業として勝利する必要はなく、その技術は Palo Alto Networks 内部で価値を証明しなければならない。重要な比較は、統合された検出とルーティングオーケストレーションが、Palo Alto のセキュリティ製品の展開を改善するかどうか、そして顧客がそれに伴うプラットフォーム依存の増大を受け入れるかどうか、に移る。

クラウドネイティブサービスは基盤であり、代替手段でもある

AWS Cloud WAN、Transit Gateway、Azure Virtual WAN、Google Cloud のネットワーキング機能は、企業に強力なネイティブの選択肢を提供する。Prosimo はこれらに依存すると同時に、顧客がそれらを直接操作する選択肢とも競合していた。

この境界線は絶えず動いている。クラウドプロバイダーがグローバルルーティング、セグメンテーション、プライベートサービス、一元的なポリシーを追加すると、一部のサードパーティー機能はネイティブに複製されやすくなる。同時に、新たなネイティブサービスが追加されるたびに、クラウド横断コントローラーが発見しコーディネートすべき新しいオブジェクトが生まれる。クラウドの進歩は、Prosimo の価値の一部を縮小するかもしれないし、ベンダー間の変換ニーズを拡大するかもしれない。

決定的な要因は、やはり組織の能力である。単一クラウドで内製エンジニアリングが強力な企業は、ネイティブツールを好むかもしれない。チームが分断されたマルチクラウド企業は、統合コントロール層を必要とするかもしれない。規制対象の組織は、サードパーティーの証拠を重視する一方で、資格情報やデータの集中を懸念するかもしれない。

ロックインを完全に排除できるアーキテクチャは存在しない。ネイティブツールは特定のクラウドの API とセマンティクスに依存する。クラウド横断コントローラーは、そのマップ、ポリシー、Edge に依存する。真に問うべきは、依存関係が透明で、移植可能であり、組織の運用モデルに適合しているかどうかである。

障害はコントローラー、Edge、クラウド API、アイデンティティシステム、アンダーレイネットワークで発生しうる

分散アーキテクチャは、単一のトラフィック集中点への依存を減らす一方で、相互作用する複数の故障ドメインを生み出す。中央サービスが利用不能になったり、古いインテントを保持したりする可能性がある。Edge が故障したり、隔離されたりするかもしれない。クラウド API が変更の一部を拒否するかもしれない。アイデンティティシステムが停止するかもしれない。アンダーレイが劣化したり、経路変更されたりするかもしれない。挿入されたファイアウォールがリソースを使い果たすかもしれない。

部分的な障害は特に困難である。あるクラウドではルーティング更新が受け入れられ、別のクラウドでは拒否されると、コントローラーが期待する状態と実際の状態が乖離する。トラフィックは非対称パスをたどったり、検査を迂回したりする可能性がある。信頼性の高いシステムには、調整、べき等性のある操作、段階的な変更、明確なエラー通知、各ベンダーに適応したロールバックが備わっていなければならない。

公開されているエビデンスは、高レベルの可用性と最適化されたアーキテクチャについて記述しているが、独立した故障注入研究、完全なインシデント記録、普遍的なサービス実績は示されていない。したがって、レジリエンスに関する結論は、文書化されたアーキテクチャや有名な顧客の証拠の範囲内に限定されるべきである。

買収は新たな故障ドメインをひとつ追加する。それは製品の継続性である。顧客は、どのコンソール、API、Edge イメージ、ポリシーモデル、サポート組織が、従来の Prosimo システムに取って代わるのかを知る必要がある。コード統合が技術的に成功しても、商業面と運用面の境界があいまいなままでは、移行リスクが生じる。

クラウドクレデンシャルがコントローラーを重要な管理プレーンに置く

資産検出とオーケストレーションには、クラウドアカウントへのアクセスが必要である。読み取り専用のインベントリは限定的な権限で済むが、ルーティング、セグメンテーション、サービス挿入の変更には、より強力な権限が必要となる。そのため、コントローラーはワークロードを所有していないにもかかわらず、高い権限を持つ管理プレーンの内部に位置することになる。

クレデンシャルの漏洩は、トポロジーを露出させたり、広範な変更を許したりする可能性がある。ソフトウェアの欠陥や操作ミスは、複数のクラウドにポリシーを伝播させるおそれがある。プラットフォームが管理するアカウントとサービスが増えるほど、潜在的な故障半径は大きくなる。

企業は、最小権限のロール、検出用と書き込み用で分離されたクレデンシャル、複数人による承認、完全な監査、ローテーション、緊急時の無効化を実装し、同じコントローラーに依存しない回復パスを保持する必要がある。公開資料には完全な独立セキュリティ評価は含まれていないため、これらは検証済みの保証ではなく、必要な展開上のコントロールである。

テレメトリーマップも同様に機密性が高い。アプリケーション名、ネットワーク構造、ポリシー、ユーザー関係、ルーティングの健全性、コストパターンが露出する可能性がある。買収後のガバナンスでは、これらのデータがどこに保存され、どの Palo Alto Networks 製品がアクセスでき、従来の顧客権限がどのように移行されるのかを明らかにすべきである。公開情報はまだこれに答えていない。

買収は「中立的」と見なされていた制御層をセキュリティプラットフォームの中に置く

Prosimo は独立していたとき、自らをクラウドとセキュリティサービスを横断する共通のコントロール層と表現することができた。Palo Alto Networks が所有者になったことで、インセンティブ構造は変化する。買収した技術によって、VM-Series や他の Palo Alto 製品の展開が容易になる。これはより緊密な統合をもたらす可能性がある一方で、サードパーティーの検査サービスが引き続き対等にサポートされるかという疑問も生じさせる。

所有権の変更は、中立性が失われたことの証明にはならない。入手可能な資料には、現在のパートナーマトリックスや完全なアーキテクチャは示されていない。しかし、顧客が問うべき質問は変化している。コントローラーは引き続き複数のセキュリティベンダーをサポートするのか、ポリシーとテレメトリーはエクスポート可能か、最適化ロジックは所有者の製品ポートフォリオを優先するのか。

統合声明は、イングレス、イグレス、東西トラフィックの検査を強調している。これは、Prosimo のトポロジーとオーケストレーションがセキュリティ展開システムの一部になる可能性を示唆するが、歴史的な App Transit、ユーザーアクセス、コスト最適化、すべてのクラウドネットワーキングワークフローが独立した機能として存続することの証明にはならない。

これはインフラストラクチャ分野でよく見られるパターンである。スタートアップが複雑なコーディネーション問題を抽象化し、大規模プラットフォームベンダーが、コア製品の展開と制御を強化するためにその抽象化層を購入する。顧客はより良い統合を得るかもしれないが、ベンダー独立性の一部を失う可能性がある。

現在の製品マッピングが最大の欠落事実である

公開記録は買収と統合を確認しているが、AXI、Network Transit、App Transit、AIR、Nebula が、現在の Palo Alto Networks のどの製品や SKU に対応するのか、旧システムのサポート終了時期、移行プロセス、機能ごとの継続性一覧表は明らかにされていない。

したがって、現在時制を用いた製品レビューを行うことは不可能である。歴史的な資料は、Prosimo が何を構築し、なぜそれが重要だったかを説明できるが、今日どの機能が利用可能で、どのようにライセンスされ、誰がサポートするのかは示せない。現在進行中の展開に関するいかなる推奨も、アーカイブされた発表ではなく、Palo Alto Networks の現在のドキュメントに依拠しなければならない。

欠落したマッピングは、戦略分析も制限する。トポロジーマップとオーケストレーション層を完全に吸収するのと、資産検出とファイアウォールの配置選択だけを使用するのとでは、結果が異なる。前者は広範なマルチクラウドコントロールサービスを形成しうる。後者は主にセキュリティ展開を迅速化するために使われる。共同創業者の声明は技術の継続性を確認しているが、このアーキテクチャ上の境界を解決していない。

将来の製品ドキュメント、移行ガイド、顧客事例が、ほとんどの疑問を明らかにするかもしれない。それまでは、正確な表現は次のとおりである。ある共同創業者によれば、Prosimo の技術は Palo Alto Networks の製品に統合されたが、その範囲とパッケージングは公に検証されていない。

誰がマルチクラウドルーティングを制御するのか？

完全なパスを単独で制御する当事者はいない。企業は、アカウントの所有権、ビジネス上の意図、アプリケーション設計、付与されたクレデンシャルを管理する。クラウド横断的なコントローラーは、トポロジーを発見し、ポリシーを翻訳し、パスを選択し、ネイティブなルーティング状態を変更できる。クラウドプロバイダーは、API、トランジットサービス、プライベートエンドポイント、バックボーン、多くの故障ドメインを制御する。通信事業者とコロケーションプロバイダーは、他の転送部分を制御する。セキュリティサービスは、検査済みのトラフィックを許可するかどうかを決定する。

Prosimo が探し求めたのは、最も戦略的価値のある中間ポジションだった。アンダーレイを所有せずに、その上のマップとポリシー変換を掌握しようとしたのである。この層を制御する者が、どの資産を可視化するか、セグメントをどのように表現するか、Edge をどこに置くか、どのサービスがトラフィックを検査するか、どのテレメトリーを信頼できる唯一の情報源とみなすかを決定できる。光ファイバーが他者の所有であっても、これが事実上のルーティング権限である。

買収後、Palo Alto Networks は Prosimo の残存技術を所有し、その統合、商用パッケージング、開発の方向性を決定する。クラウドプロバイダーは依然として各環境内で支配的であり、企業もクレデンシャルを無効にしたり、別のアーキテクチャを選択したりすることができる。しかし、トポロジー、ポリシー、運用ワークフローがコントローラーに依存している場合、撤退コストは高くつく可能性がある。

したがって、答えは階層化されている。企業が権限を付与し、コントローラーがコーディネートし、クラウドと通信事業者のアンダーレイが転送を行い、セキュリティプラットフォームが実施する。Prosimo の歴史は、クラウドアカウントと物理パスの所有権が移動しなくても、コーディネーション層の所有権が変化しうることを示している。

主要な情報源の記録

買収された後も Prosimo が注目に値する理由

Prosimo は、ひとつの真の変化を捉えていた。ネットワーク運用の単位は、デバイスやプレフィックスから、アプリケーション、アイデンティティ、サービス依存関係、ポリシーマップへと移行しつつある。クラウドネイティブ API はネットワーク状態をプログラマブルにし、分散ソフトウェア Edge は実行場所を移動可能にする。複数のクラウドを見渡せるコントローラーは、単一クラウドのコンソールでは達成できないアクションをコーディネートできる。

同社はコーディネーションのコストも露呈させた。すなわち、共通コントロール層には、高い権限のクレデンシャル、継続的な API メンテナンス、正確な検出、セマンティックな翻訳、テレメトリー、運用規律が必要となる。それは断片化した作業を減らすことができる一方で、新たな集中点を生み出す。ルーティングを簡素化する同じシステムが、ひとつのミスの影響範囲を拡大する可能性もある。

Palo Alto Networks による買収は、コントロール問題をより鮮明にした。ネットワークとセキュリティは、サービス挿入、ワークロード検出、ポリシーを巡って融合しつつある。トポロジーを把握し、ルーティングを変更できるセキュリティベンダーは、単に目の前に届けられたトラフィックを検査するだけでなく、どのトラフィックを検査ポイントに到達させ、どこで検査するかを決定する手助けもできる。

したがって、Prosimo は、消え去った独立ブランドとしてだけ記憶されるべきではなく、また、あるプラットフォームがマルチクラウド問題を「解決」したことの証明として扱われるべきでもない。その長期的な貢献は、クラウドを横断するマップをインフラストラクチャとして定義したことである。残された問いは、このマップが大規模なセキュリティ企業の手に渡った後も、顧客が信頼するに足る透明性、移植性、ガバナンスを保っているかどうかである。