Claude Codeの/goalコマンド — 完了条件を渡して達成まで自走させる使い方

/goalコマンドとは — 完了条件を渡して、満たされるまで作業を続けさせる

/goal は、「この状態になったら完了」という条件を先に設定しておくコマンドです（Claude Code v2.1.139以降）。条件を渡すとその場で作業が始まり、1回の作業が終わるたびに条件を満たしたかどうかが確認されます。満たしていなければ、あなたが何も打ち込まなくても次の作業が始まります。満たしていれば、ゴールは自動的に解除されて手が止まります。

特徴は、達成したかどうかを作業した本人とは別のモデルが判定することです。作業が終わるたびに、設定した条件とそれまでのやりとりが小さくて速いモデル（標準ではHaiku）に渡され、「満たした・満たしていない」と短い理由が返ります。満たしていない場合、その理由が次の作業の手がかりになります。自分で自分に合格点を出すのではなく、別の目が毎回チェックする構造です。

どんな仕事に向くか — 終わりが機械的に判定できる作業

• 終わりが明確な長い作業 — 「テストがすべて通るまで」「未対応の項目がゼロになるまで」のように、達成を数えられる形で言える仕事
• 単調な繰り返しで、途中に人の判断が要らない作業 — 一覧の項目を上から順に処理する、指摘事項を1件ずつ潰していく
• 席を外している間に進めておいてほしい作業 — 会議中や移動中に、完了条件まで到達させておく

逆に向かないのは、完了を言葉で定義できない仕事です。「いい感じに整えて」「読みやすくして」のような依頼は、何をもって終わりとするかが決まらないため、延々と作業が続くか、根拠のないまま完了と判定されるかのどちらかになります。途中で好みの判断が何度も必要な仕事も、人が都度見たほうが結果的に速く済みます。

使い方 — 設定・確認・解除の3つだけ

ゴールは1つのセッションに1つだけです。走っている間は画面に稼働中の表示が出て、経過時間が分かります。別の条件を設定すると前のゴールは上書きされます。セッションを閉じても、--resume や --continue で再開すれば条件は引き継がれます（経過時間や判定回数は初期化されます）。

対話画面以外でも使えます。claude -p "/goal ..." のように起動すれば、条件を満たすまでの一連の作業を1回の実行で最後まで走らせられます。この形は定期実行の中に組み込むこともできます。デスクトップアプリや遠隔操作からも同じように利用できます。

成否を分けるのは「完了条件の書き方」

最も重要な仕様は、判定役は自分でファイルを開いたりコマンドを実行したりしないことです。判定に使えるのは、Claudeが作業の中で画面に出した内容だけ。「テストがすべて通っている」という条件が機能するのは、Claudeがテストを実行し、その結果がやりとりの中に残るからです。「バグがないこと」のように、何を見れば判断できるのかが決まっていない条件では、判定役は判断材料を持てません。

• 測れる終了状態 — テストの結果、エラー件数ゼロ、未処理の行が残っていない、など数えられるもの
• どうやって示すかまで書く — 「テストコマンドが成功で終わること」のように、証拠の出し方まで条件に含める
• 変えてはいけないもの — 「ほかのファイルは修正しない」など、達成の途中で壊されると困る前提を明記する

# 判定できる条件（証拠が画面に出る）
/goal test/auth のテストがすべて通り、lintも警告ゼロで終わること。
ほかのテストファイルは変更しない

# 判定できない条件（終わらない・誤判定のもと）
/goal 認証まわりをいい感じに直して

条件は4,000文字まで書けます。長く走りすぎるのを防ぎたいときは、「20回試して達成できなければ止める」のような打ち切りの条件も一緒に書いておくと安全です。打ち切り条件も判定の対象になるため、想定外に作業が続くことを防げます。

権限は広がらない — 自走させるなら自動承認とセットで

誤解しやすい点ですが、ゴールを設定してもClaude Codeの権限は1ミリも広がりません。標準の権限設定のままなら、許可していない操作をしようとするたびに確認が出て、そこで止まります。「席を外している間に完了まで進めておいてほしい」という使い方をするなら、ツールの実行を自動で承認する設定と組み合わせる必要があります。

逆に言えば、/goal が決めるのは「いつまで続けるか」だけで、「何をしてよいか」は決めません。何を自動で許すかは権限設定側の設計です。この2つを分けて考えると、「自走はさせたいが、本番環境に触る操作だけは必ず人が承認する」といった運用が組み立てられます。

なお仕組みの上では、作業が終わったタイミングで動くフックの簡易版として実装されています。そのため、フックを禁止する設定になっている環境や、信頼済みとして開いていない作業フォルダでは使えません。その場合は理由が表示されるため、黙って動かないということはありません。

似た仕組みとの使い分け

「AIに続けて動いてもらう」仕組みはほかにもあります。違いは次の作業が始まるきっかけと止まる条件です。

完了条件で止めたいなら /goal、一定間隔で様子を見に行かせたいなら /loop、全セッション共通の判定を自前で作り込みたいならフック。決まった時刻に動かす定期実行との使い分けはClaude Codeで定期実行・自動化する方法で解説しています。

Codexの/goalとの違い

OpenAIのCodexにも同名の /goal があり、ゴールと完了条件を渡して達成まで自走させるという考え方は共通です。実務上の違いは2点で、Codexはゴール文に書いた検証方法をCodex自身が確かめながら進むのに対し、Claude Codeは作業する側とは別の判定役を置きます。また、走行中の一時停止・再開ができるのはCodex側で、Claude Codeは状況確認と解除（および新しいゴールでの上書き）が基本です。

Codex側の/goalの使い方と完了条件の書き方はCodexの/goalコマンドに、両ツールの選び方はClaude Codeの比較にまとめています。

法人運用での使いどころ

• 検収基準を言語化する訓練になる — 「何を確認できたら完了か」を書けない業務は、人に任せても品質が安定しない。ゴールが書けないこと自体が、業務が定義されていないサインになる
• 離席中・夜間の作業に使える — ただし自動承認の設定とセットになるため、何を自動で許すかの権限設計が前提。影響の大きいリポジトリでは、承認範囲を絞ったうえで使う
• コストは打ち切り条件で制御する — 判定そのものは小さいモデルで行われるため負担はわずかですが、作業が長く続けばそのぶん本体の消費は増えます。「何回で打ち切るか」を条件に含めておくのが安全です

当社のClaude Code研修では、完了条件の書き方・権限設定・ハーネスの設計を組み合わせて、「安心して任せきれる状態」を各社の実務に合わせて作るところまで支援しています。