Microsoftは2026年8月28日、Kubernetes上でAIワークロードを統合的に運用するためのセルフホスト型プラットフォーム「TauGrid」を、MITライセンスの下でオープンソースソフトウェアとして公開した。GPUノードを搭載した任意のKubernetesクラスター上で、Helmチャート1つをインストールするだけで、AI研究用のジョブ実行環境が即座に構築できる点が最大の特徴である。
Kubernetes上でAIを運用するプラットフォームチームは、通常、一つのツールだけで運用しているわけではない。キューイングシステム、分散ランタイム、GPUノードのヘルスチェック、ダッシュボード、そしてそれらすべてを束ねるジョブ投入スクリプト――これらを個別に統合するのが通例だった。TauGridは、この煩雑な組み立て作業を単一のHelmインストールに集約する。コードベースは主にGoで記述されており、Azure Kubernetes Serviceエンジニアリングチームが開発を主導した。
TauGridとは：5つの要素を1つのHelmチャートに統合
TauGridの中核は、AIワークロードのためのセルフホスト型プラットフォームである。これまではプラットフォームチームが手作業で統合していた以下の5つの要素を、一つのパッケージとして提供する。
- tau CLI：研究者がKubernetesを直接操作せずにジョブを投入するためのコマンドラインインターフェース
- Kueue によるワークロードキューイングとアドミッション制御：複数チームが共有するクラスター上で、クォータと優先順位に基づいたジョブ管理を実現
- KubeRay によるRayクラスターオーケストレーション：分散AIワークロードの実行基盤を管理
- GPUヘルスモニタリング：ノードレベルのGPU健全性を監視し、ハードウェア障害時には自動的にノードをドレイン
- クラスターおよびワークロードの可観測性：実行履歴やメトリクスの収集と可視化
責任分担の設計思想は明確である。プラットフォームチームはワークスペース、キュー、コンピュートプロファイル、ストレージ、アイデンティティ、可観測性といった基盤部分を所有する。一方、研究者はリポジトリとCLIを使って作業し、Kubernetesの設定を直接行うことなくワークロードを投入できる。この分離により、研究者は自らの責務に集中でき、プラットフォームチームは統制を維持できる。
TauGridにおけるジョブの流れ：6つのステージで構成されるライフサイクル
TauGridでのワークロードは、tau.yaml ファイルに記述される。Microsoftが公開したGPUトレーニングのサンプルでは、1基のA100上でPyTorchジョブを実行する設定が示されている。
schema_version: 1
name: aks-gpu-quickstart
run:
entrypoint: train.py
workload_kind: rayjob
compute:
gpus: 1
workers: 1
cpus: 16
memory: 64Gi
runtime:
image: mcr.microsoft.com/aks/ai-runtime/ray:py3.12-ray2.56.0-cuda13.0
pip:
- torch>=2.4.0研究者が tau run コマンドを実行すると、TauGridはプラットフォームポリシーを解決し、Kubernetes JobまたはKubeRay RayJobをレンダリングした上で、Kueue経由で投入する。Microsoftがドキュメント化しているジョブライフサイクルは以下の6つのステージで構成される。
Submission（投入）
tau CLIが tau.yaml の設定を検証し、プラットフォームポリシーを解決した上で、Kubernetes JobもしくはKubeRay RayJobのマニフェストを生成する。研究者がKubernetesのマニフェストを直接記述する必要はない。
Queueing（キューイング）
レンダリングされたジョブはKueue経由で投入される。Kueueはクォータアドミッションと優先順位の制御を司り、異なるワークスペースからのジョブは1つのClusterQueueを共有する。
Execution（実行）
TauGridはKubeRayを通じて、Kubernetes上で分散Rayワークロードを起動し管理する。スケジューラが割り当てたGPUリソース上でジョブが実行される。
Monitoring（監視）
ステータス、ログ、GPUヘルスメトリクスが実行期間中追跡される。ノードレベルの診断機能により、ハードウェア障害が検出された場合には自動的にノードがドレインされる。
Recovery（リカバリ）
失敗したジョブはリトライ可能であり、チェックポイントからの再開もサポートされる。GPU障害が発生しても、長期間のトレーニング実行をゼロから再開する必要はない。
Evidence（エビデンス）
ワークロードのメタデータ、設定、ログ、メトリクス、チェックポイント、実行履歴が「エビデンスレコード」として保存される。これにより、各実行の再現性と監査が保証される。
複数のチームがクラスターを共有する場合、それぞれのジョブは共有のKueue ClusterQueueに投入される。Kueueはクォータと優先順位に基づいて各ジョブのアドミッションを判断し、Kubernetesが健全なGPUノードにジョブを配置する。
インストール手順と動作環境：Helm 1つで即座に導入可能
TauGridはMITライセンスで提供され、コンテナイメージとHelmチャートはMicrosoft Container Registry（MCR）上にOCIアーティファクトとして公開されている。動作要件は、Kubernetes 1.30以上、GPUノード、kubectl、そしてHelm 3.0以上である。インストールは以下のコマンド一つで完了する。
helm install taugrid \
oci://mcr.microsoft.com/aks/ai-runtime/helm/taugrid \
--version 0.4.2 \
--namespace tau-system \
--create-namespaceファーストパーティイメージは mcr.microsoft.com/aks/ai-runtime/ 配下で提供され、Tau CLI、TauGrid Portal（Web UI）、そしてTauコアコントローラが含まれる。Microsoftは latest タグではなく、バージョンタグまたはイミュータブルなダイジェストを指定することを推奨している。CLIのインストーラはGitHub ReleasesからLinuxおよびmacOS向けに提供され、Windows amd64向けのPowerShellインストーラも用意されている。インストーラはリリースチェックサムを検証し、PATHは自動的に変更しない。
運用上の2つの重要ポイント：テレメトリとAzure依存の現状
Azure外でTauGridを評価するすべての関係者にとって、2つの運用上の詳細が重要である。
第一に、TauGridはデフォルトでMicrosoftにいかなるテレメトリも送信しない。リモートエクスポートも、オペレーターが明示的に送信先を設定しない限り無効のままである。プライバシーとデータ主権を重視する企業にとって、これは明確な利点となる。
第二に、一部の統合機能は現時点ではAzure固有のままである。特に、Azure Data Explorerを用いた可観測性の実装はAzure環境に依存している。ただし、Microsoftの表明した意図は、Azure依存なしでクラウドおよびオンプレミスのKubernetesをサポートすることであり、その方向でのコントリビューションを広く受け付けている。コミュニティの支援が、TauGridのポータビリティを左右する重要な要素となるだろう。
重要な5つのポイント
TauGridの理解を深めるために、本記事の要点を以下にまとめる。
- MicrosoftはTauGridを2026年8月28日にMITライセンスでオープンソース化。リポジトリは Azure/taugrid で公開されている。
- Helm 1回のインストール で、tau CLI、Kueueキューイング、KubeRayオーケストレーション、GPUヘルスモニタリング、可観測性のすべてがセットアップされる。
- Kubernetes 1.30以上とGPUノード、Helm 3.0以上 があれば、Azure内外を問わず即座にデプロイ可能。
- エビデンスレコード が設定、ログ、メトリクス、チェックポイントを保存するため、各実行の再現性と監査性が担保される。
- デフォルトではテレメトリ無効。ただし、Azure Data Explorerを用いた可観測性機能は現時点ではAzure固有であり、コミュニティによるマルチクラウド対応への貢献が期待される。
TauGridは、AI研究のためのKubernetes基盤を劇的にシンプルにする可能性を秘めている。特に、プラットフォームエンジニアリングと研究者の責任を明確に分離した設計思想は、大規模なAI開発チームにとって重要な価値を提供する。今後のコミュニティの発展と、Azure以外の環境への対応拡充が、このプロジェクトの真価を決めることになるだろう。詳細はAKS Engineering BlogおよびGitHubリポジトリを参照してほしい。
