KubeCon NA 2026開幕、AI推論とエージェント運用の新トラックに注目
2026年11月10日 13:48
米ユタ州ソルトレークシティで現地時間2026年11月9日、KubeCon + CloudNativeCon North America 2026が開幕した。会期は12日までで、会場はSalt Palace Convention Centerだ。9日に併催イベントが開かれ、10日からメインカンファレンスが始まる。
今年は「AI Inference + Agentic」トラックが新設された。主催するCloud Native Computing Foundation（CNCF）は、AI推論、エージェントの実行基盤、GPUスケジューリング、モデル配信、可観測性を主要なテーマに挙げている。AIを継続的に運用するための技術と実践が議論される。
■併催イベントから広がるAI基盤の議論
11月9日の併催プログラムには「Cloud Native AI + Inference Day」と「Agentics Day: MCP + Agents」が組み込まれた。推論基盤に加え、AIモデルを外部のツールやデータにつなぐModel Context Protocol（MCP）と、エージェントの構築・運用を集中的に扱う構成だ。
同日にはNVIDIA主催の「DSX OS AI Inference and Contributor Workshop」も別会場で予定された。推論の導入、負荷試験、スケーリング、運用の技術セッションと、オープンソース開発への貢献を体験するワークショップを組み合わせたイベントで、参加には別途登録が必要とされた。
AI基盤を支える技術の範囲は広い。モデルを実行するサーバーだけでなく、リクエストの振り分け、共有GPUの利用調整、処理経路の観測、アクセス権の管理までを組み合わせてサービスを運用する。各技術の接続部分は、プラットフォームを構築するチームにとって重要な検討対象になる。
2026年7月28〜30日には、横浜でもKubeCon + CloudNativeCon Japanが開催された。北米大会は、こうした各地のコミュニティー活動を背景に、AIとクラウドネイティブ基盤の運用経験を持ち寄る場となる。
■エージェントのIDと操作履歴をどう結び付けるか
AIエージェントの運用では、外部APIの呼び出しやデータベースへの書き込みを、実行主体や権限と対応付けることが重要になる。同じプログラムから起動したエージェントでも、会話の文脈、検索結果、ツールの呼び出し履歴によって、その後の操作は変わり得る。
この基盤の一つが、ワークロードの識別情報を定めるSPIFFEと、その実装であるSPIREだ。SPIREは、登録された条件と実行環境から取得した属性を照合し、ワークロードにSPIFFE IDと検証可能な資格情報を提供する。Kubernetes向けには、名前空間、サービスアカウント、Podのラベル、PodのUIDなどを識別条件に使える。
IDをどの粒度で割り当てるかは、運用設計に関わる。サービス全体を示すIDに加え、個別の実行主体を識別するIDや、アプリケーションが記録するセッション情報を対応付ければ、誰の権限でどの処理が動いたのかを追跡しやすくなる。エージェントの状態やツール呼び出しを記録するログ、分散トレーシングも、そのための情報となる。
Solo.ioのChristian Posta氏は2025年6月の解説で、エージェントの各インスタンスに固有のIDを与える設計を示した。SPIFFEとSPIREを利用できると説明する一方、動的に生成される細かなIDに対して、認可ポリシーをどう記述するかを課題に挙げている。識別と認可を一体として考える必要性が分かる。
アクセス権の与え方にも課題がある。Teleportが2026年に公表した調査では、回答者の70％が、同じ役割の人間よりAIシステムに広いアクセス権を与えていると答えた。調査は2025年12月、インフラのセキュリティーに責任を持つ205人への電話インタビューで実施された。エージェントを識別する仕組みとともに、実行する仕事に応じた権限の設定が問われる。
■llm-d 1.0が進める分散推論の運用
会議直前の10月20日には、分散LLM推論フレームワーク「llm-d」のv1.0が公開された。プロジェクトは2026年3月12日にCNCF Sandboxへ採択されている。2025年5月にRed Hat、Google Cloud、IBM Research、CoreWeave、NVIDIAの協力で始まった取り組みだ。
llm-dは、複数のモデルサーバーにまたがる推論リクエストの振り分けや、KVキャッシュを活用した処理の効率化を担う。KVキャッシュは、文章生成で再利用する計算結果を保持する仕組みで、共通する入力を処理済みのサーバーへリクエストを送ることで、計算の重複を減らせる。
開発チームによると、v1.0では設定APIを安定したv1へ移行した。複数の利用者で推論基盤を共有する際の優先度・公平性を考慮したフロー制御や、更新時の処理継続を支える機能も強化した。性能を引き出すだけでなく、負荷の変動や保守作業を含めてサービスを維持するためのリリースと位置付けている。
プロジェクト公開のベンチマークには、16基のH100 GPUを使い、各2基を割り当てた8つのvLLM PodでQwen3-32Bを動かした比較がある。共通の長い入力を繰り返す条件で、llm-dによるルーティングと通常のKubernetes Serviceを比較し、最大持続出力は毎秒6,986トークンから14,892トークンへ増えたと報告している。入力の共有度や負荷をそろえた、特定の構成での測定結果だ。
モデル配信基盤のKServeとの連携も進む。KServeは従来型の予測モデルと生成AIモデルの配信を扱い、LLM向けの「LLMInferenceService」を通じてllm-dの分散推論機能を利用できる。モデルの導入・管理を担う仕組みと、推論処理を最適化する仕組みを組み合わせる構成である。
■推論に応じたルーティングと実装の選択
Gateway API Inference Extensionは、Kubernetes上の生成AIモデルに向けたリクエストの振り分けを拡張するプロジェクトだ。v1.5.0は2026年4月19日に公開され、その後も更新が続いている。11月9日時点では、9月17日公開のv1.6.2までリリースされている。
中心となるリソース「InferencePool」は、推論を処理するPod群と、その振り分けに使う拡張機能を表す。GatewayとHTTPRouteで対象のプールを選び、「Endpoint Picker（EPP）」がプール内の送信先を決める構成だ。ゲートウェイはEPPの選択結果に従ってリクエストを転送する。
この構成により、推論サーバーの負荷やKVキャッシュの利用状況などを考慮したルーティングを実装できる。利用する情報や選択方針は拡張側の実装・設定に依存するため、モデル、入力の特徴、求める応答時間に合わせて選ぶことが重要になる。
プロジェクトは実装間の互換性を確認する適合性テストも整備している。公式資料にはIstio、Agentgateway、Higress、NGINX Gateway Fabricなどの対応実装が掲載されている。導入時には、採用するバージョンと機能に対応する適合性レポートを確認することが、製品や実装を比較する手掛かりとなる。
■GPU配置はキュー管理とハードウェア割り当てを組み合わせる
GPUの利用効率を高めるには、どの仕事に実行を許可するかと、その仕事をどのノードやデバイスに配置するかを組み合わせて考える必要がある。Kueue、Volcano、KAI Schedulerは、この領域で異なる役割や機能を提供している。
Kueueは主に、クォータや優先度、公平性に基づいてジョブの実行を受け入れるかを管理する。Podをノードへ配置する処理は、Kubernetesのスケジューラなどが担う。Volcanoはバッチ処理向けのスケジューリング基盤で、分散学習などに必要なPod群をまとめて実行可能にするギャングスケジューリングや、キュー間のリソース配分に対応する。
NVIDIAが公開したKAI SchedulerもCNCF Sandboxプロジェクトとなっている。AIワークロード向けに、ギャングスケジューリング、GPU共有、トポロジーを考慮した配置、公平なリソース配分などを提供する。学習と推論の両方を扱う基盤として、必要な実行単位や共有方法に応じた比較ができる。
Kubernetes本体でも「Workload-Aware Scheduling（WAS）」の整備が進む。複数のPodで構成される仕事をまとまりとして扱い、ギャングスケジューリングや配置条件を調整するための取り組みだ。分散学習や、処理段階を分離した推論など、複数Podの協調が必要な用途に関わる。
ハードウェア側では、動的リソース割り当て（Dynamic Resource Allocation、DRA）の基本機能が、2025年8月公開のKubernetes 1.34で安定版となった。ドライバーが公開するデバイス情報と、アプリケーションが要求する条件を使って、GPUなどの専用機器を割り当てる仕組みだ。利用できる属性や配置条件は、ドライバーと対応機能によって決まる。
Red Hat build of Kueue 1.4では、DRAを通じたGPU要求をクォータ管理に組み込む機能がTechnology Previewとして提供されている。従来のCPUやメモリーの要求と同様に、DRA経由のデバイス要求もチームの割り当て枠へ算入する。ジョブの受け入れ管理とデバイスの割り当てを接続する取り組みである。
■基調講演と運用事例で注目する点
11月10日朝の開会プログラムには、CNCFエグゼクティブディレクターのJonathan Bryce氏らが登壇する。AIエージェントのIDを扱うAbdel Sghiouar氏の基調講演「The Identity Crisis: Who is the AI Agent in Your Cluster?」も予定されている。エージェントを実行する基盤と、その権限・実行環境をどう設計するかが議論される。
会期中にはllm-dの本番運用を扱うセッションもあり、Mistralでの運用構成を紹介する発表が予定されている。DRAについても、ドライバーの実装や利用例を掘り下げるセッションがある。抽象的な機能比較に加え、実際の構成と運用経験を確認できる機会となる。
公式発表に掲載されたDiamondスポンサーは、AWS、Google Cloud、HAProxy Technologies、Microsoft Azure、Nutanix、Oracle、Red Hat、ScaleOps、Solo.ioの9社だ。このうちGoogle CloudとRed Hatはllm-dの創設時から参加しており、商用基盤とオープンソース開発の双方に関わっている。
Project Lightning Talksは11月9日のプログラムに組み込まれている。メインカンファレンスの基調講演と分科会の録画は、会議終了後にCNCFのYouTubeチャンネルで公開される予定だ。現地参加できないチームも、公開プログラムと録画を通じて、推論、ID管理、GPU配置を自社の運用要件に照らして検討できる。