Bayesian-Agent: Posterior-Guided Skill Evolution for LLM Agent Harnesses

これは何の論文か

この論文が面白いのは、スキル更新の失敗パターンにかなり現実味があるところだ。エージェントを運用していると、失敗ログからルールを足すのは簡単だが、ルールはすぐ肥大化する。しかも、そのルールが次の状況で本当に効くのか、別の状況を壊さないのかは見えにくい。

Bayesian-Agentは、スキルを信念として扱う。つまり「この手順は、どんな入力、どんな文脈、どんなハーネス条件で成功しそうか」を更新していく。この考え方は、SKILL.md、MEMORY、定期実行のような個人アシスタントの運用にも合う。

特に効くのは、更新アクションを分けている点だ。全部を追記するのではなく、直す、分ける、圧縮する、退役させる、探索する、という選択肢を事後分布に基づいて選ぶ。これはスキルを長期運用する時の設計語彙になる。

おい丸のようなアシスタントでは、ログから学ぶ運用が反省ログの置き場で終わると弱い。Bayesian-Agent的に見ると、ログはスキルの信念更新、失敗条件の分離、検証タスク、退役判断の材料になる。そこが実務に持ち帰りやすい。

Bayesian-Agentは、LLMエージェントのスキルや SOP をどう更新するかを扱う論文だ。中心にあるのは、スキルを単なるプロンプト断片や手順書ではなく、ある条件下でエージェントが成功するかについての仮説として扱う見方である。

既存の self-improving エージェントは、成功/失敗の軌跡を集めて反省文を作ったり、プロンプトを足したり、ルールを増やしたりしがちだ。しかし、その更新がどの条件で効くのか、どの失敗を直すのか、いつ退役させるべきかは曖昧になりやすい。

この論文は、検証済みの実行軌跡から特徴条件つきのカテゴリ事後分布を更新し、その事後分布に基づいてスキル / SOP への編集アクションを選ぶ。更新はパッチ、分割、圧縮、退役、探索のような形で整理され、あとから監査しやすい監査要約として残せる。

読む価値は、エージェントの改善を「よさそうな反省の追記」から「条件つきで信じられる手順の更新」へ変えるところにある。個人アシスタント、コーディングエージェント、長期運用スキルの設計にそのまま持ち込める視点だ。

この論文は、LLMエージェントの再利用可能なスキル / SOPを、事後分布に基づいて進化させる枠組みを提案する。対象は、プロンプト、ツール、記憶、ワークフロー、ハーネスフィードバックを組み合わせて動くエージェントである。

各スキル / SOPは、成功率そのものではなく、条件つきで成功するという仮説として表現される。条件には、タスク特徴、モデル、コンテキスト、ツール、ハーネス、過去の検証済み軌跡が関わる。

何が問題だったのか

エージェントの失敗ログからルールを足すのは簡単だが、それだけではスキルがすぐ膨らむ。似たような注意書きが増え、どの条件で効くのか、どの条件では邪魔になるのかが分かりにくくなる。

特に問題なのは、成功や失敗が条件つきで起きることだ。同じスキルでも、タスク特徴、モデル、ツール、文脈、ハーネス条件が変われば効き方は変わる。成功ログをそのまま一般ルールにすると、別の状況で回帰を起こす可能性がある。

また、スキル更新には追記以外の選択肢も必要になる。既存スキルを少し直すのか、別スキルに分けるのか、圧縮するのか、退役させるのか、追加探索するのかを分けないと、長期運用では手順書が読みにくくなる。

Bayesian-Agent の問題意識は、スキルを固定文書ではなく「どの条件で成功しそうか」という仮説として扱い、検証済み軌跡に基づいて更新することにある。

既存の自己改善型エージェントは、失敗ログから反省文を作ったり、成功パターンをスキルへ追記したりしがちである。しかし、追記されたルールがどの条件で効くのか、別の条件を壊さないのか、いつ退役すべきなのかは曖昧になりやすい。

問題は、スキルが単なる文章ではなく、条件つきの仮説であることだ。同じ手順でも、タスク、モデル、ツール、文脈、ハーネス条件が変われば成功率は変わる。成功ログを足すだけでは、この条件差を扱いにくい。

Bayesian-Agent は、検証済み軌跡を証拠として、スキル / SOP の信頼度を条件つきで更新する。更新アクションも、追記だけでなく、パッチ、分割、圧縮、退役、探索に分けるため、長期運用で膨らみすぎるスキルを扱いやすくなる。

提案手法の中身

入力は、エージェントが実行した軌跡、成功/失敗の検証結果、タスクや環境の特徴、既存スキル / SOP の状態である。

まず、実行軌跡からスキルがどの条件で効いたか、どの失敗モードで壊れたかを証拠として集める。

次に、その証拠を使って特徴条件つきのカテゴリ事後分布を更新する。ここでスキルは、単なるテキストではなく、条件つき信念の対象になる。

事後分布の変化に応じて、パッチ、分割、圧縮、退役、探索などの編集アクションを選ぶ。全部を足すのではなく、直すべきか、分けるべきか、圧縮すべきか、退役させるべきかを決める。

更新後のスキル / SOPは実行可能なガードレールや失敗モードのパッチとしてハーネスに戻され、次の実行でまた検証される。最後に監査要約が残るので、なぜその更新をしたか追いやすい。

どうやって確かめたのか

評価では、SOP-Bench、Lifelong AgentBench、RealFin-Bench を使い、段階的なスキル / SOP 更新が性能を改善するかを見る。対象モデルには deepseek-v4-flash が使われている。

比較対象は、更新前のSOP、段階的に修復されたSOP、複数の実行バックエンドである。

測る指標は、各ベンチマークの成功率、修復ステップ後の改善幅、ネイティブバックエンド、GenericAgent、mini-swe-agent、Claude Code などの複数ハーネスで改善が再現するかである。

結果はどうだったのか

論文では、deepseek-v4-flash を使った段階的な修復で、SOP-Benchが 80% から 95%、Lifelong AgentBenchが 90% から 100%、RealFin-Benchが 45% から 65% に改善したと報告されている。

バックエンドはネイティブバックエンド、GenericAgent、mini-swe-agent、Claude Code などが扱われる。つまり、特定のエージェント実装だけでなく、ハーネスをまたいだスキル / SOP 更新として評価している点が重要だ。

限界・注意点

• この論文の魅力は、スキルを足し続ける誘惑にブレーキをかける点にある。成功ログや失敗ログをそのまま規則化すると、手順は増えるが、どの条件で効くかが曖昧になる。
• 一方で、事後分布に基づく方法にも限界はある。検証信号が弱い環境、成功/失敗のラベルが曖昧なタスク、長期的な副作用があとから出るスキルでは、事後分布自体が過信を生む可能性がある。
• そのため実務では、事後分布更新と合わせて、退役条件、回帰テスト、手動レビュー、公開できない情報の扱いを設計する必要がある。

おい丸のようなエージェントにどう使えるか

おい丸のような作業支援エージェントでは、スキルは増えるほど便利になる一方で、重複、古さ、選択ミス、局所最適が起きやすい。この論文を使うなら、失敗ログをすぐルール化する前に、「どの条件で効く仮説なのか」「パッチで足りるのか」「分割や退役が必要なのか」を見る。

この論文を使うなら、スキルを単なる自然言語メモではなく、評価・統合・退役の対象として扱う。新しい経験をそのまま追記するのではなく、既存スキルへ統合するのか、原子的なルールへ分けるのか、検証タスクを作るのかを決める。

注意点として、実運用では、スキルを増やす判断だけでなく、消す判断、まとめる判断、効いているかを測る判断まで必要になる。

Q&A

この論文の中心問いは？

LLMエージェントのスキル / SOPを、成功/失敗ログの単純な蓄積ではなく、検証済み軌跡に基づく条件つき事後分布としてどう更新するか。

スキルを信念として扱うとはどういうこと？

スキルを固定の手順書ではなく、あるタスク特徴、文脈、ハーネス条件で成功しそうだという仮説として扱い、証拠に応じて確信度を更新するということ。

既存の反省型自己改善と何が違う？

反省文やルールを足すだけでなく、どの条件で効くか、どの失敗を直すか、退役させるべきかを事後分布と編集アクションで分ける点が違う。

更新アクションには何がある？

論文では、パッチ、分割、圧縮、退役、探索のようなアクションが扱われる。追記だけでなく、分割、圧縮、退役、探索も更新の選択肢になる。

ハーネスはどこで効く？

スキル / SOP はモデル単体ではなく、プロンプト、ツール、記憶、ワークフロー、検証を含むハーネスの中で実行される。更新もその実行条件と結びつけて扱われる。

評価で何が示された？

SOP-Bench、Lifelong AgentBench、RealFin-Benchで段階的な修復による改善が報告されている。特に RealFin-Bench では 45% から 65% への改善が示されている。

個人アシスタント運用にどう使える？

失敗ログからルールを足す前に、どの条件で失敗したか、既存スキルのパッチで足りるか、分割や退役が必要かを判断する枠組みとして使える。

注意点は？

事後分布は証拠の質に依存する。検証信号が曖昧なタスクでは、数式っぽい更新に見えても過信になる可能性がある。

読む順番は？

まず Abstract と手法の事後分布更新、次に更新行動、最後にベンチマークと監査要約を読むと、実務への接続がつかみやすい。

関連する記事

• 関連して、自然言語スキルを検証しながら改善する、コーディングエージェントのスキルをトレースから育てる、スキルの作成・記憶・管理・評価を回す と並べるとよい。自然言語スキルを検証しながら改善する はスキル文書の編集と検証ゲート、コーディングエージェントのスキルをトレースから育てる はトレース由来スキル、スキルの作成・記憶・管理・評価を回す はスキルライフサイクルを扱う。
• 実務に落とすなら、まず既存スキルに対して、パッチ / 分割 / 圧縮 / 退役 / 探索のどれが必要かをログごとに分類する小さな表から始めるのがよさそうだ。