原文タイトル：A guide to /goal
原文著者：@dkundel、OpenAI デベロッパーリレーションメンバー
翻訳：Peggy

編集者注：この記事はOpenAIのデベロッパーリレーションメンバーであるDominik Kundel氏が、Codexの「goal mode / /goal」機能の使用経験をまとめたものです。これは単なるプロンプトテクニックではなく、AIプログラミングツールにおける役割の変化について論じています。Codexは単発の指示に応答するコードアシスタントではなく、明確な目標に向かって継続的に実行するエージェントへと進化しつつあります。

/goalモードにおいて本当に重要なのは、要件を長く詳細に書くことではなく、Codexに対して明確で検証可能な終了基準を設定することです。例えば「デプロイ時間を30%削減」「テストカバレッジを100%パリティに達成」「LCPを2.5秒未満に低下」といった指標です。これらの指標により、Codexはタスクが完了したかどうかを判断でき、曖昧な目標の中で無限に試行錯誤することを防ぎます。同時に、ユーザーはCodexが進捗を測定し結果を検証できるよう、十分な方向性、ツール、実際の環境を提供する必要があります。ローカル環境や仮定条件下で一見実行可能な計画を完了させるだけでは不十分です。

記事は特に、ビジュアルタスクがCodexを詳細の泥沼に陥れやすいと警告しています。「100%ピクセル単位の再現」を要求するのではなく、ビジュアル目標を機能リスト、デザインシステム仕様、評価可能な指標に分解すべきです。数時間から数日にわたる長期タスクでは、コミット、ドラフトPR、進捗ドキュメント、Slack更新、サイドチャットなどを通じて継続的に追跡し、最終的に追跡不能な変更の山にならないようにする必要があります。

この記事の情報価値は、/goalを「長期タスク管理メカニズム」として再定義した点にあります。AIが数十時間から百時間以上連続して実行できるようになると、開発者の中核能力も変化します。AIにコードを生成させるだけでなく、目標を定義し、測定システムを構築し、実行環境を設定し、最後にレビューと振り返りを行うことです。言い換えれば、AIプログラミングは「プロンプトを書くこと」から「継続的に作業するエンジニア実行体を管理すること」へと移行しています。

以下が原文です：

私たちは目標モード（goal mode、または/goal）を導入しました。これは、Codexが特定の結果に向けて継続的に推進できるようにするためです。目標を設定すると、Codexは目標が達成されるまで作業を続けます。それが数時間であろうと数日であろうと関係ありません。すでに、同じ目標のためにCodexが120時間以上連続して作業した事例もあります。

目標モードは非常に強力です。その効果を最大限に引き出すには、/goal を使用する際に注意すべき7つのポイントがあります。

明確で検証可能な基準を設定する

目標モードを有効にする際に入力するプロンプトは、初期プロンプトとして機能するだけでなく、さらに重要なことに、その目標の終了基準となります。Codex は各作業ラウンドの後に、この目標が達成されたかどうかをチェックします。

したがって、目標プロンプトは長く書きすぎるのではなく、明確な基準に焦点を当てるべきです。つまり、どのような状態になれば目標が達成されたと言えるのか、ということです。

多くの場合、良い目標には、モデルが完了を判断するための明確な数値指標を含めるのが最適です。例えば：

「ビルドとデプロイの時間を30%削減する。」

「この機能を TypeScript から Rust に移行し、テストの完全な一致を100%達成する。」

「アプリケーションのスキャフォールディングを最適化し、本番環境における Largest Contentful Paint（ページの主要コンテンツ読み込み速度を測定する指標）を2.5秒未満にする。」

このプロンプトに必ずしも数字を含める必要はありませんが、通常、数字があると後続のステップが進めやすくなります。

目標の定義方法がまだわからない場合や、まず Codex と一緒にプロジェクトについてブレインストーミングしたい場合は、最初から目標モードで会話を始める必要はありません。

Codex は自分で目標を設定することもできます。まずは通常通り会話を始め、Codex に実行を開始させる準備ができたら、その時点でこれまでの議論内容に基づいて Codex に目標を設定させることができます。

また、目標はいつでも編集可能です。Codex アプリケーションでは編集ボタンをクリックするか、CLI で再度 /goal を使用してください。

可能な限り指示を提供する

「ビルドとデプロイの時間を30%削減する」のようなプロンプトは魅力的に聞こえ、Codex が創造的な解決策を見つける可能性もあります。しかし、問題がどこにあるかおおよそ見当がついている場合、このようなプロンプトは Codex を無駄な方向に導く可能性もあります。

そのため、可能な限り、Codex に調査を開始すべき場所、目標達成に使用できるツール、あるいは誤った方向に進むのを防ぐためのその他のヒントを伝えるのが最善です。

例えば、私の同僚 @reach_vb がある実験でこうしました。彼は Codex に、Chrome ブラウザを使って Google Colab にアクセスできることや、Codex にモデルをトレーニングさせる際に自分でデータセットを生成してもよいといった、許容される制約条件をいくつか伝えました。

同様に、ビルド時間を短縮したい場合、どの部分にほとんどの時間がかかっているかが既に分かっているなら、プロンプトで先に Codex をその領域に誘導するのがベストです。

別の方法として、まず Codex に計画モード（plan mode）で予備調査をさせ、潜在的な解決策を記録した計画ファイルを作成させることができます。その後、あなたの目標にその計画を参照させるようにします。

進捗を測定可能にする

あなたの目標が野心的であったり、Codex が段階的に目標に近づく方法が多数ある場合、Codex に進捗を測定するためのツールを提供することが非常に重要です。

一部のタスクでは、これは自然に成り立つかもしれません。例えば、ビルド時間の最適化やテストカバレッジの向上などは、Codex が既に関連ツールを使用できるか、自然にそれらを作成する傾向があるからです。

しかし、他の目標については、まず Codex と一緒にブレインストーミングを行い、どのツールが進捗を判断するのに役立つかを考えるか、自分が目標に近づいているかどうかを確認する方法についてヒントを与えるのが良いでしょう。例えば、2つのスクリーンショットの視覚的な差分比較ツールを作成したり、デバッグ中のエージェント用の評価セットを作成したりすることです。

私は Codex に、ある動画をもとにいくつかのコンポーネントを再現させたことがあります。その際、Codex は自分用にスクリーンショットを比較して差分をチェックするツールを作成しました。その後、このツールを継続的に改良し、異なる差分比較モードを追加していきました。

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

タスクによっては、測定またはチェックすべき追加の基準があるかどうかを検討する必要があります。そうしないと、Codex はタスクが完了したと思い込んでも、あなたの目には不完全に映る可能性があります。

例えば、Codex が UI を「ピクセル単位で再現」するために、デザイン参照画像を切り取ってページに埋め込んだり、テスト合格率を100%にするために、逆にテストカバレッジを削減したりすることがあります。これらは、あなたが本当に望む完了方法ではありません。

現実的な環境を作り出す

Codexが真に目標に向かって効果的に進展するためには、十分に現実的な環境で動作する必要があります。

具体的には、デプロイ時間やレイテンシーの問題を最適化したい場合、Codexがデプロイ環境やテスト環境にアクセスできるようにし、それらの環境を可能な限り本番環境に近づけることが重要です。つまり、同じ技術スタック、同じ設定フラグ、類似したデータベースを使用するということです。

例えば、developers.openai.comのビルドとデプロイ時間の最適化をデバッグしていた際、私たちはすでにデプロイプレビューを使用していました。そのため、Codexはこれらのプレビュー環境を利用してデプロイし、関連するログを確認できました。しかし問題は、プレビューデプロイでは本番環境と比較して一部のビルドパスが無効になっていたことです。

その結果、Codexは最終的に手動デプロイを余儀なくされ、本番設定により近い環境にコードをデプロイして、問題の原因を実際に調査する必要がありました。

同様に、Codexにcomputer use（モデルが実際のアプリケーションインターフェースを操作する能力）を利用させて、実際のアプリケーションをテストすることも可能です。iOSのパフォーマンス問題を最適化するために、@dimillianは最も正確なテスト環境を得るために実機デバイスを使用しました。

ビジュアル目標の設定には注意を

Codexに「この画像を元にUIを100%ピクセル単位で再現する」といったビジュアル目標を与えるのは魅力的です。しかし、設定によっては問題を引き起こす可能性があります。

適切な指示や制約を与えないと、Codexは特定の細部にこだわりすぎて、全体的な目標を見失うことがあります。例えば、参照画像にグラフィック要素が含まれており、Codexがそれらの要素（SVGアイコンや画像など）を生成することが期待されている場合、問題全体を適切に分解するのではなく、「これらの素材を正確に再現する方法」に多くの労力を費やす可能性があります。

さらに、Codexが正しくビジュアル比較を行うにはツールが必要です。これは、より多くの画像入力と全体的なトークン消費の増加を意味しますが、Codexが本当に価値のある改善の機会を特定するための簡単な方法を提供するとは限りません。

したがって、画像は通常、完了基準として唯一のものではなく、目標のコンテキストとして使用する方が適切です。Codexが目標を達成したかどうかを判断するための他の方法、例えば機能リスト、実装仕様、デザインシステムへの準拠などを探すべきです。

進捗の追跡

Codexがバックグラウンドで数時間、あるいは数日間も動作し続け、別のマシンで実行されている場合、どこまで進んでいるのか、どのような作業が完了したのかを忘れてしまいがちです。

目標に応じて、以下の方法が役立つことがわかりました：

· Codexに重要なマイルストーンでコードをコミットさせ、下書きPRにプッシュさせる。特にウェブサイトを開発していて、プレビューデプロイが利用できる場合に非常に有効です。

· Codexにマネジメント向けの成果物を更新させる。アプリ内ブラウザで常時開いておけるHTMLファイルでも、Sitesを介してチームに公開するページでも、レンダリングされた進捗グラフでも、単なるMarkdownファイルでも構いません。

Codexに進捗更新を自発的に公開するよう指示する。これを目標に組み込むことも可能です：重要な進展があった際に、Slackチャンネルや進捗を記録したい他の場所に更新を送信させる。

別のチャットウィンドウでステータスを問い合わせる。現在の状態を簡単に確認したい場合は、/side を実行して新しいサイドチャットを起動し、そこで質問します。このチャットは現在のスレッドから分岐するため、これまでの全コンテキストを持ちますが、ライフサイクルは短いです。

Codexアプリでの別の代替方法：新しい通常チャットを開き、Codexに別の目標スレッドを読ませて質問に答えさせる。Codexに進捗を定期的にチェックする自動タスクを設定させると、この方法は特に強力です。

結果の整理と最終確認

素晴らしい、目標がついに達成されました！では、成果をそのままチームに投げて終わりにしてもいいのでしょうか？

一般的に、特に最適化系のタスクでは、Codexに自身の作業を振り返り、レビューさせることが役立つと感じています。まず /review でローカルコードレビューを実行するのも良いですが、Codexにさらに深く反省させる価値があります：目標達成のためにどのようなアプローチを試みたのか？どの試みが有効で、どの試みが無効だったのか？そしてそれに基づいてコードを整理する。

Codexは目標を達成するまで動作し続けるため、効果が不十分だったり、まったく無効だった方法を試みた可能性があり、その残骸が最終コードに残っていることがあります。

次のタスクにもgoalを設定しましょう。

Codexの目標機能は、最も意義のあるエンジニアリングの課題を解決するための非常に強力なツールです。しかし、適切な環境と指示を提供して初めて、より効率的に目標に到達できます。

あなたは/goalで何をしましたか？

[原文リンク]

BlockBeats の公式コミュニティに参加しよう：

Telegram 公式チャンネル：https://t.me/theblockbeats

Telegram 交流グループ：https://t.me/BlockBeats_App

Twitter 公式アカウント：https://twitter.com/BlockBeatsAsia