Nextflowは、多数のコマンドをつないで大量のサンプルへ並列に流す処理を記述する、ワークフロー言語と実行エンジンです。本記事は2026年11月9日時点の安定版 26.10.5 を使い、インストール、公開パイプラインの実行、自作パイプラインの書き方、-resume、実行環境の切り替えを、実行結果付きで説明します。後半では26.10で変わった挙動と、SnakemakeやAirflowとの使い分けを扱います。
ここで扱うのはオープンソースのNextflow(nextflow-io/nextflow)です。「NextFlow」「next flow」を名乗る企業やデータ入力サービスとは関係ありません。
まとめ:Nextflowの要点と26.10で変わったこと
- Nextflowはprocess(処理単位)、channel(データの流れ)、workflow(つなぎ方)でパイプラインを書き、サンプルごとのタスクを自動で並列実行します。
- 動作要件はBash 3.2以上とJava 17〜26です。導入は
curl -s https://get.nextflow.io | bash。Windowsで使うならWSLが必要です。 - 2026年11月9日時点の最新安定版は26.10.5(11月2日公開)です。安定版は毎年4月と10月に出ます。
- 26.10ではコンソール出力が標準エラーへ移り、
echoディレクティブが削除され、Kubernetes executorの既定がJobになりました。CIでログを保存している場合は更新前に見直します。 - 26.04から既定のstrict parserでは、
params.flag = trueの形式で定義した値に--flag falseを渡すと真と評価されます。paramsブロックで型を付ければ変換されます。 - -resumeは、ハッシュが一致し出力がworkディレクトリに残っているタスクだけを再利用します。NFSのタイムスタンプが原因で外れるときは
cache 'lenient'を指定します。 - 定番の解析ならnf-coreの公開パイプラインを版固定で使うのが先です。時刻起動の日次ETLにはAirflowなどを選びます。
Nextflowの仕組みとprocess・channel・workflowの役割
数百サンプルの解析をシェルスクリプトで書くと、並列実行、失敗したサンプルだけのやり直し、計算機ごとのジョブ投入をすべて自前で書くことになります。Nextflowはこの3つを言語と実行エンジンの側で引き受けます。
開発の中心はSeqera社で、ライセンスはApache-2.0です。2017年にNature Biotechnology誌の論文として発表されました。スクリプトはJVM上で動き、文法はJVMで動くスクリプト言語のGroovyをもとにしています。パイプラインは次の3要素で組み立てます。
| 要素 | 役割 | 記述の例 |
|---|---|---|
| process | 1つのコマンド処理と入出力 | FastQC、STARなどの実行 |
| channel | process間を流れる値やファイル | channel.fromPath(‘*.fastq.gz’) |
| workflow | processとchannelの接続 | FASTQC(reads) |
channelに値が届くたびに、それを受け取るprocessのタスクが1件生成されます。100サンプルのファイルを流せばタスクも100件になり、CPUやジョブスケジューラーの空きに応じて同時に動きます。並列化のループは書きません。
各タスクは work/ 以下にハッシュ名の専用ディレクトリを持ち、入力へのリンク、展開後のスクリプト(.command.sh)、ログ、出力がそこに残ります。タスクが失敗したら、このディレクトリを開けば原因を追えます。
Nextflowのインストールと更新の手順(Java 17〜26)
公式のインストールページによると、必要なのはBash 3.2以上とJava 17以上26以下です。26.10.5のランチャーは起動時にJavaの版を正規表現で検査し、17〜26以外では「Cannot find Java or it’s a wrong version」と表示して止まります。先に java -version で手元の版を確かめ、足りなければ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に入っていません。恒久化するには同じ export 行を ~/.zshrc や ~/.bashrc に書きます。初回は依存ライブラリのダウンロードが走ります。macOSとOpenJDK 25.0.4.1の環境では、nextflow info が次のように表示しました。
Version: 26.10.5 build 14654
Created: 02-11-2026 17:37 UTC (03-11-2026 02:37 JDT)
System: Mac OS X 26.6.2
Runtime: Groovy 4.0.33 on OpenJDK 64-Bit Server VM 25.0.4.1+1-LTS
Encoding: UTF-8 (UTF-8)
WindowsはWSL経由、Condaは非推奨
公式の動作対象はLinuxやmacOSなどのPOSIX互換環境で、Windowsで使う場合はWSLが前提です。WSL上のUbuntuにJavaを入れ、上と同じ手順で導入します。
Biocondaからは conda create --name nf-env bioconda::nextflow で入ります。ただし公式は、版が古くなる、依存関係やJavaの互換性で問題が起きることがあるとして、自己展開型のランチャーを推奨しています。
更新と版の固定:self-updateとNXF_VER
最新の安定版へ上げるコマンドは nextflow self-update です。実行ファイルを書き換えるので、置き場所に書き込み権限が要ります。26.04.9でパイプラインを実行すると「Nextflow 26.10.5 is available」という案内が出ました。系統をまたぐ更新の前には、下の26.10の章を確認してください。
1回の実行だけ版を指定するなら NXF_VER=26.10.5 nextflow run ... と書きます(公式の更新手順)。論文や本番の解析では、この変数を実行スクリプトに固定しておくと後から再現できます。
公開パイプラインの実行:nextflow-io/helloからnf-coreへ
自分で書く前に、GitHubの公開パイプラインを動かすと導入の成否をすぐ確かめられます。nextflow run に「所有者/リポジトリ」を渡すと、取得から実行まで1行で済みます。
$ nextflow run nextflow-io/hello
[82/2d0b85] Submitted process > sayHello (1)
[58/92dd49] Submitted process > sayHello (3)
[94/18c5a8] Submitted process > sayHello (2)
[df/f83249] Submitted process > sayHello (4)
Bonjour world!
Hello world!
Ciao world!
Hola world!
実際の解析で最初に探すべきなのはnf-coreです。コミュニティが品質基準を決めて保守するパイプライン集で、2026年11月9日時点の一覧には160件が載っています。アーカイブ14件を除き、リリース済みのものは106件です。RNA-Seq用の nf-core/rnaseq の最新は3.27.0(2026年9月23日)で、Nextflow 25.10.4以上を要求しています。
nextflow run nf-core/rnaseq -r 3.27.0 -profile test,docker --outdir results
このコマンドの実行にはDockerのインストールと起動が別途必要です。-r で版を固定し、-profile test の小さなテストデータで手元の環境を確かめてから実データへ移ります。RNA-Seqのような定番の解析は一から書かず、足りない工程だけを自作のモジュールで補うほうが保守は楽です。比較ゲノムの結果を図にする工程などは、PythonのpyGenomeVizのようなツールと組み合わせます。
最初のパイプライン:process・channel・workflowの書き方
テキストファイルの行数をサンプルごとに数え、1つの表にまとめる例です。data/sampleA.txt(2行)と data/sampleB.txt(1行)を用意して main.nf に保存します。26.10.5の 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.10.5
Launching `main.nf` [hopeful_payne] - revision: c7a8f37cc1
[94/eeeb52] Submitted process > COUNT_LINES (sampleA)
[c4/1fb2da] Submitted process > COUNT_LINES (sampleB)
[67/54c25d] Submitted process > SUMMARY
$ cat results/summary.tsv
sampleA 2
sampleB 1
行頭の [94/eeeb52] がそのタスクのworkディレクトリ(work/94/eeeb52...)を指します。process内でシェル変数を使うときは、Nextflowの変数と区別するため \$ とエスケープします。
channelの演算子:map・filter・collect
channel.fromPath はglobに一致したファイルを1件ずつ流します。map は値を1件ずつ変換し、filter は条件に合う値だけを残します。次の例は奇数だけを10倍にして表示し、26.10.5では10、30、50が出力されました。
workflow {
channel.of(1, 2, 3, 4, 5)
.filter { n -> n % 2 == 1 }
.map { n -> n * 10 }
.view()
}
collect はchannelの値をすべて待って1つのリストにまとめるので、上のパイプラインのSUMMARYはタスクが1件だけ生成されます。複数のchannelをサンプル名で突き合わせるなら join、ペアエンドのFASTQを組にするなら channel.fromFilePairs('*_{1,2}.fastq.gz') を使います。
パラメータの上書きとstrict parserの真偽値
params. で定義した値は、実行時に --名前 値 で上書きできます。注意が必要なのは真偽値です。26.04で既定になったstrict parserは、params.xxx = 値 の従来形式では渡された値の型を判定しません。
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
26.10.5でも false を渡して true と表示されました。'false' という空でない文字列が真と評価されるためです。対策は、params ブロックで型注釈を付ける方法です。次の形にすると false と表示されました。
params {
save_intermeds: Boolean = true
}
25.10以前から使っているパイプラインは、if (params.xxx) で真偽値を判定している箇所を洗い出してから版を上げてください。
-resumeが効く条件とworkディレクトリの仕組み
-resume を付けると、前回完了したタスクを再利用します。上のパイプラインをもう一度実行すると3件とも Cached になり、コマンドは動きませんでした。
$ nextflow run main.nf -resume
N E X T F L O W ~ version 26.10.5
Launching `main.nf` [sleepy_franklin] - revision: c7a8f37cc1
[c4/1fb2da] Cached process > COUNT_LINES (sampleB)
[94/eeeb52] Cached process > COUNT_LINES (sampleA)
[67/54c25d] Cached process > SUMMARY
入力を sampleA だけに絞って再実行すると、COUNT_LINES (sampleA) はキャッシュから使われ、入力が変わったSUMMARYだけが実行し直されました。
公式の説明によると、再利用されるのはハッシュが前回と一致し、workディレクトリに出力が残っているタスクだけです。キャッシュが外れる代表的な原因は次のとおりです。
- 入力ファイルのパス・最終更新時刻・サイズのいずれかが変わった(触り直しただけでも再実行されます)
- NFSなどの共有ファイルシステムが返すタイムスタンプが一定しない(
cache 'lenient'で時刻を無視します。パスとサイズだけで判定するので、同じサイズのまま中身が変わった入力は再実行されません) - processが自分の入力ファイルを書き換えている(公式はアンチパターンとしており、再開できません)
- 起動ディレクトリの
.nextflow/cacheかwork/を消した、または別のディレクトリから起動した
原因が分からないときは、通常の実行と -resume 付きの実行の両方に -dump-hashes json を付け、ハッシュの差分を比べます。work/ は放っておくと膨らむので、不要な実行の分は nextflow clean -n 実行名 で対象を確認し、nextflow clean -f 実行名 で消します。
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
}
}
-profile slurm,docker のようにカンマ区切りで重ねられます。26.10.5のドキュメントに載っているexecutorは、Local、SLURM、SGE、PBS/Torque、PBS Pro、LSF、HTCondor、Flux、AWS Batch、Google Cloud Batch、Azure Batch、Kubernetesなど19種類です。
Slurmへの投入と26.10のグリッド資源上限
nextflow config -profile slurm を実行すると、適用後の最終的な設定を確認できます。この設定では executor = 'slurm' と queue = 'short' がprocessスコープに加わりました。本番クラスタに投入する前に、キュー名やexecutorの綴り違いをここで見つけられます。クラスタ間でジョブを配分する設計はSlurmフェデレーションの構築手順を参照してください。
共有クラスタで注意したいのが26.10の変更です。executor.cpus と executor.memory がグリッドexecutorにも効くようになり、上限を超えて要求するタスクは失敗します。ローカル実行だけを絞るつもりで書いていた設定は executor.$local.cpus に直します。
DockerとSingularity・Apptainerでの依存の固定
ツールの実行環境はprocess単位の container ディレクティブで指定します。タグだけではイメージの中身まで固定されないので、再現性を厳密に求めるなら @sha256:... のdigestで指定してください。Dockerデーモンを使えない共有HPCの選択肢は、rootもデーモンも要らないSingularityかApptainerです。プロファイルに singularity.enabled = true(Apptainerなら apptainer.enabled = true)を足すと切り替わります。
AWS Batchで動かすときの設定項目
公式のAWS Batchリファレンスが求めるNextflow側の設定はexecutor、ジョブキュー、リージョン、S3のworkDirの4つで、すべてのprocessに container の指定が必要です。計算環境・ジョブキュー・S3バケットの作成と、認証情報やIAM権限の準備はAWS側で先に済ませておきます。ジョブキューの仕組みはAWS Batchの解説にまとめています。
process {
executor = 'awsbatch'
queue = 'my-queue'
container = 'quay.io/biocontainers/salmon'
}
workDir = 's3://my-bucket/work'
aws.region = 'ap-northeast-1'
26.10で変わった挙動と更新前の確認項目
26.10は2026年10月12日に公開されました。公式の移行ガイドが挙げる変更のうち、既存のパイプラインや運用に影響するものは次のとおりです。
| 項目 | 26.10での変更 | 対処 |
|---|---|---|
| コンソール出力 | 標準エラーへ移動 | > out.log 2>&1 で保存 |
| echoディレクティブ | 削除 | debug に置換 |
| -with-weblog | 非対応 | nf-weblogプラグイン |
| Kubernetes executor | 既定がJobに | k8s.computeResourceType で Pod |
| executor.cpus・memory | グリッドにも適用 | executor.$local.* を使う |
| eval出力のハッシュ | 計算方法を変更 | 更新後の初回resumeは再実行 |
| when節・storeDir | 非推奨 | workflow側の分岐へ移行 |
コンソール出力の標準エラー移行とCIのログ保存
影響が見えにくいのがこの変更です。同じパイプラインで nextflow run main.nf -resume の出力先を分けて行数を数えると、26.04.9は標準出力に5行、26.10.5は標準出力が0行で標準エラーに5行でした。nextflow run main.nf > out.log と書いているCIは、26.10に上げるとログが空になります。全出力を残すには > out.log 2>&1 と書きます。
echoディレクティブ削除の版による挙動差
echo true を書いたprocessを旧パーサー(NXF_SYNTAX_PARSER=v1)で動かすと、26.04.9は非推奨の警告を出して実行しますが、26.10.5は Unknown process directive: `echo` で停止しました。strict parserでは26.04.9の時点ですでにエラーです。旧パーサーで延命していたパイプラインは、ここで debug true への置換が必須になります。
静的型付けの正式化:lintはエラー、runは警告
26.10で静的型付けがプレビューを終え、CLIでも型検査が使えるようになりました。スクリプトごとに nextflow.enable.types = true を書く必要があります。文字列を受ける入力に数値を渡す次の例で動作の差を確かめました。
nextflow.enable.types = true
process HELLO {
input:
name: String
output:
stdout()
script:
"""
echo Hello ${name}
"""
}
workflow {
HELLO(42).view()
}
$ nextflow lint main.nf
Error main.nf:17:11: Argument with type Integer is not compatible with process input of type String
$ nextflow run main.nf
WARN: Type checking found 1 error(s) -- run `nextflow lint` to inspect them
WARN: [HELLO] invalid argument type for input at index 0 -- expected a String but got a Integer
[d4/dc3702] Submitted process > HELLO
Hello 42
nextflow run は型エラーがあっても止まりません。型の検査を品質の関門にするなら、CIに nextflow lint を入れます。
26.10で追加されたGlobal cache・モジュール合成・Agents
Global cacheはSeqera Platform経由で使える機能で、前回の実行に限らず別の実行のタスクも再利用します。モジュールはworkflow単位でも配布できるようになりました。Agents(プレビュー)は、LLMの呼び出しをprocessと同じ形で宣言する機能です。仕様は今後変わる可能性があると公式が明記しているので、本番の解析に組み込むのは正式化を待つべきです。
版の体系とDSL2以降の節目
版番号は「年.月.パッチ」のカレンダー形式で、安定版は毎年4月と10月、edge版は毎月出ます。2026年11月9日時点では安定版が26.10.5(11月2日)で、旧系統にも26.04.9(10月22日)と25.10.9(10月20日)のパッチが出ています。
| 版 | 変更点 |
|---|---|
| 22.03.0-edge | DSL2が既定 |
| 22.12.0-edge | DSL1を削除 |
| 25.04 | nextflow lint を追加 |
| 25.10 | workflow outputsが正式機能に |
| 26.04 | strict parserが既定 |
| 26.10 | 静的型付けが正式機能に |
25.04や25.10から上げるなら、旧版のまま NXF_SYNTAX_PARSER=v2 を指定して動かし、nextflow lint のエラーを解消してから版を上げます。strict parserがCLIで使えるのは25.04以降なので、それより前の版のパイプラインは25.04以上の検証環境で先に確かめます。この順序だと、構文の問題と版の変更による問題を切り分けられます。
Seqera Platform(旧Nextflow Tower)での実行監視と料金
「Nextflow Tower」は、2023年10月10日のSeqera Enterprise v23.3でSeqera Platformへ改称されました。Nextflowの設定リファレンスにも「Seqera Platform (formerly Tower Cloud)」とあります。ただし互換性のため、設定のスコープ名は今も tower、実行を監視させるオプションも -with-tower のままです。
# YOUR_TOKEN を Seqera Platform で発行したトークンに置き換える
export TOWER_ACCESS_TOKEN="YOUR_TOKEN"
nextflow run nextflow-io/hello -with-tower
25.10からは nextflow auth login でログインでき、トークンは ~/.nextflow/seqera-auth.config に保存されます。
料金表(2026年11月9日時点)には、無料で登録できるCloud Basic(最大3ユーザー、同時実行3件、実行履歴250件)のほか、Cloud Pro、Enterprise、Validatedが並びます。1人で試すならCloud Basicで足り、社内のVPCに置く必要が出た時点でEnterpriseが候補に入ります。
Snakemake・Airflowとの使い分けと採用しない場面
| 項目 | Nextflow | Snakemake | Airflow |
|---|---|---|---|
| 記述 | Groovy系DSL | Python系DSL | Python |
| 依存の決め方 | channelの流れ | 出力ファイル名から逆算 | タスク間の明示的な依存 |
| 主な起動方法 | コマンド実行 | コマンド実行 | スケジュール実行 |
| 最新版(2026-11-09) | 26.10.5 | 9.27.1 | 3.4.0 |
Snakemakeは「このファイルを作るにはこのルール」という形で依存を逆算します。executorプラグインでSlurmやクラウドへジョブを投げられるので、実行先は決め手になりません。Pythonに慣れたチームで出力ファイルが決まっている解析ならSnakemake、nf-coreの既存パイプラインを使うならNextflowです。
Nextflowを採用しない場面もはっきりしています。毎日決まった時刻にデータベースから取り込み、失敗したら通知するような業務データのETLは、スケジューラーと実行履歴のUIを備えたApache Airflowの領域です。データ資産を単位に管理したいならDagster、Pythonの関数をそのままフローにしたいならPrefectが候補になります。Nextflowが得意なのは「大量のファイルに同じコマンドを並列で当てる」処理で、Web APIの呼び出しを組み合わせる処理ではありません。社内のデータ基盤全体の構成から決める段階であれば、データ分析基盤構築・MLOps構築支援でも相談を受けています。
サンプルが数件で一度しか流さない処理なら、シェルスクリプトで十分です。Javaの導入やworkディレクトリの管理を背負う理由がありません。
よくある質問
NextflowはWindowsで動きますか?
Windowsネイティブのインストーラーはありません。公式の動作対象はPOSIX互換環境で、WindowsではWSL上のLinuxにJava 17〜26を入れて使います。導入手順はLinuxと同じで、curl -s https://get.nextflow.io | bash で入ります。
どのバージョンのJavaが必要ですか?
26.10.5の公式ドキュメントでは、Java 17以上26以下が要件です。16以前のサポートは終了しており、ランチャーも17〜26以外では起動時に停止します。本記事の実行例はOpenJDK 25.0.4.1で確認しました。公式はTemurinの最新LTS版を勧めていますが、入れる前に対応範囲の17〜26に収まるかを確かめてください。
-resumeを付けても最初から実行されるのはなぜですか?
入力ファイルの更新時刻やサイズが変わった、NFSがタイムスタンプを一定に返さない、起動ディレクトリの .nextflow/cache や work/ を消した(または別のディレクトリから起動した)、が主な原因です。26.10へ上げた直後は、eval出力を持つprocessも1度だけ再実行されます。ハッシュの差分は -dump-hashes で確認できます。
Nextflow TowerとSeqera Platformは同じものですか?
同じ製品の旧名称と現在の名称で、2023年10月10日のSeqera Enterprise v23.3で改称されました。設定のスコープ名 tower とオプション -with-tower は残っているので、古い解説のコマンドは今も動きます。画面や料金を調べるときはSeqera Platformの名前で探してください。
nextflow.enable.dsl=2 は今も書く必要がありますか?
不要です。DSL2は22.03.0-edgeで既定になり、DSL1は22.12.0-edgeで削除されたので、今のNextflowにはDSL2しかありません。先頭にこの行を書く古い解説のコードを流用するときは、行を消して nextflow lint を通してください。