Codex を触り始めると、複数エージェントはどう切るべきか、Codex cloud はどこで使うべきか、internet access を開けても大丈夫か が一気に気になり始めます。調査、修正、テスト追加、ドキュメント更新を同時に投げれば速そうに見えますが、境界を曖昧にしたまま並列化すると、だいたい review か権限設計で破綻します。
ただし、ここを雑に扱うとすぐ破綻します。
- 同じファイルを複数スレッドが触って差分が衝突する
- background 作業の結果を誰もレビューしない
- 便利だからと広い権限でネットワークを開ける
- worktree から Local へ戻すタイミングが曖昧になる
- AGENTS.md のルールが薄く、各エージェントの判断が揺れる
この記事では、Codex の複数エージェント運用を「速くする小技」ではなく、作業を隔離してレビュー可能にする設計として整理します。特に Codex cloud 使い方 と Codex internet access を調べている人向けに、app / cloud / CLI をどう分けるか、worktree に逃がす基準、allowlist をどう切るか まで実務の順番で説明します。Claude Code との全体比較を先に見たい場合は Claude Code vs Codex CLI 比較、複数エージェントの一般論から入りたい場合は マルチエージェントオーケストレーション 4パターン解説 を先に読むとつながります。Codex 固有の運用へ降ろすときは、制御設計の土台として Harness Engineering 入門、再利用する指示部品として Codex Skills 設計入門、定期実行へ広げる記事として Codex Automations 実践ガイド が隣接します。特に Codex cloud 使い方 や Codex internet access が気になっている場合は、後半のネットワーク権限とレビュー境界の節を先に読めば要点をつかみやすいです。
結論だけ先に言うと、複数エージェント は「何本でも同時に投げてよい」話ではなく、cloud に回す仕事 と Local に残す仕事 を切り分けたあとで初めて効きます。internet access も同様で、便利だから開けるのではなく、どの調査に必要で、どのドメインまで許すか を先に決めるべきです。
Codex の主戦場記事を読む順番としては、最初に Codex Automations 実践ガイド で background task の境界を押さえ、次に Codex Skills 設計入門 で指示の再利用単位を整理し、その後に本記事で並列実行と worktree 分離へ進むと、役割の違いを混同しにくくなります。
先に結論: 複数エージェント化する前に「衝突しない仕事」だけを切り出す
OpenAI の Codex app ドキュメントでは、Codex app は複数の Codex スレッドを並列に扱うためのデスクトップ体験で、worktree、automations、Git 機能を組み込んでいると説明されています。さらに worktree は、同じプロジェクト内で独立したタスクを互いに干渉させずに動かすための仕組みです。
ここで重要なのは、並列にできる仕事と、並列にしてはいけない仕事を分けることです。
Codex に同時に投げやすい仕事:
- 既存コードの調査
- 失敗しているテストの原因切り分け
- 小さなバグ修正
- テスト追加
- ドキュメント更新
- PR差分のレビュー
Codex に同時に投げると危ない仕事:
- 同じ設計判断に依存する複数実装
- 同じファイルを触る修正
- 仕様がまだ曖昧な新機能
- DBスキーマや認可のように全体整合性が重要な変更
- ネットワークアクセスや秘密情報に触れる作業
私なら、最初の基準をこう置きます。
1つのスレッドの成果を捨てても、他のスレッドが壊れないなら並列化してよい。
逆に、あるスレッドの判断が別スレッドの前提になるなら、直列にした方が安全です。
Codex app、Codex cloud、CLI の役割を先に分ける
Codex には複数の入口があります。Help Center では、Codex はローカルツールでペアリングする使い方と、クラウドに作業を委譲する使い方の両方が説明されています。Codex app は、そのうち複数エージェントを並列に扱いやすい入口です。
ざっくり分けると、私はこう使います。
| 入口 | 向いている仕事 | 注意点 |
|---|---|---|
| Codex app | 複数スレッド、worktree、Git 操作を見ながら進める | 並列数を増やしすぎるとレビューが詰まる |
| Codex cloud | background task、調査、修正、PR 草案化 | sandbox 環境と internet access を明示する必要がある |
| Codex CLI | 手元で対話しながら修正する | ローカル作業ツリーを汚しやすい |
| IDE extension | 編集中の文脈で小さく直す | 大きな並列委譲には向きにくい |
この記事で扱う中心は Codex app + Codex cloud + worktree の境界です。CLI や IDE extension まで全部同じ「Codex」として語ると、どこで review し、どこで secrets を守り、どこで git を切るかが曖昧になります。
Codex cloud が向く仕事
私なら、次のような仕事は cloud に寄せます。
- すぐに返答しなくてよい background 調査
- GitHub issue や PR を見て下書きを作る仕事
- 手元の IDE やブラウザを使わずに閉じる小修正
- review 前提であとから diff を回収できる仕事
逆に、次は cloud に寄せません。
- ローカル DB やブラウザ確認が必要な作業
- secrets や顧客データに密接する作業
- 仕様が固まっていない大きな実装
- すぐ横で自分が同じファイルを触っている作業
Codex cloud 使い方 で一番重要なのは、クラウドに投げること自体ではなく、background に回しても壊れにくい仕事だけを選ぶことです。その意味では、本記事の worktree 分離と同じ原則で考えるのが安全です。定期実行や inbox 回収まで含めて設計したいなら、Codex Automations 実践ガイド を先に読むとつながります。
Ask / Code を混ぜず、GitHub 依頼もそのまま実行させない
cloud 側に寄せるときは、最初から「調査だけ」か「修正まで」かを分けた方が安定します。
- Ask 相当: 影響範囲調査、既存パターン探索、レビュー観点整理
- Code 相当: 小さい修正、テスト追加、PR 下書き
特に GitHub issue や外部テキストをそのまま食わせる形は危ないです。私は一度自分で読み、何をしてよいか 何をしてはいけないか を短く言い換えてから渡します。prompt injection や外部指示の混入まで含めて考えるなら、MCP prompt injection 対策ガイド も補助線になります。
Local は前線、worktree は隔離作業場として使う
OpenAI の worktree ドキュメントでは、Local を自分の通常のチェックアウト、worktree を Codex app が作る別チェックアウトとして説明しています。Git worktree を使うため、同じリポジトリの別ブランチを並列に扱えます。
この違いは、実務ではかなり大きいです。
Local に残すべき仕事:
- 仕様確認をしながら進める作業
- 自分のIDE、ローカルDB、ブラウザ確認が必要な作業
- 最終的な統合とレビュー
- 本命ブランチのコミット整理
worktree に逃がすべき仕事:
- 既存コード調査
- 小さく独立した修正
- 追加テストの草案作成
- リファクタ案の比較
- ドキュメントや型定義の補助修正
私は、Local を「人間が責任を持つ前線」、worktree を「Codex に試させる隔離作業場」として扱うのが一番安定すると考えています。
worktree 上でよい差分ができたら、そこからブランチ化し、コミットしてPRにします。OpenAI の docs でも、worktree で作業を続ける場合はその場所でブランチを作り、コミット、push、GitHub PR作成へ進められると説明されています。定期棚卸しや review queue を background 側へ逃がしたいなら、worktree の使いどころは Codex Automations 実践ガイド とそのまま接続します。
逆に、まだ設計が揺れているものをいきなり worktree に投げると、戻ってきた差分の評価に時間がかかります。曖昧な仕事は Local で会話し、境界が切れたら worktree に出す。この順番が現実的です。
私が使うタスク分割の型
Codex を複数走らせるとき、私はタスクを次の4種類に分けます。
1. explorer: 調査だけさせる
目的:
- 影響範囲を調べる
- 関係ファイルを列挙する
- 既存パターンを探す
依頼例:
このリポジトリで記事slugを生成・検証している箇所を調べてください。
編集はしないでください。
返答は、関係ファイル、現在の仕様、変更時の注意点の3つに絞ってください。これは一番安全です。書き込みをさせないので、同時に複数走らせても衝突しにくい。Codex の subagents docs でも、コードベース探索や複数観点レビューのような高並列タスクが典型例として挙げられています。
2. fixer: 小さな修正だけさせる
目的:
- 1つのバグを直す
- 1つのテストを追加する
- 1つの型エラーを消す
依頼例:
src/lib/read-time.ts だけを対象に、日本語と英数字混在時の読了時間計算を修正してください。
関連テストがなければ最小限追加してください。
他ファイルの設計変更はしないでください。fixer に渡す仕事は、ファイル境界か責務境界で切ります。「ブログ機能を改善して」のような依頼は広すぎます。「この関数だけ」「このページだけ」まで落とします。このとき、依頼文の型を毎回ゼロから書かずに済ませるには Codex Skills 設計入門 のように task ごとの部品へ落とす方が安定します。
3. reviewer: 差分だけ読ませる
目的:
- 変更後のリスク確認
- セキュリティ観点の指摘
- テスト不足の発見
依頼例:
このブランチとmainの差分をレビューしてください。
バグ、セキュリティ、SEO上の回帰、テスト不足を優先してください。
修正はしないでください。reviewer は write させない方がよいです。レビューと修正を同じスレッドに混ぜると、指摘が弱くなります。これは AIコーディングツールの社内ガイドライン で書いた「レビュー境界」と同じ考え方です。
4. integrator: 最後に人間が見る
ここは Codex に丸投げしません。
複数スレッドの成果を統合する段階では、次を人間が判断します。
- 採用する差分
- 捨てる差分
- 同じ問題を別解で解いていないか
- PRを1本にまとめるか、分けるか
- 検証コマンドの結果が本当に十分か
複数エージェント運用の失敗は、実装中より統合時に起きます。速く作った差分を雑に混ぜると、あとで原因追跡が難しくなります。
worktreeに投げる前のチェックリスト
Codex に worktree 作業を任せる前に、私は最低限これを確認します。
- 対象ファイル範囲を言えるか
- 成功条件を1文で言えるか
- 変更してはいけない領域を言えるか
- 実行すべき検証コマンドを言えるか
- 失敗したら捨ててよい作業か
全部 yes なら worktree に向いています。
たとえば、次は向いています。
src/content/blog 配下の記事frontmatterだけを確認し、descriptionがない記事を列挙してください。
編集はしないでください。次は広すぎます。
ブログのSEOを改善してください。後者は、先に人間がテーマ、対象ページ、評価軸を切る必要があります。このサイトでも、SEO施策は data/seo/keyword-plan.md と data/seo/learnings.md に分けて管理しています。AIに任せる前に、作業単位を小さくすること自体が重要です。
AGENTS.md は「全員に同じ前提を渡す」ために置く
OpenAI の AGENTS.md docs では、Codex は作業前に AGENTS.md を読み、グローバル、プロジェクト、ディレクトリ単位の指示を階層的に組み合わせると説明されています。
複数エージェント運用では、AGENTS.md の重要度が上がります。理由は単純で、スレッドが増えるほど、各エージェントに同じ前提を渡す必要があるからです。
最低限書くべき内容:
- パッケージマネージャ
- build / test / format コマンド
- 触ってよいディレクトリ
- 触ってはいけないディレクトリ
- PR前の検証条件
- 既存差分を巻き戻さないルール
- セキュリティ上の禁止事項
悪い AGENTS.md:
# Instructions
いい感じに実装してください。良い AGENTS.md:
# Instructions
- パッケージマネージャは pnpm
- 記事を追加したら `pnpm seo:update-llms` と `pnpm run build` を実行する
- 既存の未コミット差分は巻き戻さない
- mainへ直接コミットしない
- 外部ソースを参照した場合は記事末尾に参考資料を置く複数エージェントを使うなら、プロンプトを毎回長くするより、共通前提を AGENTS.md に寄せた方が安定します。これは Harness Engineering とは？ で書いた「エージェントを囲う」発想そのものです。
Codex internet access は「広く開ける設定」ではなく個別許可で扱う
Codex cloud の internet access docs では、agent phase のインターネットアクセスはデフォルトでブロックされ、必要な場合に環境単位で有効化すると説明されています。リスクとして、prompt injection、コードや秘密情報の流出、マルウェアや脆弱な依存関係の取得、ライセンス制約のあるコンテンツの取り込みが挙げられています。
この考え方は、Codex app で複数エージェントを使うときにも重要です。Codex internet access を調べている人に先に伝えたいのは、ネット接続は単なる補助機能ではなく、別の攻撃面を追加する設定だということです。
私が先に決める 4 項目
- どのタスクで外部通信が必要か
- 許可するドメインはどこか
- GET だけでよいか、POST も必要か
- 実行ログを誰がレビューするか
ネットワークを開けてよい例:
- 公式ドキュメントを読む必要がある
- package manager の install が必要
- 依存関係の脆弱性情報を確認する
ネットワークを開けない方がよい例:
- リポジトリ内だけで完結する調査
- PR差分レビュー
- 秘密情報や顧客コードに近い作業
- 外部IssueやREADMEをそのまま実行対象にする作業
特に「この GitHub Issue を見て直して」のような依頼は注意が必要です。外部テキストに隠れた指示が混ざる可能性があります。Codex に外部情報を読ませるなら、信頼できるドメインに絞り、POST 系メソッドを不要に開けない方がよいです。
実務では、私は次のように絞ります。
- 公式 docs 調査だけなら docs ドメイン + GET のみ
- package install が必要な検証だけ registry + GET/必要最小限
- Issue/PR 参照は GitHub に限定し、書き込み操作は人間レビュー後
もし社内ルールまで含めて整理したいなら、AIコーディングツールの社内ガイドライン の「入力境界」と「実行境界」がそのまま使えます。複数エージェントに広げるほど、allowlist は「書けること」ではなく「書かせないための柵」として設計した方が安全です。
並列数は「処理能力」ではなく「レビュー能力」で決める
Codex app で複数スレッドを並べられるからといって、10本同時に走らせる必要はありません。
私は、個人開発なら同時に動かすのは最大3本程度が現実的だと感じています。
- explorer: 調査
- fixer: 小さな修正
- reviewer: 差分レビュー
これ以上増やすと、レビューする人間が詰まります。AIの実行速度ではなく、人間が判断できる速度がボトルネックになります。
チームで使う場合も同じです。人数が多いから並列数を増やすのではなく、次を先に決めるべきです。
- 誰が最終レビューするか
- どの差分を捨てる基準にするか
- PRを分割する粒度
- 失敗タスクのログをどこに残すか
- 監査対象にする操作は何か
この設計なしに複数エージェントを回すと、「たくさん作ったが誰も責任を持てない差分」が増えます。まず制御原則から固めたいなら Harness Engineering 入門、指示の再利用単位を先に決めたいなら Codex Skills 設計入門、background の定期運用まで含めたいなら Codex Automations 実践ガイド の順で読むと、Codex クラスター全体の役割分担が見えやすくなります。
PRにする前の統合手順
worktree で良さそうな差分ができたら、私は次の順で見ます。
git diff --statで変更範囲を見る- 変更ファイルを上から読む
- Codex の作業ログと実際の差分を照合する
- 必要なら Local に handoff して手元で確認する
- build / test / format を実行する
- PR本文に「何を任せ、何を人間が確認したか」を書く
OpenAI の Codex 紹介記事でも、Codex は作業の根拠としてターミナルログやテスト出力を示し、ユーザーがレビュー、修正依頼、PR作成、ローカル統合を選べると説明されています。つまり、Codex の出力は「そのままマージするもの」ではなく、「レビュー可能な作業単位」です。
PR本文には、最低限これを書きます。
## Summary
- Codex worktreeで対象修正を実施
- 人間が差分と内部リンクを確認
## Verification
- pnpm run build
- pnpm seo:update-llms
## Review focus
- 対象外ファイルに副作用がないか
- 既存記事との検索意図が重複していないか複数エージェントで作ったPRほど、レビュー観点を明示した方がよいです。
よくある失敗
1. 同じファイルを複数スレッドに触らせる
これはほぼ衝突します。どうしても同じファイルを触るなら、直列にしてください。
2. 「調査」と「修正」を同時に頼む
最初は調査だけでよいです。調査結果を見て、修正タスクを切る方が精度が上がります。
3. worktreeを作っただけで安全だと思う
worktree は差分衝突を減らしますが、設計判断の衝突は防ぎません。認可、課金、DBスキーマのような変更は、人間が統合判断を持つ必要があります。
4. ネットワークを広く開ける
外部情報を読ませるほど攻撃面は広がります。必要なドメインとHTTPメソッドに絞るべきです。
5. レビューできない量を並列に投げる
AIが速くても、人間のレビューが追いつかなければ意味がありません。並列数はレビュー能力で決めるべきです。
まとめ
Codex の複数エージェント運用は、単に「同時にたくさん作業させる」機能ではありません。価値は、独立した作業を worktree に隔離し、Local を汚さず、レビュー可能な差分として回収できる点にあります。
私の結論はこうです。
- 並列化するのは、捨てても他作業に影響しない仕事だけ
- Local は人間が責任を持つ前線、worktree は隔離作業場として使う
- explorer、fixer、reviewer を分け、統合は人間が見る
- AGENTS.md で全スレッドに同じ前提を渡す
- internet access は必要タスクごとに allowlist で切る
- 並列数はAIの処理能力ではなく、人間のレビュー能力で決める
Codex app の worktree は強力です。ただし、強力なのは「自動で全部やってくれる」からではありません。人間が作業境界を切り、Codex が隔離された場所で試し、最後に人間が採用判断できるから強いのです。