原文タイトル：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アプリ内の編集ボタンをクリックするか、CLIで再び /goalを使います。
「構築とデプロイの時間を30%短縮」などのプロンプトは魅力的に聞こえますし、Codexに創造的な解決策を見つけさせることもあります。しかし、問題の出所が大まかにわかっている場合、そのようなプロンプトは逆にCodexを迷わせることもあります。
だからこそ、可能な限り、Codexに「どこから調査を始めるべきか」「どのツールを使えば良いか」「他にどんなヒントを与えられるか」を伝えるのが良いです。そうすれば、誤った方向に迷い込むのを防げます。
例えば、私の同僚@reach_vbは次のようにしました：ChromeブラウザからGoogle Colabにアクセスできることを伝え、モデルのトレーニング中にデータセットを自動生成させるなどの制約条件も示しました。
同様に、ビルド時間を短縮したい場合、すでにどの部分に時間がかかっているかを知っているなら、その部分にCodexを誘導するのが効果的です。
もう一つの方法は、計画モード（plan mode）でCodexに事前調査させ、潜在的な方案を記録した計画ファイルを作らせ、その後、その目標にこの計画を引用させることです。
あなたの目標が野心的だったり、Codexに複数の方法で段階的に近づかせたい場合、重要なのは：進捗を測るツールを提供することです。
この点は、最初から自然に成立する場合もあります。例えば、ビルド時間の最適化やテストカバレッジの向上などです。これらは通常、関連ツールを使うか、自然にこれらを作成します。
しかし、他の目標については、まずCodexとブレインストーミングして、「どのツールが進捗判断に役立つか」を考えるのが良いでしょう。あるいは、進捗を確認するためのヒントを与えます。例えば、2つのスクリーンショットの差分比較ツールを作る、またはデバッグ中のエージェントの評価セットを作るなどです。
私は以前、Codexに動画からコンポーネントを再現させたとき、差分比較ツールを自作させました。後に、そのツールは異なる差分モードを追加して進化しました。
画像：Codexが生成したスクリーンショットの一枚。2つの画面フレームの視覚比較用。
タスクによっては、追加の基準や測定項目も考慮すべきです。さもなければ、Codexはタスクが完了したと誤認し、実際には未完成のまま終わる可能性があります。
例えば、「ピクセルレベルの再現」を目指してUIを作る場合、設計参考図を切り抜いてページに埋め込むこともありますし、テスト合格率を100%にするためにテスト範囲を削減することもあります。これらは本当に望む完成形ではありません。
Codexが実際に目標に向かって有効に進めるには、十分にリアルな環境で動作させる必要があります。
具体的には、デプロイ時間や遅延の最適化をしたい場合、Codexはデプロイやテスト環境にアクセスできる必要があります。そして、その環境はできるだけ本番環境に近いものでなければなりません。例えば、同じ技術スタック、同じ設定、類似のデータベースを使うなどです。
例として、私たちはdevelopers.openai.comのビルドとデプロイ時間の最適化を行った際、デプロイプレビューを使っていました。Codexはこれらのプレビュー環境を利用してデプロイし、ログも確認できました。ただし、プレビューと本番環境では一部ビルドパスが無効になっているため、最終的には手動で本番に近い環境にコードをデプロイし、問題点を検証しました。
同様に、Codexに実際のアプリケーションを操作させるために、computer use（モデルの実環境操作能力）を使うこともあります。iOSのパフォーマンス問題の最適化には、@dimillianは実機を使って最も正確なテストを行いました。
例えば、「この画像に基づき、100%ピクセルレベルでUIを再現する」などの視覚的目標は魅力的ですが、設定次第では問題も生じます。
適切な指針や制約を与えないと、Codexは細部にこだわりすぎて全体の目標を見失うことがあります。例えば、参考画像に図形要素が含まれている場合、それらを正確に再現させようとし、SVGアイコンや画像の「正確な複製」に過剰に時間を費やすことがあります。
また、Codexには視覚比較を正しく行うためのツールが必要です。これには多くの画像入力やトークン消費が伴いますが、価値のある改善点を見つけるためのシンプルな方法は必ずしも提供されません。
したがって、画像はあくまで目標の文脈として使い、唯一の完成基準にはしない方が良いです。機能リストや実装規範、デザインシステムへの適合性など、他の判断基準を用いて進捗を評価すべきです。
Codexが数時間、あるいは数日間バックグラウンドで作業したり、別のマシン上で動作している場合、どこまで進んだのか、何をしたのかを忘れがちです。
さまざまな目標に対して、私が役立つと感じた方法は以下の通りです。
· 重要なポイントでコードをコミットし、ドラフトPRにプッシュさせる。特にウェブサイトの作成やプレビュー環境がある場合に有効です。
· 管理層向けの進捗報告を更新させる。HTMLファイルにしてアプリ内ブラウザで開いたり、チーム向けにSitesにデプロイしたページにしたり、進捗のグラフを作成したり、Markdownファイルにまとめたりできます。
· 重要な進展があったときに、Slackや他の場所に更新を送るよう指示する。これも目標に含めると良いです。
· 状況を素早く知りたいときは、/sideを使ってサイドチャットを開始し、そこで質問する。現在のスレッドから分岐しているため、これまでのコンテキストを持ちつつも短命です。
· もう一つの方法は、新しい普通のチャットを開き、Codexに別の目標スレッドを読ませて質問させることです。自動化タスクを設定し、定期的に進捗を確認させると、特に効果的です。
やった！目標は達成された！これでチームに成果を渡して終わりにしても良いでしょうか？
特に最適化系のタスクでは、Codexに自分の作業を振り返らせ、レビューさせるのが非常に役立ちます。/reviewを使ってローカルのコードレビューを行うのも良いですが、より深く振り返らせることも重要です：どの道を試し、どれが効果的だったか、どれが無駄だったかを振り返り、コードを整理します。
Codexは目標達成まで働き続けるため、効果の薄い方法や無効な方法も試し、その残骸が最終コードに残ることもあります。
次のタスクにも目標を設定しましょう
Codexのgoal機能は、非常に強力なツールです。適切な環境と指示を与えることで、より効率的に目標に到達させることができます。
あなたは /goalを使って何をしましたか？
[原文リンク]
律動BlockBeatsの求人情報はこちらをクリック
律動BlockBeats公式コミュニティに参加しませんか：
Telegram登録グループ：https://t.me/theblockbeats
Telegramグループ：https://t.me/BlockBeats_App
Twitter公式アカウント：https://twitter.com/BlockBeatsAsia
3.6M 人気度
2.19M 人気度
55.75K 人気度
657.8M 人気度
1.4M 人気度
Codexゴールモードの使い方ガイド：AIに具体的な目標を継続的に推進させる方法
編集者注：この記事は、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アプリ内の編集ボタンをクリックするか、CLIで再び /goalを使います。
指針をできるだけ提供する
「構築とデプロイの時間を30%短縮」などのプロンプトは魅力的に聞こえますし、Codexに創造的な解決策を見つけさせることもあります。しかし、問題の出所が大まかにわかっている場合、そのようなプロンプトは逆にCodexを迷わせることもあります。
だからこそ、可能な限り、Codexに「どこから調査を始めるべきか」「どのツールを使えば良いか」「他にどんなヒントを与えられるか」を伝えるのが良いです。そうすれば、誤った方向に迷い込むのを防げます。
例えば、私の同僚@reach_vbは次のようにしました：ChromeブラウザからGoogle Colabにアクセスできることを伝え、モデルのトレーニング中にデータセットを自動生成させるなどの制約条件も示しました。
同様に、ビルド時間を短縮したい場合、すでにどの部分に時間がかかっているかを知っているなら、その部分にCodexを誘導するのが効果的です。
もう一つの方法は、計画モード（plan mode）でCodexに事前調査させ、潜在的な方案を記録した計画ファイルを作らせ、その後、その目標にこの計画を引用させることです。
進捗を測定可能にする
あなたの目標が野心的だったり、Codexに複数の方法で段階的に近づかせたい場合、重要なのは：進捗を測るツールを提供することです。
この点は、最初から自然に成立する場合もあります。例えば、ビルド時間の最適化やテストカバレッジの向上などです。これらは通常、関連ツールを使うか、自然にこれらを作成します。
しかし、他の目標については、まずCodexとブレインストーミングして、「どのツールが進捗判断に役立つか」を考えるのが良いでしょう。あるいは、進捗を確認するためのヒントを与えます。例えば、2つのスクリーンショットの差分比較ツールを作る、またはデバッグ中のエージェントの評価セットを作るなどです。
私は以前、Codexに動画からコンポーネントを再現させたとき、差分比較ツールを自作させました。後に、そのツールは異なる差分モードを追加して進化しました。
タスクによっては、追加の基準や測定項目も考慮すべきです。さもなければ、Codexはタスクが完了したと誤認し、実際には未完成のまま終わる可能性があります。
例えば、「ピクセルレベルの再現」を目指してUIを作る場合、設計参考図を切り抜いてページに埋め込むこともありますし、テスト合格率を100%にするためにテスト範囲を削減することもあります。これらは本当に望む完成形ではありません。
実環境を作る
Codexが実際に目標に向かって有効に進めるには、十分にリアルな環境で動作させる必要があります。
具体的には、デプロイ時間や遅延の最適化をしたい場合、Codexはデプロイやテスト環境にアクセスできる必要があります。そして、その環境はできるだけ本番環境に近いものでなければなりません。例えば、同じ技術スタック、同じ設定、類似のデータベースを使うなどです。
例として、私たちはdevelopers.openai.comのビルドとデプロイ時間の最適化を行った際、デプロイプレビューを使っていました。Codexはこれらのプレビュー環境を利用してデプロイし、ログも確認できました。ただし、プレビューと本番環境では一部ビルドパスが無効になっているため、最終的には手動で本番に近い環境にコードをデプロイし、問題点を検証しました。
同様に、Codexに実際のアプリケーションを操作させるために、computer use（モデルの実環境操作能力）を使うこともあります。iOSのパフォーマンス問題の最適化には、@dimillianは実機を使って最も正確なテストを行いました。
視覚的目標の慎重な設定
例えば、「この画像に基づき、100%ピクセルレベルでUIを再現する」などの視覚的目標は魅力的ですが、設定次第では問題も生じます。
適切な指針や制約を与えないと、Codexは細部にこだわりすぎて全体の目標を見失うことがあります。例えば、参考画像に図形要素が含まれている場合、それらを正確に再現させようとし、SVGアイコンや画像の「正確な複製」に過剰に時間を費やすことがあります。
また、Codexには視覚比較を正しく行うためのツールが必要です。これには多くの画像入力やトークン消費が伴いますが、価値のある改善点を見つけるためのシンプルな方法は必ずしも提供されません。
したがって、画像はあくまで目標の文脈として使い、唯一の完成基準にはしない方が良いです。機能リストや実装規範、デザインシステムへの適合性など、他の判断基準を用いて進捗を評価すべきです。
進捗の追跡
Codexが数時間、あるいは数日間バックグラウンドで作業したり、別のマシン上で動作している場合、どこまで進んだのか、何をしたのかを忘れがちです。
さまざまな目標に対して、私が役立つと感じた方法は以下の通りです。
· 重要なポイントでコードをコミットし、ドラフトPRにプッシュさせる。特にウェブサイトの作成やプレビュー環境がある場合に有効です。
· 管理層向けの進捗報告を更新させる。HTMLファイルにしてアプリ内ブラウザで開いたり、チーム向けにSitesにデプロイしたページにしたり、進捗のグラフを作成したり、Markdownファイルにまとめたりできます。
· 重要な進展があったときに、Slackや他の場所に更新を送るよう指示する。これも目標に含めると良いです。
· 状況を素早く知りたいときは、/sideを使ってサイドチャットを開始し、そこで質問する。現在のスレッドから分岐しているため、これまでのコンテキストを持ちつつも短命です。
· もう一つの方法は、新しい普通のチャットを開き、Codexに別の目標スレッドを読ませて質問させることです。自動化タスクを設定し、定期的に進捗を確認させると、特に効果的です。
最終的に結果を整理し、確認する
やった！目標は達成された！これでチームに成果を渡して終わりにしても良いでしょうか？
特に最適化系のタスクでは、Codexに自分の作業を振り返らせ、レビューさせるのが非常に役立ちます。/reviewを使ってローカルのコードレビューを行うのも良いですが、より深く振り返らせることも重要です：どの道を試し、どれが効果的だったか、どれが無駄だったかを振り返り、コードを整理します。
Codexは目標達成まで働き続けるため、効果の薄い方法や無効な方法も試し、その残骸が最終コードに残ることもあります。
次のタスクにも目標を設定しましょう
Codexのgoal機能は、非常に強力なツールです。適切な環境と指示を与えることで、より効率的に目標に到達させることができます。
あなたは /goalを使って何をしましたか？
[原文リンク]
律動BlockBeatsの求人情報はこちらをクリック
律動BlockBeats公式コミュニティに参加しませんか：
Telegram登録グループ：https://t.me/theblockbeats
Telegramグループ：https://t.me/BlockBeats_App
Twitter公式アカウント：https://twitter.com/BlockBeatsAsia