0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

「見れば分かる」のに、10回とも見つけられなかった——Claudeの再探索失敗から考えるAIエージェントの観測設計

0
Posted at

この記事で扱う3つの観測事実

Anthropicが2026年9月に公開した論文 『Autonomous AI agents discover reverse transcriptases with tandem repeat arrays』 から、以下の3点を出発点にします。

  • 事実1:ClaudeエージェントがCRISPR様の反復配列を持つ新しい酵素システム(ART)を発見した
  • 事実2:しかし同じ発見キャンペーンを10回追加実行したところ、1回も再発見できなかった
  • 事実3:別途組んだ固定入力ベンチマークでは、DNA配列を直接contextに入れれば上位モデルは少なくとも90%の試行で反復配列を認識した。ところがファイル+ツール環境で自律探索させると、認識率は最低32%まで落ちた

本記事の焦点はART自体の生物学的新規性ではありません。「発見できたのに再現できなかった」という失敗パターンが、AIエージェント設計にとって何を意味するかを、実測データから読みます。

結論を先に。

モデルに能力があることと、その能力に必要な入力が届くことは、別問題である。

以下、この命題を6段で分解します。


1. ClaudeがARTを発見した経緯

まずART発見の経緯を、論文本文と補足図2から確認できる範囲で見ていきます。

Claudeエージェント群は、逆転写酵素(RT)の新しいシステムを探すという研究指示(何を調べるか・どこを目標にするかを定める上位指示) を受けて、約19億件のタンパク質クラスタを走査しました。約20万件のRTを抽出し、9つのクラスに分類、その近傍遺伝子から3,564のパートナー候補ファミリーを絞り込み、最終的に17ファミリーが精査対象になりました。

この過程で、あるworker (実際の分析作業を担当するClaudeエージェント) が特定のRTに隣接するファージポリメラーゼ遺伝子をパートナー候補として調べましたが、「これはファージ本体の遺伝子であってRTのパートナーではない」として当初のpartner仮説を棄却しました。一方、RT自体は別途調べる価値があるとして追跡調査を提案しています。

その追跡調査でsupervisor (レビュー役のClaudeエージェント) は、「retron型RTなら、その上流にnon-coding RNA(ncRNA)をコードする領域があるはずだ」と考え、RTの上流DNAを次のworkerに確認させました。

これを受けたworkerは、近縁のRTの上流領域を実際に取得して、textとしてcontextへ読み込みました。取得直後、workerは I can see by eye a tandem repeat array (配列を見ると、タンデムリピート(似たDNA配列が隣り合って繰り返す構造)が繰り返しているのが分かる) と記録しています(論文Fig. 1E)。約100~180 bp間隔で同じ配列が繰り返されていることに気づき、既知のDNA反復構造に似た何らかの機能的な配列ではないかと推測しました。

ここで重要なのは、最初の研究指示にも、その後の追加調査でworkerに渡された具体的な指示にも、「反復配列を探せ」という内容は含まれていなかったという点です。論文の手法説明では、この点についてセッションログまでさかのぼって確認しています。反復配列に気づく直前の2回のデータ取得の間には別のツール実行はなく、それ以前にも反復配列を解析する処理は行われていません。また、既存の反復配列検出ツールも使用されていませんでした。

つまりworkerは、supervisorの指示に従って上流DNAをcontextへ読み込んだ結果、事前に指定されていなかった特徴である反復配列に気づいたことになります。
専用の反復配列検出ツールに教えられたのではなく、取得したDNA配列そのものを読んで気づいた、ということです。

これが単一実行として観測された発見経路です。


2. 同じ探索を10回追加実行したところ、1回も再発見できなかった

論文は同じ発見キャンペーンを追加で10回実行しています(合計11回試行)。結果は以下のとおりです。

  • 再実行した多くの探索では、ARTに関係する候補までは見つけていた
  • そのうち2回は、ARTの系統を追加で調べるところまで進んでいた
  • それでも、RTの上流DNAを実際に読むところまでは進まず、反復配列は10回すべてで見逃された

論文では、再発見できなかった要因として「RTの広大なタンパク質探索空間」と「harnessの非決定的挙動」の両方を挙げています。そのうえで具体的な観測として、「接近しても上流DNAを読む行動が起きなかった」ことを記述しています。

ここで前節と対比すると、構造が見えてきます。

  • 初回発見の経路では、supervisorの「retron型ncRNAを調べる」という追跡調査が、上流DNAをcontextへ読み込む契機になった
  • 再実行10回では、同じキャンペーン構造を実行したが、この「上流DNAを読む」ステップが発火しなかった

発見経路そのものは説明可能です(補足図2にステップが図示されています)。しかしその経路への再到達が安定していません。説明可能性と再現可能性は別レイヤーの話です。


3. DNAを直接読ませると90%以上で認識できた

論文はこの再現性の低さを追及するため、別途固定入力ベンチマークを組んでいます(Fig. 4)。7つのClaudeモデル×5レベルの入力条件×各100 attempts、合計3,500 attemptsです。

入力レベルは以下のとおりです。

Level 入力形式 認識対象のDNAの位置
1 RTタンパク質配列2本をcontextへ DNAなし
2 対応する2 locusをtextとしてcontextへ context内
3 全96 lociをファイルとして、解析ツール付きで ファイルシステム
4 Level 3に加えて予測構造ファイル ファイルシステム
5 Level 4に加えてweb検索・文献検索 ファイルシステム

結果は次のようになりました。

  • Level 2 (locus DNAを直接contextへ):上位4モデル(Opus 5.5, Mythos 5.1, Mythos 5, Opus 5)は少なくとも90%の試行で反復配列を認識
  • Level 3-5 (ファイル+ツール):同じ上位モデルでも認識率は最低32% (Opus 5, Level 4)まで低下
  • ファイル条件の39%のattemptでは、200 nt以上の連続したDNAを一度もcontextへ取り込まなかった
  • 200 nt以上の連続DNAをcontextへ取り込んだ試行では、各モデルで認識率が16~32ポイント上昇

興味深いのは、ファイル+ツール条件の方が利用可能な情報は多いことです。Level 2では2 lociしか提供されませんが、Level 3-5では全96 lociとツールが利用可能になります。それでも繰り返し構造を持つDNA配列の認識率は低下しました。論文内でも、

more information and tooling inhibited the models' ability to accurately describe the array
(情報や使えるツールが増えるほど、かえって反復配列を正確に認識しにくくなった)

と明記しています。少なくとも繰り返し構造を持つDNA配列の認識については、「情報があるか」だけでなく、「必要な情報を実際にcontextへ取り込めるか」が大きく効いていました。

補足として、論文Fig. 5はモデルが内部で何に反応していたかを解析する観点からも同じ方向を支持します。Mythos 5の内部には、反復配列を読んだ際に反応する信号が観測されています。ただしこの信号はDNA専用ではなく、文字と数字からなるランダム文字列の反復にも反応する汎用パターンです(論文自身が "neither is specific to DNA" と明記)。つまり、モデルには反復配列に気づく能力がありますが、それが発火するには反復配列を含む配列がcontextへ入る必要がある、という同じ構造がモデル内部にも見えています。


4. モデルが認識できても、必要なデータを見なければ始まらない

ここまでの内容を整理します。

Recognition (認識)能力:上位モデルは、反復配列をcontextで見せられれば90%以上の試行で認識できます。内部信号レベルでも反応します。この能力は既に存在しています。

Observation Selection (観測選択):自律探索環境では、そもそも反復配列を含むDNAをcontextへ読み込むかどうかが安定しません。10回再実行で0回、ファイル条件の39%のattemptで200 nt以上の連続DNAを一度もcontextへ取り込みませんでした。

少なくとも今回の結果では、Recognition能力だけでは失敗を説明できません。大きな差が出ているのは、その能力を使うためのDNAを実際にcontextへ取り込めたかどうかです。

初回発見の経路では、supervisorの「retron型ncRNAをチェックせよ」という追跡調査が、上流DNAをcontextへ読み込む契機になりました。この読み込みが発生したから、Recognition能力が発火する条件が整いました。

再実行10回では、反復配列を見た上でRecognitionに失敗したわけではありません。Recognitionに必要な上流DNAそのものがcontextへ到達していませんでした。

この構造は、AIエージェント設計における失敗モードとして重要です。単純化すると次のようになります。

データが存在する ≠ そのデータを見る
そのデータを見る ≠ そこから異常に気づく
異常に気づける ≠ 毎回そこまで到達できる

だから、
「モデルができる」と「エージェントができる」は同じではない。

3段のうち、どれか1つでも壊れれば発見は起きません。今回観測されたのは、第1段(データを見るかどうか)が非決定的だったケースです。

本記事では便宜上、この失敗モードを Observation Selection Failure (必要な情報を見に行く判断の失敗) と呼びます(論文の用語ではなく、本記事内での設計上の解釈です)。


5. Memory / Thinking / Executionで分解すると何が壊れたのか

私は普段、システムを Memory / Thinking / Execution の3つの責務で捉えています。今回の失敗を、この分類で並べ直します。

責務 今回確認できたこと
Memory 必要なDNAはDB/ファイルに存在
Thinking: Observation Selection 上流DNAを読む判断が再実行では安定しなかった
Execution 初回ではDNA取得に成功。実行系単独の信頼性は本論文では未評価
Thinking: Recognition locus DNAがcontextに入る条件では上位4モデルが90%以上でarrayを認識

Memoryには必要なDNAが存在していました。初回発見ではDNA取得処理自体も実行できていました。また、DNAがcontextに入れば上位モデルには高いRecognition能力がありました。今回直接観測された大きな差の一つは、その間にある「どの情報をcontextへ取り込むか」というObservation Selectionでした。

ここで一点、細部が重要になります。「Executionが発火しなかった」と言うと実行系の障害のように聞こえますが、そうではありません。本記事の責務分解では、Executionを呼ぶかどうかの判断をThinking側として扱います。今回、Thinkingの中でも「認識」ではなく「観測選択」の部分が非決定的でした。

なお、論文中の実装ではworker、supervisor、curator、editorといった役割分業を持つharnessが組まれています。本記事のMemory / Thinking / Executionはこの実装構造をそのまま写したものではなく、失敗の責務所在を分析するための抽象です。

これは、モデルの評価軸を1本にすると見落とす失敗モードです。「repeatを認識できるか」というベンチマークだけを走らせれば、上位モデルは合格します。しかし実運用では、そのエージェント系が自律探索の中で「今、上流DNAを見に行くべきだ」という観測方向へ進むかどうかが結果を決めます。前者と後者は別のベンチマークが必要です。

論文自身、Fixed-input benchmarkを組んだ動機はまさにこれです。自律探索での失敗率が高かったから、能力側と観測側を分離するテストを別途構築しています。


6. AIエージェント設計では「モデル性能」だけ測ってはいけない

論文Discussionの末尾に、以下の記述があります。

“Our results show that agentic harness configurations and model capabilities can dramatically affect research outcomes and successful discovery.
(私たちの結果は、AIエージェントを動かす仕組みの構成とモデル自体の能力の双方が、研究成果や新しい発見の成否を大きく左右し得ることを示しています。)

これは生物学の話ではなく、AIエージェント設計の話としても正しいと考えます。今回の観測を情報システム側へ翻訳するとこうなります。

モデルに能力があることを評価して終わってはいけない。その能力に、必要な入力が本当に届くのかを測らなければならない。

具体的な設計上の含意は以下のとおりです。

  1. Recognition能力とObservation Selection能力は別々に測る。前者は入力を固定した合成タスク、後者はエージェント環境全体を走らせた実測が必要です。片方が高性能でも、もう片方の成功は保証されません。

  2. エージェント実行のうち何回で該当データがcontextへ到達したか、を可視化する。今回の論文が優れているのは、10回の再実行ではsession logまで追跡し、さらに別途組んだfixed-input benchmarkでは「200 nt以上の連続DNAがcontextへ入ったか」まで測定したことです。Recognition率だけを見ていたら、原因は分かりませんでした。

  3. taskの分岐点で「観測方向」を誰が与えるかを明示する。初回発見はsupervisorの追跡調査が上流DNA取得の契機になったから成立しました。この観測契機が再実行時に再現されなければ、Recognition能力があっても使われません。

Jev連載や以前書いた安全境界の記事で扱ってきたテーマは、「モデルが賢いか」ではなく「システムとして壊れないか」でした。今回の論文は、そのテーマに対して非常に良質な実測データを提供しています。

Claudeが新しいRTシステムARTを発見したこと自体より、Anthropic自身が10回の失敗と固定入力ベンチマークまで公表したことの方が、AIエージェント設計にとっては価値があります。成功事例より、成功と失敗の対比が観測されているデータの方が使えるからです。


まとめ

今回の論文が実測データとして示したものは以下のとおりです。

  • locus DNAを直接contextへ入れた条件では、上位モデルは90%以上で反復配列を認識した
  • しかし自律探索環境では、そのRecognition能力に必要な入力が届かないことが起こった(ファイル条件の39%のattemptで200 nt以上の連続DNAを一度もcontextへ取り込まず、10回再実行で0回発見)
  • この乖離はモデル性能だけでは説明できず、Observation Selectionを含むharness側の挙動にも左右される
  • 入力をあらかじめcontextへ与えたRecognitionベンチマークだけでは、この失敗モードは見えない

本記事の主張は次のとおりです。

AIエージェントを設計・運用するとき、「モデルが賢いか」を測るだけでは不十分です。「そのモデルに必要な入力が届くか」を別のベンチマークで測る必要があります。RecognitionとObservation Selectionは別々に評価する必要があり、片方が高性能でももう片方の成功は保証されません。


参考文献

一次資料

公式解説

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?