関連するコマンドの全体像を先に押さえるなら、以下の記事で詳しく紹介している。
Claude Codeの /goal で変わる作業感
/goal の本質は、会話を増やすことではなく、会話を減らしても作業を前に進められる点にある。たとえば「このバグを直して」で終わらず、「再現、修正、テスト通過、変更点の要約まで」を条件に入れると、Claude Code は途中で何度も確認を挟まず、終点へ向かって走りやすくなる。
Claude Code は Anthropic の公式ドキュメントでも、開発作業に入り込むターミナル型のコーディング支援として案内されている。まずは Claude Code 公式ドキュメント と Claude Code の概要 を見ておくと、/goal が単独の裏技ではなく、作業フロー全体の中で使われる機能だとわかる。
編集部として重要だと見ているのは、/goal は命令を強くする機能ではなく、作業を整理する機能だという点である。AIに強い言葉を投げるより、終わり方を設計したほうが安定する。地味に聞こえるが、実務ではこの地味さがいちばん効く。
| 項目 | 役割 | 向いている場面 | 見落としやすい点 |
|---|---|---|---|
| /goal | 完了条件を設定して到達まで進める | 修正、整形、検証、要約の反復 | 条件が曖昧だと迷走しやすい |
| /loop | 処理を繰り返して改善を重ねる | 微修正を何度も回したいとき | 回数が増えるほどコストも増える |
| Stop hook | 途中で人間の判断を入れる | 承認や確認が必要な工程 | 止めどころを決めないと中断が多い |
| 自動モード | 実行を自動化しやすくする土台 | 定型作業の連続実行 | 自由度より統制を優先する設計 |
| claude -p | 非対話モードで一括実行する | バッチ処理、CI、定期タスク | 入力の精度がそのまま結果に響く |
効果的な条件の書き方
良い /goal には、成果物・品質・終了条件の3点が入っている。この3つが揃うと、AIは「だいたいできた」で止まりにくくなる。逆に、どれかが抜けると、便利なはずの機能がふわっと漂い始める。
まず成果物は、何を出すのかを名詞で言い切ることだ。README の更新案、テスト失敗の原因整理、関数のリファクタリングなど、対象をはっきりさせる。次に品質は、どの状態なら合格かを決める。最後に終了条件は、何がそろえば終わりなのかを書く。ここが曖昧だと、AIは善意で働き続ける。少し働き者すぎるのが困りものだ。
実際に試してわかったのは、条件は長文で盛るより、短く分けたほうが安定することだ。たとえば「ログイン画面の500エラーを再現し、原因を特定し、修正し、関連テストが通るまで進める」のように、順番が見える書き方のほうが迷いが少ない。
もうひとつ見落としがちなのは、完了条件と禁止条件を分けることだ。完了条件だけだと、AIは余計な変更までしてしまうことがある。たとえば「UI を変えない」「既存 API は触らない」「テストは最小差分で通す」といった制約を添えると、枝葉の暴走を抑えやすい。
非対話で走らせるなら、さらに具体性が要る。対象ディレクトリ、変更範囲、出力形式、失敗時の扱いまで書いておくと、あとで「そんなつもりじゃなかった」が減る。AI運用の基本は、自由度を増やすことではなく、曖昧さを減らすことである。
| 書き方 | 例 | 評価 |
|---|---|---|
| 曖昧 | いい感じに整えて | 裁量が広すぎてぶれやすい |
| やや良い | テストが通るように修正して | 目的は伝わるが範囲が広い |
| 良い | 再現手順を確認し、修正し、関連テストが通るまで進めて | 完了条件が明確で安定しやすい |
| かなり良い | 再現手順の特定、修正、テスト結果の要約まで行い、失敗が残らない状態で終了して | 実務で再利用しやすい |
/loop・Stop hook・自動モードの使い分け
違いを一言で言うと、/goal は終点、/loop は反復、Stop hook は介入点である。ここを混ぜると、便利なはずの機能が一気に「全部入り定食」になる。腹は満たされるが、どれが効いたのか分からない、あの感じだ。
/goal は最終到達点を決める機能で、/loop は同じ改善を重ねる機能として見ると理解しやすい。Stop hook は、その途中に人間が目を入れるための安全弁だ。自動モードは、これらを走らせる下地として考えると整理しやすい。大事なのは道具名より、どこで止めるかを決めることである。
比較すると、/goal はカーナビに目的地を入れる操作に近い。/loop は同じルートを回り直して改善する動きで、Stop hook は「ここで一回降りて確認する」にあたる。比喩としては少し大げさだが、役割の差はかなり掴みやすい。
/loop だけで押し切ると、改善は増えても品質が上がるとは限らない。逆に /goal だけだと、途中の前提がズレたまま終点まで行くこともある。だから、反復と停止の位置を分けて設計するのが肝である。AIは万能ロボではない。文脈を与えられて初めて、それらしく動く。
実務では、こんな使い分けがわかりやすい。仕様がほぼ決まっている修正は /goal、細かい改善を何回も試したいときは /loop、レビューや承認が必要なら Stop hook、夜間に定型処理を回すなら自動モード、という順番だ。道具を増やすより、線引きを明確にするほうが速い。
Claude Code の自動化設計は、ChatGPT や Gemini の一般的なチャット運用とは少し違う。会話の巧さより、手順の再現性が重要になる。比較の視点を広げたい場合は、以下の記事で実務向けの違いを整理している。
実際に試してわかった使いどころ
実際に試してみると、/goal は「小さな作業を連続させる」より「終わりが見えている反復」に強い。編集部では、README 更新、軽微なコード修正、テスト失敗の切り分けを想定し、条件を変えながら挙動を見た。
README 更新では、「導入手順を最新化し、古いコマンド表記を修正し、変更点を要約する」と入れると流れがかなり安定した。途中の確認が減り、最後までの道筋が見えやすい。ここで効くのは速度より、迷いの少なさである。
次にコード修正では、1ファイルだけを対象にして試すと結果が読みやすかった。対象を広げるほど便利には見えるが、実際は判断点が増える。最初の一手は小さく、成功したら広げるのが安全だ。これは人間の仕事でもだいたい同じで、AIだけ急に無鉄砲になるわけではない。
一方で、設計判断が多いタスクは /goal だけでは少し危うい。前提の確認や実装範囲の見直しが必要な場面では、途中で Stop hook 的に人が入るほうが安全だ。AIに任せるときは、ボールを握らせっぱなしにせず、要所で受け取る感覚がちょうどいい。
使ってわかった副産物もある。ゴールを先に書くと、自分の指示も整理されるのだ。これは地味だが侮れない。人間側の依頼が整うと、AIの返答も整う。AIツールは魔法ではなく、やはり入力に引っ張られる。煙は出ないが、結果はちゃんと変わる。
編集部の判断としては、/goal の価値は「作業の高速化」より「作業の再現性」にある。速いだけなら場当たりでもできる。しかし、同じ品質で繰り返せるかは別問題だ。実務では後者のほうが重い。
非対話モードでの実行例
claude -p のような非対話モードでは、/goal の意味がさらにはっきりする。対話しながら迷うのではなく、条件を固定して一気に進めるため、夜間処理や定型タスクと相性がよい。公式の CLI ガイドは Claude Code の CLI 利用ガイド を確認しておきたい。
実行のイメージはシンプルだ。対象ファイルや作業内容を渡し、完了条件を指定し、出力形式を決める。たとえば「このディレクトリのテスト失敗箇所を洗い出し、必要最小限の修正を加え、結果を短くまとめる」といった依頼である。対話を減らしたぶん、入力の精度がそのまま品質に返ってくる。
ここでの注意点は3つある。第一に、対象範囲を狭めること。第二に、出力形式を決めること。第三に、異常時の扱いをあらかじめ書くことだ。非対話モードは便利だが、雑に投げると雑に返る。AIも深夜勤務には弱い、というより、深夜勤務に見合う指示が必要だと考えたほうがよい。
キャンセルしたいときは /goal clear を使う。やり直しや目的変更が入りやすい開発では、この解除手段があるだけで運用の気楽さが違う。固定化しすぎた自動化は、便利なはずなのに足かせになる。だから、終わらせ方まで設計して初めて実務向きになる。
公式情報の入口としては、Claude Code 公式ドキュメント、概要ページ、CLI 利用ガイド の3本を押さえておくと、機能の位置づけを見失いにくい。
導入前に押さえる注意点
/goal は便利だが、放っておけばうまくいく類の機能ではない。むしろ、条件設計と安全策が弱いと、ただ長く動く“元気な迷子”になりやすい。そこで、導入前に確認したい点を整理しておく。
- 変更してよい範囲を先に決める。
- 完了条件と禁止条件を分けて書く。
- テストや出力確認の基準を明示する。
- 途中停止の基準を Stop hook で用意する。
- /goal clear で戻せる前提を持つ。
この5点を先に入れておくと、/goal はぐっと扱いやすくなる。特にチーム利用では、個人の勘に頼らず、誰が見ても同じ意味で読める条件文にしておきたい。AIの自動実行は、ロマンより運用で勝つ世界だ。
なお、Claude Code の周辺機能をあわせて整理したいなら、スラッシュコマンド全体の役割を見直すのが早い。以下の記事で詳しく紹介している。
この記事のポイント
- /goal は完了条件を先に決める機能で、対話の回数を減らしやすい。
- 条件は成果物・品質・終了条件・禁止条件の4点で書くと安定しやすい。
- /loop・Stop hook・自動モードは役割が違うので、反復と介入の位置を分けて考える。
- 非対話モード（claude -p）は定型作業と相性がよく、入力の精度が品質を左右する。
- /goal clear の解除手段まで含めて運用すると、実務で使いやすくなる。
参考情報（主要ソース）
Claude Code の自動化設計は、ChatGPT や Gemini の一般的なチャット運用とは少し違う。会話の巧さより、手順の再現性が重要になる。比較の視点を広げたい場合は、以下の記事で実務向けの違いを整理している。
実際に試してわかった使いどころ
実際に試してみると、/goal は「小さな作業を連続させる」より「終わりが見えている反復」に強い。編集部では、README 更新、軽微なコード修正、テスト失敗の切り分けを想定し、条件を変えながら挙動を見た。
README 更新では、「導入手順を最新化し、古いコマンド表記を修正し、変更点を要約する」と入れると流れがかなり安定した。途中の確認が減り、最後までの道筋が見えやすい。ここで効くのは速度より、迷いの少なさである。
次にコード修正では、1ファイルだけを対象にして試すと結果が読みやすかった。対象を広げるほど便利には見えるが、実際は判断点が増える。最初の一手は小さく、成功したら広げるのが安全だ。これは人間の仕事でもだいたい同じで、AIだけ急に無鉄砲になるわけではない。
一方で、設計判断が多いタスクは /goal だけでは少し危うい。前提の確認や実装範囲の見直しが必要な場面では、途中で Stop hook 的に人が入るほうが安全だ。AIに任せるときは、ボールを握らせっぱなしにせず、要所で受け取る感覚がちょうどいい。
使ってわかった副産物もある。ゴールを先に書くと、自分の指示も整理されるのだ。これは地味だが侮れない。人間側の依頼が整うと、AIの返答も整う。AIツールは魔法ではなく、やはり入力に引っ張られる。煙は出ないが、結果はちゃんと変わる。
編集部の判断としては、/goal の価値は「作業の高速化」より「作業の再現性」にある。速いだけなら場当たりでもできる。しかし、同じ品質で繰り返せるかは別問題だ。実務では後者のほうが重い。
非対話モードでの実行例
claude -p のような非対話モードでは、/goal の意味がさらにはっきりする。対話しながら迷うのではなく、条件を固定して一気に進めるため、夜間処理や定型タスクと相性がよい。公式の CLI ガイドは Claude Code の CLI 利用ガイド を確認しておきたい。
実行のイメージはシンプルだ。対象ファイルや作業内容を渡し、完了条件を指定し、出力形式を決める。たとえば「このディレクトリのテスト失敗箇所を洗い出し、必要最小限の修正を加え、結果を短くまとめる」といった依頼である。対話を減らしたぶん、入力の精度がそのまま品質に返ってくる。
ここでの注意点は3つある。第一に、対象範囲を狭めること。第二に、出力形式を決めること。第三に、異常時の扱いをあらかじめ書くことだ。非対話モードは便利だが、雑に投げると雑に返る。AIも深夜勤務には弱い、というより、深夜勤務に見合う指示が必要だと考えたほうがよい。
キャンセルしたいときは /goal clear を使う。やり直しや目的変更が入りやすい開発では、この解除手段があるだけで運用の気楽さが違う。固定化しすぎた自動化は、便利なはずなのに足かせになる。だから、終わらせ方まで設計して初めて実務向きになる。
公式情報の入口としては、Claude Code 公式ドキュメント、概要ページ、CLI 利用ガイド の3本を押さえておくと、機能の位置づけを見失いにくい。
導入前に押さえる注意点
/goal は便利だが、放っておけばうまくいく類の機能ではない。むしろ、条件設計と安全策が弱いと、ただ長く動く“元気な迷子”になりやすい。そこで、導入前に確認したい点を整理しておく。
- 変更してよい範囲を先に決める。
- 完了条件と禁止条件を分けて書く。
- テストや出力確認の基準を明示する。
- 途中停止の基準を Stop hook で用意する。
- /goal clear で戻せる前提を持つ。
この5点を先に入れておくと、/goal はぐっと扱いやすくなる。特にチーム利用では、個人の勘に頼らず、誰が見ても同じ意味で読める条件文にしておきたい。AIの自動実行は、ロマンより運用で勝つ世界だ。
なお、Claude Code の周辺機能をあわせて整理したいなら、スラッシュコマンド全体の役割を見直すのが早い。以下の記事で詳しく紹介している。
この記事のポイント
- /goal は完了条件を先に決める機能で、対話の回数を減らしやすい。
- 条件は成果物・品質・終了条件・禁止条件の4点で書くと安定しやすい。
- /loop・Stop hook・自動モードは役割が違うので、反復と介入の位置を分けて考える。
- 非対話モード（claude -p）は定型作業と相性がよく、入力の精度が品質を左右する。
- /goal clear の解除手段まで含めて運用すると、実務で使いやすくなる。
参考情報（主要ソース）
関連するコマンドの全体像を先に押さえるなら、以下の記事で詳しく紹介している。
Claude Codeの /goal で変わる作業感
/goal の本質は、会話を増やすことではなく、会話を減らしても作業を前に進められる点にある。たとえば「このバグを直して」で終わらず、「再現、修正、テスト通過、変更点の要約まで」を条件に入れると、Claude Code は途中で何度も確認を挟まず、終点へ向かって走りやすくなる。
Claude Code は Anthropic の公式ドキュメントでも、開発作業に入り込むターミナル型のコーディング支援として案内されている。まずは Claude Code 公式ドキュメント と Claude Code の概要 を見ておくと、/goal が単独の裏技ではなく、作業フロー全体の中で使われる機能だとわかる。
編集部として重要だと見ているのは、/goal は命令を強くする機能ではなく、作業を整理する機能だという点である。AIに強い言葉を投げるより、終わり方を設計したほうが安定する。地味に聞こえるが、実務ではこの地味さがいちばん効く。
| 項目 | 役割 | 向いている場面 | 見落としやすい点 |
|---|---|---|---|
| /goal | 完了条件を設定して到達まで進める | 修正、整形、検証、要約の反復 | 条件が曖昧だと迷走しやすい |
| /loop | 処理を繰り返して改善を重ねる | 微修正を何度も回したいとき | 回数が増えるほどコストも増える |
| Stop hook | 途中で人間の判断を入れる | 承認や確認が必要な工程 | 止めどころを決めないと中断が多い |
| 自動モード | 実行を自動化しやすくする土台 | 定型作業の連続実行 | 自由度より統制を優先する設計 |
| claude -p | 非対話モードで一括実行する | バッチ処理、CI、定期タスク | 入力の精度がそのまま結果に響く |
効果的な条件の書き方
良い /goal には、成果物・品質・終了条件の3点が入っている。この3つが揃うと、AIは「だいたいできた」で止まりにくくなる。逆に、どれかが抜けると、便利なはずの機能がふわっと漂い始める。
まず成果物は、何を出すのかを名詞で言い切ることだ。README の更新案、テスト失敗の原因整理、関数のリファクタリングなど、対象をはっきりさせる。次に品質は、どの状態なら合格かを決める。最後に終了条件は、何がそろえば終わりなのかを書く。ここが曖昧だと、AIは善意で働き続ける。少し働き者すぎるのが困りものだ。
実際に試してわかったのは、条件は長文で盛るより、短く分けたほうが安定することだ。たとえば「ログイン画面の500エラーを再現し、原因を特定し、修正し、関連テストが通るまで進める」のように、順番が見える書き方のほうが迷いが少ない。
もうひとつ見落としがちなのは、完了条件と禁止条件を分けることだ。完了条件だけだと、AIは余計な変更までしてしまうことがある。たとえば「UI を変えない」「既存 API は触らない」「テストは最小差分で通す」といった制約を添えると、枝葉の暴走を抑えやすい。
非対話で走らせるなら、さらに具体性が要る。対象ディレクトリ、変更範囲、出力形式、失敗時の扱いまで書いておくと、あとで「そんなつもりじゃなかった」が減る。AI運用の基本は、自由度を増やすことではなく、曖昧さを減らすことである。
| 書き方 | 例 | 評価 |
|---|---|---|
| 曖昧 | いい感じに整えて | 裁量が広すぎてぶれやすい |
| やや良い | テストが通るように修正して | 目的は伝わるが範囲が広い |
| 良い | 再現手順を確認し、修正し、関連テストが通るまで進めて | 完了条件が明確で安定しやすい |
| かなり良い | 再現手順の特定、修正、テスト結果の要約まで行い、失敗が残らない状態で終了して | 実務で再利用しやすい |
/loop・Stop hook・自動モードの使い分け
違いを一言で言うと、/goal は終点、/loop は反復、Stop hook は介入点である。ここを混ぜると、便利なはずの機能が一気に「全部入り定食」になる。腹は満たされるが、どれが効いたのか分からない、あの感じだ。
/goal は最終到達点を決める機能で、/loop は同じ改善を重ねる機能として見ると理解しやすい。Stop hook は、その途中に人間が目を入れるための安全弁だ。自動モードは、これらを走らせる下地として考えると整理しやすい。大事なのは道具名より、どこで止めるかを決めることである。
比較すると、/goal はカーナビに目的地を入れる操作に近い。/loop は同じルートを回り直して改善する動きで、Stop hook は「ここで一回降りて確認する」にあたる。比喩としては少し大げさだが、役割の差はかなり掴みやすい。
/loop だけで押し切ると、改善は増えても品質が上がるとは限らない。逆に /goal だけだと、途中の前提がズレたまま終点まで行くこともある。だから、反復と停止の位置を分けて設計するのが肝である。AIは万能ロボではない。文脈を与えられて初めて、それらしく動く。
実務では、こんな使い分けがわかりやすい。仕様がほぼ決まっている修正は /goal、細かい改善を何回も試したいときは /loop、レビューや承認が必要なら Stop hook、夜間に定型処理を回すなら自動モード、という順番だ。道具を増やすより、線引きを明確にするほうが速い。
Claude Code の自動化設計は、ChatGPT や Gemini の一般的なチャット運用とは少し違う。会話の巧さより、手順の再現性が重要になる。比較の視点を広げたい場合は、以下の記事で実務向けの違いを整理している。
実際に試してわかった使いどころ
実際に試してみると、/goal は「小さな作業を連続させる」より「終わりが見えている反復」に強い。編集部では、README 更新、軽微なコード修正、テスト失敗の切り分けを想定し、条件を変えながら挙動を見た。
README 更新では、「導入手順を最新化し、古いコマンド表記を修正し、変更点を要約する」と入れると流れがかなり安定した。途中の確認が減り、最後までの道筋が見えやすい。ここで効くのは速度より、迷いの少なさである。
次にコード修正では、1ファイルだけを対象にして試すと結果が読みやすかった。対象を広げるほど便利には見えるが、実際は判断点が増える。最初の一手は小さく、成功したら広げるのが安全だ。これは人間の仕事でもだいたい同じで、AIだけ急に無鉄砲になるわけではない。
一方で、設計判断が多いタスクは /goal だけでは少し危うい。前提の確認や実装範囲の見直しが必要な場面では、途中で Stop hook 的に人が入るほうが安全だ。AIに任せるときは、ボールを握らせっぱなしにせず、要所で受け取る感覚がちょうどいい。
使ってわかった副産物もある。ゴールを先に書くと、自分の指示も整理されるのだ。これは地味だが侮れない。人間側の依頼が整うと、AIの返答も整う。AIツールは魔法ではなく、やはり入力に引っ張られる。煙は出ないが、結果はちゃんと変わる。
編集部の判断としては、/goal の価値は「作業の高速化」より「作業の再現性」にある。速いだけなら場当たりでもできる。しかし、同じ品質で繰り返せるかは別問題だ。実務では後者のほうが重い。
非対話モードでの実行例
claude -p のような非対話モードでは、/goal の意味がさらにはっきりする。対話しながら迷うのではなく、条件を固定して一気に進めるため、夜間処理や定型タスクと相性がよい。公式の CLI ガイドは Claude Code の CLI 利用ガイド を確認しておきたい。
実行のイメージはシンプルだ。対象ファイルや作業内容を渡し、完了条件を指定し、出力形式を決める。たとえば「このディレクトリのテスト失敗箇所を洗い出し、必要最小限の修正を加え、結果を短くまとめる」といった依頼である。対話を減らしたぶん、入力の精度がそのまま品質に返ってくる。
ここでの注意点は3つある。第一に、対象範囲を狭めること。第二に、出力形式を決めること。第三に、異常時の扱いをあらかじめ書くことだ。非対話モードは便利だが、雑に投げると雑に返る。AIも深夜勤務には弱い、というより、深夜勤務に見合う指示が必要だと考えたほうがよい。
キャンセルしたいときは /goal clear を使う。やり直しや目的変更が入りやすい開発では、この解除手段があるだけで運用の気楽さが違う。固定化しすぎた自動化は、便利なはずなのに足かせになる。だから、終わらせ方まで設計して初めて実務向きになる。
公式情報の入口としては、Claude Code 公式ドキュメント、概要ページ、CLI 利用ガイド の3本を押さえておくと、機能の位置づけを見失いにくい。
導入前に押さえる注意点
/goal は便利だが、放っておけばうまくいく類の機能ではない。むしろ、条件設計と安全策が弱いと、ただ長く動く“元気な迷子”になりやすい。そこで、導入前に確認したい点を整理しておく。
- 変更してよい範囲を先に決める。
- 完了条件と禁止条件を分けて書く。
- テストや出力確認の基準を明示する。
- 途中停止の基準を Stop hook で用意する。
- /goal clear で戻せる前提を持つ。
この5点を先に入れておくと、/goal はぐっと扱いやすくなる。特にチーム利用では、個人の勘に頼らず、誰が見ても同じ意味で読める条件文にしておきたい。AIの自動実行は、ロマンより運用で勝つ世界だ。
なお、Claude Code の周辺機能をあわせて整理したいなら、スラッシュコマンド全体の役割を見直すのが早い。以下の記事で詳しく紹介している。
この記事のポイント
- /goal は完了条件を先に決める機能で、対話の回数を減らしやすい。
- 条件は成果物・品質・終了条件・禁止条件の4点で書くと安定しやすい。
- /loop・Stop hook・自動モードは役割が違うので、反復と介入の位置を分けて考える。
- 非対話モード（claude -p）は定型作業と相性がよく、入力の精度が品質を左右する。
- /goal clear の解除手段まで含めて運用すると、実務で使いやすくなる。
参考情報（主要ソース）
Claude Code の /goal は、作業の終点を先に決めて、その条件を満たすまで進めるための実践機能だ。うまく使えば、毎ターンの確認を減らし、修正・検証・要約の流れをひとつの作業線にまとめられる。
効き目が大きいのは、派手な自動化というより、「何を達成したら終わりか」を明確にすることである。ここがぼやけると、AIは働き者のまま迷子になる。逆に条件を整えれば、Claude Code はかなり頼もしい相棒になる。
なお、Claude Code の周辺機能をあわせて整理したいなら、スラッシュコマンド全体の役割を見直すのが早い。以下の記事で詳しく紹介している。
この記事のポイント
- /goal は完了条件を先に決める機能で、対話の回数を減らしやすい。
- 条件は成果物・品質・終了条件・禁止条件の4点で書くと安定しやすい。
- /loop・Stop hook・自動モードは役割が違うので、反復と介入の位置を分けて考える。
- 非対話モード（claude -p）は定型作業と相性がよく、入力の精度が品質を左右する。
- /goal clear の解除手段まで含めて運用すると、実務で使いやすくなる。
参考情報（主要ソース）
Claude Code の自動化設計は、ChatGPT や Gemini の一般的なチャット運用とは少し違う。会話の巧さより、手順の再現性が重要になる。比較の視点を広げたい場合は、以下の記事で実務向けの違いを整理している。
実際に試してわかった使いどころ
実際に試してみると、/goal は「小さな作業を連続させる」より「終わりが見えている反復」に強い。編集部では、README 更新、軽微なコード修正、テスト失敗の切り分けを想定し、条件を変えながら挙動を見た。
README 更新では、「導入手順を最新化し、古いコマンド表記を修正し、変更点を要約する」と入れると流れがかなり安定した。途中の確認が減り、最後までの道筋が見えやすい。ここで効くのは速度より、迷いの少なさである。
次にコード修正では、1ファイルだけを対象にして試すと結果が読みやすかった。対象を広げるほど便利には見えるが、実際は判断点が増える。最初の一手は小さく、成功したら広げるのが安全だ。これは人間の仕事でもだいたい同じで、AIだけ急に無鉄砲になるわけではない。
一方で、設計判断が多いタスクは /goal だけでは少し危うい。前提の確認や実装範囲の見直しが必要な場面では、途中で Stop hook 的に人が入るほうが安全だ。AIに任せるときは、ボールを握らせっぱなしにせず、要所で受け取る感覚がちょうどいい。
使ってわかった副産物もある。ゴールを先に書くと、自分の指示も整理されるのだ。これは地味だが侮れない。人間側の依頼が整うと、AIの返答も整う。AIツールは魔法ではなく、やはり入力に引っ張られる。煙は出ないが、結果はちゃんと変わる。
編集部の判断としては、/goal の価値は「作業の高速化」より「作業の再現性」にある。速いだけなら場当たりでもできる。しかし、同じ品質で繰り返せるかは別問題だ。実務では後者のほうが重い。
非対話モードでの実行例
claude -p のような非対話モードでは、/goal の意味がさらにはっきりする。対話しながら迷うのではなく、条件を固定して一気に進めるため、夜間処理や定型タスクと相性がよい。公式の CLI ガイドは Claude Code の CLI 利用ガイド を確認しておきたい。
実行のイメージはシンプルだ。対象ファイルや作業内容を渡し、完了条件を指定し、出力形式を決める。たとえば「このディレクトリのテスト失敗箇所を洗い出し、必要最小限の修正を加え、結果を短くまとめる」といった依頼である。対話を減らしたぶん、入力の精度がそのまま品質に返ってくる。
ここでの注意点は3つある。第一に、対象範囲を狭めること。第二に、出力形式を決めること。第三に、異常時の扱いをあらかじめ書くことだ。非対話モードは便利だが、雑に投げると雑に返る。AIも深夜勤務には弱い、というより、深夜勤務に見合う指示が必要だと考えたほうがよい。
キャンセルしたいときは /goal clear を使う。やり直しや目的変更が入りやすい開発では、この解除手段があるだけで運用の気楽さが違う。固定化しすぎた自動化は、便利なはずなのに足かせになる。だから、終わらせ方まで設計して初めて実務向きになる。
公式情報の入口としては、Claude Code 公式ドキュメント、概要ページ、CLI 利用ガイド の3本を押さえておくと、機能の位置づけを見失いにくい。
導入前に押さえる注意点
/goal は便利だが、放っておけばうまくいく類の機能ではない。むしろ、条件設計と安全策が弱いと、ただ長く動く“元気な迷子”になりやすい。そこで、導入前に確認したい点を整理しておく。
- 変更してよい範囲を先に決める。
- 完了条件と禁止条件を分けて書く。
- テストや出力確認の基準を明示する。
- 途中停止の基準を Stop hook で用意する。
- /goal clear で戻せる前提を持つ。
この5点を先に入れておくと、/goal はぐっと扱いやすくなる。特にチーム利用では、個人の勘に頼らず、誰が見ても同じ意味で読める条件文にしておきたい。AIの自動実行は、ロマンより運用で勝つ世界だ。
なお、Claude Code の周辺機能をあわせて整理したいなら、スラッシュコマンド全体の役割を見直すのが早い。以下の記事で詳しく紹介している。
この記事のポイント
- /goal は完了条件を先に決める機能で、対話の回数を減らしやすい。
- 条件は成果物・品質・終了条件・禁止条件の4点で書くと安定しやすい。
- /loop・Stop hook・自動モードは役割が違うので、反復と介入の位置を分けて考える。
- 非対話モード（claude -p）は定型作業と相性がよく、入力の精度が品質を左右する。
- /goal clear の解除手段まで含めて運用すると、実務で使いやすくなる。
参考情報（主要ソース）
関連するコマンドの全体像を先に押さえるなら、以下の記事で詳しく紹介している。
Claude Codeの /goal で変わる作業感
/goal の本質は、会話を増やすことではなく、会話を減らしても作業を前に進められる点にある。たとえば「このバグを直して」で終わらず、「再現、修正、テスト通過、変更点の要約まで」を条件に入れると、Claude Code は途中で何度も確認を挟まず、終点へ向かって走りやすくなる。
Claude Code は Anthropic の公式ドキュメントでも、開発作業に入り込むターミナル型のコーディング支援として案内されている。まずは Claude Code 公式ドキュメント と Claude Code の概要 を見ておくと、/goal が単独の裏技ではなく、作業フロー全体の中で使われる機能だとわかる。
編集部として重要だと見ているのは、/goal は命令を強くする機能ではなく、作業を整理する機能だという点である。AIに強い言葉を投げるより、終わり方を設計したほうが安定する。地味に聞こえるが、実務ではこの地味さがいちばん効く。
| 項目 | 役割 | 向いている場面 | 見落としやすい点 |
|---|---|---|---|
| /goal | 完了条件を設定して到達まで進める | 修正、整形、検証、要約の反復 | 条件が曖昧だと迷走しやすい |
| /loop | 処理を繰り返して改善を重ねる | 微修正を何度も回したいとき | 回数が増えるほどコストも増える |
| Stop hook | 途中で人間の判断を入れる | 承認や確認が必要な工程 | 止めどころを決めないと中断が多い |
| 自動モード | 実行を自動化しやすくする土台 | 定型作業の連続実行 | 自由度より統制を優先する設計 |
| claude -p | 非対話モードで一括実行する | バッチ処理、CI、定期タスク | 入力の精度がそのまま結果に響く |
効果的な条件の書き方
良い /goal には、成果物・品質・終了条件の3点が入っている。この3つが揃うと、AIは「だいたいできた」で止まりにくくなる。逆に、どれかが抜けると、便利なはずの機能がふわっと漂い始める。
まず成果物は、何を出すのかを名詞で言い切ることだ。README の更新案、テスト失敗の原因整理、関数のリファクタリングなど、対象をはっきりさせる。次に品質は、どの状態なら合格かを決める。最後に終了条件は、何がそろえば終わりなのかを書く。ここが曖昧だと、AIは善意で働き続ける。少し働き者すぎるのが困りものだ。
実際に試してわかったのは、条件は長文で盛るより、短く分けたほうが安定することだ。たとえば「ログイン画面の500エラーを再現し、原因を特定し、修正し、関連テストが通るまで進める」のように、順番が見える書き方のほうが迷いが少ない。
もうひとつ見落としがちなのは、完了条件と禁止条件を分けることだ。完了条件だけだと、AIは余計な変更までしてしまうことがある。たとえば「UI を変えない」「既存 API は触らない」「テストは最小差分で通す」といった制約を添えると、枝葉の暴走を抑えやすい。
非対話で走らせるなら、さらに具体性が要る。対象ディレクトリ、変更範囲、出力形式、失敗時の扱いまで書いておくと、あとで「そんなつもりじゃなかった」が減る。AI運用の基本は、自由度を増やすことではなく、曖昧さを減らすことである。
| 書き方 | 例 | 評価 |
|---|---|---|
| 曖昧 | いい感じに整えて | 裁量が広すぎてぶれやすい |
| やや良い | テストが通るように修正して | 目的は伝わるが範囲が広い |
| 良い | 再現手順を確認し、修正し、関連テストが通るまで進めて | 完了条件が明確で安定しやすい |
| かなり良い | 再現手順の特定、修正、テスト結果の要約まで行い、失敗が残らない状態で終了して | 実務で再利用しやすい |
/loop・Stop hook・自動モードの使い分け
違いを一言で言うと、/goal は終点、/loop は反復、Stop hook は介入点である。ここを混ぜると、便利なはずの機能が一気に「全部入り定食」になる。腹は満たされるが、どれが効いたのか分からない、あの感じだ。
/goal は最終到達点を決める機能で、/loop は同じ改善を重ねる機能として見ると理解しやすい。Stop hook は、その途中に人間が目を入れるための安全弁だ。自動モードは、これらを走らせる下地として考えると整理しやすい。大事なのは道具名より、どこで止めるかを決めることである。
比較すると、/goal はカーナビに目的地を入れる操作に近い。/loop は同じルートを回り直して改善する動きで、Stop hook は「ここで一回降りて確認する」にあたる。比喩としては少し大げさだが、役割の差はかなり掴みやすい。
/loop だけで押し切ると、改善は増えても品質が上がるとは限らない。逆に /goal だけだと、途中の前提がズレたまま終点まで行くこともある。だから、反復と停止の位置を分けて設計するのが肝である。AIは万能ロボではない。文脈を与えられて初めて、それらしく動く。
実務では、こんな使い分けがわかりやすい。仕様がほぼ決まっている修正は /goal、細かい改善を何回も試したいときは /loop、レビューや承認が必要なら Stop hook、夜間に定型処理を回すなら自動モード、という順番だ。道具を増やすより、線引きを明確にするほうが速い。
Claude Code の自動化設計は、ChatGPT や Gemini の一般的なチャット運用とは少し違う。会話の巧さより、手順の再現性が重要になる。比較の視点を広げたい場合は、以下の記事で実務向けの違いを整理している。
実際に試してわかった使いどころ
実際に試してみると、/goal は「小さな作業を連続させる」より「終わりが見えている反復」に強い。編集部では、README 更新、軽微なコード修正、テスト失敗の切り分けを想定し、条件を変えながら挙動を見た。
README 更新では、「導入手順を最新化し、古いコマンド表記を修正し、変更点を要約する」と入れると流れがかなり安定した。途中の確認が減り、最後までの道筋が見えやすい。ここで効くのは速度より、迷いの少なさである。
次にコード修正では、1ファイルだけを対象にして試すと結果が読みやすかった。対象を広げるほど便利には見えるが、実際は判断点が増える。最初の一手は小さく、成功したら広げるのが安全だ。これは人間の仕事でもだいたい同じで、AIだけ急に無鉄砲になるわけではない。
一方で、設計判断が多いタスクは /goal だけでは少し危うい。前提の確認や実装範囲の見直しが必要な場面では、途中で Stop hook 的に人が入るほうが安全だ。AIに任せるときは、ボールを握らせっぱなしにせず、要所で受け取る感覚がちょうどいい。
使ってわかった副産物もある。ゴールを先に書くと、自分の指示も整理されるのだ。これは地味だが侮れない。人間側の依頼が整うと、AIの返答も整う。AIツールは魔法ではなく、やはり入力に引っ張られる。煙は出ないが、結果はちゃんと変わる。
編集部の判断としては、/goal の価値は「作業の高速化」より「作業の再現性」にある。速いだけなら場当たりでもできる。しかし、同じ品質で繰り返せるかは別問題だ。実務では後者のほうが重い。
非対話モードでの実行例
claude -p のような非対話モードでは、/goal の意味がさらにはっきりする。対話しながら迷うのではなく、条件を固定して一気に進めるため、夜間処理や定型タスクと相性がよい。公式の CLI ガイドは Claude Code の CLI 利用ガイド を確認しておきたい。
実行のイメージはシンプルだ。対象ファイルや作業内容を渡し、完了条件を指定し、出力形式を決める。たとえば「このディレクトリのテスト失敗箇所を洗い出し、必要最小限の修正を加え、結果を短くまとめる」といった依頼である。対話を減らしたぶん、入力の精度がそのまま品質に返ってくる。
ここでの注意点は3つある。第一に、対象範囲を狭めること。第二に、出力形式を決めること。第三に、異常時の扱いをあらかじめ書くことだ。非対話モードは便利だが、雑に投げると雑に返る。AIも深夜勤務には弱い、というより、深夜勤務に見合う指示が必要だと考えたほうがよい。
キャンセルしたいときは /goal clear を使う。やり直しや目的変更が入りやすい開発では、この解除手段があるだけで運用の気楽さが違う。固定化しすぎた自動化は、便利なはずなのに足かせになる。だから、終わらせ方まで設計して初めて実務向きになる。
公式情報の入口としては、Claude Code 公式ドキュメント、概要ページ、CLI 利用ガイド の3本を押さえておくと、機能の位置づけを見失いにくい。
導入前に押さえる注意点
/goal は便利だが、放っておけばうまくいく類の機能ではない。むしろ、条件設計と安全策が弱いと、ただ長く動く“元気な迷子”になりやすい。そこで、導入前に確認したい点を整理しておく。
- 変更してよい範囲を先に決める。
- 完了条件と禁止条件を分けて書く。
- テストや出力確認の基準を明示する。
- 途中停止の基準を Stop hook で用意する。
- /goal clear で戻せる前提を持つ。
この5点を先に入れておくと、/goal はぐっと扱いやすくなる。特にチーム利用では、個人の勘に頼らず、誰が見ても同じ意味で読める条件文にしておきたい。AIの自動実行は、ロマンより運用で勝つ世界だ。
なお、Claude Code の周辺機能をあわせて整理したいなら、スラッシュコマンド全体の役割を見直すのが早い。以下の記事で詳しく紹介している。
この記事のポイント
- /goal は完了条件を先に決める機能で、対話の回数を減らしやすい。
- 条件は成果物・品質・終了条件・禁止条件の4点で書くと安定しやすい。
- /loop・Stop hook・自動モードは役割が違うので、反復と介入の位置を分けて考える。
- 非対話モード（claude -p）は定型作業と相性がよく、入力の精度が品質を左右する。
- /goal clear の解除手段まで含めて運用すると、実務で使いやすくなる。
