AIサイエンティスト「Kosmos」と Structured World Model について
Kosmos: An AI Scientist for Autonomous Discovery
簡単にいうと、研究者の代わりに 12 時間ぶっ通しで “仮説生成→文献調査→コード実行→データ解析→再仮説生成” を 200 回以上繰り返し、最終的に査読論文レベルのレポートを自動生成するという恐ろしい「AIサイエンティスト」がKosmosです。
既存のAIエージェント(例:GoogleのAI co-scientist、Sakana AI Scientist、Robinなど)の弱点であった、「コンテキスト保持が浅い」「長い推論が破綻する」「分析パイプライン全体を走らせられない」を克服した「構造化ワールドモデル(Structured World Model, SWM)」が最大のコア技術となっているみたいです。
以下では、その構造化ワールドモデルを深掘りしていきたいと思います。
構造化ワールドモデルとは何か
まず用語の整理から。
「ワールドモデル」という概念
もともとワールドモデル(World Model)は、ロボティクスや強化学習の世界で使われてきた言葉で、
「エージェントが相互作用している“世界”の内部モデル」
を指します。もう少し固く言うと、
- 状態空間(State)
- 状態遷移(次状態の分布)
- 観測と状態の対応
- 行動の効果
などを含む、世界のダイナミクスの近似モデルです。例えば、
- 自動運転なら「車の位置・速度・周囲の車・信号」
- ロボットマニピュレーションなら「物体の位置・重さ・摩擦」
がワールドモデルが表現する対象になります。
LLMエージェントにおける「世界」とは何か
じゃあLLMベースのAIエージェントにとっての「世界」は何か?
- エージェントが扱う ドキュメント・データセット・コード・ツール
- エージェントが立てた 仮説・タスク・計画
- 実行した 実験やツールコールの結果
- 参照した 論文やWebページ
こういったものを総称した「情報空間」こそが、LLMエージェントにとっての世界です。
通常のエージェントは、
- これらを「ただのテキスト履歴」としてLLMのコンテキストに流し込み、
- “なんとなく”覚えていることを前提に次のアクションを決めています。
このやり方だと、
- コンテキスト長制約で過去の情報が消える
- 同じ分析や検索を何度も繰り返す
- 長期の推論チェーンで一貫性が崩壊する
といった問題が発生します。
「構造化」されたワールドモデルとは
構造化ワールドモデルは、こうした情報を
ただのテキスト履歴ではなく、明示的な構造(グラフ・テーブル・JSON)として表現するワールドモデル
です。例えば、次のようなグラフ(あるいはスキーマ)を持ちます:
-
ノード(Entity)
- Dataset, Experiment, Hypothesis, Result, Paper, Code, Metric, Task …
-
エッジ(Relation)
- supports(支持する)
- contradicts(矛盾する)
- derived_from(導かれた)
- measured_on(このデータに基づく)
- depends_on(依存している)
つまり、
「世界に存在するオブジェクト」と「それらの関係」を、
LLMのコンテキスト外に、構造化された形で保持する仕組み
が構造化ワールドモデルです。
Kosmosにおける Structured World Model
ここからは Kosmos の実装に即して、もう少し具体的に見ていきます。
Kosmos 全体の流れ
Kosmos は、研究者が指定した
- 研究目的(例:T2Dの保護メカニズムを特定せよ)
- データセット(例:GWAS、オミクスデータ)
を入力として、
- タスクを計画する(Task Planning)
- データ解析エージェントを走らせる
- 文献探索エージェントを走らせる
- それぞれの結果を Structured World Model(SWM)に統合
- SWM を読んで「次にやるべきこと」を考える
- 1〜5 を 200サイクル程度繰り返す
- 最後に SWM をもとにレポートを生成する
というループを回します。
SWMが持っている情報
論文中で SWM は厳密なスキーマとしては書かれていませんが、動きから推定すると、少なくとも次のような情報を管理しています:
-
Hypothesis(仮説)
- 例:「低体温下では nucleotide salvage がエネルギー節約に重要」
-
Finding / Result(結果)
- 統計量、p値、回帰係数、SHAP値など
- 図・テーブルのメタ情報(どのNotebook・コードから生成されたか)
-
Dataset & Analysis Context
- どのデータセットに対する分析か
- 前処理やフィルタリングの条件
-
Paper / Evidence(文献エビデンス)
- どの論文の、どの主張を引用しているか
-
Taskの履歴
- 実行したサブタスク(例:「SOD2周りのMR解析を実行」)
- 成功/失敗、エラー情報
-
Confidence / Quality
- 各ステートメントの信頼度(人間の再評価結果も含む)
重要なのは:
SWM に記録されたノードやエッジを、
次のサイクルのタスク生成に 直接参照している こと
です。Kosmosはこれにより、
- すでに検証済みの仮説をくどくど繰り返さない
- まだ検証されていないパスを重点的に探索する
- 文献とデータ解析を統合して推論の「穴」を埋める
という動きを実現しています。
Kosmos はこの仕組みにより、平均で
- 約 42,000 行のコードを実行し
- 1,500 本の論文を読み
- 約 4.1 人月分の研究に相当する作業を 1 回のランで行う
と報告されています。(おそろしや)
なぜ構造化ワールドモデルで「長時間推論」が可能になるのか
理論寄りの話もしっかり考えてみましょう。
1. コンテキスト外部化による「長期記憶」
LLMの限界として、
- コンテキスト長に上限がある
- そもそも長文コンテキストを渡しても “記憶の精度” が落ちる
という問題があります。
SWMはこれに対して、
- 重要な情報を構造化された外部メモリに退避させ、
- LLMは必要なときにクエリを投げて情報を取り出すだけ
という構造に変えています。
情報理論的に見れば、LLMのコンテキストは高価な「キャッシュ」であり、世界の完全状態は SWM に保存された「ストレージ」です。
Claude Code でも実装計画を立てるサブエージェントと実装のメインエージェントでコンテキストを分けることで計画中の無駄なコンテキスト圧迫を防ぐ機能があって似ていますね。
2. 部分観測 MDP における「belief state」に近い
強化学習の観点では、LLMエージェントは
- 環境からの観測(Observation):ログ、データ、文献
- 内部状態(State):仮説、現在の計画、タスクの進捗
を持つ POMDP(Partially Observable MDP)のエージェントと見なせます。
構造化ワールドモデルは、この「内部状態」を
- テキストではなく、
- 明示的なグラフ / テーブルとして管理する belief state ストア
だと捉えられます。これにより、
- belief state の更新を明示的に定義できる
(=どの観測をどう取り込むか) - 古い情報の重みを下げる・消すといった操作も、
ルールや関数として制御できる
ようになります。
3. 「推論の鎖」を構造として保持できる
長期の科学推論はほぼ必ず、
仮説 → 分析 → 中間結果 → 新仮説 → 追加分析 → …
という**推論の鎖(chain of reasoning)**になります。
この鎖をテキストだけで保持しようとすると、
- どの結論がどのエビデンスに依存しているかが曖昧
- 新たなエビデンスが出たときの影響範囲が分からない
- 途中のリンクだけ修正することが難しい
という問題が起こります。SWMでは、この鎖が
- グラフとしてノードとエッジで保持されるため、
- どの仮説がどのエビデンスに依存し、
- 新たな結果がどの結論に影響するのか
を構造的に扱えます。Kosmosが特定の発見について
- データ解析(MR、GP、分割回帰など)と
- 文献エビデンス
を一貫したストーリーにまとめられているのは、この構造があるからです。
データモデルとしての構造化ワールドモデル
ここからは、実際に自分で実装することを想定して、
データモデルレベルに落としていきます。
図でイメージ
シンプルにすると、次のようなグラフ構造になります:
RDBでの例(簡略版)
RDBで実装する場合、例えば:
「柔らかさ」をどう確保するか
科学研究や複雑なエージェントでは、スキーマがどんどん進化していくので、
- 核心的な部分だけ正規化
- その他は
metadata_jsonのような柔らかいカラムに逃がす
という設計が現実的です。
普段のAIエージェント開発にどう応用するか
ここが多くの人にとって一番重要なポイントだと思います。
典型的なLLMエージェントの構造
よくある構成はこんな感じです:
- システムプロンプト+履歴をLLMに投げる
- LLMが「思考」+「ツールコール」を選ぶ(ReAct系)
- ツールを実行し、結果をまたテキストでLLMに渡す
- 最後に回答を生成して終わり
「メモリ」がある場合も、
- 単に過去チャットを要約している
- ベクトルストアで類似検索している
程度のことがほとんどです。
そこに Structured World Model を足すとどう変わるか
以下のような追加を考えるとよいです:
-
エージェントの出力を必ず JSON で返させる
-
hypotheses,evidence,tasks,decisionsなどのフィールドを持つ
-
-
そのJSONをパースして、World Model ストアに保存する
- RDBでもGraph DBでもよい
-
次のプロンプトを組むときに、World Model からクエリして情報を与える
- 「未解決の仮説」
- 「矛盾する証拠」
- 「過去に実行した類似タスク」
-
最終回答を生成するときも、World Modelに紐づくエビデンスを参照・引用する
これだけでも、
- 会話の一貫性
- 「同じ質問を何度も聞かれる」問題
- 推論の深さ
が明確に改善します。
まとめ
-
ワールドモデルは、エージェントが相互作用する「世界」の内部表現。
-
LLMエージェントにとっての世界は、データ・コード・文献・タスク・仮説などの情報空間。
-
構造化ワールドモデルは、それらを単なるテキストではなく
明示的なグラフ / テーブルとして保持する仕組み。 -
Kosmos はこの仕組みを中枢に据えることで、
- 12時間で200サイクル以上の推論を回しつつ
- 4人月相当の研究タスクを自動化し
- 全ての主張にコード or 文献エビデンスを紐付けることに成功している。
-
普段のAIエージェント開発でも、
- エージェント出力をJSONで構造化し
- World Model ストアに保存し
- 次のプロンプトをWorld Modelから組み立てる
というだけで、長期推論の質と一貫性が大きく改善する。
Discussion