Nextflowとは？26.04の導入手順とパイプラインの書き方・resumeの仕組み

Nextflowは、ゲノム解析のように多数のコマンドを順番につなぎ、大量のサンプルに並列で流す処理を記述するためのワークフロー言語と実行エンジンです。本記事では2026年9月時点の安定版 26.04.6 を使い、インストールから最初のパイプライン、-resume による再実行、実行環境の切り替えまでを実行結果付きで説明します。後半では、26.04で既定になった新しい構文パーサーによる挙動の変化と、SnakemakeやAirflowとの使い分けも扱います。

なお、ここで扱うのはオープンソースのNextflow（nextflow-io/nextflow）です。「NextFlow」「next flow」を名乗る企業やデータ入力サービスとは関係ありません。

まとめ：Nextflowの要点と26.04で変わったこと

• Nextflowはprocess（処理単位）、channel（データの流れ）、workflow（つなぎ方）の3要素でパイプラインを書き、サンプルごとのタスクを自動で並列実行します。
• 動作要件はBash 3.2以上とJava 17〜26です。Linux・macOSではそのまま動き、Windowsで使う場合はWSLが必要です。導入は curl -s https://get.nextflow.io | bash が公式の推奨です。
• 安定版は毎年4月と10月、edge版は毎月出ます。版番号は「年.月.パッチ」です。2026年9月時点の最新安定版は 26.04.6 です。
• 26.04からstrict parser（v2構文パーサー）が既定になりました。params.flag = true の従来形式で定義した値にコマンドラインで --flag false を渡すと、文字列として扱われて真と評価されます（params ブロックで型を付ければ変換されます）。
• -resume は、入力やスクリプトから計算したハッシュが一致し、workディレクトリに出力が残っているタスクを再利用します。NFSでキャッシュが外れる場合は cache 'lenient' を指定します。
• コンテナとHPC・クラウドのexecutorが標準で使えるのが強みです。反対に、日次のETLを時刻起動で回す用途ならAirflowなどのほうが向いています。

Nextflowの仕組みとprocess・channel・workflowの役割

Nextflowは、Seqera社が中心となって開発しているApache-2.0ライセンスのOSSです。2017年にNature Biotechnology誌で論文として発表されており（doi:10.1038/nbt.3820）、nextflow -version を実行するとこのDOIが表示されます。スクリプトはJVM上で動き、文法はGroovyとは？JVMで動く簡潔なスクリプト言語の文法・用途・採用判断で解説しているGroovyをもとにしています。

パイプラインは次の3要素で組み立てます。

channelに値が届いた時点で、その値を受け取るprocessのタスクが1件生成されます。100サンプルのファイルを流せばタスクも100件になり、CPUやジョブスケジューラーの空きに応じて同時に実行されます。並列化のためにループやジョブ投入スクリプトを自分で書く必要はありません。これがシェルスクリプトやMakefileとの最大の違いです。

各タスクは work/ 以下にハッシュ名の専用ディレクトリを持ち、入力ファイルへのリンク、実行したスクリプト（.command.sh）、ログ、出力がそこにまとまります。失敗したタスクの原因は、このディレクトリを開けば追えます。

Nextflowのインストール手順（Java 17〜26）

公式のインストールページによると、NextflowにはBash 3.2以上と、Java 17以上26以下が必要です。Java 16以前のサポートは終了しています。26.04.6のランチャーは起動時にJavaの版を検査し、17〜26以外（Java 27を含む）では「Cannot find Java or it’s a wrong version」と表示して停止します。先に java -version で手元のJavaを確認し、足りなければSDKMAN!などでTemurinのLTS版を入れてください。

Linux・macOSへのインストール

公式が推奨しているのは、自己展開型のランチャーを取得する方法です。

java -version
curl -s https://get.nextflow.io | bash
chmod +x nextflow
mkdir -p $HOME/.local/bin
mv nextflow $HOME/.local/bin/
export PATH="$PATH:$HOME/.local/bin"
nextflow info

~/.local/bin はmacOSのzshなどでは既定のPATHに入っていません。PATHの設定を恒久化するには、同じ export 行を ~/.zshrc や ~/.bashrc に書きます。

初回の実行時には依存ライブラリがダウンロードされます。macOS上のOpenJDK 21.0.12.1で nextflow info を実行すると、次のように表示されました。

  Version: 26.04.6 build 12646
  Created: 09-07-2026 18:49 UTC (10-07-2026 03:49 JDT)
  System: Mac OS X 26.6.2
  Runtime: Groovy 4.0.31 on OpenJDK 64-Bit Server VM 21.0.12.1+1-LTS
  Encoding: UTF-8 (UTF-8)

更新は nextflow self-update で行います。版を固定したいときは、NXF_VER=26.04.6 nextflow run ... のように環境変数で指定します。

WindowsはWSL経由、Condaは非推奨

公式が動作対象としているのはLinuxやmacOSなどのPOSIX互換環境で、Windowsで使う場合はWSLが前提です。Windowsネイティブのインストーラーはありません。WSL上のUbuntuにJavaを入れ、上と同じ手順で導入します。

Biocondaからは conda create --name nf-env bioconda::nextflow で導入できます。ただし公式は、Conda経由だと版が古くなったり、依存関係やJavaの互換性で問題が起きたりする場合があるとして、自己展開型のランチャーを推奨しています。

最初のパイプライン：process・channel・workflowの書き方

テキストファイルの行数をサンプルごとに数え、1つの表にまとめるパイプラインです。data/sampleA.txt（2行）と data/sampleB.txt（1行）を用意して main.nf に保存します。26.04.6で nextflow lint を実行し、エラーと警告が出ないことを確認済みです。

params.input  = 'data/*.txt'
params.outdir = 'results'

process COUNT_LINES {
    tag "${sample}"
    cpus 1
    memory '1 GB'

    input:
    tuple val(sample), path(reads)

    output:
    tuple val(sample), path("${sample}.count.txt")

    script:
    """
    wc -l < ${reads} | tr -d ' ' > ${sample}.count.txt
    """
}

process SUMMARY {
    publishDir params.outdir, mode: 'copy'

    input:
    path counts

    output:
    path 'summary.tsv'

    script:
    """
    for f in ${counts}; do
      printf '%s\\t%s\\n' "\${f%.count.txt}" "\$(cat \$f)"
    done | sort > summary.tsv
    """
}

workflow {
    samples = channel.fromPath(params.input)
        .map { file -> tuple(file.baseName, file) }

    COUNT_LINES(samples)
    SUMMARY(COUNT_LINES.out.map { _sample, f -> f }.collect())
}

nextflow run main.nf の出力は次のとおりです（NXF_ANSI_LOG=false を指定し、1行ずつ表示される形式にしています）。

N E X T F L O W  ~  version 26.04.6
Launching `main.nf` [kickass_cantor] - revision: c7a8f37cc1
[f6/b8c95f] Submitted process > COUNT_LINES (sampleA)
[4e/c63e31] Submitted process > COUNT_LINES (sampleB)
[e1/5540f7] Submitted process > SUMMARY

$ cat results/summary.tsv
sampleA	2
sampleB	1

行頭の [f6/b8c95f] は、そのタスクのworkディレクトリ（work/f6/b8c95f...）を指します。ここに入る .command.sh には、${reads} などの変数を展開したあとの wc -l < sampleA.txt | tr -d ' ' > sampleA.count.txt が記録されます。process内でシェル変数を使うときは、Nextflowの変数と区別するため \$ とエスケープします。

channelの演算子：mapとcollect

channel.fromPath は、globに一致したファイルを1件ずつ流します。map は流れてくる値を1件ずつ変換する演算子で、上の例ではファイルを (サンプル名, ファイル) の組にしています。collect はchannelの値をすべて待って1つのリストにまとめるため、SUMMARYのタスクは1件だけ生成されます。

複数のchannelをサンプル名で突き合わせるときは join、ペアエンドのFASTQを組にするときは channel.fromFilePairs('*_{1,2}.fastq.gz') を使います。26.04の移行ガイドでは、いくつかの演算子が非推奨になったと案内されています。古いパイプラインを移すときは、演算子のリファレンスで非推奨の印を確認してください。

パラメータの上書きとstrict parserの型の扱い

params. で定義した値は、実行時に --名前 値 で上書きできます。

nextflow run main.nf -resume --input 'data/sampleA.txt' --outdir out2

注意が必要なのは真偽値です。26.04で既定になったstrict parserは、params.xxx = 値 の従来形式で定義したパラメータについては、コマンドラインから渡した値の型を自動で判定しません。公式ドキュメントにある次の例を26.04.6で実行すると、false を渡したのに true と表示されました。'false' という空でない文字列が、真と評価されるためです。

params.save_intermeds = true

workflow {
    println "save_intermeds = ${params.save_intermeds ? 'true' : 'false'}"
}

$ nextflow -q run main.nf --save_intermeds false
save_intermeds = true
$ NXF_SYNTAX_PARSER=v1 nextflow -q run main.nf --save_intermeds false
save_intermeds = false

対策として公式が示しているのは、既定値を文字列 'true' にして params.save_intermeds.toBoolean() で判定する方法と、params ブロックで Boolean の型注釈を付ける方法の2つです。25.10以前から使っているパイプラインで、真偽値のフラグを if (params.xxx) でそのまま判定している箇所は、26.04へ上げる前に洗い出してください。

-resumeとworkディレクトリの仕組み

-resume を付けると、前回の実行で完了したタスクを再利用します。デモのパイプラインをもう一度実行した結果は次のとおりで、3件とも Cached になり、コマンドは実行されませんでした。

$ nextflow run main.nf -resume
N E X T F L O W  ~  version 26.04.6
Launching `main.nf` [sick_allen] - revision: c7a8f37cc1
[4e/c63e31] Cached process > COUNT_LINES (sampleB)
[f6/b8c95f] Cached process > COUNT_LINES (sampleA)
[e1/5540f7] Cached process > SUMMARY

入力を sampleA だけに絞って再実行したときは、COUNT_LINES (sampleA) がキャッシュから使われ、入力が変わったSUMMARYだけが実行し直されました。

再利用されるかどうかは、タスクごとに計算されるハッシュで決まります。公式の説明によると、ハッシュが前回と一致し、かつworkディレクトリに出力が残っているタスクだけが再利用されます。キャッシュが外れる代表的な原因は次のとおりです。

• 入力ファイルのパス・最終更新時刻・サイズのいずれかが変わった（ファイルを触り直しただけでも再実行されます）
• NFSなどの共有ファイルシステムが返すタイムスタンプが一定しない（cache 'lenient' を指定すると、時刻を無視してパスとサイズだけで判定します）
• processが自分の入力ファイルを書き換えている（公式はアンチパターンとしており、この場合は再開できません）
• 起動ディレクトリの .nextflow/cache か work/ を消した、または別のディレクトリから起動した（キャッシュは起動ディレクトリ基準で保存されるため、両方を残す必要があります）

原因が分からないときは、nextflow -log run_1.log run main.nf -dump-hashes json と -resume 付きの実行とでハッシュの内訳を出力し、差分を比べます。work/ は放っておくと大きくなるので、不要になった実行の分は nextflow clean で消します。

nextflow.configとプロファイルでの実行環境の切り替え

CPU数・メモリ・実行時間の上限・リトライ回数や、どこでジョブを動かすかは、スクリプトに書かず nextflow.config にまとめます。

process {
    cpus   = 2
    memory = '4 GB'
    time   = '2h'
    errorStrategy = 'retry'
    maxRetries    = 2
    withName: 'SUMMARY' {
        cpus = 1
    }
}

profiles {
    slurm {
        process.executor = 'slurm'
        process.queue    = 'short'
    }
    docker {
        docker.enabled = true
    }
}

nextflow config -profile slurm を実行すると、プロファイルを適用したあとの最終的な設定を確認できます。この設定では executor = 'slurm' と queue = 'short' がprocessスコープに加わりました。本番のクラスタに投入する前に、キュー名やexecutorの綴り違いをここで見つけられます。プロファイルはカンマ区切りで重ねられ、-profile slurm,docker のように指定します。

26.04.6のドキュメントに載っているexecutorは、Local、SLURM、SGE、PBS/Torque、PBS Pro、LSF、HTCondor、Flux、AWS Batch、Google Cloud Batch、Azure Batch、Kubernetesなど19種類です。26.04でプレビューとして追加された「Seqera」executorもここに含まれます。SLURMのクラスタ間でジョブを配分する設計はSlurmフェデレーションとは？構築手順・ジョブID体系と1日5万ジョブの適用限界で、AWS側のキューの仕組みはAWS Batchとは？ジョブキュー型マネージドバッチ処理の仕組みと採用判断【2026年版】で解説しています。

ツールの依存関係は、process単位の container ディレクティブ（Docker、Singularity/Apptainer、Podman）や conda ディレクティブで固定します。同じパイプラインをノートPCとクラスタで動かしても結果が変わらないようにするための仕組みです。

版の体系と25.10・26.04の破壊的変更

Nextflowの版番号は「年.月.パッチ」のカレンダー形式です。安定版は毎年4月と10月、edge版は毎月リリースされます。GitHubのリリース一覧（2026-09-17時点）では、安定版の最新が26.04.6（2026-07-09）で、旧系統の25.10.7（2026-07-15）にもパッチが出ています。edge版の最新は26.08.0-edge（2026-08-20）です。edge版を使うには NXF_EDGE=1 nextflow self-update を実行します。

インターネット上には、nextflow.enable.dsl=2 を先頭に書く古い解説がまだ多く残っています。22.12以降はDSL2しかないため、この行は不要です。25.10で正式機能になったworkflow outputs（output ブロック）は、プレビュー時代の nextflow.preview.output フラグを残したままだと実行に失敗します。

26.04では、ほかに次の機能が加わりました。

• モジュールシステム：nextflow module install nf-core/bwa/mem でNextflow registryからモジュールを入れ、include { BWA_MEM } from 'nf-core/bwa/mem' のように名前で読み込めます。
• レコード型と静的型付け（静的型付けはプレビュー）
• エージェント向けのログ形式：NXF_AGENT_MODE=1 を指定すると、[PROCESS ...] や [SUCCESS] completed=3 failed=0 cached=0 のような短い行でログを出力します。

既存のパイプラインを26.04へ上げるときは、25.10のまま NXF_SYNTAX_PARSER=v2 を指定して動かし、nextflow lint のエラーを解消してから版を上げてください。この順序なら、構文の問題と版の変更による問題を切り分けられます。

nf-coreとSeqera Platform（旧Nextflow Tower）

nf-coreは、コミュニティが品質基準を決めて保守しているNextflowパイプラインの集まりです。nf-co.re の pipelines.json（2026-09-17取得）には157件が登録されており、そのうちアーカイブされておらずリリースのあるものが99件です。RNA-Seq用の nf-core/rnaseq は3.26.0（2026-05-07）が最新です。

自前でRNA-Seqのパイプラインを一から書くより、nf-coreを nextflow run nf-core/rnaseq -r 3.26.0 -profile docker ... のように版を固定して使い、足りない工程だけを自作のモジュールで補うほうが保守は楽です。ゲノム比較の結果を図にするなら、PythonのpyGenomeVizの使い方｜1.7.0のインストールからGenBank・GFF描画と比較図の保存までなどを組み合わせます。

「Nextflow Tower」は、2023年10月10日のSeqera Enterprise v23.3でSeqera Platformへ改称されました。Nextflowの設定リファレンスでも「Seqera Platform (formerly Tower Cloud)」と書かれています。ただし互換性のため、設定のスコープ名は今も tower で、実行を監視させるオプションも -with-tower のままです。

export TOWER_ACCESS_TOKEN=<Seqera Platformで発行したトークン>
nextflow run nextflow-io/hello -with-tower

25.10からは nextflow auth login でSeqera Cloudへのログインとトークンの保存ができるようになり、保存先は ~/.nextflow/seqera-auth.config です。Seqera Platformでは、実行状況と各タスクのリソース使用量をWeb画面で確認でき、クラウドの計算環境からパイプラインを起動することもできます。料金ページ（2026-09-17時点）には、無料で登録できるCloud Basic（最大3ユーザー、同時実行3件、実行履歴250件）に加え、Cloud Pro、Enterprise、Validatedのプランが並んでいます。1人で試すならCloud Basic、社内のVPCに置く必要があるならEnterpriseが検討の起点になります。

Snakemake・Airflowとの使い分け

Snakemakeは、「このファイルを作るにはこのルール」という形で出力ファイル名から依存関係を逆算します（PyPIの9.27.0はPython 3.11以上が必要）。Snakemakeもexecutorプラグイン（snakemake-executor-plugin-slurm 2.8.0、-kubernetes 0.5.1、-aws-batch 0.2.1など）でクラスタやクラウドへジョブを投げられるため、実行先の違いは決め手になりません。Pythonに慣れたチームで、ルールと出力ファイルが決まっている解析ならSnakemakeのほうが書きやすくなります。nf-coreの既存パイプラインを使う場合や、サンプル単位の並列化をchannelで組みたい場合はNextflowを選ぶべきです。表の最新版はGitHubとPyPIで2026-09-17に確認した値です。

一方、毎日決まった時刻にデータベースからデータを取り込み、失敗したら通知する、といった業務データのETLには、どちらも向きません。スケジューラーと実行履歴のUIを備えたApache Airflowとは？仕組み・使い方とAirflow 3の新機能を解説のほうが適しています。データ資産を単位に管理したいならDagsterとは？アセット指向の仕組み・実装手順とAirflowとの使い分けを実装者目線で解説【2026年版】も候補になります。Nextflowが得意なのは「大量のファイルに同じコマンドを並列で当てる」処理で、Web APIの呼び出しを組み合わせる処理ではありません。

よくある質問

Nextflowは無料で使えますか？

Nextflow本体はApache-2.0ライセンスのOSSで、無料で使えます。料金が発生しうるのは、実行を管理するSeqera Platformの上位プランや、ジョブを実行するクラウドの計算資源です。

NextflowはWindowsで動きますか？

Windowsネイティブ版はありません。公式の動作対象はPOSIX互換環境で、WindowsではWSL上のLinuxにJava 17〜26を入れて使います。

どのバージョンのJavaが必要ですか？

26.04系のドキュメントでは、Java 17以上26以下が要件です。Java 16以前では動きません。本記事の実行例はOpenJDK 21.0.12.1で確認しました。

-resumeを付けても最初から実行されるのはなぜですか？

入力ファイルの更新時刻やサイズが変わった、NFSがタイムスタンプを一定に返さない、起動ディレクトリの .nextflow/cache や work/ を消した（または別のディレクトリから起動した）、が主な原因です。NFSが原因の場合は cache 'lenient' で解消します。ハッシュの差分は -dump-hashes で確認できます。

Nextflow TowerとSeqera Platformは同じものですか？

同じ製品の旧名称と現在の名称で、2023年10月10日のSeqera Enterprise v23.3で改称されました。Nextflowの設定リファレンスでも「Seqera Platform (formerly Tower Cloud)」と書かれています。互換性のため、設定のスコープ名 tower とオプション -with-tower は現在も使われています。

関連記事

• Groovyとは？JVMで動く簡潔なスクリプト言語の文法・用途・採用判断
• AWS Batchとは？ジョブキュー型マネージドバッチ処理の仕組みと採用判断【2026年版】
• Apache Airflowとは？仕組み・使い方とAirflow 3の新機能を解説
• Prefect（Python）とは？ワークフロー管理の使い方と3系の始め方
• pyGenomeVizの使い方｜1.7.0のインストールからGenBank・GFF描画と比較図の保存まで