--- title: "Apache Airflowとは？Jenkinsとの違い・DAGの書き方と3.3の導入手順" url: "https://www.issoh.co.jp/tech/details/1441/" published: 2023-09-25 updated: 2026-10-19 categories: ["データ分析・BI"] publisher: "株式会社一創" --- # Apache Airflowとは？Jenkinsとの違い・DAGの書き方と3.3の導入手順 Apache Airflowは、データ処理の手順をPythonのコード（DAG）で書き、決まった時刻や前段の完了をきっかけに実行し、失敗したタスクのリトライと実行履歴の確認までを1つの仕組みで担うオープンソースのワークフローオーケストレーションツールです。現行版は2026年9月17日公開の3.3.2で、2系は2026年4月22日にサポートが終了しました。この記事では、部品の役割、公式イメージ apache/airflow:3.3.2 で実際に動かしたDAG、pipとDocker Composeでの導入、2系から消えた機能、Jenkinsとの使い分けを順に説明します。 ## まとめ：Apache Airflowの要点 - **何をするツールか**：処理の順序と依存関係をPythonで定義し、スケジュール実行・リトライ・途中からの再実行・監視をまとめて引き受ける。動かす対象は「データ処理の手順」。 - **現行版**：**3.3.2**（2026年9月17日）。対応Pythonは3.10〜3.14。2系は2026年4月22日にEOLで、これから使うなら3系一択。 - **部品**：DAG（ワークフロー）、Task（処理の単位）、Scheduler（実行の判断）、Executor（実行場所）、XCom（タスク間の小さな値の受け渡し）。既定のExecutorはLocalExecutor。 - **導入**：pipならconstraintsファイルの指定が必須級。手元で全コンポーネントを試すならDocker Composeが早く、Dockerには4GB以上のメモリを割り当てる。 - **2系の解説に注意**：SequentialExecutor、SubDAG、SLA、`execution_date` は3系で削除済み。これらを前提にした手順はそのままでは動かない。 - **Jenkinsとの違い**：Jenkinsはコードのビルド・テスト・デプロイ（CI/CD）、Airflowはデータの抽出・変換・書き込みの定期実行。両方を役割で分けて併用できる。 ## Apache Airflowの役割とcronとの違い Airflowは2014年10月にAirbnbのMaxime Beauchemin氏が始めたプロジェクトで、2016年3月にApache Software Foundationのインキュベーターへ入り、2019年1月にトップレベルプロジェクトになりました（[公式のProject沿革](https://airflow.apache.org/docs/apache-airflow/3.3.2/project.html)）。ライセンスはApache License 2.0で、商用利用も改変も無償です。 「定期実行ならcronで足りるのでは」という疑問への答えは、処理同士の関係を扱えるかどうかです。cronは時刻になったらコマンドを1本起動するだけで、「AとBが両方終わってからCを動かす」「Cだけ失敗したのでCから再実行する」「先週火曜の分だけやり直す」を表現できません。Airflowはこの依存関係・リトライ・再実行・実行履歴の画面をまとめて持っています。処理が2〜3本で依存も無いならcronのままで十分です。Airflowはメタデータ用のDBとScheduler・API serverを常駐させるため、その運用に見合うのは依存のある処理が増えてからです。 よく使われるのは、複数のデータソースから抽出してDWHへ書き込むETL／ELT、データ取得から再学習・評価までを回す機械学習パイプライン、BI用の集計テーブルの夜間再構築です。オーケストレーション以外の層も含めた設計は[データパイプラインの種類・構成要素と冪等性から考える設計判断](/tech/details/15848/)で整理しています。 ## Airflowを構成する部品：DAG・Task・Scheduler・Executor・XCom ### DAGとTask・Operator DAG（Directed Acyclic Graph、有向非巡回グラフ）はワークフロー1本分の定義です。「有向」は処理に順序があること、「非巡回」は一度通ったタスクへ戻るループを作れないことを指します。DAGの中の1つ1つの処理がTaskで、Taskの型がOperatorです。シェルを実行するBashOperator、Python関数を実行するPythonOperator、外部の状態が整うまで待つSensorなどがあります。Airflow 3ではBashOperatorやPythonOperatorが本体から `apache-airflow-providers-standard` パッケージへ移りました。 ### Airflow 3のコンポーネント構成 Airflow 3は役割ごとに別プロセスで動きます。公式の [docker-compose.yaml（3.3.2）](https://airflow.apache.org/docs/apache-airflow/3.3.2/docker-compose.yaml) に並ぶサービスがそのまま構成図になります。 - **API server**：Web画面とREST API（`/api/v2`）、タスクがメタデータにアクセスするためのExecution APIを提供する。2系のwebserverに当たる。 - **Scheduler**：DAGのスケジュールと依存関係を見て、いま実行すべきタスクをExecutorへ渡す。 - **Dag processor**：DAGファイルを読み込んで解析する。3系では開発環境でも別プロセスとして起動する必要がある（`airflow dag-processor`）。 - **Triggerer**：deferrable（遅延可能）なOperator・Sensorの「待ち」を非同期にまとめて処理し、ワーカーの枠を空ける。通常のSensorは待っている間もワーカーの枠を1つ占有する。 - **メタデータDB**：実行履歴と状態の保存先。本番はPostgreSQL 14〜18かMySQL 8.0／8.4／Innovationで、SQLiteは開発用（[公式の前提条件](https://airflow.apache.org/docs/apache-airflow/3.3.2/installation/prerequisites.html)）。MariaDBは非対応。 ### Executorの選び方 Executorは「タスクをどこで動かすか」を決めます。[公式のExecutor解説](https://airflow.apache.org/docs/apache-airflow/3.3.2/core-concepts/executor/index.html)によると既定はLocalExecutorで、それ以外は各プロバイダパッケージから入れます。公式イメージ apache/airflow:3.3.2 には celery・cncf-kubernetes・amazon のプロバイダが同梱されており、edge3は入っていませんでした。 | Executor | 配布元 | タスクの実行場所 | 向く場面 | | ------------------------- | -------------------- | --------------- | ----------- | | LocalExecutor | 本体（既定） | Schedulerと同じマシン | 検証・小規模の本番 | | CeleryExecutor | celeryプロバイダ | Celeryワーカー群 | 常時多数のタスクを流す | | KubernetesExecutor | cncf-kubernetesプロバイダ | タスクごとのPod | 依存ライブラリの分離 | | EdgeExecutor | edge3プロバイダ | HTTPでつなぐ遠隔ワーカー | 別拠点・エッジで実行 | | BatchExecutor／EcsExecutor | amazonプロバイダ | AWS Batch／ECS | AWSの計算資源で実行 | 設定は `[core] executor` で、カンマ区切りで複数並べるとリストの先頭が既定になり、タスクやDAGごとに実行先を振り分けられます。2系にあったCeleryKubernetesExecutorとLocalKubernetesExecutorは、この複数Executor設定に置き換えられ、3.0.0以降は使えなくなりました。最初はLocalExecutorで始め、1台でタスクが詰まり始めてからCeleryかKubernetesへ移すのが無駄のない順番です。 ### XComで渡してよいもの XCom（Cross-Communication）は前段タスクの戻り値を後段へ渡す仕組みで、値はメタデータDBに保存されます。渡すのは件数・ファイルパス・テーブル名のような小さな値に限り、DataFrameやファイルの中身はS3やDWHに置いて、その場所だけをXComで渡します。公式も、XComは少量のデータ向けでDataFrameのような大きな値の受け渡しに使わないよう明記しています（[公式のXCom解説](https://airflow.apache.org/docs/apache-airflow/3.3.2/core-concepts/xcoms.html)）。 ## DAGを書いて動かす：TaskFlow APIとdags test DAGの書き方は、Python関数に `@task` を付けるTaskFlow APIと、Operatorをインスタンス化して `>>` で依存をつなぐ従来の書き方の2つで、1本のDAGに混在させられます。次のコードは両方を使った例で、Airflow 3の書き方どおり `airflow.sdk` からインポートしています。 ``` from datetime import datetime, timedelta from airflow.providers.standard.operators.bash import BashOperator from airflow.sdk import dag, task @dag( schedule="@daily", start_date=datetime(2026, 10, 1), catchup=False, default_args={"retries": 2, "retry_delay": timedelta(minutes=5)}, tags=["example"], ) def etl_pipeline(): @task def extract() -> dict: return {"records": 100} @task def transform(data: dict) -> int: return data["records"] * 2 @task def load(value: int) -> None: print(f"loaded: {value}") notify = BashOperator(task_id="notify", bash_command="echo done") load(transform(extract())) >> notify etl_pipeline() ``` `extract` の戻り値がXCom経由で `transform` へ、その戻り値が `load` へ渡ります。関数の呼び出しを入れ子にするだけで依存関係が組み上がり、最後の `>> notify` で従来型のOperatorを後ろにつないでいます。`default_args` の `retries` は全タスクに効き、失敗したタスクだけが5分後に最大2回やり直されます。 スケジューラを立てずに1回だけ通しで実行するには `airflow dags test` を使います。2026年10月11日に公式イメージ apache/airflow:3.3.2（Python 3.13.15）でこのDAGを実行したところ、4タスクが依存の順に成功しました。 ``` airflow db migrate airflow dags test etl_pipeline 2026-10-10 # 出力（抜粋） [DAG TEST] running task Pushing xcom ... task_id='extract' [DAG TEST] running task [DAG TEST] running task loaded: 200 Running command: ['/usr/bin/bash', '-c', 'echo done'] DagRun Finished: dag_id=etl_pipeline, ... state=success ``` `catchup=False` は、start\_dateから今日までの未実行分をまとめて走らせない指定です。Airflow 3では `catchup` の既定値自体がFalseに変わりましたが、既定値は設定の `[scheduler] catchup_by_default` で環境ごとに変えられるため、DAG側で明示しておくほうが安全です。また、2系の書き方 `from airflow.operators.bash import BashOperator` は3.3.2でもまだ動き、`DeprecatedImportWarning` を出すだけでした。警告が出ているうちに書き換えておくべき箇所です。 ## Airflowをインストールする：pip＋constraintsとDocker Compose ### pip＋constraintsでの導入とairflow standaloneの起動 Airflowは依存パッケージが多く、素の `pip install apache-airflow` では依存の解決結果が環境ごとにずれます。[公式のQuick Start](https://airflow.apache.org/docs/apache-airflow/3.3.2/start.html)は、版を固定したconstraintsファイルを指定する入れ方を案内しています。 ``` python3.12 -m venv .venv source .venv/bin/activate AIRFLOW_VERSION=3.3.2 PYTHON_VERSION="$(python -c 'import sys; print(f"{sys.version_info.major}.{sys.version_info.minor}")')" CONSTRAINT_URL="https://raw.githubusercontent.com/apache/airflow/constraints-${AIRFLOW_VERSION}/constraints-${PYTHON_VERSION}.txt" pip install "apache-airflow==${AIRFLOW_VERSION}" --constraint "${CONSTRAINT_URL}" airflow standalone ``` `airflow standalone` はメタデータDBの初期化、ユーザー作成、全コンポーネントの起動を1コマンドで行い、画面は `http://localhost:8080` で開きます。3系では管理者パスワードが端末に出ないことがあり、その場合は `$AIRFLOW_HOME/simple_auth_manager_passwords.json.generated`（既定は `~/airflow`）に書かれています。 注意点がもう1つあります。2026年10月11日にIntel（x86\_64）のMacで `uv pip install "apache-airflow==3.3.2"` をconstraints-3.12付きで実行したところ、依存の `libcst` 1.9.0 のビルドでRustコンパイラを要求されて止まりました。PyPIにある同版のmacOS向けホイールがarm64用だけのためです。Intel Macでは次のDocker Composeか公式イメージを使うほうが早く進みます。 ### Docker Composeでの全コンポーネント起動 CeleryExecutor・PostgreSQL 16・Redisを含む全コンポーネントの構成を手元で試すなら、[公式のDocker Compose手順](https://airflow.apache.org/docs/apache-airflow/3.3.2/howto/docker-compose/index.html)が最短です。 ``` mkdir airflow-local && cd airflow-local curl -LfO 'https://airflow.apache.org/docs/apache-airflow/3.3.2/docker-compose.yaml' mkdir -p ./dags ./logs ./plugins ./config echo -e "AIRFLOW_UID=$(id -u)" > .env docker compose up airflow-init docker compose up -d ``` 起動後は `http://localhost:8080` にユーザー名・パスワードとも `airflow` でログインできます。`dags` フォルダに置いたPythonファイルがDAGとして読み込まれます。公式はDockerに最低4GB、できれば8GBのメモリを割り当てるよう求めており、macOSのDocker既定値では足りずAPI serverが再起動を繰り返すことがあります。Docker Desktopの代わりにColimaを使う場合は、既定で共有されるのがホームディレクトリ配下だけなので、作業フォルダを `/tmp` に置くとコンテナから `dags` が空に見えます（設定は[ColimaでDocker Desktopを外す導入手順と設定の落とし穴](/tech/details/17842/)を参照）。なお公式はこのDocker Compose構成を学習・検証用とし、本番にはKubernetesと公式Helm Chartを勧めています。 ## Airflow 3で変わった点と2系からの移行 ### 3.0〜3.3で入った主な機能 Airflow 3.0は2025年4月22日に公開され、その後は3〜7か月の間隔でマイナー版が出ています。各版の内容は[公式リリースノート](https://airflow.apache.org/docs/apache-airflow/3.3.2/release%5Fnotes.html)から主要項目を拾いました。 | 版 | 公開日 | 主な追加 | | ----- | ---------- | --------------------------------------------------- | | 3.0.0 | 2025-04-22 | DAGバージョニング、新UI、Task Execution API、Asset | | 3.1.0 | 2025-09-25 | Human-in-the-Loop、Deadline Alerts、UIの多言語化 | | 3.2.0 | 2026-04-07 | Asset Partitioning、Multi-Team Deployments（実験的） | | 3.3.0 | 2026-07-06 | Task and Asset State Store、Pluggable Retry Policies | | 3.3.2 | 2026-09-17 | 現行のパッチ版 | 運用で効くのは3.0のDAGバージョニングです。DAGの構造の変更がメタデータDBに版として記録され、画面からどの実行がどの版で動いたかを遡れます。ただし実行開始時点のコードで最後まで走るのは、GitDagBundleのように版管理に対応したDAG bundleを使った場合だけです。既定のdagsフォルダ（LocalDagBundle）は非対応で、2系と同じく常にディスク上の最新コードで動きます（[公式のDAG bundles解説](https://airflow.apache.org/docs/apache-airflow/3.3.2/administration-and-deployment/dag-bundles.html)）。Task Execution APIはタスクとメタデータDBを切り離す仕組みで、EdgeExecutorや、3.3.0で加わったJava・Go向けのTask SDK（実験的）はこの上に載っています。2系のDatasetはAssetに改称され、「データが更新されたら下流のDAGを動かす」というデータ駆動のスケジュールが書けます。メッセージ基盤のイベントを起点にする構成なら[Kafka 4系のKRaft構成](/tech/details/7563/)とあわせて設計します。 ### 2系のDAGで動かなくなる箇所 [公式のAirflow 3移行ガイド](https://airflow.apache.org/docs/apache-airflow/3.3.2/installation/upgrading%5Fto%5Fairflow3.html)が挙げる削除項目のうち、既存DAGで当たりやすいものは次のとおりです。 - **SubDAG**：削除。TaskGroupかAssetで書き直す。 - **SLA**：削除。3.1で入ったDeadline Alerts（3.3.2時点でも実験的機能）へ移す。 - **コンテキスト変数**：`execution_date`、`next_ds`、`prev_ds`、`yesterday_ds` などが無くなり、参照するとDAGがエラーになる。`logical_date` と `data_interval_start`／`data_interval_end` に置き換える。 - **メタデータDBへの直接アクセス**：タスクのコードからDBセッションやモデルを直接使えない。自作Operatorでやっていれば、REST APIかTask SDKへ書き換える。 - **REST API**：`/api/v1` は `/api/v2` に置き換え。外部から叩くスクリプトがあれば修正が要る。 - **CLIの `--subdir`**：DAG bundlesに置き換え。 DAGの洗い出しは手で読む前に、静的解析ツールRuffのAirflow用ルールで機械的にかけます（公式の移行ガイドはRuff 0.13.1以上を求めています）。AIR301・AIR302が3系で壊れる箇所、AIR311・AIR312が今は動くが書き換えを強く勧める箇所です。 ``` ruff check dags/ --select AIR301,AIR302 ruff check dags/ --select AIR301 --fix ``` 2系は2025年10月22日に限定保守へ入り、2026年4月22日にEOLとなりました（最終版2.11.2、[公式のバージョンライフサイクル](https://airflow.apache.org/docs/apache-airflow/3.3.2/installation/supported-versions.html)）。セキュリティ修正も出ないため、2系のまま本番を続ける理由はありません。いきなり全DAGを移すのではなく、Ruffでの洗い出し、検証環境での `airflow dags test`、DAG単位の段階移行の順に進めます。 ### 2系前提の解説を見分ける目印 Airflowの日本語の解説は2系時代のものが多く、検索上位にも残っています。次の語が「現役の機能」として出てきたら、その解説は2系時代のもので、3系ではそのまま動かないか、非推奨の書き方だと判断してください。 - Executorの選択肢に **SequentialExecutor** や **CeleryKubernetesExecutor** がある（どちらも3系では使えない。公式イメージ3.3.2で `airflow.executors.sequential_executor` をインポートすると `ModuleNotFoundError`） - Web画面を **`airflow webserver`** で起動している（3.3.2で実行すると `` Command `airflow webserver` has been removed. Please use `airflow api-server` `` で止まる） - テンプレートで **`{{ execution_date }}`** を使っている - `from airflow.models import DAG` や `from airflow.decorators import task` でインポートしている（3.3.2では `DeprecatedImportWarning` 付きで動くが、3系の正式な書き方は `airflow.sdk` で、将来の版で削除予定） - 対応Pythonに3.9以下が含まれている（3.3系は3.10〜3.14） ## AirflowとJenkinsの違い 「airflow vs jenkins」で迷うのは、どちらも「ジョブを順番に自動実行する」ように見えるからです。違いは動かす対象にあります。 | 観点 | Apache Airflow | Jenkins | | --------- | ------------------ | ------------------- | | 主な用途 | データの抽出・変換・書き込み | ビルド・テスト・デプロイ | | 主な起動のきっかけ | 時刻・前段DAG・データ更新 | Gitへのpush・プルリクエスト | | 定義の書き方 | Python（DAG） | Groovy（Jenkinsfile） | | 過去分の再実行 | 日付を指定して再実行できる | 日付の軸は無い（パラメータで自作） | | ライセンス | Apache License 2.0 | MIT License（本体） | Airflowには「2026年10月3日分のデータだけ集計し直す」というように、処理対象の日付（`logical_date`）を指定して過去分を再実行する考え方があります。Jenkinsのジョブは「今のコードをビルドする」ためのもので、この日付の軸を持ちません。逆に、プルリクエストごとにテストを走らせて結果をGitHubへ返すような処理をAirflowで組むのは筋が悪く、CI/CDツールの領分です。 判断は単純で、パイプラインが扱うのが「ソースコード」ならJenkins、「データ」ならAirflowです。データ基盤のチームでも、DAGファイル自体のテストと配置はJenkinsやGitHub Actionsで行い、配置されたDAGの定期実行をAirflowが担う、という分担にできます。Jenkins自体の機能と導入は[Jenkinsのできること・無料の範囲とインストール手順](/tech/details/3957/)、CI/CD側の考え方は[DevOpsとCI/CDの違い](/tech/details/13538/)、Kubernetes上でパイプラインを組むCI/CDなら[Tektonの仕組みと採用判断](/tech/details/15574/)で扱っています。 ## Prefect・Dagster・Temporalとの使い分けとマネージドサービス ### Prefect・Dagster・Temporalと比べる 同じデータオーケストレーションの領域で比べると、Airflowの強みはプロバイダの数と運用事例の厚さ、弱みは常駐コンポーネントが多く手元で試すまでが重いことです。 - **Prefect**（3系）：普通のPython関数にデコレータを付けるだけで動き、実行時に分岐が変わる動的なフローを書きやすい。小さく始めるならPrefectのほうが軽い（[Prefectの使い方と3系の始め方](/tech/details/10836/)）。 - **Dagster**：タスクではなく「作られるデータ（アセット）」を単位に設計し、テストとデータ品質の確認を組み込みやすい。プロジェクトの作成と実行は `dg` CLIで行う。Airflowからの段階移行の手順は[Dagsterのアセット指向の仕組みとAirflow移行](/tech/details/15948/)にまとめています。 - **Temporal**：注文処理や決済のように、アプリケーションの中で数日単位の状態を持つ処理を落とさずに完走させる用途。時刻起点のバッチではAirflowが、アプリ起点の長い処理ではTemporalが合う（[Temporal Workflowの仕組み](/tech/details/9090/)）。 Airflowを選ばないほうがよい場面もはっきりしています。公式はAirflowを「バッチワークフローのオーケストレーション基盤」と位置づけ、開始と終了がはっきりした定期処理に向くとしています（[公式ドキュメントの概要](https://airflow.apache.org/docs/apache-airflow/3.3.2/index.html)）。秒単位の遅延で処理し続けるストリーミングは守備範囲外です。AWSの中で完結する数ステップの処理なら、サーバーを持たない[AWS Step Functions](/tech/details/15429/)のほうが運用の手間が小さく済みます。機械学習の学習ジョブをKubernetes上で回すことが中心なら[Kubeflow Pipelines v2](/tech/details/10245/)も候補です。Kubernetesネイティブの代替としては、各ステップをPodとして走らせCRDでDAGを宣言する[Argo Workflows](https://www.issoh.co.jp/tech/details/18558/)があり、クラスターを既に運用しているチームではAirflowのSchedulerやExecutorを別に保守せずに済みます。 ### マネージドサービスで使う：MWAAとManaged Service for Apache Airflow Airflow本体は無料ですが、メタデータDB・Scheduler・ワーカーを自前で運用し、版を上げ続ける手間がかかります。この運用を任せるのがマネージドサービスで、利用料は環境の規模と稼働時間に応じてかかります。たとえばAmazon MWAAは東京リージョンの最小のmicro環境が1時間0.29ドルからで、常時稼働なら月約212ドル（730時間）になります（[AWS Price List APIの東京リージョン単価](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonMWAA/current/ap-northeast-1/index.json)）。 - **Amazon MWAA**：2026年9月1日にAirflow 3.3.1へ対応し、10月時点で3.3.1・3.2.1・3.0.6と2系の各版を選べる（[AWSの対応バージョン表](https://docs.aws.amazon.com/mwaa/latest/userguide/airflow-versions.html)）。環境クラスと料金の構造は[Amazon MWAAの料金と環境設計](/tech/details/15780/)で解説しています。 - **Google Cloud**：Cloud Composerは「Managed Service for Apache Airflow」に名称が変わった（[Google Cloudのドキュメント](https://docs.cloud.google.com/composer/docs)に「previously known as Cloud Composer」と明記）。仕組みと料金は[Cloud Composerの仕組み・料金と採用判断](/tech/details/15557/)を参照してください。 マネージド版は本家の最新版より少し遅れて対応します。3.3.2の新機能を前提にDAGを書く場合は、使うサービスの対応表に載っているかを先に確認します。Airflowを含むデータ基盤の設計から構築までを外部に任せたい場合は、[データ分析基盤構築・MLOps構築支援](/service/ai/data-platform/)でも相談を受けています。 ## よくある質問 ### Apache Airflowは無料で使えますか？ 本体はApache License 2.0のオープンソースで、商用でも無料です。費用がかかるのはサーバーとメタデータDBの運用費、またはAmazon MWAAやGoogle CloudのManaged Service for Apache Airflowを使う場合の利用料です。 ### Airflowの最新バージョンと対応Pythonは？ 2026年10月時点の最新は2026年9月17日公開の3.3.2で、対応Pythonは3.10〜3.14です。公式Dockerイメージ apache/airflow:3.3.2 の既定はPython 3.13でした。版の更新が速いため、導入時は[PyPIのapache-airflow](https://pypi.org/project/apache-airflow/)で確認してください。 ### Airflow 2と3の違いは何ですか？ 3系ではDAGバージョニング、ReactとFastAPIで作り直した画面、Task Execution API、Assetによるデータ駆動のスケジュールが入りました。一方でSubDAG、SLA、SequentialExecutor、`execution_date` などが削除されています。2系は2026年4月22日にEOLです。 ### AirflowはWindowsで動きますか？ Windowsには直接インストールできません。公式の前提条件ではPOSIX準拠のOSが対象で、WindowsではWSL2かLinuxコンテナ（Docker）で動かすよう案内されています。 ### airflow standaloneは本番で使えますか？ 使わないでください。公式のQuick Startは、本番ではstandaloneをやめてAPI server・Scheduler・Dag processor・Triggererを個別に起動するよう案内しています。メタデータDBもSQLiteではなく、PostgreSQLかMySQLに替えます。 ## 関連記事 - [Dagsterとは？アセット指向の仕組み・dg CLIでの実装手順とAirflow移行を解説【2026年9月版】](/tech/details/15948/) - [Prefectとは？Pythonワークフロー管理の使い方と3系の始め方【2026年版】](/tech/details/10836/) - [Amazon MWAAとは？Airflow 3.2対応とサーバーレス版の違い・料金・環境設計を実装者目線で解説](/tech/details/15780/) - [Cloud Composerとは？マネージドApache Airflowの仕組み・料金と採用判断を実装者目線で解説](/tech/details/15557/) - [データパイプラインとは？種類・構成要素と冪等性から考える設計判断を解説【2026年版】](/tech/details/15848/) --- 出典: [Apache Airflowとは？Jenkinsとの違い・DAGの書き方と3.3の導入手順]()（株式会社一創）