ProDock: From Multi-target Consensus Docking into Database-backed Storage
Phan, Nguyen Song, Le, Phan, Pham, Truong — Leipzig / Texas A&M / Vienna / Ho Chi Minh City | arXiv:2604.12821 (2026)
🎯 断片化したドッキングスクリプトを4段階統合ワークフローで置換し、再現性・トレーサビリティ・SQLiteクエリを実現する
① 背景と課題: スクリプト断片化問題

構造ベースドッキングでは受容体クリーニング・リガンド準備・ファイル変換・ボックス定義・並列実行・後処理が各研究室で独自スクリプトに分散しており、再現性低下・プロビナンス不透明化が恒常的に発生している。

受容体/リガンド準備の微小な不整合がサイレントな実行失敗や非再現結果を引き起こす
中間ファイルに生成パラメータが記録されず、後から解析が困難
後処理が実行から分離されており、スコア・ポーズ・インタラクション回収に one-off パーサーが必要

→ ProDock は新アルゴリズムでなく workflow infrastructure を提供：4段階統合 + JSON provenance + SQLite 永続化

② 手法: 4段階アーキテクチャ
A. PreProcessing PDBQuery → ReceptorPrep → LigandPrep → GridBox B. Docking Execution SingleDock / BatchDock — smina | vina | qvina | qvina-w C. PostProcessing PoseCrawler → Scores → InteractionProfiler (ProLIF) D. SQLite Database receptors / ligands / poses / interactions — queryable
② 手法: 多対多キャンペーン設計
EGFR デモ: 5受容体 × 複数リガンド × 4エンジン Receptors 2ITY 1M17 4G5J 4I23 4ZAU Backends smina vina qvina qvina-w Campaign JSON provenance many-to-many → SQLite で全組み合わせ結果をクエリ可能
③ 主な結果 (a): コンポーネント対応表
ProDock コンポーネント機能
ReceptorPrepPDBFixer + OpenMM 修復→PDBQT
LigandPrepSMILES→RDKit 3D→PDBQT
GridBoxref ligand autobox 生成
BatchDock並列多対多実行 + JSON provenance
PoseCrawlerポーズ回収・スコア一元化
InteractionProfilerProLIF 残基レベル IFP
PoseDatabaseSQLite CRUD + クエリ
③ 主な結果 (b): SQLite スキーマ設計
SQLite スキーマ（多対多リレーション） receptors ligands poses score, rank, backend interactions residue, type engines クエリ例: score <= -8.0 AND residue='Thr790'
③ 主な結果 (c): lib/docking との統合方針
  • UniDockRunner を BatchDock 相当に拡張し JSON キャンペーンシリアライズを追加
  • ProLIFCalculator を InteractionProfiler として残基レベル IFP の自動格納に接続
  • SQLite スキーマ（poses/interactions）を lib/docking に新設し結果永続化を実現
  • pip install prodock で ProDock を直接利用するラッパー採用も選択肢
4
統合対象バックエンド（smina/vina/qvina/qvina-w）
③ 主な結果 (d): 既存ツールとの比較
特徴DockStreamEasyDockProDock
多対多キャンペーン△△✓
JSON provenance△×✓
SQLite 格納××✓
ProLIF IFP 統合×△✓
PyPI インストール✓✓✓
④ 限界点・将来課題
新しいスコアリング関数ではないためドッキング精度自体は向上しない
対応バックエンドが AutoDock Vina ファミリーに限定（Glide 等の商用ソフト非対応）
数億分子規模のウルトラハイスループットスクリーニングには別アーキテクチャが必要
⑤ 実装方針まとめ
ターゲット
lib/docking — CampaignRunner + DockingDatabase クラス
依存
RDKit, PDBFixer, ProLIF, sqlite3
優先度
High（lib/docking の SQLite 統合・再現性強化）
コード参照
github.com/Medicine-Artificial-Intelligence/ProDock
arXiv:2604.12821 | Phan, Truong et al. 2026 | category: computational_chemistry | lib/docking priority: high