Goal — Claude を条件達成まで自走させる
検証可能な完了条件を設定し、Claude が達成までターンを重ねて走り、毎回続行を促さなくて済むようにする
⏱ 想定 ~6 分
01 · 読む
大きなタスクをこなすとき、「続けて」「次を直して」「テストを走らせて」「もう一度試して」と連呼することがよくあります — Claude は 1 ターンで 1 つしかやらず、あなたの催促を待って止まるからです。
/goal を使うと検証可能な完了条件を設定でき、Claude が達成までターンを重ねて自走します。たとえば「test/auth のテストがすべてパスし、lint もクリーン」と設定して Enter を押し、コーヒーを飲みに行きましょう。戻ってきたとき、条件が達成されて自動終了しているか、Claude が行き詰まってあなたの判断を待っているか、どちらかです。
💡 想像してみてくださいエンジニアにチケットと受け入れ条件を渡すようなものです 「この PR をグリーンにしたら完了」。彼は反復し、修正し、テストを走らせ、また修正し、また走らせ、ステップごとにあなたに確認しません。あなたは、彼が完全に行き詰まったときか完了したときだけ登場します。
ポイントまとめ
- /goal <条件> で完了条件を設定し、すぐに最初のターンを開始する
- Claude が 1 ターン走る → 達成したか評価 → 達成していなければさらにターンを走らせる
- 達成すれば自動終了。未達でも /goal clear で手動停止できる
- 「明確な受け入れ基準」のあるタスクに適している (テストパス、ファイル存在、queue が空)
02 · 読む
内部の仕組み : 各ターンの終わりに、独立した小型モデル (通常は Haiku) が会話の transcript を読み、条件が達成されたかを判断します。そのモデルは自分でコマンドを走らせたりファイルを読んだりできません — Claude が会話の中で「見せた」ものしか見られません。
つまり、あなたの条件は Claude が会話の中で「示せる」ものでなければなりません : - ✅ 「npm test の exit code が 0」(Claude がテストを走らせ、出力が表示される) - ✅ 「git status がクリーン」(Claude が git status を走らせ、出力が表示される) - ❌ 「コード品質が良い」(検証できない、評価器が理解できない) - ❌ 「バグがない」(会話の中で証明できない)
もう 1 つのポイントは、「実行モデル」と「評価モデル」が分かれていること — 作業する Claude が自分で完了を宣言してあなたを騙すことはできず、Haiku が独立して判断します。
ポイントまとめ
- 評価器 (Haiku) と作業モデルが分離して判断する
- 評価器はコマンドを走らせたりファイルを読んだりできない — 会話内容しか見られない
- 条件は Claude が会話の中で「見せられる」証拠であること
- 上限 4000 文字、「あるいは N ターン後に停止」を保険として加えられる
03 · コード例
3 つのコアコマンド : 設定、進捗確認、クリア。
Claude Code セッション内で
# 設定 goal — 立刻開始第一輪
/goal all tests in test/auth pass and lint is clean
# 看當前進度 (條件、跑了幾輪、花了多少 token、評估器最新理由)
/goal
# 手動清除 (條件達成會自動清，不需要這步)
/goal clear
# 別名： stop, off, reset, none, cancel
# /clear 開新對話也會清掉
ヘッドレス / 一気に走らせる
# 非互動模式，跑到完成才回 shell
claude -p "/goal CHANGELOG.md 有這週每個 PR 的條目"
# Ctrl+C 中斷
Goal がアクティブな間、プロンプトの横に ◎ /goal active と経過時間が表示されます。ヘッドレスモード (-p) は CI やスケジュールにとても向いていて、たとえば毎日「changelog エントリを生成する」を完了まで走らせるのに使えます。
04 · コード例
良い条件と悪い条件の書き方では大きく違います — 実例で見てみましょう :
❌ 悪い条件 (評価器が検証できない)
/goal 把 auth.js 拆得更好
/goal 修 login bug
/goal 確保程式碼品質夠
/goal 完成所有 TODO
✅ 良い条件 (明確な受け入れ基準 + 時間制限の保険)
/goal 把 auth.js 拆成多個 module、每個 <300 行、所有測試通過、或 20 輪後停
/goal 修登入特殊字元 bug，跑 `npm test test/auth` 全綠、或 15 輪後停
/goal 把所有 import 從 old-api 換成 new-api、lint 乾淨、grep 找不到 old-api
良い条件の 3 つの共通点 : 定量化できる終端状態 (exit code、ファイル数、queue が空)、「どう証明するか」が書いてある (どのコマンドを走らせるか)、時間制限の保険 (「あるいは N ターン後に停止」で無限にトークンを燃やさない)。悪い条件によくある問題は「品質が良い」「もっと分割する」といった主観的な言葉 — 評価器には読み取れません。
05 · 読む
Claude Code には「自動継続」のためのツールがいくつかあり、混同しないでください : - /goal — 条件を設定して、Claude が達成までターンを重ねて走る。ポイントは「完了まで走る」、何ターンかかってもいい。 - /loop — スケジュールを設定 (たとえば「5 分ごとに X をやる」)、時間が来たら走る。ポイントは「定期チェック」、走り切ることではない。 - Stop フック — 設定ファイルに書くスクリプト、各ターンの終わりにあなた独自の判断ロジックを走らせる。ポイントは「セッションをまたいで効くカスタムルール」。 - Auto mode — 「ツール呼び出しのたびに yes を押す」プロンプトを取り除く。ポイントは「承認免除」、Claude が自分で停止時を決めることではない。
組み合わせると最強 : Auto mode で承認免除 + /goal で完了まで走る = 本当に Claude に手放して自走させられる。
ポイントまとめ
- /goal = 条件達成まで走る (セッション限定)
- /loop = 時間スケジュール (定期的)
- Stop フック = セッションをまたいだカスタムロジック (設定に書く)
- Auto mode = yes を押さなくていい
- Auto mode + /goal を一緒に使うと、本当のバックグラウンド走行ができる
06 · クイズ
古い React class component をすべて hooks に書き直したい、30 ファイルあります。次のうち、どの /goal 条件が最も完了まで走り切れる見込みがありますか？
- /goal すべての class component を hooks に書き直す
- /goal すべての class component を hooks に書き直し、各ファイルで元のテストがパスし、grep で extends React.Component が見つからない、あるいは 40 ターン後に停止
- /goal コードをより現代化し、保守しやすくする
- /goal 私が満足するまで component を書き直す
07 · 対応づけ
各シナリオを、最適なツールと結びつけてください。
（このセクションはインタラクティブです — JavaScript を有効にしてください。）
⚠ 全機能のインタラクティブ体験には JavaScript が必要です。JavaScript を有効にして再読み込みしてください。
※ このサイトは独立した教育プロジェクトで、Anthropic の公式製品ではありません。Claude™ は Anthropic, PBC の商標です。