CodexでGoalsを活用する方法

• Goals は、Codexスレッドが定義された結果に向けて複数ターンにわたり作業を継続するための 永続的目標（persistent objective） 機能
• 単一プロンプトでは扱いにくい プロファイリング、パッチ適用、ベンチマーキング、フレイキーテストの再現、根拠に基づく監査 のような作業に適している
• 結果（outcome）、検証手段（verification surface）、制約（constraints）を定義すると、Codexが 証拠に基づいて完了可否を自律的に判断 する
• /goal, /goal pause, /goal resume, /goal clear コマンドで ライフサイクル制御 が可能で、Codex 0.128.0 から対応
• スレッドスコープに限定された 完了契約（completion contract） の構造であり、無制限の自律実行ではなく ユーザー管理下の持続性 が中核

---

Goalsの定義と導入背景

• Goalsは、Codexに 完了条件（completion condition） を与える機能で、何が真であるべきか、成功をどう検証するか、どの制約を維持すべきかを定義する
• Codexはすでに、リポジトリ点検、バグ修正、テスト追加、失敗原因の説明、焦点を絞った変更実装のような スコープが明確なコーディング作業 に適している
• Goalsは、途中でCodexが学んだ内容によって次のステップが変わる作業に向いている
  • プロファイリング、パッチ適用、ベンチマーキング、フレイキーテスト再現、研究課題を証拠ベースの監査へ変換する作業
• このような作業に必要なのは大きなプロンプトではなく 永続的目標 である
• Goalが有効になると、途中結果ごとに目標を言い直さなくても、Codexが目標を保持し、完了可否を評価し、次の行動を選択する
• Goalは境界のないバックグラウンド自律性ではなく、スコープが指定されユーザー管理下にある完了契約 である

Quickstart: Goalsの使い方

• 到達点は明確だが、そこへ至る経路が不確実な作業でGoalを使う
  • 良い候補: 性能最適化、フレイキーテスト調査、依存関係マイグレーション、再現が必要なバグ追跡、多段階リファクタリング、ベンチマークベースのチューニング、最終成果物が必要な研究作業
  • 単発の編集には通常のプロンプトが適している

• インストールとバージョン確認

  • Goalsは Codex 0.128.0 から利用可能
  • npm: npm install -g @openai/codex@latest の後に codex --version
  • Homebrew: brew update && brew upgrade --cask codex の後に codex --version

• Goalの設定とライフサイクルコマンド

  • /goal <結果> 形式で設定。例: /goal Reduce p95 latency below 120 ms without regressing correctness tests
  • /goal: 現在のGoalを表示
  • /goal pause: 有効なGoalを一時停止
  • /goal resume: 一時停止したGoalを再開
  • /goal clear: 現在のGoalを削除

• 停止条件（stopping condition）

  • 成功、一時停止、削除、中断、予算上限到達、ユーザー入力が必要なブロッカー発生時に停止
• 「続けて」「次に可能な修正を試して」「ベンチマークをもう一度回して」「今度はテストを確認して」のような反復指示を毎ターン出す必要がある状況で、Goalはその意図を明示的に表現する

Goals vs プロンプト

• 通常のプロンプト: 「次の作業を実行せよ」
• Goal: 「この結果が真になるまで作業を続けよ」

• 動作の違い

  • 通常のリクエストでは、Codexは即時の指示を実行し、結果を報告して待機する
  • Goalでは、スレッドに 持続的目標（durable target） が付与され、ターン終了後に現在の証拠を確認して目標達成の可否を判断する
  • 達成されておらず、Goalが有効で、予算内であれば、最新状態から作業を継続できる

• 例: /goal Reduce p95 checkout latency below 120 ms on the checkout benchmark while keeping the correctness suite green

  • 測定可能な結果、検証手段、制約を提供する
  • Codexはベンチマーク実行 → ホットパス確認 → 標的変更 → ベンチマーク再実行 → 正確性スイート実行を繰り返し、結果が不十分なら継続する

• メンタルモデル

  • プロンプト: ask → work → result → wait
  • Goal: work → check → continue or complete
• Goalはゴールラインを提供するが、作業は依然として 証拠に照らして監査される（audited against evidence） 必要がある

Goalの書き方

• 良いGoalは大きなプロンプトではなく、Codexがどう作業するか、何が成功か、成功に届かないときにどうすべきかを定義する 簡潔な契約 である

• 強いGoalが定義する6つの要素

  • Outcome: 作業完了時に真であるべきこと
  • Verification surface: それを証明するテスト、ベンチマーク、レポート、成果物、コマンド出力、ソース資料
  • Constraints: Codexの作業中に劣化（regress）させてはならないもの
  • Boundaries: 使用可能なファイル、ツール、データ、リポジトリ、リソース
  • Iteration policy: 試行後に次に何をするかを決める方法
  • Blocked stop condition: 現在の制約内で妥当な経路がなくなったときに報告して停止する時点

• 記述パターン

  • /goal <望ましい終了状態> verified by <具体的な証拠> while preserving <制約>. Use <許可された入力/ツール/境界>. Between iterations, <次善行動の選択方法>. If blocked or no valid paths remain, <報告内容と前進に必要な入力>.

• 弱い例 vs 強い例

  • 弱い: /goal Reduce p95 checkout latency below 120 ms without regressing correctness tests
  • 強い: 検証手段（checkout benchmark）、使用範囲（checkout service、benchmark fixtures、関連テスト）、反復方針（変更内容・ベンチマーク結果・次の実験の記録）、ブロッカー報告条件まで明示する

• 研究・調査向けGoal

  • 正確な証明が不可能な場合があるなら、作業開始前に 証拠基準（evidence standard） を定義する
  • 例: /goal Produce the strongest evidence-backed reproduction of the paper using the available materials and local resources. Attempt the headline results where feasible, verify outputs where possible, and end with a report that separates confirmed findings, approximate reconstructions, blocked claims, and remaining uncertainty.

• Goal作成をCodexに委任

  • 平易な言葉で作業を説明 → CodexにGoal草案の作成を依頼 → 成功条件・検証手段・制約・ブロッカー停止条件を整えてから有効化する、という2段階ワークフローが推奨される

Goal有効化時に変わること

• 目標が継続的に見えている

  • テストが失敗しても、スレッドは元の目標を維持する
  • ベンチマークが改善しても閾値に届かなければ、Codexは作業を続ける
  • 研究経路がデータ不足に突き当たっても、研究基準を失わずに証拠計画を調整する

• アイドル状態のスレッドで継続（continuation）可能

  • 別ターンが実行中、ユーザー入力がキューにある、他スレッドの作業が待機中の場合は継続しない
  • スレッドがアイドル状態で、Goalが有効で、予算内のときにのみ継続する

• 完了は証拠に基づかなければならない

  • モデルが「たぶん終わった」と信じるだけでは完了扱いにできない
  • 関連ファイル、テスト、ログ、ベンチマーク出力、生成成果物、その他の具体的証拠に照らして目標を検査した後にのみ完了できる
• 設計上の核心: Codexは動き続けられるが、完了可否は証拠が決める

Codex内におけるGoalsの設計構造

• Goalsは スレッドスコープの永続状態（persisted thread state） として実装され、グローバルメモリやプロジェクトレベルの指示ではない
  • 目標は、関連コンテキスト（確認したファイル、実行したコマンド、生成したdiff、見たログ、推論記録）を持つスレッドに属する

• アーキテクチャレイヤー

  • 永続的なスレッドスコープ状態として、目標・ライフサイクル・予算・進捗会計を記録する
  • Goal状態: active, paused, complete, budget-limited
  • 状態に応じて、Codexが継続するか、ユーザーを待つか、新規作業の代わりに進捗を要約するかを決める

• 継続（continuation）はイベント駆動

  • 単純なループではなく、安全境界でのみ確認する: ターン終了後、待機作業なし、ユーザー入力キューなし、スレッドがアイドル状態
  • ディスパッチャの動作は保守的: 計画専用タスクでは継続を発火しない、中断時は目標を一時停止、スレッド再開時は適切なら目標を復元、継続ターンでツール呼び出しがなければ次の自動継続を抑制する（スピン防止）

• プロンプティングレイヤー

  • 継続プロンプトは有効な目標を中心にCodexを整列させつつ、完了前の監査を要求する
  • 目標を具体的証拠（変更ファイル、実行コマンド、通過テスト、ベンチマーク出力、生成成果物、研究証拠）と突き合わせる

• 予算（budget）処理

  • 予算到達時は実質的な作業を停止し、進捗とブロッカーを要約し、次に有用なステップを特定する
  • 予算上限到達は目標完了と同義ではない

• ツール契約（tool contract）

  • モデルはGoalの開始が可能で、証拠が完了を裏付ける場合にのみ既存Goalを完了済みにできる
  • 一時停止・再開・削除・予算上限への移行は、ユーザーまたはシステムの制御を維持する

弱いGoalを強いGoalに変換する

• 性能チューニングの例

  • 弱い: /goal Improve performance
  • 強い: /goal Reduce p95 latency below 120 ms on the checkout benchmark while keeping the correctness test suite green
  • 強い版は結果・検証方法・制約を提供し、止まるべきでない場合を認識できる
    • p95が180ms→135msに改善してもGoalは未完了
    • レイテンシが120ms未満でも正確性テストに失敗したら未完了
    • ベンチマークを実行できないなら、成功宣言ではなくブロッカーを表面化する

• Goalの適切なスコープ

  • 監査可能なだけ十分に狭く、かつ次の行動を選べるだけ十分に広い必要がある
  • Fix the failing checkout test は、上流依存関係が本当の問題なら狭すぎる
  • Improve the whole system は、監査面がないため広すぎる
  • Make the checkout test suite pass on the current branch without changing public API behavior が適切

• 生成成果物（generated artifacts）にも同じ原則を適用

  • 弱い: /goal Write docs for this feature
  • 強い: /goal Produce a docs page for Goals that explains the lifecycle, command surface, and two examples. Verify that the page builds locally and that all referenced commands match the current CLI behavior.
  • 強い版は検査可能なページ・ビルドコマンド・コマンド動作を提供する

• 研究Goalの証拠基準

  • 調査開始前に定義する: 正確な再現、部分再構成、代理的支持、ブロッカーとして扱う項目
  • 強い研究Goalは、主張インベントリの構築、主張と証拠の対応付け、実行可能部分の実装、ブロッカーのラベル付け、確認済み主張・支持専用証拠・ブロックされた主張・残る不確実性を分離した監査の生成を要求する

複合研究でGoalsを活用する: クオンツ論文再現の事例

• 事例概要

  • 対象: Buehler, Gonon, Teichmann, Wood による Deep Hedging 論文
  • 論文テーマ: ニューラルネットワークによるトレーディング戦略が、リスク選好、取引コスト、高次元市場設定においてモデルベースのヘッジを再現できるか
  • 正しいGoalは抽象的な「論文再現」ではなく、見出し数値の主張を試み、正確なメカニズムと近似的な学習代替物を分離し、利用可能な資料で正確な再現が不可能な部分を明示すること

• 弱い研究Goal vs 強い研究Goal

  • 弱い: /goal Reproduce Buehler et al., "Deep Hedging"
    • どのセクションが重要か、何を再現と見なすか、学習状態の欠如をどう扱うか、近似的一致と正確な再生の区別基準が未定義
  • 強い: /goal Produce the strongest evidence-backed reproduction of Buehler et al., "Deep Hedging," using the available paper materials and local resources. Attempt every headline result, verify the outputs, and end with a report that separates reproduced mechanics, approximate trained results, blocked exact replay, and remaining uncertainty.

• Codexが実際に行う作業

  • 見出し主張と支持主張を分離する
  • 主張を利用可能な証拠に対応付ける
  • ローカルで検証可能な部分を再構築する
  • 利用可能な資料で正確に再現できない主張にラベルを付ける

• 実行可能だった部分

  • 価格付けおよびヘッジ機構の再構築
  • Heston参照価格の再現
  • CVaRヘッジ実験向けポリシー学習
  • メインヒストグラムおよびヘッジ曲面成果物の再構築
  • Black-Scholes取引コスト勾配の再現
  • Heston取引コストおよび高次元例に対する学習済み検査の実行

• ブロッカーとして残った部分

  • 論文が正確なランダムシード、生成済み学習パス、TensorFlowグラフ、オプティマイザ状態、チェックポイント、完全な元シミュレーション状態を提供していない
  • 最も誠実な結論は 部分的かつ近似的な再現 であり、正確なニューラルネットワーク再生ではない

• レポートにおける認識論的支持レベルの保持

  • 学習済み代替物は主張を支持しうるし、近い数値一致は信頼性を高めうるし、再構築された図は結果の一部を検証しうるが、そのいずれも元の実験を正確に復元したとは記述すべきではない
  • 台帳（ledger）の例:
    • Claim: Deep hedging approximates complete-market Heston hedge without transaction costs
    • Route: モデル機構の再構築、参照ヘッジとの比較、ニューラルネットワーク方策の学習
    • Evidence surface: 価格検査、ヒストグラム、ヘッジ曲面
    • Status: Close approximate reproduction
    • Remaining uncertainty: 元の学習パス、シード、チェックポイントが利用不可
• 研究におけるGoalsの実演価値は、曖昧さの中でも作業を継続させつつ、もっともらしい成果物が誇張された結論になるのを防ぐ点にある。完了の意味を 証拠ベースの主張別監査、近似の明示、再現と再生の境界に対する誠実さ として定義する

Goalsを使うべきでないとき

• 1行編集、単純な説明、短いコードレビュー、1回の回答後に停止したい質問には不向き → 通常のCodexプロンプトが適している
• ゴールラインが曖昧な場合は不適
  • Make this better は信頼できる完了条件を与えない
  • Refactor this code も、期待する終了状態・テスト・制約を定義しなければ弱い
• 不確実性を隠す用途に使ってはならない
  • データが利用できない可能性があるならGoalに明記する
  • ベンチマークがフレイキーになりうるなら、対処方法を明記する
  • 代理証拠を許容するなら、そのラベル付け方法を定義する
• Goalsが最も強力なのは、持続的目標、証拠ベースのゴールライン、複数ターンの調査が必要な経路 という3つの性質が組み合わさった作業である

結論: 目標は持続させ、完了は証拠が決める

• GoalsはCodexの運用モデルを変え、スレッドを孤立したプロンプトの連続から、定義された結果を中心とする 状態ベースの作業ループ へと転換する
• アーキテクチャには意図的に境界がある
  • Goalはスレッドにスコープが限定され、ライフサイクル状態と予算会計を持ち、一時停止・再開・削除・完了・予算停止が可能
  • Codexは動き続けられるが、それはユーザー定義の契約内に限られる
• これはすでに、Codexが最も価値を発揮する デバッグ、最適化、マイグレーション、テスト、研究 に有用である
• ユーザーが目標を与え、Codexが証拠を追い、Goalが作業完了または正直なブロックまで両者をつなぐ
• 複合研究では、答えを生成することと 監査（audit） を生み出すことの違いを生む
• 良いGoalとは、Codexに単に終わらせるよう求めるのではなく、終わったとはどういう意味か を伝えるものである

[hmmhmmhm]

/goal 昼休みの12時までに、私が以前に行った作業をもとに、できることはすべて確認して進めてください。12時前に作業を止めてはいけません。

[shakespeares]

すてきなコマンドですね。