AI・テクノロジー

LLMエージェントを「重み」ではなく「状態」で進化させる──AutoFynが示す非パラメトリックExpert Iteration

docker agent

• 21 min read
Share

はじめに：長時間稼働エージェントが直面する「3つの壁」

2026年現在、LLMエージェントは数時間から数日にわたり、数百回のモデル呼び出しとツール操作を連続して行うのが当たり前になっています。代表例は、SWE-bench系で見られるリポジトリ横断コーディングや、Reflexion・Self-Refineのような自己リフレクション型のループです。こうした「長時間稼働（long-horizon）」エージェントは、単発の質問応答とは質の異なる問題を抱えます。本記事では、それを「3つの壁」として整理します。

壁1「コンテキスト腐敗」。単一セッションのコンテキストが伸び続けると、モデルは長い文脈を均等に扱えず「真ん中の情報」を忘れます。これはLost in the Middle（Liu et al. 2024）として知られる現象で、途中で得た重要な仕様や結論が後段の判断から消えてしまう原因になります。会話が長くなるほど、後半の推論は前半の前提を正確に参照できなくなります。

壁2「自己評価の限界」。LLMは外部フィードバックなしに自分の推論を正しく訂正できません（Huang et al. 2024）。間違った結論が自己チェックを通り抜けて後段の判断を汚染すると、誤りは連鎖的に広がります。自分で自分の答えを「合っている」と認める仕組みは、誤りに騙されやすい構造です。

壁3「失敗の反復」。何も引き継がれないループでは、同じミスを何度も繰り返します。一度失敗した原因や教訓が次ラウンドに伝わらなければ、エージェントは毎回ゼロから同じ轍を踏むことになり、探索が進みません。

本記事の目的は、この3つに同時に対処する設計であるAutoFyn（arXiv:2609.05446、SignalPilot Labs）の設計思想と実績を解説することです。AutoFynはモデルの重みを一切変えずに「状態」を更新するという独自のアプローチで、これらの壁を乗り越えようとします。次章以降で、その全体像と仕組み、3つの実証領域での結果を順に詳しく見ていきます。

AutoFynとは何か：3行でわかる全体像

AutoFyn（arXiv:2609.05446、SignalPilot Labs）は、Expert Iteration（エキスパートイテレーション）に触発されたエージェント・ハーネスです。ハーネスとは、モデル本体は変えずにプロンプト・ツール・状態管理・検証といった周辺機構でエージェントを駆動する枠組みを指します。AutoFynはその中でも、モデルの重みを一切変更しないまま、**永続状態（persistent state）**をラウンドごとに更新することで、凍結されたモデルを探索の試行をまたいで適応させます。つまり「モデルの内部を書き換える」のではなく「モデルの外にある記憶と手続きを更新する」ことで性能を引き上げる設計です。

AutoFynを支えるのは次の3つの設計原則です。

  1. Fresh sessions over explicit state（フレッシュセッションと明示的状態）。毎ラウンド空のコンテキストから開始し、情報はメモリファイル・リポジトリ・レポート・評価履歴という固定インターフェースを通してのみ復元します。前ラウンドの会話は再読み込みしないため、コンテキストの長さは経過時間ではなく状態量に追従します。
  2. Search over candidates（候補の並行探索）。オーケストレータが専門エージェント（プランナー・ビルダー・レビュアーなど）に複数のアプローチを探索・計画・ビルド・レビューさせます。単一の推論ではなく、多様な候補を並行して生み出します。
  3. Grounded acceptance（接地された受理）。ラウンドの成否はモデルの自己評価ではなく、環境由来の客観的な検証シグナル（実行結果・ベンチマーク・実機エクスプロイト）で判定します。エージェントが自分の成功を認定することを禁止し、常に外部の裏付けを要求します。
原則 意味 対になる従来の方法
フレッシュセッションと明示的状態 空コンテキスト開始＋状態ファイルのみで復元 単一セッションの会話を延々と引き継ぐ
候補の並行探索 複数専門エージェントが複数アプローチを探索 単一エージェントの逐次推論
接地された受理 環境由来の検証シグナルで成否判定 モデル自身による自己チェック

AutoFynのコードはオープンソース（BSL 1.1、リリース3年後にApache 2.0へ自動移行）で公開されており、誰でもハーネスの中身を確認・再現できます。この3行の全体像を踏まえたうえで、次章ではなぜモデルを変えずにエージェントを改善できるのか、その意義を詳しく見ていきます。

なぜ重要か：モデルを変えずにエージェントを改善できる

「エージェントを強くする」方法として最も直感的なのは、モデル本体のファインチューニング、つまり重みを更新することです。しかし高額なフロンティアモデルやAPI越しにしか触れない非公開モデルでは、重みを書き換えることは事実上不可能です。AutoFynの意義は、こうした「モデルを触れない」環境でも、**ハーネス（周辺機構）**の改善という別ルートで性能を引き上げられることを示した点にあります。モデルの外にある状態管理・検証・蒸留といった仕組みを改良すれば、凍結したモデルのままでもエージェント全体の能力は向上しうる、というのがその主張です。

この考え方を裏付けるのが、論文が報告するIMO 2026（国際数学オリンピック相当の6問・42点満点）の実測です。AutoFynを適用した結果、Claude Opus 4.8は28.0→34.7、Claude Sonnet 5は23.3→29.7へ伸び、特にGLM 5.2は20.7→32.0（+11.3点）とメダル帯を跨ぐ大幅な改善を見せました。いずれもモデル本体は一切変更されておらず、ハーネスの設計だけが変わっています。これは「提供元のコーディングエージェント」を、同一モデルのままAutoFynが上回ったことも意味します。

さらに重要なのは、エージェントの性能評価の潮流そのものが変化していることです。従来はモデル単体の能力が評価の中心でしたが、近年はハーネスとモデルを一体で評価する「Harness-bench」「Meta-harness」といった枠組みが台頭しています。エージェントの成果は「モデル×ハーネス」の掛け算で決まるという視点が広がるなか、AutoFynの実績は、ハーネス側の改善がどれだけ大きな差を生むかの具体的な一例として位置づけられます。モデルを変えられない状況でも、周辺機構を磨くことでエージェントを進化させる道筋は、実務上の選択肢を大きく広げるのです。

仕組みを解剖する：AutoFynの1ラウンド

AutoFynの核心は、モデル本体を一切触らず「永続状態」を更新しながら反復を重ねるループです。その1ラウンドは、空のコンテキストから始まり、探索・検証・蒸留を経て次ラウンドへつながります。ループの流れは次のように整理できます。

flowchart TD
    A[空コンテキストで開始] --> B[状態ファイル M_t を読み込む]
    B --> C[オーケストレータが探索・計画・ビルドを専門エージェントへ委譲]
    C --> D[検証器が候補を採点]
    D --> E{受理かつ<br>スコアが現ベスト超え?}
    E -- はい --> F[インカンベントを更新]
    E -- いいえ --> G[インカンベントは据え置き]
    F --> H[教訓を状態へ蒸留（lossy）]
    G --> H
    H --> I[git commit & アーカイブ]
    I --> J[次ラウンドへ]

ここで重要なのは、このループ制御がモデルの外にあることです。ラウンド遷移・アーカイブ・レジューム・git commit/push・早期終了のタイムロックといった機械的な制御は、すべてハーネスプロセス（オーケストレーションの枠組み）が担当します。モデル自身が「次のラウンドへ進むか」を決めるのではなく、ハーネスが毎回フレッシュセッションを生成し、永続メタデータを読み込んで次のループを起動します。この「モデルの外に制御を置く」設計が、長時間稼働でも判断が暴走しにくい要因です。

各ラウンドの成否は、検証器（verifier）が返す型付きレコードで判定されます。検証器は候補アーティファクトaを入力に、y = (スコア, エビデンス束, 保証クラス, 検証器ID)という4要素のレコードを出力します。ここがAutoFynの特徴的な点で、次ラウンドは「合格/不合格」という裸の判定ではなく、なぜ失敗したかという理由込みの記録を読み取ります。エビデンス束は判定の根拠となる観察を、保証クラスはその根拠の強さを表します。

保証クラス（assurance class）は、エビデンスの信頼度を段階づける仕組みで、次の順に強くなります。

保証クラス 内容 信頼度
モデル自己評価 モデルが自分の出力を評価 低
別コンテキストでのレビュー 別の視点のエージェントが評価 中
実行可能チェック テスト・ビルドを実際に実行 高
独立な人間の採点 人間が評価 高
機械検証済み証明書 形式検証で証明 最高

自己評価は最も弱い保証で、AutoFynはエージェントが自分の成功を認定することを禁止します。これは、LLMが外部フィードバックなしでは誤りを訂正しにくいという知見（Huang et al. 2024）に基づく設計です。ラウンド内の探索方向づけには自己評価を使っても、受理判定には必ず環境由来のエビデンスを求めます。

検証を通過してベストスコアを上回った成果物は**インカンベント（現最良成果物）**として永続状態に保持されます。この永続状態M_tは、次の5つの要素で構成されます。

flowchart LR
    subgraph M_t[永続状態 M_t]
        G[ゴール G_t<br>+ユーザー修正]
        H[評価履歴 H_t]
        R[蒸留ルール R_t<br>ロール別教訓]
        W[作業状態 W_t<br>仮説・失敗・次の一手]
        I[インカンベント I_t<br>+エビデンス]
    end

ゴール（とユーザーによる修正）、これまでの評価履歴、蒸留されたルールとロール別の教訓、仮説・失敗・次の一手をまとめた作業状態、そしてインカンベントとそのエビデンスです。作業状態は「検証済みの事実」と「仮説・失敗・次の一手」を別セクションに分離し、推測が事実として扱われないようにしています。サブエージェントごとにロール別のメモリファイルを持たせることで、ビルダーの知識とレビュアーの知識が混ざらない点も、状態設計の工夫です。このように1ラウンドは「探索→検証→受理/棄却→蒸留→アーカイブ」という完結した単位をなし、その成果が次ラウンドのコンテキストへ確実に引き継がれていきます。

「非パラメトリックExpert Iteration」とは何か

まず前提となるExpert Iteration（エキスパートイテレーション）を確認しておきましょう。これは、見習いポリシー（アプレンティス）が候補を生成し、それをより強いエキスパート手続きが採点し、その結果を次回のポリシーに折り返す学習ループです。囲碁・将棋AIのAlphaZero（Silver et al. 2018）や、計画探索と自己リフレクションを組み合わせたLATS（Zhou et al. 2024）が代表例として挙げられます。

AutoFynはこの枠組みを、モデルの重みを一切更新せずに再現します。論文の対応表（Table 1）を要約すると次の通りです。

古典的Expert Iteration AutoFyn
アプレンティスポリシー 凍結モデルで構成される「文脈ポリシー」π(M_t)
エキスパート手続き（採点） 検証器に接地されたレビュー＆リビジョンループ
パラメータ更新 θ_{t+1} 永続状態更新 M_{t+1}

つまり「アプレンティス」に相当するのは、固定されたモデルΘとその時点の永続状態M_tから決まる文脈ポリシーπ(M_t)です。「エキスパート」に相当するのは、環境シグナルに接地された検証器を組み込んだレビュー＆リビジョンループです。検証器そのものがエキスパートなのではなく、検証器がループを環境に接地させる部品として機能する点が重要です。

「非パラメトリック」と呼ばれる理由はここにあります。Θが完全に固定されたままM_tだけがラウンドをまたいで更新されると、次ラウンドの振る舞いの分布は変化します（π^{M_{t+1}}≠π^{M_t}）。これは重みの最適化（訓練）ではなく、文脈の更新によって実効ポリシーを変える操作です。パラメータ空間ではなく状態空間で「学習」を起こす点が、通常のExpert Iterationとの最大の違いです。

ただし論文自身が明言する通り、この対応は構造的なアナロジーであってアルゴリズム的な同一性を意味しません。MCTSのように「アプレンティスより必ず強くなる」という保証はありません。検証器は正しい候補を誤って棄却したり、誤った候補を受理したりし得ます。改善は更新メカニズムから仮定されるのではなく、後のラウンドで検証された性能によって初めて確立されます。AutoFynの「改善」主張は、この非パラメトリックなループの上に、実測の成果を積み上げることで正当化されています。

検証器の設計：何を以て「進歩」とするか

検証器は「合格/不合格」という裸の判定ではなく、スコア・エビデンス束・保証クラス・検証器IDを持つ型付きレコード y = (スコア, エビデンス束, 保証クラス, 検証器ID) を返します。次ラウンドは、なぜ失敗したのかという理由込みの記録を読むことになります。何より重要なのは、この検証シグナルがモデルではなく環境によって生成される点です。アーティファクトと環境だけから判定が再現できるため、自己評価にありがちな「自分の結論への甘い採点」が構造的に排除されます。各チェックは意図的に狭く設計され、通ったテストはそのケースだけを語り、汎化を主張しません。

ドメイン 検証シグナル 判定の特徴
数学（オリンピアード） 反証探索のみ 証明の論理健全性は実行できないため、反例が見つからないことをもって進歩とする
データサイエンス ベンチマーク評価器 総合スコアとケース別の内訳（per-case breakdown）を返す
セキュリティ エクスプロイトの実機リプロダクション 対象ビルドで実際に発火したものだけを成果に計上

数学では、証明の論理健全性は実行では確立できないため、検証は「反証」に限定されます。境界主張には小ケース・退化ケースの探索を、代数計算には記号代数パッケージによる不一致チェックを適用します。反例は対象ステップだけを反駁し、不成功の探索は何も確立しません。この非対称性——「反例が見つからないことは正しさを意味しない」——を設計に織り込むことが本方式の要点です。データサイエンスでは、評価器が返すケース別の内訳、すなわち失敗ケースの一覧が次のラウンドの探索の手がかりになります。セキュリティでは、候補エクスプロイトを対象ビルドに対して実際に実行し、到達可能なパスが実証されたものだけが成果として計上されます。発火しない報告は仮説として扱われ、検証済みの事実と混ざりません。

なお論文自身も、研究レベルの数学問題にはオリンピアード型の反証探索では不十分で、Lean等のプルーフアシスタント（機械検証済み証明書を生成する形式的証明検証器）が必要になることを限界として明記しています。検証器の質がループ全体の質の上限を決める以上、この適用範囲の見極めは設計の核心です。

インカンベント保持と蒸留：知識が「腐らない」仕組み

インカンベント（incumbent）とは、ラウンドをまたいで保持される「現時点の最良成果物」のことです。AutoFynでは、候補が検証器に受理され、かつスコアが現ベストを上回った場合にのみ更新されます（式(1)）。決定論的な比較スコアのもとでは、インカンベントのスコアは単調非減少に保たれます。すなわち、失敗ラウンドや低スコアの試行は現ベストを一切汚さず、何度悪いラウンドを重ねても「最良の解」は安全に保存されます。この機械的な品質ゲートがあるからこそ、人間の介入なしで探索を長期継続できます。

セキュリティ監査でこの性質を観察すると、ラウンドを重ねるごとの累積エクスプロイト数は単調に増加し、やがて平坦化する曲線を描きます（下図は模式例。監査ごとに収束点の高さは違いますが、形状は共通します）。

xychart-beta
    title "累積エクスプロイト数の推移（模式例）"
    x-axis [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
    y-axis "累積エクスプロイト数" 0 --> 40
    line [5, 11, 17, 22, 26, 29, 31, 32, 32, 32]

蒸留は不可逆（lossy）です。ラウンドから得た教訓は「観察」としてではなく「コマンド」として永続状態に書き出されます。例えば「マイグレーションはテストの前に実行せよ（round 4起因）」のように、学習ラウンドと理由が付与されます。蒸留は要約と圧縮を伴うため元の会話は復元できず、コマンドは対象コードの消滅などで有効性を失った場合に退役します。いわば「教訓は要約として残し、会話は捨てる」設計です。

知識はロール単位でも分離されます。サブエージェントごとにロール別メモリファイル（architect.md、code-reviewer.md など役割ごとのファイル）が割り当てられ、ビルダーの知識とレビュアーの知識が相互に混ざりません。さらに作業状態ファイルでは「検証済みの事実」と「仮説・失敗・次の一手」が別セクションに分かれており、推測が事実として扱われることが構造的に防がれます。状態が「誰が・いつ・なぜ」を伴って整理されているため、知識が腐らず、次ラウンドのコンテキストとして信頼できます。

実績1：オリンピアード数学（IMO 2026）

最初の実証は、2026年国際数学オリンピック（IMO）の本番6問を使った数学タスクです。この6問はいずれも全モデルのトレーニングカットオフ後に出題されたため、モデルが解を記憶している可能性はありません。実験では5つのモデルを、Web UI・提供元コーディングエージェント・AutoFyn固定の3種類のハーネスで解かせ、完全な議論のみ7点を与える完了ベース採点（42点満点）で評価しました。さらにフロンティアモデルによる監査と元IMOメダリスト3名によるパネルレビューの二重の審査が行われています。

結果は次の通りです（提供元エージェント → AutoFynの順）。

モデル 提供元エージェント AutoFyn 差分
GPT-5.6 Sol 40.0 42.0 +2.0
Claude Fable 5 42.0 42.0 ±0.0
Claude Opus 4.8 28.0 34.7 +6.7
Claude Sonnet 5 23.3 29.7 +6.3
GLM 5.2 20.7 32.0 +11.3

最大の伸びはGLM 5.2の+11.3点で、これはメダル帯を跨ぐ大幅な改善です。Claude Fable 5は両ハーネスで完答（42点満点）のため改善余地がなく、GPT-5.6 SolもAutoFynで満点に到達しました。モデル本体は一切変更されていないにもかかわらず、全モデルでスコアが非減少である点が注目されます。このことは「モデルを変えずにハーネスを変えるだけで、同一モデルの提供元エージェントを上回れる」ことを示しています。

ただし、この結果の解釈には注意が必要です。ハーネス間ではエピソード長・ツールアクセス・検索・マルチエージェント構造が異なるため、これは「AutoFynループ単独の効果」ではなく「デプロイ（導入構成）全体の比較」であり、論文自身もこの但し書きを明記しています。また改善にはモデル側の上限があり、Problem 3はすべてのサブフロンティア実行で未解決のままで、ハーネスはモデルの能力上限そのものを超えられません。それでも、同一モデルのまま提供元エージェントを上回った事実は、ハーネス設計がエージェント性能を大きく左右する強いエビデンスです。

実績2：データサイエンス（Spider 2.0 dbt）

Spider 2.0 dbtは、実務に近いデータ変換ワークフローをエージェントに実行させ、事前に保留された期待出力との一致度で採点するベンチマークです（https://spider2-sql.github.io/）。単発のSQL生成ではなく、dbt（data build tool）プロジェクトの構成やモデル定義、変換ロジックの実装まで含めた一連の作業をエージェントが完遂できるかを評価します。AutoFynの検証器はこのベンチマーク評価器そのものであり、総合スコアに加えて**ケース別の内訳（per-case breakdown）**を返します。どのタスクで何点失ったかが一覧になるため、失敗ケースはそのまま次ラウンドの探索の手がかりになります。

AutoFynに与えられたゴールは「このタスク用エージェントをビルド・最適化せよ」というものでした。つまりAutoFyn自身が、Spider 2.0 dbtに挑むエージェントを一から設計し、ラウンドを重ねて改善していく「エージェントを作るエージェント」として機能しています。ラウンドの成否はモデルの自己申告ではなく評価器が返す客観スコアで判定されるため、どの変更が実際に性能を押し上げたのかを機械的に切り分けられます。

成果物であるSignalPilot Agentは公開リーダーボードで1位となりました。スコアは65.60点で、2位のDatabao（60.29点）を5点以上引き離し、3位以下のShadowfax-DBT（41.18点）、Spider-Agent-Extended（39.71点）、USTC-KCIL（39.7点）には20点以上の大差がついています。

順位 エージェント スコア
1 SignalPilot Agent（AutoFynが自律構築） 65.60
2 Databao 60.29
3 Shadowfax-DBT 41.18
4 Spider-Agent-Extended 39.71
5 USTC-KCIL 39.7

この事例が示すのは、検証器が強く自動化しやすいドメインほどAutoFynのループが威力を発揮するという点です。データサイエンスはスコアと内訳が数値で得られ、失敗の原因を特定しやすいため、「モデルを変えずにエージェントを強くする」仕組みとの相性が最も良い領域の一つと言えます。検証シグナルが明確に定義できるタスクであれば、同じループを別ドメインへ移植する道筋も見えてきます。

実績3：セキュリティ監査（150+の脆弱性）

3つ目の検証ドメインはサイバーセキュリティ監査です。ここでの検証器は**エクスプロイトの実機リプロダクション（再現実行）**です。候補として生成された攻撃コードを対象ビルドに対して実際に実行し、脆弱性が本当に発火したものだけを成果としてカウントします。モデルによる「たぶん危険そう」という推測は受理されず、環境が生成する実行結果のみがラウンドの成否を決める点で、接地された受理の原則が最も忠実に適用された例といえます。

結果は13プロジェクトで150以上の個別脆弱性を発見。残り27件はオープン（確認・対応待ち）です。公開されている内訳の一部を表に示します。

プロジェクト 発見件数 内訳（Critical / High / その他）
Hermes Agent 36 Critical 13 / High 22 / Medium 1
Warp 30 Critical 6 / High 7 / Medium 8 / Low 9
Agent TARS 25 Critical 4 / High 18 / Medium 3
Langflow 22 Critical 3 / High 13 / Medium 6
RAGFlow 17 Critical 5 / High 11 / Medium 1
MetaMask 12 —
Open WebUI 12 —
Next.js 8 —
pnpm 7 エクスプロイトチェーン3本を含む

なお、pnpmの7件には、単体では影響が限定的な複数の欠陥を組み合わせて権限昇格などを達成するエクスプロイトチェーンが3本含まれます。全件は責任ある開示（HackerOne経由を含む）で進められており、パッチが公開される前の情報公開はしない方針です。

この事例の示唆は2点あります。1点目は、プロンプトインジェクションなどLLMエージェントのリスクばかり議論される昨今、AutoFynが「攻撃側の自動化」としても機能するという点です。2点目は、ラウンドごとの累積発見数が単調増加から平坦化へ移行するカーブです。これは探索と収束のトレードオフの可視化であり、新規発見が減っていく様子は検証器が正しく「進歩」を限定している証拠でもあります。

先行研究との関係：何が新しくて何が既存か

AutoFynの個々の要素はどれも既存研究に存在します。新規性は、それらを「ハードなラウンド境界」「プロビナンス（由来）付き永続状態」「接地された受理」の3条件で束ね、実動するハーネスとして合成した点です。論文自身も、古典的Expert Iterationとの対応は「構造的アナロジー」であって「アルゴリズム的同一」ではないと明記しています。

最も近い先行はRalph loop（Huntley 2025）です。空コンテキストで同一プロンプトのコーディングエージェントを再起動し、リポジトリ／プランファイル／仕様ディレクトリのみで状態を生存させる設計は、フレッシュセッションと明示的状態という原則を先取りしています。ただしループは終了ステータスを読まず、継続の判断は人間に依存します。AutoFynは外部検証器で各ラウンドを採点し、スコアが現ベストを上回る場合のみ成果物を前進させる機械的な品質ゲートを追加した点が差分です。

自己リフレクション系（Reflexion、Self-Refine）は、外部接地なしにモデル自身が出力を改訂します。AutoFynは受理判定を必ず環境シグナルに求め、エージェントが自分の成功を認定することを禁止します。これは「LLMは外部フィードバックなしに自分の推論を訂正できない」という既存知見（Huang et al. 2024）への直接的な対処です。

メモリ管理系（MemGPTのページドメモリ、HiAgentの階層ワーキングメモリ、Context as a Tool、context folding、AgentFold）は「長いコンテキストをどう管理するか」を扱います。AutoFynもコンテキスト腐敗への対処では同系ですが、ロール別メモリ・評価履歴・蒸留ルールという固定インターフェースを通じて、コンテキストの長さを経過時間ではなく「状態量」に追従させます。

検証＆リファインメント系のHuang & Yang 2025（IMO 2025パイプライン）は検証器駆動の反復という形状を先取りします。差分は、明示的な永続状態と型付き検証レコード（スコア・エビデンス束・保証クラス・検証器ID）を持つ点です。さらにSWE-agent以降、エージェント性能は「モデル単体」ではなく「ハーネス×モデル」で決まるという潮流が強まっており、AutoFynはその実運用事例としても読めます。

系統 代表例 AutoFynとの差分
セッション再利用 Ralph loop 外部検証器による機械的品質ゲート
自己リフレクション Reflexion / Self-Refine 受理を環境シグナルのみに限定
コンテキスト管理 MemGPT / HiAgent / AgentFold ハードなラウンド境界＋プロビナンス付き状態
検証駆動パイプライン Huang & Yang 2025 永続状態＋型付き検証レコード

どう使うか：実際に動かす（実践ガイド）

AutoFynはモデルの重みを変えないため、既存のLLMエージェントを大きく作り替えることなく、周辺の「ハーネス」だけを差し替える形で導入できます。ここではリポジトリのREADME準拠のクイックスタートから、実際にラウンドが回るまでの流れを追います。

セットアップから起動までは数コマンドで完了します。まず任意の場所にリポジトリをクローンし、CLIをインストールします。

git clone https://github.com/SignalPilot-Labs/AutoFyn.git ~/.autofyn
pip install ~/.autofyn/cli
autofyn update && autofyn start

初回起動時にClaudeのAPIトークン、GitHubトークン、そして対象となるリポジトリを設定します。その後、用意されたプリセット（セキュリティ強化・バグ掃除・コード品質・テストカバレッジ）か、独自のゴールを指定してラウンドを開始します。例えば「品質を損なわずに圧縮率60%を達成するようアルゴリズムを最適化せよ」というタスクは次のように実行します。

autofyn run new -p "Optimize the algorithm to hit 60% compression ratio without further quality loss" -d 120

-d 120は実行時間の上限（ここでは120分）を指定するタイムロックで、ハーネスがこれを機械的に強制します。実行中はダッシュボードが localhost:3400 で開き、ラウンドごとの状態や検証結果を確認できます。--allow-docker を付ければサンドボックス内で実行され、リモートのサンドボックス（HPC/GPU環境）にもSSH経由で対応します。

以下のシーケンス図は、ユーザーがCLIにゴールを渡してから、ハーネスがサンドボックスとgitを介して1ラウンドを回し、状態を次ラウンドへ引き継ぐまでの流れです。

sequenceDiagram
    participant U as ユーザー
    participant CLI as CLI (autofyn)
    participant H as ハーネス・オーケストレータ
    participant SB as サンドボックス
    participant G as gitリポジトリ

    U->>CLI: autofyn run new -p "ゴール" -d 120
    CLI->>H: ゴール・プリセット・予算を渡す
    H->>G: 永続状態 (run_state.md等) を読み込む
    H->>SB: 専門エージェント群へ探索・計画・ビルドを委譲
    SB->>SB: 候補を生成し検証器が採点
    SB-->>H: 型付き検証レコード (スコア・エビデンス) を返す
    H->>G: インカンベント更新・蒸留・git commit/push
    H-->>CLI: ラウンド結果を通知
    CLI-->>U: ダッシュボード (localhost:3400) で確認

チームの差し替えも可能です。.autofyn/subagents.json を編集すると、デフォルトのプランナー・ビルダー・レビュアー構成を、ML研究・形式証明・データ作業などドメイン特化のサブエージェントに入れ替えられます。各サブエージェントはロール別メモリファイル（例：architect.md, code-reviewer.md）を所有し、ビルダーとレビュアーの知識が相互に汚染されないよう分離されます。

ライセンスには注意が必要です。 コードはBSL 1.1（ソース利用可能）で公開されており、プロダクションや商用利用には商用ライセンスが必要です。ただしリリースから3年後には自動的にApache 2.0へ変換されるため、長期的には制約が緩和される設計です。トークンやリポジトリへの書き込み権限を与えるツールである以上、本番環境で動かす前には必ずサンドボックス上で検証し、設定した権限の範囲を確認しておくことを推奨します。

限界と注意点（批判的に読むための4点）

AutoFynの実績は印象的ですが、論文自身が認める限界も含めて、批判的に読むためのポイントを4つ挙げます。どれも「結果を額面通り受け取らない」ための注意事項です。

1. IMOの差分は「デプロイ全体」の比較であって「ループ単独」の効果ではない

IMO 2026の結果（例：GLM 5.2が20.7→32.0）は、検証器や永続状態を持ち込んだAutoFynと「提供元コーディングエージェント」の比較ですが、両者のエピソード長・ツールアクセス・検索方法・マルチエージェント構造はすべて異なります。つまり改善を「AutoFynループ単独の効果」と切り分けた測定ではなく、ハーネス全体を入れ替えた際の総合比較です。どの要素（フレッシュセッション／検証器／マルチエージェント／エピソード長）が効いたのかは未分離で、論文もこの但し書きを明記しています。

2. 「必ず改善する」保証は存在しない

構造的にはExpert Iterationに似ていますが、アルゴリズム的に同一ではありません。AlphaZero系のMCTSには「探索がアプレンティスより必ず良い結果を出す」という理論的保証がありますが、AutoFynにはそれがなく、改善は更新メカニズムからではなく「後の検証された性能」によってのみ確立されます。しかも検証器は誤った候補を受理したり、正しい候補を棄却したりし得ます。検証器の質がループ全体の質を決めるため、検証器が粗いと誤った受理が状態に蓄積し、以後のラウンドを汚染します。

3. 探索コストは単発タスクには過剰

探索ベースのループは、1回きりの単発推論より多くの計算を消費します。実運用では数百回のモデル呼び出しと多数のラウンドを消費するため、ゴールの受理や検証に数時間単位の時間を要します。コスト対効果が成立するのは「長時間続けば続くほど価値が出る」タスクであり、数分で終わる小さなタスクや、1回の回答で済む質問には明らかに過剰です。

4. 「検証可能な報酬」が前提であり、適用ドメインは限定される

AutoFynはタスク接地型の検証器を用意できる環境でしか回りません。READMEでも明言されているように、主観評価しかないタスクや評価器を新たに作れない領域には適用できません。逆に言えば、ベンチマーク評価器のあるデータサイエンス、エクスプロイト発火で判定できるセキュリティ監査、反証探索が可能な数学問題といった「客観シグナルが定義できるか」が導入判断の分かれ目になります。

最後に、数値の読み方にも注意が必要です。セキュリティの成果（13プロジェクト・150以上の脆弱性・16件のメンテナ確認）はすべて自己申告に基づいており、第三者の監査を受けているわけではありません。責任ある開示方針や内訳の公開は評価できますが、独立した検証を経るまでは「メンテナが確認した報告」として読むのが安全です。

よくある質問

AutoFynを実際に使う前に寄せられやすい質問を5つまとめました。設計思想と適用範囲を確認するための手引きとしてお読みください。

AutoFynはモデルのファインチューニングをするの？

しません。AutoFynはモデルの重みを完全に凍結したまま、ラウンド間で引き継ぐ「永続状態」（メモリファイル・レポート・リポジトリ状態・評価履歴）だけを更新します。これはパラメータ更新ではなく「文脈更新」であり、だからこそ非パラメトリックと呼ばれます。モデル本体を変更しないため、重みを公開していないフロンティアモデルにもそのまま適用できます。

「検証器」と「自己チェック」の違いは？

自己チェックはモデル自身が自分の出力を評価するため、LLMが自己訂正を苦手とする性質から誤りに騙されやすいです。一方、検証器は環境・実行・外部評価器が生成する客観シグナル（テスト実行・ベンチマーク採点・エクスプロイトの実機発火）に基づき、モデルの意見に依存しません。AutoFynではエージェントが自分の成功を認定することを禁止し、受理判定を必ず検証器に委ねています。

コンテキストが長くなる問題にはどう対処しているの？

毎ラウンドを空のコンテキストから開始し、前ラウンドの会話は一切再読み込みしません。情報は状態ファイルという固定インターフェースだけを通して復元されるため、コンテキストの長さは経過時間ではなく状態の量に追従します。これにより、長い文脈の中間部分が失われる「コンテキスト腐敗」が起きない構造になっています。

どのようなタスクに使える？ 使えないタスクは？

使えるのは、検証可能な報酬を定義できるタスクです。具体例は、ベンチマーク評価器があるデータサイエンス、エクスプロイトの発火で判定できるセキュリティ監査、反証探索が可能な数学問題です。逆に、主観評価しかないタスクや評価器を用意できないタスク、単発で終わる小さなタスクは向きません。後者は数百回のモデル呼び出しを伴う探索コストに見合わないためです。

IMO 2026の結果は「AutoFynの効果」と言っていいの？

注意が必要です。IMO 2026の結果は、エピソード長・ツール・検索・マルチエージェント構造を含むハーネス全体を入れ替えた比較であり、論文自身も「ループ単独の効果は分離していない」と明記しています。とはいえ、モデル本体を一切変えずにGLM 5.2が20.7→32.0（+11.3点）でメダル帯へ達した事実は、ハーネス設計が性能に与える影響の大きさを示す強いエビデンスです。

まとめ

AutoFynは、長時間稼働エージェントが直面する「コンテキスト腐敗」「自己評価の限界」「失敗の反復」という3つの壁を、フレッシュセッション・接地された検証・状態への蒸留という3つの原理で同時に乗り越えるエージェント・ハーネスです。モデルの重みは一切変えず、ラウンド間で引き継ぐ永続状態だけを更新するため、ファインチューニングが不可能な非公開モデルにも適用できます。

その本質は、古典的なExpert Iterationを「重み空間」から「コンテキスト空間」へ移植した点にあります。見習いポリシー・エキスパート手続き・パラメータ更新という構成を、文脈ポリシー・検証器に接地されたレビューループ・永続状態更新に対応させる構造的アナロジーです。ただしこの対応に理論的な保証は伴いません。MCTSのような「必ず改善する」保証はなく、改善は更新メカニズムから仮定されるのではなく、後の検証された性能によってのみ確立されます。

ドメイン 検証器 主な成果
オリンピアード数学（IMO 2026） 反証探索と完了ベース採点 GLM 5.2が20.7→32.0（+11.3点）、メダル帯を跨ぐ
データサイエンス（Spider 2.0 dbt） ベンチマーク評価器 1位エージェント（65.60点）を自律構築
セキュリティ監査 エクスプロイトの実機リプロダクション 13プロジェクトで150以上の脆弱性、16件メンテナ確認

3ドメインの実績が示すのは、検証器を用意できる環境なら「モデルを変えずにエージェントを強くする」ループが汎用的に機能するという事実です。エージェントの性能は「モデル×ハーネス」で決まる時代に入り、AutoFynはその最前線の具体的な設計書として、実装ごと公開されています。

最後に、読者の次の一手をひとつ提案します。まず自分のタスクに「客観的な検証器」を定義できるかを問うことです。それができるなら、AutoFyn型のラウンドループはどのドメインにも適用できるはずです。

参考資料

関連記事