1. サポート
2. Help - 解析理論とケーススタディ
3. iDEPを使ってみた ― 豊富なQCグラフから、データの問題を発見できるか？

RNA-Seq解析で、データの問題を発見できるか？

RNA-Seqデータ解析では、PCA、ヒートマップ、DEG解析、エンリッチメント解析など、多様な結果を簡単に得られるツールが増えています。しかし、得られた結果を信頼してよいかどうかを判断するには、解析に使用したデータそのものを調べる必要があります。

以前の記事「データの可視化による問題の発見」では、多発性硬化症（MS）患者とHealthy Control（HC）のRNA-Seqデータ（GSE173789）を解析し、一部のサンプルにGene Countsの分布の歪みがあることを確認しました。この歪みによって、正規化後の発現値が相対的に高く見える遺伝子群が生じ、DEG解析の結果にも影響していることを明らかにしました。 さらに、HCサンプルの中にも、異なる発現パターンを示す集団が存在していました。

こうしたデータの構造や、それが解析結果に与える影響は、一般的なRNA-Seq解析ツールでも発見・検証できるのでしょうか。このシリーズでは、同じデータを使い、異なる解析ツールで問題を発見し、その原因や解析結果への影響を検証できるかを調べています。目的は解析ツールの優劣を決めることではありません。研究者がデータの問題に気づき、元のデータに立ち返って検証しやすい解析環境とはどのようなものかを考えることです。

まずは、以前のケーススタディ、または下記のショート解析1の動画で、このデータセットの特徴を確認してから、この先を読み進めることをお勧めします。

---

今回は、WebベースのRNA-Seq解析ツール、iDEPを試します。

解析結果が豊富で見やすく、説明も丁寧なiDEP

今回、Galaxyで作成したGene CountsをiDEPに入力し、解析しました。iDEPには、前処理、QC、クラスタリング、PCA、DEG解析、エンリッチメント解析などの機能が用意されており、さまざまな結果が整理されて表示されます。特に優れていると感じたのは、解析結果の豊富さと見やすさ、そして各解析で何を行っているのかについての説明が丁寧なことです。

RaNA-Seqでは自動的に多数の結果が得られる一方、処理内容を理解しにくい部分がありました。iDEPでは、前処理の設定や解析手法について説明が用意されており、何を行っているのかを確認しながら結果を見ることができます。RNAseqChefと比較しても、QCに関する表示は充実しています。ただし、解析手法を説明してくれることと、その処理が今回のデータにどのような影響を与えたかを理解できることは別です。実際のQC結果を見ていきましょう。

QCグラフには、発現分布の問題を疑うための情報がある

総カウント数の違いと、正規化後にも残るダイナミックレンジの違い

［図1：サンプルごとの総カウント数（左）と変換後の発現値の分布（右）］

まず、サンプルごとの総カウント数には大きなばらつきがありました。総カウント数がばらつくこと自体は普通です。左図を見ると、総カウント数が他のサンプルより大幅に少ないサンプルが存在することが分かります。右図では、変換後の発現値の75th percentileの位置がそろっている一方、下限値にはサンプル間で大きな違いが生じています。ダイナミックレンジの狭いサンプルでは、正規化によって下限値が引き上げられ、多数の遺伝子が発現上昇しているように見える。 403の記事で確認した現象を、この二つの図でも確認できます。

ポイントは、この効果が解析結果にどの程度影響を与えるかを、関連づけて考えられるかどうかです。また、iDEPでは前処理に関する設定も表示されています。この設定を変えることで、変換後の値の分布がどのように変わるかを確認できるのは利点です。ただし、解析経験の少ない人がこの意味を十分に理解し、使いこなせるかはかなり疑問です。なぜなら、その影響を確認できるのは一部のタブ（Boxplot、Dispersion、Gene plotなど）に限られており、これが発現変動やクラスタリングなどの解析結果にどのような影響として現れるのかを直接確認することは難しいからです。

iDEPは、何を行ったのかを説明してくれます。しかし、その処理が今回のデータにどのような影響を及ぼしたかについては、解析者自身が複数のグラフを関連づけて考える必要があり、かなり熟練した解析者でないと難しいと思います。

Density Plotは、HCとMSの違いを示しているのか？

［図2：Density Plot］

赤がHC、青がMSを表しています。一見すると、HCとMSで発現値の分布が異なっているように見えます。しかし、実際にはそうではありません。分布が歪んでいるのは一部のMSサンプルとHCの1サンプルであり、MSサンプルの約半数はHCの多くのサンプルと似た分布を示しています。青い曲線の多くは赤い曲線と重なっているため、図からは見えにくくなっています。しかし、そのような事実をこの図だけから読み取ることは難しいでしょう。

むしろ、最初に設定したHCとMSという分類を前提に、両群で発現分布が異なると解釈してしまう可能性があります。この段階でHCとMSの発現分布が異なると思い込んでしまうと、後のPCAやDEG解析の結果も、その前提に沿って解釈してしまう可能性があります。もしここで、気になる曲線を選択して、それがどのサンプルなのかを確認できれば、もう少し調べようがあると思います。しかし、この図は固定されており、インタラクティブな要素はありません。

2サンプルのScatter Plotでは、分布の歪みを確認できる

［図3：2サンプルのScatter Plot］

iDEPには、任意の2サンプルの発現値を比較するScatter Plotも用意されています。比較するサンプルを変更していくと、右側の図のように、通常とは異なる発現値の関係を示すサンプルを見つけることができます。これは有用な機能ですが、問題はどのサンプルを比較すべきかということです。サンプル数が多い場合、比較対象を一つずつ変更して問題のあるサンプルを探すのは現実的ではありません。

BarplotからGene plotまでのタブで気になるサンプルを選択し、そのサンプルをタブの間で追跡しながら検証できれば、探索はずっと容易になるはずです。iDEPにはQCに役立つ情報や機能がかなり用意されています。しかし、それらが独立した図として表示され、相互に連動していないことが、探索的な検討の大きな制約になっています。

Gene plotで問題のある遺伝子を表示できても、そこにたどり着くのは難しい

［図4：iDEPとSubio Platformの正規化後データ ※両ツールではデータの変換方法が異なるため、発現値のスケールや数値は直接比較できません］

iDEPのGene plotでは、遺伝子名を指定して、その発現プロファイルを表示することができます。SND1、LMAN1、LMAN2の発現値を表示しました。左側がiDEP、右側がSubio Platformによる表示です。これらは、正規化によって一部のサンプルで変換後の発現値が引き上げられ、MS群で発現上昇して見えるようになる遺伝子の例です。

さらに、Raw Countsについても比較しました。正規化前と後のグラフを見比べてみてください。

［図5：iDEPとSubio Platformの生カウントデータ ※遺伝子の色は図4と図5で異なります］

ただし、この2枚の図を見るとき、指摘しておかなければならない重要な点が二つあります。第一に、iDEP側のサンプル名の下にあるカラーブロックは、筆者が後から追加したものです。サンプル間に存在する違いを分かりやすくするために追加しましたが、実際のiDEPではこの情報が表示されないので、発現プロファイルとサンプル情報を関連づけて解釈することは非常に難しいです。

第二に、ここで表示した遺伝子は、iDEPで発見したものではありません。 先にSubio Platformでサンプル間の発現分布を調べ、分布の歪みと関連する遺伝子を確認したうえで、その名前をiDEPに入力しています。しかし、iDEPだけでは、そもそもどの遺伝子を調べるべきかをデータの中から発見し、サンプル全体の発現パターンと対応づけて原因を検証することが難しいのです。

ヒートマップには、これまで確認した二つの特徴が現れている

［図6：ヒートマップ全体と一部の拡大］

iDEPのヒートマップにも、403の記事で確認したデータの特徴が現れています。まず、全体を見ると、一部のサンプルで多くの遺伝子が高発現（赤）に見える領域があります。これは、発現分布の歪みによって正規化後の値が相対的に高く見えるようになった遺伝子群の動きを反映しています。そして、一部を拡大すると、HCサンプルの約半数が共通する発現パターンを示していることが分かります。つまり、今回問題とした二つの特徴は、iDEPのヒートマップにも表示されています。

しかし、データをインポートしてグループを設定すると、後は自動的に解析が進むため、いくらその前に各種QCに関するグラフが見えたとしても、「つつがなく解析された結果を眺めて、後は生物学的な解釈をするだけ」になってしまうのではないでしょうか。注意深い解析者であれば、この図から特定のサンプルにおける発現の偏りに気づき、その原因を検証したいと思うかもしれません。

Heatmapは拡大できるので、気になる遺伝子の名前をメモして、先ほどのGene plotに戻って視覚化することはできます。しかし、その操作がまあまあ面倒なことと、これらがDEGとして抽出されるのかどうかを確認するのが難しいことがボトルネックになります。なお、iDEPのヒートマップには優れた機能もあります。領域を選択して拡大すると、その領域に含まれる遺伝子群のエンリッチメント解析が自動的に行われます。

解析結果を眺めたり生物学的な意味を調べる機能は充実している一方、そのパターンがデータの問題によって生じたものではないかを検証するための自由度は限られています。

PCAには、問題の原因を調べる手がかりも用意されている

［図7：PCA 2D表示（左）と3D表示（右）］

PCAでも、Galaxy、RaNA-Seq、RNAseqChefを使った検証記事で確認したサンプル間の構造が再現されました。分布の歪みの影響を受けて、一部のサンプルがPC1軸に沿って他のサンプルから離れています。ただし、これらの記事で述べたように、HCとMSの違いを見たいという目的に引っ張られすぎた経験の浅い解析者がこの図を見ると、MSの一部で特異的な発現が見られるという結論に引きずられる可能性があります。

つまり、PCAで外れたサンプルが見えても、それがデータの歪みによる影響なのかどうかをQCレポートと連動して検証する機能がないのです。

［図8：PCA toolsのShow Loadings］

一方、iDEPの優れた点として紹介したいのは、「Show Loadings」という機能です。これを有効にすると、PCAで観察されるサンプルの配置に寄与する遺伝子が表示されます。単にサンプルが分かれていることを示すだけでなく、その違いを特徴づける遺伝子について考える手がかりを与えてくれる点は、有用です。 ただし、表示する遺伝子の選択基準や数について、解析者が自由に指定できるわけではありません。また、表示された遺伝子を起点に、サンプルごとの発現分布を調べる操作にも制約があります。

DEG解析では、発現差が生じた原因を追跡できない

［図9：DEG解析図（Volcano plot, MA plot, Scatter plot）］

最後に、HCとMSの二群比較によるDEG解析も行いました。iDEPでは、Volcano Plot、MA Plot、Scatter Plotなどの結果を表示できます。しかし、今回試したDEG解析の図は固定されており、気になる遺伝子を選択して、その発現プロファイルを詳しく調べることができませんでした。この点では、今回比較した他のツールより操作性が劣っていると感じました。また、遺伝子名を表示できるのがHeatmapだけで、遺伝子名で検索できるコントロールがないことも、もどかしく感じました。

また、今回のメインテーマである、一部のサンプルに見られる発現分布の歪みが、DEG判定にどのような影響を与えているかを検証することは、非常に難しいと言わざるを得ません。

［図10：DEGのHeatmap］

iDEPには、DEGをHeatmapで表示する機能があります。このHeatmapを見れば、一部のサンプルがDEGの抽出に強い影響を与えていることを推察することは可能です。しかし、サンプル数が多いと、まずどのサンプルがHCあるいはMSなのかが分かりません。そして、どのサンプルのデータを確認すればよいのかも分かりません。ただし、ヒートマップの領域をドラッグすると拡大表示されるので、そこでサンプル名を確認することは可能でした。したがって、iDEPでも問題を検証する手がかりがまったく得られないわけではありません。

iDEPでの問題は、データの質に問題があるかもしれないと気づきにくい操作の流れと、実際に検証したいと思ったときに、それを進めやすいように設計されていないことです。

iDEPの評価 ― 解析結果は充実しているが、QCの探索には限界がある

今回試したiDEPは、解析結果が豊富で見やすく、何を行っているのかについての説明も丁寧でした。特に、サンプルごとの発現分布を比較できるQCグラフ、SDの大きな遺伝子を使ったクラスタリング、PCAのShow Loadingsなどは評価できる機能です。定型的なRNA-Seq解析を実行し、多様な結果を確認する用途では、今回試したRaNA-SeqやRNAseqChefよりもお勧めできると感じました。

しかし、今回の目的は、解析機能の多さや解析結果の見やすさではありません。データに問題があるとき、それに気づき、原因を調べ、解析結果を信頼してよいか判断できるかという点です。

iDEPは、解析に適したデータが入力されることを前提として、多様な解析結果を見やすく提示し、その生物学的な意味を調べることに重点を置いたツールのように感じられます。それ自体は合理的な設計です。しかし、入力データに問題がある場合、その発見から原因の検証までを支援する設計にはなっていません。もちろん、問題を疑うための情報はQCグラフやPCA、ヒートマップに現れていました。しかし、それらを関連づけて、データの問題が解析結果にどの程度の影響を与えているのか、そして問題の原因がどこにあるのかを検証することは容易ではありませんでした。

さらに重要なのは、そもそも解析者が問題の存在に気づけるように設計されているかどうかです。解析結果が豊富で見やすいことはiDEPの大きな長所ですが、それだけでiDEPを使ったデータ解析結果の信頼性が保証されるわけではありません。

4つのツールを試して、見えてきた共通の問題

このシリーズの出発点となった最初の記事では、公開されたRNA-Seqデータの中に、特定のサンプル群がDEG解析の結果を大きく左右する構造が存在することを確認しました。しかし、原著論文の本文や補足資料には、その影響を検討した記述が見当たりません。それでも、この論文は査読を経て公表されています。しかも、私がこれまで公開データを解析してきた中でも、同様の問題に繰り返し出会ってきました。

なぜ、こうした問題が研究者による解析の段階だけでなく、論文の査読過程でも十分に検討されないまま残ってしまうのでしょうか。その背景を考えるため、同じデータを使って、Galaxy、RaNA-Seq、RNAseqChef、そしてiDEPで解析手順をたどってみました。4つのツールには、それぞれ異なる長所があります。解析工程の柔軟性、自動化による簡便さ、解析機能の豊富さ、結果の見やすさなど、さまざまな工夫が見られました。特に、自動化されたツールの手軽さは魅力的でした。

一方で、「そもそも入力したデータに問題はないのか」という視点から、解析者がデータを探索的に検討するための支援が十分ではないという共通点も見えてきました。問題を疑うための情報がまったくないわけではありません。しかし、その情報をほかの解析結果と関連づけ、問題の原因や影響を調べることは容易ではありませんでした。もちろん、十分な知識と経験を持つ解析者であれば、こうしたツールでも問題に気づき、別の方法を組み合わせて検証することは可能でしょう。しかし、それでは問題を発見できるかどうかが、解析者個人の経験や注意力に大きく依存してしまいます。

こうした解析ツールの設計思想は、研究現場でデータの問題が見過ごされることと無関係ではないのかもしれません。QCレポートを出力すること自体が目的化してしまうと、そこに問題を疑うための情報が含まれていても、その原因や解析結果への影響を詳しく調べる機会は失われてしまいます。その結果、問題を含むデータから得られた解析結果が、十分に検証されないまま論文に掲載されてしまう可能性があります。

解析手順を自動化し、解析結果を見やすく提示することはメリットが大きいです。しかし、それだけでは、信頼できる解析結果が得られるとは限りません。解析ツールには、結果を出すことだけでなく、解析者がその結果を疑い、元のデータに立ち返って検証することを支援する役割も必要なのです。

このシリーズが、RNA-Seq解析ツールの開発に携わる方々にも読まれ、データの問題を発見し、検証するための機能について、一緒に考えるきっかけになれば嬉しく思います。

---