この記事の根拠

根拠は、ChatGPTデスクトップアプリ本体に含まれるタスク操作ツールの定義文と表示文言(当社が実機のアプリファイルから確認)、Codex公式「Long-running work」ガイドClaude Code公式「Message your other Claude Code sessions」Claude Code公式デスクトップアプリガイド、当社の運用で観察した挙動です。Codex側にはこの機能を説明する公式ドキュメントが当社の確認した範囲では見当たらず、アプリ本体の定義を一次情報にしています。

結論:別のタスクにいるCodexが、あなたの代わりに送っている

結論から書きます。「別のタスクから送信」は、別のタスクで動いているCodexが、そのタスクに宛てて送った指示です。人間が入力したメッセージと同じ吹き出しで届き、Codexはそれを新しい指示として扱います。送るかどうかを決めているのは、送信元のタスクにいるCodex自身です。

そして、「Claude Codeにはこの機能がない」というのは誤解です。Claude Codeにはセッション間メッセージ(cross-session messaging)という同じ役割の機能が、バージョン2.1.224(2026年8月7日公開)から入っています。違うのは有無ではなく、届き方と、権限や受け取りの制御が明文化されているかどうかです。

画面で起きていること — 当社の実例

当社で実際に起きた場面です。自社サービスの通知メールを設計しているタスクAと、その実装を進めているタスクBを並行して走らせていました。宮地がタスクAに「差出人が送信専用アドレスだと、そこに返信してしまう人もいる」という追加要件を伝えたところ、タスクBに次のメッセージが届きました

ChatGPTデスクトップアプリ(Codex)のタスク画面。「ChatGPTが別のタスクから送信」のラベルの下に、「ユーザーから追加要件です」で始まるメッセージが表示されている
タスクBに届いたメッセージ(当社環境)。ラベルの下の吹き出しは、タスクAのCodexが書いた文章

吹き出しの文章は「ユーザーから追加要件です:「…」」と、宮地の言葉を引用しつつ、タスクAのCodexが書き直したものです。宮地はタスクBには何も送っていません。タスクAのCodexが「この要件は実装側のタスクBに関わる」と判断し、自分で転送したことになります。

ラベルの「ChatGPTが別のタスクから送信」は、アプリ本体の定義では「別のタスクから委任された、ユーザーメッセージ風のプロンプトの上に出す表示」と説明されています。このラベルはクリックでき、送信元のタスクへ移動します。誰が送ったのか分からないときは、まずここを押してください。

仕組み — アプリ本体の定義から分かる4つの事実

この機能は、ChatGPTデスクトップアプリがCodexに渡している「タスク操作ツール」の一部です。アプリ本体の定義を追うと、画面からは見えない事実が4つあります。

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

事実内容
①「タスク」=「スレッド」Codexへの指示文は「task・thread・chat・conversation を同義として扱え。ツール名は thread、画面では task を使う」と定めている。ラベルの「タスク」とツール名の「スレッド」は同じもの
②タスク操作ツールは11個作成・分岐・一覧・アーカイブ一覧・読み取り・完了待ち・メッセージ送信・引き継ぎ・ピン留め・アーカイブ・名前変更。Codexは自分のタスクの外にある、サイドバーの他のタスクを扱える
③送信ツールの説明文「既存のスレッドかチャットにフォローアップのプロンプトを送る。プロンプトは宛先タスクにユーザーから見えるメッセージとして表示される。明確で、まとまった、人が読める文章で書け」。宛先と本文のほか、モデルと推論の深さも指定できる
④届く形には送信元IDが付く本文は「codex_delegation」という包みで囲まれ、送信元のタスクIDが添えられて宛先に届く。画面ではこの包みがラベルに変換される。受け取る側のCodexは、それが別タスクからの委任だと分かる

この機能の呼び名 — 公式名はなく、コードでは「委任(delegation)」

Claude Code側の「セッション間メッセージ」に当たる公式の名前は、Codex側にはありません。OpenAIの公開ドキュメント・変更履歴・公式Xアカウントのいずれにも、この機能を指す名称は当社の確認した範囲で見当たりませんでした。手がかりはアプリとCodex CLIのソースコードにあり、そこでは一貫して「委任(delegation)」と呼ばれています

  • タスク委任(task delegation)。アプリ本体のエラー文は「そのサーバーがこのホストで使えない場合、タスク委任は利用できません」。Codex CLIのソースコード(openai/codex)は、作成・送信・分岐の3ツールを DELEGATION_TOOLS と定義し、送る文章を「委任されたプロンプト」と呼ぶ。届く包みの名前も codex_delegation
  • Thread Coordination(スレッドの連携)。Codexへの指示文で、タスク操作ツールの使い方を定めた節の見出し。ツール群の機能キーは thread_tools
  • cross-thread messaging(スレッド間メッセージ)。公式の名前ではなく、GitHubの issue やX投稿で利用者が使っている呼び方。「別のタスクから送信」というラベル文言で検索する人が多いのはこのため

本記事では、機能全体をタスク委任(task delegation)、届いたメッセージをタスク間メッセージと呼びます。Claude Codeの「セッション間メッセージ」と並べて読めるようにするための、当社の呼び分けです。

主要なツールの役割を整理すると次のとおりです。ツール名はそのまま書いていますが、利用者がツール名を打つ必要はありません。自然な言葉で頼めば、Codexが該当するツールを探して呼びます。

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

ツール何をするか
list_threadsサイドバーにあるタスクの一覧を取る(ピン留め・プロジェクト別の区分も含む)
read_thread他のタスクを開かずに、直近の状態とやり取りの要約を読む
wait_threads最大8つのタスクのどれかが完了するか、承認・入力待ちになるまで待つ
send_message_to_thread他のタスクにフォローアップのプロンプトを送る。「別のタスクから送信」の正体
handoff_threadタスクを別の実行場所(ローカルとワークツリーなど)へ引き継ぐ

なぜ頼んでいないのに送るのか — 縛りがあるのは「新しいタスクを作る」ことだけ

指示文を読むと、Codexに「ユーザーが明示的に頼んだときだけ使え」と縛りをかけているのは、新しいタスクを作るツールcreate_thread)だけです。作ったタスクはサイドバーに出て利用者のものになるので、勝手に増やすなという趣旨です。

一方、既存のタスクへメッセージを送るツールには、そうした縛りがありません。指示文にあるのは「ユーザーが引き継ぎや継続を頼んだら、該当するツールを先に探せ」という手順だけで、自発的に送ることを禁じる文言はない。だから、Codexが「この要件はあのタスクの担当だ」と判断すれば、自分で送ります。

判断材料も揃っています。Codexは一覧ツールでサイドバーのタスクを見渡し、読み取りツールで各タスクの直近の状態を読めます。別のタスクが何をしているか知ったうえで、伝えるべき相手を選べる。冒頭の実例で、通知メールの要件が実装側のタスクへ正しく届いたのはそのためです。

ここは当社の推論です

自発的に転送する挙動は、当社の実例と指示文の読み取りから導いたもので、OpenAIが意図を説明した公開文書は当社の確認した範囲では見当たりません。モデルやアプリのバージョンで頻度は変わりえます。

使いこなし — 自分から頼む書き方と、届いた側の扱い

自動で送られるのを待つだけでなく、自分から頼むこともできます。宛先はサイドバーに表示されているタスク名で伝えれば足ります。Codexが一覧ツールで探して送ります。次のように頼みます。

別のタスクへ伝言を頼む書き方の例
この件は「通知メール実装」のタスクに伝えてください。
伝える内容:差出人を送信専用アドレスにするなら、本文に問い合わせ先を明記すること。
今のタスクの作業はそのまま続けてください。

この機能は2026年3月には利用者の間で知られていました。メディア企業EveryのDan Shipper氏は同月のX投稿で「Codexのスレッド同士がメッセージを送れるようになった。スレッドIDを他のCodexのチャットに貼れば、そのスレッドに引き継ぎを頼める」と紹介しています。タスク名で通じない場合は、この方法も使えます。

進捗の見張りも頼めます。「◯◯のタスクが終わったら教えて」と頼むと、Codexは完了待ちツールでそのタスクが終わるか、承認待ちで止まるまで待ち、結果を報告します。複数のタスクを回すときの司令塔役を、Codexに任せる形です。

届いた側では、次の3点を意識してください。

  • 送信元を確かめる。ラベルをクリックして送信元のタスクに飛び、そこでの会話と照らす。伝言はCodexが書き直した要約で、原文そのままではない
  • ずれていたら自分の言葉で言い直す。伝言が意図と違うときは、宛先のタスクで直接指示を出す。伝言を修正するより早い
  • 前の作業が止まっていたら1行で戻す。動いている最中のタスクに伝言が差し込まれると、前の作業を取消しと読まれることがある。「さっきの伝言は前の作業の取消しではありません。中断した◯◯を再開してください」で戻る(フォローアップの動作の設定

動いている最中のタスクに伝言が届いたとき、キューに積まれるのか、今すぐ反映されるのかは、アプリ本体の定義からは断定できませんでした。送信ツールの説明が「フォローアップのプロンプト」なので、自分で送る追加指示と同じ扱いになると当社は見ていますが、未確認の点として記しておきます。

参考になる利用者の報告はあります。openai/codex の issue #30499では、送信が相手の進行中の推論に割り込むとして、割り込まない配送方式の追加が要望されています。少なくとも一部の環境では「今すぐ反映」に近い届き方をしている、と読めます。

Codex CLIにも入り口があります。codex queue --thread <セッション名かUUID> --message "…" で、動いている別のセッションにメッセージを積める(codex-cli 0.153.4のヘルプ「既存のセッションにメッセージをキューする」)。ターミナル派の人は、こちらで同じことができます。

Claude Codeとの違い — 「Claude Codeには無い」は誤解

Claude Codeには、公式ドキュメント「Message your other Claude Code sessions」が説明するセッション間メッセージがあります。2.1.224(2026年8月7日公開)以降のmacOS・Linuxで設定なしで有効、Windowsは2.1.234以降。Claudeが ListAgents で相手を探し、SendMessage で送ります。

公式ドキュメントは「Claudeは必要だと判断すれば、頼まれなくても自分でメッセージを送る」と明記しています。例として挙がっているのは、別のセッションが進めている作業に影響する変更をしたあと、という場面です。Codexで起きたのと同じ「勝手に連絡する」挙動が、こちらは公式に説明された仕様です。

当社の実測でも、Claude Codeのセッションで /list-agents を打つと、自分のセッション名と、同じMacで動いている別のセッションの名前が一覧に出ました。デスクトップアプリでは「◯◯のセッションに、スキーマが変わったと伝えて」のように自然な言葉で頼めます(公式デスクトップガイド。アプリの全体像はClaude Codeのアプリ・Web版・スマホ対応まとめ)。

両者の違いを表にまとめます。Codex側の「記載なし」は、アプリ本体の定義文と当社が確認した公開情報に記述がないという意味で、機能が無いと断定するものではありません。

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

項目Codex(ChatGPTデスクトップアプリ)Claude Code
提供時期遅くとも2026年3月には利用者の報告あり。公式の告知・専用ドキュメントは当社の確認した範囲で見当たらず2.1.224(2026年8月7日)から。公式ドキュメントあり
単位と探し方タスク(内部名はスレッド)。一覧ツールでサイドバーのタスクを引くセッション。ListAgents/list-agents@セッション名 で宛先を指定できる
届き方宛先タスクの本文に、人の入力と同じ吹き出しで「別のタスクから送信」ラベル付き「Message from @送信元」の1行プレビュー。デスクトップアプリでは送信元へのリンク付きカード
相手が作業中のとき記載なし(当社未確認)ツール呼び出しの合間に読み、実行中のツールは中断しない。デスクトップ経由は作業完了後に読む
自発的に送るか送る(指示文に禁止なし・当社実例)送る(公式「必要と判断すれば自分で送る」)
権限の扱い記載なし伝言は承認の代わりにならない・設定変更の指示には従わない・コマンドは実行しない・受け手の権限設定が優先
受け取りの制御記載なしcrossSessionInbound(accept/hold/refuse)。承認省略モードのセッション宛ては既定で保留し、本人が承認してから渡す
届く範囲同じアプリ内のタスク(接続したホストを含む)同じマシン。Remote Control経由で他のマシンやWeb版のセッションにも

違いの本質は、「別のセッションからの伝言」を人の指示と区別して渡す設計が明文化されているかです。Claude Codeは、伝言が承認の代わりにならず、設定も変えられず、受け取り側の権限が優先されると公式が定めています。Codexも包みに送信元IDを付けて渡していますが、その先の扱いは公開情報にありません。

どちらも独立したタスク同士の伝言であって、1つの仕事を分担するサブエージェントとは別物です。1つの仕事は分けずに1体でやる、というGPT-6 Astra以降の考え方は「AI社員」「AIチーム」はもう終了で、分担の型はサブエージェントと並列実行で解説しています。

運用の注意 — 便利さの裏で起きる3つのこと

  • 伝言は要約であって原文ではない。冒頭の実例でも、宮地の言葉は引用符付きで引かれつつ、前後はCodexの文章になっていた。重要な数値・固有名詞は、宛先のタスクで自分の目で確かめる
  • 同じファイルを2つのタスクで触らせない。Codex公式ガイドは「独立した仕事は別のチャットで並列に走らせ、2つのタスクに同じソースへの書き込み権限を与えない」「同時に走らせるならワークツリーで作業コピーを分ける」と勧めている。伝言で連携できるからこそ、書き込み先は分ける
  • 往復が始まったら止める。タスク同士が伝言を返し合うと、利用枠を消費しながら会話が膨らむ。Claude Codeは同じ内容の連投を落とし、未読の上限を50件にする仕組みを公式に持つが、Codex側は当社未確認。案件ごとにタスクを分け、伝言は片方向を基本にする

まとめ

  • 「別のタスクから送信」は、別のタスクにいるCodexが送信ツールで送った指示。人の入力と同じ吹き出しで届き、ラベルをクリックすると送信元へ飛べる
  • 自発的に送るのは、禁止されていないから。縛りがあるのは新しいタスクを作るツールだけ。Codexは他のタスクの状態を読んだうえで宛先を選ぶ
  • Claude Codeにも同じ機能がある(2.1.224以降のセッション間メッセージ)。違いは有無ではなく、届き方と、権限・受け取り制御の明文化
  • 運用は3点。伝言は要約と心得る・同じファイルを2つのタスクで触らせない・往復が始まったら止める

複数のタスクやセッションでAIを走らせる働き方は、機能を知るだけでは定着しません。どの仕事を分け、どこで合流させ、何を人が確認するかという設計が要ります。当社のCodex研修・導入伴走支援では、貴社の実業務を題材に、並列で任せる仕事の分け方から確認の型づくりまでを一体でご支援しています。

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