DEV Community

Cover image for /goal コマンド: CodexとClaudeを24時間365日自律エージェントとして実行する方法
Akira
Akira

Posted on • Originally published at apidog.com

/goal コマンド: CodexとClaudeを24時間365日自律エージェントとして実行する方法

過去6週間で、主要なAIラボは同じプリミティブを相次いでリリースしました。AnthropicはClaude Codeに /goal を追加し、OpenAIはCodex CLIとCodexデスクトップアプリに搭載し、Nous ResearchはHermesに組み込みました。この命名の一致は偶然ではありません。業界は「測定可能な最終状態に到達するまで、逐一承認を求めずにクローズドループで実行するエージェント」という共通インターフェースに収束しつつあります。

今すぐApidogを試す

これまで「承認する → プロンプトを送る → 続行を指示する → 繰り返す」という作業を手動で行っていたなら、/goal はそのループをエージェントに渡すためのスラッシュコマンドです。目標を与えると、エージェントは達成条件を満たすまで作業し、完了後に結果を返します。

この記事では、開発者とAPIビルダー向けに次を解説します。

  • /goal が内部で何をしているのか
  • CodexとClaude Codeでの設定方法
  • 無限ループを避けるプロンプト構造
  • Apidog を使ってAPI開発ワークフローに組み込む方法

後半のAPI例を試す場合は、Apidogを無料でダウンロードしてください。

/goal が実際にしていること

/goal は、AIエージェントに「停止条件が満たされるまでタスクを自律的に繰り返す」実行モードを与えます。

基本的な流れは次のとおりです。

  1. メインエージェントが次の作業を実行する
  2. 小型で高速なバリデーターモデルが結果を確認する
  3. バリデーターが「目標は達成されたか？」を判定する
  4. 未達ならメインエージェントが続行する
  5. 達成済みならループを終了し、結果を報告する

通常のエージェント利用との違いは明確です。

  • /goal なし：あなたがループを管理する。出力を読み、正しいか判断し、次の指示を出し、ツール呼び出しを承認する。
  • /goal あり：エージェントがループを管理する。計画、実行、自己検証を行い、完了・制約到達・予算超過時だけ結果を返す。

たとえばClaude Codeに次のように指示します。

/goal create a landing page
Enter fullscreen mode Exit fullscreen mode

この場合、調査、実装、スタイリング、デバッグ、プレビュー確認までを連続実行できます。あなたは途中の承認作業から離れ、最後に成果物を確認してリリースまたは修正判断を行います。

なぜ /goal が急に広がっているのか

長期実行のエージェントタスクは、主に2つの理由で失敗していました。

  1. ドリフト
    • 元の目標に対して継続的に検証しないと、モデルは徐々に目的から逸れます。
  2. 付きっきり運用
    • モデルが作業できても、ユーザーが各イテレーションを監視する必要があると、自律エージェントの価値が下がります。

/goal はこの問題に対して、バリデーターモデルをループ内に置きます。

バリデーターは小型モデルで十分なため比較的安価で、役割も限定的です。重要なのは、タスクに明確な停止条件を与えることです。これにより、エージェントは「終わったつもり」ではなく、定義された成功条件に基づいて停止できます。

Codexで /goal を設定する

Codex CLIでは、比較的細かく制御できます。最小構成は次のとおりです。

1. デスクトップアプリでGoalsを有効化する

Codexデスクトップを開き、設定画面で次を有効にします。

goals = true
Enter fullscreen mode Exit fullscreen mode

CLIはこの設定を継承します。

2. CLIをフルオートモードで起動する

承認プロンプトで止まらないように、次のように起動します。

codex --approval-mode full-auto
Enter fullscreen mode Exit fullscreen mode

3. 目標を設定する 

/goal [your goal here]
Enter fullscreen mode Exit fullscreen mode

Codexは目標が登録されたことを表示し、そのまま実行を開始します。

Codex goal example

CLIに慣れていない場合は、Codexデスクトップアプリから始めるのが安全です。機能は同じですが、一時停止、クリア、トークン使用量の確認をUIから行えます。

Claude Codeで /goal を設定する

Claude Code CLIでも基本は同じです。

CLIを起動し、次の形式で入力します。

/goal [task description]
Enter fullscreen mode Exit fullscreen mode

公式情報は Claude Codeドキュメントサイト で確認できます。

Claude Code goal example

Claude Codeの起動時にセットアップや設定エラーが出る場合は、無効なcustom3pエンタープライズ設定の修正が参考になります。

また、/goal と組み合わせてマルチエージェント構成でClaude Codeを使う場合は、Claude Code上のマルチエージェントレイヤーであるRufloの解説も確認してください。

実行中は、出力だけでなくトークン使用量も見てください。進捗がないままトークンだけ消費している場合、バリデーターが収束できていない可能性があります。その場合は次のいずれかを実行します。

/pause
Enter fullscreen mode Exit fullscreen mode

または

/goal clear
Enter fullscreen mode Exit fullscreen mode

実用的な /goal プロンプトの構造

/goal の構文自体は簡単です。難しいのは、エージェントが正しく停止できる目標を書くことです。

有効な /goal プロンプトには、次の3要素を入れます。

  1. 作業内容
    • 何をするのか
  2. 測定可能な最終状態
    • 何をもって完了とするのか
  3. 制約
    • 守るべき境界条件

基本形は次です。

/goal [do the work] until [measurable end state] without [constraints that must hold]
Enter fullscreen mode Exit fullscreen mode

コーディングタスクなら、次のように書けます。

/goal fix every failing test until npm test exits 0 without modifying any file outside the /auth directory
Enter fullscreen mode Exit fullscreen mode

このプロンプトでは、成功条件と制約がどちらも検証可能です。

  • 成功条件：npm test が終了コード 0 で終わる
  • 制約：/auth ディレクトリ外のファイルを変更しない

バリデーターはテストコマンドとファイル差分を確認できるため、エージェントは曖昧に「完了」と言い張れません。

一方、次のような目標は /goal に向きません。

/goal make this UI feel modern
Enter fullscreen mode Exit fullscreen mode

「モダン」が測定できないためです。使うなら、次のように成功条件を具体化します。

/goal improve the UI until Lighthouse accessibility score is at least 90 without changing existing routes
Enter fullscreen mode Exit fullscreen mode

長いタスク向けのプロンプト形式

大きなタスクでは、1行ではなくブロック形式にします。

/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]
Enter fullscreen mode Exit fullscreen mode

この形式にすると、バリデーターが各ループで確認すべき項目が明確になります。

成功基準がない場合、バリデーターは曖昧な意味的マッチングに頼ります。そこからドリフトが起きます。

使える /goal 例

/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
Enter fullscreen mode Exit fullscreen mode

ポイントは、最終成果物が明確なことです。

  • ソースを保存する
  • Markdownテーブルにする
  • 10件以上のベンチマークを含める

リポジトリ保守 

/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
Enter fullscreen mode Exit fullscreen mode

削除そのものではなく、根拠付きのPR説明を作らせるため、安全にレビューできます。

ドキュメント整備 

/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
Enter fullscreen mode Exit fullscreen mode

READMEの品質を「各手順にコマンドと期待出力があるか」で検証できます。

機能開発 

/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
Enter fullscreen mode Exit fullscreen mode

この場合の成功条件は次です。

  • ページリロードなしで切り替わる
  • localStorage に保存される
  • リフレッシュ後も設定が維持される

共通点は、すべての例で「検証可能な完了条件」を持っていることです。これが、完了する目標と堂々巡りする目標の違いです。

/goal とAPI開発ワークフローを組み合わせる

/goal はAPI開発と相性が良いです。APIには、検証可能な完了条件を作りやすいからです。

たとえば、APIエンドポイントの完了条件は次のように定義できます。

  • リクエストが 200 を返す
  • レスポンススキーマがOpenAPI定義と一致する
  • エラーケースが仕様どおりに返る
  • テストケースがすべてパスする
  • ドキュメントが更新されている

実践ワークフロー

1. ApidogでAPI契約を設計する

Apidogで次を定義します。

  • エンドポイント
  • リクエストスキーマ
  • レスポンススキーマ
  • サンプルペイロード
  • テストケース

これを信頼できる唯一の仕様として扱います。

2. OpenAPI仕様をエクスポートする

ApidogからOpenAPI 3.xをエクスポートし、CodexまたはClaude Codeにコンテキストとして渡します。

3. /goal を実行する

たとえば次のように指示します。

/goal implement the user creation endpoint until all Apidog test cases pass without changing the exported OpenAPI contract
Enter fullscreen mode Exit fullscreen mode

4. バリデーターにテストを実行させる

各ループで、バリデーターが実行中サービスに対してApidogのテストを実行します。

成功条件を「すべてのテストケースがグリーンになること」にすれば、エージェントは仕様を満たすまで終了できません。

この方法は、エージェントにテストケースを自由に作らせるより安全です。先に契約が固定されているため、仕様上のエッジケースを見落としたまま「テストは通った」と判断しにくくなります。

Apidogを使ったことがない場合、これは設計、モック、テスト、ドキュメント作成を統合するAPIプラットフォームです。/goal は、バリデーターが1つのコマンドで状態を確認できる場合に特に機能します。

契約ファーストの設計については、デザインファーストのAPIワークフローガイドを参照してください。テストケースの構成については、QAエンジニア向けのAPIテストツール概要が参考になります。

MCPサーバーを扱っている場合も、同じ考え方を適用できます。AIコーディングツールが外部ツールを呼び出す環境では、ローカルMCPサーバーに対して安全にテストを実行できる構成が必要です。詳しくは ApidogでのMCPサーバーテスト を確認してください。

本番運用で役立つ /goal のコツ

実際に使うと、次のポイントが重要になります。

一度に1つの目標だけ実行する

CodexとClaude Codeは、アクティブな目標を1つに制限しています。

複数の目標を重ねると状態が不安定になります。実行間では必ずクリアします。

/goal clear
Enter fullscreen mode Exit fullscreen mode

先に /plan を使う

長いタスクでは、いきなり /goal を投げるより、先に計画を作らせる方が安定します。

/plan implement the billing webhook endpoint
Enter fullscreen mode Exit fullscreen mode

計画を確認した後、その計画をコンテキストにして /goal を実行します。

これにより、エージェントがループ途中で方針を変えるリスクを減らせます。

progress.md をスクラッチパッドにする

エージェントに進捗ログを残させます。

Maintain progress.md with completed steps, current hypothesis, failed attempts, and next action.
Enter fullscreen mode Exit fullscreen mode

メリットは2つあります。

  • 人間が後から監査しやすい
  • エージェントがイテレーション間で文脈を保持しやすい

モデルに /goal を書かせる

大まかな意図だけを通常プロンプトで伝え、モデルに成功条件付きの /goal に変換させるのも有効です。

Convert this task into a /goal prompt with measurable success criteria and strict constraints:
[rough task description]
Enter fullscreen mode Exit fullscreen mode

モデルは、バリデーターが実際に確認できる条件に落とし込むのが得意です。

閉じないループは成功条件を見直す

ループが終わらない場合、問題は多くの場合、成功条件が測定不能であることです。

悪い例：

until the code is clean
Enter fullscreen mode Exit fullscreen mode

良い例：

until npm run lint exits 0 and npm test exits 0
Enter fullscreen mode Exit fullscreen mode

曖昧な条件のまま再試行せず、測定可能な条件に書き換えてください。

小さいタスクには使わない

/goal は長めの作業向けです。

1行の修正や小さなリファクタリングでは、通常のプロンプトの方が速いです。自律ループにはオーバーヘッドがあります。

/goal が向かないケース

/goal には制限もあります。

コストが増える

1時間回るループは、手動で同じ作業を進めるより多くのトークンを消費します。予算を決め、必要なら途中で停止してください。

/pause
Enter fullscreen mode Exit fullscreen mode

検証シグナルがないタスクには弱い

次のようなタスクは、明確なバリデーターを作りにくいです。

  • UXの微調整
  • 文章のトーン調整
  • デザインの好み
  • ブランド感の改善

この場合は、通常のプロンプトで反復した方がよい場合があります。

外部副作用には厳格な制約が必要

次を含むタスクでは特に注意が必要です。

  • メール送信
  • 支払い処理
  • 本番API呼び出し
  • データ削除
  • 顧客環境への変更

エージェントは自動的に慎重な振る舞いを推測しません。明示的に制約してください。

AIエージェントがAPIを呼び出す際のアクセス制御や利用管理を検討している場合は、チーム向けGitHub Copilotの利用状況と課金APIに関する記事も参考になります。

コンテキストが古くなる

長時間実行中にコードベースが変わると、エージェントは古い前提のまま作業する可能性があります。

その場合は続行させず、一度停止してコンテキストを更新してください。

AIを使った開発で変わること

/goal は、AIを「オートコンプリート」として使う段階から、「指示して検証するワーカー」として使う段階への移行を示しています。

インターフェース上は1つのスラッシュコマンドですが、開発者の役割は変わります。

これまで重要だったのは、コードを直接書くことでした。今後さらに重要になるのは、次を正しく定義することです。

  • 成功条件
  • 制約
  • テスト可能な契約
  • 自動検証の仕組み

最も恩恵を受けるのは、すでに次を持っているチームです。

  • 明確なOpenAPI仕様
  • 再現可能なテストスイート
  • CIで実行できる検証コマンド
  • 実装と契約の差分を検出する仕組み

APIがOpenAPIドキュメントとテストスイートを持っていれば、/goal エージェントに「このエンドポイントを実装し、すべての契約テストを通す」と依頼できます。

逆に、API仕様が誰かの頭の中にしかない場合、エージェントには検証対象がありません。その場合、ループは破綻しやすくなります。

ここでAPIプラットフォームがAIワークフローの基盤になります。Apidog はデザインファーストのAPI開発を中心に構築されています。エージェントが仕様を読み込み、テストケースに対して自身の作業を検証できる状態を作ることで、/goal の実用性は大きく上がります。

契約ファーストのワークフローを構築する場合は、Apidogをダウンロードしてください。

よくある質問

/goal はCodexウェブアプリで動作しますか？

はい。Codex CLI、Codexデスクトップ、Codexアプリ、Claude Code CLIで動作します。Hermesも同じコマンドをサポートしています。ベンダー間で同じようなインターフェースが広がっている点が重要です。

/goal は通常のプロンプトと何が違いますか？

通常のプロンプトは1ターンで実行され、そこで止まります。

/goal は、各ステップ後にバリデーターモデルが停止条件を確認するクローズドループです。止めるか続けるかを、ユーザーではなくエージェント側が判断します。

エージェントは制約を破ることがありますか？

制約はバリデーターが各イテレーションで確認します。ただし、制約が曖昧だと解釈の余地が生まれます。

良い制約：

without modifying any file outside the /auth directory
Enter fullscreen mode Exit fullscreen mode

悪い制約：

without breaking anything
Enter fullscreen mode Exit fullscreen mode

強制可能な形で書くことが重要です。

/goal は通常のClaudeやCodexセッションより高コストですか？

はい。より多くのトークンを消費する可能性があります。

バリデーターは小型モデルで動いても、メインモデルは自律的に多くの作業を行います。予算を設定し、必要に応じて /pause を使ってください。

エージェントの出力を実際のAPIに対してテストするには？

Apidog のようなツールでAPI契約を固定し、実装に対して実際のテストケースを実行します。

エージェントのバリデーターがApidogのテストを呼び出せるようにすれば、測定可能な最終状態を作れます。

Claudeを活用したサービスを低予算で立ち上げる場合は、無料のClaude APIガイドも参照してください。

Top comments (0)