Chat・Work・Codexはなぜ分かりにくいのか --- Web・アプリ・CLIを、機能・実行場所・引き継ぎから整理する

Posted at 2026-09-15

Chatで企画を詰め、Workで資料を作り、Codexで実装する。一見すると、自然な役割分担に思える。

ところが、実際に仕事を任せようとすると別の疑問が出てくる。Workでもコードを扱えるなら、Codexに移る理由は何か。Web版とデスクトップアプリで同じ仕事を続けられるのか。Codex CLIで進めた作業を、スマホから確認できるのか。

用途だけで答えようとすると、説明はすぐに行き詰まる。「どう仕事を進めるか」「どこから操作するか」「どこで実行するか」が、別々の選択だからだ。 さらに、会話や資料を共有できても、作業状態や権限まで引き継がれるとは限らない。

本稿では、Chat・Work・Codexの役割に加え、Web・デスクトップ・モバイル・CLIの相関関係を整理する。3つのモードを順番に使うためではなく、仕事を任せる場所と、移動するときの境界を判断するための見取り図である。

確認範囲： 2026年9月14日時点のOpenAI公式資料に基づく。全OS・全プランでの実機検証ではない。機能の提供状況はプラン、地域、アプリのバージョン、段階的な展開、管理者設定などによって異なる。料金・利用枠は主に個人向けChatGPTプランを対象とし、API開発の詳細は扱わない。¹

1. 「入口」「体験」「実行場所」を分けて考える

混乱を避けるため、まず3つの軸を区別する。次の分類は、公式の製品構成を読むための本稿の整理である。

軸	判断すること	例
操作の入口	どこから指示・確認するか	Web、デスクトップアプリ、モバイルアプリ、CLI
作業の体験	どのように依頼し、結果を確認するか	Chat、Work、Codex
実行場所	ファイル操作やコマンドをどこで実行するか	自分のPC、WSL2、管理されたクラウド環境

例えば、「デスクトップアプリを使う」は操作の入口を選ぶ話であり、「ローカルで実行する」と同義ではない。デスクトップのWorkにはクラウド実行とローカル実行があり、CodexにもLocal・Worktree・Cloudの選択がある。¹²

Codex CLIも、ChatやWorkに続く「第4の工程」ではない。ターミナルからCodexを使うクライアントである。通常のローカル作業では、CLIが動く環境のファイルや開発ツールを利用する。³

本稿でいう実行場所は、主にファイル操作やコマンドなどのツールを動かす場所である。ローカル実行は、モデルもPC内で動くことや、情報が一切クラウドに保存されないことを意味しない。ローカル作業でも、メッセージやタスクの文脈がクラウドに保存される場合がある。⁴

Codexという名称は画面と製品群の両方を指すため、本稿では必要に応じて「デスクトップのCodex」「Codex CLI」「Codex Cloud」と書き分ける。

2. Web・アプリ・CLIの対応関係

どの入口から、何を使えるのか

以下は、必要な機能と権限がアカウントに提供されている場合の対応表である。「アプリ版」はPC用とスマホ用に分け、「Web版」もChatGPTの通常画面とCodex Cloudの専用画面を区別する。

操作の入口	利用する体験・機能	主な実行場所と対象
ChatGPTのWeb版	Chat／Work	Workはクラウドで実行。アップロード資料や接続したサービスを利用する⁵⁶
ChatGPTデスクトップアプリ	Chat／Work／Codex	Workはクラウドまたはローカル。CodexはLocal・Worktree・Cloudを選択する⁷¹²
ChatGPTモバイルアプリ	Chat／Work。Remoteから対応するPC上のCodexへ接続	Workはクラウド。Remoteのタスクは接続先PCで実行する⁴⁸
Codex CloudのWeb画面	クラウドのCodexタスク	リポジトリと依存関係などを設定したクラウド環境で実行する⁹
Codex CLI	ターミナルからCodexを操作	通常はCLIの実行環境。Codex Cloudのタスクを開始・確認する経路もある³⁹
Codex IDE拡張	エディター内でCodexを操作	開いているコードを文脈として利用。長い作業をクラウドへ委任する機能もある¹⁰

この対応表は、同名の機能がどのOSでも同じように動くという保証ではない。特にローカル操作とRemoteは、対応端末、権限、接続設定を別途満たす必要がある。

デスクトップは、単純に3つのボタンが並ぶ構造ではない

デスクトップアプリの階層を簡略化すると、次のようになる。これは画面の関係であり、作業の順番を示すものではない。⁷

ChatGPTデスクトップアプリ
├─ ChatGPT側の画面
│  ├─ Chat
│  └─ Work
└─ Codex側の画面

Codex CLI
└─ 同じアプリのタブではなく、ターミナルから使う別クライアント

「ChatGPT」はアプリ全体の名称でもあり、Codexに対する一方の画面の名称でもある。「ChatGPTとCodexは統合されたのか」という疑問に、単純なYes／Noで答えにくい理由の一つが、この階層にある。

「WebではCodexを使えない」は、範囲を限定しなければ不正確

ChatGPTの通常のWeb画面では、Chat／Workと同列のモードとしてデスクトップのCodexを選ぶことはできない。一方、ブラウザーからCodex Cloudを利用する専用のWeb画面は存在する。⁴⁹

したがって、「Web版Codexがある」と「ChatGPTのWeb画面にCodexモードがある」は同じ意味ではない。利用案内で「WebにはCodexがない」とだけ書くと、Codex Cloudまで使えないと読めてしまう。

同様に、スマホのRemoteは「モバイル版にPCと同じ実行環境が入る」機能ではない。スマホは、接続先PCで動くCodexを操作する入口になる。⁸

3. Chat・Work・Codexの違いは、担当分野より仕事の進め方

公式ガイドでは、Chatは対話、Workは確認可能な成果物までの委任、Codexは開発用の表示や技術的な詳細を確認する体験として整理されている。¹

Chatは、質問や比較を重ねて考えを詰めたいときに向く。Workは、目的と完成条件を示して、情報収集や分析を含めた仕事を任せたいときに向く。例えば、「企画の弱点を議論したい」と「資料を基に企画書を完成させたい」では、やり取りの重心が異なる。

ただし、これは排他的な機能分担ではない。Workでもコードを扱い、Codexでも調査や文書を作成できる。Workは成果物を、Codexはコマンド、Git差分、レビューなどを確認しやすい設計である。公式ガイドも、非コーディング作業でCodexを使い続けてよいと説明している。¹¹¹

「Chatで考え、Workで作り、Codexで仕上げる」という必須工程はない。 必要な道具と確認方法がそろっていれば、一つの環境で完了させる選択もある。

同じ実行基盤でも、同じ作業状態とは限らない

OpenAIの技術資料では、WorkとCodexは中核的な実行・隔離・権限の仕組みを共有し、Cloud Workは隔離環境でCodexハーネスを実行すると説明されている。⁶

ハーネスは、モデルへ文脈を渡し、ツールを実行させ、権限や承認を管理する周辺基盤である。Codexのアプリ、CLI、IDE拡張は、この共通基盤を利用する異なる入口になる。¹²

この構造は能力の重なりを説明するが、履歴や保存先の統合まで意味しない。同じモデルを選んだとしても、参照できる資料や使えるツールまで同一になるとは判断できない。

4. 「別の端末で続ける」には、異なる連携がある

Web、アプリ、CLIの関係は、「同期するか、しないか」の二択では整理できない。主な関係は次のように分かれる。

組み合わせ	連携の種類	継続する際の要点
通常Chat：Web ↔ デスクトップ／モバイル	アカウント上の会話・プロジェクトを利用	同じアカウントとワークスペースで、対象の会話を開く⁴¹³
Cloud Work：Web ↔ デスクトップ ↔ モバイル	クラウドのWork会話を同期して継続	PCのローカル実行環境を持ち運ぶ仕組みではない⁴
モバイルのRemote ↔ PCのCodex	接続先PCへの遠隔アクセス	PC側で作業を継続。PCの稼働と接続が必要⁸
デスクトップのCodex ↔ Codex CLI	ローカルの設定・保存履歴を共有できる構成がある	保存先、実行環境、対象フォルダが一致するかを確認する¹⁴¹⁵
CLI／IDE／デスクトップ → Codex Cloud	クラウド環境へのタスク委任	クラウド側の依存関係と対象リビジョンを確認する⁹¹⁰²
ChatGPTの会話 → デスクトップのCodex	会話を明示的に追加	プロジェクト全体の自動同期とは区別する¹⁵

Cloud Workは「同じクラウドの仕事を、別の入口から開く」

Cloud Workの会話は、Web・モバイル・デスクトップ間で同期する。デスクトップで開始したクラウドのWorkも、Webやモバイルで継続できる。⁴

WebのWork ──────────────────┐
デスクトップのWork ─────────┼─ Cloud Workの会話・タスク
モバイルのWork ─────────────┘

例えば、PCのブラウザーで資料分析を依頼し、移動後にスマホから追加条件を伝える使い方が考えられる。クラウド実行ではデスクトップアプリを閉じてもタスクを継続できるが、入力や承認が必要になれば停止する。¹

一方、PC上のアプリやファイルを使うLocal Workまで、同じ条件で持ち運べるとは限らない。会話が見えることと、必要なファイル、アプリ、実行中の処理へ到達できることは分けて確認する必要がある。

Remoteは「スマホが、PC上の仕事を操作する」

Remoteでは、作業を実行するのは接続先PCである。スマホから進捗を確認し、指示や承認を送れるが、PCを起動したままオンラインに保つ必要がある。⁸

モバイルアプリのRemote
          │ 指示・確認・承認
          ▼
接続先PCのCodex
          │
          ▼
PC側のファイル・開発ツール

Remoteで見えるCodexの会話が、通常のChatGPTのWeb／モバイル履歴へ変換されるわけでもない。履歴の同期ではなく、対応するPC上の会話へアクセスする仕組みとして理解した方がよい。⁴

Codex Cloudは「別の実行環境に仕事を委任する」

Codex Cloudでは、対象リポジトリ、依存関係、環境変数などを設定した隔離環境でタスクを実行する。Webだけでなく、CLIやIDEなどから利用する経路も用意されている。⁹¹⁰

これは、PCで実行中のプロセスを、そのままクラウドへ移すという意味ではない。手元で使っているファイルや依存関係がクラウド側にも存在するか、作業対象のリビジョンが合っているかを確認する必要がある。

結果をローカルへ取り込む際にも、成果物の受け渡しと会話状態の継続を同一視しない。コードが同じになっても、元の会話で検討した判断理由まで共有されたとは限らない。

5. プロジェクト・履歴・メモリは、別々に確認する

連携を評価するときは、共有の対象を少なくとも4つに分けると判断しやすい。以下は、本稿で用いる整理である。

共有の対象	確認したいこと
ファイル・参照資料	同じ版の原稿、コード、仕様書を参照できるか
会話履歴	過去の指示、応答、ツール実行結果を参照できるか
メモリ	別の会話で得た情報を、どの範囲から参照するか
作業状態	完了箇所、未解決事項、判断理由、実行中の処理を把握できるか

例えば、仕様書を読めても、仕様書に残していない「別案を採用しなかった理由」は分からない。「テストは成功した」という会話を読めても、対象コミットと実行条件が不明なら、別のコードにも結果を適用できるか判断できない。

同じ資料が見えることは、同じ仕事の続きを正しく始められることと同義ではない。

ChatGPTプロジェクトとローカルプロジェクト

ChatGPTプロジェクトは、会話、資料、指示、接続した情報源をまとめる単位である。ChatとWorkの会話を同じプロジェクトに置ける。一方、ローカルプロジェクトはPC上のフォルダへのアクセスを与える。両方がProjects画面に表示されても、同じ仕組みになったわけではない。¹⁵

CLIは作業ディレクトリを基準に動作し、ChatGPTのProjects画面を直接開く機能はない。ChatGPTプロジェクトに登録した資料が、CLIの作業フォルダへ自動的に配置されるという関係ではない。¹⁵

ChatGPTプロジェクトには、メモリ設定による制約もある。2026年9月14日時点では、プロジェクト専用メモリのプロジェクト内でWorkは利用できない。共有プロジェクトは自動的にプロジェクト専用メモリになる。会話間の参照範囲も、プランやメモリ設定に依存する。¹³

したがって、「ChatとWorkは同じプロジェクトを使える」という説明には条件が付く。情報の分離を目的に設定を選んでいるなら、Workを利用する都合だけで分離を解除するのではなく、必要な境界を先に決めたい。

会話を渡せても、プロジェクト全体の同期ではない

デスクトップのCodexには、既存のChatGPTチャットを開き、Codexチャットへ追加する機能がある。連携手段がないわけではないが、全資料、全指示、全履歴、実行中の処理まで継続的に同期するという保証は、この機能説明からは確認できない。¹⁵

メモリも別系統である。WorkはChatGPTアカウントやワークスペースのメモリ設定を使い、ローカルCodexは別のローカルメモリ保存先と制御を持つ。¹⁶

「同じアカウントだから、どの入口でも全部知っているはずだ」という前提は置かない。常に適用したい方針は、次の作業環境から読み取れる資料として残す方が管理しやすい。

6. デスクトップとCLIでは、作業フォルダと状態保存先を分けて見る

デスクトップのCodexとCodex CLIの連携は、コードの保存場所だけでは決まらない。Codex自身の設定や会話が保存される場所にも注意が必要だ。

Windows側の既定のCodex保存先は%USERPROFILE%\.codex、WSL2内のCLIはLinux側のホームディレクトリ配下を使う。標準では設定、キャッシュ済み認証、セッション履歴は自動共有されない。公式には共有のための構成方法も案内されているため、「共有不可能」ではなく「同じアカウントだけでは自動共有されない」と理解するのが正確である。¹⁴

Windows側のデスクトップアプリ／ネイティブCLI
└─ Windows側のCodex保存先

WSL2内のCodex CLI
└─ Linux側のCodex保存先

同じリポジトリにアクセスできても、保存履歴が同じとは限らない

Windowsアプリの統合ターミナルと、エージェント自体の実行環境も別設定である。ターミナルがWSLでも、エージェントはWindows側で動いている場合がある。¹⁴

Git worktreeを使う場合は、同じリポジトリから別の作業ファイルを持つ。CodexのLocalとWorktreeはともにPC上で実行されるが、編集対象のチェックアウトが異なる。²

引き継ぎでは、作業パス、ブランチ、コミット、未コミット差分を識別する。保存履歴の再開を、ファイルを過去の状態へ戻す操作とも混同しない。Codexは会話の記録とは別に、実際の作業ツリーからファイルを読む。¹⁵

この記事は連携の構造を説明するものであり、保存先の変更手順ではない。認証情報や設定も含まれるため、履歴をそろえる目的で状態ディレクトリを安易にコピー・上書きする運用は避けたい。

7. 利用枠はWorkとCodexが共通、APIは別会計

操作する入口と、課金の区分も別の軸である。個人向けChatGPTプランでは、主に次のように整理できる。¹⁷¹⁸

利用方法	主な利用枠・課金の区分
通常のChat：Web／デスクトップ／モバイル	Chat側のモデル・機能別の制限
Work：Web／デスクトップ／モバイル	Work／Codexの共通利用枠
ChatGPTログインのCodex：デスクトップ／CLI／IDE／Cloud	Work／Codexの共通利用枠
APIキーで利用するローカルCodexクライアント	ChatGPT契約とは別のAPI課金

Workを使えば、同じアカウント・契約の枠で動くCodex CLIの利用可能量にも影響する。Webからアプリ、アプリからCLIへ切り替えても、独立した利用枠が追加されるわけではない。¹⁷

CLIがログイン時にブラウザーを開いても、作業そのものがWeb版へ切り替わるわけではない。ブラウザーは認証に使われる。公式の認証説明では、ローカルのデスクトップアプリ、CLI、IDE拡張はChatGPTログインとAPIキーの両方を扱い、Codex CloudはChatGPTログインを必要とする。¹⁸

共通枠を使うことと、同じ依頼が同じ量を消費することも別だ。モデル、文脈、推論設定、速度、ツール、タスクの複雑さなどで消費量は変わる。アップロードや画像生成など、個別機能の上限まで同一という意味でもない。¹⁷

同じ機能名でも区分が変わる例がDeep Researchである。Chat内ではChat側の調査タスク枠を使うが、Work内ではWork／Codexの利用枠またはクレジットを使い、Chat側の調査タスク枠は消費しない。¹⁹

プロジェクトやメモリの面ではChatとWorkが近く、実行基盤や利用枠の面ではWorkとCodexが近い。 一つの線だけで製品同士を結ぼうとすると、この関係を説明しきれなくなる。

8. 使い分けより、仕事を分断しない設計を優先する

ここからは、仕様を踏まえた運用上の提案である。

基本方針は、必要な資料、ツール、権限、確認方法がそろう環境を、主な作業場所にすることだ。成果物の種類が変わるたびに移動するのではなく、移動する理由があるときに引き継ぐ。

端末をまたぐ仕事と、PCに依存する仕事を分ける

外出先のスマホからも進めたい資料分析なら、Cloud Workを主な作業場所にする案が考えられる。PCにしかないアプリや作業ファイルを使うなら、デスクトップのローカル実行が候補になる。両者では、作業を続けるために必要な端末が異なる。¹⁶

Gitで管理する技術記事なら、原稿の執筆、サンプルコードの実行、差分レビューを同じ環境で扱う方が、文章と検証対象を対応付けやすい。文章だからWork、コードだからCodexと細切れにする必要はない。

一方、既存の開発環境に依存せず、再現可能な設定で並行して処理できる仕事は、Codex Cloudへ委任する候補になる。重要なのは、すべての入口を使うことではなく、完了条件を満たせる環境を選ぶことである。

継続性を、長い会話だけに預けない

作業場所を維持することと、すべてを一つの会話に詰め込むことは違う。調査、執筆、レビューなど、成果が独立する単位で会話を分けても、確定した条件と正式な参照元を決めておけば、引き継ぎを明確にできる。

OpenAIも、常に適用すべき指示はAGENTS.mdやバージョン管理された文書に残し、メモリは補助的に扱うよう案内している。¹⁶

AGENTS.mdはCodexが作業前に読み込む指示ファイルだが、配置、探索範囲、優先順位、読み込み量に制約がある。どの入口でも同じファイルを無条件に読む、という仕組みではない。²⁰

運用では、日常的な作業規則と、個別タスクの引き継ぎ情報を分けるとよい。引き継ぎ情報には、承認済みの方針、判断理由、未完了事項、直近の検証結果を記し、正式なファイル名と保存場所を示す。

開発作業なら、実行者、OSと実行環境、対象の完全なパス、ブランチ名、コミット、対象PR、未コミット差分まで識別する。変更対象と変更禁止対象、実行時点、期待結果、エラー時の分岐、復旧方法も必要だ。PR未作成など、該当しない項目はその旨を記す。

一時修正と恒久修正、今すぐ実施する作業と別セッションで後から実施する作業も区別する。「続きを進めて」という短い指示に、実施範囲まで推測させないためである。

ただし、引き継ぎ文書は運用上の補完策だ。利用者が毎回状態を整理して渡さなければならないなら、その手間自体が製品の継続性を評価する要素になる。

9. 求められるのは、画面の統合より引き継ぎ範囲の明示

「Codexを独立したまま使いたい」という要求と、「ChatとCodexを統合してほしい」という要求は、必ずしも対立しない。

前者は、慣れた操作環境を維持したいという要求だ。後者は、同じ仕事について何度も説明し直さずに続けたいという要求である。どちらも、利用者が不要な製品境界の管理を引き受けなくて済むことを求めている、と考えられる。

本稿で重視したい改善は、入口を切り替える際に、引き継ぐ会話・資料・指示、引き継がない処理や権限、実行先、消費する利用枠を明示することだ。目的、制約、判断、成果物、検証結果をプロジェクトが保持し、Web・アプリ・CLIが異なる操作の入口になれば、利用者は内部構造より仕事に集中しやすくなる。

これは本稿の設計上の提案であり、現行仕様やOpenAIの開発予定を示すものではない。

全面的な共有が常に望ましいわけでもない。別案件の情報を混ぜたくない場面や、閲覧だけを許可したい場面はある。判断理由を共有することと、認証情報や変更権限を渡すことは分けなければならない。

必要なのは、すべてを無条件につなぐことではなく、必要な文脈を、必要な権限の範囲で、確実に引き継げることである。

おわりに

Chat・Work・Codexは仕事の進め方を、Web・デスクトップ・モバイル・CLIは操作の入口を表す。そこにクラウドとローカルという実行場所の違いが重なる。

連携を考えるときは、履歴の同期、PCへの遠隔アクセス、別環境へのタスク委任、成果物の受け渡しを区別する。同じアカウント、同じ資料、同じモデルというだけでは、同じ仕事をそのまま続けられるとは判断できない。

実際の運用では、必要な文脈と道具がそろう環境を選び、完了できる仕事はその場所で進める。入口を変えるときには、何を参照でき、どこで実行し、どこから再開するかを明確にする。

Chat・Work・Codexは、順番に通過する工程ではない。Web・アプリ・CLIも、能力を順に高める階段ではない。選択の基準は、その組み合わせで何ができ、どこまで仕事を継続できるかに置くべきだ。

参考文献

参照日はすべて2026年9月14日。本文中の脚注は、各記述の確認に使用したOpenAI公式資料を示す。実機で確認した範囲を示すものではない。

OpenAI, Use ChatGPT. 「Choose how you want to work」「Compare ChatGPT Work and Codex on desktop」。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷
OpenAI, Codex environments. ↩ ↩² ↩³ ↩⁴
OpenAI, Codex CLI. ↩ ↩²
OpenAI, ChatGPT Work and Codex. 履歴、端末間の継続、ローカル実行、認証と課金の説明。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷
OpenAI, ChatGPT on the web. Chat／Workの選択とWeb上の作業対象。 ↩
OpenAI, ChatGPT Work Overview. 共通の実行基盤とローカル／クラウドの説明を参照。法人契約固有の保証を個人プランへ適用する意図はない。 ↩ ↩² ↩³
OpenAI, ChatGPT desktop app. 「Get started with the desktop app」。 ↩ ↩²
OpenAI, Codex Remote. ↩ ↩² ↩³ ↩⁴
OpenAI, Codex cloud. 専用Web画面、クラウド環境、タスク委任、Web／CLIからの利用。 ↩ ↩² ↩³ ↩⁴ ↩⁵
OpenAI, Codex IDE extension. エディターの文脈、ローカル作業、クラウドへの委任。 ↩ ↩² ↩³
OpenAI, Get started with ChatGPT Work. 「Introducing ChatGPT Work」。 ↩
Nicolas Bonamy and Derrick Choi, OpenAI, Codex as a platform: build on the open agent harness, 2026-08-19. ↩
OpenAI, Projects in ChatGPT. 「Memory in projects」「Project-only memory」。 ↩ ↩²
OpenAI, ChatGPT desktop app for Windows. 「Windows Subsystem for Linux (WSL)」「Share config, auth, and sessions with WSL」。 ↩ ↩² ↩³
OpenAI, Projects and chats. ChatGPTプロジェクト、ローカルプロジェクト、CLI、Quick chatの説明。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
OpenAI, Memories. ↩ ↩²
OpenAI, Using Codex with your ChatGPT plan. 「Why usage can run out」および利用制限に関するFAQ。 ↩ ↩² ↩³
OpenAI, Authentication. 「OpenAI authentication」「Sign in with an API key」。 ↩ ↩²
OpenAI, Deep research in ChatGPT. 「How does usage differ between Chat and Work/Codex?」。 ↩
OpenAI, Custom instructions with AGENTS.md. 「How Codex discovers guidance」。 ↩

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up