Codexの別タスクを束ねる「上位管制」プラグインを作ってみた

最初は、一本のX投稿だった。

Codex が「別スレッド」を新規作成できる。

月読いおり氏の投稿には、Codexが自分で別のチャットを立ち上げ、そこへ仕事を振り、完了を待って親へ結果を戻せると書かれていた。投稿内に並んでいたのは、次の4ツールだ。

• codex_app__create_thread
• codex_app__send_message_to_thread
• codex_app__wait_threads
• codex_app__read_thread

これを見た瞬間、単なる「便利な並列実行」では終わらないと感じた。

すでに手元には、複数のCodexセッションを識別し、状態を記録し、管制判断を残すためのローカルなcontrol planeがあった。そこへ、Codex自身が持つ純正の別タスク作成機能を接続できるならどうなるか。

純正ツールを「手足」にして、既存の状態管理と管制機能を「頭脳と記憶」にできる。

しかも、画面に見える各Codexタスクの内部では、従来どおりCoding AgentsやSubagentを動かせる。つまり、一つのエージェントが複数の子エージェントを使うだけではない。複数の「エージェントチーム」を、さらに上位の管制役が束ねる構造を作れる。

この着想から、旧 codex-session-control-plane を全面的に作り直した。名称、ディレクトリ、plugin IDも整理し、現在は Codex Thread Orchestration としてGitHubで公開している。

GitHub：mlabo-org/codex-thread-orchestration

これは、Codexの画面に存在する複数タスクを統括する「上位管制」プラグインである。

なお、CodexのUIでは現在「タスク」という表現が使われる一方、ツール名では thread が使われている。本記事では、画面に独立して残るトップレベルの作業単位を「画面タスク」、ツールや一般概念を指す場合は「Thread」と表記する。

>>>Amazonのお得な最新の情報はここ

サーバー管理者歴17年の筆者が選んだレンタルサーバー会社はここ

Codexの画面に別タスクが生えると知った瞬間

X投稿でまず驚いたのは、Codexが別の処理を裏側で走らせられることではない。Codexの画面に、新しいチャットが実在する形で作られることだった。

このスレッドで最初に確かめたかったのも、まさにそこだ。

codexの画面に関連した新しいスレッドとか出来上がるのが目で見えるわけだよな。

答えは、イエスだった。

create_thread で作られたタスクには個別のIDがあり、Codexの一覧から直接開ける。親タスクはバックグラウンドでメッセージを送り、進捗を待ち、結果を読み取れる。それでも子タスクは親の一時的な内部処理ではなく、ユーザーが後から自分で開いて会話を続けられる独立した作業場所として残る。

これは体感が大きく違う。

従来のマルチエージェントでは、ユーザーが見るのは主に「親が複数の担当者へ仕事を振り、その要約を受け取った結果」だった。今回の経路では、担当者ごとの作業部屋そのものがCodexの画面に増える。

途中経過を見たいときは開ける。人間の判断が必要なら、そのタスクへ直接入れる。別の成果へ育ったなら、そのまま独立したチャットとして継続できる。

投稿では、この仕組みを「Thread orchestration」と呼んでいた。ただし、今回確認した公開マニュアルには、codex_app__create_thread などのホストツール名は掲載されていなかった。投稿が言及していたOpenAI関係者の元ポストも、今回のintakeにはURLが含まれておらず、独立確認はできていない。

したがって、本記事ではこれらを固定された公開APIとは呼ばない。現在のCodexホストがエージェントへ露出している純正タスク管理ツールとして扱う。実行前に利用可能なツール名を毎回確認する設計にした。

それでも、実際に別タスクを作成・待機・読取できた事実は変わらない。

そして、ここで次の発想が出てきた。

すでに状態管理と管制機能はあるわけじゃん？ これうまく融合したらすごくね？

本当に、その融合が核心だった。

Subagentと画面に見える別タスクは何が違うのか

Thread Orchestrationを理解するには、まずSubagentとの違いを整理する必要がある。

Codexの公式Subagentドキュメントでは、Subagentは主タスクから境界のある仕事を委譲され、並列に作業し、その結果を主スレッドへ返す仕組みとして説明されている。調査、テスト、ログ解析、レビューなどを主タスクから切り離し、親のコンテキストをノイズで埋めないために非常に有効だ。

一方、今回の上位管制が扱う画面タスクは、それ自体が独立した成果単位である。

ただし、「画面に見えるかどうか」だけで両者を分けるのは正確ではない。対応するCodexクライアントではSubagent threadも開いて確認できるからだ。

本当の違いは、誰がその作業の最終責任を持ち、どの単位で履歴・環境・受理判断を管理するかにある。

Subagentは、同じ会議室の中で担当者を分けるイメージに近い。画面タスクの上位管制は、複数のプロジェクトルームを統括本部が管理するイメージに近い。それぞれの部屋にリーダーがいて、さらに内部メンバーへ仕事を分けてもよい。

この違いは、長期作業になるほど効いてくる。

公式のProjects and chatsドキュメントも、一つのチャットへプロジェクト全体を詰め込むのではなく、一つの明確な成果ごとに別チャットを使うことを勧めている。会話が肥大化すれば、重要な要件や判断が大量のログへ埋もれる。成果ごとにタスクを分ければ、それぞれのコンテキストを細く保ちながら、プロジェクト単位では関連付けて管理できる。

Thread Orchestrationは、この運用を人間が毎回手で行うのではなく、管制役がタスク作成、指示、待機、継続、分岐、整理まで扱えるようにする。

つまり、Subagentの代用品ではない。Subagentを含む複数の作業組織を、一段上から管理する層である。

純正Thread Toolsと既存管制をどう融合したか

設計を始めた直後は、三つの経路が混線していた。

• Codex CLIを複数プロセス起動する
• codex app-server をクライアントから操作する
• Codexホストが露出する codex_app__* Thread Toolsを呼ぶ

どれも「複数のCodexセッションを動かす」ように見える。しかし、責任範囲はまったく異なる。

Codex App Serverの公式説明では、App Serverは認証、会話履歴、承認、ストリーミングイベントまで扱う独自クライアント向けのJSON-RPCインターフェースとされている。thread/start、turn/start、各種通知を使えば、Codexを組み込んだリッチクライアントを一から作れる。

App Serverが弱いわけではない。むしろ、自分の製品へCodexを深く埋め込むなら本命になる。

しかし今回欲しかったのは、新しいCodexクライアントではなかった。すでにCodexアプリが持っているタスク、worktree、画面一覧、引継ぎ機能を、そのまま使いたかった。そこへ別のプロセス所有層を重ねると、どちらが実在タスクの正本なのか分かりにくくなる。

そこでv0.2.0では、旧版にあったプラグイン所有の app-server-client.mjs を削除し、native-thread-tools.mjs へ置き換えた。

現在の責務分担は明快だ。

• 純正 codex_app__* ツールが、実在する画面タスクの作成・送信・待機・分岐・引継ぎ・整理を行う
• アクティブな管制役が、どのツールをいつ呼ぶか判断し、複数タスクの成果を統合する
• Control Plane MCPが、正確な呼び出し意図、タスクID、観測結果、メッセージ出自、失敗、受理判断を台帳へ記録する
• ダッシュボードが、台帳を人間へ見せ、次の操作意図を準備する

MCPサーバーは、Codexホストのふりをしてタスクを作らない。ダッシュボードも、背後で勝手に純正ツールを実行しない。実行主体は最後までCodex純正であり、プラグインは制御状態を所有する。

純正と自作のどちらが強いか、という二者択一ではない。

純正の実行能力を、自作の管制能力で包む。

この構造なら、Codex側のタスク機能が進化するほど、上位管制もその恩恵を受けられる。

Codex Thread Orchestrationプラグインの全体設計

完成した構造は、次のようになる。

flowchart TB
  U["人間"] --> C["上位管制タスク"]
  C --> N["Native codex_app Thread Tools"]
  N --> W1["画面タスク A"]
  N --> W2["画面タスク B"]
  N --> W3["画面タスク C"]
  W1 --> A1["Coding Agents / Subagents"]
  W2 --> A2["Coding Agents / Subagents"]
  W3 --> A3["Coding Agents / Subagents"]
  C <--> L["Control Plane MCP / atomic ledger"]
  L --> D["ローカルダッシュボード"]

名前と正本の境界を先に揃えた

開発途中では、旧ディレクトリ名の codex-session-control-plane と、完成後の表示名が混在していた。ローカルだけなら意味を追えるが、GitHubから初見で取得する読者には余計な混乱になる。

現在の公開上の名称は、次のように整理した。

skill名とMCP名は内部インターフェースとして役割を表す。一方、読者がrepo、ディレクトリ、manifestを見たときの製品識別子は codex-thread-orchestration に統一した。

ここで重要なのが、GitHubの正本とインストール済みcacheを混同しないことだ。

公開・修正・レビューの基準はGitHubへpushするsource repoである。~/.codex/plugins/cache/ は、公式インストール経路が正本から生成するruntime copyにすぎない。正本を直しただけでは日常利用中のcacheは勝手に変わらず、明示的なinstallまたはrefreshを行ったときだけ反映される。

現行13ツールを一つの管理面へまとめる

X投稿で見つかったのは4ツールだったが、このセッションで確認できた現行のタスク管理系は13ツールあった。v0.2.0は、それらを一通り扱う。

これらは、利用できることを前提にハードコードして終わりではない。ライブ管制の前にpreflightを行い、現在露出しているツール、必須ツールの不足、管理系ツールの不足を分けて確認する。

コアとなる作成・一覧・待機・読取・送信が欠けていれば、存在しないツールを推測で呼ばない。その場合は不足名を報告し、目的を満たせるなら同一タスク内の公式Subagentへ戻す。

意図を準備してから純正ツールを呼ぶ

ライブ実行は、MCPが直接タスクを操作するのではなく、次の順序で進む。

1. 管制対象全体のrunを台帳へ作る
2. 各ワーカーの役割、指示、作業場所、受け入れ条件をtask contractとして登録する
3. MCPが「次に呼ぶ純正ツール名と引数」を意図として返す
4. アクティブな管制役が、その純正ツールを実行する
5. 結果のタスクID、状態、カーソル、成果物を台帳へ記録する
6. 完了したワーカーを管制役が accept、continue、fail のいずれかで判断する

重要なのは、ワーカーが「終わりました」と言っただけでは、全体runを完了にしないことだ。最終受理は管制役に残す。これは人間のチームでも同じで、担当者の作業完了とプロジェクトとしての受理は別の判断である。

会話の記憶ではなく、atomic ledgerへ状態を残す

台帳の既定位置は次のとおりだ。

~/.codex/session-control-plane/ledger.json

ファイルは 0600 で作成し、更新を直列化したうえで、一時ファイルへの書き込み、sync、atomic renameを使って保存する。

ここには、タスクの役割だけでなく、Thread ID、host ID、準備した操作、実行結果、メッセージの送信元、観測状態、管制判断が残る。一つのチャットが長くなったり、要約されたりしても、管制対象の対応関係を会話の記憶だけに依存しない。

ローカルダッシュボードは、この台帳を観測するための画面だ。ダッシュボードが勝手にCodexを操作するのではなく、人間が現在のrun、各タスクの状態、次の意図を把握するためのcontrol surfaceとして機能する。

dry-runを既定にする

上位管制は強力だが、タスクを増やせることと、勝手に増やしてよいことは別問題である。

そのためプラグインは、通常 dry-run を既定にした。画面タスクの作成、メッセージ送信、分岐、引継ぎ、名前やアーカイブ状態の変更は、現在のユーザーがその種類のライブ操作を明示した場合だけ実行する。

Control Planeは権限を増やす仕組みではない。削除、公開、認証、課金など、元の依頼にない外部作用を正当化することもない。

上位管制だからこそ、強さと同時に「何を実行しないか」を台帳と実装で固定する必要がある。

読者のCodexが初見でインストールできるようにした

GitHubで公開するなら、人間向けREADMEだけでは足りない。

最近のCodex利用者なら、興味のあるrepoを見つけたとき、手順を一行ずつ自分で実行するより、URLをCodexへ渡して「このプラグインを自分の環境へ入れて」と頼むはずだ。そこで、取得しに来た先方のCodexを第一読者として情報構成を組み直した。

repo直下の AGENTS.md は、明示的なインストール依頼だけで発火する極小ルーターにした。通常の開発、閲覧、記事作成、プラグイン利用ではinstallerを起動せず、日常運用へ余計な制約を加えない。

インストール依頼があった場合だけ、docs/INSTALL_FOR_CODEX.md の固定手順へ進む。

1. 読者自身のホームディレクトリをOSから解決する
2. 正本を <user-home>/plugins/codex-thread-orchestration へ取得する
3. npm run check でsource contractとテストを確認する
4. npm run plugin:install:check で変更予定をread-only表示する
5. 競合がなければ npm run plugin:install を実行する
6. 既存marketplaceの無関係なエントリを保全する
7. 公式 codex plugin add を呼び、導入バージョンを確認する
8. Codex再起動後、新しいタスクでdry-run preflightを行う

人間向けの日英READMEには、Codexへそのまま渡せる依頼文も用意した。installerはcacheを直接書き換えない。source位置、marketplace名、予定される変更、plugin selectorをJSONで返し、同名プラグインが別sourceを指していれば勝手に上書きせず停止する。

公開するとは、ソースを置くだけではない。先方のCodexが初見で迷わず、安全に同じ状態を再現できるところまでが配布設計である。

各タスクの中でCoding Agentsを多重稼働させる

今回の構造で最も面白い部分は、画面タスクとCoding Agentsを競合させず、階層として組み合わせられる点だ。

上位管制が扱うのは、画面に並ぶトップレベルタスクである。各タスクには、独立した役割、成果、作業範囲、受け入れ条件を与える。

その各タスクの中では、従来どおりCoding Agentsを動かせる。

たとえば、一つのプロジェクトを次の三つへ分ける。

• 画面タスクA：バックエンド実装を担当
• 画面タスクB：フロントエンド実装を担当
• 画面タスクC：ドキュメントと移行手順を担当

上位管制は、この3タスクのID、worktree、依存関係、進捗、結果を管理する。一方、バックエンド担当のタスクAは、内部でさらに調査、実装、テストといったCoding Agentsの委譲を行える。

ここで、内部Subagentを上位管制の兄弟タスクとして数えないことが重要だ。

上位管制
├── 画面タスクA
│   ├── 内部Subagent A-1
│   └── 内部Subagent A-2
├── 画面タスクB
│   ├── 内部Subagent B-1
│   └── 内部Subagent B-2
└── 画面タスクC
    └── 内部Subagent C-1

トップレベルの画面タスクは上位管制が所有する。内部Subagentは、その画面タスクの責任下に置く。内部担当者が別のトップレベルタスクを勝手に探し、直接操る設計にはしない。

タスクAからタスクBへ情報を渡す必要がある場合も、上位管制が送信元Aを記録したうえでBへメッセージを中継する。こうすることで、「誰が、どの成果を根拠に、どのタスクへ何を伝えたか」が台帳へ残る。

Gitプロジェクトでは、画面タスクごとにworktreeを分ければ、同時編集の衝突も抑えられる。それぞれのCoding Agentsは、自分のworktreeを作業場所として完結する。管制役は、各ワーカーが返した成果を統合し、受理する。

これは単なるエージェントの大量起動ではない。

責任境界を持つチームを複数作り、そのチーム群を管理するmanager of managers構造である。

Lunaで実タスクを作って動作確認した

設計と自動テストだけでは、「本当にCodexの画面へ別タスクが生えるのか」は証明できない。

v0.2.0では、まずソース契約と状態機械を自動検証した。公開直前の受入結果は次のとおりだ。

• npm run check：23テスト成功
• Plugin validator：成功
• Codex向けread-only install preflight：ready
• preflight前後のpersonal marketplace SHA-256：一致
• 公開したGitHub main と検証済みローカルHEAD：完全一致

自動テストでは、正規化した疑似ツール結果を使う。これにより、タスクを大量作成せず、意図準備、ID紐付け、状態遷移、台帳更新、管理操作を再現できる。

installerのテストも、初回marketplace作成、既存エントリ保全、同一導入の冪等性、異なるsourceとの競合停止、Node要件、atomic persistenceまで模擬環境で確認した。read-only preflightでは実際のmarketplaceが一切変化していないこともハッシュで確認している。

そのうえで、ユーザーの明示許可を得て、実在する検証タスクを一本だけ作った。

作成されたタスクIDは、次のものだった。

019fc433-c11f-7643-87f4-976cf20601ef

親タスクから完了を待ち、結果を読み取ると、子タスクは次の2行を返した。

TEST-RUN
THREAD_OK

子タスクによるファイル変更や追加作業はなかった。read_thread で確認した最終ターンは約1.2秒で完了している。

これで、少なくとも現在のローカルCodex環境では、次の経路を実際に確認できた。

1. 親タスクがモデルと指示を指定する
2. 画面に見える別タスクを一本作る
3. 子タスクが独立して指示を実行する
4. 親タスクが完了を待つ
5. 親タスクが子の最終結果を読む
6. ユーザーは子タスクをCodex画面から直接確認できる

自動テストとライブカナリアを分けたのは、目的が違うからだ。

自動テストは、プラグイン自身の状態管理と契約を確かめる。ライブカナリアは、現在のCodexホストが本物の画面タスクを作れることを確かめる。後者を通常のテストスイートへ混ぜれば、検証のたびにユーザー所有タスクが増えてしまう。だから実カナリアは、明示されたときだけ、範囲を限定して行う。

公開用のsourceは 4e45a75 としてコミットし、GitHubの main へpushした。リポジトリはpublic、ライセンスはMIT、READMEは日本語・英語の両方に対応している。

上位管制はAgent Operating Systemへ進化するか

ここまで作ると、「これは上位管制の究極系ではないか」と言いたくなる。

方向としては、かなり近いと思う。

従来のマルチエージェントは、一つの親が複数の子へ仕事を分ける構造だった。今回のプラグインは、ユーザーが所有する独立タスク群を管理し、その各タスクがさらに内部エージェントを持てる。状態は会話の外にある耐久台帳へ残り、人間はCodexの画面から任意のタスクへ介入できる。

これは、チャットの中だけで完結するエージェント群から、画面、履歴、作業環境、状態、権限、受理判断を持つ実行基盤への変化である。

ただし、現時点の制約も明示しておきたい。

1. Thread Toolsは公開された固定APIとして確認できない

2026年8月3日時点のこのセッションでは13ツールを確認できたが、同じツール名は公開マニュアルに見つからなかった。Codexのバージョンや実行面によって、露出するツールが変わる可能性がある。

そのため、プラグインは毎回preflightする。将来ツールが増減しても、存在しない機能を推測で実行しない。

2. 現行ツール群には直接停止がない

現在確認できるタスク管理系には、実行中タスクを直接停止する専用ツールがない。プラグインは cancel_requested を台帳へ記録できるが、それ自体を実行停止とは扱わない。

実行中の画面タスクはユーザーがCodex画面で停止し、その後に管制役が終了状態を観測する。ここは、純正側に停止能力が追加されるか、別の正式経路が示されるまで、人間の介入点として残る。

3. 上位管制は権限を拡張しない

複数タスクを作れるからといって、公開、削除、認証、課金を自動で行ってよいわけではない。各タスクへ分配できるのは、元の依頼で許可された作業だけである。

むしろタスク数が増えるほど、管制役は権限、期限、予算、停止条件を明示的に持つ必要がある。

4. GitHub公開後もinstallとruntime反映は別工程である

ソースをGitHubへ公開したことと、各読者のCodexへプラグインが有効化されたことは同じではない。

公開repoは、レビュー、修正、配布の正本だ。読者のCodexはそこからsourceを取得し、自分のpersonal marketplaceへ登録し、公式CLIでinstallする。Codexのmanifest、skill、MCP surfaceを確実に読み込むには、install後にCodexを再起動し、新しいタスクを開始する必要がある。

この境界を省けば、「GitHubは更新されたのに手元の挙動が変わらない」「cacheを直したのに公開repoへ反映されていない」という混乱が起きる。だから正本、marketplace、cache、runtime uptakeを別工程として明示した。

では、何が加われば「Agent Operating System」と呼べるのか。

次の段階では、少なくとも以下を一つの制御ループへ統合したい。

• タスク間依存を表すDAG
• 作業内容に応じたモデル・推論深度・worktreeの自動配車
• トークン、費用、時間、最大往復数の予算制御
• 完了、停滞、エラー、ユーザー割り込みを扱う停止条件
• 再実行時に二重作成を防ぐ冪等性と障害復旧
• 人間が承認すべきポイントの明示
• タスク群全体を追える観測画面
• 各ワーカー成果を管制役が受理する統合ルール

ここまで揃えば、人間は「エージェントAを起動して、次にBへこの文章を貼って」と操作するのではなくなる。

人間が与えるのは、成果、制約、予算、判断基準である。上位管制は必要な画面タスクを作り、各タスクは内部チームを編成し、状態を台帳へ残しながら進む。人間は、重要な判断点だけに入る。

今回作ったものは、その完成形ではない。

しかし、重要な土台はできた。

• 実在するCodexタスクを操作する純正の手足
• タスクIDと状態を失わない耐久台帳
• 各ワーカー内部でCoding Agentsを動かす二層構造
• 人間が画面から直接介入できる所有モデル
• 最終受理をワーカー任せにしない管制境界
• 初見のCodexでも再現できる公開インストール経路

独自のエージェント基盤をCodexと競わせるのではない。Codexそのものを実行ノードとして束ねる。

それが、公開した codex-thread-orchestration v0.2.0で実装したThread Orchestrationである。

そしておそらく、これは単なる便利プラグインの先にある。

Codex上にAgent Operating Systemを作るための、最初のcontrol planeだ。

参照資料

• GitHub：Codex Thread Orchestration
• 月読いおり氏のX投稿：Codexが別スレッドを新規作成できる
• Codex公式：Subagents
• Codex公式：Projects and chats
• Codex公式：App Server

※ codex_app__* のツール一覧と実カナリア結果は、2026年8月3日のローカルCodexセッションで確認したものです。ツールの提供状況はCodexのバージョンや実行環境によって変わる可能性があります。