過去6週間の間に、主要なAIラボはすべて同じプリミティブをリリースしました。AnthropicはClaude Codeに/goalを追加し、OpenAIはCodex CLIおよびCodexデスクトップアプリにそれを搭載し、Nous ResearchはHermesに組み込みました。この命名の一貫性には意味があります。これは、測定可能な最終状態に到達するまで、逐一許可を求めることなく、クローズドループで実行されるエージェントという一つの共有インターフェースに業界が落ち着きつつあることを示しています。
もしあなたが手動で「承認し、プロンプトを送信し、エージェントに続行を指示し、繰り返す」という作業をしていたのなら、/goalはその作業を終わらせるスラッシュコマンドです。エージェントに目標を与えれば、エージェントはその目標に向かって作業し、目標が達成されたら結果を返します。
このガイドは開発者およびAPIビルダー向けです。/goalが実際に内部で何をしているのか、CodexとClaude Codeでの設定方法、無限ループではなく実際の結果を生み出すプロンプト構造、そしてApidogを使用してすべてをAPIワークフローに組み込む方法について説明します。
このガイドの後半でAPIの例に従って進めたい場合は、Apidogを無料でダウンロードしてください。
/goalが実際にしていること
一言で言えば、/goalはAIエージェントが、承認のためにあなたと往復することなく、停止条件がトリガーされるまでタスクをループ実行させるものです。
その仕組みはシンプルです。メインエージェントが各ステップを実行した後、小型で高速なバリデーターモデルが動作し、「目標は達成されたか？」という一つの質問に答えます。達成されていなければ、メインモデルは続行します。達成されていれば、ループは終了し、エージェントは結果を報告します。これは2026年初頭に普及した「ラルフループ」と同じパターンですが、現在は公式ツール内にファーストクラスのコマンドとして搭載されています。
通常のエージェント利用との対比：
/goalなし：ループはあなた自身です。出力を読み取り、それが正しいか判断し、次のステップを促し、ツール呼び出しを承認する、といったことを繰り返します。各イテレーションであなたの注意力が消費されます。/goalあり：エージェントがループを所有します。計画、実行、自己検証を行い、完了したとき、制約に達したとき、または予算が尽きたときにのみ結果を表面化します。
具体的な例を挙げます。Claude Codeに/goal create a landing pageと指示すると、調査、足場構築、スタイリング、デバッグ、そして最終プレビューがすべて一連の連続した実行としてトリガーされます。あなたは作業から離れ、後で戻ってきて、それをリリースするか、または反復します。
なぜこれが突然、至るところにあるのか
現在、/goalがベンダー間でリリースされている理由は、長期的なエージェントタスクが予測可能な2つの方法で失敗していたためです。
- ドリフト（逸脱）。元の目標に対してチェックを行うバリデーターがなければ、モデルは逸脱し、自信満々ではあるものの誤った出力を生成する可能性がありました。
- 付きっきり。モデルが作業をこなせたとしても、ユーザーは各イテレーションを監視しなければならず、エージェントの目的を損なっていました。
2つ目のバリデーターモデルがこれら両方の問題を解決します。これは安価であり（小型モデル、限定的なプロンプト）、ループに厳格な停止条件を与えます。これこそがその秘訣です。このパターンが機能することにラボが気づくと、彼らは数週間のうちにすべて同じ名前でこれをリリースしました。
Codexで/goalを設定する
Codex CLIは最も強力な制御を提供します。以下は最小限の設定です。
- デスクトップアプリで目標を有効にする：Codexデスクトップを開き、設定 → 設定に進み、
goals = trueを設定します。CLIはこの設定を継承します。 - 承認プロンプトが表示されないようにCLIをフルオートモードで起動する：
codex --approval-mode full-auto
- 目標を設定する：
/goal [your goal here]
これだけです。Codexは目標が登録されたことを確認表示し、実行を開始します。
非技術者の方は、CLIではなくCodexデスクトップアプリから始めることをお勧めします。機能は同じですが、一時停止、クリア、トークン使用量の監視のためのUIが提供されます。
Claude Codeで/goalを設定する
Claude Code CLIもほぼ同様に機能します。CLIを起動し、/goalと入力し、その後にタスクの説明を続けます。公式ドキュメントはClaude Codeドキュメントサイトで確認できます。
Claude Codeの起動時にセットアップまたは設定エラーに遭遇した場合は、無効なcustom3pエンタープライズ設定の修正が最も一般的な失敗パターンをカバーしています。/goalと並行してマルチエージェントワークフローでClaude Codeを駆動する方法について詳しく知りたい場合は、Claude Code上のマルチエージェントレイヤーであるRufloに関する弊社の解説をご覧ください。
見落としがちなヒントが一つあります。/goalは、Claude Code内で実行中のタスクのリアルタイムトークン数と進行状況バーを表示します。出力だけでなく、トークン数も監視してください。進行なくトークンを消費している目標は、バリデーターが収束に失敗している兆候であり、/pauseまたは/goal clearを実行すべきです。
実際に機能するプロンプト構造
/goalの構文は取るに足らないものです。難しいのは、2時間実行されて微妙に間違った結果を渡してくるエージェントではなく、使える結果を生み出すプロンプトを書くことです。
効果的な/goalプロンプトはすべて、3つのコンポーネントで構成されています。
- 作業内容：何を行いたいのかを一行で。
- 測定可能な最終状態：バリデーターがチェックできる形式での「完了」の定義。
- 制約：全体を通して保持されなければならないルール。
骨格：
/goal [do the work] until [measurable end state] without [constraints that must hold]
コーディングタスクの実際の例：
/goal fix every failing test until npm test exits 0 without modifying any file outside the /auth directory
最終状態は検証可能であり（npm testの終了コード）、制約はバリデーターが各イテレーションで強制できる厳密な境界です。バリデーターがテストコマンドを実行するため、エージェントは完了を偽装することはできません。
曖昧なタスク（「このUIをモダンな雰囲気にしてください」など）では、最終状態が測定できないため、/goalはうまく機能しません。目標を測定可能に書き換えるか（「Lighthouseのアクセシビリティスコアが90以上になるまで」など）、通常のプロンプトを使用してください。
より長いタスクのための高度な構造
より大きな目標の場合、骨格を4つのブロックに展開します。
/goal
Objective: [one-line goal]
Success criteria:
- [measurable criterion 1]
- [measurable criterion 2]
Constraints:
- [boundary 1]
- [boundary 2]
Context:
- [files, repos, API keys the agent should know about]
この形式は、バリデーターが各ループイテレーションでチェックすべき具体的な項目を提供します。成功基準がなければ、バリデーターは曖昧な意味的マッチングに頼ることになり、そこからドリフトが発生します。
参考にすべき例
/goalはコードを書くだけのものではありません。うまく機能するいくつかのパターンを以下に示します。
リサーチ
/goal collect every public benchmark for Claude Opus 4.7 published since April 2026, save sources, and produce a markdown table sorted by date until the table covers at least 10 distinct benchmarks
リポジトリ保守
/goal find dead code, unused dependencies, and stale files in this repo, then propose a PR description listing safe removals until every item has a justification
ドキュメンテーション
/goal rewrite README.md so a new contributor can install, run, test, and understand the project until each of those four steps has a working command and an expected output
機能開発
/goal add a dark/light theme toggle, persist the choice in localStorage, update styles for both themes, and verify in the browser until the toggle works without a page reload and survives a refresh
共通のパターンは、すべての例で検証可能な最終状態を明確に定めていることです。それが、完了する目標と堂々巡りする目標の境界線です。
/goalとAPI開発ワークフローの組み合わせ
これまでの/goalに関するほとんどの報道は、一般的なコーディングタスクについてのものでした。バックエンドおよびプラットフォームエンジニアにとってより興味深いユースケースはAPI作業であり、そこでは最終状態がほぼ常にテスト可能です。
APIエンドポイントは/goalに最適です。「完了」が明確だからです。つまり、リクエストが200を返し、レスポンススキーマが一致し、契約が文書化されている状態です。「このエンドポイントがテストをパスするようにする」という目標を書けば、バリデーターは読み取るべき具体的な信号を得られます。
実践で役立つワークフロー：
- まずApidogで契約を設計します。Apidog内でエンドポイント、リクエストスキーマ、レスポンススキーマ、および例のペイロードを定義します。これが信頼できる唯一の情報源となります。
- 仕様をエクスポートします。ApidogはOpenAPI 3.xをエクスポートし、これをCodexまたはClaude Codeにコンテキストとして渡します。
/goalを実行します。エージェントに「すべてのApidogテストケースがパスするまでエンドポイントを実装せよ」と指示します。- バリデーターがテストランナーをチェックします。各ループイテレーションで、バリデーターは実行中のサービスに対してApidog CLIテストを実行します。エージェントはすべてのケースがグリーンになるまで完了しません。
これは、エージェントに独自のテストを考案させるよりもはるかに優れています。契約がすでに確定しているためです。エージェントは、仕様でカバーされているエッジケースを見落としたまま、パスするテストスイートを出荷することはできません。
Apidogをこれまで使用したことがない場合、このAPIプラットフォームは設計、モック、テスト、ドキュメント作成を一つのツールに統合しています。これは、バリデーターが状態をチェックするために一つのコマンドを実行するだけで済む場合に/goalが最もよく機能するため、重要です。デザインファーストのAPIワークフローガイドでは、契約ファーストのセットアップについて詳しく説明しており、QAエンジニア向けのAPIテストツール概要では、エージェントが反復するテストケースをどのように構成するかを示しています。
MCPサーバー（ほとんどのAIコーディングツールが外部ツールを呼び出すために現在使用しているプロトコル）を扱っている場合も、同じパターンが適用されます。/goalエージェントをローカルMCPサーバーに対して安全に実行させるセットアップについては、ApidogでのMCPサーバーテストをご覧ください。
本番環境で/goalを実行して得られたプロのヒント
/goalを実際に使用してみて初めてわかることがいくつかあります。
- 一度に一つの目標。CodexとClaude Codeはどちらも、一度にアクティブな目標を一つに制限しています。それらを重ねようとすると、奇妙な状態になります。実行間には
/goal clearを使用してください。 /planと組み合わせる。有用なワークフローは、まず/planを実行し、計画を確認してから、その計画をコンテキストとして/goalを実行することです。これにより、エージェントがループ途中でアプローチを再設計することがなくなるため、イテレーション回数を半分に減らすことができます。- マークダウンファイルをスクラッチパッドとして使用する。エージェントに
progress.mdファイルを維持するように指示します。これにより、読みやすい監査証跡が得られ、エージェントはイテレーション間で永続的なコンテキストを得られます。 - モデルに独自の目標を書かせる。あなたの大まかなアイデアを通常のプロンプトに入れ、モデルに成功基準を含む
/goal呼び出しに変換するように求めます。モデルは、バリデーターが実際に何をチェックできるかを知っているため、あなたよりも優れた目標プロンプトを作成します。 - メインモデルではなく、バリデーターを監視する。ループが閉じない場合、問題はほぼ常に成功基準が測定できないことです。基準を厳密にし、同じ目標を再試行しないでください。
/goalは長期的な作業向けです。一行のリファクタリングでは、通常のプロンプトの方が高速です。自律的なループにはオーバーヘッドがあります。
/goalが期待外れになる場合
考慮すべき正直な制限事項：
- コスト。1時間実行されるループは、同じタスクを手動で行うよりも多くのトークンを消費します。予算を設定してください。
- シグナルがないタスク。UXの洗練、文章のトーン、デザインの好みなど、これらには明確なバリデーターがありません。エージェントは諦めるか、偽の停止条件を作り出すでしょう。
- 外部への副作用。メール送信、支払い処理、本番APIの呼び出しを伴う目標には、厳格な制約が必要です。エージェントは自動的に注意を推測しません。AIエージェントがAPIを呼び出す際のアクセス制御をまだ構築中の場合、主要ベンダーがこれをどのように処理しているかについては、チーム向けGitHub Copilotの利用状況と課金APIに関する記事をご覧ください。
- 古いコンテキスト。コードベースがループの途中で変更された場合、長期間実行される目標は元の仕様から逸脱する可能性があります。古いコンテキストに対して続行させるのではなく、一時停止してリセットしてください。
AIを使った構築方法にこれが意味するもの
/goalは、「AIをオートコンプリートとして使う」から「AIを指示し、確認するワーカーとして使う」への転換を意味します。インターフェースの変更は小さいものの（一つのスラッシュコマンド）、その意味合いは大きいです。開発者としてのあなたの仕事は、実際のコード行をタイプすることから、より良い成功基準と制約を書くことへと移行します。
これから最大限の恩恵を受けるチームは、すでにテスト可能な契約、堅牢なCI、そして明確な仕様を持っているチームです。もしあなたのAPIが定義されたOpenAPIドキュメントとテストスイートを持っているなら、/goalエージェントにエンドポイントと期限を渡すことができます。もしあなたのAPIが誰かの頭の中にしか存在しない場合、エージェントには検証すべきものがなく、ループは破綻します。
ここにAPIプラットフォームがAIワークフローにとって基盤となるインフラとなる場所があります。ApidogはデザインファーストのAPI開発を中心に構築されており、実装を行うエージェントがあなたの仕様を読み込み、テストケースに対して自身の作業をチェックできる場合、その有用性は格段に高まります。上記の契約ファーストワークフローをセットアップしたい場合は、Apidogをダウンロードしてください。
よくある質問
/goalはCodexウェブアプリで動作しますか？ はい、動作します。Codex CLI、Codexデスクトップ、Codexアプリ、Claude Code CLIで動作します。Hermesも同じコマンドをサポートしています。ベンダー間の機能パリティがポイントです。
/goalは通常のプロンプトとどう異なりますか？ 通常のプロンプトは一回のターンで実行され、停止します。/goalは、各ステップの後に停止条件をチェックするバリデーターモデルとともにクローズドループで実行されます。停止するかどうかはあなたではなく、エージェントが決定します。
エージェントは私が設定した制約を破ることができますか？ バリデーターは各イテレーションで制約を強制するため、エージェントはそれを違反すべきではありません。実際には、制約の表現が緩いほど、エージェントがそれを解釈する余地が大きくなります。明確にしてください：「/authディレクトリ外のファイルを変更しない」は強制可能ですが、「何も壊さない」は強制可能ではありません。
/goalは通常のClaudeまたはCodexセッションよりも費用がかかりますか？ はい、かかります。より多くのトークンを消費すると予想されます。バリデーターはより安価で小型のモデルで動作しますが、メインモデルは引き続き作業を行い、自律的にその多くを実行します。予算を設定するか、/pauseを使用して費用を管理してください。
エージェントの出力を実際のAPIに対してテストしたい場合はどうすればよいですか？ Apidogのようなツールを使用してAPI契約を固定し、実装に対して実際のテストケースを実行します。エージェントのバリデーターはApidog CLIを呼び出すことができ、これにより測定可能な最終状態が得られます。限られた予算でClaudeを活用したサービスを立ち上げている場合は、無料のClaude APIガイドをご覧ください。