究極の個別化医療を目指したスタートアップが「技術」ではなく「スケーラビリティと規制」で壁にぶつかった話

N=1の創薬。つまり「超希少な遺伝子疾患を持つ、たった1人の患者」のために、完全オーダーメイドの薬を処方するプラットフォームの構築を目指した「EveryONE Medicines」というスタートアップをご存知でしょうか？

彼らは、資金調達も完了し、イギリスでのパイロットテストにもこぎつけていました。しかし、2026年3月、突如として事業停止を発表しました。
技術的に患者を救う一歩手前まで到達しながら、なぜ彼らは倒れざるを得なかったのか。エンジニアや技術組織の視点から、この事例が持つ「アーキテクチャ設計」と「システムのスケーラビリティの限界」について考察します。

オーダーメイドを「プラットフォーム化」しようとした矛盾

ソフトウェア開発において、SaaSモデルは「一度構築したシステムを限界費用ゼロで多くのユーザーに展開できる」からこそ強力です。
EveryONE Medicinesは、手作業になりがちな「N=1の創薬」を、マスタープロトコル（共通の承認枠組み）を使って工場のごとく「スケーラブルなプロセス」に変えようとしました。言わば、バイオテクノロジー界隈でのSaaS化を目指したのです。

しかし、現実は甘くありませんでした。

薬を作るプラットフォームシステム自体をどれだけ抽象化・標準化しても、「この患者の、この固有の遺伝子変異」にアプローチしてテストするフェーズは、極度に労働集約的な「手作業（オーダーメイド）」から抜け出せなかったのです。
コードをリファクタリングするように患者の細胞を簡単に書き換えることはできません。一つ一つのケースが「難易度の高い受託開発プロジェクト」であり、スケーラブルな事業構造を描けなかったことが最大のボトルネックとなりました。

「APIとしての承認」を許さなかった旧来のシステム

彼らのビジネスモデルが成立するためには、**「一つの一つの薬ごとの安全性承認」ではなく、「薬を生成するプラットフォーム（生成マシン）自体の承認」**を規制当局から勝ち取る必要がありました。
しかし、2026年2月に米国食品医薬品局（FDA）が発表したガイダンス草案は、依然として「個別の薬ごとに審査する」という旧来の枠組みを強く残したものでした。

これはソフトウェアに例えるなら、「自動生成システムのデプロイは許可するが、生成された個別の成果物すべてに対して人間による重厚なバリデーションテストを毎回要求する」ようなものです。
技術的なブレイクスルーだけでは超えられない、「ルールの壁」と「資金燃焼」の前に、彼らは撤退を選択しました。

実装アイデア：我々は何を学ぶべきか？

この事例から、技術者がアーキテクチャを決定する際に持つべき重要な視座が得られます。

ルールの外側に出る設計の危険性：
どれほど技術的に美しく、超パーソナライズされたアーキテクチャであっても、最終的なアウトプットが「既存のレガシーな検証・承認プロセス」を経由しなければならない場合、そこが致命的なボトルネックになります。システム全体の最適化を描く際は、「現行の運用フロー」という自分たちのコントロール外にあるコンポーネントの処理能力を必ず考慮する必要があります。
「自動化」と「人的作業」の境界線設計：
高度に個別化された要件を持つドメインでは、完全なSaaS化を狙うよりも、泥臭い「人的作業」を前提とし、その裏側をプログラマティックに効率化する**「Copilot型のアプローチ」**の方が、はるかに持続可能性が高いという現実です。

出典・元記事：本記事は、SaaS事例/先進技術の考察記事（Sparks Station）の一部をQiita向けに技術的な視点で再構成・加筆したものです。