LlamaDeploy は非推奨になった：llama-agents への移行を前提に読む
Deploy your agentic worfklows to production
ひと目でわかる
- これは何？
- LlamaDeploy は LlamaIndex のワークフローをサービスとしてデプロイするための仕組みだが、README の冒頭で非推奨が宣言され、後継として llama-agents が示されている。採用判断よりも、既存コードの読み替えと移行先の確認が中心になる。
- 誰に向いている？
- これから新規にエージェントを本番へ出すなら、LlamaDeploy を選ぶ理由はほぼない。README は冒頭で非推奨を宣言し、ワークフローの提供には llama-agents を使うよう案内しているため、移行先の llama-agents 側のドキュメントとリリース状況を先に確認するのが順序として正しい。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 162 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
非推奨の宣言を出発点にする
このリポジトリを評価するとき、最初に読むべきなのは機能一覧ではなく README の冒頭にある警告だ。引用すると「This project is deprecated.」と明記され、続けてワークフローを提供するには llama-agents（リンク先は run-llama/workflows-py）を使うよう指示している。プロジェクトの説明文は「Deploy your agentic worfklows to production」であり、LlamaIndex で組んだエージェントのワークフローを本番環境で動かすためのデプロイ層を担う、という位置づけだったことが読み取れる。MIT ライセンスで、既定ブランチは main、最終プッシュは 2026-04-06、その同日に v0.9.2 が出ている。非推奨の告知と最後のリリースが同じ日付なのは、機能追加ではなく終了処理としてのリリースだった可能性を示す。ここから先は、新規採用の可否を論じるより、既存の構成をどう読み替えるかに読む価値がある。
何を本番に出そうとしていたのか
LlamaDeploy が扱う単位は、単体の API サーバーではなくエージェントのワークフローだ。トピックに agents、multi-agents、deployment、framework が並んでいることから、複数のエージェントを組み合わせた処理を、ローカルのノートブックから外へ出す作業を想定していたことが分かる。LlamaIndex で書いたワークフローをそのままサービスとして公開したい、という動機が中心にある。対象読者は、プロトタイプまでは動いたが、それを常時起動のサービスに変える段階で止まっている開発者だ。逆に、単一の関数を HTTP で包むだけの用途や、バッチ処理として一度だけ走らせればよい処理には、この層を挟む意味は薄い。デプロイという語が指す範囲が、コンテナの起動そのものではなく、ワークフローをサービスとして分割し配置するところにある点を押さえておきたい。
uv と pyproject.toml が示す入口
README のバッジは uv と PyPI のバージョン、そして pyproject.toml から読み取った Python の要求バージョンを示している。つまり配布は PyPI の llama-deploy パッケージとして行われ、依存解決には uv が想定されている。インストール手順そのものは README に書かれていないため、pip install llama-deploy が正しいかどうかは、この資料からは断定できない。バッジの URL が pypi.org/project/llama-deploy を指していることだけが、パッケージ名の根拠になる。Python の要求バージョンもバッジ経由で pyproject.toml を参照する形になっており、具体的な下限値はこの資料には現れない。設定キーやデプロイ定義のスキーマも README には載っていないので、実際に動かす前に確認すべきは、リポジトリ内の pyproject.toml とデプロイ定義のサンプル、そしてホームページに挙がっている docs.llamaindex.ai 配下のモジュールガイドだ。バージョンは v0.9.0 が 2025-07-18、v0.9.1 が 2025-07-29、v0.9.2 が 2026-04-06 で、0.9 系のまま終わっている。
非推奨プロジェクトを読むときの限界
最大の制約は、これが非推奨であるという一点に尽きる。バグが見つかっても修正が入る保証はなく、v0.9.2 が最後のリリースになる可能性がある。0.9 系というバージョン番号は 1.0 に達していないことを示しており、API の安定性を前提にした設計は避けたほうがよい。もうひとつの限界は資料の薄さだ。README にはインストール手順も設定例もなく、警告文とバッジ、そしてリポジトリ名だけが並ぶ。ドキュメントの本体は外部のモジュールガイドに置かれているが、その内容はこの資料からは確認できない。したがって、LlamaDeploy の内部アーキテクチャ、メッセージの流れ、永続化の方式について、ここで具体的に述べることはできない。推測で埋めるより、確認できない部分として残すほうが誠実だ。新規の学習対象として選ぶ場合は、この薄さ自体がコストになる。
llama-agents との役割の違い
README が移行先として挙げるのは llama-agents で、リンク先は run-llama/workflows-py となっている。ここで注意したいのは、名前が似た別物を想定していない点だ。LlamaDeploy はワークフローを本番へ配置する層として説明され、llama-agents はワークフローを提供する側として案内されている。つまり同じ問題に対する後継であり、並行して使い分ける関係ではない。両者の実装の差、たとえばサービスの分割方法や通信の方式がどう変わったのかは、この資料からは分からない。差分を確認するには workflows-py 側のリポジトリとドキュメントを直接読む必要がある。移行を検討する際に最初に突き合わせるべきは、LlamaDeploy で書いたデプロイ定義の各サービスが、llama-agents でどう表現されるかという一点だ。ここが一対一で対応しない場合、移行は書き直しに近づく。
メンテナンスとライセンスの見取り図
ライセンスは MIT で、これは変更点を公開せずに改変物を配布できる条件だ。ただし非推奨の表明と MIT であることは別の話で、ライセンスが許す範囲と、上流が保守を続けるかどうかは独立している。フォークして自前で保守する道は MIT の下で開かれているが、その場合のコストは利用側が全部抱えることになる。リリース間隔を見ると、v0.9.0 から v0.9.1 までは 11 日、v0.9.1 から v0.9.2 までは 8 か月以上空いている。この間隔の変化だけでも、活発に開発されていた時期とそうでない時期の差が読み取れる。アップグレードの判断材料としては、0.9 系の間に破壊的変更が入ったかどうかをリリースノートで追う必要があるが、その内容はこの資料には含まれていない。法務上の判断はここでは扱わない。
それでも読む価値がある場合
非推奨だからといって、リポジトリを開く意味がなくなるわけではない。LlamaIndex のワークフローをサービスとして切り出すとき、どの単位で分割し、何を設定として外に出すかという設計の型は、後継を読むときの語彙になる。既に LlamaDeploy で本番運用している構成があるなら、移行の前に現状を書き出しておく価値はある。具体的には、pyproject.toml に記録された Python の要求バージョン、デプロイ定義に並ぶサービスの名前と責務、そして外部から叩かれるエンドポイントの一覧だ。この三つが揃っていれば、llama-agents 側のドキュメントと突き合わせる作業は機械的に進められる。逆に、これから最初のエージェントを本番へ出す人が、学習コストを払ってまでこのリポジトリを読む理由は見当たらない。
編集部の結論
これから新規にエージェントを本番へ出すなら、LlamaDeploy を選ぶ理由はほぼない。README は冒頭で非推奨を宣言し、ワークフローの提供には llama-agents を使うよう案内しているため、移行先の llama-agents 側のドキュメントとリリース状況を先に確認するのが順序として正しい。既に LlamaDeploy で動いている構成がある場合は、pyproject.toml が要求する Python のバージョンと、デプロイ定義に書いたサービスの分割単位を書き出しておく。移行時にその分割をそのまま持ち込めるかどうかが、作業量を左右する。
コミュニティノート