Julep 3 の @flow は AI エージェントを再開可能な実行グラフにする
プロジェクト概要：Julep、耐久性があり、構成可能な AI エージェント。クラッシュして再開し、安全に再試行し、すべてのステップを説明するフロー。
ひと目でわかる
- これは何？
- julep-ai/julep の README とメタデータを基に、永続データフロー、MCP の境界、CLI、拡張パッケージ、移行上の注意点を整理します。
- 誰に向いている？
- Julep 3 は、ツール呼び出しを含む長い AI 処理を Python の定義から凍結した実行グラフへ落とし込みたいチームに向きます。まずは --pre 版と dry_run を隔離環境で試し、Temporal、MCP、秘密情報、v1 からの移行経路が自分の運用に存在するかを公式文書で確認してください。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 41 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
ループではなく再開点を持つデータフロー
Julep の README は、AI エージェントを場当たり的なループではなく、合成可能で永続的なデータフローとして構築するプロジェクトだと説明しています。フローが途中でクラッシュしても再開でき、安全に再試行でき、派生した projection を通じて各ステップを説明できる、という設計が中心です。モデルに明示的に許可していないツールを呼ばせない点も、単なるプロンプトの工夫ではなく、実行面の境界として扱われています。これは README に書かれた設計方針であり、特定の負荷や成功率を示す測定結果ではありません。
@flow が Python の名前を凍結 IR に変える流れ
主な記述面は、定義時にグラフを組み立てる @flow です。通常の Python の名前を使ってステップを表し、登録済みの tool、pure、reasoner、分岐、fan-out、retry、timeout を同じ frozen wire-format IR にコンパイルします。クイックスタートでは、チケットを読む @tool、入力を整える @pure、モデルを指定した Reasoner を組み合わせ、縦棒演算子でレコードをマージし、ハンドルのキーを読み取ります。deploy は利用可能なツールと reasoner の面を固定し、dry_run はインメモリのツールと決定的な偽 reasoner でローカル実行する入口です。
Julep 3 は --pre を要するリリース候補
README が示す導入コマンドは pip install --pre julep です。Julep 3 は資料取得時点で release candidate とされ、3.0.0 が正式版になるまでは --pre が必要だと記されています。最小 Python 版、対応 OS、実運用に必要な依存関係の完全な表は README から確認できません。したがって、最初の評価では本番用の認証情報を入れず、サンプルの dry_run と自分の Python 環境を分離して、インストール結果と生成物を記録するのが現実的です。
CLI の選択文法と Application の明示性
julep CLI はディレクトリをエージェントのモジュールとして発見します。ls、show、graph、run、lint、test、trace、doctor、deploy、serve という動詞が README に並び、tag:support や state:modified、+agent、交差、除外を組み合わせるセレクタも説明されています。運用対象では、発見規則を増やす代わりに PipelineSpec を持つ Application を明示する構成が示されています。julep plan は成果物、MCP スキーマ、Helm や KEDA、ランタイムの差分を報告し、apply は不変の S3 リリースと Helm リリースを扱い、status はリリースと lane の状態を集約します。
secret:// と MCP preflight が置く境界
セルフホストの control plane には、保存時に暗号化される書き込み専用の operator vault があると README は説明します。実行ごとの短命な資格情報は secret://name 形式の MCP ヘッダー参照に結び付けられ、暗号化された Temporal payload の中だけを通り、保存済みの run data と projection から除外されます。ユーザー側の効果を起こす前には、worker が凍結された到達可能ツール面を事前確認します。新しいリリースの比較方式は pin が既定で、names と off が明示的な選択肢です。保管庫の喪失、鍵のローテーション、実行間のテナント分離については、素材は手順を示していません。
ランタイムは extras を選んで足す
ベースパッケージはオーサリングとコンパイルを担い、README の説明では PyYAML を取り込みます。temporal は Temporal 上の永続実行、dbos は DBOS または Postgres、http はネイティブ HTTP ツール、cma は CMA HTTP アダプター、mcp は公式 MCP SDK、server は FastAPI の control plane を追加します。providers は any-llm による複数プロバイダーの LlmCaller、otel と langfuse は projection の出力、store は成果物配布と bundle 署名、wasm は bundle 由来の pure のサンドボックス実行に対応すると記載されています。julep.HAVE_TEMPORAL で runtime の利用可能性を確認できますが、互換性の一覧は別途確認が必要です。
v1 との断絶とライセンスの読み方
旧来のエージェント API プラットフォームである Julep v1 は v1 ブランチと v1.docs.julep.ai に残され、Julep 3 はゼロからの書き直しで移行経路はない、と README は区別しています。リポジトリのライセンスは Apache-2.0 です。素材で示されたライセンスは、著作権と特許に関する許諾、再配布や派生物に関する条件を定めますが、サポート、保証、セキュリティ監査を約束するものではありません。Julep 3 を選ぶときは、v1 のコードや設定がそのまま使えると仮定せず、実際の導入対象で再設計の範囲を洗い出すべきです。
採用候補として見るときの論点は、コードを短く書けるかだけではありません。定義時に作られたグラフと、実際に worker が動かす runtime の境界を同じ版で保存し、tool の追加や削除がどの release で起きたかを追う必要があります。README はワークフローの再開、retry、timeout、tool の許可面を説明していますが、ワーカーの台数、外部 API の idempotency、S3 の保持期間、Temporal の障害復旧手順は示していません。dry_run で確認できる決定性と、本番の外部効果が安全に再実行できることは別の検証項目です。Julep 3 の新しい構成を選ぶなら、v1 の資産を移せるという前提を捨て、PipelineSpec、capability manifest、MCP snapshot、秘密情報の経路を一つずつ設計記録に落とすべきです。
実装を始める前に、フローの入力、読み取り専用の tool、書き込みを伴う tool、reasoner、外部への効果を別の表にすると設計の穴が見えます。Julep の frozen IR と capability manifest は許可面を固定する材料ですが、呼び出し先の API が二重実行に耐えるかまでは決めません。MCP snapshot のスキーマが変わった場合に release を止めるのか、names や off へ切り替えるのかも運用判断です。README は control plane、worker、Temporal、S3、Kubernetes の構成例を示しますが、組織の復旧時間や監査要件を満たすとは述べていません。従って最初の評価では、再開可能性を確認する小さな失敗試験と、秘密情報が run data に残らないことを確認する記録を分けて作るべきです。
編集部の結論
Julep 3 は、ツール呼び出しを含む長い AI 処理を Python の定義から凍結した実行グラフへ落とし込みたいチームに向きます。まずは --pre 版と dry_run を隔離環境で試し、Temporal、MCP、秘密情報、v1 からの移行経路が自分の運用に存在するかを公式文書で確認してください。性能値やサポート水準は素材からは判断できません。
コミュニティノート