3
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【2026年版】bulk RNA-seq解析の一次解析を徹底解説

3
Last updated at Posted at 2026-03-20

トランスクリプトーム解析の記事第一弾として、本記事では**bulk RNA-seq 一次解析(primary analysis)**に焦点を当てます。
対象は、FASTQファイルから遺伝子発現カウント行列を作るまでです。
2026年時点で広く受け入れられている実務・ガイドライン・主要ツールの動向に基づき、正確性と再現性を重視して整理します。


目次

パート1:背景知識(初心者の方はここから)

  1. この記事の対象読者と読み方ガイド
  2. トランスクリプトーム解析とは何か?
  3. bulk RNA-seqとは何か?
  4. RNA-seqの実験から解析までの全体像
  5. 本記事で使う用語集

パート2:一次解析の実践

  1. はじめに:一次解析とは何か
  2. bulk RNA-seq全体像の中での一次解析の位置づけ
  3. 解析開始前に必ず確認すべき実験情報
  4. 一次解析の標準ワークフロー
  5. Step 0: 解析環境と再現性の確保
  6. Step 1: FASTQの品質評価(QC)
  7. Step 2: アダプタ除去・トリミングは本当に必要か
  8. Step 3: リードのアラインメント or 擬似アラインメント
  9. Step 4: 発現定量(gene-level quantification)
  10. Step 5: マッピング後QCで見るべき指標
  11. Step 6: カウント行列作成時の注意点

実践ガイド・リファレンス

  1. 2026年時点での推奨ツール構成
  2. 実践例:推奨パイプライン(構成B:STAR型)
  3. ikraを活用した一次解析の自動化
  4. よくある失敗とその回避策
  5. 一次解析の成果物一覧
  6. 二次解析へどうつなぐか
  7. まとめ
  8. 参考文献・根拠

この記事の対象読者と読み方ガイド

本記事は、bulk RNA-seq(バルクRNA-seq)の一次解析について、初心者にもわかりやすく、かつ中級者にとっても実践的な知見が得られるように構成しています。

想定する読者

レベル こんな方を想定しています 本記事での活用法
🔰 初心者 RNA-seqのデータ解析をこれから始めたい方、FASTQファイルを受け取ったがどう処理すればよいかわからない方 導入セクション(トランスクリプトーム解析とは?〜用語集)から順番に読み進めてください
🔧 中級者 一通りの解析経験はあるが、パラメータの根拠やツール選択の判断基準をより深く理解したい方 目次から必要なステップに飛んで、各セクション冒頭の「このセクションで学ぶこと」を確認してください

記事の全体構成

本記事は、大きく 3つのパート で構成されています。

📘 パート1:背景知識(初心者の方はここから)
  ├─ トランスクリプトーム解析とは何か?
  ├─ bulk RNA-seqとは何か?
  ├─ RNA-seqの実験から解析までの全体像
  └─ 本記事で使う用語集

🔬 パート2:一次解析の実践(本記事のメイン)
  ├─ 解析開始前に確認すべき実験情報
  ├─ Step 0〜6:各解析ステップの詳細
  ├─ 推奨ツール構成と実践パイプライン例
  └─ よくある失敗とその回避策

📦 パート3:まとめと次のステップ
  ├─ 一次解析の成果物一覧
  ├─ 二次解析への接続方法
  └─ 参考文献・根拠

💡 初心者の方へ:パート1の背景知識から読むことを強くおすすめします。用語や概念を先に理解しておくと、パート2の実践パートがぐっと理解しやすくなります。

⚠️ 中級者の方へ:パート1は既知の内容かもしれませんが、「用語集」セクションではアラインメントとマッピングの使い分けなど、混同しやすい概念も整理しています。必要に応じてご確認ください。


パート1:背景知識


トランスクリプトーム解析とは何か?

📖 このセクションで学ぶこと:トランスクリプトームの定義、セントラルドグマとの関係、そしてトランスクリプトーム解析がなぜ生命科学研究で重要なのかを理解します。

セントラルドグマとRNAの役割

生物の細胞の中では、遺伝情報は次のような流れで機能しています。これを**セントラルドグマ(中心教義)**と呼びます。

DNA  ──→  RNA  ──→  タンパク質
(設計図)  (転写産物)  (実際に働く分子)
  転写        翻訳

ここで重要なポイントは、DNAはすべての細胞でほぼ同じですが、RNAはどの遺伝子がどれだけ「読まれて」いるかによって細胞ごとに大きく異なるという点です。

たとえば、肝臓の細胞と脳の神経細胞は同じDNAを持っていますが、実際に発現している(=RNAに転写されている)遺伝子のセットはまったく違います。つまり、RNAを調べることで「いま、この細胞で何が起きているか」がわかるのです。

トランスクリプトームとは

トランスクリプトーム(transcriptome)とは、ある時点・ある条件下で細胞や組織に存在するRNA転写産物の総体のことです。

用語 意味
ゲノム(genome) ある生物が持つDNA配列の全体
トランスクリプトーム(transcriptome) ある時点で転写されているRNA全体(条件や組織で変わる)
プロテオーム(proteome) ある時点で存在するタンパク質の全体

ゲノムが「設計図のすべて」だとすれば、トランスクリプトームは「いま、どの設計図が使われているか」を示すスナップショットです。

トランスクリプトーム解析とは

トランスクリプトーム解析とは、このRNA転写産物の全体像を網羅的に測定・解析する手法の総称です。具体的には、以下のような問いに答えるために使われます。

  • ある疾患の患者と健常者で、どの遺伝子の発現が変化しているか
  • 薬剤を投与した前後で、細胞内のどの経路が活性化・抑制されたか
  • 発生過程の各段階で、どの遺伝子がオン・オフされるか
  • がん細胞と正常細胞で、特異的に発現している遺伝子は何か

トランスクリプトーム解析の代表的な手法が、次のセクションで説明する**RNA-seq(RNA sequencing)**です。

なぜゲノム解析だけでは不十分なのか

「ゲノムを読めばすべてわかるのでは?」と思う方もいるかもしれません。しかし、ゲノム配列は基本的に「静的な情報」であり、以下のことはゲノムだけでは直接わかりません。

知りたいこと ゲノム トランスクリプトーム
遺伝子の配列・構造
遺伝子の発現量(いまどれだけ使われているか)
条件による発現変動
スプライシングバリアント(同じ遺伝子由来の異なるRNA) △(予測のみ)
組織・細胞種ごとの違い

このように、トランスクリプトーム解析は「遺伝子がどれだけ活動しているか」というダイナミックな情報を捉えるための手法であり、ゲノム解析とは相補的な関係にあります。

bulk RNA-seqとは何か?

📖 このセクションで学ぶこと:RNA-seqの基本原理、bulk RNA-seqとsingle-cell RNA-seq(scRNA-seq)の違い、そしてbulk RNA-seqが適している場面と限界を理解します。

RNA-seqの基本原理

**RNA-seq(RNA sequencing)**とは、細胞や組織から抽出したRNAを次世代シーケンサー(NGS: Next-Generation Sequencer)で網羅的に読み取る技術です。基本的な流れは以下の通りです。

1. RNA抽出
   細胞や組織からRNAを取り出す

2. ライブラリ調製
   RNAをcDNA(相補的DNA)に逆転写し、
   アダプター配列を付加してシーケンス可能な形にする

3. シーケンシング
   NGSでcDNA断片を大量に読み取り、
   短い配列(リード)として出力する → FASTQファイル

4. データ解析
   リードを参照ゲノムにマッピングし、
   各遺伝子の発現量を定量する → カウント行列

この「大量のリードを使って遺伝子発現を網羅的に測定する」のがRNA-seqの本質です。以前はマイクロアレイが主流でしたが、RNA-seqはダイナミックレンジが広く、未知の転写産物も検出できるため、現在ではトランスクリプトーム解析の標準手法となっています。

bulk RNA-seqとは

bulk RNA-seqとは、多数の細胞をまとめて(バルクで)RNA抽出し、その集団全体の遺伝子発現プロファイルを測定するRNA-seqのことです。

🔬 bulk RNA-seq のイメージ

  組織サンプル(数千〜数百万の細胞)
        │
        ▼
  まとめてRNA抽出 ← すべての細胞のRNAが混合される
        │
        ▼
  シーケンシング
        │
        ▼
  遺伝子発現プロファイル ← 細胞集団の「平均的な」発現量

つまり、bulk RNA-seqの結果は「その組織(または細胞集団)に含まれるすべての細胞のRNA発現の平均値」を反映しています。

bulk RNA-seq と single-cell RNA-seq(scRNA-seq)の違い

近年注目されているsingle-cell RNA-seq(scRNA-seq)との違いを整理しておきましょう。

比較項目 bulk RNA-seq scRNA-seq
解析単位 細胞集団(組織全体) 個々の細胞
得られる情報 集団の平均的な発現プロファイル 細胞ごとの発現プロファイル
1サンプルあたりのコスト 比較的低い 高い
必要なRNA量 比較的少量でOK 極微量(1細胞分)
データ解析の複雑さ 標準的なパイプラインが確立 より複雑(次元削減、クラスタリング等)
細胞種の不均一性 検出しにくい(平均化される) 検出できる
生物学的反復 複数サンプルで統計的検定が容易 サンプル数の確保が課題になりやすい
主な用途 群間比較(疾患 vs 正常、処理 vs 未処理) 細胞タイプの同定、細胞状態の解析

bulk RNA-seqが適している場面

bulk RNA-seqは「古い技術」ではありません。以下のような場面では、2026年時点でも第一選択となります。

  • 群間の差次的発現解析(DEG解析):疾患群と対照群、薬剤処理群と未処理群の比較など
  • 多数のサンプルを効率的に処理したい場合:臨床コホート研究、タイムコース実験など
  • 統計的に堅牢な比較を行いたい場合:生物学的反復を十分に確保した上での検定
  • パスウェイ解析やGSEAなどの下流解析に接続したい場合
  • コストや計算リソースに制約がある場合

bulk RNA-seqの限界

一方で、以下のような限界があることも理解しておく必要があります。

  • 細胞種の不均一性を直接解像できない:異なる細胞種が混在する組織では、少数派の細胞の発現変化が平均化されて見えなくなることがある
  • 希少な細胞集団の検出が困難:腫瘍微小環境中の免疫細胞サブセットなど
  • 空間的な情報が失われる:組織のどの位置にどの遺伝子発現パターンがあるかは、spatial transcriptomicsの領域

💡 初心者の方へ:まずはbulk RNA-seqの解析手法をしっかり身につけることをおすすめします。bulk RNA-seqで学ぶ品質管理、マッピング、発現定量の概念は、scRNA-seqやspatial transcriptomicsを学ぶ際にも基盤となります。


RNA-seqの実験から解析までの全体像

📖 このセクションで学ぶこと:RNA-seq実験のウェット(実験操作)とドライ(データ解析)の全体の流れを俯瞰し、本記事で扱う「一次解析」が全体のどこに位置するかを理解します。

RNA-seqプロジェクトは、大きく**ウェット工程(実験操作)ドライ工程(データ解析)**に分かれます。以下に、サンプル採取から生物学的知見の獲得までの全体像を示します。

全体フロー

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  ウェット工程(実験操作)         ← 実験者・シーケンス施設が担当
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  1. 実験デザイン
     ├─ 比較群の設定(疾患 vs 正常、処理 vs 未処理 など)
     ├─ 生物学的反復数の決定(※統計的検出力に直結)
     └─ サンプル採取・保存方法の決定

  2. RNA抽出
     └─ 組織・細胞からtotal RNAを抽出

  3. ライブラリ調製
     ├─ mRNA選択(poly(A) selection)or rRNA除去(rRNA depletion)
     ├─ cDNAへの逆転写
     ├─ 断片化
     └─ アダプター付加・PCR増幅

  4. シーケンシング
     ├─ シーケンサーにライブラリをロード(例:Illumina NovaSeq, NextSeq)
     └─ 出力:BCLファイル → FASTQ変換

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  ドライ工程(データ解析)          ← バイオインフォマティシャンが担当
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  5. 一次解析 ★本記事の対象★
     ├─ FASTQ品質確認(FastQC / MultiQC)
     ├─ アダプタ除去・トリミング(必要時のみ)
     ├─ リードのマッピング(STAR)or 擬似アラインメント(Salmon)
     ├─ 遺伝子発現定量(featureCounts / Salmon)
     ├─ マッピング後QC(RSeQC等)
     └─ 出力:遺伝子発現カウント行列

  6. 二次解析
     ├─ 正規化(DESeq2 / edgeR内部で実施)
     ├─ サンプルQC(PCA、階層クラスタリング)
     └─ 差次的発現解析(DEG解析)

  7. 三次解析
     ├─ Gene Ontology(GO)解析
     ├─ パスウェイ解析(KEGG等)
     ├─ GSEA(Gene Set Enrichment Analysis)
     └─ 生物学的解釈・論文化

ウェット工程のポイント

実験操作の詳細は本記事の範囲外ですが、ドライ解析を行ううえで以下の情報は実験者から必ず受け取ってください。一次解析のパラメータ設定に直接影響します。

実験者から受け取るべき情報 なぜ必要か 一次解析での影響箇所
ライブラリ調製キット名 stranded/unstrandedの判断に必要 featureCountsの-sオプション、Salmonのlibtype
single-end / paired-end FASTQ入力方法が変わる すべてのツールの入力設定
read長 STARのsjdbOverhang設定等 STARのindex作成、マッピング精度
生物種 参照ゲノム・アノテーションの選択 genome FASTA、GTFの取得元
poly(A) selection / rRNA depletion 期待されるリード組成が変わる QC結果の解釈、rRNA残存率の評価

ドライ工程の3段階

ドライ工程は以下の3段階に分かれます。本記事のパート2で詳しく解説するのは一次解析です。

段階 入力 出力 主なツール
一次解析 FASTQファイル 遺伝子発現カウント行列 FastQC, STAR, Salmon, featureCounts
二次解析 カウント行列 DEGリスト、PCAプロット等 DESeq2, edgeR, limma-voom
三次解析 DEGリスト等 生物学的知見 clusterProfiler, fgsea, DAVID

一次解析の位置づけ(なぜ最も重要か)

一次解析は「地味な前処理」に見えるかもしれませんが、実は解析全体の信頼性を決定づける最も重要な工程です。

理由は明確です。一次解析で作られるカウント行列の品質が悪ければ、その後の二次解析・三次解析でどれほど高度な統計手法を使っても、正しい結論は得られません。具体的には、参照ゲノムの選択ミス、strandedness設定の誤り、不適切なトリミングなどが一次解析で発生すると、下流のDEG解析で偽陽性や偽陰性が大量に発生します。

逆に、一次解析が正確であれば、二次解析以降は統計的手法の選択に集中でき、結果の解釈もスムーズになります。

💡 初心者の方へ:「とりあえずパイプラインを回せばOK」と思われがちですが、各ステップでなぜその設定にするのかを理解していることが、トラブルシューティングや結果の解釈で大きな差になります。本記事のパート2では、各ステップの「なぜ」を丁寧に解説します。


本記事で使う用語集

📖 このセクションで学ぶこと:本記事で頻出する専門用語を一覧で整理します。初心者の方は一読しておくとパート2以降の理解がスムーズになります。中級者の方は、混同しやすい用語の整理にご活用ください。

基本用語

用語 英語表記 意味
リード(read) read シーケンサーが読み取った短いDNA/RNA配列の断片。1回の読み取りで得られる1本の配列。典型的には75〜150塩基程度
FASTQ FASTQ シーケンサーの出力ファイル形式。各リードの塩基配列とその品質スコア(Phredスコア)がセットで記録されている
参照ゲノム reference genome リードのマッピング先となる、その生物種の標準的なゲノム配列(例:ヒトならGRCh38)
アノテーション(注釈) annotation ゲノム上のどこにどの遺伝子があるかを記述した情報。GTF/GFF形式で提供される
カウント行列 count matrix 行が遺伝子、列がサンプルで構成される表。各セルにはその遺伝子のリード数(発現量)が入る。一次解析の最終成果物

シーケンシング関連用語

用語 英語表記 意味
NGS Next-Generation Sequencing 次世代シーケンサーの総称。大量のDNA/RNA断片を並行して読み取る技術
paired-end(PE) paired-end sequencing 1つのDNA断片の両端からリードを取得する方式。R1とR2の2本のリードが得られる
single-end(SE) single-end sequencing 1つのDNA断片の片端からのみリードを取得する方式
read長 read length 1本のリードの塩基数(例:150 bp)
アダプター adapter ライブラリ調製時にDNA断片の両端に付加される短い人工配列。シーケンサーが断片を認識するために必要だが、解析時には除去が必要な場合がある
stranded library stranded library 元のRNAがどちらの鎖(sense/antisense)由来かの情報を保持するライブラリ。発現定量の正確性向上に寄与
シーケンス深度 sequencing depth 1サンプルあたりに得られるリード数の総量。一般的にbulk RNA-seqでは数千万リード/サンプルが目安

マッピング・定量関連用語

用語 英語表記 意味
マッピング mapping リードを参照配列上の位置に対応付ける処理の総称
アラインメント alignment リードと参照配列の塩基レベルでの対応付け。ギャップやミスマッチを考慮した厳密な位置合わせ
スプライスアラインメント splice-aware alignment RNA-seqのリードがイントロンをまたぐ場合に対応するアラインメント。STARなどが対応
擬似アラインメント pseudoalignment リードを転写産物に高速に対応付ける手法。厳密な塩基アラインメントは行わず、k-merベースで帰属先を推定。Salmonなどが使用
BAM Binary Alignment Map アラインメント結果を格納するバイナリ形式のファイル。ゲノム座標、マッピング品質などを含む
発現定量 quantification 各遺伝子(または転写産物)に帰属するリード数を数える処理
raw counts raw counts 正規化前のリードカウント数。DESeq2やedgeRへの入力に使用

混同しやすい用語の整理

マッピング vs アラインメント

日常的にはほぼ同義で使われますが、厳密には以下のような使い分けがあります。

マッピング(mapping) アラインメント(alignment)
意味 リードを参照配列上の位置に対応付ける処理全般 塩基レベルでの厳密な位置合わせ
範囲 広い(擬似アラインメント等も含む) 狭い(マッピングの一手法)
「Salmonでマッピングする」 「STARでアラインメントする」

本記事では、位置合わせの処理全般を指すときはマッピング、STARなどによる厳密な位置合わせを指すときはアラインメントと表記します。

TPM vs FPKM vs raw counts

発現量の表現方法には複数の種類があり、用途によって使い分けが必要です。

指標 正式名称 特徴 主な用途
raw counts 遺伝子に帰属したリードの生カウント数 DESeq2/edgeRへの入力(DEG解析)
TPM Transcripts Per Million 遺伝子長とライブラリサイズで正規化。サンプル内比較に適する 可視化、サンプル内の相対比較
FPKM/RPKM Fragments/Reads Per Kilobase per Million 遺伝子長とライブラリサイズで正規化(TPMとは計算順序が異なる) 古い論文で使用。現在はTPMが推奨

⚠️ 重要:DEG解析(DESeq2/edgeR)にはraw countsまたはtximport経由のcount相当量を使います。TPMやFPKMをDEG解析に直接入力するのは不適切です。DESeq2やedgeRは内部で独自の正規化を行うため、事前に正規化された値を渡すと統計モデルの前提が崩れます。

QC(Quality Control)

QCは「品質管理」を意味しますが、RNA-seq解析では複数の段階でQCを行います。

QCの段階 タイミング 確認する内容 主なツール
FASTQ QC シーケンシング直後 リードの塩基品質、アダプター混入、GC含量の偏り FastQC, MultiQC
マッピング後QC アラインメント後 マッピング率、遺伝子body coverage、strandedness RSeQC, MultiQC
サンプルQC 二次解析の冒頭 サンプル間の類似性、外れ値サンプルの検出 PCA、階層クラスタリング

パート2:一次解析の実践


はじめに:一次解析とは何か

📖 このセクションで学ぶこと:RNA-seq解析における一次解析・二次解析・三次解析の区分と、一次解析で具体的に何を行うのかを理解します。

ここからが本記事のメインパートです。パート1で学んだ背景知識をもとに、bulk RNA-seqの一次解析を一つずつ見ていきましょう。

RNA-seq解析の3段階

RNA-seq解析は大きく次の3段階に分けられます。パート1の「RNA-seqの実験から解析までの全体像」でも触れましたが、ここで改めて各段階の役割を整理します。

段階 目的 入力 出力
一次解析(本記事の対象) 生データを遺伝子発現量に変換する FASTQファイル カウント行列
二次解析 統計的に発現変動を検出する カウント行列 DEGリスト、PCAプロット等
三次解析 生物学的な意味を解釈する DEGリスト等 パスウェイ、機能アノテーション

一次解析で行うこと

本記事で扱う一次解析では、具体的に以下の6つのステップを実行します。

  FASTQファイル(シーケンサーの出力)
        │
        ▼
  Step 1: FASTQ品質評価(QC)         ← データの状態を把握する
        │
        ▼
  Step 2: アダプタ除去・トリミング     ← 必要な場合のみ実施
        │
        ▼
  Step 3: マッピング / 擬似アラインメント  ← リードをゲノムや転写産物に対応付ける
        │
        ▼
  Step 4: 発現定量                     ← 遺伝子ごとのリード数を数える
        │
        ▼
  Step 5: マッピング後QC              ← マッピング結果の品質を確認する
        │
        ▼
  Step 6: カウント行列作成             ← 二次解析への入力データを整える
        │
        ▼
  遺伝子発現カウント行列(一次解析の成果物)

一次解析の目的を一言で表すと

「実験由来のシーケンスデータを、統計解析可能な遺伝子発現行列へ正確に変換すること」

「正確に」というのがポイントです。単にカウント行列を作れればよいのではなく、参照ゲノムの選択、strandedness設定、アノテーションの整合性など、各ステップの設定が適切であってはじめて、信頼性のある結果が得られます。

パート1の「RNA-seqの実験から解析までの全体像」で述べたとおり、一次解析の品質が二次解析・三次解析の信頼性をすべて決定づけます。ここからの各ステップを、「なぜその設定にするのか」を意識しながら見ていきましょう。

bulk RNA-seq全体像の中での一次解析の位置づけ

📖 このセクションで学ぶこと:一次解析が生み出す具体的なファイルと、それが二次・三次解析でどのように使われるかを理解します。

前のセクションで一次解析の全体像を示しました。ここでは、各段階で実際にどのようなファイルが生まれ、どこへ渡されるかをより具体的に見ていきます。

データの流れとファイル形式

  シーケンサー
    │
    ▼
  BCLファイル → bcl2fastqで変換
    │
    ▼
  ┌─────────────────────────────────────────────┐
  │  FASTQファイル(.fastq.gz)                    │
  │  └ 各リードの塩基配列 + 品質スコア             │
  └─────────────────────────────────────────────┘
    │
    │  ★ 一次解析ここから ★
    ▼
  ┌─────────────────────────────────────────────┐
  │  QCレポート(FastQC HTML, MultiQC HTML)       │
  │  └ 品質の可視化・集約レポート                   │
  └─────────────────────────────────────────────┘
    │
    ▼
  ┌─────────────────────────────────────────────┐
  │  BAMファイル(STAR使用時)                      │
  │  └ ゲノム座標へのアラインメント結果             │
  │  または                                        │
  │  quant.sf(Salmon使用時)                      │
  │  └ 転写産物ごとの定量結果                      │
  └─────────────────────────────────────────────┘
    │
    ▼
  ┌─────────────────────────────────────────────┐
  │  カウント行列(gene_counts.txt / tximport出力) │
  │  └ 行:遺伝子、列:サンプル、値:リード数      │
  │  ★ 一次解析ここまで ★                          │
  └─────────────────────────────────────────────┘
    │
    │  二次解析へ
    ▼
  ┌─────────────────────────────────────────────┐
  │  DESeq2 / edgeR                                │
  │  └ 正規化 → DEG検出 → 結果テーブル            │
  └─────────────────────────────────────────────┘
    │
    │  三次解析へ
    ▼
  ┌─────────────────────────────────────────────┐
  │  パスウェイ解析 / GSEA                          │
  │  └ 生物学的解釈                                │
  └─────────────────────────────────────────────┘

一次解析が「正しくない」とどうなるか

一次解析は「単なる前処理」ではなく、後続の全解析の信頼性を決定づける工程です。ここでのミスは下流で取り返しがつきません。

一次解析のミス 発生する問題 影響の深刻さ
参照ゲノムの生物種を間違える マッピング率が極端に低下し、カウントがほぼゼロになる 🔴 致命的
strandedness設定を誤る sense/antisenseの発現量が入れ替わり、カウントが半減〜崩壊する 🔴 致命的
genome FASTAとGTFのバージョンが不一致 染色体名不一致でカウントが欠損する 🟠 重大
過剰なトリミング リードが短くなりすぎてマッピング率が低下する 🟡 中程度

このように、一次解析の各ステップには「なぜその設定にするのか」という明確な根拠があります。次のセクション以降で、各ステップの詳細と判断基準を順番に見ていきましょう。

解析開始前に必ず確認すべき実験情報

このセクションで学ぶこと

  • 一次解析に入る前に確認すべき 4つの実験情報 とその理由
  • stranded / unstranded ライブラリの違いと解析への影響
  • single-end / paired-end の選び方と使い分け
  • 参照ゲノム・アノテーションのバージョン管理の重要性
  • シーケンス深度とサンプル数のバランス

一次解析に入る前に、以下の4つの実験情報を必ず整理しましょう。これらを把握していないと、ツールの設定ミス → 結果の信頼性低下 という事態に直結します。

┌─────────────────────────────────────────────────────────┐
│          解析前に確認すべき 4つの実験情報                │
├──────────────┬──────────────────────────────────────────┤
│ 1. ライブラリ │ stranded? unstranded? キット名は?       │
│ 2. リード構成 │ single-end? paired-end? リード長は?     │
│ 3. 参照配列   │ genome build? annotation version?        │
│ 4. 深度目安   │ 何 million reads/sample? 複製数は?      │
└──────────────┴──────────────────────────────────────────┘
         ↓ すべて揃ったら一次解析スタート!

💡 初心者向けTip: これらの情報は、実験担当者やシーケンス受託会社からもらえる「サンプルシート」「納品レポート」に記載されていることがほとんどです。解析を始める前に必ず手元に用意しましょう。


1. ライブラリタイプ(Library Type)

確認すべき項目:

項目 確認内容
Strandedness strand情報を保持しているか stranded / unstranded
選択方法 mRNAの濃縮方法 poly(A) selection / rRNA depletion
使用キット 実験で使ったキット名 TruSeq Stranded mRNA, NEBNext など

stranded と unstranded の違い

stranded library(鎖特異的ライブラリ) は、元のRNAがどちらのDNA鎖(sense / antisense)から転写されたかの情報を保持しています。一方、unstranded library はその向き情報を保持しません。

比較項目 stranded unstranded
sense / antisense の区別 ⭕ 可能 ❌ 不可
オーバーラップ遺伝子の正確なカウント ⭕ 有利 ⚠️ 誤カウントのリスク
antisense 転写の検出 ⭕ 可能 ❌ 困難
解析時の設定 strand 指定が必要 設定はシンプル
現在の主流 2026年の標準 レガシーデータに多い

💡 中級者向けTip: featureCounts の -s オプションや Salmon の --libType パラメータは、このstrandedness情報に基づいて設定します。設定を間違えると、カウント値が大幅にずれるため、最も注意すべきパラメータの一つです。stranded libraryでは featureCounts で -s 2(dUTP法の場合)、Salmon では -l A(自動検出)が安全です。

poly(A) selection と rRNA depletion

方法 原理 対象RNA 適した用途
poly(A) selection mRNAのポリAテールを利用して捕捉 主にmRNA 遺伝子発現解析(標準的)
rRNA depletion rRNAを除去して残りを取得 mRNA + non-coding RNA lncRNA解析、分解サンプルなど

2. リード構成(Read Configuration)

項目 確認内容
リードタイプ single-end (SE) か paired-end (PE) か SE / PE
リード長 1リードあたりの塩基数 50bp, 100bp, 150bp
インサートサイズ PE の場合のフラグメント長 200〜400bp(キットに依存)

single-end と paired-end の違い

【Single-end (SE)】
  ───────────→          片方向からのみ読む
  リード1本/フラグメント

【Paired-end (PE)】
  ───────────→          ←───────────
  Read 1                Read 2
  両方向から読む → フラグメント全体の情報が得られる
比較項目 Single-end (SE) Paired-end (PE)
コスト 安い やや高い
マッピング精度 標準的 高い(特にリピート領域)
スプライスジャンクション検出 基本的に可能 より正確
novel transcript / fusion 検出 限定的 有利
一般的な遺伝子カウント ✅ 十分 ✅ 十分

Illumina は paired-end sequencing の利点として、genomic rearrangements、novel transcripts、repetitive sequence elements、gene fusions の検出に有利であることを挙げています。一般的な遺伝子発現比較(DEG解析)が目的であれば SE でも十分ですが、転写産物構造やスプライスバリアントを詳しく調べたい場合は PE が推奨されます。


3. 参照配列とアノテーション(Reference & Annotation)

参照ゲノムとアノテーション(遺伝子注釈)は、一次解析の土台です。ここがずれていると、すべてのダウンストリーム解析に影響します。

確認項目 内容
Genome build ゲノムアセンブリのバージョン GRCh38(ヒト), GRCm39(マウス)
Annotation source アノテーションの提供元 GENCODE, Ensembl, RefSeq
Annotation version アノテーションのバージョン GENCODE v46, Ensembl 112
ファイル整合性 FASTAとGTF/GFFのバージョンが一致しているか ⚠️ 最重要チェック項目

⚠️ よくあるミス: FASTA の染色体名が chr1 形式(UCSC系)なのに、GTFが 1 形式(Ensembl系)になっている → STARやHISAT2でアラインメントが0%になる典型パターンです。必ず両方のファイルで染色体名の形式を確認しましょう。

【正しい組み合わせの例】
  GENCODE の FASTA (chr1, chr2, ...)  +  GENCODE の GTF (chr1, chr2, ...)  → ⭕ OK
  Ensembl の FASTA (1, 2, ...)        +  Ensembl の GTF (1, 2, ...)        → ⭕ OK

【NGな組み合わせ】
  GENCODE の FASTA (chr1, chr2, ...)  +  Ensembl の GTF (1, 2, ...)        → ❌ NG!

4. 期待シーケンス深度とサンプル数

bulk RNA-seqにおけるシーケンス深度(リード数)は、検出感度に直接関わります。

目的 推奨深度(目安) 備考
一般的な遺伝子発現比較(DEG) 20〜30 M reads/sample 多くの研究で標準的
低発現遺伝子の検出 40〜60 M reads/sample lncRNAなど
スプライスバリアント解析 60〜100 M reads/sample 高深度が必要

💡 重要:深度 vs 複製数のトレードオフ
DEG解析においては、1サンプルの深度を上げるよりも、生物学的複製(biological replicate)の数を増やす方が統計的検出力が上がることが多いです。予算が限られている場合は、少ないリード数でもサンプル数を確保する戦略を検討しましょう。

💡 初心者向けTip: シーケンス深度は「何 million reads」で表します。「30M reads」は3,000万本のリードという意味です。この数字は FASTQ ファイルのリード数(行数 ÷ 4)から確認できます。

一次解析の標準ワークフロー

このセクションで学ぶこと

  • 一次解析の 標準的な7ステップ の全体像
  • 各ステップで使うツールと生成されるファイル
  • 2つの主要パイプライン(ゲノムアラインメント型 vs 擬似アラインメント型)の違い
  • 自分の目的に合ったパイプラインの選び方

2026年時点でも、bulk RNA-seqの一次解析は以下の流れが標準的です。各ステップで何をするかなぜ必要か何が出力されるかを意識しながら見ていきましょう。

全体フロー

 ┌─────────────────────────────────────────────────────────────────┐
 │                  一次解析の標準ワークフロー                     │
 ├────────┬──────────────────────┬─────────────────────────────────┤
 │ Step   │ 処理内容             │ 主なツール → 出力ファイル       │
 ├────────┼──────────────────────┼─────────────────────────────────┤
 │ Step 0 │ 解析環境の構築       │ conda/mamba → environment.yml  │
 │ Step 1 │ FASTQの品質評価(QC)  │ FastQC/MultiQC → HTML レポート │
 │ Step 2 │ アダプタ除去/トリム  │ fastp/Trim Galore → FASTQ      │
 │ Step 3 │ アラインメント/定量  │ STAR or Salmon → BAM or quant  │
 │ Step 4 │ 発現定量             │ featureCounts/Salmon → counts  │
 │ Step 5 │ マッピング後QC       │ RSeQC/Picard → QCレポート      │
 │ Step 6 │ カウント行列作成     │ R/tximport → count matrix      │
 └────────┴──────────────────────┴─────────────────────────────────┘
          ↓ 完成した count matrix を二次解析(DEG解析等)へ渡す

💡 初心者向けTip: 上のフローは「レシピの手順」のようなものです。Step 1から順にこなしていけば、最終的に**カウント行列(count matrix)**という「遺伝子 × サンプル」の数値表が完成します。これが二次解析の入力データになります。

2つの主要パイプライン

ツール選択としては、大きく次の 2系統 があります。目的に応じて使い分けましょう。

比較項目 ゲノムアラインメント型 擬似アラインメント型
代表ツール STAR + featureCounts Salmon(+ tximport)
処理の仕組み リードをゲノムにマッピング → 遺伝子領域のリードをカウント 転写産物配列に対して擬似アラインメント → 直接定量
出力ファイル BAMファイル + カウント行列 quant.sf + カウント行列
処理速度 やや遅い(BAM生成に時間) 高速(BAM不要)
ディスク使用量 大(BAMが数十GB) 小(BAMを生成しない)
スプライシング解析 ⭕ 可能(BAMから確認) ⚠️ 限定的
IGV等での可視化 ⭕ 可能(BAMを使用) ❌ 不可(BAMがない)
gene-level DEG解析 ✅ 十分 十分(推奨される場面も多い)
【パイプラインA:ゲノムアラインメント型】
  FASTQ → FastQC → (fastp) → STAR → featureCounts → count matrix
                                ↓
                              BAMファイル(IGV可視化・追加QCに使用)

【パイプラインB:擬似アラインメント型】
  FASTQ → FastQC → (fastp) → Salmon → tximport → count matrix
                              (高速・軽量、BAMなし)

💡 どちらを選ぶべきか?

  • 遺伝子発現量の比較(DEG解析)が主目的 → Salmon + tximport が高速・軽量で実務的に有力
  • スプライシング解析・IGVでの可視化・BAMベースの追加QCが必要 → STAR + featureCounts が有利
  • 迷ったら? → まず Salmon で高速に結果を得て、必要に応じて STAR で補完する「ハイブリッド戦略」も実践的です

以降のセクションでは、各Stepを順番に詳しく解説していきます。

Step 0: 解析環境と再現性の確保

このセクションで学ぶこと

  • なぜ解析環境の「再現性」が重要なのか
  • 固定すべき 8つの項目 とその理由
  • Conda/Docker/ワークフローエンジンの使い分け
  • 実際の環境構築コマンド例

RNA-seq一次解析では、「正しく動いた」だけでなく「後から同じ結果を再現できる」ことが非常に重要です。ツールのバージョンが変わるだけで、マッピング率やカウント値が微妙に変わることがあります。

💡 初心者向けTip: 「再現性」とは、同じデータ・同じ手順で解析したら、誰がいつやっても同じ結果が得られることです。論文の査読で「解析を再現できない」と指摘されるのは致命的です。最初から環境を記録しておく習慣をつけましょう。


固定すべき8つの項目

以下の項目をすべて記録しておくことで、将来の再解析・共同研究者との共有・論文執筆時の Methods 記述がスムーズになります。

# 固定すべき項目 具体例 記録しないとどうなるか
1 使用ツール名とバージョン STAR 2.7.11b, Salmon 1.10.3 バージョン違いで結果が変わる
2 Genome FASTA GRCh38.primary_assembly.fa 異なるアセンブリで座標がずれる
3 Annotation GTF/GFF gencode.v46.annotation.gtf 遺伝子定義の違いでカウントが変わる
4 Index 作成条件 STAR: sjdbOverhang=149 インデックス不一致でエラー
5 実行コマンド 全パラメータを含む完全なコマンド パラメータ忘れで再現不能
6 サンプル対応表 sample_id, group, batch 等 どのFASTQがどの条件か不明に
7 Strandedness 指定 stranded (dUTP), -s 2 カウント値が半減〜崩壊
8 環境定義ファイル environment.yml, Dockerfile 他の人が環境を構築できない

⚠️ よくあるミス: 「動いたからOK」で環境情報を記録せず、半年後に追加サンプルを解析しようとしたら同じ結果が出ない — これは非常によくあるトラブルです。


推奨される環境管理の方法

目的やスキルレベルに応じて、以下のツールを使い分けます。

方法 難易度 特徴 推奨場面
Conda / Mamba パッケージ管理。environment.yml で環境を定義・共有 個人解析、初心者の第一歩
Docker / Singularity (Apptainer) ⭐⭐ OS含めた完全な環境のコンテナ化 共同研究、論文投稿時の再現性保証
Nextflow / Snakemake ⭐⭐⭐ ワークフローエンジン。パイプライン全体を定義・自動実行 大規模解析、定常的なパイプライン運用
【再現性のレベル】

  レベル1(最低限):コマンド履歴 + ツールバージョンのメモ
       ↓
  レベル2(推奨)  :Conda environment.yml で環境を定義
       ↓
  レベル3(理想)  :Docker/Singularity + Nextflow/Snakemake
                     → 完全自動で再現可能なパイプライン

💡 中級者向けTip: nf-core/rnaseq のような公開パイプラインは、Nextflow + Docker/Singularity で構築されており、再現性のレベル3を実現しています。自前でパイプラインを組む場合も、これらを参考にすると良いでしょう。


実践例:Mambaで解析環境を構築

以下のコマンドで、一次解析に必要な主要ツールを一括インストールできます。

# 環境の作成(初回のみ)
mamba create -n bulk-rnaseq-2026 -y \
  fastqc=0.12.1 \
  multiqc=1.25 \
  star=2.7.11b \
  salmon=1.10.3 \
  subread=2.0.6 \
  fastp=0.23.4 \
  rseqc=5.0.3 \
  samtools=1.20 \
  -c bioconda -c conda-forge
# 環境の有効化
conda activate bulk-rnaseq-2026
# 環境定義をファイルに書き出し(共有・再現用)
conda env export > environment.yml

💡 初心者向けTip: mambaconda の高速版です。使い方はほぼ同じですが、依存関係の解決が圧倒的に速いため、bioconda のような大規模リポジトリでは mamba の利用を強く推奨します。まだインストールしていない場合は、Miniforge の導入から始めましょう。

Step 1: FASTQの品質評価(QC)

このセクションで学ぶこと

  • FASTQファイルとは何か、その構造
  • FastQC / MultiQC による品質チェックの実行方法
  • QCレポートで 重点的に見るべき7項目 とその判断基準
  • RNA-seq特有の「FAIL でも問題ない」ケースの見極め方

一次解析の最初のステップは、受け取ったFASTQファイルの品質を確認することです。ここで異常を見逃すと、後続のすべてのステップに影響します。

💡 初心者向けTip: FASTQファイルは、シーケンサーから出力される「生データ」です。1リードごとに「塩基配列」と「各塩基の品質スコア(信頼度)」がセットで記録されています。以下が1リード分の構造です:

@SRR12345678.1                    ← リードID(識別子)
ATCGATCGATCGATCGATCGATCG          ← 塩基配列(A, T, C, G の並び)
+                                  ← 区切り記号
IIIIIIIIIIIHHHHHFFFFFFBB          ← 品質スコア(ASCII文字で表現)

品質スコアは Phredスコア と呼ばれ、文字が「I」に近いほど高品質(Q30以上 = 精度99.9%以上)、「B」や「#」に近いほど低品質です。


実行方法:FastQC + MultiQC

FastQC は各FASTQファイルの品質レポートを生成し、MultiQC は複数サンプルのレポートを1つのHTMLにまとめてくれるツールです。

# 出力ディレクトリの作成
mkdir -p qc/fastqc_raw

# FastQC の実行(全FASTQファイルに対して)
fastqc -o qc/fastqc_raw -t 8 *.fastq.gz

# MultiQC で集約レポートを作成
multiqc qc/fastqc_raw -o qc/multiqc_raw
【QCの流れ】
  sample_1.fastq.gz → FastQC → sample_1_fastqc.html  ─┐
  sample_2.fastq.gz → FastQC → sample_2_fastqc.html  ─┤→ MultiQC → multiqc_report.html
  sample_3.fastq.gz → FastQC → sample_3_fastqc.html  ─┘    (全サンプル一覧レポート)

💡 初心者向けTip: -t 8 はスレッド数(並列処理数)の指定です。サーバーのCPUコア数に応じて調整してください。サンプル数が多い場合、MultiQC のレポートで全サンプルを俯瞰するのが効率的です。


QCレポートで見るべき7項目

FastQC のレポートには多数の項目がありますが、RNA-seq一次解析で特に重要な7項目を以下にまとめます。

# 項目名 何を見るか 判断基準
1 Per base sequence quality 各位置の品質スコア分布 📊 大部分がQ30以上(緑ゾーン)ならOK。末端の低下は許容範囲
2 Per sequence quality scores リード全体の平均品質分布 📊 ピークがQ30以上にあればOK
3 Per base sequence content 各位置の塩基組成比率 ⚠️ RNA-seqでは先頭10bp程度の偏りは正常(ランダムプライミングの特性)
4 Per sequence GC content GC含量の分布 📊 理論分布と大きくずれていたら汚染の可能性
5 Sequence duplication levels リードの重複率 ⚠️ RNA-seqでは高発現遺伝子由来の重複は正常。極端な場合はライブラリ複雑性の問題
6 Overrepresented sequences 頻出する特定配列 🔍 アダプター配列やrRNA配列が出ていないか確認
7 Adapter content アダプター残存率 ❗ 右肩上がりの場合はトリミングが必要(Step 2で対応)

RNA-seqでの「FAIL」の読み方

FastQC の PASS / WARN / FAIL 判定は、ゲノムDNA向けの基準で設計されています。そのため、RNA-seqでは以下のように「FAILでも正常」なケースがあります。

FastQCの項目 典型的な表示 RNA-seqでの解釈
Per base sequence content ⚠️ WARN / ❌ FAIL 先頭の偏りはランダムプライミングの影響で正常
Sequence duplication levels ❌ FAIL 高発現遺伝子の重複は正常(mRNAの偏りを反映)
Per sequence GC content ⚠️ WARN 生物種によってGC含量が異なるため多少のずれは許容
Overrepresented sequences ⚠️ WARN rRNA由来配列が少量混入するのは一般的

⚠️ 一方、以下のケースは本当に問題がある可能性が高いです:

  • Adapter content が右肩上がり → アダプター残存(Step 2でトリミング)
  • Per base quality が全体的にQ20以下 → ランの品質が低い(シーケンスセンターに問い合わせ)
  • GC content に複数のピーク → 別生物種の汚染の可能性

💡 中級者向けTip: MultiQCレポートでは、全サンプルの品質を一覧で比較できます。特に外れ値のサンプルがないかを確認しましょう。batch effect の検出にも役立ちます。また、fastqc --extract オプションを使うと、プログラムからパースしやすいテキスト形式でも出力されます。

Step 2: アダプタ除去・トリミングは本当に必要か

このセクションで学ぶこと

  • アダプター配列とは何か、なぜ混入するのか
  • 「常にトリミングする」が正解ではない 理由
  • トリミングすべきケースとしなくてよいケースの判断基準
  • fastp を使った実践的なトリミング方法
  • before / after の比較で効果を確認する方法

⚠️ 重要:「必ず最初にトリミングする」が正解ではありません。 過剰なトリミングはリード長を短くし、マッピング率や定量精度を下げるリスクがあります。Step 1 のQC結果を見て、必要な場合にだけ最小限のトリミングを行うのが正しいアプローチです。


アダプター配列とは

💡 初心者向けTip: シーケンシングでは、目的のRNA断片の両端に「アダプター配列」という人工的なDNA配列を付加します。これはシーケンサーがリードを認識するために必要ですが、リードが断片より長い場合、アダプター部分まで読んでしまうことがあります(read-through)。この余分な配列は解析に悪影響を及ぼすため、除去が必要です。

【アダプター混入のしくみ(read-through)】

  短いインサート(RNA断片)の場合:
  ──[アダプター]──[RNA断片]──[アダプター]──
  ──────────────────→ Read 1(リード長 > 断片長のとき)
                     ↑ここからアダプター配列が混入

  長いインサートの場合:
  ──[アダプター]──[  十分な長さのRNA断片  ]──[アダプター]──
  ──────────────────→ Read 1(断片内で読み終わる → 混入なし)

トリミングの判断フローチャート

Step 1 のQC結果に基づいて、以下のフローで判断しましょう。

  Step 1 の QC 結果を確認
       │
       ├── Adapter content が右肩上がり?
       │      YES → トリミング必要 ✂️
       │      NO  ↓
       ├── 末端の品質スコアが大幅に低下?(Q20以下が多い)
       │      YES → 品質トリミング検討 ✂️
       │      NO  ↓
       ├── 短いインサート由来の read-through がある?
       │      YES → アダプター除去必要 ✂️
       │      NO  ↓
       └── トリミングなしで Step 3 へ進む ✅
状況 判断 理由
adapter content 低い、末端品質も良好 スキップ 不要なトリミングはリード長低下のリスク
adapter が明確に混入 トリミング ✂️ アダプター配列がマッピングを阻害する
末端品質が大幅に低下 最小限のトリミング ✂️ 低品質塩基がマッピング精度を下げる
Salmon を使う予定 軽微なら省略可 Salmon は軽微なアダプター残存に頑健

💡 中級者向けTip: Salmon(擬似アラインメント)は、リード末端の低品質塩基や軽微なアダプター残存に対して比較的頑健です。STAR を使う場合でも、最近のバージョンはソフトクリッピングで対応できるケースが多いです。ただし、明確なアダプター汚染がある場合はどちらのツールでもトリミングを推奨します。


代表的なトリミングツール

ツール 特徴 推奨度(2026年)
fastp QC + トリミング + フィルタリングを一括処理。高速。HTMLレポート付き ⭐⭐⭐ 推奨
Trim Galore cutadapt + FastQC のラッパー。簡潔なコマンド ⭐⭐
cutadapt アダプター除去に特化。細かい制御が可能 ⭐⭐
Trimmomatic Java ベース。古くからの定番だが速度面でやや劣る

💡 初心者向けTip: 迷ったら fastp を選べば間違いありません。QCレポートの生成も同時にやってくれるので、FastQC の代替としても使えます。


実践例:fastp によるトリミング

# Paired-end の場合
fastp \
  -i sample_R1.fastq.gz \
  -I sample_R2.fastq.gz \
  -o sample.trimmed.R1.fastq.gz \
  -O sample.trimmed.R2.fastq.gz \
  --detect_adapter_for_pe \
  --qualified_quality_phred 20 \
  --length_required 36 \
  -h sample.fastp.html \
  -j sample.fastp.json \
  -w 4
オプション 意味
--detect_adapter_for_pe PE データのアダプターを自動検出して除去
--qualified_quality_phred 20 Q20未満の塩基を低品質とみなす
--length_required 36 トリミング後に36bp未満になったリードを除去
-h / -j HTML / JSON 形式のQCレポートを出力
-w 4 4スレッドで並列処理

before / after の比較を忘れずに

トリミング後は、必ず再度QCを実行して効果を確認しましょう。

# トリミング後のFASTQに対してFastQCを再実行
mkdir -p qc/fastqc_trimmed
fastqc -o qc/fastqc_trimmed -t 8 sample.trimmed.*.fastq.gz

# before / after を MultiQC で並べて比較
multiqc qc/fastqc_raw qc/fastqc_trimmed -o qc/multiqc_comparison

💡 チェックポイント: トリミング後に以下を確認しましょう。

  • Adapter content が解消されているか
  • 品質スコアが改善されているか
  • リード数が大幅に減少していないか(10%以上減った場合は設定を見直す)
  • 平均リード長が極端に短くなっていないか

Step 3: リードのアラインメント or 擬似アラインメント

このセクションで学ぶこと

  • アラインメントと擬似アラインメントの 違いと仕組み
  • STAR(ゲノムアラインメント)と Salmon(擬似アラインメント)の使い分け
  • それぞれの index 作成 → 実行 の具体的なコマンド
  • 各パラメータの意味と設定の根拠

一次解析の中心工程です。FASTQに含まれる数千万〜数億本のリードを、参照配列上の「どこ由来か」を特定し、遺伝子ごとの発現量を計算するための土台を作ります。

💡 初心者向けTip: アラインメントは「辞書で単語の出典を調べる」作業に似ています。リード(短い配列断片)がゲノムや転写産物のどの位置に対応するかを見つける処理です。


アラインメント vs 擬似アラインメント

2つの方法には根本的な仕組みの違いがあります。

【ゲノムアラインメント(STAR)】
  リード → ゲノム全体に対してスプライスアウェアでマッピング → BAMファイル
         → 各リードのゲノム上の座標が確定
         → BAMから遺伝子領域のリードをカウント(featureCounts)

【擬似アラインメント(Salmon)】
  リード → 転写産物配列に対して高速マッチング → 定量結果(quant.sf)
         → 各リードの「由来転写産物」を確率的に推定
         → BAMファイルを生成しない(高速・軽量)
比較項目 STAR(ゲノムアラインメント) Salmon(擬似アラインメント)
参照配列 ゲノム FASTA + GTF 転写産物 FASTA(cDNA配列)
処理の仕組み スプライスを考慮した厳密なアラインメント k-mer ベースの高速マッチング
出力 BAM ファイル(座標付き) quant.sf(転写産物ごとの定量値)
処理速度 数十分〜数時間/サンプル ⚡ 数分〜十数分/サンプル
メモリ使用量 約30〜40 GB(ヒトゲノム) 約5〜10 GB
ディスク使用量 大(BAM: 数GB〜数十GB/サンプル) 小(数MB/サンプル)
IGV等での可視化 ⭕ 可能 ❌ 不可
splice junction 解析 ⭕ 高精度 ❌ 不可
gene-level 発現定量 ⭕(+ featureCounts が必要) ⭕(直接出力、tximport で集約)

どちらを選ぶべきか

  あなたの解析目的は?
       │
       ├── 遺伝子発現量の比較(DEG解析)が主目的
       │      → Salmon がおすすめ(高速・軽量・高精度)
       │
       ├── BAM を使った可視化(IGV)やQCが必要
       │      → STAR が必須
       │
       ├── スプライシング解析をしたい
       │      → STAR が必須
       │
       ├── 多サンプル(数十〜数百)を効率的に処理したい
       │      → Salmon が圧倒的に有利
       │
       └── 迷っている
              → Salmon で高速に結果を得て、必要に応じて STAR を追加

💡 中級者向けTip: STAR と Salmon は排他的ではありません。Salmon で素早く発現定量を行い、一部の注目遺伝子について STAR + IGV で詳細確認する「ハイブリッド戦略」は実務的に非常に有効です。


STAR(ゲノムアラインメント)の実行

1. ゲノムインデックスの作成(初回のみ)

STAR \
  --runThreadN 16 \
  --runMode genomeGenerate \
  --genomeDir reference/star_index \
  --genomeFastaFiles reference/genome.fa \
  --sjdbGTFfile reference/annotation.gtf \
  --sjdbOverhang 149
パラメータ 意味 設定の根拠
--runThreadN 16 使用スレッド数 サーバーのコア数に合わせて調整
--genomeDir インデックスの保存先 再利用するため専用ディレクトリに保存
--genomeFastaFiles ゲノムFASTAファイル Step 0 で確認した参照ゲノム
--sjdbGTFfile アノテーションファイル FASTA とバージョンを合わせる(⚠️重要)
--sjdbOverhang 149 スプライスジャンクション周辺の読み取り長 リード長 - 1 を指定(150bp リードなら 149)

⚠️ 注意: --sjdbOverhang はリード長に依存します。100bp リードなら 99、150bp リードなら 149 を指定します。STAR マニュアルでも「ReadLength - 1」が推奨値とされています。

2. アラインメントの実行

STAR \
  --runThreadN 16 \
  --genomeDir reference/star_index \
  --readFilesIn sample_R1.fastq.gz sample_R2.fastq.gz \
  --readFilesCommand zcat \
  --outSAMtype BAM SortedByCoordinate \
  --quantMode GeneCounts \
  --outFileNamePrefix results/star/sample.
パラメータ 意味 設定の根拠
--readFilesIn 入力 FASTQ(PE の場合は R1 R2 の順) トリミング後のファイルがあればそちらを使用
--readFilesCommand zcat gzip 圧縮ファイルの展開コマンド .fastq.gz を直接入力するために必要
--outSAMtype BAM SortedByCoordinate 座標ソート済み BAM を直接出力 IGV 可視化や featureCounts にそのまま使える
--quantMode GeneCounts STAR 内蔵のカウント機能を有効化 簡易カウントが得られる(featureCounts も別途推奨)

Salmon(擬似アラインメント)の実行

1. 転写産物インデックスの作成(初回のみ)

salmon index \
  -t reference/transcripts.fa \
  -i reference/salmon_index \
  -k 31
パラメータ 意味 設定の根拠
-t 転写産物 FASTA ファイル GENCODE / Ensembl の cDNA FASTA を使用
-i インデックスの保存先 再利用するため専用ディレクトリに保存
-k 31 k-mer サイズ デフォルト 31。通常変更不要

💡 初心者向けTip: Salmon のインデックスにはゲノム FASTA ではなく転写産物(cDNA)の FASTA を使います。GENCODE なら gencode.vXX.transcripts.fa.gz、Ensembl なら *.cdna.all.fa.gz をダウンロードしてください。

2. 定量の実行

salmon quant \
  -i reference/salmon_index \
  -l A \
  -1 sample_R1.fastq.gz \
  -2 sample_R2.fastq.gz \
  -p 16 \
  --validateMappings \
  -o results/salmon/sample
パラメータ 意味 設定の根拠
-l A ライブラリタイプを 自動検出 手動指定も可能だが、A(auto)が安全
-1 / -2 PE の Read 1 / Read 2 SE の場合は -r を使用
--validateMappings マッピング精度を高める検証を有効化 2026年時点で常に有効にすることを推奨
-o 出力ディレクトリ サンプルごとにディレクトリを分ける

💡 中級者向けTip: Salmon の出力 quant.sf には TPM と NumReads(推定リード数)が含まれます。DEG解析には NumReads を tximport 経由で DESeq2 に渡すのが推奨されるワークフローです(Step 4, 6 で詳述)。

Step 4: 発現定量(gene-level quantification)

このセクションで学ぶこと

  • 「発現定量」とは何をしているのか
  • STAR + featureCounts による定量方法と strandedness 設定の重要性
  • Salmon + tximport による定量方法と tx2gene マッピング
  • 2つのパイプラインの出力の違いと、DEG解析への正しい接続方法

Step 3 でリードの位置が特定できたら、次は各遺伝子にリードが何本マッピングされたかを数える「発現定量」を行います。ここで得られるカウント値が、二次解析(DEG解析)の直接の入力データになります。

💡 初心者向けTip: 発現定量を簡単に言うと「各遺伝子の領域にリードが何本落ちているか数える」作業です。リードが多い遺伝子 = よく発現している遺伝子、という関係になります。

【発現定量のイメージ】

  ゲノム上の遺伝子A領域:  ||||||||||||||||  → 16リード → カウント = 16
  ゲノム上の遺伝子B領域:  |||              → 3リード  → カウント = 3
  ゲノム上の遺伝子C領域:  ||||||||         → 8リード  → カウント = 8

  → これを全遺伝子 × 全サンプルで集計 = カウント行列(count matrix)

パイプライン別の定量方法

パイプライン 定量の仕組み 必要な入力 出力
STAR + featureCounts BAM中のリードがGTFの遺伝子領域に何本重なるかカウント BAM + GTF gene-level raw counts
Salmon + tximport 転写産物レベルの推定値を遺伝子レベルに集約 quant.sf + tx2gene gene-level counts(tximport経由)

A. STAR + featureCounts

STAR で生成した BAM ファイルに対して、featureCounts(subread パッケージ)で遺伝子領域のリードをカウントします。

基本実行例

featureCounts \
  -T 16 \
  -p --countReadPairs \
  -s 2 \
  -a reference/annotation.gtf \
  -o results/counts/gene_counts.txt \
  results/star/*.bam
パラメータ 意味 設定の根拠
-T 16 スレッド数 サーバーのコア数に応じて調整
-p --countReadPairs PE データとしてカウント PE の場合は必須。フラグメント単位でカウント
-s 2 strandedness 設定 ⚠️ 最重要パラメータ(下表参照)
-a アノテーション GTF Step 0 で確認したものを使用
-o 出力ファイル名 全サンプルのカウントが1ファイルにまとまる

⚠️ strandedness 設定(-s)の選び方

この設定を間違えるとカウント値が半減〜崩壊します。 Step 0 で確認したライブラリタイプに基づいて正しく設定してください。

ライブラリタイプ -s の値 説明
unstranded 0 strand 情報を使わない
stranded(dUTP法 = 主流) 2 reverse strand をカウント
stranded(直接法) 1 forward strand をカウント

💡 判断に迷ったら: featureCounts を -s 0, -s 1, -s 2 でそれぞれ実行し、Assigned reads の割合が最も高い設定が正解です。RSeQC の infer_experiment.py でも strandedness を事前判定できます(Step 5 参照)。


B. Salmon + tximport

Salmon は転写産物(transcript)レベルで定量するため、tximport を使って遺伝子(gene)レベルに集約し、DESeq2 に接続します。

tx2gene マッピングファイルの準備

まず、転写産物ID → 遺伝子ID の対応表(tx2gene)を作成します。

# GENCODE GTF から tx2gene を作成する例
library(GenomicFeatures)
txdb <- makeTxDbFromGFF("reference/annotation.gtf")
tx2gene <- select(txdb, keys(txdb, "TXNAME"), "GENEID", "TXNAME")
write.csv(tx2gene, "reference/tx2gene.csv", row.names = FALSE)

💡 初心者向けTip: tx2gene は「この転写産物はこの遺伝子のもの」という対応表です。1つの遺伝子から複数の転写産物(スプライスバリアント)が作られるため、転写産物レベルのカウントを遺伝子レベルにまとめる必要があります。

tximport による集約

library(tximport)
library(readr)

# サンプル情報の読み込み
samples <- read.csv("metadata/sample_table.csv", stringsAsFactors = FALSE)

# quant.sf ファイルのパス一覧
files <- file.path("results/salmon", samples$sample_id, "quant.sf")
names(files) <- samples$sample_id

# tx2gene の読み込み
tx2gene <- read.csv("reference/tx2gene.csv")

# tximport の実行
txi <- tximport(
  files,
  type = "salmon",
  tx2gene = tx2gene,
  countsFromAbundance = "no"
)
パラメータ 意味 推奨値
type 定量ツールの指定 "salmon"
tx2gene 転写産物→遺伝子の対応表 2列のデータフレーム(TXNAME, GENEID)
countsFromAbundance カウント値の補正方法 "no"(DESeq2 使用時の推奨)

⚠️ 注意: countsFromAbundance = "no" は DESeq2 の公式推奨設定です。"scaledTPM""lengthScaledTPM" も指定可能ですが、DESeq2 の内部正規化との相互作用を理解した上で使ってください。


2つのパイプラインの出力比較

項目 STAR + featureCounts Salmon + tximport
出力形式 タブ区切りテキスト(gene_counts.txt) R の tximport オブジェクト
カウント値 整数(raw counts) 推定値(小数を含む場合あり)
DESeq2 への接続 DESeqDataSetFromMatrix() DESeqDataSetFromTximport()
遺伝子長の補正 自分で補正が必要 tximport が自動で考慮

💡 中級者向けTip: Salmon の NumReads をそのまま丸めて DESeq2 に入れるのは推奨されません。必ず tximportDESeqDataSetFromTximport() の正規ルートを使いましょう。これにより、転写産物長のバイアス補正が適切に反映されます。

Step 5: マッピング後QCで見るべき指標

このセクションで学ぶこと

  • なぜ「マッピング後QC」が重要なのか
  • STAR の Log.final.out で確認すべき指標と 正常値の目安
  • Salmon の出力で確認すべき指標
  • RSeQC による追加QC(geneBody coverage, strandedness 判定など)

Step 1 の FASTQ QC が良好でも、参照配列の不一致やライブラリの問題により、マッピング以降で結果が崩れることがあります。マッピング後QCは「データが本当に使えるか」を判断する最後の砦です。

💡 初心者向けTip: マッピング後QCは「リードがちゃんと正しい場所に貼り付いたか」を確認する作業です。FASTQ QCが「素材の品質チェック」なら、マッピング後QCは「組み立て結果の検品」にあたります。


STAR で見るべき指標

STAR は各サンプルの Log.final.out に詳細な統計情報を出力します。以下が主要な確認項目です。

指標 正常値の目安 異常時に疑うこと
Uniquely mapped reads % 70〜90% 低い → species mismatch, 参照不一致, contamination
Multi-mapped reads % 5〜15% 極端に高い → リピート領域の問題, リード長が短すぎる
Unmapped: too many mismatches % < 5% 高い → 参照ゲノムの種が違う可能性
Unmapped: too short % < 10% 高い → 過剰トリミング, アダプター残存
Mismatch rate per base < 1% 高い → 低品質リード, SNPが多い系統
% of reads mapped to multiple loci < 15% 高い → リピート領域, 偽遺伝子の影響
【マッピング率の判断フロー】

  Uniquely mapped > 70% → ✅ 正常。次のステップへ
  Uniquely mapped 50〜70% → ⚠️ 要確認。原因を調査
  Uniquely mapped < 50%  → ❌ 深刻な問題の可能性大
       │
       ├── rRNA 残存が多い? → rRNA depletion の問題
       ├── 別の種のリード混入? → contamination
       ├── chr名の形式不一致? → FASTA/GTF の整合性(Step 0 参照)
       └── アダプター残存? → Step 2 の見直し

💡 中級者向けTip: STAR の Log.final.out を全サンプル分まとめて MultiQC に通すと、サンプル間の比較が容易になります。外れ値サンプルの早期発見に非常に有効です。


Salmon で見るべき指標

Salmon を使った場合は、ログ出力や aux_info/ ディレクトリの情報を確認します。

指標 確認方法 正常値の目安 異常時に疑うこと
Mapping rate ログ出力 or aux_info/meta_info.json 70〜90% 低い → インデックスの種不一致, cDNA配列の問題
サンプル間の総カウント quant.sf の NumReads 合計 サンプル間で大きな差がない 極端な差 → シーケンス深度の偏り, 技術的問題
Library type の自動検出結果 ログ出力 全サンプルで一貫 サンプル間で異なる → ライブラリ調製の問題
Fragment length distribution aux_info/fld.gz 予想範囲内(200〜400bp) 極端に短い/長い → ライブラリの品質問題

💡 初心者向けTip: Salmon も MultiQC に対応しています。salmon quant の出力ディレクトリごと MultiQC に渡すと、全サンプルの mapping rate やライブラリタイプを一覧で確認できます。


RSeQC による追加QC(STAR パイプライン向け)

RSeQC は RNA-seq に特化したQCパッケージで、BAMファイルから詳細な品質指標を抽出できます。

ツール 目的 確認できること
infer_experiment.py strandedness の判定 ⭐ featureCounts の -s 設定の確認に最適
geneBody_coverage.py 遺伝子全体のカバレッジ分布 RNA分解の有無(3' bias の検出)
read_distribution.py リードの分布先 exon / intron / intergenic の割合
inner_distance.py インサートサイズの分布(PE) ライブラリ調製の品質確認

特に重要:strandedness の事後確認

# strandedness の判定(Step 4 の -s 設定の確認に使える)
infer_experiment.py \
  -r reference/genes.bed \
  -i results/star/sample.bam
【出力例の解釈】
  "1++,1--,2+-,2-+": 0.0192    ← sense strand
  "1+-,1-+,2++,2--": 0.9627    ← antisense strand(dUTP法)
  → antisense が 96% → stranded (reverse) → featureCounts -s 2

gene body coverage の確認

# 遺伝子全体のカバレッジ分布を確認
geneBody_coverage.py \
  -r reference/housekeeping.bed \
  -i results/star/sample.bam \
  -o qc/rseqc/sample

⚠️ 3' bias に注意: gene body coverage が3'側(右側)に偏っている場合、RNA分解が起きている可能性があります。FFPE サンプルや保存状態の悪いサンプルでよく見られるパターンです。この場合、定量結果の信頼性に影響するため注意が必要です。

💡 チェックポイント: マッピング後QCで以下を確認したら、Step 6 へ進みましょう。

  • ✅ マッピング率が正常範囲内(>70%)
  • ✅ サンプル間で大きな外れ値がない
  • ✅ strandedness が想定通り
  • ✅ gene body coverage に極端な偏りがない

Step 6: カウント行列作成時の注意点

このセクションで学ぶこと

  • カウント行列(count matrix)とは何か、その構造
  • gene ID の選び方と gene symbol を主キーにしてはいけない理由
  • TPM と raw counts の違いと、DEG解析への正しい入力
  • 低カウント遺伝子の扱い方(一次解析 vs 二次解析の役割分担)
  • 最終成果物としてのカウント行列の品質チェック

ここで作る count matrix(カウント行列) が、一次解析の最終成果物であり、二次解析(DEG解析等)の直接の入力データになります。この行列の作り方を間違えると、後続の解析すべてが破綻します。

💡 初心者向けTip: カウント行列とは、行が遺伝子、列がサンプルの「数値表」です。各セルには「その遺伝子にマッピングされたリードの数」が入っています。

【カウント行列のイメージ】

              Sample_1  Sample_2  Sample_3  Sample_4
  GeneA          152       203       178       195
  GeneB           23        18        31        25
  GeneC         1840      2105      1923      2011
  GeneD            0         1         0         2
  ...
  (約20,000〜60,000 遺伝子 × サンプル数)

注意点1:Gene ID を統一する

ID の種類 主キーとしての適性 理由
Ensembl Gene ID ENSG00000141510 推奨 一意で安定、バージョン管理しやすい
GENCODE ID ENSG00000141510.18 ⭕ 良い Ensembl ID + バージョン番号
Gene Symbol TP53 非推奨 重複・更新・別名の問題がある
Entrez Gene ID 7157 ⚠️ 場合による 一意だが、ツール間の互換性に注意

⚠️ よくあるミス: Gene Symbol(例:TP53, BRCA1)を主キーにすると、以下の問題が発生します。

  • 同じ symbol に複数の遺伝子が対応する場合がある
  • symbol が更新されて名前が変わることがある(特にマウス)
  • Excel で開くと日付に変換される symbol がある(例:MARCH1 → 3月1日)

原則:内部処理では Ensembl Gene ID を主キーにし、gene symbol は表示・可視化時に付加する


注意点2:Genome と Annotation のバージョンを記録する

同じ「GRCh38」でも、annotation のバージョンによって遺伝子の数や定義が変わります

【例:GENCODEのバージョン違いによる遺伝子数の差】

  GENCODE v38 (2021):  約 60,660 遺伝子
  GENCODE v46 (2024):  約 63,000 遺伝子
  → 約 2,300 遺伝子の差がある!

カウント行列のメタデータとして、以下を必ず記録しておきましょう。

記録すべき項目
Genome build GRCh38
Annotation source & version GENCODE v46
定量ツール & バージョン featureCounts 2.0.6 / Salmon 1.10.3
strandedness 設定 -s 2 / -l A

注意点3:TPM と raw counts を混同しない

これは非常に重要な区別です。

指標 定義 DEG解析への使用 主な用途
Raw counts 遺伝子にマッピングされたリード数そのもの 適切 DESeq2 / edgeR の入力
TPM 遺伝子長とライブラリサイズで正規化した値 不適切 可視化、サンプル間の相対比較
FPKM / RPKM 遺伝子長とライブラリサイズで正規化(旧式) 不適切 非推奨(TPMに移行)
tximport counts Salmon の推定値を tximport で変換 適切 DESeqDataSetFromTximport() で使用

⚠️ TPM を DEG解析に入れてはいけない理由: DESeq2 や edgeR は、raw counts を入力として受け取り、内部で独自の正規化を行います。すでに正規化された TPM を入れると、統計モデルの前提が崩れ、偽陽性/偽陰性が増加します。

【正しいワークフロー】

  STAR + featureCounts  → raw counts    → DESeq2 (DESeqDataSetFromMatrix)     ✅
  Salmon + tximport     → tximport obj  → DESeq2 (DESeqDataSetFromTximport)   ✅
  Salmon → TPM を直接使用                → DESeq2                              ❌ NG!

注意点4:低カウント遺伝子の扱い

低発現遺伝子(多くのサンプルでカウントが0または極めて少ない遺伝子)のフィルタリングについて:

段階 推奨される対応 理由
一次解析 フィルタリングしない(原則) 再利用性を保つため。別の目的で使う可能性がある
二次解析 実験デザインに基づいてフィルタリング 統計的検出力の向上。DESeq2 の independent filtering 等

💡 中級者向けTip: DESeq2 には independentFiltering 機能が組み込まれており、低カウント遺伝子を自動的に除外して多重検定補正の負荷を軽減します。一次解析で先回りしてフィルタリングするよりも、この機能に任せる方が柔軟で安全です。


最終チェック:カウント行列の品質確認

カウント行列が完成したら、以下を確認して一次解析を締めくくりましょう。

チェック項目 確認方法 期待される結果
遺伝子数 nrow(counts) ヒト: 約20,000〜60,000(annotation依存)
サンプル数 ncol(counts) 期待するサンプル数と一致
総カウント数 colSums(counts) サンプル間で極端な差がない
ゼロカウントの割合 colMeans(counts == 0) 全遺伝子の30〜60%程度(正常範囲)
外れ値サンプル PCA / 相関ヒートマップ 明らかな外れ値がない

💡 初心者向けTip: カウント行列ができたら、まず colSums() で各サンプルの総カウント数を確認しましょう。あるサンプルだけ極端に少ない(または多い)場合は、シーケンス深度の問題やマッピングの問題が疑われます。

2026年時点での推奨ツール構成

このセクションで学ぶこと

  • 2026年時点で推奨される 2つのパイプライン構成 の全体像
  • 各構成のツールの役割と推奨バージョン
  • 自分の目的に合った構成の選び方
  • 既成パイプライン(nf-core/rnaseq)の活用

ここまで Step 0〜6 で学んだ内容を踏まえ、2026年時点で実務的に推奨される2つのパイプライン構成を整理します。


構成A:Salmon 型(高速・軽量・DEG解析向け)

  FASTQ → FastQC → (fastp) → Salmon → tximport → DESeq2
                      ↓
                  MultiQC(QCレポート集約)
Step ツール バージョン(推奨) 役割
0 Conda/Mamba - 環境構築
1 FastQC + MultiQC 0.12.1 / 1.25 FASTQ品質チェック
2 fastp 0.23.4 トリミング(必要時のみ)
3+4 Salmon 1.10.3 擬似アラインメント + 定量(一括)
6 tximport (R) 最新版 遺伝子レベル集約 + DESeq2接続

向いているケース:

  • 遺伝子発現比較(DEG解析)が主目的
  • 多サンプルを高速に処理したい
  • BAMファイルを生成する必要がない
  • ディスク容量を節約したい

構成B:STAR 型(高精度・可視化・追加QC向け)

  FASTQ → FastQC → (fastp) → STAR → featureCounts → DESeq2
                      ↓          ↓
                  MultiQC     BAMファイル
                              → RSeQC(追加QC)
                              → IGV(可視化)
Step ツール バージョン(推奨) 役割
0 Conda/Mamba - 環境構築
1 FastQC + MultiQC 0.12.1 / 1.25 FASTQ品質チェック
2 fastp 0.23.4 トリミング(必要時のみ)
3 STAR 2.7.11b ゲノムアラインメント
4 featureCounts 2.0.6 発現定量
5 RSeQC + samtools 5.0.3 / 1.20 マッピング後QC

向いているケース:

  • IGV でリードの分布を目視確認したい
  • スプライスジャンクション解析をしたい
  • RSeQC をフル活用してQCしたい
  • BAMファイルを他の解析に再利用したい

構成の選び方まとめ

判断基準 構成A(Salmon型) 構成B(STAR型)
DEG解析が主目的 最適 ✅ 可能
処理速度 高速 やや遅い
ディスク使用量 💾 少ない 大(BAM生成)
IGV可視化 ❌ 不可 最適
スプライシング解析 ❌ 不可 最適
追加QC(RSeQC等) ❌ 不可 最適
初心者の学習用 ✅ シンプル ✅ 理解が深まる

💡 実践的なアドバイス: 多くの研究室やプロジェクトでは、まず構成A(Salmon型)で素早く結果を得て、必要に応じて構成B(STAR型)で詳細確認するハイブリッド運用が効率的です。


既成パイプラインの活用:nf-core/rnaseq

自分でパイプラインを組む以外に、コミュニティが整備した既成パイプラインを利用する方法もあります。

項目 内容
名前 nf-core/rnaseq
基盤 Nextflow + Docker/Singularity
特徴 STAR, Salmon, featureCounts, RSeQC 等を統合。全自動実行
再現性 コンテナ化されており、どの環境でも同じ結果が得られる
URL https://nf-co.re/rnaseq

💡 中級者向けTip: nf-core/rnaseq は構成A・Bの両方をカバーしており、パラメータ一つで切り替え可能です。大規模プロジェクトや論文投稿時の再現性保証には非常に有力な選択肢です。ただし、Nextflow の学習コストがあるため、まずは手動パイプラインで各ステップを理解してから移行するのがおすすめです。

ikraを活用した一次解析の自動化

このセクションで学ぶこと

  • ikra とは何か、どのような場面で便利か
  • ikra の入出力と内部で使われているツール
  • インストールから実行までの具体的な手順
  • ikra を本記事のパイプラインにどう組み込むか

ikra は、日本発の bulk RNA-seq 一次解析用パイプラインで、SRA 登録済みの公開データやローカルの FASTQ ファイルから、最小限のコマンドで発現量テーブル(TPM / expected counts)を作成できる ことが特徴です。内部では Trim Galore / fastp、Salmon、tximport など本記事で紹介したツールが使われており、構成A(Salmon 型)を手軽に試したい場合の有力な選択肢です。

💡 初心者向けTip:ikra は「1 行のコマンドで構成A を一通り実行できる Salmon ベースのパイプライン」と考えると分かりやすいです。個別のコマンドを組み立てるのが難しいと感じる方は、まず ikra で結果を出してから、Step 0〜6 を読み返すと各処理の意味が理解しやすくなります。

ikra の特徴

項目 内容
対応入力 SRA アクセッション(例:SRR...)または ローカル FASTQ ファイル
内部ツール Trim Galore / fastp、Salmon、tximport
出力 遺伝子レベル・転写産物レベルの TPM / expected counts テーブル
対応生物種 ヒト・マウスを中心にプリセットあり(リファレンスは自動取得)
実行環境 Docker / Singularity(Apptainer)を前提
URL https://github.com/yyoshiaki/ikra

ikra が向いているケース

  • 公開データ(GEO / SRA)を素早く再解析したい:SRR ID を並べた CSV を渡すだけで、ダウンロード〜定量まで自動化されます。
  • Salmon ベースの構成A を試したい:Step 3・Step 4 で紹介した Salmon + tximport の流れを 1 コマンドで実行できます。
  • BAM が不要で、とにかく発現量テーブルだけ欲しい:軽量・高速でディスク使用量も少ないため、多サンプルの初期検討に適しています。

逆に、IGV でリードを可視化したい場合や、スプライシング解析のために BAM が必要な場合は、本記事の構成B(STAR 型)や nf-core/rnaseq の方が適しています。

インストール(Docker 利用例)

ikra は Docker / Singularity 環境で動作します。ローカルに Docker がインストールされていることを前提に、以下のようにセットアップします。

# ikra 本体を取得
git clone https://github.com/yyoshiaki/ikra.git
cd ikra

# 実行スクリプトにパスを通す(例)
export PATH=$PWD:$PATH

# 動作確認(ヘルプ表示)
ikra.sh --help

⚠️ 注意:ikra は内部で複数のコンテナイメージを pull するため、初回実行時はネットワーク帯域とディスク容量に余裕があるマシンで実行してください。HPC 環境では Singularity / Apptainer モードでの利用が便利です。

実行例:SRA データから発現量テーブルを作る

ikra は「サンプル情報を記した CSV」を入力として受け取り、FASTQ の取得から定量までを一括で処理します。

1 つ目のステップとして、以下のような experiment.csv を用意します。

name,SRR,Layout,condition
control_1,SRR1234567,PE,control
control_2,SRR1234568,PE,control
treated_1,SRR1234569,PE,treated
treated_2,SRR1234570,PE,treated

その後、1 コマンドで一次解析を走らせます。

# ヒトデータの場合(例)
ikra.sh experiment.csv hg38 \
    --threads 16 \
    --output results_ikra
引数 意味
experiment.csv サンプル情報ファイル(name / SRR / Layout / condition 等)
hg38 参照ゲノム・アノテーションのプリセット(マウスは mm10 など)
--threads 並列実行スレッド数
--output 出力ディレクトリ

実行が完了すると、results_ikra/ 以下に以下のような成果物が生成されます。

  • 各サンプルの quant.sf(Salmon の出力)
  • 遺伝子レベルに集約された TPM / expected counts の行列(tximport 経由)
  • MultiQC レポート

本記事のパイプラインへの組み込み方

本記事の Step 0〜6 と ikra の対応関係を整理すると、ikra は Step 0〜4 までを内部で実行してくれるイメージです。

本記事の Step ikra での扱い
Step 0: 解析環境と再現性 Docker / Singularity コンテナで担保
Step 1: FASTQ QC FastQC / MultiQC を内部で実行
Step 2: トリミング Trim Galore / fastp を内部で実行
Step 3: マッピング・擬似アラインメント Salmon を内部で実行
Step 4: 発現定量 Salmon + tximport により gene-level 行列を生成
Step 5: マッピング後QC MultiQC で集約。詳細な RSeQC が必要なら別途実施
Step 6: カウント行列作成 TPM / expected counts 行列が出力される

推奨される活用フロー

  1. まず ikra で全体を回す:SRR ID や FASTQ を CSV に並べ、ikra.sh で一気に発現量テーブルまで作成します。ここで strandedness の推定結果やマッピング率を MultiQC レポートで確認します。
  2. 怪しいサンプルだけ手動で検証:マッピング率が低い、TPM 分布が異常などの問題があるサンプルについては、本記事の Step 1・Step 5 の観点(strandedness、rRNA 残存、gene body coverage など)を参考に個別に調査します。
  3. BAM が必要になったら構成B に切り替え:IGV での可視化やスプライシング解析など BAM が必要な解析が出てきた段階で、該当サンプルのみ STAR + featureCounts(構成B)で再解析します。

💡 中級者向けTip:ikra の出力は Salmon ベースなので、DEG 解析に進む際は tximport 経由で DESeq2 に渡すルート(Step 4・Step 6 参照)がそのまま使えます。countsFromAbundance = "no" で DESeqDataSetFromTximport() に渡すのが公式推奨です。

⚠️ 注意:ikra のリファレンス(ゲノム・アノテーション)のバージョンは、ツール側のデフォルトに依存します。論文や社内レポートにまとめる際は、ikra のログから 使用された参照ゲノムとアノテーションのバージョンを必ず記録し、Step 0 の「固定すべき 8 項目」と同じ粒度でメタデータを残しておきましょう。

実践例:推奨パイプライン(構成B:STAR型)

このセクションで学ぶこと

  • STAR + featureCounts パイプラインの コピペで実行可能な完全なコマンド例
  • 各ステップのディレクトリ構成
  • 複数サンプルをループ処理する実践的なスクリプト

以下は、構成B(STAR + featureCounts)の実践的なコマンド例です。実際のプロジェクトでコピペして使えるように、ディレクトリ構成も含めて示します。

ディレクトリ構成

project/
├── data/                    # 入力 FASTQ ファイル
│   ├── sample1_R1.fastq.gz
│   ├── sample1_R2.fastq.gz
│   └── ...
├── reference/               # 参照ゲノム・アノテーション
│   ├── genome.fa
│   ├── annotation.gtf
│   └── star_index/
├── trimmed/                 # トリミング後 FASTQ
├── results/
│   ├── star/                # STAR 出力(BAM等)
│   └── counts/              # カウント行列
├── qc/                      # QCレポート
│   ├── fastqc_raw/
│   ├── fastqc_trimmed/
│   ├── fastp/
│   ├── multiqc/
│   └── rseqc/
├── metadata/
│   └── sample_table.csv     # サンプル情報
└── environment.yml          # 環境定義ファイル

Step 1: FASTQ QC

mkdir -p qc/fastqc_raw qc/multiqc

fastqc -o qc/fastqc_raw -t 8 data/*.fastq.gz
multiqc qc/fastqc_raw -o qc/multiqc

Step 2: トリミング(必要な場合のみ)

mkdir -p trimmed qc/fastp

for sample in sample1 sample2 sample3; do
  fastp \
    -i data/${sample}_R1.fastq.gz \
    -I data/${sample}_R2.fastq.gz \
    -o trimmed/${sample}_R1.fastq.gz \
    -O trimmed/${sample}_R2.fastq.gz \
    --detect_adapter_for_pe \
    -h qc/fastp/${sample}.html \
    -j qc/fastp/${sample}.json \
    -w 4
done

Step 3: STAR インデックス作成(初回のみ)

STAR \
  --runThreadN 16 \
  --runMode genomeGenerate \
  --genomeDir reference/star_index \
  --genomeFastaFiles reference/genome.fa \
  --sjdbGTFfile reference/annotation.gtf \
  --sjdbOverhang 149

Step 4: アラインメント(サンプルループ)

mkdir -p results/star

for sample in sample1 sample2 sample3; do
  STAR \
    --runThreadN 16 \
    --genomeDir reference/star_index \
    --readFilesIn trimmed/${sample}_R1.fastq.gz trimmed/${sample}_R2.fastq.gz \
    --readFilesCommand zcat \
    --outSAMtype BAM SortedByCoordinate \
    --quantMode GeneCounts \
    --outFileNamePrefix results/star/${sample}.
done

Step 5: 発現定量

mkdir -p results/counts

featureCounts \
  -T 16 \
  -p --countReadPairs \
  -s 2 \
  -a reference/annotation.gtf \
  -o results/counts/gene_counts.txt \
  results/star/*.Aligned.sortedByCoord.out.bam

Step 6: マッピング後QC + 最終レポート

mkdir -p qc/rseqc

# strandedness 確認
infer_experiment.py -r reference/genes.bed -i results/star/sample1.Aligned.sortedByCoord.out.bam

# gene body coverage
geneBody_coverage.py -r reference/housekeeping.bed -i results/star/sample1.Aligned.sortedByCoord.out.bam -o qc/rseqc/sample1

# 全QCを MultiQC でまとめて最終レポート
multiqc . -o qc/multiqc_final

💡 最後のポイント: multiqc . をプロジェクトルートで実行すると、FastQC, fastp, STAR, featureCounts, RSeQC の全QC結果を1つのHTMLレポートにまとめてくれます。これが一次解析の「成績表」になります。

よくある失敗とその回避策

このセクションで学ぶこと

  • 一次解析で 特に頻出する5つの失敗パターン とその具体的な症状
  • 各失敗の 回避策と確認方法
  • 失敗に気づくためのチェックポイント

一次解析は手順自体はシンプルですが、設定ミスや確認不足により結果が大きく狂うことがあります。ここでは、実務で特に多い失敗パターンとその回避策をまとめます。

💡 初心者向けTip: 以下の失敗は「経験者でもやりがち」なものばかりです。初めての解析では、このリストをチェックリストとして使いましょう。


失敗パターン一覧

# 失敗 深刻度 症状 該当Step
1 strandedness 設定の誤り 🔴 致命的 カウント値が半減〜崩壊 Step 4
2 FASTA と GTF の不整合 🔴 致命的 マッピング率0%、カウント欠損 Step 0, 3
3 FastQC フラグの機械的解釈 🟡 中程度 不必要なトリミング、データロス Step 1, 2
4 TPM を DEG 解析に直接投入 🟠 重大 偽陽性/偽陰性の増加 Step 6
5 QC をサンプル単位でしか見ない 🟠 重大 外れ値サンプルの見落とし Step 1, 5

1. strandedness 設定の誤り 🔴

項目 内容
何が起こるか featureCounts の -s や Salmon の --libType を間違えると、sense/antisense のカウントが入れ替わり、発現量が半減〜崩壊する
気づくサイン Assigned reads の割合が極端に低い(featureCounts)、カウント値が想定の半分以下
回避策 ① 実験キットの仕様書を確認(dUTP法 → -s 2
② RSeQC の infer_experiment.py で事後確認
③ featureCounts を -s 0, 1, 2 で実行して Assigned 率を比較
【strandedness 誤りの診断方法】

  featureCounts -s 0 → Assigned: 80%  ← unstranded として全カウント
  featureCounts -s 1 → Assigned: 5%   ← forward(間違い)
  featureCounts -s 2 → Assigned: 78%  ← reverse(正解!dUTP法)

  → -s 2 が最も高い = reverse stranded が正しい設定

2. Genome FASTA と GTF の不整合 🔴

項目 内容
何が起こるか 染色体名の形式不一致(chr1 vs 1)で、リードが一切マッピングされない
気づくサイン STAR のマッピング率が0%に近い、featureCounts の Assigned が極端に低い
回避策 ① FASTA と GTF を同一配布元・同一バージョンから取得
head コマンドで両ファイルの染色体名を目視確認
③ GENCODE同士、Ensembl同士で揃える
# 染色体名の確認(FASTAとGTFが一致しているか)
head -1 reference/genome.fa
# >chr1          ← GENCODE/UCSC 系
# >1             ← Ensembl 系

head -1 reference/annotation.gtf
# chr1  HAVANA  gene  ...   ← chr あり → GENCODE/UCSC
# 1     havana  gene  ...   ← chr なし → Ensembl

3. FastQC フラグの機械的解釈 🟡

項目 内容
何が起こるか RNA-seq では正常な偏り(sequence content, duplication)を異常と誤認し、不必要なトリミングを実施 → リード長が短くなりマッピング率低下
気づくサイン トリミング後にリード数やリード長が大幅に減少
回避策 ① PASS/WARN/FAIL を絶対視しない(Step 1 の解釈テーブル参照)
Adapter content末端品質 のみ重視
③ トリミング前後で必ず比較QCを実施

4. TPM を DEG 解析に直接投入 🟠

項目 内容
何が起こるか 既に正規化された TPM を DESeq2/edgeR に入れると、統計モデルの前提が崩れ、偽陽性/偽陰性が増加
気づくサイン DEG の結果が不自然(差のある遺伝子が極端に少ない/多い)
回避策 ① STAR 系 → featureCounts の raw counts を使用
② Salmon 系 → tximport 経由 で DESeq2 に接続
③ TPM は可視化・相対比較にのみ使用

5. QC をサンプル単位でしか見ない 🟠

項目 内容
何が起こるか 個別のQCレポートだけ見て、全サンプルの中での外れ値を見落とす。batch effect や技術的問題に気づけない
気づくサイン DEG解析の結果がバッチで分かれる、PCAでサンプルが想定外のクラスタリング
回避策 MultiQC で全サンプルを横並び比較
② カウント行列完成後に PCA / 相関ヒートマップを確認
③ 外れ値サンプルは除外を検討(根拠を記録)

チェックリスト:一次解析完了前の最終確認

以下をすべて確認してから、二次解析に進みましょう。

# チェック項目 確認方法
1 strandedness が正しく設定されている infer_experiment.py / -s 比較
2 FASTA と GTF の染色体名が一致 head コマンドで目視確認
3 マッピング率が正常範囲(>70%) STAR Log.final.out / Salmon ログ
4 全サンプルの QC を横並びで比較済み MultiQC レポート
5 カウント行列に raw counts を使用 TPM/FPKM でないことを確認
6 環境情報(ツール・バージョン)を記録済み environment.yml 等

一次解析の成果物一覧

このセクションで学ぶこと

  • 一次解析完了時に 揃っているべき成果物 の一覧
  • 各成果物の形式と用途
  • 再現性を担保するための記録すべきメタデータ

一次解析が完了した時点で、以下の成果物が揃っていることを確認しましょう。

必須成果物

# 成果物 ファイル形式 用途
1 カウント行列 TSV / RDS 二次解析(DEG解析)の直接入力
2 QCレポート(raw FASTQ) HTML(MultiQC) データ品質の記録・共有
3 QCレポート(トリミング後) HTML(fastp / MultiQC) トリミング効果の確認(実施時のみ)
4 マッピングログ テキスト(STAR Log / Salmon log) マッピング率・統計の記録
5 BAM ファイル(構成Bの場合) BAM + BAI IGV可視化・追加QC・再解析
6 Salmon 定量結果(構成Aの場合) quant.sf tximport への入力
7 最終 MultiQC レポート HTML 全ステップのQC集約
8 サンプル対応表 CSV / TSV サンプルID・条件・バッチ情報

再現性のための記録(メタデータ)

# 記録すべき情報 推奨形式
1 使用ツール名とバージョン environment.yml
2 参照ゲノム・アノテーション情報 README.md に記載
3 全実行コマンド シェルスクリプト or ワークフロー定義
4 環境定義 Dockerfile / environment.yml
5 設定パラメータ config.yaml
【理想的なプロジェクトの成果物構成】

project/
├── results/
│   ├── counts/gene_counts.txt     ← カウント行列(最重要)
│   ├── star/*.bam                 ← BAM(構成Bの場合)
│   └── salmon/*/quant.sf          ← 定量結果(構成Aの場合)
├── qc/
│   └── multiqc_final/report.html  ← 最終QCレポート
├── metadata/
│   └── sample_table.csv           ← サンプル対応表
├── scripts/
│   └── run_pipeline.sh            ← 実行スクリプト
├── environment.yml                ← 環境定義
└── README.md                      ← 解析概要・パラメータ記録

💡 初心者向けTip: 最低限「カウント行列」「最終QCレポート」「サンプル対応表」「environment.yml」の4点があれば、二次解析を開始できます。余裕があれば上記すべてを揃えましょう。


二次解析へどうつなぐか

このセクションで学ぶこと

  • 一次解析の出力を二次解析に 正しく接続する方法
  • パイプライン別の接続先と R コード例
  • 一次解析で「やるべきこと」と「やらないこと」の境界

一次解析の出力は、最終的に DESeq2 / edgeR / limma-voom などの二次解析ツールへ接続されます。一次解析の段階で重要なのは、

統計モデルにそのまま渡せる、由来が明確で再現可能な発現定量結果を作ること

です。「きれいな表を作ること」や「前処理を完璧にすること」ではありません。

パイプライン別の接続方法

パイプライン 一次解析の出力 二次解析への接続
STAR + featureCounts gene_counts.txt(raw counts) DESeqDataSetFromMatrix()
Salmon + tximport tximport オブジェクト DESeqDataSetFromTximport()
# 構成A: Salmon + tximport → DESeq2
dds <- DESeqDataSetFromTximport(txi, colData = samples, design = ~ condition)
dds <- DESeq(dds)
res <- results(dds)

# 構成B: STAR + featureCounts → DESeq2
counts <- read.table("results/counts/gene_counts.txt", header=TRUE, row.names=1)
dds <- DESeqDataSetFromMatrix(countData = counts, colData = samples, design = ~ condition)
dds <- DESeq(dds)
res <- results(dds)

一次解析と二次解析の境界

やるべきこと(一次解析) やらないこと(二次解析の領域)
FASTQ QC・トリミング 低カウント遺伝子のフィルタリング
アラインメント・定量 正規化(DESeq2 が内部で実施)
マッピング後QC 差次的発現解析(DEG)
カウント行列の作成 機能解析(GO / GSEA 等)
環境・パラメータの記録 可視化(Volcano plot 等)

💡 中級者向けTip: 一次解析では「過度な前処理をしない」ことが重要です。低カウント遺伝子の除去、正規化、バッチ補正などは二次解析の段階で実験デザインを考慮して行うべきです。一次解析の成果物は「生に近い状態」で保存し、再利用性を最大化しましょう。


まとめ

bulk RNA-seq の一次解析は、単なる前処理ではありません。生データを統計解析可能な形へ正しく変換するための中核工程であり、ここでの判断が二次解析以降のすべての結果に影響します。

本記事の要点

ポイント 内容
2つのパイプライン Salmon型(高速・軽量)と STAR型(高精度・可視化対応)を目的に応じて使い分ける
QCは2段階 FASTQ QC(Step 1)+ マッピング後QC(Step 5)の両方が重要
strandedness 最も間違いやすく最も影響が大きいパラメータ。必ず確認・検証する
参照配列の整合性 FASTA と GTF のソース・バージョンを必ず一致させる
トリミングは最小限 過剰なトリミングはリード長低下のリスク。必要時のみ実施
カウント行列が最終成果物 raw counts を使用。TPM は DEG 解析に使わない
再現性の記録 ツール・バージョン・コマンド・参照配列情報を必ず記録

この記事が、あなたの RNA-seq 一次解析の道標になれば幸いです。正確な一次解析は、信頼できる生物学的発見への第一歩です。


参考文献・根拠

本記事の内容は、以下の文献・公式ドキュメントに基づいています。

# 文献・リソース 関連内容
1 Andrews S. FastQC: A Quality Control tool for High Throughput Sequence Data. Step 1: FASTQ QC
2 Ewels P, et al. MultiQC: summarize analysis results for multiple tools and samples in a single report. Bioinformatics. 2016. Step 1, 5: QCレポート集約
3 Chen S, et al. fastp: an ultra-fast all-in-one FASTQ preprocessor. Bioinformatics. 2018. Step 2: トリミング
4 Dobin A, et al. STAR: ultrafast universal RNA-seq aligner. Bioinformatics. 2013. Step 3: ゲノムアラインメント
5 Patro R, et al. Salmon provides fast and bias-aware quantification of transcript expression. Nature Methods. 2017. Step 3, 4: 擬似アラインメント・定量
6 Liao Y, et al. featureCounts: an efficient general purpose program for assigning sequence reads to genomic features. Bioinformatics. 2014. Step 4: 発現定量
7 Wang L, et al. RSeQC: quality control of RNA-seq experiments. Bioinformatics. 2012. Step 5: マッピング後QC
8 Soneson C, Love MI, Robinson MD. Differential analyses for RNA-seq: transcript-level estimates improve gene-level inferences. F1000Research. 2015. Step 4, 6: tximport
9 Love MI, Huber W, Anders S. Moderated estimation of fold change and dispersion for RNA-seq data with DESeq2. Genome Biology. 2014. 二次解析接続
10 Illumina. Stranded mRNA Library Preparation, Technical Note. ライブラリタイプ
11 Illumina. Paired-End Sequencing, Technical Note. リード構成
12 nf-core/rnaseq pipeline documentation. https://nf-co.re/rnaseq 推奨パイプライン

💡 注記: 各ツールの推奨バージョンは2026年時点の情報です。最新バージョンについては、各ツールの公式リポジトリ(GitHub / Bioconda)を確認してください。

3
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?