ChatGPTのデスクトップアプリを使っていると、少し不思議に感じることがあります。
「WorkモードとCodex、結局そんなにハードル変わらなくない?」
どちらも自然言語で指示できますし、ファイルを扱ったり、まとまった作業を任せたりできます。
以前なら「ChatGPTは一般ユーザー向け、Codexはエンジニア向け」というイメージが強かったかもしれません。しかし現在は、この分け方では実態に合わなくなってきています。
この記事では、ChatGPTのデスクトップアプリを日常的に使う前提で、WorkモードとCodexをどう使い分ければよいかを整理します。
結論:難易度ではなく「仕事を残すか」で分ける
最初に結論から書くと、次のように考えるのがいちばん分かりやすいと考えています。
残らない仕事はWork。残して育てる仕事はCodex。
もう少し言い換えると、こうなります。

- 考える・調べる・成果物を作る → Work
- 仕組みにする・自動化する・継続運用する → Codex
WorkとCodexの違いを「初心者向けか、上級者向けか」で考える必要は、かなり薄くなっています。重要なのは、AIに今回の仕事をしてもらいたいのか、それとも今後もその仕事をしてもらえる仕組みを作りたいのか、という違いです。
Workは「仕事そのもの」を依頼する場所
Workモードは、AIに「この仕事を完成させてください」とお願いするときに向いています。
- Webで競合を調査する
- PDFを読み込んで要約する
- データを分析する
- レポートや提案資料を作る
- 複数の情報源から情報を整理する
例えば「競合10社を調査して、自社との違いを整理し、経営会議用の資料を作って」という依頼なら、Workとの相性がよいでしょう。
重要なのは、最終的な成果物が欲しいという点です。調査の途中経過や作業環境そのものより、「最終的にちゃんとしたレポートや資料ができればいい」という仕事です。
Codexは「仕事の仕組み」を作る場所
一方のCodexは、成果物を1回作るだけではなく、その仕事を継続的に行える環境そのものを作る場所と考えると分かりやすくなります。
例えば「自社WebサイトのSEOを改善したい」という場合。今回だけWebサイトを分析して改善案を出してほしいのであれば、Workで十分です。
しかし、次のような流れを毎月回したいのであれば、Codexの領域になってきます。
- GA4とGoogle Search Consoleのデータを取得する
- アクセスが悪化したページを検出する
- 原因を分析する
- 改善案を生成する
- 課題として記録する
- 必要なら実際に修正する
つまりCodexでは、AIに仕事を依頼するというより、AIを仕事の現場に参加させるイメージに近くなります。
デスクトップアプリなら「Codexは難しい」がかなりなくなる
Codexという名前を聞くと、ターミナル、Git、プログラミング、開発環境といった言葉を想像して、難しそうに感じる方も多いと思います。
しかしChatGPTのデスクトップアプリから使う場合、操作の入口そのものはWorkとそれほど変わりません。基本的には「こうしてほしい」と自然言語で指示します。
もちろん、Gitやプログラミングを理解していれば、より細かな指示を出せます。ただ、Codexを使い始めるのに、仕組みを完全に理解している必要はありません。
そのため現在は「Workは簡単だけどCodexは難しい」というより、どこまで継続的な作業環境をAIに持たせるかの違いとして考えるほうが実態に合っています。
いちばん大きな違いは「フォルダに仕事が残る」こと
WorkとCodexの違いを最も大きく感じるのはここです。Codexでは、仕事のやり方そのものをフォルダに蓄積していけます。
GitHubやリポジトリといった開発者向けの管理を、最初から使う必要はありません。**1人で使うなら、パソコンの普通のフォルダで始められます。**チームで共有する段階になったら、そのフォルダをリポジトリ(変更履歴つきの共有フォルダ)としてGitHubなどで管理する形に進めばよい、という順番です。
例えば会社の業務を、次のようなフォルダで整理しておけます。
company-operations/
├─ marketing/ … 広告分析の方法
├─ sales/ … 営業資料のフォーマット
├─ finance/
├─ research/
├─ content/ … ブログを書くときのルール
├─ automation/ … 作業用スクリプト
├─ skills/ … 繰り返し使う手順書
└─ AGENTS.md … AIへの共通指示
ここに、デザインルール、セキュリティポリシー、過去の改善履歴などを蓄積していきます。するとAIとの仕事が、毎回ゼロから始まる会話ではなく、前回までの仕組みを引き継いだ会社の業務環境に変わっていきます。
当社も業務環境をリポジトリとして運用しています(構成は自社の業務に合わせて変えています)。運用の考え方は2026年7月時点のKOIYALのハーネスで紹介しています。
Workでうまくいった仕事をCodexへ「昇格」させる
ここからが、この記事でいちばんお伝えしたい部分です。
最初から「全部Codexで自動化しよう」とする必要はありません。おすすめは、まずWorkで仕事をしてみて、繰り返す価値があると分かった仕事だけCodexへ昇格させる方法です。
Workで業務を試す → Codexで業務を仕組みにするという流れです。具体例を5つ見てみます。
具体例1:採用の求人票づくりを昇格させる
最初はWorkに「営業事務の求人票の下書きを作って。仕事内容と必須条件はこれ」とお願いします。良い下書きができれば、まずはそれで十分です。
しかし職種ごとに求人を出していると、自社の言葉づかい、待遇の書き方、避けたい表現、過去にうまくいった求人票の型。毎回似たことを説明していることに気づきます。
そこでCodexへ昇格させます。
recruit/
├─ AGENTS.md … AIへの共通指示
├─ company-voice.md … 自社の言葉づかい
├─ job-template.md … 求人票の型
├─ ng-expressions.md … 使わない表現
├─ past-postings/ … 過去の求人票
└─ interview-guide.md … 面接質問の型
さらに「過去の求人票を確認する → 職種の要件を整理する → 下書きを作る → 自社の表現ルールでレビューする → 面接用の質問リストも用意する」という流れまで仕組みにします。
すると次からは「経理の求人票を作って」だけでも、自社の型に沿った下書きが出てくるようになります。Workでは「求人票」を作っていたものが、Codexでは「求人票を作り続ける仕組み」になります。
具体例2:営業前の企業調査を昇格させる
商談前にWorkへ「○○株式会社について調べて。事業内容、売上規模、直近のニュース、採用状況、AI活用の可能性をまとめて」とお願いします。これだけでもかなり便利です。
しかし商談のたびに同じことをしているなら、昇格させる価値があります。調査項目を「企業概要・事業内容・従業員規模・最近のニュース・採用情報・利用していそうなITツール・AI導入余地・提案できそうな業務・商談で聞くべき質問」のように標準化し、レポートの型と一緒にフォルダへ置きます。
すると「○○株式会社と明日商談なので準備して」だけで、会社ごとの営業準備を一定品質で行う仕組みになります。将来的には、商談結果→提案書→フォローアップまでを一つの業務フローとして育てることもできます。
具体例3:経理の月次レポートを昇格させる
Workに「この売上明細と入金一覧を突き合わせて、未入金の一覧を作って」と依頼するのも便利です。ただし、月次の締めは一度で終わる仕事ではありません。
毎月同じことをするなら、突き合わせの手順・確認する差異の種類・報告書の型を仕組みへ移します。そのうえで「データを整える → 突き合わせる → 差異の一覧を作る → 前月と比べて気になる点を挙げる → 月次報告の下書きにまとめる」までつなげます。
この段階になると、「集計してください」とAIに毎月頼むのではなく、毎月の定型部分はAIが進め、人は例外の判断だけをする業務フローが出来上がります。
具体例4:プレゼン資料作成を昇格させる
「この企画書をもとに、顧客説明用の10枚のプレゼンを作って」はWork向きの仕事です。
しかし営業資料を何度も作るのであれば、色・フォント・余白・1スライドの情報量・タイトルの書き方・NGデザインを毎回説明するのは非効率です。デザインルールと良い例・悪い例をフォルダに置いておくと、同じ指示でも自社のデザインルールを前提とした資料生成へ変わります。
Workではプレゼンを1個作る。Codexでは、プレゼンを作る会社独自の製造ラインを作る。この違いです。
具体例5:競合調査を「市場監視」に昇格させる
「競合5社の料金、サービス内容、最近の発表を調査して」は単発調査です。
競合調査を毎月やる必要があるなら、競合ごとに料金変更・新サービス・プレスリリース・採用・Webサイトの変更・新しい訴求を確認する仕組みを作ります。すると「競合調査」という作業が、競合環境の変化を継続的に捉える仕組みへ変わります。
人間は毎回ゼロから検索するのではなく、AIが整理した変化を見て「では自社はどうするか」という意思決定に集中できるようになります。
どのタイミングでCodexへ昇格させるか:5つの兆候
すべての仕事をCodex化する必要はありません。やりすぎると管理対象が増えます。次のような兆候が出たら、昇格を考えるタイミングです。

1. 同じ仕事を2回以上やっている。 一度きりならWorkで十分です。「またこれやってるな」と思ったときが仕組み化を考えるタイミングです。
2. 毎回同じ説明をAIにしている。 「当社のターゲットは○○です」「この言葉は使わないでください」「色はこの4色です」と毎回説明しているなら、それはルールとして残す価値があります。
3. 品質にばらつきが出る。 毎回結果が違って困る仕事は標準化の候補です。テンプレート、チェックリスト、良い例・悪い例をフォルダに入れることで再現性を高められます。
4. データ取得から成果物まで同じ流れがある。 「データ取得 → 分析 → 判断 → レポート」という流れが毎回同じなら、自動化しやすい業務です。
5. 自分がその仕事から離れたい。 時間の短縮だけでなく、最終的に自分が確認するだけにしたい仕事は、Codexへ移す価値があります。
Workは「試作」、Codexは「標準化」
この考え方をすると、AI導入そのものも進めやすくなります。いきなり「この業務を完全自動化しよう」と考えると、設計が大きくなりすぎます。それよりも、次の順番が安全です。
- WorkでAIに実際の仕事をさせる
- 結果を人間が確認する
- 何度か試し、良いやり方を見つける
- ルール、テンプレート、チェック項目を整理する
- Codexへ移して仕組みにする
- さらにスクリプトやAPIを組み合わせて自動化する

つまり、**先にAI活用をする。後からAI自動化する。**という考え方です。
さらに単純化すると、判断基準はこれだけでも構いません。
- 1回しかやらない → Work
- またやりそう → Codexを検討
「このPDFを3行で要約して」ならWorkで十分です。「毎週届くPDFレポートを要約して重要な変化だけ報告して」となると、Codexや自動化を考える価値が出てきます。同じ「PDFを読む」作業でも、単発なのか、業務なのかで使う場所が変わります。
では、全部Codexでいいのでは?
ここまで読むと「だったら全部Codexでよくない?」と思うかもしれません。
実際、仕事をどんどん仕組み化していく方であれば、かなりの割合をCodex側へ寄せられます。これは1人の仕事に限った話ではなく、少人数のチームでも、中小企業や大企業の部署単位でも同じ構図です。
進め方に段階があるだけです。1人で試す段階は、自分のフォルダで十分です。チームで同じ仕組みを使う段階になったら、フォルダをリポジトリとして共有・管理する形に進みます。当社が業務環境をリポジトリで運用しているのも、この段階の話です。
ただし「この文章を少し読みやすくして」「このPDFの内容を教えて」「今日だけ必要な市場調査をして」といった仕事まで、すべてフォルダへ持ち込む必要はありません。
**その場で完結する仕事はWork。会社の能力として残したい仕事はCodex。**このほうがシンプルです。
AI時代は「仕事をする」から「仕事の仕組みを作る」へ
これまでのAI活用は「ChatGPTに何を聞けば便利か」が中心でした。しかし、Codexのようなエージェント型の環境が一般化すると、次に重要になるのは「この仕事をAIが繰り返し実行できる形にできないか」という発想です。
毎月「アクセス解析して」と12回お願いすることもできます。しかし毎回ほぼ同じことをしているのであれば、「アクセス解析を継続的に行う仕組みを作って」と一度お願いするほうがよいかもしれません。
そして人間は、**作業をする側から、AIが動く仕組みを設計・改善する側へ回る。**この変化はかなり大きいと考えています。
なお、仕組みに移す前の段階でも、AIとのやり取りが長くなると精度が落ちる問題があります。この対策はセッションとコンテキスト圧縮を理解するで解説しています。
まとめ
ChatGPTのデスクトップアプリを使う現在、「Workは初心者向け、Codexはエンジニア向け」という理解では分かりにくくなっています。操作の入口はかなり近くなりました。
そのため、次の基準で考えることをおすすめします。
- 残らない仕事 → Work(考える・調べる・作る)
- 残して育てる仕事 → Codex(仕組みにする・自動化する・運用する)
そして最もおすすめしたいのは、Workで試して、うまくいった仕事をCodexへ昇格させる使い方です。
最初からすべてを自動化する必要はありません。まずAIと一緒に仕事をやってみる。うまくいったら、そのやり方を残す。繰り返すなら、仕組みにする。さらに必要なら、自動化する。
この流れで考えると、WorkとCodexは競合する機能ではありません。Workで仕事を発見し、Codexで会社の能力に変える関係です。
※本記事の機能名・提供状況は2026年8月時点の確認です。アップデートで変わる可能性があります。