第2章: 計算インフラストラクチャ

2.0 この章で学ぶこと

この章では、バイオインフォマティクス解析を「手元で動いたコマンド」から、再現可能で監査しやすい計算基盤へ移すための考え方を扱う。対象は、FASTQ、BAM/CRAM、VCF、count matrix、metadata などの研究・教育用途データを、HPC、クラウド、コンテナ、workflow / ワークフロー、CI で扱う IT 技術者である。

この章を読み終えた時点で、次のことを説明できることを目標にする。

• 解析の入力データ量、I/O、CPU、メモリ、GPU、ストレージを見積もる観点。
• ローカルPC、HPC、クラウド、コンテナ、ジョブスケジューラの使い分け。
• Docker、Apptainer/Singularity、conda/mamba、Bioconda、uv の役割分担。
• Nextflow、Snakemake、CWL、WDL を選ぶときの比較軸。
• ログ、バージョン、checksum、provenance / 来歴、費用、セキュリティを記録する理由。
• 解析が再現できることと、研究結論が妥当であることは別問題であるという境界。

2.1 なぜ IT 技術者に必要か

バイオインフォマティクスでは、同じコードでも入力データ、参照配列、annotation、ツールバージョン、スレッド数、メモリ、I/O、乱数、ジョブスケジューラの制限が変わると、実行時間、失敗モード、出力の細部が変わる。IT 技術者は、単に「コマンドを並べる」のではなく、解析がどの環境で、どの入力から、どの出力を生成したかを追跡できるように設計する必要がある。

Webアプリ開発と異なる点は、主に次の5点である。

2.2 前提知識

この章では、次の前提を置く。

• Unix/Linux の基本操作、path、標準入出力、環境変数を理解している。
• Python または R の仮想環境・package 管理を触ったことがある。
• FASTQ、BAM/CRAM、VCF、count matrix が大きなファイルになり得ることを第1章で確認済みである。
• Docker や GitHub Actions の概念を聞いたことがある。
• 個人ゲノムデータや医療データを扱う場合は、第11章と第12章の責任境界を先に確認する。

ここで示す設定値や構成は、教育用の考え方を示す。実運用では、所属機関、クラウド契約、HPC利用規程、データ利用条件、セキュリティ要件を優先する。

2.3 基本概念

計算資源を分解して見る

実行場所を選ぶ

SHIROKANE などの共同利用HPCは、バイオインフォマティクス実務で重要な選択肢である。ただし、ノード構成、キュー、利用条件、性能値、民間利用可否、保存期間は更新され得るため、本書では固定の性能値を本文に残さない。利用時は公式情報、所属機関の案内、ジョブログ、利用申請条件を確認し、確認日とともに記録する。

2.4 入力データと出力データ

計算基盤の設計では、解析対象のデータだけでなく、参照データ、設定、ログ、成果物を含めて管理する。

2.5 標準的なワークフロー

環境の層を分ける

Docker は開発・CI・クラウドで扱いやすい。一方、HPC では権限やセキュリティ上の理由で Apptainer/Singularity が使われることがある。conda/mamba、Bioconda、uv は、container の内外で依存関係を固定するために使う。どれか1つで全てを解決するのではなく、実行場所に合わせて層を組み合わせる。

workflow engine の比較

既存の公開ワークフローがある領域では、手元で独自pipelineを作る前に nf-core などの community-maintained pipeline を候補に入れる。導入時は pipeline release、test profile、container、入力サンプルシート、出力仕様、ライセンス、引用方法を確認する。

ワークフロー公開前チェックリスト

Nextflow、nf-core、Snakemake のどれを選んでも、公開・共有前のレビューでは「動いたか」だけでなく、入力、供給網、期待出力、再実行条件を同じ単位で確認します。教材では、実データや controlled data ではなく、公開 tiny data または合成 fixture で次の項目を埋めてから PR / 解析メモに残します（確認日: 2026-06-05）。

Nextflow は、local / HPC scheduler / cloud と container runtime / package manager をまたいで実行する可搬性が強みです。nf-core は Nextflow pipeline の release、template、test data、lint、RO-Crate などのコミュニティ標準を利用できる場合に優先候補になります。Snakemake は Python ベースの rule で研究室内の小〜中規模処理を表現しやすく、profile、software deployment、report / provenance を固定して共有します。いずれも「workflow engine があるから再現できる」のではなく、上のチェックリストを満たして初めて再現入口として扱います。

tiny fixture と cache の使い方

CI では、本番データを短く切り出したものではなく、利用条件を確認した公開データの最小 subset、または合成 FASTQ / VCF / count matrix を使います。外部 API や DB から取得する結果は、raw response と加工後 TSV を fixture として凍結し、取得日、endpoint、query、response schema、checksum を残します。API を毎回呼ぶ smoke test は、サービス停止、schema 変更、rate limit、利用条件変更で壊れるため、教材の CI では cache / frozen fixture を既定にします。

供給網リスクも fixture と同じ単位で確認します。container は tag だけでなく digest を記録し、conda は lockfile と channel priority を残します。curl | bash で外部スクリプトを直接実行する例は教材では避け、どうしても必要な場合は公式 URL、取得日、checksum、実行前レビューを明記します。controlled-access のヒトデータ、個人情報、未公開研究データは、CI artifact、ログ、公開リポジトリ、公開 LLM、未承認クラウドへ残さないことを前提条件にします。

🔁 疑似コード（実行不可: workflow 設計メモのひな形）

workflow_name: rnaseq_qc_example
purpose: RNA-seq のQCと定量前確認
input:
  - samplesheet.csv
  - FASTQ files
reference:
  - genome build
  - annotation release
runtime:
  - workflow engine and version
  - profile: local / hpc / cloud
  - container image digest
outputs:
  - QC report
  - tool logs
  - run summary
re-run policy:
  - resume allowed when inputs and reference checksums match
  - rerun required when annotation or container digest changes

2.6 実務上の落とし穴

• I/Oが律速になる: CPUを増やしても、圧縮FASTQの読み書き、BAM sort、object storageとの転送が詰まることがある。
• scratch容量を見積もらない: 中間ファイルは入力より大きくなることがある。削除方針と再生成可否を事前に決める。
• versionだけでなくdigestを記録しない: latest tag や環境の自動更新は再現性を壊す。container digest、lock file、reference checksumを残す。
• HPCとクラウドの権限モデルを混同する: HPCはqueue・quota・shared filesystem、クラウドはIAM・region・object storage・費用監査が中心になる。
• 費用をログに残さない: クラウドでは計算時間だけでなく、storage、egress、snapshot、idle resourceが費用になる。
• 個人情報・制限データを検証用に持ち出す: smoke test は公開tiny dataで設計し、患者個人データや非公開医療データを前提にしない。
• 臨床用の検証と研究用の再現性を混同する: CIで解析手順が動くことは、臨床判断へ使えることを意味しない。

2.7 小さな実例

ここでは、公開tiny dataを使った variant calling や RNA-seq の一部処理を想定し、実行前に作る要件表の例を示す。実データや施設環境に合わせる前の、設計レビュー用メモとして扱う。

🧪 概念例（実行不可: コマンドではなく確認ログの形を示す断片）

run_id: 2026-05-13-ch2-smoke-design
input_checksum: <sha256 of tiny input>
reference_checksum: <sha256 of reference subset>
container_digest: <image digest>
workflow_version: <release or commit>
executor: local
resources: cpu=2, memory=4GB, scratch=10GB
result: completed / failed
elapsed_time: <measured>
notes: tiny data; not for biological interpretation

2.8 結果の読み方

計算基盤の結果は、処理時間だけで評価しない。最低限、次の観点を一緒に読む。

2.9 限界と注意点

• この章は、計算基盤の設計・記録・レビューの考え方を扱う。施設固有のHPC設定、クラウド契約、セキュリティ審査、臨床品質管理の代替にはならない。
• SHIROKANE 等の固有HPC事例は、公式情報が更新される。本文中に古い性能値や利用条件を固定せず、実際の利用前に確認日付きで記録する。
• workflow engine や container の採用は、解析の妥当性を保証しない。研究デザイン、統計、参照データ、サンプル品質、専門家レビューは別途必要である。
• 個人ゲノムデータ、医療データ、アクセス制限データを扱う場合は、データの持ち出し、暗号化、アクセス制御、監査ログ、同意、研究倫理審査を第11章・第12章の範囲で確認する。

2.10 演習

1. 自分が扱う予定の解析について、入力データ、参照データ、実行環境、出力、ログ、保存方針を表にする。
2. ローカル、HPC、クラウドの3案で、CPU、メモリ、storage、network、費用、監査ログの違いを比較する。
3. workflow engine を1つ選び、選定理由、採用しなかった選択肢、version固定方法、container方針を書く。
4. tiny data smoke test の成功条件を、期待ファイル、exit code、実行時間、ログ、checksum の観点で定義する。
5. 制限データを使わずに CI で確認できる項目と、人間のレビューが必要な項目を分ける。

2.11 参考資料

• 付録A: 環境構築ガイド — Docker、環境ラベル、lock file、CIの入口。
• 付録E: ワークフロー例 — Snakemake / Nextflow / WDL / CWL の位置づけと、実行可能例・概念例の読み分け。
• 第4章: ゲノム解析技術 — FASTQからVCFまでの実務的な入力・出力。
• 第10章: データベース技術 — accession、version、checksum、API、cache、provenance。
• 第11章: プライバシー保護技術 — 個人情報、アクセス制御、監査ログ、NBDC。
• 2026年版 source audit — workflow / ワークフロー管理、container、公式ドキュメント確認の棚卸し。

2.12 2026年時点の更新メモ

• 第2章では、古い固定性能値やSHIROKANEの断定的な実績説明を本文から外し、共同利用HPCの利用条件・性能・保存期間は利用時に公式情報で確認する方針へ変更した。
• 解析環境は、Dockerだけでなく Apptainer/Singularity、conda/mamba、Bioconda、uv、GitHub Actions、container digest、lock file を組み合わせて記録する前提にした。
• workflow / ワークフローは、Nextflow、Snakemake、CWL、WDL の比較軸を示し、既存の nf-core など community-maintained pipeline を候補に入れる方針にした。
• CIは本番解析ではなく、公開tiny dataによる smoke test、build、lint、navigation、コードラベル検査の入口として扱う。
• 更新根拠は 2026年版 source audit の workflow 行と、付録A・付録Eの確認日付き説明へ集約する（確認日: 2026-05-12）。

最小入出力（期待成果物/期待ログ）

• 入力: 解析対象データの種類とサイズ、参照データ、利用可能な計算資源、実行場所の候補、データ利用条件。
• 出力（期待成果物）: 実行環境の要件表、workflow engine / container / package manager の選定理由、ログ・checksum・provenance の記録方針、tiny data smoke test の成功条件。
• 期待ログ（例）: 実行ID、入力checksum、参照checksum、container digest、tool/workflow version、CPU/memory/scratch、処理時間、exit code、失敗時の確認ポイント。