本記事の情報の鮮度について

本記事の内容は2026年7月時点で公式ドキュメント(learn.chatgpt.com)とCodex CLI(0.144.5)の実機で確認したものです。サブエージェント周りは機能追加が続いている領域のため、設定項目の名称は公式ドキュメントで最新をご確認ください。「分担できる仕事だけ分担させる」という考え方自体は、仕様が変わっても変わりません。

Codexの並列には2種類ある

結論から書くと、Codexで「並列」と呼ばれるものは2種類あり、解決する問題が違います。1つは、1つの大きな仕事を複数の担当に分ける「サブエージェント」。もう1つは、そもそも別々の仕事を、別のセッションで同時に走らせる「並列セッション」です。検索で「Codex 並列」「Codex サブエージェント」にたどり着いた方が本当に知りたいのはどちらか、まずここを分けて考えると迷いません。

表は横にスクロールできます →

比較の観点サブエージェントで分担するセッションを分けて同時に走らせる
対象になる仕事1つの大きな仕事互いに関係のない複数の仕事
指示の出し方いま話しているセッションに「分担して」と頼む仕事の数だけセッションを立てる
結果の受け取り方親のセッションが全員の結果をまとめて1つの回答にするセッションごとに個別に受け取る
向いている場面調査・レビュー・複数観点のチェックなど、分けても成立する工程資料作成と調べもののように、そもそも別の用件
主な注意点トークン消費が増える。役割定義が曖昧だと機能しない同じフォルダを同時に触ると変更がぶつかる

「1本の仕事を速く終わらせたい」のならサブエージェント、「待ち時間を有効に使いたい」のなら並列セッションです。以降で順に見ていきます。

サブエージェント — 1つの仕事を複数の担当に分ける

サブエージェントは、Codexが専門の担当を複数立ち上げて並行で作業させ、全員の結果が出そろってから1つの回答にまとめる仕組みです。人にたとえるなら、リーダーが「あなたは調査、あなたは検証」と割り振り、上がってきた報告をまとめて1本の結論にする動き方に近いものです。公式ドキュメントでも、コードベースの探索や複数工程にまたがる作業のように、分けても成立する仕事で効果が出る機能として説明されています。

速さ以上に大きいのが、親のセッションが散らからないという効果です。調査の過程で読んだ大量の中間情報がすべて同じ会話に積み上がると、肝心の要件や判断基準が埋もれ、やりとりが長くなるほど精度が落ちていきます。公式ドキュメントはこれをコンテキストの汚染・劣化として説明し、中間作業を別スレッドに逃がすことを推奨しています。親は要件・判断・最終成果に集中し、調べものや検証は子に出す——これがサブエージェントの本質的な価値です。

この「中間作業で本題を埋めない」という発想は、渡す情報そのものの整理とセットで効きます。作業フォルダの作り方についてはCodexの使い方もあわせてご覧ください。

最初から用意されている3つの担当

自分で何も定義しなくても、Codexには標準で3つの担当が用意されています(2026年7月時点)。まずはこれをそのまま使えば十分です。

  • default — 汎用の担当。特に指定しないときに使われる
  • worker — 実装や修正など、手を動かす作業に寄せた担当
  • explorer — 読み込み中心の調査・探索に寄せた担当

頼み方 — 「並列で」と明示的に言う

重要な前提として、Codexは放っておいても勝手に分担してくれるわけではありません。デスクトップアプリ・CLI・IDE拡張では、こちらが分担を頼むか、AGENTS.mdスキルにその指示が書かれているときに分担が起きます(例外として、ChatGPTのWeb側の上位プランでは適した作業を自動で振り分ける挙動があります)。つまり、プロンプトで明示するのが基本です。

良い頼み方には共通点があります。どう分けるか・全員の完了を待つか・何をまとめて返すかの3点を書くことです。

サブエージェントへの頼み方の例
この提案書のドラフトを、サブエージェントを3つ立てて並列でチェックしてください。
1つ目は数値と固有名詞の裏取り、2つ目は論理の飛躍がないかの確認、
3つ目は先方の関心事と噛み合っているかの確認を担当してください。
3つとも終わるまで待ってから、指摘を重要度順にまとめて1つの一覧で返してください。

走っている担当の様子を見たいときは、CLIでは /agent で各スレッドを切り替えて中を確認できます。デスクトップアプリでは各担当のスレッドがそのまま表示され、IDE拡張では入力欄の上に進行中の担当が並びます。走らせたまま方針を変えたいときの追加指示の出し方はSteerとQueueの使い分けで解説しています。

役割を固定したいなら自前の担当を定義する

同じ役割を毎回使うなら、担当を設定ファイルとして定義しておけます。置き場所は2か所あり、自分専用なら ~/.codex/agents/、プロジェクトの全員で共有するならそのフォルダ内の .codex/agents/ に、それぞれTOML形式のファイルを置きます。当社でも、公開前の原稿から出してはいけない情報を洗い出す専任の担当をこの形で定義し、記事を書くたびに呼び出しています。

表は横にスクロールできます →

設定項目必須書く内容
name必須呼び出すときの名前。ファイル名ではなくこの値が正になる
description必須どんなときに使う担当かの説明。Codexが使いどころを判断する材料になる
developer_instructions必須その担当への指示書。何をもって合格とするかまで書く
model / model_reasoning_effort任意この担当だけ頭脳や思考の深さを変えたいとき。省略すると親の設定を引き継ぐ
sandbox_mode任意読むだけの read-only か、書き込みも許す workspace-write
mcp_servers / skills.config任意この担当にだけ持たせたい外部ツールやスキル
自前の担当を定義する例(事実確認の専任担当)
# ~/.codex/agents/fact-checker.toml
name = "fact-checker"
description = "原稿の事実確認の専任担当。数値・固有名詞・日付の裏取りに使う"
model_reasoning_effort = "high"
sandbox_mode = "read-only"
developer_instructions = '''
あなたは事実確認の専任担当です。
渡された原稿の主張を1つずつ確認し、裏付けが取れないものを一覧で返してください。
出典が確認できたものは出典を添えてください。
原稿の編集はしません(指摘のみ)。
'''

実務で効くのは sandbox_mode の使い分けです。チェックやレビューの担当は read-only にしておけば、指摘はするがファイルは書き換えないという安全な役割分担になります。権限の考え方の全体像はCodexのセキュリティ設定で解説しています。担当ごとに頭脳を変えたい場合の選び方はCodexのモデルをご覧ください。

ちなみに、この「役割別の担当を置く」という発想はClaude Codeにも同じ形であります。考え方の詳細はClaude Codeのサブエージェントで解説しており、両ツールとも役割定義の質がそのまま成果物の質になる点は共通です。

もう1つの並列 — 複数の仕事を同時に走らせる

こちらは単純で、別々の用件を、別々のセッションに任せるやり方です。1つのセッションに資料の下書きを、もう1つに調べものを頼み、自分は自分の仕事を進める。非エンジニアの日常業務では、実はこちらのほうが出番が多い並列です。入り口は主に3つあります。

  • ChatGPTデスクトップアプリ(Codex)で複数のスレッドを走らせる — 手元のPCで動かす基本形
  • クラウドで走らせる — 隔離された環境でタスクが動くため、手元のPCを占有しない。Web・GitHub・Slack・Linearから起動でき、結果は要約と差分を見て取り込む
  • CLIを複数立てる — ターミナルのタブを分けて走らせる。作業フォルダを分けるのが前提

時間のかかる仕事はクラウドに投げ、手元では別の作業を進める——という組み合わせが、待ち時間をいちばん減らせます。クラウドとスマホからの使い方はCodexのWeb版・スマホ活用で詳しく解説しています。走っている各セッションの状態を横目で把握する方法はペット機能の使いどころをご覧ください。

同じフォルダを同時に触らせない

並列セッションで最も起きやすい事故が、複数のセッションが同じフォルダの同じファイルを同時に書き換えて、片方の変更がもう片方に上書きされることです。対策はシンプルで、セッションごとに作業フォルダを分けること。プログラムの開発では、同じリポジトリの作業コピーを複数持てるワークツリー(git worktree)という仕組みがこの用途に使われます。非エンジニアの業務でも「並列にするなら作業フォルダも分ける」と覚えておけば十分です。

並列の落とし穴 — 増やすほど速くなるわけではない

並列は万能ではありません。研修の現場でも、最初に増やしすぎて手戻りするケースをよく見ます。あらかじめ知っておきたい注意点は4つです。

  1. 1利用量が増える — 担当ごとに自分でモデルとツールを動かすため、公式ドキュメントも「同じ仕事を1体でやるより多くのトークンを消費する」と明記しています。利用枠の確認方法はCodexの利用制限を参照
  2. 2分けられない仕事は分けない — 前の工程の結果が出ないと次が始まらない仕事を無理に分割すると、待ちが発生するだけで速くなりません
  3. 3役割定義が曖昧だと機能しない — 人の組織と同じで、「何をもって合格とするか」が書かれていない担当は、それらしいだけの報告を返してきます
  4. 4人間のレビューが最後のボトルネックになる — 5本同時に走らせても、確認するのは自分ひとりです。自分がレビューしきれる本数が実質的な上限になります

同時に開く担当スレッドの数そのものにも上限を設けられます。設定ファイルの agents の項目にある max_concurrent_threads_per_session で、親を除いた同時スレッド数の上限を指定できます(未設定ならCodexが既定値を選びます)。まずは既定のまま使い、増やしたくなってから触れば十分です。

非エンジニアの始め方 — 2本から

いきなり5本並列にしても、確認が追いつかず結局止まります。おすすめは2本からです。まず、時間のかかる調べものを1つCodexに任せ、自分はその間に別の作業を進める。この「任せている間に自分の仕事が進む」感覚がつかめたら、次に1つの仕事をサブエージェントに分担させる段階に進みます。分担の第一歩としては、チェック工程を分けるのが失敗しにくく、効果も見えやすいのでおすすめです。

たとえば「原稿を書く」という仕事なら、書くのは1体に任せ、事実確認・読み手目線のチェック・体裁確認を別の担当に並列でやらせる。制作と検品を分けるという発想です。担当が固定できたら、前述のTOMLファイルとして定義し、毎回呼び出せるようにします。ここまで来ると、Codexは「便利な道具」から「役割を持ったチーム」に変わります。他の応用機能との位置関係はCodexの応用機能まとめで俯瞰できます。

組織で並列運用を進めるには

サブエージェントも並列セッションも、仕組みそのものは設定を数行書けば動きます。難しいのは「どの業務を分担させるか」「各担当の合格基準をどう言語化するか」「並列で上がってきた成果を誰がどうレビューするか」という任せ方の設計のほうです。ここが決まらないまま本数だけ増やすと、レビュー待ちの成果物が積み上がるだけになります。

当社のCodex研修・導入伴走支援では、自社で40以上の業務をAIエージェントに任せてきた経験をもとに、貴社の実業務を題材に、分担できる工程の切り出しから担当の定義・レビューの型づくりまでを一体でご支援しています。

Codexを組織に定着させたい企業様へ。AI Orchestraの法人研修・導入支援をご覧ください。