ヒートマップで見ている値は、本当にDEG解析に使われた値なのか
RNA-Seqデータを解析した論文では、DEG（Differentially Expressed Genes）解析によって抽出された遺伝子が、 ヒートマップで可視化されていることがよくあります。 そのような論文を読む人からすれば、 そのヒートマップは、DEG解析で発現差の判定に使われた値を、 見やすく表示したものだと考えるのが自然です。
しかし、実際にはそうとは限りません。
DEG解析にはGene Countsが使われていても、 ヒートマップには遺伝子ごとにZ-scoreへ変換された値が使われていることがあります。 PCAではVSTやrlogによって変換された値が使われ、 発現量の表示にはTPMやFPKMが使われている場合もあります。
つまり、一つのRNA-Seq解析として示されていても、 解析の途中で、使われる値の意味や性質が切り替わっていることがあるのです。 そのような場合、提示されたデータや図から、どのようにその妥当性を判断できるというのでしょうか。
どうして、このようなことが起こるのか？
解析者は、意図的に異なる値を混同しているわけではありません。 むしろ、多くの場合は、 それぞれの解析をできるだけ正しく行おうとしています。
DEG解析について調べれば、 edgeRやDESeq2にはGene Countsを使うように説明されています。 PCAについて調べれば、 Gene Countsをそのまま使うのではなく、 VSTやrlogなどによってデータを変換する方法が推奨されています。 ヒートマップについて調べれば、 遺伝子ごとの発現パターンを見やすくするために、 Z-scoreへ変換する方法が紹介されています。 発現量を比較する場合には、 TPMやFPKMを使うように説明されていることもあります。
解析者は、マニュアル、論文、公式ドキュメント、チュートリアルなどを調べ、 それぞれの解析に適しているとされる方法を選びます。 その結果、たとえば次のようなワークフローが作られます。
Gene Counts
↓
edgeRまたはDESeq2によるDEG解析
↓
VSTまたはrlogによる変換
↓
PCA
↓
遺伝子ごとのZ-score
↓
ヒートマップ
一つ一つの手順だけを見れば、 いずれも一般的に推奨されている方法です。 しかし、これらの方法は、 それぞれ異なる目的のために開発され、 別々のマニュアルや文献で説明されています。 それらの結果を最後にどのようにつなぎ、 一つの解析として解釈すべきかまでは、 個々のマニュアルには書かれていません。
解析者は、それぞれの場所で示された「正しい方法」を集め、 一つのワークフローを組み立てます。 その結果、その過程で使われる値は、 Gene Counts、VST、rlog、TPM、Z-scoreなどへと変化していきます。 解析者は同じRNA-Seqデータを一貫して解析しているつもりでも、 実際には、各段階で異なる性質を持つ値を見ていることがあります。
つまり、この問題は、 解析者が正しく解析しようとしなかったために起こるのではありません。 個々の解析を正しく行おうとして、 それぞれの推奨手順を組み合わせた結果として起こり得るのです。
たとえばedgeRでは、Gene Countsを入力し、 TMM（trimmed mean of M-values）によって推定された正規化係数を DEG解析の統計モデルに反映します。 一方、クラスタリングやヒートマップには、 別の正規化やデータ変換を行った値が使われることがあります。 そのため、同じGene Countsから解析を始めていても、 各解析が実質的に同じ値を見ているとは限りません。
不足しているのは、 個々のツールを正しく使うための知識だけではありません。 それぞれの正しさを、 解析全体としてどのようにつなぐのかという視点です。
解析者の仕事は、個々の結果をつなぐこと
RNA-Seq解析では、 edgeRやDESeq2、PCA、クラスタリング、ヒートマップ、 GO解析、Pathway解析など、多くのツールや解析手法を利用します。
しかし、解析者の仕事は、
それらを順番に実行することではありません。
個々のツールから得られた結果をつなぎ、
一つの生物学的な解釈として組み立てることです。
そのためには、
このPCAが何の値から計算されたのか、
このヒートマップがDEG解析の結果をどのように表しているのか、
データ変換によって何が変わったのかを理解する必要があります。
異なる解析結果を、どのような関係としてつなぐのか。
それを判断することは、解析者の責任です。
個々のツールの正しさとは別の次元の正しさが必要
解析者には、 個々のツールを正しい入力と設定で動かすこととは別の責任があります。 それは、解析全体に、 次の性質を持たせることです。
- 妥当性（Validity）
- 一貫性（Consistency）
- 検証可能性（Verifiability）
- 再現性（Reproducibility）
再現性とは、 同じデータと手順を使えば、 別の解析者も同じ結果を得られることです。 しかし、再現されたワークフローの中で、 異なる性質の値が確認されないままつながれていれば、 同じ結果を再現できても、その解釈が妥当とは限りません。 そのため、再現性だけでなく、 その前提となる妥当性、一貫性、検証可能性が必要になります。
妥当性とは、選択した解析方法が実際のデータの特徴と解析目的に適しており、得られた結果から導かれる解釈に無理がないことです。
一貫性とは、 各解析結果が、前後の結果と論理的につながっていることです。
検証可能性とは、 ある結果や解釈が、 どの値と処理から生まれたのかを遡って確認できることです。
同じ手順を再現できても、 その方法が目の前のデータに適していなければ、 解析として妥当とは限りません。 また、個々の処理が一般的に妥当であっても、 異なる値から得られた結果が確認されないままつながれていれば、 解析全体としての一貫性や検証可能性が不足します。
妥当性、一貫性、検証可能性、再現性がそろって初めて、 解析結果の信頼性を高めることができます。
解析手順を検討し、必要に応じて組み替えるのが解析者の役割
Rスクリプトで解析を組み立てる場合には、 途中のデータを取り出し、 異なるデータ表現を比較し、 必要な検証を行う柔軟性があります。
もちろん、Rを使えば自動的に問題が解決するわけではありません。 マニュアルに書かれた推奨手順をそのまま並べているだけでは、 データ表現が変わっていることや、 結果同士の関係が弱くなっていることに気付かない場合もあります。 しかし、少なくとも解析者には、 途中のデータを確認し、 異なるデータ表現を比較し、 必要に応じて解析を組み替える自由があります。
同時に、その自由を使って、 解析全体の妥当性、一貫性、検証可能性を確保する責任もあります。 個々のツールの推奨手順に従うだけでは、これらの責任を果たせません。 使用する値が変わることによって、 前の解析結果との関係が分かりにくくなるのであれば、 変換方法や可視化方法を見直し、 必要に応じて解析手順を修正または調整する必要があります。 同時に、 その変更が各解析手法の前提を損なわず、 解析方法としての妥当性を保つ範囲に収める責任もあります。
マニュアルよりも優先すべきは、目の前にあるデータ
解析で最も優先しなければならないのは、 マニュアルに書かれた方法を忠実に再現することではありません。 実際に得られたデータの特徴に合わせて、 解析方法を選び、必要に応じて調整することです。
マニュアルやチュートリアルで示される推奨手順は、 多くの場合、比較的きれいで、 想定された条件を満たすデータを前提としています。 しかし、実際のRNA-Seqデータには、 低Counts領域の不安定さ、 サンプルごとの測定量やダイナミックレンジの違い、 外れ値、欠損値、 特定のサンプルだけで高発現する遺伝子など、 さまざまな特徴があります。 そのようなデータに対して、 マニュアルの推奨をそのまま適用することが、 妥当な結果につながるとは限りません。
マニュアルの想定と実際のデータが異なるのであれば、 優先すべきなのはマニュアルではなく、 目の前にあるデータです。 データの性質がマニュアルの想定と異なる場合には、 その特徴を適切に扱えるように解析方法を変更する必要があります。 解析方法はデータに合わせるのであって、 データをマニュアルに合わせるのではありません。
たとえば、 AIと相談しながらRNA-Seq deconvolution解析を実行したこちらの記事 では、xCellへのRNA-Seq入力として一般的に推奨されるTPMを、 そのまま使用しませんでした。 それは、 同じRNA-Seqデータを用いた以前の解析 から、低Counts領域の値をそのまま使用すると、 サンプルごとのダイナミックレンジの違いが、 生物学的な発現差のように検出されることを知っていたためです。 これは、個々の解析をそれぞれ独立したものとして扱うのではなく、 以前の解析で把握したデータの特徴を次の解析方法の選択に反映し、 複数の解析をつなげて考えることで、 解析全体の一貫性を確保した例です。
統合パッケージでは、値の違いがさらに見えにくくなる
一方、多くのRNA-Seq解析パッケージは、 複数のツールやアルゴリズムを、 一つのワークフローとしてまとめています。 解析者は一つの画面上で、 DEG解析、PCA、クラスタリング、ヒートマップなどを連続して実行します。 そのため、操作上は、 一つのデータをそのまま次の解析へ渡しているように見えます。
しかし実際には、 内部でGene CountsからVSTやrlogへ変換され、 さらにZ-scoreなどへ切り替わっている場合があります。 操作の連続性と、データの一貫性は同じではありません。
Rスクリプトであれば、 少なくとも途中のオブジェクトを確認し、 値を出力して比較することができます。 しかし、統合パッケージでは、 内部で使われた値や変換後のデータへアクセスできない場合があります。 それだけでなく、注意深くマニュアルを読まない使用者には、 一貫した解析が行われているという誤解を与えがちです。
しかしこれは、単に解析者が確認を怠ったという問題ではありません。 個々の解析の妥当性や再現性が重視される一方で、 解析間で使われる値の一貫性や、 結果を元の値まで遡って検証できることが、 十分に考慮されていないパッケージもあります。
パッケージと解析者、それぞれの責任
パッケージを使うこと自体が問題なのではありません。
パッケージに求められるのは、 解析の各段階でどの値が使われ、 どのような処理によって次の結果が作られたのかを、 使用者が誤解する余地のないほど明確に示すことです。
しかし、それだけで解析全体の一貫性が保証されるわけではありません。 個々のツールから得られた結果をどのようにつなぐのか、 そのつながりが妥当かどうかを検証するのは、 やはり解析者の責任です。
さらに解析者には、 必要な途中の値や処理内容を確認できるツールなのかを見極め、 そのツールを自分の解析に使うべきかどうかを判断する責任もあります。 内部で使用された値や処理を確認できないのであれば、 解析者は結果同士のつながりを十分に検証できません。 その場合には、 操作が簡単であるという理由だけでそのパッケージを採用してよいのかを、 改めて考える必要があります。
一般的な統合パッケージとSubio Platformの比較
一般的な統合パッケージとSubio Platformの違いを、 解析者が一貫性と検証可能性を確保できるかという観点から整理すると、 次のようになります。
| 比較項目 | 複数のツールを統合した一般的なパッケージ | Subio Platform |
|---|---|---|
| 解析に使用する値 | 解析ごとに異なる値へ内部で変換されることがあり、 実際に使われた値やデータ表現の切り替わりを 確認しにくい場合がある | Subio Platform内の可視化や比較解析では、 基本的に同じ前処理・正規化を施したProcessed Signalを使用する。 元データであるCh1 Raw Signalへ表示を切り替え、 変換前後の関係を確認することもできる。 異なる前処理や正規化を試す場合には、 Seriesを複製して別の解析として管理できる |
| フィルタリングの確認 | どの遺伝子が、 どの条件によって除外されたのかを 詳細に確認できない場合がある | フィルタリング条件に該当した遺伝子を Measurement Listとして保存できる。 Measurement Listをフォルダー構造に整理することで、 どのリストから派生した結果なのかを 解析者が分かりやすく管理できる |
| DEG解析と可視化の関係 | DEG解析に使った値と、 ヒートマップなどの可視化に使った値が異なっていても、 その関係が明示されないことがある | DEG解析の判定結果を表示したまま、 Subio Platform上で各遺伝子の発現パターンを確認できる。 外部ツールでDEG解析を行った場合にも、 使用した入力値と可視化に使う値の関係を 解析者が目視で確認できる |
| 元の値との比較と検証 | 図や遺伝子リストだけが表示され、 元のGene Countsなどの入力値や変換前の値まで戻って、 結果がどの値から生じたのかを 確認しにくい場合がある | 解析結果を表示したまま、 Processed Signalと元データであるCh1 Raw Signalの表示を切り替え、 判定結果と変換前後の発現パターンの関係を 目視で確認できる。 前処理や正規化を変更した場合には、 独立したSeriesとして保存し、 変更前後の結果を比較できる |
| Rや外部ツールとの連携 | 内部でRパッケージを利用していても、 入力値や途中の出力値が 利用者に公開されないことがある | Gene Countsなどの生データ、または前処理・正規化済みの Processed Signalを出力してRで解析し、 その結果をSubio Platform上で表示して、 元の発現パターンとあわせて確認できる |
| 判断や変更内容の記録 | 解析手順や設定が自動的に保存される場合でも、 なぜその方法を選んだのかまでは 記録されないことが多い | 解析上の判断や処理内容をメモとして書き込み、 関連するファイルもまとめて保存できる。 さらに、データ、解析結果、メモなどを含む SSAファイルとして保存し、 共同研究者への共有やバックアップに利用できる。 ただし、必要な記録を残すことは解析者の責任となる |
| 解析者が担う責任 | 提示された結果をそのまま受け取るのではなく、 使用された値や処理を確認し、 結果同士の関係が妥当かを判断する必要がある。 ただし、必要な情報へアクセスできない場合には、 十分な検証が難しいことがある | 途中の値や処理結果を確認できる環境を使って、 どの値と方法を採用するかを判断し、 変更内容とその理由を記録する必要がある。 確認できることは、解析者の判断責任を代替するものではない |
解析ソフトウェアの中には、 誰が、いつ、どのような操作を行ったのかを、 変更できない監査証跡として自動的に記録するものもあります。 このような仕組みは規制対応が必要な用途では重要ですが、 権限管理、電子署名、システムのバリデーションなどを伴うため、 一般に高価で複雑です。
Subio Platformは、 そのような監査証跡を自動作成するシステムではありません。 途中の値を確認し、異なる処理結果を比較し、 判断や処理内容をメモとしてデータと一緒に保存できます。 しかし、何を記録し、どの方法を選び、 結果をどのようにつなげて解釈するかは解析者の責任です。 Subio Platformが提供するのは、 解析者が確認、比較、調整、記録を行うための環境です。
ワークフロー管理で議論される一貫性とは異なる
RNA-Seqデータ解析では、「一貫性」という言葉が、 NextflowやSnakemakeによるワークフロー管理や、 Docker・Singularityなどによる解析環境の固定という文脈でも使われます。 これらは、同じツール、同じバージョン、同じパラメータを用いて解析を実行し、 誰がいつ実行しても同じ結果を得られるようにするための重要な取り組みです。 ただし、そこで議論されている一貫性は、 同じ解析手順を同じ条件で繰り返せるようにするという意味で、 基本的には再現性の延長にある概念です。
本記事で問題にしているのは、 解析ワークフロー全体を通して、 それぞれの解析結果がどの値から作られ、 それらが互いにどのような関係にあるのかを、 一貫して説明できるか という点です。 このような解析全体を通した整合性は、 従来のワークフロー管理で議論されてきた一貫性とは異なる概念です。 そこで本記事では、この考え方を analysis-wide consistency と呼び、RNA-Seqデータ解析における新たな評価軸として加えることを提案します。
AIによる自動解析で、この問題はさらに見えにくくなる
今後、AIによるRNA-Seq解析の自動化は、 さらに加速していくと考えられます。 そのとき、analysis-wide consistencyを意識し、 解析全体を通して確認することは、 決定的に重要になるでしょう。
なぜなら、AIが一連の解析結果を滑らかに提示するほど、 それらは互いに整合しているように見えるからです。 それぞれの結果がどの値から作られ、 どのような関係にあるのかを確認し、 必要に応じて元のデータに戻って検証することを、 解析者自身が意識し、AIにも明確に指示しなければ、 これまで以上に大量の解析結果に翻弄されることになるでしょう。
