技術要約：トークン効率の高い自律的実験のためのステートフルなReActエージェント

問題提起

「オートリサーチ（autoresearch）」パターンは、ターゲットとなる指標を最適化するために、LLM（大規模言語モデル）がコードを反復的に修正することで、自律的な実験を可能にします。しかし、標準的な実装は**ステートレス（状態を持たない）**です。各イタレーションにおいて、エージェントは研究指示ファイル（例：program.md）に蓄積された実験結果とコード修正の全履歴を再読することで、実験コンテキスト全体を再構築しなければなりません。

この設計は、構造的な非効率性を招きます：

• トークンコスト： プロンプトのサイズがイタレーション数に対して線形（$O(n)$）に増加するため、総トークンコストは $O(n^2)$ に達します。
• 冗長性： エージェントは、以前のステップですでに処理した情報を再送することになります。
• スケーラビリティ： 実験が蓄積されるにつれ、プロンプトがコンテキストウィンドウの制限に近づき、情報の切り捨てや要約が必要になります。これは、重要な実験のニュアンスを失うリスクを伴います。

本論文は、LLMは相互作用を通じて一時的な状態を保持できないため（Huang et al. [10]）、外部での状態管理がこの二次的なコスト曲線を打破するための建築的な必然性であると断じています。

メソドロジー

著者らは、オートリサーチ・パターンを LangGraph を用いた ステートフルなReActエージェント として再定式化しています。モノリシックなプロンプトに全履歴を含める代わりに、エージェントはツール呼び出しを通じてMLシステムと対話し、実験履歴、推論の痕跡、および収束メトリクスは、型定義された永続的な状態グラフに保持されます。

アーキテクチャ

エージェントは、主に3つのノードからなる状態グラフとして動作します：

1. REASON（推論）： 現在の状態コンテキストを用いてLLM（Claude Haiku 4.5）を呼び出します。モデルは推論の痕跡とツール呼び出しを生成します。
2. TOOLS（ツール）： ツール呼び出しを決定論的に実行し（例：実験の実行、結果のクエリ）、観測結果を返します。
3. CHECK（確認）： LLMを介さずに、収束基準（ターゲットメトリクスの閾値、イタレーション予算、またはLLMによる結論）を評価します。

条件付きエッジによってフローが制御されます。LLMがツール呼び出しを生成した場合は、制御は TOOLS へと移ります。そうでなければ、CHECK へ進みます。収束していない場合は、ループは REASON に戻ります。

状態管理

核心となるイノベーションは、イタレーションを横断して保持される型付き辞書である AgentState です。これには以下が含まれます：

• messages: 入力コストを制限するための、直近20メッセージのスライディングウィンドウ。
• experiment_history: 過去のすべての結果のリスト。
• current_best: これまでに見つかった最高の結果。
• train_py_content: 現在のコード状態。

極めて重要な点として、エージェントはヘルパークラス（ExperimentState または CodeState）を使用して、各ステップでLLM向けのコンパクトな要約を生成します。この要約には以下が含まれます：

• 現在のイタレーション数と、最高の集計メトリクス。
• 直近5件の実験（または最近の結果）。
• 戦略上のノートおよび失敗したアプローチ。

これにより、エージェントが実行した総実験数に関わらず、LLMは常に $O(1)$ の入力トークンのみを受け取ることになります。全履歴は状態内にアクセス可能な状態で保持されますが、明示的にツール経由でクエリされない限り、プロンプトからは除外されます。

ツール

エージェントは、特定のツールを通じてMLシステムと対話します：

• ハイパーパラメータ・チューニング： get_experiment_history および run_experiment。
• コード最適化： get_current_train_py、modify_train_py（評価ロジックを維持するためのガードレール付き）、submit_training_job、および query_results。

主な貢献

1. アーキテクチャの再定式化： ステートレスなオートリサーチ・パターンを、LangGraphを用いたステートフルなReActエージェントへと変換し、エージェントのワーキングメモリをプロンプトのコンテキストから分離したこと。
2. トークンの効率化： ステートレスな $O(n^2)$ から、ステートフルな $O(n)$ への総トークンコストの構造的な削減を実証したこと。
3. 実装のブループリント： 実践者がステートフルなエージェントを実装するための、詳細かつ再現可能なアーキテクチャ（状態スキーマ、グラフロジック、ツール定義を含む）を提供したこと。

実験結果

著者らは、3つのランダムシードを用いて、2つのベンチマーク・タスクにおいてステートフルなエージェントをステートレスなベースラインと比較評価しました。

タスク1：ハイパーパラメータ・チューニング（小規模な観測）

• 設定： UCI Covertypeデータセット上でXGBoostを最適化する15回のイタレーション。観測内容は小規模（約200トークン：JSON設定 + メトリクス）。
• 結果：
  • トークン削減： ステートフルなエージェントは、90%少ないトークン（2,492 vs 24,465）を消費し、9.8倍の削減を達成した。
  • パフォーマンス： 両エージェントは同等のF1スコア（0.779 vs 0.764）を達成した。この差は、アーキテクチャの優位性ではなく、シードの分散に起因するものと考えられる。
  • コスト曲線： ステートレスな入力コストはイタレーションごとに約700から約1,900トークンへと線形に増加したが、ステートフルなコストは一定の約100トークンで横ばいとなった。

タスク2：コード・パフォーマンス最適化（大規模な観測）

• 設定： Pythonのデータ処理関数を最適化する40回のイタレーション。観測内容は大規模（約1,500–3,000トークン：完全なソースコード + ベンチマーク）。
• 結果：
  • トークン削減： ステートフルなエージェントは、52%少ないトークン（627K vs 1,275K）を消費し、2.0倍の削減を達成した。
  • パフォーマンス： 両エージェントは同等のスピードアップ（ベースラインに対し約1.9倍）を達成した。
  • コスト曲線： ステートフルなエージェントも、毎ステップで「現在のベストなコード」を送信するための固定コスト（約1,500トークン）を依然として発生させるが、総コストは頭打ちとなった。対照的に、ステートレスなコストは上昇し続け、イタレーション40までに80,000トークン以上の履歴が蓄積された。

比較分析

トークン削減率は、状態の要約に対する観測サイズの比率に反比例します。

• 小規模な観測： 固定サイズの要約は蓄積された履歴よりも劇的に小さいため、高い削減率（9.8倍）が得られる。
• 大規模な観測： ステートフルなエージェントも現在のコード・アーティファクトを送信する必要があるため、比率は限定的となる（2.0倍）。しかし、論文ではイタレーション数が増加する（例：100や200へ）につれ、$O(n^2)$ と $O(n)$ の乖離により、この比率は大幅に拡大すると指摘されている（予測では4倍から7倍）。

意義と主張

本論文の主な貢献は、最適化の質の向上ではなく、構造的な効率性であると主張しています。ステートフルなエージェントは、ステートレスなベースラインと同等の最適化品質を達成しながら、トークン消費量を劇的に削減しています。

• スケーラビリティ： イタレーションあたりの $O(1)$ のコストにより、プロンプトの切り捨てや意思決定能力の喪失を伴うことなく、任意の長さの実験シーケンスが可能になります。
• 経済的影響： 短期的な実行では節約効果は限定的ですが、大規模な研究（毎日数百回の実験を行うようなケース）においては、ステートレスな実行による二次的なコストが支配的なボトルネックとなるため、その効果は重大になります。
• 将来の展望： 著者らは、実験のホライゾン（期間）が長くなるにつれ、ステートレスな実行における二次的なトークンコストが主要な制約となり、持続可能な自律的実験のためにはステートフルなアーキテクチャが不可欠になると示唆しています。

著者らは最適化の質に関して謙虚な姿勢を崩しておらず、観察されたメトリクスの差異はノイズの範囲内であり、ステートフルなアプローチの品質上の利点として解釈すべきではないと明記しています。焦点は、あくまでも効率的なアーキテクチャへの移行による効率性の向上に置かれています。