自己改善のためのハーネスエンジニアリング

目次 ハーネス設計パターン パターン1: ワークフロー自動化 パターン2: ファイルシステムを永続メモリとして利用 パターン3: サブエージェントとバックエンドジョブ ケーススタディ: コーディングエージェントハーネス ハーネス層 vs コアインテリジェンス? Harness Optimization コンテキストエンジニアリング ワークフロー設計 自己改善ハーネス 進化的探索 モデルウェイトとの共同最適化 将来の課題 引用 付録: いくつかの有用なベンチマーク 参考文献 再帰的自己改善（RSI）の概念は、I. J. Good（1965）にまで遡り、彼は「超知能マシン」を、すべての知的活動において人間を凌駕し、自身を改善するためのより良いマシンを設計できるシステムと定義しました。Yudkowsky（2008）は、「再帰的自己改善」というフレーズを、特定のフィードバックループに対して使用しました。すなわち、AIはその現在の知能を使用して、その知能を生み出す認知メカニズムを改善します。現代のAIにおけるこのフィードバックループは、モデルが自身のウェイトを直接書き換えること、またはより広範には、モデルがトレーニングパイプラインとデプロイメントシステムを改善し、それが結果として経済的に価値のあるタスク全体でパフォーマンスが向上した、より良い後継モデルを可能にすることを示唆する可能性があります。AIにおける研究開発の速度は、フロンティアラボ（Anthropic; OpenAI）で劇的に加速することが示されています。私は「デプロイメントシステム」を明示的に言及します。なぜなら、生のモデルと現実世界のコンテキストの間のレイヤーが、モデルの生の知能（すなわち、事前トレーニング直後の評価）と同じくらい重要であるように見えるからです。ハーネスはAIデプロイメントの重要なコンポーネントであり、Claude CodeやCodexのような成功したコーディングエージェント製品によって示されています。ハーネスとは、基盤モデルを取り囲み、実行をオーケストレーションし、モデルがどのように考え、計画し、ツールを呼び出し、行動し、知覚し、コンテキストを管理し、成果物を保存し、結果を評価するかを決定するシステムです。この投稿では、ハーネスエンジニアリングに関する研究と、それがRSIにどのように貢献するかを中心に説明します。最近の自動リサーチ、自己改善エージェント、および進化的プログラム検索に関する多くの作業は、この質問を中心に整理できます。モデルの自己プレイ、合成データ、テストタイムトレーニング、および継続的学習というより広範なテーマに関する他の作業もRSIのビジョンに合致していますが（例: Yuan et al. 2024, Chen et al. 2024, Zhao et al. 2025, Choi et al. 2026）、それらはこの投稿の焦点ではありません。 ハーネス設計パターン# 初期のエージェントフレームワークと比較して、「エージェント = LLM + メモリ + ツール + プランニング + アクション」という構造に対し、ハーネスエンジニアリングはさらにワークフロー設計（例: ループエンジニアリング）、評価、権限制御、および永続状態管理を含みます。もはやプロンプトテンプレートだけではなく、ランタイムやソフトウェアシステムの設計に近くなります。モデルがどのように観察し、行動し、記憶し、自己チェックし、改善するかです。設計は、一般化を可能にするために意図的にシンプルかつ汎用的であるべきであり、事前知識の恩恵を受けるために既存のソフトウェアエンジニアリングの実践を参照する可能性が高いです。オペレーティングシステムとハーネスの間には強い類似性もあります。OSと同様に、ハーネスは複雑なロジックをカプセル化しながら、インターフェースをシンプルに保つべきです。同時に、設定、ツールインターフェース、その他のプロトコルは、業界全体で標準化されていく可能性があります。 パターン1: ワークフロー自動化# モデルが操作、テスト、反復できるワークフローを定義することは、自動化の重要な設計です。Karpathyのautoresearchリポジトリ（https://github.com/karpathy/autoresearch）は、そのようなワークフローを構築できるクリーンな例です。一般的なワークフローは、目標指向のループ（計画、実行、観察/テスト、改善、そして目標達成まで再度実行）に従います。このプロセスは、タスクの仕様または実行の好みを明確にするために、ユーザーに積極的な要求をトリガーする可能性があります。簡略化されたCodexエージェントループ: エージェントはツールを呼び出し、ツールの応答がモデルの次の生成に影響します。（画像ソース: OpenAI codex agent post） ワークフローグラフは、モデルが自身の軌跡と失敗ケースを分析し、静的なプロンプトテンプレートではなく「エージェントランタイム」を通じて進捗を反復することをも強調しています。 パターン2: ファイルシステムを永続メモリとして利用# 長期間にわたるエージェントシステムで繰り返し現れるパターンは、リッチな状態と成果物に対するシンプルな制御です。ハーネスは、ワークフロー全体とすべてのログをコンテキストに含めるべきではありません。代わりに、ファイルを介して耐久性のある状態を維持する必要があります。長期間にわたるエージェントのロールアウトでは、実験ログ、コード差分、論文要約、エラートレース、過去のロールアウト軌跡などの成果物は、モデルがトレーニングされたコンテキストウィンドウよりもはるかに長くなることがよくあります。ファイルシステム（通常はbashコマンド経由）の読み書き、編集を学ぶことは、LLMの基本的なスキルであり、したがって、ファイルの単純な形式での永続メモリの管理は、コアモデル機能の改善から自然に恩恵を受けます。 パターン3: サブエージェントとバックエンドジョブ# ハーネスは、複数のサブエージェントを並列実行するためにスポーンし、バックエンドジョブを監視できます。これは、メインエージェントが複数の仮説を検索したり、実験を並行して実行したり、メインコンテキストを汚染せずに分離されたサブタスクを委任したりする必要がある場合に役立ちます。親エージェントには、小さなプロセス管理者が必要になります。ジョブを起動し、ログを検査し、失敗した実行をキャンセルし、結果をメインエージェントスレッドにマージします。重要な設計上の選択は、並列処理を明示的かつ検査可能にすることです。サブエージェントの出力が一時的なチャットコンテキストにのみ存在する場合、それらはすぐに時代遅れになり、隠されてしまいます。それらがファイル、ログ、ステータスレコードとして保存されていれば、モデルは中断後に回復し、自身の実行履歴を推論できます。 ケーススタディ: コーディングエージェントハーネス# Claude Code、Codex、OpenCode、およびCursorスタイルのエージェント全体で、主流のコーディングエージェントのコアインターフェースが安定してきました。それらは一般的に次のようなループを使用します: ツールセットへのアクセスにより、コーディングエージェントは、人間がIDEを備えているのと同様に、指定されたリポジトリ内の問題を開発およびデバッグできます。（包括的なリストではありません。デモンストレーションのために表示されています。興味があればこちらをお読みください。） グループ ツール定義 ファイルシステム - ファイル発見: glob, grep, ls - ファイル読み込み: read, read_many - ファイル変更: write (全く新しいファイル); edit (文字列完全一致置換); multi_edit; apply_patch (構造化されたパッチ/diffを適用) シェル実行 コマンド実行: bash, PowerShell IO lsp, gitツール (git_status, git_diff, git_commitなど) 外部コンテキスト MCPツール, スキル Web検索 web_search, web_fetch, browserツール 成果物 ドキュメント、画像を読み込む; HTML、画像を生成する バックエンドプロセス 例: CronCreate, CronDelete, CronList エージェント委任 例: spawn_agent, resume_agent, wait_agent, list_agents, close_agent, interrupt_agent, など Harness層 vs コアインテリジェンス?# 将来のRSIがハーネスエンジニアリングにどれほど依存するかを予測するのは難しいですが、RSIの実用的な短期的なパスが、モデルが直接自身のウェイトを書き換えることから始まる可能性は低いです。私の実用的な短期的なパスの予測は次のとおりです。 Harnessエンジニアリングは、メタ方法論（すなわち、単に回答自体を改善するだけでなく、より良い回答を得るためのメカニズムを改善する方向）へと進化するでしょう。ハーネスシステム自体が最適化ターゲットとなり、ヒューリスティックなルールは少なくなり、より汎用的なメカニズムが増えるでしょう。その結果、成熟したハーネスはモデルの自己改善ループのための自動リサーチを可能にし、よりスマートなモデルはハーネスが過剰に設計されるのを防ぎ、システムを持続可能に保ちます。最終的には、多くのハーネスの改善がコアモデルの動作に内部化される可能性がありますが、外部コンテキストやツールとのインターフェースは維持されるべきです。プロンプトエンジニアリングでこのパターンのよりソフトなバージョンを見てきました。手動のプロンプトトリックは、インストラクションチューニングとモデルの推論が改善されるにつれて中心性を失いましたが、目標、制約、コンテキスト、および評価を指定する必要性は消えませんでした。 Harness Optimization# Harnessシステムで最適化される対象の進行は、大まかに次のようになります。インストラクションプロンプト → 構造化コンテキスト → ワークフロー → ハーネスコード → オプティマイザーコード。モデルがより知的で強力になるにつれて、私たちは