「分子シミュレーションが実験室を消す日は来るか？」
2026年2月26日、Eli Lillyがインディアナポリスで発表した答えは、少なくとも「その日は想定より近い」だった。LillyPodと名付けられたAIスーパーコンピュータは、1,016基のNVIDIA Blackwell Ultra GPUを搭載し、9,000ペタフロップスを超える演算能力を持つ。製薬会社が単独所有する施設としては世界最大だ。
この記事では、LillyPodの技術アーキテクチャを解剖する。単なる「すごいスペック」の紹介ではなく、なぜこのアーキテクチャが創薬の時間軸を変えうるのか、AIエージェント開発者の視点から読み解く。
LillyPodのスペックを数字で読む
まず数値の全体像を整理しよう。
| 項目 | 詳細 |
|---|---|
| GPU | NVIDIA Blackwell Ultra × 1,016基 |
| システム | DGX SuperPOD構成 |
| 総演算能力 | 9,000ペタフロップス（AI向け） |
| 構築期間 | わずか4ヶ月 |
| 稼働開始 | 2026年2月26日 |
| 主な用途 | タンパク質拡散モデル・小分子GNN・ゲノム基盤モデルの学習 |
9,000ペタフロップスは9クインティリオン（10の18乗）回の計算を毎秒実行できる数値だ。NVIDIAによると、Blackwell Ultra GPU 1基が持つ処理能力は、1992年当時の世界最高峰スーパーコンピュータ（Cray）約700万台分に相当する。1,016基ではその700万倍×1,016倍の計算能力ということになる。
（ソース: NVIDIA Blog — Lilly Deploys World’s Largest AI Factory for Drug Discovery、参照日: 2026-04-09）
DGX SuperPODアーキテクチャ: なぜBlackwell Ultraなのか
NVIDIA DGX SuperPODは、複数のDGXノードをNVLink/InfiniBandネットワークで密結合させた構成だ。LillyPodが採用したDGX B300システムは、Blackwell Ultra GPU（B300）を搭載した最新世代のノードになる。
Blackwell UltraがBlackwell（前世代）から何が変わったかというと、主に以下の3点だ：
- HBM3eメモリの増量: より大きなモデルをGPUメモリ上に展開できる
- NVLink-Cの高速化: ノード間の通信帯域が向上し、モデル並列化の効率が上がる
- MIG（マルチインスタンスGPU）の改善: 複数のAIワークロードを同一GPU上で効率的に実行
創薬AIにとってこれが重要な理由は、分子シミュレーションの「サイズと速度のトレードオフ」にある。タンパク質の3D構造を予測するモデルは非常に大きく（数十〜数百億パラメータ）、かつ膨大な仮説を並列で試す必要がある。
創薬AIの3つのコアワークロード
LillyPodが稼働させる主要なAIワークロードは、Eli Lillyの公式発表から3つに整理できる。
ワークロード1: タンパク質拡散モデル
タンパク質の3D構造予測とde novo設計。AlphaFold2以降、この分野では「拡散モデル（Diffusion Model）」が主流になりつつある。拡散モデルは、既知の構造からノイズを加えて「崩壊」させ、そこから新構造を生成する逆プロセスを学習する。
LillyPodでは、これを大規模にスケールさせることで、「人間の化学者が思いつかない原子配置」を大量に生成し、その中から有望な候補を絞り込む。
ワークロード2: 小分子グラフニューラルネットワーク
低分子化合物の活性予測。分子はグラフ構造（原子=ノード、結合=エッジ）として表現でき、GNN（グラフニューラルネットワーク）はこの構造から特性を予測する。
Blackwell Ultraの密行列演算能力は、大規模なGNN学習で直接的な恩恵をもたらす。特に、何十億もの化合物候補を高速にスクリーニングする「バーチャルスクリーニング」で威力を発揮する。
ワークロード3: ゲノム基盤モデル
患者ゲノムデータを使った疾患リスク予測と、薬効の個人差分析。GPUクラスタが必要な理由は、ゲノムデータのサイズにある。1人分のゲノムは約30億塩基対あり、大規模コホート（数万〜数十万人分）を扱うモデルは、従来のCPUベース処理では非現実的だった。
「計算上のドライラボ」が意味すること
Eli Lillyの公式発表で注目したいのは、「数十億の分子仮説を実験室での検証前に並列シミュレーションできる」という表現だ。これは「計算上のドライラボ」という概念を実装したものだ。
従来の創薬プロセスとの対比を見てほしい：
| フェーズ | 従来 | LillyPod導入後 |
|---|---|---|
| 候補化合物数 | 数百〜数千件/年 | 数十億件をコンピューター上でスクリーニング |
| 絞り込み方法 | 実験 + 推測 | AI予測 → 上位候補のみ実験 |
| PoC期間 | 2〜4年 | 短縮（具体的数値は未公表） |
| 研究者の役割 | 広範な合成・実験 | AI候補の評価・高度な判断に集中 |
重要な注意点: 具体的な開発期間の短縮率はEli Lillyが公表していない。「短縮される」という方向性は示されているが、「何倍速くなった」という数値はまだない。
Lilly TuneLab: AIモデルの外部提供モデル
LillyPodのもう一つの側面は、ビジネスモデルだ。Eli Lillyは「Lilly TuneLab」という形で、LillyPodで学習させた創薬AIモデルをバイオテック企業向けに提供する。Lillyの10億ドル超のデータコストで学習されたモデルを、フェデレーテッドラーニングインフラ経由でアクセスできる仕組みだ。
フェデレーテッドラーニングを採用している理由は、データプライバシーだ。各バイオテックの独自データをLillyサーバーに送らずに、モデルだけを更新できる。
AIエージェント開発者が参照できる設計原則
LillyPodのアーキテクチャから、大規模AIエージェントシステムを設計する際に参照できる原則を抽出する。
以下はPythonによる並列分子仮説評価の概念的な実装例だ（LillyPodの実際のコードではなく、アーキテクチャの考え方を示すサンプルコード）：
# 動作環境: Python 3.11+, asyncio
# 概念実装サンプル — LillyPodの実際のコードではありません
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
import asyncio
from typing import List, Dict
async def evaluate_molecular_hypothesis(
molecule_smiles: str,
model_endpoint: str
) -> Dict:
"""
単一分子仮説の評価
実際のLillyシステムではGPUクラスタ上の推論APIを呼び出す
"""
# ここではHTTPクライアントで推論APIを呼ぶ想定
async with aiohttp.ClientSession() as session:
payload = {"smiles": molecule_smiles}
async with session.post(model_endpoint, json=payload) as resp:
result = await resp.json()
return result
async def parallel_screening(
candidate_molecules: List[str],
batch_size: int = 1000,
max_concurrent: int = 100
) -> List[Dict]:
"""
数百万の候補化合物を並列スクリーニング
batch_size: 1バッチあたりの分子数
max_concurrent: 同時実行する並列タスク数
"""
semaphore = asyncio.Semaphore(max_concurrent)
results = []
async def bounded_evaluate(mol: str):
async with semaphore:
return await evaluate_molecular_hypothesis(
mol, "https://lillypod-internal/api/v1/screen"
)
# batches に分割して並列実行
for i in range(0, len(candidate_molecules), batch_size):
batch = candidate_molecules[i:i+batch_size]
batch_results = await asyncio.gather(
*[bounded_evaluate(mol) for mol in batch]
)
results.extend(batch_results)
# レート制限対策: バッチ間で100ms待機
await asyncio.sleep(0.1)
# 上位候補を絞り込み（活性スコア上位1%）
top_candidates = sorted(
[r for r in results if r.get("activity_score", 0) > 0],
key=lambda x: x["activity_score"],
reverse=True
)[:len(results) // 100]
return top_candidates
ポイント: asyncio.Semaphoreでコンカレンシーを制限しているのは、GPUリソースの過負荷を防ぐため。1,016基のGPUがあっても、無制限に並列リクエストを送ると逆にスループットが下がる。
タンパク質構造予測: AlphaFold2スタイルの推論実装
LillyPodが実行するタンパク質拡散モデルの推論パイプラインを、概念的に実装してみよう。実際のLillyのコードではなく、アーキテクチャの考え方を示すサンプルだ。
# 動作環境: Python 3.11+, torch>=2.0, transformers>=4.40
# pip install torch transformers biopython
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
# このコードはLillyの実際のシステムではなく、アーキテクチャの参照実装です。
import torch
import json
from typing import Optional
class ProteinDiffusionInference:
"""
タンパク質拡散モデルの推論クライアント
実際のLillyPodでは、このクライアントがGPUクラスタのAPIを呼び出す
"""
def __init__(self, model_endpoint: str, api_key: str):
self.endpoint = model_endpoint
self.headers = {"Authorization": f"Bearer {api_key}"}
def generate_protein_structure(
self,
sequence: str,
num_samples: int = 10,
guidance_scale: float = 7.5,
num_diffusion_steps: int = 100
) -> list[dict]:
"""
アミノ酸配列から3D構造を生成
Args:
sequence: アミノ酸配列（例: "MKTLLILAVLCLGFAQASSSTDKQLQ..."）
num_samples: 生成する候補構造数
guidance_scale: 構造品質と多様性のトレードオフ（高いほど品質重視）
num_diffusion_steps: 拡散ステップ数（多いほど精度向上・時間増）
Returns:
予測された3D構造のリスト（pLDDTスコアつき）
"""
import requests
payload = {
"sequence": sequence,
"num_samples": num_samples,
"guidance_scale": guidance_scale,
"diffusion_steps": num_diffusion_steps,
}
response = requests.post(
f"{self.endpoint}/v1/protein/generate",
json=payload,
headers=self.headers,
timeout=300 # タンパク質生成は時間がかかる
)
response.raise_for_status()
structures = response.json()["structures"]
# pLDDTスコア（予測精度指標）でフィルタリング
# 70以上が「高信頼度」、90以上が「非常に高信頼度」
high_confidence = [
s for s in structures
if s.get("mean_plddt", 0) >= 70
]
return sorted(high_confidence, key=lambda x: x["mean_plddt"], reverse=True)
# 使用例
if __name__ == "__main__":
client = ProteinDiffusionInference(
model_endpoint="https://your-ml-platform.internal",
api_key=os.environ["ML_API_KEY"]
)
results = client.generate_protein_structure(
sequence="MKTLLILAVLCLGFAQASSSTDKQLQ",
num_samples=50,
guidance_scale=9.0,
)
print(f"高信頼度構造: {len(results)}件")
print(f"最高pLDDTスコア: {results[0]['mean_plddt']:.1f}")
フェデレーテッドラーニングでデータプライバシーを守る
Lilly TuneLab（外部バイオテック向けAPI）がフェデレーテッドラーニングを採用している理由は実用的だ。各企業の独自データをLillyサーバーに送らずに、モデルの勾配情報だけを集約してモデルを更新できる。
# 動作環境: Python 3.11+, flwr>=1.10（Flower - フェデレーテッドラーニングフレームワーク）
# pip install flwr torch
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
# フェデレーテッドラーニングの概念実装サンプルです
import flwr as fl
import torch
import torch.nn as nn
class MolecularPropertyModel(nn.Module):
"""小分子特性予測モデル（概念実装）"""
def __init__(self, input_dim: int = 1024, hidden_dim: int = 512):
super().__init__()
self.layers = nn.Sequential(
nn.Linear(input_dim, hidden_dim),
nn.ReLU(),
nn.Dropout(0.2),
nn.Linear(hidden_dim, 256),
nn.ReLU(),
nn.Linear(256, 1),
nn.Sigmoid()
)
def forward(self, x: torch.Tensor) -> torch.Tensor:
return self.layers(x)
class BiotechFederatedClient(fl.client.NumPyClient):
"""
各バイオテック企業がローカルで実行するFLクライアント
データはローカルに留まり、モデルの重みのみをサーバーに送る
"""
def __init__(self, local_data_path: str):
self.model = MolecularPropertyModel()
self.local_data_path = local_data_path # 社外に出ないデータ
def get_parameters(self, config):
return [val.cpu().numpy() for _, val in self.model.state_dict().items()]
def fit(self, parameters, config):
# グローバルモデルの重みを受け取る
params_dict = zip(self.model.state_dict().keys(), parameters)
state_dict = {k: torch.tensor(v) for k, v in params_dict}
self.model.load_state_dict(state_dict)
# ローカルデータでファインチューニング（データは外部に出ない）
local_dataset = load_local_dataset(self.local_data_path)
train_local(self.model, local_dataset, epochs=config.get("local_epochs", 5))
# 更新された重みを返す（生データは一切送らない）
return self.get_parameters(config={}), len(local_dataset), {}
# Flowerサーバーへの接続（グローバルモデルと重みを交換）
fl.client.start_numpy_client(
server_address="lillytunelabs.lilly.com:8080",
client=BiotechFederatedClient(local_data_path="/data/proprietary_molecules/")
)
ポイント: `fit()`メソッドの中でローカルデータをロードして学習しているが、サーバーに返しているのは「更新後の重み」のみ。生の分子データは一切サーバーに送られない。これがフェデレーテッドラーニングのプライバシー保護の核心だ。
Omniverse統合: 物理シミュレーションとの連携
LillyPodはNVIDIA Omniverseとも統合されており、製造プロセスのデジタルツイン（仮想複製）を構築している。デジタルツインにより、物理的な製造ラインを変更する前に、シミュレーション上で最適化できる。
これはAIエージェントのユースケースとしても興味深い。製造工程における「仮説検証を実環境より先に計算空間で行う」という設計は、ソフトウェア開発のCI/CD環境や、シミュレーション環境でのエージェント評価にも応用できる考え方だ。
【要注意】LillyPodを巡る過大評価パターン
落とし穴1: 「創薬期間が劇的に短縮される」という主張
Eli Lillyの公式発表は慎重で、具体的な期間短縮率を数値で示していない。「加速する」「より効率的になる」という方向性は示されているが、創薬には規制承認プロセス（FDA等）という物理的な時間軸があり、AI計算だけで全体を劇的に圧縮するのは難しい。
落とし穴2: 「AIが人間の研究者を置き換える」という解釈
Eli LillyのCDAO（最高データ分析責任者）の発言を見ると、AIは「化学者が今まで到達できなかった原子配置を発見するのを助ける」という表現だ。置き換えではなく、研究者の能力拡張。この区別は重要だ。
落とし穴3: 他社が同じものを即座に構築できるという思い込み
LillyPodは10億ドル以上のLilyデータを学習に使っている。ハードウェアが同じでも、10億ドル分の医薬品研究データは1〜2年では複製できない。データとモデルの差別化が本当の参入障壁だ。
参考・出典
- Lilly Deploys World’s Largest AI Factory for Drug Discovery Using NVIDIA Blackwell — NVIDIA Blog（参照日: 2026-04-09）
- Lilly Launches LillyPod NVIDIA DGX SuperPOD for Genomics and Drug Discovery AI — HPCwire（参照日: 2026-04-09）
- Pharmaceutical giant Lilly launches Nvidia DGX B300 SuperPOD — Data Center Dynamics（参照日: 2026-04-09）
- Now Live: The World’s Most Powerful AI Factory for Pharmaceutical Discovery — NVIDIA Blog（参照日: 2026-04-09）
あわせて読みたい:
- AIエージェント構築完全ガイド — 大規模エージェントシステムの設計パターン
- AIエージェント構築ツール徹底比較 — 用途別の選定ガイド
大規模AIシステムの設計・導入についてのご相談は Uravation お問い合わせフォーム からどうぞ。
この記事はAIgent Lab編集部がお届けしました。
