要約

  • Prosimoは2019年に設立され、2021年のシリーズAと2022年のシリーズBで少なくとも5,500万米ドルを調達した。監査済み売上高、評価額、買収価格は公表されていない。
  • AXIは、中央の意図・トポロジー・分析層と分散エッジを組み合わせ、物理バックボーンを所有せずにクラウド資産の発見、アプリ接続、セキュリティ挿入、テレメトリー収集を行った。
  • 2024年6月のVM-Series統合発表後、Prosimoは2025年2月ごろまでにPalo Alto Networksの傘下へ移ったが、正確な買収日、価格、現行製品との対応関係は明らかになっていない。
  • 制御は企業、オーケストレーションソフトウェア、クラウド事業者、Palo Alto Networksに分散している。トポロジー、認証情報、ポリシー、経路変更権限を移行できるかが、顧客にとって重要な判断材料となる。

企業としての独立性が失われても、問題は残った

2026年のProsimoを、現役の独立系ベンダーとして紹介するのは正確ではない。公開されている職歴を見ると、創業者と複数の従業員は2025年2月ごろPalo Alto Networksへ移っている。Prosimoの会社ページは買収済みと表示され、元最高技術責任者のNehal Bhauも後に、同社の技術がPalo Alto Networks製品へ統合されたと記した。これらの証拠は支配権の移転と技術価値の継続を示すが、契約締結日、取引完了日、法的形式、価格までは明らかにしない。

この訂正を冒頭に置く必要があるのは、すべての製品記述の時制が変わるからである。AXI、Network Transit、App Transit、Application-driven Intelligent Results、Nebulaは、独立経営期のProsimoの機能として記録されている。Palo Alto Networksが現在の製品・サポート対応表を公開しない限り、個別に販売中の現行製品として書くべきではない。過去のアーキテクチャは、組み込みコード、共有サービス、モジュール、社内エンジニアリング資産として買収後も残り得るが、これらは同じ状態ではない。

ブランドが消えたからといって、基礎にある問題がなくなったわけではない。企業は今もAmazon Web Services、Microsoft Azure、Google Cloud、プライベートデータセンター、コロケーション拠点、SaaS、遠隔利用者へワークロードを分散している。それぞれに固有のルート、ゲートウェイ、プライベートエンドポイント、アイデンティティ制御、セキュリティサービス、上限、課金規則がある。企業はアカウントを所有していても、ある要求が環境間をどう移動するのかを一つの画面で把握できないことがある。Prosimoの重要性は、その全体像を一つの運用層で把握し、制御しようとした点にある。

したがって買収は後日談ではなく、記事全体を貫く軸となる。Prosimoは、資産を発見し、アプリケーションの文脈を解釈し、セキュリティサービスへトラフィックを誘導できるクラウド横断制御層を築いた。Palo Alto Networksはまず、VM-Seriesファイアウォールをその経路に挿入する技術パートナーとして登場した。その後、技術の所有者となった。ルーティングオーケストレーションと深い検査を隔てていた境界が、一つのサイバーセキュリティ基盤の内部へ移ったのである。

マルチクラウドルーティングは文脈をめぐる競争である

ルーティングテーブルは、あるプレフィックスへ別のネクストホップ経由で到達できるかを答えられる。しかし、それだけでは、利用者がどのアプリケーションへ行こうとしたのか、要求者を信頼できるのか、検査サービスを通す必要があるのか、プライベートエンドポイントが利用できるのか、どのクラウド経路が高価なのか、パケット到着後にトランザクションが失敗しているのかまでは説明できない。マルチクラウド運用は、これらを一つの制御問題へまとめる。

Prosimoの主張は、ルーティング権限をレイヤー3の到達性だけで決めるべきではないというものだった。同社のソフトウェアは、クラウド資産一覧、ネットワーク状態、アプリケーションアイデンティティ、利用者アイデンティティ、リスク、性能、トランザクションテレメトリーを組み合わせようとした。これにより、特定アプリケーションの接続、セグメント分離、入口地点の選択、選択トラフィックのファイアウォール経由化といったポリシーを表現できた。価値は新しい光ファイバー経路の発明ではなく、既存の経路とサービスをどう組み合わせるかを決めることにあった。

この違いが、同社が「application experience infrastructure」という言葉を使った理由を説明する。管理の中心は個別ネットワーク構成要素ではなく、アプリケーション要求だった。VPC、VNet、サブネット、トランジットハブ、プライベートリンクは、管理対象の最終単位ではなく、端から端までの経路を構成する一要素となる。この考え方により、製品はクラウドネットワーキング、アプリケーション配信、ゼロトラストアクセス、ネットワークアシュアランス、コスト最適化、セキュリティサービス挿入という複数市場へ同時に踏み込んだ。

広い範囲は機会と曖昧さの両方を生んだ。複数チームにまたがる製品は、誰も単独では所有していない調整不全を解決できる。その一方、ネットワーク、セキュリティ、クラウド、アプリケーション、財務の各チームで成功の定義が違うため、評価は難しい。Prosimoには、クラウド横断モデルが運用を改善しつつ、その誤りがすべての環境へ波及する新たな特権層にならないことを示す必要があった。

Prosimoとは何だったのか、何が残ったのか

Prosimoは2019年設立の非公開企業で、サンフランシスコ・ベイエリアを拠点とするクラウドネットワーキングソフトウェア会社だった。独立経営期には、Ramesh Prabagaranが共同創業者兼最高経営責任者、Nehal Bhauが共同創業者兼最高技術責任者を務めた。公開職歴ではLinus AranhaとPradeep Aragondaも創業または上級エンジニアリングの役割に挙げられているが、正確な肩書は日付のある経歴資料に合わせるべきである。

主力基盤はApplication eXperience Infrastructure、通称AXIだった。AXIは、意図、トポロジー、分析、オーケストレーションを担う中央ソフトウェア層と、クラウドリージョン、コロケーション環境、または隣接するオンプレミス基盤に配置される分散AXI Edgeを組み合わせた。後に製品はFull-Stack Cloud Transitとして整理され、Network TransitとApp Transitが異なる接続種別を扱った。AIRはテレメトリーを分析して運用上の示唆を示し、2024年にはNebulaが対話型インターフェースを追加した。

Prosimoはクラウドキャリアではなかった。全リージョンを結ぶ世界規模の光ファイバーバックボーンを所有していない。経路はクラウド事業者のバックボーン、公衆インターネット、専用回線、コロケーション接続、企業ネットワークを通り得た。またPalo Alto Networksと同じ意味でのファイアウォールベンダーでもなかった。2024年の統合におけるProsimoの役割は、発見、セグメンテーション、誘導であり、深いセキュリティ検査はVM-Seriesが担った。

買収後の最も安全な表現は「技術的系譜」である。後の統合声明は、マルチクラウド資産発見と、イングレス、エグレス、東西方向の検査に使うソフトウェアファイアウォール配備の迅速化を強調した。これは重要なProsimo構成要素が残った証拠である。しかし、過去のAXI製品群、商用パッケージ、顧客サポートモデルがそのまま続いた証拠ではない。

SD-WANの次に現れた問題

創業チームは大規模ネットワーキング、アプリケーション配信、クラウド基盤の経験を持っていた。Prosimoは、SD-WANを企業市場の一分野として確立するうえで大きな役割を果たしたViptelaに連なる創業者・エンジニアの広い人脈からも生まれた。しかし次の問題は違った。SD-WANは支店からネットワークやアプリケーションへの接続を簡素化できても、複数のパブリッククラウド内部とその間に一つの運用モデルを作るものではなかった。

マルチクラウドアプリケーションは、ある環境のWebエンドポイント、別環境のデータベースやマネージドサービス、双方の外にあるアイデンティティプロバイダー、データセンターへのプライベート接続、選択された境界でのセキュリティ検査に依存し得る。各依存関係は異なるネイティブ構成要素で表される。ネットワークチームにはプレフィックスとトランジットハブが見え、クラウドチームにはアカウントとリソースオブジェクトが見え、アプリケーション所有者にはドメインとトランザクションが見え、セキュリティチームにはゾーンと検査ポリシーが見える。

Prosimoは支店ではなく要求から考え始めた。問うべきことは、利用者またはワークロードが、十分なセキュリティ、性能、可用性、コスト条件のもとでアプリケーションへどう到達するかだった。この枠組みは、ルーティング対象を単なる宛先プレフィックスから、アイデンティティとアプリケーション文脈を持つトランザクションへ広げた。その分、従来型ルーターよりはるかに多くの情報を収集し、維持する必要が生じた。

市場環境も追い風だった。AWS、Azure、Google Cloudはネイティブのトランジットサービスとプライベート接続サービスを拡張していた。企業は各クラウド内で高度なネットワークを構築できるようになったが、API、オブジェクト、ポリシーモデルは事業者ごとに異なった。Prosimoの機会は、それらを独自バックボーンへ置き換えることではなく、相互に調整することにあった。

2019年の設立から2021年の正式公開まで

Prosimoは2019年に設立されたが、正式公開を発表したのは2021年4月6日だった。公開時の2,500万米ドルのシリーズAはGeneral Catalystが主導した。同投資家は、複数クラウドにまたがるアプリケーション体験の提供という機会を強調しており、従来型の支店接続を超える分野を定義しようとした創業者の構想と一致していた。

公開時点の市場は混雑し、境界も定まっていなかった。クラウド事業者は自社ネットワークサービスを使いやすくしていた。SD-WANやSASEのベンダーはポリシーをクラウドへ拡張し、アプリケーション配信事業者は要求を最適化し、ネットワークセキュリティ企業はそれを検査できた。Prosimoの説得力は、周辺のすべてを置き換えると主張せず、これらの機能を一つのクラウド志向アーキテクチャで結び付けられるかにかかっていた。

資金は、統合、ソフトウェアエッジ、分析、販売組織、パートナー関係を築く余地を与えた。しかし、製品市場適合性、売上規模、持続的差別化を証明したわけではない。提供資料には、監査済み売上高、年間経常収益、顧客数、評価額がない。資金調達記録が示すのは、投資家が一つの仮説に資本を投じたことであり、業績の全体像ではない。

2022年、Prosimoは募集超過と説明された3,000万米ドルのシリーズBを完了した。明確に確認できる二つのラウンドを合計すると、資金調達額は少なくとも5,500万米ドルとなる。一部データベースは発表や関連記録を重複計上してさらに大きな数字を表示することがあるため、元の取引を確認せず使うべきではない。

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

AXIアーキテクチャは、中央の制御・分析層と分散ソフトウェアエッジの間で役割を分けた。中央層はアプリケーションとネットワークの意図を保持し、資産を発見し、トポロジーを組み立て、アイデンティティを統合し、テレメトリーを分析し、変更をオーケストレーションした。AXI Edgeはワークロードまたは利用者の近くに配置され、すべての経路を遠隔の物理ハブへ戻さずにポリシーを適用できるようにした。

この分離は他のソフトウェア定義システムにも似ているが、対象はクラウド固有で、アプリケーションを意識したものだった。コントローラーにはクラウドアカウントとAPIへのアクセスが必要で、エッジにはネイティブトランジットサービス、ワークロードネットワーク、プライベートエンドポイント、外部経路への接続が必要だった。クラウドの上にある全体的な意図と、関連トラフィックに近いローカル実行を組み合わせることで、基盤としての権限が生まれた。

同時に、実装上の境界も生じた。各エッジはクラウド資源を消費し、高可用性設計が必要で、更新、監視、保護の対象となった。制御層には、資産を発見しネットワーク状態を変えられる十分な権限の認証情報が必要だった。企業は共通ワークフローを得る一方で、可用性と正しさが本番到達性に影響する新たな管理システムを追加した。

Prosimoは自律型クラウドネットワーキングという表現を使うことがあった。証拠が裏付けるのは、自動化、推奨、API駆動オーケストレーションである。人のポリシー、クラウド事業者のサービス、下位の輸送経路から独立して動作するネットワークではない。運用者は意図を定め、アクセスを承認し、例外を処理し、結果への責任を負い続けた。

AXI Edgeは汎用アプライアンスではなく、配置の判断だった

AXI EdgeはクラウドのVPCやVNet、コロケーション環境、または隣接基盤へ配置できた。AWSの技術解説では、エッジVPCがTransit Gatewayを介してワークロードVPCへ接続され、必要に応じてファイアウォールを連鎖させ、遠隔利用者やオンプレミス拠点からアクセスする構成が示された。Prosimoの実行地点は遠隔の企業境界ではなく、クラウドトポロジー内部に置かれた。

配置は遅延だけでなく、トラフィックがどこでポリシードメインへ入るか、どのクラウドバックボーンまたはインターネット経路を使うか、どこで暗号化と検査を行うか、どのテレメトリーを収集できるかを決めた。不適切な配置は遠回りやコストを生み、適切な配置は経路を短くし、トラフィックをワークロード近くに保つことができた。

分散配置は、管理すべき障害ドメインの数を増やした。容量、ソフトウェア版、クラウドゾーン設計、経路収束、アクセス権はリージョンごとに異なり得る。高可用性は単に二つのインスタンスを動かすだけでは成立しない。コントローラー、クラウドルートテーブル、セキュリティサービス、戻り経路も同じフェイルオーバー状態を共有する必要があった。

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

アンダーレイは常に別の誰かの所有物だった

Prosimoは輸送を調整したが、物理経路を所有していなかった。アプリケーション経路は、AWSなどのクラウドバックボーン、公衆インターネット、Direct ConnectやExpressRoute、コロケーションサービス、通信事業者回線、企業ネットワークを使い得た。利用可能な選択肢から経路を選び、連携させることはできても、各事業者がもたらす遅延、パケット損失、障害ドメイン、料金規則をなくすことはできない。

この境界は性能主張を評価するときに重要である。コントローラーは観測上より良い経路を選び、入口を利用者に近づけられる。しかし、通信事業者の障害、クラウドリージョンの停止、外部依存先の遅延を防ぐ保証はできない。アプリケーション体験にはDNS、サーバー処理、ストレージ、ブラウザ動作、第三者サービスも含まれ、これらはネットワークコントローラーの完全な権限外にある。

独自バックボーンを持たないことは、単なる弱点ではなかった。企業が既に購入した基盤を利用し、クラウド事業者の投資から恩恵を受けられた。光ファイバーを敷設せずにリージョンへ到達し、AWS Cloud WANのようなネイティブシステムを連携できた。代わりに、APIの安定性、サービス上限、商用条件、事業者固有の意味論へ依存した。

したがって主張の対象は物理所有ではなく運用制御だった。異種アンダーレイのネイティブな利点を残したまま、一つの管理システムとして振る舞わせようとしたのである。その抽象化がロックインを減らしたのか、別の場所へ移しただけなのかは、ポリシー、トポロジー、エッジ配置の移植性に左右された。

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は、一方を他方へ置き換えるのではなく、両方を一緒に運用するための製品名だった。

アイデンティティはルーティング判断と信頼境界を広げた

アプリケーション認識型アクセスにはアイデンティティ統合が必要だった。プラットフォームは利用者またはワークロードの文脈を使い、接続を許可するか、どのように確立するかを決められた。場所だけでは権限の十分な根拠にならないという、ゼロトラスト型ポリシーを支えるものだった。

アイデンティティは精度を高める一方、新たな依存関係を生んだ。ルートまたはアプリケーションポリシーは、アイデンティティプロバイダー、その主張、セッション状態、グループ情報へ依存する。ルーターとエッジが正常でも、認証停止や属性変更でネットワーク経路が失敗し得た。障害対応はネットワーク運用とアイデンティティ運用の境界を越える必要があった。

コントローラーは機微な文脈の集中点にもなった。トポロジー、アプリケーション関係、利用者属性、リスク信号、ポリシー結果を保持できた。このデータは診断と最適化を改善するが、不正アクセスの影響も大きくする。最小権限、保持期間、監査、職務分離は、事務上の後付けではなくアーキテクチャ要件だった。

Prosimoの方式は、基盤全体で進む変化を示している。ルーティングとアクセスのポリシーは、アイデンティティとアプリケーション意味論にますます依存する。プラットフォームが見る文脈が増えるほど、判断は有用になり得る。同時に、その権限をより厳密に統制しなければならない。

資産発見が、その後のすべての判断を支えるグラフを作った

クラウド横断コントローラーは、見えないものを統制できない。Prosimoはクラウド資産発見とマップを開発し、VPC、VNet、サブネット、アプリケーション、接続、セキュリティ関係を表現した。これらのビューはオンボーディング、設計、障害対応、ポリシーを支えた。

クラウド資産は中央ネットワーク手順の外で変化するため、発見には戦略的価値があった。アプリケーションチームは独自自動化でアカウント、ネットワーク、エンドポイント、マネージドサービスを作れる。手作業の図は古くなる。API駆動の資産一覧はより新しいグラフを作れるが、その完全性はアカウント範囲、権限、解析ロジック、事業者APIに依存する。

グラフは単なる文書ではなかった。ルーティング、セグメンテーション、サービス挿入、最適化を計算するためのデータ構造だった。資産または依存関係が欠ければ、その上に積み上げた結論はすべて誤り得る。したがってトポロジーには、いつ収集したか、どのアカウントが提供したか、どのリージョンを含むか、要求に失敗がなかったかという来歴が必要だった。

このグラフは買収の理由も説明する。Palo Alto Networksは、ワークロードとトラフィック経路の位置が分かればセキュリティ価値を生み出せる。クラウド資産を発見しルートを変更できるシステムは、ソフトウェアファイアウォールの購入から正しい配置までの距離を縮める。Bhauの後の統合声明も、資産発見とソフトウェアファイアウォール配備の迅速化を具体的に強調した。

AIRはエッジテレメトリーを運用上の推奨へ変えた

Application-driven Intelligent Results（AIR）はAXI Edgeが収集したテレメトリーを分析した。AWSの解説では、往復時間、処理時間、アプリケーション応答時間、トランザクション種別、リスク、ポリシー結果の可視化が説明されている。プラットフォームは孤立した機器カウンターではなく、利用者、ネットワーク、アプリケーションの観測を関連付けられた。

この相関はよくある運用問題に対応する。遅いトランザクションの原因は、利用者経路、エッジ、クラウドバックボーン、セキュリティサービス、アプリケーション自体のいずれにもあり得る。層をまたぐビューは、別々のコンソールより早く調査範囲を絞り、経路、配置、リスク、コストに関する推奨も支援できる。

推奨品質は、テレメトリーの範囲と解釈モデルに依存した。エッジが観測できるのは自身を通るトラフィックだけである。外部アプリケーション依存関係やクラウド事業者内部の状態は見えない場合がある。推奨は方向性として有用でも、根本原因を証明するとは限らない。

テレメトリーには統制上の価値もあった。過去の観測は、ルートやポリシーがなぜ変わったかを説明する助けになる。同時に、機微なアプリケーション利用状況や利用者行動も明らかにし得る。公開資料は保持期間や買収後のデータ統制を完全には説明していないため、これらは顧客のデューデリジェンス項目として残る。

AWSが最も明確な実装証拠を提供した

ProsimoのAWS関連作業は、最も強い公開技術証拠を残した。同社はAWS Transit Gateway、Cloud WAN、PrivateLink、Marketplace for Containers Anywhereの配備ワークフローと統合した。AWSはAXI Edgeの配置、アプリケーションのオンボーディング、アイデンティティ、セキュリティ、最適化を説明する技術解説を公開した。

特に重要だったのがAWS Cloud WANである。Prosimoが置き換えるのではなくオーケストレーションできる、クラウドネイティブなバックボーンとセグメンテーションサービスを提供した。この構成は協調型モデルを示す。AWSがネイティブネットワークと世界規模基盤を所有し、Prosimoがクラウド横断の意図、アプリケーション文脈、エッジソフトウェア、分析を提供した。

Marketplaceのワークフローは、承認済みチャネルを通じてAXI Edgeをパッケージ化し、最初の配備手順を簡素化した。しかし後続のアカウント権限、経路設計、高可用性、容量、運用は残った。初日以前の自動化は導入摩擦を減らしても、長期的な制御問題をなくさない。

会社資料ではFlexportの名前付き事例がAWS Cloud WANのユースケースを支えた。これは企業顧客がアーキテクチャを支持した証拠であり、配備規模、削減額、可用性の独立監査ではない。顧客コメントは普遍的な性能証拠ではなく、採用例として扱うべきである。

AzureとGoogle Cloudがマルチクラウドという主張を完成させた

ProsimoはMicrosoft AzureとGoogle Cloud環境も支援した。製品資料はAzure Virtual WAN、Google Cloudのネットワーキング、プライベートサービス構成の周辺をオーケストレーションすると説明した。各事業者のネイティブネットワークを残しつつ、一つの運用モデルを示すことが目標だった。

対応の存在は、事業者間で同一機能を証明しない。クラウドAPIの成熟速度は異なり、似た製品名でも意味論が違うことがある。ルート、セグメント、プライベートエンドポイント、サービス挿入には事業者固有の扱いが必要になり得る。提供資料は、全リージョンとリリースを対象とする機能別の同等性表を再構成できない。

したがってマルチクラウド抽象化は、翻訳システムとして理解するのが最も適切である。共通の意図とワークフローを標準化できるが、セキュリティ、コスト、障害に影響する詳細を残さなければならない。画面だけが統一され、実装差が運用者から隠れると、プラットフォームは危険になる。

買収後にも同じことが言える。Palo Alto Networksは共通グラフを使って複数クラウドへセキュリティを配置できるかもしれないが、経路を実装するネイティブオブジェクトはクラウド事業者が支配する。オーケストレーション層を所有しても、クラウドアンダーレイを所有することにはならない。

製品は接続からライフサイクルへ広がった

2023年までにProsimoは、マルチクラウドネットワークを設計、構築、障害対応、管理するワークフローを説明していた。製品はトンネルやゲートウェイの確立を超えていた。資産発見が設計を支え、オーケストレーションが接続を作り、マップとテレメトリーが障害対応を支え、ポリシーと履歴状態が継続管理を支えた。

このライフサイクルの枠組みは商用購入者を広げた。ネットワーク技術者はトポロジーと経路分析を使え、クラウド基盤チームはアカウントとサービスを取り込め、セキュリティチームはセグメンテーションと検査を確認でき、移行チームは変更を計画でき、FinOpsチームは経路とエグレスの影響を検討できた。複数の組織が同じ証拠を使うほど、プラットフォーム価値は高まった。

共有証拠は統制上の対立も生む。中央基盤は、クラウドチームのネイティブ設定が企業ポリシーと異なることを明らかにし得る。組織はどのシステムを権威あるものとし、誰が修正を承認するかを決めなければならない。ソフトウェアだけでは、この制度上の問題を解決できない。

ライフサイクルの物語は切り替えコストも強めた。コントローラーが資産グラフ、ポリシー、テレメトリー、エッジ配置、自動化統合を保持すると、その置き換えは回線移設以上の作業になる。顧客は運用モデルをエクスポートするか、再構築しなければならない。Prosimoはクラウド断片化の削減を売る一方で、コントローラー依存の可能性を作った。

セグメンテーションはネットワーク到達性からアプリケーションポリシーまで及んだ

Prosimoはレイヤー3から7までのセグメンテーションを掲げた。ネットワーク層ではルートドメインとセグメントが、どのサブネットや拠点が通信できるかを決めた。上位層ではアプリケーションアイデンティティ、利用者文脈、トランザクション特性が規則を細かくした。

階層型モデルは、ネットワークゾーンとアプリケーションポリシーの隔たりを縮められた。広いサブネット間到達性を遮断したまま、特定業務サービスだけを許可できる可能性がある。逆に、ネットワーク経路は到達可能でも、アイデンティティまたはアプリケーション文脈が不適切なら拒否できた。

これによってProsimoが完全な次世代ファイアウォールになったわけではない。2024年のPalo Alto Networks統合では責任が分けられた。Prosimoがルート、セグメンテーション、サービス挿入をオーケストレーションし、VM-Seriesが深い検査を実施した。ポリシーによる経路制御とセキュリティ適用は異なる形で失敗するため、この区別は重要である。

セグメントが有効なのは、関連するすべての経路が表現されている場合だけである。未知のルート、クラウドネイティブな例外、失敗したサービス挿入は、意図した制御を迂回させ得る。したがって保証には、コントローラー画面だけを信じるのではなく、宣言ポリシー、事業者状態、観測トラフィックの比較が必要である。

サービス挿入はルート制御をファイアウォール経済へ結び付けた

クラウドセキュリティ設計では、検査をどこで行うか決めなければならない。中央ファイアウォールはポリシーを簡素化し、台数を減らせるが、遠回り、集中、規模圧力を生むことがある。分散ファイアウォールはワークロード近くに置けて経路の歪みを減らす一方、配備、ライセンス、更新、ポリシー運用を増やす。

ProsimoはVM-Series統合で両方の構成を支援した。ポリシーにより選択トラフィックを中央検査点へ送ることも、アプリケーションVPCへ分散されたファイアウォールへ送ることもできた。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が、技術はPalo Alto Networks製品へ完全統合されたと述べた。これらの記録を合わせると買収判断を支えられるが、法的手続きは未解明のままである。

この順序は編集上の正確さと顧客の双方に重要である。提携では二つのベンダー、二つのサポート体制、明確な統合境界がある。買収ではロードマップ、データ、契約、権限が一社へ移り得る。技術経路が当初似ていても、移行が変えるのはブランドだけではない。

Nebulaはトポロジーグラフを対話型インターフェースへ変えた

Prosimoは2024年2月、マルチクラウドネットワーキング向けAI Suiteの一部としてNebulaを発表した。このアシスタントは、重複ネットワーク、コスト、ルート健全性、セキュリティポリシー違反など、プラットフォームのグラフとテレメトリーに表現された状態について、自然言語の質問へ答える設計だった。

有用な資産は言語インターフェースそのものではなく、その下にある構造化されたクラウド横断文脈だった。汎用モデルは、見えないプライベートルートやセグメントを診断できない。Nebulaは、Prosimoが既に収集していた資産一覧、トポロジー、ポリシー、観測結果を利用できた。共通グラフへの先行投資がAIOpsに結び付いたのである。

対話型アクセスは複雑なデータをより多くの運用者へ開放できる。一方、未対応資産を回答から落としたり、質問を誤解したり、推奨を承認済みの操作として扱ったりすると、誤った自信を生む。高リスク変更には引き続き、決定論的な制御、権限境界、人の確認が必要だった。

Prosimoは、平均復旧時間を60～80%短縮し、クラウドネットワーキングコストを60%以上削減できる可能性を示した。これらは製品発表における会社主張である。提供資料には、一般的に適用できると証明する独立方法論や顧客基準値がない。Prosimoが提示した便益として引用することはできても、測定済みの市場事実として扱うことはできない。

AIワークロードは新しいユースケースであり、新市場の証明ではなかった

同じ2024年の発表は、ProsimoのアーキテクチャをAIワークロードにも有用と位置付けた。分散AIシステムでは、データへのプライベートアクセス、クラウドとデータセンター間の接続、コンプライアンス制御、アプリケーション動作を反映したルーティングが必要になり得る。これらは既存の資産、ポリシー、経路モデルと整合する。

名称が変わってもアンダーレイは変わらない。Prosimoは引き続きクラウドネットワーク、通信事業者、顧客基盤へ依存した。またGPUコンピュートやモデル開発ソフトウェアを提供したわけではない。想定される役割は、分散データとサービスを取り巻く接続・セキュリティ層だった。

データとサービスの分散が進むほどクラウド横断トポロジーの価値は上がるため、AIという位置付けには戦略的な合理性があった。同時に、これは会社が独立運営を終える直前に導入したマーケティングカテゴリーでもあった。提供資料は、AI製品単独の売上、名前付き本番導入、監査済みのワークロード成果を示していない。

持続的な論点は、マルチクラウドテレメトリーが機械支援運用の入力になり得ることである。現在の製品上の問いは、Palo Alto Networksがその文脈を保持したのか、どのように機能を提供しているのかである。調査期限時点の公開証拠は完全な答えを与えない。

商用モデルは、自社所有でない基盤の上にソフトウェアを販売した

独立経営期のProsimoは、通信事業者型ではなく、ソフトウェアのサブスクリプションとサービスを売る事業だった。顧客は自社環境にAXI Edgeを配備し、クラウドアカウントを制御層へ接続した。売上はライセンスまたはサブスクリプション、サポート、専門サービス、チャネル活動に依存していたと考えられるが、正確な価格や契約指標は提供資料で公開されていない。

光ファイバーを所有せずに規模を拡大できるモデルだった。一つのソフトウェア基盤が多数のクラウドリージョンと顧客環境を調整できる。しかし、このアーキテクチャだけから粗利構造を推測することはできない。ベンダーAPI対応、エッジのライフサイクル、セキュリティ統合、企業導入の支援にはコストがかかり、エッジが消費するクラウド資源はベンダーではなく顧客負担だった可能性がある。

Prosimoはクラウドマーケットプレイス、統合パートナー、販売チャネル、名前付き顧客事例を使って企業へ到達した。これらは同じ証拠ではない。マーケットプレイス掲載が示すのは調達・配備経路である。技術統合が示すのは、定義された条件で二つのシステムを組み合わせられることだ。顧客コメントは採用事例を示す。どれも単独では有料顧客数や経常収益を証明しない。

対象範囲の広さは販売の複雑さを増やした可能性もある。ネットワーク、セキュリティ、クラウド、アプリケーションの各チームが恩恵を受けても、予算所有者は明確でないことがある。製品には、クラウドと各チームを別々に運用させるのではなく、共通制御層へ資金を出す買い手が必要だった。

パートナー、顧客、投資家は異なる位置を占めた

Amazon Web Servicesはアンダーレイ事業者であると同時に、市場展開のための統合パートナーだった。AzureとGoogle Cloudは対応環境である。アイデンティティプロバイダーは認証文脈を供給し、ファイアウォールベンダーは検査を供給した。コロケーション事業者や通信事業者はエッジを設置・接続でき、チャネルパートナーは導入を設計・運用できた。

AWS Cloud WAN資料では、Flexportが名前付き顧客事例として登場した。この事例は企業がアーキテクチャに関心を持った証拠だが、導入の全範囲、期間、商用価値は提供資料から分からない。顧客基盤全体の代理指標にしてはならない。

General CatalystはシリーズAを主導し、投資家としてガバナンスに関与した。会社資料にはWRVIまたはCelesta関連投資家が現れ、後のProsimo発信にはBlackRock関連の名称を含む有力投資参加も言及されたが、正確な投資ビークルは調査で解決されていない。これらの記録は影響力ある資金基盤を示すが、完全な資本構成表ではない。

最も重要な関係はPalo Alto Networksだった。2024年のセキュリティパートナーから、2025年初頭までに買収者へ変わった。この順序は、あるエコシステム依存先が、その製品への経路を調整するソフトウェア層を購入すると、支配関係へ変わることを示している。

少なくとも5,500万米ドルを調達したが、出口の経済条件は不明である

確認できる資金調達は、2021年4月の2,500万米ドルシリーズAと、2022年の3,000万米ドルシリーズBである。合計は少なくとも5,500万米ドルとなる。提供資料には監査済み資本構成表、評価額、債務一覧、後続調達ラウンドがない。

買収対価は公表も独立検証もされていない。価格がなければ、結果を戦略的プレミアム、限定的な技術買収、人材獲得型買収、経営難による売却のいずれかに責任を持って分類できない。技術が製品へ統合され続けたことは価値を示すが、投資家や創業者の収益を明らかにしない。

買収後のPalo Alto Networksの売上高や市場規模をProsimoへ帰属させるべきではない。スタートアップが個別に観測できなくなれば、分析できる単独の売上、利益、顧客セグメントはない。大きな所有者は技術を広く展開できる一方、その個別経済性を見えにくくする。

正式な買収発表がないこと自体にも意味がある。顧客、従業員、研究者は通常、そのような発表から時期、サポート、戦略的理由を確認する。今回は職歴、会社ページの表示、後の創業者声明から状態を再構成しなければならない。独立企業ではないと訂正するには十分だが、取引詳細を作り出すには不十分である。

競争相手は専門基盤、クラウド、社内エンジニアリングだった

ProsimoはAviatrixやAlkiraのような専門マルチクラウドネットワーキング基盤、企業ネットワーキング・SASEベンダー、AWS、Azure、Google Cloudのネイティブサービスと競合した。また企業がインフラストラクチャ・アズ・コード、クラウド事業者のトランジットサービス、ルートテーブル、ファイアウォールを直接使う内製モデルとも競った。各選択肢は同じ問題の異なる部分を解決した。

専門コントローラーは複数事業者へ一つのトポロジー・ポリシーモデルを提供できる。クラウドネイティブ設計は第三者依存を減らし、単一事業者へ密接に合わせられる。キャリア支援サービスは物理輸送を供給できる。SASEまたはセキュリティ基盤は接続とセキュリティ適用を統合できる。社内エンジニアリングは人員と統合作業を増やす代わりに制御を維持できる。

Prosimoの差別化は、アプリケーション・ネットワークの両トランジット、分散エッジ、クラウドネイティブオーケストレーション、トポロジー、テレメトリー、サービス挿入の組み合わせにあった。同じ広さが比較を難しくした。買い手はカテゴリー名を比べるのではなく、実際に使うクラウドサービス、ルート、アイデンティティシステム、セキュリティ構成を試す必要があった。

買収は競争の枠組みを変える。Prosimoは独立企業として勝つ必要はなくなったが、その技術はPalo Alto Networks内部で価値を示さなければならない。比較すべきは、統合された発見とルートオーケストレーションがPalo Alto Networks製セキュリティ製品の配備を改善するか、顧客がその基盤依存を受け入れるかである。

クラウドネイティブサービスは土台であり、代替でもあった

AWS Cloud WAN、Transit Gateway、Azure Virtual WAN、Google Cloudのネットワーキングは企業へ強力なネイティブ選択肢を提供した。Prosimoはそれらに依存すると同時に、顧客が直接運用できるという可能性と競った。

この関係は動く境界を作った。クラウド事業者がグローバルルーティング、セグメンテーション、プライベートサービスアクセス、中央ポリシーを追加すると、第三者機能の一部はネイティブで再現しやすくなる。同時に、新しいネイティブサービスが増えるたび、クラウド横断コントローラーが発見・調整すべきオブジェクトも増える。クラウドの進歩はProsimoの価値の一部を狭めながら、事業者間翻訳の必要を広げ得た。

決定要因は技術だけでなく組織にもあった。強い社内エンジニアリングを持つ単一クラウド企業はネイティブツールを選びやすい。チームが分断されたマルチクラウド企業は一つの制御面を評価し得る。規制業界の組織は第三者の証拠層を好む一方、特権認証情報とデータ集中を懸念し得る。

ロックインを完全に消すアーキテクチャはない。ネイティブツールは一つのクラウドのAPIと意味論への依存を増やす。クラウド横断コントローラーはグラフ、ポリシー、エッジソフトウェアへの依存を増やす。有用な問いは、その依存が見えるか、移植できるか、組織の運用モデルに合うかだった。

障害はコントローラー、エッジ、クラウドAPI、アイデンティティ、アンダーレイで起こり得た

Prosimoの分散アーキテクチャは一つのトラフィックハブへの依存を減らしたが、相互作用する複数の障害ドメインを作った。中央サービスは停止し、古い意図を保持する可能性がある。エッジは故障または孤立し得る。クラウドAPIは変更の一部を拒否し得る。アイデンティティプロバイダーは停止し得る。アンダーレイは容量を失い、想定外経路を取ることがある。挿入されたファイアウォールは資源を使い切ることがある。

特に難しいのが部分障害である。ある事業者がルート更新を受け入れ、別の事業者が拒否する場合がある。するとコントローラーの意図状態と実際のクラウド状態がずれる。トラフィックは非対称経路を通り、検査を迂回する可能性がある。信頼できるシステムには、調整、冪等操作、段階的変更、明示的エラー状態、事業者ごとの動作を考慮したロールバックが必要になる。

公開証拠は高水準の可用性と最適化を説明するが、独立した障害注入試験、完全なインシデント記録、普遍的なサービス水準結果を含まない。したがって回復力の主張は、記録されたアーキテクチャまたは顧客名を伴う導入事例に結び付けるべきである。

買収はもう一つの障害ドメイン、製品継続性を導入する。顧客は、過去のProsimoシステムをどのコンソール、API、エッジイメージ、ポリシーモデル、サポート組織が置き換えるかを知る必要がある。コード統合が技術的に成功しても、商用・運用境界が不明なら移行リスクは残る。

クラウド認証情報により、コントローラーは重要管理プレーンの一部になった

資産発見とオーケストレーションにはクラウドアカウントへのアクセスが必要だった。読み取り専用資産一覧は限定権限で取得できるが、ルート、セグメント、サービス挿入を変更するには強い権限が必要になる。したがって、コントローラーはワークロードを所有していなくても、特権管理プレーン内部に位置した。

認証情報が侵害されればトポロジーが漏れ、広範な変更が許される可能性がある。ソフトウェア不具合または運用者の誤りは、複数クラウドへポリシーを伝播させ得る。プラットフォームが有用になるほどリスクは大きくなる。管理できるアカウントとサービスが増えるほど、潜在的影響範囲も広がる。

企業には最小権限ロール、発見と変更の認証情報分離、複数者承認、完全な監査、ローテーション、緊急失効、同じコントローラーだけに依存しない復旧経路が必要だった。公開資料には完全な独立セキュリティ評価がないため、これらは製品保証ではなく導入時に必要な統制である。

テレメトリーグラフも同じく機微である。アプリケーション名、ネットワーク構造、ポリシー、利用者関係、ルート健全性、コストパターンを明らかにし得る。買収後の統制は、そのデータがどこに保存され、どのPalo Alto Networks製品が利用でき、旧顧客権限がどう移行されたかを明確にすべきである。調査期限時点の公開証拠はこれらへ答えていない。

買収はクラウド中立層をセキュリティ基盤の中へ移した

独立企業だったProsimoは、クラウドとセキュリティサービスを横断する共通層として自社を位置付けられた。Palo Alto Networksが所有者になると、インセンティブが変わる。買収技術はVM-SeriesなどPalo Alto Networks製品を配備しやすくできる。統合体験が向上する可能性がある一方、第三者検査サービスの対応について新たな問いが生じる。

所有権だけで中立性の消失を証明することはできない。提供資料には現在のパートナー一覧や製品アーキテクチャがない。しかし、顧客が問うべき内容は変わる。ルートコントローラーが複数セキュリティベンダーに開かれているか、ポリシーとテレメトリーを輸出できるか、最適化が所有者の製品群を優先するかを確認する必要がある。

統合声明はイングレス、エグレス、東西方向検査を強調した。この重点から、Prosimoのトポロジーとオーケストレーションはセキュリティ配備システムの一部になったと考えられる。一方、過去のApp Transit、利用者アクセス、コスト最適化、すべてのクラウドネットワーキングワークフローが個別機能として残ったことまでは証明しない。

これは基盤分野で繰り返される構図である。スタートアップが難しい調整問題を抽象化し、大手プラットフォーム企業が、その抽象化によって自社主力製品の利用と支配を増やせるため買収する。買い手は配備経路を得る。顧客は統合を得る一方、供給者からの独立性を一部失う可能性がある。

現行製品対応表が最大の欠落情報である

公開記録は買収と統合を確認できるが、AXI、Network Transit、App Transit、AIR、Nebulaが現在のPalo Alto Networks製品またはSKUへどう対応するかを完全には示さない。旧製品のサポート終了日、移行手順、機能ごとの継続表も公開していない。

この欠落により、現行製品レビューはできない。過去の説明はProsimoが何を作り、なぜ重要だったかを示せる。しかし、どの機能が現在利用可能で、ライセンスされ、サポートされるかは示せない。現在の導入助言には、過去のProsimo発表ではなく、現行Palo Alto Networks文書が必要である。

欠落した対応表は戦略分析も制限する。トポロジーグラフとオーケストレーション層の全面吸収は、資産発見とファイアウォール配置だけの選択的利用とは異なる。前者は広いマルチクラウド制御サービスを作り、後者は主にセキュリティ配備を加速する。共同創業者の声明は技術継続を支持するが、このアーキテクチャ境界を解決しない。

将来の製品文書、移行ガイド、顧客事例が不確実性の多くを解消できる。それまでは、共同創業者によればProsimo技術はPalo Alto Networks製品へ統合されたが、範囲とパッケージは未検証である、というのが正確な表現である。

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

経路全体を単一の主体が制御しているわけではない。企業はアカウントの所有権、事業上の意図、アプリケーション設計、付与する認証情報を管理する。クラウド横断コントローラーはトポロジーを発見し、ポリシーを変換し、経路を選び、ネイティブルート状態を変えられる。クラウド事業者はAPI、トランジットサービス、プライベートエンドポイント、バックボーン、多くの障害ドメインを管理する。通信事業者とコロケーション事業者は、その他の輸送区間を管理する。セキュリティサービスは、検査されたトラフィックを許可するか決める。

Prosimoは最も戦略的に有用な中間位置を狙った。アンダーレイは所有しないが、その上にあるグラフとポリシー変換を所有しようとした。この層を制御する者は、どの資産が見えるか、セグメントをどう表現するか、エッジをどこに置くか、どのサービスがトラフィックを検査するか、どのテレメトリーを権威あるものとみなすかを決められる。光ファイバーを別の誰かが所有していても、これは実務上のルーティング権限に相当する。

買収後はPalo Alto Networksが残ったProsimo技術を所有し、統合、パッケージ、開発方法を決める。クラウド事業者は自社環境内で主権を保ち、企業は認証情報を取り消し、別アーキテクチャを選べる。しかし、トポロジー、ポリシー、運用ワークフローがコントローラーへ依存していれば、離脱は高価になる。

したがって答えは絶対ではなく階層的である。企業が権限を与え、コントローラーが調整し、クラウドと通信事業者のアンダーレイが輸送し、セキュリティ基盤がポリシーを適用する。Prosimoの歴史は、クラウドアカウントや物理経路の所有者が変わらなくても、調整層の所有権が変わり得ることを示す。

主要情報源

買収後もProsimoが重要である理由

Prosimoは基盤の実際の変化を捉えた。ネットワーク運用の単位は機器とプレフィックスから、アプリケーション、アイデンティティ、サービス依存関係、ポリシーグラフへ移っている。クラウドネイティブAPIはネットワーク状態をプログラム可能にし、分散ソフトウェアエッジは、ポリシーの適用地点を移動可能にする。複数クラウドを見渡すコントローラーは、一つのクラウドコンソールだけでは完結しない操作を調整できる。

同社はその調整に必要なコストも明らかにした。共通層には特権認証情報、継続的API保守、正確な発見、意味論変換、テレメトリー、運用規律が必要である。分断作業を減らす一方、新たな集中点を作る。同じシステムがルーティングを簡素化し、誤った一判断の影響範囲を広げ得る。

Palo Alto Networksによる買収は制御問題をより見えやすくした。ネットワーキングとセキュリティは、サービス挿入、ワークロード発見、ポリシーを中心に収斂している。トポロジーを知りルートを変更できるセキュリティベンダーは、提示されたトラフィックを検査するだけでなく、どのトラフィックがどこで検査へ到達するかの決定にも関与できる。

したがってProsimoを、独立ブランドとしての失敗とも、一つの基盤がマルチクラウドを解決した証拠とも見るべきではない。長期的な貢献は、クラウド横断グラフを基盤として定義したことにある。残る問いは、今や大手セキュリティ企業の中にあるそのグラフが、顧客に信頼されるだけの透明性、移植性、統制可能性を保つかである。