Cloud

概要 Solo.ioは2026年3月25日、アムステルダムで開催されたKubeCon + CloudNativeCon Europe 2026において、Kubernetes上でAIエージェントを実行するオープンソースフレームワーク「kagent」のCNCF（Cloud Native Computing Foundation）サンドボックスプロジェクトへの寄贈を正式に発表した。あわせて、AnthropicのModel Context Protocol（MCP）に対応した新ツール「MCP Gateway」も披露された。kagentはリリースからわずか1週間でCNCFのランドスケープ登録に必要な300 GitHubスターを達成し、最速クラスで成長しているCNCFサンドボックスプロジェクトの一つとなっている。 kagentとMCP Gatewayの技術詳細 kagentは、AIエージェント・ツール・モデル設定をすべてKubernetes CRD（カスタムリソース定義）として管理するKubernetesネイティブなAIエージェントフレームワークである。Solo.ioがOSSとして公開してから100日間で100名以上のコントリビューター（85%以上が外部）と1,000以上のGitHubスターを獲得した。 MCP GatewayはAI開発で広く採用が進むMCPプロトコルに対応した新ツールで、複数のMCPツールサーバーを単一の安全なエンドポイントに集約（フェデレーション）する機能を持つ。Solo.io共同創業者兼CEOのIdit Levine氏はKubeCon基調講演でその意義を「すべてのツールサーバーを単一エンドポイントに統合できる」と説明した。MCP Gatewayはkgatewayとのタイトな統合が特徴で、上席OSS担当ディレクターのLin Sun氏は「kgatewayをMCP Gatewayプロキシのコントロールプレーンとして捉えることができる」と述べている。 Solo.ioのアジェンティックインフラ戦略 Solo.ioはkagentのCNCF寄贈と並行して、AIエージェントインフラ全体をカバーするOSSエコシステムを構築している。その主要な4つの柱は以下のとおりである。 kagent — KubernetesネイティブなAIエージェント構築・実行のためのCNCFサンドボックスプロジェクト agentgateway — MCPおよびA2A（Agent-to-Agent）プロトコルを完全サポートするLinux Foundation傘下のAIネイティブデータプレーン agentregistry — AIエージェント・MCPツール・エージェントスキルの一元的なCNCFレジストリ。KubeCon Europe 2026でCNCFへの寄贈が発表された agentevals — OpenTelemetryを活用してAIエージェントの動作を継続的に評価・スコアリングする新OSSプロジェクト CEO Levine氏は「評価（evaluation）はアジェンティックインフラにおける最大の未解決問題だ」と述べ、agentevalsがプロダクション環境での信頼性確保を担う重要な位置づけにあることを強調した。 今後の展望 kagentはCNCFサンドボックスでインキュベーション申請が進行中であり、最新のCNCFテクノロジーレーダーのアジェンティックAI部門でも取り上げられている。agentregistryはKubernetes、AWS AgentCore、Google Vertex AIとの統合や、未統制のエージェントを検出するランタイムディスカバリ機能を備え、エンタープライズ規模でのAIガバナンスの基盤となることが期待される。KubeCon Europe 2026では「Agentics Day: MCP + Agents Hosted by CNCF」と題したハーフデイイベントも開催されるなど、KubernetesとAIエージェントの融合は急速に進んでいる。

概要 CoreWeave（Nasdaq: CRWV）は2026年1月、NVIDIA Rubinテクノロジーをクラウドプラットフォームへ統合すると発表した。同社は2026年下半期にNVIDIA Rubinプラットフォームを最初に展開するクラウドプロバイダーの一つとなる予定で、エージェント型AI・大規模推論・大規模インファレンスワークロードの構築・デプロイを支援する。CoreWeaveのCEO Michael Intrator氏は「エンタープライズ顧客は本物の選択肢と、複雑なワークロードを本番スケールで確実に実行できる能力を求めてCoreWeaveを選ぶ」とコメントしており、NVIDIA Rubinプラットフォームはその戦略をさらに強化するものと位置付けている。NVIDIA CEOのJensen Huang氏も「CoreWeaveのスピード、スケール、そして独創性はこの新時代のコンピューティングにおいて不可欠なパートナーだ」と述べている。 NVIDIA Rubinプラットフォームの技術仕様 NVIDIA Rubinプラットフォームは6種類のチップを極限まで協調設計（コデザイン）することで、AIシステムの構築・デプロイ・セキュリティ確保の新たな基準を打ち立てる。構成要素は以下の通りだ。 NVIDIA Vera CPU：88個のカスタムOlympusコア（Armv9.2互換）を搭載 NVIDIA Rubin GPU：第3世代Transformer Engineを搭載し、NVFP4で50ペタフロップスの計算性能を発揮 NVIDIA NVLink 6 Switch：GPU1基あたり3.6TB/sの帯域幅を実現するGPU間通信スイッチ NVIDIA ConnectX-9 SuperNIC：高速ネットワークインターフェース NVIDIA BlueField-4 DPU：AIネイティブなストレージ処理 NVIDIA Spectrum-6 Ethernet Switch：大規模クラスタ向けイーサネットスイッチング 旗艦ラック構成「Vera Rubin NVL72」にはRubin GPUを72基、Vera CPUを36基搭載し、合計260TB/sのトータル帯域幅を誇る。前世代のBlackwellプラットフォームと比較して、推論トークンコストを最大10分の1に削減し、混合専門家（MoE）モデルの学習に必要なGPU数を4分の1に抑えることができるとされている。 CoreWeaveの独自技術と展開戦略 CoreWeaveは単にNVIDIA Rubinを採用するだけでなく、自社開発の技術でその運用基盤を強化している。同社が構築したRack Lifecycle Controllerは、NVIDIA Vera Rubin NVL72ラック全体を単一のプログラマブルエンティティとして扱うKubernetesネイティブのオーケストレーターだ。電力供給、液体冷却、ネットワーク統合の緊密な要件を調整し、顧客のワークロードを投入する前にハードウェアの本番稼働準備を確実にする。 また、Rubinベースのシステムは業界初のAIワークロード向けオペレーティング標準であるCoreWeave Mission Controlと連携して展開される。これはトレーニング・インファレンス・エージェント型AIワークロードをセキュリティ、オペレーション、可観測性を統合して管理するものだ。CoreWeaveは既にGB200 NVL72やGrace Blackwell Ultra NVL72の一般提供を最初に実現した実績を持ち、SemiAnalysisのClusterMAX™ プラチナ評価を2度獲得している。 業界全体での展開動向と今後の展望 NVIDIA Rubinプラットフォームへの対応は、CoreWeaveだけにとどまらない。AWS、Google Cloud、Microsoft、OCIといった主要クラウドプロバイダーに加え、NVIDIA Cloud Partnersであるλambda、Nebius、Nscaleも2026年下半期にVera Rubinベースのインスタンスをいつしかのパートナーとともに提供予定だ。AI研究機関側でも、Anthropic、Meta、OpenAI、Mistral AI、xAIなど多数の企業がRubinプラットフォームへの期待を表明している。 CoreWeaveはNasdaq上場（2025年3月）後も、NVIDIAの最新プラットフォームへの早期アクセスを競争上の差別化要因として活用し続けている。薬物探索・ゲノム研究・気候シミュレーション・核融合エネルギーモデリングといった高負荷科学計算からエンタープライズAIまで幅広いユースケースをカバーするNVIDIA Rubinの採用を通じて、同社は専業AIクラウドとしての地位をさらに強固にしようとしている。

概要 Kubernetes v1.36のスナップショット（Sneak Peek）記事が2026年3月30日に公式ブログで公開された。正式リリースは2026年4月22日を予定しており、セキュリティ強化を軸に複数の重要な変更が加えられる。主な変更点は、長年の脆弱性対応としてspec.externalIPsフィールドの非推奨化、セキュリティリスクのあったgitRepoボリュームドライバーの完全削除、SELinuxラベリング改善のGA（一般提供）対応、そしてHPAのScale-to-Zeroのデフォルト有効化などだ。 セキュリティ関連の変更 spec.externalIPsの非推奨化は、CVE-2020-8554への対応として実施される。この脆弱性はServiceのexternalIPsフィールドを悪用することで中間者攻撃が可能になるもので、v1.36で非推奨となりv1.43での削除が計画されている。代替手段としてはLoadBalancer Service、NodePort Service、またはGateway APIへの移行が推奨されている。 gitRepoボリュームドライバーの削除も同リリースで実施される。このドライバーはv1.11から非推奨だったが、ノード上でroot権限によるコード実行を可能にするセキュリティ上の欠陥があったため、v1.36でついに完全削除される。代替手段としてはinitコンテナや外部のgit-syncツールの利用が推奨されている。 また、Ingress NGINXプロジェクトのリタイアが2026年3月24日に発表された。セキュリティバグ修正と新リリースが停止され、既存のデプロイメントは引き続き動作するものの、Gateway APIへの移行が強く推奨されている。 kube-proxyのIPVSモードもv1.35で非推奨となっており、v1.36で削除される。移行先としてはnftablesバックエンドのiptables、またはCiliumなどのeBPFベースのソリューションが選択肢となる。 新機能・改善 SELinuxボリュームラベリングの改善がGA（一般提供）に昇格する。従来は再帰的なファイルリラベリングが行われておりPodの起動遅延を招いていたが、mount -o context=XYZオプションを用いた新方式によりこの問題が解消される。v1.28のReadWriteOncePod向けベータ実装から始まり、v1.32のメトリクス追加を経て、v1.36では全ボリューム対応・デフォルト有効化としてGAに到達する。 HPA（Horizontal Pod Autoscaler）のScale-to-Zero機能がデフォルト有効となる。v1.16からアルファとして提供されていたHPAScaleToZeroフィーチャーゲートが有効化され、トラフィックがゼロになった際にPodを完全にスケールダウンし、需要が復帰した際に自動でスケールアップできるようになる。ステージング環境やバッチ処理、コスト最適化の観点で特に有用な機能だ。 イメージプルへのエフェメラルサービスアカウントトークンの採用（KEP-2535）も注目の変更点だ。これまでの長期有効なシークレットに代わり、Podのアイデンティティにスコープされた短命かつ自動ローテーションされるトークンを使用するようになる。v1.33でアルファ、v1.34でベータを経てv1.36で本番対応となる予定だ。 新しいアルファ機能として、HPAのPod選択の精緻化も導入される。メトリクス収集において、対象ワークロードが直接管理するPodのみを収集対象とすることで、孤立したPodによるスケーリングエラーを防止できるようになる。 今後の展望 containerd 1.6.x系のサポートについては、v1.36が古いバージョンをサポートする最後のリリースとなるため、該当ユーザーはcontainerd 2.x系へのアップグレードを検討する必要がある。リリーススケジュールは機能強化フリーズが2月11日に完了し、コード凍結が3月18日、ドキュメント凍結が4月8日、そして正式リリースが4月22日となっている。セキュリティを重視した今回の変更群は、長年先送りにされてきた脆弱性対応を一気に前進させるものであり、クラスター管理者には早期の影響評価と移行計画の策定が求められる。

概要 AWSは、Amazon Route 53 Global Resolverの一般提供（GA）を開始した。本サービスは2025年のre:Inventで11リージョンでのプレビューとして発表されていたもので、今回30のAWSリージョンに拡大して正式リリースとなった。Route 53 Global Resolverは、インターネット経由でアクセス可能なマネージドエニーキャストDNSリゾルバサービスであり、オンプレミスのデータセンター、ブランチオフィス、リモートクライアントなど、あらゆる場所からのDNSトラフィックのルーティングとセキュリティを簡素化する。パブリックインターネットドメインとRoute 53プライベートホストゾーンの両方の名前解決に対応しており、ハイブリッドクラウド環境におけるスプリットDNS構成を大幅に簡素化できる。 暗号化DNSとセキュリティ機能 Route 53 Global Resolverの大きな特徴は、DNS over HTTPS（DoH）およびDNS over TLS（DoT）による暗号化DNS通信のサポートである。これにより、DNSクエリが平文で送信されることを防ぎ、通信の盗聴やDNSスプーフィングのリスクを低減する。認証方式としては、DoH/DoT向けのトークンベース認証（有効期限や失効の設定が可能）と、Do53/DoT/DoH向けのIP/CIDRベースのACLによるアクセス制御の2つが用意されている。 セキュリティ面では、悪意のあるドメインへのDNSクエリをブロックするDNSフィルタリング機能を内蔵しており、DNSトンネリングやドメイン生成アルゴリズム（DGA）、辞書DGAに関連するドメインへのアクセスもブロックできる。さらに、CloudWatch、S3、Data Firehoseへの集中クエリログ出力に対応し、コンプライアンス要件への対応やセキュリティ監視を容易にする。 運用上の利点と今後の展望 Route 53 Global Resolverの導入により、企業はカスタムDNSフォワーダの構築・運用が不要になり、運用負荷を大幅に削減できる。複数リージョンへのデプロイにより、レイテンシの最適化とフェイルオーバーも実現される。VPNや企業ネットワークとの互換性も備えており、既存のネットワーク構成への統合が容易である。新規利用者には30日間の無料トライアルが提供されており、導入前の検証が可能となっている。IPv4およびIPv6の両方のDNSクエリトラフィックに対応している点も、モダンなネットワーク環境への適応を示している。

概要 Datadogは2026年3月20日、Terraformプロバイダーのメジャーバージョンアップとなるv4.0.0をリリースした。今回のリリースでは、モニターのアクセス制御における予測可能性の向上、AWS統合リソースの一本化、認証情報のセキュリティ強化、そしてTerraformプロトコルv6への移行という4つの主要な改善が盛り込まれている。Terraform CLI 1.1.5以降が必須となる破壊的変更を含むメジャーアップデートだが、段階的な移行パスが用意されており、v3を利用中のチームはレガシーリソースを引き続き利用しながら準備が整った段階でアップグレードできる。 モニターアクセス制御の改善 v4.0.0では、モニターのrestricted_rolesフィールドがデフォルトで「スティッキー」な動作に変更された。これにより、Terraform構成からフィールドを省略しても既存のロール制限が意図せず削除されることがなくなり、制限を完全に解除するには明示的に空配列[]を設定する必要がある。従来のv3では構成の省略がアクセス制限のリセットを引き起こす可能性があり、予期しない権限変更のリスクがあった。なお、非推奨だったlockedフィールドは完全に削除され、今後はrestriction_policyの利用が推奨される。ただし、restricted_rolesとrestriction_policyの併用は機能的な競合を引き起こすため注意が必要だ。 AWS統合リソースの統合 これまで4つの個別リソースに分散していたAWS統合の管理が、新しいdatadog_integration_aws_accountリソースに一本化された。この統合リソースでは、従来の機能に加えてログのタグフィルタリング、X-Rayトレーシング、EC2オートミュート制御、AWSパーティションサポートといった新機能が利用可能になっている。v4にアップグレードするチームは統合リソースへの移行が必要だが、移行ドキュメントがTerraform Registryで提供されている。なお、基盤となるv1 APIは引き続き稼働しており、後方互換性も維持されている。 セキュリティ強化と技術基盤の刷新 認証情報のセキュリティ面では、datadog_application_keyデータソースの削除と既存アプリケーションキーのインポート機能の廃止が行われた。これにより認証情報の露出経路が削減され、ワンタイムリード方式のアプリケーションキーとの互換性が確保された。Terraformで作成・管理している既存のキーはアップグレード後も引き続き機能する。技術基盤としては、Terraform Plugin SDK v2からプラグインフレームワークへの移行が実施され、Terraformプロトコルv6が採用された。これにより、将来的にネストされた属性のサポートなど、スキーマの改善が可能になる見通しだ。

概要 KubernetesのSIG Networkは2026年3月20日、Ingressリソースから Gateway APIへの移行を支援するツール「Ingress2Gateway」のバージョン1.0を正式リリースした。Ingress-NGINXが2026年3月に廃止されることを受け、既存のIngress設定をGateway APIリソースへ自動変換するための公式ツールとして位置づけられている。以前のバージョンではわずか3つのアノテーションしかサポートしていなかったが、1.0では30以上のIngress-NGINXアノテーションに対応し、CORS設定、バックエンドTLS、正規表現パスマッチング、パスリライト、プロキシボディサイズ、タイムアウト設定、カスタムリクエストヘッダーなど幅広い構成の変換が可能になった。 Gateway APIへの移行が必要な背景 Gateway APIはIngress APIの後継として設計されたKubernetesのネットワーキングインターフェースであり、すでにGA（一般提供）に到達している。従来のIngressがアノテーションベースの拡張に依存していたのに対し、Gateway APIはモジュラーで拡張性の高いAPI設計、KubernetesネイティブのRBACサポート、より明確な抽象化を提供する。Ingress-NGINXの廃止により、Kubernetes上でトラフィック管理を行うすべての組織はGateway APIへの移行を迫られている状況だ。 技術的な特徴と移行プロセス Ingress2Gatewayはコマンドラインツールとして提供され、Go install、Homebrew、GitHubリリースからインストールできる。YAMLマニフェストファイルからの変換のほか、クラスターに接続して単一ネームスペースまたは全ネームスペースのIngressリソースを一括変換する機能を備える。さらに、出力先のGateway API実装としてagentgateway、envoy-gateway、kgatewayなどの実装固有のエミッターを指定可能だ。 1.0リリースの大きな特徴として、コントローラーレベルの統合テストが整備された点が挙げられる。このテストでは実際のIngress-NGINXコントローラーと複数のGateway APIコントローラーを起動し、変換前後のルーティングやリダイレクト、リライトといった実行時の振る舞いが同等であることを検証する。YAML構造の比較ではなくランタイムの動作を検証することで、Ingress-NGINXの予期しないデフォルト値やエッジケースを本番デプロイ前に検出できる仕組みとなっている。 移行における留意点と今後の展望 Ingress2Gatewayはワンショットの置換ツールではなく、反復的な移行プロセスを前提として設計されている。変換時には自動変換できない設定について明確な警告と代替手段の提案が出力されるため、チームはこれを確認しながら段階的に移行を進めることが推奨される。この移行プロセスは既存のアーキテクチャ判断を見直す機会でもあるという設計思想が反映されている。Kubernetes 1.36が2026年4月22日にリリース予定であり、Gateway APIの本格採用がさらに加速する見通しだ。本ツールはGoogle所属のBeka Modebadze氏とMicrosoft所属のSteven Jin氏が中心となって開発された。

概要 AWSは、Kubernetes Load Balancer ControllerにおけるGateway APIサポートのGA（一般提供）を発表した。これにより、Application Load Balancer（ALB）とNetwork Load Balancer（NLB）をGateway API仕様で管理できるようになり、従来のアノテーションベースの設定から型安全なCustom Resource Definitions（CRD）ベースの設定へと移行が可能になった。Gateway APIはKubernetes Ingress APIの後継として位置づけられており、今回のGA対応はAWSにおけるKubernetesネットワーキングの標準化にとって重要なマイルストーンとなる。 技術的な詳細 今回のリリースでは、レイヤー4ルーティング（TCP、UDP、TLS、NLB経由）とレイヤー7ルーティング（HTTP、gRPC、ALB経由）の両方がサポートされる。新たに導入されたCRDとして、TargetGroupConfiguration、LoadBalancerConfiguration、ListenerRuleConfigurationの3つがあり、スキーマバリデーション付きの型安全な設定が可能になった。従来のアノテーション方式ではJSONを埋め込む形で設定していたため、スキーマバリデーションやIDEサポートがなく、実行時にエラーが発覚するリスクがあった。新しいアプローチでは、適用時に設定が検証されるため、こうした問題が解消される。 RBACとの整合性とクロスネームスペースルーティング Gateway APIはリソースをGatewayClass（インフラストラクチャテンプレート）、Gateway（リスナー、TLS、サブネット配置）、Routes（パスベースルーティング）の3つに分離しており、Kubernetesのロールベースアクセス制御（RBAC）の境界と自然に対応する設計となっている。これにより、プラットフォームチームが共有Gatewayをプロビジョニングし、各アプリケーションチームは自身のネームスペースからHTTPRouteを作成して参照するという運用が、クラスタ管理者権限なしで実現できる。GitOpsフレンドリーなYAML設定との親和性も高く、開発者体験の向上にも寄与する。 今後の展望 なお、AWSのVPC Latticeはすでにサービスメッシュのeast-west（サービス間）トラフィックにおいてGateway APIをサポートしており、今回のリリースでnorth-south（イングレス）トラフィックのカバレッジが完成した形となる。これにより、AWS上のKubernetesネットワーキングはGateway APIを共通インターフェースとして統一的に管理できる基盤が整ったと言える。

概要 KubeCon Europe 2026にて、Kubernetes上でLLM推論を最適化する分散推論フレームワーク「llm-d」がCNCF Sandboxプロジェクトとして採択された。llm-dは2025年5月にRed Hat、Google Cloud、IBM Research、CoreWeave、NVIDIAによって立ち上げられたプロジェクトで、AMD、Cisco、Hugging Face、Intel、Lambda、Mistral AI、UCバークレー、シカゴ大学など幅広い企業・研究機関が支援している。KServeのような高レベルのコントロールプレーンとvLLMのような低レベルの推論エンジンの間を橋渡しし、ハードウェアベンダーに依存しない「あらゆるアクセラレータ上でのSoTA推論性能」の実現を目指している。 アーキテクチャと技術的特徴 llm-dの中核となる技術革新は「Disaggregated Serving（分離型サービング）」だ。LLM推論のprefill（入力処理）フェーズとdecode（トークン生成）フェーズを独立したスケーラブルなPodに分離することで、リソース配分とレイテンシ管理をきめ細かく制御できるようにしている。Red HatのAI CTO Brian Stevens氏は「分離によって入力処理とトークン生成を独立してスケールできるようになった」と説明している。 その他の主要な技術的特徴として、Kubernetes Gateway API Inference Extension（GAIE）を活用したプレフィックスキャッシュ対応ルーティング、LeaderWorkerSet（LWS）プリミティブによるマルチノードレプリカとエキスパート並列処理、GPU・TPU・CPU・ストレージを横断した階層的KVキャッシュオフロードが挙げられる。 ベンチマーク結果 マルチテナントSaaSシナリオにおいて、Qwen3-32Bモデルを16基のNVIDIA H100 GPUで実行した場合、llm-dはTime-to-First-Token（TTFT）レイテンシをほぼゼロに維持しながら約12万トークン/秒のスループットを達成し、高負荷時にベースラインのKubernetesサービスを大幅に上回るパフォーマンスを示した。 今後の展望 Red Hatのエンジニアリングディレクター Robert Shaw氏は、今後の優先事項としてマルチテナントモデルサービング、リクエスト優先順位付け、新しいアクセラレータへの対応、Kubernetes上のエージェントシステム向けセキュリティ強化を挙げている。また、CNCFのAI Conformanceプログラムとの連携を通じて、分離型サービング機能のエコシステム間相互運用性の確保と、推論性能測定のためのオープンなベンチマーク標準の策定も計画されている。Mistral AIもLeaderWorkerSet向けのDisaggregatedSetオペレータの開発にコミットしており、コミュニティ主導でのエンタープライズ推論基盤の標準化が進む見通しだ。

昇格の概要 CNCF（Cloud Native Computing Foundation）の技術監視委員会（TOC）は2026年3月24日、KubernetesネイティブのCI/CDフレームワーク「Tekton」をIncubatingプロジェクトとして正式に承認した。TektonはCD Foundation（CDF）で既に卒業プロジェクトとしての地位を確立しており、CNCFにはSandboxを経ずに直接Incubatingレベルで受け入れられた。これはプロジェクトの成熟度、安定性、そしてクラウドネイティブエコシステムにおける重要性が認められた結果である。TOCスポンサーのChad Beaudin氏は「TektonはKubernetesネイティブなデリバリーのためのコアインフラとしての実力を証明した。Incubatingへの移行は、強力なマルチベンダーガバナンスとCNCFプロジェクトとの深い連携を反映している」と評価している。 Tektonのアーキテクチャと主要コンポーネント TektonはKubernetes上で動作するCI/CDフレームワークであり、Steps、Tasks、Pipelinesという構成可能なプリミティブを通じて、マルチクラウドおよびオンプレミス環境でのビルド、テスト、デプロイを実現する。プロジェクトは複数のコンポーネントで構成されており、CI/CDワークフローの中核を担う「Pipelines」（コアはv1.0安定版に到達済み）、Gitプッシュやプルリクエストなどのイベントに基づいてパイプラインを起動する「Triggers」、コマンドラインインターフェースの「CLI」、Webベースの管理UIである「Dashboard」、そしてアーティファクトの署名・証明を行うサプライチェーンセキュリティツール「Chains」がある。 コミュニティの成長と採用実績 Tektonのコミュニティは着実に成長を遂げており、GitHub上で11,000以上のスター、5,000以上のプルリクエスト、2,500以上のIssue、そして600人以上のコントリビューターを擁する。企業採用も広がっており、Red Hat OpenShift PipelinesやIBM Cloud Continuous Deliveryといった商用製品の基盤として活用されているほか、Puppet社やFord Motor Companyなどの大手企業でも導入されている。さらに、CNCFプロジェクトであるShipwrightやRed Hatが主導するKonfluxといったプロジェクトの基盤としても機能しており、エコシステム内での存在感を高めている。Argo CD（GitOps）、SPIFFE/SPIRE（アイデンティティ管理）、Sigstore（署名・検証）との統合も進んでいる。 今後のロードマップ Tektonの今後の開発では、サプライチェーンセキュリティの強化が重要な柱となる。SLSA Level 3をデフォルトで達成することを目指すほか、共有ストレージなしでタスク間のデータを安全に受け渡す「Trusted Artifacts」機能の開発が進められている。また、リモートのTask/Pipeline参照の構文改善、Kueueとの統合による高度なスケジューリング、長期的な履歴管理とクエリのためのResults APIの安定化、Artifact Hubを通じたCatalogの進化、そしてGitベースのワークフローを実現する「Pipelines as Code」の継続的な開発が予定されている。TOCスポンサーのJeremy Rickard氏は「Tektonのコンポーザブルな設計と幅広い採用は、クラウドネイティブワークフロー環境において重要な位置を占めている」と述べており、Incubating昇格によりエンタープライズ採用のさらなる加速が期待される。

概要 Googleは2026年3月、Kubernetes上でマルチプレイヤーゲームの専用サーバーをオーケストレーション・スケーリングするオープンソースプラットフォーム「Agones」を、Cloud Native Computing Foundation（CNCF）にSandboxレベルのプロジェクトとして寄贈した。これにより、Agonesはベンダー中立なコミュニティ主導のガバナンス体制へと移行し、Google以外のクラウド事業者やゲームスタジオからの参加拡大が期待される。 Agonesは2017年にGoogleとUbisoftの共同開発で誕生し、現在は250人以上のコントリビューターによって支えられている。プロジェクト創設者でリードメンテナーのMark Mandel氏は「マルチプレイヤーゲームサーバーのホスティングはかつて独自のプロプライエタリシステムに完全に依存していたが、オープンソースがゲームを変えた」と語り、CNCF移管の意義を強調した。 技術的な特徴 Agonesの最大の強みは、Kubernetesを拡張してゲームサーバーのライフサイクル管理を標準化する点にある。PC、コンソール、モバイルといったプラットフォームを問わず、一度ビルドしたサーバーバイナリを修正することなく、オンプレミスを含む主要なクラウドプロバイダーへシームレスにデプロイできる「Build Once, Deploy Everywhere」のアプローチを採用している。UbisoftのThomas Lacroix氏も、このクラウドアグノスティックな設計により、ゲームサーバーバイナリを変更せずにあらゆるクラウドで一貫して専用サーバーを稼働できる点を評価している。 また、単一のサーバープロセスで複数のゲームセッションを安全にホストする機能や、再利用可能なゲームサーバーパターンによる効率化、共通APIによるサーバー管理の簡素化といった機能を備えており、大規模なマルチプレイヤーゲームの運用コスト削減に貢献する。 今後の展望 CNCFへの移管は、マルチプレイヤーゲームインフラのオープンスタンダード化を推進する重要な一歩となる。これまでゲーム業界ではプロプライエタリなインフラが主流だったが、Agonesがベンダー中立な基盤として広く採用されることで、業界全体のインフラ標準化が加速する可能性がある。2026年のKubeCon + CloudNativeCon Europe（アムステルダム）では、Mark Mandel氏とUbisoftのJean-François Hubert氏による基調講演が予定されており、Ubisoftにおけるオーケストレーション戦略が紹介される見込みだ。