はじめに

1 回の通常のターンで作業を終えるのではなく、一貫した 1 つの目標に向けて Codex に作業を続けさせたい場合は、/goal を使用します。目標が明確で、検証ループがあり、各ステップを逐一指示しなくても Codex が作業を進められる場合に適しています。/goal を使用すると、Codex はユーザーの入力なしで何時間も自律的に作業できます。

/goal <objective> でゴールを設定し、/goal で現在のゴールを確認します。実行を制御する必要がある場合は、/goal pause、/goal resume、または /goal clear を使用します。

/goal がスラッシュコマンドの一覧に表示されない場合は、 config.toml で features.goals を有効にします：

[features]
goals = true

CLI から codex features enable goals を実行するか、Codex に実行を依頼することもできます。

適切な作業の選択

適切なゴールの範囲は、1 回のプロンプトで完了する作業より広く、終わりのないバックログより狭いものです。Codex が達成すべきこと、変更してはいけないこと、進捗の検証方法、停止するタイミングを定義する必要があります。

次のような作業に適しています：

• 移行先の技術スタック、同等性の検証方法、制約が明確なコード移行
• 各チェックポイントの後に Codex がテストを実行できる大規模なリファクタリング
• 動作する成果物を Codex が継続的に改善できる実験、ゲーム、プロトタイプ

互いに関連のない作業を並べただけのリストには、ゴールを使用しないでください。

ループの設定

重要なのは、取り決めを明確にすることです。Codex は作業を始める前に「完了」の意味を把握している必要があります。ゴールが移行の場合、「完了」とは、新しい処理経路がコントラクトテストに合格し、従来の処理経路へのロールバック手段が維持されていることを意味する場合があります。ゴールがゲームやプロトタイプの場合は、アプリをビルドして起動でき、入力として指定されたリファレンスまたは期待される動作と一致することを意味する場合があります。

Codex による自律的な作業

ゴールの実行中は、安心して作業を任せられるよう、簡潔な進捗報告を求めます。役立つ状況報告には、現在のチェックポイント、検証済みの内容、残りの作業、Codex が行き詰まっているかどうかを含めます。 状況が不明確になった場合は、単発の指示を増やすのではなく、ゴールをより具体的にします。次に重要なチェックポイント、それを検証するコマンド、一時停止すべき条件を Codex に明確に伝えます。

Codex はゴールに取り組む際、ユーザーが途中で状況を確認しなくても、何時間も自律的に作業できます。停止条件に達したと判断すると実行を停止するため、/goal は監視の必要がないバックグラウンドタスクとして捉えてください。

ゴールの例

移行

ゲームを新しい技術スタックに、モバイルアプリを新しいプラットフォームに、コードベースを新しいフレームワークに移行する場合は、/goal を使用して Codex に移行作業を任せられます：

プロトタイプの作成

新しいアプリをゼロから作る場合でも、新しいゲームや機能を作る場合でも、/goal を使用すれば、Codex に完成度の高い初版を作成させることができます。作りたいものを正確に記述した PLAN.md ファイルを、初版を作成する際の指針として活用することもできます。

プロンプトの最適化

評価スイートがある場合は、/goal を使用して評価結果を基準にプロンプトを最適化できます。Codex は失敗したケースを調査してプロンプトを更新し、評価を再実行して、スコアが改善するか指定した停止条件に達するまでこの作業を繰り返せます。