Skip to content
←

필사 모드: ハーネスエンジニアリングとは何か — モデルは固定入力、デプロイするのはその周り全部です

日本語
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

同じモデルなのに、なぜ結果が違うのか

2つのチームが同じ基盤モデルで同じ種類の課題を自動化するとします。一方のチームのエージェントはイシューを受け取ってテストが通るパッチを作り上げ、もう一方のエージェントは似たイシューでファイルを漁ったまま途中で止まります。この対比は説明のために構成した例ですが、構図そのものはエージェントを運用したことのあるチームなら見覚えがあるはずです。モデルが同じなら、差はモデルの外から来たものです。

モデルの外に何があるかを書き出してみると、リストは思ったより長くなります。どのツールを何個公開したか。ツールが失敗したときモデルに何を返すか。何回まで再試行し、何を根拠に止まるか。毎ターン、コンテキストウィンドウに何を入れて何を外すか。エージェントがどのパスまで書き込めるか。そして結果が良かったかどうかを、誰がどんな基準で判定するか。このリスト全体がコードとして存在し、デプロイされ、課題成功率を動かします。

ハーネス：モデルを取り囲む実行システム全部

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

この連載では、その境界の内側を6つのつまみに分けて扱います。

  • ツール表面 — モデルに公開するツールの集合とスキーマ。何個を、どんな名前と説明で渡すか。
  • 失敗の返し方 — ツールが失敗したとき、例外文字列をそのまま返すか、原因と代替案を構造化して返すか。
  • ループ — 再試行上限、停止条件、詰まったときのエスカレーション。
  • コンテキストポリシー — 何を入れ、何を外し、いつ要約するか。
  • 権限 — エージェントが読み書きできる範囲。特に評価コードがその中にあるかどうか。
  • 評価者 — 結果を判定する採点器。これがシステム全体の上限を決めます。

前提はひとつです。ほとんどのチームにとって、モデルは固定入力です。基盤モデルを作らずファインチューニングもしないチームが手を入れられるのはこの6つが全部であり、同時にこの6つだけで十分に広いのです。

「プロンプトエンジニアリング」という名前が隠すもの

この仕事を長く呼んできた名前はプロンプトエンジニアリングでした。その名前が間違っているわけではありませんが、範囲を大きく過小評価しています。プロンプトは上の6つのつまみのどこにも単独項目としては現れません。システムプロンプトはコンテキストポリシーの一部であり、ツール説明の文言はツール表面の一部です。文章で指示できる空間よりコードで定義できる空間のほうがはるかに広く、成功率を大きく動かす決定はほとんど後者にあります。

Anthropicが2024年12月に公開したエージェント構築ガイドは、この点をツール側から突いています。人間にUIがあるように、エージェントにはツール定義がインターフェースなのだから、プロンプトにかけるのと同じだけの手間をツール設計にかけるべきだ、というものです。同じ記事は、自社のSWE-bench作業では全体のプロンプトよりツールの最適化に多くの時間を使ったと書いています。

失敗の返し方も同じ種類の例です。例外文字列をそのまま返すハーネスではモデルは同じ呼び出しを繰り返しがちで、失敗の原因といま試せる代替案を構造化して返すハーネスでは次の呼び出しが変わります。この差はプロンプトをどれだけ磨いても得られません。完全にコード側の決定です。

ワークフローでもエージェントでも、ハーネスはある

同じAnthropicの記事は、エージェント型システムを2つに分けます。ワークフローはLLMとツールをあらかじめ決めたコード経路に配置する方式で、エージェントはモデル自身が次の行動とツール使用を決める方式です。そして、最も単純な解法から始め、必要なときだけ複雑さを上げよと勧めています。単一の呼び出しに検索と例を付けるだけで十分な問題が、実際には多いのです。

この区分をハーネスの観点から読み直すとこうなります。ワークフローでもツール表面、失敗の返し方、権限、評価者は全部必要です。エージェントに寄るほどループの主導権がモデルへ移るので、再試行上限、停止条件、コンテキストポリシーの比重が急に大きくなります。どちらであっても、あなたがデプロイしているのはハーネスであり、何をデプロイしたか言えるようになって初めて管理が始まります。

つまみは別々には回りません

6つのつまみをコードに書くと、この連載の目次になります。

harness = {
    "tools": ["read_file", "write_file", "run_tests"],      # 第3回: ツール表面
    "on_error": "cause_plus_alternatives",                  # 第3回: 失敗をどう返すか
    "loop": {"max_retries": 3, "stop": "goal_check"},       # 第4回: ループと停止条件
    "context": {"policy": "playbook", "budget": 12000},     # 第2回: コンテキスト予算
    "permissions": {"write": ["src/"], "deny": ["eval/"]},  # 第6回: リワードハッキングと権限
    "evaluator": "rubric_v3",                               # 第5回: 評価者のボトルネック
}

注意すべきは、つまみ同士が絡み合っていることです。再試行上限を上げる決定は失敗の返し方と絡んでいます。原因のない再試行は、同じ失敗をより高いコストで繰り返すだけです。ツールを増やす決定はコンテキスト予算と絡んでいます。ツールのスキーマもトークンを食うからです。そしてすべてのつまみは評価者と絡んでいます。どの組み合わせが良いかを判定するのが評価者であり、評価者が弱ければ比較そのものが成立しません。だからこの連載はつまみをひとつずつ扱いながら、いつも同じ問いに戻ります。この変更が良くなったと、何をもって知るのか。

実際に練習する

このブログには、ハーネスエンジニアリングをゲームで練習するハーネスエンジニアリングRPGがあります。いま見た6つのつまみを自分で組み立てて27のシナリオを攻略する構成で、ティア1「観測と指紋」がこの記事の内容に当たります。プロンプト側の基礎を固めたいならプロンプトエンジニアリング練習ツールもあります。

参考資料

  • Harness engineering for self-improvement — Lilian Weng, 2026-07-04 — ハーネスの定義と構成要素、ハーネスエンジニアリングが直面する難問の一覧がこの記事にあります。
  • Building effective agents — Anthropic, 2024-12-19 — ワークフローとエージェントの区分、単純な解法から始めよという勧め、ツール定義をインターフェースとして扱う観点がこの記事にあります。
  • 冒頭の2チームの事例と本文のハーネスのコードは、実測ではなく説明のために構成した例です。

현재 단락 (1/32)

2つのチームが同じ基盤モデルで同じ種類の課題を自動化するとします。一方のチームのエージェントはイシューを受け取ってテストが通るパッチを作り上げ、もう一方のエージェントは似たイシューでファイルを漁ったま...

작성 글자: 0자원문 글자: 3,494자작성 단락: 0/32