AIエージェントを自動最適化！Meta-Harness入門
私がソフトウェアエンジニアとしてキャリアをスタートさせた15年前、システムの振る舞いはすべて決定論的なコードで記述されていた。それが今や、LLMという非決定論的な「脳」をどうシステムに組み込むかという、全く異なるパラダイムで我々は格闘している。最近、エージェント開発の現場で嫌というほど実感するのは、LLMそのものの性能以上に「LLMの周辺コード」がプロダクトの成否を分けるという事実だ。
RAGの実装一つをとっても、チャンクの分割サイズ、検索結果をいくつコンテキストに含めるか、過去の対話履歴をどう要約して保持するか。外部ツールを呼び出す際のエラーハンドリングやリトライのロジックはどうするか。現在のAI開発において、我々エンジニアは「賢い脳」を使いこなすための泥臭い配管工事に多大な時間を奪われている。
「足場」自体を自動探索空間に落とし込む
スタンフォード大学のチームから公開された「Meta-Harness」は、まさにこの痛いところを突いてきた野心的なフレームワークだ。論文のタイトルにもある通り、彼らが最適化のターゲットに据えたのは「モデルハーネス（Model Harness）」である。
ハーネスとは、モデルがタスクを遂行する際に「何を保存し、何を検索し、何をプロンプトに提示するか」を決定する周辺のコード群を指す。これまで我々は、タスクが変わるたびにこのハーネスを手作業で書き換えてきた。Meta-Harnessは、Claude Codeのようなプロポーザー（提案）エージェントを用いて、この「システムアーキテクチャのコードそのもの」を自動で探索・進化させてしまおうというのだ。
| アプローチ | 最適化の対象 | 最適化の主体と手法 |
|---|---|---|
| 従来の手法 | プロンプト文字列・静的なスクリプト | 人間によるヒューリスティックな試行錯誤 |
| DSPy等のフレームワーク | プロンプト内のシグネチャ・パイプラインの重み | コンパイラ的な少数ショットの自動チューニング |
| Meta-Harness | モデル周辺のPythonコード（状態管理や検索ロジック） | プロポーザーエージェントによるコード生成・探索ループ |
DSPyが「プロンプトとパイプラインの自動化」をもたらしたのだとすれば、Meta-Harnessは「ソフトウェア設計の自動化」へと一歩踏み込んでいる。単なるパラメータチューニングではなく、記憶の持ち方やツールの叩き方といったロジックの構造自体が、タスクのスコアを最大化するように書き換わっていくというのだから恐ろしい。
対話から始まる新しいオンボーディング
このリポジトリの設計で特に興味深いのは、新しいドメイン（タスク）への適用プロセスである。通常、こうしたフレームワークを使う際は長大なYAMLファイルや複雑なクラスの継承を要求されるものだが、Meta-Harnessのアプローチは少し違う。
開発者はまず、リポジトリに含まれる ONBOARDING.md を自身のコーディングアシスタント（Claude等）に読み込ませる。そして「こんなタスクのエージェントを作りたい」と対話を行うのだ。すると、アシスタントがフレームワークの思想を理解した上で、具体的な実装方針を記した domain_spec.md を出力してくれる。
もちろん、リポジトリには即座に動かせる参照実装も用意されている。例えばテキスト分類のハーネス最適化であれば、最新のPythonパッケージマネージャである uv を使って数行で実行可能だ。
cd reference_examples/text_classification
uv sync
uv run python meta_harness.py --iterations 1
このスクリプトを実行すると、背後でプロポーザーエージェントが既存のハーネスコードを読み込み、より効率的なメモリシステムを提案してコードを改変し、評価を回すというサイクルが回り始める。
エージェント工学の進化は止まらない
複雑なコマンドライン環境の操作を評価する「Terminal-Bench 2」のような難解なベンチマークにおいて、人間が事前に設計した固定の足場（Scaffold）には限界がある。タスクの性質に応じて、動的に最適なアーキテクチャを模索するアプローチは、今後のエージェント開発において間違いなく主流になっていくだろう。
AIが自らの能力を最大限に引き出すための「システム」を、AI自身が設計し、コーディングする。Meta-Harnessの登場は、そのような再帰的な自己進化の時代が、研究室のアイデアから現実のコードへと落ちてきた決定的な証拠だ。
参考リポジトリ: stanford-iris-lab/meta-harness