「血液型でAIに治験させたい」→ 調べたらコンピュータだけで新薬を作る世界があった
はじめに:ふとした疑問から
ある日、ふと思った。
「血液型ってペルソナとして使えないの?AIに血液型情報を持たせて、仮想の患者に薬を投与したらどうなるかシミュレーションできないかな」
エンジニアとして「バーチャル患者をAIで作れないか」というアイデア自体は割と自然に浮かんだんだけど、調べてみたら、製薬業界ではすでに「コンピュータだけで新薬の臨床試験をシミュレーションする」という取り組みが本格化してた。
しかもかなりヤバかった。
この記事は、その世界を調べてわかったことの整理メモ。
この記事で扱う技術スタック:
- PBPKモデル — 人体を臓器ごとの微分方程式で再現する計算基盤
- LLM — 論文から薬物動態パラメータを自動抽出する仕組み
- ベイズ最適化 — パラメータを実測データに合わせて効率よく調整する手法
最後に最初の疑問「血液型は使えるの?」に答える。
新薬開発、実はめちゃくちゃ失敗する
まず前提として、新薬開発の現実から。
| 指標 | 数値 |
|---|---|
| 新薬1本の平均開発コスト | 約1,800億〜3,000億円 |
| フェーズ1(初期臨床)から承認までの成功率 | 約12% |
| 開発期間 | 平均10〜15年 |
88%は失敗する。 しかも「失敗」が判明するのは、実際に人間に投与した後のことも多い。
なぜこんなに失敗するかというと、主な原因がこのあたり:
- 動物実験では安全だったのに人間では副作用が出た
- 効果が思ったより出なかった
- 特定の体質の人だけに重篤な反応が起きた
「薬を人に試してみないと、人への影響がわからない」という構造的な問題がある。
そこに登場したのがインシリコ(in silico)創薬という考え方。

FDA の PBPK Program 公式ページ。2018年にガイダンスを発行し、IND/NDA/BLA/ANDA での PBPK 解析提出を正式サポート
インシリコ創薬とは
「in silico」はラテン語で「シリコン上で(= コンピュータ上で)」という意味。
コンピュータ上に人体をシミュレーションして、そこに仮想の薬を投与するという発想。
すごく雑に言うと:
従来:
動物実験 → 人間(フェーズ1) → 人間(フェーズ2) → 人間(フェーズ3) → 承認
インシリコ創薬(目指す姿):
コンピュータでシミュレーション → 安全と予測されたものだけ人間へ
これができれば、失敗コストが激減する。
実際、FDAは2018年にPBPKモデルの申請ガイダンスを公式発行しており、新薬申請(NDA/BLA)の約26%でシミュレーション結果が審査資料として活用されている(FDA PBPK Program)。
コアとなる技術:PBPKモデル
インシリコ創薬の中心にあるのが PBPK(Physiologically Based Pharmacokinetic)モデル という技術。
日本語にすると「生理学的薬物動態モデル」。
考え方
人体を「臓器ごとの箱(コンパートメント)」の集まりとして表現する。
[肺] → [心臓] → [肝臓]
↓
[腎臓]
↓
[脂肪組織]
[筋肉]
[脳] ...
薬を飲むと、血流に乗ってこれらの「箱」を移動していく。
各箱での吸収・分解・排泄を微分方程式で記述することで、「この薬が30分後に肝臓にどれくらい残るか」 が計算できる。
実際は連立微分方程式
各臓器コンパートメントの薬物量は、こういう方程式で表現される:
dC_tissue/dt = (Q_tissue / V_tissue) × (C_arterial - C_tissue / Kp)
肝臓など代謝臓器ではさらに代謝項が加わる:
dC_liver/dt = (Q_liver / V_liver) × (C_arterial - C_liver / Kp) - CL_int × C_liver
-
C_tissue:組織内の薬物濃度 -
Q_tissue:血流量 -
Kp:組織/血液分配係数(どれだけ組織に蓄積しやすいか) -
CL_int:代謝クリアランス(肝臓・腎臓など代謝臓器のみに付く項)
臓器が10〜20個あれば、方程式が10〜20本の連立になる。
肝臓・腎臓・筋肉の3コンパートメントで24時間分を計算する簡略実装(概念理解用。実務では Simcyp・GastroPlus 等の専用ツールを使う):
import math
from scipy.integrate import solve_ivp
# ── 1. パラメータ定義 ──────────────────────────────
params = {
"Q_liver": 1.5, # 肝臓血流量 (L/h)
"Kp_liver": 8.0, # 肝臓/血液分配係数
"CL_int": 0.8, # 代謝クリアランス (L/h)
"C_iv": 10.0, # 初期動脈濃度 (μg/L)
}
# ── 2. 各臓器の微分方程式 ─────────────────────────
def pbpk_model(t, y, p):
C_liver, C_kidney, C_muscle = y
C_arterial = p["C_iv"] * math.exp(-0.1 * t) # 動脈濃度(指数減衰で近似)
dC_liver = (p["Q_liver"] / 1.0) * (C_arterial - C_liver / p["Kp_liver"]) \
- p["CL_int"] * C_liver # 肝臓:代謝項あり
dC_kidney = 0.05 * (C_arterial - C_kidney / 3.0) # 腎臓(簡略)
dC_muscle = 0.02 * (C_arterial - C_muscle / 5.0) # 筋肉(簡略)
return [dC_liver, dC_kidney, dC_muscle]
# ── 3. 数値求解(剛性対策で Radau を指定)────────────
result = solve_ivp(
pbpk_model,
t_span=(0, 24), # 24時間シミュレーション
y0=[0.0, 0.0, 0.0],
method='Radau', # ← RK45 だと発散する
args=(params,),
dense_output=True,
)
print(result.y[0, -1]) # 24時間後の肝臓内薬物濃度
可視化するとこうなる:
import matplotlib.pyplot as plt
fig, ax = plt.subplots(figsize=(9, 5))
ax.plot(result.t, result.y[0], label='肝臓', linewidth=2.5, color='#e74c3c')
ax.plot(result.t, result.y[1], label='腎臓', linewidth=2.5, color='#3498db')
ax.plot(result.t, result.y[2], label='筋肉', linewidth=2.5, color='#2ecc71')
ax.set_xlabel('時間 (h)')
ax.set_ylabel('薬物濃度 (μg/L)')
ax.set_title('PBPKシミュレーション:臓器別薬物濃度の推移(24時間)')
ax.legend()
ax.grid(True, alpha=0.3)
plt.tight_layout()
plt.show()

肝臓は代謝で急激に低下、腎臓・筋肉はゆっくり蓄積・排泄。臓器ごとに全然違う動きをするのが見てとれる
なぜ
Radau?
臓器によってタイムスケールが全然違う(肺:数秒 vs 脂肪:数週間)。
この「剛性(Stiffness)」の高い方程式には、陰解法のRadauやBDFが必須。
RK45(デフォルト)だと計算が発散する。

Certara の Simcyp PBPK シミュレーター。製薬業界標準の PBPK モデリングツール
PBPKモデルを動かすにはパラメータ(各臓器の血流量・分配係数など) が必要になる。これをどうやって集めるかが次の問題だ。
LLMが論文を読んでパラメータを自動抽出する
PBPKモデルを動かすには、パラメータ(各臓器の血流量・組織分配係数など)が必要になる。
問題は、これらが**「論文に散らばってる」**ということ。
しかも単一のデータベースにまとまっているわけじゃなく、表のフォーマットや単位もバラバラ。
例えば「半減期」一つとっても:
T1/2Elimination Half-Lifet½ αHLgamma
文献によって数百種類の表記がある。正規表現でのルールベース抽出は無理。
LLMが解決する
最近の取り組みでは、LLMエージェントが論文PDFを読んで、必要なパラメータを自動抽出している。
論文PDF
↓
PDFパーサー(unstructured等)
↓
テキスト・テーブルに分割
↓
オープンソースLLM(Llama, Qwen 等)がパラメータを特定・正規化
↓
JSON形式でデータストアに格納
↓
PBPKモデルに自動投入
プロンプトはこんなイメージ:
<task>
以下の表から薬物動態パラメータを抽出してください。
必ず元の数値と単位を引用し、推測・計算は行わないこと。
出力はJSON形式で。
</task>
<table>
{{ extracted_table_text }}
</table>
<output_schema>
{
"parameter_name": "string",
"value": "number",
"unit": "string",
"source_quote": "string" // 元の文章をそのまま引用
}
</output_schema>
「推測しない、引用だけ」 というルールを守らせることでハルシネーション(でたらめな数値生成)を防いでいる。
なぜオープンソース LLM?
大手製薬企業では社内蓄積論文を NLP で処理しているが、未公開の化合物データを外部 API(GPT-4 等)に送れないケースが多い。ローカル実行できるオープンソース LLM はこの問題を回避できるため採用が進んでいる(出典: ScienceDirect 2025)。

ChEMBL。化合物・活性データ・薬物動態パラメータが集約された研究者御用達 DB
パラメータが集まったら、次は「実測データとのズレ」をどう縮めるかが問題になる。
パラメータを自動調整するLLM誘導型ベイズ最適化
シミュレーション結果が実験データとズレたとき、どのパラメータを変えるかが問題になる。
パラメータが数十〜数百個あると、全部試すのは現実的じゃない。
ここに活用が模索されているのが ベイズ最適化(Bayesian Optimization)× LLM の組み合わせ(研究段階)。
① シミュレーション実行
↓
② 実験データとの誤差を計算
↓
③ LLMが「生物学的に意味のある探索範囲」を提案
(「肝臓の代謝クリアランスはこの範囲が妥当」等)
↓
④ ベイズ最適化が効率的に次の候補点を選択
↓
⑤ ①に戻る(収束するまで自動繰り返し)
従来の勾配法や総当たりと違い、**「少ない試行回数で最適解に近づける」**のがポイント。
Python では optuna を使うのが現実的:
import optuna
from scipy.integrate import solve_ivp
# ※ pbpk_model は前節のコードブロックで定義済み
# 実験で観測した肝臓内薬物濃度-時間曲線下面積(AUC)
observed_AUC = 12.5 # μg·h/mL
def simulate_AUC(CL_int, Kp_liver):
"""簡易PBPKで肝臓内AUCを計算"""
p = {"Q_liver": 1.5, "Kp_liver": Kp_liver, "CL_int": CL_int, "C_iv": 10.0}
res = solve_ivp(pbpk_model, (0, 24), [0, 0, 0], method="Radau", args=(p,))
t = res.t
C_liver = res.y[0] # 肝臓内薬物濃度(CL_int・Kp_liver に依存)
return float(C_liver[:-1] @ (t[1:] - t[:-1])) # 台形積分でAUC
def objective(trial):
# 研究では LLM が「生物学的に妥当な範囲」を提案するアプローチが試みられている
CL_int = trial.suggest_float("CL_int", 0.1, 5.0)
Kp_liver = trial.suggest_float("Kp_liver", 1.0, 20.0)
return abs(simulate_AUC(CL_int, Kp_liver) - observed_AUC)
optuna.logging.set_verbosity(optuna.logging.WARNING)
study = optuna.create_study(direction="minimize")
study.optimize(objective, n_trials=100)
print(f"最適パラメータ: {study.best_params}")
# → {'CL_int': 1.23, 'Kp_liver': 8.7} のように収束する
研究アプローチとして探索範囲をLLMが提案する手法が論文で報告されている(AutoLead 等)。生化学的知識なしで全範囲を探索すると収束が遅くなるため、「この化合物の肝臓への親和性はこの範囲が妥当」という事前知識をLLMに提案させてから最適化を走らせる、というアイデアだ。
エンジニアが今すぐ触れる入口
「面白そうだけど製薬業界はハードル高い」と思ったかもしれないが、意外と普通のツールで入れる。
※ 難易度は「Python に慣れたエンジニアが環境構築してすぐ動かせるか」の目安。
| ツール | 何ができるか | 難易度 |
|---|---|---|
| tellurium | Python で PBPK/ODE モデルを記述・可視化 | ★☆☆(pip install だけ) |
| PyPKPD | PK/PD モデルのフィッティング | ★★☆(薬学の前提知識が必要) |
| ChEMBL API | 薬物動態パラメータを REST で取得 | ★☆☆(認証なし・即使える) |
| PK-DB | 公開されたヒトの薬物動態データ | ★☆☆(ブラウザで閲覧可) |
| Simcyp(Certara) | 商用の本格 PBPK。製薬企業が実際に使う | 要ライセンス |
# ChEMBL API から薬物動態データを取得する例
import requests
# Imatinib(グリベック)の分子情報を取得
res = requests.get(
"https://www.ebi.ac.uk/chembl/api/data/molecule/CHEMBL941.json"
)
data = res.json()
print(data["molecule_properties"]["alogp"]) # 脂溶性
print(data["molecule_properties"]["hba"]) # 水素結合受容体数
ChEMBL の API は RESTful で、認証なしで叩ける。薬の物性(脂溶性・分子量・水素結合数など)がそのまま返ってくるので、PBPK の初期パラメータ推定に使える。
結局、血液型は使えるの?
ここで最初の疑問の答え合わせ。
結論:使えるけど「脇役」
血液型(ABO式)がPBPKモデルに影響する部分:
| 影響 | 説明 |
|---|---|
| von Willebrand因子量 | O型は他の血液型より低いという報告がある → 出血・血栓リスクに微差 |
| 血栓形成リスク | A型がわずかに高いという疫学研究がある |
| 感染症感受性 | 一部の疾患で相関が報告されている |
ただしこれらは**「弱い統計的相関」**(観察・疫学研究による傾向)であって、薬物動態(PK)を直接左右するほど強い変数じゃない。
本命はこっち
バーチャル患者のペルソナとして実際に使われているのは:
| パラメータ | 影響の大きさ |
|---|---|
| CYP2D6/CYP3A4代謝型 | 非常に大きい(同じ薬でも代謝速度が10倍以上違う) |
| HLA型 | 免疫応答・特異的副作用の予測に必須 |
| 年齢・体重・腎機能 | PK全般に直接影響 |
| 血液型 | 限定的(上記の補助的な変数として組み込む程度) |
「血液型B型の人はこの薬が効きにくい」みたいなことは現時点ではほぼ言えない。
ただ将来的には、血液型も含めた多変量なバーチャル患者コホートが設計されていく方向にはある。
まとめ
「血液型でAIに治験させたい」という素朴な疑問から調べ始めたら、思ったより本格的な世界があった。
- 新薬開発の成功率は約12%で、業界全体がコスト問題を抱えている
- PBPK + LLMエージェント + ベイズ最適化で「コンピュータだけで新薬を評価する」流れが加速している
- FDAは2018年にPBPKモデルの申請ガイダンスを公式発行。新薬申請(NDA/BLA)の約26%でシミュレーションが活用されている
- 血液型はバーチャル患者のペルソナとして使えるが、主役は代謝型(CYP)とHLA型
SciPy・LLM・ベイズ最適化というお馴染みの技術スタックが製薬業界でもそのまま使われている。微分方程式を解いて、論文からパラメータを抽出して、ベイズ最適化でフィッティングする——普通のMLパイプラインとほぼ同じ設計思想だ。製薬という「遠い業界」への偏見が少し崩れた。
参考
- DrugPilot: LLM-based Parameterized Reasoning Agent for Drug Discovery(プレプリント, arXiv)
- PBPK-iPINNs: Inverse Physics-Informed Neural Networks for Pharmacokinetic Brain Models(プレプリント, arXiv)
- AutoLead: An LLM-Guided Bayesian Optimization Framework(プレプリント, bioRxiv)
- LLM-BioDataExtractor (GitHub)
- Large Language Models and Their Applications in Drug Discovery — Pfizer R&D 共著 (PMC, 2025)
- Medication information extraction using local large language models (ScienceDirect, 2025)
- FDA PBPK Program(公式)
- Certara Simcyp PBPK Simulator
- ChEMBL Database