--- title: "Prefectとは？Pythonワークフロー管理の使い方と3系の始め方【2026年版】" url: "https://www.issoh.co.jp/tech/details/10836/" published: 2026-02-03 updated: 2026-10-01 categories: ["自動化"] publisher: "株式会社一創" --- # Prefectとは？Pythonワークフロー管理の使い方と3系の始め方【2026年版】 Prefectは、Pythonの関数を`@flow`・`@task`で囲むだけでデータパイプラインを構築・監視できるワークフローオーケストレーションツールです（英単語の prefect＝監督生・長官の意味ではなく、開発元 Prefect Technologies が提供するOSSツールを指します）。2024年9月にメジャー更新の3.0がGAとなり、2026年10月1日時点の最新は3.8系（[PyPIのprefectパッケージ](https://pypi.org/project/prefect/)で3.8.7）です。この記事では、Prefectとは何かという定義から、cronやタスクキューとの違い、`pip`導入とDocker Composeでの環境構築、FlowとTaskの書き方、デプロイとWork Pool、スケジューリング、キャッシュによる冪等性、AirflowやDagsterとの使い分け、採用を決める条件までを、最新の3系にそろえて解説します。 ## まとめ：Prefectとは何か・3系の要点と最短で動かすまでの手順 - **正体**：Pythonネイティブのワークフローオーケストレーションツール。既存のPython関数にデコレータを付けるだけでフロー化でき、実行状況をUIで可視化・リトライ・スケジュール実行できる。ライセンスはApache 2.0。 - **3系の要点**：イベント駆動オートメーションがOSSに開放、トランザクションAPIで冪等性を確保、実行基盤はエージェント廃止でWork Pool＋Workerへ統一、実行エンジン刷新で高速化。3.8系ではセルフホストのUIが新しいV2 UIへ切り替わった。 - **最短の始め方**：`pip install prefect` → 関数に`@task`/`@flow` → `python flow.py` で実行。UIは`prefect server start`で`http://127.0.0.1:4200`。Python 3.10以上が前提。 - **使いどころ**：Pythonで動的にパイプラインを書きたいチーム向き。静的DAGの大規模バッチを既にAirflowで回しているなら無理に移行しない、長時間の分散ステートフル処理はTemporalが候補、という線引きで選ぶ。 - **費用**：OSS本体は無料で自前運用できる。マネージドのPrefect Cloudにも無料のHobbyプラン（2ユーザー・5デプロイメント・実行履歴7日）があり、検証はコストをかけずに始められる。 ## Prefectとは｜Python関数からワークフローを組むオーケストレーションツール Prefectは、複数の処理（データ抽出→変換→ロード、モデル学習、バッチ集計など）を「いつ・どの順で・失敗したらどうするか」を含めて管理する仕組みを、Pythonコードのまま与えます。ライセンスはApache 2.0のOSS本体（ソースは[GitHubのPrefectHQ/prefectリポジトリ](https://github.com/PrefectHQ/prefect)で公開）に加え、マネージド版のPrefect Cloudがあり、同じコードをそのまま自前サーバーでもCloudでも動かせます。特別なDSLやYAMLでDAGを宣言する必要はなく、通常のPython関数にデコレータを付けるだけで、リトライ・キャッシュ・ログ・可視化が後付けで効く仕組みです。 「オーケストレーション」という言葉自体は、複数の処理や部品を順序・依存関係・失敗時の扱いまで含めて指揮することを指します。用語の整理と自動化との違いは[オーケストレーションとは？自動化との違いと種類](https://www.issoh.co.jp/tech/details/13632/)にまとめているので、言葉の定義から入りたい場合は先に目を通すと理解が早くなります。 まず押さえるべき構成要素は次の5つです。この語彙が分かると、以降のインストールやデプロイの説明が一直線に理解できます。 | 要素 | 役割 | | ---------- | ---------------------- | | Task | 最小単位。リトライ・キャッシュの対象 | | Flow | Taskを束ねる本体。実行の単位 | | Deployment | Flowをスケジュール・API実行できる登録 | | Work Pool | どのインフラで動かすかの窓口 | | Worker | Poolを監視しジョブを起動するプロセス | Taskは`@task`を付けた関数、Flowは`@flow`を付けた関数です。Work Poolはローカル・Docker・Kubernetes・ECSなど実行先ごとに作り、Workerは旧エージェントの後継として、そのPoolに積まれた実行要求を拾って起動します。 同種のツールにApache AirflowやDagster、Temporalがあります。Airflowが静的なDAG定義と豊富な運用実績で強いのに対し、Prefectは「普通のPythonをそのままワークフロー化する」動的な書き味が特徴です。比較の詳細は本文後半の[Apache Airflowとは（仕組み・使い方とAirflow 3の新機能）](https://www.issoh.co.jp/tech/details/1441/)との違いの章で扱います。 ### Prefectとcronやタスクキューの違いと、ワークフロー管理が要る場面 「定期実行ならcronで足りるのでは」という疑問は、Prefectを検討する人がまず抱くものです。cronは「決まった時刻にコマンドを起動する」ところまでしか面倒を見ません。処理が途中で落ちたとき、どのステップで止まったのか、再実行してよいのか、前段の結果をどこに残したのか、といった情報はcronの外で自作することになります。 タスクキュー（CeleryやRQなど）は、Webアプリから非同期処理を切り出してワーカーに配る仕組みです。1件ずつのジョブを速く確実に処理するのは得意な一方、「抽出が終わったら変換、変換が全部終わったら集計」のような処理間の依存関係や、実行履歴を横断して眺める画面は主目的ではありません。違いの詳細は[Celery（Python）とは：分散タスクキューの仕組み](https://www.issoh.co.jp/tech/details/17293/)で扱っています。 | 手段 | 守備範囲 | 足りなくなる場面 | | ------- | ------------ | ----------- | | cron | 時刻起動のみ | 依存関係・再実行・履歴 | | タスクキュー | ジョブの非同期配布 | 処理間の依存と可視化 | | Prefect | 依存・再試行・履歴・通知 | 常駐基盤の運用が増える | 目安として、処理が3ステップ以上に分かれ、失敗時に「どこから再開するか」を人が判断している状態なら、Prefectのようなワークフロー管理ツールを入れる価値が出てきます。ETL処理の全体像やツールの種類は[ETLとは？仕組み・ELTとの違い・ツール選定](https://www.issoh.co.jp/column/details/13364/)も参考になります。 ## Prefect 3系の主な特徴と2系からの変更点、3.8系で変わったこと 3.0は2.xからの単なる機能追加ではなく、実行エンジンとキャッシュ、実行基盤を作り替えたメジャー更新です。2系の記事やコードを見て学ぶ場合は、次の変更点を前提に読み替えてください。公式の移行手順は[How to upgrade to Prefect 3.0](https://docs.prefect.io/v3/how-to-guides/migrate/upgrade-to-prefect-3)にまとまっています。 | 観点 | Prefect 2.x | Prefect 3.x | | ------------- | ---------------- | ---------------- | | イベント/オートメーション | Cloud限定 | OSSにも開放 | | キャッシュ/冪等性 | 個別キャッシュ | トランザクションAPIで統一 | | 実行基盤 | Agent＋Work Queue | Worker＋Work Pool | | 実行モデル | スレッド分散 | 既定でメインスレッド実行 | | 型/検証 | Pydantic v1 | Pydantic v2 | 最大の変更は、これまでPrefect Cloud専用だった**イベント＆オートメーション基盤がOSS本体に入った**ことです。フローの完了や外部イベントをトリガーに別のフローを起動する、といった自動化を無料のOSSだけで組めます。 もう一つの核が**トランザクションAPI**です。複数のTaskを1つのトランザクションにまとめ、途中で失敗したら副作用（書き込み済みファイルの削除など）をロールバックできます。これによりキャッシュも「トランザクションがコミットされた時だけ結果を確定する」方式に刷新され、再実行時の冪等性が扱いやすくなりました。 実行基盤では**エージェントが廃止され、Work Pool＋Workerに一本化**されました。公式の移行ガイドにも、エージェントは2系の途中で非推奨となり3系ではWorkerが標準である旨が書かれています。2系でagentを使っていた場合は[Upgrade from agents to workers](https://docs.prefect.io/v3/how-to-guides/migrate/upgrade-agents-to-workers)の手順に沿ってWorkerへの置き換えが必要です。あわせて、既定でコードがメインスレッド上を走るようになり、共有リソースやスレッドセーフでない処理での挙動が直感的になったうえ、実行エンジンの刷新で大規模フローの処理性能が改善しています。 3系の中でもマイナー版ごとに変更が入っています。[Prefect 3.8のリリースノート](https://docs.prefect.io/v3/release-notes/oss/version-3-8)によると、3.8.0（2026年7月23日リリース）では**セルフホストのサーバーで新しいV2 UIが既定**になり、フロー実行トリガーにデプロイメントの絞り込み条件を足せるようになりました。古い記事のスクリーンショットと画面の並びが違って見える場合は、この切り替えが原因です。以降も9月下旬の3.8.7まで修正版が続いており、版ごとの細かな差分はリリースノートで確認するのが確実です。 ## Prefect 3系の導入手順｜pip・ローカルUI・Compose・Cloudの環境構築 導入はPythonパッケージ1つで完結します。ローカルで試す→Docker Composeで永続化する→Cloudに載せる、の順で環境を広げていくと迷いません。 ### pipでのインストールとバージョン確認｜Python 3.10以上が前提 [公式のInstall Prefect](https://docs.prefect.io/v3/get-started/install)にある通り、PrefectはPython 3.10以上を要求します（PyPIの宣言は2026年10月時点で3.10以上3.15未満）。仮想環境（venvやuv）を切ってから入れるのが安全です。 ``` python -m venv .venv source .venv/bin/activate pip install -U prefect prefect version ``` `prefect version`で3.8.x系が表示されればOKです。uvを使っている場合は`uv pip install -U prefect`でも同じ結果になります。2系が入っている環境をアップグレードする場合は、上の変更点の表（特にエージェント廃止）を確認してから上げてください。 ### ローカル環境でのサーバー（UI）起動手順とAPI接続先の設定方法 手元でダッシュボードを立ち上げるにはサーバーを起動します。 ``` prefect server start ``` 起動後、ブラウザで`http://127.0.0.1:4200`を開くとUIが表示され、フローの実行履歴やログ、Work Poolの状態を確認できます。フロー実行時にこのローカルAPIへ接続させたい場合は、別ターミナルで次のように設定します。 ``` prefect config set PREFECT_API_URL=http://127.0.0.1:4200/api ``` 3.8系ではこの画面が新しいV2 UIになっています。設定値の優先順位（環境変数・プロファイル・`prefect.toml`）は公式の設定ガイドで定義されているので、複数環境を切り替える場合はプロファイルを分けておくと取り違えを防げます。 ### Docker Composeで永続構成を作る｜PostgreSQLとRedisの公式構成 `prefect server start`単体はSQLiteの一時構成で、チームで共有する履歴の置き場には向きません。チームで使うなら、PostgreSQLをバックエンドにしたサーバーをDocker Composeで永続化するのが実務的です。現行の[公式のDocker Compose手順](https://docs.prefect.io/v3/how-to-guides/self-hosted/docker-compose)は、PostgreSQL・Redis（イベントのメッセージブローカー）・APIサーバー・バックグラウンドサービス・Workerの5つに分けた構成を示しています。次はその構成を要点に絞って写したものです。 ``` services: postgres: image: postgres:14 environment: POSTGRES_USER: prefect POSTGRES_PASSWORD: prefect POSTGRES_DB: prefect volumes: - postgres_data:/var/lib/postgresql/data healthcheck: test: ["CMD-SHELL", "pg_isready -U prefect"] interval: 5s retries: 5 redis: image: redis:7 healthcheck: test: ["CMD-SHELL", "redis-cli ping"] interval: 5s retries: 5 prefect-server: image: prefecthq/prefect:3-latest depends_on: postgres: condition: service_healthy redis: condition: service_healthy environment: PREFECT_SERVER_DATABASE_CONNECTION_URL: postgresql+asyncpg://prefect:prefect@postgres:5432/prefect PREFECT_SERVER_API_HOST: 0.0.0.0 PREFECT_SERVER_UI_API_URL: http://localhost:4200/api PREFECT_SERVER_EVENTS_MESSAGING_BROKER: prefect_redis.messaging PREFECT_SERVER_EVENTS_MESSAGING_CACHE: prefect_redis.messaging PREFECT_REDIS_MESSAGING_HOST: redis PREFECT_REDIS_MESSAGING_PORT: 6379 command: prefect server start --no-services ports: - "4200:4200" prefect-services: image: prefecthq/prefect:3-latest depends_on: - prefect-server environment: PREFECT_SERVER_DATABASE_CONNECTION_URL: postgresql+asyncpg://prefect:prefect@postgres:5432/prefect PREFECT_SERVER_EVENTS_MESSAGING_BROKER: prefect_redis.messaging PREFECT_SERVER_EVENTS_MESSAGING_CACHE: prefect_redis.messaging PREFECT_REDIS_MESSAGING_HOST: redis PREFECT_REDIS_MESSAGING_PORT: 6379 command: prefect server services start prefect-worker: image: prefecthq/prefect:3-latest depends_on: - prefect-server environment: PREFECT_API_URL: http://prefect-server:4200/api command: prefect worker start --pool local-pool restart: on-failure volumes: postgres_data: ``` 公式の構成ではprefect-serverにAPIヘルスチェックを付け、servicesとworkerは`service_healthy`を待ってから起動させています。ここでは紙幅の都合で省いたので、本番で使う場合は公式ページの全文に合わせてください。旧来の解説には単一コンテナで`PREFECT_API_DATABASE_CONNECTION_URL`を渡す例も残っていますが、現行の手順は`PREFECT_SERVER_`で始まる設定名でAPIと裏方のサービスを分けて動かす形です。`docker compose up -d`で起動したら、ブラウザで`http://localhost:4200`を開いて確認します。 Docker Compose自体の書き方（サービス定義やボリューム管理）に不安があれば、[docker-composeで複数コンテナを一括管理する仕組み](https://www.issoh.co.jp/tech/details/13282/)を先に押さえておくと、この構成の意味が理解しやすくなります。 ### Prefect Cloudを使う場合のOSSとの違いと無料Hobbyプランの範囲 サーバー運用を自前で抱えたくない場合はPrefect Cloudを使います。CLIからログインしてワークスペースに接続すれば、フローの実行結果が自動でCloud側に集約されます。 ``` prefect cloud login ``` OSSとCloudでフローのコードは同一で、違いは「オーケストレーション面（履歴保存・イベント基盤・権限管理・SLA監視）を誰が運用するか」です。[Prefect Cloudの料金ページ](https://www.prefect.io/pricing)を2026年10月1日に確認した時点では、無料のHobbyプランは2ユーザー・最大5デプロイメント・実行履歴の保持7日・Prefect Serverlessの実行枠が月500分という内容でした。その上のStarterは月額100ドルで3ユーザー・最大20デプロイメントです。料金は「実行回数ではなく席数とワークスペース数で決まる」と明記されており、Taskを細かく分けても課金が増えない点はOSSの自前運用と比べる際の材料になります。上限や価格は改定されるため、採用前に最新のプランを確認してください。 ## FlowとTaskの最小実装｜デコレータ2つでPythonの関数を動かす Prefectの学習コストが低い理由は、通常のPython関数にデコレータを足すだけでワークフロー化できる点にあります。次はTaskを1つ定義し、Flowから呼び出す最小例です。 ``` from prefect import flow, task @task def add(x: int, y: int) -> int: return x + y @flow(log_prints=True) def my_flow(): total = add(3, 5) print(f"3 + 5 = {total}") if __name__ == "__main__": my_flow() ``` 実行はスクリプトをそのまま走らせるだけです。 ``` python flow.py ``` 2系の解説記事に出てくる`prefect run`コマンドは3系では使いません。開発中は`python flow.py`で直接実行し、スケジュールやAPI経由の実行が必要になった段階で次章のデプロイに進む、という流れになります。`@flow(log_prints=True)`を付けると`print`出力がそのままフローのログとしてUIに残ります。 複数のTaskを並べて呼べば、それがそのまま依存関係になります。たとえば「APIから取得→整形→保存」の3段なら、前のTaskの戻り値を次のTaskの引数に渡すだけです。 ``` from prefect import flow, task @task(retries=2, retry_delay_seconds=5) def extract() -> list[dict]: return [{"id": 1, "amount": 1200}, {"id": 2, "amount": 800}] @task def transform(rows: list[dict]) -> int: return sum(r["amount"] for r in rows) @task def load(total: int) -> None: print(f"total={total}") @flow(log_prints=True) def etl(): load(transform(extract())) if __name__ == "__main__": etl() ``` Airflowのように依存関係を別途宣言する必要はなく、Pythonの呼び出し順と引数の受け渡しから実行順が決まります。ループの回数や分岐が実行時に変わる処理も、通常のPythonの`for`や`if`で書けるのがPrefectの書き味です。 ## デプロイとWork Pool・Workerによる実行｜serveとdeployの使い分け スケジュール実行やAPIからのトリガー実行をするには、Flowを「デプロイ」して常時受け付けられる状態にします。3系での基本パターンは2通りです。 手軽なのは`.serve()`で、指定したFlowを常駐プロセスとして待機させ、スケジュールやUIからの実行を受け付けます。 ``` if __name__ == "__main__": my_flow.serve(name="my-first-deploy", cron="0 9 * * *") ``` 本番でインフラを分けたい場合は、[Work Pool](https://docs.prefect.io/v3/concepts/work-pools)とWorkerを使います。Work Poolは「どこで実行するか」の窓口、WorkerはそのPoolを監視して実際にジョブを起動するプロセスです。 ``` prefect work-pool create my-pool --type process prefect worker start --pool my-pool ``` あとはFlowを`flow.deploy()`または`prefect deploy`で対象のWork Poolに紐付けて登録すれば、スケジュールやAPI実行のたびにWorkerがジョブを起動します。CLIで登録して手動で1回走らせるなら次の形です。 ``` prefect deploy ./flow.py:my_flow --name my-deploy --pool my-pool prefect deployment run "my-flow/my-deploy" ``` デプロイ名は「フロー名/デプロイ名」で指定し、フロー名は関数名のアンダースコアがハイフンに置き換わったものになります。ローカル検証は`process`タイプ、本番はDockerやKubernetesなどのPoolタイプ、と実行基盤に合わせて選び分けます。`.serve()`は常駐プロセスが1つで済む反面、そのプロセスが落ちると実行も止まるため、複数マシンに処理を散らしたい段階でWork Poolへ移すのが自然な順序です。 ## スケジューリングと自動化（Automation）｜Cron・Interval・失敗通知 定期実行は、デプロイにスケジュールを付けるだけで有効になります。[公式のスケジュール解説](https://docs.prefect.io/v3/concepts/schedules)のとおりCronとIntervalなどの方式があり、`.serve()`や`prefect deploy`の引数、またはUIから設定できます。 ``` # 毎日9時に実行（Cron） my_flow.serve(name="daily", cron="0 9 * * *") # 1時間ごとに実行（Interval） my_flow.serve(name="hourly", interval=3600) ``` 時刻ベースの定期実行に加え、3系ではイベント駆動の[Automation](https://docs.prefect.io/v3/concepts/automations)がOSSで使えます。「あるフローが失敗したらSlackに通知する」「特定のイベントを受けたら別フローを起動する」といったルールは、UIまたはコードから定義することが可能です。失敗時のリトライはTask/Flowの引数で指定します。 ``` @task(retries=3, retry_delay_seconds=10) def call_api(): ... ``` この`retries`とAutomationの通知を組み合わせると、「3回リトライしても失敗したら通知」という運用が定型化できます。通知チャネル（メール・Slack等）はブロック（Block）として登録して再利用します。 ## キャッシュとトランザクションによる冪等性の確保と、結果永続化の前提 同じ入力に対する再計算を避けたい、あるいは途中失敗した処理をきれいにやり直したい——こうした冪等性の要求に、3系はトランザクションとキャッシュポリシーで応えます。パイプライン全体で冪等性をどう設計するかは[データパイプラインとは？冪等性から考える設計判断](https://www.issoh.co.jp/tech/details/15848/)で整理しているので、ここではPrefect側の書き方に絞ります。まずTaskのキャッシュを制御する設定項目は`cache_policy`です。 ``` from prefect import task from prefect.cache_policies import INPUTS @task(cache_policy=INPUTS) def transform(data): ... ``` `INPUTS`を指定すると、同じ引数で呼ばれたTaskは前回結果を再利用してスキップします。[公式のCaching解説](https://docs.prefect.io/v3/concepts/caching)によると、既定の`DEFAULT`ポリシーは「Taskの入力・コード定義・実行中のフローランID」からキーを作ります。フローランIDが含まれるため、既定のままでは別の実行回をまたいだ再利用は起きません。実行回をまたいで結果を使い回したいときに`INPUTS`を選ぶ、という関係です。 同じページには、キャッシュは結果の永続化が前提で、その永続化は既定でオフだという注意もあります。すべてのTaskで永続化を有効にする場合は次の設定を入れます。 ``` prefect config set PREFECT_RESULTS_PERSIST_BY_DEFAULT=true ``` さらに複数Taskをまとめて「全部成功したら確定、途中で失敗したら巻き戻す」制御をしたい場合はトランザクションを使います。 ``` from prefect import flow from prefect.transactions import transaction @flow def pipeline(): with transaction(): write_file() # 失敗時はon_rollbackで削除 load_db() ``` トランザクション内のTaskに`on_rollback`フックを定義しておくと、後段のTaskがこけた時に前段の副作用（書き込んだファイルの削除など）を自動で取り消せます。[公式のトランザクション解説](https://docs.prefect.io/v3/advanced/transactions)にもある通り、このフックは`on_failure`とは別物で、紐付けたTask自身が成功していても、同じトランザクション内の後続が失敗すれば呼ばれます。 ``` import os from prefect import task @task def write_file(contents: str): with open("side-effect.txt", "w") as f: f.write(contents) @write_file.on_rollback def del_file(transaction): os.unlink("side-effect.txt") ``` バッチ処理の「途中まで書き込まれて中途半端な状態が残る」問題を、コードの構造として防げるのが3系の強みです。 ## 実行基盤との連携（Docker・Kubernetes・ECS・Cloud Run・GCP） 本番ではフローをコンテナやマネージド基盤で動かします。実行先はWork Poolのタイプで切り替えるだけで、Flowのコードは変えません。代表的なタイプは次の通りです。 | Work Poolタイプ | 実行先 | 向いている用途 | | ------------ | ---------------- | ------------- | | process | ローカルプロセス | 開発・検証 | | docker | Dockerコンテナ | 環境固定・単一ホスト | | kubernetes | K8s Job | 大規模・自動スケール | | ecs | AWS ECS/Fargate | サーバーレスにAWSで実行 | | cloud-run | Google Cloud Run | サーバーレスにGCPで実行 | KubernetesでのJob実行は、クラスタ側の権限やイメージ管理を含めた設計が要ります。前提となるK8sの挙動は[Kubernetes 1.34の新機能・変更点の解説](https://www.issoh.co.jp/tech/details/8967/)を、AWSでのコンテナ実行は[AWS ECSの仕組みと起動タイプ](https://www.issoh.co.jp/tech/details/3870/)および[AWS Fargateの料金とEC2との違い](https://www.issoh.co.jp/tech/details/3304/)をあわせて確認すると、どのWork Poolを選ぶかの判断が付きます。GCP連携は`prefect-gcp`、AWS連携は`prefect-aws`のように、統合パッケージを追加インストールして使います（2026年10月時点のPyPIでは prefect-aws が0.7系、prefect-gcp が0.6系）。 ``` pip install prefect-gcp # Cloud Run・Vertex AI 連携 pip install prefect-aws # ECS・S3 連携 ``` 機械学習の学習ジョブや推論バッチをPrefectで回す構成は、実験管理やモデル監視のツールと組み合わせて使うのが一般的です。周辺ツールの組み合わせ方は[MLOpsツール比較｜実験管理・パイプライン・監視の主要スタック](https://www.issoh.co.jp/tech/details/15341/)で整理しています。 ## PrefectとAirflow・Dagsterの違いと、採用すべきでない場面の見分け方 「結局どれを使うか」で迷うなら、書き味と運用モデルで割り切るのが早いです。主要ツールの性格を並べます。 | ツール | 書き方 | 強み | | -------- | --------------- | ------------ | | Prefect | 通常のPython＋デコレータ | 動的・低学習コスト | | Airflow | DAGを明示定義 | 実績・エコシステム | | Dagster | アセット（データ資産）中心 | データ品質・リネージ管理 | | Temporal | 言語横断のワークフローSDK | 長時間・分散の状態保持 | Prefectを積極的に選ぶのは、Pythonチームが動的なパイプライン（実行時に分岐やループ数が変わる処理）を素早く書きたいときです。OSSのままイベント駆動の自動化まで組める点も、3系での強みになりました。逆に、次のような場面ではPrefectを第一候補にしない方が無難です。 - **既にAirflowで安定運用している静的な大規模バッチ**：移行コストに見合うだけの利点が出にくい。まずAirflowのまま運用を改善する。[Apache Airflowとは（仕組み・使い方とAirflow 3の新機能）](https://www.issoh.co.jp/tech/details/1441/)で自社の運用と照らして判断する。マネージドで回したい場合はGCPなら[Cloud Composer](https://www.issoh.co.jp/tech/details/15557/)、AWSなら[Amazon MWAA](https://www.issoh.co.jp/tech/details/15780/)という選択肢もある。 - **数時間〜数日にわたる長時間・分散のステートフル処理**：耐久性の高いワークフロー実行が本質なら[Temporal Workflowの仕組みと比較](https://www.issoh.co.jp/tech/details/9090/)が適する領域。 - **データ資産のリネージ・品質管理が主目的**：アセット中心のDagsterの方がモデルに合う。仕組みと採用判断は[Dagsterとは？アセット指向の仕組みと実装手順](https://www.issoh.co.jp/tech/details/15948/)を参照。 Prefectは「オーケストレーションを重装備で導入する」より「今あるPythonコードに信頼性を後付けする」方向に強いツールだ、と位置づけると選定を誤りません。 ### AirflowからPrefectへ移すときに書き換えが要る3つの箇所 Airflowから乗り換える判断をした場合、公式の[Migrate from Airflow](https://docs.prefect.io/v3/how-to-guides/migrate/airflow)が対応関係を示しています。実務で書き換えが要るのは主に3か所です。1つ目はDAGとOperatorで、`PythonOperator`で包んでいた関数はそのまま`@task`にし、DAG定義は`@flow`関数の中の呼び出し順に置き換えます。2つ目はXComで、Task間のデータ受け渡しは戻り値と引数で済むため、XCom用のコードは削除してよい部分です。3つ目はスケジュールと接続情報で、DAGの`schedule`はデプロイのスケジュールへ、Airflow Connectionsは`prefect-aws`などのBlockへ移します。全DAGを一度に移さず、新規のパイプラインからPrefectで書き、既存DAGは更新が入るタイミングで1本ずつ移すのが安全です。 ## Prefectを採用する条件と見送る条件を受託開発の現場目線で整理する ここまでの機能を踏まえ、導入相談を受けたときにどう判断するかを言い切っておきます。Prefectを採用してよいのは、次の3条件がそろうときです。 - **処理の主言語がPythonで、今後もPythonで書く**：Prefectの利点はPythonの関数をそのまま使える点にあり、JavaやGoの処理が主体なら恩恵が薄い。 - **処理が3ステップ以上に分かれ、失敗時の再実行判断を人がしている**：cronと手作業の再実行で回っている状態が、Prefectで最も改善しやすい。 - **サーバーかCloudのどちらかを運用する体制がある**：OSSならPostgreSQLとRedisを含む5コンテナ、CloudならHobbyの5デプロイメント上限を超えた時点の費用、のどちらかを引き受ける人がいる。 反対に、定期実行するスクリプトが1〜2本でステップ間の依存がない場合は、cronやクラウドのスケジューラで足ります。数十本のDAGがAirflowで安定稼働している組織も、移行の手間に見合う利点が出にくいため見送りが妥当です。業務システムの承認フローのような「人の判断を順に回す」ワークフローも、Prefectの守備範囲ではありません。 判断に迷う場合は、まず1本のパイプラインをOSSの`prefect server start`とローカルWorkerで2週間ほど回し、失敗時の再実行と通知が運用者の手間をどれだけ減らしたかで決めるのが確実です。一創では、Prefectを含むワークフロー基盤の選定からPostgreSQL・Redisを含む環境構築、既存バッチの移行までを[データ分析基盤構築・MLOps構築支援](https://www.issoh.co.jp/service/ai/data-platform/)として請け負っています。 ## よくある質問 ### Prefectとは何ですか？一言でいうと何のツールですか？ Prefectとは、Pythonで書いたデータ処理やバッチを、実行順・リトライ・スケジュール・履歴の可視化まで含めて管理するワークフローオーケストレーションツールです。関数に`@task`と`@flow`を付けるだけで使い始められ、OSS本体はApache 2.0で無料、マネージド版のPrefect Cloudも用意されています。英単語の prefect（監督生・長官）とは別物で、ツールを探す場合は「prefect python」「prefect オーケストレーション」で絞ると精度が上がります。 ### Prefect Cloudは無料で使えますか？ 無料での利用が可能です。2026年10月1日時点の公式料金ページでは、無料のHobbyプランに2ユーザー・最大5デプロイメント・実行履歴7日・Serverlessの実行枠月500分が含まれます。OSS本体（Apache 2.0）はサーバーごと無料で自前運用でき、Cloudは履歴保存・イベント基盤・権限管理などのオーケストレーション面をマネージドで肩代わりします。上限や有料プランの条件は改定されるため、採用前に公式の最新プランを確認してください。 ### Prefect 2から3への移行は必要ですか？互換性は？ 新機能や性能改善は3系が対象で、2系のまま使い続ける利点はほとんどありません。3系ではエージェントが廃止されWorkerへ移行が必要、キャッシュがトランザクション方式に、型検証がPydantic v2に変わっています。既存の2系フロー自体はデコレータの書き方が近く移行しやすい一方、実行基盤（agentからworkerへ）とキャッシュ設定は書き換えが要ります。 ### PrefectのGUI（UI）はどこで確認しますか？ ローカルでは`prefect server start`を実行し`http://127.0.0.1:4200`を開くとUIが表示されます。フローの実行履歴・状態・ログ、Work PoolやWorkerの稼働状況、スケジュールの管理をこの画面で行います。3.8系からはセルフホストでも新しいV2 UIが既定です。Prefect Cloudを使う場合はCloudのワークスペース画面が同じ役割を担います。 ### AirflowとPrefectはどちらを選ぶべきですか？ 静的なDAGを明示定義して大規模バッチを堅く運用したいならAirflow、通常のPythonをそのまま動的にワークフロー化して素早く回したいならPrefectが向きます。既にAirflowで安定している場合は無理に乗り換えず、新規のPythonパイプラインからPrefectを試すのが現実的です。 ## 関連記事 - [Apache Airflowとは？仕組み・使い方とAirflow 3の新機能を解説](https://www.issoh.co.jp/tech/details/1441/) - [Dagsterとは？アセット指向の仕組み・dg CLIでの実装手順とAirflow移行を解説](https://www.issoh.co.jp/tech/details/15948/) - [Temporal Workflowとは？コードで書く分散ワークフローエンジンの仕組みと比較](https://www.issoh.co.jp/tech/details/9090/) - [データパイプラインとは？種類・構成要素と冪等性から考える設計判断を解説](https://www.issoh.co.jp/tech/details/15848/) - [Celery（Python）とは：分散タスクキューの仕組みとブローカー選定・冪等性設計を解説](https://www.issoh.co.jp/tech/details/17293/) - [docker-composeとは？複数コンテナをymlで定義し一括管理する仕組みを解説](https://www.issoh.co.jp/tech/details/13282/) - [AWS ECSとは？コンテナの仕組み・起動タイプ・料金・EKSとの違い](https://www.issoh.co.jp/tech/details/3870/) - [Kubernetes 1.34の新機能・変更点とEOL｜DRA GA・再起動ルールを解説](https://www.issoh.co.jp/tech/details/8967/) --- 出典: [Prefectとは？Pythonワークフロー管理の使い方と3系の始め方【2026年版】]()（株式会社一創）