Agents in biology — ウイルス配列取得をgget virusで99.7%まで揃えた研究
Anthropicが6月8日に公開した生物学エージェントの現在地。120クエリのVirBenchで、フロンティアモデル単体は精度がばらつくが、決定論的な取得層gget virusを挟むと全モデルが90%超に揃った結果を読み解きます。
Anthropicは2026年6月8日、「Paving the way for agents in biology」と題したリサーチ投稿を公開しました。執筆はLaura Luebbert氏で、Pardis Sabeti氏ら複数の研究者との共同研究に基づいています(発表ページには各氏の所属は記載されていません)。テーマは「Claudeを含む科学エージェントが、ウイルス配列のような生物学データを取り出すワークフローでどこまで実用に耐えるか」です。
注目すべきは、フロンティアモデル単体の生データ取得精度は16.9〜91.3%とばらつき、同じモデル・同じプロンプトでも回答が大きくぶれた一方で、gget virusという決定論的な取得層を挟んだ瞬間に全モデルの精度が90%を超え、GPT-5.5は99.7%、モデル間の差もほぼ消えた点です。エージェントの賢さよりも、生物学データインフラを「エージェントが歩ける道」に整える方が効くという主張は、Making Claude a chemistの化学領域の取り組みや社会科学者のコーディングエージェント常用率調査とも揃った、Anthropicの科学領域への投資方針の延長線上に位置付けられます。
要点 — VirBenchで見えた3つの事実
このリサーチ投稿が提示した中核ポイントを、研究者と非専門の読者の双方が判断に使える粒度で押さえます。
- フロンティアモデル単体ではウイルス配列取得が安定しない — Claude Sonnet 4、Claude Opus 4.7、Biomni OSS、Edison Analysis、GPT-5.2-pro、GPT-5.5の6システムをVirBench(120クエリ・40病原体)で測ると、平均精度は16.9〜91.3%。Sonnet 4は同一プロンプトで3回試して、想定266件のクエリに対し106件・15件・5件と異なる結果を返しました。
- 決定論的な取得層gget virusを挟むと全モデルが90%超に到達 — gget virusはNCBIの研究者と共同で開発したPythonパッケージで、REST / Datasets / E-utilitiesという3系統のAPIを内部でつなぎ替え、Web UIの絞り込みを再現します。導入後の精度はGPT-5.5で99.7%、Run-to-Runのばらつきもほぼ解消されました。
- モデルの新しさより「取り出し口」の整備が効く — gget virus導入後はモデル間の差がほぼ消えたため、「最新で最も高価なモデルを使わなくても信頼できるデータセットを作れる」状態に近づきました。Anthropicはこれを「context engines(文脈エンジン)」と呼ぶ広い構想の一例として位置付けています。
全体メッセージは「エージェントの推論能力よりも、生物学データインフラ側の決定論レイヤーが今のボトルネック」という事実報告です。投稿自体も「将来モデルがさらに賢くなれば、こうしたハーネスは不要になる可能性はあるが、いまの科学ワークフローの精度・監査性・コストを考えると、決定論層を作る価値は残る」と控えめなトーンで結論を置いています。
背景 — なぜ生物学はソフトウェア工学のようにエージェント化しにくいのか
投稿の冒頭は、生物学データインフラを「車(エージェント)が出てくる前に設計された旧市街」に例えるところから始まります。狭く曲がりくねった道、独自のファイル形式、散在するデータベース、ワンオフの取得スクリプト。一方でソフトウェア領域は最初から車のために設計された都市で、バージョン管理・整備されたAPI・パッケージマネージャという形でエージェントが走りやすい道路が用意されてきました。コーディングエージェントの進歩が生物学エージェントよりはるかに速かった理由のひとつはここにあります。
もうひとつの非対称性は「報酬の検証可能性」です。ソフトウェアではGitHub Issueに対してパッチを生成し、プロジェクトのテストが通るかどうかで成果を即時に評価できます。一方の生物学は、検証しやすく意味のある報酬がそもそも少ない領域です。RefSeqとGenBankのレコードを意図せず混ぜる、断片ゲノムを完全ゲノムとして扱う、セグメントウイルスのセグメント名を取り違える、メタデータフィールドの不整合で関連レコードを取り損ねる──こうした細部のズレが下流の生物学的解釈そのものを無効化してしまいます。
「コードを書くのは一番ラクな部分だった。ほとんどの仕事はブラウザでクリックすることだった」
これは投稿が引用するAndrej Karpathy氏の発言で、Web開発を「vibe-coding」した後で認証・決済・デプロイを設定しようとして1週間溶かしたという話に紐づいています。投稿はこの不満を「人間用に作られた環境にエージェントを差し込もうとしたときに必ず出てくる摩擦」と一般化し、ソフトウェア領域では新しく感じられたこの問題に、生物学者は長年向き合ってきたと位置付けています。
事例 — DRCのEbola(Bundibugyo virus)アウトブレイクで何が懸かっているか
抽象論ではなく、投稿は2026年5月の現実のアウトブレイクを具体例として置きます。
- 2026年5月14日、DRCのInstitut National de Recherche Biomédicale(INRB Kinshasa)が13検体を解析し、翌15日にうち8件でBundibugyo virusによるエボラ病を確認しました。
- 2026年5月29日時点で、WHOはDRCにおいて1,000件超の確定および疑い症例、200名超の死亡を報告しています。
- 研究者は流行株のほぼ完全なゲノムを取得し、新規のスピルオーバーであることを確認しました。
これら新規ゲノムを公衆衛生の判断に変換するには、3つの問いに答える必要があります。①過去のEbolavirusと比べてどの程度違うのか。②既存の診断薬は依然検出できるのか。③既存の治療薬は引き続き有効か。3問いずれも、新規ゲノムをNCBI VirusやPathoplexusに登録されている歴史的Ebolavirus配列と比較することで答えに近づきますが、その第一歩がWeb UIで手作業フィルタを再現し、結果が完全か正しいかを祈りながらクリックしていくという、自動化に最も向かない作業から始まる構造になっています。
VirBench — 「現実的に効くウイルス取得タスク」を120本集めたベンチマーク
VirBenchは40病原体にまたがる120の現実的なウイルス配列クエリで構成されます。グラウンドトゥルース件数は手作業で検証されており、想定タスクはウイルスサーベイランス、診断アッセイ設計、タンパク質モデル学習用データ構築といった、ラボで実際に発生する形状に揃えられています。
代表的なクエリの例として、投稿は次の文面を挙げています。
TaxID 3052462(Orthoebolavirus zairense、ZEBOV)のウイルス配列をNCBIから取得せよ。条件:宿主はヒト、地理的位置はアフリカ、採取日は2014/01/01以降かつ2014/06/20以前、最小配列長15,200塩基、Nの最大1,900、ラボ継代株は除外する。
これは「フィルタが多重に重なり、宿主種・地域・期間・配列長・曖昧塩基数・派生履歴という6軸を同時に満たすレコードを揃えに行く」典型的な現場クエリです。
| 評価軸 | 設計 |
|---|---|
| 対象タスク | 設計NCBI Virusからのウイルス配列取得(REST / Datasets / E-utilitiesの組み合わせが必要) |
| クエリ数 | 設計120(40病原体) |
| 想定ユースケース | 設計サーベイランス、診断アッセイ設計、タンパク質モデル学習データ構築 |
| 評価対象システム | 設計Claude Sonnet 4 / Claude Opus 4.7 / Biomni OSS / Edison Analysis / GPT-5.2-pro / GPT-5.5 |
| 再現性測定 | 設計同一プロンプトを複数回実行し回答ばらつきも記録 |
なお投稿は脚注で、評価に使ったClaudeモデルがClaude Sonnet 4までである理由を「より新しいモデルにはバイオセーフティ関連のアクセス制限がかかっており、本評価では使用できなかったため、評価で利用可能だった最新の公開モデルがClaude Sonnet 4だった」と説明しています。新しいモデルが評価不能だったことそのものは、生物学領域のエージェント設計でセキュリティとリリース戦略の関係を考える材料になります。
単体性能の限界 — Sonnet 4の同一プロンプト3回が106・15・5件
投稿はSonnet 4による具体的な失敗例を、エージェントの「もっともらしく見える答え」がいかに危ういかを示すために提示しています。
先に挙げた2014年Ebolavirus流行クエリ(想定266件)に対し、Sonnet 4は実行ごとに以下の出力を返しました。
| 実行回 | 取得件数 | 想定との差 |
|---|---|---|
| 1回目 | 取得件数106件 | 想定との差160件不足 |
| 2回目 | 取得件数15件 | 想定との差251件不足 |
| 3回目 | 取得件数5件 | 想定との差261件不足 |
3つのデータセットをそれぞれ系統樹解析(Delphyを利用)に流し込むと、下流の生物学的結論まで揺らぎます。手作業で取得した参照データセットでは最も近い共通祖先(TMRCA)が2014年1月に推定され、過去報告(95% HPD区間:1月27日〜3月14日)と整合しました。一方Sonnet 4の3回はいずれも結論を揺らがせました。2回目(15件)と3回目(5件)は系統樹が目に見えて不完全で、うち一方はTMRCAを1922年まで遡らせています。これに対し1回目(106件)は表面的にはもっともらしく見えるものの、ギニアの配列を回収できておらず、TMRCAを2014年4月にずらして流行のタイミングを誤らせる結果になりました。
治療薬の評価でも同様で、Ebolavirus糖タンパク質配列を取得してmaftivimabとMBP134(WHO優先治療候補)のエピトープ周辺の変異を分析させたところ、Sonnet 4は1回目では手作業に近い結果を出したものの、2回目では変異残基の大半を見落とし、3回目では別の残基集合を強調し、3回それぞれで標的領域の変動性に対する印象が大きく異なる結果になりました。
サーベイランスのような領域では「事実上100%が必要なバー」が要求されるため、91.3%という最高スコアでも単体運用にはまだ足りない、というのが投稿の見立てです。
gget virus — NCBIと共同で作った決定論的な取得層
gget virusは、NCBI Virusの「Web UIにしか存在しないフィルタ挙動」をプログラム的に再現するPythonパッケージとして開発されました。NCBIの研究者と共同で設計され、内部では3系統のAPIを使い分けます。
| API | 役割 |
|---|---|
| REST API | 役割基本検索とメタデータ取得 |
| Datasets API | 役割バッチ取得と大規模ダウンロード |
| E-utilities | 役割補助情報の参照と識別子の正規化 |
gget virusは「どのフィルタはAPIで通せて、どれはローカルで再評価する必要があるか」を内部で判断します。SARS-CoV-2やInfluenza Aのような巨大結果セットに対するバッチ取得も、途中で打ち切られないよう取り回します。さらに、特定のウイルスタンパク質が含まれているかなど追加情報が別データベースにあるケースでは、GenBankレコードを取得して必要なフィールドだけを残しつつ、最終出力には根拠となるGenBank情報を保持します。出力は人と機械の双方が読める標準形式で、どの工程でどんなフィルタが効いたかを後追いできるログ付きです。
導入後のVirBench精度は劇的に変化しました。
| 評価対象 | gget virusなし | gget virusあり |
|---|---|---|
| Claude Sonnet 4 / Opus 4.7 / Biomni OSS / Edison Analysis / GPT-5.2-pro / GPT-5.5 | gget virusなし16.9〜91.3%(モデル差大) | gget virusあり全モデルで90%超 |
| 最高スコア | gget virusなし91.3% | gget virusあり99.7%(GPT-5.5) |
| ばらつき(再現性) | gget virusなし大(例:266件想定で106・15・5件) | gget virusありほぼ解消 |
モデル差がほぼ消えたことは、運用上の含意としても大きいポイントです。投稿は「最新で最も高価なモデルや、特定データベースに強いモデルを選ぶスキル」をユーザーに求めなくて済む状態に近づくため、より安価なモデルとツールを組み合わせる構成で広いアクセスを担保できる、と整理しています。
context engines — 「エージェントが歩ける生物学インフラ」という構想
gget virusは「context engines」と呼ばれる広い取り組みのひとつとして紹介されています。投稿が併記する関連例は次のとおりです。
- ToolUniverse
- Edison ScientificのRobin
- Biomni
- その他の生物医学エージェント群
これらに共通する考え方は、推論はモデルに任せつつ、その下にある「遺伝子識別子、スキーマ、取得ロジック、座標系、メタデータ規約、データアクセスパス」の層は「退屈なほど信頼できる(決定論的な)」状態に揃えるという役割分担です。これはEffective context engineering for AI agentsで繰り返し主張されてきた「コンテキストの編集こそがエージェントの性能を決める」という工学方針と同じ系列の議論で、自然言語タスクから科学領域へ拡張した形と読めます。
編集視点 — モデル進化線と「ハーネス不要」の境界線
投稿の終盤は、面白い自己批判を含みます。「もしモデル性能曲線をこのまま外挿すれば、gget virusのようなツールの恩恵がゼロに近づく未来は容易に想像できる。エージェント単体で乱雑なポータルを乗りこなし、識別子の食い違いを解消し、ページングや失敗からの回復まで自前でこなせるようになるかもしれない」と書いた直後に、それでも決定論層を残す理由を3点に整理しています。
| 残す理由 | 中身 |
|---|---|
| コスト | 中身高性能モデルを毎回呼び出すのは現場ワークフローでは高い |
| レイテンシ | 中身既知の取得は決定論層で即時に返した方が速い |
| 監査可能性 | 中身何が・どう取られたかをログで再現できる方が科学的に検証しやすい |
「賢いモデルがあればすべて解ける」のではなく、賢いモデルとそれを支える退屈で堅いインフラの両方を設計する、というのがここでの編集解釈です。Anthropic自身もこの構想を「もしハーネスが将来不要になっても、生物学データベースは『エージェントをスケールしたユーザーとして想定する』設計を続けるべき」と締めくくっており、議論の重心はモデルそのものよりインフラ側に置かれていると読めます。
サーベイランスから創薬、生物学モデリングまでエージェントを科学発見に役立てたいのであれば、人間と同じくらい確実にエージェントが歩ける生物学データインフラを作る必要がある、というのが今回の投稿の中心命題です。
まとめ — 誰がこの投稿を読むべきか
- 計算生物学・バイオインフォの実務者 — VirBenchの設計と、Sonnet 4が同一プロンプトで106・15・5件と返した事例は、自分のパイプラインで決定論層をどこに置くかを設計し直す材料になります。
- 科学エージェント / 研究エージェントのプロダクトを作る開発者 — Biomni / Edison Analysis / Robin / ToolUniverseと並ぶ位置付けで紹介されているので、フロンティアモデル単体ではなく「決定論的取得層 + モデル」の構成が現実的な解になりつつあることを確認しておく価値があります。
- 公衆衛生 / アウトブレイク対応に関わる方 — Bundibugyo virusの2026年DRC流行が引用された通り、配列取得の精度はTMRCA推定や抗体エピトープ変異の評価といった臨床判断に直結する話題です。
- Anthropicの科学領域戦略を追う読者 — 化学領域の第一報やAnthropic Instituteの研究アジェンダ、Project Glasswingの初期アップデートと並べて読むと、Anthropicが「Claudeを各専門領域の同僚にする」方向に何を積んでいるかが立体的に見えてきます。
関連する記事
Anthropic をもっと見る →Claude Opus 4.7がNMR予測でChemDrawとMestReNovaに並ぶ — 化学領域第1報
Claude商用利用の可否・生成物の権利・データ学習のオプトアウトをプラン別に確認する
Anthropicとは — Claude開発元の企業概要・経営陣・資金調達・日本展開
Anthropicが語る「Claudeを封じ込める」3パターン — サンドボックスとVMの隔離設計
Anthropicのマルチエージェント研究システム — Claude Researchを支える分業設計と9割向上の内訳
Teaching Claude why — Anthropicが「行動」より「理由」を教えるアラインメント訓練の中身