【備忘録】Claudeによる生体分子モデル最適化の36キットを読む ― exact / fast / bigと再現条件を整理する

はじめに

Anthropicは2026年9月17日、Claudeを使って生体分子モデリング向けのオープンソースモデルを最適化した成果を公開しました。あわせて、36個の推論最適化キットを公式GitHubリポジトリで公開しています。

研究記事によると、作業はClaude Science上で社内の汎用研究モデルが行い、生体分子モデリングの経験はあるものの推論最適化やkernel開発の経験はない技術スタッフ2名が監督したとのことです。

発表では「平均で約4倍」という数字が目を引きます。ただし、この値を任意のモデル・GPU・入力で再現できる一般的な性能保証として読むのは適切ではありません。公開リポジトリには、対象ツールごとに固定されたupstream、実行モード、GPU条件、出力差、セキュリティ上の前提が細かく記載されています。

この記事では、実GPUベンチマークを行ったとはせず、公開artifact（成果物）を読むための入口として、次を整理します。

• off / exact / fast / bigの違い
• 「約4倍」と「同一出力でほぼ2倍」を混同しない見方
• Docker / Apptainer / Python venvによる再現条件
• upstream code、weights、起動hook、compile cacheの安全上の注意
• 手元で試す前に確認したいチェックリスト

※本記事は2026年9月25日時点のAnthropic Research、technical report（2026年9月21日更新版）、公式GitHubリポジトリの公開情報をもとに整理した個人の備忘録です。生体分子モデルの精度や研究上の妥当性を独自に検証した記事ではありません。図解は公開情報をもとに筆者が独自に作成したもので、Anthropic公式の資料ではありません。

先に結論

今回の公開物は、継続提供されるSDKというより、36個のupstreamツールごとに固定条件を持つ参照用の最適化キット集として読むと整理しやすいです。

特に重要なのは次の5点です。

1. リポジトリは36キットを収録していますが、Anthropicの研究記事は「30超のモデル」を4週間弱で最適化した成果として説明しています。technical reportによると、36は実装単位の数で、AlphaFold3の2実装（JAX版・PyTorch版）、OpenFold3の2種類の重み（preview2・OpenBind-0）、Enformerの2実装などを別々に数えています。集計単位を混同しないようにします。
2. exactはoffと同一出力で高速化するモード、fastは文書化された小さな数値差を許容するモード、bigはpeak GPU memoryを抑えるモードです。
3. すべてのキットが全モードを持つわけではなく、既定モードもキットごとに異なります。
4. Anthropicの発表値は特定のモデル、入力、GPU、評価方法、baselineに基づく結果です。自分の環境では、精度と速度を別々に測る必要があります。
5. このリポジトリは「not maintained and not accepting contributions」と明記されたreference releaseです。固定されたupstreamや依存関係の脆弱性確認は利用者側に残ります。

公開されたものを分けて見る

公式情報は、大きく3層に分けて読むと理解しやすそうです。

層	主な内容	読むときの注意
Anthropic Researchの記事	研究全体の成果、速度・メモリ・protein designの評価	発表値を一般性能へ拡大しない
technical report	評価方法、対象モデル、baselineの定義、ベンチマークの詳細	条件の異なる数値を合算しない
GitHubの36キット	実行方法、mode、固定version、GPU、変更点、安全上の前提	キットごとの差を各README / STOCK.mdで確認する

ニュースとしての成果と、手元で再現するための手順は同じものではありません。実際に試す場合は、トップレベルREADMEだけでなく、対象キットの次のファイルまで確認する必要があります。

• README.md: setup、run、対応mode
• STOCK.md: upstreamの正確なversion、weights、software stack
• CHANGES.md: 各modeで何を変更するか
• THIRD_PARTY_NOTICES.md: 第三者コードやライセンス
• configs/<card>.env: 対応GPUごとの設定（多くのキット。enformer、esmc、evo2などconfigsを持たないキットもあります）

4つのmodeを整理する

トップレベルREADMEでは、全キット共通の語彙として4つのmodeを定義しています。

mode	公式README上の位置づけ	確認したいこと
off	固定されたupstream releaseを、キットの最適化なしで実行	比較基準として本当に同じ入力・seed・環境か
exact	offと同一出力で高速化	「同一」の判定方法と対象出力
fast	ツール固有のseed間変動内にある、文書化された小さな数値差を許容して高速化	downstream taskの指標、許容差、再現回数
big	peak GPU memoryを最小化し、他modeでは載らない入力を扱う。対応キットでは--n_gpu Pで1ホスト内のP枚に分割	使用GPU数、速度、出力精度、入力サイズ

ここで、exactという名前だけを見て「科学的に常に正しい」、fastを見て「精度劣化は無視できる」と判断しないことが重要です。これはキット内の比較モードです。対象モデル自体の妥当性や、未知のデータに対する予測性能まで保証する名前ではありません。

対応modeと既定modeはキットごとに違う

2026年9月25日時点の公式リポジトリで36ディレクトリを確認したところ、各READMEに記載されたmodeの組み合わせは同一ではありません。たとえばesm_if1はoffとfastだけでexactを持たず、borzoiやprogen2はoffとexactだけです。トップレベルREADMEでも、既定modeについて次の例外が説明されています。

• 既定は多くの場合fast
• fastを提供しないキットとevo2では、通常exact
• atlasfoldはoff
• proteinmpnnは毎回mode指定が必要
• library-styleのキット（enformer、enformer_deepmind、esmc、gpnstarなど）は、<KIT>_OPT=exactのような環境変数やenable()で最適化を有効化

したがって、共通コマンドを36キットへ一律に当てはめるのではなく、対象キットのREADMEを正とするのが安全です。

また、キットmodeが有効になると[<kit>-opt] ACTIVE mode=...が出力され（多くのキットではstderr）、環境条件を満たさない場合はNOT ACTIVEとして終了コード3で止まる設計です。最適化できない場合に黙ってstockへ戻らない点は、比較結果を読むうえで確認しやすい仕組みです。

「平均約4倍」をどう読むか

Anthropic Researchの記事には、少なくとも次の異なる主張があります。

• 30超のdeep learning modelを4週間弱で最適化
• 全体として、minimal amount of precisionを犠牲にする設定では平均約4倍
• identical outputsでは全体としてほぼ2倍（nearly 2x）
• 12個を超える（over a dozen）biomolecular structure prediction model群では、最小限のprecision低下で平均約4倍、同一出力で平均約1.6倍
• FlashPairformer（triangle attention / multiplication用のcustom kernel）は、field standard比でtriangle attentionが2.7〜2.9倍、triangle multiplicationが1.7〜3.2倍（モデル構成による）

これらは同じ分母の一つの数値ではありません。計測単位もモデル群ごとに異なります。technical reportによると、structure prediction model群の値はH100上でのforward passの比較で、Fastは13モデル平均で約4.1倍、Exactは14モデル平均で約1.6倍です。FlashPairformerの値はfield standard比のkernel比較で、pair width（128か256か）によって倍率が変わり、モデル全体の推論時間とは別です。

baselineの定義と用語のずれ

technical reportの速度比較のbaselineはdefaultと呼ばれ、未改変のupstreamを、同じGPU上で知識のある利用者が取れる最速かつ正しい構成で動かしたものです。具体的には、upstreamがサポートするoptionalなfused kernelの有効化、GPUを飽和させるbatch size、MPSによる複数プロセス共有などが含まれます。作者が出荷したままの状態はbaseとして別に扱われています。

紛らわしいのは、reportがコード側の呼び名について、reportのdefaultをstock、reportのbaseをdefaultと呼ぶと説明している点です。つまり、reportの「default」とコード上の「default」は別物です。また、本記事で使う「既定mode」は--modeを省略したときにキットが選ぶmodeのことで、どちらのdefaultとも別の概念です。

公開キットのoffは固定されたupstreamをキットなしで実行するものですが、手元で動かすoffがreportの比較条件（fused kernelやbatch sizeの設定）に揃っているかは、各キットのREADMEとtechnical reportの該当節で確認が必要です。そのため、発表値の倍率と手元でoffを基準に測った倍率をそのまま同一視しないよう注意が必要です。一部のキットのREADME（boltz2、openddeなど）も、起動・checkpoint読み込み・featurizationなどはどのmodeでもかかるため、小さな入力や1回あたりの処理件数が少ない場合は、コマンド全体の短縮がモデル処理部分の短縮より小さくなると説明しています。

精度側の確認範囲

精度側については、研究記事は構造予測モデルについて、最適化版がdownstream task（構造予測）の性能に影響しないことを確認したと述べています。構造予測のfast相当は、DockQ 0.23以上をacceptableとする評価で既定設定（reportのdefault）と統計的に区別できなかったと報告しています。technical reportでは、13構成を合算した評価で、acceptableな界面の割合の変化はどのmodeでも1ポイント未満で、ゼロと区別できなかったとされています。ただし、モデル単位では小さな低下を否定しきれないケースがあることもreportに書かれています。

また、reportのLimitationsによると、downstreamの精度評価の対象はdesign modelsと、AF2 initial guessを除く構造予測モデルです。genomicsモデルとprotein language modelsは、defaultとの出力比較にとどまります。「全モデルで精度が確認済み」と読まないようにしたいところです。

記事に引用する場合は、次をセットで残す必要があります。

• どのモデル群か
• exact相当か、数値差を許容する設定か
• コマンド全体の実行時間か、forward passか、特定kernelか
• baselineがreportのdefault（最速構成）か、出荷時のままか
• 使用GPUとsoftware stack
• input size、seed、recycleなどの条件
• 精度指標と比較方法

なお、キットのREADMEには入力サイズによって効果が変わる例も書かれています。atlasfoldは約400 residueを超える入力で効果が出始め、小さな入力ではstockより遅くなるとされています。

👉 「Claudeを使えば自分の推論も4倍になる」ではなく、Anthropicが特定条件で報告した結果であり、公開キットで対象ごとに検証できると捉えるのがよさそうです。

bigは「実行できた」と「正しく予測できた」を分ける

研究記事では、big modeにより、単一のNVIDIA GPU node（8 GPU）で10,000 tokenを超える一部の生体分子システム（ヒトミトコンドリアcomplex I、70S ribosomeなど）を正確に予測できたと報告されています。

一方で、単一の8-GPU B300 nodeで約31,000〜70,000 residue規模のviral capsidやprotein compartmentの推論を完了した実験については、予測構造がcollapseし、正しく予測できなかったことも明記されています。technical reportによると、7件の実行はすべて完了したもののすべてcollapseしており、そのうち4件はrecycleなしの単一trunk passという短縮protocolでした。ただし、recycle 10回とtemplateを使ったAAV2の実行もcollapseしているため、短縮protocolだけが原因とは言えません。reportは、学習時のcropより桁違いに大きい入力への汎化の失敗が原因ではないかという仮説を示しています。

ここは次の3段階を分ける必要があります。

1. GPU memoryに載る
2. inferenceが完了する
3. downstream taskとして妥当な結果になる

bigは主に1と2の到達範囲を広げるmodeです。technical reportも、bigは計算できる範囲を広げるものであって、モデルが学習した範囲を広げるものではないと述べています。大きな入力を処理できたことだけで、3まで保証されたとは判断できません。

再現環境は「どれを使うか」より「固定条件を守れるか」

公式READMEは、キットごとに利用可能な範囲で次の3経路を示しています。

• Docker
• Apptainer
• Python venv

基本的な流れは、対象キットの固定stackを用意し、bash run.sh install、bash run.sh check、実行の順に進みます。ただし、すべてのキットが全経路を提供するわけではなく、手順もキットごとに異なります。たとえばatlasfoldはcontainer recipeがなくPython venvのみです。また、enformer_deepmindはapptainer.defを使わず、Dockerで作ったイメージから直接.sifへ変換する手順になっています。

また、トップレベルREADMEは、ビルド済みのDocker / Apptainer imageを初回公開から1週間以内に提供予定としています。2026年9月25日時点でもリポジトリのmainは初回公開commitのままでREADMEにも更新がないため、当面は各キットのenvironment/Dockerfileやapptainer.def（またはキットのREADMEが示す手順）からbuildする前提で考えておくのが無難です。

ハードウェア条件

すべてのキットは、Linux x86-64上のNVIDIA H100 80 GB向けの設定を基準として記載されています。technical reportの速度・メモリ測定もすべてH100 80 GBで行われています。A100、H200、B200、B300などは、対応するconfigを持つキットに限り、各READMEの条件で利用します。

また、NVIDIA driverの下限はsoftware stackにより異なり、READMEでは525〜580の範囲とされています。コンテナを使っても、host側driverの条件はなくなりません。

compile cache

初回実行時にはkernel compileが走り、数秒から数分かかる場合があります。JAX系の一部（af2ig、colabdesign、mosaic）では入力長やshapeごとにcompileが必要です。また、事前に埋めたcacheは、Torch/Triton系では同じcompute capabilityのGPUで使えますが、JAX系では同じGPUモデルでしか使えません。

そのため、ベンチマークでは少なくとも次を分けたほうがよさそうです。

• 初回compileを含む時間
• 起動・checkpoint読み込み・featurizationを含むコマンド全体の時間と、モデル処理部分の時間
• cache済みのsteady-state時間
• 入力長・shapeを変えたときの再compile
• peak GPU memory
• output差とdownstream metric

速度だけを1回測ると、compile時間やcache条件の違いをモデル差として誤読する可能性があります。

セキュリティ境界を先に確認する

このリポジトリは研究用performance toolingであり、READMEはtrusted inputs、trusted weights、single-user machineまたはcontainerを前提にしています。

特に確認したいのは次の点です。

1. upstream codeとweightsを実行する

各キットは固定されたupstream releaseをstock/に同梱し、それを実行します。最適化キットだけでなく、upstream project側のadvisoryも追う必要があります。

weightsにはtorch.load / pickleで読み込むものがあり、悪意あるpickleはload時にコードを実行し得ます。READMEは、文書化された取得元とSHA-256 pinに一致するweightsのみを使うよう案内しています。

2. Python起動hookを追加するキットがある

多くのキットでは、editable installによりsite-packagesへ<kit>_opt_autoload.pthファイルが置かれ、Python起動時にautoload moduleが読み込まれます。環境変数でmodeが指定されると、import hookによりupstream packageへ実行時の変更を加えます（af2ig、ef2inv、esm_if1、progen2、proteinmpnnはこのhookを入れません）。

このほか、boltzgenやopenfold3などはsitecustomize経由でhookを読み込み、rfdiffusion3とrosettafold3はinstall時にupstreamのファイルを上書きします（元ファイルはbackupされ、stock用に別のinterpreterを残す構成です）。

共有された汎用Python環境へ安易に入れず、キット専用のvenvまたは隔離したcontainerを使うほうが境界を理解しやすいです。

3. containerは自動的に安全になるわけではない

公式READMEでは、Docker / Apptainer recipeは非privileged userを作成せず、rootとして動くと説明されています。rootless runtime、不要なcapabilityを付けないこと、READMEが指定するmountだけにすることが推奨されています。

4. sequenceが外部へ送られる既定動作に注意する

READMEは、stock ColabFoldが、alignmentを事前指定しない場合や--msa-mode single_sequenceを選ばない場合に、query sequenceを公開alignment server（api.colabfold.com）へ送ると説明しています。OpenFold3も--use-msa-serverが既定で有効で、キットはこれらの既定をそのまま通します。

非公開sequenceを扱う場合は、モデル実行だけでなくMSA取得経路とnetwork egressまで確認が必要です。

手元で試す前のチェックリスト

対象の固定

• 36個から対象キットを1つに絞った
• STOCK.mdでupstream version / commit / weightsを確認した
• CHANGES.mdでmodeごとの差を確認した
• upstreamとweightsのライセンスを別々に確認した

環境

• Linux x86-64、NVIDIA GPU、driver条件を満たす
• 対象GPU用のconfigが存在する
• Docker / Apptainer / venvのうち、そのキットが案内する経路を選んだ
• compile cacheを他ユーザーと共有しない
• 初回compileとcache済み実行を分けて測る

比較

• 同じinput、seed、recycle、batch条件でoffを基準にする
• offの設定がtechnical reportのbaseline（default）と揃っているか確認する
• ACTIVE行で意図したmodeが有効か確認する
• wall-clock timeだけでなくpeak GPU memoryも記録する
• output差とdownstream taskの指標を別々に確認する
• bigでは「完走」と「妥当な予測」を分けて評価する

安全性

• upstream codeとadvisoryを確認した
• weightsの取得元とdigestを確認した
• 専用環境または隔離containerを使う
• mount、capability、network egressを最小化する
• 非公開sequenceを外部MSA serverへ送らない設定を確認した

この公開物から学べること

このリポジトリの面白い点は、AIがコードを書いたこと自体よりも、生成された最適化を比較可能な形へ閉じ込めていることだと感じました。

• upstreamを固定する
• stock相当のoffを残す
• 出力同一性を保つexactと、数値差を許容するfastを分ける
• memory制約を扱うbigを別にする
• modeが有効でなければ黙ってfallbackしない
• 対象ごとに変更点と再現環境を文書化する

AI生成コードを採用するときも、「生成できたか」だけでなく、基準実装、許容差、環境pin、失敗時挙動、安全境界をartifactとして残す設計が重要だと整理しやすそうです。

まとめ

• Anthropicは30超の生体分子モデルを4週間弱で最適化したと報告し、公式GitHubで36個の推論最適化キット（実装単位）を公開しています。
• 平均約4倍は特定条件で数値差を許容した結果で、同一出力側（全体でほぼ2倍）やモデル群別の値、kernel単位の値とは分けて読む必要があります。baselineはreportのdefault（未改変モデルの最速構成）で、コード上の用語とずれている点にも注意します。
• downstreamの精度評価はdesign modelsと構造予測モデル（AF2 initial guessを除く）が対象で、genomics / protein language modelsは出力比較にとどまります。
• off / exact / fast / bigは比較の目的が異なり、対応modeと既定modeもキットごとに異なります。
• bigでは、memoryに載ること、推論が完了すること、結果が妥当であることを分けて確認します。
• 公開物は保守されないreference releaseです。固定upstream、GPU、compile cache、weights、起動hook、network egressまで確認してから隔離環境で試すのが安全です。

実際に再現する場合は、36個を一度に扱うより、対象キットを1つ選び、offとそのキットが持つ最も保守的なmode（多くはexact）の比較から始めると整理しやすいと思います。

参考（公式情報）

• Anthropic Research: How Claude is uplifting biomolecular modeling
  https://www.anthropic.com/research/claude-uplifts-biomolecular-modeling
• Anthropic公式GitHub: Inference optimization kits
  https://github.com/anthropics/uplifting-biomolecular-modeling
• Initial public release commit（2026-09-17）
  https://github.com/anthropics/uplifting-biomolecular-modeling/commit/f4f62fa6592ae4938d49b1757bea0cfeff9f468e
• Technical report: Accelerating open-source biomolecular models with Claude（PDF、2026-09-17公開、2026-09-21更新版を参照）
  https://www-cdn.anthropic.com/e96b5807039a88168733d9687afe41dfbbd5de13.pdf