公開更新 自動化

Prefectとは？Pythonワークフロー管理の使い方と3系の始め方【2026年版】

Prefectとは？Pythonワークフロー管理の使い方と3系の始め方【2026年版】

Prefectは、Pythonの関数を@flow・@taskで囲むだけでデータパイプラインを構築・監視できるワークフローオーケストレーションツールです（英単語の prefect＝監督生・長官の意味ではなく、開発元 Prefect Technologies が提供するOSSツールを指します）。2024年9月にメジャー更新の3.0がGAとなり、2026年10月1日時点の最新は3.8系（PyPIの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リポジトリで公開）に加え、マネージド版のPrefect Cloudがあり、同じコードをそのまま自前サーバーでもCloudでも動かせます。特別なDSLやYAMLでDAGを宣言する必要はなく、通常のPython関数にデコレータを付けるだけで、リトライ・キャッシュ・ログ・可視化が後付けで効く仕組みです。

「オーケストレーション」という言葉自体は、複数の処理や部品を順序・依存関係・失敗時の扱いまで含めて指揮することを指します。用語の整理と自動化との違いはオーケストレーションとは？自動化との違いと種類にまとめているので、言葉の定義から入りたい場合は先に目を通すと理解が早くなります。

まず押さえるべき構成要素は次の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の新機能）との違いの章で扱います。

Prefectとcronやタスクキューの違いと、ワークフロー管理が要る場面

「定期実行ならcronで足りるのでは」という疑問は、Prefectを検討する人がまず抱くものです。cronは「決まった時刻にコマンドを起動する」ところまでしか面倒を見ません。処理が途中で落ちたとき、どのステップで止まったのか、再実行してよいのか、前段の結果をどこに残したのか、といった情報はcronの外で自作することになります。

タスクキュー（CeleryやRQなど）は、Webアプリから非同期処理を切り出してワーカーに配る仕組みです。1件ずつのジョブを速く確実に処理するのは得意な一方、「抽出が終わったら変換、変換が全部終わったら集計」のような処理間の依存関係や、実行履歴を横断して眺める画面は主目的ではありません。違いの詳細はCelery（Python）とは：分散タスクキューの仕組みで扱っています。

手段 守備範囲 足りなくなる場面
cron 時刻起動のみ 依存関係・再実行・履歴
タスクキュー ジョブの非同期配布 処理間の依存と可視化
Prefect 依存・再試行・履歴・通知 常駐基盤の運用が増える

目安として、処理が3ステップ以上に分かれ、失敗時に「どこから再開するか」を人が判断している状態なら、Prefectのようなワークフロー管理ツールを入れる価値が出てきます。ETL処理の全体像やツールの種類はETLとは？仕組み・ELTとの違い・ツール選定も参考になります。

Prefect 3系の主な特徴と2系からの変更点、3.8系で変わったこと

3.0は2.xからの単なる機能追加ではなく、実行エンジンとキャッシュ、実行基盤を作り替えたメジャー更新です。2系の記事やコードを見て学ぶ場合は、次の変更点を前提に読み替えてください。公式の移行手順はHow to upgrade to Prefect 3.0にまとまっています。

観点 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の手順に沿ってWorkerへの置き換えが必要です。あわせて、既定でコードがメインスレッド上を走るようになり、共有リソースやスレッドセーフでない処理での挙動が直感的になったうえ、実行エンジンの刷新で大規模フローの処理性能が改善しています。

3系の中でもマイナー版ごとに変更が入っています。Prefect 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にある通り、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手順は、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で複数コンテナを一括管理する仕組みを先に押さえておくと、この構成の意味が理解しやすくなります。

Prefect Cloudを使う場合のOSSとの違いと無料Hobbyプランの範囲

サーバー運用を自前で抱えたくない場合はPrefect Cloudを使います。CLIからログインしてワークスペースに接続すれば、フローの実行結果が自動でCloud側に集約されます。

prefect cloud login

OSSとCloudでフローのコードは同一で、違いは「オーケストレーション面（履歴保存・イベント基盤・権限管理・SLA監視）を誰が運用するか」です。Prefect Cloudの料金ページを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と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・失敗通知

定期実行は、デプロイにスケジュールを付けるだけで有効になります。公式のスケジュール解説のとおり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がOSSで使えます。「あるフローが失敗したらSlackに通知する」「特定のイベントを受けたら別フローを起動する」といったルールは、UIまたはコードから定義することが可能です。失敗時のリトライはTask/Flowの引数で指定します。

@task(retries=3, retry_delay_seconds=10)
def call_api():
    ...

このretriesとAutomationの通知を組み合わせると、「3回リトライしても失敗したら通知」という運用が定型化できます。通知チャネル（メール・Slack等）はブロック（Block）として登録して再利用します。

キャッシュとトランザクションによる冪等性の確保と、結果永続化の前提

同じ入力に対する再計算を避けたい、あるいは途中失敗した処理をきれいにやり直したい——こうした冪等性の要求に、3系はトランザクションとキャッシュポリシーで応えます。パイプライン全体で冪等性をどう設計するかはデータパイプラインとは？冪等性から考える設計判断で整理しているので、ここではPrefect側の書き方に絞ります。まずTaskのキャッシュを制御する設定項目はcache_policyです。

from prefect import task
from prefect.cache_policies import INPUTS

@task(cache_policy=INPUTS)
def transform(data):
    ...

INPUTSを指定すると、同じ引数で呼ばれたTaskは前回結果を再利用してスキップします。公式の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がこけた時に前段の副作用（書き込んだファイルの削除など）を自動で取り消せます。公式のトランザクション解説にもある通り、このフックは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の新機能・変更点の解説を、AWSでのコンテナ実行はAWS ECSの仕組みと起動タイプおよびAWS Fargateの料金とEC2との違いをあわせて確認すると、どの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ツール比較｜実験管理・パイプライン・監視の主要スタックで整理しています。

PrefectとAirflow・Dagsterの違いと、採用すべきでない場面の見分け方

「結局どれを使うか」で迷うなら、書き味と運用モデルで割り切るのが早いです。主要ツールの性格を並べます。

ツール 書き方 強み
Prefect 通常のPython＋デコレータ 動的・低学習コスト
Airflow DAGを明示定義 実績・エコシステム
Dagster アセット（データ資産）中心 データ品質・リネージ管理
Temporal 言語横断のワークフローSDK 長時間・分散の状態保持

Prefectを積極的に選ぶのは、Pythonチームが動的なパイプライン（実行時に分岐やループ数が変わる処理）を素早く書きたいときです。OSSのままイベント駆動の自動化まで組める点も、3系での強みになりました。逆に、次のような場面ではPrefectを第一候補にしない方が無難です。

Prefectは「オーケストレーションを重装備で導入する」より「今あるPythonコードに信頼性を後付けする」方向に強いツールだ、と位置づけると選定を誤りません。

AirflowからPrefectへ移すときに書き換えが要る3つの箇所

Airflowから乗り換える判断をした場合、公式のMigrate from 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構築支援として請け負っています。

よくある質問

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を試すのが現実的です。

関連記事

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

この記事に関連するサービス

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.07.09　テックブログ Muse Imageとは？Metaの画像生成AIの使い方・API料金（1枚0.01ドル）と日本での提供状況【2026年10月】
  2. 2026.10.21　テックブログ ユミルリンク不正アクセス第二報で延べ5,162万件：Cuenote FC利用企業と受信者の確認点
  3. 2026.10.23　テックブログ Renta!はいつ再開？不正アクセスでメールアドレス等が流出したおそれ・再開時のパスワード再設定と運営側の対応
  4. 2026.10.23　テックブログ Splunk 脆弱性CVE-2026-76299：影響版の確認と10.2.8などへの更新手順
  5. 2026.10.22　テックブログ Tomcatのバージョン一覧とサポート期限【2026年10月】最新版11.0.27、9.0系は2027年3月末終了・9.1系は2030年末まで

RELATED POSTS 関連記事

一覧へ戻る

目次