DMTAサイクルにおけるデータフロー

低分子創薬

研究情報基盤

Design Hub

ChemAxon

はじめに

製薬業界の研究開発(R&D)では、毎年莫大な費用が費やされているにもかかわらず、市場に出ることのないプロジェクトが数多く存在します。1つの医薬品が承認されるまでには、平均して9つの候補化合物が臨床試験で失敗しており、その過程では数えきれないほどの障害や落とし穴、不確実性が存在します。これらが高額な開発コストの一因となっています。綿密な前臨床試験を経ても、候補薬がヒトに対して期待される治療効果を示さなかったり、安全性に問題があるケースもあり、有望に見える化合物が開発プロジェクトの最終かつ最も高コストな段階で失敗することも珍しくありません。

 

こうした失敗率を下げるために、より優れたリード化合物や臨床候補化合物の設計を目指すことは、長年にわたり創薬に携わるすべての関係者の共通の目標となっています。その目標を支える要素は多岐にわたりますが、ここでは特に2つの重要な要素に注目したいと思います。それは、研究チーム内およびチーム間の自由なコラボレーションと、ヒットからリード化合物への最適化フェーズにおいて、化合物の評価や「次に何を作るか」という意思決定に必要なすべての知識、視点、洞察を一貫して考慮することです。

 

これら2つの要素の背景には、研究チームのメンバーがアクセス・活用できる「データ」が密接に関係しています。仮説駆動型の従来型創薬プロジェクトでは、有望な薬剤候補を「設計→合成→試験→解析(DMTA)」というサイクルを繰り返すことで最適化していきますが、その各フェーズで多様な新しいデータが生成されます。理想的には、こうしたデータすべてに加えて、並行または過去のプロジェクトから得られた類似情報も、プロジェクト期間中チーム全体がアクセスできる状態にあるべきです。しかし実際には、情報へのアクセスが断片的になっているケースが少なくありません。ソフトウェアツールの不整合、互換性のないレガシーシステム、異なるファイル形式、または企業の厳格すぎるポリシーなどが原因で、情報が分断されてしまうのです。このような断片化と、それによって生じる「データのサイロ化」は、製薬R&Dにおけるデータ管理上の最大の課題のひとつとなっています。

では、実際にはこの問題がどのような影響を及ぼしているのでしょうか?

サイロは創薬チームの業務にどのような妨げとなっているのでしょうか?

そして、私たちはどうすればこの壁を打ち破れるのでしょうか?

 

 

DMTA各段階におけるデータサイロ

データソースの数、使用されるアプリケーションの数、データを生成・利用する人の数が増えるほど、情報がサイロ(分断状態)に閉じ込められるリスクは自然と高まっていきます。創薬ワークフローは複雑化が進み、設計→合成→試験→解析(DMTA)のすべての段階で取り扱うデータ量が急増していることから、製薬R&Dにおけるデータの断片化は今後さらに進むことが予想されます。したがって、根本的な原因に積極的に対処しない限り、この問題は深刻化する一方です。

ここでは網羅的な説明を目指すのではなく、DMTAサイクルの中でデータサイロがどのように発生し得るかを示すため、いくつかの例を挙げて説明していきます。

 

設計(Design)

新たな化合物のアイデアが生まれる設計フェーズは、創薬プロセスの中でも伝統的に最も標準化が進んでいない段階のひとつです。Generative AIやその他の機械学習ベースの手法が登場してきているとはいえ、メディシナルケミストの専門知識と直感はいまだに創薬におけるイノベーションの主要な推進力となっています。このような役割の研究者は、多くの場合、自身のアイデアをチームと共有する準備が整うまで、個人で分子設計を進めていく傾向があります。その間に、化学構造の生成、性質の予測、仮想スクリーニングなどを行うために複数のソフトウェアツールを用いて作業します。多様なアプリケーションを用い、各研究者が自分専用の作業スペースで自由にアイデアを練ること自体は、必ずしもデータサイロの発生に直結するわけではありません。しかし現実には、そうした作業が情報の断片化を招いているケースが非常に多いのです。

 

  • このような分断が生じてしまう一因として、現在でもなお構造生成、物性予測、仮想スクリーニングなどに使用される複数の計算化学ツールが、互いに連携しておらず、R&D全体のIT基盤にも統合されていないという現状があります。こうしたツールの利用者は通常、ファイルのエクスポート/インポートや、KNIMEなどを使ったカスタムワークフローを通じて、生成またはスクリーニングされた化合物構造を仮想化合物ライブラリや別のソフトウェアに移動させています。しかしこの工程は、独自ファイル形式やアプリケーション間の互換性の欠如によって、不要なまでに複雑化してしまうことがあります。さらに、こうした方法でエクスポートされたデータには、通常化学構造そのものは含まれていても、それを生成・選定する際に使用したパラメータやその他のメタデータが含まれていないため、設計の背景情報が失われ、後々のレビューが極めて困難になるという問題があります。
  • 以前にも触れましたが、設計仮説や研究成果の記録、化合物構造とアッセイ結果の保存にMicrosoft ExcelやPowerPointといった静的ファイルを使用することが、R&Dチームにどれほどの困難をもたらすかは明らかです。化学構造や設計に関連する考察、意思決定が分断されたファイルに閉じ込められていると、更新や検索が極めて煩雑になります。チームはオフラインファイルのバージョン管理、最新版の所在確認、関係者への共有といった作業を繰り返さねばならず、大きな労力が必要です。加えて、例えば「似たような化合物アイデアがすでに誰かによって検討されていないか」を確認するだけでも、非常に時間がかかり、既に長く複雑なプロセスにさらなる負担を加えることになります。
  • こうした情報へのアクセスのしづらさは、進行中のプロジェクトに限らず、さらに深刻な長期的な悪影響を及ぼすこともあります。数年にわたる研究プロジェクトと、何百人もの研究者によって蓄積された「設計の履歴」が、現在のチームからほぼ完全に見えない状態になってしまい、過去数十年にわたって構築されてきた社内知見に基づく意思決定ができなくなるのです。
  • しかも、設計に関連する情報へのアクセスを必要とするのは設計チームだけではありません。化学構造、合成計画、優先順位といった情報は、社内の合成化学や薬理のチーム、あるいは外部パートナーやCRO(受託研究機関)とも定期的に共有される必要があります。ここに効果的かつ安全で信頼できる情報共有プロセスが存在しないと、協業相手との間で目標のすり合わせができず、不要な遅延や重複作業による時間の浪費が発生してしまいます。
    たとえば、内部での化合物優先順位の変更が外部の合成パートナーに伝わっていない場合、彼らはすでに優先度の下がった化合物の合成作業に数日かけてしまい、本来最も注力すべき化合物の作業に遅れが生じる可能性があります。また、セキュリティ機能がシステムに組み込まれていないことも、別のタイプの遅延の原因となります。細かいアクセス制御機能がない場合、外部とのデータ共有時には共有すべきでない情報が含まれていないかを、手動で何度も確認する必要が出てきます。この作業は一回あたり数分で済むかもしれませんが、これを毎週あるいは毎日、何十人もの担当者が繰り返すことを考えれば、その積み重ねは決して小さな負担ではありません。

 

 

合成(Make)

Makeフェーズ(合成フェーズとも呼ばれます)は、設計された化合物が実際にラボで合成される段階です。データ管理の観点から見ると、このフェーズは一見シンプルに思えるかもしれません。しかし、データのサイロ化や情報の非効率な伝達がこの段階でも深刻な問題を引き起こす可能性があります。ここでは、いくつかの落とし穴を紹介します。

 

  • まず挙げられるのは、合成に関するデータや手法が十分に可視化されていない、あるいは簡単にアクセスできないという問題です。たとえば、ある化学者が、社内の別の誰かがすでに特定の合成プロセスを最適化済みであることを知らない場合、同じ(あるいはほぼ同じ)作業を再度繰り返すことになりかねません。
    このような重複作業が発生する原因のひとつとして考えられるのが、化学反応に対応していないELN(電子実験ノート)システムの存在です。そうしたシステムでは、類似の反応や生成物を検索する機能が備わっていないため、過去の知見を有効に活用することが困難です。こうした冗長性は、設計チームへのフィードバックループを遅らせ、プロジェクト全体の進行にも遅延をもたらします。
  • 合成チームが設計チームから受け取るデータの形式も、非常に重要な要素です。なぜなら、分子の解釈は全チームで一貫していなければならないからです。設計チームは分子モデリング専用のソフトウェアを使っている一方で、合成チームは化学反応の計画や実行に特化した別のツールを使っているかもしれません。こうしたツールが統合されていない場合、データの受け渡しは煩雑な作業になりがちです。データの転送には、ファイルのエクスポート/インポート、あるいは手作業での再入力が必要になることもあり、エラーの発生リスクが高まります。たとえば、立体化学(ステレオケミストリー)の解釈がファイル形式や使用アプリケーションの違いによって異なるという問題は繰り返し発生しており、誤った化合物が合成されてしまうといった深刻な事態を招く可能性があります。
  • また、合成フェーズでは、化学反応の詳細な記録、収率、プロセス中に発生した課題など、多くの新たなデータが生成されます。新規化合物が合成されるたびに得られる知見は、将来のプロジェクトにとって非常に貴重なものです。しかし、この合成フェーズのデータが適切に統合され、中央のリポジトリに保存されていなければ、その知識は簡単に失われてしまいます。将来のチームが「何がうまくいって、何がうまくいかなかったのか」を参照できなければ、過去と同じ失敗を繰り返すことになりかねません(これは前述のポイントに立ち返る問題です)。
    実際には、分子構造、反応、関連データはしばしばスライド資料やメールを通じて共有されており、過去のデータを効果的に検索・参照することがほぼ不可能な状態になっています。
  • 統合されたデータ環境では、合成の進捗をリアルタイムで把握することができ、問題が発生した場合もすぐに特定・対処することが可能になります。しかし、合成の進捗状況がサイロ化された環境に記録されていたり、一貫性のないチャネル(例:メール)を通じて共有されている場合、プロジェクトマネージャーが現在の状況を正確に把握することが困難になります。もし合成に遅れが生じたとしても、断片化されたデータ環境のせいでボトルネックの存在に気づけなかったり、原因を特定できなかったりして、次回以降にタイムリーかつ効果的な対策を講じることが難しくなります(たとえば、「この化合物の合成を続けるべきか、それとも他の化合物に方針転換すべきか」といった判断がしにくくなります)。
  • また、合成された化合物の分析や品質管理の段階でも、データの断片化によってプロジェクトの進行状況の把握が煩雑になったり、更新が遅れたりするリスクがあります。これは、分析やQCを担当するチームが他の研究チームと物理的にも業務的にも分かれて活動しているだけでなく、彼らが使用するLIMS(実験室情報管理システム)などのデータ管理ソリューションが、R&D全体のITインフラから切り離されていることが多いためです。

 

評価(Test)

  • 合成フェーズと同様に、アッセイデータも複数のソースやプラットフォームから得られることが一般的です。各ソースが異なる種類のデータを生成するため、これらのデータが分離された非接続システムに保存されている場合、化合物の性能を包括的に把握することは困難になります。たとえば、生物活性のデータはあるデータベースに、毒性のデータは別のデータベースに、薬物動態(PK)のデータはさらに別の場所に保管されているというケースは珍しくありません。
  • アッセイ結果は、出典によってスプレッドシートやデータベースなど様々な形式で報告されます。データ形式の不統一や、適切に設計されたETL(抽出・変換・ロード)システムの不在は、データの統合や分析を著しく難しくし、研究者が本来の分析業務ではなく、データの変換やクレンジングに多くの時間を費やしてしまう原因となります。
  • 生物学チームが孤立して作業している場合、アッセイ結果が適切かつ迅速に共有されなかったり、仮説や設計セットが保存されている他のシステムとは別の場所に保存されていたりすることがあります。その結果、すでに効果が低いと判明している化合物を設計チームが引き続き作り続けてしまうという非効率な反復が生まれてしまいます。
    多くの組織では、アッセイ結果がプロジェクトチーム全体にすぐにアクセス可能な状態になっていないという課題があります。データが特定の人物や部門に保有されたままになっていることで、設計チームや合成チームへの共有が遅れ、DMTAサイクルにおける反復プロセスの進行が妨げられます。その結果、どの化合物を前進させるか、あるいは改変すべきかという重要な意思決定が遅れてしまうのです。アッセイデータへのタイムリーなアクセスは、創薬プロセスの勢いを維持するために不可欠です。Testフェーズは、合成された化合物の生物活性、効果の強さ、選択性を評価するための段階です。

 

解析(Analyze)

Analyzeフェーズでは、Design・Make・Testの各フェーズで得られたデータを総合的に分析し、化合物に関する有意義な結論を導き出すことを目的とします。この段階では、アッセイ結果の解釈や構造活性相関(SAR)の把握を行い、次のアクションを決定します。このフェーズは、研究者がすべてのデータを俯瞰して完全な状況を把握する必要があるため、データサイロの影響を最も強く受けやすい工程でもあります。

 

  • たとえば、予測パラメータ、合成の詳細、アッセイ結果がそれぞれ異なるデータベースに保存されている場合、それらを統合するためのデータ変換やクレンジングに多大な時間と労力を費やすことになります。
  • また、SAR解析が別のアプリケーション上で実行されている場合、データの全体像を把握したり、有望な候補を特定したりするのが難しくなるおそれがあります。さらに、共有されたSARデータがインタラクティブではない場合、設計チームのメンバーが自由に操作したり、深掘りして新たな相関や洞察を見出したりすることが困難になります。
  • 機械学習モデルなどの高度な分析ツールやアルゴリズムは、複雑なデータセットから洞察を得るために不可欠です。しかし、SAR解析に用いるデータが複数のシステムに分散して保存されている場合、これらのツールを最大限に活用することができません。

 

これまで挙げた例はあくまで一部に過ぎませんが、研究データの断片化によるサイロ化が発生しやすい状況をよく表していると言えます。技術的な観点から見た典型的な原因としては、システム間の連携不足、分散型のデータ保存、そして非互換なファイル形式が挙げられます。しかしながら、根本的な原因はそれ以上に深く、組織内での「データの記録・共有・アクセス」に関するベストプラクティスが整っていないこと、そしてセキュリティ上の懸念といった要素にも起因しています。本来協働すべき部門同士でプロセスや使用するソフトウェアの統一がなされていない場合、サイロのリスクは一気に高まります。さらに、CRO(開発業務受託機関)などの外部パートナーへ業務のアウトソーシングが加速している現状も、創薬という多くの関係者が関わる領域においてサイロ化を避けることを難しくしている要因の一つです。

 

データサイロは避けられないのか?

前のセクションでは、製薬企業のR&Dの日常業務の中で、どのようにしてデータサイロが形成されるのかについて、さまざまな例を通じてご紹介しました。一方で、前向きな側面も存在します。たとえば、多くの製薬R&Dプロジェクトにおいては、化学部門と生物学部門のメンバーが同じ会議に参加し、プレゼンテーションを通じてデータを共有するというのが一般的なスタイルです。この方法は理想的とは言えないかもしれませんが、データサイロによる悪影響をある程度緩和する効果があるのは確かです。

 

では、サイロ化は本当に避けられないものなのでしょうか?

研究データを分断する「壁」を築くのではなく、統合を支援するエキスパートシステムの導入や、R&Dデータを一元管理するリポジトリの整備によって、サイロ化のリスクは大幅に低減することが可能です。質の高いシステム統合がなされていれば、創薬で使用される数多くのソフトウェアツールから得られる情報を、コピー&ペーストやエクスポート・変換・インポートといった煩雑な手作業なしに、自動的に収集・統合することができます。こうして取得・整理された情報を中央のリポジトリに保存することで、データの重複や曖昧さが排除されるだけでなく、過去のナレッジや洞察を単一のプラットフォーム上で分析できるようになります。それにより、組織全体の知見を活用した研究活動が実現可能になります。また、きめ細かなアクセス制御機能を備えたシステムであれば、外部パートナーとの連携が必要な場面でもセキュリティを犠牲にすることなく、安全に情報共有が可能になります。そして何より重要なのは、導入されるエキスパートシステムが柔軟性を持ち、研究者それぞれの多様なワークフローや好みに適応できることです。柔軟性が不足していると、研究者たちは結局新しいツールの使用を諦めてしまい、旧来の方法に戻ってしまうことになり、かえってデータの分断が悪化してしまう恐れもあります。

 

あなたの現場では、どんなストーリーがありますか?

データの断片化をどうやって減らしましたか?

今、どんな「サイロ」と闘っていますか?

 

参考文献

 

お問合せフォーム以外にも、電話やE-mailでのお問い合わせも受け付けています

03-6256-0331

(平日 9:00 ~ 17:00)

info@patcore.com