/goal の活用ガイド

ゴールモード（または /goal）は、Codex が具体的な成果に向かって進むのを支援するために導入しました。ゴールを設定すると、Codex はその目標が達成されるまで、数時間でも数日でも作業を続けます。Codex を使って 120 時間以上 にわたって 1 つのゴールに取り組んだ人もいます。

ゴールモードは非常に強力で、その効果を最大限に引き出すためにできることがいくつかあります。以下は、/goal を使用する際に覚えておくべき 7 つのポイントです。

**1. 明確で検証可能な基準**

ゴールモードを起動するときに定義するプロンプトは、最初の指示として機能するだけでなく、より重要なのはゴールの終了条件として機能することです。Codex は各ターンの後にゴールが達成されたかどうかをチェックします。そのため、ゴールのプロンプトは長くなりすぎず、ゴールが達成されたと判断するための明確な基準に焦点を当てる必要があります。

ほとんどの場合、良いゴールには、モデルが到達すべき明確な数値* が含まれています。良い例を挙げます。

"ビルドとデプロイの時間を 30% 削減する。"
"この機能を TypeScript から Rust に移行し、テストの完全な互換性 (100%) を達成する。"
"アプリケーションのスキャフォールディングを改善し、本番環境での Largest Contentful Paint を 2.5 秒未満にする。"

\プロンプトは必ずしも数値である必要はありませんが、一般的に数値があると以下のヒントに役立ちます。*

ゴールをどのように定義するのが最適かわからない場合や、まず Codex と一緒にプロジェクトについてブレインストーミングしたい場合は、ゴールモードでスレッドを開始する必要はありません。

Codex は自分でゴールを設定できるため、会話を始めて、Codex に作業を開始してもらう準備ができたら、会話に基づいてゴールを設定するよう Codex に依頼することができます。

また、Codex アプリの編集ボタンを押すか、CLI で /goal を再度使用することで、いつでもゴールを編集できます。

2. 可能であればガイダンスを提供する

"ビルドとデプロイの時間を 30% 削減する" のようなプロンプトを送信するのはクールで、創造的な解決策が見つかるかもしれません。しかし、問題がどこにあるかについてあなたに心当たりがある場合、Codex が的外れな方向に進んでしまう可能性もあります。

可能であれば、Codex に作業を開始するための出発点、ゴールを達成するために使用できるツール、または Codex が間違った方向に進む可能性がある場合の指針を与えてください。

例えば、私の同僚である @reach_vb は、ある実験で、Codex に Chrome ブラウザを使用して Google Colab にアクセスできることや、Codex がモデルをトレーニングする際に独自のデータセットを生成するといった許容可能な制限を伝えていました。

同様に、ビルド時間を短縮したい場合で、時間の大部分がどこに費やされているかわかっているなら、プロンプトの一部として、まずその領域を Codex に指示するようにしてください。

あるいは、プランモードで Codex に事前調査をさせ、潜在的なオプションを文書化した計画をファイルとして作成させることもできます。その後、ゴールからその計画を参照するようにします。

3. 進捗を測定可能にする

ゴールが野心的であったり、Codex がゴールに近づく方法が複数ある場合、Codex に進捗を測定するためのツールを与えることが重要です。

ビルド時間の改善やテストカバレッジの向上など、一部のタスクでは、Codex がすでにツールを持っているか、自然に作成することが多いため、これは当然のことかもしれません。

その他のゴールについては、どのようなツールが役立つかを Codex とブレインストーミングするか、進捗状況を把握する方法を Codex に示唆する価値があります。例えば、2 つのスクリーンショット間の視覚的な差分を計算するツールや、調整しようとしているエージェント用の評価スイートを作成するなどです。

私が Codex にビデオからいくつかのコンポーネントを再作成させたとき、スクリーンショットの差分を確認し、その差分を検査するためのツールを Codex 自身に作成させました。Codex は時間の経過とともに、さまざまな差分モードを持つようにツールを進化させることを選択しました。

Codex が 2 つのフレームを視覚的に比較するために生成したスクリーンショット

タスクによっては、Codex がタスクは完了したと判断するが、あなたが不完全とみなす可能性のある追加の基準を測定/チェックすることを検討する必要があります。例えば、デザインインスピレーションを切り取ってインライン化することで UI を実装し「ピクセルパーフェクト」にすることや、テストカバレッジを減らして 100% のテスト合格率を達成することなどです。

4. 現実的な環境を作成する

Codex がゴールに向かって真に進捗するためには、現実的な環境で動作する必要があります。具体的には、デプロイ時間やレイテンシの問題を改善しようとしている場合、本番環境を模したデプロイ環境とテスト環境にアクセスできるようにする必要があります。つまり、同じスタック、同じフラグ、同様のデータベースです。

例として、developers.openai.com のビルドとデプロイ時間の改善をデバッグしていました。私たちはすでにデプレビューを使用していたため、Codex はそれらを使用してデプロイし、関連するログを確認できました。しかし、プレビューデプロイメントでは、本番実行と比較していくつかのビルドパスが無効になっていました。そのため、Codex は代わりに、環境を検査するために、同様の本番構成で同じ環境に手動デプロイを実行する必要がありました。

同様に、Codex にコンピューター使用をさせて実際のアプリケーションをテストさせることもできます。iOS のパフォーマンス改善に取り組むために、@dimillian は最も正確な環境を得るために物理デバイスさえ使用しました。

5. 視覚的なゴールには注意する

"この画像に基づいて、この UI を 100% ピクセルパーフェクトで実装する" のような視覚的なゴールを Codex に与えるのは魅力的ですが、設定によっては問題を引き起こす可能性があります。

適切なガイダンスと制約を与えないと、全体的なゴールを無視して、いくつかの問題に深入りしてしまう可能性があります。例えば、参照に Codex が生成することが期待される SVG アイコンや画像などのグラフィックが含まれている場合、問題を適切に分析する代わりに、それらの正確な再現にこだわってしまう可能性があります。

さらに、Codex は視覚的な比較を正しく行うためのツールを必要とするため、より多くの画像入力と全体的なトークン使用量の増加につながり、Codex が改善の機会を特定する簡単な方法を必ずしも提供しません。

代わりに、画像はゴールに向かうための有益なコンテキストとして機能することがよくありますが、Codex がゴールに到達したことを識別するための他の方法（機能チェックリスト、実装する仕様、デザインシステムへの準拠など）を見つけるべきです。

6. 進捗状況の追跡

Codex がバックグラウンドで（または別のマシンで）何時間も何日も作業を続けると、Codex がどの程度進んでいるか、どのような作業が行われたかを把握するのが難しくなることがあります。ゴールに応じて、進捗を追跡するために役立ついくつかの方法があります。

意味のあるステップでコミットし、ドラフト PR にプッシュするよう Codex に依頼する。これは特に、プレビューデプロイメントがあるウェブサイトで作業する場合に役立ちます。
Codex にエグゼクティブ向けのアーティファクトを更新させる。これは、アプリ内ブラウザで開いておける HTML ファイルや、Sites を使用してチームにデプロイできるもの、進捗を追跡するレンダリングされたグラフの画像、あるいはプレーンなマークダウンファイルでも構いません。
Codex に更新を投稿するよう指示する。ゴールの一部として、主要な進捗状況を Slack チャンネルや、進捗を記録したい他の場所に報告するよう Codex に依頼することもできます。
他のチャットを使用してステータス更新を依頼する。現在の状態を簡単に確認したいだけの場合は、/side を実行して新しいサイドチャットを起動し、そこで質問することができます。これは現在のスレッドをフォークするため、その時点までのすべてのコンテキストを持ちますが、短命です。Codex アプリでの代替方法は、通常の新しいチャットで Codex に、他のゴールスレッドを読んで質問に答えるよう依頼することです。これは、Codex に定期的にチェックインする自動化をスケジュールするよう依頼すると特に強力です。

7. クリーンアップと結果の最終確定

素晴らしい、ついにゴールが達成されました！さあ、$yeet してチームに共有して、今日は終わりにしましょうか？

一般的に、特に最適化タスクでは、Codex に実行した作業を振り返らせ、レビューさせることが役立つと感じています。/review を実行してローカルコードレビューを実行することから始められますが、Codex にゴールを解決するために試みたさまざまなアプローチをより深く振り返らせ、それに応じてクリーンアップさせることも価値があります。

Codex はゴールに到達するまで継続するため、うまく機能しなかったり、まったく機能しなかったいくつかの試みが変更に残っている可能性があります。