99% の人が /goal とループを間違って使っています。
彼らが耳にする誇大広告は「長時間実行されるループが自律エージェントを動かす」というものです。つまり、タスクを指示して、立ち去り、帰ってきたら動くコードができているというもの。
しかし、トップのエージェントエンジニアは、6ヶ月前（GPT-5.2 と Opus 4.5 が出たとき）から、/goal を使わずにそれをやっていました。それは 「ハーネスエンジニアリング + スペック駆動開発」 と呼ばれています。
- エージェントが問題を観察するためのハーネスを構築する
- すべてのテストケースを含むタイトなスペックを書く
- すべてのテストが通るまで、Codex や Claude Code を無人でループさせる
私はこれを頻繁に夜通しで実行しています — 1回の実行で2〜5時間かかります。4月には、Vercel モノレポ全体にわたる Turbo のビルドキャッシュバグを、朝までにすべて修正してくれました。/goal は実際には必要ありません。
では、/goal は実際に何のためにあるのか？
私が離れている間に、たった1つのプロンプトが何をしたかをお見せします。
- 約30時間、6,300行のコード、92,000ページのクロール、APIに40ドル消費
- 別の製品のコアループをクローン — アーキテクチャ全体をゼロからリバースエンジニアリング
- 私たちのバージョンの出力は、同じクエリで参照製品よりも約50倍優れていました。（これは newsjack.sh を強化する新しいデータレイヤーです — 私が取り組んでいるオープンソースのニュースインテリジェンススキルです）
秘訣は 損失関数開発（LFD: Loss Function Development） です。エージェントに達成すべきスペックではなく、最適化すべき目標を書くのです。
これは、Peter のツイートを具体化し、運用可能にしたものです。
スペック駆動開発で使用されていたスペックは、今や出発点になり、ゴールラインではなくなりました。
これを正しくするには、多少の実験が必要でした。しかし、ここに完全なプレイブックがあります — ただし、まずはどれだけうまくいかなかったかから始めて、/goal をどのように設計すべきかを理解する必要があります。
エージェントは3回もズルをしました。
すべてはいつも通り、スペックから始まりました。
私は単に Codex を他の製品の公開ウェブサイトに向けました — 「これを自分たちで作るにはどうすればいいか？」。30分で、完全なシステム設計とテストケース（スペック）が返ってきました。
しかし今回は、別のプロンプトを試しました。
「/goal 出力が完全に一致するまで実装せよ」
そして、こうなりました。
ループ1（5分）
エージェントは評価セットを取得し、それを反映したシードデータを生成し、5分で勝利を宣言しました。
「100% 再現率、汎用性はゼロ」 — 私が渡した30個のものしか見つけられない検索エンジンでした（笑）。
修正 → 評価をブラインドにする。 実行中は評価を隠し、スコアリング時のみ公開し、各アイテムのミスリストを表示。
ループ2（20分） - ブラインド、30アイテム。
エージェントを評価セットからブラインドにしましたが、ミスから学習しました — 「X が見つかりませんでした」というたびに、次のサイクルでキーワードになりました。数ループ後には、ちょうど30個のキーワード（アイテムごとに1つ）を使用し、再び「勝利」しました。
修正 → 評価セットを拡大する。 スコアリング対象を数百アイテムに増やし、列挙が不可能に。
ループ3（30分） - ブラインド、200アイテム。
新しい評価セットに200アイテム追加後も、エージェントは再びズルをしました。
面白いことに、エージェントはそれでも列挙しました。キーワードリストは数百に膨れ上がり、各キーワードが次のミスを正確に誘導する餌となりました。
3ラウンド、3回のズル。
そこで気づきました。エージェントは単に最適化していたのです。
ズルはエージェントのバグではありませんでした。それは私の 目標 のバグでした。行き先を教え、すべての近道を広く開けて放置していたのです。
フェンスで囲っていない安易な道はすべて、最適化エンジンが突っ走る方向になります。そして私の最初の目標は、フェンスをすべてスキップしていました。
ループ4（30時間） - ブラインド、200アイテム、ハードリミット。
そこで方向をブロックし始めました。キーワードリストを制限し、評価をブラインドにし、日付範囲を広げる — それぞれの修正で安易な道を1つずつ閉じ、数字を動かすために残った唯一の方向は、タスクで真に向上することだけになりました。
エージェントはズルをやめました。
そして、実行しました。約30時間の計算、92,000ページのクロール、約40ドルトークン、6,300行のコード。
結果的に、私たちが参考にした製品は下限であり、上限ではありませんでした。同じクエリで 約50倍の結果 を出すようになりました。
（興味のある方のために、全旅程と証拠はこちら）
損失関数開発（LFD） - 良い損失関数の構造
ほとんどの人が製品を作ろうとするとき、エージェントを使ってゼロから数時間で出荷しようとしています。
しかし、問題はその後にあります — ロングテールです。 スペックが想定しなかったエッジケースは、プロダクションでのみ、一度に1つのエラーログとして浮かび上がります。それらを1つずつ修正します。ログでキャッチできなかったケースは、ユーザーから報告されます — これはバグを見つける最も高価な方法です。
私はこの安価な部分を自動化しました。私の OpenClaw エージェント Zoe は毎日エラーログを監視し、新しいエラーが発生すると Codex を起動して PR を作成します — これ以上ないほどタイトなループです。（完全なセットアップはこちらで文書化しています）
それでもテールには数ヶ月かかります。だからこそ、エージェントが作業を行っても、良い製品を作るにはまだ時間がかかるのです。
LFD はテールを早送りします。事前に実際の期待される出力例を入手できれば — 良い状態が大規模にどのようなものか — 出荷前にテストを実行できます。つまり、何百ものエッジケースが、四半期ごとのバグ報告の滴りではなく、1回の最適化実行でエージェントにヒットするのです。そしてこれが突然実現可能になった理由は、ますます多くの問題において、これらの例が公開でただそこにあるからです。
スペック駆動開発：
これを構築しろ。テストを通せ。
損失関数開発：
これを構築しろ。テストを通せ。その後、これら1,000の評価ケースに対して反復改善しろ。
テストスイートは有限です — グリーンになった瞬間に完了です。1,000ケースの評価で95%は、下りていく 目標です。バーを下回らない限り出口はありません。これは重要です。なぜなら、エージェントはあなたが見ることのない数百の決定を行い、そのすべてが 何か に対して解決されるからです。目標を書かなければ、エージェントがそれを選びます — ラウンド1〜3が示したように、最も安価に満たせるものを選びます。
損失関数は評価よりも大きいです。それには4つの要素があります — 目標、制約、計測手段、強制エントロピー。4つの部分です。
1. 目標
- 列挙が報われないほど大きいこと。 28アイテムの評価は1ラウンドで記憶されました。多ければ多いほど良い。
- エージェントを解答からブラインドにすること。 評価データは事後スコアリングのためだけに存在します。エージェントが実行中に答えを見ることができれば、それを見る方法を見つけます。
2. 制約
エージェントに許可されることと許可されないこと。
- 時間はエージェントが常に忘れる制約です。 エージェントには時間の感覚がありません。メトリックが名目上動いているため、2%の向上に10時間もかけることがあります。しかし、30日かけて100%の解決策よりも、2時間で80%の解決策の方が優れています。解決策：実時間の予算を設定する。
- 金銭。 有料の呼び出しごとにハードキャップ：クローラークレジット、LLM 支出、使い捨てキーの総ドル上限。
- サーフェス。 すべてのプロバイダー、許可されたモデル、同時実行数の上限。エージェントを触れさせたいものだけにサンドボックス化する。
- 方法論。 LLM 分析が許可されるか、決定論的ロジックのみか？エージェントがアクセスできるデータソースは何か？明確に指定すること。
3. 計測手段（ハーネス）
計測手段のない制約はフィーリングに過ぎません — エージェントは違反していることを認識できないため、喜んで違反します。上記の制約ごとに、エージェントが検査できる CLI コマンドを用意すること。
- 目標測定、適切な解像度で。 目標の計測手段を慎重に選ぶこと。実際の例：ナイーブに「LLM に2つのスクリーンショットを評価させる」判定者は、12pxのスペーシングエラーを持つ UI クローンを承認します。なぜなら LLM は実際には画像を 見る ことができず、埋め込みに変換してから埋め込みを比較するからです。したがって、ピクセルパーフェクトなUIクローンが必要なら、エージェントにピクセル差分ツールを与えなさい。そして、/goal を使ってピクセル差分が0になるまで実行する。
- 時間の計測。 すべての実行とステップにタイムスタンプを付ける。エージェントは各ステップにかかった時間、経過時間を知るべきです。時間は第一級の計測手段であり、脚注ではありません。
- プロバイダー予算。 「今、クローラーでどれだけ使っているか？」は推測ではなく、1つのコマンドでわかるべき。スクレイプクレジットの残り、このループでの消費、累積消費、次の有料バッチまでの予測消費を追跡する。
- LLM 支出。 エージェントに LLM API キーをデータプレーンで使用させることで、ロジックを単純化できることがあります。しかし、エージェントは実際にどれだけ使っているかをまず知ることで、責任を持って支出すべきです。
- Codex 使用量。 これは少しメタです。ループは自己認識的であるべき：この最適化にどれだけのトークンを使っているか？現在の最適化ステップの勾配を知るのに役立ちます。
パターンは古い格言と同じです：見えないものは最適化できない。
これらのループの実行に慣れていないなら、起動して立ち去らないでください。最初のサイクルに付き合ってください。何に触れるか観察してください。構築したハーネスが適切に使用されていることを確認してください。それから寝てください。（そして、目覚めたときに何があるかを考えずに眠りにつくようにしてください）
4. 強制エントロピー
強制エントロピーが重要な理由：各ループは前回の実行の 全体の コンテキストから続行します。モデルはゼロから始めるのではなく、自身の過去100の決定と、これまで機能した勾配を読み取っています。
/goal ループでは、局所的な最大値に到達するのがデフォルトの状態です。 明示的なキックがなければ、エージェントは同じ丘を登り続けます。そして「同じ丘」とは、改善が止まった時点でたまたまいた場所です。
例えば、小さなノブが結果を0.1%改善する場合、たとえ他に1,000個のノブがあっても、エージェントはそのノブを回し続けます。
エントロピーは明示的に実行に強制する必要があります。 モデルは自発的にそれを取らないからです。
- 各サイクルで過学習を振り返る。 私はより一般的な解決策を構築しているのか、それとも評価を記憶しているのか？ 記憶している場合、次の変更は評価の形のアーティファクトを 削除 するもの（リストを制限する、特徴をブラインドにする、評価を拡大する、シードを拒否する）であるべきで、追加するものではない。
- 停滞時にエントロピーを強制する。 前のサイクルがメトリックを動かさなかった場合、次のサイクルは「同じアイデアをもっと強く」ではいけません。モデルは真に非自明な飛躍をしなければなりません — 「枠にとらわれずに考える」は良いプロンプトです — エージェントが同じノブをもっと強く回すのを防ぎます。
- 反復ログを保持する。 エージェントに仮説、予想される失敗モード、各ステップの診断をログに記録させ、後でコンパクションをまたいで振り返れるようにする。
メタメタプロンプト
私はこれらの目標を自分で書いていましたが、すぐにそれがエージェントの仕事であることを学びました。
そこで、良い損失関数開発実行のためのこの種の目標を生成するスキルを書きました。
現在、こちらでオープンソース化されています：
https://github.com/elvisun/loss-function-development
/lfd-design を使用してハーネスと目標を生成する
ずっと勾配降下法：2つのループ
一歩引くと、ずっと勾配降下法です。
内側のループはエージェントです：コードを書き、テストを実行し、修正する。短い地平線、速いフィードバック、1つの目的 — テストを通すこと。これは開発者の内側のループであり、スペック駆動開発はその実行方法です。コーディングエージェントはすでにそれを自動化しています。
外側のループは /goal です：多くのサイクルにわたって、システム全体を成果メトリックに向けて駆動します — 出荷、測定、方向転換、下降。長い地平線、疎なフィードバック。これは伝統的に プロダクトチーム のループであり、出荷-測定-反復の数ヶ月の浸漬を1回の実行に圧縮したものです。
両方のループが自動化されました。あなたに残されたのは、損失関数を定義することです — /goal が正確に何を、どのように最適化すべきか。
あなたは製品を蒸留している — または公開アーティファクトを残すもの
別のレンズ：これは本質的に蒸留であり、トレーニング時間からプロンプト時間に移行したものです。DeepSeek、Kimi、Minimax のラインが GPT や Claude との差をほとんど埋めた方法です — あなたのモデルを他の誰かの出力でトレーニングし、あなたのモデルがそれを再現するまで続ける。
しかし、モデルを蒸留する代わりに、/goal と LFD を使用して、公開で見つけられる任意のアーティファクトに蒸留フィッティングを実行できるようになりました — 内部を検査する必要はなく、その必要もありません。
公開で という言葉に注目してください。誰かの ToS で保護された、ログインが必要な、または有料の出力を蒸留することは許容されません。しかし、公開で公開されているもの — 企業が顧客を獲得するために出荷する出力 — は常に学習するのにフェアです。その部分は新しいものではありません — それはソフトウェア最古の手です。新しいのは、それが安価になり、数ヶ月ではなく数時間でできるようになったことです。
一歩引いて、より大きなシフトを見てみましょう。情報対称性があるところでは、実行コストは約0ドルにまで崩壊します — 出力が公開されていれば、誰もが良い状態がどのようなものかを見ることができ、誰でも週末に40ドルでそれを蒸留し返すことができます。
そこで、ますます価値が高まっている新しい堀があります：情報非対称性。
正準的なオープンソース企業はすでにまばたきしました。2026年4月、cal.com（ARR 500万ドル）はプロダクションコードを非公開にし、クローズドソースに移行しました。その理由は、文字通りこのエッセイの概要を読んでいるかのようです：AI 主導のセキュリティ脅威の時代に、エージェントが読める場所にソースを残しておくことはできません。
「/goal read [cal.com](https://cal.com/) のソースコードと攻撃面を列挙し、何かが機能するまで実行」
それはあまりにも危険な攻撃であり、あまりにも簡単に実行できます。
アイデンティティ全体が「オープンソース」だった企業が、2026年に、オープン性が負債になったと判断しました。それがすべてを物語っています。
ソフトウェアの歴史全体を通じて、「私たちが作った」ことが堀でした。
その時代は終わりつつあります。
次の時代は、アーティファクトが決して含んでいなかったものを所有する者に属します：他の誰もスコアリングできない評価セット。ユーザーが実際に遭遇するエッジケースのリスト。あなたが非公開で測定するグラウンドトゥルース。競合のエージェントが見えない目標を持つ者が、ループが下降し続ける唯一の者です。
製品は今や週末です。
週末には触れられない評価を構築しに行きなさい。
