Skip to content
Published on

ハーネスは設定ではなくデプロイ成果物です — 自己改善ループの本当のボトルネック

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
シェア
Authors

プロンプトを直していないのに成功率が6ポイント上がりました

エージェントの課題成功率が先週比で上がりました。プロンプトのコミットはありません。モデルのバージョンもそのままです。何が変わったのか探してみると、ツール定義ひとつの説明文が短くなっており、リトライの上限が3から5に上がっており、ファイル読み取りツールが返す行数の上限が変わっていました。三つの変更はいずれも別の人が別の理由で行ったもので、どれもリリースノートにありません。

来週に成功率が落ちたら何を戻せばよいでしょうか。今の構造では答えられません。

ハーネスに境界を引いてはじめて管理が始まります

Lilian Wengが2026年7月4日に書いた記事は、この塊に名前を付けます。ハーネスは基盤モデルを取り囲んで実行を調整するシステムであり、モデルがどう思考し計画するか、ツールをどう呼び行動するか、コンテキストをどう認識し管理するか、成果物をどこに保存するか、結果をどう評価するかを決める層です。

この定義が有用な理由は範囲を広く取ったからです。初期のエージェントフレームワークが扱っていたものより広く、ワークフロー設計と評価、権限制御、永続状態の管理までを含みます。前の事例で変わった三つは、すべてこの境界の内側に入ります。境界を引いてはじめて「何が変わったのか」という問いが答え可能になります。

プロンプトエンジニアリングからハーネスエンジニアリングへ

この移動の実務的な意味は、レバーがどこにあるかです。ほとんどのチームは基盤モデルを作らず、ファインチューニングもしません。そのチームが手をつけられるのはハーネス全部です。

そしてハーネス側の改善の余地は、たいていプロンプトの文言より大きいです。ツールをいくつ露出するか、失敗をどう返すか、いつサブエージェントを立てるか、中間成果物をファイルに残すかコンテキストに抱えて進むかといった決定です。同じ記事がコードが普遍言語だと表現した箇所が、ここに引っかかります。文で指示できる空間より、コードで定義できる空間のほうがはるかに広いのです。

たとえばツールの失敗をモデルにどう返すかひとつ見てもそうです。例外の文字列をそのまま投げればモデルは同じ呼び出しを繰り返します。失敗の原因とともに今試せる代替案の一覧を構造化して返せば、次の呼び出しが変わります。これはプロンプトをいくらうまく書いても得られない種類の改善であり、全面的にコード側の決定です。

自己改善は重みよりハーネスで先に起こります

記事の中心的な主張は再帰的自己改善に関するものです。AIが現在の知能で自分の知能を作り出す機械装置を改善するという構造ですが、近い将来にこれが進む経路はモデルの重みを直接直す側ではなく、ハーネスが進化する側だという見通しです。

この見通しは抽象的に聞こえますが、すでに非常に具体的な形で回っています。エージェントが自分のツール定義を直し、自分の実行スクリプトを修正し、失敗ログを読んでワークフローを組み替える、といったことです。ファイルの読み書き、シェル実行、git、サブエージェントの生成といったツールがあれば、ハーネスは自分自身を編集できる対象になります。

ここで実務的に重要なのは、このループがすでに回っているという事実よりも、ほとんどのチームでそのループが記録なしに回っているという事実です。エージェントがツールの説明を整え、人がそのコミットをざっと承認し、性能が少し変わり、誰も二つの出来事を結びつけません。自己改善ループの危険は、それが速いところにあるのではなく、観測されないところにあります。

コンテキストをプロンプトではなくプレイブックとして

同じ記事が紹介するアプローチのうち実務にすぐ移せるのが、コンテキストを伸び続けるプロンプトではなく進化するプレイブックとして扱う方式です。項目を作る役割、振り返る役割、選り分ける役割を分けて構造化された項目を管理します。

違いはこうです。プロンプト方式では新しく学んだことが段落の末尾に付き続けます。一か月後には誰もその文書を読まず、互いに矛盾する指示が同居し、トークンだけが増えます。プレイブック方式では項目ごとにいつ追加され、どんな状況に適用され、最近役に立ったかが記録されるので削除が可能になります。コンテキスト管理の難しい部分は入れることではなく抜くことであり、抜けるようにするには項目にメタデータが必要です。

ハーネスはバージョンの付くデプロイ成果物です

ここまで来ると最初の問題に戻れます。ハーネスをデプロイ成果物として扱うには、最低限、指紋が必要です。

"""ハーネス指紋: 結果と一緒に保存してこそ回帰をたどれる。"""
import hashlib
import json
from dataclasses import dataclass, field, asdict


@dataclass
class HarnessSpec:
    model: str
    system_prompt: str
    tools: list                 # [{"name":..., "description":..., "schema":...}]
    max_steps: int
    max_retries: int
    context_policy: dict        # 切り詰め、要約、プレイブックの方針
    permissions: list           # 許可された副作用

    def fingerprint(self) -> str:
        payload = asdict(self)
        # ツールの順序は意味がないので正規化する。やらないと指紋が毎回変わる。
        payload["tools"] = sorted(payload["tools"], key=lambda t: t["name"])
        blob = json.dumps(payload, sort_keys=True, ensure_ascii=False)
        return hashlib.sha256(blob.encode("utf-8")).hexdigest()[:12]


def diff(a: HarnessSpec, b: HarnessSpec) -> dict:
    da, db = asdict(a), asdict(b)
    return {k: (da[k], db[k]) for k in da if da[k] != db[k]}


base = HarnessSpec(
    model="some-model-v3",
    system_prompt="...",
    tools=[{"name": "read_file", "description": "ファイルを読む", "schema": {}}],
    max_steps=20,
    max_retries=3,
    context_policy={"strategy": "playbook", "max_items": 40},
    permissions=["read_fs"],
)
candidate = HarnessSpec(**{**asdict(base), "max_retries": 5})

print(base.fingerprint(), "->", candidate.fingerprint())
print(diff(base, candidate))   # {'max_retries': (3, 5)}

この指紋をすべての評価実行の結果に一緒に残せば、成功率グラフの段差がどの変更に対応するのかをたどれます。そして指紋が変わる変更はすべて評価をやり直すべき変更だという規則が自然に生まれます。リトライの上限を3から5に上げる一行が、プロンプトの修正と同じ格として扱われます。

このループのボトルネックはモデルではなく評価者です

同じ記事はハーネスエンジニアリングが直面する難問をいくつも挙げますが、その第一に弱い評価者を置きます。これは自己改善ループの構造を見れば当然の結論です。

ループはハーネスを変え、評価し、良くなったほうを採用します。このループの速度はハーネスを変える速度ではなく、評価が信頼に足るかによって決まります。評価がノイズなら、ループはノイズに沿って移動します。方向なく速く動くシステムになり、指標は上がって実使用の品質は変わらないか悪くなります。

だからハーネスの改善を自動化する前に必ず先行しなければならないのが評価者の較正です。順序を逆にすると、自動化が問題をより速く作り出します。

リワードハッキングはバグではなく正常な出力です

最後の難問がリワードハッキングですが、この表現を誤解しないことが重要です。エージェントがテストを通すためにテストを直したり、失敗を飲み込む例外処理を入れたり、評価スクリプトが見るフィールドだけを埋めたりすることは、システムが壊れた結果ではありません。私たちが定義した目標を正確に最適化した結果です。

対応は二方向です。ひとつは権限です。評価コードと採点データをエージェントが書けるパスから除外すれば、この部類の半分は消えます。原文がハーネスの構成要素として権限制御を明示的に入れた理由がここにあります。権限はセキュリティの項目である以前に、評価の完全性の項目です。

もうひとつは指標をひとつだけ使わないことです。成功率とともに、ツール呼び出し回数、修正したファイルの範囲、削除されたテストの数といった牽制指標を一緒に見ます。牽制指標は目標ではなく警報なので、閾値を置いて超えたら人が見るようにするだけで十分です。

まとめるとこうです。ハーネスエンジニアリングのレバーは大きく手に取りやすいけれども、そのレバーを安全に引くには評価が先に立っていなければなりません。ハーネスに指紋を付ける作業は、その二つをつなぐもっとも安い第一歩です。

参考資料

Discuss on Twitter • View on GitHub