Claude Code 条件評価の仕組み深掘り — Haiku評価器とプロンプト型 vs スクリプト型

/goal の心臓部は Haiku評価器 だ。毎ターン後に会話ログを読み、完了条件と照合して「達成 / 未達成」を判定する。

この記事では評価器の判定フローと、プロンプト型 vs スクリプト型のトレードオフを掘る。

Haiku評価器とは

Haiku評価器とは、Claude Codeの/goalに内蔵された軽量判定モデルだ。 Anthropic社のClaude Haikuをベースに、完了条件の充足判定タスクに特化している。

なぜHaikuか

観点	Haiku	Sonnet	Opus
入力単価	$0.25/M	$3.00/M	$15.00/M
出力単価	$1.25/M	$15.00/M	$75.00/M
速度（rel）	1.0	0.4	0.2
判定精度（評価タスク）	92-95%	95-97%	96-98%

Sonnetの1/12のコスト、Opusの1/60のコストで、判定精度は実用十分。これが採用理由だ。

評価フロー（判定の中身）

評価器が1ターン後に走る流れ：

1. メインターン終了
   ↓
2. 評価器が会話ログを取得（過去Nターン分）
   ↓
3. 完了条件文を読み込み
   ↓
4. ログ内に「条件達成の証拠」が存在するか判定
   ├─ あり → 「達成」を返す → /goal 停止
   └─ なし → 「未達成」+ 理由 → 次のターンへ
   ↓
5. 判定理由はトランスクリプトと status view に記録

評価器は 「次に何をすべきか」は考えない。あくまで「終わったか / 終わっていないか」の判定に専念する。

プロンプト型 vs スクリプト型

完了条件の評価方式には2系統ある。

プロンプト型（/goalの標準）

/goal リファクタリングが完了し、コードがCLAUDE.mdの規約に従っている

• 判定主体: Haiku評価器（LLM）
• 強み: 柔軟、自然言語で書ける、複雑な意味判定可能
• 弱み: 確定的でない、誤判定リスクあり

スクリプト型（Stop Hooks経由）

~/.claude/settings.json：

{
  "hooks": {
    "stopOn": {
      "script": "/Users/me/scripts/check-done.sh"
    }
  }
}

scripts/check-done.sh：

#!/bin/bash
cd /path/to/project
[ -f .done.flag ] && exit 0 || exit 1

• 判定主体: シェルスクリプト
• 強み: 100%確定的、コスト0、ログ不要
• 弱み: 自然言語で書けない、複雑な判定は不可

どっちを使うべきか — 早見表

完了条件のタイプ	推奨タイプ	理由
テスト全件通過	スクリプト型	npm test の exit code で確定判定
coverage>=80%	スクリプト型	coverage.json の数値判定
lint エラー0件	スクリプト型	linter のexit code
ファイル存在確認	スクリプト型	[ -f file ]
「ドキュメントが分かりやすい」	プロンプト型	主観評価が必要
「リファクタが規約に従う」	プロンプト型	規約解釈が必要
「セキュリティ的に安全」	プロンプト型	文脈判断が必要
「文章のトーンが統一」	プロンプト型	意味的判断

一般的なソフトウェア開発タスクの8割はスクリプト型で確定的に判定可能。 残り2割（コンテンツ品質、設計判断）はプロンプト型が必要になる。

ハイブリッド戦略

実務では 両方を併用 することが多い。

/goal リファクタが完了し、CLAUDE.mdの規約に従っている状態

done when:
- test/auth/ 全件通過（npm test exit 0）   ← スクリプト型相当
- coverage.json の total>=80               ← スクリプト型相当
- CLAUDE.md の規約と矛盾していない          ← プロンプト型相当
- progress.md に判断理由が3行以上記録      ← プロンプト型相当

確定的な条件はログから機械的に検証され、柔軟な条件はHaikuが意味判定する。両者の強みを活かす設計。

評価器がHallucinationする典型パターン

「達成」と誤判定される典型例を知っておく。

パターン	例	防止策
ログに「達成っぽい文字列」混入	プロンプト内に「完了したように見える」と書いた	完了条件を具体的な観測値に
過去の達成ログを誤読	別タスクの「テスト通過」ログがある	scope を明示（「今ターンの」）
部分達成を全体達成と誤読	5/10 件通過を「テスト通過」と判定	「全件通過」「100%」「すべて」と明示
同義語で混乱	「lint」と「linter」「リンター」の表記揺れ	完了条件と本文で表記を統一

「裁判の証拠のように厳密に書く」がこれを防ぐ最強のアプローチだ。

完了条件が評価可能か自己診断（4ステップ）

書いた完了条件をHaiku評価器が判定できるか、4つの問いで自己診断する。

Step 1: ログから検証可能か

会話ログ、ファイル、コマンドの出力から条件達成の証拠を取得できるか？「いい感じ」「きれい」のような主観表現は不可。

Step 2: 30秒で証拠を確認できるか

条件達成の証拠を人間が30秒で確認できるか？できなければ評価器も判定困難。コマンド1つで確認できる形が理想。

Step 3: 数値または真偽値で表現可能か

exit code 0/非0、coverage>=80、ファイル存在の有無等、二値または閾値で判定できるか？

Step 4: サンプル証拠を書き出せるか

「条件達成時に会話ログに現れるであろう具体的な1行」をあなた自身が書けるか？書ければ評価器も検出できる。

4つすべてYesになる条件文は、評価器が高精度で判定できる。

よくある質問

Haikuはなぜ評価器に選ばれていますか？

速度・コスト・判定精度のバランスが最適だからだ。Sonnetより約12倍安く、レスポンスも数倍速い。「会話ログを読んで条件と照合する」タスクは複雑な推論を必要としないため、Haikuで十分な精度が出る。

プロンプト型とスクリプト型のどちらを使うべきですか？

確定的な判定（exit code、ファイル存在、数値閾値）はスクリプト型。柔軟な判定（文章の意味的近さ、複雑な状況判断）はプロンプト型。一般的なテスト / lint / 型エラー系はスクリプト型が安定し、コンテンツ品質チェック系はプロンプト型が柔軟だ。

評価器のトークン消費を確認するには？

/goal 実行中に /goal コマンドを単独で打つと、累積ターン数・累積トークン・評価器の最後の判定理由が表示される。判定理由はトランスクリプトの中にも保存される。

カスタム評価ロジックは書けますか？

Stop Hooks（settings.json）でスクリプト型の評価ロジックを書ける。/goal の内部評価器を完全に置き換えることはできないが、追加の停止条件として併用可能だ。

評価器が Hallucination を起こすことはありますか？

完了条件が曖昧な場合に起こり得る。「ログに『完了』っぽい文字列が混入」「複数解釈可能な条件」等で誤判定が報告されている。複数の独立証拠を要求することで誤判定率は大幅に下がる。

関連記事

• Claude Code /goal 完全ガイド — シリーズPillar
• Claude Code /goal 完了条件の書き方 — 5つのベストプラクティス — 条件設計の基礎
• Claude Code /goal トラブルシューティング — 誤判定対処

参照

• Claude Code 公式ドキュメント — /goal
• Anthropic Pricing — Haiku/Sonnet/Opus