テクノロジーとその仕組みに対する私たちの理解は、さまざまな面で根本的に変わりつつあります。組織がこうした変化にどのように対応しているかを把握するため、F5はテクノロジー分野を専門とする大手市場調査会社SlashDataと提携し、世界各地の多様な業界でIT、セキュリティ、ソフトウェア開発に携わる数百人のリーダーと実務担当者を対象に調査を実施しました。
参加者には、NGINXオープンソースプロジェクト、NGINX Open Source、F5 NGINX商用製品のユーザーが含まれていました。調査結果から、コンテナ化、セキュリティ、開発者プラットフォーム、AIの分野で早急な変革を目指す組織が抱く切迫感が裏付けられました。以下に、2025年NGINX年次調査の主な結果をご紹介します。
新たなトレンド:エージェント型AIと非CPUが切り拓く未来
F5 NGINXは、AIインフラストラクチャの標準的なフロントドアとして選ばれる存在となっています。主要なAIハードウェアおよびソフトウェアプロバイダーは、AIアプリケーション向けの主要または推奨のリバースプロキシおよびデリバリーコントローラーとしてF5 NGINXを採用しています。調査結果からは、NGINXユーザーだけでなく、より広範なアプリケーションデリバリーコミュニティでも、AI主導の未来を受け入れる動きが加速していることが明らかになりました。
AIエージェントの利用:エージェント型AIタスクの利用状況について尋ねたところ(図1参照)、現在の導入率が最も高かったのは「NGINXの構成」で25%、僅差で「ネットワークトラフィックの最適化と負荷分散」が24%でした。「インフラストラクチャのデプロイとスケーリング」と「セキュリティ脆弱性の修復」は、いずれも現在23%の回答者が利用しています。
総合的な取り組み状況:エージェント型AIを現在利用している回答者と試験的に利用している回答者の回答を合算すると、「ログ分析とプロアクティブなトラブルシューティング」が48%で首位となりました。「NGINXの設定」と「インフラストラクチャのデプロイとスケーリング」はそれぞれ46%で並び、「ネットワークトラフィックの最適化」が45%で続きました。
今後最も関心が高い分野:「ドリフトの検出と修正」への今後の関心が33%で最も高く、次いで「NGINXデプロイメントの監視」が32%、「インシデントのアラートとトリアージ」が31%でした。
専用ハードウェア: 調査回答者の25%がGPU、TPU、またはFPGA上でワークロードを実行しています。これは、従来汎用コンピューティングを中心としてきたインフラストラクチャとしては注目に値します(図2を参照)。この割合は今後も増加すると予想されます。その主な要因として、小規模AIモデルの進歩、Dockerやクラウドハイパースケーラーなどのクラウドネイティブインフラストラクチャで小規模AIモデルを実行しやすくなったこと、アプリケーションデリバリープロセスのオフロード(暗号化処理やSSL処理のNPUおよびFPGAへのオフロード、AI推論のGPUおよびTPUへのデプロイなど)が挙げられます。
主な障壁:調査回答者は、AI統合の主な障壁として、セキュリティ上の懸念(26%)と精度への信頼不足(24%)を挙げました。統合の複雑さ、コンプライアンスおよび規制上の制約、エージェントの機能に対する理解不足はいずれも17%でした。
クラウドネイティブは広く普及しているものの、なお発展途上
コンテナとKubernetesを起点とするクラウドネイティブ革命は、始まってから10年以上が経過した今も勢いを増し続けています。クラウドネイティブの主要要素は、導入がほぼ普遍的になっているものの、完全な普及にはまだ時間がかかります(図3を参照)。
具体的には、調査から次のことが明らかになりました。
- マルチ環境の時代がまさに到来:組織の66%が少なくとも1つのクラウドを利用していますが、導入先としてはオンプレミスが39%で依然として最多であり、パブリッククラウドは38%、ハイブリッドは36%です。これは、単純な「クラウド移行」という構図ではなく、現代のインフラストラクチャが複雑かつ分散している実態を示しています。
- コンテナの導入にはまだ拡大の余地があります:コンテナ上でワークロードを実行している回答者はわずか42%で、マイクロサービスの導入率も31%にとどまっています。仮想マシンが60%と主流であることから、多くの組織が依然としてクラウドネイティブ変革の初期段階にあることがうかがえます。
- Kubernetesの分散化: セルフマネージド型のKubernetesは24%でコンテナオーケストレーションをリードしています。一方、Red Hat OpenShiftはセルフマネージド型とフルマネージド型を合わせて21%を占め、Amazon Web Services(21%)、Microsoft Azure(17%)、Google Cloud Platform(17%)のマネージドサービスも大きく普及しています。
APIとマイクロサービスのセキュリティ管理には大きなギャップ
過去10年間で、多くのテクノロジー組織が、社内外の業務をつなぐ中核的な仕組みとしてAPIを採用するようになりました。クラウドネイティブアーキテクチャでは、APIファーストが中核的な設計原則です。これに伴い、回答者の86%がAPIインフラストラクチャの管理にAPIゲートウェイを導入しています(図4を参照)。
APIへの移行が広く進み、APIゲートウェイが普及しているにもかかわらず、大半の組織ではAPIセキュリティ対策が依然として未成熟です(図5を参照)。組織の86%がAPIを利用している一方で、APIセキュリティを実装している組織はわずか34%にとどまります。これは、最新のアプリケーションインフラストラクチャにおける極めて大きなリスク要因です。
APIセキュリティの中核を成すもう2つの要素であるAPIトラフィック分析(43%)とオブザーバビリティ(38%)に注力している回答者は、いずれも半数未満です。このギャップは、API全般の可視化と管理に課題があることを示していると考えられます。実際、回答者の23%はチームごとに異なるAPI管理手法を採用しています。こうした分断は、組織全体でAPI管理の標準的な「ゴールデンパス」を採用することの難しさに起因していると考えられます。
プラットフォームエンジニアリングは進化したものの、まだ成熟には至っていない
バズワードとして登場したプラットフォームエンジニアリングは、今や広く普及しています。実際、回答者の65%が、プラットフォームエンジニアリングの機能と責任の導入に着手しています(図6を参照)。その形態は、専任のプラットフォームチームを擁する大規模組織から、1人のチームメンバーがプラットフォームエンジニアリングのリードを務めるケースまでさまざまです。約27%が小規模な専任プラットフォームエンジニアリングチームを設置し、21%の組織では開発/運用チーム内にプラットフォームエンジニアリングを担当する個人の役割を設けています。さらに、13%の組織が大規模な専任プラットフォームエンジニアリングチームを設置しています。このように、プラットフォームエンジニアリングの価値提案は明らかに広まり、定着しています。
とはいえ、チームの規模を問わず、プラットフォームに関する課題への回答からは、導入初期段階での苦労が明らかになりました。重大な課題はないと回答したのは、回答者のわずか20%でした。残りの回答者は、セキュリティとコンプライアンス(18%)、ドキュメントの保守(16%)、テクノロジーを最新の状態に保つこと(16%)、リソースの制約(14%)など、プラットフォームエンジニアリングに関する多岐にわたる課題が組織に実際に影響を及ぼしていると回答しました。
調査では、サービス提供と価値提案の優先事項について、大規模チームと小規模チームの間に明確な違いがあることがわかりました。予想どおり、大規模チームはより高度な領域に重点を置く一方、小規模チームの重点領域は従来のDevOpsと類似していました。大規模な専任プラットフォームエンジニアリングチームは、Database as a Service(54%)、オブザーバビリティ(52%)、API管理(51%)、ファイアウォールの構成と管理(54%)、CI/CDパイプラインツール(50%)などの高度なサービスを提供する傾向が強くなっています。
クラウド、AI、APIの進化に対応し続ける難しさ
企業は、管理が追いつかないほどの速さでテクノロジーを導入しています。調査によると、組織はコンテナ、API、プラットフォームエンジニアリングの導入に意欲的である一方、構築したものを安全に運用する準備が現時点では整っていません。なかでも最も重大な問題はAPIセキュリティです。ほぼすべての組織がAPIを運用していますが、3分の2は基本的な保護対策を講じていません。これは将来のリスクではなく、今まさに本番環境に存在する現実の脆弱性です。
一方、特定の領域では着実な進展が見られます。AIエージェントは、デモにとどまらず、実際のインフラストラクチャタスクを大規模に処理できる段階に近づいています。GPUや専用プロセッサーは標準になりつつあります。プラットフォームエンジニアリングチームは、役割をまだ模索している場合もあるものの、ほとんどの組織に設置されています。
今、重要なのは実行を徹底することです。F5は、現在の機能を適切に管理できるようになるまで、新たな機能を追加しないことを推奨します。APIのセキュリティと管理手法を標準化し、システムを把握するために必要なオブザーバビリティを確保してください。また、プラットフォームチームの責任を明確にし、成果を上げるために必要なリソースを提供してください。
モダンで効率的なインフラストラクチャを構築するためのテクノロジーは、すでに存在します。今こそ、安全性と持続可能性を確保するために、地道ながらも必要な取り組みを進めるときです。
F5 NGINX製品の詳細については、Webページをご覧ください。
著者について

関連するブログ記事
チュートリアル:NGINXを使用してアプリケーション向けにOpenTelemetryを構成する
OpenTelemetryを使用してNGINXサーバーの状態と健全性をより明確に把握することで、問題のトラブルシューティングを行い、Webアプリケーションのパフォーマンスを向上できます。
AkitaのNGINX Plus認定モジュールでAPIエンドポイントの問題を特定・修正
Akita SoftwareのAPIオブザーバビリティ向け新しいNGINX Plus Certified Moduleを活用して、APIエンドポイントの問題をより迅速に特定し、修正できます。
JavaプロジェクトをスキャフォールディングしてKubernetesネイティブアプリを構築する方法
Red HatのシニアプリンシパルデベロッパーアドボケイトであるDaniel Oh氏が、Javaプロジェクトをゼロから構築するためのひな形を作成し、Kubernetesネイティブアプリケーションとしてビルドする方法を解説します。
F5 NGINXaaS for Azureのご紹介:Microsoft Azureでネイティブに利用できるSaaS型ロードバランシング
NGINXaaS for Azureは、NGINX PlusをAzureネイティブのSaaSとして利用できるサービスです。NGINXの設定を容易にリフト&シフトできるため、クラウド導入とモダンアプリの展開を加速できます。

SELinuxでNGINXおよびNGINX Plusを使用する
Red Hat Enterprise Linux(RHEL)および関連ディストリビューションでSecurity-Enhanced Linux(SELinux)を有効にすると、デフォルト設定によりNGINXとNGINX Plusの一部の操作が制限されます。この記事では、すべての機能を利用できるようにSELinuxの設定を変更する方法について説明します。
NGINX PlusによるAWS Auto Scalingグループの負荷分散
新しいnginx-asg-sync統合ソフトウェアにより、NGINX PlusはAWS Auto Scalingグループの負荷を直接分散できるため、クラウドでの負荷分散がさらに柔軟になります