「Claude Code goal 使い方」で検索してここに来られた方へ、先に結論から書きます。/goal は「これが終わりだと言える条件」を1つ書いておくコマンドです。条件を書いておくと、Claudeは1ターン終わるたびに別のAIから「その条件、満たしましたか？」と聞かれて、満たしていなければ勝手にもう1ターン働き始めます。ぼくがこのコマンドを使うようになったきっかけは、単純な困りごとでした。Claude Codeに何か頼むと、途中で「この方針でいいですか？」「次はこうしますか？」と聞き返されて、そのたびにぼくが「はい」と打つまで作業が止まるんです。席を離れて戻ってくると、5分前から質問の画面のまま止まっている。あれが地味にきついんですよ。この記事では、/goal が何をしているのか、条件はどう書けばいいのか、そしてぼくが実際に走らせて測った数字まで、初めての方に向けて順番に書いていきます。
Claude Code そのものを触ったことがない方は、こちらを先に読むと話が早いです。
Claude Code goal 使い方の基本は「条件を1つ書くだけ」です
まず、いちばん短い説明から。Claude Code の入力欄で、こう打つだけです。
/goal kuku.txt に九九の表があり、81行すべてが正しい答えつきで書かれていることこれだけです。別に「作業を始めて」と改めて頼む必要はありません。条件を書いて送った瞬間に、Claudeはその条件を指示そのものとして受け取って動き出します。
コマンドの説明文には何と書いてあるか
Claude Code の本体を調べると、このコマンドの説明文が入っています。原文はこうです。
Set a goal Claude checks before stopping
（訳：Claudeが止まる前に確かめる目標を設定する）
画面を使わずに動かすときの説明文のほうは、もう少し直接的でした。
Set a goal — keep working until the condition is met
（訳：目標を設定する。条件が満たされるまで働き続ける）
打ち方は3つです。条件を書く／clear と書いて消す／何も付けずに打って様子を見る。3つ目はこの記事の最後で使います。覚えることが3つしかないのは、初心者にはありがたいですよね！
条件を送った瞬間、Claudeには何が伝わっているのか
ここが面白かったところです。/goal で条件を送ると、Claude Code はその裏で、Claudeに向けてこんな文を差し込んでいます。原文の一部を引きます。
A session-scoped Stop hook is now active with condition: "...". Briefly acknowledge the goal, then immediately start (or continue) working toward it — treat the condition itself as your directive and do not pause to ask the user what to do.
（訳：このセッションの間だけ有効な停止フックが、次の条件で動き出しました。目標を短く受け止めたら、すぐにその達成へ向けて作業を始める（または続ける）こと。条件そのものを指示として扱い、何をすべきかをユーザーに尋ねるために止まらないこと）
「何をすべきかをユーザーに尋ねるために止まらないこと」。ぼくが困っていたあの聞き返しを、名指しで止めにいっているわけです。これを読んだとき、ちょっと笑ってしまいました！ 同じ文の続きには、It auto-clears once the condition is met — do not tell the user to run /goal clear after success…（訳：条件が満たされれば目標は自動的に解除される。成功したあとにユーザーへ /goal clear を実行するよう伝えないこと）とも書かれています。達成したら勝手に片づくので、こちらから消す必要はありません。
/goal を付けたときと付けないときで、何が変わるのか
付けないときは、Claudeが「もういいだろう」と判断した時点で手が止まって、こちらに順番が回ってきます。付けたときは、1ターン終わるたびに別のAIが条件を見て、まだなら次のターンが勝手に始まります。この流れの違いを図にしました。左が /goal なし、右が /goal ありです。判定するAIが割り込む位置に注目してみてください。
公式ドキュメントには、/goal が向いている作業の例も挙がっています。テストが全部通るまでの移行作業、受け入れ条件が全部そろうまでの実装、キューが空になるまでの処理。どれも「終わったかどうかを外から確かめられる作業」です。逆に言うと、終わりを確かめようがない作業には向いていません。
この「条件を書いて意図どおり動かす」という話をもっと深くやりたい方には、解説書も出ています。技術評論社の『実践Claude Code入門』は304ページで、目次に「Claude Codeの動作原理を理解する」「Claude Codeを意図どおりに動かす」という章が並んでいます。ぼくはまだ読んでいないので中身の評価はできません。この記事ではあと2冊の本にふれますが、「Claudeに何をどう伝えるか」の続きとしては、3冊のなかでいちばん近い1冊だと思います。ソフトウェア開発の現場を前提にした本なので、そこは好みが分かれるところです。
判定は3つあります。「まだ」「達成」、そして「不可能」
/goal の説明でいちばん見落とされているのが、ここだと思います。判定は「できた」「まだ」の2つではなく、3つあるんです。公式の説明に並んでいる順で見ていきます。
1つめ：まだ（Not yet met）
まだ満たしていないと判定されると、Goal not yet met… continuing（訳：目標はまだ達成されていません…続けます）と出て、次のターンが始まります。ここが地味に効くところで、公式の説明では、判定するAIが返した「なぜまだなのか」という理由が、次のターンの手がかりとしてClaudeに渡されます。ただ「もう一回やれ」と言われるのではなく、「ここが足りない」と言われて続きをやる形です。このとき目標は解除されず、付いたまま次のターンへ進みます。
2つめ：達成（Met）
条件を満たしたと判定されると、画面に Goal achieved（訳：目標を達成しました）と出ます。公式の説明では、このとき目標は自動的に解除され、達成した記録が会話に残ります。こちらから消す操作は要りません。
3つめ：不可能（Impossible）
そして3つめ。「その条件は、どうやっても満たせない」と判定される道があります。このとき画面には Goal could not be achieved（訳：目標を達成できませんでした）と出ます。公式の説明では、目標は自動的に解除され、理由とともに失敗として記録されます。
この3つめがあるおかげで、無理な条件を書いてしまっても永久に回り続けることはない、という作りになっています。逆に言えば、条件の書き方を間違えると「不可能」で終わってしまうということでもあります。3つの結末を図にまとめました。達成と不可能のときは、目標が自動で片づきます。まだのときは、目標がついたまま次のターンが始まります。
いちばん大事なこと：判定するAIは「会話の記録」しか見ていません
ここがこの記事でいちばん伝えたいところです。ここさえ分かっていれば、/goal がうまく動かないときの原因の大半は自分で見当がつくようになります。
条件を判定するAIは、ファイルを開きません。コマンドも走らせません。見ているのは、Claudeとあなたのやりとりが並んだ会話の記録だけです。
公式の説明では、こう書かれています
Anthropicの公式ドキュメントには、はっきりこう書いてあります。
It doesn't run commands or read files independently, so write the condition as something Claude's own output can demonstrate.
（訳：判定する側はコマンドを実行することも、自分でファイルを読むこともしない。だから条件は、Claude自身の出力によって示せる形で書くこと）
同じページには、判定する側はcan only judge what Claude has already surfaced in the conversation（訳：Claudeが会話の中にすでに出したものしか判定できない）とも書かれています。
Claude Code 本体に入っている、判定するAIへの指示文
公式の説明だけだと「本当かな」と思ったので、Claude Code の本体そのものから、判定するAIに渡している指示文を取り出してみました。原文です。
You are evaluating a stop-condition hook in Claude Code. Read the conversation transcript carefully, then judge whether the user-provided condition is satisfied.
（訳：あなたはClaude Codeの停止条件フックを評価しています。会話の記録を注意深く読み、ユーザーが与えた条件が満たされているかどうかを判定してください）
「会話の記録を注意深く読み」。渡されているのは読むものだけで、調べにいくための道具は与えられていません。さらに、こういう一文も入っていました。
If the transcript does not contain clear evidence that the condition is satisfied, return {"ok": false, "reason": "insufficient evidence in transcript"}.
（訳：条件が満たされたという明確な証拠が会話の記録に含まれていない場合は、{"ok": false, "reason": "insufficient evidence in transcript"}＝「記録内の証拠が不十分」を返すこと）
この insufficient evidence in transcript（記録内の証拠が不十分）という言葉が、たぶん初心者が最初にぶつかる壁です。ファイルの中身が正しくても、その正しさが会話に出てきていなければ「証拠が不十分」で終わります。
だから条件は「Claudeの発言の中で証明できる形」で書きます
ここまでをつなぐと、条件の書き方の答えが出てきます。判定するAIが読めるのは会話だけ。ということは、条件は「Claudeがしゃべった内容だけで白黒つけられること」でなければいけないんです。
たとえば「バグが全部直っていること」。これはダメな条件です。バグが全部直ったかどうかは、会話を読んだだけでは分かりません。一方「npm test を実行して、終了コードが0だったこと」なら大丈夫です。Claudeがテストを走らせれば、その結果が会話に出てきます。判定するAIはそれを読んで「満たした」と言えます。
判定するAIに見えているもの・見えていないものを図にしました。左に並んでいるのが判定に使える材料、右がまったく届かない材料です。右側のものを条件に書いてしまうと、いつまでも「証拠が不十分」が返ってきます。
会話が長すぎるときも「証拠が不十分」になります
もう1つ、覚えておくと得をする話があります。会話が長くなりすぎると、判定するAIには前半が渡されません。そのときの指示文の原文がこれです。
... earlier messages omitted. Evaluate the condition against the recent transcript below; if the required evidence may be in the omitted prefix, return {"ok": false, "reason": "insufficient evidence in transcript"}.
（訳：…前のほうのメッセージは省略されています。以下の直近の記録に対して条件を評価してください。必要な証拠が省略された前半にある可能性がある場合は、「記録内の証拠が不十分」を返してください）
つまり、ずっと前のターンで達成していても、会話が長くなると判定に届かなくなることがあるということです。長い作業をさせるときほど、Claudeに「いまこうなりました」と直近で言わせる条件にしておくほうが安全だと思います。
条件の書き方：3つの要素と「打ち切り」を入れる
では、実際にどう書けばいいのか。公式ドキュメントは、長く持ちこたえる条件には3つの要素がある、と書いています。
要素1：測れる終わりの状態を1つ
原文では One measurable end state です。テストの結果、ビルドの終了コード、ファイルの数、キューが空になったこと。数えられるか、通った・通らないで言えるものを1つだけ置きます。2つ3つ並べたくなりますが、まずは1つで試すのがおすすめです。
要素2：どうやって確かめるかを書く
原文では A stated check、つまり「Claudeがそれをどう証明すべきか」です。公式の例は npm test exits 0（npm test の終了コードが0）や git status is clean（git status に変更が残っていない）でした。ここが、さっきの「会話の記録しか見ていない」という話と直結します。確かめ方を書いておけば、Claudeがそれを実行して、結果が会話に残ります。
要素3：崩してはいけないものを書く
原文では Constraints that matter。そこへ至る途中で変えてはいけないものです。公式の例は「他のテストファイルは変更しないこと」でした。これが無いと、テストを通すためにテストのほうを書き換える、みたいな解決をされかねません。
「または20ターンで止まる」を足しておく
公式ドキュメントは、走る長さを区切りたいときは条件文の中にそう書け、としています。例として挙がっているのが or stop after 20 turns（訳：または20ターンで止まる）です。設定画面のどこかにある項目ではなく、条件の文章の中に日本語なり英語なりで書き足すだけという点が、ちょっと意外でした。公式の説明では、Claudeは毎ターンその区切りに対する進み具合を報告し、判定するAIは会話からそれを判定します。
条件は4,000文字まで
条件の長さには上限があります。Claude Code 本体の中では4,000文字と決められていて、超えるとこう出ます。
Goal condition is limited to 4000 characters (got N)
（訳：目標の条件は4000文字までです（受け取ったのはN文字））
4,000文字あれば、たいていの条件は書けます。ちなみに、条件を自分で考えつかなくても、Claude自身が「こういう目標にしませんか」と提案してくる場面もあります。そちらの上限は500文字でした。
良い条件と悪い条件を並べた表を作りました。左が「読んでも白黒がつかない書き方」、右が「会話の記録だけで白黒がつく書き方」です。ここを見比べるだけでも、書き方のコツがつかめると思います。
ぼくが実際に測ってみました（/goalあり・なしで1回ずつ）
ここからは、公式の説明ではなくぼくが実際に走らせて測った話です。
やったこと
同じ内容の指示を、/goal を付けた場合と付けない場合で1回ずつ走らせました。作業用のフォルダは別々にして、前の作業が残らないようにしています。指示はこれです。
/goal kuku.txt に九九の表があり、81行すべてが「a x b = c」の形で正しい答えつきで書かれていること付けないほうは、先頭の /goal だけを外した同じ文です。使ったのは Claude Code 2.1.234、測ったのは2026年8月18日です。
結果の数字
ターン数は /goal ありが6、なしが5。所要時間はありが26.7秒、なしが19.1秒。費用はありが0.16852ドル、なしが0.14427ドルでした。主な作業をしたのはどちらも Sonnet 5 で、出力したトークン数もありが1,759、なしが1,725とほとんど変わりません。数字を並べた表がこちらです。差が出ているのは、ターン数・時間・費用と、あとで書く小型のAIの使われ方だけです。
判定していたのは Haiku 4.5 で、費用は全体の約6%でした
数字を見ていて「おっ」と思ったのがここです。/goal を付けたほうは、小型のAI（Haiku 4.5）の側に会話の記録がキャッシュとして6,983トークン分つくられていました。付けなかったほうはそこが0で、入力が933トークンあるだけです。このときのHaikuは判定役ではなく、別の用途で動いていたぶんだと思います（何に使われたかまでは測れていません）。出力のほうも、付けたほうが241トークン、付けなかったほうは20トークンでした。数え方の欄が違うので単純な倍率では比べられませんが、付けたときだけ会話の記録がまるごと小型のAIに渡っていることは、この2つの数字から読み取れます。
これは、判定するAIが実際に会話の記録を受け取って読み、判定の文章を書き返している跡だと思います。「会話の記録しか見ていない」という公式の説明が、渡されたトークンの量として目に見えた形です。ここはぼくが自分で測った数字なので、そのつもりで読んでください。
気になる費用ですが、判定にかかったのは0.00994ドルで、その回の全体（0.16852ドル）の約6%でした。公式ドキュメントも、判定に使うトークンは本体の作業に比べればふつうは無視できる程度、という言い方をしています。ぼくが測った1回も、それと矛盾しない結果でした。
正直に書きます。成果物は同じでした
さて、ここが正直に書かないといけないところです。
できあがった九九の表は、/goal ありもなしも、81行すべて正しくて、まったく同じでした。
/goal を付けたほうが1ターン多く、7.6秒長く、0.024ドル高くつきました。それで得られた成果物は同じ。この1回だけを見れば、/goal は少し高くついただけ、ということになります。「/goal を付けると成果物が劇的に良くなる」とは、ぼくの実測からは言えません。
ただし、逆の結論を出すのも間違いです。これは1回ずつ走らせた結果でしかないので、「差が無い」ことの証明にもなりません。回数を増やせば違う数字が出るかもしれませんし、そもそも今回は条件がはっきりしすぎていました。「81行すべてが正しい答えつきで書かれていること」なんて、Claudeが1回で正しくやってしまえば、続ける理由がありません。
ぼくの考え（ここは実測ではなく推測です）としては、/goal が効いてくるのは条件があいまいで、Claudeが途中で「もういいかな」と判断してしまいそうな作業のほうだと思っています。九九の表のように一発で終わる作業では、そもそも判定するAIの出番がほとんどありません。何十ターンも続く作業で、しかも途中で聞き返されると止まってしまう場面。そういうところでこそ効くはずです。ここは回数を増やして確かめたいところなので、この記事の最後にもう一度ふれます。
/goal は「許可を自動で通す」コマンドではありません
ここも誤解されやすいところなので、はっきり書いておきます。/goal を付けても、コマンドの実行許可が自動で下りるようにはなりません。
実測で3回はじかれましたが、目標は続きました
ぼくが /goal ありで走らせたとき、実際にBashコマンドが3回はじかれました。許可されていない書き方を使おうとしたためです。ここで「じゃあ目標は失敗になったのか」というと、そうはなりませんでした。目標は解除されず、Claudeは別の書き方に切り替えて最後まで走り切りました。
この動きは、ぼくにはかなり好ましく見えました。許可の壁は壁のまま残っていて、そのうえで目標だけが「まだ終わってないよ」と押し続けている形だからです。/goal が許可の壁まで勝手に開けてしまう作りだったら、こわくて使えません。
ここまでに出てきたスラッシュコマンドや、/goal が裏で使っている仕組みまで踏み込みたい方向けの本もあります。技術評論社の『Claude CodeによるAI駆動開発入門』は320ページで、料金の話とアカウント登録から始まって、目次の後半に「並行処理とサブエージェントを使った開発手法」という章や、「カスタムスラッシュコマンドとHooks」「Claude Codeのセキュリティ設計を理解する」という見出しが並んでいます。ぼくはまだ読んでいないので中身の評価はできませんが、この記事の次に読むなら、3冊のなかではこれがいちばん奥まで連れていってくれそうです。
Autoモードとは役割が別で、組み合わせると効きます
公式ドキュメントは、Autoモードとの関係をこう書いています。
auto mode removes per-tool prompts, and /goal removes per-turn prompts
（訳：Autoモードは道具ごとの確認をなくし、/goalはターンごとの確認をなくす）
言い換えると、Autoモードは「1ターンの中で、いちいち許可を聞かれるのをやめる」もの。/goal は「1ターン終わるたびに順番がこちらに戻ってくるのをやめる」ものです。止めている場所が違うので、両方使うと止まる場所がほぼ無くなります。公式ドキュメントも、目標のターンを見ていなくても回したいならAutoモードで /goal を使え、という書き方をしています。裏を返すと、これは「見ていなくてもいい」と思えるようになってからの話です。慣れないうちは片方ずつ、まずは様子を見ながら試すのが安心だと思います。
Autoモードそのものについては、別の記事で6つのモードの選び方を書きました。/goal と組み合わせる前に、いま自分がどのモードにいるかは確かめておいたほうがいいです。
/loop・Stop hook との違い
似たようなことができる仕組みが他にも2つあります。/loop と Stop hook です。公式ドキュメントの比較を読むと、違いは「次のターンが何をきっかけに始まるか」にありました。
/goal：前のターンが終わったら始まる。止まるのは、AIが条件を満たしたと確認したときか、不可能と判定したとき/loop：一定の時間が経ったら始まる。止まるのは、こちらが止めたときか、Claudeが仕事は終わったと判断したとき- Stop hook：前のターンが終わったら始まる。止まるかどうかは、自分で書いたスクリプトや文章が決める
公式の説明では、/goal は「そのセッションの間だけ有効な近道」で、Stop hook は設定ファイルに置いておくもの、という区別になっています。毎回同じ確かめ方をさせたいならStop hook、今日この作業だけ続けさせたいなら /goal、ということですね。いま挙げた3つに、さきほどのAutoモードを加えた4つの役割分担を、1枚にまとめました。自分がやりたいことがどれに当たるかを、この図で当ててみてください。
/goal が使えないときの2つの原因
「打っても反応しない」「メニューに出てこない」というときの話です。原因はほぼ2つに絞れます。しかもClaude Code は、どちらの場合も理由を画面に出してくれます。黙って何もしない作りにはなっていません。
原因1：そのフォルダを信頼していない
このとき出るメッセージの原文がこれです。
/goal is only available in trusted workspaces. Restart, accept the trust dialog, and try again.
（訳：/goalは信頼済みのワークスペースでのみ使えます。再起動して信頼の確認画面を承認し、もう一度お試しください）
Claude Code は、新しいフォルダで初めて起動したときに「このフォルダを信頼しますか」と聞いてきます。そこで承認していないと /goal は使えません。メッセージのとおり、いったん終了して起動し直し、確認画面を承認すれば使えるようになります。
なぜフォルダの信頼が関係するのかというと、/goal は「フック」という仕組みを使って作られているからです。フックというのは、Claude Codeが決まった場面で自動で何かを走らせる仕組みのことで、公式ドキュメントによると、/goal にもそのフックと同じ信頼のルールが当てはまります。
原因2：フックが止められている
もう1つの原文はこちらです。
/goal can't run while hooks are restricted (disableAllHooks or allowManagedHooksOnly is set in settings or by policy).
（訳：フックが制限されている間は/goalを実行できません（設定またはポリシーによってdisableAllHooksまたはallowManagedHooksOnlyが設定されています））
設定で disableAllHooks がtrueになっているか、管理側の設定で allowManagedHooksOnly が指定されていると、/goal は動きません。自分で設定した覚えがないのにこれが出るなら、会社や学校から配られたパソコンで、管理側の設定が効いている可能性があります。その場合は自分では外せないので、設定を管理している方に相談するしかありません。
この2つの原因と、それぞれ何をすればいいかを図にしました。画面に出た英語のメッセージと見比べて、自分がどちらなのかを確かめてみてください。
ちなみに「No goal set」は故障ではありません
もう1つ、初めてだと戸惑うメッセージがあります。
No goal set. Usage: /goal <condition>
（訳：目標は設定されていません。使い方：/goal <条件>）
これは単に「いま目標が入っていませんよ」というお知らせです。エラーではないので、あわてないでください。
止め方と、暴走しない仕組み
勝手に働き続けると聞くと、止まらなくなったらどうしようと思いますよね。ぼくも最初にそこが不安でした。止める方法と、勝手に止まる仕組みの両方があります。
自分で止めるなら /goal clear
いま動いている目標を途中でやめさせたいときは、これです。
/goal clear画面には /goal clear to stop early（訳：早めに止めるなら /goal clear）という案内も出ています。公式ドキュメントによると、clear の代わりに stop・off・reset・none・cancel と書いても同じように消せますし、会話を新しく始める /clear を打っても目標は消えます。「止め方を忘れた」で困ることはなさそうです。
ツールを使わないターンが続くと、Claude Code のほうが止めます
ここは、よくできているなと思ったところです！ 公式ドキュメントの説明では、こうなっています。
If Claude keeps answering the evaluator without making progress (no tool use for several turns in a row), Claude Code stops the loop, prints a warning, and returns control to you with the goal still set.
（訳：Claudeが前に進まないまま判定する側に返事を続けている場合（何ターンも続けて道具を使っていない場合）、Claude Code は繰り返しを止め、警告を表示し、目標は設定されたままで操作をあなたに返します）
「口だけ動いていて手が動いていない」状態が続くと、Claude Code のほうが打ち切ってこちらに順番を返してくれる、ということです。目標そのものは残ったままなので、次にこちらが何か打てば判定は再開します。
もう1つ、公式ドキュメントには「ターンが終わった時点でサブエージェントやバックグラウンドのコマンドがまだ動いている場合は、そのターンの判定を飛ばして、次のターンが終わったときに判定する」とも書かれています。走っている途中の作業を「まだできてない」と誤判定しないようになっているわけですね。
途中でやめて、あとから再開したとき
目標が動いたままセッションを終えて、あとから --resume や --continue で再開した場合。公式の説明では、条件は引き継がれますが、ターン数・経過時間・トークンの数え直しは全部リセットされます。すでに達成した目標や、消した目標はよみがえりません。
セッションを切り替えるか、続けるかの考え方は、Claude Codeのセッション履歴は削除すべき？結論と対処法という別の記事に書きました。あわせてどうぞ。
今日から試す3ステップ
長くなったので、最初にやることだけまとめます。この3つで動きます。
ステップ1：フォルダを信頼する
Claude Code をそのフォルダで起動して、信頼の確認画面が出たら承認します。ここを飛ばすと、さっきの /goal is only available in trusted workspaces. が出て先へ進めません。
ステップ2：/goal に条件を1つ書く
欲張らずに、測れる終わりの状態を1つだけ書きます。しかもClaudeがしゃべった内容で証明できる形で。慣れないうちは、末尾に「または20ターンで止まる」を足しておくと安心です。
/goal ○○を実行して結果を貼り、エラーが0件であること。または20ターンで止まるステップ3：/goal だけを打って様子を見る
条件を付けずに /goal だけを打つと、いまの状態が出ます。公式の説明では、出るのは「条件」「どれくらい動いているか」「何ターン判定されたか」「いまのトークンの使用量」「判定するAIが最後に返した理由」です。ぼくはこの最後の「理由」がいちばん役に立つと思っています。なぜまだ終わっていないのかが、判定した側の言葉で読めるからです。ここを読むと、自分の書いた条件のどこが伝わっていないかが分かります。
使い込んでいくと、こういう自動で回る仕組みをいくつも組み合わせたくなってきます。ブログの更新まわりを自動で回す方法は3つ試したことがあって、その結果はこちらにまとめました。
さらに進めて、ぼくがClaude Codeで会社の形を作ってみて、どこで行き詰まって、どう作り直したかはこちらに書きました。
ここまで読んで「プログラムは書かないけど、これで仕事を任せてみたい」と思われた方には、『文系・非エンジニアがClaude Codeで自走するAIチームをつくる本』という1冊があります。176ページと3冊のなかではいちばん薄く、目次も「まず1体動かし、最初の仕事を頼む」「自分専用のAIチームをつくる」と、開発ではなく仕事の任せ方のほうを向いています。ぼくはまだ読んでいないので中身の評価はできませんが、上の2冊が開発者向けなのに対して、こちらは非エンジニアを名指しで読者にしている点が違います。
まとめ：分からなかったこと、次にやること
/goal は、条件を1つ書いておくと、1ターンごとに別のAIがそれを見て、まだなら勝手に続けてくれるコマンドでした。いちばん大事なのは判定するAIが会話の記録しか見ていないことで、だから条件はClaudeの発言の中で証明できる形に書く。ここさえ押さえれば、あとは打つだけです。「Claude Code goal 使い方」を調べてここに来られた方に覚えてほしいのは、正直これだけです。
そのうえで、今回分からなかったことを正直に書いておきます。
1つめ。/goal を付けると成果物が良くなるのかどうかは、ぼくには確かめられませんでした。今回の九九の表では、あってもなくても同じものができました。1回ずつしか走らせていないので、良くなるとも、変わらないとも言えません。
2つめ。どういう作業なら差が出るのかも、まだ分かっていません。条件があいまいな作業ほど効くはずだ、というのはぼくの推測であって、測った結果ではありません。
3つめ。「不可能」と判定される瞬間を、ぼくはまだ見ていません。3つめの結末があることは本体の中身と公式の説明で確かめましたが、実際にその画面を見たわけではないんです。
次にやることは決めています。まず、わざと満たせない条件を書いて Goal could not be achieved を自分の目で見ること。それから、何十ターンもかかる長い作業を /goal あり・なしで何回か走らせて、ターン数と成果物を並べてみること。あと、会話が長くなったときに insufficient evidence in transcript が本当に返ってくるのかも試したいです。やってみて分かったら、この記事に書き足しますね。
この記事を書くきっかけは、ライフハッカー・ジャパンが2026年8月17日に出した /goal の紹介記事（原題「I added one command to my Claude Code prompts and the difference is night and day」／MakeUseOf）を読んだことでした。ただ、その記事には「不可能」という3つめの結末や、判定するAIが会話の記録しか見ていないという話は出てきません。そこが実際に使うときにいちばん効くところだと思ったので、公式ドキュメントと自分の実測で確かめ直したのがこの記事です。元の記事はこちらから読めます。
/goal の公式ドキュメントはこちらです。Keep Claude working toward a goal（Claude Code 公式ドキュメント） ※英語サイト・自動翻訳推奨
コメント