跳转至

Agent の継続的進化

今日の Agent は、明確な能力上のパラドックスに直面している。未知の複雑なタスクをゼロショットで解決できる一方、類似タスクを一万回処理した後でも、翌日に初日と同じ誤りを犯す可能性がある。経験から自律的に学習できるかどうかは、Agent が「タスクを完了できる」段階から「信頼性をもって働ける」段階へ進むための重要な能力となりつつあり、次世代モデルの中核的な研究課題でもある。しかし現時点では、モデル自体の継続学習能力は依然として大きく不足している。

その理由は、デプロイ後のモデルが、一度の推論によって自動的にパラメータを変更するわけではないことにある。第2章で論じたコンテキスト学習、状態維持、圧縮により、Agent は現在のタスク内で適応できる。しかしコンテキストが終了すると、その変化が次のタスクへ自然に引き継がれることはない。対話をメモリに保存しても、新しい行動を学習したことにはならない。生の軌跡は長大になり得るうえ、有効な戦略だけでなく、偶然の成功、誤った原因帰属、信頼できない入力も含まれるからである。

ここには混同しやすい重要な違いがある。経験を保存することは、経験から学ぶことと同じではない。100本の軌跡を長いコンテキストやベクトルデータベースに入れれば、必要なときに特定の事例を思い出す助けにはなる。しかし、成功した軌跡でどの手順が繰り返し現れたのか、旧バージョンのインターフェースでしか通用しない方法はどれか、ある成功が正しい戦略によるものか環境上の偶然によるものかを、事例横断で自動比較してくれるわけではない。学習は、システムが「評価、比較、帰納、検証」を能動的に行った後に生じるのであり、ログをディスクへ書き込んだ瞬間に生じるのではない。第3章のユーザーメモリは主に「ユーザーと世界がどのようなものか」を蓄積する。本章の経験学習はさらに、「どの条件で、どのように行動すべきか」を蓄積する。前者は Agent の記憶を増やし、後者が初めて Agent を賢いだけの存在から熟練した存在へ変える。

では、各タスクの終了後にモデル自身を直接訓練すればよいのではないか。実運用環境では、クリーンな学習信号が得られることはまれである。ユーザーの満足はコンプライアンスを意味せず、テストの通過も失敗したテストケースを削除した結果かもしれない。一度の局所的な更新が、能力の忘却、戦略のドリフト、安全性の低下を引き起こす可能性もある。稼働中のモデルが未検証のフィードバックに基づいて自身を直接変更することを許せば、誤った経験やプロンプトインジェクションが固定化され、後続タスクで継続的に増幅されかねない。基盤モデルの定期的な訓練は汎用能力を向上させられるが、各 Agent が日々遭遇する非公開ルール、ツールの変更、局所的な経験を即時に取り込むことはできない。

したがって、モデル自体がまだ信頼性の高い継続学習を実現できない段階では、まず「学習」をモデル周辺の自律的なシステムとして構築しなければならない。すなわち、実行証拠を記録し、結果とプロセスを検証し、複数の軌跡から共通性を抽出したうえで、知識、指示、プログラム、モデルパラメータのいずれを更新すべきか判断する。すべての変更はまず候補バージョンとして作成し、回帰テストと安全性検査を通過して初めて、次回以降の実行を変更できる。これはモデルの学習能力を代替するものではなく、現在の技術条件の下で Agent に継続学習能力を持たせるための工学的経路である。

これまでの各章では、このシステムに必要な主要構成要素を示してきた。第2章はタスク内状態を扱い、第3章は知識基盤を提供し、第5章は Agent にツールを作成してシステムを変更するメタ能力を与え、第6章は評価と検証を確立し、第7章はモデルパラメータの更新方法を説明した。第8章の役割は、これらの構成要素を図8-1に示す継続的進化の閉ループとして組織化することである。

図8-1 Agent の継続的進化における全体的な閉ループ

継続的進化には、追跡可能な実行経験に基づき、その後の行動を変化させ、明白な劣化を引き起こしていないことを検証する必要がある。本章ではまず、一度の実行について、どこが優れており、どこが誤っていたのかを判断する方法を論じる。次に、4つの更新方法とその適用範囲を比較し、最後に、それらの更新を長期運用の中でどのように検証、リリース、修正、廃止するかを論じる。

実行軌跡から学習信号を得る

継続的進化の起点は「要約」ではなく「評価」である。システムがタスクの完了可否を把握できず、どのステップが成功または失敗をもたらしたかも分からなければ、言語モデルが生成する反省は推測にすぎない。誤った評価が長期知識、システム Prompt、訓練データに入ると、その影響は後続タスクをまたいで増幅され続ける。

結果を比較的容易に検証できるタスクもある。Coding Agent はテスト、型検査、性能ベンチマークを実行できる。ユーザーに代わって返金を処理する Agent は、注文状態と実際の返金額を照会できる。この種の信号は環境内の実状態から得られるため、通常はモデル自身による行動の説明より信頼できる。ただし、結果が正しいことは、プロセスが正しいことを意味しない。失敗したテストケースを削除してもテストは通過し、「7日以内に返金いたしますので、しばらくお待ちください」と口頭で約束するだけでも、一時的に満足度の高いフィードバックを得られる可能性がある。したがって、信頼できる評価では、結果だけでなく、その結果を達成した経路も検査しなければならない。

より多くのタスクには、単一の正解が存在しない。カスタマーサービスが忍耐強く対応したか、コンプライアンスの範囲内で代替策を提示したか、調査報告が重要な証拠を捉えたか、生成テキストが自然かつ簡潔かは、いずれも文脈に基づいて判断する必要がある。この場合、第6章で紹介した LLM-as-a-Judge を利用できるが、Judge に曖昧な総合点だけを与えさせるべきではない。より効果的なのは、評価基準（Rubric）を事前に定義し、検証器に項目別の採点と軌跡証拠の引用を求め、証拠が不十分な場合には不確実であることを明示させる方法である。

図8-2は、3層の検証構造を示している。最下層の結果検証器は、テスト結果、データベース状態、ツールの戻り値を読み取り、「実際に処理が完了したか」に答える。中間層のプロセス検証器は、業務ルール、権限、アクション列を検査し、「許可された方法で完了したか」に答える。上位層の品質検証器は Rubric に基づいて言語と戦略を評価し、「適切に処理したか」に答える。下位に位置する指標ほどコードと環境のグラウンドトゥルースに依存すべきであり、形式化が困難な部分だけを言語モデルに委ねるべきである。

図8-2 環境の結果から LLM Rubric までの3層軌跡検証

カスタマーサービス Agent を例にすると、有用な Rubric は少なくとも表8-1に示す複数の次元を含むべきである。最初の5項目は主として最低限の要件を制約し、後の2項目はサービス品質を測定する。この分解は、「ユーザーが満足したか」よりも診断価値が高い。ユーザーは Agent が規則に違反して返金したために満足することも、コンプライアンス上の制約によって不満を抱くこともあるため、単一の満足度では両者を区別できない。

表8-1 カスタマーサービス Agent の軌跡評価次元

次元 検証事項 主な証拠
タスク結果 ユーザーの中核的な要求が解決されたか 最終的な環境状態、ツール結果
ルール遵守 ポリシー、権限、必須プロセスに違反していないか ポリシー庫、アクション軌跡
プライバシー境界 提供すべきでない情報を漏えいしていないか 応答テキスト、データアクセス記録
事実の信頼性 記述が知識またはツール結果によって裏付けられているか 引用元、ツールの戻り値
約束と行動の一貫性 完了したと主張する操作が実際に行われたか 応答とツールログの照合
表現品質 自然かつ簡潔で、反復やテンプレート化を避けているか 対話全文、言語 Rubric
コンプライアンスに沿った代替対応 当初の案が実行不可能な場合、許可された代替経路を見つけたか ユーザー目標、ポリシー、後続アクション

このうち「約束と行動の一貫性」は、特に Agent のシナリオに適している。従来のテキスト評価は最終応答だけを読み、「返金を申請しました」という発言を良好なサービスとみなしやすい。これに対し、軌跡評価では、実際に返金ツールが呼び出されたか、呼び出しが成功したか、注文状態が変更されたかをさらに検査する。「コンプライアンスに沿った代替対応」も、モデルが恣意的にルールを破ることを奨励するものではない。ユーザーの真の目標を理解し、返金が不可能な場合に、変更、延期、一部補償などの合法的な選択肢を確認することを求めるものである。

検証結果を単一のスカラーに圧縮すべきではない。一度の軌跡評価は、むしろ構造化された診断に近い。たとえば、タスクは部分的に成功し、ルール遵守は合格したが、証拠のない記述が1か所、虚偽の約束が1か所あり、さらに応答内でポリシーを3回繰り返し説明した、という形である。次元別の信号は、問題の性質と証拠の位置をともに保持する。これにより後続モジュールは、証拠のない記述が知識不足、引用要件の欠如、モデル能力不足のいずれに起因するのか、また虚偽の約束に対して Prompt を修正すべきか、Harness に応答とツール状態の一貫性検査を追加すべきかを判断できる。

LLM 検証器自体も較正する必要がある。実運用システムでは通常、専門家がアノテーションした少量の軌跡を用意し、各次元における検証器の一貫性を確認する。高リスクまたは低信頼度のケースは、別のモデルまたは人間による再確認に回す。モデルのバージョン変更後には、較正セットを再実行する。検証器は評価と証拠の提示を担当し、Agent のどの部分を変更すべきかは独立した診断・進化モジュールが決定すべきである。これにより、同一モデルが審判を務めると同時にルールを直接書き換える事態を避けられる。

実験 8-1 ★★：カスタマーサービス Agent の軌跡検証器を構築する

実験目標：1本のカスタマーサービス実行軌跡を、後続の学習に利用できる構造化診断へ変換し、「多次元の結論と証拠」が単一の総合点より根本原因を特定しやすいかを検証する。

データと手順：正常な返金、虚偽の約束、プライバシー漏えい、過剰な拒否という4種類の、専門家ラベル付き軌跡を用意する。第1層は注文の最終状態とツールログを読み、返金または変更が実際に行われたかを判定する。第2層は業務ポリシーと手順ごとに照合し、権限、必須プロセス、プライバシー、事実の根拠、約束と行動の一貫性を検査する。第3層は表8-1の Rubric に従って表現品質とコンプライアンスに沿った代替対応を評価し、失敗判定には証拠となるターンを残す。デフォルトの品質 Judge は決定論的ルールを使い、実際の LLM Judge も提供する。上位層でどのモデルを使う場合でも、結果層とルール層を言語モデルの推測に委ねない。

対照と指標：ベースラインは総合点だけを出力し、実験群は次元ごとの pass、fail、uncertain、証拠、信頼度を出力する。較正段階では、失敗検出の適合率と再現率を次元別に集計し、専門家ラベルとの完全一致率も報告する。同時に、虚偽の約束などの失敗について、結論だけでなく空でない証拠が提示されているかを確認する。

受け入れ基準：検証器は重大な違反、虚偽の約束、過剰な拒否を安定して識別しなければならない。高い総合点がプライバシーやルール次元の失敗を覆い隠してはならない。低信頼度または高リスクのケースは、自動的に学習信号へ変換せず、2つ目の検証器または人間による再確認へ送る。

関連実装は trajectory-verifier を参照されたい。デフォルトではオフラインで再現可能な品質 Judge を使用し、--judge llm を指定すると、実装済みの実際の LLM 検証器を実行できる。

Agent の継続的進化における4つの方法

学習信号は Agent が変化すべきことを示すが、その変化をどこで生じさせるべきかは示さない。更新方法を選択する第一の基準は、経験がどれほど長く存在したかではなく、対象能力を特定の媒体で自然に表現できるかどうかである。事実や経験は知識文書として記述するのに適している。明確に言語化できる戦略は Prompt または Skill に記述するのに適している。正確に実行できるプロセスや制約はプログラムとして記述するのに適している。知覚、言語スタイル、暗黙的な戦略などの高次元能力は、モデルパラメータに組み込む必要がある。図8-3は、この4つの方法とその関係を示している。

図8-3 継続的進化における4つの更新方法

表8-2に簡潔な比較を示す。4つの方法は相互排他的ではない。医用画像 Agent はパラメータによって病変を識別し、知識ベースから最新ガイドラインを提供し、コードによってリスク指標を計算する。カスタマーサービスモデルの自然な口調は後訓練によって獲得され、個別企業のポリシーは知識と Skill によって提供され、重要なコンプライアンスはサーバー側コードによって最終的に保証される。

表8-2 4つの継続的進化方法の適用範囲

更新方法 適した内容 主な利点 主な制約
経験知識ベース 事実、経験則、例外、情報源 更新が速く、追跡可能で、必要に応じて検索できる 検索とモデルによる正しい適用に依存する
Prompt と Skill 言語化可能な判断原則と運用規範 説明可能で、適用範囲を制御できる 肥大化、衝突、無視が生じやすい
プログラムと Harness 決定論的なプロセス、ツール、強い制約 テスト可能で、実行が安定し、コストが低い 開発・保守コストが比較的高い
モデルパラメータ 高次元の知覚、生成スタイル、暗黙的戦略 汎化能力が高く、推論オーバーヘッドが低い 更新と回帰検証のコストが高い

経験を知識として蓄積する

最も軽量な進化方法は、複数回の実行で繰り返し現れた経験を、検索可能な知識文書として整理することである。ここでいう「経験知識ベース」は、第3章とストレージ、インデックス、検索技術を共有するが、知識の情報源と検証目標が異なる。第3章では主に、ユーザー対話、文書、データセットから「ユーザーと世界がどのようなものであるか」を抽出した。これに対し本章では、Agent の行動軌跡と結果から「どの条件でどのように行動すべきか」を抽出する。たとえば、「この航空会社では特別食を24時間前までに予約する必要がある」はドメイン知識であり、「航空券を予約する前に特別食の締切を確認し、支払い後に要望を満たせないことが判明する事態を避ける」は行動経験である。

生の軌跡は、正式な知識単位として適していない。長くノイズが多いうえ、ツールの生出力、偶発的な迂回、環境の詳細を含むからである。より堅牢なシステムでは、3層のデータを保持する。変更不能な生の軌跡を監査用に保存し、単一実行の分析に今回の成否と教訓候補を記録する。さらに、同種の複数軌跡を比較、クラスタリング、帰納し、将来に向けた Markdown 知識文書を形成する。正式な文書には通常、一度のタスクの全プロセスを再記述するのではなく、適用場面、推奨戦略、禁止事項、例外条件、証拠の出典、直近の検証時刻を明記する。

この設計は、第3章の User-as-Code と同じ2段階の考え方を採用している。User-as-Code では、まず対話中の事実を変更不能なログに追記し、その後、構造化されたユーザーモデルを定期的に再構築する。経験学習も同様に、まず証拠を保存し、その後オフラインで変更可能な知識を生成すべきである。図8-4は、このプロセスを示している。記録と整理を分離することで、一度の偶発的な成功やネットワーク障害が即座に Agent を変化させることを防げる。また、複数の成功と失敗を確認したうえで共通性を判断できる。

図8-4 評価済み軌跡から経験知識文書への変換

経験文書は、単なる軌跡の要約ではない。真に転移価値のある内容は、比較対照から得られる。同種の成功軌跡が何を行い、失敗軌跡に何が欠けていたか、ある戦略がどの環境バージョンで有効であり、どの前提条件で失敗したかを明らかにする必要がある。第3章では知識抽出、クラスタリング、検索をすでに紹介したため、本章ではこれらのアルゴリズムを繰り返さず、軌跡評価がどのように抽出条件となるか、また抽出された知識が後続タスクの性能を向上させるかに重点を置く。

完全な知識精製パイプラインは5段階に分けられる。まず変更不能な軌跡と環境結果を保存する。次に、単一実行についてタスク種別、必要な能力、観察された戦略、誤り、例外を列挙した構造化分析を生成する。続いて同じタスク群の実行を集約し、候補規則ごとに「どの軌跡が支持し、どの軌跡が反証するか」を示す証拠表を作る。支持のしきい値に達した候補だけを正式文書へ書き込み、最後に、精製に使っていない新規タスクで転移効果を試す。正式知識と候補分析を別々のストアに置けば、原証拠を改ざんせずに再帰納でき、環境バージョンが変わったときには特定の結論だけを正確に取り消せる。

GAIA の経験学習は直感的な例である。GAIA2 は、検索、Webページの読解、ファイル処理、計算を組み合わせる必要がある多段階問題を収録する。一方、AWorld3 は Agent を実行し、それらのツールを呼び出し、軌跡を保存する実行環境を提供する。前者が試験問題なら、後者は試験会場と実験記録システムに相当する。従来の方法は、タスクが一度成功するとすぐに戦略要約を生成し、ベクトル化してライブラリへ保存していた。より厳密な実装では、まず GAIA の正解検証または別の環境検証器によって成功、部分的成功、失敗を付与し、その後、同じタスク群の複数経路を比較する。成功軌跡は戦略候補を、失敗軌跡は排除的知識を提供し、部分的成功の軌跡は「どの部分が有効で、どの部分にまだ問題があるか」を識別する助けとなる。Reflexion1 が提案した自然言語による反省は教訓候補の生成に利用できるが、反省自体は証拠ではない。環境結果と一致し、軌跡横断的な支持を得て、新規タスクで正の転移を示した内容だけを正式な経験文書に組み込むべきである。

実験 8-2 ★★：GAIA 軌跡から経験知識文書を抽出する

実験目標：「複数軌跡から作った知識文書」が「一度の成功を要約して記憶する方法」より転移しやすく、偶発的成功や誤った経験による負の転移を抑えられるかを検証する。

データと手順：gaia-experience は各実行の完全な軌跡と外部の environment_score を保存し、それを task_family、必要な capabilities、applies_when、観察された戦略、誤り、例外、出典軌跡 ID からなる最小の学習記録へ変換する。結果検証器は実行を成功、部分的成功、失敗に分類する。学習モジュールは同じタスク群の経路を比較する。LLM は帰納候補を提案できるが、推奨戦略には少なくとも2本の非失敗軌跡による支持が必要である。最終的な Markdown 文書には、適用場面、推奨戦略、一般的な誤り、例外条件、出典、直近の検証時刻を含める。適用時にはこれらの文書だけを検索し、長大な生の軌跡を直接コンテキストへ入れない。

3つの対照群：第1群は過去の経験を使わない。第2群は現在のタスクに最も似た単一軌跡の要約を検索する。第3群は複数軌跡に共同で支持された知識文書を検索する。学習セットと転移セットは重複させず、同じ GAIA 問題の答えが「経験」として評価へ漏れるのを防ぐ。

指標と受け入れ基準：転移タスクの成功率、平均検索文字数または Token 数、負の転移率を同時に報告し、各正式結論に出典軌跡が列挙されているかを確認する。複数軌跡の文書がコンテキストを短くしただけで新規タスクの性能を高めていなければ、経験を学習した証明にはならない。一度の偶発的成功を正式知識へ昇格できる場合や、文書を原軌跡まで追跡できない場合も不合格とする。

関連実装は gaia-experience を参照されたい。demo_documents.py はデフォルトでオフライン実行され、--extractor llm を指定すると、実際の LLM が軌跡横断的な経験候補を提案できる。

経験を指示として記述する

経験知識ベースは Agent に参考資料を提供するが、Prompt と Skill はより強い指示性を持つ。複数の軌跡で同種の戦略的誤りが繰り返し明らかになり、その規則を自然言語で明確に表現できる場合、システムはそれを「参照可能な経験」から「遵守すべきルール」へ昇格できる。ほぼすべてのタスクに適用されるルールはシステム Prompt に組み込むのが適している。特定のドメイン、プロジェクト、ツールにのみ適用される複雑なプロセスは、オンデマンドで読み込まれる Skill またはプロジェクト指示ファイルとして記述するのがより適切である。

Prompt 学習と第2章の Prompt エンジニアリングでは、役割が異なる。第2章では、構造が明確でキャッシュに適した Prompt の書き方を扱った。ここでは、どのような実運用フィードバックが Prompt の変更を引き起こすに足るか、また新ルールをデプロイ前にどのように検証するかを扱う。変更に際して、システム Prompt 全体を繰り返し書き直すべきではない。より信頼できる方法は、同種の失敗群に基づいて最小限の diff を生成し、ルールの適用範囲を明記し、既存ルールとの矛盾を確認したうえで、失敗を引き起こした境界ケースと既存タスクの保持セットを同時に評価することである。

Andrej Karpathy は2025年の長文投稿で、この新しい可能性のあるパラダイムを暫定的にシステムプロンプト学習（System Prompt Learning）と呼んだ7。彼の整理では、事前学習は主に知識を学び、微調整は主に習慣的な行動を形づくる。しかし人間には、問題に直面し、方法を理解した後、未来の自分に「次にこの種の問題に出会ったら、まずこの方法を試す」と明確な言葉で伝える学び方もある。彼は、このメモ帳を持たない LLM を映画『メメント』の主人公になぞらえた。また、システムプロンプト学習と強化学習はいずれも経験から行動を改善するが、更新アルゴリズムが異なると指摘した。前者は文章を編集し、後者は勾配降下でパラメータを変更する。例として、当時約1万7千語あった Claude のシステムプロンプトには、単語、文字、文字数を数える問題に遭遇したら、まず各項目に番号を振って明示的に数えてから答えるよう、特別な指示が含まれていた。これはまさに「strawberry には r がいくつあるか」のような問題に対処するためである。

Agent システムに落とし込むと、失敗後に言語化できる教訓を、将来の実行が直接読めるルール候補として記述することになる。「成功／失敗」だけのスカラー結果に比べ、証拠付き診断は、問題が本人確認、ツール選択、エスカレーション境界のどこにあったかを示せるため、より的を絞った修正候補を生成できる。Karpathy のいう「知識に導かれた振り返りは、スカラー報酬より高次元のフィードバックチャネルを持つ」という見方は、この方法が高いデータ効率を持ち得る理由を説明する。ただし情報量が多いからといって、それが本質的に正しいわけではない。同じユーザー意見でも、特定の顧客または旧版ポリシーにしか当てはまらない場合があるため、クラスタリング、適用範囲の判定、回帰テストはなお必要である。

Prompt の自動最適化には、すでに複数のアプローチがある。DSPy4 は、複数の言語モデル呼び出しから成るプログラムを最適化対象とし、開発セット上で指示と例を探索する。OPRO5 は、過去の Prompt とその得点に基づいて言語モデルに次の候補を提案させる。GEPA6 は、失敗軌跡についての自然言語による反省を使い、相互補完的な Prompt 候補を生成して選別する。これらは主にオフライン評価セット上での一括最適化を対象とする。実運用システムの最小 diff は、むしろ継続的な保守に近く、新たな境界ケースを契機として、出典、監査、迅速なロールバックを重視する。実際には、まずオフライン探索で良好な初期版を見つけ、その後は事例ごとのパッチでリリース後のロングテール規則を維持できる。

たとえば、航空会社のカスタマーサービス Agent が、ユーザーからポリシーへの疑義を示された際、時期尚早に人間へエスカレーションすることが頻発しているとする。軌跡評価では、ルール違反はないが、コンプライアンスに沿った代替対応が不足していることが示される。候補パッチでは、まずポリシーを説明し、ユーザーの真の目標を特定し、許可された代替案を探し、ユーザーが明示的に要求した場合、または実際に権限を超える場合にのみ人間へエスカレーションするよう Agent に求められる。新ルールによって過剰なエスカレーションが減少しても、人間へ引き継ぐべき安全上の事象を処理し続けるようになれば、回帰テストには合格していない。システム Prompt 学習の価値は、より多くの文を自動追記することではなく、実運用上の境界ケースによってルールの適用範囲を継続的に明確化することにある。

Skill 学習も同じ原則に従うが、適用範囲はより局所的である。Skill は必要なときに開く職務手順書と考えられる。複数の経験が共同して完全な保険金請求プロセスを形成する場合、システムは対応する Skill を生成または修正できる。候補 Skill は一度の対話の要約にとどまらず、少なくとも、いつ読み込むか、前提条件、操作手順、既知の落とし穴、検証方法を記載し、出典軌跡も保存すべきである。システムはまず既存の Skill ライブラリから類似能力を検索する。同じ手順が存在するなら局所的な patch を優先し、本当に新しい独立能力が現れた場合だけ新しいディレクトリを作り、名称だけ異なり内容が似た手順書の乱立を防ぐ。Anthropic の Skill Creator8 は「草案作成―テスト―評価―改訂」という生成サイクルを示している。これは Skill の作り方と改善方法を解決するが、どの実行証拠が生成を起動するに足るか、衝突をどう処理するか、変更後に領域タスクと旧タスクの回帰を通過できるかが、依然として難しい問題である。

実験 8-3 ★★：失敗軌跡に基づいてシステム Prompt を最適化する

実験目標：航空会社のカスタマーサービス Agent に、「ユーザーがポリシーを疑ったときに時期尚早に人間へエスカレーションする」失敗軌跡から学ばせる。同時に、新ルールが本当に人間への引き継ぎを必要とする旧場面を壊していないことを証明する。

手順：まず旧タスク保持セットと過剰エスカレーション境界セットを別々に実行する。learning_signal.py は失敗をルール遵守、タスク解決、コンプライアンスに沿った代替対応という3次元に分け、出典 case ID を保持する。次に Coding Agent は既存 Prompt を読み、監査可能な old_str → new_str 形式の最小編集を1件だけ生成する。Agent に、まずポリシーを説明し、真の目標を特定し、適法な代替案を探すよう求める一方、ユーザーが明示的に人間を求めた場合や安全上の事象がある場合のエスカレーション経路は残す。パッチは出典、対象ルール、変更理由とともに候補 manifest へ記録する。

3つの対照群：初期 Prompt、自動生成した候補 Prompt、人間が一度だけ調整した Prompt を比較する。3者は同一モデルと同じ保持／境界タスク群を使用する。--quick はケース数を減らすだけで、タスク Agent、LLM Judge、Coding Agent を実際に呼び出すため、オフラインの模擬結果とはみなせない。

リリース基準と指標：候補は、パッチが空でない、出典を追跡できる、境界セットの性能が実際に改善する、保持セットが劣化しない、という4条件を満たす必要がある。境界タスクの正解率、保持タスクの正解率、Prompt の増加長、導入された回帰数、失敗の発見から候補生成までの時間を比較する。基準通過後も得られるのは release_to_canary だけで、安定版 Prompt を直接上書きしない。いずれか1項目でも失敗すれば reject_candidate を返す。

関連実装は prompt-auto-optimization を参照されたい。オフラインテストでは診断とリリース基準を網羅し、--quick を指定すると、タスク Agent、LLM Judge、Coding Agent を実際に呼び出す。

経験をプログラムとして記述する

経験が安定的かつ反復的で、検証可能な操作を記述している場合、モデルに毎回文書を再読させ、推論させるのは効率的ではない。この場合、経験をワークフロー、ツール、Harness コードにコンパイルし、一度の探索を反復実行可能なプログラムに変換する方が適切である。第5章では、Coding Agent がファイルを読み書きし、テストを実行し、システムを生成する方法をすでに説明した。本節で焦点を当てるのは一般的なコード生成ではなく、Agent が自身の軌跡に基づいて将来の自身のバージョンをどのように変更するかである。

変更可能な対象は、新しいツールに限られない。操作層では、ブラウザ軌跡をパラメータ化されたワークフローにコンパイルしたり、変更された API のアダプターを生成したりできる。制御層では、ツールルーティング、再試行、サーキットブレーカー、コンテキスト圧縮戦略を変更できる。検証層では、実運用上の失敗に基づいてパラメータ検査、状態検証器、回帰テストを追加できる。アーキテクチャ層では、Reviewer Agent を追加し、計画と実行の間の情報フローを変更できる。

ブラウザワークフローは、経験をプログラム化する価値を示している。これは表計算ソフトのマクロ記録にたとえられる。初めてメールを送るとき、マルチモーダル Agent は観察―思考―行動を通じて、「作成、宛先、件名、本文、送信」の各コントロールを見つける。次に別のメールを送るとき、変わるのは宛先と内容だけで手順は同じなので、ピクセルや DOM から経路全体をモデルに再発見させる必要はない。システムが行うべきなのは、最初の探索で得た軌跡を、パラメータ、状態チェック、バージョン情報を持つ小さなプログラムへコンパイルすることである。

図8-4に示した知識精製は、ブラウザ場面では次のような、より具体的なライフサイクルになる。

  1. 軌跡の取得：ナビゲーション、クリック、入力、プルダウン選択などの操作を記録し、操作パラメータ、当時の URL、XPath、CSS、id、role、aria-label、data-testid などの要素特定情報を保存する。特定情報は要素を再発見するためのものであり、タスク完了を証明するものではない。
  2. パラメータ化：初回実行のリテラルをテンプレート変数として識別する。たとえば test@example.com、件名、本文を {recipient}、{subject}、{content} に置き換え、その他の安定した操作はそのまま保つ。教育用実装では正規表現とテンプレート置換を使い、実運用では構造化タスク入力または制約付き抽出モデルを利用できる。
  3. 状態チェックの定義：操作の前後に、「送信ボタンが現在表示されている」「移動後の URL が対象サイトに属する」といったチェックを追加する。ワークフロー全体にも、「送信済み一覧に新しいメールが現れた」「テストページの状態値が期待どおりに変化した」といった最終状態チェックを設ける。操作の実行成功とタスク成功は別物であり、最終チェックは実際のページまたはバックエンド状態を読み取らなければならない。
  4. 候補の検証：初回成功から生成されるのは candidate にすぎない。システムはサンドボックスアカウントまたはテストサイトを独立した初期状態へリセットし、候補を最初から最後まで再生する。各操作の事前チェック、事後チェック、最終状態チェックをすべて通過して初めて validated として公開できる。メール送信や注文のように副作用を伴うタスクで安全なリセットコールバックがない場合、候補は監査用に保存するだけとし、検証のために本番アカウントで再実行してはならない。
  5. 照合と再生：新しいタスクが来ると、まず正式な能力ライブラリから意図とキーワードに基づいてワークフローを探し、今回のパラメータを抽出し、Playwright で直接実行する。再生経路では段階ごとに LLM を呼び出す必要はないが、要素が利用可能になるまで待ち、すべての状態チェックを完了する必要がある。
  6. 無効化と再学習：対象要素が見つからない、状態チェックが通らない、API Schema が変わった、最終状態が誤っている場合は、後続操作を直ちに停止する。旧版を検索可能ライブラリから invalid 領域へ移し、完全な Agent にフォールバックして再探索させる。旧ファイルは監査と比較のために残すが、黙って検索対象にし続けてはならない。

メール送信を例にすると、コンパイル結果は単なる「このボタンを順番にクリックする」という記録ではなく、宛先、件名、本文をパラメータに持つ小さなプログラムである。送信前に作成ウィンドウと入力欄を確認し、送信後に成功メッセージを確認し、最後に送信済み一覧へ該当メールが現れたことを確認する。PreAct9 の実験では、このようなプログラムが反復タスクでエンドツーエンド 8.5～13 倍の高速化を実現し、再生段階では言語モデルを一手ごとに呼び出す必要がなかった。さらに重要なのは、手順の記憶には操作前検証、操作後検証、保存前の独立検証がすべて必要だという点である。そうでなければ、再生カバレッジは100％で、すべてのボタンをクリックしたのに、実はある入力欄が空で、タスク自体は一度も完了していないという危険な錯覚が生じる。

実験 8-4 ★★★：ブラウザ軌跡から検証可能なワークフローを生成する

実験目標：Web Agent が一度の高コストな探索を再利用可能なワークフローへ変換でき、Webページが変化したときに、「操作をすべて実行した」ことを成功と誤報せず、誤った再生を拒否できるかを検証する。

4段階の場面：第1段階では、テスト用メールサイトまたは模擬メッセージページで「test@example.com 宛てに件名『テストメール』のメッセージを送る」タスクを実行する。完全な Agent が探索し、ラッパー層が操作、パラメータ、ページ状態を取得して candidate を生成する。第2段階では validation_reset でサンドボックスを元に戻し、独立して完全再生する。操作前チェック、操作後チェック、最終状態チェックがすべて通過した候補だけを正式な能力ライブラリへ入れる。第3段階では宛先、件名、本文がすべて異なる同種タスクを実行する。システムは検証済みワークフローを照合し、新しいパラメータを埋め、段階的な LLM ループに入らず Playwright で再生すべきである。第4段階ではボタンの特定方法、ページ文言、最終状態を変更し、旧ワークフローが直ちに invalid となって fallback_required=True を返すかを検証する。

対照設計：単純なベースラインは、クリックや入力などの操作が例外を投げずに終わったかだけを数える。実験群はさらに、操作前ページ、操作後ページ、タスクの最終状態を検証する。両群には同じ軌跡とページ変更を与え、「入力欄が空なのに送信ボタンはクリックされた」「Save はクリックされたがデータベースに保存されていない」といった偽成功場面での誤判定率を比較する。

指標と受け入れ基準：初回探索と再生のエンドツーエンド時間、LLM 呼び出し回数、成功率、誤成功率、ワークフロー照合率、ページ変更検出率、フォールバック再学習回数を記録する。リセットコールバックがない場合、ワークフローは候補領域にとどめなければならない。検証に失敗した版を検索できてはならない。パラメータ化再生で初回の宛先や内容を再利用してはならない。ページ変更後は危険な後続操作を停止しなければならない。これらを同時に満たして初めて、高速化の結果に意味がある。

関連実装は browser-use-rpa を参照されたい。決定論的な状態機械のデモと、実際のブラウザ Agent を呼び出す実行経路の両方を提供する。

Agent が自身のコードを変更することは、稼働中のプロセスが直接自身を上書きすることを意味しない。実運用システムでは、現在の安定版から候補ブランチを作成し、Coding Agent が最小限のパッチを生成する。その後、静的検査、単体テスト、セキュリティスキャン、失敗軌跡のリプレイ、既存タスクの回帰テストを順次通過させ、カナリアデプロイ可能な新バージョンを生成する。これにより「自己変更」は監査可能なソフトウェアリリースプロセスに変換される。ここに第8章と第5章の境界がある。第5章はシステムを変更する能力を提供し、本章は経験によって起動され、検証の閉ループによって制約される自己変更方法を提供する。

「パッチを小さくする」だけでは、信頼できる原因帰属には足りない。各変更要求は、失敗証拠、推定根本原因、担当する Harness コンポーネント、候補変更、改善を期待する挙動、損なわれる可能性のある既存挙動、両者のテストを明記した反証可能な変更契約であるべきだ。Agentic Harness Engineering はこれを、コンポーネント、経験、意思決定の3層の可観測性として整理する。編集可能な各コンポーネントはファイル単位で表現され、大量の軌跡は段階的に掘り下げられる証拠へ整理され、各編集は実行前に影響予測を宣言し、次の結果で検証される19。これにより得点上昇を、解釈不能な試行ではなく具体的な機構へ結び付けられる。

候補生成器へ渡すのも失敗事例だけではない。Self-Harness は、保持すべき成功挙動と、過去に却下された変更の記録も提供する20。前者は修復時に壊してはならない性質を示し、後者は失敗案を言い換えて再提出することを防ぐ。失敗証拠、成功制約、過去の試行を合わせた境界付き候補空間は、全ソースと生ログを無差別に変更 Agent へ詰め込むより、局所的で検証可能な変更を生みやすい。

ツール作成も同じプロトコルに従う。Alita10 が示した事例では、Agent は『ロード・オブ・ザ・リング』のゴラム役の俳優がナレーションを担当する YouTube の 360度 VR 動画から、恐竜が初めて登場した直後に言及される数字を探す必要があった。字幕を読む能力がないことに気づくと、youtube-transcript-api を検索してテストし、新しい字幕ツールとしてラップし、最終的に字幕から答え 100000000 を得た。新ツールが能力ライブラリへ入るのは、セキュリティスキャン、機能テスト、後続タスクでの再利用をすべて通過した後である。第4章の能動的ツール発見は「既存ツールのどれが適するか」を、第5章は「ツールをどう作るか」を扱う。本章が問うのは、「どの実行証拠が作成を起動し、新ツールがどうすれば検証済みの長期能力になるか」である。

実験 8-5 ★★★：失敗軌跡によって Agent の自己変更を起動する

実験目標：「retryable=false のエラーがなお連続して呼び出される」複数の軌跡から、根本原因を再試行・サーキットブレーカーコードへ特定し、一時的障害に対する再試行能力を壊さず候補修正を生成できるかを検証する。

手順：診断モジュールはまず異なるタスクで起きた同一障害を集約する。軌跡横断的な支持のしきい値に達した場合だけ変更要求を作り、対象を安定版の retry_policy.py に定める。候補生成器は失敗診断、保持すべき一時障害の回復挙動、過去に却下された変更、安定版ソースを読み、「再試行不能エラー後の呼び出し数は減り、一時的タイムアウトの回復率は下がらない」という影響予測を先に提出してから最小のコード diff を出力する。決定論的生成器を使う場合も、実際の LLM Coding Agent を使う場合も、結果は隔離された候補ディレクトリにしか書き込めない。検証 Harness は続いて候補をコンパイルし、元の失敗軌跡を再生し、再試行不能エラーが即時停止してサーキットブレーカーを開くかを確認した後、一時的タイムアウトが従来のしきい値どおり再試行されるかを再テストする。

診断対照と指標：「Prompt に『繰り返し呼び出さない』と一文追加するだけ」の方法を、誤った層へ対処する概念的対照とし、決定論的に実行できる再試行制約をなぜプログラムへ入れるべきかを示す。実行可能な実験では決定論的パッチ生成器と LLM 生成器を比較し、両者に同じリリース基準を適用する。再試行不能エラーの呼び出し回数、一時的エラーの回復率、旧タスクの回帰数、パッチサイズ、候補受け入れ率を記録する。

受け入れ基準：すべての検査を通過しても、生成するのは release_to_canary だけである。静的検査、失敗再生、旧タスク回帰のいずれかが失敗すれば reject_candidate を返す。release_manifest.json には、失敗クラスタ、出典軌跡、推定根本原因、対象コンポーネントとファイル、コード diff、期待する修復、潜在的回帰、検査結果、候補版、ロールバック版を記録しなければならない。却下候補の失敗理由も次の生成ラウンド用に保持する。パッチを生成する Agent は、安定版コード、検証器、監査ログ、自身の公開を承認する基準を変更できない。

関連実装は self-modifying-agent を参照されたい。決定論的な候補生成器または実際の LLM Coding Agent を選択でき、2つの経路は同じリリース基準を共有する。

経験をパラメータに書き込む

知識、指示、プログラムは、いずれも対象能力を外部記号によって比較的完全に表現できることを前提としている。しかし、医用画像の理解、自然な音声韻律、テキストからテンプレート的な「AI らしさ」を除去すること、長期的な計画などの能力は、少数のルールやワークフローへ圧縮することが難しい。この種の能力は、後訓練を通じてモデルパラメータに書き込む必要がある。

パラメータ化すべきかどうかは、「タスクが長期的に安定しているか」だけでは決まらない。新しい画像装置によるドメインシフトには、依然として LoRA または継続的な微調整が必要になる可能性がある。急速に変化する言語スタイルにも、定期的な選好訓練によって適応できる。安定性は更新頻度とコストに影響するが、能力の表現特性が主要な媒体を決定する。逆に、長期的に安定した送金承認ルールも、パラメータの記憶だけに依存すべきではなく、サーバー側コードによる決定論的な保証が必要である。

第7章では SFT、蒸留、RL を詳しく論じたため、本節ではアルゴリズムを繰り返さない。継続的進化において重要なのは、評価済みの実運用軌跡を訓練データへ変換することである。高品質なデモンストレーションは SFT に使用でき、明確な選好はペアデータを形成でき、信頼できる環境報酬を持つインタラクションは RL に利用できる。訓練前にはプライバシー情報を除去し、誤った軌跡をフィルタリングし、独立した回帰セットを保持する必要がある。訓練後には、汎用能力と安全性アラインメントが忘却されていないかを検査する。

パラメータ学習は通常、外部手法と連携する。医用画像モデルはパラメータによって視覚表現を学習し、知識ベースによって最新ガイドラインを提供し、コードによって病変を測定してリスクを計算する。カスタマーサービスの自然な口調は、選好訓練によって全体的な分布を形成し、Prompt で現在のブランドアイデンティティを規定し、ユーザーメモリで個人のコミュニケーション選好に適応できる。継続的進化とは、4つの方法から唯一の答えを選ぶことではなく、それぞれの能力を、その表現とガバナンスに最適な場所へ配置することである。

成果物の更新から「更新方法」の更新へ

前の4つの方法は、経験をどこへ書くかを扱った。しかし継続的進化にはもう一つ直交する軸がある。システムが最適化しているのは、ある成果物の内容なのか、それとも成果物を生成、管理、検証する方法なのか。この軸では、最適化対象を 個々の規則や記憶 → 構造化コンテキスト → ワークフロー → Harness コード → 候補案を生成する最適化器コードへ広げられる14。これは5種類の新しい更新媒体ではなく、5つの探索規模であり、知識、Prompt、Skill、プログラムはいくつもの層に現れうる。

最内層は成果物の内容だけを変える。たとえば失敗軌跡に基づいてシステム Prompt へ局所ルールを加えたり、経験文書へ例外条件を補ったりする。影響範囲が小さく、原因帰属とロールバックが容易なので、これを既定とすべきである。ただし Prompt や記憶全体をモデルに繰り返し書き直させると、簡潔化の過程で少数の重要な詳細が消え、相互に制約する条件が過度に抽象的な原則へまとめられる。Agentic Context Engineering（ACE）はコンテキストを安定した識別子付き項目として管理し、生成、反省、整理モジュールが差分更新を提案し、決定論的ロジックで統合・重複排除する。毎回全文を短く書き直すのではない15。これは本章の「最小 diff、出所保持」を具体化する研究例である。

一段外では、最適化対象は「コンテキストに何があるか」だけでなく「どう構築するか」になる。Meta Context Engineering（MCE）は内外2つのループへ分ける。内側は所与の管理方法で現タスクのコンテキスト成果物を最適化し、外側は複数回の実行・検証結果から検索、選択、フィルタリング、整形の操作そのものを変更する16。検索ルールを一つ直すのは内容管理機構の変更であり、複数の検索・整理機構を比較して転移の良いものを残すのが「コンテキスト管理方法」の学習である。

同じ発想はワークフローと Harness 全体へ拡張できる。AFlow は複数の LLM 呼び出しからなるワークフローをコードグラフで表し、実行フィードバックからノードと制御フローの組合せを探索する17。Meta-Harness は Coding Agent に候補 Harness のソース、得点、軌跡を読ませ、情報の保存、検索、提示を決めるコードを探索する18。第5章はコードを Agent システム構造の共通言語として示した。ここでの追加点は、コードが一度きりの成果物ではなく、評価履歴とともに継続探索の対象になりうることである。

高い層ほど良いわけではない。局所ルールの探索には少数の境界ケースで足りても、ワークフローや Harness 全体の探索は候補空間、評価コスト、原因帰属の難しさが大きい。単一コンポーネントへ特定できる明確で反復的な障害には、まず監査可能な局所パッチを適用する。局所変更では複数コンポーネントにまたがる問題を解けない場合、または管理方法自体がボトルネックの場合にだけ、ワークフロー、Harness、最適化器へ上がるべきである。どの層でも評価器、権限境界、留保テストは変更可能範囲の外に置く。探索空間が大きいほど、この信頼の基点は重要になる。

実験 8-6 ★★★：Hermes にこの本を渡したら、自分をアップグレードできるか？

実験目的：外部知識を自分自身の能力更新へ変換できるかを検証する。修正すべき問題や機能一覧は与えない。Hermes に全10章と自身のソースコードを渡し、原則を理解し、実装を見直し、価値のある改善を自分で選ばせる。

実験設計：本とソースコードは読めるコンテキストだが、安定版、独立 Reviewer、受け入れテストは Hermes の編集範囲外に置く。Hermes は 読む → 比べる → 選ぶ → 変える → 検証する を完了しなければならない。候補が拒否された場合、その指摘は次の学習ラウンドへの入力となり、ゲートを迂回して成功を宣言することはできない。

実行結果：本を読んだ Hermes は、保存された実行軌跡に、後続学習が直接使える構造化された証拠が不足していると自ら判断した。そこで実行結果を保守的な学習シグナルへ整理し、自身のコードを編集してテストを追加した。最初の3回の独立レビューは、実データ形式、保存経路、カウントの意味との不一致を発見した。指摘は毎回元の Hermes セッションへ戻され、4回目のレビューで候補が受理された。

主張の境界：この実行は、Agent が長い知識から原則を抽出し、自分のコードへ対応づけ、外部検証の下で自己更新を完了できることを示す。下流タスクの成功率向上はまだ示しておらず、別の ablation 実験が必要である。実験案は読者 Grace の提供による。

長期運用可能な継続的進化の閉ループを構築する

4つの更新方法は、同一の自律的な循環に組み込まれて初めて、一度限りの最適化から継続的進化へ移行する。図8-5は、実運用システムにおけるより堅牢な二重ループ構造を示している。オンライン実行ループはタスクを完了して証拠を記録するだけであり、正式な Agent を直接書き換えない。オフライン進化ループは軌跡を集約し、根本原因を診断し、変更候補を生成してから、検証基準を通じて新バージョンをリリースする。両者は、バージョン管理された経験ライブラリと評価セットによって接続される。

図8-5 オンライン実行とオフライン進化の二重ループ

Voyager13 は、比較的完全な継続的進化ループを示している。Minecraft において現在の能力に基づいて新たな目標を選択し、環境フィードバックを通じてプログラムを反復的に改善し、成功を検証した後にコードをスキルライブラリへ保存し、既存スキルを組み合わせてより困難なタスクを解決する。自動カリキュラム、実行可能なスキル、環境検証のいずれも欠かせない。スキルライブラリだけがありカリキュラムがなければ、Agent は次に何を学ぶべきか分からない。自己反省だけがあり環境検証がなければ、スキルライブラリには誤りが蓄積する。探索だけがあり永続化がなければ、各タスクを毎回最初から始めなければならない。現実の Agent における知識、Prompt、ツール、パラメータはより複雑だが、基本的な学習プロセスは類似している。

具体的には、Voyager は3つの相互にかみ合う仕組みから成る。自動カリキュラム生成器は、現在の所持品、環境、習得済みスキルに基づいて次の適度な難易度の目標を提示し、探索をランダムな徘徊にしない。スキルライブラリは成功したプログラムを検索・合成可能なコードとして保存し、たとえば高度な採集スキルから移動やクラフトといった基礎スキルを呼び出せる。反復的な Prompt の仕組みは環境観察、実行エラー、自己検証の結果を次回のコード生成へ戻し、タスクが実際に通るまで反復する。論文によれば、当時のベースラインに比べて Voyager は3.3倍の固有アイテムを獲得し、2.3倍の距離を探索し、主要な技術ツリーのマイルストーンを最大15.3倍速く解除した。また、スキルライブラリを新しい Minecraft ワールドへ転移できた。これらの指標は、凍結された Agent の一度の試験成績ではなく、経験に伴って能力が伸びる曲線を測っている。

問題特定から経験蓄積まで

同じ表面的な問題でも、異なる変更方法が必要になる場合がある。カスタマーサービス Agent に事実を捏造するハルシネーションが発生した場合、知識ベースに事実が不足している可能性もあれば、Prompt に引用要件がない可能性もある。Agent がタスクを完了していないのに「完了しました」と虚偽の約束をする問題は、指示によって修正することも、Harness によって応答とツール状態の整合性を強制検査することもできる。進化モジュールは、まず根本原因を特定し、次に最小で、最も検証しやすく、ロールバックしやすい変更対象を選択すべきである。証拠が不十分な偶発的障害は、直ちに学習を引き起こすべきではなく、サンプルをさらに蓄積すべきである。

この選択は、経験の増加に伴って変化することもある。新たに発見された戦略は、まず検索用の経験文書として提供される。複数の事例で繰り返し検証された後は、知識へ昇格できる。知識には3つの表現方法がある。自然言語で明確に記述できるルールは Skill として蓄積できる。ステップが安定し、自然言語理解能力を必要としない場合は、ツールコードへコンパイルできる。それが実際には広範な暗黙的意思決定能力を反映する場合は、後訓練に組み込める。

検証、リリース、ロールバック

すべての変更は、まず候補能力または候補 Agent を生成し、実運用版を直接上書きしない。知識文書については、検索後に新規タスクの性能が向上するかを検証する。Prompt と Skill については、境界ケースと既存タスクの回帰を検査する。プログラムについては、サンドボックスとリセット済み環境でテストを実行する。パラメータ更新については、忘却、安全性、分布外タスクを検査する。検証に合格した後も、カナリアリリースによって実トラフィックを観察すべきである。主要指標が悪化した場合は、既知の安全なバージョンへ自動的にロールバックする。

検証では、混同されやすい2つの能力も分ける必要がある。Harness 更新能力（harness-updating）は軌跡から価値ある永続的変更を生む能力、Harness 利得能力（harness-benefit）はタスク Agent が後続実行でその変更を見つけ、起動し、正しく使う能力である。Skill 自体は正しくても、弱いタスクモデルが適切な場面で読み込まなかったり、長い軌跡で従えなかったりすれば、最終得点は「進化なし」に見える。したがってエンドツーエンド得点だけで更新器の良否を推定できない。Lin らのモデル交換実験は、この2能力と基礎モデル能力の関係が同一ではないことを示す21。具体的関係はさらに多くのタスクで検証すべきだが、分離評価自体は広く有効である。

表8-3 継続的進化の階層別評価指標

指標 答える問い 主な証拠
候補変更の有効率 更新器は価値ある変更を提案したか 独立検証での受け入れ率と改善幅
成果物の起動率 タスク Agent は新しい Skill、記憶、ツールを適切な場面で読み込んだか 検索、ルーティング、ツール呼び出し軌跡
遵守成功率 起動後に新ルールや手順へ従ったか 行動列とプロセス検証器
留保タスクの改善 進化に使わなかったタスクも改善したか held-out の成功率、品質、コスト

診断では候補 Harness を固定し、タスクモデルだけを交換できる。強いモデルは利得を得るが弱いモデルが成果物を起動しないなら、ボトルネックは検索かルーティングである。両者が起動しても強いモデルだけが正しく実行するなら、指示遵守か長期計画である。すべてが劣化するなら変更自体が疑わしい。逆にタスクモデルを固定し、変更を提案するモデルを交換すれば更新器の品質を比較できる。この双方向交換は「進化後の総得点」一つより、能力予算の投入先を特定しやすい。

評価は学習終了後の試験ではなく、自己進化プロセスに不可欠な構成要素である。長期評価では、少なくとも次の5種類の結果を同時に観察する必要がある。

  • 回帰（regression）。すなわち、新しい経験が既存の他の経験と衝突していないか、従来は合格できたケースで回帰が生じていないか。
  • 汎化能力。すなわち、新しい経験が、テストセットでまだ網羅されていない場面にもたらす性能向上。
  • Token 効率。すなわち、タスク完了に消費される token コスト。
  • 安全性。すなわち、ルール、プライバシー、拒否境界が進化に伴ってドリフトしていないか。
  • 長期的な工学品質。保守の複雑さ、アーキテクチャの一貫性、所有権境界、後方互換性、将来の移行・デバッグ負担が悪化していないか。

現在の失敗ケースだけを解決し、他の既存ケースや新しいドメインで性能が低下するのであれば、継続学習に成功したとはいえない。

検証可能な閉ループの境界：「完了」が「進歩」を意味しないとき

前述の閉ループは、テスト、環境状態、決定論的規則が素早くフィードバックを返せる Coding、ツール呼び出し、業務状態変更で最も成立しやすい。一方、オープンな研究、戦略立案、複雑な製品設計では、評価信号が遅く、正解は一つではなく、研究センス、長期価値、保守性という本当に重要な目標を即時得点にしにくい。Harness が手順を完全に遂行しても、実目標を進めず「成果らしいもの」を安定して出すだけになりうる。

自動研究は代表的なストレステストである。Trehan と Chopra は、研究アイデアから論文までの4件のエンドツーエンド試行を記録した。3件は実装または評価で失敗し、全工程を完了したのは1件だけだった22。問題は3つに分けられる。実装ドリフト：元の方法が難しくなると、Agent は訓練分布で馴染みがあるが研究仮説から外れた実装へ戻る。認識論的な過度の楽観：信号がまだノイズかもしれないのに、結果を説明し、パッチを加え、発見を宣言し、失敗や陰性結果を軽視する。暗黙の判断力不足：実験は走らせられても、重要な baseline、追うべき異常、仮説を捨てる時点を判断できない。

この種のタスクでは、論文を書くのが上手いモデルへ替えるだけでなく、証拠と監督の構造を変える必要がある。

  • 結論と証拠を分離する：引用、数値、方法、結論の出所を別々に記録し、最終文書は証拠グラフの一表現とする。ScientistOne の Chain-of-Evidence は主張の種類ごとに監査可能な出典へ結び付け、追跡可能性を高めるが、研究課題の価値までは保証しない23。
  • 陰性結果を保持する：失敗実験、却下候補、停止理由を成功と同じ検索可能性を持つ不変ログへ書く。そうしなければ進化モジュールは生存案しか見ず、反証済み経路を繰り返し、曖昧な結果を成功と解釈するようになる。
  • 探索の多様性を保つ：オープン探索で現在最高得点の一本だけを残さない。機構、コードの新規性、仮説種別が異なる低得点の枝も候補プールへ残し、全案が同じ採点しやすいテンプレートへ収束するのを防ぐ。
  • 人間の関与を上位層へ移す：人は危険なツール呼び出しを承認するだけでなく、問題を定義し、評価基準を審査し、異常結果を解釈し、停止時点を決める。曖昧なフィードバックでは、こうした上位判断は各実行ステップを代行するより自動化しにくく、価値が高い。

同じ制約は通常のソフトウェア工学にもある。単体テストの全合格は現在観測できる挙動がテストを満たすことしか証明せず、数か月後も保守しやすいとは保証しない。だから長期工学品質は、現在のタスク成功率で遅延した外部性まで覆えると期待せず独立指標にする。継続的進化の上限は、測りやすい代理指標ではなく、真に重視する目標を評価できるかで決まる。

継続的進化の安全境界

Agent の自己進化能力は、一度の誤りを長期的なリスクへ変える可能性がある。Webページ、メール、ツール出力に含まれるプロンプトインジェクションが経験として要約されると、セッションをまたいで繰り返し作用し得る。自動検索で見つけた悪意あるパッケージをツールとしてラップすれば、影響は一度のサンドボックス実行から後続の全タスクへ広がる。欠陥のある検証器は、改善に見えて実際には劣化した候補版を承認し続ける可能性もある。したがって Agent の自己進化システムは、「強くなったか」を検証するだけでなく、「誰が何を変更でき、その根拠がどこから来たか」も制限しなければならない。

第1の境界は、証拠と指示の分離である。Webページやツールの生出力は信頼できない証拠であり、Skill などへ直接書き込めない。書き込み前には LLM による要約を経る必要がある。書き込みにはバージョン管理を使い、pull request を提出し、異なる出典を持つ reviewer LLM のレビューを通過して初めてマージする。

第2の境界は、候補能力と正式能力の分離である。新しい知識、Prompt、Skill、プログラム、パラメータはすべて、実トラフィックへサービスできない候補領域へ先に入れる。新しく生成したコードと外部依存関係には、サンドボックス、権限検査、サプライチェーンスキャン、挙動テストなどの安全性検査も必要である。安全性検査と回帰テストを通過して初めて実トラフィックへ提供し、正式能力にできる。

第3の境界は、安全機構を自己変更させないことである。業務 Agent は Prompt、Skill、知識ベース、ツールなどを変更できるが、自身の更新を承認する検証器、テストケース、リリース基準、監査ログ、安定版バックアップを変更してはならない。さもなければ Agent は、テストのしきい値を下げたり失敗ケースを削除したりするだけで、劣化を改善に見せかけられる。

睡眠学習：統合、忘却、能力の鮮度維持

「睡眠学習」はオフライン統合の認知的なたとえであり、処理を本当に夜間に実行する必要はない。オンライン Agent の第一の責務は現在のタスクを完了し、変更不能な証拠を追記することである。バックグラウンドの学習プロセスは、アイドル時またはゲート条件を満たしたときに新しい経験をまとめて読み、新旧の結論を比較し、重複を統合し、衝突を解決し、更新候補を提案して回帰テストを実行する。収集と整理を分ければ、一度の偶発的成功、ネットワーク障害、悪意ある入力が長期能力を即座に書き換えるのを防げる。また、整理にはより大きなバッチと安価なモデルを利用できる。

典型的な睡眠学習サイクルは5段階から成る。

  1. 起動：一定時間、新規軌跡数、保存容量、エラー頻度のしきい値に達し、現在、高優先度のオンラインタスクがないことを確認する。
  2. 方向づけ：正式な知識、Prompt、Skill のディレクトリとそのバージョンを読み、既存能力と変更不能な境界を把握する。
  3. 収集と統合：最近評価済みの軌跡から新しい信号を探し、重複を統合し、衝突と適用条件を記録し、局所的なパッチを優先して生成する。
  4. 検証と承認：転移セット、保持セット、安全性セットで候補を評価し、高リスクな書き込みは人間の承認待ちにする。
  5. 剪定と索引化：検索インデックスを更新し、長期間使われていない能力や新しい証拠で否定された能力を期限切れ、アーカイブ、削除のいずれかにする。同時に、出典とロールバック版は残す。

ユーザーメモリは最も分かりやすい例だが、行動経験とは区別する必要がある。Claude Code の自動メモリは、プロジェクトごとに MEMORY.md のインデックスと、トピック別に分割した詳細ファイルを維持する。セッション開始時にはインデックスの上限付き先頭部分だけを読み込み、残りは必要に応じて読む。インデックスが上限に近づくと、Agent に詳細の統合または移動を求める。これは、プレーンテキストのメモリにも容量制約、階層的な読み込み、能動的整理が必要であることを示す。ただし現在公開されている仕組みは主にセッション内で継続的に書き込むものであり、固定された夜間バックグラウンドタスクと単純に同一視することはできない11。

Hermes は、より完全なバックグラウンド進化の事例を示す。長期情報を、上限付きの MEMORY.md と USER.md、SQLite/FTS5 に基づく過去セッション検索、必要に応じて読み込む Skill、Honcho などの任意の外部メモリプロバイダーに分ける。過去検索は LLM に先に要約させず原メッセージを返し、検索と生成が監査不能な一手順に混ざるのを防ぐ。あるタスクに多数のツール呼び出しが含まれる場合、エラーや行き止まりから復旧した場合、ユーザーの訂正を受けた場合、または自明でないワークフローを発見した場合、バックグラウンドの振り返りが Skill を作成または局所修正できる。メモリと Skill の書き込みには承認ゲートも設けられる。独立した Curator はさらに、Skill の利用状況、陳腐化、アーカイブ状態を追跡し、アイドル時に決定論的な剪定を行い、任意で LLM による統合も実行する。変更前にはスナップショットを保存するため、誤った整理をロールバックできる12。この事例は「記録―統合―検証―剪定」を比喩から実行可能な能力ライフサイクルへ変えている。

継続的進化は、知識、Prompt、ツールを無限に増加させることでもない。第2章で述べたコンテキストの劣化は、より長い時間軸で再現する。経験文書が相互に衝突し、Prompt が境界ルールに埋め尽くされ、Skill ライブラリに重複能力が現れ、複数回の微調整によって破局的忘却が生じる。システムには定期的なオフライン整理が必要である。

  • 重複する経験を統合し、出典とバージョンを保持する。
  • 局所的なルールをグローバル Prompt からドメイン Skill へ移動し、グローバル Prompt を簡潔に保つ。
  • Prompt と Skill は、新入社員向けの手引書のように明確な構造を維持し、「99か条の軍規」のようなルール列挙を避ける。
  • 長期間使用されていないツールを再検証する。
  • 新しい証拠によって否定された知識を削除する。
  • 元の基盤モデルから LoRA を再訓練する。

実験 8-7 ★★★：Agent が継続的に進化しているかを評価する

実験目標：「一度のフィードバックを保存できる」「追記するだけ」「能力を更新、転移、保持できる」という3種類の長期的行動を区別し、同じ問題群の反復実行を継続学習に見せかけないようにする。

4段階のタスクフロー：学習段階では、返金、本人確認、手荷物ポリシーなど、共通する潜在規則を持つタスクを提供する。転移段階では表現、ユーザー、局所環境を変更し、過去の経験を新規タスクに利用できるかを確認する。ルール変更段階では手荷物上限を20kgから23kgへ変更し、旧知識の置換または廃止を求める。保持段階では、変更のない能力と現在有効なルールを再テストし、更新による忘却を測る。外部メモリの更新はフィードバック付きタスクが終わった後だけ許し、現在の問題で期待される操作を事前に Agent へ漏らしてはならない。

対照群：static はフィードバックを永続化しない。append_only は初版の規則を覚えられるが、衝突処理や廃止ができない。evolving はバージョンを保存し、新証拠で旧規則を置き換える。参照実装は、評価 Harness がこれらの行動を区別できるかを検証するために使う。実際の実験では LLM に同じ14問の順序付きタスクフローを経験させてもよいが、結果は必ずモデル外の Harness で計算する。

指標と受け入れ基準：段階ごとの正解率と学習曲線を報告し、転移正解率、新規則の受領後に正解へ復帰するまでのタスク数、旧能力保持率、負の転移率、安全性 Rubric 通過率、Token・レイテンシ・保存コストを個別に計算する。Prompt、Skill、Harness を更新する実システムでは、候補変更の有効率、成果物の起動率、遵守成功率も記録し、「更新は正しいが読み込まれなかった」を更新失敗と誤判定しない。最終正解率が高くても、廃止済み規則を引用し続ける、ルール違反の近道でタスクを完了する、更新後に既存能力を忘れる Agent は、継続的に進化しているとは判定できない。

関連実装は self-evolution-eval を参照されたい。デフォルトでは、更新可能、追記のみ、静的という3種類の参照 Agent を比較する。--profile llm を指定すると、実際の LLM に同一の長期タスクフローを経験させられる。

本章のまとめ

継続学習は Agent にとって最も重要な能力の一つになりつつあるが、現在のモデルは、信頼できる継続学習を自律的に実現することがまだできない。推論時のコンテキスト適応は自動的には永続化されず、未検証のオンラインパラメータ更新はノイズ、攻撃、能力ドリフトを増幅する。したがって現時点でより実用的なのは、モデル周辺に検証可能な学習システムを構築することである。

Agent は環境との相互作用と評価から学習信号を得て、能力の表現特性に応じて知識、Prompt、Skill、プログラム、モデルパラメータを更新する。これらの成果物を管理・生成する方法自体も最適化できるが、まずは原因帰属、検証、ロールバックが可能な局所変更を優先すべきである。

継続的進化ではオンライン実行とオフライン学習を分ける。オンラインで証拠を記録し、オフラインで候補更新を生成・検証し、その後に段階的なリリース、整理、ロールバックを行う。この閉ループは結果を自動検証できるタスクで最も信頼できる。目標が曖昧でフィードバックが遅れるオープンタスクでは、人間が問題定義と評価基準の策定に引き続き関与する必要がある。

考察問題

  1. ★★ ある経験文書が、3件の成功軌跡と1件の失敗軌跡によって支持されている。失敗は、より新しい API バージョンで発生した。システムは、経験が否定されたのか、適用条件が変化したのかをどのように判断すべきか。
  2. ★★ カスタマーサービス Agent のユーザー満足度が上昇した一方、ルール違反率も上昇した。なぜ満足度を単一の学習信号として使用できないのか。どのようなガードレール指標を設計するか。
  3. ★★★ 同じ「虚偽の約束」の問題は、Prompt、Harness の検査、パラメータ訓練によって軽減できる。どのような証拠に基づいて変更位置を選択するか。
  4. ★★★ Agent はツールと検証器を変更できるが、自身の更新を承認する信頼の基点を変更すべきではない。この2つの部分について、権限とコードの境界をどのように分割するか。
  5. ★★ 経験知識ベースが増大し続けると、検索誤りと知識衝突が学習効果を相殺する。バージョン、有効期間、廃止の仕組みをどのように設計するか。
  6. ★★★ パラメータ学習は自然言語スタイルに優れるが、厳格な業務ルールを保証することは難しい。医療カスタマーサービス向けに、パラメータ、知識、Skill、コード制約が連携する継続的進化の設計を示せ。

  1. Shinn, N., et al. Reflexion: Language Agents with Verbal Reinforcement Learning. arXiv:2303.11366, 2023. ↩

  2. Mialon, G., et al. GAIA: a benchmark for General AI Assistants. arXiv:2311.12983, 2023. ↩

  3. Yu, C., et al. AWorld: Orchestrating the Training Recipe for Agentic AI. arXiv:2508.20404, 2025. ↩

  4. Khattab, O., et al. DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines. arXiv:2310.03714, 2023. ↩

  5. Yang, C., et al. Large Language Models as Optimizers. arXiv:2309.03409, 2023. ↩

  6. Agrawal, L., et al. GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning. arXiv:2507.19457, 2025. ↩

  7. Karpathy, A. “We’re missing (at least one) major paradigm for LLM learning … system prompt learning?” X, May 11, 2025. https://x.com/karpathy/status/1921368644069765486 ↩

  8. Anthropic. Skill Creator. 2026. https://github.com/anthropics/skills/blob/main/skills/skill-creator/SKILL.md ↩

  9. Li, Bojie. PreAct: Computer-Using Agents that Get Faster on Repeated Tasks. arXiv:2606.17929, 2026. ↩

  10. Qiu, J., et al. Alita: Generalist Agent Enabling Scalable Agentic Reasoning with Minimal Predefinition and Maximal Self-Evolution. arXiv:2505.20286, 2025. ↩

  11. Anthropic, “How Claude remembers your project”, 2026. https://code.claude.com/docs/en/memory ↩

  12. Nous Research, Hermes Agent Documentation: Persistent Memory, Skills System, and Curator, 2026. https://hermes-agent.nousresearch.com/docs/user-guide/features/memory ; https://hermes-agent.nousresearch.com/docs/user-guide/features/skills ; https://hermes-agent.nousresearch.com/docs/user-guide/features/curator ↩

  13. Wang, G., et al. Voyager: An Open-Ended Embodied Agent with Large Language Models. arXiv:2305.16291, 2023. ↩

  14. Weng, Lilian. “Harness Engineering for Self-Improvement.” Lil’Log, 2026. https://lilianweng.github.io/posts/2026-07-04-harness/ ↩

  15. Zhang, Qizheng, et al. Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models. ICLR 2026. arXiv:2510.04618. ↩

  16. Ye, Haoran, et al. Meta Context Engineering via Agentic Skill Evolution. arXiv:2601.21557, 2026. ↩

  17. Zhang, Jiayi, et al. AFlow: Automating Agentic Workflow Generation. ICLR 2025. arXiv:2410.10762. ↩

  18. Lee, Yoonho, et al. Meta-Harness: End-to-End Optimization of Model Harnesses. arXiv:2603.28052, 2026. ↩

  19. Lin, Jiahang, et al. Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses. arXiv:2604.25850, 2026. ↩

  20. Zhang, Hangfan, et al. Self-Harness: Harnesses That Improve Themselves. arXiv:2606.09498, 2026. ↩

  21. Lin, Minhua, et al. Harness Updating Is Not Harness Benefit: Disentangling Evolution Capabilities in Self-Evolving LLM Agents. arXiv:2605.30621, 2026. ↩

  22. Trehan, Dhruv and Paras Chopra. Why LLMs Aren't Scientists Yet: Lessons from Four Autonomous Research Attempts. arXiv:2601.03315, 2026. ↩

  23. Meng, et al. ScientistOne: Towards Human-Level Autonomous Research via Chain-of-Evidence. arXiv:2605.26340, 2026. ↩