Codex は長時間の作業に適しており、特に /goal によって持続的な目標が与えられると効果的です。難しいのは、Codex が何時間も何日も作業を続け、新たな実装の詳細を発見し、複数の検証を経ていく中で、方向性を見失わないようにすることです。
実装を始めると、初期の前提が変わることはよくあります。コラボレーションモデルは、目標を維持しつつ、新しい証拠が現れるたびにあなたと Codex の両方が計画を修正できる余地を残す必要があります。
ここ数週間、私は以下の 5 つのプラクティスを実践してきました。
- Codex に作業計画とロードマップの管理を任せる。
- メインスレッドを調整に集中させる。
- 各マイルストーン後にロードマップを監査し、コードをレビューする。
- Computer Use のテストにはローカルスレッドを使用する。
- 簡潔なアップデートとダッシュボードで進捗を報告する。
Codex 内で GPT Image 2 を使用して生成
1. Codex に作業計画とロードマップの管理を任せる
私は通常、/plan モードではなく、会話から始めます。構築しようとしているものを説明し、大まかなアイデアを口述し、制約を共有し、Codex が質問をして、初期計画を提案するのに十分なコンテキストを得られるようにします。
これにより、初期の議論は柔軟に進みます。Codex が支援を開始する前に、漠然としたアイデアを正式な仕様書にまとめる必要はありません。Codex は私にインタビューし、理解した内容を反映し、ギャップを特定し、徐々に会話を実行可能な計画に変えていくことができます。
プロジェクトの形が見えてきたら、Codex に現在の Goal を設定するよう依頼します。Goal モードは Codex に持続的な目標を与え、目標が完了、ブロック、または置き換えられるまで、複数のターンにわたって同じ成果に向けて作業を続けられるようにします。
/goal を使って自分で目標を設定することもできますが、通常は Codex に任せます。Goal モードはハーネスを通じて公開されているため、Codex は私たちの会話、プロジェクトのコンテキスト、そしてこれまでに学んだすべての情報を統合して、明確な目標を定義できます。また、その目標が完了したと見なすために必要なエビデンスも定義できます。
大規模なプロジェクトでは、Codex に GOALS.md へ広範なロードマップを記述するよう依頼します。これは組み込みの Codex 機能ではなくプロジェクトの慣習であり、ファイル名は任意に設定できます。
GOALS.md は、フラットなタスクリストではなく、マイルストーンを中心に整理するのが一般的です。各マイルストーンには以下を記録します。
- 意図した成果
- 現在スコープ内の作業
- 重要な決定事項
- 既知のブロッカー
- 次に進む前に必要なエビデンス
Codex はプロジェクトの進行に合わせてこのファイルを管理します。新しい発見により、マイルストーンのスコープが変更されたり、新しいマイルストーンが追加されたり、完了に必要なエビデンスが変わったりする可能性があります。
Goal モードの目標は常に 1 つだけアクティブになります。マイルストーンが完了するたびに、Codex は GOALS.md を更新し、次の目標をアクティブにして、作業を続けます。
2. メインスレッドを調整に集中させる
ロードマップができたら、メインスレッドを目標、制約、決定事項、現在のプロジェクト状態に集中させます。
メインスレッドは次に何をすべきかを決定し、境界のあるタスクを委任し、結果を評価します。すべての実装の詳細を把握する必要はありません。
ワーカーは、慣れないコードを読んだり、いくつかのアプローチを試したり、失敗するテストを追跡したりするのに 1 時間を費やすかもしれません。コーディネーターは、プロジェクト全体に影響を与える情報のみを必要とします。
- ワーカーが学んだこと
- 変更されたこと
- それを裏付けるエビデンス
- 次に何をすべきか
Codex はこの作業を subagent に委任するか、別のスレッドを作成できます。機能的には、同じタスクを実行できます。後で作業を再確認する可能性がある場合は、別のスレッドを使用します。Codex アプリに表示され続け、独自の履歴を保持するからです。
これは、複数の作業が並行して実行されるようになると特に便利です。各調査、実装、レビューを簡単に検査できる状態を保ちながら、メインスレッドはプロジェクトの調整を続けることができます。
3. 各マイルストーン後にロードマップを監査し、コードをレビューする
GOALS.md は、Codex が最後に更新した時点で判明していた情報を反映しています。マイルストーンの終わりまでに、プロジェクトは通常、何か新しいことを発見しています。
先に進む前に、別のスレッドにロードマップと現在の状態を比較するよう依頼します。
- マイルストーンは実際に完了しているか？
- 次の目標は依然として適切か？
- 欠落しているマイルストーンはないか？
- 新しいエビデンスによって作業の順序が変わったか？
- 完了の定義は依然として有効か？
この監査は各マイルストーンの終了時、および新しいエビデンスがプロジェクトの方向性を実質的に変更するたびに実行します。
また、実装に対して /review も実行します。
サインインフローの実装とリモートテストが完了したとします。ロードマップの監査により、実際にサインインしたブラウザでフローをテストした人がいないことが判明するかもしれません。同時に、/review により、リモートテストはパスしても、新しいパスがトークンを誤って保存していることが判明するかもしれません。
コーディネーターは GOALS.md を更新し、トークンの修正を委任し、不足しているブラウザ検証を追加し、その後でのみ次のマイルストーンをアクティブにします。
監査とレビューは通常、別々のスレッドで行います。サブエージェントでも同じ作業は可能ですが、別のスレッドにすることで、後で確認できる可視性のある記録が残ります。
4. Computer Use のテストにはローカルスレッドを使用する
私の Codex セッションのほとんどはリモートインスタンスで実行されるため、ラップトップを閉じている間も作業を続けられます。ただし、一部のチェックはローカルマシンに依存します。
- サインインしたブラウザ
- ローカル認証情報
- Xcode
- macOS の権限
- iOS シミュレーター
リモートコーディネーターは、これらのチェックのいずれかに対してローカルスレッドを作成できます。リモートの差分を適用するか、関連するブランチまたはコミットをチェックアウトして、ローカルスレッドが正しいコードをテストするようにします。
ローカルスレッドはブラウザまたはアプリケーションを操作し、スクリーンショット、ログ、調査結果を返します。チェックが失敗した場合、リモートワーカーが問題を修正し、ローカルスレッドが再度テストします。
典型的なループは次のようになります。
- リモートワーカーがサインインフローを実装する。
- リモートテストがパスする。
- ローカルスレッドが Codex Chrome 拡張機能 を使用する。
- ブラウザテストでリダイレクトのバグが明らかになる。
- リモートワーカーがそれを修正する。
- ローカルスレッドがチェックを繰り返す。
プロジェクトはデフォルトでリモートのままです。私のコンピュータは、それを必要とするチェックのためだけに参加します。リモートスレッドは、ラップトップを再度開いたときにローカルスレッドが再び利用可能になるかどうかを確認し続けることもできます。
5. 簡潔なアップデートとダッシュボードで進捗を報告する
ワーカースレッドは通常、1 つのタスクについて報告します。プロジェクトに戻ったとき、全体的な状態を把握する必要があります。
- 何が完了したか
- 何が変更されたか
- 何が残っているか
- 何について決定が必要か
プロジェクトの状態が変わるたびに、Codex に次の 3 つの短いセクションを使用して報告するよう依頼します。
**完了したこと
次に行うこと
ブロッカーがあれば**
これは、Codex と毎日スタンドアップミーティングを行っているようなものですが、毎時間行われます。
Codex は同じアップデートを Slack に、ダイレクトメッセージまたは専用のプロジェクトチャンネルとして送信できます。
Codex アプリを使用している間は、/side を使用してメインスレッドを中断せずに状況を確認することもできます。サイドスレッドから、何が完了したか、何が残っているか、手動でのクリック、承認、その他のクリックオプスなど、私の助けが必要なものがあるかどうかの要約を依頼できます。
サイドスレッドから要約を取得
サイドスレッドに指示をメインスレッドに伝えるよう依頼
その後、指示を明確にしたり、ブロッカーを解決したり、コンテキストを追加したり、サイドスレッドに更新されたガイダンスをメインスレッドに送り返すよう依頼したりできます。
複数のマイルストーンや並行するワークストリームがあるプロジェクトでは、progress-dashboard.html も管理します。これは組み込みの Codex UI ではなく、カスタムプロジェクトアーティファクトです。以下を表示できます。
- アクティブな目標
- 完了したマイルストーン
- エビデンス
- ブロッカー
- 決定事項
- 最近のアップデート
数時間後に戻ってきたときに、すべてのワーカースレッドを読まなくてもプロジェクトの状態を理解できます。Codex はダッシュボードを Site としてデプロイし、リモートからアクセスできるようにすることもできます。
まとめ
この構造は、プロジェクトが新しい情報を発見する可能性が高い場合、複数の独立した作業が含まれる場合、または複数の環境からのエビデンスが必要な場合に使用します。
ワークフローは単純なサイクルに従います。Codex は最初の会話をロードマップに変え、1 つのマイルストーンをアクティブにし、作業を委任し、結果を確認してから次に進みます。ローカルスレッドは私のマシンを必要とするチェックを処理し、アップデートとダッシュボードは、すべてをゼロから再構築することなくプロジェクトに戻るのに役立ちます。
重要なのは、次の決定が Codex が実際に学んだことを反映できるように、プロジェクトの状態を常に最新に保つことです。
試してみる
これを新しい Codex スレッドに貼り付けてください。
これを長期実行プロジェクトとして調整してください。
まず、私が何を構築しようとしているのかについてインタビューを行ってください。私が大まかなアイデアや制約を会話形式で説明できるようにし、その後、その議論を初期計画に落とし込んでください。
共有ロードマップとして GOALS.md を作成してください。マイルストーンを中心に整理し、各マイルストーンの意図した成果、スコープ、決定事項、ブロッカー、必要なエビデンスを記載してください。
一度に 1 つの Goal モードの目標を設定し、維持してください。アクティブな目標は現在のマイルストーンに対応している必要があります。
このスレッドを目標、制約、決定事項、プロジェクト状態に集中させてください。実装はサブエージェントまたは新しいスレッドに委任してください。
ワーカーには、完全なトランスクリプトではなく、結論、変更点、エビデンスを返すように要求してください。
後で作業を検査、継続、またはレビューする可能性がある場合は、別のスレッドを使用してください。独自の可視性のある履歴を必要としない境界のある作業にはサブエージェントを使用してください。
各マイルストーンの後、別のスレッドを使用して GOALS.md を現在の状態に対して監査し、実装に対して /review を実行してください。次の目標をアクティブにする前にロードマップを更新してください。
ブラウザ、デスクトップアプリケーション、権限、認証情報、またはデバイスの状態に依存する Computer Use テストには、ローカルスレッドを使用してください。
*プロジェクトの状態が変わった場合は、以下のみを報告してください。 - 完了したこと - 次に行うこと - ブロッカーがあれば*
プロジェクトが複数のマイルストーンまたはワーカーにまたがる場合は、progress-dashboard.html を管理してください。合意されたエビデンスが存在するまで、完了を宣言しないでください。
または、この記事の Appshot を取得して、Codex に次のように依頼することもできます。
この記事から、orchestrate-projects という名前の再利用可能な Codex スキルを作成してください。
以下のプラクティスを保持してください。
*- Codex にインタビューさせ、初期計画を作成させる - GOALS.md をマイルストーンベースのロードマップとして使用する - 一度に 1 つの Goal モードの目標をアクティブに保つ - メインスレッドを調整に集中させる - 各マイルストーン後にロードマップを監査し、/review を実行する - 後で再確認したい作業には別のスレッドを使用する - Computer Use テストにはローカルスレッドを使用する - 簡潔なアップデート、Slack、progress-dashboard.html を通じて進捗を報告する*
