CodexのSubAgentと「別スレッド委譲」は同じ？ Thread orchestrationの使い分け
結論からいうと、かなり同じです。どちらも、親のCodexが仕事を分け、別の作業単位に任せ、結果を受け取ります。違うのは能力ではなく、仕事を分ける単位と管理の仕方です。
いまSolに「調査担当を立ち上げて」「実装はworkerに任せて」と頼んでいるなら、すでにCodexの委譲機能を使えています。今回見つけたThread orchestrationは、その委譲を別のCodexタスク／チャット単位で扱う経路です。
きっかけは、GPT-5.6 LunaとSubAgentについてのポストにあった「かわりにThread orchestrationを使って」という趣旨の言葉でした。製品メニューや公式ドキュメントで、その名前を見た記憶はありませんでした。
そこで、いま使っているCodexのツール一覧を調べると、別スレッドを作って仕事を渡すための4つのツールが見えてきました。
codex_app__create_threadcodex_app__send_message_to_threadcodex_app__wait_threadscodex_app__read_thread
Thread orchestrationは、SubAgentより上位の機能ではない。仕事を「別チャット単位」で委譲するための入口だ。
まず答え：目的はほぼ同じ
「SubAgentをうまく使いたい」という目的なら、Solにサブエージェントを立ち上げてもらう方法で十分です。
Solを親役にして、調査、実装、レビューを分ける。各担当から結果を受け取り、Solが最後に判断してまとめる。この流れは、Thread orchestrationの中心にある「親が仕事を委譲し、結果を回収する」という考え方と同じです。
Solに頼むSubAgentでは何が起きている？
親スレッドでSolに次のように頼んだとします。
Sol、次の仕事を分担して。 explorer：関連ファイルと公式情報を読む。変更はしない。 worker：要件が固まったら、指定したファイルだけ実装する。 最後に、根拠・変更点・未確認事項をまとめて。
この場合、Solが親としてサブエージェントを起動し、担当ごとの結果を回収します。サブエージェント側にも作業用のagent threadができるため、進捗を見たり、その結果を確認したりできます。
つまり「同じスレッドの中にAIが増える」というより、親タスクから管理される子の作業スレッドが動くと考えるほうが正確です。
Thread orchestrationは「別タスク／別チャット」を作る
codex_app__create_threadを使う経路では、親タスクとは別のCodexタスク、つまり別チャットを新規作成します。そこへモデル、目的、対象、禁止事項を渡して、独立した作業として走らせます。
別チャットなので、履歴も別です。親の会話を全部知っている前提にせず、必要なファイル、URL、背景、出力形式を最初の依頼に書く必要があります。終わった結果も、親が自動的に全部読むのではなく、待機してから読みに行きます。
ただし、SubAgentにもagent threadがあるため、画面上は似て見えます。違いは「別スレッドがあるかどうか」だけではなく、そのスレッドが親タスクの内部で管理されるのか、別のCodexタスクとして立ち上がるのかです。
| SubAgent | Thread orchestration | |
|---|---|---|
| 目的 | 親の仕事を分担する | 別タスクへ仕事を委譲する |
| 単位 | 親タスクにぶら下がる作業スレッド | 独立したCodexタスク／チャット |
| 親との関係 | 親が担当を振り、結果をまとめる | 親が作成・連絡・待機・読取を管理する |
| 文脈 | 親の要件を前提に分担しやすい | 必要な前提を依頼文で渡す |
| 向いている場面 | 調査・実装・レビューの分業 | 長めの独立作業、別履歴で残す仕事 |
この表の「場所」は、画面やクライアントによって見え方が変わります。ここでの違いは、現在のCodex環境で確認できるツールの役割と、公式マニュアルにある親タスク・agent threadの整理をもとにしたものです。
4つのツールは「始める・頼む・待つ・読む」
Thread orchestrationは、ひとつの魔法のボタンではありません。別スレッドを作り、指示を送り、完了を待ち、結果を読む。仕事の順番に沿って4つに分かれています。
| ツール | 役割 | 覚え方 |
|---|---|---|
create_thread | 別のCodexタスク／スレッドを作る | 始める |
send_message_to_thread | そのスレッドへ依頼や追加指示を送る | 頼む |
wait_threads | 完了または対応が必要になるまで待つ | 待つ |
read_thread | 進捗、要約、結果を読む | 読む |
create_threadは非同期で動きます。作成を依頼した直後に、すぐ読めるとは限りません。準備中の状態と、実際に作業できるスレッドを区別します。
wait_threadsは、この環境のツール定義では最大8件のスレッドを対象に、先に完了したものや対応が必要になったものを待てます。全員の回答を一度に待つというより、進んだ仕事から拾うための道具です。
どちらを使えばいい？
日常のCodex作業なら、まずSubAgentで十分です。Solに親役を任せ、独立した部分だけを担当者へ渡します。
- Solに調査・実装・レビューを分担させる
- explorerにファイルや公式情報を読ませる
- workerに範囲を限定した変更を任せる
- 最後にSolが結果を比較して判断する
次のような場合は、別タスクとしてThread orchestrationを使う意味があります。
- サイドバーに別チャットとして残したい
- 後でその作業だけ再開したい
- 親の会話と履歴を完全に分けたい
- 別のモデル、プロジェクト、worktreeで動かしたい
- 複数の独立した調査を長めに並行させたい
「仕事を分担して、Solがまとめてほしい」ならSubAgent。「別チャットを生やして、独立した仕事として残したい」ならThread orchestration。この一行で使い分けられます。
SolにSubAgentを頼む依頼文
SubAgentを使いたいだけなら、次のように頼めます。
Sol、親担当として次の仕事を分担して。 explorer：Codexの公式情報と現在のツール定義を読む。変更はしない。 worker：記事の構成案だけ作る。ファイル変更はしない。 reviewer：事実の断定しすぎと、初心者に伝わらない箇所を確認する。 各担当は、結論・根拠・未確認事項を短く返して。 最後にSolが、採用する内容を1本の記事構成へまとめて。
役割、対象、禁止事項、完了条件を小さく書くのがコツです。「いい感じに調べて」だけでは、担当の範囲が広がり、結果の比較もしづらくなります。
別スレッドを作る依頼文
別チャットとして残したい場合は、Thread orchestrationを明示します。
別スレッドを新規作成して、gpt-5.6-lunaで調査を委譲して。 目的：CodexのSubAgentとThread orchestrationの違いを整理する 対象：create_thread、send_message_to_thread、wait_threads、read_thread 出力：初心者向けの結論、ツール別の説明、使い分け、依頼文 禁止：ファイル変更、公開、削除、外部サービスへの送信 完了条件：根拠と未確認事項を分けて、親スレッドで読める形にする
モデル名だけを指定して終わりにしないことが大切です。別スレッドは別の履歴なので、目的、材料、出力、禁止事項、完了条件を一緒に渡します。
使う前に知っておきたい注意点
- 文脈は分けて考える：別タスクには必要なファイル、URL、前提を依頼文に書く。
- 権限とモデルは別：Lunaを指定しても、変更・公開・削除を許可したことにはならない。
- 同じファイルを同時に触らせない：並列化は、まず調査・レビューなど読み取り中心から始める。
- 結果を鵜呑みにしない：親タスクで根拠、未確認、次の一手を確認する。
- 機能の見え方は変わる：Codexのクライアント、アカウント、ワークスペースによって表示や利用可否が違う。
とくに大切なのは、委譲したあとも親が判断役であることです。子の作業を増やすことが目的ではありません。親の判断を止めず、独立した作業を先に進めるために使います。
まとめ：あなたが今やっていることと、核は同じ
SolにSubAgentを立ち上げてもらう方法と、別チャットを作るThread orchestrationは、目的の核が同じです。親が仕事を分け、担当が作業し、親が結果を受け取ります。
違いは、SubAgentが親タスクの分業として動くのか、別タスク／別チャットとして独立して動くのか。まずはSubAgentで調査・実装・レビューを分担し、長く残したい仕事や完全に分けたい仕事だけ、別スレッドへ出すのがわかりやすい使い方です。
create_threadで始め、send_message_to_threadで頼み、wait_threadsで待ち、read_threadで読む。チャットが、ぴょこんと生えてくる。その体験は面白いですが、SubAgentとの違いを知ると、必要なときに迷わず使い分けられます。
なお、「Thread orchestration」が正式な製品メニュー名として定義されているかは、この記事では断定しません。ここでは、別スレッドを作成・連絡・待機・読取する一連の流れを説明するための呼び名として使っています。
