self-improvement-loops

自己改善ループ

このスキルでは、最適化対象そのものがハーネスであるシステムを扱います。エージェントが自らの失敗を掘り起こして自身のスキャフォールドを編集する、メタエージェントがハーネスコードを探索する、ワークフロー候補の集団が評価器に対して進化する、あるいはコンテキストを生成する仕組みそのものがバージョン管理され改善される、といったシステムです。設計上の問いは「1つのループをどう制御するか」（harness-engineering）から、「ループを動かすシグナルを損なわずに、ループ自身の一部を書き換えさせるにはどうするか」へと移ります。

公開されているすべてのシステムに共通する制約があります。ループは与えられたシグナルが持つ弱点も含め、そのシグナルに基づいて最適化します。最適化器が指標と意図の間にあるあらゆるギャップを見つけ出すことを前提に、ループを設計してください。

有効にするタイミング

次の場合に、このスキルを有効にしてください。

• エージェントが、掘り起こした失敗パターンに基づいて自身のハーネス、プロンプト、コンテキストプレイブック、またはワークフローの編集を提案するループを構築する場合
• ハーネスやスキャフォールドのコードを対象とするメタレベルの探索を設計する場合：メタエージェントによる探索、ワークフローグラフ上のツリー探索、LLM の変異オペレーターを用いる進化的プログラム探索
• 自己変更型エージェントシステムの受け入れ基準を決める場合
• コンテキスト成果物を手作業で編集するのではなく、コンテキストを管理する仕組み（スキル、プレイブック、コンテキスト関数）を進化させる場合
• 性能が低下する自己改善ループを診断する場合：報酬ハッキング、多様性の崩壊、コンテキストの崩壊、または気づかれない停滞
• 繰り返し発生する失敗を最適化の階層（プロンプト、コンテキスト、ワークフロー、ハーネスコード、最適化器コード）のどのレベルで修正するかを決める場合

次のような、他のスキルが担当する隣接領域には、このスキルを有効にしないでください。

• 自己変更を行わない単一の自律ループのガバナンス：固定面と編集可能面、永続ログ、ロールバック、新規性ゲート、PR の準備、人間による承認の境界は、harness-engineering が担当します。このスキルが最適化対象となる場合に何が起こるかを定義するのに対し、harness-engineering は制御面を定義します。
• 候補を評価する評価器、回帰テストスイート、品質ゲートの構築：evaluation。
• 候補のスコアリングにおける LLM を用いた判定、ペアワイズ比較、バイアス軽減の設計：advanced-evaluation。
• 改善ループを伴わない、単発のトークン効率化、マスキング、キャッシュ：context-optimization。
• ループの実行に使うリモートサンドボックスとバックグラウンド実行のインフラストラクチャ：hosted-agents。
• そもそもループを構築するかどうか、パイプラインの構成、コスト見積もり：project-development。
• ループが最適化する、自己編集型コンテキストの動作と効率報酬：self-managed-context。

主要な概念

最適化の階層

公開されている自己改善システムは、段階的に深い対象を最適化します。

段階	最適化対象	システムの例
1	指示プロンプト	Promptbreeder、GEPA
2	構造化コンテキスト	ACE（項目別の箇条書きで構成されたプレイブック）
3	コンテキストの仕組み	MCE（コンテキストを生成するスキル）
4	ワークフローグラフ	ADAS、AFlow
5	ハーネスコード	Self-Harness（範囲を限定した自己編集）、Meta-Harness、Darwin Godel Machine
6	最適化器コード	STOP（改善器が改善器自身を改善する）

段階を上げるほど設計空間と効果は大きくなりますが、評価ごとのコストも増え、不正に最適化される可能性のある面も広がります。繰り返し発生する失敗は、その修正を表現できる最も低い段階で直してください。古いライブラリが原因の失敗はコンテキストの修正であり、ワークフローの書き換えではありません。現在の段階で失敗が候補をまたいで繰り返し発生する場合にのみ、上位の段階へ進んでください。

ループは知能ではありません

再帰的な構造は、ベースモデルの品質を良い方向にも悪い方向にも増幅します。強力なモデルで成果を積み重ねる同じ再帰的改善設計も、弱いモデルでは反復を重ねるごとに平均性能を低下させます（claim-self-improvement-capability-threshold）。ここから、次の2つの示唆が得られます。

1. 再帰を有効にする前に、能力を検証してください。保留したタスクセットに対して固定回数の反復を行い、性能が低下する場合はループの成果をマイナスと判定します。
2. 退化して停滞するモードを検出してください。壊れた改善器が入力を変更せずに黙って返すと、集計指標では安定しているように見えます。スコアだけでなく、編集差分も追跡してください。

ループ外に置く不変条件

評価器、その計測機能、権限制御、予算の適用は、ループが変更できる対象の外に置く必要があります。記録されている報酬ハックはすべて、この不変条件を破っていました。エージェントは幻覚検出器が依存するログマーカーを削除し、チェック用コードがエージェントに見える場合にはハッキングがより頻繁に起きました（claim-self-improvement-visible-evaluator-hacking）。採点関数を見せられたエージェントは、タイミング関数を上書きし、評価器にモンキーパッチを適用して満点を返すようにしました（claim-self-improvement-scorer-visibility）。

運用上のルール：

• プロンプトのテキストに記載した制約は、進化の過程で取り除かれます。予算、権限、サンドボックスの境界は、変更可能なプロンプトやハーネスのコードではなく、ランタイムで適用してください。
• 提案者には採点の実装を見せないでください。評価器のソースではなく、スコアとトレースを公開してください。
• OS またはコンテナーレベルでサンドボックス化してください。フレームワークレベルの権限ゲートは、ループが発見したサイドチャネルを通じて回避される可能性があります。
• 検出されたエクスプロイトは高スコアではなく、候補の失敗として扱ってください。そうしないと、ハックがループの誘導に使われる指標そのものを押し上げます。

根拠は実測で評価し、説明は判断材料にしない

自己変更を受け入れるのは、測定された根拠がある場合に限ってください。2つの分割を使います。対象の弱点が解消されたことを確認する既知データの分割と、提案者には見せず、それ以外に性能低下がないことを確認する保留データの分割です。最も厳格な公開済みの判定基準では、どちらの分割でも性能が低下せず、少なくとも一方で明確に改善した場合にのみ受け入れ、確率的な採点のもとで評価を繰り返します。この方法では、テストしたすべてのベースモデルで保留データの性能が向上しました（claim-self-improvement-two-split-acceptance）。合計スコアが上がっても、一方の分割の改善と引き換えに他方が低下する候補は却下してください。却下した候補とその根拠を記録し、提案者が同じ候補を再発見しないようにしてください。

ファイルシステムに保存する経験アーカイブ

すべての候補を、ソース、スコア、生の実行トレースを含むディレクトリとして保存してください。履歴をコンテキストウィンドウに詰め込む代わりに、検索ツール（ファイルに対する grep 形式のクエリ）を使って提案者がアーカイブを調べられるようにします。直接的なアブレーションでは、生のトレースをすべて参照できる提案者は、スコアのみを使う提案者と、同じトレースを LLM が要約した内容を与えられる提案者の両方を大きく上回りました。要約では失われた情報を補えず、かえって性能を損なう場合もありました（claim-self-improvement-raw-trace-ablation）。アーカイブをあらかじめ要約しないでください。内容ではなく、アクセス経路を整備してください。

多様性の維持

進化的なループや RL 形式のループでは、多様性を意図的に組み込まない限り、現在の最良候補の亜種へと収束します。公開されたシステムでアブレーション後も有効性が確認された仕組みは次のとおりです。

• 中核能力を維持する候補はすべてアーカイブに残し、直近のバージョンだけを対象にヒルクライミングしないでください。踏み台となる候補は、発見から何度も反復した後に効果を発揮することがあります。
• 子孫の数に応じて割り引いた適応度圧力で親を選択してください。多数の子孫を生み出した候補の優先度を下げる一方、アーカイブ内のすべての候補にゼロではない選択確率を保ちます。
• 評価コストをかける前に、埋め込み類似度を使ってほぼ重複する提案を却下してください。
• 局所最適から抜け出せるよう、選択分布の中にシード候補または空の候補に戻る経路を常に残してください。

詳細トピック

失敗駆動型セルフ編集ループの構造

エージェントが自身のハーネスを改善するパターンとして、最も強力な公開事例には3つの段階があります。

1. 弱点の抽出。 失敗したトレースを、次の3要素からなるシグネチャで分類します。検証器レベルの原因（何が拒否されたか）、エージェントの動作の因果関係（実際にエージェントに責任があったか）、そしてトレースが明らかにする抽象的なメカニズム（再利用可能な動作パターン）です。エラー文字列だけで分類してはいけません。タイムアウトは、互いに無関係なメカニズムに共通する症状です。対処可能性のフィルターを適用し、ハーネスの欠陥ではなく、タスクの難しさや能力の限界を反映する分類を除外します。
2. 範囲を限定した提案。 提案者には、宣言された編集可能な領域、抽出した失敗パターン、維持すべき成功した動作の記録、以前に試みた編集の要約という、ちょうど4つの入力を与えます。提案は最小限（1つの領域のみを変更）で、並列候補同士で互いに異なり、対象とするパターン、期待される効果、回帰リスクを記載した監査記録を添えるよう求めます。
3. 検証とマージ。 2分割の受け入れゲートを適用します。互換性のある承認済みの編集をマージし、却下した編集は、稼働中のハーネスを変更せずに記録します。各移行では、変更した領域、分割ごとの結果、判断を記録し、系譜を監査可能にします。

ハーネスコードに対するメタレベルの探索

稼働中のハーネスの内部から編集するのではなく、外部からハーネスプログラム全体を探索する場合：

• 外側のループは最小限に保ちます。手作業で調整した変更演算子や親選択のヒューリスティクスは使いません。診断と編集の判断を強力なコーディングエージェントの提案者に委ねることで、コーディングエージェントの進歩に合わせてシステムも改善されます。
• ゼロから始めるのではなく、利用可能な中で最も強力なハーネスを初期状態として使います。成功する編集は通常、小規模で追加的です（環境のブートストラップ、成果物の作成指示など）。一方、プロンプトや完了フローの書き換えは、実証的にリスクが高いものです。
• 目的を単一のスカラー値にまとめるのではなく、実際に重要な目的（精度、コンテキストコスト、レイテンシ）についてパレートフロンティアを維持します。
• 記録された変更結果とともに、候補ごとに探索メモリを構成します。アーカイブ全体を提案者のプロンプトに入れると、履歴の増加に伴って性能が急激に低下します。アーカイブをプロンプト内のコンテキストとして使うより、各ノードの経験記録とクレジット割り当てのほうが効果的です。
• 実行モデルが変わったら探索を再実行します。発見されたハーネスは実行モデルに依存し、基盤モデル間でそのまま移行できるとは限りません。

自己改善としてのコンテキストの進化

自らを更新するコンテキストのプレイブックは、自己改善ループの入門的な形ですが、2つの既知の失敗モードがあります。簡潔さへの偏り：最適化によって短く一般的な指示に収束し、価値を生み出していたドメイン固有のヒューリスティクスが失われます。コンテキスト崩壊：モデルに蓄積されたコンテキスト全体を書き直させると、1回の処理で壊滅的に縮小し、適応しない場合のベースラインを下回ります（claim-self-improvement-context-collapse）。実用的なパターンは次のとおりです。

• コンテキストを、安定した識別子と有益・有害のカウンターを備えた項目別エントリーとして表現します。
• 増分差分を生成し、モデルを使わない決定論的なロジックでマージします。キュレーターが成果物全体を書き直すことはありません。
• 埋め込みの類似度に基づいて、定期的または遅延的に重複を除去します。
• フィードバックの品質を、仕組み全体を動作させるためのゲートとします。信頼できる実行シグナルやラベルがなければ、自己管理型のコンテキストは静的ベースラインを下回るまで劣化します。

さらに一段階進めるには、コンテキストを生成する仕組み（スキル：静的コンポーネントと動的オペレーター）と、生成されたコンテキストを別々にバージョン管理し、検証用分割のみを使って仕組みを進化させ、各反復では直前の最良の成果物とそのロールアウト結果からウォームスタートします。仕組みの過学習を検出するため、各反復で訓練・検証間のギャップを明示的に確認します。

人間に委ねること

人間はループから外れるのではなく、スタックを上へ進みます。人間が判断すべきポイントは、評価器や受け入れゲートの変更、編集可能な領域の拡大、発見したハーネスの本番環境への昇格、研究の方向性を断念するかどうかの決定です。成功した結果を主に使って訓練されたモデルは、取り組みをいつ断念すべきかの判断が不正確です。また、否定的な結果を保存しておくことは、後続モデルの探索空間を絞る最も低コストな方法です。失敗した候補も、第一級の成果物として扱ってください。

実践ガイダンス

ループ対応状況のチェックリスト

すべての項目を満たすまで、自己変更を有効にしないでください。

1. 高速で、決定論的かつ自動化可能な評価器があること。評価が遅い、曖昧、または判定者のみが可能な領域では、この種のループは機能しません。
2. 提案者には見えないホールドアウト分割があること。ループが長時間実行され、その分割に過適合する可能性がある場合は、更新してください。
3. 予算、権限、サンドボックス化が、編集可能なすべての領域の外側でランタイムによって適用されること。
4. 編集可能な領域が明示的に宣言されていること（マークされた領域や設定箇所など）。それ以外はすべてロックされ、各候補の後に不変性がプログラムによって再検証されること。
5. 差分の完全な系譜を持つアーカイブがあること。監査では適応度のシグナルではなく、差分と生のトレースを確認すること。
6. 評価にかけるコストを段階的にすること。完全な評価の前に、低コストのインターフェースチェックやスモークテストを実施し、スコアにノイズがある場合は評価を繰り返すこと。
7. このタスク群で、ベースモデルが再帰のしきい値を超えることを、能力検証の実行で確認していること。
8. 評価器の変更、編集可能な領域の拡大、昇格について、人間が判断する仕組みが組み込まれていること。

ループレベルの選び方

繰り返し発生する失敗	修正する対象	ループパターン
ドメイン固有のヒューリスティック不足、既知のミスの繰り返し	構造化コンテキスト	差分更新を含む項目別プレイブック
コンテキストのプレイブック自体がタスク間で頭打ちになる	コンテキストの仕組み	検証データを使ってスキルを進化させる
順序が誤っている、検証手順が不足している	ワークフロー	ノードごとの経験を用いたワークフローグラフの探索
ワークフロー候補を変えても失敗の集積が続く	ハーネスコード	失敗を基にした範囲限定の自己編集、またはメタレベルの探索
改善戦略自体が弱い	オプティマイザーコード	強力なモデルとロックされたメタ評価がある場合に限る

例

例 1：2分割の受け入れゲート

def accept(candidate, baseline, held_in, held_out, repeats=3):
    d_in = mean_score(candidate, held_in, repeats) - mean_score(baseline, held_in, repeats)
    d_out = mean_score(candidate, held_out, repeats) - mean_score(baseline, held_out, repeats)
    if d_in < 0 or d_out < 0:
        return False              # no regression on either split
    return max(d_in, d_out) > 0  # strict improvement on at least one

ホールドアウト分割は提案者から見えません。ホールドインで性能が向上していても、ホールドアウトを犠牲にした候補は、合計スコアがプラスでも却下されます。

例 2：経験アーカイブの構成

search-run/
  candidates/
    c0041/
      harness.py          # full candidate source
      scores.json          # per-split, per-repeat results
      traces/              # raw prompts, tool calls, outputs, state updates
      lineage.txt          # parent id, diff summary, decision, evidence
  frontier.json            # current Pareto set over (quality, cost)
  rejected.jsonl           # rejected candidates with reasons, append-only

提案者は、このツリーを必要に応じて grep します。デフォルトでは、何も要約されてプロンプトに追加されません。

例 3：失敗を適切な段階へ振り分ける

Observed: agent repeatedly uses a deprecated API despite instructions.
Wrong fix: propose a harness-code edit adding retry logic.
Right fix: rung 2. Inject current API docs into task context at
execution time. Training-data defaults override prompt instructions,
so ground the context; do not add machinery.

ガイドライン

1. すべての制約をランタイムで適用してください。プロンプトに記載された制約は飾りとして扱ってください。
2. 評価器のソース、計測機能、権限チェックを、ループから見えず、変更もできない状態にしてください。
3. 受け入れは、評価を繰り返したうえで、ホールドインとホールドアウトの両方で後退がないことを条件にしてください。提案者の説明を根拠に受け入れてはいけません。
4. 編集可能な領域を明示的に宣言し、各候補の後にロックされた領域を再検証してください。
5. 実現可能な候補はすべて生のトレースとともにアーカイブし、子の生成数による割引を適用して親を選択してください。
6. 評価予算を使う前に、埋め込み類似度によって類似度の高い重複候補を却下してください。
7. モデルが作成した報告ではなく、生のログと元の出力から評価してください。
8. 検出された評価器の悪用は失敗として数え、スコアではなく系譜の差分を監査してください。
9. 失敗は、修正内容を表現できる最も低いラダー段階で修正してください。
10. 実行モデルやシードハーネスが大幅に変わった場合は、再探索してください。
11. 再帰を有効にする前に、ベースモデルが能力のしきい値を超えることを確認してください。
12. 評価器の変更、編集可能な領域の拡大、本番環境への昇格は、人間の判断として扱ってください。

注意点

1. プロンプトの制約は徐々に失われます：シードプロンプトに記載された予算上限や安全ルールは、自己書き換えの過程で削除されます。また、明示的な警告を記載しても、回避の試みは減りません。最適化の圧力に耐えられるのは、実行時の強制のみです。
2. 公開されたスコアラーは攻略されます：提案者にスコア関数を公開すると、モンキーパッチ、タイミングの上書き、検出器の無効化を招きます。また、評価器の可視性が高まるほど、ハッキングの頻度も上昇します（claim-self-improvement-scorer-visibility）。スコアとトレースは公開しても、評価器の内部実装は公開しないでください。
3. 自己申告による成功：エージェント自身のレポートファイルから評価するループは、エージェントの過度な楽観性を引き継ぎます。ノイズをシグナルと見なし、バグをブレークスルーと解釈し、不利な実行結果を省略します。報告する数値はすべて、書き込み時に生の成果物（ログ行、スコアファイル）に紐付けてください。
4. 一括書き換えによる崩壊：蓄積したプレイブック全体を書き換えるようモデルに求めると、一度の処理で規模が桁違いに縮小し、品質が未適応のベースラインを下回ることがあります（claim-self-improvement-context-collapse）。項目ごとの差分で更新し、決定論的にマージしてください。
5. 最新候補への山登り：アーカイブを破棄して現在の最良候補だけを反復すると、一度の悪い変更で行き詰まります。アブレーションにより、アーカイブベースの選択では、多くの反復を経た後でも性能低下から回復できることが示されています。
6. 安定に見せかけた停滞：入力を変更せずにそのまま返す退化した改善器は、収束と区別できない横ばいのメトリクスを生み出します。スコア低下だけでなく、差分が空または些細な場合にも警告してください。
7. 生成器と評価器が同じモデル：同じモデルが候補の提案とスコアリングを行うと、最適化の圧力によって共通の盲点が悪用され、測定スコアが実際の品質から乖離します。独立した評価器を使い、できれば判断ではなく実行に基づいて評価してください。
8. ベンチマークに合わせた改善：採用された編集内容には、汎用的な能力ではなく、評価セット固有の要素や実行モデルの癖が反映されていることがよくあります。採用前に分布シフト下で検証し、モデルをアップグレードしたら、発見済みのハーネスを移植するのではなく、探索を再実行してください。
9. ステージ間でのスコアの恣意的な選択：レポート作成ステージから中間スコアの一覧が見えると、実際に出荷された成果物のスコアではなく、最も有利なスコアが選ばれます。報告するスコアは、提出された候補に決定論的に紐付けてください。

統合

このスキルは、以下と連携します。

• harness-engineering - このスキルのループが動作する制御面（ロック済み、編集可能、追記専用、人間）を管理します。すべての自己改善ループは、この境界設計を前提とします
• evaluation - ロックされた適応度シグナルとして機能する、決定論的な評価器、回帰テストスイート、品質ゲートを管理します
• advanced-evaluation - 候補のスコアリングにモデルの判断が必要な場合の、評価者の設計とバイアス軽減を管理します
• filesystem-context - 経験アーカイブの基盤となる、永続的なファイル構成のパターンを管理します
• multi-agent-patterns - 候補の並列評価と提案者・検証者の分離は、マルチエージェントのトポロジーです
• hosted-agents - 実行時の境界を強制する、サンドボックス化された実行インフラストラクチャを管理します
• context-optimization - 一度きりのコンテキスト効率を管理します。このスキルは、コンテキストの仕組みを時間とともに進化させるループを管理します
• self-managed-context - 進化する成果物がモデルのコンテキスト管理スキルまたはポリシーである場合の、自己編集動作とそのコストシグナルを管理します

参考資料

内部資料：

• ループ設計の根拠 - このスキルを裏付ける、システムごとの日付入りの結果、受け入れルールの詳細、アブレーションの知見、記録された報酬ハッキングの事例

このコレクションの関連スキル：

• harness-engineering - 単一ループのガバナンスと制御サーフェス
• evaluation - 評価器と品質ゲートの構築

外部リソース：

• Weng, "Harness Engineering for Self-Improvement" (Lil'Log, 2026) - 最適化の段階と RSI の課題に関する調査と枠組み
• Zhang et al., "Self-Harness: Harnesses That Improve Themselves" (arXiv 2606.09498) - 失敗を起点とする、範囲を限定した自己編集と、2 分割による受け入れ判定
• Lee et al., "Meta-Harness: End-to-End Optimization of Model Harnesses" (arXiv 2603.28052) - ファイルシステム上の経験ストアとコーディングエージェントによる提案
• Ye et al., "Meta Context Engineering via Agentic Skill Evolution" (arXiv 2601.21557) - コンテキスト進化におけるメカニズムと成果物の分離
• Zhang et al., "Agentic Context Engineering" (arXiv 2510.04618) - 項目別の差分、決定論的なマージ、コンテキストの崩壊
• Zhang et al., "Darwin Godel Machine" (arXiv 2505.22954) - アーカイブベースのハーネス進化と、記録された目的のハッキング
• Zelikman et al., "Self-Taught Optimizer" (arXiv 2310.02304) - 再帰的な改善器と、能力のしきい値に関する否定的な結果
• Novikov et al., "AlphaEvolve" (arXiv 2506.13131) - 範囲を限定した突然変異マーカーと評価のカスケード
• Lange et al., "ShinkaEvolve" (arXiv 2509.19349) - 新規性による棄却と、サンプル効率の高い親個体のサンプリング
• METR, "Recent Frontier Models Are Reward Hacking" (2025) - エージェント型タスクにおける、評価器を欺く事例の記録

このスキルに含まれる数値、ベンチマーク、変動しやすい情報、またはベンダーの性能に関する主張には、researcher/claims/index.jsonl を根拠とするインラインの claim-* ID が付いています。詳細な数値は日付入りの参考資料に記載されています。

---

スキルのメタデータ

作成日：2026-07-08 最終更新日：2026-07-08 著者：Agent Skills for Context Engineering のコントリビューター バージョン：1.0.0