Back to Blog

iGEM と最近の AI Scientist について

この記事は生成 AI と一緒に書きました。

この投稿は,iGEM・Synthetic biology(合成生物学)・Japan Advent Calendar 2025の 5 日目です。

こんにちは、tax_free です。 今年も iGEM Japan Community で Advent Calendar をやるとのことなので、せっかくなら私が最近興味を持っている AI for Science、特に AI Scientist について書こうと思っています。 ひさしぶりに 1 日目じゃない記事を書きます。

ここ 1 年くらい、「AI が科学者になる」「AI Scientist」みたいな話題をよく見るようになりました。 具体的には Google の AI Co-scientist、SakanaAI の The AI Scientist-v2、FutureHouse の Robin あたりが、代表例として挙げられることが多いと思います。

どれも「論文を要約してくれる便利ツール」というより、

  • 仮説を立てて
  • 実験を計画・実行して
  • 結果を解析して
  • それを踏まえて次の仮説を立てる

という自律的なループを回そうとしていてある程度上手くいっているプロジェクトです。

この記事ではざっくり、

  1. この 1 年くらいの AI for Science + Agent の状況
  2. それをそのまま iGEM に持ち込もうとすると何がつらいか
  3. それでもうまく使うにはどうすればいいか

を、自分なりにまとめてみます。

1. ここ 1 年くらいの AI for Science の状況

なお、この章で紹介する AI Co-scientist / AI Scientist-v2 / Robin / Sparks は、いずれも 2025 年時点では arXiv プレプリントとして公開されている段階で、今後の査読や追試で評価が変わる可能性があります。

1.1 AI for Science と Agent について

「AI for Science」自体は前からあるキーワードですが、2024〜2025 年あたりで変わってきたと感じているのは、単発タスク (翻訳、サマリ、画像解析など) に使う AI から、科学プロセス全体をワークフローとして回す Agent 群に重心が移りつつある点です。

具体的には、

  • 文献を読む Agent
  • 実験案を考える Agent
  • データを解析する Agent
  • それらをまとめて「次に何をするか」を決める supervisor agent

みたいな構成で、複数の Agent が科学プロセスを分担する設計が増えています。

いわゆる self-driving lab 系も、この流れの中にあります。 例えば材料分野では、ロボットと ML とアクティブラーニングを組み合わせて新しい無機材料を自律合成する A-Lab が Nature に載っていて、Google DeepMind の GNoME で理論的に予測された物質から多数の新物質を実際に合成したと報告されています。ただし、A-Lab が本当に「新物質」を見つけたかについては後続研究から批判も出ており、議論が続いています。

タンパク質設計の世界では、multi-agent な AI モデル Sparks が、仮説生成から実験設計・反復実行・レポート作成までを自律で回しながら、ペプチドの長さと構造に依存した新しい力学設計原理を見つけたと主張しています。

こうした「分野ごとの AI Scientist」はかなり増えてきていますが、この記事ではその中でも、汎用 LLM ベースの multi-agent system で「研究者っぽいこと」をさせている 3 つに絞って見てみます。

1.2 Google:AI Co-scientist

Google が 2025 年 2 月に出した AI Co-scientist は、Gemini 2.0 をベースにした multi-agent systemで、「バーチャル共同研究者」という位置づけです。

論文と公式ブログをざっくり読むと、やっていることはだいたいこんな感じです。

  • 研究者が自然言語でゴールや制約を書く
  • Supervisor Agent がタスクを管理し、以下の専門 Agent を動かす
    • Generation Agent: 仮説と研究提案を生成
    • Reflection Agent: 仮説の正確性・新規性・実現可能性をチェック
    • Ranking Agent: トーナメント方式で仮説をランク付け
    • Evolution Agent: 既存の仮説を改善
  • 最終的に研究計画のドラフトを生成してくれる

つまり、「論文サマリ係」ではなく、仮説生成と研究計画立案にかなり踏み込んだ co-scientist です。

代表例としてよく出てくるのが、急性骨髄性白血病 (AML) に対するドラッグリポジショニングと、肝線維化 (liver fibrosis) に対する新規エピジェネティック標的の提案です (専門外なので詳しくは理解してないです)。

  • AML では、AI Co-scientist が候補薬を提案し、in vitro で腫瘍抑制効果が確認された
  • 肝線維化では、新しい治療標的を提案し、ヒト肝オルガノイドで抗線維化作用や肝細胞再生を示すものが見つかった

という流れが報告されています。 さらに抗生物質耐性や細菌進化メカニズムに関する仮説生成なども含めて、「AI が wet 実験と組み合わさって新しい知識を作った」というストーリーになっています。

AI Co-scientist 自体はロボットを動かすわけではなく、「仮説生成 → 文献を踏まえた裏取り → 研究計画のドラフト」といった「頭の部分」を担当し、wet 実験は人間が行う構成です。 重要なのは、AI が仮説を出す → 人間が wet 実験で検証する → その結果を踏まえて AI が次の仮説を出す、というループが回っている点です。「AI がちゃんと新しい仮説を作って、in vitro やオルガノイドレベルの実験では有望だった」という事実は、AI for Science の象徴的な例だと思います。

1.3 SakanaAI:The AI Scientist-v2

SakanaAI の The AI Scientist-v2 は、主に機械学習分野にフォーカスした「AI 研究者」です。

タイトルからして「Workshop-Level Automated Scientific Discovery via Agentic Tree Search」と名乗っていて、

  • 研究アイデアを出す
  • 実験のコードを書く
  • 実験を実行する (主に ML 実験)
  • データを可視化・解析する
  • 論文を書く
  • さらに AI が自分の論文をレビューして直す

という一連のループを、ほぼ全部 AI にやらせるシステムになっています。 コードも SakanaAI/AI-Scientist-v2 で公開されています。

v1 では「人間が用意したコードテンプレートを改変して使う」設計でしたが、v2 ではこれをやめて、

  • agentic tree search でアイデアや実験パスを探索し
  • experiment manager Agent が全体の流れを管理し
  • 図についても Vision-Language Model を使って自動修正する

という、より自立した設計になったと主張しています。

評価としては、

  • AI Scientist-v2 が完全自動生成した 3 本の論文を ICLR 2025 のワークショップに投稿し
  • そのうち 1 本が、人間著者の平均スコアを上回る形で採択ラインを超えた

報告されています

もちろんツッコミどころも多くて、

  • 本当に「新規性」があると言えるのか
  • 評価の設定が妥当か
  • ワークショップ 1 本採択をどこまでブレイクスルーと呼んでいいか

といった点について、メタな議論や再評価記事も出ています。

それでも、「アイデア → 実験 → 解析 → 論文」まで全部 AI がやった論文が、トップ会議ワークショップの査読を通ったという事実自体は、インパクトとしてかなり大きいと思います。 biology というよりは ML の話ですが、「少なくとも dry lab だけなら、full-stack な AI Scientist はここまで来ている」と言ってもよさそうで、iGEMer 的にも無視しにくい存在です。wiki 執筆のような「実験結果をまとめてストーリーを作る」タスクとも関連が深いと思います。

1.4 FutureHouse:Robin

FutureHouse の Robin は、創薬寄りの領域で話題になった multi-agent systemです。 技術的な詳細は Robin の論文 にまとまっています。

以下のような専門 Agent を orchestration し、

  • Crow / Falcon: 文献検索とサマリ生成
  • Owl: 研究ギャップの特定
  • Finch: 実験データ解析 (RNA-seq、フローサイトメトリーなど)
  • Phoenix: 化学実験の計画

といった「知的ステップ」を Agent 同士で回す構成になっています。

ケーススタディとして強く押し出されているのが、dry AMD (ドライ型加齢黄斑変性) に対する新規治療候補の探索です (専門外なので詳しくは理解してないです)。

ざっくりいうと、

  • Robin が dry AMD の病態と既存知見を踏まえて、「網膜色素上皮 (RPE) の貪食を高める」という治療戦略を仮説として提示する
  • 既存薬の中から、その戦略に合いそうな候補として ripasudil (ROCK 阻害薬) などを選ぶ
  • 研究者が in vitro 実験や RNA-seq を行い、RPE の貪食機能向上や関連遺伝子の変化を確認する

という流れで、dry AMD 向けの新しい治療候補を見つけたと報告されています(まだ臨床試験などは行われていない前臨床レベルの検証です)。

Robin 自体はロボットを動かしているわけではありませんが、「仮説 → 実験計画 → データ解釈 → 仮説更新」という「頭のワークフロー」を 1 つの multi-agent systemとしてまとめた例で、「AI Scientist」っぽさがかなり強いプロジェクトだと思います。

2. iGEM への応用と障壁

ここまで見ると、「じゃあ iGEM でも AI Scientist にテーマ決めから実験計画までやってもらえばよくない?」という気持ちになってきます。 ただ、そのまま持ち込もうとすると、いくつか大きな障壁があります。

2.1 実験環境との統合の難しさ

まず、実験環境側の前提がかなり違うという問題があります。

AI Co-scientist や Robin、A-Lab などのプロジェクトは、暗黙の前提として、

  • ちゃんと構造化された実験データとログ
  • 大規模な計算資源や予算、ストレージ
  • 提案された実験を素早く回せるラボ体制

が存在する世界を想定しています。A-Lab のように実験ロボットと ML が密に統合された環境もありますが、AI Co-scientist や Robin は現時点では wet 実験自体は人間のラボで行われています。

一方で、典型的な iGEM チームの環境は、

  • 大学や企業の共用機器を時間でシェアしている
  • 実験手続きは基本手動
  • pipetting robot すらない、もしくは予約が取りにくい

みたいな感じで、「AI が直接ラボを統括する」世界とはだいぶ距離があります。

さらに、AI Co-scientist や Robin がうまく機能している例では、「提案された実験をそれなりのスピードと品質で回せるラボ」が前提になっています。フルタイムの研究者やテクニシャンがいて、ロボットや共用設備も潤沢にあり、PDCA のループが物理的にも速い環境です。

iGEM チームだと、

  • メンバーは講義やアルバイトの合間にラボに来る
  • 実験に慣れていなくて失敗率も高い
  • 使える時間スロットも限られている

という状況が普通なので、「AI がどんどん実験案を出すけど、人間側の実験サイクルが遅すぎて全然検証できない」というデッドロックに近い状態になりがちです。たとえ頭脳の部分だけ理論上は到達可能だとしても、そこにお金と時間を注ぎ込んでも見合うパフォーマンスを出せるとは限りません。

しかも現実には、大規模モデルをフルで回すと単純に API 代が重く、学生チームの予算感からすると「毎日 Co-scientist と数時間ディスカッションする」みたいな使い方はかなり厳しいと思います。

AI Scientist 的なシステムをそのまま iGEM に持ち込もうとすると、

  • 実験条件のメタデータが揃っていない
  • プロトコルがロボットに流せる形式になっていない
  • 実験ログが Excel と紙ノートと Google Drive などに散らばっている
  • お金がない!!!

みたいな理由で、結局 ChatGPT とかだけ「賢いアイデア出し & おしゃべり相手」に落ち着いてしまう、というのが最初の障壁だと思います。

A-Lab のようにロボットと ML をガッチリ統合した環境を作るのは、さすがに iGEM のスケールでは難しいです。

2.2 Integrated Human Practices (iHP) とか iGEM 独自の価値観への統合

もうひとつ大きいのが、評価軸の違いです。

AI Co-scientist / AI Scientist / Robin のようなプロジェクトは、基本的に、

  • 新規性 (Novelty)
  • 効率・スループット
  • 論文・創薬としてのインパクト

といった軸で成果を語っています。

一方 iGEM では、

  • Integrated Human Practices (iHP)
  • Safety
  • Education / Inclusivity

みたいな要素がかなり大きなウェイトを占めています。

ここだけ切り取ると、「AI Scientist は iHP が苦手で、iGEM とは相性が悪い」みたいな話になりがちですが、実際にはそこまで単純でもないと思っています。というのも、すでに多くの iGEM チームが ChatGPT などを使って、Education の企画や iHP の案出しをしているからです。

  • 過去の受賞プロジェクトの wiki
  • iGEM の Judging Handbook や評価基準のページ
  • 自分たちのインタビュー議事録やアンケート結果

みたいなコンテクストをきちんと渡してやると、「iGEM 的にそれっぽい案」を出すこと自体は、わりと普通にできます。「地域のステークホルダーは誰か」「どんな社会的インパクトがありそうか」「既存の規制や倫理的な論点は何か」といった観点も、それなりに拾ってくれます。

なので問題は「AI が iHP を理解できない」ことではなくて、

  • コンテクストを渡さずに、「かっこよくて新規性の高いテーマを考えて」とだけ投げると、iGEM 的にはズレた提案になりやすい
  • ちゃんと iGEM のコンテクストを渡し、iHP や Safety まで含めた評価軸をプロンプト側で定義してやらないといけない
  • そこまで設計しても、最終的な判断は人間側が持っておかないと危ない

という運用の部分にあります。

乱暴にいうと、

  • 「AI Scientist をそのまま放つ」と、技術的に面白いけど iGEM 的には微妙なプロジェクトを推してくる
  • 「iGEM のルールブックと過去 wiki と自分たちの iHP ログを全部読ませた AI co-scientist」を育てると、iHP や Education のブレスト相手としてかなり使える

のあいだにグラデーションがある感じです。

このセクションで言いたいのは、「AI と iHP とかの iGEM 固有の指標は相性が悪いからやめよう」ではなくて、「ちゃんと iGEM のコンテクストを食わせて、どこまでを AI に任せてどこから先を人間が責任を持つのかを決めないと、評価軸のズレが一気に目立ってくる」という話に近いです。最新の大会で活動している方々の方が詳しいと思うので、ぜひ感想を聞かせてほしいです。

3. それでも部分的にやれること

ここまで、実験環境と評価軸という 2 つのギャップについて書いてきました。1 チームで AI Co-scientist や Robin のような仮説生成からデータ解析までを自律的に回すシステムを再現するのは、正直かなり厳しいと思います。

ただ、部分的にならできることはあるはずです。

3.1 現実的なアプローチ

いくつか思いつくのは、

  • 複数チームでのシェア: 設備やノウハウを iGEM チーム同士で共有して、共同で「self-driving っぽい実験ライン」を作ってみる
  • 企業・研究所との連携: ラボ側は企業や研究所、Agent の設計や評価は学生チーム、という役割分担

といったあたりです。

個人的には、ScienceTokyo は TSUBAME を学内料金で使えば大手クラウドを使うよりも圧倒的に安価に計算資源を借りられるはずなので、大規模モデルをゼロから学習するのは無理でも、小さめのオープンモデルで Agent 作るとか試したり、他チームと協力してデータ連携してベンチマーク・データセット作るとかができると思っているので、やってほしい (丸投げ)。もしやるなら声かけてください。

3.2 iGEM 版ベンチマーク

もうひとつ、「iGEM 版のベンチマーク」があったら面白いんじゃないかと思っています。

ラボオートメーションの文脈だと、最近 LA-Bench のようなベンチマークが出てきています。「実験指示」「使用する物品」「元プロトコル」などから「実験手順」を生成するタスクを定義して、手法を比較できるようにする試みです。

同じ発想で、iGEM の制約条件込みのベンチマークがあってもいいのでは、と思います。例えば、

  • 過去の iGEM プロジェクトのプロトコルやスケジュールを集めたデータセット
  • 期間・予算・設備の制約をパラメータとして持っている
  • 「10 週間でここまで行く実験計画」や「この制約で Gold を狙う iHP / Education の組み合わせ」を出させるタスク

みたいなもの。「AI Scientist が出してきた案が iGEM 的にどうか」を試す遊び場にもなります。

おわりに

この 1 年で、AI Co-scientist、AI Scientist-v2、Robin など「AI が研究のパートナーになる」事例が急速に増えてきました。ただ、それをそのまま iGEM に持ち込むには、実験環境や評価軸のギャップがまだ大きいというのが正直な実感です。

とはいえ、部分的にでも Lab Automation や AI Scientist 的なアプローチに挑戦する iGEM チームが出てきたら、すごくワクワクします。1 チームで全部やる必要はなくて、チーム間でシェアしたり、企業や研究所と組んだり、使える計算資源を活かしたりしながら、少しずつ試していく形でいいと思います。

個人的には、B1 と B2 のあいだくらいに GPT-4 が出たとき、dry チームで「これは iGEM に応用してちゃんとまとめよう」と話していたのを覚えています。当時は「早く出さないと来年には新規性がなくなる」と焦っていたのですが、結局まとめきれませんでした (あのときのチームメンバーには申し訳ない気持ちがあります)。

あれから 3 年弱。Agent 系は実務で普通に使えるレベルになりつつありますが、iGEM などの実験系での活用は思っていたほど進んでいない印象です。iGEM だと wiki の実装・デザインや writing の効率化など、coding や文章生成の部分では確実にレベルが上がっている気がしますが、それ以外の領域 (例えば実験計画の自動生成や大規模な Agent 利用) への拡張はまだこれからなのかもしれません。

数年後には、ここで書いたようなことも「当たり前でしょ」と言われている気がします。そのときに自分がこの文章をどう振り返るのか、楽しみです。

もし AI for Science、Agent に興味ある人がいれば声かけてください。discord (tax_free) でも Twitter (taxfree_python) でも大丈夫です。ご飯行きましょう!!!

それ以外でもご飯行きましょう!!!。暇なので!!!

参考リンク