A10 NetworksのAI Gatewayを巡る主張は検証が難しい

A10 Networksは、AI gatewayの発表に関連するGoogle Newsの見出しに登場した。しかし、同社の公開製品情報はより複雑な実像を示している。

2026年8月15日時点で、A10の公開ニュースルームや製品カタログには、該当するgatewayの発表は見当たらない。検証できる動きは別のものだ。A10はAI firewallを導入し、TrojAIを買収するとともに、モデル、アプリケーション、自律型agent向けのセキュリティを拡充している。

この違いは重要である。AI gatewayとAI firewallは関連しつつも別個の課題を解決するからだ。また、企業の購入担当者がこの見出しをどう解釈すべきかにも影響する。A10は単に新たなソフトウェアカテゴリへ参入しているのではない。ネットワークインフラにおける立場をAI securityへと拡張しようとしている。

F5、Kong、Cloudflare、Vercel、そして主要クラウドプラットフォームはすでに、モデルのルーティング、認証、可観測性、ポリシー適用のためのgateway機能を提供している。A10のより強い主張は別の場所にある。同社は、こうした制御を高スループットのトラフィック管理、ハードウェア支援型の検査、AI専用のruntime defenseと組み合わせようとしている。

この戦略には、TrojAIのred-team testingやagentic workflowの保護など、信頼できる構成要素がある。ただし、A10はこれらの構成要素が「A10 AI Gateway」という名称の一般提供製品を形成していることを公には示していない。

そのため、企業の購入担当者には実務的な疑問が残る。A10は本番AI向けの完全な制御ポイントを構築しているのか。それとも、より広範なインフラ戦略のもとで隣接するセキュリティ製品を組み合わせているのか。

A10 Networksの発表が実際に裏付けていること

検証された出来事は、スタンドアロンのAI gatewayが明確に文書化された発表ではなく、A10のAI securityポートフォリオの拡張である。

A10の公開製品カタログでは、A10 AI FirewallがAI専用のセキュリティ製品として位置付けられている。同社はこれを、AI applicationとlarge language modelをAIネイティブの脅威から保護するguardrail layerと説明している。

firewallは、ユーザー、application、またはagentがアクセスを得た後にモデルとのやり取りを検査する。prompt injection、機密データの露出、モデルの悪用、関連する挙動について、promptとresponseを評価できる。

AI gatewayは通常、より広範なトラフィック制御の役割を担う。clientの認証、credentialの管理、利用制限の適用、requestのルーティング、モデルやproviderを横断したアクティビティの記録を行う。

A10自身も、過去の技術ガイダンスでこの違いを説明している。同社はgatewayを認証・認可のポイントとし、AI firewallはpromptとresponseの内容を検査するものと説明した。

この説明は、2つのlayerが代替可能ではないため、今も重要である。gatewayは、自然言語上の意図を理解せずに未認可のrequestを拒否できる。firewallは、認可済みのrequestを検査し、内容が悪意あるものに見える場合には依然として遮断できる。

A10は2025年5月、新たなAI firewall機能を公開デモした。同社によると、その機能はcustomおよびcommercial language modelを公開するAPIやURLの前段に配置できる。

AI firewall demonstrationでは、promptレベルの検査、機密情報の制御、prompt injection対策が説明された。A10はGPU対応ハードウェアと予測的なネットワーク分析についても言及している。

これらはデモに付随する企業側の主張であり、独立した性能試験ではない。A10はこの発表で、比較可能な検出率、レイテンシー測定値、false positiveの結果を公表していない。

同社は2026年6月15日、TrojAIを買収することで、より具体的な戦略的行動を取った。TrojAIは、AI model、application、agentic workflowのテストと保護のためのセキュリティツールを開発している。

TrojAI acquisitionにより、主に2つのlayerが加わった。TrojAI Detectは導入前にAI systemの脆弱性を検査し、TrojAI Defendは運用中のやり取りを監視・保護する。

A10は、この組み合わせにより、ハードウェアベースのAI firewallと、TrojAIのソフトウェアベースのテストおよびruntime protectionを統合すると述べた。また、この買収はon-premises、cloud environment、hybrid infrastructure全体での導入を支援するとしている。

これは、見出しレベルのgateway発表よりも実質的な動きである。A10にとって、開発中のモデルをテストし、導入後の挙動を検査する技術をもたらす。

TrojAIはModel Context Protocol、すなわちMCPもサポートしている。MCPは、AI applicationが共通のinterfaceを通じてtool、data source、serviceと接続できるようにする標準だ。

MCPのサポートにより、セキュリティ上の課題はchatbotのpromptを超える。agentは企業記録を取得し、workflowを実行し、外部serviceと通信できる。許可されたすべてのactionが、侵害されたinstructionによる影響を拡大する。

A10によると、TrojAIのred-teamによる発見は、同社のguardrail intelligenceの更新に活用できる。このfeedback loopは、導入前のテストとruntime enforcementを結び付ける可能性がある。

ただし、これは依然として企業が説明する統合の道筋である。A10は、顧客環境全体で発見事項がどの程度迅速に実施可能な保護へ転換されるかを示す包括的なbenchmarkを開示していない。

同社はまた、この買収が2026年度の財務結果に重要な影響を与えることはないと述べた。この声明は、即時の売上変革ではなく、戦略的な技術買収であることを示している。

したがって、A10の検証済みロードマップには、AI firewall、application protection、red-team testing、runtime defense、agent securityが含まれる。これらの構成要素は、enterprise AI control layerの一部に似ている。

しかし、Google Newsの見出しが示唆する正確な発表を独立して裏付けるものではない。A10が製品名、documentation、提供状況の詳細、対応するdeployment configurationを公開するまで、購入者は「AI gateway」を戦略的な解釈として扱うべきである。

Google Newsがより大きなEnterprise AIの物語を浮上させている理由

この見出しが重要なのは、enterprise AIが孤立した実験から、ネットワークおよびセキュリティチームが統制すべき本番トラフィックへ移行しているためだ。

初期のgenerative AIプロジェクトでは、従業員がhosted chatbotを利用するケースが多かった。セキュリティ制御は、account access、データ取扱規則、従業員が機密情報をpublic serviceに貼り付けたかどうかに焦点を置いていた。

本番AIでは、異なる運用モデルが生まれる。applicationは複数のmodelを呼び出し、retrieval systemは内部データを追加し、agentはbusiness recordを変更できるtoolに接続する。

すべてのrequestは、identity、networking、application、model、toolのlayerを通過し得る。これらのlayerは多くの場合、異なるチームに属し、それぞれ別個のlogを生成する。

AI gatewayは、この複雑性の一部を一元化することを約束する。provider credentialを保持し、applicationを認証し、制限を適用し、トラフィックをルーティングし、共通のaudit trailを作成できる。

このカテゴリが魅力的なのは、企業がすべてのworkloadを1つのmodelに委ねることがほとんどないためだ。チームはcodingにはあるprovider、document analysisには別のprovider、機密情報にはlocal modelを使う場合がある。

ルーティングは可用性にも対処できる。あるmodelやproviderが利用不能になった場合、gatewayはすべてのapplication teamにintegrationの書き換えを強いることなく、互換性のあるrequestをredirectできる。

cost controlもgatewayの機能の1つだが、価格がセキュリティ判断を支配すべきではない。管理者には、usage attribution、quota、agentが予期しないrequest volumeを生成した場合のwarningが必要だ。

従来のAPI gatewayはすでに、これらのタスクのいくつかを実行している。clientを認証し、rate limitを適用し、requestを記録し、service間でトラフィックをルーティングする。

AI trafficには、特異なcontentとbehaviorが加わる。promptには自然言語が含まれ、model responseは変動し、一見成功したrequestでも安全でないactionを生み出す可能性がある。

これがAI firewall layerの重要性を示す理由である。OWASPは、prompt injectionをlanguage-model applicationにおける主要リスクの1つとして挙げている。細工されたinputはmodelの挙動を変え、情報を開示させ、downstream decisionに影響を及ぼし得る。

LLM risk frameworkは、機密情報の開示、supply-chainの弱点、data poisoning、不適切なoutput handling、過剰なagencyも扱っている。

過剰なagencyは、AI systemがそのtaskに必要な以上のpermissionやautonomyを受け取る場合に発生する。agentが人間による各actionの確認なしにtoolを呼び出せる場合、リスクは高まる。

gatewayはagentが有効なcredentialを持つことを検証できる。しかし、その認証済みagentが従うすべてのinstructionが安全だと仮定することはできない。

逆に、AI firewallはinteractionを検査できても、gatewayからidentity、routing、policyのcontextを必要とする場合がある。これらのlayerが情報を共有するとき、enterprise control pointの価値は高まる。

ここにA10の機会がある。同社はすでにapplication delivery、load balancing、DDoS defense、traffic inspection、centralized management製品を販売している。

A10は、AI trafficもまたbusiness-critical application flowの1つだと主張できる。そのうえで、promptとresponseのsemantic contentに対する制御を追加しながら、使い慣れたnetwork機能を適用できる。

semantic contentとは、protocolやdestinationだけでなく、requestの意味を指す。有効なHTTPS requestでも、従来のnetwork firewallには見えない悪意あるinstructionを含み得る。

A10の既存顧客との関係も重要である。同社によると、enterprise、service provider、cloud platformにまたがる7,000社超の顧客にサービスを提供している。

この数字はA10によるものであり、AI専用製品を利用している顧客数を明らかにするものではない。それでも、既存のインフラ基盤は、関連するsecurity controlを導入する際の摩擦を減らし得る。

networking vendorは、規制の厳しい組織にとって重要なdeployment choiceも提供できる。一部の企業は、prompt、model、security telemetryを自らが管理するinfrastructure内に保持しなければならない。

A10はこの要件をsovereign AI securityと呼ぶ。実務的には、model、data、agent、protective controlがどこで動作するかに対する権限を維持することを意味する。

このアプローチは、hosted serviceとしてのみ提供されるgatewayとは異なる。厳格なデータ所在地要件を持つ政府、金融、医療、産業組織に訴求する可能性がある。

したがって、Google Newsを通じて浮上している戦略的な物語は、単一の製品ラベルより大きい。A10は、traffic pathの所有権がAI policy enforcementの所有権になり得るかを試している。

A10 NetworksとSoftware-First AI Gateway路線の比較

A10の主な競争は、あるvendorと別のvendorの対決ではなく、infrastructure-integrated securityとsoftware-first gateway controlの対決である。

software-first gatewayは通常、AI applicationとそのmodel providerの間に置かれる。developerはapplicationをgatewayに向け、その後にrouting、logging、limit、safety policyを設定する。

Kongは、API gateway architectureをmodel、MCP server、agent-to-agent communicationへと拡張している。AI gateway documentationでは、gatewayをAI-native applicationのためのconnectivityおよびgovernance layerとして位置付けている。

F5は、A10のnetworking heritageにより近い道筋を取る。同社のNGINX製品はすでにapplication delivery pathに配置されており、F5 AI GatewayはAI専用のpolicyおよびsecurity processingを追加している。

F5 gateway approachは、モデルトラフィック管理をNGINXのプロキシおよびロードバランシングの役割と結び付けるものだ。これにより、F5はA10にとって最も明確な既存比較対象となる。

CloudflareとVercelは、分散型の開発者向けインフラを重視している。両社のゲートウェイ製品は、利便性の高いモデルアクセス、ルーティング、可観測性、プロバイダー抽象化に焦点を当てている。

プロバイダー抽象化は、複数のモデルサービスに対してアプリケーションへ単一のインターフェースを提供する。これにより、統合作業を減らし、プロバイダー変更を容易にできる。

Palo Alto Networksはセキュリティ側から参入している。同社が計画するPortkey買収は、AIゲートウェイをはるかに大きなサイバーセキュリティ製品群の隣に配置するものだ。

Portkey acquisitionは、ゲートウェイを自律型エージェントのコントロールプレーンとして位置付けている。この方向性は、アイデンティティ、モデルアクセス、エージェントの挙動を、より広範なエンタープライズセキュリティプラットフォームに組み込むものだ。

A10が存在感を維持するために、すべての競合機能をそろえる必要はない。ソフトウェアのみの制御では容易に再現できない利点を、自社のインフラ上の立ち位置が生み出すことを証明する必要がある。

レイテンシーは、その利点の一つになり得る。AIアプリケーションはすでに、モデル推論、検索、安全性チェック、ツール実行を待っている。複数の検査サービスを追加すれば、応答時間が増加する可能性がある。

A10は、ハードウェア支援処理により、TLS復号やトラフィック最適化などの処理をオフロードできるとしている。また、AIファイアウォールは、必要な可用性を損なうことなくプロンプトレベルのトラフィックを検査できるとも主張している。

こうした主張には比較可能な証拠が必要だ。エンタープライズアーキテクトが求めるのは、AIワークフローの外側で測定したパケットスループットだけではなく、現実的なリクエストサイズでのエンドツーエンドのレイテンシーである。

また、導入の詳細も必要になる。物理アプライアンスはプライベートデータセンターに適しているかもしれない一方、クラウドネイティブアプリケーションではソフトウェアインスタンス、コンテナ、またはマネージド型の強制機能が必要になる可能性がある。

こうした環境をまたぐカバレッジは、制御機能が共有プラットフォームになるか、それとも孤立した別のセキュリティ製品になるかを左右し得る。

A10の潜在的な優位性は、プライベートAIインフラでより明確になる。ローカル推論クラスタを運用する組織は、受信リクエストの管理、ワークロードの分散、モデルエンドポイントの保護、ネットワーク容量の監視を行わなければならない。

ロードバランシング、暗号化トラフィックの検査、アプリケーションセキュリティ、AI対応の制御機能を組み合わせるプラットフォームは、運用の分断を減らせる可能性がある。

ただし、顧客が欠けている一つの機能を得るために大規模なスタックを導入しなければならない場合、同じ統合は弱点にもなり得る。ソフトウェアファーストのゲートウェイは、しばしば一つの開発チームから導入され、価値を証明した後に拡大する。

A10の製品はネットワーキング、インフラ、アプリケーションセキュリティ、AIガバナンスの予算にまたがるため、より長い購買サイクルに直面する可能性がある。

開発者体験も別の課題となる。ゲートウェイの導入は、多くの場合、ドキュメント、ソフトウェア開発キット、デプロイメントテンプレート、小規模なアプリケーション変更から始まる。

A10がこれまで用いてきた言葉は、ネットワークアプライアンス、アプリケーションデリバリーコントローラー、セキュリティプラットフォームを中心としている。大規模なインフラプロジェクトを待たずに、開発者がAI制御機能を利用できることを示す必要がある。

TrojAIはこのギャップへの対応を支援する。同社のソフトウェアはモデルのテストと実行時インタラクションの保護を行え、MCPサポートはA10を新たなエージェントアーキテクチャへ接続する。

しかし、ソフトウェアを買収しただけで、一貫したプラットフォームが自動的に生まれるわけではない。顧客には、TrojAIとA10の製品全体で一貫したポリシー、共有テレメトリー、管理可能な導入が必要だ。

したがってA10の主な対抗相手は、ソフトウェアファーストのゲートウェイが約束するシンプルさである。同社の答えは、パフォーマンスおよびセキュリティインフラとのより深い統合だ。

どちらが定義上勝つわけでもない。ソフトウェアゲートウェイは外部セキュリティサービスで過負荷になる可能性があり、統合プラットフォームは導入・運用が難しくなる可能性がある。

エンタープライズの購入者は、実際のAIトラフィックに基づくアーキテクチャテストを要求すべきだ。評価には、モデルルーティング、プロンプト検査、エージェント権限、障害時の挙動、運用責任を含める必要がある。

AIゲートウェイの主張が依然として証明していないこと

A10は信頼に足るセキュリティコンポーネントをそろえているが、公開情報はまだ統合されたエンタープライズAIゲートウェイを証明していない。

第一の不確実性は製品アイデンティティにある。A10のカタログには、A10 AI Firewall、TrojAI by A10、ThreatX、Thunder ADC、および関連セキュリティ製品が掲載されている。

しかし、A10 AI Gatewayという独立した製品は明確には記載されていない。この不在は、命名、リリース時期、あるいはA10のより広範な戦略を見出しが過度に緩く解釈したことを反映している可能性がある。

製品ローンチでは、ドキュメント、提供状況、対応モデル、デプロイメント形式、ポリシー機能、運用上の制限を提示すべきである。こうした詳細を欠く公開主張だけでは、調達には不十分だ。

第二の不確実性は統合にある。A10はTrojAIを進化するセキュリティポートフォリオに統合すると述べているが、買収完了はこの記事の日付のわずか2カ月前だった。

統合は、製品を一つの営業提案に並べる以上の意味を持ち得る。ポリシーはテスト環境と実行時システムの間で一貫して移行し、イベントは共通の監視ワークフローに到達すべきだ。

アイデンティティコンテキストも、各レイヤーをまたいで維持される必要がある。セキュリティチームは、どのユーザー、アプリケーション、またはエージェントがプロンプトを生成したか、どのモデルがそれを処理したか、どのツールが動作したかを把握できるべきである。

ある製品がトラフィックを認証し、別の製品がプロンプトをスキャンし、さらに別の製品が結果として生じるアプリケーション呼び出しを監視する場合、その連鎖は複雑になる。

第三の不確実性は有効性である。AIセキュリティ製品は、通常の業務利用を妨げることなく、有害な挙動を検出しなければならない。

誤検知はワークフローを中断させ、見逃しはデータを露出させたり、エージェントによる不正な操作を許したりする可能性がある。AIシステムが大規模に稼働する場合、どちらの結果も重要性を増す。

A10は、モデル、言語、エンコーディング手法、間接プロンプト、エージェント型ツール呼び出しにまたがる検出品質を確立するのに十分な独立評価を公表していない。

レッドチーミングは、導入前にシステムをテストすることで信頼性を高められる。しかし、言語モデルは確率的に振る舞うため、テスト結果が将来のすべてのインタラクションで同一の挙動を保証することはできない。

脅威パターンも進化する。攻撃者は、文書、ウェブサイト、画像、ツールメタデータ、あるいはエージェントのワークフロー中に取得されるデータに指示を隠すことができる。

元のユーザープロンプトだけを検査するゲートウェイは、その文脈の一部を見逃す。効果的な保護は、情報がモデル、検索システム、ツールの間を移動する過程を追跡しなければならない。

第四の不確実性は運用責任にある。ネットワークチーム、セキュリティチーム、プラットフォームエンジニア、AI開発者、コンプライアンス担当者は、それぞれ異なる制御機能を必要とする。

ゲートウェイは価値ある共有ポリシーポイントになり得るが、それは各チームが責任について合意している場合に限られる。そうでなければ、誰もが監視し、誰も所有しない別のプラットフォームになる。

第五の不確実性はデータの取り扱いに関するものだ。プロンプト検査によって、セキュリティレイヤーそのものに機密性の高い業務情報が露出する可能性がある。

購入者には、保持、暗号化、モデル利用、管理者アクセス、セキュリティテレメトリーの処理場所について明確な回答が必要だ。オンプレミス導入は役立つ可能性があるが、ガバナンス要件をなくすものではない。

第六の不確実性は経済性にある。A10は、TrojAI買収が2026年度の業績に重要な影響を与えないとしている。

この開示は適切に慎重だ。同時に、投資家がこの買収や暗黙のゲートウェイローンチを、新たな成長エンジンの即時の証拠として扱うべきではないことも意味する。

報じられた決算説明会の数値によると、A10のAI関連需要はすでにネットワーキング事業の物語を支えている。2026年度第1四半期の売上高は7,500万ドルに達し、前年同期比成長率は13.4％だった。

経営陣は、その業績の一部をAIインフラ需要によるものとした。ある重要な導入案件は、四半期売上高のおよそ5％を占めたと報じられている。

これらの結果は、AI関連インフラへの需要を裏付ける。しかし、AIファイアウォール、TrojAI、またはゲートウェイ固有の製品による売上高は明らかにしていない。

インフラ需要は、顧客が従来型のロードバランシングやセキュリティ容量を購入する場合でも増加し得るため、製品レベルの導入状況が重要になる。こうした支出は、必ずしも新しいAI制御プラットフォームを実証するものではない。

投資家は三つの主張を分けて考えるべきだ。AIトラフィックはインフラ需要を増加させる、A10は関連するインフラを販売している、そしてA10は差別化されたAIセキュリティ事業を構築できる。

最初の二つにはより強い証拠がある。三つ目は、顧客、統合、財務開示による検証が必要な戦略にとどまる。

元のGoogle News見出しも、情報品質の問題を示している。集約された見出しは、買収、デモンストレーション、製品ロードマップを、より整ったローンチの物語に圧縮し得る。

こうした圧縮は発見には有用だが、技術的な意思決定には弱い。購入者はリンクをたどり、一次発表を確認し、見出しをベンダーの製品ドキュメントと比較すべきである。

急速に変化するインフラ関連のニュースを追跡するチームは、検索可能なtechnical knowledge baseに発表、評価、アーキテクチャ上の決定を保存できる。その記録では、ベンダーの主張と完了したテストを区別すべきだ。

エンタープライズの購入者が次に注視すべきこと

A10が防御可能なAIプラットフォームを立ち上げているのか、それとも既存のセキュリティ製品をAI向けメッセージングへ拡張しているにすぎないのかは、三つのシグナルで分かる。

第一のシグナルは正式な製品リリースだ。A10は、ゲートウェイという名称を使うか別の名称を使うかを問わず、統合制御レイヤーについて明確なドキュメントを公開する必要がある。

そのドキュメントでは、認証、認可、モデルルーティング、レート制御、プロンプト検査、応答検査、MCP保護、対応するロギング統合を特定すべきだ。

さらに、何がA10ハードウェア上で動作し、何がソフトウェアとして動作し、何にTrojAIコンポーネントが必要かを説明すべきである。一般提供開始は、ゲートウェイという解釈をより強めるだろう。

限定的なデモンストレーションやロードマップ上の発言では、それを弱める。購入者には、評価、導入、サポートが可能なバージョン管理された製品が必要だ。

第二のシグナルは統合の証拠である。A10は、レッドチームでの発見がどのように実行時ルールとなり、そのルールがアプリケーション環境全体でどのように動作するかを示すべきだ。

説得力のあるデモンストレーションは、テストから強制まで一つの攻撃を追跡するものになる。それには、関連するアイデンティティ、モデル、エージェント、ツール、そして結果として生じるセキュリティイベントが含まれるだろう。

独立した評価は、管理されたデモンストレーションよりも重みを持つ。有用な証拠には、検出品質、誤検知率、レイテンシー、スループット、コンポーネント障害時の復旧が含まれる。

ここでの成功は、A10の統合セキュリティという論点を強化する。断片化したコンソール、分離されたポリシー、手作業によるルール移行は、ソフトウェアファーストの競合に有利に働くだろう。

第三のシグナルは、顧客および財務面での検証だ。A10は、顧客機密情報を露出させることなく、本番利用のユースケースを特定するか、測定可能な導入状況を開示すべきである。

関連する指標には、AIセキュリティ導入数、既存アカウント内での拡大、継続的なソフトウェア収益への貢献、孤立したインフラプロジェクト以外での需要が含まれる。

単一の大規模AI構築案件は能力を示せるが、集中リスクや時期による影響も生み得る。より広範な導入は、この戦略の持続性を高めるだろう。

今後数回の決算サイクルにおける経営陣のコメントは、AI需要が通常のネットワーク容量、AI固有のセキュリティ製品、あるいはその両方を反映しているかを明らかにするはずだ。

この区別は、投資家がAI関連のすべての受注をゲートウェイ収益と見なすことなくATENを評価する助けとなる。また、購入者が製品の成熟度を判断する助けにもなる。

競合他社の動向も補足的な比較材料にはなるが、主要な判断基準ではない。F5、Kong、Palo Alto Networks、Cloudflare、そしてクラウドプロバイダーは、引き続き制御レイヤーを拡大していくだろう。

A10に必要なのは、最大規模のモデルカタログではない。企業が自社の制御機能を本番トラフィック経路に直接組み込むべき明確な理由である。

その理由としては、プライベートデプロイメント、高スループットの検査、アプリケーションとAIトラフィックを横断する単一のポリシー、あるいはエージェント型ワークフローに対するより厳格な保護が考えられる。

したがって最終的な評価は、見出しが示すほど断定的なものではない。A10は、買収と既存のネットワーク能力を基盤として、エンタープライズAIセキュリティへ本格的に踏み出した。

ただし、完全に独立したゲートウェイがローンチされたことを確認するには、公開されている証拠はまだ十分ではない。この隔たりは戦略の重要性を損なうものではないが、検証を不可欠なものにする。

次にGoogleニュースのアラートがAIセキュリティのロードマップを完成済みのプラットフォームとして扱っていたら、3つの問いを投げかけてほしい。利用可能な製品は何か。独立した検証を受けたものは何か。そして、どの顧客が本番環境で運用しているのか。

エンタープライズチームにとって次の一手は、見出しに左右された購入ではなく、アーキテクチャレビューである。ゲートウェイを評価する前に、モデルトラフィック、エージェントの権限、機密データ、ツールへのアクセスを整理すべきだ。

そのうえで、A10と競合他社を同一の本番環境に近いワークロードでテストする。この比較によって、インフラに統合されたセキュリティが意味のある制御をもたらすのか、それとも管理対象のレイヤーを一つ増やすだけなのかが明らかになる。