生物学データには機械インターフェースが欠けており、加工具層を導入することでAIの精度を大幅に向上させることができます。記事執筆者、出典：新智元
【導読】トップレベルのAIコーディングは急速に進化しているが、生物学の分野では頻繁に失敗する。これはモデルが十分に賢くないからではなく、科学データベースがいまだに人間のマウスクリックのためにのみ設計されているからである。
最強のモデルが、最もあってはならない場所で転んだ：数えることに？
最近、Anthropicは「生物学的エージェントのための道を切り開く（Paving the way for agents in biology）」というタイトルの科学ブログを公開し、その中で示された一連の数字が背筋を凍らせた。
https://www.anthropic.com/research/agents-in-biology
研究者は、現在最も強力な複数の科研エージェント（Claude、GPT、Biomni、Edison Analysis）に、NCBI Virusデータベースから条件に合致するウイルス配列が何本あるか正確に数えるという、難しくないように見えるタスクを課した。
結果、どれも安定して正解できませんでした。
さらに驚くべきことに、同じ問題、同じモデル、同じプロンプトで3回質問すると、答えが数十倍も異なることがある。
Claude Sonnet 4はエボラウイルスの配列を検索し、最初に106件、次に15件、その後5件を返した。正しい答えは266件である。AIが生物学を扱うのは本当にできないのでしょうか？
その背後には、心を抉る真実が隠されている。科学の分野では、エージェントの本当の弱点は推論ではなく、データを正確に抽出するための安定し、再現可能で、機械が実行できる道がそもそも存在しないことである。
専用の検索層がない場合、各システムの平均精度は16.9%から91.3%まで幅広く散らばっており、新しいモデルが改善されたとしても、残存するエラーは依然として致命的である。なぜなら、このようなタスクの合格ラインは実際には100%だからである。
1つの記録が欠けているだけで、診断キットがすべての流行株をカバーしているように見えたり、感染拡大の発生時期が数週間も誤って推定されたりする可能性がある。
では、問題はどこにありますか？
馬車のために作られた街では、自動車は走れない
Anthropicは、エージェントを使って生物データベースを操作することは、自動車が存在する前に建設された古い街を車で走り抜けるようなものだと、非常に具体的な比喩を示した。
街路は洗練され、丁寧に設計されているが、すべて馬車用に設計された狭い路地と急カーブばかりだ。散在するデータベース、多様なファイル形式、一回限りの検索スクリプトは、この古い街の一部である。交通標識を設置したり、駐車場をいくつか作ったり、道路を数本広げることはできるが、都市の基本的なレイアウトは、元々自動車のために設計されていない。
ソフトウェアの世界はその逆です。それは車のために建てられた新都市です：平らなアスファルトの道路、明確な車線、標準化された信号灯。バージョン管理、文書化されたAPI、パッケージマネージャー——これら一連のシステムは、起点から終点へ高速で到達できるように、「車」（すなわちエージェント）のために最初から整備されています。
したがって、コードのエージェントは急激に進化する一方で、生物のエージェントはその場でぐるぐる回っている。
ソフトウェア分野では、構造化されたデジタルワークフローと信頼できるインターフェースが提供され、GitHubのイシューからパッチを生成し、テストを実行し、即座に検証できる。一方、生物学分野では、脆弱で異質であり、特定のプロセスに依存するインフラが与えられ、単純で検証可能かつ意味のある報酬信号はほとんど存在しない。
NCBI Virusに具体的に当てはめると、それは本質的にウェブポータルです。ウェブページ上で宿主をヒト、サンプリング地をアフリカ、配列長をある値以上、実験室での伝代サンプルを除外という条件をチェックすると、サイトのバックエンドがこれらの条件を底層の複数のデータベース（GenBank、RefSeq、INSDCシステム）に対するクエリに変換し、結果をフィルタリングして表示します。
NCBIウイルスポータルのトップページ：ウイルス配列を検索するには、ウェブページ上でオプションを選択し、キーワードを入力し、フィルターをクリックする必要があり、この一連のインタラクションは人間向けに設計されており、機械が直接再利用することは困難です。
その大量フィルタリングロジックは、ウェブページのレイヤーに記述されており、クリーンなプログラムインターフェースとして公開されていません。
人間のウイルス学者にとっては、これは単にブラウザで数回クリックするだけの話だ。しかし、機械（エージェント）にとっては、これはまさに災難だ。エージェントが直接呼び出せるのは、底層の数個の原始API（REST、Datasets、E-utilities）だけであり、これらのAPIはウェブページとまったく同じフィルタリングセマンティクスを公開していないからだ。
具体的な例を挙げると：
ウェブページ上の「サンプリング地がアフリカ」はチェックボックスであり、背後では数十カ国にわたるメタデータフィールドを整備し、表記が不統一なレコードを処理する必要がある。「表面糖蛋白を含む」という条件は、配列のみでは判断できず、各レコードの遺伝子／タンパク質アノテーションをGenBankから取得して比較する必要がある。
これらの隠れたステップは、ウェブサイトが代わりに処理しますが、元のAPIは処理しません。
そのためエージェントは自ら「推測」してこのロジックを再構成するしかない。どこかを抜けたら計算が不足する（アフリカのある国のシーケンスを見落とす）、間違えたら過剰に計算する（フィルタ条件を誤解する）。
これは、Sonnet 4が同じテーマで106、15、5に回答する際の根本的な原因である：毎回再構築されるフィルタリングロジックが完全に一致しないからである。
gget virusが解決しようとしているのは、まさにこのことだ：ウェブページインターフェースに隠されたフィルタリング動作を、安定し、再現可能で、機械が直接呼び出せるプログラム化されたシステムとして再実装し、エージェントが毎回推測する必要がないようにする。
シーケンスに誤りがあり、パンデミックの発生時期が数週間ずれている
「数え間違いが些細なことだ」と思っているなら、以下の現場があなたの見方を変えるでしょう。
2026年5月、コンゴ民主共和国でバンドibu型エボラウイルスの流行が発生した。5月14日、キンシャサのINRBは13件の血液サンプルを分析し、翌日そのうち8例を確認した。5月29日までに、WHOは確認病例と疑い病例が1000件を超え、死亡者が200人以上であると報告した。
研究者は、このウイルスが過去のものとどれほど異なるのか、現在の診断法で検出できるのか、現在の治療法が効果があるのか、という三つの生死を左右する問題に直面している。
これらすべての回答について、新しいゲノムとNCBI Virus内の過去のエボラゲノムを一つずつ比較しなければならない。この分析の最初のステップは、まさにウェブページを手動でクリックし、長大な複雑なフィルタ条件を手動で再現して、取得されたデータセットが完全で正しいことを願うことである。
研究者向けに、以前のエボラ検索結果を使用してSonnet 4にデータを取得させ、系統樹を構築し、最近共通祖先の時期（TMRCA）を推定してください。これは感染症の発生時期を推定する上で重要な指標です。
人工精校されたデータセットでは、TMRCAは2014年1月とされ、過去の報告と一致しています。
一方、Sonnet 4が生成した3つのデータセットのうち、2つは明らかに欠損している。そのうち1つは、推定された起源時間を2014年から1922年に遡らせ、無理に90年以上を追加した。残りの1つは見た目は完璧だが、ギニアの系列を見落とし、起源時間を2014年4月に静かに変更し、タイムラインが書き換えられた。
ザイール型エボラの系統樹：左上は手動で精査されたデータ、Run 1～3はSonnet 4の検索結果。赤い破線はTMRCAを示し、灰色は国情報の欠落または誤りを表す。
抗体療法の分析も同様です。研究者たちは、マフティビマブとMBP134という2つのエボラ抗体療法が標的とする部位に、過去に変異が発生していたかどうかを確認し、その療法がウイルスの進化に追いつけるかどうかを判断しようとしました。その結果、Sonnet 4は3回の実行でそれぞれ全く異なる変異のパターンを示しました。
エボラウイルス（ザイール型）の糖蛋白の変異分布。赤が濃いほど頻度が高い。球体はmaftivimabおよびMBP134抗体の結合部位を示す。最も左は手動で精査されたデータであり、Sonnet 4の3回の検索（Run 1～3）の結果はそれぞれ異なる。
失敗のパターンは明確です：結果セットを拡大中に途中で停止すると、数が漏れます；フィルター条件を間違えると、数が過剰になります。インフルエンザA、HIV-1などの記録は膨大なウイルスを含み、バイアスが最大です。フィルター条件が3〜4つ以上並列になると、パフォーマンスが即座に崩壊します。
間違っているのに正々堂々と主張するのは、科学研究で最も恐ろしい誤りである。
古い街に機械専用のトンネルを掘る
では、どのように修理しますか？
AnthropicとNCBIの研究者が協力して、gget virusというものを開発しました。
それはまた一つの派手な「AIプラグイン」ではなく、決定論的検索レイヤーです。本質的に、NCBI Virusのウェブインターフェースにあるフィルタリング動作を、再現可能なプログラム化システムに変換しています。
技術的には、REST、Datasets、E-utilitiesという複数の基盤システムを統合し、どのフィルタリングをAPIで処理し、どのフィルタリングをローカルで検証するかを自動的に判断します。バッチでのデータ取得を処理し、大規模な結果セットが途中で切断されることなく、完全に取得されるようにします。
INSDCシステム（NCBI、ENA、DDBJ）からウイルスの核酸配列と関連メタデータをダウンロードし、FASTA、CSV、JSONLなどの人間と機械が読み取れる形式で出力します。また、結果がどのように計算されたかを詳細なログで説明します。高頻度のクエリに対しては、データ転送量を98％以上圧縮します。
効果が即座に現れます。
ggetウイルスに接続後、すべてのテストシステムの精度が90.0％以上に向上し、GPT-5.5は99.7％に達した。実行間のランダムな揺らぎはほぼ消失し、安定性は0.92から1.00に向上した。
最も素晴らしいのは、モデル間の差が大きく縮小されたことです。
VirBenchベンチマークにおける各エージェントの検索精度：gget virus（濃色）を接続後、すべて90%を超え、最右はgget virus単体での実行。
確定性ツール層を追加すると、どのモデルを使用するかはそれほど重要ではありません。
这才是真正值得注意的地方。
信頼できるデータセットの構築は、最新で最高価なモデルを購入できるかどうかや、どのモデルがどのデータベースに最適かを知っているかどうかに左右されるべきではありません。適切なツールと安価なモデルでも、安定して実現できます。
もう一つ興味深い細部があります。360回の実行の中で、GPT-5.5は任何のヒントもなく、自らgget virusを見つけ出し使用しました。そのときが、その問題で唯一正解した回でした。
ツールの価値は、モデル自身が脚で投票した。
真の勝負手は、モデルから基盤へと移る
もう少し視野を広げてみましょう。この出来事はウイルスについてだけの話ではありません。
同じ摩擦は、「人間のために設計され、エージェントのために設計されていない」すべての環境に現れる。
数か月前、KarpathyはAI時代のソフトウェアについて語り、自分自身がvibe codingで小さなウェブアプリを作成した際、本番公開（ログイン、支払い、デプロイ）に整整1週間をブラウザ内でクリックし続けることに費やしたと不満を述べた。彼の結論は、「コードを書くのが最も簡単な部分だ。」
Karpathyのスピーチスライド「Docs for people」：Vercel、Clerkなどのサービスの設定ドキュメントは、すべて「ここをクリックして、あそこに入力する」ように人間向けに設計されており、LLMは直接呼び出せない。
カーパスキーの不満を聞いた生物学者たちは、おそらく共感するだろう。この苦痛は、彼らもすでに長年我慢してきたものかもしれない。
gget virusは孤立した事例ではなく、同様に「コンテキストエンジン」を構築しているのは、ToolUniverse、Robin、Biomniなどの複数のバイオメディカルエージェントである。
課題は：決定性をどの層に置き、どのように構築するかである。
もちろん、誰かはこう尋ねるでしょう：モデルの進歩がこれほど速いなら、もしいずれエージェントが自ら混乱のポータルを越え、IDを整列させ、正しいページめくりを行い、エラーを自己修復できるほど強大になった場合、gget virusのような「足場」は一瞬でゼロになるのではないか？
可能性はあります。しかしAnthropicの答えは、エージェントが実行できても、毎回最初から再発明する必要はないということです。
この混乱したデータ取得プロセスを自力で乗り越えることができるモデルは、コストが高すぎたり、速度が遅すぎたり、監査が難しかったり、信頼しにくかったりして、日常的な研究を支えるには不十分です。
さらに、足場がいずれ時代遅れになるとしても、生物データベースへの教訓は依然として有効である：今から、エージェントをスケーラブルなユーザーとして扱い、最初から大規模な呼び出しに備えて構築すべきである。
このコンテストの表面では、どのモデルがより賢いかが競われている。その下層では、どの基盤が機械の走行に適しているかが競われている。
モデルが仮説を生成し、実験を設計する際は自由奔放であってほしい。しかしその下層、すなわち遺伝子識別子、データスキーマ、検索ロジック、座標系、メタデータの約束事は、絶対に信頼できるほど「退屈」でなければならない。
モデルの曲線はまだ上昇しています。
しかし、このラウンドの真の鍵は、雲上の巨大モデルではなく、誰も修復したがらないが勝敗を左右する下層のデータインフラにあるかもしれない。