5年のMLOps基盤からagent runtimeへ、ZenMLがAI workflowを作り直した理由

現在のZenMLは、ML pipelineだけでなくAI agentまで扱うplatformへ広がっている。

公式ブログの著者でもある共同創業者Hamza Tahirは、agent時代について「We spent five years building ML pipeline infrastructure. Then agents showed up and we realized the next problem needed a new tool — not an extension of the old one.」と書いている。出典

パイプラインを運用の単位にする

ZenMLの出発点は、Pythonで書いたpipelineを実験のコードから本番のworkflowへ移すことだった。

公式READMEは、pipelineをinfrastructure backendであるstack上で実行し、codeをcontainerizeしtrackingすると説明する。出典

複雑さをstackの境界へ押し出す

MLの実行先はlocal、Kubernetes、Vertex、SageMaker、AzureMLなどに分かれる。

ZenMLはそれぞれを別製品として覚えさせるより、orchestrator、artifact store、model registryなどの差分をstackとして扱う。出典

OSSからcontrol planeへ

OSS版はself-hostedで使え、Proはmanaged control plane、SSO、RBAC、audit logsなどを追加する。

ここで売っているのはpipeline syntaxではなく、複数チームを企業のルール内で動かす運用面だ。出典

agentで新しい谷を見つける

2026年3月、ZenMLはKitaruをAI agentのproduction runtimeとして打ち出した。

従来のML pipelineとagent loopは同じではないという認識から、既存製品の単純な拡張ではなく新しい層を用意した。出典

ZenMLの道のりは、抽象化を増やす話ではない。

変化する実行環境をstackに閉じ込め、次に運用責任をcontrol planeへ移し、さらにagentの信頼性へ対象を広げる話だと言える。

ZenMLは、実験用notebookと本番のML/AI運用の間にある再現性の断絶を埋める。

Pythonで書いたpipelineを、artifact、model、orchestrator、deploymentの組み合わせとして運用し、Kubernetesや各cloudへ同じ考え方で移せる。出典

対象は、LLM workflowやagentを試すだけでなく、会社の運用責任まで負うML/AI Engineerだ。

OSSで始めて、control planeやgovernanceが必要になった段階でProへ進める導線が明確である。出典

防御力は単独の実行エンジンではなく、pipeline、artifact、model、stackを横断する運用モデルにある。

OSS repositoryとintegrationの蓄積が移行コストを下げ、Proのcontrol planeへ接続する。出典

直接のnetwork effectは弱い。

pipelineは顧客環境ごとに動くため、利用者が増えても同じworkspaceの価値が自動的に増えるわけではない。

一方でOSS examplesとintegrationが増える間接効果はある。出典

主対象は、複数cloudやKubernetesをまたいでML/LLM/agent workflowを本番運用する中規模以上の開発チームだ。

単発のnotebook分析や、完全に単一cloudへ閉じた小規模案件には過剰になりやすい。出典

第一はstack abstractionだ。

pipeline codeと実行基盤を切り離し、同じworkflowを別のorchestratorやcloudへ移しやすくする。出典

第二はOSSとdocumentationの組み合わせである。

GitHub、examples、導入ガイドが試行の入口になり、Proはmanaged control planeとenterprise governanceへ役割を分ける。出典 出典

抽象化が強いほど、stackの概念と各backendの差分を学ぶコストが生じる。

小さなチームには、単一cloudのmanaged ML serviceより設定が多く見える可能性がある。

また、agent向けKitaruまで広げる戦略は機会を増やす一方、MLOpsとagent runtimeの製品境界を曖昧にするリスクがある。

現在の企業導入数や売上は公開されていないため、成長規模は要確認だ。

OSSを入口に、documentation、GitHub、integration、case studyで導入を広げる。

無料のself-hostedから、managed control plane、SSO、audit logs、supportへアップセルするopen-core型だ。出典

この構造は開発者の試行を増やせるが、self-hosted利用者が有料化する理由をgovernanceと運用負荷で明確にする必要がある。

主要チャネル: open_source, documentation, developer_relations, content_marketing, community, platform_distribution

インフラを抽象化するときは、利用者が持ち込む実行環境を消すのではなく、差分をstackとして見える形にするのが重要だ。

OSSでpipelineの書き方を広げた後、control planeとgovernanceを有料化する順序も、開発者体験と企業要件を分ける一例になる。

日本企業では、既存のAWS、GCP、Azure、オンプレミスをまたぐAI案件が増えるほど、モデル選定より運用の再現性がボトルネックになる。

ZenML型のstack abstractionは、特定cloudへの依存を抑えながら社内標準を作る候補になる。

ただし導入前に日本語サポート、監査要件、データの保管場所を確認したい。