# 忘れることで発見をスケールさせる：Shangyin Tan 氏と語る Weaviate Podcast #149

- 番組: [Weaviate Podcast](https://ai-curator.jp/podcasts/shows/cmv8ukqps000871106w428xh5)（Weaviate）
- 元のタイトル: Scaling Discovery with Shangyin Tan - Weaviate Podcast #149!
- 配信日: 2026年11月2日
- 長さ: 57分
- 要約作成日: 2026年11月3日
- トピック: [#LLM](https://ai-curator.jp/topics/LLM) [#GEPA](https://ai-curator.jp/topics/GEPA) [#autoresearch](https://ai-curator.jp/topics/autoresearch) [#マルチエージェント](https://ai-curator.jp/topics/%E3%83%9E%E3%83%AB%E3%83%81%E3%82%A8%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%B3%E3%83%88) [#コンテキスト管理](https://ai-curator.jp/topics/%E3%82%B3%E3%83%B3%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88%E7%AE%A1%E7%90%86) [#ハーネス設計](https://ai-curator.jp/topics/%E3%83%8F%E3%83%BC%E3%83%8D%E3%82%B9%E8%A8%AD%E8%A8%88)
- URL: https://ai-curator.jp/podcasts/cmvzei8bl00002m126pfauc7t

## 要約

UC Berkeley の博士課程学生 Shangyin Tan 氏が、論文「Scaling Discovery Requires Forgetting」を題材に、長時間動かす AI オプティマイザが停滞する理由とその打開策を語った回。GEPA や Optimize Anything の枠組みを前提に、最良候補だけを新しいオプティマイザに渡して文脈を忘れさせると、どのバックエンドでも停滞が解消されたという。さらに Git の diff だけを共有するマルチエージェント構成、評価コストや指標定義という本番運用の壁、「frontier モデルは十分賢く、課題はハーネス設計」という見方にも触れた。

## ポイント

- GEPA は LLM を提案者としてプロンプトを最適化する手法で、後継の Optimize Anything はコード、GPU カーネル、エージェントハーネスなどテキストで表せる対象に拡張される。
- 問題は汎化が必要なもの（プロンプトやハーネス）、単一問題の最適化（カーネルなど）、その中間の複数問題最適化の3種類に分けられるという。
- GEPA、autoresearch 型、Meta Harness のどれでも約2時間で伸びが止まったが、最良候補のみを新しいオプティマイザに渡すと毎回停滞が解けたと述べている。
- セッションが長いほど思考トークンが減り、編集行数が縮み、数値調整ばかりになる。あるモデルは「実用上の限界に達した」と言った直後に改善を見つけることを繰り返した。
- チームでは他エージェントのコードではなく commit の diff だけを読ませることで、弱いエージェントが多様性を保ちつつ他者のアイデアを取り込める。
- 研究と本番の最大の隔たりは、高コストな評価や定義しにくい指標（上級エンジニアの承認など）にあるという見方を示した。

## 章立て

- [00:00] **発見とは何か：GEPAと Optimize Anything** — GEPA を出発点に、最適化の過程でできる候補の木を「発見」の構造と捉える考え方を説明している。
- [03:12] **プロンプト最適化とコード最適化の違い** — 汎化が要る問題、単一問題最適化、その中間という3分類と、評価コストの違いを議論している。
- [08:29] **長時間最適化の停滞と「忘れる」手法** — 複数バックエンドで共通して起きる停滞と、最良候補だけを引き継ぐと解消する発見を紹介している。
- [12:50] **エージェントチームとGit diffによる通信** — ワークスペースを開放し commit の diff だけを読ませる、単純なチーム設計の狙いと効果を語っている。
- [22:39] **Pareto frontier、ルーティング、JITデータベース** — 多様性維持の道具としての Pareto frontier や、入力別ハーネスへのルーティング、実行時コード生成の是非を議論している。
- [37:06] **評価の壁と本番運用のギャップ** — 指標が定義しにくい、または評価が高価という課題が、研究と本番の最大の差だと述べている。
- [40:10] **忘却の実証とidea basin** — 思考トークンや編集行数の減少、限界宣言の例を示し、Fork and Flush の idea basin や最良候補の情報量にも触れている。
- [55:00] **mismanaged genius という展望** — frontier モデルは既に十分賢く、重要なのはそれを邪魔しないハーネス作りだという結論で締めている。

## 解説記事

UC Berkeley の博士課程学生 Shangyin Tan 氏が Weaviate Podcast に出演し、論文「Scaling Discovery Requires Forgetting」の内容を語った。長く走らせるほど停滞する AI オプティマイザを、どうすれば再び伸ばせるのか。その答えが、タイトルにある「忘れること」である。

#### 「発見」の定義と3種類の問題

Tan 氏の言う発見は、プロンプトオプティマイザ GEPA に由来する。GEPA は LLM を提案者として使い、プロンプトを改良していく手法だ。最適化が進むと、各候補が親候補に依存する木ができる。氏はこの木をテキスト成果物の発見の構造と見なしている。続く Optimize Anything は、同じ発想をコード、GPU カーネル、エージェントハーネスへ広げたものだという。

氏は対象を3種類に分けている。1つ目はプロンプトやハーネスのように、未知の入力でも動く汎化が必要なもの。最適化時に見られるのはデータ分布の一部だけだからだ。2つ目は特定 GPU 上の特定カーネルのような単一問題で、最適化中のスコアがそのまま本番のスコアになる。3つ目はその中間で、たとえば100個のカーネルをまとめて扱うため、カーネルを生成するプロンプトを最適化するような場合である。

#### 停滞と「忘れる」トリック

Optimize Anything を共通のフロントエンドとして、GEPA、autoresearch 型のエージェント、Meta Harness をバックエンドとして動かしたところ、どれも2時間ほどで伸びが止まったという。そこで、それまでの最良候補だけを別のオプティマイザに渡したところ、再び上昇した。当初は別のオプティマイザへの切り替えが効いたと考えたが、実際に効いていたのは他の文脈をすべて捨てたことだったと氏は述べている。ここでの「忘れる」とは、停滞した時点で最良候補以外の文脈を渡さない、いわばコンテキスト管理の工夫を指す。

#### 長いセッションで何が起きるか

氏が示した観察は具体的だ。セッションが長くなると、1ターンあたりの思考トークンが減る。編集行数も、最初の100行程度から数行へ縮む。その数行も数値の書き換えが中心になり、新しいアルゴリズムを試さなくなる。ある DeepSeek 系モデルは、数十万トークンの時点で「実用上の限界に達した」と繰り返し述べた。ところが「続けて」と促すと改善案を出し、実際にスコアが上がった。その直後にまた限界を宣言したという。氏はこれを、文脈に積み上がった失敗や諦めの記述がモデルの意欲を削ぐ現象と解釈している。

単なる要約による圧縮では不十分かという問いに対し、氏は、文脈に既出のアイデアがあるとモデルは同じ方向へ引きずられると説明した。同時期の研究 Fork and Flush が提案する idea basin（同じ谷にアイデアが集まる現象）の考え方も、この分析と補完的だと紹介している。また最良候補は複数の反復で得たアイデアの合成物なので、履歴を失うわけではないとも主張している。ただし、要約より優れるという比較実験は多くないとも認めている。

#### チームと多様性

マルチエージェントの設計では、直接のメッセージ交換はトークンを浪費しがちだとして採用せず、各エージェントのワークスペースを開放した。ただし他者のコードを丸ごと読ませると全員が同じコードに収束し、並列サンプリングと変わらなくなる。そこで読めるのは commit の diff だけにした。diff は多くの場合アイデアやアルゴリズムの単位に対応するので、スコアの低いエージェントが他者の工夫を自分のコードに取り込める。チームは上昇を速め、忘却は停滞を防ぐ。両方を組み合わせれば強い autoresearch ハーネスになる、というのが氏の見立てだ。

GEPA の Pareto frontier も多様性の道具として位置づけられた。あるプロンプトは問題1〜3を、別のプロンプトは4〜6を解く場合、どちらも進化の土台として価値がある。ホストの Connor 氏は、入力ごとに専用ハーネスへルーティングする案を挙げた。氏も、本番分布に合わせた過学習は恐れる必要がないと応じている。

#### 本番との距離とハーネスの重要性

議論では just-in-time データベースにも触れた。氏は、エンジン全体を入力に応じて即時生成するのではなく、傾向を見ながらバックグラウンドで新しい候補を作り、十分成熟した時点で差し替える形を想定している。

研究と本番の最大の隔たりとして氏が挙げたのは評価である。研究では10分で測れる明確な指標を選べるが、現実には評価が高価だったり、「上級エンジニアの承認」のように指標自体を定義しにくかったりする。現在のコーディングエージェントはヒルクライムが非常に得意なので、指標を作れる領域が増えるほど最適化できる範囲も広がる、と述べている。

#### まとめ

本回の中心は、モデルの能力不足ではなく、すべてを覚えているハーネスが進歩を妨げているという見方である。氏の関心は「mismanaged genius（うまく扱われていない天才）」、つまり frontier モデルの力を引き出す仕組み作りにある。日本の開発者にとっても、長時間走らせるエージェントで文脈を保持し続けるべきかを見直す材料になる。コンテキストをリセットして最良成果物だけを引き継ぐ運用や、diff 単位の情報共有は、すぐ試せる設計案だろう。一方で、実験は主にアルゴリズムやカーネルの最適化が中心で、他の領域での効果は今後の検証課題として残る。

> この要約・解説記事は、元の音声の文字起こしをもとに AI（Claude）が日本語で作成したものです。出典: Weaviate Podcast「Scaling Discovery with Shangyin Tan - Weaviate Podcast #149!」