概要

  • 2019年に設立された Prosimo は、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 が現在の製品・サポートのマッピングを公開するまでは、これらを現在販売中の独立製品として提示すべきではない。買収後、過去のアーキテクチャは組み込まれたコード、共有サービス、モジュール、または内部エンジニアリング資産として残ることがある。これらの状況は同等ではない。

ブランドの消滅は問題を時代遅れにするものではない。企業は現在も Amazon Web Services、Microsoft Azure、Google Cloud、プライベートデータセンター、コロケーションサイト、SaaS プラットフォーム、リモートユーザーにワークロードを分散している。各環境には独自のルート、ゲートウェイ、プライベートエンドポイント、アイデンティティ管理、セキュリティサービス、割り当て、課金ルールがある。企業がすべてのアカウントを所有していても、リクエストがたどる経路を単一の視点で把握できるとは限らない。Prosimo の重要性は、この全体像を制御しようとした点にある。

したがって、買収は単なる最後の注記ではなく、物語の軸である。Prosimo は、資産を発見しアプリケーションコンテキストを解釈し、トラフィックをセキュリティサービスへ誘導できる横断的な制御レイヤーを構築していた。Palo Alto Networks は当初、VM-Series ファイアウォールをこれらの経路に挿入できる技術パートナーとして登場し、その後、技術の所有者となった。ルーティングのオーケストレーションとディープインスペクションを隔てていた境界は、単一のサイバーセキュリティプラットフォーム内に移動した。

マルチクラウドルーティングはコンテキストをめぐる戦い

ルーティングテーブルは、プレフィックスがネクストホップ経由で到達可能かどうかを示すことができる。しかし、ユーザーが到達しようとしていたアプリケーション、リクエスタが信頼できるかどうか、インスペクションサービスがトラフィックを検査すべきかどうか、プライベートエンドポイントが利用可能かどうか、あるクラウド経路が別の経路よりコストがかかるかどうか、パケットが到着した後にトランザクションが失敗するかどうかは説明できない。マルチクラウド運用は、これらの問いを共有制御の問題に変える。

Prosimo の主張は、ルーティング権限がレイヤー3の到達可能性以上のものに基づくべきだというものだった。そのソフトウェアは、クラウドインベントリ、ネットワーク状態、アプリケーションアイデンティティ、ユーザーアイデンティティ、リスク、パフォーマンス、トランザクションテレメトリを組み合わせようとした。このコンテキストにより、定義されたアプリケーションの接続、セグメントの分離、エントリポイントの選択、選択したトラフィックのファイアウォールへの誘導などのポリシーを表現できた。価値は新しいファイバー経路を発明することではなく、既存の経路とサービスをどのように組み合わせるかの決定にあった。

この区別が「アプリケーションエクスペリエンスインフラストラクチャ」という表現を説明する。これはアプリケーションリクエストをネットワークオブジェクトの上位に置く。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 はクラウド事業者ではなかった。全リージョンを結ぶグローバルなファイバーバックボーンを所有していなかった。経路はクラウドプロバイダーのバックボーン、パブリックインターネット、専用回線、コロケーションリンク、企業ネットワークを経由する場合があった。また、Palo Alto Networks と同じ意味でのファイアウォールプロバイダーでもなかった。2024年の統合では、その役割は発見、セグメンテーション、誘導であり、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日に発表された。General Catalyst はローンチ時に2,500万ドルのシリーズ A を主導した。投資家は、創業者が従来のブランチ接続を超えたカテゴリを定義しようとしていることに沿って、複数のクラウドにわたるアプリケーションエクスペリエンスを提供する機会として提示した。

ローンチは、企業を密度が高く、まだ不明確な市場に置いた。クラウドプロバイダーは自社のネットワークサービスの消費を容易にした。SD-WAN および SASE ベンダーはポリシーをクラウド環境に拡張した。アプリケーションデリバリプロバイダーはリクエストを最適化し、サイバーセキュリティ企業はリクエストを検査できた。Prosimo の提案は、周囲のシステム全体を置き換えると主張せずに、これらの機能をクラウドネイティブアーキテクチャに統合することだった。

資金調達により、統合、ソフトウェアエッジ、分析、営業組織、パートナーシップを開発できた。しかし、市場適合性、売上の規模、持続可能な差別化を証明するものではなかった。提供された資料には、監査済み売上、年間経常収益、顧客数、評価額は記載されていない。資金調達は投資家のコミットメントを示すものであり、運用実績の完全な説明ではない。

2022年、Prosimo は3,000万ドルのシリーズ B を実施し、オーバーサブスクライブとされた。明確に特定された2つのラウンドを合計すると、検証済みの総額は少なくとも5,500万ドルになる。一部のデータベースは、発表や関連記録を重複して表示するため、より多くの金額を表示することがある。これらの合計は、基礎となるイベントを解決せずに使用すべきではない。

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

AXI アーキテクチャは、中央の制御・分析レイヤーと分散ソフトウェアエッジの間で作業を分割した。中央レイヤーはアプリケーションとネットワークのインテントを保持し、資産を発見し、トポロジを組み立て、アイデンティティを統合し、テレメトリを分析し、変更をオーケストレーションした。AXI Edge はワークロードまたはユーザーの近くに展開され、すべての経路を遠隔の物理ハブに通すことなくポリシーを適用した。

この分離は他のソフトウェア定義システムを連想させるが、オブジェクトはクラウドネイティブでアプリケーション認識型だった。コントローラはクラウドアカウントとその API へのアクセスを必要とし、エッジはネイティブのトランジットサービス、ワークロードネットワーク、プライベートエンドポイント、外部経路に接続する必要があった。プラットフォームの権限は、クラウド全体のグローバルインテントとトラフィック近くのローカル実行というビューの組み合わせから生まれた。

このアーキテクチャはまた、具体的な展開境界を生み出した。各エッジはクラウドリソースを消費し、高可用性設計を必要とし、更新・監視・保護が必要だった。制御レイヤーは、資産を発見しネットワーク状態を変更するための十分な特権を持つ認証情報を要求した。企業は共通のワークフローを得たが、可用性と信頼性が本番到達可能性にとって重要となる管理システムを追加した。

Prosimo は「自律型クラウドネットワーク」という語彙を使用することがあった。証拠は自動化、推奨事項、API オーケストレーションを裏付けている。しかし、人間のポリシー、クラウドプロバイダーのサービス、基盤となる転送から独立したネットワークを説明しているわけではない。運用者は常にインテントを定義し、アクセスを承認し、例外を処理し、結果に対して責任を負った。

AXI Edge は配置の決定であり、汎用アプライアンスではなかった

AXI Edge は、クラウド VPC または VNet、コロケーション環境、隣接インフラに展開できた。AWS テクニカルガイドは、Transit Gateway を介してワークロード VPC に接続されたエッジ VPC を示し、オプションのファイアウォールチェーンと、リモートユーザーまたはオンプレミスサイトからのアクセスを示していた。Prosimo の実行は、企業の遠隔境界ではなくクラウドトポロジ内にあった。

配置はレイテンシだけでなく、トラフィックがポリシードメインに入るポイント、使用されるクラウドバックボーンまたはインターネット経路、暗号化と検査の場所、利用可能なテレメトリを決定した。誤った配置は迂回やコストを生み、適切な配置は経路を短縮したり、トラフィックをワークロードの近くに維持したりできた。

分散は障害ドメインを増やした。容量、ソフトウェアバージョン、クラウドゾーン設計、ルート収束、権限はリージョンによって異なる可能性があった。高可用性は単に2つのインスタンスではなかった。コントローラ、クラウドルーティングテーブル、セキュリティサービス、リターンパスもフェイルオーバー状態で一致する必要があった。

したがって、エッジはより広いオペレーティングシステムの一部だった。その価値は、資産発見、トポロジ、ポリシー、分析、クラウド環境の間の一貫性に依存していた。これを独立した仮想アプライアンスとして扱うと、Prosimo が販売しようとしていたアーキテクチャを見失うことになる。

基盤となる転送は常に他の誰かのものだった

Prosimo は物理経路を所有せずに転送を調整した。アプリケーション接続は、AWS または別のクラウドのバックボーン、パブリックインターネット、Direct Connect または ExpressRoute、コロケーションサービス、通信事業者の回線、企業ネットワークを利用できた。プラットフォームは利用可能なオプションを選択・オーケストレーションできたが、これらのプロバイダーが生み出すレイテンシ、パケットロス、障害ドメイン、料金ルールを排除することはできなかった。

この境界は、パフォーマンスの約束を評価する上で重要である。コントローラは観測されたより良い経路を選択したり、ユーザーのエントリポイントを近づけたりできる。しかし、事業者が停止しないこと、クラウドリージョンが利用可能であり続けること、外部依存関係が迅速に応答することを保証することはできない。アプリケーションエクスペリエンスには、DNS、サーバー処理、ストレージ、ブラウザ動作、サードパーティサービスも含まれ、ネットワークコントローラの完全な権限の範囲外である。

独自バックボーンがないことは、単に弱みではなかった。Prosimo は企業がすでに購入したインフラを活用し、クラウドプロバイダーの投資から利益を得ることができた。新しいリージョンにファイバーを敷設せずに到達し、AWS Cloud WAN などのネイティブシステムを調整できた。その代わりに、各プロバイダーの API、割り当て、商用条件、セマンティクスの安定性に依存した。

したがって、提案は物理的な所有権ではなく、運用上の制御に関するものだった。Prosimo は、異種のアンダーレイを単一の管理システムとして機能させつつ、ネイティブの利点を維持しようとした。この抽象化がロックインを減らすのか、それとも移動させるのかは、ポリシー、トポロジ、エッジ展開の移植性に依存していた。

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 は、ワークロードとトラフィック経路がどこにあるかを知るときにセキュリティ価値を生み出す。資産を発見しルートを変更できるシステムは、ソフトウェアファイアウォールの購入と正しい配置の間の距離を縮める。Nehal 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 が本格的な次世代ファイアウォールに変わったわけではない。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 を買収したとは述べていなかった。この発表を所有権の証拠として使用することは、2つの異なるイベントを混同することになる。

しかし、パートナーシップは橋を架けた。Prosimo は、ルートとポリシーシステムが複数のクラウドにわたる VM-Series 展開をどのように容易にするかを示すことができた。Palo Alto Networks は、その後の移行前に実際の統合で技術を評価できた。公開ソースは買収プロセスを説明していない。パートナーシップが正式に準備段階だったと主張するのは推測である。

2025年初めまでに、創業者と従業員の経歴は変わっていた。企業ページはその後、買収済みステータスを表示した。2025年末までに、Bhau は技術が Palo Alto Networks の製品に完全に統合されたと述べた。これらの要素は買収の結論をまとめて支持するが、法的メカニズムは未解決のままである。

この順序は、編集上の正確さと顧客にとって重要である。パートナーシップは2つのベンダー、2つのサポート構造、定義された統合境界を意味する。買収はロードマップ、データ、契約、権限を単一の企業に移す可能性がある。移行は技術経路が最初は似ていても、ブランド以上のものを変える。

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

Prosimo は2024年2月に、マルチクラウドネットワーキング向け AI スイートで Nebula を導入した。このアシスタントは、重複ネットワーク、コスト、ルートヘルス、セキュリティポリシー違反、およびグラフとテレメトリで表現されるその他の状態に関する質問に自然言語で回答することを目的としていた。

有用な資産は言語インターフェースだけではなく、その下にある構造化されたマルチクラウドコンテキストだった。一般モデルは、見えないプライベートルートやセグメントを診断できない。Nebula はすでに収集されたインベントリ、トポロジ、ポリシー、観測に依存できた。共通グラフへの以前の投資は、AIOps にとって関連性を持つようになった。

会話型アクセスは、複雑なデータをより多くの運用者に利用しやすくする可能性があった。しかし、回答がサポートされていない資産を省略したり、質問を誤解したり、推奨事項を承認済みアクションとして扱ったりすると、誤った信頼を生み出す可能性もあった。リスクの高い変更には、依然として決定論的な制御、承認境界、人間のレビューが必要だった。

Prosimo は、平均解決時間の60～80%削減、クラウドネットワークコストの60%以上削減など、可能性のある改善を主張した。これらの数値は製品発表における企業の主張だった。独立した方法論や提供された顧客基盤は、それらが一般的に適用されることを示していない。Prosimo が提案する利益として引用できるが、測定された市場事実としては引用できない。

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

同じ2024年の発表は、アーキテクチャが AI ワークロードに役立つと提示した。分散 AI システムは、データへのプライベートアクセス、クラウドとデータセンター間の接続、コンプライアンス制御、アプリケーション動作を考慮したルーティングを必要とする場合がある。これらのニーズは、すでに開発された資産・ポリシー・経路モデルに対応していた。

ラベルはアンダーレイを変えなかった。Prosimo は依然としてクラウドネットワーク、通信事業者、クライアントインフラに依存していた。同社は GPU コンピューティングやモデル開発ソフトウェアを提供していなかった。その潜在的な役割は、分散データとサービスをめぐる接続とセキュリティだった。

AI ポジショニングは、トポロジの横断的価値がデータとサービスの分散とともに増加するため、論理的だった。また、独立の終わり近くに導入されたマーケティングカテゴリでもあった。提供された要素は、AI 関連の分離収益、指名された本番展開、監査済み結果を確立していない。

永続的なポイントは、マルチクラウドテレメトリが機械支援運用を促進できることである。現在の問いは、Palo Alto Networks がこのコンテキストを維持し、能力をどのように公開するかである。カットオフ日時点で利用可能な公開ソースは完全な回答を提供していない。

ビジネスモデルはサードパーティインフラの上でソフトウェアを販売した

Prosimo はオペレーターではなく、サブスクリプションソフトウェアおよびサービス企業として運営された。顧客は自環境に AXI Edge を展開し、クラウドアカウントを制御レイヤーに接続した。収益はライセンスまたはサブスクリプション、サポート、プロフェッショナルサービス、チャネルに依存したと思われるが、正確な価格と契約メトリクスは提供された要素に公開されていない。

モデルはファイバーを所有せずに成長できた。ソフトウェアプラットフォームは多くのリージョンと環境を調整できた。しかし、粗利の経済性を推測することはできない。プロバイダーAPI のサポート、エッジのライフサイクル、セキュリティ統合、エンタープライズ展開にはコストがかかる可能性があり、エッジが消費するクラウドリソースは顧客が直接支払う場合があった。

Prosimo はマーケットプレイス、統合パートナー、チャネル、顧客紹介を使用してエンタープライズにリーチした。これらの関係は同等ではない。マーケットプレイスへの存在は購入と展開のチャネルを証明する。技術統合は2つのシステムが定義された条件下で連携できることを証明する。顧客の引用は紹介を提供する。どれも単独では有料顧客数や経常収益を明らかにしない。

オファリングの広さは販売を複雑にする可能性があった。ネットワーク、セキュリティ、クラウド、アプリケーションの各チームがすべて恩恵を受ける可能性があったが、予算の所有権は不明確なままであった。製品は、各クラウドと各チームを別々に運用するのではなく、共通の制御レイヤーに資金を提供する用意のある購入者を必要とした。

パートナー、顧客、投資家は異なる立場にあった

Amazon Web Services は、基盤となるインフラのプロバイダーであると同時に商用統合パートナーでもあった。Azure と Google Cloud はサポート対象環境だった。アイデンティティプロバイダーは認証コンテキストを提供した。ファイアウォールは検査を提供した。コロケーションと通信事業者のサービスはエッジをホストまたは接続できた。チャネルパートナーは展開を設計・運用できた。

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 が含まれ、少なくとも5,500万ドルになる。監査済みの株主構成、評価額、負債、その後のラウンドは提供された要素では利用できない。

買収の対価は開示または独立して検証されていない。価格がなければ、取引を戦略的プレミアム、控えめな技術買収、アクイハイヤー、窮地の売却として適切に特徴付けることは不可能である。統合の継続は技術的価値の考えを支持するが、投資家や創業者のリターンを明らかにしない。

Palo Alto Networks の収益と規模は、買収後に Prosimo に帰属させるべきではない。スタートアップは別々に観測可能ではなくなったため、分析すべき独立した収益、利益、顧客セグメントは存在しない。より大きな所有者は技術をより広く配布できる一方、個々の経済性をより見えにくくする。

正式な買収発表がないこと自体が関連性を持つ。顧客、従業員、研究者は通常、これらのリリースを使用して、タイミング、サポート、戦略的論理を判断する。ここでは、ステータスは経歴、企業ページのラベル、創業者のその後の声明から再構築する必要がある。ステータスを修正するには十分だが、取引の詳細を発明するには不十分である。

競争はプラットフォーム、クラウド、内部エンジニアリングから来た

Prosimo は、Aviatrix や Alkira などの専門プラットフォーム、エンタープライズネットワークおよび SASE プロバイダー、AWS、Azure、Google Cloud のネイティブサービスと競合した。また、企業がプロバイダーのインフラストラクチャ・アズ・コード、トランジットサービス、ルーティングテーブル、ファイアウォールを直接使用する内部モデルとも競合した。これらの代替案は同じ問題の異なる部分を解決した。

専門コントローラは単一のトポロジとポリシーモデルを提供できた。クラウドネイティブ設計はサードパーティへの依存を減らし、1つのプロバイダーに密接に整合できた。通信事業者が提供するサービスは物理的輸送を提供できた。SASE またはセキュリティプラットフォームは接続と施行を組み合わせることができた。内部エンジニアリングはスタッフと統合の労力を犠牲にして制御を維持できた。

Prosimo の差別化は、アプリケーションとネットワークのトランジット、分散エッジ、ネイティブオーケストレーション、トポロジ、テレメトリ、サービス挿入を組み合わせたことだった。この広さは比較も難しくした。購入者は、実際に使用する予定のクラウド、ルート、アイデンティティ、セキュリティモデルをテストする必要があり、カテゴリラベルを比較するだけではなかった。

買収は競争の枠組みを変える。Prosimo はもはや独立企業として勝つ必要はなく、その技術は Palo Alto Networks 内で価値を証明しなければならない。関連する比較は、統合された発見とオーケストレーションが Palo Alto のセキュリティ製品の展開を改善する能力と、顧客が結果として生じる依存関係を受け入れるかどうかである。

クラウドのネイティブサービスは基盤であると同時に代替案だった

AWS Cloud WAN、Transit Gateway、Azure Virtual WAN、Google Cloud のネットワークサービスは、企業に強力なネイティブオプションを提供した。Prosimo はこれらのサービスに依存し、顧客が直接利用する可能性に直面した。

この関係は移動する境界を生み出した。プロバイダーがグローバルルーティング、セグメンテーション、プライベートサービス、中央ポリシーを追加すると、一部のサードパーティ機能は再現しやすくなった。同時に、新しいネイティブサービスごとに、横断コントローラが発見・調整できるオブジェクトが追加された。クラウドの進歩は Prosimo の価値の一部を減らす一方で、プロバイダー間の翻訳の必要性を高める可能性があった。

決定的な要因は技術と同じくらい組織的だった。単一クラウドに集中し、強力な内部エンジニアリングを持つ企業はネイティブツールを好む可能性がある。断片化したチームを持つマルチクラウド企業は単一のコントロールプレーンを評価するかもしれない。規制対象組織は独立した証拠レイヤーを評価する一方で、認証情報とデータの集中を懸念する可能性がある。

どのアーキテクチャもロックインを排除しなかった。ネイティブツールは1つのクラウドの API とセマンティクスへの依存を高めた。横断コントローラはそのグラフ、ポリシー、エッジへの依存を高めた。有用な問いは、依存関係が可視的で、移植可能で、運用モデルに適合しているかどうかだった。

障害はコントローラ、エッジ、クラウド API、アイデンティティ、アンダーレイに存在する可能性があった

分散アーキテクチャは単一のトラフィックハブへの依存を減らしたが、相互作用する複数の障害ドメインを生み出した。中央サービスが利用できないか、古いインテントを保持する可能性があった。エッジがダウンするか、孤立する可能性があった。クラウド API が変更の一部を拒否する可能性があった。アイデンティティプロバイダーが利用できない可能性があった。アンダーレイが容量を失うか、予期しない経路を取る可能性があった。挿入されたファイアウォールがリソースを使い果たす可能性があった。

部分的な障害は特に難しい。1つのプロバイダーがルート変更を受け入れ、別のプロバイダーが拒否する可能性がある。コントローラの意図した状態は実際の状態から乖離する。トラフィックは非対称になるか、検査を迂回する可能性がある。信頼性の高いシステムには、調整、冪等操作、段階的変更、明示的なエラー状態、プロバイダーごとのロールバックが必要である。

公開ソースは可用性と最適化のアーキテクチャを説明しているが、障害注入の独立した研究、完全なインシデント登録、普遍的なサービスレベル結果は含まれていない。回復力の主張は、文書化されたアーキテクチャまたは指名された顧客例に結び付けられたままにすべきである。

買収は別の障害ドメインを追加する。製品の継続性である。顧客は、どのコンソール、API、エッジイメージ、ポリシー、サポート組織がレガシーシステムを置き換えるかを知る必要がある。技術的に成功したコード統合は、商用および運用の境界が不明確なままの場合、移行リスクを生み出す可能性がある。

クラウド認証情報はコントローラを重要な管理インフラにした

発見とオーケストレーションにはクラウドアカウントへのアクセスが必要だった。読み取り専用インベントリは制限された権限を使用できたが、ルート、セグメント、サービスの変更にはより強力な権限が必要だった。したがって、コントローラはワークロードを所有していなくても、特権管理プレーンに位置していた。

認証情報の侵害はトポロジを露出させたり、広範な変更を可能にしたりする可能性があった。ソフトウェアのバグやオペレーターのエラーは、複数のクラウドにポリシーを伝播させる可能性があった。リスクは有用性とともに増加した。プラットフォームが管理するアカウントとサービスが増えるほど、潜在的な影響範囲は大きくなった。

企業は最小特権ロール、発見と書き込みの分離された認証情報、多者承認、完全な監査、ローテーション、緊急失効、コントローラから独立した復旧経路を必要とした。公開文書は完全な独立セキュリティ評価を提供していない。これらの要件は検証済みの保証ではなく、必要な展開制御のままである。

テレメトリグラフも同様に機密性が高かった。アプリケーション名、ネットワーク構造、ポリシー、ユーザー関係、ルートヘルス、コストを明らかにする可能性があった。買収後のガバナンスは、このデータがどこに保存され、Palo Alto Networks のどの製品が使用でき、レガシー顧客の権限がどのように移行されたかを指定する必要がある。公開ソースはこれらの質問に回答していない。

買収は名目上中立なレイヤーをセキュリティプラットフォームに移した

Prosimo の独立した立場は、クラウドとセキュリティサービス間の共通レイヤーとして提示することを可能にした。Palo Alto Networks が所有者になると、インセンティブは変化した。買収された技術は VM-Series や他の Palo Alto 製品の展開を容易にできた。これはより良い統合を生み出す一方で、サードパーティ検査のサポートに関する疑問を提起する。

所有権は中立性が消えたことを証明しない。提供された要素には現在のパートナーマトリックスやアーキテクチャは含まれていない。しかし、問うべき質問は変わる。顧客は、コントローラが複数のベンダーに開かれたままか、ポリシーとテレメトリがエクスポート可能か、最適化が所有者のポートフォリオを優先するかを知る必要がある。

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

これはインフラストラクチャでよく見られるパターンである。スタートアップは難しい調整問題を抽象化し、大規模ベンダーは主要製品の使用と制御を増加させるため、その抽象化を買収する。買収者は展開への経路を得る。顧客は統合を得て、ベンダー独立性を失う可能性がある。

現在の製品マッピングは主要な欠落事実である

公開記録は買収と統合を確認しているが、AXI、Network Transit、App Transit、AIR、Nebula と Palo Alto Networks の現在の製品またはオファリングとの完全な対応を提供していない。サポート終了日、移行手順、機能継続テーブルも公開していない。

このギャップは現在形での製品レビューを妨げる。歴史的説明は Prosimo が何を構築し、なぜ重要だったかを説明する。今日どの機能が利用可能で、ライセンスされ、サポートされているかは述べていない。現代の展開アドバイスは、古い Prosimo の発表ではなく、Palo Alto Networks の現在のドキュメントに基づく必要がある。

マッピングの欠如は戦略分析も制限する。グラフとオーケストレーションの完全な吸収は、資産発見とファイアウォール配置の選択的使用とは異なる。前者は広範なマルチクラウド制御サービスを生み出し、後者は主にセキュリティ展開を加速するために Prosimo を使用する。共同創業者の声明は技術的継続性を確認するが、この境界を解決しない。

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

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

単一のアクターが完全な経路を制御しているわけではない。企業はアカウントの所有権、ビジネスインテント、アプリケーション設計、付与する権利を制御する。横断コントローラはトポロジを発見し、ポリシーを翻訳し、経路を選択し、ネイティブルート状態を変更できる。クラウドは自社の API、トランジットサービス、プライベートポイント、バックボーン、多くの障害ドメインを制御する。通信事業者とコロケーションサイトは他の部分を制御する。セキュリティサービスは検査されたトラフィックが許可されるかどうかを決定する。

Prosimo は最も戦略的な中間立場を求めた。アンダーレイを所有せずに、その上のグラフとポリシー翻訳を所有したいと考えた。このレイヤーを制御する者は、どの資産が見えるか、セグメントがどのように表現されるか、エッジがどこに配置されるか、どのサービスがトラフィックを検査するか、どのテレメトリが権威を持つかを決定する。これは、ファイバーが第三者に属していても実用的なルーティング権力である。

買収後、Palo Alto Networks は生き残った技術を所有し、その統合、販売方法、開発を決定する。クラウドは自環境で主権を保ち、企業は認証情報を失効させたり、別のアーキテクチャを選択したりできる。ただし、トポロジ、ポリシー、ワークフローがコントローラに依存するようになった場合、出口はコストがかかる可能性がある。

したがって、答えは分散している。企業は許可し、コントローラは調整し、クラウドと通信事業者の基盤インフラは輸送し、セキュリティプラットフォームは施行する。Prosimo の物語は、調整レイヤーの所有権は、クラウドアカウントや物理経路が移動しなくても変わり得ることを示している。

主要なソースレジストリ

買収後も Prosimo が関連性を持つ理由

Prosimo はインフラストラクチャの実際の進化を捉えた。ネットワーク運用の単位は、デバイスとプレフィックスから、アプリケーション、アイデンティティ、サービス依存関係、ポリシーグラフへと移動している。ネイティブ API はネットワーク状態をプログラム可能にし、分散ソフトウェアエッジはポリシー適用ポイントの移動を可能にする。複数のクラウドを見るコントローラは、個々のコンソールだけでは達成できないアクションを調整できる。

同社はまた、この調整のコストも明らかにした。共通レイヤーには特権認証情報、継続的な API メンテナンス、正確な発見、セマンティック翻訳、テレメトリ、運用規律が必要である。断片化した作業を減らす一方で、新しい集中点を生み出す。ルーティングを簡素化する同じシステムが、誤った決定の影響範囲を拡大する可能性がある。

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

したがって、Prosimo は単に失敗した独立ブランドとしても、プラットフォームがマルチクラウドを解決した証拠としても記憶されるべきではない。その永続的な貢献は、横断グラフをインフラストラクチャとして定義したことである。残る問いは、このグラフが大規模なセキュリティ企業内で、十分に透明性があり、移植可能で、ガバナンスが効き、信頼に値するかどうかである。