/goal は機能ではありません。プリミティブです。
HTTP はプリミティブです。JSON もプリミティブです。/goal はコーディングエージェントにとって、そのようなものになりつつあります。
数週間前、OpenAI の Codex CLI が /goal を追加し、コーディングワーカーに明確な完了状態を持つジョブを与える方法を提供しました。今週は Claude Code もこれを追加しました。
Hermes Agent は、私が Mac Mini で実行しているオーケストレーターで、コーディングワーカー間の作業を調整するものですが、ずっと以前から /goal を組み込んでいました。
その結果、今ではビルダー、レビューアー、オーケストレーターのすべてが、他に何も共有していなくても、同じ指示フォーマットを受け入れるようになりました。
もし /goal が単なる凝ったプロンプトとして使われているのを見ただけなら、その本質的な変化を見逃していることになります。
/goal の正体
通常のプロンプトは、エージェントに次の応答を求めます。返ってきた内容を読んで、正しいかどうかを判断し、次のステップに進ませます。毎ターン、あなたが操縦しているのです。
/goal はそれを逆転させます。「完了」の状態を書き出し、一度だけ送信すると、エージェントはそこに到達するまで作業を続けます。実際の例を示します：
1/goal SPEC.md に記述されたアプリを構築してください。完了とは、テストがパスし、2ビルドがパスし、README が正確で、git status に関連する3プロジェクトファイルのみが表示される状態を指します。
ゴールは、達成されるか、一時停止されるか、ブロックされるか、クリアされるか、予算を使い切るまでアクティブな状態を保ちます。
これは、通常のワンショットコマンド内に「goal」という単語を入れることとは異なります。codex exec 'goal: build the app' と書いた場合、それはラベルが付いたプロンプトに過ぎません。真のプリミティブは、対話型のワーカーセッションの中に存在します。CLI を起動し、/goal を送信し、そしてその場を離れます。
この変化は、「プロンプト（あなたが操縦する）」から「アサインメント（あなたが定義した目標に向かってエージェントが操縦する）」へのシフトです。
GIF
現在 /goal を採用している 3 つのツール
/goal を受け入れている 3 つのツールは、すべて同じ種類のものではありません。そのため、具体的に説明する価値があります。
Codex は OpenAI のコーディング CLI です。特に明確な仕様が与えられた場合、実装に強みを発揮します。/goal はその仕様を与える方法です。
Claude Code は Anthropic のコーディング CLI です。その逆、つまり正しく見えるコードの問題点を見つけることに強みを発揮します。仕様準拠、安全性の問題、エラー状態、セキュリティホールなどです。/goal はコードを指してレビューを依頼する方法です。
Hermes Agent はまったく異なる種類のツールです。コーディングワーカーではなく、上記 2 つのようなコーディングワーカー間の作業を調整するオーケストレーターです。/goal は、Hermes がタスクをジョブに適したツールに引き継ぐ方法であり、同時に、私が最初に Hermes に希望を伝える方法でもあります。
重要なのは、これらのいずれかが /goal を実装したことではありません。3 つの異なるチームが同じプリミティブに収束したこと、そしてその収束こそが、それらを構成可能にしているのです。
GIF
セットアップ手順
Hermes を実行する Mac Mini に Codex と Claude Code を初めてインストールする必要があったとき、手動でインストールはしませんでした。Hermes に両方をインストールしてログインするようメッセージを送りました。残りは Hermes が処理しました。
これが現在のワークフローです。インストールコマンドを入力する必要はありません。セットアップもまた、別のゴールに過ぎないのです。
まだオーケストレーターを実行していない場合は、Codex と Claude Code のインストールページに従うのは簡単です。しかし、一度オーケストレーターを実行し始めたら、他のツールを手動でセットアップするべきではありません。オーケストレーターを持つ意義は、機械的な作業があなたの手を離れることにあるからです。
Hermes が /goal に追加するもの
生の /goal だけでもそれなりに役立ちます。しかし、それだけでは調整の問題が残ります。
Codex が 1 つのターミナルで実行され、Claude Code が別のターミナルで実行されている場合、どのプロセスが何をしているかを覚えておく必要があります。ログを確認する必要があります。あるツールのレビュー結果を別のツールに手動で渡す必要があります。
Hermes は、これらのバラバラな実行をワークフローに変換します：
- Hermes にメッセージを送る（私の場合は、スマートフォンから Telegram 経由）
- Hermes がカンバンボードにゴールカードを作成する
- Hermes が各カードに適切なワーカーを選択する
- ワーカーがバックグラウンドでゴールを実行する
- カードがプロセス ID、PID、リポジトリ、完了条件を保存する
- ビルドの準備ができたら、Hermes がリポジトリをレビューアーに渡す
- レビューでブロックされた場合、Hermes は修正ゴールとしてレビュー結果を送り返す
- Hermes がファイルシステム、テスト、ビルド、git 状態を検査して最終出力を検証する
ボードこそ、オーケストレーターが /goal を進化させた姿です。すべてのゴールにはカードがあり、すべてのカードにはステータスがあり、すべての引き継ぎには痕跡が残ります。ターミナルを探し回る代わりに、スマートフォン上で作業が列を移動していくのを確認できます。
3 つの役割
ツールは変わります。しかし、役割は変わりません。
オーケストレーター。 制御ループを担当します。タスク分解、ワーカー選択、カンバンカード、バックグラウンドプロセス、依存関係、最終検証、ユーザー向けサマリー。私のセットアップでは Hermes がこれにあたります。
ビルダー。 仕様を受け取り、動作するコードを生成します。この役割が解決するボトルネックは実装です。Codex はここで強みを発揮する傾向があります。
レビューアー。 ビルダーが生成したものを読み、問題点を見つけます。ボトルネックは正確性です。Claude Code はここで強みを発揮する傾向があります。
実際の実行例：エンドツーエンド
Hermes エージェントに次のゴールを与えました：
1/goal 私に関する X での言及を見つけ、何か重大なことが起きたら2私に通知する CLI ツールを構築してください。
Hermes はこのリクエストを 6 つのカードに分解しました。
Shubham Saboo
@Saboo_Shubham_
·
Codex /goal がビルドします。
Claude Code /goal がレビューと改良を行います。
Hermes /goal がオーケストレーションと引き継ぎを管理します。
すべてが単一のカンバンボードで追跡され、エージェントはループ内で実行を続けます。
58
61
852
カード 1：仕様。 Hermes が SPEC.md を自ら作成し、スタック、リポジトリパス、読み取り専用制約、モックモード要件、テスト、検証コマンドを記録しました。PM ロールが担当。
カード 2：Codex がビルド。 Codex が SPEC.md に対して /goal を実行しました。プロジェクトファイルを作成し、UI とバックエンドを実装し、テストを追加し、アプリをパス状態にしました。約 15 分。終了時、npm test がパス、npm run build がパス、git status は関連する新しいファイルのみを表示しました。
カード 3：Claude Code がレビュー。 Claude Code が /goal を実行し、Codex がビルドしたものをレビューしました。仕様準拠、読み取り専用の安全性、API キーの取り扱い、エラー状態、テスト、UI の有用性、バグ、セキュリティ問題をチェック。結果：PASS、ブロックする問題なし。
カード 4：Codex による修正ループ。 レビューがパスしたためスキップ。スキップされた場合でも、このカードは重要です。Hermes が条件付き作業をモデル化できることを示しています。もし Claude Code がブロックしていた場合、Hermes はレビュー結果を新しい /goal として Codex に渡していたでしょう。
カード 5：Claude Code による最終検証。 同じ理由でスキップ。
カード 6：Hermes による最終サマリー。 ローカルパスに動作するアプリ、UI と API の両方がモックモードで検証済み。Codex が /goal でビルド。Claude Code が /goal でレビューし、PASS を返しました。
これらすべては、たった 1 つのメッセージから生まれました。3 つの異なるツールが実際の作業を行いましたが、私がやり取りしたのは Hermes だけです。
検証ルール
Hermes は Codex の自己申告を決して信頼しません。Codex がビルド完了を報告した後、Hermes 自身がコマンドを実行しました：
1npm test # 17 tests passed2npm run build # vite build passed
検証こそが、/goal を「約束」ではなく「契約」に変えるものです。ワーカーの自己申告を最終結果として信頼してはいけません。検証を信頼してください。
コーディングエージェントは自信過剰です。ビルドが実行されたことすらないのに、ビルドがパスしたと伝えてきます。決して実行されなかったテストを書いたにもかかわらず、テストがパスしたと伝えてきます。検証がそのギャップを埋めます。
検証がなければ、/goal は単なる凝ったプロンプトに過ぎません。検証があれば、それは契約になります。
GIF
複数のゴールを実行する
複数の /goal を並行して実行することは可能ですが、事前に検討することなく複数のコーディングワーカーを同じファイルに向けることはできません。
私のデフォルトは、1 つのリポジトリに対して 1 つのメインビルダーです。並列処理を希望する場合は、明確な境界を設けて追加します。異なるリポジトリ、異なるブランチ、git worktree、別々のパッケージ、ドキュメントとコード、テストと実装など、2 つのワーカーが互いに干渉できない場所であればどこでもです。
悪いパターンは、3 つのワーカーがすべて同じリポジトリ内の同じファイルを編集することです。競合、部分的な上書き、そしてあるワーカーが別のワーカーの作業を静かに元に戻すことになります。
より良いパターンは、特定のファイルに対して一度に 1 つのライターだけが作業することです。ビルダーが書き、レビューアーは読むだけ、修正ゴールは修正範囲に限定されます。または、3 つの競合するアプローチで 3 つの worktree に 3 つのビルダーを実行し、オーケストレーターに最良のものを選ばせます。
ボードこそがこれを実用的にします。ボードがなければ、バックグラウンドの並行ワーカーはターミナルの混沌となります。
私にとって何が変わるか
ここで有用な捉え方は、「バックグラウンドでエージェントを実行できる」ということではありません。
それは、たった 1 つのメッセージが 3 つの異なるコーディングツールにまたがるパイプラインに変わり、その全体が 1 つのボード上を移動していくのを確認できる、ということです。
あなたはターミナルに座って 1 つのエージェントが終わるのを待つことをやめ、可視化された状態を持つ作業キューを管理するようになります。
もし Codex と Claude Code がそれぞれ独自のジョブ引き継ぎフォーマットを発明していたら、オーケストレーターはそれらの間でルーティングできませんでした。ボードは印象的ですが、プリミティブがボードをさらに有用なものにしているのです。
ワーカーは変わっても、プリミティブは変わりません。次に /goal を採用するコーディングツールは、私が何も変えることなく、このパイプラインに加わることができます。単にそのツールに作業をルーティングすればよいのです。
それが、良いプリミティブの力です。
Hermes、OpenClaw、Claude Code、Codex、その他の 24 時間 365 日稼働するエージェントチームに関する、このようなクールなヒントや興味深いアイデアをもっとご覧になりたい方は。
こちらをフォロー → @Saboo_Shubham_
