はじめに
OpenAI Codexの真価は、単一タスクの処理能力だけでなく、複数のタスクを同時に管理・実行できる点にあります。従来のAIコーディングツールでは、1つのタスクが完了するまで次のタスクに着手できませんでした。Codexでは、クラウドサンドボックスの分離された環境を活用することで、複数の開発タスクを並列に実行し、効率的に管理できます。
本記事では、複数タスクの同時実行方法から、進捗監視、タスクの中断と再開、実行ログの読み解き方、そしてタスク完了後のレビューフローまでを実践的に解説します。
前提条件
本記事の内容を実践するには、以下の準備が必要です。
| 要件 | 詳細 |
|---|---|
| ChatGPTプラン | Plus、Pro、Business、Edu、Enterpriseのいずれか |
| GitHub連携 | Codexとの接続設定が完了していること |
| 環境設定 | 対象リポジトリの環境が作成済みであること |
基本操作については、前回の記事で解説していますので、まだ設定が完了していない方はそちらを参照してください。
スレッドの概念を理解する
Codexにおけるタスク管理の基本単位は「スレッド」です。スレッドとは、プロンプトの送信からCodexの応答、ツール呼び出しまでを含む一連のセッションを指します。
スレッドの特徴
flowchart TD
subgraph "スレッド(Thread)"
A[プロンプト送信] --> B[モデル応答]
B --> C[ツール呼び出し]
C --> D[ファイル編集]
D --> E[テスト実行]
E --> F{完了 or キャンセル}
endスレッドは以下の特性を持ちます。
| 特性 | 説明 |
|---|---|
| 実行中状態 | Codexがアクティブに作業している状態 |
| 複数プロンプト | 1つのスレッド内で複数のプロンプトを送信可能 |
| 並列実行 | 複数のスレッドを同時に実行可能 |
| 再開可能 | 中断後に続きから作業を継続可能 |
ローカルスレッドとクラウドスレッド
Codexのスレッドには2種類あり、用途に応じて使い分けます。
ローカルスレッド
ローカルマシン上で実行されるスレッドです。Codexはファイルの読み書きやコマンド実行を行い、変更を直接確認できます。セキュリティを考慮し、サンドボックス内で実行されます。
クラウドスレッド
Codexのクラウド環境で実行されるスレッドです。リポジトリをクローンし、指定されたブランチをチェックアウトして作業します。並列実行やバックグラウンド処理に適しています。
flowchart LR
subgraph "ローカルスレッド"
L1[IDE/CLI] --> L2[ローカルファイル]
L2 --> L3[即時フィードバック]
end
subgraph "クラウドスレッド"
C1[Codex Web] --> C2[クラウドサンドボックス]
C2 --> C3[PR作成]
end
L1 -.->|委任| C1複数タスクの同時実行
Codexの強力な機能の一つが、複数のタスクを同時に実行できる点です。各タスクは独立したサンドボックスで実行されるため、相互に影響を与えません。
並列実行のメリット
複数タスクを並列に実行することで、以下のメリットが得られます。
| メリット | 説明 |
|---|---|
| 時間効率 | 待ち時間なしで複数の作業を進行 |
| 独立性 | 各タスクが分離された環境で安全に実行 |
| 柔軟性 | 異なるブランチで同時に作業可能 |
| スケーラビリティ | チーム全体の生産性向上 |
並列実行の開始方法
Codexダッシュボードから複数のタスクを同時に開始する方法を説明します。
Step 1: 最初のタスクを開始
環境を選択し、最初のタスクを「コード」モードで送信します。
認証モジュールにリフレッシュトークン機能を追加してください。
トークンの有効期限は7日間とし、期限切れ時に自動更新するようにしてください。
Step 2: 新しいタブでタスクを追加
タスクが実行中の状態で、Codexダッシュボードの「New Task」ボタンをクリックします。新しいタスクウィンドウが開きます。
ユーザープロファイルAPIに、プロファイル画像のアップロード機能を追加してください。
画像サイズは最大5MB、対応形式はJPEG、PNG、WebPとしてください。
Step 3: さらにタスクを追加(必要に応じて)
同様の手順で、必要な数だけタスクを追加できます。
ダッシュボード画面のパフォーマンスを最適化してください。
特にAPI呼び出しの削減とコンポーネントのメモ化に注力してください。
並列実行時の注意点
複数タスクを同時に実行する際は、以下の点に注意が必要です。
同一ファイルの編集を避ける
flowchart TD
A[タスク1: auth.ts を編集] --> B{コンフリクト発生リスク}
C[タスク2: auth.ts を編集] --> B
B --> D[マージ時に競合]
E[タスク1: auth.ts を編集] --> F{安全}
G[タスク2: profile.ts を編集] --> F
F --> H[独立してマージ可能]| 状況 | 推奨アクション |
|---|---|
| 同じファイルを編集する可能性がある | タスクを順次実行 |
| 異なるモジュールの作業 | 並列実行OK |
| 依存関係がある | 親タスク完了後に子タスクを開始 |
レート制限の考慮
プランによって、同時に実行できるタスク数や使用量に制限があります。
| プラン | 推奨同時実行数 |
|---|---|
| Plus | 2〜3タスク |
| Pro | 3〜5タスク |
| Business/Enterprise | チーム設定による |
タスクの進捗確認
実行中のタスクの進捗を効率的に監視する方法を解説します。
ダッシュボードでの一覧確認
Codexダッシュボードでは、すべてのアクティブなタスクを一覧で確認できます。
タスクリストの表示項目
| 項目 | 説明 |
|---|---|
| タスク名 | プロンプトの要約または自動生成されたタイトル |
| ステータス | Running / Completed / Failed / Cancelled |
| 経過時間 | タスク開始からの経過時間 |
| 環境 | 使用している環境名 |
| ブランチ | 作業対象のブランチ |
リアルタイム進捗インジケーター
個々のタスクをクリックすると、詳細な進捗状況を確認できます。
進捗ステータスの詳細
stateDiagram-v2
[*] --> Starting: タスク開始
Starting --> Reading: 環境準備完了
Reading --> Thinking: コード読み込み完了
Thinking --> Editing: 解決策決定
Editing --> Testing: 編集完了
Testing --> Editing: テスト失敗
Testing --> Completed: テスト成功
Starting --> Failed: セットアップエラー
Reading --> Failed: 読み込みエラー
Editing --> Failed: 編集エラー
Testing --> Failed: 致命的エラー
Starting --> Cancelled: ユーザーキャンセル
Reading --> Cancelled: ユーザーキャンセル
Thinking --> Cancelled: ユーザーキャンセル
Editing --> Cancelled: ユーザーキャンセル
Testing --> Cancelled: ユーザーキャンセル各ステータスの意味
| ステータス | 意味 | 推定時間 |
|---|---|---|
| Starting | コンテナの起動とリポジトリのクローン | 5〜30秒 |
| Reading | コードベースの読み込みと分析 | 10〜60秒 |
| Thinking | 解決策の検討と計画 | 30秒〜5分 |
| Editing | ファイルの編集 | タスクによる |
| Testing | テストとLintの実行 | プロジェクトによる |
| Completed | タスク完了 | - |
| Failed | エラーで停止 | - |
| Cancelled | ユーザーによるキャンセル | - |
コンテキスト使用量の監視
長時間のタスクでは、コンテキストウィンドウの使用状況を監視することが重要です。
Codexはモデルのコンテキストウィンドウを監視し、残り容量を報告します。長いタスクでは、自動的にコンテキストを圧縮(要約)して、関連性の高い情報を保持しながら作業を継続します。
タスクの中断と再開
実行中のタスクを中断し、後から再開する方法を解説します。
タスクのキャンセル
実行中のタスクは、いつでもキャンセルできます。
キャンセル方法
- タスク詳細画面を開く
- 「Cancel」ボタンをクリック
- 確認ダイアログで「Yes, cancel」を選択
キャンセルのユースケース
| 状況 | 推奨アクション |
|---|---|
| 間違った指示を送った | 即座にキャンセルして再送信 |
| 想定と異なる方向に進んでいる | キャンセルして指示を明確化 |
| 優先度の高いタスクが発生 | キャンセルして優先タスクを実行 |
| 時間がかかりすぎている | キャンセルしてタスクを分割 |
タスクの再開(Resume)
キャンセルしたタスクや、完了したタスクに対してフォローアップを送信することで、作業を継続できます。
フォローアップの送信
タスク完了後またはキャンセル後に、同じスレッド内でプロンプトを送信すると、前のコンテキストを維持したまま作業を継続できます。
先ほどの変更に加えて、エラーハンドリングを強化してください。
特にネットワークエラーとタイムアウトのケースを適切に処理してください。
CLIでのセッション再開
Codex CLIでは、codex resumeコマンドを使用して、前回のセッションを再開できます。
|
|
これにより、中断した箇所から作業を継続できます。
実行ログの読み方
Codexが実行したアクションを詳細に追跡するための、実行ログの読み方を解説します。
ターミナルログの構造
タスク詳細画面の「Terminal」タブで、Codexが実行したすべてのコマンドと出力を確認できます。
ログの構成要素
[12:34:56] $ npm install
added 142 packages in 4.3s
[12:35:01] $ npm run lint
> project@1.0.0 lint
> eslint src/**/*.ts
✓ No issues found
[12:35:08] $ npm test
PASS src/auth/auth.service.spec.ts
AuthService
✓ should validate token (12 ms)
✓ should refresh expired token (8 ms)
Test Suites: 1 passed, 1 total
Tests: 2 passed, 2 total
ログの読み方
| 要素 | 説明 |
|---|---|
| タイムスタンプ | コマンド実行時刻 |
| コマンド | 実行されたシェルコマンド |
| 出力 | コマンドの標準出力・標準エラー |
| 終了コード | コマンドの成功(0)または失敗(非0) |
アクションログの確認
Codexが実行したファイル操作やツール呼び出しを確認できます。
アクションの種類
| アクション | 説明 |
|---|---|
| read_file | ファイルの読み取り |
| write_file | ファイルの書き込み |
| apply_patch | パッチの適用(差分編集) |
| run_command | シェルコマンドの実行 |
| search | コードベースの検索 |
アクションログの例
Action: read_file
Path: src/auth/auth.service.ts
Lines: 1-150
Action: apply_patch
Path: src/auth/auth.service.ts
Changes: +15 lines, -3 lines
Action: run_command
Command: npm test src/auth/auth.service.spec.ts
Exit code: 0
エラーログの分析
タスクが失敗した場合、エラーログを分析して原因を特定します。
よくあるエラーパターン
| エラータイプ | 原因 | 対処法 |
|---|---|---|
| Setup failed | 依存関係のインストール失敗 | セットアップスクリプトを確認 |
| Test failed | テストが通らない | テストコードまたは実装を修正 |
| Lint error | コード規約違反 | Lintエラーを修正 |
| Timeout | 処理時間超過 | タスクを分割 |
| Permission denied | 権限不足 | GitHub連携を再確認 |
テスト結果の確認方法
Codexはタスク実行中にテストを自動で実行し、その結果を検証します。
テスト実行の流れ
flowchart TD
A[コード編集完了] --> B[テスト実行]
B --> C{テスト結果}
C -->|成功| D[次のステップへ]
C -->|失敗| E[失敗原因を分析]
E --> F[コードを修正]
F --> Bテスト結果の表示
タスク完了後、テスト結果は以下の形式で表示されます。
成功時
Test Results:
✓ All tests passed (24 tests in 3 suites)
Coverage:
Statements: 87.5%
Branches: 82.3%
Functions: 91.2%
Lines: 88.1%
失敗時
Test Results:
✗ 2 tests failed, 22 passed (24 tests in 3 suites)
Failures:
1) AuthService > should handle expired refresh token
Expected: UnauthorizedError
Received: undefined
2) AuthService > should reject invalid token format
Timeout: exceeded 5000ms
テスト失敗時の対応
Codexはテストが失敗した場合、自動的に修正を試みます。ただし、修正が困難な場合はユーザーへの報告を行います。
フォローアップ例
テストが失敗しています。以下の点を修正してください:
1. handleExpiredRefreshToken メソッドで UnauthorizedError をスローするように
2. タイムアウトテストは、モックを使用して高速化してください
引用(Citations)の確認方法
Codexは変更の根拠を「引用」として提供します。これにより、なぜその変更が行われたのかを追跡できます。
引用の種類
| 引用タイプ | 説明 |
|---|---|
| ファイル参照 | 参考にしたソースファイル |
| テスト結果 | 検証に使用したテストの結果 |
| ドキュメント | 参照した仕様やREADME |
| エラーメッセージ | 修正の根拠となったエラー |
引用の活用方法
引用を確認することで、Codexの判断プロセスを理解し、レビューを効率化できます。
引用表示の例
変更理由:
- src/auth/auth.service.ts の既存のtokenValidation実装を参考に、
refreshToken処理を追加しました [参照: auth.service.ts:45-67]
- JWT仕様に基づき、exp クレームで有効期限を管理します [参照: README.md:認証仕様]
- 既存のテストパターンに従い、モックを使用しています [参照: auth.service.spec.ts:12-34]
タスク完了後のレビューフロー
タスクが完了したら、体系的なレビューを行いましょう。
レビューチェックリスト
flowchart TD
A[タスク完了] --> B[コードDiffを確認]
B --> C[テスト結果を確認]
C --> D[引用を確認]
D --> E[実行ログを確認]
E --> F{問題あり?}
F -->|はい| G[フォローアップを送信]
G --> A
F -->|いいえ| H[PRを作成 or 変更を適用]コードDiffのレビュー
変更されたファイルの差分を詳細に確認します。
確認ポイント
| ポイント | 確認内容 |
|---|---|
| 変更範囲 | 想定した範囲のみ変更されているか |
| コード品質 | 既存のコードスタイルに合っているか |
| エッジケース | 例外的なケースが考慮されているか |
| セキュリティ | 脆弱性が含まれていないか |
| パフォーマンス | 効率的な実装になっているか |
フォローアップの活用
レビューで問題を発見した場合、フォローアップで修正を依頼します。
効果的なフォローアップの書き方
レビューでいくつかの改善点を発見しました:
1. src/auth/auth.service.ts:78
- refreshToken が null の場合のエラーハンドリングを追加してください
2. src/auth/auth.controller.ts:45
- レスポンスの型定義を追加してください
3. テストカバレッジ
- トークン期限切れのエッジケースをテストに追加してください
PRの作成とマージ
レビューが完了したら、PRを作成します。
PR作成時のオプション
| オプション | 説明 |
|---|---|
| ブランチ名 | 自動生成またはカスタム指定 |
| PRタイトル | タスク内容に基づいて自動生成 |
| PR説明 | 変更のサマリーと引用を含む |
| レビュアー | 自動でチームメンバーを提案(Enterprise) |
効率的なタスク管理のベストプラクティス
タスクの粒度を適切に設定する
大きすぎるタスクは失敗しやすく、小さすぎるタスクは非効率です。
推奨されるタスクサイズ
| タスクタイプ | 推奨サイズ | 例 |
|---|---|---|
| バグ修正 | 1〜3ファイル | 特定のエンドポイントのバグ修正 |
| 機能追加 | 3〜10ファイル | 単一のAPI機能追加 |
| リファクタリング | 5〜15ファイル | 1モジュールの構造改善 |
| テスト追加 | 1〜5ファイル | 特定モジュールのテスト |
依存関係を考慮した実行順序
タスク間に依存関係がある場合は、適切な順序で実行します。
flowchart LR
A[基盤タスク] --> B[機能タスク1]
A --> C[機能タスク2]
B --> D[統合タスク]
C --> D命名規則とタグ付け
タスクを識別しやすくするため、一貫した命名規則を使用します。
命名例
[Feature] ユーザー認証: リフレッシュトークン機能
[Bug] API: プロファイル更新時の500エラー修正
[Refactor] Database: クエリ最適化
[Test] Auth: エッジケースのテスト追加
まとめ
本記事では、Codexのタスク管理における実践的なテクニックを解説しました。
学んだこと
- スレッドの概念とローカル/クラウドの使い分け
- 複数タスクの並列実行方法と注意点
- リアルタイム進捗監視の活用
- タスクの中断と再開(Resumeコマンド)
- 実行ログとテスト結果の読み方
- 引用を活用した変更追跡
- 体系的なレビューフロー
効率的なタスク管理は、Codexを最大限に活用するための鍵です。並列実行を活用することで開発速度を向上させ、適切な監視とレビューによって品質を担保できます。
次のステップとして、AGENTS.mdによるCodexの最適化を学ぶことで、プロジェクト固有の知識をCodexに伝え、さらに高品質なコード生成を実現できます。