ZenML 0.96系レビュー: パイプラインとエージェントを同じスタックで動かす設計を読む

ZenMLが埋めようとしているのは実行基盤の断絶である

READMEはZenMLの対象読者を「ML or AI Engineers working on traditional ML use-cases, LLM workflows, or agents, in a company setting」と明記している。個人の実験ではなく、企業内で複数のワークフローを運用する立場が想定されている。解決しようとしている問題は、モデル学習のパイプラインとエージェントのループを別々のツールで組むと、実行履歴やメタデータが分断されるという点にある。ZenMLはパイプラインという記述単位とスタックという実行基盤の単位を分離し、同じパイプライン定義を異なるバックエンドで動かせるようにする。READMEの表現を借りれば「write workflows (pipelines) that run on any infrastructure backend (stacks)」であり、この分離が設計の中心にある。

パイプラインとスタックの分離、そしてスナップショットという記録単位

ZenMLのデータフローは、パイプライン定義、ステップ、アーティファクト、スナップショット、デプロイメントという語彙で整理されている。READMEのquickstartの説明にこれらの概念が列挙されており、ステップの入出力はアーティファクトとして扱われ、パイプラインの構成はスナップショットとして記録される。実行基盤側はスタックと呼ばれる抽象で、SageMakerやGCP Vertexのようなクラウドサービス、あるいはローカル環境を同じインターフェースで扱う。READMEは「Automatically containerizing and tracking your code」と「Tracking individual runs with metrics, logs, and metadata」を主要機能として挙げており、コードのコンテナ化とrun単位のメタデータ記録が自動化の対象だと分かる。MLflow、Langgraph、Langfuseといった既存ツールとの統合も機能として列挙されているが、統合の具体的な実装範囲はREADMEからは読み取れない。

client-server構成を取る点が他のPythonワークフロー基盤との分岐点になる

ZenMLは単体のPythonライブラリではなく、client-serverアーキテクチャを採用している。READMEは「ZenML uses a client-server architecture with an integrated web dashboard」と述べ、ダッシュボードが別リポジトリ(zenml-io/zenml-dashboard)で管理されていることを示している。開発時はpip install "zenml[local]"でクライアントとサーバーをローカルに同居させ、本番ではサーバーを別途デプロイしてpip install zenmlとzenml login <server-url>で接続する。この構成は、AirflowやPrefectのようなスケジューラ中心のツールとは異なる。ZenMLはスケジューリングそのものよりも、実行の記録と基盤の抽象化に重心を置いている。サーバーが状態を持つ以上、チームで共有する場合はサーバーの運用が前提になり、完全にサーバーレスな使い方は想定されていない。

導入手順は3コマンドだが、依存セットの選択が最初の判断になる

READMEが示す導入は次の3行である。pip install "zenml[server]" でサーバー機能込みのパッケージを入れ、zenml init でリポジトリを初期化し、zenml login でローカルサーバーを起動するかリモートに接続する。READMEは「pip install zenml will install a slimmer client」と注記しており、サーバーを持たないクライアント専用の構成も選べる。ローカル開発ではpip install "zenml[local]"という選択肢も示されている。つまり最初に決めるべきは、自分がサーバーを立てる側なのか、既存サーバーに接続するだけの側なのかである。初期化後はリポジトリ内のexamples/配下を試す流れが案内されており、quickstartがパイプライン、ステップ、アーティファクト、スナップショット、デプロイメントの各概念を扱うと説明されている。

抽象化の層が厚いほど、基盤固有の挙動は見えにくくなる

ZenMLの価値は「Abstracting away infrastructure complexity」にあるとREADMEは述べる。ただしこの抽象化はトレードオフを伴う。SageMakerやGCP Vertexの固有機能のうち、ZenMLのスタック抽象が公開していないものは、そのままでは使えないか、スタックのカスタム実装を書く必要がある。READMEにはスタックの拡張方法の詳細は含まれておらず、どの程度まで固有機能に到達できるかは資料からは判断できない。また、client-server構成はサーバーのバージョンとクライアントのバージョンの整合が前提になる。リリースは0.96.2から0.96.4まで約2か月で3回出ており、マイナーバージョン内でも更新頻度は低くない。バージョンを固定せずに追従すると、サーバー側との不一致が問題になり得る。

MLflowやLangfuseとの違いは、記録の対象がモデルか実行全体かにある

比較対象として分かりやすいのはMLflowである。MLflowは実験の記録とモデルレジストリに焦点を当て、学習ジョブのメトリクスやパラメータを追跡する。ZenMLはrunそのものを記録対象にし、そのrunをどのスタックで実行したかまで含めて扱う。READMEがMLflowを統合先の一つとして挙げている点は重要で、両者は競合というより層が違う。ZenMLのパイプラインの中からMLflowのトラッキングを呼ぶ、という使い方が自然である。LangGraphやLangfuseとの関係も同様で、エージェントのループやLLMのトレースはそれらのツールが担い、ZenMLはそれをパイプラインとして包み、実行基盤とメタデータの層を提供する。どのツールがどの責務を持つかを先に決めておかないと、記録が二重になる。

Apache-2.0で公開されている範囲と、Pro版との境界

リポジトリのライセンスはApache-2.0で、archivedにはなっておらずmainブランチが更新されている。READMEには「Sign up for ZenML Pro」へのリンクがあり、オープンソース版とは別に有償の提供があることが示されている。ただしREADMEからは、Pro版にしか含まれない機能が何かは分からない。Apache-2.0は商用利用や改変を許容する寛容なライセンスだが、Pro版の機能範囲とOSS版の機能範囲の境界は、導入判断の前に公式ドキュメントで確認する必要がある。ここで注意したいのは、ライセンス条項の解釈は法的判断であり、この記事で断定できないという点である。実際の利用条件はLICENSEファイルとPro版の契約条件を直接確認してほしい。

向くチームと向かないチームを分ける基準

ZenMLが効くのは、実行基盤が既に複数あり、ワークフローの定義と実行環境を分離したい場合である。READMEが挙げる導入企業の例(Airbus、AXA、JetBrains、Rivianなど)はいずれも大規模組織で、この前提と整合する。逆に、単一のスクリプトやノートブックで完結する処理、あるいは依存パッケージを極力増やしたくない小規模プロジェクトでは、サーバーの運用とスタック概念の学習が負担になる。判断の分かれ目は、run単位のメタデータを後から横断的に検索する必要があるかどうかである。必要がないなら、ZenMLの抽象化は得られるものより失うものの方が大きい。導入する場合は、zenml initで生成される構成を確認し、zenml loginで接続するサーバーのバージョンをクライアントと揃え、examples/quickstartでパイプライン、ステップ、アーティファクト、スナップショットの関係を実際に動かしてから本番スタックの設計に進むのが順当である。

編集部の結論

採用を検討すべきなのは、社内に複数のML/LLMワークフローがあり、実行基盤がKubernetes、SageMaker、GCP Vertexなどに分散していて、run単位のメタデータを一元管理したいチームである。逆に、単一のノートブックや単発のバッチ処理で完結する個人開発、あるいは依存を最小限に保ちたい小規模プロジェクトには、client-server構成とスタック概念の学習コストが上回る可能性が高い。導入前に確認すべきは、zenml initで作られるリポジトリ構成と、zenml loginで接続するサーバーのバージョン互換性、そしてzenml[server]とzenml[local]のどちらの依存セットが自分の環境に必要かである。

公式情報源

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. zenml-io/zenml on GitHub