- 完了条件を1文書くと、AIは条件を満たすまで自分でターンを回し続ける。
- customer-portalの4機能を、逐次プロンプトなしで完走させた実体験ベース。
- 効く条件の核心は「検証結果を会話に出させる」一文。公式情報で裏取り済み。
Claude Codeを毎日触っていて、地味にストレスだったのが「続けて」の連打だ。AIがひと仕事するたびに手を止めて、また同じ指示を打つ。SE歴20年で本業も副業もClaude Code Max 5xで回している筆者でも、この往復は効いた。
/goalコマンドはこの往復を消す。完了条件を1文書くと、AIは条件を満たすまで自分でターンを回し続ける。実際にcustomer-portalの生産パイプラインを設計工程まで広げる4機能を、逐次プロンプトなしで完走させた。この記事は、その実体験で分かった「効く完了条件の書き方」を軸に、Anthropicの公式ドキュメントで裏を取りながらまとめる。
最初は半信半疑だった。でも一度走らせたら、詰まっても止まらず原因を追い続けるAIを横で見て、考え方が変わった。
/goalとは？「続けて」連打から解放される仕組み
「続けて」を何度も打っていた従来のClaude Code
通常のClaude Codeは1ターンごとに手を止める。テストを書いて、止まる。「続けて」。実行して失敗、止まる。「続けて」。長い作業ほど、この間に人が挟まる回数が増える。
問題は手数だけじゃない。人が間に入るたびに集中が切れ、AIがどこまで進んだかを毎回読み直すことになる。タスクが大きいほど、この「Enterを押す係」の負担が重くなっていく。
/goalの動作フロー：評価器が毎ターン完了判定するループ
/goalは完了条件をひとつ受け取り、その条件を満たすまでターンを自動で回す。Anthropicの/goalコマンド公式ドキュメントによると、各ターンが終わるたびに小さく速い評価モデル（既定はHaiku）が「条件は満たされたか」を判定する。未達ならその理由を次ターンへの指示として渡し、もう一度ターンを始める。条件が満たされた瞬間にゴールは自動で解除され、Claudeは通常モードに戻る。
graph TD A["ターン実行"] --> B["評価器が判定"] B -->|"未達 理由を渡す"| A B -->|"達成"| C["ゴール自動解除"] B -->|"打ち切り句"| D["停止"] style A fill:#e8eef6,stroke:#9fb3cc style C fill:#e8f3ec,stroke:#9ec7ad style D fill:#f3ece8,stroke:#c7b09e
筆者の実行では、途中で2回詰まった。1回目は"use server"ファイルでobjectをexportしてアクションが全滅したケース、2回目はagent-browserのclickがServer Actionを発火させなかったケース。どちらも/goalは「未達」と扱って継続させ、原因の特定から修正まで自走でやり切った。止まらず原因追及を続けるこの粘りが、人が「続けて」を打つ運用との一番の差だった。
コスト感覚：自走で消費トークンはどう変わるか
正直に書くと、正確なトークン数は筆者の手元では計測していない。ただ確認手段はある。引数なしで/goalを打てば、その時点のターン数とトークン消費が出る。これが唯一の実測手段だ。
体感はこうだ。「続けて」連打は人が間に入る分、自然にペースが制御される。一方/goalは人の入力なしで連続ターンが走るので、短時間に多くのターンが進み、消費は速い。判定役のHaiku分は、公式も本体ターンに比べて無視できる量だと明記しているので、評価器のコストは気にしなくていい。気をつけるべきは本体ターンの速度のほうだ。トークン単価そのものを詰めたい場合は、Opus・Sonnet・Haikuを役割で分ける3層スタックでコストを半減させる手順が効く。
完了条件の書き方：自走を成功させた実例
効いた条件の4要素
公式ドキュメントは、長いターン数を越えても崩れない条件の要素を挙げている。測定可能な終了状態、それをどう証明するかの手段、途中で壊してはいけない制約だ。筆者が実際に走らせて完走した条件は、これに打ち切り句を足した形だった。
/goal customer-portalの生産パイプラインを設計工程まで拡張する。
レビュー収束性・承認フロー・改訂自由指示・設計工程の横展開の4機能を実装し、
npx tsc --noEmit がエラー0で、各機能を実際にsupabaseで確認した結果を会話に示し、
既存機能を壊さないこと。 or stop after 60 turns要素を分解すると、こうなる。
測定可能な終了状態：「tsc がエラー0」。会話に証拠（コマンド結果）が残る終了点。
証明する手段：「supabaseで確認した結果を会話に示す」。検証を強制する一文。
壊してはいけない制約：「既存機能を壊さない」。暴走の歯止め。
打ち切り句：「or stop after 60 turns」。上限を切ってループの底を作る。
条件は最長4,000文字まで書ける。短くまとめる必要はないので、終了状態・証明手段・制約を遠慮なく詰め込んでいい。
最重要は「検証結果を会話に出させる」一文
4要素のなかで決定的だったのは、「supabaseで確認した結果を会話に示す」の一文だ。評価器は会話に出た内容しか見ない。コマンドを自分で叩いたりファイルを読んだりはしない。公式も評価器について、Claudeが会話で表に出したものしか判定できないと明記している。
つまり「検証結果を会話に出させる」と書くことで、AI自身が検証ログを吐くよう仕向けられる。この一文がないと、AIは内部で「できたつもり」になっても、評価器にはそれが見えず判定が進まない。逆にこの一文があると、AIは証拠を会話に残しながら進むので、判定がきれいに通る。
「会話に出させる」を入れるか入れないかで、自走の安定感がまるで違った。評価器の目線で条件を書く、という発想が要る。
主観条件が引き起こす「止まれないループ」
逆に入れてはいけないのが主観条件だ。筆者は「UXを良くする」のような条件は最初から外した。評価器が良し悪しを測れないからだ。
公式が挙げる典型的な失敗例も「本番運用に耐える品質（production-ready）」型の条件で、検証可能な出力を生まないため達成判定が出ない。条件が甘すぎれば早すぎる解除、達成不能なら打ち切り句に当たるまで回り続ける。会話に証拠が出る客観条件だけが機能する–これは実際に走らせて骨身にしみた。
「指示を出す人」から「仕事を設計する人」へ
曖昧な指示はAIにも人にも通じない
完了条件を書く作業は、要するに「終わりの定義」を言語化する作業だ。これはAI特有の話じゃない。曖昧な指示は人間の部下にも通じない。「いい感じにして」で動ける人はいない。
AIの場合、曖昧さは別の形でも牙をむく。指示が緩いと、存在しない仕様を勝手に埋めてくることがある。プロンプトが育ちすぎて888行プロンプトで起きた破綻を一度経験すると、客観的に検証できる指示だけが効くという感覚が身につく。/goalの完了条件は、その感覚を毎回強制してくる。
完了条件を書く訓練が仕事の解像度を上げる
「会話に証拠が出る客観条件だけが効く」という制約は、副業開発でそのまま武器になる。何をもって完了とするかを1文で書けるなら、その仕事は設計できている。書けないなら、まだ自分の中でゴールが曖昧だということだ。
筆者がCLAUDE.mdとBUGS.mdを使い分ける運用に行き着いた経緯は個人サービスを作った正直な話に書いたが、結局どれも同じ方向を向いている。AIを動かすほど、自分の指示の甘さが可視化される。/goalはその最先端で、「指示を出す人」を「仕事の終わりを定義する人」に変えていく。
Agent View・/loopと組み合わせる（公式情報・筆者未検証）
claude agentsで並列セッションを一望する
複数のセッションを並列で回すと、ターミナルのタブが増えて、どれが終わったか分からなくなる。AnthropicはAgent Viewの公式発表で、claude agentsコマンド（またはセッション内で左矢印）から全セッションを1画面に並べる仕組みを示している。各行に「どれが入力待ちか・作業中か・完了したか」が出る研究プレビュー機能だ。
/goalを背景で走らせ、その進捗をAgent Viewで眺める、という組み合わせが想定できる。並列実行やHooksの基礎をまず固めたい場合は、/powerupで隠れ機能を体系的に学ぶ手順から入ると地続きで理解しやすい。
/loopとの違い：時間駆動 vs 完了駆動
/goalと混同しやすいのが/loopだ。公式の比較によれば、/goalは「前のターンが終わったら次が始まり、条件を満たすと止まる」完了駆動。/loopは「一定間隔で同じプロンプトを再実行する」時間駆動で、夜間テストや朝の定期チェックに向く。終わりが条件で決まる作業は/goal、決まった間隔で回したい作業は/loop、という切り分けになる。
朝に仕込んで夕方確認するハーフオート運用
公式は、開いたセッションとは独立に夜間テストや朝の仕分けを走らせるスケジューリングにも触れている。背景セッションとAgent View、あるいは/loopを組み合わせれば、朝に仕込んで夕方に結果だけ見る運用が描ける。ただし筆者の今回の実行はインタラクティブな単一セッションで、ここまで完走させたところまでだ。背景＋並列の本格運用は未検証なので、組み合わせる際は小さく試してから広げてほしい。
/goalが動かないときの前提条件
信頼ダイアログとフックシステム
/goalの実体は、セッション単位のStopフックのラッパーだ。だから公式のフックガイドが示すフックシステムが動く環境が前提になる。具体的には、信頼ダイアログを承認したワークスペースでないと/goalは動かない。承認していない場合、コマンドが理由を表示してくれるので、無反応で悩むことはない。
法人・チームのポリシーで無効化される
会社のmanaged policy設定でdisableAllHooksが有効になっていると、フックごと無効になり/goalも使えなくなる。チームや法人のClaude Codeで「コマンドが反応しない」場合は、まずこの管理ポリシーを疑うといい。これも公式のRequirementsに明記されている挙動だ。
バージョン確認とアップデート
/goalもAgent Viewも比較的新しい機能で、Agent Viewの研究プレビューはv2.1.139以降が要件とされている。claude --versionで確認し、古ければnpmで更新しておく。完了判定の精度はバージョンが上がるほど改善されているので、新しめに保つのが無難だ。
今日から始める/goal活用ステップ
副業開発で試すなら、いきなり大物に当てず、小さく回して感覚を掴むのが近道だ。
- STEP1連打タスクを1つ選ぶ
今「続けて」を繰り返しているタスクを1つ特定する。テストを通すまで、リファクタが終わるまで、といった「終わりが言える」作業が向く。
- STEP2完了条件を1文で書く
終了状態・証明手段・制約・打ち切り句を1文に詰める。とくに「結果を会話に示す」を入れて、AIに証拠を吐かせる。これが効く条件の核心。
- STEP3小さく走らせて消費を見る
短い作業で走らせ、引数なしの/goalでターン数とトークン消費を確認する。自走のペース感を体で覚えてから、大きいタスクに広げる。
よくある質問
- Q/goalは普通のClaude Codeと何が違いますか？
- A
通常はAIが1ターンごとに止まり、人が「続けて」と打ち直す。/goalは完了条件を満たすまでAIが自分でターンを回し続ける。各ターンの後ろで小さな評価器が条件を満たしたか判定し、未達なら自動で次のターンに入る。人がEnterを押す回数がゼロになるのが最大の違い。
- Q自走中にトークンを使いすぎませんか？
- A
人が間に入らない分ターンが連続するので、消費は短時間で速く進む。引数なしの/goalを打てば、その時点のターン数とトークン消費が出るので途中で確認できる。条件末尾に「or stop after 60 turns」のような打ち切り句を入れておけば暴走は防げる。判定役のHaiku分は本体に比べて無視できる量だと公式も明記している。
- Qどんな完了条件だと失敗しますか？
- A
「本番運用に耐える品質」のような主観的な条件は失敗する。判定する評価器は会話に出た内容しか見ないので、良し悪しを測れない条件は達成判定が出ない。「npm testがエラー0」「git statusがクリーン」のように、AIの出力に証拠が残る客観的な終了状態を書くこと。
- Q法人アカウントで/goalが使えないのはなぜですか？
- A
/goalはフックシステムを使って動く。会社のmanaged policyでdisableAllHooksが設定されていると、フックごと無効になり/goalも使えない。また信頼ダイアログを承認していないワークスペースでも動かない。どちらの場合もコマンドが理由を表示するので、無反応で悩むことはない。
- Q/loopとはどう使い分けますか？
- A
/goalは「条件を満たしたら止まる」完了駆動。/loopは「一定間隔で同じプロンプトを再実行する」時間駆動で、夜間テストや定期チェックに向く。終わりが条件で決まる作業は/goal、決まった間隔で回したい作業は/loop、と分けると迷わない。
まとめ
/goalを実際に使って分かったのは、3つだ。
ひとつ、完了条件を1文書くだけで、AIは詰まっても止まらず条件を満たすまで自走する。ふたつ、効く条件の核心は「検証結果を会話に出させる」一文で、評価器は会話しか見ないからここが決定的。みっつ、客観的に検証できる終了状態だけが機能し、主観条件は止まれないループを生む。
まず手元で「続けて」を連打しているタスクを1つ選び、終わりを1文で書いてみる。それが書けたなら、その仕事はもうAIに渡せる。書けないなら、自分の中でゴールがまだ曖昧だというサインだ。/goalは、その曖昧さを毎回突きつけてくる道具でもある。
「Enterを押す係」から卒業すると、空いた時間で次の設計を考えられる。副業の時間は有限だから、この差は大きい。
