ハーネスは「盛る」より、モデルが知り得ない情報だけ足す
リトライ指示・完了ゲート・Skill・別エージェント点検などのベストプラクティスを全部入れても品質は上がらずコストが増える。効いたのは「どれが正しい資料か」「前のセッションの取り決め」といった、モデルが自力で知り得ない情報を渡すものだけだった。
電通総研の検証(Opus 4.8 と Haiku 4.5、隠しテストで採点、各3〜5回)で、ハーネスを6成分に分けて有無を比べた結果。
検証で分かったこと
- 効いた: 状態の引き継ぎ(取り決めを
state.jsonに残して新セッションで読み戻す)と、文脈管理(新旧の仕様書が混在する中で「こちらが現行」と教える)。Opus でも効果は変わらず、文脈管理はむしろ Opus の方が大きく改善 - 差が出なかった: 一時失敗のリトライ指示、完了前の型チェックゲート、反復作業用 Skill。今のエージェントは言われなくても再実行や型チェックをする。足した分ターンとコストだけ増えることもあった
- 弱いモデルにだけ効いた: 別エージェントによる点検。Haiku の取りこぼしは拾えたが、Opus は最初からほぼ満点で空振り
- 全部盛り: 品質は変わらず、ターン数とコストだけ増えた
どう使うか
- まず素の構成でタスクを解かせる
- 失敗した原因が「情報の欠落」(正本がどれか、過去の決定、社内ルールなど)なら、その情報だけを渡す仕組みを足す
- 点検役やゲートは、弱いモデルを使うときや実際に取りこぼしが出たときに足す
- モデルを替えたら、足した仕組みを引き算できないか見直す(関連: 新モデルに乗り換えたら「公式プロンプトガイド」を読み、指示を削る)
注意点
- 小規模な TypeScript の課題での検証。長時間・大規模タスクでは結果が変わりうる
- 「Haiku でも十分賢い」という所感も添えられている。小さな修正は下位モデルに任せて試す価値がある
出典
- @moneymog 2026-10-12(紹介): @moneymog · 2026-10-12
- 元記事: 電通総研テックブログ「ハーネスエンジニアリングとは何か——"盛れば効く"のかを確かめる」 tech.dentsusoken.com