Claude Code の /goal：2026年の自律モードと Agent View

Ailoot リファレンスドキュメント：ailoot.ai/docs/。

Claude Code の /goal とは？#

以前の Claude Code は、応答のたびに停止し、次のプロンプトを待っていました。短いタスクでは問題ありませんでしたが、長いタスクでは行き詰まりました。API の移行、12件の失敗テストの修正、800行のファイルのリファクタリングといった作業には20～30回の反復が必要で、そのたびにターミナルに戻ることになります。

/goal は、「作業する者」と「完了を判断する者」を分けるというシンプルな考え方で、この問題を解決します。メインエージェントがコードを書きます。別の評価役（高速な Haiku モデル）が各ターンの後に会話を読み、ひとつの質問に答えます。「条件は満たされましたか？」満たされていなければ、エージェントは次のターンを開始します。満たされていれば、制御があなたに戻ります。

Anthropic の公式ドキュメントでは、次のように定義されています。

スマートフォンから夜間に何千ものエージェントを動かす――これは宣伝文句ではなく、Anthropic のエンジニアが現在実践している方法です。それを可能にする仕組みが、2026年5月11日の同じリリースで導入された /goal と Agent View の組み合わせです。

自律モードが必要な理由：2026年5月11日より前と後では何が変わったのか？#

「AI に一晩中作業させる」という考え方は、Cursor Composer や Cline の自動モードがすでにバックグラウンドで動作できた2025年秋には存在していました。しかし2026年5月11日より前の Claude Code では、これを実現するために手作業のラッパーが必要でした。N分ごとに claude -p を呼び出す cron タスクや、git status を監視して次のプロンプトを起動するラッパーなどです。

この自作方式は、たびたび大失敗につながりました。2026年5月22日、開発者がそのようなスクリプトを動かしたまま一晩過ごし、朝起きると6,000ドルの請求が届きました。根本原因は、Anthropic が告知なしに Claude Code のキャッシュ TTL を1時間から5分に変更したことでした。cron は30分ごとに本番環境を呼び出しており、実行の合間にキャッシュが期限切れになっていました。実行のたびに80万トークンの履歴が最初から再構築されました。新しいデータをキャッシュに書き込むコストは、アクティブなキャッシュから読み込むよりもはるかに高くなります。

その開発者は、何か特殊なことをしていたわけではありません。Anthropic が宣伝していたとおりにツールを使っていました。

/goal は、次の組み込みアーキテクチャでこの問題を解決します。

1. 監督プロセスがセッションをターミナルの外に置き、ウィンドウを閉じたりノートパソコンがスリープしたりしても維持します。
2. Haiku 評価モデルが各ターンを低コストで確認します。評価モデルのトークン費用はわずかです。
3. 条件内の厳格なターン上限として、or stop after 20 turns を明示できます。これにより、セッションは確実に停止します。
4. バックグラウンドセッションの worktree 分離により、変更は別のブランチに保存され、作業コピーには触れません。

「bash スクリプトを自作する」方法との違いは、Anthropic がこうした仕組みをサードパーティー製のハックではなく、ツールの中核機能として提供していることです。

/goal を3ステップで有効にする方法#

ステップ1. Claude Code を 2.1.139 以降に更新する。

バージョンを確認します。

claude --version

2.1.139 より古い場合は更新します。

claude update
# or force it through npm
npm install -g @anthropic-ai/claude-code@latest

2026年5月12日から19日のリリースでは、初期バージョンの重要なバグが修正されました。2.1.140 では、disableAllHooks が評価モデルをブロックする無言のハングが修正されました。2.1.143 では、worktree.bgIsolation: "none" と stop hook のループに対する修正が追加されました。2.1.144（5月19日）では、バックグラウンドセッション用の --resume と、スクリプト実行用の agents --json が追加されました。最低バージョンは 2.1.143 です。

ステップ2. 条件を付けて /goal を入力する。

通常の Claude Code セッションを開き、次のコマンドを入力します。

/goal all tests in test/auth pass and the linter is clean, or stop after 15 turns

この後に別のプロンプトを送る必要はありません。コマンドを入力すると、最初のターンがすぐに始まります。条件は日本語、英語、またはその混在で書けます。モデルはどちらの言語も理解します。長さの上限は4,000文字です。

ステップ3. ライブオーバーレイで監視する。

/goal が始まると、ターミナルの下部にライブパネルが表示されます。

/goal active · 3 turns · 12m elapsed · 18,400 tokens · last: tests in test/auth/login.test.ts still fail

表示される内容は次のとおりです。

• Turns—完了したターン数
• Elapsed—起動からの経過時間
• Tokens—使用したトークンの合計（予算を監視する主要な数値）
• Last—評価モデルが最後に「まだ」と判断した理由

便利な見分け方として、評価モデルが3ターン連続で同じ理由を返したら、ループに入っている兆候です。その場合は Ctrl+C を押すか、/goal clear（同義語：stop、off、reset、cancel）を入力し、条件を書き直して再び起動します。このルールは /goal のコミュニティーガイドにも、ループの主要な兆候として記されています。「同じ理由で3回行き詰まったらループなので、終了する」。

良い条件の書き方：5つのルールと5つの例#

Anthropic のドキュメントでは、良い条件に必要な3つの要素を次のように説明しています。

3つの要素を1行で網羅する、そのまま使えるテンプレートがあります。

/goal [作業内容] を [測定可能な最終状態] になるまで実行する。ただし [守るべき制約] は遵守する

多くの人がつまずく5つのルール：

ルール1. 最終状態は、好みではなくコマンドで検証できる必要があります。

「見栄えを良くする」ではなく npm test exits 0。「UX を改善する」ではなく Lighthouse Performance score above 90 とします。評価モデルが読むのはトランスクリプトだけです。コマンドを実行したり、スクリーンショットを見たりはしません。結果をテキストで記録できなければ、評価モデルは決して「はい」と言いません。

ルール2. 制約は明示し、範囲を絞る必要があります。

制約がなければ、Claude はテストそのものを削除したり、失敗するアサーションをコメントアウトしたりして、テストを修正するかもしれません。without modifying any file outside /auth、without removing existing assertions、without bumping major versions of dependencies と指定してください。

ルール3. 厳格なターン上限が必要です。

すべての条件に or stop after N turns を加えてください。終わりのないループに対する命綱です。上限がなければ、1時間続くループは同じ作業を手作業で行うより多くのトークンを消費します。その分の予算を確保してください。

1時間続くループは、同じ作業を手作業で行うより多くのトークンを消費します。その分の予算を確保してください。

ルール4. 方法だけでなく、何を求めるかを説明します。

決定性、不変条件、クリア可能性のプレイテストを条件に含め、ビジュアルには触れずに /goal でゲームをビルドしたところ、すべてのチェックに合格し、グラフィックのない動作するゲームができました。

条件にビジュアルを書かなければ、Claude は作成しません。条件が「テストに合格すること」だけなら、複雑なテストをコメントアウトするかもしれません。検証方法だけでなく、何を求めるかを説明してください。

ルール5. チャットで証拠を示すよう Claude に求めます。

評価モデルはコマンドを実行せず、Claude がすでに示した内容だけを読みます。条件で「npm test が成功する」と求めているのに、Claude がトランスクリプトに npm test の出力を表示しなければ、評価モデルはいつまでも「まだ」と言います。条件に「会話内に <command> の出力を表示する」という文言を加えてください。

よくあるタスク向けの5つの実用例：

1. API 移行：
/goal every call to getUser() has been replaced with fetchUser(), npm test passes, npm run build is green, no other API names have been touched, or stop after 30 turns

2. テストの修正：
/goal all failing tests in test/auth are now green (npm test shows 0 fails in the chat), without changing assertions or deleting tests, or stop after 20 turns

3. コード品質（ファイルサイズ）：
/goal src/legacy/UserService.ts has been split into files under 200 lines each, all imports are updated, npm run build is green, or stop after 25 turns

4. バックログの解消：
/goal process every issue labeled 'good-first-issue': read the description, implement a fix in a worktree branch, open a PR. Continue until the queue is empty or 6 issues have been processed

5. セキュリティ監査：
/goal every npm audit vulnerability with severity >= high is fixed, all existing tests pass, no breaking API changes, or stop after 15 turns

単に /goal を実行するだけでなく、自律モードがプロジェクトで本当に機能する環境を作りたいですか？/goal は最後のリンクにすぎません。その前に3つの柱が必要です。Skills と Subagents による AI クローン、第二の脳（CLAUDE.md と plans/ フォルダー）、そしてコンテキストエンジニアリング（Plan Mode と /compact）です。コンテキストを保ちながら作業するには、この3つを組み合わせて考える必要があります。

/goal が本当に役立つ5つの例#

Anthropic のドキュメントでは、/goal に適したタスクを4種類挙げています。

すぐに使える条件の例を5つ紹介します。自分のプロジェクトに合わせて調整してください。

例1. モジュールを新しい API に移行する。

シナリオ：REST から GraphQL に移行する、または古い getUser() 関数を新しい fetchUser() に置き換えるところです。作業は機械的ですが、30～50個のファイルに及びます。

条件：

/goal every getUser() in src/ has been replaced with fetchUser(), all calls updated to the new interface (id instead of userId), npm test passes, no files outside src/ touched, or stop after 30 turns

効果がある理由：grep -r getUser src/ | wc -l（結果は0になるはず）と npm test exits 0 で最終状態を確認できます。この制約により、テストファイルが守られます。

例2. 失敗テストを修正する。

シナリオ：ライブラリを更新した後、15件のテストが失敗しました。修正方法は機械的で、モックを更新し、新しい形式に合わせてアサーションを調整すればよいと分かっています。手作業ではやりたくありません。

条件：

/goal all failing tests in test/ are now green, npm test shows the results in the chat with 0 failures, without deleting tests or commenting out assertions, or stop after 25 turns

次の例を示します。

/auth ディレクトリの外にあるファイルを変更せずに、npm test が0件の失敗を返すまで、失敗しているテストをすべて修正する

例3. 巨大なクラスを分割する。

シナリオ：モデル、サービス、ユーティリティ、API クライアントがすべて1つの1,200行のファイルに入っています。「1ファイルに1つの責務」の原則に従って分割し、すべての import を更新して、テストに合格させたいと考えています。

条件：

/goal src/legacy/UserService.ts has been split into files under 200 lines, each file handles one responsibility (model, repository, api-client, validator), all imports are updated, npm run build is green, existing tests pass, or stop after 25 turns

例4. 夜間に課題バックログを解消する。

シナリオ：オープンソースリポジトリに good-first-issue ラベル付きの未解決課題が20件あります。Claude に夜間のうちに処理してほしいと考えています。

条件：

/goal process every issue labeled 'good-first-issue': read the description, implement a fix in a separate worktree branch worktree-issue-N, open a PR with a description. Continue until the queue is empty or 6 issues have been processed, or stop after 80 turns

数字の6は適当に選んだものではありません。Pro プランで一晩に処理する現実的な上限です。

例5. セキュリティ監査。

シナリオ：npm audit で深刻度が high の脆弱性が8件見つかりました。メジャーバージョンを更新せずに修正したいと考えています。

条件：

/goal every npm audit vulnerability with severity high+ is fixed, npm audit shows 0 high in the chat, all existing tests pass, no breaking API changes, no major version bumps to packages, or stop after 15 turns

/goal でやるべきではないこと：

Croucher はフィールドガイドで、「完了」が「見栄えがよい」「しっくりくる」「よく設計されている」「楽しい」を意味する作業に /goal を使わないという目安を強く主張しています。評価モデルはトランスクリプトだけを読み、ツールを実行せず、結果がどのように機能するかも評価できません。このルールに従うと、/goal が有用な成果を出さずにループする主観的なタスクの80%が対象外になります。

/goal が無駄に費用を使うとき：3つのアンチパターン#

アンチパターン1. 厳格なターン上限のない曖昧な条件。

最もよくある間違いは、「コードを改善する」「良くする」「最適化する」といった条件です。ターン上限がなければ、エージェントは利用枠を使い切るまで動き続けます。

Findskill は実際の事例を紹介しています。

曖昧な条件で14時間に200ドルというのは、Max プランの週ごとの上限全額に相当します。朝起きると、利用枠はなく、有用な成果もありません。

対策：すべての条件を or stop after N turns で終えます（簡単なタスクでは15、難しいタスクでは50、夜間実行では最大100）。

アンチパターン2. キャッシュが壊れた再帰ループ。

2026年5月22日、開発者がキャッシュ TTL の変更により一晩で6,000ドルを費やしたと伝えられています。その開発者は /goal を直接使っていませんでしたが、仕組みは同じでした。30分の cron タイマーで自律ループが動き、そのたびに80万トークンの履歴を最初から再構築していました。

根本の問題は、外部の自動化がプロバイダー側の内部変更を把握できなかったことです。監視なしで /goal を8時間動かした場合も同じことが起こり得ます。トークンの使用量は非線形に増え、プロンプトキャッシュは想定どおりに機能しないことがあります。

対策：

1. 途中で確認せずに /goal を8時間以上動かさない。
2. Settings → Usage で利用上限を有効にする（6,000ドルの事故後に追加された新しい対策です）。
3. 夜間に claude agents を2回開く。Space で内容を確認し、ターン数が想定以上の速さで増えていないか確認します。
4. 高価なモデルの連鎖（Opus 4.7）では、ターン上限をさらに厳しくし、最大30に設定します。

アンチパターン3. /goal による創造的な作業。

Croucher は /goal を使ってゲームを作りました。条件には決定性、不変条件、レベルをクリアできるかどうかの確認が含まれていました。ゲームは完成し、テストに合格し、評価モデルは「達成」と判断しました。しかし、ゲームにはビジュアルがありませんでした。条件にグラフィックが含まれていなかったためです。

これは一般的なルールを示しています。評価モデルは測定対象をそのまま最適化します。条件にビジュアルがなければ、ビジュアルはありません。テストしか指定しなければ、アサーションをコメントアウトするかもしれません。

対策：デザイン、コピー、UX など、好みに左右される作業に /goal を使わないでください。通常のセッションか Plan Mode に戻りましょう。どちらなら判断に関わり続けられます。

Agent View とは？ダッシュボードの開き方#

/goal が「終わるまで作業する」コマンドなら、Agent View はそのすべてのコマンドを一度に確認できるコントロールルームです。Anthropic は次のように説明しています。

開くコマンド：

claude agents

TUI（ターミナル内のテキストダッシュボード）が開きます。左側にセッション一覧、右側に選択した行の最新メッセージを表示する peek ペインがあります。

6つのセッション状態：

主なショートカット：

↑ / ↓             セッション一覧を移動
Space             peek ペイン（接続せずに表示）
Enter / →         セッションに接続（セッションに入る）
←                 detach（終了せずに離れる）
Ctrl+T            pin（自動停止からセッションを保護）
Ctrl+X            セッションを停止。2秒以内にもう一度押すと削除
Ctrl+R            名前を変更
Ctrl+S            グループ表示を切り替え（状態 ↔ ディレクトリ）

バックグラウンドセッションの起動方法：

対話型の Claude Code から：

/bg fix the failing test test/auth/login.test.ts

またはシェルから直接：

claude --bg "fix the failing test test/auth/login.test.ts"

名前を付けて起動する場合（Agent View に識別しやすいラベルで表示されます）：

claude --bg --name "flaky-test-fix" "fix test/auth/login.test.ts"

バックグラウンドセッションは Agent View に自動で追加されます。--bg で起動し、claude agents を開くと、一覧に表示されます。

主な機能：ノートパソコンがスリープしたり、ウィンドウを閉じたりしてもセッションが維持されます。

ただし、ノートパソコンをシャットダウンしたり手動で再起動したりすると、バックグラウンドセッションは Failed で終了します。夜間の多数のバックグラウンドエージェント実行は、電源を切らないノートパソコンでのみ可能です。

worktree：Claude が並行セッションを分離する方法#

worktree は、自律的な並行作業における主な問題を解決します。同時に2つのセッションが src/auth.ts を編集しようとしたらどうなるでしょうか。2.1.139 より前は、セッション同士が実際に互いの変更を上書きすることがありました。Agent View とともに、Anthropic は自動分離を導入しました。

実際の動作：

# Launched three background sessions:
claude --bg --name "fix-tests" "fix the failing tests in test/"
claude --bg --name "add-oauth" "add Google OAuth according to the plan in plans/oauth.md"
claude --bg --name "split-userservice" "split UserService.ts into modules"

# File structure after launch:
.claude/worktrees/
├── fix-tests/             # separate repo copy on branch worktree-fix-tests
├── add-oauth/             # separate copy on branch worktree-add-oauth
└── split-userservice/     # separate copy on branch worktree-split-userservice

各セッションは独自のコピーで作業します。タスクが完了したら、必要なブランチを main にマージします。

危険な落とし穴――セッションを削除すると、その worktree も削除されます。

Agent View でセッションを終了（Ctrl+X を2回押す）すると、worktree は消えます。コミットされていない変更はすべて失われます。Agent View でセッションを削除する前に、必ずコミットまたはプッシュしてください。

オプトアウト（まれなケース向け）：

たとえばシンボリックリンクを含む構成や、チェックアウトに時間のかかる大規模モノレポなど、git worktree が使えないリポジトリでは、分離を無効にできます。

// .claude/settings.json
{
  "worktree": {
    "bgIsolation": "none"
  }
}

その場合、バックグラウンドセッションは作業コピーを直接編集します。このオプトアウト機能は、大規模モノレポを扱うチームからの要望を受け、2.1.143 で追加されました。

並行実行は利用枠を消費します。

つまり、Pro プラン（月額20ドル）で一晩に並行実行できるのは1～2セッションで、10セッションではありません。多くのエージェントを並行して実行するには、Max または Enterprise が必要です。

/goal と Plan Mode、subagents を組み合わせて長いタスクに取り組む#

よくある失敗は、いきなり /goal build a new feature と入力することです。評価モデルは「完成した機能」がどのような状態なのか分からないため、うまくいきません。評価モデルが1つずつ確認できるチェックボックス付きの計画が必要です。

レイヤー1. Plan Mode で段階的な計画を作る。

Plan Mode で、検証可能なチェックボックスを含む5～7段階の詳細な変更計画を作るよう Claude に依頼します。plans/2026-05-24-google-oauth.md として保存します。各段階には、具体的な作業を示すチェックボックスを3～7個含めます。

レイヤー2. subagents が段階ごとに作業を分担する。

計画を並列化できる場合（たとえば、バックエンドのエンドポイント、フロントエンドのフォーム、DB 移行など、各段階が独立している場合）、claude --bg --name "<phase>" を使って各段階を別のバックグラウンドセッションで開始できます。それぞれに専用の worktree が割り当てられます。

レイヤー3. /goal がチェックボックス完了までサイクルを実行する。

/goal all phases 1–7 in plans/2026-05-24-google-oauth.md are complete and marked [x], all tests in test/auth pass (npm test shows 0 failures), npm run build is green, or stop after 50 turns

各ターンの後に評価モデルが計画を読み、どのチェックボックスにチェックが付いたかを確認します。未完了のものがあれば、エージェントは作業を続けます。

この組み合わせは3つの要素に支えられています。

• コンテキストエンジニアリング：plans/ に置く適切なコンテキストを評価モデルが読みます
• 第二の脳：plans/ フォルダーに計画を保存し、セッション間で共有します
• AI クローン：CLAUDE.md がエージェントの従うルールを定めます

CLAUDE.md がなければ、/goal はアーキテクチャを壊す解決策を提案するかもしれません。plans/ に計画がなければ、評価モデルには成功基準が分かりません。subagents がなければ、並行して進める段階がなく、すべてが逐次処理になります。

/goalをCodex、Cursorなどのモードと比べるには#

/goalは各ターン後に別の完了チェックを加えます。他製品にも異なるモードがあり、ローカルCLI、ホストされたクラウドタスク、人が操作するエディターは同じ比較単位ではありません。すべてのCodex CLIをクラウドコンテナと呼んだり、全実行に同じ評価モデルや請求方法を仮定したりしないでください。

同じリポジトリ状態、タスク、合格条件で、次を記録します。

一定倍のトークンを使うという主張には、同じ成功結果に対する条件と計測数が必要です。ベンチマーク率にも版、モデル、ハーネス、実行設定が必要で、そうした条件がないTerminal-Benchの割合だけでは代用できません。この記事に独立したツール横断ベンチマークはありません。

人が確認する編集、範囲を絞ったバックグラウンド作業、明確な完了条件のある複数ターンなど、必要な流れで選びます。他製品全体に自律動作がないと決めず、導入した製品の対応モードを試してください。ツールの承認とタスクの継続も別です。呼び出しの自動承認だけでは、利用者の目的を達成した証明にはなりません。

/goal と /loop：

/loop は同じリリースに含まれるもうひとつのコマンドで、一定の時間間隔（N分ごと）で定期タスクを起動します。/goal は条件に基づき、その条件が満たされるまで実行します。cron のようなタスクには /loop を、明確な目標の達成には /goal を使います。

Anthropic のドキュメントより：

/goal 実行前のチェックリスト：7項目#

/goal を実行する前に、毎回次のチェックリストを確認してください。

1. Claude Code のバージョンが2.1.139以降である—claude --version で確認し、古ければ更新します。推奨される最低バージョンは、stop hook のループが修正された 2.1.143（2026年5月15日）です。

2. 条件に検証可能な最終状態が含まれている—「改善する」ではなく npm test exits 0 と指定します。結果を検証する bash コマンドを考えられないなら、このタスクに /goal は適しません。

3. 厳格なターン上限がある—すべての条件で or stop after N turns を指定します。簡単なタスクでは15、難しいタスクでは50、夜間実行では最大100にします。

4. 制約の範囲が明示され、狭い—without modifying files outside /auth、without removing existing assertions、without bumping major versions と指定します。そうしないと、Claude がテストそのものを削除して修正するかもしれません。

5. 重要な変更をすべてコミットまたはプッシュしている—worktree で作業していない場合（たとえば worktree.bgIsolation: "none"）、Claude は作業コピーを編集します。誤りがあれば、保存していない作業を失うおそれがあります。

6. Settings → Usage で利用上限が有効になっている—6,000ドルの事故後に追加された新しい対策です。1日、1セッション、1か月ごとの上限を設定します。

7. Agent View claude agents を別ウィンドウで開いている—長いタスクでは、1時間に1回 Space で内容を確認します。ターン数が予想以上の速さで増えたり、評価モデルが3ターン連続で同じ理由を繰り返したりしたら、Ctrl+C を押して条件を書き直します。

追加の項目がひとつあります。他人のコードや不慣れなコードで /goal と --dangerously-skip-permissions を決して併用しないでください。この組み合わせはすべてのチェックを無効にし、エージェントがプロジェクト内で好きなことをできるようにします。この分析の著者は、失うもののない新しい worktree でのみこれを使っています。

/goal は強力な機能ですが、魔法ではありません。条件をどれだけ適切に定義できるかに応じて、機能します。「完了」をコマンドで検証できる言葉で表せるなら、後は /goal が実行します。できない場合は、通常のセッションか Plan Mode に戻りましょう。

Ailoot の記事をさらに読むには、ailoot.aiをご覧ください。