Claude Code の /goal コマンドで AI を自走させる——完了条件を1行書いて放置する新しい開発スタイル

Last updated at 2026-05-30Posted at 2026-05-30

この記事の要点（2026-05-25 執筆時点）: Claude Code v2.1.139（2026年5月リリース）で追加された /goal コマンドは、完了条件を1行書くだけで AI が条件達成まで自律継続する仕組みだ。本記事では「完了条件の書き方」という実践スキルにフォーカスし、良い条件・悪い条件の対比と、マネジメント型ユーザーが「指示を出す人」から「仕事を設計する人」へシフトする視点を整理する。なお、/goal コマンドは安定機能として提供されているが、後述の Agent View（claude agents）は研究プレビュー（Research Preview）段階であり不安定さが残る。

「続けて」を何度タイプしたか、覚えていない。

テストが通るまでデバッグしてほしいとき、Claude Code に指示を出しても1ターン分しか動かない。「続けて」。また止まる。「続けて」。またエラー。この繰り返しに、昔のバッチジョブ監視と同じ疲労感を覚えた人は少なくないと思う。

Claude Code v2.1.139（2026年5月リリース、出典: Claude Code 公式ドキュメント）で登場した /goal コマンドは、この「続けて」の連打から解放してくれる。完了条件を1行書いたら、あとは Claude が自走する。

/goal とは何か——仕組みを30秒で理解する

/goal の仕組みはシンプルだ。

/goal [完了条件]

このコマンドを入力すると、Claude はその条件を「判定基準」として持ちながら作業を続ける。各ターンの終わりに、別の小型モデル（デフォルトは Haiku）が「条件を満たしたか」を判定する。「まだ」と判定されれば次のターンへ自動的に進む。「達成」と判定された瞬間に止まる。

図にするとこうなる。

ユーザーが /goal [条件] を入力
    ↓
Claude が作業を実行（1ターン）
    ↓
Haiku が条件達成を判定
    ├─ 未達成 → 次のターンへ（自動）
    └─ 達成 → ゴールをクリアして終了

ユーザーが何もしなくても、このループが回り続ける。

コスト感覚: 判定を担う Haiku は軽量モデルなので、判定コスト自体は主要ターンに比べて無視できるレベルだ（出典: 公式ドキュメント）。ただし自律継続によってターン数が増えると、主要ターンの消費は当然増える。「放置すれば終わる」の裏に「放置した分だけ消費する」があることは忘れないようにしたい。

完了条件の書き方が「仕事の設計スキル」になる

/goal を使いこなす核心は、完了条件をどう書くか にある。

これは単なるプロンプトテクニックではない。「Claude に何をどこまでやらせるか」を言語化する行為そのものだ。SE としてチームメンバーへ仕事を割り振るとき、「完了の定義が曖昧な指示はゴールまで届かない」と何度も経験してきた。/goal はその感覚をそのまま AI との仕事設計に持ち込んでいる。

良い条件：機械的に判定できるもの

Haiku は「会話に現れたテキスト」から判定を行う。ファイルを独立して読みに行ったりコマンドを独自実行したりはしない。だから、Claude 自身が作業結果をアウトプットとして会話に出せる形で条件を書く必要がある。

良い例:

/goal npm test の終了コードが 0 になること

/goal git status がクリーンで、lintエラーの件数がゼロであること

/goal README に「インストール方法」「使い方」「ライセンス」の3セクションが書かれ、コードブロックが1つ以上含まれていること

これらは Claude がテストを実行し結果を会話に出す → Haiku がそれを読んで「0だ、達成」と判定できる、というフローが成立する。

条件の要素を整理するとこうなる（出典: Claude Code 公式ドキュメントをもとに筆者整理）:

要素	説明	例
測定可能な終端状態	数値・件数・存在有無で確認できる	テスト合格件数、エラー件数ゼロ
確認手段	Claude がどう証明すべきか	`npm test` が 0 で終了する
制約	変えてはいけないものを明記	他のテストファイルは変更しない
打ち切り句（任意）	無限ループ防止	または 20ターンで停止

悪い条件：主観・曖昧・判定不能なもの

悪い例:

/goal テストをきれいにしてください

/goal コードが良い状態になること

/goal ファイルが完成すること

「きれい」「良い状態」「完成」は Haiku には判定できない。どのタイミングで達成と宣言すればいいかわからないまま、Claude が止まれずにループし続けるか、途中で誤判定して早期終了するかのどちらかになる。

曖昧な条件のリスクは予算超過だ。止まれない Claude はターンを重ね続け、気づいたら想定外のトークンを消費している。打ち切り句（or stop after 20 turns）を付けておくのはコスト管理としても理にかなっている。

「指示を出す人」から「仕事を設計する人」へ

ここからは SE 視点の話になる。技術手順よりもマネジメント寄りの話なので、「実装例だけでいい」という方は次章に飛んでもらっても構わない。

少しだけ技術の話を離れて、SE としての実感を書かせてほしい。

SE歴26年のキャリアで、マネジメントに軸足が移ってから強く意識したことがある。優秀な担当者ほど、曖昧な指示では動かない、ということだ。「よしなにやっておいて」が通じるのは、担当者との間に長い文脈の積み重ねがあるときだけだ。

Claude Code の /goal も同じだ。「よしなに」は通じない。何をもって完了とするかを、自分の言葉で定義する必要がある。

これは制約ではなく、スキルアップの機会だと考えている。

「テストが通るまで直して」と口頭で伝えるとき、SE 的なアタマの中には「どのテストスイートを、どんな状態にするか」というイメージがあるはずだ。/goal はそのイメージを言語化する訓練になる。書いてみて「この条件、自分でも曖昧だな」と気づく経験が、仕事設計の解像度を上げる。

Agent View との組み合わせで「複数タスクの並列管理」へ

同じ v2.1.139 で追加された claude agents（研究プレビュー）を使うと、複数のセッションを一覧で監視する Agent View が使えるようになる（出典: 公式ドキュメント）。

/goal と Agent View の組み合わせで現実的になるシーンがある。

シーン例: 朝に仕込んで夕方確認

朝のセッションAで「テストが全件グリーンになること」を /goal で設定
別のセッションBで「ドキュメントの誤字チェックとREADME更新」を /goal で設定
Agent View で両セッションの状態を見ながら、他の仕事をする
夕方、両方のセッションが完了しているか確認

これは「命令を出す人」ではなく、「複数の仕事が並行して進む状態を管理する人」の働き方だ。プロジェクトマネジャーが複数の担当者のタスクを並走させるのと構造が似ている。

ただし現時点（2026-05-25）の注意点として、claude agents（Agent View）は 研究プレビュー（Research Preview） 段階にある（出典: 公式ドキュメント）。/goal コマンド自体は安定機能だが、それを束ねて見る Agent View が不安定なため、「完全放置で朝確認すれば終わっている」という段階にはまだない。「止まっていたら手動で再開する」ハーフオート運用が現実的だと考えている（筆者の現時点判断）。

エージェントが並列で自律的に動く設計をもう一歩進めた事例として、自己改善するマルチエージェント組織の作り方も参考になる。

要件：/goal が動かない環境に注意

/goal には前提条件がある。

Claude Code v2.1.139 以降が必要（出典: 公式ドキュメント）
フックシステムが有効な環境のみ動作する: disableAllHooks が設定されている、または allowManagedHooksOnly が管理設定で設定されている場合、/goal は利用できない（出典: 公式ドキュメント）
/goal は /loop とは別物: /loop は時間間隔で繰り返す定期実行型、/goal は条件達成で終了する完了駆動型（出典: 公式ドキュメント）