Claude Code /goal 完了条件の書き方 — 5つのベストプラクティス【Haiku評価器対応】
/goal のアウトプットの質は、ほぼ完了条件の書き方で決まる。Haiku評価器は会話ログだけを読んで判定するため、「ログを見れば30秒で確認できる」レベルの具体性が必要だ。
5つのベストプラクティスを順に解説する。
完了条件とは
完了条件とは、Haiku評価器が「達成された」と判定するために必要な観測可能な証拠を1文で記述したものだ。
/goal の各ターン後、評価器は会話ログを読んでこの条件と照合する。条件が曖昧だと2種類の失敗で終わる：
- Claudeが「何をもって完了か」を判断できずに同じ作業を繰り返す
- 評価器が証拠のないまま「完了した」と誤判定する
どちらもトークンの無駄遣いで、作業は進まない。
1. 観測可能な動詞を使う
「きれいにする」「整える」「いい感じにする」のような主観的動詞は評価不能だ。ログに痕跡が残る動作動詞を選ぶ。
| ❌ 評価不能 | ✅ 観測可能 |
|---|---|
| コードをきれいにする | lint エラーが0件になる |
| テストを整える | npm test が exit 0 で完了する |
| ドキュメントを更新する | CHANGELOG.md に該当エントリが追加される |
| パフォーマンスを改善する | Lighthouse スコアが90以上になる |
2. ログから検証できる証拠を要求
評価器は「会話ログの中の証拠」を頼りに判定する。ファイルやログから30秒で確認できる証拠を条件に含める。
# ✅ ログに証拠が残る
/goal coverage.json に total>=80 が記録される
/goal git log --oneline でCHANGELOG関連コミットが確認できる
/goal docs/api.md に POST /users の説明が存在する
# ❌ 証拠が曖昧
/goal カバレッジを改善する
/goal 変更履歴を追加する
/goal API仕様を書く
裁判の証拠のように考えると判断が楽だ。「この条件が満たされた証拠が、会話ログのどこに、どんな形で存在するか」を一文で書ければ良い条件である。
3. 否定形を「do not」ブロックに分離する
完了条件に否定形（〜しない、〜避ける）を混ぜると評価器が混乱する。肯定形だけを done when に置き、否定形は do not ブロックに分離する。
/goal test/auth のテストがすべて通る
context:
src/auth/ 配下の認証モジュールをリファクタリング中
done when:
- test/auth/ 全テストが exit 0 で完了
- coverage が80%以上
do not:
- migrations/ フォルダは触らない
- 既存のAPIエンドポイントの引数を変更しない
- node_modules を変更しない
評価器は done when の条件だけを判定し、do not は Claude本体への指示として効く。
4. progress.md 進捗追跡を必ず指示
長時間の実行では、Claudeが前のターンで何を決定したかを忘れ始め、矛盾した行動を取ることがある。 1時間を超えるタスクでは特に顕著だ。
progress tracking:
completed steps を progress.md に随時記録すること
各ステップに完了時刻・採用した判断・残課題を3行で書く
これを完了条件に組み込むと、progress.md が 外部メモリとして機能し、実行全体の一貫性が保たれる。
さらに複数時間かかる作業では plan.md（開始前の方針）と decisions.md（なぜその選択をしたか）を追加すると安定する。
5. タイムアウト・上限を併記する
「条件が満たされなくても止まる」安全装置を必ず付ける。
# Nターン上限
/goal test/auth が全件通過する状態, or stop after 10 turns
# 時間上限
/goal リファクタリング完了, or stop after 30 minutes
# 両方
/goal coverage>=80, or stop after 15 turns or 20 minutes
ターン上限なしの /goal は理論上無限ループに陥り得る。Haiku評価器のトークン消費は1ターンあたり数百円分のごく一部だが、暴走させればすぐ100倍規模になる。
📘 コスト爆発の回避戦略は 自律実行のループ＆コスト爆発を回避する戦略 を参照。
5つを統合した完全形プロンプト
実務で使う完全形を載せておく。コピペして条件部分だけ書き換えれば即使える。
/goal [達成したいゴール、1文、観測可能な動詞]
context:
[プロジェクトの構成・使用技術・今回の作業背景]
done when:
- [測定可能な完了条件1（ログから検証可能）]
- [測定可能な完了条件2]
do not:
- [触らないファイル・避けるべきアプローチ]
progress tracking:
completed steps を progress.md に随時記録すること
最大10ターンまで、または30分以内に達成すること
よくある質問
完了条件は何文字以内が適切ですか？
公式仕様では条件は最大4,000文字。実務的には1-3文・合計200字以内が読みやすく、長すぎると評価器が要点を見失う。複雑なタスクは Kanau Tech 推奨の4ブロック構造（context / done when / do not / progress tracking）でテンプレ化すると安定する。
「テストが全部通る」は良い完了条件ですか？
不十分だ。「test/auth のテストがすべて通り、npm test が exit 0 で完了する」のように、対象スコープと検証コマンドを明示すべきだ。評価器はログの中に exit code 0 を確認できれば100%確信して停止できる。
否定形（〜しない）はどう書くべきですか？
完了条件には書かず、do not ブロックに分離する。例：done when:「テスト全件通過」、do not:「migrations/フォルダは触らない」。これで評価器は「何が達成されたか」だけを判定すればよくなる。
評価器が誤判定したらどうしますか？
完了条件にもう1つ「証拠」を追加する。例：「テスト通過 + coverage.json の totalが80以上」。複数の独立した証拠を要求することで誤判定率は劇的に下がる。
複数条件を and/or で結合できますか？
可能だ。done when ブロックに箇条書きで並べると and として扱われる。or が必要な場合は「Aが達成、または Bが達成」と明示的に書く。ただし条件は単一の方が安定するため、可能なら or は避けてほしい。
関連記事
- Claude Code /goal 完全ガイド — シリーズPillar
- Claude Code 条件評価の仕組み深掘り — Haiku評価器・プロンプト vs スクリプト — 評価器の内部動作
- 自律実行のループ＆コスト爆発を回避する戦略 — リスク管理