はじめに

通常の 1 ターンで作業を終えず、1 つの目標に向けて Codex に作業を続けてもらいたいときは、/goal を使います。達成したいことが明確で、繰り返し結果を検証でき、手順を逐一指示しなくても Codex が進められる作業に適しています。/goal を使うと、追加の指示がなくても Codex は数時間にわたって自律的に作業できます。

/goal <objective> で目標を設定し、/goal で現在の目標を確認できます。実行を一時停止するには /goal pause、再開するには /goal resume、目標を解除するには /goal clear を使います。

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

[features]
goals = true

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

目標に適した作業

目標に適しているのは、1 回のプロンプトでは完結せず、どこまで進めれば完了かを決められる規模の作業です。Codex が達成すべきこと、変更してはいけないもの、進捗の検証方法、停止条件を明確にします。

たとえば、次のような作業に適しています。

• 移行先の技術スタック、移行前後の動作が同等かを確認する方法、制約が明確なコード移行
• チェックポイントごとに Codex がテストを実行できる大規模なリファクタリング
• 動作するものをもとに Codex が改良を重ねられる実験、ゲーム開発、プロトタイプ制作

互いに関連のない作業をまとめて 1 つの目標にするのは避けてください。

作業と検証の進め方

大切なのは、何をもって「完了」とするかを、作業に入る前に Codex と取り決めておくことです。たとえば移行なら、新しい実装が契約テストに合格し、従来の実装にロールバックできることを完了条件にできます。ゲームやプロトタイプなら、アプリをビルドして起動でき、提示した見本と一致するか、期待どおりに動作することを完了条件にできます。

Codex による自律的な作業

目標に沿って安心して作業を任せられるよう、Codex には簡潔な進捗報告を求めます。現在のチェックポイント、検証済みの内容、残っている作業、進行を妨げているものの有無を報告してもらうと、状況を把握しやすくなります。 報告が曖昧になったら、その都度指示を追加するよりも、目標を具体化してください。次にどのチェックポイントに到達すべきか、どのコマンドで到達を確認できるか、どのような場合に一時停止すべきかを Codex に明示します。

目標を設定すると、途中で様子を確認しなくても、Codex は何時間も自律的に作業できます。停止条件を満たしたと確信した時点で実行を終了するため、/goal は監視する必要のないバックグラウンドタスクとして扱えます。

目標の例

移行

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

プロトタイプ制作

アプリを一から作る場合も、新しいゲームや機能を開発する場合も、/goal を使えば、完成度の高い初版を Codex に仕上げてもらえます。作りたいものを PLAN.md ファイルに具体的に記述しておくと、Codex はそれを指針に初版を作成できます。

プロンプトの最適化

評価スイートがあれば、/goal を使って評価結果に基づきプロンプトを最適化できます。Codex は失敗したケースを調べ、プロンプトを修正し、評価を再実行します。スコアが改善するか、指定した停止条件を満たすまで、この手順を繰り返せます。