編集者注：この記事は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をプランモードで動作させ、潜在的なソリューションを記録するためのプランファイルを作成させ、その後、あなたの目的がそのプランを参照するようにします。

進捗を測定可能にする

目標が野心的である場合、またはCodexが目標に到達するための複数の段階的アプローチがある場合、Codexに進捗を測定するためのツールを提供することが重要です。

一部のタスクについては、これは自然に当てはまります。たとえば、ビルド時間を最適化したり、テストカバレッジを向上させたりする場合、Codexは通常、関連ツールを既に使用しているか、自然にこれらのツールを作成します。

しかし、他の目標のために、まずCodexとブレインストーミングすることをお勧めします。進捗を判断するのに役立つツールは何か？あるいは、自分が目標に近づいているかどうかを確認する方法をCodexに教えるためのヒントを提供してください。たとえば、2つのスクリーンショットの視覚的差異を比較するツールを作成するか、デバッグ中のエージェント用に評価セットを構築するなどです。

私は以前、Codexに動画に基づいていくつかのコンポーネントを再現させた際、Codexがスクリーンショットを比較して差異を検査するためのツールを自ら作成しました。その後、Codexはこのツールを継続的に改善し、異なる差異比較モードを追加しました。

タスクによっては、追加の基準を測定またはチェックする必要があることに注意してください。そうでないと、Codex はタスクが完了したと判断するかもしれませんが、あなたにとってはまだ不完全なままです。

たとえば、Codex は UI を「ピクセル単位で再現」するために、デザイン参照画像を切り抜いてページに埋め込むことがある。あるいは、テスト通過率を 100% にするために、テストカバレッジを逆に削減することもある。これらはあなたが真に望む完了の仕方ではない。

本物の環境を作成する

Codexが目標に向けて実際に進展を遂げるためには、十分に現実的な環境で動作する必要があります。

実際には、これは次のことを意味します：デプロイ時間や遅延の問題を最適化したい場合、Codex はデプロイおよびテスト環境にアクセスでき、これらの環境は生産環境にできるだけ近い形で模倣される必要があります。つまり、同じ技術スタック、同じ設定スイッチ、類似のデータベースを使用することです。

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

そのため、Codexは最終的に手動でデプロイを行い、本番環境に近い環境にコードをデプロイして、ようやく問題の原因を確認することができました。

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

視覚的目標を慎重に設定してください

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

適切なガイドラインと制約を提供しない場合、Codexは細部にこだわりすぎて、全体の目標を見失う可能性があります。たとえば、参照画像にグラフィック要素が含まれており、それら（SVGアイコンや画像など）をCodexに生成させたい場合、Codexは「これらの素材を正確に再現する方法」に多くのリソースを費やし、問題全体を正しく分解することを怠ってしまうかもしれません。

また、Codexは正確な視覚比較を行うためにツールを必要とします。これはより多くの画像入力とより高い全体的なトークン消費を意味しますが、Codexが本当に価値のある改善機会を識別するための簡単な方法を提供するとは限りません。

したがって、画像は通常、完了の唯一の基準ではなく、ターゲットのコンテキストとしてより適しています。機能チェックリスト、実装仕様、デザインシステムへの準拠など、Codexがターゲットが達成されたかを判断する他の方法を探すべきです。

進捗を追跡

Codexがバックグラウンドで数時間、あるいは数日、甚至は別のマシン上で動作し続けた場合、どの程度進捗したか、すでにどのような作業を完了したかを忘れてしまうのは容易です。

目標に応じて、以下の方法が役に立ちました：

·Codex が重要な節目でコードを提出し、ドラフト PR にプッシュしてください。特にウェブサイトを作成しており、プレビューデプロイが可能な場合、これは非常に役立ちます。

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

Codex が進捗更新を積極的に公開するように指示してください。また、目標に以下を含めることもできます：Codex が重要な進捗を達成した際に、Slack チャンネルまたは進捗を記録したい他の場所に更新を送信する。

状態を確認するには、他のチャットウィンドウをご利用ください。現在の状態を素早く確認したい場合は、/side を実行して新しいサイドチャットを起動し、そこで質問してください。このチャットは現在のスレッドから分岐するため、これまでのすべてのコンテキストを保持しますが、ライフサイクルは短いです。

Codexアプリでの別の方法は、通常の新しいチャットを開始し、Codexに別のターゲットスレッドを読み取らせ、あなたの質問に答えさせることです。Codexに自動化タスクを設定して進捗を定期的にチェックさせると、この方法は特に強力になります。

クリアリングして最終確認を行う

素晴らしい！目標がついに達成されました！これで成果をチームに渡して、あとは終了でいいのでしょうか？

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

Codexは目標に達するまで継続して作動するため、効果が十分でない、あるいは完全に無効な方法を試した可能性があり、その残留変更が最終コードに残っている可能性があります。

次のタスクにも目標を設定してください

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

/goal を使って何をしましたか？