HARNESS ENGINEERING / CONCEPT
ハーネスエンジニアリング
— 概念と、ジェネレーター／エバリュエーターの作り方
AIの出力品質はモデルの賢さではなく環境設計で決まる。
長時間タスクでエージェントが壊れる2つの原因と、その中核的解決策である「作る側と採点する側の分離」を整理する。
出典 Anthropic Engineering 2026/3 ＋ 2025/11
軽量版（HTML図解化スキル・1パス生成）
2026-07-30
CORE NUMBERS — 単体エージェント vs フルハーネス（同一プロンプト・1文）
20分 / $9
単体。速いが中核機能が動かない。自己評価は「いい出来です」
6時間 / $200
フルハーネス。実際に遊べるものが完成
5-15回
生成→評価の反復。品質のジャンプは後半に来る
SECTION 01
問題 — 素朴な使い方が壊れる2つの原因
「賢いモデルに丁寧なプロンプトを渡す」だけでは長時間・複雑タスクで必ず壊れる。壊れ方は2種類あり、それぞれ別の対処を要する。
Aはモデル世代で解消されつつある（Opus 4.5でほぼ消えた）が、Bは構造的な問題でモデルが賢くなっても消えない。
SECTION 02
解決 — ジェネレーターとエバリュエーターを分離する
機械学習のGAN（敵対的生成ネットワーク）に着想を得て、作る側と採点する側を別エージェントにする。ただし「別のAIなら客観的」という単純な話ではない。
生成器も評価器も、LLMである以上どちらも本質的に「甘い」。しかし、独立した評価器を懐疑的にチューニングすることは、生成器に自作を批判させることよりも、はるかに扱いやすい。
Anthropic Engineering / Harness Design for Long-Running Application Development（要旨）
観点 1
文脈の違い
自己評価する生成器のコンテキストには「なぜこう作ったか」の正当化の連鎖が全部入っている。独立した評価器は作った過程を一切見ていない。あるのは成果物だけ。
観点 2
役割の純粋さ
同一プロンプトに「完成させる」と「粗を探す」を同居させると衝突する。評価器は「粗を探す」だけなので、役割プロンプトが純粋になる。サンクコストも知らない。
観点 3
権限の剥離
直せる立場だと「直しながら甘く判断」できてしまう。書き込みツールを外せば判断しかできない。プロンプトのお願いではなく構造で縛れる。
逆向きの検証① 「厳しく自己評価せよ」
厳しい言葉で書かれた甘い評価が返る。文体が変わるだけ。
逆向きの検証② 「必ず3つ欠点を挙げよ」
些末な欠点3つを挙げて中核の破綻を見逃す。数を満たすことが目的化する。
逆向きの検証③ 「テストで検証せよ」
通るテストを書く。テストが仕様ではなく実装に寄る。
いずれも「完成させたい」という主目的が採点を汚染している。だから主目的を持たない別人格を立てる。
SECTION 03
作り方 — エバリュエーターを成立させる4つの構造
プロンプトの文言よりこの構造が効く。ハーネスエンジニアリングの思想は「お願いではなく構造で縛る」ことにある。
構造 01
まっさらな文脈
生成を見ていないコンテキストから採点する。サブエージェントか別プロセスで実現。同一セッションで役を切り替えるのは無意味。
構造 02
書き込み権限なし
公式実装は tools: Read, Glob, Grep, Bash のみ。採点インフレと役割混濁を防ぐ。
構造 03
証拠主義
Plausibility is not correctness.
ファイル名ではなく実際に写っているものを見る。「たぶん動く」と仮定したことに気づいたら止まる。
構造 04
デフォルトFAIL
全基準を false から始める。証拠を読むまで結果ファイルへの書き込みをhookで拒否する。
主観的品質を採点可能にする4軸ルーブリック
| 軸 | 問い | 重み |
|---|
| 質 | 部品の寄せ集めではなく、一体感のある全体になっているか | 高（苦手な軸） |
| 独自性 | テンプレやデフォルトを超えたカスタムな判断の証拠があるか。AI生成の兆候にペナルティ | 高（苦手な軸） |
| 丁寧さ | タイポの階層、余白の一貫性、色の調和、コントラスト比 | 低（既に得意） |
| 機能性 | 目的が理解でき、主要アクションを見つけられ、タスクを完了できるか | 低（既に得意） |
原則① 重みは「モデルが苦手な軸」に置く
Claudeは丁寧さと機能性がデフォルトで得意。放っておいてもできることに配点しても品質は上がらない。
原則② モデルの初期値そのものを減点対象にする
LLMは平均に回帰する。平均そのものを罰しないと平均から離れない。「AIっぽい紫グラデーション」を明記して減点する。
原則③ ハードしきい値を置く
平均点で誤魔化させない。1軸でも閾値未達ならスプリント全体を不合格にする。「見た目は良いが動かない」を通さない。
SECTION 04
活用 — 3エージェント構成とスプリント契約
プランナーを足したフルスタック開発向け構成。着手前に「完了とは何か」を合意するスプリント契約が、見落とされがちだが効果が大きい。
SECTION 05
実験結果 — コストはどこに消えるのか
同一プロンプトでの比較と、簡素化後の構成での実測コスト内訳。削るべき部品と削ってはいけない部品がはっきり分かれる。
| 実験1：レトロゲームメーカー |
|---|
| 単体 | フルハーネス |
| 所要時間 | 20分 | 6時間 |
| コスト | $9 | $200 |
| 機能数 | 素朴 | 16機能 |
| 中核機能 | 動かない | 動く（遊べる） |
| 失敗の可視性 | 表示なし・自覚なし | 未達が明示される |
| 自己評価 | 「いい出来です」 | 評価者が未達を検出し続けた |
| 実験2：ブラウザDAW（Opus 4.6世代） |
|---|
| プランナー | 4.7分 | $0.46 |
| ビルド R1 | 2時間7分 | $71.08 |
| QA R1 | 8.8分 | $3.24 |
| ビルド R2 | 1時間2分 | $36.89 |
| QA R2 | 6.8分 | $3.09 |
| ビルド R3 | 10.9分 | $5.88 |
| QA R3 | 9.6分 | $4.06 |
| 合計 | 3時間50分 | $124.70 |
エバリュエーターを削るのはコスト削減としてほぼ意味がない。削るならジェネレーター側の反復回数。
QA 3ラウンド合計 $10.39（総額の8.3%）が、ビルド $113.85 の品質を保証している。ビルド時間は127分→62分→11分と収束
SECTION 06
意思決定 — ハーネスを組むべきか
部品は「モデルが自力ではできないこと」への仮説である。だから常に必要でも、もう不要でもない。
| 判断軸 | ハーネスを組む | 単体で済ませる |
|---|
| 成果物の性質 | 納品物・保存物。他人が見る | 壁打ち・調べ物・使い捨て |
| 検証可能性 | 主観的でテストが書けない（デザイン・文章） | テストで自動判定できる |
| タスク難易度 | モデル能力の境界付近にある | 境界の内側で余裕がある |
| 失敗コスト | 壊れたまま出ると困る | 間違っていてもすぐ気づける |
| 許容レイテンシ | 数十分待てる | その場で欲しい |
境界は移動する
Sonnet 4.5では境界が近く、多くのタスクで評価者が必要だった。Opus 4.6では素の能力が上がり境界が外側へ移動。以前は検査が必要だったタスクが単独で足りるようになった。
Anthropicが削った部品
- コンテキストリセット（Opus 4.5で不安が消えた）
- スプリント分割（Opus 4.6が長く持続できる）
- スプリント毎の評価 → 単一パスへ
空間は縮まず移動する
面白いハーネスの組み合わせの空間は、モデルが良くなっても縮まらない。移動するだけ。次の組み合わせを探し続けるのがAIエンジニアの仕事。
ハーネスのあらゆる構成要素は、「モデルが自力ではできないこと」についての仮説を符号化している。それらの仮説はストレステストする価値がある。間違っているかもしれないし、すぐに陳腐化しうるからだ。
NEXT ACTION
最小の始め方 — 段階1だけで効果の大半が出る
hookや自動ループは後回しでよい。逆に段階1を飛ばすと効果が実感できない。
STEP 01
評価者を1体だけ立てる
.claude/agents/evaluator.md を置き、Write/Editを外して1行目にPASS/NEEDS_WORKを出させる。ここだけで効果の大半が出る。
STEP 02
ルーブリックとしきい値
4軸に分解し、モデルが苦手な軸に重みを寄せる。1軸でも未達なら不合格にする。
STEP 03
一次情報を証拠にする
生成側の要約ではなく、原文・実データ・実表示を見に行かせる。ここが無いと机上採点になる。