magattacaのブログ

日付以外誤報

CXSMILESでSMILESに情報を追加する話

マクロ分子の表現HELMについて調べているうちに見慣れないSMILES表現に出会いました。Pistoia Alliance HPのHELMの解説でMonomer (Alanine) の表現として記載されていたものです。

f:id:magattaca:20201123113248p:plain

色々と調べた結果おそらくCXSMILESなのかな?という結論に達しました。

というわけで、CXSMILESについての記事です。ついでにフェロセンをどう表すか問題についても遊んでみました。

CXSMILES

CXSMILES(ChemAxon Extended SMILES)はChemAxon社によるSMILESの拡張表現です(そのまんま)。

簡単にいうとSMILES文字列のあとに分子の特徴を追加で記載する表現形式です。基本的な形式は以下の通り

SMILES_String |<feature1>,<feature2>,...|

SMILESではスペースやタブで区切って書かれた情報をコメントとして無視することになっているそうです。これを利用して、区切りの後にバーティカルバー「|」で挟む形で特徴を記載し、+αの情報を追加する、というのが基本的な内容です。

記載できる特徴としては原子の座標、アトムラベル、配位結合・水素結合、立体配置といったものがあります。

ChemAxson社のこちらのページ (ChemAxson Extended SMILES and SMARTS - CXSMILES and CXSMARTS )に追加できる特徴やその記載方法が書かれているのでご参照ください。*1

RDKitとCXSMILES

CXSMILESはRDKitでも取り扱うことができます。The RDKit BookCXSMILES extentions項の記載をChemAxonの説明と比較しつつ表にしてみました。*2

構文解析(parse)できる特徴 記載方法 MolToCXSMILESで書き出せるか?
原子座標
atomic coordinate
(x,y,z);(x,y,z); できる
原子価
atomic values
$_AV: できる
原子のラベル/エイリアス $で挟み、各ラベルは;で区切る できる
原子のプロパティ atomprop:0.key1.value1:0.key2.value2:1.key3.value3
アトムインデックス、キー、バリューを1セットにコロンで区切る
できる
配位結合 C:結合の最初の原子のインデックス.結合のインデックス,
RDKitでは2重結合に翻訳される
ラジカル 1価のラジカル中心は^1:の後、
2価のラジカル中心は^1:の後...
できる
立体化学表現の拡張
enhanced stereo
絶対立体配置 a:<atom index>,...
OR o:<atom index>,...
AND &:<atom index>,...
できる
Link node LN:<atom index>:<minimum repetition>.<maximum repetition>.<first outer atom index>,<second outer atom index>,...
多重中心
multi-center attachments
m:<multicenter atom index>:<atom index>.<atom index>...
環結合数の指定
rinb bond count specification
rb
非水素置換数の指定 s
不飽和の指定 u

RDKitで原子のラベル/エイリアスとして認識されるものは_APstar_eQ_eQH_pAH_PX_pXH_pM_pMH_p*です。

enhanced stereoはRDKitではStereoGroupsに変換されます。ABSANDORの説明と利用方法はThe RDKit BookのSuppoer for Enhanced Stereochemistryの項に記載があります。

Link Nodeは実例があまりなく何を表すのかわかりませんでした。ご存知の方教えていただけると嬉しいです。

Pistoia Alliance アラニンモノマーの解釈

CXSMILESの記法だけを並べてもよくわからないので、実例として冒頭のアラニンを見直してみます。

f:id:magattaca:20201123111214p:plain

まず、SMILES文字列中のアスタリスク(*)は「水素原子以外の全ての原子」を表すワイルドカードなのでSMARTSにあたると思います。*3

スペースを挟んで追記されている特徴は以下の通りです。

  • r」 相対的立体配置(relatice stereoconfiguration)を表します。
  • $;;;_R1;;_R2;$」 原子のラベル/エイリアスを表します。

原子一つずつをセミコロンで区切ってあらわすので、SMILESにおける4番目と6番目の(水素以外の)原子、つまり2つのワイルドカード(*)に対して「_R1_R2」というラベルを与えています。

このCXSMILES表記はHELMモノマーのアラニンを表すので、「ペプチド結合の相手に何が来ても良いようにSMILESを表現する」という要件を満たすように拡張表記が活用されている、という様子ですね。

Atom label/aliaseについてはRDKitでも取り扱えるとのことですので、早速読み込んでみましょう。

from rdkit import rdBase, Chem
from rdkit.Chem import Draw
from rdkit.Chem.Draw import IPythonConsole
print('rdkit version: ', rdBase.rdkitVersion)
# rdkit version:  2020.03.2

alanine_monomer = Chem.MolFromSmiles('C[C@H](N[*])C([*])=O |r,$;;;_R1;;_R2;$|')
alanine_monomer 

f:id:magattaca:20201123111331p:plain

無事、_R1や_R2といったラベルを含めたMolオブジェクトを生成することができました。原子の情報を確認してみます。*4

# 原子の取得
atoms = [a for a in alanine_monomer.GetAtoms()]

print('atom index 3: Symbol: ', atoms[3].GetSymbol())
print('atom index 3: Properties: ', atoms[3].GetPropsAsDict())

# atom index 3: Symbol:  *
#  atom index 3: Properties:  {'dummyLabel': '*', 'atomLabel': '_R1', '__computedProps': <rdkit.rdBase._vectNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEE object at 0x11ea3ae10>, '_CIPRank': 1}

ワイルドカードにはdummy labelというKeyが、_R1にはatomLabelというKeyが割り当てられているようです。

セミコンマによる区切りがわかりづらいので数字をそのまま割り当ててみます。

alanine_fig = Chem.MolFromSmiles('C[C@H](N[*])C([*])=O |$0;1;2;3;4;5;6$|')
alanine_fig

f:id:magattaca:20201123111919p:plain

なるほど。

出力と読み込み

CXSMILESの動作が分かってきたので、もう一例CXSMILESの読み書きを行ってみます。

例としてRDKit Blog「 New drawing options in the 2020.03 release」で取り上げられているジクロフェナクをお借りします。

from rdkit.Chem.Draw import rdMolDraw2D
from rdkit.Chem import rdDepictor
rdDepictor.SetPreferCoordGen(True)
from rdkit.Chem.Draw import IPythonConsole
from IPython.display import SVG

diclofenac = Chem.MolFromSmiles('O=C(O)Cc1ccccc1Nc1c(Cl)cccc1Cl')

cp = Chem.Mol(diclofenac)
cp.GetAtomWithIdx(2).SetProp("atomNote","pKa=4.0")
d2d = rdMolDraw2D.MolDraw2DSVG(350,300)
d2d.drawOptions().setHighlightColour((0.8,0.8,0.8))
d2d.DrawMolecule(cp,highlightAtoms=[2])
d2d.FinishDrawing()
SVG(d2d.GetDrawingText())

f:id:magattaca:20201123112003p:plain

カルボキシル基の酸素原子にpKaのプロパティをセットしています。

これをCXSmilesに変換してみます。

cp_cxsmi = Chem.MolToCXSmiles(cp)
print(cp_cxsmi)
# 'O=C(O)Cc1ccccc1Nc1c(Cl)cccc1Cl |atomProp:2.atomNote.pKa=4.0|'

SMILES文字列に続いてatomPropが加わっています。Atom Index 2の原子に対して、atomNoteというKeyにpKa=4.0というValueがセットされています。

このCXSMILESから再度Molオブジェクトを構築してみます。

cp_reconst = Chem.MolFromSmiles(cp_cxsmi)
cp_reconst

f:id:magattaca:20201123112058p:plain

再構築したMolオブジェクトでも原子のプロパティがうまく認識されているようです。

線形表記にプロパティを追加でき、再構築しても情報が再現できるというのは多数の分子を取り扱う際にデータ量の節約になりそうです。

フェロセン問題

つづいて話題をかえて「フェロセンどうやって表記するの?」問題に取り組みます。

唐突感がありますが、フェロセンはどうもSMILESでは表しづらい分子だそうです。

フェロセンのSMILES表記

SlideShareに公開してくださっていた資料 「第11回分子化学討論会 PubChemQCプロジェクト: 分子データベース構築と機械学習による電子構造の推定」のスライド p13には「SMILESで表現できない例」というタイトルでFerroceneが例示されています。

スライドには表現例として以下の2つが記載されています。2つめはPubChem(Ferrocene) の表記と同じです。

  1. C12C3C4C5[Fe]23451234C5C1C2C3C45
  2. [CH-]1C=CC=C1.[CH-]1C=CC=C1.[Fe+2]

それぞれRDKitでMolオブジェクトに起こしてみましょう。まずは1つ目。。。

Fer_1 = Chem.MolFromSmiles('C12C3C4C5C1[Fe]23451234C5C1C2C3C45')
Fer_1

f:id:magattaca:20201123112124p:plain!

・・・・スターウォーズにこういう飛行機あった気がする。

for b in Fer_1.GetBonds():
    print('{}: {}'.format(b.GetIdx(), b.GetBondType()))

# 0: SINGLE
# 1: SINGLE
# 2: SINGLE
# 3: SINGLE
# 4: SINGLE
# 5: SINGLE
# 6: SINGLE
# 7: SINGLE
# 8: SINGLE
# 9: SINGLE
# 10: SINGLE
# 11: SINGLE
# 12: SINGLE
# 13: SINGLE
# 14: SINGLE
# 15: SINGLE
# 16: SINGLE
# 17: SINGLE
# 18: SINGLE
# 19: SINGLE

こちらの表現ではFe(II)イオンとシクロペンタジエニルアニオンの結合が明示されている一方で、20本全ての結合が単結合(SINGLE)となっており、芳香属性を表すことができていません。

つづいて2つ目の表現です。

Fer_2 = Chem.MolFromSmiles('[CH-]1C=CC=C1.[CH-]1C=CC=C1.[Fe+2]')

d2d = rdMolDraw2D.MolDraw2DSVG(200,200)
d2d.drawOptions().addBondIndices=True
d2d.DrawMolecule(Fer_2)
d2d.FinishDrawing()
SVG(d2d.GetDrawingText())

f:id:magattaca:20201123112309p:plain

for b in Fer_2.GetBonds():
    print('{}: {}'.format(b.GetIdx(), b.GetBondType()))

# 0: AROMATIC
# 1: AROMATIC
# 2: AROMATIC
# 3: AROMATIC
# 4: AROMATIC
# 5: AROMATIC
# 6: AROMATIC
# 7: AROMATIC
# 8: AROMATIC
# 9: AROMATIC

分かりやすさのためい結合のインデックスも表記しています。描画ではケクレ構造となっていますが、2つめの表現ではシクロペンタジエニルアニオンの結合がすべて芳香属性として認識されています。

一方で、こちらではFe(II)イオンとの間の結合が表現できていません。

SMILESの拡張表現を使えばうまくフェロセンを表現できるのか?検証してみましょう。

CXSMILESの配位結合表記

ChemAxonのCXSMILES解説には、「CXSMILESの一部として現れるSMILESが、必ずしも標準的なSMILESに一致しない」という事例としてフェロセンが挙げられています。

  • plain SMILES: [Fe].c1cccc1.c1cccc1
  • CXSMILES: c12c3c4c5c1[Fe]23451234c5c1c2c3c45 |C:4.5,0.6,1.7,2.8,3.9,7.12,6.10,9.16,10.18,8.14|

但しこれらはどちらもRDKitではエラーが出てしまい扱うことができません。RDKitではシクロペンタジエニルアニオン部位を芳香属性のc1cccc1であらわすとケクレ化ができないとなってしまいます。sanitize=Falseの設定をすることでオブジェクを作ることはできますがDrawでエラーがいっぱい出てきます。

cpa = Chem.MolFromSmiles('c1cccc1', sanitize=False)
cpa
# エラーメッセージは省略

f:id:magattaca:20201123112426p:plain

話を簡単にするために、ここではCXSMILESの配位結合の表現の利用箇所だけを検証したいと思います。

配位結合の表現は「C:結合の最初の原子のインデックス:結合のインデックス」ですので、Feに結合するBondのインデックスと結合に関わる原子のインデックスを取得します。原子のインデックスは配位結合の出発点、FeではなくCとなるようにします。

Fe_connected_bonds = []
C_idx_list = []

for b in Fer_1.GetBonds():
    bond_idx = b.GetIdx()
    
    begin_atom = b.GetBeginAtom()
    begin_symbol = begin_atom.GetSymbol()
    begin_idx = begin_atom.GetIdx()
    
    end_atom = b.GetEndAtom()
    end_symbol = end_atom.GetSymbol()
    end_idx = end_atom.GetIdx()
    
    if begin_symbol == 'Fe':
        Fe_connected_bonds.append(bond_idx)
        C_idx_list.append(end_idx)
        
    elif end_symbol == 'Fe':
        Fe_connected_bonds.append(bond_idx)
        C_idx_list.append(begin_idx)        

print(Fe_connected_bonds)
#    [4, 5, 11, 12, 13, 14, 15, 16, 17, 18]

print(C_idx_list)
#   [4, 6, 7, 0, 8, 1, 9, 2, 10, 3]

追記すべき配位結合の表現は以下となります。

dative_bonds = 'C:'
n = len(Fe_connected_bonds)

for i in range(n-1):
    dative_bonds = dative_bonds + str(C_idx_list[i]) + '.' + str(Fe_connected_bonds[i]) + ','

dative_bonds = dative_bonds + str(C_idx_list[n-1]) + '.' + str(Fe_connected_bonds[n-1])

print(dative_bonds)
#   C:4.4,6.5,7.11,0.12,8.13,1.14,9.15,2.16,10.17,3.18

従ってCXSMILESはこんな感じになりそうです。

Fer_1_CXSMILES = 'C12C3C4C5C1[Fe]23451234C5C1C2C3C45 |C:4.4,6.5,7.11,0.12,8.13,1.14,9.15,2.16,10.17,3.18|'
Fer_1_CX = Chem.MolFromSmiles(Fer_1_CXSMILES)
Fer_1_CX

f:id:magattaca:20201123112600p:plain

できました! あいかわらずシクロペンタジエニルアニオンは単結合のままですが配位結合はそれとして認識できているようです!

念のため確認...

for b in Fer_1_CX.GetBonds():
    print('{}: {}'.format(b.GetIdx(), b.GetBondType()))

# 0: SINGLE
# 1: SINGLE
# 2: SINGLE
# 3: SINGLE
# 4: DATIVE
# 5: DATIVE
# 6: SINGLE
# 7: SINGLE
# 8: SINGLE
# 9: SINGLE
# 10: SINGLE
# 11: DATIVE
# 12: DATIVE
# 13: DATIVE
# 14: DATIVE
# 15: DATIVE
# 16: DATIVE
# 17: DATIVE
# 18: DATIVE
# 19: SINGLE

CXSMILESから起こした構造は配位結合をDative bondとして認識することができているようです。

RDKitで配位結合を形成する

次に、RDKitで配位結合を形成し、それをCXSMILESに変換するという方法を試してみます。

シクロペンタジエニルアニオンとFeの間に結合の無かったオブジェクトに対して配位結合を追加していきます。 まずは原子のインデックスを確認します。

d2d = rdMolDraw2D.MolDraw2DSVG(200,200)
d2d.drawOptions().addAtomIndices=True
d2d.DrawMolecule(Fer_2)
d2d.FinishDrawing()
SVG(d2d.GetDrawingText())

f:id:magattaca:20201123112712p:plain

Fe (Atom Index 10)に対して、シクロペンタジエニルアニオン (Atom Index: 0 ~ 9)から配位結合を形成すれば良いようです。

結合を編集するために、RWMolにオブジェクトを変換します*5

Fer_2_RW = Chem.RWMol(Fer_2)
type(Fer_2_RW)
#  rdkit.Chem.rdchem.RWMol

for i in [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]:
    Fer_2_RW.AddBond(i,10, Chem.BondType.DATIVE)

Fer_2_RW

f:id:magattaca:20201123112754p:plain

for b in Fer_2_RW.GetBonds():
    print(b.GetIdx(), b.GetBeginAtomIdx(),  b.GetEndAtomIdx(), b.GetBondType())
# 0 0 1 AROMATIC
# 1 1 2 AROMATIC
# 2 2 3 AROMATIC
# 3 3 4 AROMATIC
# 4 5 6 AROMATIC
# 5 6 7 AROMATIC
# 6 7 8 AROMATIC
# 7 8 9 AROMATIC
# 8 4 0 AROMATIC
# 9 9 5 AROMATIC
# 10 0 10 DATIVE
# 11 1 10 DATIVE
# 12 2 10 DATIVE
# 13 3 10 DATIVE
# 14 4 10 DATIVE
# 15 5 10 DATIVE
# 16 6 10 DATIVE
# 17 7 10 DATIVE
# 18 8 10 DATIVE
# 19 9 10 DATIVE

シクロペンタジエニルアニオンは全てAROMATIC、Feとの間はDATIVE結合となったオブジェクトを作成することができました!!

これをSMILESおよびCXSMILESに変換してみましょう。まずはSMILES。

Fer_2_smi = Chem.MolToSmiles(Fer_2_RW)
print(Fer_2_smi)
# c12->[Fe+2]3456789(<-c1c->3[cH-]->4c->52)<-c1c->6c->7[cH-]->8c->91

The RDKit Book SMARTS Support and Extensionsの項の記載によると、RDKitではSMILESの拡張として配位結合を<-->で表せるようになっているそうです。

この配位結合の表現と芳香属性炭素(c)の表現が組み合わさったSMILESになっているようです。

つづいてCXSMILESです。

Fer_2_CXSMILES = Chem.MolToCXSmiles(Fer_2_RW)
print(Fer_2_CXSMILES)
#  c12->[Fe+2]3456789(<-c1c->3[cH-]->4c->52)<-c1c->6c->7[cH-]->8c->91 |^2:1|

先にみたように、配位結合はMolToCXSmilesで書き出せるプロパティの中に入っていません。
ですのでSMILES文字列のあとの特徴には配位結合の情報が含まれていないようです。

追記されている特徴^2:1はラジカルを表す表現のようです。ここではAtom Index 1のFeが2価のラジカルとして認識されています。確認のためCXSMILESからMolオブジェクトを作成し、Atom Indexと共に描画してみましょう。

mol = Chem.MolFromSmiles(Fer_2_CXSMILES)

d2d = rdMolDraw2D.MolDraw2DSVG(200,200)
d2d.drawOptions().addAtomIndices=True
d2d.DrawMolecule(mol)
d2d.FinishDrawing()
SVG(d2d.GetDrawingText())

f:id:magattaca:20201123112948p:plain

Atom Index 1のFe2+に対してシクロペンタジエニルアニオンから配位結合がでていることが無事確認できました。

CookBookのやり方

と、ここまで書いてきてRDKit CookBookにOrganometallics with Dative Bondsという項目があることに気づきました。そのまんまやん!

CookBookで書かれている方法を参考にGetNeighbors()をつかって配位結合を設定してみたいと思います。

 Fer_3 = Chem.MolFromSmiles('c12c3c4c5c1[Fe]23451234c5c1c2c3c45', sanitize=False)

# RWMolに変換
rw_mol = Chem.RWMol(Fer_3)

# Fe(原子番号26)のAtomを取得
for atm in rw_mol.GetAtoms():
    if atm.GetAtomicNum() == 26:
        metal = atm

# Feの近接原子を取得
nbrs = metal.GetNeighbors()

# Feとの結合をDativeBondに書き換える
for nbr in nbrs:
    rw_mol.RemoveBond(nbr.GetIdx(), metal.GetIdx())
    rw_mol.AddBond(nbr.GetIdx(), metal.GetIdx(), Chem.BondType.DATIVE)

rw_mol
# エラーは省略

f:id:magattaca:20201123113031p:plain

print(Chem.MolToSmiles(rw_mol))
# c12->[Fe]3456789(<-c1c->3c->4c->52)<-c1c->6c->7c->8c->91

先の2例目と異なりシクロペンタジエニルアニオンのアニオンを設定していないので、Kekule化できないエラーはそのままですが配位結合は設定できているようです。

気づかぬ間にRDKit CookBook内容がすごい更新されてました。はじめからこっち見ておけばよかった。。。

まとめ

以上、今回はSMILESの拡張表現の一つ、CXSMILESとその応用としてFerroceneをどのようにSMIELSで表せるか、という問題にアプローチしてみました。

特徴の追記ができることで、線形表現のままより複雑な情報が表せるというのはとても便利そうです。

一方で、副次的ではありますがChemAxon社のページで記載されていた小文字のcを用いたフェロセンの表記([Fe].c1cccc1.c1cccc1)がRDKitではエラーが出てしまうこと、ソフトウェアによるSMILES表記の取り扱いの違いがわかった点で興味深いと思いました。

適当なことをあれこれ書いているので間違い等ご指摘いただければ幸いです。

*1:以下の記載はChemAxson社ページの記載を引用しています

*2:RDKit Bookの内容をCC BY 4.0のライセンスのもとに利用させて頂いています。

*3:ChemAxsonのドキュメントではSMILESに記載されていますがおそらくSMARTの方が正しいと思います。「化学の新しいカタチ」さんの記事 SMILES記法は化学構造の線形表記法がとても参考になります。

*4:参考:化学の新しいカタチ「RDKitの分子Molオブジェクトを扱う

*5:RDKitドキュメント Getting Started In Python

HELMで核酸医薬をお絵描き

前2回の記事でマクロ分子の線形表現HELMについて概要と利用ツールをみてきました。

「いろいろなモダリティの表現に良さそう!!」ということですが、実際どんな感じになるのでしょうか??
今回は核酸医薬の具体例をお絵描きしていきたいと思います。

核酸医薬の概要

といっても私は核酸医薬をよくわかっていません。

国立医薬品食品衛生研究所 遺伝子医薬部 井上貴雄先生の以下2件の解説に特徴と現状がまとまっており非常にわかりやすかったです。(いずれもオープンアクセス)

以下、引用させていただきつつ、基本的な内容を辿りたいと思います。
長くなってしまったのでご存知の方は飛ばしてください。

核酸医薬の特徴

まず、核酸医薬品とは一般に以下のような医薬品を指します。

  1. 核酸あるいは修飾核酸が十数〜数十塩基連結したオリゴ核酸で構成され、
  2. タンパク質に翻訳されることなく直接生体に作用するもので、
  3. 化学合成により製造される

上記の特徴は、核酸医薬と遺伝子治療用製品との違いを踏まえると納得しやすいかもしれません。(後者は翻訳されたタンパク質が作用(②)し、生物学的に製造される(③))

さて、従来の医薬品(低分子、抗体)と比較した核酸医薬の特徴としては、以下3点が挙げられています。

  1. (従来の標的の)タンパク質のさらに上流のRNAのレベルで制御することができる
  2. 原理的にはすべての分子を創薬対象とすることができる
  3. アンメットメディカルニーズの高い遺伝性疾患や難治性疾患を治療しうる

加えて、新規モダリティとして核酸医薬には従来の低分子と抗体の利点を併せ持つことが期待されています。具体的には以下2点。

  1. 抗体同様、高い特異性有効性をもつ
  2. 低分子同様、化学合成で製造可能できる

(2.の利点はより具体的には低コスト、高均質性でしょうか??)

また、核酸医薬は一度開発スキームができれば、異なる創薬標的に対しても迅速に開発可能なことが期待されます。理由は以下3点。

  1. 共通の構造を有する核酸モノマーが連結した「オリゴ核酸
  2. 有効性の高いシーズ(核酸配列)を短期間で取得できる
  3. シーズがそのまま臨床開発品になる

核酸医薬の課題

このように魅力的な特徴のある核酸医薬品ですが、薬効本体であるオリゴ核酸に由来する、生体内での安定性・有効性という課題がありました。

これらの課題に対して修飾核酸技術薬物送達技術(DDS)といった技術発展により改善が見られ、 現在の全身投与でも高い効果を発揮する候補品の開発に至っている、とのことです。

核酸医薬の薬物送達技術

核酸医薬の実用化に寄与した技術のうち薬物送達技術にはどのようなものがあるでしょうか?

臨床応用されているデリバリー技術は大きく①Lipid Based Nanoparticle、②Polymer Based Nanoparticle、③Conjugated Delivery Sytemに分かれるそうです。 *1

文献2 表1にはPEGGalNacLNPという例が記載されています。*2

薬物送達技術 商品名 一般名 分類 適応 投与
PEG Macugen®︎ pegaptanib アプタマー 滲出型加齢黄斑変性 硝子体内投与
GalNAc Givlaari®︎ givosiran siRNA 急性肝性プリフィリン症 皮下投与
LNP Onpattro®︎ patisiran siRNA 遺伝性ATTRアミロイドーシス 静脈内投与

前2例(PEG、GalNac)は核酸そのものに薬物送達のためのユニットを直接(共有)結合させるもので、 後1例(LNP)は脂質ナノ粒子(Lipid Nano Particle)という粒子に核酸を内包させるDDS技術です。

f:id:magattaca:20201109001435p:plain
薬物送達のためのユニット例

3剤の内、全身投与という観点ではgivosiranpatisiranが当てはまります。 これら2剤はどちらもAlnylam社によるもので標的臓器は肝臓となっています。

例えばgivosiranの場合、GalNAcリガンドは上図のような構造となっているそうです。*3

末端に結合するN-アセチルガラクトサミン(GalNAc)は肝実質細胞の細胞表面に発現するアシアロ糖タンパク質(asialoglycoprotein receptor, ASGPR)に認識され結合します。 そして、受容体介在型エンドサイトーシス(receptor-mediated endocytosis)によって取り込まれることで、細胞内において核酸の効果が発揮されるとのことです。 *4

f:id:magattaca:20201109001548p:plain
GalNAcの役割

なぜhydroxyproline誘導体をかませているのか?炭素鎖の長さの影響は?GalNAcを3つぶら下げてるのは?などなど色々と興味深いところです。

脂質ナノ粒子

全身投与のもう一方patisiranは脂質ナノ粒子(LNP)によって体内動態がコントロールされています。

Alnylam社のOnpattro製品解説ページの図が非常にわかりやすいですが、 とても興味深い輸送メカニズムとなっています。

標的臓器、肝臓に到達するポイントは2点。

  1. 肝臓が大量の血液が潅流する臓器であること
  2. ApoE依存的機構

①は静脈内投与なので血液が集まりやすい肝臓に行きやすくなるのはなんとなくわかります。

面白いのは②で、肝臓分布過程でLNPに内因性アポリポタンパク質E(ApoE)が結合するそうです。 肝細胞表面の低比重リポタンパク質受容体(LDLR)などのApoE結合受容体を介して細胞内に取り込まれる、とのこと。

Alnylam社の2010年の文献ではapoE-/-マウス、LDLR-/-マウスを用いた解析が行われています。*5

www.ncbi.nlm.nih.gov

中性リポソーム(neutral liposome)にアポリポタンパク質が吸着することが一般に知られていて、 その中でアポリポタンパク質Eだけ肝細胞への取り込みを促進できるから、ということに基づく研究のようです。

・・・すごい。

中性と書きましたが、ここも大事なポイントです。

実験室レベルでは核酸送達のキャリアとしてカチオン性キャリアがよく用いられるそうです。*6

カチオン性を用いることの利点は2つ

  1. 負電荷のリン酸基をもつ核酸と静電的に相互作用しナノ粒子を形成(リポプレックス、ポリプレックス)
  2. 細胞表面も負電荷を帯電しているので、細胞内への受動的な取り込みに寄与

一方で核酸医薬のDDSに応用するにあたって困難な問題点も指摘されています。

  1. 細胞毒性:細胞内タンパク質との非特異的吸着による阻害
  2. キャリア正電荷により核酸が細胞内でもリリースされづらい
  3. 生体内組織への非特異的吸着により初回通過臓器(肝臓、肺)に捕捉されやすい
  4. in vivoで血中の細胞、タンパク質との非特異的結合により凝集、不活化、排出される  

そこで臨床応用にあたっては非カチオン性キャリアが重要になってきます。 特にLNPでは非カチオン性脂質とpH感受性カチオン性脂質のハイブリッドといったアプローチがとられています。

このpH感受性というのがとても面白いポイントで、安全性や核酸輸送にとって以下のような利点があるそうです。*7

  1. 血中pH7.4ではほとんどイオン化しない(中性)ので、細胞障害性が低い
  2. 細胞内に取り込まれたのち、エンドソーム・リソソーム内の弱酸性pHでイオン化
  3. イオン化するとエンドソーム・リソソーム膜と融合し、内包核酸を細胞質に効率よく放出

patisiranで用いられているpH感受性カチオン性脂質はDLin-MC3-DMAというもので、pKa6.5前後、3級アミンを有する構造です。

f:id:magattaca:20201109001706p:plain
pH感受性カチオン性脂質

このLNP技術は元々Pieter Cullis 教授らにより2010年 Nature Biotechnolgyに報告された下記文献が鍵となっているようです。*8 LNPの要素として1,2-dilinoleyloxy-3-dimethylaminopropane (DLinDMA)構造に基づく脂質のスクリーニングを行なっています。(読めなかった)

www.nature.com

さらに2012年、Angewante Chemie Internal Editionに報告された文献では、 種々の親水性head groupを有する脂質を用いたpKaとin vivoでの効果の相関を調べており、 pKa 6.2-6.5が最適な範囲であるとしています。(オープンアクセス。Abstractの図がとても印象的です。)*9

Jayaraman M. et. al., Maximizing the potency of siRNA lipid nanoparticles for hepatic gene silencing in vivo. Angew. Chem. Int. Ed. Engl. 2012;51:8529–8533. https://onlinelibrary.wiley.com/doi/full/10.1002/anie.201203263

こういう化学構造のデザインで好ましい性質を達成していくのとても格好いいですよね。*10

修飾核酸

薬物送達技術につづいて修飾核酸による核酸医薬の改善です。

こちらは核酸医薬自体の安定性に関与し、具体的には生体内に存在する核酸分解酵素(ヌクレアーゼ)等による分解への抵抗性や、 標的との結合安定性の強化といった効果が期待されます。

文献2 SAR News No.38 の図2がわかりやすので以下に引用させていただきます。

f:id:magattaca:20201109002816p:plain
SAR News No.38 核酸医薬 〜低分子、抗体に続く第3のモダリティ〜 図2より引用

まずリン酸部位の修飾です。ここには酸素原子を硫黄原子に置換したホスホロチオアート修飾(S化)がよく用いられます(S化オリゴ核酸、Sオリゴ)。

これにより以下の利点が期待されます。

  1. タンパク質との結合の向上、脂溶性の増加により細胞膜上のタンパク質を介した細胞親和性膜透過性が向上
  2. 血中タンパク質との結合による血中滞留性の増加
  3. ヌクレアーゼ耐性の付与による整体安定性の改善

化学的な注意点として、リン原子上に不斉点が発生するためSオリゴは立体異性体混合物になってしまいます。

この立体配置を厳密に制御する技術を持った企業もあるそうです(Wave Life Sciences)。

文献*11によるとリン原子に不斉補助基を結合させたモノマーを使って、伸長・キラルS化を行なっているようです。*12

www.nature.com

・・・すごい。

続いて糖部の修飾です。これによりRNAとの結合力の強化が期待され、2'位の修飾と架橋型修飾が例としてあげられています。

2'位の修飾としては上図に引用した2'-MOE以外にもフッ素化体(2'-F)、メトキシ体(2'-OMe)などがあります。

架橋型は糖部の2'と4'を架橋することでゆらぎのある糖部の立体配座を固定化します。これにより以下が期待できます。

  1. 相補鎖との結合力の向上
  2. 立体障害によるヌクレアーゼ耐性

他にも糖部修飾そのものではありませんが糖部にモルフォリノ環を用いたモルフォリノ核酸が知られており、

  1. ヌクレアーゼで分解されない
  2. 毒性が低い

といった利点があります。

以上が、修飾核酸の概要でした。 こういった様々な非天然のユニットが活用されていることが、HELMにおけるモノマーの取り扱いの柔軟さとどのように結びつくか、気になるところです。

核酸医薬の分類

核酸医薬の構造的特徴をざっとみたので、最後に分類についても触れておきます。

文献2 SAR News No.38 の表2がわかり易いので引用させていただきます。

f:id:magattaca:20201109003503p:plain
SAR News No.38 核酸医薬 〜低分子、抗体に続く第3のモダリティ〜 表2より引用

この分類は「RNAを標的とするか、タンパク質を標的とするか」でとらえるとわかり易い、とのこと。

表2の左3つ(アンチセンス、siRNA、miRNA)がRNAを標的、右3つ(デコイ、アプタマー、CpGオリゴ)がタンパク質標的に相当します。

RNAを標的とする中でもアンチセンスは病因となるタンパク質を減少させたり、機能的なタンパク質を増加させたりと様々な作用機序があるそうです。

ちなみに薬物送達技術のところで取り上げた3剤はそれぞれ、① Macugen®︎(pegaptanib) アプタマー、② Givlaari®︎(givosiran) siRNA、③ Onpattro®︎(patisiran) siRNA となっていました。

分類は以上です。

以上、核酸医薬の基本的な事項について辿ってみました。

面白い話題が多くてどんどん脱線してしまいましたが、構造の複雑さと背景を知るのが表現方法を考える上で大事ということで。。。

HELM表現と他の表現の比較

では漸くですがHELM表記を試してみましょう。

文献2 SAR News No.38 の表1に記載されている中から化学修飾の異なる以下の3つを試してみたいと思います。

f:id:magattaca:20201109003719p:plain
SAR News No.38 核酸医薬 〜低分子、抗体に続く第3のモダリティ〜 表1より一部を抜粋して構成

Exsondys®︎ (eteplirsen)

まずはSarepta TherapeuticsのExsondys®︎ (eteplirsen)から。

Drugs@FDAで閲覧できるLabel(NDA 206488)記載の構造はこんな感じです。

f:id:magattaca:20201109003803p:plain
eteplirsen

えらいごっついですわ。。。

表現の比較対象としてIUPHAR/BPS Guide to Pharamacologyの2D表現を引用してみます。 Guide to Pharmacologyは専門家によりキュレーションされたリガンド-活性-標的関係についてのデータベースで、CC BY 4.0で利用可能です。

Guide to Pharamacology; eteplirsen核酸配列の2D表現はこんな感じ。

f:id:magattaca:20201109003845p:plain
Guide To Pharmacologyにおけるeteplirsenの2D表現

配列はわかりやすいですが、この表現ではモルフォリノ核酸であることやリン酸の修飾といった情報が表現できていないようです。

ではHELM editorをつかって構造を描いていきましょう。

まずはmonomerの確認してみます。モルフォリノ核酸糖部はあるようです。

f:id:magattaca:20201109004054p:plain

リン酸部位と5'末端の構造は無いようなのでMonomer Managerに登録しましょう。
前者はPolymer Type RNA、後者はCHEMとしました。

f:id:magattaca:20201109004126p:plain
モノマーライブラリーの拡張

まずは天然の核酸の場合のHELMを確認します。HELM Web-editorがお手軽です。
配列を「CTCCAACATCAAGGAAGATGGCATTTCTAG」をSequenceに入れてApplyするとグラフ表現とHELMが確認できます。

f:id:magattaca:20201109004216p:plain
HELM Web-editorで天然のアナログの場合を描画

糖部位はすべてモルフォリノ核酸なので[mph]で、リン酸部位は新しく作ったモノマー[DMP]で置き換えていきます。
複数文字の略記なので角括弧[]で囲むことに注意します。

Pythonreplaceで文字列置換してみます。RではなくR([mph](で置換しているのはRNAのRも置換されてしまうからです。

natural_analogue = 'RNA1{R(C)P.R(T)P.R(C)P.R(C)P.R(A)P.R(A)P.R(C)P.R(A)P.R(T)P.R(C)P.R(A)P.R(A)P.R(G)P.R(G)P.R(A)P.R(A)P.R(G)P.R(A)P.R(T)P.R(G)P.R(G)P.R(C)P.R(A)P.R(T)P.R(T)P.R(T)P.R(C)P.R(T)P.R(A)P.R(G)}$$$$'
mph_analogue = natural_analogue.replace('R(', '[mph](')
DMP_analogue = mph_analogue.replace(')P', ')[DMP]')
print(DMP_analogue)
# RNA1{[mph](C)[DMP].[mph](T)[DMP].[mph](C)[DMP].[mph](C)[DMP].[mph](A)[DMP].[mph](A)[DMP].[mph](C)[DMP].[mph](A)[DMP].[mph](T)[DMP].[mph](C)[DMP].[mph](A)[DMP].[mph](A)[DMP].[mph](G)[DMP].[mph](G)[DMP].[mph](A)[DMP].[mph](A)[DMP].[mph](G)[DMP].[mph](A)[DMP].[mph](T)[DMP].[mph](G)[DMP].[mph](G)[DMP].[mph](C)[DMP].[mph](A)[DMP].[mph](T)[DMP].[mph](T)[DMP].[mph](T)[DMP].[mph](C)[DMP].[mph](T)[DMP].[mph](A)[DMP].[mph](G)}$$$$

できました!お手軽!

HELM Editorで読み込んでみます。

f:id:magattaca:20201109004432p:plain
修飾核酸のHELM表現のグラフ化

グラフ表現でました!小さいので5'末端の拡大図も載せました。

ここに5'末端の修飾を足します。リン酸の追加とChemical Modifierから先に作成したモノマーを選んで貼り付け。

こんな感じになりました。

f:id:magattaca:20201109004536p:plain
5'末端の修飾の追加

先の「Guide to Pharmacology」のような2D表現と比較してどうでしょうか?

HELMのグラフ表現ではモノマーが拡張可能かつ塩基リン酸の3つに分かれており、非天然の構造修飾をもった核酸であることが明確に示されています。
また、モノマーライブラリを介してより具体的な構造式と結びついているため、このグラフ表現は実際の構造式の情報と紐づけることが可能です。
一方で、構造式そのものよりも単純化されているため塩基の配列といった情報を把握しやすいものともなっています。

ではこのグラフ表記のHELMはどのようになっているでしょうか?

作成したグラフ表現の他の表記はEditViewから確認できます。

f:id:magattaca:20201109004655p:plain
HELM editorでHELM表記を確認

HELM表記の変更点はSimple polymer listの最初とConnection listです。 「RNA1{[DMP]. ~~~~ |CHEM1{[EPR_5']}$RNA1,CHEM1,1:R1-1:R1$$$」という表現になっています。

SMILESやMolファイルといった表記も確認できます。線形表記同士、SMILESとHELMを並べてみましょう。

f:id:magattaca:20201109004742p:plain
HELM 対 SMILES

HELMはモノマーの略記(ID)が使えることで簡略化されています。

SMILESで途中でてくる「%xx (xは数字)」は2桁の番号を使って閉環位置を示すためのものだそうです。*13

・・・初めて見ました。

このSMILESが他のソフトでも認識できるものなのか?念のためRDKitで構造を起こしみます。

from rdkit import rdBase, Chem
from rdkit.Chem import Draw
from rdkit.Chem.Draw import IPythonConsole

# smi = SMILES文字列長いので省略

m = Chem.MolFromSmiles(smi)
m

f:id:magattaca:20201109005001p:plain
RDKitで構造式を描画

できました!わけがわからないがMolオブジェクトはできた!

Spinraza®︎ (nusinersen)

つづいてSpinraza®︎(nusinersen)です。Novaltis社のZolgensma®︎(Onasemnogene abeparvovec-xioi)との関係でも話題となりましたね。

構造は以下の通りです。

f:id:magattaca:20201109005050p:plain

特徴としてはリン酸がS化されたSオリゴであることと、糖が2'-MOEとなっていることです。

こちらはPubChemにHELM含めて色々な表現が載っていました!こんな感じ・・・

f:id:magattaca:20201109005113p:plain

他にもInChiやCanonical SMILES、Isomeric SMILESが載っていました。情報が載っているものと見当たらないものの違いは何なのでしょう??

HELM editorに入れる前にモノマーがあるかを確認しておきます。

f:id:magattaca:20201109005138p:plain

デフォルトで必要なモノマーが揃っていそうです。モノマーライブラリの追加が必要ないのでHELM Web-editorで描画してみます。

HELMをはりつけてApply!!

f:id:magattaca:20201109005211p:plain
nusinersenをHELM Web-editorで描画

HELMがPubChem等で提供されているとお手軽ですね!

HELM表記およびグラフ表現では修飾構造(5meC、sP、MOE)といった点がわかりやすいように思います。

Givlaari®︎(givosiran)

最後、Givlaari®︎(givosiran)です。

f:id:magattaca:20201109005325p:plain

先の2つよりも構造の特徴が多いようです。

  • リン酸部位にO体とS体の両方
  • 糖部位は2'-F体と2'-OMe体が使われている
  • 2本鎖
  • GalNAcコンジュゲート結合

まずはモノマーの確認です。2'-Fと2'-OMeはあるようです。

f:id:magattaca:20201109005347p:plain

コンジュゲートを用意しましょう。こんな感じで登録してみました。

f:id:magattaca:20201109005403p:plain

ある程度HELMの書き方がわかってきたのでStrandごとのSimple Polymerを書いてみます。

f:id:magattaca:20201109005427p:plain

HELM editorに描いていきます。StrandごとにHELMを読み込んでいきましょう。

f:id:magattaca:20201109005515p:plain

Sense StrandとAntisense Strandをどちらも読み込むと図のようになります。 どちらも左から右に向かって5'-3'の向きとなっています。

この状態で図の上にあるHybridizeボタンを押してやります。 するとAntisense Strandの左右がひっくり返り、2つのStrand間に水素結合が形成されます。

f:id:magattaca:20201109005553p:plain

拡大してみます。塩基の間のドットが水素結合を表しています。

f:id:magattaca:20201109005634p:plain

この状態でHELMは以下のような表現となっています。 水素結合がpairとして表されています。

f:id:magattaca:20201109005651p:plain

最後にsense鎖(ss)、antisens鎖(as)を明確にするためAttribute Listに属性を付け加えることもできます。こんな感じ、、、

f:id:magattaca:20201109005709p:plain

以上、givosiranのHELM表記とグラフ構造でした。
givosiranは添付文書の構造式の書き方がかなり分かりやすいのでHELMにしたことで可読性がよくなったか?というとちょっと微妙です。

ですが、モノマーライブラリと紐づいているので、略語の説明を個別にする必要がなく、糖、塩基の結合位置も構造式レベルで明確に指定されている、という点では HELMを使うことに利点があるのかもしれません。

またGalNAcコンジュゲートを一つのCHEMモノマーとして登録しましたが、リンカーと糖(GalNac)を別々に登録すれば、 異なる糖の組み合わせのコンジュゲートライブラリを表現し、それぞれの性質と結びつけることもできそうです。

まとめと感想

以上、今回は核酸のHELM表現を試してみました。

実際に使われている医薬品でHELM表現を試すことでいくつかメリットを感じられたように思います。

  • 異なるタイプの核酸医薬に対して同じモノマーライブラリに基づいた共通の表現ができる
  • 実際の構造式に紐づいており、修飾構造を明確に表現できる
  • IDで表記するのでユニットの文字列置換で簡単に記述を変更できる

と、いったところでしょうか?

それぞれ単独の構造のみで記載したのであまり"旨み"がなかった感もありますが、 これらの裏側にあるであろう大量の核酸医薬候補ライブラリーを表現、管理、データベース化する、 となった場合に中々使い勝手の良いものとなるのではないでしょうか???

一方で、使いにくさを感じる点としては、コンジュゲートのような化学修飾ユニットをCHEMモノマーとしてそれぞれ登録する必要があることです。
化学修飾はSMILESで書いてハイブリッドな表現ができたらもっと便利な気もしますが、やはり難しいのでしょう。

あとPuChemやChEMBL、思ったより欲しいHELM表記あまり載ってなかったです・・・。 もう少し核酸医薬分野のデータベースも手厚くして欲しい気もします・・・が、ひょっとしたらHELMの標準ライブラリ、IDに修飾核酸をどこまで含めるか?みたいな問題があるのかもしれません。

毎度のごとく知識不足すぎて基礎事項を調べていたら本題のHELM表記に中々たどり着けませんでした。。。

まあ色々面白かったのでいいや。

以上!

今回も色々と間違いが多そうです。ご指摘いただければ幸いです。

*1:久保田恒平博士 博士論文「siRNA 担持脂質ナノ製剤の評価 に関する研究」記載より CiNii

*2:下表は文献2 表1より抜粋・改変して作成

*3:Pharmaceuticals 2020, 13(3), 40 CC BY 4.0の元に図を引用

*4:Toxicologic Phatology 2018, 46, 735 CC BY 4.0の元に図を引用

*5:Mol. Ther. 2010(18)1357

*6:非カチオン性リポソームによる核酸医薬送達法の可能性

*7:菊池 寛 Drug Delivery System 2019(34)106 企業的観点からみた核酸・遺伝子医薬品開発の現状と今後の展望:DDSとの関わり

*8:Semple, S. et. al., Rational design of cationic lipids for siRNA delivery. Nat. Biotechnol. 28, 172–176 (2010).

*9:Jayaraman M. et. al., Maximizing the potency of siRNA lipid nanoparticles for hepatic gene silencing in vivo. Angew. Chem. Int. Ed. Engl. 2012;51:8529–8533.

*10:こちらのレビューの図も良いです Mol Ther. 2017(25)1467

*11:Nat. Biotecnol. 2017(35)845

*12:文献は会社HPの技術紹介から読めます。CBS還元剤みたいな不斉補助基なので結構お安く作れてしまうんでしょうか?

*13:Daylight社 SMILESより

HELM editorでお絵描き

前回の記事でマクロ分子の表現方法HELMの表記ルールについて調べてみました。
今回は実際の利用にあたって便利そうなツール、特にHELMエディタの入手方法と簡単な使い方について調べてみたいと思います。

HELMのデータベース・ツール

Pistoia AllianceのHPによるとHELMはマクロ分子の表現として標準的な手法となることを目指しているそうです。 新しい表記の普及にはデータベースの整備お手軽な読み書きのツールが大事そうです。

データベースが準備されていれば、実際の分子がその表現でどのように表せるか実例を参照したり、他の表現方法との比較が簡単にできます。 また、ツールを使って自分で表記を書いてみたり変換したりできれば、ちょっと使ってみようかなってなりますよね!

具体例としてHELM Wiki (HELM Resources)には 以下が記載されていました。ありがたいことにツールの開発・公開も行なってくださっているそうです。

  1. オンラインデータベース:HELM in Online Databases
    • PubMed:PubChemの「biologic description」セクションにHELM表記の記載
    • EBI ChEMBL:「BIOTHERAPEUTICS」テーブルや「Compound Report Card」に記載
  2. ツール:

HELM Toolkitはこんな感じの構成。MIT licenseライセンスの下でオープンソースとなっています。 *1

f:id:magattaca:20201101011514p:plain
HELM Toolkit *2

前回の記事でRDKitでもHELMの取り扱いが可能であることを確認しましたが、現在RDKitで扱える範囲は以下のような天然のモノマー+αに限定されているようです。(RDKit-discussの議論より)

  • FASTA配列から読み書きできるタンパク質、核酸配列
  • PDBの残基コードで利用可能なモノマー
  • 頻繁に使われる非天然アミノ酸(D体 etc.)、ジスルフィド結合など

HELMの表現力を活かすには新しい非天然のモノマーもどんどん取り込んでいきたいところです。 上記RDKit-disucsではより細かな内容を扱うにはPiasota Allianceが提供しているJavaツールキットを利用する方が良いとオススメされていました。

ほな公式のHELM Toolkitで遊ばしてもらいましょ!

HELM editor入手方法

ざっと見た感じeditorには3種類のアクセス方法がありそうです。一つずつ試してみましょう!

HELM editor (ローカル環境)

まずはHELM editorに記載のローカル環境にインストールする方法。

GitHubページのリンク先に「HELM Editor v1.4.1」のバイナリファイル(zip)があるので ダウンロードしてきて解凍するだけです。

f:id:magattaca:20201101011854p:plain
HELM Editorの入手方法

「HELMEditor-1.4.1.jar」というファイルをひらけばJAVAプログラムが起動します。

f:id:magattaca:20201101011944p:plain
デスクトップ版アプリ HELM Editor

HELM Web-editor (トライアルバージョン)

ついで、WebベースのHELM Web-ediorです。HELM Wikiのページはこちら

トライアルバージョン(v1.1.4)が用意されているので下のリンク先に飛べばすぐに試すことができます。

http://webeditor.openhelm.org/hwe/examples/App.htm

先のローカルに落としたEditorとWeb-editorはちょっと見た目が違う感じです。

f:id:magattaca:20201101012048p:plain
Web版の方がシュッとしてる(個人の感想です)

HELM Web-editor (インストールバージョン)

Web-editorをインストールして利用することも可能です。GitHubにコードが公開されており、 ReadMeにインストール方法が書かれています。

HELM Web-editorはJavascriptで書かれているそうです。で、JavascriptのWebアプリを使うには、Webコンテナとかいうアプリケーションサーバを用意してWebサーバで動かすことになるらしい。。。どういうこっちゃ?

Tomcatを使って、ということなのでダウンロードしてみます。*3

Java SE Development Kit (JDK)のインストール

OracleのサイトからmacOS用のJDK-15.0.1というのをダウンロードしてインストールしました。 Personal useはOKですと。。。アグリーアグリー

Apache Tomcatのインストール

ついでApache TomcatのページからTomcat 9.0.39というのをダウンロードしてきました。 Tomcat 10.0もあるようでしたがalpha版のようだったので9.0にしました。

インストール後、実行権限を確認する必要があるそうです。

ターミナルでディレクトリを移動してls -lとしたところ、binは「drxr-xr-x」となっていました。(755であってます?)

一方、binの中のファイル群は「-rw-r--r--」(これは644?)となっていたのでシェルスクリプトの権限を書き換えました。 ターミナルに「chmod 755 *.sh」とコピペします。

実行権限も設定できたので、後はbinの中にあるstartup.shというスクリプトを実行すれば良いそうです。

ターミナルで./startup.shとすると「Tomcat started」と無事出てきました。 あとはlocalhostのポート番号8080にアクセスすれば良いらしい...

http://localhost:8080/」をChromeに貼り付けてエンター!

f:id:magattaca:20201101012549p:plain
Tomcat見参!!

できた!劇団四季のライオンキングみたい!この微妙な可愛くなさがいい!

シャットダウンは「./shutdown.sh」だそうです。忘れぬうちにメモしときます。

HELM Web-editorのインストール

Tomcatの準備ができたのでHELM Web-editorを順番に準備して行きます。必要なファイルは3つ!

まず、「①HELM2MonomerService (HELM2MonomerService.war)」 と 「② HELM2WebService (WebService.war)」を手に入れます。

GitHubからのリンク先からはダウンロードファイルがうまく見つからなかったので、 HELM Wikiに記載の Nexus repository managerというところから それっぽいファイルを取ってきました。コンパイル済みのJAVAファイルを置いてくださっているそうです。

f:id:magattaca:20201101012717p:plain
ダウンロードしたファイル

warファイルというのはJAVAベースのwebアプリが圧縮された形式らしいです。

ファイル名が長いのでGitHubの手順と同じ名前に変更した後、2つのwarファイルを「apache-tomcat-9.0.39ディレクトリ配下の「webappsディレクトリに入れました。

デプロイ!!・・・で、あってます?

で、すぐにwarと同じ名前のディレクトリが勝手に作られます。こんな感じになりました。。。

f:id:magattaca:20201101012911p:plain
Tomcat webappsディレクトリ内に格納

最後に「③HELMWebEditor (hwe-1.1.0.zip)」を手に入れます。こちらはGitHubのリンクからそのままダウンロードできました。

unzipしてできた「hweディレクトリを先に作った「\webapps\HELM2MonomerService\」の中に移動します。

ファイルの準備はこれでおしまい。

④ 起動

Apatche Tomcatのサーバーを起動した後、URL「http://SERVER/HELM2MonomerService/hwe/」にブラウザからアクセスすれば Web Editorが起動するとのことです。

SERVERのところをlocalhost:8080として「http://localhost:8080/HELM2MonomerService/hwe/」にアクセス!!

f:id:magattaca:20201101013034p:plain
HTTP 404

見つかりません!何故!

右往左往しているとhweディレクトリの中のexapmleAPP.htm.というファイルがありました。 中身を見てみるとJSDrawディレクトリのjavascriptを読みに行っている感じです。

f:id:magattaca:20201101013103p:plain
アプリっぽいファイル

なんだかアプリっぽい。。。

URLを「http://localhost:8080/HELM2MonomerService/hwe/examples/App.htm」に変更してアクセス!

f:id:magattaca:20201101013136p:plain
立ち上がった!

デモ版と同じ画面が立ち上がりました!あってた!嬉しい!

HELM Web editorの使い方

インストール完了したので使ってみましょう!

HELMEditorよりもHELM Web-editorの方が画面がスッキリしているので、Web-editorで遊んでみたいと思います。

といっても使い方は簡単!モノマーのブロックを繋いでお絵描きしていくだけです。

画面の説明

まずは全体の画面。3分割されていて以下のようになっています。

f:id:magattaca:20201101013205p:plain
画面構成

2次元構造は②Canvasに表示されます。①monomer browserでモノマーを選んで投げ込んでいけます。 ③Viewing areaはテキストベースの情報を見る箇所で、②と③の間で、グラフ構造とHELMを相互に変換する することも可能です。

monomer browser

monomer browserはSimple Polymer Type毎のタブに分かれています。 モノマーが略語で表されていますが、カーソルをあわせるだけで構造が表示されます。

f:id:magattaca:20201101013231p:plain
monomer browserのPeptideタブ*4

RNAタブはこんな感じ。尚、Simple Polymer TypeのRNAヌクレオチドポリマー全てを含むのでDNAも含みます。

f:id:magattaca:20201101013306p:plain
RNAタブ*5

ヌクレオチドR(A)PのAが「丸括弧( )」で囲まれているのは塩基を分岐として扱うことを反映しています。

構造の定まっていない曖昧なモノマーのための表現や、一発変換のRulesといったものも用意されてます。

f:id:magattaca:20201101013404p:plain
ambiguous monomerとRules*6

デフォルトで用意されているルールはRNAポリマーのAをU、G、Tに変換するもののようです。 センス鎖-アンチセンス鎖を一発変換できれば便利そうと思いましたが、5'-3'配列順序も反転させないといけないので難しいのかもしれませんね。

Canvas

Canvasに用意されているボタンはアイコンを見ると使い方がだいたいイメージできるようになっています。

f:id:magattaca:20201101013516p:plain
Canvasのアイコン

見慣れないのはBLOBですが、これは未知の構造/配列からなるSimple Polymerとして利用できます。

試しにお絵描きして見ます。始まりはいつも開始コドン!!!

f:id:magattaca:20201101013554p:plain
開始コドンをお絵描き

できました!

モノマー間をSingleアイコンでつないでいますが、 singleを選択しなくても2つのブロックの中の文字をドラッグしながらつなぐだけで結合が作られます。

ついでにDNAのセンス鎖に変えてみます。

f:id:magattaca:20201101013638p:plain
お絵描きの編集

簡単!

Viewing area

Viewing areaには①Sequence、②HELM、③Properties、④Structure Viewの4つのタブがあります。

先にお絵描きした状態で表示される情報はこんな感じ。。。

f:id:magattaca:20201101013716p:plain
Viewing area

一部重なってしまっていますが④Structure Viewで配列を構造に変換、確認できるのはちょっと感動です。

Propertiesでは分子量、組成式に加えてExtinction Coefficient(モル吸光係数?)も表示されています。

以上はCanvasに描いたグラフ構造の情報の確認ですが、反対にViewing areaに書いた配列をCanvasに反映させることも可能です。

終止コドンを加えてみます。開始即終了!!

f:id:magattaca:20201101013830p:plain
HELMからグラフへ

できました!

ValidateでHELMが正しいかどうか確認できるのは手厚いですね!書き方のテストにも良さそうです。

簡単な描画画面の説明は以上です。

Monomer Library

HELM Web editorで利用可能なmonomer browserのMonomerRulesといったデータの元を参照することも可能です。このデータを編集して表現を拡張することが意図されているようです。

グラフ描画の上のほうにカーソルをあわせると、下図のようなバナーが表示されます。

f:id:magattaca:20201101014150p:plain

ここで画面を切り替えてMonomer LibraryRulesetの確認、編集、追加といったことが可能になります。

Monomer Library画面へと切り替えてみましょう!図のようにデフォルトで入っているMonomer Listが表示されます。

f:id:magattaca:20201101014222p:plain
デフォルトのMonomer List

SymbolNameをつかってライブラリを検索できます。

登録されているチロシン(Y)の関連構造をみてみるために「Symbol: Y」で検索してみました。

f:id:magattaca:20201101014258p:plain
デフォルトのチロシン関連構造

天然のチロシン以外にD体やN-メチル体、ニトロチロシンが登録されています。 鉛筆マークをクリックするとmonomer情報を編集することができ、プラスマークでは新規monomerを追加できるようになっています。

・・・が、どうもうまくいかないようです。編集、追加ともにエラーが出てしまいました。

f:id:magattaca:20201101014512p:plain
エラーでmonomerの追加ができない

GitHubのissue #220 に同じ状況が報告されており、まだ解決していないようでした。

残念。。。*7

HELM editorの使い方

HELM Web editorではmonomerの追加がうまくいかなかったので、Web版ではないHELM Editorも試して見ることとしました。

画面構成と使い方

基本的な使い方は同じですがアイコンの見た目や配置が異なる箇所があります。
ざっと画面をみていきます。

f:id:magattaca:20201101014650p:plain
HELM editor

  • ① Web版のMonomer browserに相当
  • ② Web版のCanvasに相当
  • ③ Web版のViewing areaに相当。ただしApplyAppendといった機能はない
  • ④ 線形表記をここに書いてLoadするとグラフ表現にできる。Web版のApplyに相当。

Web版のViewing areaで便利だったSequenceからHELMへの変換はToolsConvert Notation機能で実行できます。

f:id:magattaca:20201101015048p:plain
Convert NotationでHELMに変換

またグラフ表現上でクリックすることで構造の情報確認が可能です。

f:id:magattaca:20201101015129p:plain
構造式が確認できる

さらに面白い機能として、モノマーを編集して構造修飾を加えることができます!

f:id:magattaca:20201101015205p:plain
モノマー構造を直接編集

上の図では塩基のウラシルを5-フルオロウラシルに編集しています。
編集してSaveすると、グラフの表記が5fUに変化し、 Sequence viewのUもイタリック(modified)に変わっています。

これは便利ですね!・・・配列に突如組み込まれるテガフール!

新しいモノマーの追加

さて、気になる新しいモノマーの追加です。デスクトップ版ではうまくライブラリを拡張できるでしょうか??

Web版のMonomer Libraryに相当するのはMonomer Managerという機能です。
ここでライブラリにない新しいモノマーの情報を入れてregisterとすることでライブラリに追加できます。

f:id:magattaca:20201101015430p:plain
モノマーの追加

上の図では3-Fluoro-L-tyrosineを「Monomer ID FlY」として追加登録しました。
登録後、Monomer browserのOtherから新しいモノマーFlYが選べるようになっていることを確認できました!*8

Web版でうまくいかなかったモノマーの追加がうまくいったようです!!

これでオリジナル分子を自由にかけますね!

まとめ

以上、今回はHELMの利用をめざしてツールの導入と簡単な使い方を調べてみました。 ツールがあれば自分でHELMを書いたり、グラフ表現との変換が容易にできるのでいろいろと遊ぶことができそうです。

HELMエディタとしてデスクトップ版のHELM EditorとHELM Web editorの両方を試してみました。

Web editorはデスクトップ版よりも画面がスッキリしていて、よりシュッとした(?)インターフェースといった印象でした。 CanvasやViewing areaの使い勝手が良い一方で、Monomer Libraryの追加機能に不具合があるという問題点がありました。

デスクトップ版 HELM Editorは見た目がちょっと旧い感じはありますが、新しいモノマーが追加可能、構造の編集が容易という点がWeb版よりも優れている印象です。

特殊ペプチドや核酸アナログといった構造修飾、化学変換を組み入れていくには現在のところデスクトップ版を使う方が良いかもしれません。

マニュアルの図を貼り付けたりしていたらまた長い記事になってしまいました。

「途中のWeb版の長々としたインストールの説明必要だったのか?」というツッコミをいただきそうですが、 Tomcatのライオンキングみたいなロゴが気に入って使いたかっただけです。・・・すみません。

これでHELMの書き方は心配ないさ~~

適当に調べたことを書いているので誤り等ご指摘いただければ幸いです。

*1:但し、HELM toolkitが利用しているMarvinBeansはChemAxonのもので、HELMのためにロイヤリティフリーで提供されていますが、他の目的の利用についてはライセンスが必要となるそうです。

*2:https://pistoiaalliance.atlassian.net/wiki/spaces/PUB/pages/13795362/HELM+Notation

*3:インストールはこちらのページを参考にさせていただきました。

*4:User Guide for the HELM Web Editor V1.1.0より

*5:User Guide for the HELM Web Editor V1.1.0より

*6:User Guide for the HELM Web Editor V1.1.0より

*7:MonomerLib2.0.dbというそれっぽいファイルがあったのでパーミッションを変えて書き込みできるようにしてもダメでした、、、

*8:登録したモノマーの削除方法がわからないので試しに登録したFYも残っています。。。

マクロ分子の線形表記 HELMについて調べた話

先日@iwatobipen先生のブログ記事「Create macrocyclic mol object from sequence」を読み、RDKitでペプチドが取り扱えることに感動しました!*1

配列をそのまま原子レベルのオブジェクトに変換できるってすごい!

で、「もうちょっとこの辺りの話知りたいなー」となったので、「そもそも生物っぽい分子の表現ってどうなんですかね?」ということで調べてみることにしました。

とりあげるのはマクロ分子の表現方法、HELM

こちらのレビュー(J. Cheminform. 2020(12)56)の中で取り上げられていました。*2

歴史やら表記のルールやら、だらだら書いていきますよ!

HELM?

HELMHierarchical Editing Language for macromolelucesの略です。 雑にまとめると、「マクロ分子を原子レベルかつ簡潔に表現できる線形表記」といった感じで、 複雑な生物学的分子を単一の表記で記載することができます。

ペプチドやタンパク質、オリゴヌクレオチドといった生物学的な分子の線形表記というと、まずは配列アミノ酸や塩基といった(限られた)ユニットを表す文字の組み合わせが思い浮かびます。

対してHELEMはSMILESをベースとしており、配列だけではなく細かな化学構造も表すことができるため、 構造修飾や特殊なユニットといった、より豊かな表現が可能です。

つまり抗体+低分子のADCや修飾核酸医薬といった複合的な構造もきっちりと表現できます。

また、その表現力により表記とマクロ分子の構造とを1対1で対応させることができるので、 データベースへの格納といった厳密さが必要となる場面でも利用できます。

まさにNew Modality時代に必須の表現!!デファクトスタンダードとなるポテンシャルを持つ表現なのだ!!

・・・知らんけど。

f:id:magattaca:20201024200156p:plain
HELMとその表現範囲*3

歴史

元を辿ると2008年Pfizer社内でアルゴリズムの開発が始まったHELMですが、 2010年前後からPistoia Allianceという非営利のコンソーシアムの支援を受けてさらに開発が進みました。*4

2012年にオープンなものとしてリリースされ無料で利用できるようになりました。 同年、Pfizerより論文も発表されています。*5

HELM: A Hierarchical Notation Language for Complex Biomolecule Structure Representation
Zhang, T. et. al., J. Chem. Inf. Model. 2012, 52, 10, 2796–2806

2014年にはChEMBLがHELMの採用を公表し、2015年にはChemAxonがHELM toolkitのMarvinBeans 5.0ライセンスを無料化、 また、RDKitでもHELMが利用できるようになったりと、データベースツールともにHELMへのアクセスが広がり、 順調にデファクトスタンダードとしての地位を築きつつあります。*6

Pistoia Alliance

f:id:magattaca:20201024200439p:plain
Pistoia Alliance ロゴ*7

Pistoia Allianceはグローバル製薬企業(AstraZeneca、GSK、Novartis、Pfizer)の代表によって2007年構想、2009年設立された組織で、 2020年現在、100を超える企業・団体がメンバーとなっています。日本からは武田薬品が参加しているみたい。*8

組織の目的はR&Dイノベーションを妨げる共通の課題を協力して解決し、効率をあげることです。 具体的にはデータの収集、アクセス、共有方法といった、R&Dに必須でありながら、各社それぞればらばらに取り組んでいた課題があげられます。

規制当局と協力して新しい標準化を取り入れたり、法的な枠組みを提供することで、各社が競争する前の「場」をまずは整備しましょう、ということみたいです。

ちなみにPistoiaは会合が開かれたイタリアの都市の名前だそうです。ミニマルなデザインのロゴにトスカーナの風を感じますね!・・・知らんけど。

脱線しますが、個人的にとても良いな、と思ったのはPistoia Alliance Chemical Safety Libraryという取り組みです。

実際のラボ実験の経験にもとづき、危険な化学実験のリスクについて情報共有を行おうとするもので、CASと協力してオープンアクセスのプラットフォームChemical Safety Library の公開に至っています。*9

f:id:magattaca:20201024201133p:plain
化学実験安全性の向上に向けた取り組み

企業間の垣根を超えてノウハウを共有し、安全性の向上をめざしていこうというのはすごく良いですよね。推せるぞ!Pistoia!

HELM表記の構造と表現方法

背景がわかったところで具体的なHELMの中身について見ていきましょう。 Pistoia Allianceホームページの図表が非常に分かりやすいので、先のPfizerの論文を参照しつつ眺めていきます。

以下、特段の記載の限り図表はこちらのURL を引用させていただいています。

HELMの階層構造

Hierarchical Editing Language for macromolelucesという名前が示す通り、HELMは階層構造を持った表現です。

① Complex polymer、② Simple polymer、③ Monomer、④ Atomの4階層で構成されています。

階層構造であることにより、文脈に応じて異なるレベルで構造の解析と描画を行うことができます。 また、高次の階層は低次の階層の表現をもちいて表すことができます。

Complex polymer

では、まず、一番高次のComplex Polymerから。この階層はマクロ分子全体の化学構造の情報を表現します。

下図の通り、構成要素であるsimple polymerとそれらをつなぐ接続(connection)によって表すことができます。

f:id:magattaca:20201024201652p:plain
Complex polymer 階層

Simple polymer

Simple polymerは同じpolymerタイプのmonomerから構成されています。

複雑さを避けるため単一の直鎖(single linear chain)として定義されています。 従って分岐(branching)や環状(cyclization)といった構造はこの階層では扱いません。

また、特定のpolymerタイプにはmonomer間の接続(connection)のルールが明示的に定義されており、 接続の位置とルールによってmonomer配列の方向性が表せるようになっています (ex. ペプチド:N末端→C末端)。

f:id:magattaca:20201024201724p:plain
Simple Polymer階層

Monomer

Monomerは原子(atom)と結合(bond)から構成されており、MolfileやSMILESといったフォーマットで表すことができます。 ペプチドにおけるアミノ酸の表記(ex. A, G)と同様に、各monomerには単一のID(unique ID)が与えられており、 IDを使ってsimple polymerを表すことができます。

また、monomerの定義の中には接続の位置(attachment point)も含まれています。

monomerはsimple polymerのビルディングブロックとしても、複数のpolymer間をつなぐ接続要素としても用いることができます。

f:id:magattaca:20201024201807p:plain
monomer階層

Atom

AtomAtomです。。。

f:id:magattaca:20201024201853p:plain
Atom階層

以上がHELMの階層構造でした。

各階層のプロパティと表記のルール

続いて、各階層のより具体的な表記方法、特徴を見ていきます。最終的にこんな感じの表記が理解できるようになりたい!

f:id:magattaca:20201024201928p:plain
HELM Notation

Monomer definition

HELMの表現の簡潔さはMonomerを単一のIDで表せることによるところが大きいと思われます。

従って、各Monomerがしっかりと定義されていることが重要となります。例えばChEMBLではHELM表現と一緒にMonomerの辞書(monomer library)も提供されていたりします。

ではそのMonomerがどのようなプロパティをもっているのか?先の図を拡大して見てみましょう。

f:id:magattaca:20201024221125p:plain
monomerの7つのプロパティ

プロパティの① ~ ③はこんな感じ。Attachment pointがちょっと細かい。

f:id:magattaca:20201024221019p:plain
プロパティの説明 (1/2)

後半④ ~ ⑦はこんな感じ。

f:id:magattaca:20201024220758p:plain
プロパティの説明 (2/2)

文字ばっかりの説明になってしまいました。
イメージを掴むために論文からFig.2を引用させていただきましょう。 ペプチド鎖のHELM表記の中で、monomerはこんな感じででてきます。

f:id:magattaca:20201024212712p:plain
ペプチド鎖におけるmonomerの表記

Attachment pointにおけるCapping groupや、 非天然のアミノ酸とNatural analogの表記の比較がイメージしやすいですね。

Simple Polymer の記載の仕方

Simple polymerの表記はmonomerの定義に基づいています。

特にプロパティの⑥ monomer typeと ③ attachment point が大事で、タイプによってR1、R2、R3の意味合いが変わってきます。

f:id:magattaca:20201024212917p:plain
monomer typeとattachment point

backboneであればR1R2は別のbackbone monomerと接続して主鎖が伸びる場所で、 branchingであればR1はbackboneのR3のと接続する場所となります。

先のアラニンのmonomer定義でプロパティのSMILES表記は以下のようになっていました。伸張の方向性(N末からC末)からattachment pointがR1、R2となっているのが分かりやすいですね。

f:id:magattaca:20201024213003p:plain
例:アラニ

で、具体的な線形表記のルールですが、SMILESと非常に類似しています。こんな感じ、、、

f:id:magattaca:20201024221704p:plain
HELM 線形表記のルール

適当に比較例をつくってみました。分岐や特殊なユニットの表し方といった文法が似てますね!

f:id:magattaca:20201024213227p:plain
HELMとSMILESの比較

Simple Polymer Type の分類

ざっくりこんなタイプにわかれます。

f:id:magattaca:20201024213256p:plain
Simple Polymer Typeの分類と特徴

RNA TYPEのmonomerを3つの部分(sugar、base、linker)に分けて定義しているのは、 まとめて定義すると組み合わせごとに別の定義が必要になり、膨大な数になってしまうからだそうです。

またNonespecificなCHEM TYPEでは、モノマー間の接続が定義されていないので、 モノマー1つずつを別々のsimple CHEM polymerとして扱います。

従ってCHEMでは複数モノマーの表現がcomplex polymer notationの範疇で取り扱われる事になります。

Complex Polymer Notation Specification

複数のsimple polymerの組み合わせからなるcomplex polymerには、 Conjugated Polymers (ex. protein-drug conjugate)、 Cross-linked polymers (ex. antisense oligonucleoide dimers)、 Polymer mixtures (ex. siRNA) といったものがあります。

表記の特徴はこんな感じ・・・

f:id:magattaca:20201024213547p:plain
Complex polymer 表記の特徴

各セクションは以下のようになっています。

f:id:magattaca:20201024213630p:plain
Complex polymer 各セクションのルール

また、simple polymerは一本鎖なので、環状構造(Cycles)や分岐鎖(Branches)はsimple polymer間を接続する事で表現されます。

環状構造の具体例として、ペプチドホルモンオキシトシンのPubChem上の表記を見てみましょう。 2つのシステイン残基がジスルフィド結合で繋がれています。

f:id:magattaca:20201024213913p:plain
PubChem 項目 「Oxytocin」の表記より*10

以上でHELMの各階層の表記方法の説明はおしまいです。

HELMの表記例

表記方法が大体わかったので例をもう少し見て見ましょう。

以下はいずれもPistoia Alliance HPに記載の例です。Complex polymerのグラフ表現HELM表記とが並んでいます。

グラフは見慣れない図ですが、monomerをベースにした表現で、HELM web editor を使って同様の図を作成できます。*11

まずは直鎖のオリゴヌクレオチド…。塩基も糖もリン酸も修飾が入ったゴリゴリした例です。

f:id:magattaca:20201024214609p:plain
Linear oligonucleotides

続いて環状ペプチド。HELM表記は先にみたオキシトシンと同様に解釈できます。 monomerを1文字表記したグラフ表現はPubChemで見た構造式と比べてより簡潔な表現になっているように見えます。

f:id:magattaca:20201024214902p:plain
Cyclic peptide

・・・赤色背景に黒字はColor Blind Friendlyじゃ無いので読むのがつらいです。。。カラーユニバーサルデザインでお願いします。。。

つぎはsiRNA、塩基対で水素結合を形成し2本鎖となっています。Hydrogen bond list、Attribute listの参考例としてどうぞー

f:id:magattaca:20201024215014p:plain
siRNA

最後はオリゴヌクレオチドとペプチドのコンジュゲートです。
異なるPolymer typeの組み合わせの例。Non-specific polymerのCHEMも使われています。

f:id:magattaca:20201024215056p:plain
Oligonucleotide peptide conjugate

以上、具体例でした。

HELMのバージョン

ここまでHELMの階層構造と表記方法について見てきましたが、HELMのバージョンについても触れておきます。

現在2つのバージョンがあり、新しいHELM2ではHELM1よりもさらに表現の幅が広がっています。*12

HELM1では自由にmonomerの定義を加えていく事で非天然のモノマーを含めていくことができました。 HELM2ではさらに定義可能な範囲が広がり、混合物のような曖昧さのある構造も表現可能となっています。

f:id:magattaca:20201024222107p:plain
HELM2

ChEMBLとRDKitにおけるHELM

オープンソース化されたマクロ分子の表記HELM。オープンなものとしてやっぱりChEMBLとRDKitは外せないですよね!

ChEMBLでは2015年リリースのChEMBL 20からHELMを含めるようになったようです。*13 ちなみに2020年10月現在のバージョンはChEMBL 27です。

PubChemでも検索してみたオキシトシンを調べてみましょう。

疲れた心と体に幸せホルモンを!!*14

ID CHEMBL395429でヒットしました。 Compound Report Cardをスクロールしていくと「HELM Notation」という項目があります。

f:id:magattaca:20201024222415p:plain
ChEMBL 27バージョン 「CHEMBL395429」*15

PubChemと比較すると、わずかに異なるHELM表記となっていました。ChEMBLではconnection listのSourceTargetが反対となっています(「6:R3-1:R3」)。
分子内ジスルフィド結合なのでどちらでも良いですが、個人的にはPubChemの数字が小さい方を先にする書き方の方が好きです。

また、monomerの定義はXML形式でダウンロードすることもできます。サイズ 3.9MBもある。。。

続いてRDKit!

現在の所、ペプチドだけサポートされているみたいです。まずはHELMからMolオブジェクトを作ってみましょう!

ライブラリをインポート・・・

from rdkit import rdBase, Chem
from rdkit.Chem import Draw, rdDepictor
from rdkit.Chem.Draw import IPythonConsole
print('rdkit version: ', rdBase.rdkitVersion)
# rdkit version:  2020.03.2

SMILESからMolオブジェクトをつくるときと同じノリでMolFromHELM( )とすればOKです!

Oxytocin_mol = Chem.MolFromHELM('PEPTIDE1{C.Y.I.Q.N.C.P.L.G.[am]}$PEPTIDE1,PEPTIDE1,1:R3-6:R3$$$')
Oxytocin_mol

f:id:magattaca:20201024223205p:plain

Molオブジェクトが無事生成されました! でももっと可愛く! *16

rdDepictor.SetPreferCoordGen(True)
Oxytocin_mol

f:id:magattaca:20201024223533p:plain

CoordGen良い!! 幸せホルモン分泌された!

逆にMolオブジェクトからHELM表記を生成してみます。こっちもいつものノリでMolToHELM( )とすればOKです!

Oxytocin_helm = Chem.MolToHELM(Oxytocin_mol)
print("Generated HELM Notation: ", Oxytocin_helm)

Generated HELM Notation: PEPTIDE1{C.Y.I.Q.N.C.P.L.G.[am]}$PEPTIDE1,PEPTIDE1,1:R3-6:R3$$$」と出力されました。

バッチリっすね! もうMolToHELMキャンペーンしたいくらい!

まとめ

以上、マクロ分子の線形表記 HELMついてでした。相変わらず大事なポイントを絞れないので無駄に長くなってしまいました。。。 まぁ、なんとなく表記の読み方もわかるようになったのでいいや。

さてHELMですが、原子数がべらぼうに多い巨大な分子でも簡潔に線形表記できてしまうところが素敵と思いました。

J.Cheminformのレビューでは、HELMのような表現は生物と化学の融合地点としてのBiocheminformatics的表現といったことが書かれていました(雰囲気意訳)。
冒頭にも書きましたが、化学修飾された生物学的分子を表現できることで、技術発展が著しいモダリティ分野をインフォマティクスの観点からもっと取り扱えるようになりそうです。

っていうか、もうできてるのか!知らなかったの私だけだったのか!!

無知を晒しついでの感想ですが、私はケモインフォを齧り始めて、「コンピューターに分子を認識させるのってこんなに難しいことだったのか!」とびっくりしました。

正直SMILESやら今回のHELMやら「なぜそれで一意に構造に対応させられるか?」といったことや、「どうやってこのルールに絞り込んだのか?」みたいなことはさっぱり分かりません。
ですが賢い人々が考えた表記方法を調べてみると新しい言葉を習う感じの面白さがあります。

ロゴスはロジックだから!・・・知らんけど!

適当に調べたことを書いているので色々と間違いがあると思います。ご指摘いただけると幸いです。

オープンソースで逆合成解析 ~AiZynthFinder~ part 3. CLI

オープンソース自動逆合成解析ツール、AiZinthFinder。インターフェースとしてGUIコマンドラインの2種類が用意されています。

Command Line Interface (CLI)の利点はバッチ処理ができることです。ポチッとやって多数の分子を処理できたら楽そうですね!

ツールは以下のGitHubに、

github.com

ドキュメントはこちらにあります。

molecularai.github.io

課題設定

逆合成解析のバッチ処理の利用として、AI-drivenな創薬のDMTA探索サイクルが想定されているのだと思います。(生成モデルでデザインされた化合物をそのまま逆合成解析、合成ロボットに流す、みたいな?) 

ですが、私はどうして良いのかわからないので、もう少し簡単な課題を設定したいと思います。

つまるところ、効率よく多種類の化合物を手に入れたいという課題です。そのためにはちょうど良い共通中間体を設定し、できるだけ少ない反応の数で異なる目的物が得られるようにすればOKです。

もう少し遡ると、化合物群に共通して必要となる試薬を確保する必要がある、ってなことになりそうです。

と、いうわけで、今回の目標は、「論文記載の化合物群をAiZynthFInderのCLIでまとめて逆合成解析し、それらの合成に必要な共通の試薬をみつけよう!」です。

データの準備

AiZynthiFinderのCLIで解析を行うには「SMILESが1行1化合物分格納されたテキストファイル」必要になります。早速準備していきましょう。

対象のデータとしては、py4chemoinformatics 第8章で用意してくださっているOrexin Receptorアンタゴニストを利用させていただきたいと思います。

Table 1から下記のMerckの文献3つを選び、ChEMBLから化合物をSDFでダウンロードしてきました。

Doc ID Journal
CHEMBL3098111 Bioorg. Med. Chem. Lett. (2013) 23:6620-6624
CHEMBL3867477 Bioorg Med Chem Lett (2016) 26:5809-5814
CHEMBL3352684 Bioorg. Med. Chem. Lett. (2014) 24:4884-4890

RDKitでSDFをテキストファイルに変換していきたいと思います。

まずはどんな化合物たちか見てみます。

CHEMBL3098111はこんな化合物群、、、

from rdkit import Chem
from rdkit.Chem import AllChem, PandasTools

df_8111 = PandasTools.LoadSDF('./data_oxr/CHEMBL3098111.sdf')
df_8111.head(2)

f:id:magattaca:20201018190637p:plain

CHEMBL3867477はこんな感じ、、、

df_7477 = PandasTools.LoadSDF('./data_oxr/CHEMBL3867477.sdf')
df_7477.head(2)

f:id:magattaca:20201018190746p:plain

中央に位置する環がピリジンだったり4,4-ジフルオロピペリジンだったりするみたいですね。

では、テキストファイルに変換する関数をつくってみます。

一部、塩酸塩が含まれているようでしたので、SaltRemoverを使って脱塩処理をします。*1
また、重複した化合物を除くためにset()でリストからユニークなSMILESのみを残します。

こんな感じに書いてみました。

# SaltRemoverで脱塩処理を行うための設定
from rdkit.Chem import SaltRemover
remover = SaltRemover.SaltRemover(defnData="[Cl]")

def desalt_smis(sdf_data):
    # 空のリストを用意
    desalted = []

    Suppl = Chem.ForwardSDMolSupplier(sdf_data)
    
    for mol in Suppl:
        # 塩酸塩の脱塩処理
        res = remover.StripMol(mol)
        # SMILESに変換
        smi = Chem.MolToSmiles(res)
        desalted.append(smi)
    
    # unqueなSMILESのみ保持する    
    unique_smi = set(desalted)
    
    return desalted

3つのSDFに適用してテキストファイルを作成します。「data_oxr」というディレクトリにSDFを保存したのでos.pathでパスを指定しました。

CHEMBL_IDs =  ['CHEMBL3098111', 'CHEMBL3352684', 'CHEMBL3867477']

import os

for chembl_id in CHEMBL_IDs:
    # SDFデータのパスを指定
    sdf_file = os.path.join("data_oxr", chembl_id + '.sdf')
    
    # 作成した関数でSMILESに変換
    chembl_smis = desalt_smis(sdf_file)
    
    # 出力テキストファイルを指定
    txt_path =  os.path.join("data_oxr", chembl_id + '.txt')
    
    with open(txt_path, mode='w') as f:
        for smi in chembl_smis:
            f.write(smi + '\n')

1行1化合物とするため、改行\nでつないでいます。

が、もっと簡単の方法があるらしい!

その名もSmilesWriter! @iwatobipen先生がこちらの記事で紹介してくださっていました。

折角なので使ってみます。SDFを入力としてテキストファイルを出力する関数を書き直してみます。

from rdkit.Chem.rdmolfiles import SmilesWriter

def desalt_smi_write(sdf_data, text_file):
    # 空のリストを用意
    desalted = []

    Suppl = Chem.ForwardSDMolSupplier(sdf_data)
    
    for mol in Suppl:
        # 塩酸塩の脱塩処理
        res = remover.StripMol(mol)
        desalted.append(res)
   
    # SDWriterで書き出し
    writer = SmilesWriter(text_file)
    
    for mol in desalted:
        writer.write(mol)
    writer.close
    
    return None

for chembl_id in CHEMBL_IDs:
    # SDFデータのパスを指定
    sdf_file = os.path.join("data_oxr", chembl_id + '.sdf')
 
    # 出力テキストファイルを指定
    txt_path =  os.path.join("data_oxr", chembl_id + '.txt')
    
    # SDFからテキストに変換する関数
    desalt_smi_write(sdf_file, txt_path)

できました!3つとも無事テキストファイルとして出力されました。

今回は短いのであまりご利益を感じられないかもしれませんが、SMILESに変換してリストに格納する操作がいらなかったり、プロパティをもたせて書き出したりできるようなので便利そうです。

但し、SmilesWriterで書き出したテキストファイルは、各行のSMILESのあとに「空白 + インデックス」も追加されていました。

処理されるうえでは無視されるものかもしれませんが、AiZynthFinderで問題が起きないかわからないので、今回は無難に先に出力したファイルを利用することとします。

AiZynthFinder コマンドライン

データが用意できたのでCLIバッチ処理を行います。

データを格納したディレクトリ「data_oxr」に以下の4つも合わせて入れて起きます。

  1. config.yml
  2. zinc_stock_17_04_20.hdf5
  3. full_uspto_03_05_19_rollout_policy.hdf5
  4. full_uspto_03_05_19_unique_templates.hdf5

これらはデータと同じディレクトリにある必要はありませんが、configのパスを直すのが面倒なので入れてしまいました。・・・無精ですみません。

コマンド自体は簡単!ターミナルで作業ディレクトリを移動し、以下を実行するだけ*2

export KMP_DUPLICATE_LIB_OK=TRUE

aizynthcli --config config.yml --smiles CHEMBL3098111.txt

最初の1行は「OMP: Error #15」を回避するためのものなので、他の環境では必要ないかもしれません*3

で、こんな感じでターミナルに出力されていきます。

Loading policy model from full_uspto_03_05_19_rollout_policy.hdf5 and templates from full_uspto_03_05_19_unique_templates.hdf5 to full_uspto
Loading stock from zinc_stock_17_04_20.hdf5 to zinc
Selected stocks: zinc
Compounds in stock: 17422831
Selected policy is full_uspto
Done with Cc1cc(C)cc(-c2cnc(-c3cccnc3)c(C(=O)NCc3ccc4c(c3)OCO4)c2)c1 in 70.4 s
Done with Cc1cc(C)cc(-c2cnc(-c3cccnc3)c(C(=O)NCc3ccc(F)c(C)c3)c2)c1 in 69.8 s
Done with COc1ccc(CNC(=O)c2cc(-c3cccc(Cl)c3)cnc2-c2cccnc2)cc1OC in 75.0 s

分子にもよりますが1化合物2分前後なので、10化合物で20~30分くらいをみておけば良いでしょうか? Macがウィンウィン唸るのを放っておくと、「output.hdf5」というhdf5ファイルが出力されます。

ファイル名が重なると上書きされてしまいそうなので、それぞれChEMBL IDを後ろにつけて別のフォルダに保存しておきました。

では、解析結果を見てみましょう!

バッチ処理結果解析

CHEMBL3098111

出力はhdf5なので、PandasのDataFrameに読み込むことができます。*4

import pandas as pd
data_8111 = pd.read_hdf('./data_oxr/output_files/output_CHEMBL3098111.hdf5', "table")

こんな感じ

data_8111.head()
target search_time number_of_nodes max_transforms max_children top_score is_solved number_of_steps number_of_precursors number_of_precursors_in_stock precursors_in_stock precursors_not_in_stock top_scores trees
0 Cc1cc(C)cc(-c2cnc(-c3cccnc3)c(C(=O)NCc3ccc4c(c... 70.419213 545 7 19 0.986553 True 3 4 4 OB(O)c1cccnc1, Cc1cc(C)cc(B(O)O)c1, NCc1ccc2c(... 0.9866, 0.9866, 0.9866, 0.9866, 0.9866, 0.9866... [{'type': 'mol', 'smiles': 'Cc1cc(C)cc(-c2cnc(...
1 Cc1cc(C)cc(-c2cnc(-c3cccnc3)c(C(=O)NCc3ccc(F)c... 69.782567 592 7 25 0.986553 True 3 4 4 OB(O)c1cccnc1, Cc1cc(C)cc(B(O)O)c1, Cc1cc(CN)c... 0.9866, 0.9866, 0.9866, 0.9866, 0.9750 [{'type': 'mol', 'smiles': 'Cc1cc(C)cc(-c2cnc(...
2 COc1ccc(CNC(=O)c2cc(-c3cccc(Cl)c3)cnc2-c2cccnc... 74.974893 585 7 23 0.986553 True 3 4 4 OB(O)c1cccc(Cl)c1, OB(O)c1cccnc1, COc1ccc(CN)c... 0.9866, 0.9866, 0.9866, 0.9866, 0.9750 [{'type': 'mol', 'smiles': 'COc1ccc(CNC(=O)c2c...
3 Cc1cc(C)cc(-c2cnc(-c3cccnc3)c(C(=O)NCc3ccc(N(C... 71.364885 590 7 22 0.986553 True 3 4 4 OB(O)c1cccnc1, Cc1cc(C)cc(B(O)O)c1, CN(C)c1ccc... 0.9866, 0.9866, 0.9866, 0.9866, 0.9866 [{'type': 'mol', 'smiles': 'Cc1cc(C)cc(-c2cnc(...
4 COc1ccc(CNC(=O)c2cc(-c3cc(F)cc(F)c3)cnc2-c2ccc... 63.741923 587 7 22 0.986553 True 3 4 4 OB(O)c1cc(F)cc(F)c1, OB(O)c1cccnc1, COc1ccc(CN... 0.9866, 0.9866, 0.9866, 0.9750, 0.9634 [{'type': 'mol', 'smiles': 'COc1ccc(CNC(=O)c2c...

どのような合成ルートが提案されたか、画像ファイルとして出力することができます。

ドキュメントをコピペ・・・・

from aizynthfinder.analysis import ReactionTree

# 全化合物について全てのツリーのリストを取得
all_trees = data_8111.trees.values

# 最初の化合物についての情報を取り出す
trees_for_first_target = all_trees[0]

# 各ツリーを画像ファイル(png)として書き出していく
for itree, tree in enumerate(trees_for_first_target):
    imagefile = f"route{itree:03d}.png"
    ReactionTree.from_dict(tree).to_image().save(imagefile)

実行すると最初のターゲット化合物について11個の合成ルートがそれぞれpngファイルとしてフォルダに出力されました。

こんな感じです。

f:id:magattaca:20201018191630p:plain

鈴木-宮浦クロスカップリングが2回使われています。ClとBrがあって先にClを反応させるルートになっています。反応性としては逆になってしまいそうです。

では、最初にもどって課題「論文記載の化合物群の合成に必要な共通の試薬」を検証してみたいと思います。

逆合成解析を進めた終点、試薬はDataFrameのprecursors_in_stockというcolumnに格納されています。

一つ目の例を取り出してみます。

precursors_8111 = data_8111['precursors_in_stock']
print(type(precursors_8111[0]))
print(precursors_8111[0])

#  <class 'str'>
#  OB(O)c1cccnc1, Cc1cc(C)cc(B(O)O)c1, NCc1ccc2c(c1)OCO2, O=C(O)c1cc(Br)cnc1Cl

str型で一つの文字列中に複数のSMILESが「カンマ+空白」(, )で区切られて格納されています。

構造式に起こしてみましょう。文字列をsplitで区切って、SMILES一つずつに分解した後、Molオブジェクトに変換しています。

precursor_mols = []

l = precursors_8111[0].split(', ')
for smi in l:
    m = Chem.MolFromSmiles(smi) 
    precursor_mols.append(m)

Chem.Draw.MolsToGridImage(precursor_mols, molsPerRow=4)

f:id:magattaca:20201018191820p:plain

合成ルートと見比べてみてきちんと目的の原料が取り出せているようです。

では、全ての化合物についてそれぞれで提案されているルートの出発原料を取り出し、集計してみます。
集計結果で出現頻度が多くなった原料は、複数の化合物の合成に必要となる試薬なので、優先順位高く確保する必要がありそうです。

具体的な処理としては、原料のSMILESをリストとしたのち、Python標準ライブラリcollectionscounterを使って出現回数に基づく処理を行います。*5

# 全化合物の全ての原料のSMILESを格納するためのリストを用意
precursors_list_8111 = []

for i in range(len(precursors_8111)):
    # 原料のSMILES 一つずつを要素としたリスト
    l = precursors_8111[i].split(', ')
    
    # extendでリストの要素を追加
    precursors_list_8111.extend(l)

import collections

# Counterで各要素の出現頻度を数える
c_8111 = collections.Counter(precursors_list_8111)

# most_common()で出現頻度で並べ替え
mc_8111 = c_8111.most_common()

print(mc_8111)

#   [('OB(O)c1cccnc1', 17), ('O=C(O)c1cc(Cl)cnc1Cl', 10), ('Cc1cc(C)cc(B(O)O)c1', 9), ('COc1ccc(CN)cc1OC', 8), ('O=C(O)c1cc(Br)cnc1Cl', 6), ('OB(O)c1cc(Cl)cc(Cl)c1', 2), ('NCc1ccc2c(c1)OCO2', 1), ('Cc1cc(CN)ccc1F', 1), ('OB(O)c1cccc(Cl)c1', 1), ('CN(C)c1ccc(CN)cc1', 1), ('OB(O)c1cc(F)cc(F)c1', 1), ('CNCc1ccc2nccnc2c1', 1), ('CNCc1ccc2c(c1)OCO2', 1), ('COc1ccc(CN)cc1', 1), ('Cc1cc(C)cc(B2OC(C)(C)C(C)(C)O2)c1', 1), ('CN1CCc2cc(CN)ccc21', 1), ('COc1cccc(CN)c1', 1), ('NCc1ccc(C(F)(F)F)c(F)c1', 1), ('Cc1cc(F)cc(B(O)O)c1', 1), ('COC(=O)c1cc(Cl)cnc1Cl', 1), ('Nc1cc(C(F)(F)F)cc(C(F)(F)F)c1', 1), ('OB(O)c1cc(F)cc(Cl)c1', 1)]

(要素, 出現回数)という形のタプルが出現回数順に並んでいます。

では、マストバイアイテム3つを見てみましょう!

must_buy_reagents = []
occurence = []

for i in range(3):
    smi = mc_8111[i][0]
    m = Chem.MolFromSmiles(smi)
    must_buy_reagents.append(m)
    occurence.append(str(mc_8111[i][1]) + ' times')

Chem.Draw.MolsToGridImage(must_buy_reagents, legends=occurence)

f:id:magattaca:20201018192113p:plain

図の下、数字はこれらの試薬が出現した回数です。全17化合物ですので、3-ピリジンボロン酸はすべてに共通する試薬のようです。

とりあえずこの3つを購入してカップリングで骨格を作っておけば、様々なフラグメントとアミド結合をつくることで多種類の化合物を合成することができそうです。

カップリングの選択性は・・・頑張る!

CHEMBL3867477

CHEMBL3352684はCHEMBL3098111と構造が似ていたので割愛し、CHEMBL3867477の結果を見てみます。

まずは、提案ルート例から。コードは同じなので割愛します。

f:id:magattaca:20201018192251p:plain

で、出現頻度の高い上位3試薬はこちら、、、

f:id:magattaca:20201018192412p:plain

例に挙げた合成ルートでは、アルコールとフェノールの光延反応という感じですが、頻度の多い試薬を見るとフッ素原子を脱離基として求核置換のルートが多く提案されているようですね。

全49化合物ということを考えると、これらの試薬は半数前後で必要となる試薬です。これは買い、でしょうか???

まとめ

今回はAiZynthFinderのコマンドラインバッチ処理を行ってみました。複数の化合物の解析結果、共通する原料・試薬があれば、多種類の化合物を作る上で重要となりそう、ということで検証してみました。

論文というストーリーのある化合物群なので、互いに類似した化合物群があげられている、という前提はありますが、頻度の高い重要そうな試薬が結構いい感じでみつかったかな、という印象です。

さて、なぜ今回こんな解析をしてみたか? 

ここで思い出話を・・・

私は学生の頃、構造活性相関のようなテーマを行なっていました。
ダメな学生だったので指導教官から何度か急かされていたものの、ノラリクラリとかわしつつのんびり実験をしていました。

ある土曜の午後でした。TLCを焼いていると、指導教官が無言で足早に近づいてきます。

「早くテーブルの化合物作って!!!!」

温厚な指導教官も流石に堪忍袋の緒が切れたようでした。

やべぇやべぇ。至急、合成しなければ。。。

と、いうわけで多種類の化合物を急いで作らないといけないシチュエーションでした。
まずは共通の試薬を確保せねば!と、・・・必死でラボの試薬庫と冷蔵庫あさりました。

こんな時、今回みたいに重要な試薬がわかったら何を探せば良いか分かって楽だったかもしれませんね!

まあ、ちゃんと実験してればお叱り受けなかったですけどね!!

今回も色々と間違いが多いと思うので、ご指摘いただければ幸いです。

ではでは!

オープンソースで逆合成解析 ~AiZynthFinder~ part 2. 遊んだ

オープンソースの自動逆合成解析ツール、AiZynthFInder。前回は背景を知るために文献を読んでみました。今回は実際に遊んでみたいと思います。

ツールは以下のGitHubに、

github.com

ドキュメントはこちらにあります。

molecularai.github.io

インストール

GitHubのREADMEそのままにインストールしていきます。

Prerequisites

サポートされているOSはLinuxWindowsMacです。ツールの開発はLinuxで、Windows 10、macOS Catalinaではテスト済みとのこと。

ちなみに私のPCはmacOS High Serraです。後ほどいくつか躓いた点を書きますが、他のOSでは当てはまらないかもしれません。

あと、Python 3.6か3.7のanacondaかminicondaのインストールが必要です。

Installation

まずcondaのパッケージを3つインストール。

RDkitユーザーおなじみの仮想環境 my-rdkit-env に入れてみます。アクティベート! !

conda activate my-rdkit-env # お好みの環境でどうぞ

conda install -c rdkit "rdkit=>2019.09.1" -y
conda install -c anaconda tensorflow>=2.1.0 -y
conda install graphviz -y

ついでAiZynthFinderパッケージをインストール

python -m pip install https://github.com/MolecularAI/aizynthfinder/archive/v1.0.0.tar.gz

簡単! でもこれでも失敗するんですよ、私は。

インストールの注意点

起動するとこんな感じになる予定でしたが、私はSMILESを入力しても構造式が描画されませんでした。

f:id:magattaca:20201011235449p:plain
AiZynthFInder GUI

RDKitのモルオブジェクトがある、みたいな表示はされましたが、、、

f:id:magattaca:20201011235519p:plain
構造式の描画がうまくいかない場合(エラー)

READMEを見直すと、Graphvizに問題がありそうでした。インストールの際に代わりに-c anacondaを使ってくださいとのことだったので、こんな感じでやってみたら解決しました。

conda install -c anaconda graphviz -y

違いがわからない…

他に必要なもの

ツールを使うには以下の3つ用意する必要があります(ファイル的には4つ)。

  1. stock file : 逆合成の終点となる前駆体(購入可能な試薬)のリスト
  2. 訓練済みの rollout policy network : Kerasモデルと、ユニークなテンプレートのリスト(計2ファイル)
  3. configuration file

ありがたいことに1と2はfigshare からダウンロードできるようにしてくださっています。

以下の3つのファイルがダウンロードできます。結構大きいのでちょっと時間がかかります...

  1. zinc_stock_17_04_20.hdf5 (約650MB)
  2. full_uspto_03_05_19_rollout_policy.hdf5 (約300MB)
  3. full_uspto_03_05_19_unique_templates.hdf5 (約45MB)

ファイル名からstockはZINC、rollout policy model と template はUSPTOをベースとしてそうな感じがわかりますね。

で、figshareからはダウンロードした場合はconfiguration fileは自分で用意する必要があります。

ドキュメンテーションConfiguration file を参考に、こんな感じのテキストファイルを書いて「config.yml」として保存しました。

policy:
  files:
    full_uspto:
      - full_uspto_03_05_19_rollout_policy.hdf5
      - full_uspto_03_05_19_unique_templates.hdf5
stock:
  files:
    zinc: zinc_stock_17_04_20.hdf5

面倒!! という方のためにもっと簡単な方法も用意されています。

次のコマンドで指定したフォルダにデータのダウンロードとconfigファイルの作成まで行ってくれます。「my_folder」のところはお好きなフォルダ名に変えてください。

download_public_data my_folder  

著者親切すぎる・・・。

さて、ファイルが4つとも用意できたら、これらを全部作業ディレクトリに入れます。ディレクトリを移動して起動だ!!

・・・の前に、configの注意点を少し。

configの注意点

configuration fileはインターフェースにpolicy modelとstockへのファイルパスと、探索の詳細なパラメータを追加で指定するためのものです。

ですので、ファイルを作業ディレクトリ直下やパスの通っていない場所に置いておくとエラーが出てしまいます。

私は最初、作業ディレクトリ内に「data」というフォルダを作ってそこに「~.hdf5」ファイルを入れていました。この状態で先の「config.yml」を使うと以下のエラーが出ました。

OSError: SavedModel file does not exist at: full_uspto_03_05_19_rollout_policy.hdf5/{saved_model.pbtxt|saved_model.pb}

だよね! 見つかんないよね! 指定してないもんね!

相対パスに直したら動きました(「./data/」を追加)。

# config.yml
policy:
  files:
    full_uspto:
      - ./data/full_uspto_03_05_19_rollout_policy.hdf5
      - ./data/full_uspto_03_05_19_unique_templates.hdf5
stock:
  files:
    zinc: ./data/zinc_stock_17_04_20.hdf5

わかってみれば簡単でした。パス苦手・・・。

GUIアプリ

AiZynthFinderはJupyter Notebook上で使えるGUIと、コマンドベースのCUI両方が提供されています。

GUIの利点は何と言っても構造式を見ながら使えることでしょうか?
一方、CUIBatchモードが使えるので複数の分子を一度に処理できるという利点があります。

ここは、コマンド苦手だからGUI一択で!

まずは作業ディレクトリに移動してJupyter notebookを起動します。

ちなみに、aizynthapp --config config_local.ymlとするとノートブックを自動で作ることもできるらしい。至れり尽くせり。。。

以下、2行をコピペしてCtrl+Enterでインターフェースが起動します。

from aizynthfinder.interfaces import AiZynthApp
app = AiZynthApp("./config.yml")

f:id:magattaca:20201011235741p:plain
GUI全体のみため。真っ白。

出た!! さあ、逆合成開始だ!・・・と思いましたが、ここでもまた問題が! Kernelが死ぬ。。。

OMPとKernelの死(Mac限定?)

さて、インターフェースが起動したので早速検索を実行したところ、直ぐに画面が灰色になり「kernel die」と表示されnotebookが止まってしまいました。

・・・ YOU LOSE 的な?

ターミナルをみると以下のエラーが出てました。

OMP: Error #15: Initializing libiomp5.dylib, but found libiomp5.dylib already initialized.
OMP: Hint This means that multiple copies of the OpenMP runtime have been linked into the program. That is dangerous, since it can degrade performance or cause incorrect results. The best thing to do is to ensure that only a single OpenMP runtime is linked into the process, e.g. by avoiding static linking of the OpenMP runtime in any library. As an unsafe, unsupported, undocumented workaround you can set the environment variable KMP_DUPLICATE_LIB_OK=TRUE to allow the program to continue to execute, but that may cause crashes or silently produce incorrect results. For more information, please see http://www.intel.com/software/products/support/.

どうもOpenMPというのがよろしくないらしい。原因がわからない。。。

ヒントに安全じゃないけど、と断りつつ回避方法も書いてあるのでそのままやってみます。Notebook上で環境変数を書き換えます、、、 *1

import os
os.environ['KMP_DUPLICATE_LIB_OK']='TRUE'

パス苦手・・・。

この後、再度GUIを起動するコマンドをうつと今度は「kernel die」することなく検索できました!

I win !!!

もうちょっと調べるとmacOSでcondaを使っていることが原因な疑惑が出てきました。( stack overflowの記載より )

雰囲気こんな感じ・・・

  1. Condaは IntelのMKL optimizationsを使っていてそれにOpenMPが使われている。
  2. macOSはMKLではなく、独自のアルゴリズムを使っていてそこに既にOpenMPが使われいる。
  3. なのでOpenMPが重複することになり先のエラーが出る

解決方法として、MKLサポートなしでパッケージを再イントールすること(conda install nomkl)が書かれていました。試してませんが備忘録として・・・。

詳しい方ご存知でしたら教えていただけると嬉しいです。

逆合成してみた

やっと準備が整ったので、気を取り直して再度実行。
まとめると私の場合これを打ち込めばOK!

import os
os.environ['KMP_DUPLICATE_LIB_OK']='TRUE'

from aizynthfinder.interfaces import AiZynthApp
app = AiZynthApp("./config.yml")

Favipiravir

まずは小さなものから、ということで話題のアビガン(Favipiravir)!

PubChemによるとSMILESは「C1=C(N=C(C(=O)N1)C(=O)N)F」ということみたいです。

SMILESをコピペ + Enterで構造出ました! 

f:id:magattaca:20201011235729p:plain
かわいい

さあ、逆合成解析の実行だ! Run Search!!

f:id:magattaca:20201011235943p:plain
進捗!

終わった。探索の最長時間 2分、最大イテレーション 100となっていたので、今回は2分経った時点で探索終了。イテレーションは80でした(80/100)。

どんな結果かみてみましょう。Show Reactionsをクリック!

f:id:magattaca:20201012000058p:plain
提案合成ルート1

上位5つの結果から選択でき、上は最も良いスコアのルートです。
Compounds to ProcureがStock fileで指定したZincの中で見つかった手に入りそうな原料、Stepsが合成ルートです。

シアノ基の水和で1 stepのルート。ふむ、なるほど。。。

別のルートはどうでしょうか?

f:id:magattaca:20201012000622p:plain
提案合成ルート2

フッ素化・・・ミニスキ反応っぽいあれを使えばできる、、、のでしょうか?

science.sciencemag.org

3つめのルート。

f:id:magattaca:20201012000137p:plain
提案合成ルート2

N-oxideの転位で酸素を導入! ほーそういうのもあるのか!!

選択性の考慮は今後の課題と論文にありましたが、確かにこのルートでは酸化も転位も選択性が課題になりそうです。

Remdesivir

もう少し大きな分子、ということで今度はレムデシビルを試してみます。

立体は考慮しないみたいですがとりあえずIsomeric SMILESは「CCC(CC)COC(=O)C@HNP@(OC[C@@H]1C@H(C#N)C2=CC=C3N2N=CN=C3N)O)O)OC4=CC=CC=C4」だそうです。

f:id:magattaca:20201012000446p:plain
RDKitの描画カラフルで綺麗ですよね

今回は探索時間2分でイテレーション78回でした。で、残念ながら解けなかったらしい(Not Solved, Route score: 0.715)。

最もスコアが良いものはこんな感じ、、、。

f:id:magattaca:20201012001305p:plain
収束しなかった合成ルート

画像が小さいですが、Compounds to Procureの一番右の化合物はNot in stockとなっています。
Stock file内の構造まで分解できなかったみたいのでNot Solvedとなるようです。

ルートを見ると最初はtert-Butylエステルを作っては分解、作っては分解してます。
文献中に保護-脱保護の合成戦略はまだ組み入れられていないと記載されていましたが、確かに苦戦している様子が伝わってきます。

核酸アナログや糖って合成特殊な感じしますよね。ジョーンズ有機化学にも糖の合成しんどいみたいなこと書いてあった気がします。記憶の彼方ですが。。。

Ledipasvir

目標はもっと高く、大きな分子!ノーベル賞関連でC型肝炎治療薬、レジパスビルを逆合成!

SMILESも長い!! 「CC(C)C@@HN1CC2(CC2)C[C@H]1C3=NC=C(N3)C4=CC5=C(C=C4)C6=C(C5(F)F)C=C(C=C6)C7=CC8=C(C=C7)N=C(N8)[C@@H]9[C@H]1CCC@HN9C(=O)C@HC)NC(=O)OC)NC(=O)OC」

f:id:magattaca:20201012001514p:plain
NS5A阻害阻害剤 Ledipasvir

イテレーション3までしか進まずに探索が終了してしまいました。全くもってすごい分子ですよ。どうやって見つけたんだろう??

これもNot Solved(Route score: 0.534) で、分解の結果にZincのStock fileにないものが含まれていました。提案ルートはこんな感じ、、、

f:id:magattaca:20201012001728p:plain
合成提案ルート

真ん中あたりで切って、左右ユニットに分かれたルート提案となっています。

構造の右半分ユニットのルートは図の上部、左半分ユニットは下部に分かれています。
どちらもイミダゾール環(右はベンゾイミダゾール)を構築しています。
なかなかヘテロ環、芳香環を切断-構築する逆合成って難しいのかな、と思っていたのですが、合成のプロからしたら普通なのでしょうか?

イミダゾールの特殊性みたいなものがあるのでしょうあ?ちょっとわからないので専門家の方コメントいただけると嬉しいです。

ここで気づいてしまいました。正解(実際の合成ルート)を知らず、妥当な合成を判断できない私が眺めていてもツールの性能は評価できない・・・・

答え合わせ?

というわけで合成ルートをググりました。巨人の肩の上に立つ!

実際の製造方法はわかりませんが一つのルートとして比較してみると面白いかもしれません。

Favipiravir

富士フィルム株式会社の特許から(JP2012180336)。以前Twitterで見かけて印象に残ったルートです。

f:id:magattaca:20201012002211p:plain
JP2012180336

H1からT-705Aへは塩基性条件で加熱撹拌してます。加水分解、脱炭酸、ヘテロ環の開裂の3段階が起こってるんですかねー?お洒落!

・・・というか最終工程(T-705A → T-705)、AiZynthFinderが最初に予想したルートそのものです。えっ、凄い!!!

Remdesivir

New Drug Approvalsというサイトに合成ルート含めて色々と記載がありました。が、ちょっと長いのと、今回はAiZynthFinderの提案がうまくいってなかったので割愛させていただきます。

気になる方はサイト(New Drug Approcals: Remdesivir)をご覧ください。こちらによるとGilead Sciences社の特許に記載があるらしいです(WO2016069826)。

Ledipasvir

こちらも先のサイトに記載がありました。 リンクはこちら New Drug Approvals:Ledipasvir

Gilead Sciences社の特許WO2013184702が引用されています。ルートの全体は上記サイトをみていただくとして、特許の一部を抜粋します。

右側ユニット・・・ベンゾイミダゾール巻いてます!っていうかそのまんま!

f:id:magattaca:20201012002455p:plain
WO2013184702 ベンゾイミダゾール環の構築

左側ユニット・・・こっちもイミダゾール巻いてます!保護基が特許はN-Boc基、AiZynthFInderはN-Cbz基という違いはありますがだいたい一緒!

f:id:magattaca:20201012002615p:plain
WO2013184702 イミダゾール環の構築

そんでもって右側と左側の連結は・・・ベンゾイミダゾールユニットのボリル化を経た鈴木-宮浦クロスカップリング!反応の選択一緒!

f:id:magattaca:20201012002702p:plain
合体!

ここから特許では両端のBoc基を外し、2つともバリンメチルエステルとアミド化することでLedipasvirに導いています。

AiZynthFInderは、バリンユニットの導入のタイミングをのぞいて、ほぼ反応のコンセプトとしては同じルートを提案しているようです!

すごい!!!

まとめ

他にも機能はあるようですが、とりあえず今回はGUIで遊んでみました。これだけ親切設計なのに使えるまでに色々躓いてしまいました・・・。

実際に遊んで見るまでは、データから学習しているといっても限界があるのではないかな・・・と思ってましたが、AiZynthFInder予想以上に良い提案を出している、というのが私の感想です。

というか少なくとも私よりはるかに賢いです。。。ワタシ、チョットカナシイ。。。オベンキョウタイヘンダッタノニ。。。

しかし、これがオープンソースで公開されるというのは本当に凄いですね。私は遊ぶことしかできないので、みなさんぜひ使ってみてGitHubに改善を提案してください。合成の専門家からみたルートへのつっこみとか聞いてみたいです。

ではでは

オープンソースで逆合成解析 ~AiZynthFinder~ part 1. 文献メモ

有機合成の授業を受けた方なら習ったであろう逆合成、パズルみたいで楽しいって言ってる人もいましたが、私はこれがとても苦手でした・・・。全合成の研究発表見てはすげぇー、わけわかんねぇーて思ってました。

で、そんな私が知っていたら大喜びしたであろう素敵なツールがRDKit UGM 2020で紹介されていました!

その名もAiZynthFInder!!オープンソースの自動逆合成解析ツールです!!

これは遊ぶしかないですね!でもその前にどんなツールか背景をしらべましたよ。

f:id:magattaca:20201011234506p:plain
AiZynthFinderドキュメンテーションより

AiZynthFinder ?

まずどんなツールなのか? 残念ながらUGMの発表をお聞きすることができなかったのですが、スライドをアップしてくださっていました。

スライドはこちら・・・ *1

github.com

ソフトウェアについての論文はChemRxivにあります。

文献1. Genheden S, Thakkar A, Chadimova V, et al (2020) AiZynthFinder: a fast, robust and flexible open-source software for retrosynthetic planning. ChemRxiv. Preprint. 

doi.org

使われているデータやアルゴリズムの背景についてはこっち。これもオープンアクセスです。ありがとうございます。

文献2. Thakkar A, Kogej T, Reymond J-L, et al (2019) Datasets and their influence on the development of computer assisted synthesis planning tools in the pharmaceutical domain. Chem Sci.

pubs.rsc.org

論文も読めるようにしてくださっているので、この記事では論文をとスライドを頼りにツールの理解を試みたいと思います。

背景

伝統的な逆合成解析は専門家の手作業 or (手作業で抽出された)ルールベースのエキスパートシステムでした。

最近、Deep Learningの発展に伴いデータドリブンな手法がでてきました。有名なのは2018年 Nature の論文("AlphaChem"?)。

www.nature.com

化学同人の「化学」誌(2019年02月号)でも取り上げられていました。

www.amazon.co.jp

で、逆合成解析のアルゴリズムは大きく2つに分かれるそうです。

  1. template-based approach
  2. template-free approach

template-base の"reaction template"は先のエキスパートシステムにおけるルールで、化学変換を表現するルールです。このルールを「既知の反応のデータベースから(自動的に)抽出しよう!」というのがDeep Learningにおけるアプローチ。

AlphaChem (で定着したんでしょうか?) もこちらの手法で、

  1. templateを優先する形でneural networkを訓練
  2. 合成経路の提案はMonte Carlo tree search アルゴリズムによる
  3. 2.の探索を導くポリシーとして、1.で学習したtemplateを使う

ってことみたいです。今回のAiZynthFinderもtemplate-basedで、アルゴリズムの大枠はAlphaChemと同じっぽい。間違ってたらごめんなさい。

また、もう一方のtemplate-freeのアプローチにおける典型的な例としては、化学反応を自然言語処理の問題として捉え、単語のセット(出発物質、reactant)を別の単語のセット(生成物、product)に変換する問題としてアプローチします。

アルゴリズム

概要

AiZynthFinderのアルゴリズムの概要は以下のようになっています。

  1. 目的: 入力の分子を購入可能な前駆体(precursor)にまで分解する
  2. 出力: 前駆体のリストで、それ以上はアルゴリズムで分解できないもの
  3. 探索: Monte Carlo tree search
    1. 木のノード(leaf): 分子のセット
    2. ノードの選択 : 各ステップでは信頼区間上限を使って一番良さそうな leaf nodeを選択する
    3. 子ノード(child)の作成 : Neural network policyを使って反応テンプレートの候補をリスト化し、新しい前駆体を作成。どの子ノードを作るか優先順位付けを行う。
    4. イテレーションの終点 : 購入可能な前駆体に到達 or 最大の深さに達するまで2-3を繰り返す。
    5. イテレーションのスコア: 終点に達するとleaf nodeのスコアは木の根(root, 入力分子)まで逆伝搬され、次のイテレーションが開始。
  4. 終点: 設定した回数のイテレーションに達するか、時間制限に達した段階で探索ストップ

UCB?

ノードの選択で"upper confidence bound statistics"と書いてあったところを信頼区間上限としました。よくわからないですが、ググった感じ多腕バンディット問題っていうのと関係している感じでしょうか?

こんな雰囲気の話らしい…*2

  1. それぞれ得られる報酬の確率分布がわからない複数の選択肢がある状態で、限られた試行回数で報酬が最大となる選択肢を選びたい
  2. 探索と利用のバランスを取るアルゴリズムで報酬の最大化を目指す(Exploration-exploitation tradeoff)
    1. 探索 : 色々な選択肢を試す
    2. 利用 : 過去の結果から最適と思われる選択肢を試す  
  3. 解法例
    1. ランダム探索 : ε-greedy(貪欲)方策
    2. 信頼上界による方法: UCB1アルゴリズム。不確かな時は楽観的に(発見的な原理)
    3. 事後確率サンプルによる方法 : Thompsonサンプリング(ベイズ推論)

強化学習の文脈でよく取り上げられる問題なのでしょうか?   

UCB(Upper Confidence Bound)法ではUCBスコアと呼ばれるスコアに基づいて次の選択肢を選びます。この中に、探索枝の選択をバンディット問題と捉えるUCT(Upper Confidence bounds on Trees)アルゴリズムというのもあるそうなので、多分これが関係してるのではないでしょうか??

よくわからないので詳しい方教えてください。

もう少し詳しく

話を戻して、 AiZynthFinderのアルゴリズムについてより詳しくはChemical Sicenceの文献を読んでね。と、いうことなのでそっちも見てみたいと思います。

大きく3つの点について議論されていました。

  1. 学習に用いたデータセット
  2. 反応テンプレートの抽出とサイズ、種類の影響
  3. スコア(解析がうまくいったかをどう評価するか?)

データセット

データセットとしては以下の4つが用いられています。

  1. USPTO dataset (patents, ~ Sep. 2016)
  2. Pistachio dataset (patents, ~Nov. 2017)
  3. Reaxys dataset (literature and patents)
  4. AstraZeneca ELN (industrial data)

抽出されたユニークな反応テンプレートがそれぞれどのデータセットに由来したものだったか、Fig. 1にベン図で示されています。

Reaxys datasetだけで見つかったテンプレートの割合がもっとも多く41.1%、ついで特許データ(USPTO and Pistachio)のみで見つかったものは32.5%とのことです。

抽出のルールにも依存した結果、とのことですが、Reaxysにも含まれていない特許情報があるかも、っていうのはちょっと面白かったです。あらかた全部カバーしているのかと思ってました。

AstraZenecaのin-houseデータにユニークなテンプレートも1.5%みつかったようですが、これは外部データベースに無い新規反応を社内で見つけているから、というよりも化合物の構造の多様性によるアーティファクトではないか、とのことです。

また、Fig.4 では各データセットごとに訓練したモデルについてそのパフォーマンスの比較が議論されています。

テンプレートの抽出

テンプレートの抽出は Coleyet al. (ACS Cent. Sci., 2017, 3 , 434-443) によるルール抽出の実装が応用されています。

元々は、反応中心に直近接した範囲のみを考慮するものでしたが、脱離基や保護基といった拡張した環境、反応性官能基(reactive speices)を考慮できないという問題点がありました。

その後、RDChiral (Coley et al. J. Chem. Inf. Model., 2019, 59 , 2529-2537 )で、有機合成でよく使われる約75種の官能基と保護基を含めるように修正されました。

これにより指定したグループについて、分子の拡張された環境をモデルが説明できるようになったそうです。

今後の課題として、ここではまだ保護、脱保護について合成戦略の観点を取り込むことができていないこと、指定していない新しい保護基や官能基について学習することができないこと、が挙げられています。

ネットワークとテンプレート

AiZynthFinderが参照しているAlphaChemでは3つのネットワークの訓練が行われていました。

  1. expansion policy : 与えられた化合物に適用されるテンプレートセットを予測
  2. rollout policy : より厳密で具体的なテンプレートセットの予測
  3. in-scope filter : 成功した(positive)反応にもとづいて訓練し、仮想的にうまくいかない(negative)反応のセットを列挙する

このうちAiZynthFinderでは 2. rollout policyに相当するネットワークだけに焦点をあてています。

入力に対してテンプレートを予測、そこから前駆体を導き、再帰的に当てはめていくことで逆合成の木(retrosynthetic tree)を生成していきます。

生成された逆合成ルートが妥当(valid)であるには、3つの条件をみたす必要があります。

  1. あたえられたcontextに対して予測される、データセットから抽出されたテンプレートがあること
  2. 予測されたテンプレートが「うまく(successfully)」適用できること
  3. 前駆体のセットが妥当なSMILESであること

逆合成解析の最終的な目標はウェットのラボでうまくいく合成ルートを提案することですが、この研究の主眼はまずin silico で何が予測できるかを見極めることにおかれています。それを踏まえた上で、先の条件の補足を見ていきます。

まず、「2. テンプレートの適用の成功(success)」について、これは「その反応が実際にうまくいくかどうか」ではありません。生成物(product)とテンプレートにマッチするサブグラフがあり、そのマッチするテンプレート使って前駆体/反応剤のセットが生成できること、を成功(success)としています。

3.のSMILESに関して、テンプレートベースのアプローチでは、生成物の全体の構造は保ったままで反応点(reactive site)だけが変更されます。したがって生成された前駆体のSMILESがvalidであれば、生成物と同じ構造の特徴を共有する前駆体のセットが得られたと推定できます。
ですが、ここにも実用上の問題があり、化学反応の選択性の問題などから、得られた前駆体が必ずしも実際の反応に適したものとは言えない、と指摘されています。

最後に、ここではin silicoでどこまでできるかを見る目的として、neural network policyの目標を、「適用可能なテンプレートの数を最大化すること」におかれています。また、ルートの終点は列挙された前駆体が購入可能か(commercially available)チェックすることで決定されています。

スコアと正確さ

先行研究では逆合成解析のパフォーマンス評価として正確さ(accuracy)が用いられていました。

正確さは「policy netoworkが反応テンプレートを正確に予測できるか」を反映します。

一方で、逆合成解析のタスクは「データセットにある一つの例(one to one)」ではなく、「適用可能な複数のテンプレートを予測(one product to many template)」することにあります。したがって、データセットに基づき1対1を評価する正確さでは、テンプレートの抽出源であるデータセットオーバーフィッティングしてしまう可能性があります。

また、正確さはテンプレートの適用可能性をうまく説明できないことが指摘されています(Fig. 2)。例として、テンプレートの考慮する反応中心からの範囲(radius)を広げて特異度を上げていくにつれて、マッチするサブグラフを見つけるのに失敗して適用がうまくいかなくなり、モデルのパフォーマンスが下がる傾向にあるのに対し、正確さではその変化を捉えることができずミスリーディングな評価となってしまうそうです。

以上を踏まえて、著者らは正確さに加えて、policyの評価に適用可能なテンプレートの数を使うことを提案しています。もう少し全体論的な観点からモデルのパフォーマンスを評価しましょう、ということのようです。

比較検証したころ抽出したテンプレートのうち、種々の分子に適用可能なテンプレートの割合は非常に少なかったそうで、特異度(specificity)と一般化可能性(generalizablitity)のバランスを取るために、

  1. テンプレートは反応中心と、その一次の最近接したもの(the first degree nearest neighbors)を考慮したものにすること
  2. 種々の官能基と保護基をあわせて指定すること

といった提案がなされています。

テンプレートのサイズとパフォーマンス

評価方法についての議論を踏まえた上で、テンプレートライブラリーのサイズがパフォーマンスに与える影響を検証しています(Fig. 3)。

用いるテンプレートライブラリーが大きくなるほど正確さは低下する一方、「逆合成モデルがルートを生成できるか?」によるパフォーマンス評価は低下しませんでした。逆合成タスクは考えうる可能な出力を出すことに対し、正確さは"ground truth"(データセットにある実例)に基づくので、よりタスクに即した評価基準が重要になるかも、ということのようです。

テンプレートライブラリーのサイズの影響について以下が指摘されています。

  1. ライブラリサイズが大きくなるとテンプレートの化学的多様性が増加し、より合成ルートを見つけることができる
  2. 一方で、数が増えるにつれてノイズも増えパフォーマンスが低下する

反応テンプレートの数と、それらが表す反応の範囲(reaction space)にはバランスがあって、ライブラリを増やすについれてカバーできる範囲もふえるものの、逆に、適した反応テンプレートをライブラリの中から探し出すことが難しくなってしまい、増やしすぎるとパフォーマンスが落ちる可能性もあるよ。

ってな感じでしょうか?

以上が、アルゴリズムの背景でした。

オープンソース

なんとなくソフトの裏で動いていることがわかってきたところで、もう一度ChemRxivの文献に戻ります。

イントロでは他のソフトウェアにも触れられています。比較のためにメモ・・・

  • オープンソース: ASKCOS (from MIT)、LillyMol (from EliLilly)
  • 登録必要だけどフリー: Chemical AI、IBM RXN

逆合成解析のオープンソースソフトが限られている理由として、2点指摘されています。

  1. 反応データベースと、手作業によるルールの多くが商用であること
  2. 購入可能な前駆体のデータベース(ルート予測の終点判断によく使われる)も多くが商用

で、今回著者らがAiZynthFinderをオープンソースとして公開することにした理由としてIntroductionでこう書かれています。

...However, we believe that the scientific community would benefit from an open source implementation that provides algorithmic transparency and promotes reproducible research with sustainable software...(中略)...We envisage that by providing this tool free and open-source, other researchers can use it for benchmarking, contribute to a continuous development and, suggest synthetic routes for novel compounds.

素敵! ありがとうございます!

で、使えるように3つ提供するよ!っと

  1. 訓練済みのneural network policy
  2. 購入可能な前駆体のデータベースを作るためのツール
  3. 新規ユーザーの学習曲線を下げるための詳しいドキュメント

ツールは以下のGitHubで公開されています。

github.com

ドキュメントはこっち。

molecularai.github.io

一旦まとめ

ぶっちゃけ理論の詳しいところはさっぱりわかりませんでしたが、これは楽しそうですね!

早速遊んでみたいですが、ちょっとここまでで力尽きたので一旦区切ります。

最後に、遊ぶのに覚えておかないといけなさそうな用語・・・

  1. policy : 反応データセットで訓練したNeural networkのモデル
  2. template : 反応データセットから抽出した反応テンプレート(ライブラリ)
  3. stock : 購入可能な前駆体のデータベース(ルート終点に関係)

RDKit UGM時間が合わずにほとんど見られなくて残念でした。でもDiscordの議論をみたらさっぱついていけかったので、これは聞けてもわかんなかっただろうな、ってなりました。残念なのは私の方でしたね!

色々と間違っていることが多そうなのでご指摘いただけると幸いです。

*1:最後のページにConfidentiality Noticeとか書いてあるんですけど良いのでしょうか?

*2:参考
1. 探索と利用のトレードオフベイズ環境モデル 牧 野 貴 樹 計測と制御 第52巻 第2号 p154-161 https://www.jstage.jst.go.jp/article/sicejl/52/2/52_154/_pdf
2. 私のブックマーク 小宮山純平 Vol.31.No.5(2016/9)多腕バンディット問題 https://www.ai-gakkai.or.jp/my-bookmark_vol31-no5/