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

再帰的自己改善（RSI）の概念は、I. J. Goodが1965年に定義した「超知能機械」に起源を持ちます。それはあらゆる知的活動で人間を凌駕し、より優れた機械を設計して自己改善するシステムです。Yudkowsky（2008年）はこのフレーズを、AIが現在の知能を使ってその知能を生み出す認知機構を改善する特定のフィードバックループとして用いました。現代のAIでは、このフィードバックループはモデルが直接自身の重みを書き換える形、あるいはより広範にはモデルがトレーニングパイプラインとデプロイメントシステムを改善し、経済的に価値のあるタスクで優れた性能を持つ後継モデルを可能にする形で現れます。フロンティアラボ（Anthropic、OpenAI）におけるAI研究開発の速度は劇的に加速していることが示されています。

デプロイメントシステムを明示的に言及する理由は、生のモデルと現実世界のコンテキストの間の層が、モデルの生の知能（すなわちプリトレーニング直後の評価）と同様に重要だからです。成功したコーディングエージェント製品（Claude CodeやCodexなど）は、ハーネスがAIデプロイメントの重要な要素であることを示しています。ハーネスとは、ベースモデルを囲むシステムであり、実行を orchestrate し、モデルがどのように思考、計画、ツール呼び出し、行動、コンテキストの知覚と管理、アーティファクトの保存、結果の評価を行うかを決定します。本記事は、ハーネスエンジニアリングの研究とRSIへの貢献に焦点を当て、自動研究、自己改善エージェント、進化的プログラム検索などの分野の研究を整理します。

ハーネスのデザインパターン

初期のエージェントフレームワーク（「エージェント＝LLM＋メモリ＋ツール＋計画＋行動」）と比較して、ハーネスエンジニアリングは追加でワークフロー設計（ループエンジニアリングなど）、評価、許可制御、永続状態管理を含みます。もはやプロンプトテンプレートだけではなく、ランタイムとソフトウェアシステム設計に近いものとなっています：モデルがどのように観察、行動、記憶、自己チェック、改善するかです。設計は意図的にシンプルで汎用的であるべきで、既存のソフトウェアエンジニアリングプラクティスを参照してプリトレーニング知識の恩恵を受けることができます。ハーネスはオペレーティングシステムと強い類似性を持ちます。複雑なロジックをカプセル化しつつ、インターフェースをシンプルに保つべきです。一方、設定、ツールインターフェース、その他のプロトコルは業界全体で徐々に標準化される可能性があります。

パターン1：ワークフロー自動化

モデルが操作、テスト、反復できるワークフローを定義することは自動化の鍵です。Karpathyのautoresearchリポジトリはそのクリーンな例です。一般的なワークフローは目標指向のループに従います：計画、実行、観察/テスト、改善、そして目標達成まで繰り返します。プロセスは、タスク仕様や実行の好みの明確化のためにユーザーに積極的にリクエストを送ることもあります。簡略化されたCodexエージェントループでは、エージェントがツールを呼び出し、ツール応答がモデルの次の生成に影響を与えます。ワークフローグラフは、モデルが自身の軌跡と失敗事例を分析し、静的なプロンプトテンプレートではなく「エージェントランタイム」を通じて反復することを強調します。

パターン2：ファイルシステムを永続メモリとして

長期間のエージェントシステムで繰り返し現れるパターンは、豊かな状態とアーティファクトに対するシンプルな制御です。ハーネスはワークフロー全体とすべてのログをコンテキストに保持すべきではなく、代わりに永続状態をファイルに保持します。長期間のエージェントロールアウトでは、実験ログ、コード差分、論文要約、エラートレース、過去のロールアウト軌跡などのアーティファクトが、モデルが訓練されたコンテキストウィンドウよりもはるかに長くなることがよくあります。ファイルシステムの読み書き、編集（通常はbashコマンド経由）はLLMの基本スキルであり、そのためファイルの形で永続メモリを管理することは、コアモデル能力の向上から自然に恩恵を受けます。

パターン3：サブエージェントとバックエンドジョブ

ハーネスは複数のサブエージェントを生成して並列実行し、バックエンドジョブを監視できます。これは、メインエージェントが複数の仮説を検索したり、実験を同時に実行したり、メインコンテキストを汚染せずに分離されたサブタスクを委任する必要がある場合に有用です。親エージェントは小さなプロセスマネージャーを必要とします：ジョブの起動、ログの検査、失敗した実行のキャンセル、結果をメインスレッドにマージします。重要な設計上の選択は、並列性を明示的かつ検査可能にすることです。サブエージェントの出力が一時的なチャットコンテキストにのみ存在する場合、すぐに陳腐化して隠れてしまいます。ファイル、ログ、ステータスレコードとして保存されれば、モデルは中断後に回復し、自身の実行履歴に対して推論できます。

ケーススタディ：コーディングエージェントハーネス

主流のコーディングエージェントの中核インターフェースは、Claude Code、Codex、OpenCode、Cursorスタイルのエージェント間で安定しています。これらは一般的に次のようなループを使用します：

• ツールグループ定義：ファイルシステム（発見、読み取り、変更）、シェル実行、IO（lsp、git）、外部コンテキスト（MCP、スキル）、ウェブ検索、アーティファクト（ドキュメント読み取り、HTML生成）、バックエンドプロセス（Cron）、エージェント委任など。

ハーネス層 vs. コア知能？

将来のRSIがハーネスエンジニアリングにどの程度依存するかを予測するのは困難ですが、近い将来のRSIの道筋はモデルが直接重みを書き換えることから始まる可能性は低いです。私の予測する実用的な近未来の道筋は次の通りです：

ハーネスエンジニアリングはメタ方法論の方向に進化します—すなわち、答え自体を改善するだけでなく、より良い答えを得るための仕組みを改善します。ハーネスシステム自体が最適化目標となり、ヒューリスティックなルールは減り、より汎用的なメカニズムが採用されます。成熟したハーネスはモデル自己改善ループのための自動研究を可能にし、よりスマートなモデルはハーネスの過剰エンジニアリングを防ぎ、システムを持続可能に保ちます。最終的には、多くのハーネス改善がコアモデル行動に内面化される可能性がありますが、外部コンテキストやツールとのインターフェースは残るべきです。プロンプトエンジニアリングでこのパターンのソフトバージョンを見てきました：手動プロンプトのトリックはインストラクションチューニングとモデル推論の改善により中心ではなくなりましたが、目標、制約、コンテキスト、評価を指定する必要はなくなりませんでした。

ハーネス最適化

ハーネスシステムで最適化される対象の進行はおおよそ次の通りです：インストラクションプロンプト → 構造化コンテキスト → ワークフロー → ハーネスコード → オプティマイザコード。モデルがより知的で強力になるにつれて、より複雑な目標とより汎用的な方法へと移行します。

コンテキストエンジニアリング

すべてのツール応答とモデル生成を単純にコンテキストに追加すると、エージェントジョブの期間が大幅に増えるにつれて急速に制御不能になります。コンテキスト管理は、LLMのために構造化された簡潔なコンテキストを構築し、永続状態を管理する層です。長いコンテキストの研究は進歩し続けるでしょうが、現時点では長いコンテキストの知能とコンテキストエンジニアリングは時々絡み合います。

エージェンティックコンテキストエンジニアリング（ACE; Zhang et al. 2025）は、コンテキストをますます長くなるプロンプトではなく、進化するプレイブックとして扱います。これには3つのコンポーネントがあります：

• ジェネレーター：タスクの軌跡を生成し、箇条書きを参照。
• リフレクター：成功した軌跡と失敗した軌跡から洞察を抽出。
• キュレーター：段階的で項目化されたエントリで構造化コンテキストを更新。

反復的な書き換え中のコンテキスト崩壊と簡潔性バイアスを防ぐため、ACEの重要な設計上の選択は、キュレーターが完全なプロンプトブロブを書き換えないことです。代わりに、（識別子、説明）の形式で構造化された項目化された箇条書きの集合を出力し、これらの箇条書きは決定論的なロジックで構造化コンテキストログブックにマージされます。コンテキスト項目は定期的に洗練され重複排除されます。

ACEがロールアウトから洞察を学習するという事実は、自己管理メモリへの移行に役立ちますが、更新ルールとワークフロー全体は依然として手作りのままです。より自己改善ループへ移行するために、メタコンテキストエンジニアリング（MCE; Ye et al. 2026）は、メカニズム（コンテキストの管理方法）をアーティファクトコンテンツ（コンテキストに何があるか）から分離し、メタ最適化レベルでスキル進化を、ベースレベルでコンテキスト最適化を実行します。

MCEスキル$s \in \mathcal{S}$は、コンテキスト関数$c_s=(\rho_s,F_s)$を定義し、入力$x$をコンテキスト$c = F_s(x;\rho_s)$にマッピングします。ここで、$\rho_s = \{\rho_1,\dots,\rho_m\}$は静的コンポーネント（プロンプト、知識ベース、コードライブラリ）、$F_s = \{F_1,\dots,F_k\}$は動的オペレーター（検索、選択、フィルタリング、フォーマット）です。二段階最適化は、トレーニングデータ上でスキル$s$が与えられた最適なコンテキスト$c_s^*$を見つける内部ループと、バリデーションセットで最良のパフォーマンスを提供する最適なスキルを見つける外部ループからなります。

スキルデータベースは、過去のスキル、コンテキスト関数、評価指標の履歴$\mathcal{H}_{k-1} = \{(s_i,c_i,J_i^\text{train}, J_i^\text{val})\}_{i=1}^{k-1}$を追跡します。メタレベルのエージェントは、タスク$\tau$が与えられたときに、以前のスキルに対してエージェンティック交叉を実行して新しいスキルを作成します：$s_k=\text{crossover}(\tau,\mathcal{H}_{k-1})$。次に、ベースレベルのコンテキストエンジニアがスキル$s_k$を実行し、ロールアウトフィードバック$\mathcal{R}_k$からコンテキスト関数を学習します。これは現在のスキルによって導かれます：$c_k=\text{engineer}(\tau,s_k;c_{k-1}^*,\mathcal{R}_k)$。

MCEはACEのようにコンテキストの構造化方法にヒューリスティックなルールを強制しません。タスクにとって最も重要な知識を保存するために自由形式のスキルを使用し、スキルとスキル条件付きコンテキストを反復的に共進化させます。実装では、コンテキスト関数$c$は専用ディレクトリ内のファイルの集合としてインスタンス化され、静的コンポーネント（skill.md）と動的コンポーネント（コンテキストとデータロールアウト）の両方を含みます。メタレベルとベースレベルの両方の最適化は、標準ツールセットを使用したエージェンティックコーディング環境で実行されます。

メタハーネス（Meta-Harness; Lee et al. 2026）は、最適化をもう一段深く進めます。最適化対象は、どの情報を保存、取得、モデルに提示すべきかを決定し最適化するコードです。そのメタループ最適化アルゴリズムでは、提案者が新しいハーネス設定を作成し、評価者が並行してスコアリングし、進化者が交叉と突然変異を通じて改善バージョンを生成します。このアプローチは、ハーネス設計を検索可能な空間として扱い、システムがより効率的な相互作用パターンを自動的に発見できるようにします。

結論として、ハーネスエンジニアリングはRSIにおいて中心的な役割を果たし、手動プロンプトから自律的で自己改善的なシステムへの架け橋を提供します。モデル能力が向上するにつれて、ハーネス自体がますます知的で適応的になり、最終的にはモデル行動に内面化される可能性がありますが、外部世界とのインターフェースは残り続けるでしょう。