10年以上前、ソリューションエンジニアだった私は、さまざまな組織が本業務とは別の試験的なプロジェクトとしてKubernetesの導入を始める様子を見ていました。少人数でひそかに進める実験的な取り組みで、ほかのコンテナスケジューラーのテストと並行して行われることもよくありました。本番のワークロードは依然として、サービスレベル目標と復旧時間目標を軸に構築されたvSphere環境の仮想マシン上で稼働していました。その環境では、サーバー管理者だけでなく、関係者全員が役割を担っていました。それが、いわばエンタープライズグレードということでした。
その後、状況は変わりました。パブリッククラウドが急速に普及し、アプリケーションのモダナイゼーションが進み、企業がコンテナ化されたアプリケーションを実行する手段としてKubernetesが標準になりました。その原動力は、それまでと同じく、迅速な規模拡大を求めるビジネスでした。企業はスピードを上げたいと考えており、私は多くの初期導入のお客さまとともに、Kubernetesをエンタープライズ向けプラットフォームにする取り組みに携わりました。
そうしたお客さまが目指す到達点は、事業側の期待によって決まりました。社内の実験的な開発プロジェクトなら、できる範囲で取り組めばよく、それさえ求められないこともあります。一方、エンタープライズプラットフォームは事業の動きに歩調を合わせる必要があり、理想的には競争力を支える不可欠な存在となります。Kubernetesにも、その水準の期待が寄せられるようになりました。しかし、Kubernetes単体では、vSphereのような完成されたプラットフォームにはなりません。オープンソースの基盤は素晴らしいものですが、それは出発点にすぎません。
F5がSlashDataに委託した新たな調査は、エンタープライズ水準との隔たりの大きさを示しています。本番環境でKubernetesを運用する企業の61%が、他のIT環境と同等以上の基準をKubernetesに求めていますが、エンタープライズ水準の成熟度に達している企業はわずか38%です。
このレポートでは、エンタープライズグレードであることは、単に高いスコアを獲得することではありません。自動化されたアドミッション制御、テナント分離の強制適用、オブザーバビリティの一元化、復旧目標の文書化、過去12か月以内のフェイルオーバーテストの実施が必要です。この調査では、従業員数500人超の組織で実務に携わる担当者から2026年8月に収集した445件の回答を基に、チームが自らの成熟度をどう捉えているかではなく、実際に何を行っているかを評価しました。
大半のIT環境は定着しているものの、成熟には至っていない
このレポートの定義は、すべての組織が歩む道のりの道標だと考えています。どの組織にも完成という状態はおそらくなく、優先順位を決める際には常にトレードオフが伴います。このレポートは、企業の現在地を示しています。半数の企業（51%）は、標準が定義され、おおむね適用されているものの、明らかな不足が残る「確立」段階に位置しています。また、11%はまだ標準化の途上にあります。9割近く（88%）が少なくとも1つの領域で最上位の段階に達していますが、4つすべての領域で達している企業は22%にとどまります。総合スコアが80以上の企業（全体の51%）でも、4社に1社（24%）は前提条件を1つ満たしていないため、最上位の段階には達していません。
最も多く欠けている要素は、オブザーバビリティです。最上位の階層にあと一歩届かなかった企業のうち、36%は一元化されたオブザーバビリティを、31%は自動化されたアドミッション制御を欠いています。どちらも、私が現場で見てきた状況と一致します。担当したお客さまの多くでは、Kubernetesを利用しているかどうかにかかわらず、不足していたのはオブザーバビリティでした。トラブルシューティングは難しく、必要以上に多くの人を巻き込み、責任の押し付け合いに発展することも少なくありませんでした。
アドミッションコントロールが重要なのは、規模に対応するためです。あるお客さまは、環境の規模が大きいため、vSphereのガバナンスをアドミッションコントロールに大きく依存していました。Kubernetes環境は急速に拡大し、レポートで最も多く挙げられた課題は、クラスターと環境の管理の複雑さ（39%）でした。大規模環境で重要となる制御は、多くのチームが想定するよりも早い段階で重要になります。それにもかかわらず、今後12か月間にオブザーバビリティへの投資を計画しているのはわずか28%で、セキュリティとポリシー適用への投資を計画している42%を下回っています。
成熟度の向上はチームの連携から
年月を重ねる中で、それぞれの役割が予想以上に重要だとわかりました。プラットフォームチームやDevOpsチームとお会いしたのは、NGINXを知り、信頼し、使いたいと考えていたからです。また、ネットワークチームやセキュリティチームともお会いしました。これらのチームは、まったく別のワークフローを作るのではなく、企業のNetOpsやSecOpsの運用にKubernetesを組み込めるかどうかを確認したいと考えていました。
あるお客さまは、当時としては異例のことをしました。DevOpsエンジニアに専用のF5 BIG-IPを提供したのです。そのエンジニアは隅々まで使い方を学び、従来のBIG-IP管理者が自ら行うのを私がほとんど見たことのないような活用を実現しました（Stevenさん、見事でした！）。まさに信頼を行動で示した例です。成功は常に協力と信頼から生まれていました。エンタープライズで求められる水準の成果を上げるには、チーム同士が互いを避けて仕事を進めるのではなく、頼り合うことが欠かせないからです。
調査結果も同じことを示しています。専任のプラットフォームエンジニアリングチームがKubernetesを運用し、別の中央セキュリティチームがポリシーを策定している企業では、66%がエンタープライズグレードの成熟度に達しており、他の体制の約2倍に上ります。この体制を採用している企業はわずか19%です。導入範囲の広さも重要です。Kubernetesを全社共通の標準プラットフォームとして運用している企業の53%が最上位の成熟度に達しているのに対し、単一チーム内で運用している企業では25%にとどまります。
これは相関関係であり、因果関係を証明するものではありません。規模が大きく、取り組みに積極的な組織ほど、単にこのような分業体制を取りやすいだけかもしれません。それでも、私の経験とは一致しています。負担を分かち合い、互いを信頼してそれぞれの役割を任せるチームこそが、エンタープライズグレードに到達するのです。
ガバナンスがAIの進展に追いついていない
私も、こうした状況の初期の姿を目にしました。ある企業では、事業に不可欠になりつつある機械学習ワークロードを急速に導入していました。その事業部門は、ほかの部門では従来型の体制を維持していた企業にとって、イノベーションの中心となっていました。このようなスピードでは、ガバナンスが追いつかなくなる可能性があります。
Kubernetesを本番環境で運用している企業の45%がモデルをデプロイまたは提供しており、そのうち86%が既存のWebアプリケーションファイアウォール（WAF）またはAPI保護の適用範囲を、そのトラフィックにも拡大しています。一方、AI固有の制御の導入は遅れています。エージェントツールとModel Context Protocol（MCP）のトラフィックを検査している企業は43%にとどまりますが、49%は12か月以内に実施する予定です。成熟した環境では、レート制限とトークンクォータの導入率が高いものの（80%対50%）、プロンプト検査とMCPトラフィックでは、その優位性は見られません。従来のワークロード向けに培ってきたガバナンスの慣行は役立ちますが、まだすべてをカバーするには至っていません。
調査結果から見える技術スタックへの示唆
この調査が示しているのは、特定の製品ではなく、対処すべきギャップと、それぞれに対応する役割です。オブザーバビリティの出発点はエッジでのテレメトリであり、これはプラットフォームとネットワークに関わる領域です。Web application and API protection（WAAP）は、階層間で技術の導入率の差が特に大きい分野の1つです。エンタープライズグレードの環境での導入率は69%であるのに対し、それ以外の環境では50%です。このポリシーはセキュリティチームが責任を持ち、すべてのクラスターが継承する必要があります。フェイルオーバーはクラスター間でテストする必要があり、そのためにはネットワークチームとプラットフォームチームの連携が欠かせません。
F5のアプローチは、これらのチームの実際の働き方に沿っています。Kubernetesのようなソフトウェアスタックではオープンソースが標準となるため、Kubernetesチームはオープンソースから始めます。出発点としては、NGINX Ingress ControllerやNGINX Gateway Fabricなどのプロジェクトを選べます。NGINX Ingress Controllerは、コミュニティのingress-nginxプロジェクトの終了後も、長期サポートを提供するIngressソリューションです。一方、NGINX Gateway Fabricは、Gateway APIに完全に準拠しています。
やがて、商用ソリューションならではの安心感を求めるようになると、 F5 NGINX Enterpriseへ移行し、強化されたイメージ、エッジでのアイデンティティ、アプリケーションごとのセキュリティポリシー、サポートSLA、あるいはフリート規模への対応を得られます。
ネットワークチームとセキュリティチームは、Kubernetesを既存の運用方法に適合させたいと考えています。そのため、F5 BIG-IP with Container Ingress Services (CIS)を利用すれば、プラットフォームチームがKubernetesで作業を続ける一方で、BIG-IPからトラフィックポリシーとセキュリティポリシーを一元的に適用し、クラスター間のフェイルオーバーを実行できます。
ネオクラウドやAIファクトリーの規模で実行されるAIワークロードに対して、F5 BIG-IP Next for Kubernetesは、Kubernetes上のAI向けに設計されたトラフィック管理とセキュリティにより、このアプローチを拡張します。各チームは使い慣れたツールを引き続き利用でき、共通の制御ポイントによってチーム間の連携を維持できます。
関連ホワイトペーパーでは、この取り組みを4つのフェーズに分け、それぞれに完了基準を設けています。タイムラインはあくまで例ですので、現在の成熟度に合ったフェーズから始め、状況に応じてスケジュールを調整してください。
- 標準化（0～3か月）：すべてのクラスターでサポート対象のIngressパターンを1つに統一し、エッジテレメトリを導入して、プラットフォームとセキュリティの役割を明確に定義します。
- 確立（3～9か月目）：Gateway APIの標準、セキュリティ継承のためのWAF、テレメトリの一元化。
- エンタープライズグレード（9～18か月目）：自動化されたアドミッション制御、トラフィックとポリシーの単一の制御ポイント、テスト済みのフェイルオーバー。
- 最適化（18か月目以降）：AIガードレール、コードとしてのポリシー、四半期ごとの成熟度の再評価。
フェーズ4では、先ほど触れた機械学習ワークロードのように、AIが再び登場します。チームは、F5 NGINX EnterpriseとCISを組み合わせたBIG-IPで既に構築した基盤を活用して、この段階に到達します。ネオクラウドやAIファクトリーの規模に対応するため、その基盤をBIG-IP Next for Kubernetesへと拡張できます。規模にかかわらず、テクノロジーが力を発揮できるかどうかは、それを支えるパートナーシップにかかっています。
まずは現在地を把握しましょう。エンタープライズレベルのKubernetes成熟度を達成するためのロードマップをダウンロードして、自己評価を行い、段階的な計画を立てましょう。調査の全容は、エンタープライズKubernetes戦略の現状2026をご覧ください。
こちらのブログもぜひご覧ください。「あらゆるチームに向けたKubernetesのクラウドネイティブなトラフィック制御とセキュリティ」
著者について
関連するブログ記事
F5 LabsのAIセキュリティモデルに関する知見：攻撃者がいなくてもAIエージェントがデータを漏えいさせるとき
無害なタスクを実行しようとするエージェントでも、その動作範囲の制限が適切に適用されていなければ、予期せぬデータ露出やビジネスリスクにつながる可能性があります。
マルチモデルAIのセキュリティ戦略：今すぐ実行すべき2つのステップ
エージェント型AIが急速に拡大する中、マルチモデルAIの可視性とサイバーセキュリティを向上させるために、企業が今すぐ実行できる主な対策をご紹介します。
セキュリティリーダーシップを再構築する3つの力：分散AI推論、脅威の進化、ハイブリッドマルチクラウド
セキュリティ環境を急速に変化させている最新のAIトレンドをご覧ください。
SecOpsはAIをどう捉えているのか？パート2：データ保護
F5は、AIに対する考えについてRedditに投稿されたセキュリティ専門家の意見を包括的に分析しました。
IL5/6だけでは守れない：プロンプトインジェクションが読み取り専用LLMを脅かす
LLMが米国国防総省のIL5/IL6環境に統合される中、F5のソリューションがデータを保護し、インジェクション攻撃を防止して、ゼロトラストモデルを強化する仕組みをご紹介します。