/goal を効率的に使う方法：自律エージェントは魔法のボタンではなく運用契約だ（2026年）
/goal はエージェントを賢くするわけではなく、より粘り強くするだけです。正しい方向に粘り強いのは素晴らしいですが、間違った方向に粘り強いのは厄介です。うまく使えば、/goal は運用契約になります。すなわち、成果 + スコープ + 制約 + 検証 + 停止ルールであり、「一度押せばアプリが勝手に完成する」魔法のボタンではありません。本記事では、3つの実体験からの教訓（とその対処法）、そして最終的に私に効果があった「日中に計画し、夜に実行する」ワークフローを紹介します。
- /goal は Codex の機能で、現在はフィーチャーフラグ付きで、変化が速いです。ここで示す構文と挙動は執筆時点で公式ドキュメントと照合していますが、依存する前に最新のドキュメントを確認してください。
/goal とは何か（そして何ではないか）
/goal は Codex のゴールモード（OpenAI Codex CLI）で、検証可能な停止条件を持つ、長く機械的な目標のためのものです。/experimental から、または config.toml の [features] の下に goals = true を追加して有効化し、/goal <objective> を実行します。実行中は /goal と入力してステータスを確認でき、/goal pause、/goal resume、/goal clear で制御します。
そして最も重要な点はこれです。/goal は安全境界ではなく、プロダクトの意思決定の代わりにもならず、無制限のバックログを走らせる場所でもありません。 それは単なる粘り強いループにすぎません。（注：/goal は Codex の機能であり、Claude Code のネイティブコマンドではありません。両者を混同しないでください。）構文については公式のゴールモードガイドを参照してください。
厳しい真実：/goal はエージェントを賢くするのではなく、より粘り強くするだけ
人々は /goal を「一度押せばアプリが勝手に完成する」ボタンのように持ち上げます。私は1週間使いすぎて、毎回きれいに打ちのめされました。結論はシンプルです。/goal はエージェントを賢くするのではなく、より粘り強くするだけです。 正しい方向に粘り強いのは素晴らしいですが、間違った方向に粘り強いのは厄介です。自らを問い直すこともなく、間違った道を突き進んでしまうのです。
以下の3つの「打撃」は、最もよくある失敗パターンと、それぞれから得た教訓です。
打撃その1 - 自動コンパクト後の境界のズレ（本番へのデプロイ）
私は目標を非常に明確に書きました。ステージングにのみデプロイすると。しかし数回の自動コンパクトの後、エージェントはコンテキストから外れ、境界を忘れ、そのまま本番にデプロイしてしまいました。コンパクトのたびにタスクを思い出させるフックがあったにもかかわらずです。
痛い教訓です。エージェントに本番への特権的なアクセスを絶対に与えないでください。「覚えているだろう」を信じてはいけません。いいえ、あなたが思うほど確実には覚えていません。これこそがゴールモードが安全境界ではない理由です。安全のラインはプロンプト内のメモではなく、権限の中に置かなければなりません。アクセスを厳しくする方法はClaude Code の権限とAI コーディングのセキュリティのベストプラクティスを参照してください。
打撃その2 - 曖昧な目標はさまよう許可証
「もっときれいにして」「UX を改善して」。人間には聞こえます。しかしエージェントにとっては、さまよう許可証です。あるものを変え、別のものを壊し、少し幻覚を起こし、時には何も明確に改善しないまま早めに止まってしまいました。
教訓です。目標は「より良い」が何を意味するかを定義しなければなりません。 どうきれいにするのですか？
- 余白を詰める？
- 読みやすいコントラスト？
- モバイル対応の改善？
- チェックアウトの手順を減らす？
- 完了率を上げる？
何が欲しいか分からないなら、それをエージェントに投げて /goal を実行しないでください。まずブレインストーミングし、計画を立て、受け入れ基準を書きましょう。 要件がまだ不明確なときは、自律性をオンにするよりも、アドバイザーに明確化を依頼する（advisor/kongming）ひと手間のほうが勝ります。具体的なチェック付きの計画の書き方はClaude Code のためのプロジェクト計画を参照してください。
打撃その3 - 検証の欠落（自信満々の、偽物の「完了」）
私は新しいフロントエンドページに目標を設定しましたが、視覚的な検証のために agent-browser を使うようエージェントに伝え忘れました。結果は？ 本当の検証をスキップし、自信満々に「正常に完了しました」と報告したのです。そして開いてみて、人生は童話ではないことを思い出しました。
教訓です。誰も信用しないこと。適切なツールを提供し、完了する前にそれを使うようエージェントに明示的に要求してください。 テストがグリーンなだけでは不十分です。
- フロントエンドは目で見る必要があります（スクリーンショット/agent-browser）。
- ワークフローはクリックして通す必要があります。
- デプロイは環境を確認する必要があります。
- PR は差分をレビューする必要があります。
運用契約 - 良い /goal のための公式
要するに、良い /goal は巧妙なプロンプトではありません。それは5つの部分からなる運用契約です。
| 部分 | 答える問い |
|---|---|
| 成果（Outcome） | 「完了」とは何を意味するか？（具体的で測定可能な結果） |
| スコープ（Scope） | 何に触れてよく、何に触れてはいけないか？ |
| 制約（Constraints） | どの境界を破ってはいけないか（本番なし、公開 API の変更なし…）？ |
| 検証（Verification） | 「完了」はどう証明されるか（テスト、ビルド、スクリーンショット、クリック確認）？ |
| 停止ルール（Stop rules） | いつ止めるか、いつ人間に尋ねるか？ |
これはゴールモードの「使用テスト」に合致します。すなわち、タスクが (1) 1ターンより長く、ほぼ機械的で、(2) 検証可能な停止条件を持ち、(3) 各チェックポイントでプロダクトの意思決定を必要とせずに進められるほど明確にスコープされている場合にのみ使うべきです。探索的な作業、曖昧な改善要求、本番の認証情報の変更、破壊的な共有インフラ、混在したバックログには /goal を使わないでください。
私の /goal の使い方：日中の計画と夜間の実行を分ける
今のお気に入りのやり方は、日中の思考と夜間の実行を分けることです。
日中（思考）
- 各バグ / 機能 / 改善ごとに GitHub の issue を作成します。
- ブレインストーミングと計画のスキルを使って各 issue を明確化します。
- 実装のサマリー +
plan.mdへのリンクを issue に返信します。 ready to implementラベルを追加します。- すべての issue の準備が整うまで繰り返します。
夜間（実行）
休んで家族と過ごす前に、私は /goal を走らせます。「事前に定めた計画に基づいて、ready-to-implement のタグが付いたすべての issue を実装せよ。」 issue ごとのループは次のとおりです。
- issue を優先度で並べ替えます。
- 一度に1つの issue を実装します。
- issue ごとに別々の worktree とブランチを作成します。
ak:cook --auto（計画に対する継続的な実行）。ak:code-review。ak:ship beta。ak:review-pr --fix。ready to shipラベルを追加し、次の issue に移ります。
これははるかにうまくいきます。エージェントはもう「何が欲しいの？」と当て推量しません。明確化された計画に対して、自分のブランチ、レビュー、ベータデプロイ、PR、ラベルとともに実行します。起きて、コーヒーを淹れ、マシンを開けば、PR の山が待っています。私の仕事はもう、マイクロマネジメントの道化のように「continue」とタイプすることではありません。人間の目でレビューし、もう一度テストし、そしてマージすることです。worktree/PR を並行して走らせる方法はサブエージェントのオーケストレーションを参照し、このループをブレインストーミング → 計画 → cook → ship のワークフローの中に置いてください。
ゲートループを組み立て済みで欲しい？（AgentKit）
夜間のループが強力なのは、その品質ゲートのおかげです。ak:cook、ak:code-review、ak:ship、ak:review-pr。AgentKit はこれらのゲートを提供し、Claude Code と Codex の両方で動作します。だから Codex の /goal にも合います。率直に言えば、/goal は Codex のもので無料です。キットは組み立て済みのプロセス + レビューを追加するだけで、自分で組み立てる必要をなくします。詳しくはAgentKit レビューまたはEngineer Kit レビューをお読みください。
/goal の本当の価値
それが /goal の本当の価値です。エージェントにあなたの代わりに考えさせることではなく、あなたがすでに考え終えた後の、反復的な実行を任せることです。あなたが考え（仕様、計画、受け入れ基準）、そのうえでそれに黙々とこなさせます。あなたの仕事は、人間の目でレビューし、もう一度テストし、そしてマージすることです。
よくある質問（FAQ）
/goal とは何で、どのツールのものですか？
/goal は Codex のゴールモード（OpenAI Codex CLI）で、現在はフィーチャーフラグ付きです。/experimental から、または config.toml の [features] の下に goals = true を追加して有効化します。これは Claude Code のネイティブコマンドではありません。両者を混同しないでください。
/goal を使うべきでないのはどんなときですか？
探索的な作業、曖昧な要件、本番の認証情報の変更、破壊的な共有インフラの操作、スコープが不明確な混在バックログのときです。/goal は、検証可能な停止条件を持つ、機械的で長時間実行のタスクに向いています。
良い目標はどう書けばよいですか？
5つの部分からなる運用契約として扱いましょう。成果（「完了」の意味）、スコープ（触れてよい/いけない範囲）、制約（破ってはいけない境界）、検証（「完了」をどう証明するか）、停止ルール（いつ止めるか、いつ人間に尋ねるか）です。
/goal は本番に安全にデプロイできますか？
すべきではありません。エージェントに本番アクセスを与えないでください。ゴールモードは安全境界ではありません。安全のラインはプロンプトのメモではなく、権限（最小権限）の中にあります。数回の自動コンパクトの後、エージェントは境界を忘れるかもしれません。
エージェントが「完了」と報告するのに、グリーンなテストで十分ですか？
いいえ。フロントエンドは目で見る（スクリーンショット/agent-browser）、ワークフローはクリックして通す、デプロイ環境は確認する、PR の差分はレビューする必要があります。適切なツールを提供し、完了する前にそれを使うようエージェントに要求してください。
/goal を使うのに AgentKit は必要ですか？
いいえ。/goal は Codex のもので無料です。AgentKit は ak:cook / ak:code-review / ak:ship / ak:review-pr のゲートをループの中で動かせるように追加するだけです。組み立てる代わりに組み立て済みのプロセスが欲しい場合に便利です。
結論
/goal を神話化しないでください。それは頑固なループであり、あなたが考え終えて、あとは反復的な実行が必要になったときに役立ちます。目標を運用契約として書き、本番アクセスをロックダウンし、検証を要求し、日中の計画と夜間の実行を分けましょう。実行前に要件を明確化する必要がありますか？advisor と kongmingを参照してください。受け入れ基準付きの計画が必要ですか？Claude Code のためのプロジェクト計画を参照してください。
あなたの /goal ループに組み立て済みの品質ゲートが欲しいですか？ AgentKit Engineer Kit は ak:cook、ak:code-review、ak:ship、ak:review-pr を Claude Code と Codex 向けに提供します。プロセスを自分で組み立てる必要はありません。価格は $99 で、継続的な料金の記載はありません。