待つことの代償：臨床データマネジメントに機動性をもたらす

臨床開発の世界では、「時は金なり」という業界の格言が今なお当てはまります。しかし、プロトコルはますます複雑化し、業界全体で開発期間の短縮が進む中、この言葉は単なる決まり文句ではなく、日々の業務上の課題として実感されるようになっています。

臨床試験が停滞すると、その財務的影響は瞬く間に膨らみます。しかし、こうした遅延の原因は、患者の関心の低さや規制上のハードルであることは意外と少なく、むしろデータを管理するために設計されたテクノロジーそのもの、すなわち従来型のレガシーなElectronic Data Capture（EDC）システムであることが少なくありません。

停滞がもたらす高いコスト

問題の実態を把握するには、公開されている実際のデータに目を向けることが有効です。営業トークではしばしば大まかで一般化された数字が用いられますが、Tufts Center for the Study of Drug Development（Tufts CSDD）の最新データは、試験遅延がもたらすコストについて、より正確で根拠のある内訳を示しています。

直接的な運営コスト：第III相試験の実施には、直接的な運営費用として1日あたり平均55,716ドルがかかります。
機会損失コスト：治療薬の上市が1日遅れるごとに、約500,000ドルの売上機会が失われます（腫瘍領域や循環器領域などのブロックバスター医薬品の場合、1日あたりの中央値は140万ドルに達することもあります）。

直接支出と逸失利益の可能性を合わせると、わずか1週間の不要な停止であっても、治験依頼者に380万ドルを超えるコストをもたらしかねません。

レガシーEDCが進捗を停滞させる理由

試験途中でのプロトコル改訂は、統計的に見ても珍しいことではありません。臨床プロトコルの半数以上が、その過程で少なくとも1回の重要な改訂を経験しています。しかし、従来型のEDCシステムは、こうした変更にスムーズに対応することが困難な場合が少なくありません。

レガシーデータベースは硬直的でハードコードされたアーキテクチャに依存しているため、日常的なプロトコル変更であっても、複雑な技術的プロセスが引き起こされます。

カスタム再コーディング：ソフトウェアエンジニアが、基盤となるデータベーススキーマやエディットチェックを手作業で書き換える必要があります。
ダウンタイムとテスト：システムには広範なUser Acceptance Testing（UAT）が必要となり、実施医療機関レベルでのデータ入力を一時停止しなければならないケースも少なくありません。
データ移行：既存の患者データを改訂後の新しい構造に移行する際には、コンプライアンスおよびデータの完全性に関するリスクが生じます。

数日で完了するはずが、従来型EDCでのプロトコル改訂には3週間から6週間もかかることが少なくありません。1日あたり55,000ドルを超える運営コストがかかることを考えると、この遅延は治験依頼者にとって重い負担となります。

板挟みになるCRO：その視点

この技術的なボトルネックは、治験依頼者の予算に影響を及ぼすだけでなく、治験依頼者とCROの関係に不要な緊張をもたらすこともあります。

治験依頼者がContract Research Organization（CRO）とパートナーシップを組む理由は様々です。自社の運営リソースを補うため、特定の治療領域における専門知識を活用するため、あるいは確立された実施医療機関ネットワークを活用するためなど、その動機は多岐にわたります。しかし、そうした個別の理由にかかわらず、共通して期待されているのは、試験を通じて着実なモメンタムを維持できることです。

改訂が承認されると、治験依頼者は当然、迅速な実行を期待します。しかし、CROはレガシーEDCベンダーの開発サイクルに全面的に依存せざるを得ず、もどかしい立場に置かれることが少なくありません。

テクノロジーがタイムラインを左右するとき：規制当局の承認が完了し、実施医療機関の準備も整ったことをCROが治験依頼者に伝えなければならない一方で、EDCベンダーが改訂のコーディングとテストに4週間を要するとなれば、信頼関係は揺らぎ始めかねません。

CROは自らコントロールできないタイムラインについてもどかしさを抱えることになり、一方の治験依頼者は資金が目減りしていくのを目の当たりにします。本来、テクノロジーは物事を後押しする存在であるべきですが、レガシーアーキテクチャはしばしばそれをクリティカルパス上に押し上げてしまい、協力関係にあるはずのパートナーシップを双方にとってストレスの多い状況に変えてしまいます。

テクノロジーをクリティカルパスから切り離す：CRScubeのソリューション

CRScubeでは、臨床試験のタイムラインはソフトウェア開発の都合ではなく、サイエンスと患者ケアによって決定されるべきだと考えています。私たちは、データマネジメントのためのテクノロジーを、試験の立ち上げやプロトコル調整のクリティカルパスから切り離し、チームとともに機能するプラットフォームを設計しました。

AI主導のEDCセットアップ：試験の初期構築段階で数ヶ月にわたるカスタム開発を繰り返す代わりに、CRScubeはAIによる自動化を活用してデータベースのセットアップを加速します。当社のシステムは試験関連文書を取り込み、フォームやエディットチェック、データ構造の自動生成を支援することで、標準的なセットアップ期間を大幅に短縮し、First Patient In（FPI）へより効率的に到達できるようにします。
真のノーコードプラットフォーム：私たちは、従来のハードコード型アーキテクチャとは異なる道を選びました。CRScubeは純粋なノーコードプラットフォーム上で稼働します。プロトコル改訂が発生しても、書き換えるべきカスタムコードはなく、手作業で再構築するデータベースもなく、長期にわたるダウンタイムも発生しません。
設定変更のみで完結する数日単位の改訂：当社のプラットフォームは完全に設定ベースの枠組みに依存しているため、試験途中の改訂を実装する際も、データベースを再構築するのではなく、ビジュアルインターフェース上で設定を調整するだけで済みます。従来型EDCのセットアップが再コーディングと移行テストに3週間から6週間を要する一方、CRScubeは数週間ではなく数日で改訂を実現し、データ入力を止めることなくタイムラインを維持します。

足並みをそろえたパートナー。アジャイルな試験。

臨床試験には本質的に予測不可能な要素がつきものですが、それを管理するために使用するテクノロジーが、その不確実性をさらに増幅させるべきではありません。EDCシステムが運営上のタイムラインを左右してしまうと、治験依頼者とCROという重要な関係に負荷がかかり、本来患者のアウトカムに向けられるべき意識が、ソフトウェアのトラブルシューティングへとそれてしまいます。

硬直的でハードコードされたソフトウェアから離れ、アジャイルで設定主導型のプラットフォームを採用することで、臨床チームはテクノロジーをクリティカルパスから完全に切り離すことができます。改訂にかかる期間を数週間から数日へと短縮することは、単に予算を守るだけにとどまりません。それは治験依頼者とCROの間の協力的な信頼関係を守り、両者が意味のある治療を患者に安全かつ効率的に届けることに専念できるようにするものです。

参考文献

Getz, K. (2024). Quantifying the Value of a Day of Delay in Drug Development. Tufts Center for the Study of Drug Development (Tufts CSDD) White Paper.
Getz, K. (2024). "How Much Does a Day of Delay in a Clinical Trial Really Cost?" Applied Clinical Trials.
Tufts Center for the Study of Drug Development (CSDD). Data on the frequency, causes, and operational impact of mid-study protocol amendments.