Red Hatのハイブリッドプラットフォーム部門副社長兼ゼネラルマネージャーのマイク・バレットは、異なる事業部門が異なる大規模言語モデルを使用している例を挙げ、「企業顧客が求めているのは、特定の環境向けのツールではなく、企業レベルの『水平プラットフォーム』だ」と説明する。これに対処するため、Red HatはKubernetesを基盤とし、すべての環境を横断してAIワークロードを一元管理するコントロール層、すなわち「AIコントロールプレーン」の構築に注力している。
Red Hatのエンジニアリングディレクター、ロバート・ショーティは、オープンソース推論フレームワーク「llm-d」を挙げ、「ユーザーは最先端の性能を持つシステムを構築したいだけでなく、その後の運用段階の複雑さも解決したい」と述べる。これは、AIシステムの不安定さが生じるのは訓練段階ではなく、実サービス運用段階であることを示している。
ナシャワティは、「Red Hatは単なる商用プラットフォームの提供者にとどまらず、CNCFのエコシステムの中で最も活発に貢献している企業の一つだ」と評価する。この上流の取り組みは、単なるミラーリングや管理だけではなく、各ベンダーのKubernetes実装の差異を防ぎ、一貫性を維持するための重要な仕組みだ。Red Hatはまた、NVIDIAと協力して「Red Hat AIファクトリー」を推進し、OpenShiftとNVIDIAの高速計算を融合した拡張可能なエンタープライズAIインフラの構築に取り組んでいる。
AI拡散を防ぐのはモデルではなくインフラストラクチャ……Kubernetesの「統一運用」の役割がますます顕著になっている
AI拡散のボトルネックはモデルではなく、「インフラストラクチャ」—この診断はますます拡大している。
最近開催された「KubeCon+CloudNativeConヨーロッパ」会議で、人工知能（AI）競争の核心はもはやモデル性能だけではないことが明らかになった。分析によると、企業がAIを実際にサービスに展開する過程で最大の障壁は、クラウド、エッジ、ローカルに分散されたシステムを単一の全体として運用できない構造的制約にある。
新たな研究は、ほとんどのAIプロジェクトが実運用段階に到達できておらず、その失敗原因もモデル自体よりも統合と運用の実行に集中していることを示している。TheCube Researchのチーフアナリスト、ポール・ナシャワティは述べる。「AIは企業のインフラの根本的な欠陥を明らかにしている」「クラウド、エッジ、ローカル展開の全面的な断片化が、運用型AIの最大の障害となっている」。
「主権」問題がAIインフラをより複雑に
この断片化は最近、「主権」という名で呼ばれるようになった。これは、データの主権、地域の規制、企業内部のポリシーが絡み合い、データやワークロードを一箇所に集中させることを難しくしているためだ。その結果、AIシステムは単一のスタックではなく、複数の環境にまたがる分散運用の構造へと変化を余儀なくされている。
Red Hatのハイブリッドプラットフォーム部門副社長兼ゼネラルマネージャーのマイク・バレットは、異なる事業部門が異なる大規模言語モデルを使用している例を挙げ、「企業顧客が求めているのは、特定の環境向けのツールではなく、企業レベルの『水平プラットフォーム』だ」と説明する。これに対処するため、Red HatはKubernetesを基盤とし、すべての環境を横断してAIワークロードを一元管理するコントロール層、すなわち「AIコントロールプレーン」の構築に注力している。
Kubernetesはオーケストレーションを超え、「運用の一貫性」ツールへと進化
もともとKubernetesはAI推論のために設計された技術ではない。その役割はコンテナの展開と管理に近いものだった。しかし、AI推論が実サービス環境に移行するにつれ、地域間の一貫性不足、遅延の変動、リソースの争奪、ポリシーのドリフトなど、「日常運用」の問題が顕在化し始めている。
Red Hatのエンジニアリングディレクター、ロバート・ショーティは、オープンソース推論フレームワーク「llm-d」を挙げ、「ユーザーは最先端の性能を持つシステムを構築したいだけでなく、その後の運用段階の複雑さも解決したい」と述べる。これは、AIシステムの不安定さが生じるのは訓練段階ではなく、実サービス運用段階であることを示している。
Cloud Native Computing Foundation（CNCF）管理委員会副議長のヤン・メレンも、類似の問題意識を示す。彼は、「クラウドネイティブは世界的なオープンソース協力へと進化しているが、AIは『グローバルな一貫性』に基づくシステムと、地域規制や分散環境との現実的な衝突を引き起こしている」と分析している。
TheCube Researchのチーフアナリスト、ロブ・ストレイチャイは、「代理型AIの本質はモデルの問題ではなく、プラットフォームアーキテクチャの問題だ」と評価し、「今後の競争力は、より良いインフラを構築することにより大きく左右されるだろう」と述べている。
プラットフォームエンジニアリングがAI運用の現実的解決策に
問題は、Kubernetesがすべてのチームにとってあまりにも複雑であり、直接扱うのが難しい点にある。Red HatのAI部門最高技術責任者（CTO）であるブライアン・スティーブンスは、現在、多くのデータサイエンティストがインフラの実行も担っていると述べる。こうしたギャップを埋めるのがプラットフォームエンジニアリングだ。
ストレイチャイは、ツールの断片化、人的能力の差、運用の複雑さが実質的なボトルネックとなる中、業界はプラットフォームエンジニアリングとKubernetesを中心とした統一制御構造へと移行していると解説する。この流れの中で、Red HatのOpenShift AIは、学習、展開、サービス、推論を横断的に抽象化し、再現性のある運用を実現する役割を担っている。
仮想マシンもKubernetesに進入
企業インフラは一度にすべてを近代化できるわけではない。請求システムやデータベースなどのコアなレガシー資産は、リスク管理の観点から従来の環境に残されることが多い。これにより、仮想マシン（VM）とコンテナは長期にわたり二元的に運用されている。
調査によると、IT意思決定者の84％が仮想マシンとコンテナの環境を個別に管理することに困難を感じている。Red Hatのダニエル・メッセルは、「仮想化とコンテナは孤立した状態にすべきではなく、同じプラットフォーム上にあるべきだ」と述べる。CNCFで成熟段階に入ったKubeVirtは、Kubernetes内で仮想マシンとコンテナを同時に動かす拡張プロジェクトだ。
これは、レガシーシステムを排除するのではなく、既存システムも同一のコントロール層に取り込み、運用インターフェースを統合する戦略と解釈されている。
また、「利便性」は必ずしもコントロール権を意味しないとの指摘もある。
主権型AIは一見代替案のように見えるが、実際にはより多くの制約を伴うとの見解もある。各国の規制はデータの移動を制限し、企業のポリシーは集中化を妨げる。その結果、企業は準備ができていなくても、ワークロードをクラウド、ローカル、エッジに分散させざるを得なくなる。
EnterpriseDBのガブリエル・バルトリーニは、「データベースの移植性を保証しなければ、真の主権は得られない」と強調し、「ホスティングサービスの『便利さ』はコントロール権を意味しない」と指摘する。ヤン・メレンも、「主権の議論では、『コードの主権』と『展開の主権』を区別すべきだ」と述べている。コードはグローバルなオープンソース資産として存在できるが、実際の展開は法律やポリシーの影響を受ける。
この点で、Kubernetesの役割はより明確になる。グローバルに共有されるコードを、異なる地域制限に適応した運用環境に連結する仕組みだ。
勝敗は最終的にエコシステム次第
単一の企業だけではAIインフラを担いきれない。Kubernetesコントロールプレーンを有効に機能させるには、複数のシステムを置き換えるのではなく、連携させる必要がある。その実現には、標準、API、上流のオープンソースプロジェクトからなる「エコシステム」が不可欠だ。
ナシャワティは、「Red Hatは単なる商用プラットフォームの提供者にとどまらず、CNCFのエコシステムの中で最も活発に貢献している企業の一つだ」と評価する。この上流の取り組みは、単なるミラーリングや管理だけではなく、各ベンダーのKubernetes実装の差異を防ぎ、一貫性を維持するための重要な仕組みだ。Red Hatはまた、NVIDIAと協力して「Red Hat AIファクトリー」を推進し、OpenShiftとNVIDIAの高速計算を融合した拡張可能なエンタープライズAIインフラの構築に取り組んでいる。
ナシャワティは、「システムの断片化によりAIの失敗率が二桁に達している企業が75％に上る現状を踏まえると、ボトルネックはインフラに移っている」と指摘し、「問題は機能不足ではなく、システム間の連携の構造的な難しさにある」と述べている。
KubernetesはAI時代の生産層へと台頭
AIは特定のポイントを破壊するのではなく、
TP AI注意事項 TokenPost.aiの基礎言語モデルを用いて記事の要約を行った。本内容の主要部分は省略されている可能性があり、事実と異なる場合もある。