私は AI コーディングエージェントをチャットウィンドウというよりも、契約を結んだ労働者として扱うようになり始めました。その違いはモデルにあるのではありません。違いは、エージェントが何を続けべきか、どのように進捗を証明するか、そしていつ停止すべきかを知っているかどうかです。
そこで重要になるのが /loop と /goal です。
Claude Code は現在、これらの概念を直接的に公開しています。/goal は完了条件用、/loop はセッションが開いている間、プロンプトを繰り返すためのものです。OpenAI Codex には文書化されたコマンドとして /goal があり、OpenAI はまた評価駆動型の改善ループをワークフローとして文書化しています。重要な詳細として、インストールされたコマンドリストにそれが表示されない限り、OpenAI Codex が同じ公式の /loop スラッシュコマンドを持っているとは言えません。私が確認した現在のドキュメントでは、/goal が公式であり、「loop」はパターンです。
この区別は重要です。これらのツールは外見上似て見えますが、私は異なる仕事のためにそれらを使用しているからです。
簡潔な答え
明確な条件が真になるまで、エージェントが一つの永続的な結果を追求すべき場合は /goal を使用します。
セッションが開いている間、間隔または自発的なリズムでプロンプトを繰り返すべき場合は /loop を使用します。
出力をスコア付けし、繰り返し改善できる場合は評価駆動型ループを使用します。コード品質、視覚的品質、パフォーマンス、SEO、移行、テスト、あるいは各パスを測定できるあらゆるタスクです。
実践的なルールは単純です。ゴールにはfinish line（終点）が必要であり、ループにはcadence（リズム）が必要であり、その両方に検証が必要です。
Claude Code の /goal の機能
Claude のコマンドリファレンスでは、/goal [condition|clear] は、その条件が満たされるまで Claude がターンをまたいで働き続けるように条件を設定する方法として説明されています。フックのドキュメントには有用な実装詳細が追加されています。/goal はセッション範囲の停止条件のための組み込みショートカットのように動作します。
平易な英語で言えば、/goal は Claude にこう伝えます：
それは強力ですが、条件が具体的である場合にのみ有効です。
弱い例：
text /goal Make the app better
有用な例：
text /goal Fix the checkout bug, keep all existing payment behavior intact, and stop only when pnpm test, pnpm build, and the Playwright checkout path all pass.
2 つ目のバージョンは、Claude にターゲット、境界、そして証明を提供します。パスを決定することはできますが、途中で成功の定義を変更することはできません。
私は以下のような仕事に /goal を使用します：
タスクに複数の無関係な結果がある瞬間、私は 1 つの大きなゴールを使用しません。それを分割します。結果ごとに 1 つのゴールの方がクリーンで、信頼しやすいです。
Claude Code の /loop の機能
Claude のコマンドリファレンスでは、/loop [interval] [prompt] をバンドルされたスキルとしてリストしています。これはセッションが開いている間、プロンプトを繰り返し実行します。間隔を指定したり、Claude に自発的なペースを任せたり、プロンプトを省略して利用可能な場合に構成されたメンテナンスプロンプトを使用させたりできます。
これにより、/loop は /goal よりも運用的な感覚になります。
例：
text /loop 5m check if the Vercel preview deployment is ready, then verify /blog and /api/health
text /loop take the next unchecked item in PRODUCTION_READINESS.md, fix it, run the relevant test, then update the checklist
text /loop every 10m check CI, summarize failures, and stop escalating only after the latest run is green
最も良いユースケースは、繰り返しチェックまたは繰り返し的小規模な作業単位です。私の hybrid AI code review loop→ において、有用なパターンは「永遠に書き続ける」ことではありませんでした。それは：チェックリストの 1 つの項目を取り、実装し、別のモデルにレビューを依頼し、ビルドを実行し、ボックスにチェックを入れ、繰り返すというものでした。
それが、怠惰なプロンプトを書いた場合に /loop が危険になる理由です。プロンプトが何を検証するかを明記していない場合、エージェントは誰も信頼すべきではないもっともらしい作業を続けられることになります。
OpenAI Codex の /goal の機能
OpenAI はアプリと CLI の両方で Codex 用の /goal を文書化しています。Codex ガイドでは、これを長期間実行される作業のための永続的な目標として位置づけており、特にタスクに明確な成功条件と検証ループがある場合に適しています。
Codex CLI コマンドリファレンスでは、/goal をタスクゴールの設定、一時停止、再開、表示、またはクリアするためのコマンドとしてリストしています。アプリのドキュメントも製品用語で同じアイデアを述べています。ゴールは永続的であり、可視であり、一時停止または再開可能です。
良い Codex ゴールは、良い Claude ゴールとほぼ同じように見えます：
text /goal Complete the Next.js 16 migration without changing public routes. Stop only when pnpm build passes, the homepage loads, /blog loads, and the changed routes return 200.
Codex については、以下を明示するゴールが好きです：
困難な問題に対する OpenAI 自身のガイダンスは、私がすでに行っている働き方に近いものです。Codex に評価システムを与え、焦点を絞った改善を行い、スコアを再実行し、アーティファクトを検査し、スコアが十分に良くなるまで続けさせるのです。
それがエージェント作業の核心です。それ自体のための自律性ではありません。測定に結びついた自律性です。
OpenAI には /loop があるのか？
ここで人々は言葉遣いいがおろそかになりがちです。
Claude Code には文書化された /loop コマンドがあります。OpenAI Codex には、評価ループ、修復ループ、検証付きゴールモード、フック、および自動化など、ループスタイルのワークフローが文書化されています。しかし、私が確認した現在の Codex スラッシュコマンドリファレンスでは、/goal、/plan、/review、/status、/mcp、およびその他多くが見つかりましたが、Claude のものと同等の公式な /loop コマンドは見つかりませんでした。
したがって、私の表現は以下の通りです：
それは弱点ではありません。それは私がそれをどのようにセットアップするかを変えるだけです。Codex では、通常、ループをゴールまたはプロンプト内で表現します：
text /goal Improve this component until the visual regression score is above 95%. Make one focused change at a time, run the screenshot comparison after each change, keep a score log, and stop when the target holds twice in a row.
これにより、別個の /loop スラッシュコマンドがあるふりをすることなく、Codex に同じ動作リズムを与えます。
私の実践的なセットアップ
真剣な作業のために、私は 5 層のパターンを使用します。
1. 書かれたターゲット
短い計画またはチェックリストから始めます。`PLAN.md`、`PRODUCTION_READINESS.md`、GitHub のイシュー、または単純なプロンプトのいずれでも構いません。形式よりも重要なのはチェック可能性です。
弱いタスクは「記事システムを改善する」と言います。
強いタスクは「外部 URL が 404、ソフト 404、間違った content-type、または間違ったターゲットへのリターンを返す場合に公開を防止し、ドラフト保存は許可されたままにし、ビルドと焦点を絞った検証ケースで証明する」と言います。
それがエージェントが行動し続けることができる種類の指示です。
2. 一人の所有者モデル
誰が主導するかを選びます。Claude が実装者かもしれません。Codex が実装者かもしれません。worktrees または厳格な受け渡しがない限り、両方が同時に同じファイルを編集することは許さないでください。所有権のない自律性は、マージ競合の劇場になります。
3. 第二の意見
よりリスクの高い作業については、モデル間レビューを依然として好みます。私は AI peer-review bridge→ について書きましたが、それは単一のモデルが自分自身をチェックするよりも異なる失敗モードを捕捉するからです。
レビュアーは読み取り専用でも構いません。有用であるために書き込みアクセスは必要ありません。必要なのは、diff、ゴール、リスクのあるファイル、そして「これは間違っている」と言う許可です。
4. 硬い検証者
テストは自信に勝ります。ビルドは要約に勝ります。ブラウザのスクリーンショットは「レンダリングされるはずだ」に勝ります。ログは雰囲気に勝ります。
Web 作業の場合、通常は以下を意味します：
bash pnpm build pnpm lint pnpm test
さらに、タスクがユーザー向けである場合は、ルートチェック、スクリーンショット、または Playwright フローを追加します。
コンテンツワークフローの場合、私の好みは公開前の URL QA です。単に「リンクが 200 を返したか」だけでなく、「記事が主張したページに到達したか」も確認します。それは同じ原則です。検証者は、読者が実際に体験するものを検証すべきです。
5. 停止ルール
これが人々が飛ばす部分です。
停止ルールのないループは高価になります。停止ルールのないゴールは曖昧になります。停止ルールは退屈で文字通りであるべきです：
最後の行は重要です。良いエージェントは不確実性を隠しません。それを表面化させます。
それぞれをいつ使用するか
| 状況 | 最適なツール | 理由 |
|---|---|---|
| --- | ---: | --- |
| 完了の明確な定義を持つ 1 つの大きなタスク | /goal | エージェントが永続的な終了状態に向かって動き続けられるため |
| 数分ごとにデプロイステータスを確認する | Claude /loop | 同じチェックを繰り返し実行する必要があるため |
| スコアに対して生成されたアーティファクトを改善する | 評価ループ | スコアがエージェントに最後のパスが何かを改善したかどうかを伝えるため |
| チェックリストを項目ごとにクリーンアップする | /loop または /goal | 繰り返し項目には /loop を、最終結果には /goal を使用 |
| 方向性が不確実な調査 | 通常のプロンプトまたはプランモード | ターゲットが明確になる前に自律性を開始しない |
| 機密性の高い本番環境アクション | 人間の承認ゲート | エージェントはアクションを準備できるが、静かに実行すべきではない |
コピー＆ペースト用プロンプト
Claude Code /goal
text /goal Finish this bug fix without changing unrelated behavior. First read AGENTS.md and the relevant route/component files. Make small commits in logic only, run pnpm build and the focused regression path, and stop only when the original bug no longer reproduces and all verification passes.
Claude Code /loop
text /loop take the next unchecked item in TODO.md, inspect the real files first, make one focused fix, run the relevant validation command, update the checkbox only after verification, and report any blocker instead of skipping it
OpenAI Codex /goal
text /goal Complete the migration described in PLAN.md. Preserve public behavior, keep unrelated files unchanged, run the listed validation commands after each milestone, keep a short progress log, and stop only when every milestone is complete and the final build passes.
Codex 評価駆動型ループプロンプト
text I want this as an eval-driven improvement loop. Find or create the command that scores the output. Make one focused improvement at a time, re-run the score after each change, inspect any generated artifact directly, log score changes, and keep iterating until the target score is reached twice in a row. If the score stops improving, explain the bottleneck and stop.
よくある間違い
最初の間違いは、/goal を動機づけの文として使用することです。「これを本番対応にする」はゴールではありません。それは気分です。
2 つ目の間違いは、検証者なしで /loop を使用することです。すべてのイテレーションが未確認の主張で終わる場合、そのループは単なる繰り返しです。
3 つ目の間違いは、無関係な作業を束ねることです。「認証を修正し、ダッシュボードを再設計し、価格を更新し、SEO をクリーンアップする」は、1 つの英雄的な自律実行ではなく、4 つのタスクであるべきです。
4 つ目の間違いは、エージェントがリポジトリのルールを理解する前に書き込みアクセスを与えることです。私の自身のプロジェクトでは、エージェントに `AGENTS.md` を読み込ませ、デプロイルールを尊重し、シークレットを回避し、成功を主張する前に検証させることを望みます。モデルの周りの制御層はモデル自体と同じくらい重要です。それが私が MCP developer workflows→ に立ち返り続ける理由です。ツール、権限、証拠、そして再生可能なアクションこそが、巧妙なチャットを運用システムに変えるものです。
真の要点
/loop と /goal について興味深いのは、スラッシュコマンドの構文ではありません。興味深いのは責任のシフトです。
通常のプロンプトは言います：私に答えて。
ゴールは言います：これを完了させよ、そして完了が何を意味するかを知れ。
ループは言います：条件が変わるまでチェックまたは改善を続けよ。
それが私が AI コーディングエージェントに働いてほしい方法です。魔法としてではなく。監督のない混沌としてではなく。契約、検証者、そしてクリーンな停止ルールを持つ労働者としてです。
Claude Code を使用している場合、/loop は繰り返し運用的なチェックを、あなたが働き続けている間にエージェントが処理できるものに変える最速の方法です。/goal は、作業に 1 つの永続的な終了状態がある場合により良いツールです。
OpenAI Codex を使用している場合、/goal は永続的な目的を与え、ループは検証設計の中に属します：テスト、評価、アーティファクト、フック、進捗ログ、そしてエージェントが静かに再定義できない停止条件です。
それが私が信頼するパターンです。「AI に走らせる」のではなく、「AI に『ノー』と言えるシステム内で走らせる」ことです。
確認したソース
---