プロテオームとトランスクリプトームの現場
わたしは、実際に試験管を振るわけではないので、バイオテクノロジの現場で本当になにが問題になっているのかを知ることはできません。しかしながら、バイオテクノロジーの分野にコンピュータ技術でサービスを提供していく我々は、蓄積されて公開されている膨大なバイオテクノロジーに関する情報や実験から出力される大量のデータをより利用しやすくするのが仕事ですから、現場の問題を知っておくことは、必須であります。（コンピュータのソフトウエアは、もともと、なにか新しいものを発見する役割を担うよりは、”やってみたいな”と思ったことを”より短い時間で、スマートに、美しく実現することを支援する”役割を担う道具＝TOOLだと、わたしは考えております。ですので、必要としている人々の現場の日々の作業を深く知ることが、喜ばれるソフトウエアを開発する最も良い方法だと考えております。）
前置きが長すぎ！！（自分でつっこんでるし・・・）
断片配列にアノテーションをつけるとき
分子生物学の実験で得られるデータの代表的なもののひとつは、塩基配列ですよね。
目的配列の由来遺伝子を確認する意味
ゲノムDNAの塩基配列と転写産物RNAの塩基配列の２種類があるわけですが、転写産物の場合、実験結果で塩基配列が得られるとまず研究者の方々が行われるのは、おそらく、その配列が”どの遺伝子由来であるか”ということを確認することだと思います。
それがなぜなのか、つまり、遺伝子がわかるとなにがいいのか、わたしには、最初よくわかっていなかったのですが．．． それは、その配列の”遺伝子名”がわかることで、コードされている蛋白質名がわかり、蛋白質がわかるとその蛋白質の機能や細胞内の役割がわかり、それで、実験結果をはじめて検討することができということなんですよね。
その先には、その転写産物が生体内で本当に発現しているかどうかを確認するために、RealTime-PCRやノーザンnortharn blot（これ方角なの？？北と南と西はあるが東がないのはなぜ？）やin situインサイチュ（焼肉屋さんで出てくるサンチュを思い浮かべてしまうのはわたしだけでしょうか？）を行うわけですが、これらの実験を行うためには、遺伝子がわかって、転写産物全体の配列がわからなければならないわけです。
さらに、転写産物の遺伝子とコードしている蛋白質の予測がついても、本当にその転写産物がコードしている蛋白質がその実験系で発現しているのかどうか確認しなければならないわけでして、cDNAから蛋白質の発現を確認したり、ウエスタンwestern blotやったり、抗体を作って染色してみたり、とこれらの実験は、転写産物やゲノムDNAの塩基配列情報があって、はじめてできるものがほとんどです。
転写配列の由来遺伝子を決める方法（蛋白質の話をするはずだったのに。。。）
さて、実験から得られた転写配列を決めるにあたって、なにをやるか。まず最初に行うことは、既知の配列データベースに類似性検索BLASTを行うことだと思います。
ここで、最近は、由来遺伝子を決めるのに、なかなかスマートに決められないという事が起こっているようです。
ここで、由来遺伝子を決めるということについて、定義しておきましょう。”遺伝子”という言葉の定義は、いろいろと議論されるようですが、ここではそういう意味の定義ではありません。現場として、由来遺伝子が決まるということは、具体的にどういうことであるかをこれまでのいろいろな研究者の方に聞いた話をもとにして、まとめておこうということです。目的のアウトプットを明確にし、そのアウトプットを得るための方法を考えるということですね。
で、おそらく、遺伝子を決めるというのは、次のようなことなのでしょう。
・類似性の高い、公共DBに登録されている転写産物の配列がわかること
・NCBIのAccession
・DDBJのAccession
・EnsemblトランスクリプトID
・転写産物のクラスターがわかること
・NCBIのUniGeneClusterがわかること
・ゲノム上の遺伝子座＝ゲノムの絶対位置がわかること
・NCBIのGeneがわかること
・NCBIのLocusIDがわかること
・H-InvitationalDBのLocusID（HIX番号）がわかること
なお、”似ている”とか”まったく一致している”とかを判断すれう場合、わたしは、Query配列の全塩基数に対して得られたホモロジーストレッチのQuery側の長さの割合（カバー率）と、ホモロジーストレッチ内の長さに対するホモロジーストレッチ内での一致した塩基数の割り合い（塩基一致率）を閾値にして検討しています。
遺伝子決定時の問題点
さて、いざわたしたちが、塩基配列をお客様からいただいて、由来遺伝子を決めていく場合、まずは、核酸データベースに塩基配列どおしの類似性検索プログラムBLASTNを使って、塩基配列でぴったりヒットする転写配列を見つけ出そうとします。ここで発生する問題は、冗長性redundancyです。
ｍRNAにヒットした場合
NCBIのRefSeqやH-InvのHIT配列など、配列として信頼のおけるデータベースに対して、まずは、類似性検索を行います。そこでヒットした場合、RefSeqが一本ならば問題はないのですが、現在は、おそらくある程度のスコアで複数のRefSeqにヒットするケースがかなりあると思われます。その場合にはやっかいです。BLAST結果のヒットしたSubjectごとに、UniGeneIDやGeneなどを確かめていく地道な作業を続けていく必要があります。
もし、既知の転写配列にパーシャルPartial（部分的）にヒットした場合（新規のスプライシングバリアントではないか）、また、同じ遺伝子なのですが、異なる配列にヒットして、ヒットした配列どおしが、どのような関係にあるのかを判断するにはどうすればよいでしょう。さらに、異なる遺伝子の配列にそれぞれヒットしてしまった場合は、どのように解釈すればよいでしょう。そのようなことがあるので、今では、みなさん、まずは、EnsemblやUCSCのゲノムブラウザを参照されるようです。この参照については、後述します。
NCBIのESTにヒットした場合
もし、mRNAにヒットしなかった場合には、次の手段として、EST（Expressed Sequence Tag）への検索を行うのもひとつの方法だと思います。
ところで、ESTのデータ蓄積の状況はどうでしょう。ヒトのESTは、2006年10月6日現在で、約789万の登録数があります。毎年、約100万配列単位で増えてきています。ヒトの遺伝子座の数が、３万弱といわれていますので、平均１遺伝子約２６０配列存在しているということになります。しかしながら、実情はどうかというと、UniGeneの各Cluster（由来遺伝子ごとの分類と考えてもよいと思います）に分類されるEST配列の数を見てみると、下記に示すように、Totalのクラスタ数が８万ある中で、１クラスタに１配列しか分類されなかったシングルトンのクラスタが約４万７千あり、さらに、64配列分類されているクラスタまで含むと約７万という数になります。これは、分類された配列の数の少ないクラスタが大半であることを示しています。また、この表は一方で、ESTの登録が進む中で、アバンダントが遺伝子に分類されるESTは、ますます増加していって、巨大クラスタは、さらに巨大化する傾向も示しています。
さて、このようなESTの状況の配列データベースに、類似性検索を行うとどういう状況になるでしょう。
（１）ヒットしたはいいけれど、それにほとんど情報がない。
（２）ある程度の数ヒットしたESTがあるが、それぞれのUniGeneを調べるには、手作業ではたいへんである。mRNAの配列にヒットした場合と同じ問題で。冗長性があるために、類似性検索結果から遺伝子を特定する手間がかかること、スプライシングやnon-codingRNAやオーバーローカスなど、特定した場合の信頼性（本当にこの遺伝子か？本当にこの転写産物か？）に対する不安が拭い去れない。
（３）大クラスタにヒットしてしまって、膨大なヒットの中から遺伝子と転写配列を特定するには、人間の手作業では無理である。
このようなことがあるので、やはり、多くの研究者の方は、ゲノムブラウザを使って、アノテーションされるケースが多いようです。後述します。
Histogram of cluster sizes for UniGene Hs build 195
Total Clusters: 86804
Sequences in a Cluster Fequence 16385-32768 8 8193-16384 22 4097-8192 59 2049-4096 240 1025-2048 740 513-1024 2146 257-512 4289 129-256 4239 65-128 3271 33-64 3089 17-32 3274 9-16 4043 5-8 5434 3-4 6547 2 6579 1 42824
ゲノム配列を利用したを使ったアノテーション
mRNAやESTの配列データベースで決着がつかないものや、類似性検索の結果にいまいち不安がある場合は、ゲノム配列への類似性検索を行い、その結果をゲノムビューアで、他の転写配列のデータや他の生物とのゲノム比較により得られた保存領域の情報などと同時に見ることにより、視覚的に、Queryの配列に関する情報を得ることができます。queryの配列のゲノムアライメントされた”バー”とその他の情報の”バー”を見比べながら、スプライシングバリアントのどのパターンと同じなのか、新規のバリアントの可能性もあるのではないか、これはアンチセンスで発現しているnon-codingRNAでかもしれない、なんて類推することができるわけです。おそらく、配列を取る仕事をされているかなりの数の研究者は、ゲノム配列への類似性検索とそのビューイングシステムを利用して、配列の遺伝子を決める仕事をされていると思っております。
アノテーションをつけるという意味では、この方法は完璧ではないかと思いました。しかしながら、この方法も、情報量が膨大になるにつれて、かならずしも良い方法ではなくなってきました。ゲノムビューアの多くが、ゲノム配列をリファレンスにして公開されてくるあらゆる情報（アノテーション）を重み付けなしに、ゲノムビューア上に自由に貼り付けることができるようになってきましたが、ユーザは、なにを信じていいのか、わからなくなってきて、細部まで配列を検討しないで、遺伝子を決定しているようなことはないでしょうか？ また、ゲノムビューアの公開責任者はできるだけ”正しい”情報を”まるめて”、”単純化”して提示すると、ユーザは喜ぶであろうと考えているようで、表示データを少しでも減らしたいという意図もあるのか、提示されるデータが削られるベクトルがあるようで、ESTに検索するとヒットする配列があるのに、ゲノムのヒット領域には、アノテーションがないという現象に遭遇された経験はないでしょうか？さらに、ゲノムに類似性検索を行うと複数個所にヒットするということは、みなさん経験されていると思いますが、アノテーションそのものは、”1箇所に限定されていない”ことが多いのです。従って、ゲノムビューでは、Query配列がこの遺伝子と決めたとしても、mRNAへの類似性検索では、それほど高いホモロジーをしめさないということを経験されたことはないでしょうか？
コンピュータ処理のマジック
ゲノムビューアの問題点は、実は、コンピュータ処理でアノテーションする場合の問題ともいえます。わたしたちが、コンピュータ処理でいつもお客様に伝えることは、”コンピュータ処理は一定の割合で間違う”ということです。原因はいろいろあります。データソースそのものに間違いが入っていれば、これも大きな問題です。コンピュータ処理の設計に問題がある場合もあるでしょう、プログラムの障害があるかもしれません。そこで、わたしたちは、コンピュータでデータを処理していく場合に、結果にたどり着くまでのアノテーションの処理ステップをできるだけ少なくするようにします。アノテーション処理ステップが多くなると、間違いが間違いを呼び、間違いによって、真実が見えなくなってしまうからです。たとえば、ゲノムビューアの公開者は、ゲノムマッピングによりゲノム配列をリファレンスとしてアノテーションをゲノム配列上に置いていきます。ゲノムビューアの利用者は、ゲノム配列に類似性検索を行い、ヒットした領域のアノテーションを参照します。これで、結果を得るためのコンピュータ処理が２段階になってしまいました。もし、ゲノムへのアノテーションがセカンドヒットまで行われていて、セカンドヒットの領域により高いスコアでQuery配列がヒットした場合、さて、これをどう解釈すればよいのでしょう。
