Codexのサブエージェントと並列作業の注意点

こんにちは。Osukeラーニング、運営者の「osuke」です。

Codexのサブエージェントで並列作業をすれば、調査や実装が速くなるのでは。そう思っても、同じファイルを同時に直してよいのか、誰の結果を採用するのか、途中で止まった担当をどう扱うのかは迷いますよね。分担する前に、独立した仕事と、最後に一つへまとめる仕事を決めると整理しやすくなります。

この記事では、サブエージェントの頼み方、担当範囲、作業場所、同時編集、結果の統合と検証を説明します。2026年10月13日に確認したOpenAI公式資料とXの公開投稿をもとにした調査記事です。私自身の並列実行の体験や速度測定ではなく、ログイン機能のレビューは説明用の架空例です。

記事のポイント

• 並列に向く独立した仕事を選べる
• 担当範囲と編集の可否を具体的に決められる
• サブエージェントと作業場所の分離を区別できる
• 返された結果を統合して検証できる

Codexのサブエージェントと並列の基本

まずは、同時に進めてよい仕事を見つけます。担当を増やすだけでなく、待つ必要のある工程と、主担当が判断する工程も分けましょう。

独立した調査から分担する

最初の並列作業は、互いの結果を待たずに調べられる読み取りの仕事が向いています。たとえば一つの変更について、入力の境界を調べる担当と、テストの抜けを調べる担当に分けます。どちらも同じ変更を見られますが、調べる問いが違うので独立して進められます。一方、まだ決まっていない仕様を前提に実装とテストを同時に作ると、後から前提をそろえる作業が必要になるかもしれません。

OpenAIのサブエージェントの公式ガイドも、探索や調査などの読み取り中心の分担を出発点として案内しています。記事では、ログイン機能の変更を二つの観点で確認する例を使います。最初から複数の担当へ自由な修正を任せるのではなく、問題の候補、根拠、未確認事項を返してもらいます。主担当は返された結果を照合し、何を修正するかを判断します。

分担を考えるときは、「担当Aの結果が変わっても、担当Bはそのまま仕事を進められるか」と問いかけると分かりやすいです。進められないなら、先に必要な決定を終えるか、順番に依頼します。並列化はすべての工程を同時に始めるためのものではありません。独立して調べられる部分を同時に進め、依存する部分を順番に扱う設計です。小さな二つの調査から始め、返された情報を自分で確かめられる状態を作りましょう。

最初の分担候補

• コードの入力条件を調べる
• 既存テストの対象を調べる
• ログから失敗した工程を整理する

結果が出るまで他の担当を待たなくてよい仕事を選びます。たとえば入力条件の調査で仕様が未確定と分かった場合は、テスト担当にもその前提を伝えます。独立した調査であっても、全体の要件が変わったときは主担当が両方へ同じ条件をそろえる必要があります。

並列数と作業速度は比例しない

担当を二つに分けても、仕事全体が必ず半分の時間で終わるわけではありません。依頼を説明する時間、結果を待つ時間、重複を整理する時間、最後の検証があるからです。小さな一行の修正など、分けるより一人で終えた方が確認しやすい仕事もあります。最初は人数を増やすことより、分けることで何を同時に確かめられるかを決めましょう。全体の完了まで見て、並列化する価値を判断します。

公式資料では、サブエージェントごとにモデルやツールの作業が発生し、同等の単独実行よりトークンを多く使うと説明されています。複数の担当が同じ長い資料を繰り返し読めば、作業の重複も増えます。必要な資料と問いを絞り、返す情報の形式をそろえると、統合側の確認がしやすくなりますね。長いログをそのまま全員へ渡すより、対象と調べる範囲を指定して、根拠が必要な箇所だけを返してもらいましょう。

効果を見るときは、担当の数や表示上の進捗だけで判断しません。利用者が確認できる結果を得るまでの時間、修正が必要だった回数、重複した指摘、使った利用量などを比較します。同じ条件の実測がないまま、速さや費用の倍率を一般化することはできません。この記事も二担当を最適数として保証するものではなく、小さな試行の例です。結果を受け取る負担が増えるなら、分担を減らす選択も含めて見直します。

並列化の効果を見る項目

• 完成物を確認するまでの時間
• 重複した調査と指摘
• 統合や修正の手間
• 必要な範囲の利用量

サブエージェントと作業場所の違い

サブエージェントは仕事を分担する担当で、ワークツリーはGitの作業場所を分ける仕組みです。別のエージェントスレッドができたことだけで、ファイルも自動的に隔離されたと判断しないようにしましょう。調査なら同じコードを読めても、編集が加わる場合は、各担当がどの場所で作業するかの確認が必要です。担当の分離とファイルの分離を別々に確認すると、同時編集の行き違いを避けやすくなります。

架空の例として、画面の入力部分とサーバーの検証部分を同時に直す仕事を考えます。別のファイルへ分けたつもりでも、共通の型定義や設定を両方が変更する可能性があります。作業場所を分けた場合も、最後に同じ仕様へ統合する工程は残ります。また、共有のデータベースや外部サービスを使っていれば、ファイルを分けるだけでは影響を隔離できません。どのファイルと接続先を使うかを、担当範囲に含めて確認します。

公式のワークツリー資料は、別のチェックアウトを使う並列作業を説明しています。ただし、記事で示す分担例が、各サブエージェントへ自動的に新しいワークツリーを用意するという意味ではありません。実際の作業場所と参照する変更を確認してから依頼します。ワークツリーの詳しい使い方は、Codexワークツリーの使い方と注意点へ分けています。並列作業では、場所が違うことに加えて、同じ前提で結果を比べられることが重要です。

分離を確認する二つの問い

• 担当：誰が何を調べ、何を変更するか
• 場所：どのチェックアウト、ファイル、接続先を使うか

別スレッドの表示だけで、作業場所や外部状態の隔離を確定しないようにします。結果にも参照した場所を残すと、統合時に比較できます。

Xの運用例と反対事例を読む

Xで確認したMadeactualさん（@Madeactual）の投稿は、サブエージェントの多いCodexセッションでデスクトップ表示に負荷を感じ、作業を一つずつ進める方法や短い進捗記録を使うという運用紹介でした。条件や再現手順は分からないため、すべての環境で同じ問題が起きるとは言えません。それでも、表示上の作業が増えたときに、対象と進捗を短く記録することは、確認方法を考える着眼点になります。

Soumyadeb Mitraさん（@soumyadeb_mitra）の投稿は、Codex CLIを組み込んだ独自システムの話でした。複数のセッションがあるときの再開先や、工程が実行されたかの確認に困り、制御の方法を変えたと説明しています。これは独自のサブプロセス連携の報告で、Codex組み込みのサブエージェントの一般的な不具合とは扱いません。何を再開し、どの条件を渡し、何が終わったかを識別する必要がある、という論点に限定して参考にします。

Chad Coderさん（@thechadcoder）の投稿は、Codexと別製品の個人比較を紹介し、並列処理を含む費用に言及していました。同じ条件の実験をこの記事で検証したわけではなく、時間、費用、倍率や製品の優劣は採用していません。今回のX調査で得られたのは、運用の摩擦や比較の着眼点です。再現可能な性能測定や現行版固有の失敗手順までは取得できなかったので、原因を推測せず、公式資料と確認できる結果を基準に分担を設計します。

投稿を記事へ使う範囲

• 本人の運用紹介は条件が分かる範囲で読む
• 独自システムの問題を標準機能へ一般化しない
• 別製品の費用比較を並列数の推奨値にしない

これらはosuke本人の並列実行の実績ではありません。

目的と担当範囲を依頼へ書く

分担を頼むときは、目的、対象、担当範囲、編集の可否、返す結果、待ち方、完了条件をそろえます。たとえば「ログイン機能を並列で確認して」だけでは、全員が同じ箇所を見たり、調査のつもりが修正まで進んだりするかもしれません。「入力の境界」と「テストの抜け」に分け、どちらも読み取りのみと指定すれば、結果を比べる入口ができます。何人使うかに加えて、各担当が答える問いを明確にしましょう。

対象となる変更もそろえます。同じリポジトリでも、片方が未保存の変更を見て、もう片方が別のブランチを見ていれば、結論が違う理由を追いにくくなります。参照するブランチ、コミット、差分やファイルを指定し、必要なら結果に対象を記載してもらいます。担当へ渡す情報は、要件と範囲が分かるものに絞ります。独立した調査でも、期待する動作という共通の前提がないと、指摘の基準がそろいません。

さらに、結果の形式をそろえると主担当が統合しやすくなります。問題の候補、起きる入力、期待する動作、根拠のファイル、確認済みと未確認の項目を返してもらいます。「問題なし」だけでは、何を確認したかが分からないので、対象範囲と残る不確実さも必要です。最後は、依頼した全担当の結果がそろうまで待つのか、途中結果で判断するのかを指定します。待ち方が分かれば、足りない調査を完了扱いにせずに済みます。

分担の依頼票

• 目的と期待する動作
• 参照する変更と対象ファイル
• 各担当が調べる問い
• 編集してよいか
• 返す根拠と未確認事項
• 全結果を待つか
• 統合後の完了条件

Codexのサブエージェントと並列の運用

ここからは、二つの観点でレビューを頼む例を使います。分担した後も、担当範囲、待ち状態、結果の根拠を確認し、最後の判断は一つへまとめます。

二つの観点でレビューする例

最初の試行は、読み取りだけのレビューを二つの観点に分ける形が分かりやすいです。ログイン機能の変更について、担当Aは空欄や不正な入力の扱い、担当Bは既存テストと追加で必要なケースを調べます。二つとも同じ変更と期待する動作を見ますが、返す問いを分けます。次の依頼は説明用の例であり、この記事の作成中に実際のログイン機能を並列レビューした記録ではありません。

説明用の依頼例

指定したログイン機能の差分を、二つのサブエージェントで並列に読み取りレビューしてください。担当Aは空欄、不正形式、境界値とエラーの扱いを確認します。担当Bは既存テストの対象と、抜けているケースを確認します。ファイルは変更しません。各担当は、問題の候補、起きる条件、根拠のファイル、確認できた範囲、未確認事項を返してください。主担当は両方の結果を待ち、重複と矛盾を整理して、追加確認が必要な点をまとめてください。

• 担当A：入力とエラーの扱い
• 担当B：テストの範囲と抜け
• 主担当：重複整理、根拠確認、最終判断

確認日時点の公式資料では、ローカルCodexの分担は直接の依頼や、適用されるAGENTS.md・Skillの指示に基づいて行うと説明されています。記事の例も、並列作業を明示して頼む形です。表示や利用できる機能は、自分の環境の現行状態を確認してください。担当が始まったか分からないときは、結果の一覧だけでなく、どの問いを誰へ割り当てたかを確認すると、意図した分担になっているか見やすくなります。

結果が返ったら、同じ不正入力を二人が指摘していても、一つの候補へまとめます。担当Aが挙動の問題を見つけ、担当Bがそのケースのテスト不足を見つけたなら、関係を整理できますね。ただし、両方が同意したから事実だと決めるのではなく、コードと期待する動作を照合します。具体的な根拠が足りなければ追加確認を頼みます。最初の二観点を受け取ってから、必要な部分だけを掘り下げる方が、担当を増やす理由も明確になります。

同時編集で担当ファイルを分ける

調査から実装へ進む場合は、変更してよいファイルを各担当へ割り当てます。フロント側とサーバー側へ分けるだけでなく、共通の型、設定、依存関係、生成ファイルを誰が更新するかも決めます。公式資料も、同時の書き込みは競合や調整の負担に注意するよう説明しています。全員へ「必要なら何でも修正して」と任せると、担当を分けたつもりでも同じ箇所へ変更が集まることがあります。

架空のログイン機能なら、担当Aが画面の表示、担当Bがサーバーの検証を直し、共通のエラー型は主担当が更新する、といった所有を決めます。担当が自分の範囲外の変更を必要と感じた場合は、勝手に直すのではなく、必要な理由と対象を報告してもらいます。外の変更をすべて禁止するためではなく、誰が何を変えたかを追えるようにするためです。担当を変更するときは、既に作業中の相手へ同じ条件が伝わっているかも確認します。

さらに、編集の前後で未完了の変更を把握します。利用者が作った変更がある場合は、それを残したまま今回の範囲を直す必要があります。競合したからといって、広くファイルを戻して解消する判断は避けます。作業場所を分けた場合も、統合時に差分と共通の仕様を確認します。個別のテストが成功していても、組み合わせると型や入出力が合わない場合があります。編集の分担には、最後に結合した状態を確認する工程まで含めましょう。

実装の担当表に入れるもの

• 変更してよいファイル
• 共通ファイルの更新担当
• 範囲外の変更が必要な場合の報告先
• 残すべき既存の変更
• 統合後に確認する動作

担当数を増やす前に、編集する場所の所有を決めます。担当変更があった場合は、作業を引き継いだ範囲も記録します。

待ち状態と承認を確認する

結果がそろわないときは、どの担当が何を待っているかを確認します。調査を続けている、承認を待っている、対象を取得できない、既に完了しているなど、状態によって対応が違います。主担当が待っているだけでは、未完了の理由が見えにくいことがあります。担当ごとの対象と進捗、次に必要な入力を短く示してもらいましょう。「全員終わった」と判断する前に、依頼した問いごとの結果があるかを見ます。

公式資料では、サブエージェントは現在のサンドボックスや選択した権限モードを引き継ぐと説明されています。担当を増やしても、必要なアクセスが自動的に広がるわけではありません。承認が必要な操作は、利用環境によって確認が出たり、新しい承認を表示できない実行では失敗が主担当へ返ったりします。承認の表示がある場合は、どの担当が何をしようとしているかを確認してください。利用できる進捗表示や操作は、アプリ、CLI、IDEなどで異なります。

担当へ追加の依頼を出すときは、元の仕事の続きか、範囲の変更かを明示します。たとえば「指摘した不正入力の根拠だけを追加で確認し、修正はしない」と頼めば、必要な調査へ絞れます。担当を止める場合は、途中結果と未確認事項を残してもらうと再開しやすいです。仕事が終わったのか、処理を止めただけなのかも区別します。止まった担当の結果を空欄のまま成功扱いにせず、残る工程として最終報告に残しましょう。

主担当が確認する状態

• 実行中：何を調べているか
• 入力待ち：何が必要か
• 失敗：どの工程が未完了か
• 完了：どの結果を返したか

途中で止めた担当は、確認できた範囲と残作業を引き継ぎます。全体の報告にも、その担当の未確認項目を残します。

結果を統合して最後に検証する

主担当の仕事は、返された文章を並べるだけでなく、根拠と前提をそろえて結論を作ることです。指摘が重複していれば一つにまとめ、違う前提の結論はその違いを確認します。対象の変更、期待する動作、再現する条件がそろっているかを見てください。多数の担当が同じ意見を返しても、同じ誤った前提を読んでいる可能性は残ります。判断に使うのは票数より、確認できるコードと結果です。

修正を伴う場合は、最終の差分を開き、要求した変更だけになっているか確認します。担当別の結果には問題がなくても、組み合わせたコードで動作が変わることがあります。必要なテストや実際の入力ケースを、統合した状態で確認しましょう。レビューの詳しい進め方は、Codexのコードレビューとテストで確認漏れを防ぐ方法で整理しています。並列化したことを、最後の検証を省く理由にはしません。

最終報告には、採用した指摘、確認した根拠、実行した検証、残る未確認事項を入れます。テストを実行できなかった場合は、そのことを明記してもらいます。調査が終わったことと、変更が検証済みであることは違うからです。また、担当ごとの長い作業ログをすべて転記する必要はありません。利用者が判断するための要点へ絞り、詳しい根拠を必要な箇所で追える形にします。結果を一つに受け取れる状態までが、並列作業の完了です。

統合後の報告項目

• 採用した結論と根拠
• 重複や矛盾をどう整理したか
• 実際に確認した差分と検証結果
• 未完了、未確認の工程

Codexのサブエージェントと並列の要点

Codexのサブエージェントを使うときは、独立して調べられる仕事を分け、主担当が結果を統合する形から始めると理解しやすくなります。最初は入力の境界とテストの抜けなど、二つの読み取り観点を明示して頼みます。目的、対象の変更、担当範囲、編集の可否、返す根拠、待ち方をそろえてください。並列数を増やすことより、各担当が答える問いが重ならず、同じ前提で結果を比べられることが重要です。

編集へ進むなら、担当ファイルと共通部分の更新担当を決めます。別のスレッドができても、作業場所の隔離を自動的に保証するものではありません。どの場所と接続先を使うかを確認し、統合後の差分と動作を検証します。結果がそろわない場合は、承認待ちや取得失敗などの理由を見ます。未完了の担当を成功扱いにせず、残る調査や検証を報告へ残しましょう。利用量と統合の手間も含めて、分担する価値を判断します。

Xの運用報告は、困り方や試す工夫を知る材料です。ただし、独自システムの問題や別製品との比較を、そのまま現在のCodexの仕様や速度の保証にはできません。この記事も本人の性能測定ではなく、公式資料と取得できた投稿を踏まえた設計例です。全体の使い方へ戻りたい方は、Codexのできることと使い方の全体ガイドも確認してください。今日試すなら、変更を伴わない二つの調査を選び、根拠付きで結果を受け取る依頼から始めましょう。

最初の一歩

1. 独立した問いを二つ選ぶ
2. 対象と編集の可否をそろえる
3. 各担当の返す根拠を決める
4. 結果を待って重複と矛盾を確認する
5. 結論と未確認事項を一つにまとめる

小さく分担し、最後まで確認できる形を作ってから範囲を広げます。