AIのハーネスでは防げなかった誤り。直したのは、仕様の1文だった

AIエージェントに「終わった」と言わせない仕組み（ハーネス）を厚くすれば、誤りは減るのか。経費申請のチェックを題材に、ハーネスあり・なしで比べました。

結論から書くと、ハーネスでは直らない誤りが 1 つ残り、それは仕様に 1 文を足すだけで消えました。その 1 文は、エンジニアではなく、業務を知る側が決めることでした。

要点

• ルール 8 個のやさしい課題は、ハーネスなしでも全件合格した。ハーネスは、時間と費用が約 2 倍かかっただけだった
• ルール 18 個にしたら、誤りは「空白だけの文字列を、空とみなすか」の 1 か所に集まった。ハーネスありでも、同じ誤りで「完了」と報告した
• 仕様に「空白だけも空とみなす」と 1 文足したら、20 回の試行すべてが全件合格した

検証用の小さなサンプルでの結果です。課題は 1 種類、試行は各条件 5〜10 回で、一般化はできません。条件と限界は、後ろに書きます。

ハーネスとは

この記事では、AIモデルの外側にある、動かす仕組みの全体を指します。どの道具を使わせるか、終わったかをどう判定するか、前回の続きをどう引き継ぐか、などです。

Anthropic の記事には、こう書かれています。

every component in a harness encodes an assumption about what the model can't do on its own

訳すと「ハーネスのどの部品も、モデルが単独ではできないことについての仮定を符号化している」です。

元記事の対策

長時間動くエージェントのハーネス（2025-11-26）は、Claude で観察した失敗を 4 つ挙げています。

失敗（原文の表）	何が起きるか
早すぎる完了宣言	プロジェクト全体を、まだ終わっていないのに「終わった」と判断する
散らかった環境	バグや、記録されていない進捗を残したまま、回を終える
機能の早すぎる完了マーク	確かめきれていない機能を、できたことにする
動かし方の調査	アプリの動かし方を調べるのに、時間を使う

対策は、機能リスト（200 を超える機能を、すべて "passes": false で始める）、1 回に 1 機能、実装前の通し確認、Git と進捗ファイル、そして「テストを消したり書き換えたりするのは許容できない」というルールです。

試した条件

課題： 経費申請をチェックする関数 check_expense(expense, history) を実装させる。結果は ok、approval（上長承認）、hold（保留）、reject（差し戻し）のどれか。複数のルールに当てはまるときは、reject > hold > approval > ok の順で強いものを返す。実在の業務ではなく、この検証のために作った仕様です。

仕様の例：

R5: category が "entertainment" のとき、attendees が 1 以上の整数で、purpose が空でない文字列でなければ、差し戻す

採点： エージェントに見せない隠しテスト（第 1 回は 30 件、第 2・3 回は 68 件）で採点します。正解の実装で全件合格することと、境界や優先順位をわざと壊した実装でテストが落ちることを、先に確かめました。

条件：

条件	渡すもの
A	仕様書だけ。実装して、1 行目に「完了」か「未完了」を書かせる
B	A に加えて、機能リスト（passes: false で始める）。機能ごとにテストを書いて実行し、通ったものだけ true にする。進捗ファイルを書く。テストを消さない。全部 true になるまで「完了」と書かない

実行： Claude Code 2.1.311 のコマンドライン（claude -p）を、モデル haiku と sonnet（claude-haiku-5-5、claude-sonnet-5-5）で動かしました。「誤った完了」は、「完了」と報告したのに、隠しテストに落ちたものを数えます。

結果

第 1 回：ルール 8 個

モデル	条件	全件合格	誤った完了	時間（中央値）	費用（平均）
haiku	A	10/10	0	21秒	$0.008
haiku	B	10/10	0	50秒	$0.019
sonnet	A	5/5	0	27秒	$0.121
sonnet	B	5/5	0	51秒	$0.196

やさしすぎて、差が出ませんでした。条件 B は、時間も費用も約 2 倍です。

第 2 回：ルール 18 個

モデル	条件	全件合格	誤った完了
haiku	A	6/8	2
haiku	B	7/8	1
sonnet	A	0/5	5
sonnet	B	1/5	4

不合格は、すべて同じ 1 件でした。「接待で目的が空白だけ（" "）のとき、差し戻す」というテストです。

ここで、私のミスに気づきました。仕様は「空でない文字列」としか書いておらず、空白だけが「空」に当たるかを決めていませんでした。テストが、仕様より厳しかったのです。

第 3 回：ルール 18 個＋仕様に 1 文

仕様に、次の 1 文を足しました。

文字列の項目で「空」と言うときは、空文字のほか、空白だけの文字列も含める。

モデル	条件	全件合格	誤った完了
haiku	A	5/5	0
haiku	B	5/5	0
sonnet	A	5/5	0
sonnet	B	5/5	0

20 回すべてが全件合格でした。

読み取れること

1. ハーネスは、曖昧な仕様の誤りを防げなかった。
第 2 回の条件 B で不合格だった 5 回（sonnet 4 回、haiku 1 回）は、いずれも、エージェントが自分でテストを書いて実行し、R5 を「通った」と記録していました。誤った完了マークです。

その 5 回のテストを確かめると、空文字（""）と None は試していて、空白だけの目的を試している行は 0 件でした。エージェントは、自分の解釈の中でテストを書き、その中で通っていました。

2. 直したのは、仕様の 1 文だった。
「何を空とみなすか」は、実装の細部のようで、業務の決めごとです。ここを決めるのは、業務を知る側です。

3. 課題がやさしければ、ハーネスは費用になるだけ。
第 1 回の条件 B は、時間が約 1.8〜2.4 倍、費用が約 1.6〜2.4 倍でした。元記事も、評価役を動かすのは「課題が今のモデルが単独で確実にできる範囲を超えるとき」に、費用に見合うと書いています。

限界

• 課題は 1 種類で、試行は各条件 5〜10 回です。第 2 回の A と B の差（haiku 6/8 対 7/8、sonnet 0/5 対 1/5）は、偶然の範囲かもしれません。「ハーネスで直らなかった」とは言えても、「ハーネスに効果がない」とは言えません
• 第 1 回と第 2 回で、同じ「空白だけ」のテストがあるのに、第 1 回は全件合格でした。保存してある全実装を実際に動かして数えると、空白だけの目的を差し戻したのは、第 1 回が 30 件中 30 件、第 2 回が 26 件中 14 件、第 3 回が 20 件中 20 件です。第 2 回で目的を使うルール（贈答）が増えたので、補助関数に切り出したせいかと考え、コードを検索して調べました。しかし、第 1 回でも、目的を補助関数に渡していた実装が 12 件あり、すべて差し戻していました。理由は、説明がつきませんでした
• 実行は、許可したツールだけで動かしました。第 1 回の sonnet・条件 A の 2 回は、「未完了」と報告しました。1 回は Python の実行が許可されず確認できなかったため、もう 1 回は一部しか確認できなかったためです。どちらも、コードは隠しテストに全件合格しました
• テストの作者は私です。曖昧さを作ったのも私で、これを見つけたのも、結果を見てからでした

ビジネスが決めることと、エンジニアが作ること

この表は、Anthropic の記事に書かれた分担ではなく、私の整理です。

部品	ビジネスが決めること	エンジニアが作ること
完了の定義	何ができたら「完了」か。曖昧な言葉の意味（今回は「空」）	機能リストと、自動で動くテスト
採点の基準	良い出来と悪い出来の違い、その実例	評価する役の実装と、基準による調整
記録と引き継ぎ	後から確認できるように、何を残すか	進捗ログの形式と、履歴の保存
守らせるルール	変えてはいけないものは何か	変更を止める仕組み
コスト	品質にいくらまで払うか	部品の厚さの調整

2 本目の記事（アプリ開発向けのハーネス設計、2026-03-24）は、作る役と評価する役を分けています。ただし、分けただけでは甘さは消えず、評価役も LLM で、LLM が作ったものに寛容になりやすいと書いています。そこで元記事の筆者は、採点の内訳をつけた具体例を見せて、評価役を調整しました。

今回の結果も同じ向きです。エージェントが書くテストの基準は、エージェントの解釈です。基準と具体例は、人が出す必要があります。

同じ記事には、構成ごとの時間と費用もあります。ゲーム制作を同じプロンプトで動かすと、単独実行は 20 分・$9 で、操作に反応せず壊れていました。フルハーネスは 6 時間・$200 で、操作して遊べました。ハーネスの厚さは、品質に払う費用です。

今日からできること

1. 任せたい仕事を 1 つ選び、「完了」の条件を 3 つ、業務の言葉で 書く
2. 条件に出てくる 曖昧な言葉（空、重複、期限内、など）を 1 つずつ拾い、境界の例 を書く
3. その条件と例を、エンジニアと一緒に 自動で確かめられる形 にする
4. 「何を残すか」を決める。後から人が見て、判断を追えるようにする

出典

• Anthropic Engineering、Effective harnesses for long-running agents（2025-11-26）
• Anthropic Engineering、Harness design for long-running application development（2026-03-24）