ChatGPT の Work と Codex、どちらに頼むか

Codex で足りていると、Work の出番が見えない

2026年7月に ChatGPT Work が出てから、デスクトップの ChatGPT アプリには Chat、Work、Codex の3つが並んでいます。私は普段の作業をほとんど Codex で済ませていて、Work はほぼ使っていません。Codex でも調べ物はできるし、文書も書けるので、わざわざ Work に切り替える理由が見えなかったからです。

そこへ9月末に dots が加わり、dot から Work にも Codex にも仕事を振れるようになりました。使い分けがはっきりしたのか、かえって混ざったのかを確かめたくなり、次の3つの観点で調べました。

• 使い分け
  • Work と Codex は、どういう仕事で使い分けるとよいのか
• dot からの頼み方
  • dot 経由で Work も Codex も使えるのか
  • そのとき、ローカルとクラウドを使い分けられるのか
• 作業場所
  • Work は、どこに作業フォルダを用意して作業するのか
  • ワークツリーを使っていると、フォルダがさらに散らからないか

先に結論を図にまとめます。

• 使い分けの基準は、頼んだ仕事が返ってきたとき、自分が何を確かめるかです。資料、表、調べ物の結論なら Work、コードの差分やテスト結果なら Codex に頼みます
• dot は、Work と Codex の上に立って仕事を振り分ける係です。dot のクラウドのコンピューターで進める仕事と、接続した自分のコンピューターで進める仕事を、頼み方で選べます
• 作業フォルダは、プロジェクトにフォルダを付けて始めればそのフォルダです。付けずに始めると、ドキュメント配下の Codex フォルダに「日付/チャット名」のフォルダが自動でできます
• ワークツリーは、さらに別の場所（ホームの .codex/worktrees）にできます。散らかりやすいのは、ワークツリーよりもプロジェクト外のチャットのほうでした

以下、公式ドキュメントとコミュニティの情報を引きながら、私の Windows 機の設定画面とフォルダの中身で確かめた結果を書きます。

公式の区別は「成果物」か「ソフトウェア開発」か

OpenAI のヘルプ記事は、Work と Codex を次のように説明しています¹。

Work is an agent designed for longer, multi-step work and finished deliverables.

Codex remains dedicated to software development and technical work.

• 訳（1文目）: Work は、長く、何段階にもわたる仕事と、仕上がった成果物のために作られたエージェントである。
• 訳（2文目）: Codex は、引き続きソフトウェア開発と技術的な仕事に特化している。

この記事では、この2文を使い分けの出発点として使います。Work の成果物として公式が挙げているのは、文書、表計算、プレゼンテーション、レポート、Sites です¹。Work の発表記事では、Codex の技術を組み込むことで、ChatGPT が質問に答えるだけでなく作業そのものを進められるようになった、と説明しています²。

Starting today, the Codex app is merging with the new ChatGPT desktop app.

• 訳: 本日から、Codex アプリは新しい ChatGPT デスクトップアプリに統合される。

この記事では、この1文を「Work と Codex は同じアプリの別のモードになった」という意味で使います。同じアプリに入ったとはいえ、ヘルプ記事によれば Work の会話履歴と Codex の履歴は別々に保たれ、Codex のサイドバーには ChatGPT のチャットは出ません³。

利用枠については、Work と Codex が同じ利用枠を使い、通常の Chat は別枠だと紹介している記事があります⁴⁵。Codex に慣れた人から見ると、Work を使っても枠が別に増えるわけではない、という点は押さえておくとよさそうです。

Codex 派が Work に回すとよい仕事

公式の区別だけだと、私のように「Codex でも文書は書ける」と思っている人には決め手になりません。実際、Work でもコードは書けるし Codex でも文書は作れる、と書いている紹介記事もあります⁴。

決め手になったのは、Work や Codex から仕事が返ってきたとき、自分がそこで何を確かめるかで頼む先を選ぶ、という基準です。比較記事は、返ってきた成果を使う前に人が確かめて承認するものが文書やレポートなら Work、コードの差分やテスト結果、プルリクエストなら Codex だと整理しています⁶。この基準で、Codex に慣れた人が Work に回すとよい仕事を並べると、次のようになります。

Work のプラグインと Scheduled Tasks は、発表記事に書かれている機能です²。Work はウェブとスマホから始めてクラウドで進められるので、外出先で調べ物を投げておき、戻ってから結果を読む、という使い方もできます¹。

両方を続けて使う例も挙がっています⁶⁴。

• Work で競合の調査や要件の整理をして、資料にまとめる
• そのうちリポジトリに入れる部分（料金表の更新など）を Codex に渡し、差分をレビューする

Codex 派の私にとって、Work に回す価値がありそうなのは、上の表の前半4つでした。特に、リポジトリを用意するまでもない調べ物を Codex に頼むと、後で触れるとおり、中身のわからないフォルダが増えていきます。

dots は Work と Codex に仕事を振る係

dots は、2026年9月29日の DevDay で発表された、常に動いているエージェントです⁷。公式ドキュメントは、dot が自分のコンピューターを持っていると書いています⁸。

Your dot has its own computer and browser in the cloud for research, files, and running software.

Your dot can use background agents, start new cloud threads, and create Work or Codex tasks on a connected computer.

• 訳（1文目）: dot は、調べ物、ファイル、ソフトウェアの実行のために、クラウド上に自分のコンピューターとブラウザを持っている。
• 訳（2文目）: dot は、バックグラウンドのエージェントを使い、新しいクラウドのスレッドを始め、接続されたコンピューターで Work や Codex のタスクを作れる。

この記事では、この2文から、dot 自身はクラウドにいて、手を動かす仕事は Work か Codex に振る、という役割分担を読み取ります。dot に話しかけること自体は利用枠を使わず、dot が始めた Work や Codex のタスクが利用枠を使う、とも紹介されています⁷⁹。

ローカルとクラウドは、振り方で決まる

dot からの振り方は、公式ドキュメントで次の3種類に分かれています¹⁰。

条件を表にすると次のとおりです。

つまり、dot 経由で Work も Codex も使え、ローカルとクラウドの使い分けもできます。ただし、条件はそれぞれ違います。ローカルで動かす場合について、公式は次のように書いています¹¹。

Keep your computer online with the ChatGPT app open while your dot uses it.

• 訳: dot がコンピューターを使うあいだは、コンピューターをオンラインにして、ChatGPT アプリを開いたままにしておく。

この記事では、この1文を、ローカルに振った仕事はコンピューターを閉じると止まる、という意味で使います。dot に接続できる自分のコンピューターは1台だけです⁸。手元の Mac を何台も切り替えて使うのは面倒だった、という体験記もあります⁹。

クラウドでコードを書かせる場合は、Codex のクラウド環境が前提です。クラウド環境は GitHub のリポジトリを選んで作り、Publish してから使います¹²。クラウドのタスクは、手元のファイル、動いているプロセス、ブラウザのログイン状態、VPN を引き継ぎません¹³。

Your computer’s local files, running processes, browser sign-ins, and VPN access aren’t automatically transferred to it.

• 訳: コンピューターのローカルファイル、実行中のプロセス、ブラウザのログイン、VPN のアクセスは、自動では引き継がれない。

この記事では、この1文を、クラウドに振る仕事はリポジトリだけで完結するものに限る、という判断の根拠に使います。

dot を使えるのは、2026年10月時点で Pro（100 / 200 / 500）、Business Premium、Enterprise のプランです。Pro は18歳以上で、欧州経済領域、英国、スイス以外の利用者が対象です。Enterprise では管理者が有効にする必要があります⁸。dot を使わなくても、スマホの Remote から手元の Windows や Mac の Codex タスクを始めたり見守ったりできる、という使い方も紹介されています⁵。

作業フォルダはどこにできるか

ここからが、一番気になっていた作業フォルダの話です。Work と Codex がどこで動くかによって、ファイルの置き場は次のように分かれます。

1. クラウドで動く Work と Codex Cloud、dot のクラウドのコンピューターは、手元にフォルダを作りません
2. デスクトップでプロジェクトにフォルダを付けて始めると、そのフォルダで作業します
3. プロジェクトの外でチャットを始めると、チャット用のフォルダが日付ごとに自動でできます
4. Codex の Worktree モードは、ワークツリー用の別の場所を使います

クラウドの Work は手元にフォルダを作らない

ウェブとスマホの Work はクラウドで動き、手元のファイルには直接触れません¹。作ったファイルは、使える場合は Library に保存されます¹⁴。デスクトップでローカルに作ったファイルについては、次のように書かれています¹⁴。

Local desktop outputs may remain in local projects or folders and do not automatically appear on web or mobile.

• 訳: デスクトップでローカルに作った成果物は、ローカルのプロジェクトやフォルダに残ることがあり、ウェブやスマホには自動では表示されない。

この記事では、この1文を、ローカルの Work で作ったファイルは手元のフォルダを見に行く必要がある、という意味で使います。

プロジェクトにフォルダを付けると、そのフォルダで作業する

デスクトップアプリでは、Work でも Codex でもローカルのフォルダを開けます¹。プロジェクトの説明は次のとおりです³。

Projects don’t need a folder, but you can attach folders as needed.

New chats start in the primary folder.

• 訳（1文目）: プロジェクトにフォルダは必須ではないが、必要に応じてフォルダを付けられる。
• 訳（2文目）: 新しいチャットは、プライマリフォルダで始まる。

この記事では、この2文を、作業フォルダを自分で決めたいならプロジェクトにフォルダを付けて始める、という手順の根拠に使います。フォルダは、プロジェクトのメニューの Edit project から Add folder で足し、Make primary でプライマリを切り替えます³。Codex は、プライマリフォルダを Git の操作と AGENTS.md の読み込みに使います³。

Work の作業フォルダでつまずく人は多いようで、プロンプトにフォルダのパスを書いても、そのフォルダを作業場所として開いたことにはならない、と解説している記事があります¹⁵。同じ記事は、Windows 版で「＋」からフォルダを選べなかったときに、プロジェクトの編集からフォルダを足してプライマリにする回避策を紹介しています¹⁵。

プロジェクトの外で始めると、日付フォルダが増える

プロジェクトに入れずにチャットを始めると、アプリはそのチャット用のフォルダを自動で作ります。既定の場所は、Windows なら %USERPROFILE%\Documents\Codex、Mac なら ~/Documents/Codex で、その下に「日付/チャット名」のフォルダができます¹⁶¹⁷。チャット名が同じなら、new-chat-2 のように番号が付きます。

この場所は、設定の「一般」にある「プロジェクト外のチャット用フォルダー」で変えられます。私の Windows 機では次のように表示されていました（設定済みのパスは塗りつぶしています）。

この設定は、まだ公式ドキュメントのプロジェクトのページには書かれていません³。コミュニティでは、ドキュメント配下は iCloud や OneDrive で同期されることが多く、チャットのフォルダに入った node_modules などが同期を重くする、という報告が続いています¹⁶¹⁷。設定を変えても、ブラウザ拡張から始めたタスクなど一部の入り口では既定の場所に戻ってしまう、という未解決の報告もあります¹⁸。

私の Windows 機で数えてみた

実際にどれくらい散らかるのかを、私の Windows 機で数えました。私はこの設定を途中で変えていたので、既定の場所と変更後の場所の両方にある日付フォルダの中身を数えています。

フォルダは10日分で26個あり、そのうち15個は new-chat、task、1文字だけ、といった名前で、中身を開かないと何のフォルダかわかりませんでした。1日に new-chat から new-chat-6 まで並んだ日もあります。フォルダ名はチャットの名前から付くようで、名前が付く前に作られたチャットや、短い確認の依頼ほど、汎用の名前のまま残っているように見えます。

最新の日付のフォルダには、その日に Work で始めたチャットと同じ名前のフォルダもありました。フォルダの中までは確かめていませんが、Work のローカルのチャットも、同じ「プロジェクト外のチャット用フォルダー」を使っているように見えます。

ワークツリーを使うと、フォルダはさらに散らかるか

Codex のデスクトップアプリには、Local、Worktree、Cloud の3つのモードがあります¹³。

• Local: いま開いているプロジェクトのフォルダで、そのまま作業する
• Worktree: Git のワークツリーを作り、変更をいまのチェックアウトから切り離す
• Cloud: 公開済みのクラウド環境から、リモートの作業場を作って作業する

Worktree モードのワークツリーがどこにできるかは、公式ドキュメントに次のように書かれています¹⁹。

Codex creates worktrees in $CODEX_HOME/worktrees.

By default, Codex keeps your most recent 15 Codex-managed worktrees.

Before deleting a Codex-managed worktree, Codex saves a snapshot of the work on it.

• 訳（1文目）: Codex は、$CODEX_HOME/worktrees にワークツリーを作る。
• 訳（2文目）: 既定では、Codex が管理するワークツリーを直近の15個まで残す。
• 訳（3文目）: Codex が管理するワークツリーを消す前に、その作業のスナップショットを保存する。

この記事では、この3文を、Worktree モードのワークツリーは自分のリポジトリの横ではなく、アプリが管理する場所にまとまる、という意味で使います。CODEX_HOME の既定は ~/.codex で、Windows のアプリでは %USERPROFILE%\.codex です²⁰。

私の Windows 機の設定の Worktrees 画面でも、Worktree ルートの欄に既定の場所が薄く表示され、自動削除の制限値は15になっていました（ユーザー名は塗りつぶしています）。

つまり、ワークツリーを使っても、自分のリポジトリの横に兄弟フォルダが増えるわけではありません。リポジトリ本体、ホームの .codex/worktrees、ドキュメント配下のチャット用フォルダの3か所に分かれる、というのが実態です。

ワークツリーのほうは既定で自動削除がオンになっているので、設定を変えないかぎり15個を超えて増え続けることはありません。上限のない日付フォルダのほうが、散らかる元になります。

ワークツリーで気をつけたいのは、.gitignore に入っているファイルが付いてこない点です。Local と Worktree のあいだでチャットを移す Handoff は Git で動くので、無視されたファイルは移りません。必要なファイルは、リポジトリ直下の .worktreeinclude に書いておくとワークツリーにコピーされます¹⁹。同じブランチは2か所で同時にチェックアウトできないので、ワークツリーで作ったブランチを手元で開きたいときは、Handoff で Local に戻します¹⁹。

Windows と Mac で違うところ

調べた範囲で、Windows と Mac の違いを表にまとめます。

Windows のアプリは、既定で Windows ネイティブのエージェントを使い、コマンドは PowerShell で動きます²⁰。

By default, the ChatGPT desktop app uses the Windows-native Codex agent.

• 訳: 既定では、ChatGPT デスクトップアプリは Windows ネイティブの Codex エージェントを使う。

この記事では、この1文を、Windows では既定で PowerShell の環境が作業場所になる、という前提として使います。エージェントを WSL に切り替えた場合、WSL の CLI は Linux 側のホームを使うので、Windows のアプリと設定やセッションを共有しません²⁰。公式は、Windows ネイティブのエージェントでは、プロジェクトを Windows のドライブに置き、WSL からは /mnt/<ドライブ>/... で触るほうが確実だとしています²⁰。WSL とアプリを行き来する人は、.codex も作業フォルダも Windows 側と WSL 側の2か所に分かれる点に気をつけてください。

Windows では、ドキュメントフォルダを OneDrive に移している人も多いので、既定のチャット用フォルダが同期の対象に入りやすくなります。既定の場所が OS 側で移したドキュメントの場所に従わない、という報告もあります¹⁶。

Codex 派の私がまず Work に回すもの

調べた結果をまとめます。

• Work と Codex は、頼んだ仕事が返ってきたとき、自分が何を確かめるかで分けます。資料、表、調べ物の結論は Work、差分とテスト結果は Codex です
• dot は、Work と Codex に仕事を振る係です。クラウドのコーディングにはクラウド環境、ローカルには接続したコンピューターが要ります
• 作業フォルダは、プロジェクトにフォルダを付ければそのフォルダです。付けなければ、ドキュメント配下に日付フォルダが自動でできます
• ワークツリーは .codex/worktrees にまとまり、既定では上限15の自動削除があります。散らかりやすいのは、プロジェクト外のチャット用フォルダのほうです

フォルダを散らかさないために、私は次の3つを決めました。

• リポジトリの作業は、必ずプロジェクトを開いてから始める
• プロジェクト外のチャット用フォルダーは、同期されない場所に移す
• 手元のファイルが要らない調べ物は、Codex ではなくクラウドで動く Work に頼む

3つ目は、Codex 派の私には意外な結論でした。ローカルで始めたチャットは、Codex でも Work でも日付フォルダを残すように見えますが、クラウドの Work は手元にフォルダを作らないからです。次は、調べ物をクラウドの Work に回すようにして、日付フォルダの増え方がどう変わるかを見てみます。

参考文献