ChatGPTには、日常的な質問に答える「チャット」、複数の資料やツールを使って完成品を作る「Work」、ローカル環境やリポジトリで技術作業を行う「Codex」があります。
ところが、現在はWorkだけでなくCodexでも文書、表計算、プレゼンテーション、PDF、画像などを作成できます。
反対に、Workもコードやシェルコマンドを扱える場合があります。
そのため、「OfficeファイルならWork」「コードならCodex」という分類だけでは、正しい使い分けができません。
本記事では、次の疑問をまとめて整理します。
- チャット、Work、Codexは何が違うのか
- それぞれから別のタスクを起動できるのか
- Workのセッションはどこに表示され、どう継続するのか
- WorkとCodexでは、ファイル、承認、画像生成、MCP、スキルの扱いがどう違うのか
- WorkタスクをCodexやHome Assistantから監視できるのか
- WorkとCodexの利用枠は共通なのか
最終確認日：2026年7月27日
確認対象：ChatGPT Web、ChatGPTデスクトップアプリ、CodexのOpenAI公式ドキュメント
注意：Workは段階的に提供されている機能です。利用できる画面、モデル、ツール、料金体系は、プランやワークスペースの設定によって異なります。
先に結論を言えば、選択基準は「何を作るか」だけではなく、どこに作業状態を残し、どの画面で確認・修正・再実行したいかです。
ChatGPT-5.6 Solに質問を行った際に、Codexからworkのクラウドタスクを生成できるということが分かったため、workとCodexの関係を調べてみようと考えた。そのため、「それぞれから別のタスクを起動できるのか」という調査項目が本記事に含まれている。また、workとCodexの使い分け・併用要領についてもあらためて詳細調査を行った。
（注）本記事の内容は正確性を保証するものではない。
（2026年7月27日 追記）YouTube動画を追加しました。 https://youtu.be/jDmB8LCqKSE
最初に結論：チャット・Work・Codexの役割
OpenAIは、チャットを日常的な対話、Workを長時間・複数ステップの作業と完成成果物、Codexをソフトウェア開発と技術作業のための体験として説明しています。
| モード | 主な役割 | 向いている処理 |
|---|---|---|
| 通常のチャット | 相談、質問、軽作業の入口 | 質問、要約、アイデア出し、短い文章、方針検討 |
| Work | 資料やツールを使って、レビュー可能な成果物を完成させる | 調査、分析、Word、Excel、PowerPoint、PDF、レポート、Site |
| Codex | ローカル環境や技術資産を操作し、実行結果まで検証する | コード、Git、ターミナル、テスト、自動化、監視、リポジトリ作業 |
公式の簡潔な説明は、ChatGPT Work and Codexで確認できます。
ただし、この表は「片方でしかできないこと」を示すものではありません。
- Codexでも文書、表、スライド、PDFを作成できる
- Workでも、許可された環境ではコードやシェルコマンドを実行できる
- WorkとCodexの両方で、プラグイン、画像生成、Browser、Computer Useなどを利用できる場合がある
本質的な違いは、Workが完成品と人によるレビューを中心に設計されているのに対し、Codexは実行環境、変更内容、ログ、テスト、再現性を中心に設計されていることです。
チャット・Work・Codexの関係
通常のチャットは相談の入口です。
内容が大きくなったらWorkへ移り、ローカル環境での処理や厳密な検証が必要になったらCodexを使います。
正確性と見栄えの両方が重要なら、WorkとCodexを併用します。
チャット・Work・Codex間でタスクを起動できるのか
独立した別タスクを起動できるか（例：Chatからworkの独立した別タスクを起動できるか）を下図に示す。
- 緑の実線：現在の確認環境で起動可能
- オレンジの破線：Voice、プラン、段階的提供機能に依存
- Chatへの矢印なし：通常のチャットはエージェントタスクの起動先ではない
- 手動で画面を切り替えて開始する操作は、別タスクの自動起動と区別
現時点で確認できること
OpenAIの現行マニュアルでは、ChatGPT Voiceが別スレッドを作成し、既存タスクの確認や追加指示を行えること、さらに「Codexタスクを開始してテストを実行する」といった指示例が示されています。
また、定期タスクはChatGPTまたはCodexのチャットから作成・更新できます。
一方、文字入力によるすべての組み合わせが、全プラン・全画面で同じように利用できるとは公式に保証されていません。
相互起動は、デスクトップアプリのバージョン、提供状況、プラン、管理者設定、利用可能なツールによって変わります。
タスクIDが返される環境では、そのIDを使って同じタスクへ追加指示を送ったり、状態を取得したりできます。
ただし、そのIDが一般公開された外部APIから永続的に利用できるとは限りません。
アプリ内部のタスク管理機能と、Home Assistantなどから利用できる公開APIは別の話です。
Codexから、独立した別のworkタスクを起動できることが分かったが、起動できるのは、workの「クラウドタスク」であり、「ローカルタスク」ではないとのこと。
Workのセッションはどこに表示されるのか
2026年7月時点の公式説明では、ChatとWorkの会話はChatGPT側の「Recents」に一緒に表示され、並べ替え、絞り込み、ピン留めができます。
ChatGPTプロジェクトでは、同じプロジェクト内からChatまたはWorkを選んで新しい会話を開始できます。
一方、Codexはデスクトップアプリ内の別ビューです。
Codexの履歴はChatGPT側のChat／Work履歴とは分かれています。
| 項目 | Chat／Work | Codex |
|---|---|---|
| 主な表示場所 | ChatGPTビューのRecents、Projects | Codex専用ビュー |
| 履歴 | ChatとWorkが一緒に表示される | ChatGPT履歴とは別 |
| プロジェクト | 同じChatGPTプロジェクトにChatとWorkを置ける | ローカルフォルダやリポジトリをプロジェクトとして扱う |
| クラウド同期 | クラウドWorkはWeb、モバイル、デスクトップ間で同期 | Codexはデスクトップ中心。 対応チャットはモバイルのRemoteから確認可能 |
| 継続方法 | 対象のChat／Work会話を開いて続ける | Codexビューで対象タスクを開いて続ける |
つまり、プロジェクト内の一覧でWorkセッションを選んで続きを依頼できますが、それはChatGPT側のWorkとして再開されます。
Workを継続するためにCodexビューへ移る必要はありません。
反対に、Codexのタスクを継続する場合はCodexビューを使います。
Chat／WorkとCodexは、同じデスクトップアプリ内にあっても履歴管理の系統が異なります。
詳しくは、ChatGPT Work and CodexおよびProjects in ChatGPTを参照してください。
workを使ったことがなかったので、チャットとworkの履歴が同じ画面に表示されることを本調査で知った。チャットとCodexとworkはそれぞれ独立した画面を持っていると思っていた。
また、workはローカルファイルを扱うものと思っていたが、クラウドタスクもあるとのこと。
workのクラウドタスクではどのような処理を行えるのか、よく分からないところがあったのでCHatGPT-5.6 Solに質問してみた。
ChatGPTのworkは「クラウドタスク」も起動できるということですが、何を入力とし、どのような処理を行い、どこに出力するのですか。例えば、添付資料を入力とし、報告書を作成して、回答画面でダウンロードできるようにするとかですか
はい。添付資料を入力として、内容を分析し、報告書ファイルを作成するという使い方は、ChatGPT Workの代表的な利用方法です。
ただし、「クラウドタスク」には似た仕組みがいくつかあるため、分けて考えると分かりやすくなります。
1．通常の「クラウドWorkタスク」
Web版やモバイル版でWorkを選んで依頼すると、処理はChatGPTのクラウド環境で実行されます。
会話を閉じても、追加確認が不要な範囲では処理を続けられ、同じWork会話をWeb・モバイル・デスクトップ間で引き継げます。(OpenAI Help Center)
基本的な流れは次のとおりです。
指示・添付資料・接続アプリ
↓
クラウド上で調査・分析・ファイル作成
↓
回答画面・Library・Google Driveなどに出力入力できるもの
| 入力 | 具体例 |
|---|---|
| 指示文 | 「添付資料をもとに報告書を作成してください」 |
| 添付ファイル | PDF、Word、Excel、CSV、画像、PowerPointなど |
| 参考ファイル | 過去の報告書、書式見本、スライドのテンプレート |
| プロジェクト内の情報 | プロジェクトの指示、ファイル、過去の会話 |
| 接続アプリ | Google Drive、Gmail、Slackなど |
| Web情報 | 公開Webサイト、ニュース、製品ページなど |
| 出力条件 | PDF、Word、スプレッドシート、スライドなど |
| 品質条件 | ページ数、文体、対象読者、図表、引用元など |
Workでは、作成する成果物、利用目的、参考資料、出力形式、保存先、変更してはいけない部分などを指示できます。(OpenAI Help Center)
内部で行われる処理
たとえば、添付PDFから報告書を作る場合、Workはおおむね次の処理を行います。
- 添付資料を読み取る
- 内容を分類・整理する
- 重複や矛盾を確認する
- 必要に応じてWebや接続アプリから補足情報を取得する
- 報告書の構成を決める
- 本文、表、グラフなどを作成する
- WordやPDFなどのファイルに整形する
- 内容を確認し、成果物として返す
作業中に判断できない点がある場合は、質問や確認を求めて一時停止することがあります。ユーザーは進捗を確認し、途中で方向を変更したり、重要な操作を承認したりできます。(OpenAI Help Center)
出力先
出力先は、依頼時に指定できます。
回答画面
文章による要約、分析結果、注意事項などが表示されます。
ファイルを作成した場合は、会話内に成果物として表示されることがあります。
ChatGPTのLibrary
クラウド版Workで作成したファイルは、利用可能な環境ではLibraryに保存されます。
Libraryからファイルを選択し、ダウンロードできます。(OpenAI Help Center)
したがって、質問にある次の使い方は可能です。
添付資料
↓
内容を分析
↓
報告書を作成
↓
WordまたはPDFとして保存
↓
ChatGPTのLibraryからダウンロード「必ず回答画面だけにダウンロードボタンが表示される」というより、会話内の成果物またはLibraryから取得すると考える方が正確です。
Google Workspace
Google Driveを接続している場合は、次の形式で作成・編集できます。
- Googleドキュメント
- Googleスプレッドシート
- Googleスライド
実行前に、対象アカウントやファイルの選択、書き込み操作の承認を求められる場合があります。(OpenAI Help Center)
ローカルフォルダ
デスクトップ版Workでローカルフォルダを開いている場合は、MacやWindows上のフォルダにファイルを作成できます。
この場合、出力はそのパソコンに残り、自動的にWeb版やLibraryへ同期されないことがあります。(OpenAI Help Center)
workの「クラウドタスク」に関するChatGPT-5.6 Solの回答で、上記内容「デスクトップ版Workでローカルフォルダを開いている場合は、MacやWindows上のフォルダにファイルを作成できます。」があったが、これは「クラウドタスク」ではないのかを追加質問してみた。
はい。ご指摘の記述は「ローカルタスク」に分類するのが正確です。
デスクトップ版Workでローカルフォルダを開いている場合は、MacやWindows上のフォルダにファイルを作成できます。
これは、クラウドタスクの説明に含めるべきではありません。
前の回答では、クラウド版Workとデスクトップ版のローカルWorkを混同していました。
正しい区別
| 項目 | クラウドWorkタスク | ローカルWorkタスク |
|---|---|---|
| 開始場所 | Web、モバイル、デスクトップ | デスクトップアプリ |
| 入力元 | アップロードファイル、プロジェクト、接続サービス | Mac・Windowsのローカルフォルダ |
| 作業対象 | クラウド側で利用可能なファイル | パソコン内のファイル |
| 出力先 | 回答画面、Library、接続サービス | 指定したローカルフォルダ |
| 別端末との同期 | Web・モバイル・デスクトップ間で同期 | 原則として同期されない |
| パソコンの電源 | 処理中に閉じても継続可能 | タスクによっては電源とアプリ起動が必要 |
OpenAIの公式説明でも、クラウドWorkチャットは端末間で同期する一方、ローカルチャットはパソコン上に残ると区別されています。
また、ローカルファイルと出力も、明示的に移動・共有しない限り、そのパソコンに残ります。(OpenAI Help Center)
クラウドタスクの例
添付資料をアップロードして、次のように依頼するケースです。
添付したPDFを分析し、A4で5ページ程度の報告書を作成してください。
Word形式とPDF形式で出力してください。この場合は、おおむね次の流れです。
ChatGPTへ資料をアップロード
↓
クラウド上のWorkが分析
↓
Word・PDFを作成
↓
会話画面またはLibraryから取得クラウドWorkで作成したファイルは、利用できる環境ではLibraryに保存される場合があります。(OpenAI Help Center)
ローカルタスクの例
デスクトップアプリでMac上のフォルダを開き、次のように依頼するケースです。
このフォルダにある3つのPDFを分析してください。
分析結果を「調査報告書.docx」と
「調査報告書.pdf」で同じフォルダに保存してください。この場合は次の流れです。
Macのローカルフォルダを開く
↓
Workにフォルダへのアクセスを許可
↓
フォルダ内の資料を読み取る
↓
報告書を作成
↓
Macのフォルダに保存
これはローカルWorkタスクです。
作成されたファイルは自動的にLibraryやWeb版へ表示されるとは限りません。(OpenAI Help Center)
スケジュール実行にも2種類ある
「毎週月曜日に報告書を作る」といったスケジュールタスクも、クラウドとローカルに分かれます。
クラウドのスケジュールタスク
Web版で作成し、次のような情報を使います。
- アップロード済みファイル
- 接続したGoogle Drive
- GmailやSlackなどのプラグイン
- Web上の情報
パソコンが停止していても実行できますが、パソコン内のフォルダを直接操作することはできません。(OpenAI Developers)
ローカルのスケジュールタスク
デスクトップアプリでローカルプロジェクトを対象に設定します。
毎週日曜日の午後11時に、
このフォルダのCSVを集計し、
weekly_report.xlsxを更新するこの場合はMacやWindows上で動くため、パソコンの電源が入り、ChatGPTデスクトップアプリが動いている必要があります。(OpenAI Developers)
「ローカル」の意味に関する注意
ここでいう「ローカルタスク」は、
- ローカルフォルダを作業対象にする
- 出力をローカルフォルダに保存する
- チャットや作業状態がそのパソコンに残る
という意味です。
AIモデルそのものがMacのCPUやGPUだけで動く、という意味ではありません。
OllamaやLM Studioのような完全なローカルLLM実行とは別です。
したがって、引用された記述は次の章に置くのが正確です。
Workの実行方法
├─ クラウドWorkタスク
│ ├─ Web・モバイル・デスクトップ
│ ├─ アップロード資料や接続サービスを使用
│ └─ 回答画面・Libraryなどへ出力
│
└─ ローカルWorkタスク
├─ デスクトップアプリ限定
├─ Mac・Windowsのフォルダを使用
└─ ローカルフォルダへ出力つまり、「ローカルフォルダを開き、そのフォルダにファイルを作る」という説明は、クラウドタスクではなくローカルタスクの説明です。
報告書作成の入力例
たとえば、Workに資料を添付して、次のように依頼します。
添付した3つのPDFをもとに、内容を整理した報告書を作成してください。
目的：
ブログ記事を作成する前の調査資料として使用します。
対象読者：
専門知識のない一般ユーザー
構成：
1. 調査の目的
2. 各資料の概要
3. 共通している内容
4. 資料間で異なる内容
5. 重要なポイント
6. 結論
7. 出典一覧
条件：
・日本語で作成
・A4で5ページ程度
・表を1つ以上入れる
・資料に記載されていないことは推測しない
・引用元の資料名とページ番号を記載する
・Word形式とPDF形式で作成する
完成したファイルは、ダウンロードできる形で出力してください。この場合の処理は次のイメージです。
| 段階 | 内容 |
|---|---|
| 入力 | 添付PDF3点と作成条件 |
| 処理 | 読み取り、比較、要約、構成、文章化、表作成 |
| 出力 | 回答画面の説明、Word、PDF、Libraryへの保存 |
今すぐ実行するWorkとは、起動方法が異なるスケジュール済みタスクもある
Workには、指定した日時や条件でクラウド上から実行するスケジュール済みタスクもあります。
こちらは次のような用途です。
- 毎朝Webサイトを確認して変更点を報告する
- 毎週Slackの新着内容をまとめる
- 商品が在庫ありになったときだけ通知する
- 新しいメールを確認して資料を更新する
- 毎月、接続されたデータから定例報告を作る
スケジュール済みタスクでは、回答は関連するタスクのチャットに記録され、プッシュ通知やメール通知を受け取れます。
接続アプリが許可されていれば、Gmailなどの情報を読み取ったり、対応する操作を実行したりできます。(OpenAI Help Center)
スケジュール済みタスク
あらかじめ指示と実行条件を登録
↓
指定日時・繰り返し・変化検出で自動開始
↓
結果をチャットや通知で返すスケジュール済みタスクは、将来の日時、定期的なスケジュール、トリガー、変更監視によってWorkを自動実行する仕組みです。(OpenAI Help Center)
なお、Scheduled Taskには、プロジェクト内の添付ファイルへアクセスできないという制限があります。そのため、「今添付した資料から今すぐ報告書を作る」は通常のクラウドWork向きで、「毎週同じプロジェクト資料を読み直す」はそのままでは実行できません。(OpenAI Help Center)
クラウドで実行されるスケジュール済みタスクと、ローカルで実行されるスケジュール済みタスクの違い・使い分け要領を説明してください
使い分けの基準は、パソコン内のファイルを直接扱う必要があるかです。
| 項目 | クラウドのスケジュール済みタスク | ローカルのスケジュール済みタスク |
|---|---|---|
| 実行場所 | ChatGPTのクラウド | デスクトップアプリからローカルプロジェクトを操作 |
| PCの電源 | 原則不要 | 電源オン・アプリ起動が必要 |
| 主な入力 | Web情報、接続アプリ、タスクに登録した情報 | Mac・Windows内のフォルダやファイル |
| 主な出力 | Scheduled画面、チャット、通知、接続サービス | ローカルフォルダ内のファイル |
| 向く用途 | ニュース収集、在庫監視、定期通知、メール要約 | CSV集計、ローカル資料の更新、プログラム実行 |
クラウドタスクは、パソコン内のフォルダを直接参照できません。
一方、ローカルタスクは指定したプロジェクトフォルダやGitのworktreeで動作するため、実行時にパソコンとChatGPTデスクトップアプリが動いている必要があります。(OpenAI Developers)
使い分け例
毎朝、CarPlayの最新ニュースを検索して通知
→ クラウド
毎晩、Mac内のCSVを集計してExcelを更新
→ ローカルなお、「ローカル」はファイルの読み書きや実行環境がパソコン側という意味で、AIモデル自体がMacだけで動くという意味ではありません。
添付資料についての重要な制限
現在のスケジュール済みタスクは、ファイルが登録されたプロジェクト内で作成しても、そのプロジェクトのファイルにはアクセスできません。(OpenAI Help Center)
したがって、次の2つは扱いが異なります。
| 依頼 | 適性 |
|---|---|
| 添付資料を毎週読み直して報告書を作る | 現状ではプロジェクト添付だけに依存しない構成が必要 |
| Google Drive上の更新資料から毎週報告書を作る | 接続アプリ対応なら実現しやすい |
| Webサイトを毎日確認して報告する | スケジュール済みタスクが適する |
クラウドブラウザータスクとの違い
「クラウドタスク」がクラウドブラウザータスクを指している場合は、主目的がファイル作成ではなく、公開Webサイト上での調査や操作です。
入力は、調べるWebサイト、商品名、条件、希望する結果などです。
クラウドブラウザーは公開ページを移動し、在庫確認、料金比較、フライト検索などを実行します。
処理は会話を離れても継続できます。(OpenAI Help Center)
ただし、提供開始時点では、サイトへのサインインや支払いには対応していません。
「添付資料を入力し報告書を作成してダウンロードする」という例に当てはめると
「添付資料を入力し、報告書を作成してダウンロードする」は、次の分類になります。
Work
└─ 1回限りのクラウドWorkタスク
├─ 入力：添付資料＋作成指示
├─ 処理：読み取り・分析・構成・ファイル作成
└─ 出力：回答画面＋LibraryのWord／PDF一方、毎週や毎月、自動的に新しい情報を集めて報告書を更新する場合は、次の構成になります。
スケジュール済みタスク
├─ 入力：実行指示＋スケジュール＋接続アプリやWeb
├─ 処理：新着確認・分析・既存成果物の更新
└─ 出力：タスクのチャット、通知、接続先の文書などつまり、単発の資料作成は通常のWork、定期更新や監視はスケジュール済みタスクと考えると分かりやすいです。
WorkとCodexの詳細比較
下表では各判断項目ごとに「Work向き／Codex向き／併用向き」を具体例付きで整理しています。
Work／Codex判断一覧
| 判断項目 | Workが適している場合 | Codexが適している場合 | 併用が適している場合 |
|---|---|---|---|
| 最終成果物 | Word、Excel、PowerPoint、PDFなどを、見栄えよく完成させて共有したい | コード、設定ファイル、CSV、JSON、HTML、または厳密な仕様でOfficeファイルを生成したい | Codexでデータ処理・検証し、Workで読みやすい報告書やスライドに仕上げる |
| 入力元 | Google Drive、Slack、Gmail、SharePoint、Webなど複数の業務情報源を横断する | ローカルフォルダ、Git、Home Assistant、LAN内API、データベース、ターミナル出力を扱う | Codexでローカル情報を集計し、Workでクラウド資料と統合する |
| ファイル追加 | 会話やプロジェクトのSourcesへ資料を順次アップロードしたい | 作業フォルダへファイルを追加し、パスを指定して一括処理したい | Workへ参考資料を追加し、Codexへ処理対象データを配置する |
| 目視確認・注釈修正 | スライド、表、文章、グラフを画面で確認し、該当箇所を指して修正したい | ファイル内容、差分、数式、データ構造、テスト結果を確認したい | 内容・計算はCodex、表現・レイアウトはWorkで確認する |
| ローカル環境 | ローカルアプリやファイルを使うが、技術的な操作は（エージェントに）任せたい | ターミナル、Git、Python、Node.js、シェル、ローカルAPIを直接使う | Codexでローカル処理を実行し、Workで成果物をレビューする |
| 定期実行・監視 | Slack、Drive、Webなどをクラウドで定期確認し、PC停止中も継続したい | Home Assistant、LAN機器、ローカルファイル、スクリプトを定期処理したい | Codexでローカル監視し、Workで定期レポートを生成する |
| 正確な検証 | 人が読んで判断する報告書・比較表としての妥当性を確認したい | テスト、再実行、差分比較、数式検証、スキーマ検証が必要 | Codexで検証済みデータを作り、Workで意思決定資料にする |
| 再現性 | 毎回同じ形式の成果物が得られればよく、内部手順は任せたい | 同じ入力から同じ処理を再実行できるスクリプトやパイプラインが必要 | Codexでテンプレート生成処理を作り、Workで最終調整する |
| 外部サービスへの送信・更新 | Gmail送信、Slack投稿、カレンダー登録、Drive更新などの業務操作 | GitHub Push、PR、API更新、Home Assistant操作、サーバー処理 | Codexでデータを作り、Workで人間向けの送信内容を作成・承認する |
| 重要操作の承認 | 送信、共有、予定登録など、業務上の影響を確認したい | コマンド、ネット接続、範囲外書き込み、削除などを確認したい | Codexで技術処理を承認し、Workで公開・送信を別途承認する |
| クラウド継続 | PCを閉じても継続し、Webやモバイルから確認したい | Codex Cloudでリポジトリ作業を継続したい | ローカル処理はCodex、PC停止中の調査・報告はWork Cloud |
| 複数セッション | 同じプロジェクトのSourcesを共有して、報告書・表・スライドを並行作成する | 複数の実装を別Worktreeやブランチで並行処理する | Workで企画・資料作成、Codexで技術タスクを並行処理する |
| 途中経過 | 調査・分析・資料作成の進み具合を成果物中心に確認したい | コマンド、変更ファイル、Git差分、テスト結果まで確認したい | Workで全体進捗、Codexで技術的な進捗を確認する |
| ツール確認 | Sources、プラグイン、コネクタを画面上で選びたい | MCP、スキル、作業フォルダ、Git、権限を厳密に管理したい | 共通プラグインを使いつつ、Codexだけローカル拡張を追加する |
| 画像生成 | プレゼンや報告書へ入れる画像を作り、画面上で選びたい | Web素材、UIアセット、アイコンなどを指定パスへ保存したい | Workで方向性を決め、Codexでファイル名・サイズ・配置を管理する |
| ユーザーの関与 | 完成条件を伝え、途中の細かい判断はエージェントへ任せたい | 計画・実装・テストを段階ごとに管理したい | Workへ成果物を委任し、技術的な難所だけCodexへ分離する |
Workは、Officeファイルを作成するものという認識しかなかったが、WorkとCodexを比較する今回の詳細調査により、下記の多くの違いを確認することができた。
・生成に適する最終成果物が異なる（コード、設定ファル、CSV、JSON、HTMLなどはCodex特有の成果物）
・入手元が異なる
・使用するファイルの保管場所が異なる
・成果物の確認要領・修正要領が異なる
・検証要領が異なる（workは成果物の内容を人が確認、Codexはテストなどによって検証する）
・外部サービス操作内容が異なる（workは業務操作、CodexはGit更新などの操作）
・承認内容が異なる
（workは業務に影響する「公開・送信」などの承認を要求、Codexはコマンドなどの技術処理の承認を要求）
・共有ファイルが異なる
・確認できる進捗内容が異なる
・ツールの確認要領が異なる
・ユーザーの関与の程度が異なる（workでは細かい判断はエージェント任せ、Codexでは段階ごとにユーザーが判断）
成果物別の簡易判断
下表では「どちらでも可能」な場合も含め、操作性・再現性・確認方法から第一候補を示します。
| 成果物 | 第一候補 | Codexを選ぶ条件 |
|---|---|---|
| Word報告書 | Work | 大量生成、テンプレート厳守、自動化が必要 |
| Excel比較表 | Work | 複雑な数式、データ検証、再生成処理が必要 |
| PowerPoint | Work | スクリプトで大量生成、Git管理したい |
| Work | HTMLやデータから定期的に自動生成したい | |
| 画像 | Work | Web・アプリ用アセットとしてファイル管理したい |
| CSV・JSON | Codex | Workで分析し、人間向け資料に変換したい場合は併用 |
| Webサイト | Codex | 内容・構成検討をWork、実装をCodexに分ける |
| プログラム | Codex | 仕様書や利用者向け資料をWorkで作る場合は併用 |
| Home Assistant設定 | Codex | 状態をまとめた報告書だけWorkで作る |
| 定期レポート | 入力元による | クラウド情報はWork、ローカル／LAN情報はCodex |
最短の判断基準
- 「完成した資料を受け取り、画面で確認・修正したい」→ Work
- 「ローカル環境で正確に処理し、テスト・再実行したい」→ Codex
- 「正確なデータ処理と、見栄えのよい成果物の両方が必要」→ Codex＋Work
- 「PCを閉じても業務情報を定期確認したい」→ Work Cloud
- 「Home AssistantやLAN内機器を監視したい」→ Codex
Officeファイルの生成自体は両方可能なので、「ファイル形式」だけではなく、プレビュー中心か、処理・検証・自動化中心かで判断するのが最も確実です。
ファイルを追加する
Workでは、作業途中に文書、表計算、プレゼンテーション、PDF、画像などを添付し、それらを調査・比較・変換・成果物作成に利用できます。
ChatGPTプロジェクトに追加したファイルは、同じプロジェクト内の関連チャットから利用できます。
Codexもファイルを扱えます。
特に、ローカルフォルダやリポジトリ内の大量ファイルを検索し、複数ファイルを一括編集する作業が得意です。
判断基準は、「アップロードできるか」ではありません。
- 人が選んだ資料を追加しながら成果物を仕上げる：Work
- ローカルにある大量ファイルを横断検索・変換する：Codex
- プロジェクト資料とローカルデータの両方が必要：併用
生成物を目視確認する
ChatGPTデスクトップアプリは、生成した文書、プレゼンテーション、表計算、PDFをチャットの横でプレビューできます。プレビュー上の特定箇所に注釈を付けて、修正を依頼することもできます。
Workの大きな利点は、この「完成品を見ながら直す」流れです。
Codex CLIには、Officeファイル専用のビジュアルプレビューや注釈画面がありません。
Codexデスクトップアプリでは生成物を表示・確認できる機能が増えていますが、Codexの中心は差分、コード、ログ、テスト結果などの技術的な確認です。
Officeファイルの作成可否では両者を分けられません。
目視確認と注釈修正を作業の中心にするならWork、生成工程と検証結果を中心にするならCodexです。
詳細は、Work with filesを参照してください。
重要な操作の承認
Workは、接続サービスへの書き込み、共有、送信、公開などの重要な操作について、人による承認を挟めます。
許可の単位は、プラグイン、接続先、ワークスペースポリシーによって異なります。
Codexでは、承認に加えてサンドボックスという考え方があります。
- 承認：その操作を実行してよいか
- サンドボックス：どのファイル、ネットワーク、コマンドへアクセスできるか
WorkのWeb版は管理された隔離環境でコードやシェルを実行しますが、ローカルCodexのサンドボックスや承認モードをそのまま公開しているわけではありません。
デスクトップ版では、WorkとCodexのどちらでもローカルアプリやBrowserを操作できる場合がありますが、ファイル、シェル、アプリ操作にはそれぞれの権限設定が適用されます。
したがって、非技術ユーザーが成果物作成の途中で重要操作を確認するならWorkが分かりやすく、技術者がファイル変更やコマンド実行の範囲を細かく制御するならCodexが向いています。
workは、送信、共有、予定登録などの承認を取るのに対し、Codexはコマンド、ネット接続、範囲外書き込み、削除などの、技術処理の承認をとる。
複数セッションを整理する
Workでは、ChatGPTプロジェクト内に関連資料、指示、ChatとWorkの会話をまとめられます。
成果物ごとに会話を分け、よく使う会話をピン留めする運用が適しています。
Codexでは、ローカルプロジェクト、ブランチ、Gitワークツリー、タスクを基準に整理できます。
同じリポジトリで複数の作業を並行するときは、ワークツリーを分けることでファイル変更の衝突を避けられます。
- 「営業会議資料」「市場調査報告書」のように成果物で分ける：Work
- 「バグ修正」「機能追加」「コードレビュー」のように変更単位で分ける：Codex
詳細な途中経過を確認する
Workは、進捗、質問、承認待ち、成果物のプレビューを非技術的な形で確認しやすく設計されています。
Codexは、次のような詳細を確認しやすい環境です。
- 実行したコマンド
- 編集したファイル
- Git差分
- テスト結果
- 標準出力とエラー
- ブランチやワークツリーの状態
Workでも進捗は確認できますが、技術的な実行ログを常にCodexと同じ粒度で表示するわけではありません。
完成品を中心に確認するか、処理の再現性を中心に確認するかで選びます。
利用するツールとプロジェクトコンテキスト
WorkとCodexは、同じプラグインディレクトリから公開プラグインを利用できます。
Google Drive、Gmail、Slack、GitHubなどの接続先は、プラン、インストール状況、認証、管理者設定によって利用可否が決まります。
ただし、コンテキストの置き場所が異なります。
| コンテキスト | Work | Codex |
|---|---|---|
| 会話の添付ファイル | 得意 | 利用可能 |
| ChatGPTプロジェクトの資料 | 得意 | ChatGPT側とは管理系統が異なる |
| ローカルフォルダ | デスクトップで許可された場合に利用 | 中心的な作業対象 |
| リポジトリ、Git履歴 | 補助的 | 得意 |
| AGENTS.md | ローカル作業では関係する場合がある | 継続的なプロジェクト指示の中心 |
| MCP | 利用可能なプラグイン・環境経由 | config.tomlなどで詳細に構成可能 |
| スキル | Work、Codex、定期タスクで利用可能 | ローカル資産やスクリプトを含む再利用に強い |
「MCPやスキルはCodex専用」「コネクタはWork専用」という分け方ではありません。
両方で使えるものが増えていますが、Codexのほうがローカル設定や実行環境を細かく確認しやすいという違いがあります。
画像生成ツール
Workでは、画像を生成し、そのままスライド、文書、Siteなどの成果物に組み込む流れが自然です。
完成品を見ながら「この画像を明るくする」「別の構図にする」と修正できます。
Codexでも画像生成や画像編集ツールを利用できます。
生成した画像をローカルファイルとして保存し、Webサイト、アプリ、ドキュメントなどへ組み込んで検証する作業に向いています。
画像生成そのものの能力よりも、その後の工程で選びます。
- 画像をプレゼンテーションや資料の一部として仕上げる：Work
- 画像をアプリやリポジトリの資産として管理する：Codex
なお、画像生成にはエージェント枠とは別の利用制限が適用される場合があります。
エージェント利用枠と画像生成枠を同じものとして扱わないよう注意が必要です。
出力できるファイル形式
Workは、文書、表計算、プレゼンテーション、PDF、レポート、Siteなど、完成成果物を明示的に作る用途として案内されています。
Codexも、利用可能なライブラリやツールを使ってWord、Excel、PowerPoint、PDF、画像、CSV、JSON、HTMLなどを作成できます。
さらに、ソースコード、設定ファイル、テスト、ログ、差分なども同じ作業ディレクトリに残せます。
違いは対応形式よりも、成果物の確認方法です。
| 重視するもの | 推奨 |
|---|---|
| 完成ファイルを画面で開き、見た目を修正したい | Work |
| 生成処理をスクリプト化し、同じ結果を再生成したい | Codex |
| 見た目と再現性の両方が必要 | Codexで生成・検証し、Workでレビュー |
Codexで段階的に依頼できるのに、Workを使うメリットは何か
Codexでも、プランモードで工程を決め、資料を読み、Officeファイルを生成し、目視確認と修正を順番に進められます。
それでもWorkを使うメリットは、作業の中心が最初から「人が確認して使える成果物」に置かれていることです。
Workのメリット
- 複数資料の収集から完成品までを一つの作業として扱いやすい
- 文書、表、スライド、PDFをプレビューしながら修正しやすい
- 注釈で修正箇所を直接示しやすい
- 技術的なログより、進捗、判断、成果物を優先して表示する
- クラウドWorkなら、アプリを閉じた後も処理を継続できる
- Web、モバイル、デスクトップ間でクラウドWorkの会話を継続できる
- プロジェクト資料や接続サービスを成果物中心に扱いやすい
Codexのメリット
- ローカルファイル、フォルダ、リポジトリを直接扱いやすい
- Git差分、コマンド、テスト、ログを確認できる
- スクリプトによって成果物を再生成できる
- 定型処理をスキル、MCP、フック、定期タスクへ発展させやすい
- Home Assistantなどローカルシステムと連携しやすい
- 作成した成果物だけでなく、生成過程や検証手順も保存できる
WorkはCodexの簡易版ではなく、CodexもWorkの代用品ではありません。
両者は共通のエージェント技術を使いながら、作業を見せる相手と管理単位が異なります。
依頼内容別：どれを選べばよいか
| 依頼例 | 推奨 | 理由 |
|---|---|---|
| 会議資料からPowerPointを作る | Work | スライドの目視確認と反復修正が中心 |
| Excel集計表とグラフを作る | Work寄り | 表やグラフを確認しながら直しやすい |
| 大量CSVをスクリプトで処理する | Codex | 再現性、速度、検証を確保しやすい |
| Web調査からWord報告書を作る | Work | 調査から完成品まで一体化しやすい |
| アプリを修正してテストする | Codex | コード、Git、ターミナルが中心 |
| Home Assistantを監視・変更する | Codex | ローカル接続、設定、ログ、定期処理が必要 |
| 毎週の定期レポートを作る | 併用 | Codexで収集・検証し、Workで仕上げる |
| 技術資料から経営向けスライドを作る | 併用 | 技術的正確性と伝わりやすい見た目を分担できる |
| 文章の言い換えを数行だけ依頼する | 通常のチャット | Workを使うほど工程が多くない |
| 複数サービスから情報を集めて報告書を作る | Work寄り | プラグインと成果物作成を一つの流れにしやすい |
WorkとCodexを併用する3つの実践パターン
パターン1：Codexで収集・検証し、Workで仕上げる
- CodexでWeb、API、CSV、ログ、ローカルファイルから情報を集める
- 数値を検証し、出典と処理条件を記録する
- 中間データをCSV、Markdown、JSONなどで保存する
- Workへ中間データと構成指示を渡す
- WorkでWord、Excel、PowerPoint、PDFとして仕上げる
- プレビューへ注釈を付けて最終修正する
定期レポート、調査報告書、経営会議資料などに向いています。
パターン2：Workで構成を作り、Codexで検証する
- Workで読者、目的、構成、デザインを決める
- Workで成果物の初稿を作る
- Codexへ数値、引用、計算式、コード例を渡して検証する
- 検証結果をWorkへ戻す
- Workで最終版へ反映する
見た目を先に固めたい企画書や提案資料に向いています。
パターン3：Codexで監視し、必要なときだけWorkを使う
- Codexの定期タスクやローカルスクリプトで状態を監視する
- 変化、異常、期限到来などを検出する
- 監視結果を構造化データとして保存する
- 必要な場合だけWorkタスクを作り、報告書やスライドを生成する
- Home Assistant、メール、Slackなどへ完了情報を通知する
監視とOfficeファイル生成を常に同じタスクで行うより、変化があったときだけ成果物を作るほうが、利用枠を節約しやすくなります。
Codexとworkの併用という考えも有効だと考えるが、連携環境の構築が容易かどうかまで確認する必要がありそう。
WorkタスクをCodexで常時監視できるか
workのタスクは、監視対象として取得できる項目が少なく、Codexのタスクのような情報は取得できないことは、以前のブログ記事でも確認済みだが、Codexで起動したWorkタスク（ただしクラウドタスク）はCodexがそのタスクの情報をより多く取得できるとのことだったので、それについても再度確認する。
結論は、監視対象として取得できる状態情報によるです。
Workが画面上で進捗を表示していても、その状態が外部API、ローカルファイル、MCPツールなどから読み取れるとは限りません。
正確に監視しやすいケース
- CodexからWorkタスクを作成し、タスクIDが返される
- そのIDに対する状態取得機能が継続して利用できる
- 完了、失敗、承認待ちなどの状態が構造化データとして返される
- 定期タスクとして作成し、「Scheduled」で実行履歴を確認できる
- Enterpriseの管理APIなど、契約上利用できる監査・分析機能がある
正確な監視が難しいケース
- 手動でWork画面から始めたタスクに、外部から参照できるIDがない
- 状態がChatGPT画面内にしか表示されない
- セッションの内部進捗がAPIとして公開されていない
- 利用枠到達、承認待ち、エラーの状態形式が統一されていない
2026年7月時点で、一般ユーザー向けに、すべてのWorkタスクの詳細状態をHome Assistantから取得できる公開APIは公式文書で確認できませんでした。
そのため、外部ダッシュボードで「正確な進捗率」まで常時監視できるとは断定できません。
実際の監視方法は、次の優先順位になります。
- 公式のタスクID・状態取得機能
- Scheduledの実行状態と履歴
- 完了通知やアプリ内通知
- Codexが管理する中間ステータスファイル
- 最終手段として画面監視
Home Assistantへ表示するなら、Work内部の進捗率を推測するより、Codex側で次の状態を管理するほうが現実的です。
queued：開始待ちrunning：処理中needs_approval：承認待ちcompleted：完了failed：失敗limit_reached：利用枠到達unknown：状態取得不能
unknownを用意することが重要です。
取得できない状態を「実行中」や「完了」と推測すると、ダッシュボードの信頼性が失われます。
定期タスクについては、Scheduled tasksで、作成、実行履歴、通知、チャット内での継続方法を確認できます。
WorkとCodexのエージェント利用枠
WorkとCodexは、同じエージェント利用枠とクレジットプールを共有します。
対象プランでは、ChatGPT for ExcelやWorkspace Agentsも同じプールを使います。
そのため、利用状況画面に5時間枠や7日枠が表示されているアカウントでは、Workを使うとCodex側の残量にも影響します。ただし、すべてのプランで同じ時間窓や同じ上限値が設定されているとは限りません。
自分のアカウントに表示されるUsage画面を正確な基準にしてください。
詳細は、Using Codex with your ChatGPT planおよびCodex rate cardで確認できます。
5時間枠でOfficeファイルを何個作れるのか
ファイル数による固定上限はありません。消費量は主に次の条件で変わります。
- 使用モデル
- 推論レベル
- 読み込む資料の量
- 入力、キャッシュ入力、出力トークン
- 表、グラフ、画像の数
- Web検索やプラグインの利用
- 修正回数
- 単一エージェントか、複数のサブエージェントか
公式の参考値では、GPT-5.5を使った一般的なChatGPT for Excel／Sheetsタスクは5～20クレジット、PowerPointタスクは10～50クレジット程度とされています。
ただし、これはWork全体の保証値ではなく、5時間枠をファイル数へ直接換算できる数字でもありません。
最も現実的なのは、代表的な作業を1件実行し、前後の利用メーターを比較する方法です。
作成可能数の概算 ＝ 残り利用率 ÷ 代表タスク1件の消費率たとえば、同じ形式のプレゼンテーション1件で5時間枠を8％消費した場合、単純計算では約12件です。
ただし、資料量や修正回数の変動に備え、20～30％程度の余裕を見ます。
クレジットの参考値は、Using Credits for Flexible Usage in ChatGPTで確認できます。
上限に達したときの挙動
| 状況 | 主な挙動 |
|---|---|
| 個人プランの含有枠を使い切った | 利用可能なら追加クレジット、リセット、アップグレード、リセット待ちなどが表示される |
| 追加クレジットを保有している | 含有枠の後に共有クレジット残高から消費される場合がある |
| Codexの実行中に上限へ到達 | 公平利用制限の範囲で、そのターンを継続できる場合がある |
| Businessで枠とクレジットを使い切った | バナーが表示され、機能がブロックされる。管理者への追加要求が可能 |
| Enterprise／Eduで共有プールを使い切った | 超過利用が有効でなければ対象機能が一時停止する |
Codexについては、実行中のターンで上限へ達しても、そのターンを継続できる場合があると公式に説明されています。
ただし、Workのすべての処理が必ず完了するという保証ではありません。
長い資料作成では、中間成果物を保存しながら進めるのが安全です。
通知については、個人プランではUsage画面やアプリ内の上限バナーが中心です。
個人プランの上限到達時に、必ずメールやプッシュ通知が届くとは公式に案内されていません。
Businessでは製品内バナー、Enterprise／Eduでは設定されたしきい値に応じた管理者向けメールや製品内通知を利用できます。
詳しくは、Flexible pricing for Enterprise, Edu, and Businessを参照してください。
APIキーを使う場合
ChatGPTアカウントでCodexを利用する場合と、APIキーでCodex CLI、SDK、IDE拡張を利用する場合は、課金の考え方が異なります。
- ChatGPTログイン：プランの共有エージェント枠と追加クレジット
- APIキー：APIで使用したトークンに応じた従量課金
APIキー利用には、ChatGPT上のWorkやクラウド機能が自動的に含まれるわけではありません。
サブスクリプション枠とAPI利用料金を混同しないよう注意してください。
（ChatGPT-5.6 Solへの質問）
ChatGPTのworkは、APIで利用できますか
結論
個人向けChatGPTの「Work」を、そのまま通常のOpenAI APIから呼び出すことはできません。
たとえば、次のようなAPIは用意されていません。
POST /v1/workChatGPT Workは、複数ステップの調査・分析や、文書、表計算、プレゼンテーションなどの完成物を作成するためのChatGPT内の実行環境です。
通常のOpenAI APIとは別の製品として提供されています。
現在のPlusプランの場合
あなたが現在利用しているChatGPT Plusでは、画面からWorkを利用できますが、Workを外部プログラムから直接呼び出すAPIは利用できません。
また、ChatGPT Plusの利用料金とOpenAI APIの料金は別です。
APIを利用する場合は、API Platform側でAPIキーを作成し、従量課金で利用します。
ChatGPTのワークスペースとAPI Platformの組織も別々に管理されています。
例外：Business／EnterpriseのWorkspace Agents
ChatGPT BusinessまたはEnterpriseでは、Workに近い処理を「Workspace Agent」として保存し、外部システムからAPIで起動できます。
公式ドキュメントでは、Workspace AgentをAPIトリガーから実行できると案内されています。
よくある誤解
WorkならOfficeファイルを無制限に作れる
誤りです。
ファイル作成数ではなく、タスクの処理量に応じて共有エージェント枠やクレジットを消費します。
ファイルアップロードや画像生成には別の上限が適用される場合もあります。
CodexではOfficeファイルを作れない
誤りです。
Codexでも必要なツールやライブラリがあれば、Word、Excel、PowerPoint、PDFなどを作成できます。
違いは主にプレビュー、注釈、実行ログ、再現性です。
WorkとCodexは別々の利用枠である
誤りです。
利用可能なプランでは、WorkとCodexは同じエージェント利用枠とクレジットプールを共有します。
チャットから依頼すれば、必ず独立タスクになる
誤りです。
現在の会話でツールを使うことと、新しいタスクやスレッドを作ることは別です。
独立タスクにしたい場合は、「別のWorkタスクを作成」「新しいCodexタスクとして開始」などと明示します。
Workタスクは必ずCodexから監視できる
誤りです。
タスクIDと状態取得機能が利用できる場合（Codexからworkのクラウドタスクを起動した場合など）、クラウドは追跡できますが、一般向けの公開状態APIが確認できないタスクを外部から正確に監視することはできません。
処理中に利用枠へ達しても、必ず最後まで完了する
誤りです。
Codexでは実行中のターンを継続できる場合がありますが、公平利用制限があり、Workを含むあらゆる長時間処理の完了が保証されるわけではありません。
同じプロジェクトなら、すべての情報が自動共有される
注意が必要です。
ChatGPTプロジェクトではファイル、指示、接続元などを関連チャットで共有できますが、個々の会話内容、権限、ツールの状態が無条件ですべて共有されるわけではありません。
CodexのローカルプロジェクトとChatGPTプロジェクトも同じ管理単位ではありません。
迷ったときのチェックリスト
次の質問に上から答えると、Codexかworkかを選びやすくなります。
- 最終成果物は、回答だけか、完成ファイルか、コードや設定か
- 入力元は、添付資料か、Google DriveやSlackか、ローカルフォルダか
- 文書、表、スライドを画面で見ながら修正したいか
- Git、ターミナル、テスト、ログを使うか
- 同じ処理を再現・再実行する必要があるか
- 外部サービスへ送信、更新、公開するか
- 定期実行や常時監視が必要か
- パソコンを閉じた後もクラウドで続けたいか
判断の基本ルールは次のとおりです。
- 相談や短い処理なら通常のチャット
- 完成成果物と目視修正を重視するならWork
- ローカル実行、コード、検証、監視を重視するならCodex
- 正確性と見栄えの両方が必要なら併用
まとめ
WorkとCodexは、できることが重なっています。Officeファイルを作るか、コードを書くかだけで分けると、本来の強みが見えません。
Workは、複数の資料やツールから情報を集め、文書、表、スライド、PDFなどの人がレビューして使う完成品を作るための体験です。
Codexは、ローカル環境、リポジトリ、ターミナル、Git、テスト、MCPなどを使い、処理を実行・検証・再現するための体験です。
通常のチャットで相談し、必要に応じてWorkまたはCodexへ作業を発展させるのが基本です。
さらに、Codexでデータ収集と検証を行い、Workで最終成果物を仕上げれば、正確性と見栄えを両立できます。
最後に、タスクの相互起動、利用可能なツール、クラウド同期、利用枠は変更される可能性があります。
実際の運用では、公式ドキュメントと自分のアカウントのUsage画面、デスクトップアプリの表示を確認してください。