OpenAIは2026年7月9日、ChatGPT Workを発表しました。あわせて、独立していたCodexアプリを新しいChatGPTデスクトップアプリへ統合し、Chat / Work / Codex の3モードが並ぶ構成へ移しています。
📑目次
この記事で先に押さえること
仕事の単位から読む
この記事の結論はシンプルです。ChatGPT Workは「質問に答えるチャット」ではなく、接続アプリとファイルを横断して完成成果物まで進める長時間エージェントです。一方、Codexは実装・テスト・レビュー向けのコーディングエージェントとして残ります。モデル更新ニュースとして読むより、仕事の単位とデスクトップUXの再配置として捉える方が実務判断につながります。
想定読者は、Codex / Claude Code / Cursor を使う開発者と、チーム導入を検討する担当者です。以下では役割分担、プラン別可用性、導入チェックリスト、権限境界を整理します。
ChatGPT Workが変える「仕事の単位」
Work向きの仕事を見分ける
結論から言うと、Workが変えるのは回答文の質だけではありません。目標を渡し、調査・分解・実行を進め、シート・スライド・ドキュメント・Sites（Webアプリ）などの完成物に寄せる点が中心です。
理由は、OpenAIの発表がWorkを「最も野心的な仕事のパートナー」として位置づけ、接続アプリとファイルを横断したコンテキスト収集、複数時間スケールの分解実行、途中での方向転換と重要操作の承認を前提にしているためです。動力源は同日ロールアウトのGPT-5.6ですが、本記事ではモデル詳細よりワークフロー変化を優先します。モデルの使い分け自体は別記事で扱えます。
具体例としては、次のような単位がWork向きです。
- Slackやメール、CRM、ドキュメントをまたいだ週次レポートや経営向けダッシュボード
- リリース計画・Jira・GTM資料を横断したローンチ準備チェック
- 競合調査をまとめた資料セットや、更新が続く社内ポータル（Sites）
逆に、単発の仕様確認や短い壁打ちはChatのままの方が負荷が低いです。実装・テスト・PRレビューはCodex側の作業単位に寄せる判断がしやすいです。
Scheduled TasksもWorkの運用を変えやすい機能です。一度きり、定期、イベント起点、監視型で作業を進め、離席中も進捗を維持できます。ただし「勝手に完了して終わる」前提ではなく、途中質問・方向転換・重要操作の承認を挟む設計が前提です。
実務で確認すること
再結論として、Work導入の最初の問いは「どのモデルか」ではなく、完成物まで任せたい仕事単位が既にあるかです。
デスクトップ統合後の Chat / Work / Codex
結論として、Codexアプリは消えず、新しいChatGPTデスクトップ（Mac / Windows）の中に専用コーディング体験として合流します。既存Codexユーザーは通常の更新経路で移行でき、Codexを既定ビューにしたり、Codexロゴをアプリアイコンにしたりできます。旧デスクトップはChatGPT Classicとして残る説明です。
3つの面を比較する
Help Centerの定義を実務向けに言い換えると、次の分担になります。
表を読む前に
| 面 | Chat | Work | Codex |
|---|---|---|---|
| 主な用途 | 質問・壁打ち・検索 | 調査から完成成果物まで | 実装・テスト・レビュー・リポジトリ作業 |
| Web / モバイル | あり | 有料プラン中心で段階ロールアウト | 選択モードとしては無し（Remoteで一部デスクトップ作業） |
| デスクトップ | Quick chat 等 | 権限付きでローカルファイル/アプリ利用可 | デスクトップのコーディングモード（Free含む全プラン） |
| 利用量の考え方 | 通常チャット | Codexと同系統。タスク複雑度で消費が増えやすい | コーディング利用枠/追加クレジット説明が基準 |
出典: OpenAI Help: ChatGPT Work and Codex、OpenAI発表、ChatGPT Learn What’s new（2026年7月時点）
{{screenshot: codex-10115-source-3-learn.chatgpt.com-4cc1e5ca693b.png | alt=ChatGPT LearnのWhat’s new画面。WorkとCodexデスクトップ統合の更新が掲載されている | caption=公式LearnドキュメントのWhat’s new。Work機能とCodexデスクトップ統合の位置づけを確認できる（2026年7月時点）}}
実務で確認すること
デスクトップ側で強調されているCodex能力には、差分内のインライン編集、サイドパネルでのPRレビュー、GPT-5.6によるComputer Useの高速化、複数リポジトリを1プロジェクトで扱う点が含まれます。コーディング専用アプリが消えるというより、入口がChatGPTデスクトップに寄せられたと理解する方が正確です。
ここで見落とすと痛い境界があります。
- Web/モバイルのWorkはクラウド上で動く
- デスクトップのWorkは、許可したローカルファイルとデスクトップアプリを使える
- ローンチ時点では、クラウドWorkの会話はデスクトップWorkに現れない
- デスクトップWorkのスレッドとローカルファイルはその端末側に残る
- Codexはデスクトップのモードであり、Web/モバイルで同じように選べない
- モバイルのRemoteから対応済みのデスクトップCodex作業に触れることはできるが、それがWeb/モバイルのチャット履歴になるわけではない
Chatの会話はWebとデスクトップで同期する一方、WorkとCodexは起動面ごとに履歴と成果物の置き場が分かれます。「同じ案件なのに画面が違う」ことが起きやすいので、プロジェクト単位で入口を固定する運用が安全です。
再結論として、統合は機能削除ではなく導線の再配置です。既存Codex利用者は「アプリが無くなる」より「どこで何を始めるか」を再設計する必要があります。
プラン別の可用性・利用制限・モデル選択
結論として、可用性は「全部同じ日に全員へ」ではありません。特にWeb/モバイルのWorkは有料プラン中心の段階ロールアウトです。
面ごとの提供状況
OpenAIの発表ベースでは、次のように整理できます。
- Web/モバイルのWork: Pro / Enterprise / Edu から開始し、その後数日でPlus / Businessへ拡大
- デスクトップの Chat / Work / Codex: Freeを含む全プランでグローバル提供（Mac / Windows）
- 利用量: Workはチャットより長く重い。Codexと同系統の利用構造で、タスク複雑度により消費が増えやすい
- Enterprise: Admin Consoleの利用量/支出コントロール（ワークスペース既定、グループ上限、個別上書き、理由付きクレジット申請）
モデル選択は、WorkやCodexの「動力」として短く押さえる程度で十分です。Learn docs上の目安は次の通りです。
モデル選択の考え方
| モデル | 位置づけ | 向きやすい用途 |
|---|---|---|
| Sol | 旗艦 | 複雑なコーディング、Computer Use、調査、セキュリティ作業 |
| Terra | バランス | 日常的な業務・実装 |
| Luna | 高速/低コスト寄り | 軽い反復、コスト優先の作業 |
| Power既定 | Sol + medium | 迷ったときの初期値 |
出典: GPT-5.6公式、ChatGPT Learn What’s new（2026年7月時点）
実務では、最初から最上位に固定せず、パイロットではTerraやPower既定で消費と品質を測り、詰まった工程だけSolへ上げる方が再現しやすいです。利用制限を「月間の残量」だけで見るのではなく、1タスクあたりの消費として記録する運用が重要です。
実務で確認すること
再結論として、プラン判断の要点は「FreeでもデスクトップCodexに触れられる」ことと、「長時間Workは有料ロールアウトと利用枠の影響を強く受ける」ことの両立です。
導入チェックリストと最初の1タスク設計
結論として、最初の成功は大きな自動化構想より、既知の繰り返し作業1本のパイロットで決まります。
振り分け基準
| 判定質問 | Yesなら | No / 迷いなら |
|---|---|---|
| 欲しいのは完成した資料・表・サイトか | Work | Chat または人手 |
| 欲しいのはコード変更・テスト・PRか | Codex | Workに寄せない |
| 複数アプリ横断の調査が必要か | Work | 単発Chat |
| ローカルリポジトリ操作が中心か | Codex（デスクトップ） | クラウドWork |
パイロット手順（30–90分）
- 候補作業を1つ選ぶ（週次レポート、依存更新PR、障害対応メモなど、既に手順が分かるもの）
- Work向き成果物か Codex向き実装かを上表で判定する
- 接続プラグインとローカルフォルダを最小権限で選ぶ
- 成功条件、禁止操作、承認が必要な操作を先に書く
- Scheduled Taskは、監視できる定型作業からだけ有効化する
- 30–90分で1本走らせ、成果物品質と利用消費を記録する
- 結果をチーム共有テンプレ（モード選択 / 権限 / 消費 / 失敗点）に残す
成功条件の書き方（例）
- 成果物: 「営業向け週次ダッシュボード1枚。未更新データは空欄にし、推測で埋めない」
- Codex: 「失敗テストを1件グリーンにするPR差分。無関係なリファクタ禁止」
- 承認ゲート: 「外部共有リンク作成、本番設定変更、顧客データエクスポートは実行前に停止」
失敗しやすい点
- ゴールが曖昧（「いい感じにまとめて」）
- アプリ接続が過剰で、誤操作時の影響範囲が広い
- クラウドWorkとデスクトップWork/Codexの会話分断を想定せず、同じ案件を複数面で同時に進める
- Scheduled Taskを監視なしで回し、途中の方向転換ができない
再結論として、読後の次アクションは次の3点に固定できます。
- 既知の繰り返し作業を1つ選ぶ
- Work向き成果物か Codex向き実装かを判定する
- 最小権限と承認ゲート付きで30–90分の試行を1本走らせ、結果と利用消費を記録する
権限・セキュリティ・運用上の注意点
公式の統制を確認する
結論として、WorkとCodexは便利さの裏側で、接続ツールとローカル権限の影響範囲が広がります。導入判断には機能一覧だけでなく、誰が何を承認するかが必要です。
公式発表が示す統制の方向性は次の通りです。
- Enterprise向けに、アクセス、会社コンテキスト、接続ツール、許可アクションの基盤を用意
- Compliance APIによるWork会話/アクションの可視化
- デスクトップはCodex由来のガバナンス（ローカルファイル、アプリ、ブラウザ、エージェントのネットワークポリシー）を拡張
- Auto-review: 接続ツール/APIに関わる重要操作を、実行前に高度なモデルがレビューし、意図しない機密共有を抑える
独立報道の運用リスク
- 独立報道（Ars Technica、Tech Times）も参照します。
公式機能一覧だけでは見えにくい運用リスクとして、次の点を確認します。
具体的には、接続面・利用消費・承認境界を導入前に確認します。
- Workはチャットより長く重く、Codexと同系統の利用構造で消費が増えやすい（「ウォレット注意」）
- 統合デスクトップでは、コーディングエージェント・内蔵ブラウザ・Computer Use・ライブプラグインが同じセッション/信頼境界に寄る
- 以前のクラウドCodexがマイクロVM境界を強めに取っていたのに対し、ホスト側ファイルや接続アプリへ届く面が広がる
- プロンプトインジェクションは完全解決が難しい前提で、悪意あるページ/メール経由の指示が複数システムへ波及しうる
- だから初日に全部つなぐのではなく、パイロットに必要な最小接続だけを許可する
個人利用でも、次のレビュー観点は入れておく価値があります。
- 共有してよいデータと、接続してはいけないフォルダ/メールボックス
- 外部送信・公開Sites・顧客データの取り扱い
- プラグイン追加の承認フロー（誰が入れられるか）
- パイロット期間中の利用量上限と、超過時の止め方
Atlasブラウザの段階的終了は、移行前提のUI変化として短く押さえておけば十分です。主問題はブラウザブランドではなく、エージェントが触れる面が増えたあとの境界設計です。
再結論として、権限設計は「全部つなぐ」ではなく、「最初の1タスクに必要な最小接続だけを許可し、承認ゲートを先に書く」が安全です。
よくある質問 (FAQ)
実務で確認すること
実務で確認すること
まとめ
ChatGPT Workは、チャット回答ではなく完成成果物まで進める長時間エージェントです。Codexは実装エージェントとしてデスクトップに残り、統合は導線の再配置です。可用性は面ごとに違い、特にクラウドWorkとデスクトップWork/Codexの履歴分断を先に設計する必要があります。
次にやることは1つです。既知の繰り返し作業を1本選び、WorkかCodexかを判定し、最小権限と承認ゲート付きで30–90分のパイロットを記録する。その結果をチームのモード選択テンプレに落とせば、モデルニュースに流されない導入判断ができます。
著者
krona23
IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。
コメントを残す