Claude Code /goal コマンド完全入門｜完了条件を渡すとターンを跨いで自走する仕組み【2026年版】

Anthropic Official · Claude Code · 2026 Edition

本サイトは Google AdSense による広告が表示されることがあります（記事内容には影響しません）。本記事はアフィリエイトではなく公式ドキュメントの解説です。

毎ターン「続けて」「次やって」「テストまだ落ちてる？」と Claude Code に打ち続けるのに疲れたことはありませんか。2026 年に公式追加された /goal コマンドは、まさにその「ターン渡り作業」を消すための仕組みです。本記事は Anthropic 公式ドキュメント Keep Claude working toward a goal^[1] を、はじめて触る人向けに 1 行ずつほどいて解説します。読了 8 分。

user@sinyblog:~/article ❯ 01_tldr.md結論：/goal は「完了条件を渡すと自走する」コマンド

細かい説明に入る前に、この記事を 1 行で要約します。

/goal <完了条件> と打つと、Claude Code は その条件が満たされるまで毎ターン自動で次の作業を続ける。完了したかどうかは別の小さなモデル（既定は Haiku）が判定する。

公式ドキュメント要約 / [1]

つまり、これまで自分が「続けて」「もう一回やって」と毎ターン打っていた判断を、あなたが渡した完了条件と、その条件の自動判定モデルに置き換えるのが /goal の仕事です。

user@sinyblog:~/article ❯ 02_problem.mdこれまでの不便：「続けて」を毎ターン打つ問題

Claude Code は、Claude にツール（ファイル編集・コマンド実行・テスト走行など）を使わせながら開発を進められる CLI です。ただし、1 つ大きなクセがあります。

1 ターンが終わるたびに、制御がユーザーに戻るのです。たとえば次のような流れは、よくある光景でした。

1. 「test/auth のテストを通して」と指示
2. Claude が修正 → テスト実行 → 2 件赤いまま 1 ターン終了
3. ユーザーが「続けて」と打つ → 次のターンが走る
4. また赤が残っている → ユーザーが「続けて」
5. ……これを 5〜10 回繰り返す

本来は 「全部緑になるまで頑張って」と一度伝えれば済む話なのに、合間の「続けて」を人間が毎回タイプしないと進まない。これは Claude Code 1.x 時代から続く構造的な不便で、運用上、地味に集中力を削っていました。

/goal はこの問題に対する公式の回答です。Anthropic 公式ドキュメントは次のように説明しています^[1]。

After each turn, a small fast model checks whether the condition holds. If not, Claude starts another turn instead of returning control to you.

Anthropic — Keep Claude working toward a goal / [1]

つまり「制御をユーザーに戻すか、Claude にもう 1 ターン回させるか」の判定を、小さい評価モデルに肩代わりさせる仕組みになっています。

user@sinyblog:~/article ❯ 03_syntax.md基本構文：set / status / clear はすべて /goal

/goal は「設定・確認・解除」のすべてを 1 つのコマンドで兼ねます。引数の違いで動きが変わるだけです。

最小例を 1 つ動かしてみます。

/goal all tests in test/auth pass and the lint step is clean

この 1 行を送ると、ふだんなら「test/auth のテストと lint を通して」と打ったときと同じように Claude が動き始めます。違うのは、1 ターン目が終わってもプロンプトが返ってこないことです。代わりに評価器が走り、条件が満たされていなければそのまま 2 ターン目に入ります。

解除したくなったら /goal clear です。すぐ止まります。

/goal clear

user@sinyblog:~/article ❯ 04_display.md画面に出るもの：経過時間・ターン数・トークン

ゴールが動いている間、画面の上端付近に ◎ /goal active という小さなインジケータが表示され、そのゴールが何分動いているかを常時カウントします^[1]。

もっと詳しい数字を見たくなったら、/goal を引数なしで叩きます。表示されるのは次の 5 つです。

• 現在の完了条件（あなたが渡した文）
• 経過時間（このゴールを動かしてから何分か）
• ターン数（評価器が見たターンの累計）
• トークン使用量（このゴールで消費した分）
• 評価器の最新コメント（なぜまだ未達なのか、または次に Claude が見るヒント）

最後の「評価器の最新コメント」は地味に強力です。Claude が「コードを書き換えた → テストはまだ赤」と動いた直後だとすると、評価器は次のような短文を返します（公式の挙動説明より^[1]）。

2 of 14 tests in test/auth are still failing; lint has not been re-run yet.

評価器が返すコメントの例（概念図）

このコメントは 次のターンの Claude にも引き継がれるので、人間が「次は lint を流して」と言わなくても、Claude はそのヒントを読んで動きを継続できます。

user@sinyblog:~/article ❯ 05_condition.md「効く完了条件」の書き方 3 原則

/goal は強力ですが、条件文の書き方しだいで成果が大きく変わります。評価器は「自分でコマンドを叩いてファイルを読む」ことはできず、会話のなかで Claude が表に出した出力だけを見て可否判定するためです^[1]。

公式が推奨する「長持ちする条件文」の構造は次の 3 点セットです。

1. 計測可能な終端状態を 1 つだけ書く（テスト結果・ビルドの終了コード・ファイル数・キューが空・など）
2. その確認手段を一緒に書く（例：「npm test exits 0」「git status is clean」）
3. 途中で壊してはいけない制約があれば書く（例：「他のテストファイルは編集しない」）

ダメな書き方と効く書き方を 1 組だけ比べてみます。

もう 1 つ覚えておきたいのが 「打ち切り句」です。完了条件のなかに 「もしくは 20 ターン経過したら止める」のような句を入れておくと、評価器はそれも判定材料にしてくれます。たとえば次のように書きます。

/goal `npm test` exits 0 and `npm run lint` exits 0, or stop after 20 turns

これがないと、テストが永遠に直らないコードでゴールが回り続けて、想定外のトークンを溶かす可能性があります。「自走系コマンドには必ず止め時を一緒に渡す」と覚えておきましょう。

user@sinyblog:~/article ❯ 06_evaluator.md完了判定はどう行われるのか（評価モデルの正体）

「条件が満たされたかどうかは誰が決めるのか？」——これは /goal を使うとき必ず気になる点です。仕組みは次のようになっています^[1]。

1. Claude が 1 ターン終わる
2. その時点までの会話全体と完了条件が、契約中プロバイダの「small fast model」（既定では Haiku）に送られる
3. その小さなモデルが Yes / No と短い理由を返す
4. No なら、その理由が次ターンへのヒントとして Claude に渡され、自動的に次ターンが始まる
5. Yes なら、ゴールは自動クリア。トランスクリプトに「achieved」として記録される

仕組み上、評価器は 自分でツールを呼ばない点が重要です。会話のなかで Claude が表に出した文字情報しか見られないので、たとえば「テスト全部緑」を判定させたいなら、Claude が npm test を実行してその出力を会話に貼り付ける必要があります（普通は実行すれば貼られるので、特別な工夫はほぼ不要）。

実装的には、/goal は 「セッション限定の prompt-based Stop hook」のラッパーです^[1]。Stop hook を自分で書けば同じことができますが、/goal は「セッション内で 1 行で起動・解除できる」気軽さが売りです。逆に「全セッション共通で同じ判定を走らせたい」「シェルスクリプトで判定したい」場合は、settings に Stop hook を仕込むほうが向いています（後述）。

user@sinyblog:~/article ❯ 07_compare.md似た自走系コマンドとの違い（/loop / Stop hook / Auto mode）

Claude Code には、自走に使える仕組みがすでに複数あります。/goal をきれいに使い分けるには、それぞれが 「いつ次ターンを始めるか」「いつ止まるか」で何が違うかを押さえるのが近道です。公式のまとめを表にすると次のとおりです^[1]。

関係を一文で言うと、Auto mode は「ツール承認」を自動化し、/goal は「次ターンを開始するか」を自動化する、というレイヤーの違いです。両者は併用できます^[1]。Auto mode で個別ツールの「許可しますか？」をスキップしつつ、/goal でターンの「続けますか？」もスキップする、というのが実用上いちばん強力な組み合わせです。

user@sinyblog:~/article ❯ 08_headless.md非対話実行と再開（-p / --resume）

/goal は対話セッション専用ではありません。非対話モード（headless）でも、Remote Control 経由でも動きます^[1]。CI からも cron からも呼べる、ということです。

公式の最小例はこうです。

claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"

この 1 行で、Claude Code は 「今週マージされた全 PR が CHANGELOG.md に記載されている」を満たすまで自走し、達成したら 0 で終了します。途中で止めたいときは Ctrl+C で OK。

もう 1 つ覚えておきたいのが セッション再開時の挙動です。

• claude --resume や --continue でセッションを再開した場合、未達のゴールはそのまま引き継がれる
• ただしターン数・経過時間・トークンのカウンタはリセットされる
• すでに達成済み or 解除済みのゴールは復元されない

「昨日の自走を、今日は別マシンから続きたい」みたいなときに便利な仕様です。ただしカウンタはリセットされるため、コスト感の通算管理は別途必要になります。

user@sinyblog:~/article ❯ 09_use_cases.md使いどころ：今日から試せる 4 ユースケース

公式が想定例として挙げているのは、次の 4 つのような 「終端状態が検証可能」な仕事です^[1]。

1. モジュールの API 移行：旧 API を呼んでいる全箇所をビルド成功＆テスト通過まで書き換える
2. 設計ドキュメントの実装：仕様書中の acceptance criteria を全部満たすまで実装と修正を続ける
3. 大ファイルの分割：1 ファイル N 行以下になるまでモジュール分割
4. ラベル付きの Issue バックログ整理：対象ラベルの Issue キューが空になるまで対応

個人開発寄りの例にも置き換えやすいので、3 つだけ条件文サンプルを置いておきます。コピペで動く形にしてあります。

// 1. テストと lint を全部通す
/goal `pytest` exits 0 and `ruff check` exits 0, or stop after 15 turns

// 2. 大ファイルを分割し、すべて 400 行以下にする
/goal every file under src/ is at most 400 lines, all tests still pass, or stop after 30 turns

// 3. TODO コメントを 0 件にする
/goal `grep -r "TODO" src/` returns no matches, no test breaks, or stop after 25 turns

user@sinyblog:~/article ❯ 10_requirements.md要件と注意点

/goal は hooks システムの上で動いているため、ワークスペースの信頼設定が前提になります。具体的には次の 2 点です^[1]。

• そのワークスペースで trust dialog（信頼ダイアログ）を承認済みであること
• 管理ポリシーで disableAllHooks が true になっていないこと

どちらかを満たしていない場合、コマンドは黙って失敗するのではなく、その理由を表示して停止してくれます。企業環境などで動かない場合は、まず IT 管理者に hooks の有効化を相談するのが筋です。

user@sinyblog:~/article ❯ 99_summary.mdまとめ

ここまでを 3 点に圧縮します。

1. /goal <完了条件> で Claude Code はターン跨ぎで自走する。判定は小さい評価モデル（既定 Haiku）が会話履歴を見て下す。
2. 条件文は「終端状態 + 確認手段 + 制約 + 打ち切り句」の 4 点セットで書くと壊れにくい。「いい感じに」みたいな主観条件は向かない。
3. Auto mode と組み合わせると効果が大きい。Auto mode が「ツール承認」を、/goal が「次ターン開始」を肩代わりしてくれるので、人間は完了通知が来るまで他の作業に集中できる。

慣れてくると、/goal は「タスク管理 UI」に近い感覚で扱えるようになります。GitHub Action や CI 上の cron からも投げられるので、夜のうちに走らせて朝には PR ができている、という運用も現実的です。まずは手元のテストプロジェクトで「テストが緑になるまで」のシンプルな条件文を 1 度試してみるのが、いちばん早く感覚を掴む方法です。