Nexus AIコミュニティにお越しいただき、ありがとうございます。
ChatGPTのChatとWorkは何が違う?
ChatGPTには、2026年8月時点で「Chat」と「Work」という異なる使い方があります。
画面構成はよく似ていますが、OpenAIは両者を同じ用途の機能として扱っているわけではありません。
Chatは質問や相談、学習、アイデア整理などの対話を中心とした体験として位置づけられています。
一方のWorkは、複数の情報やツールを使いながら、仕事を最初から最後まで進めるためのAIエージェントとして設計されています。
最初に結論を整理すると、次のように考えると違いが分かりやすくなります。
| 項目 | Chat | Work |
|---|---|---|
| 主な役割 | 質問・相談・対話 | 仕事の遂行 |
| 得意なタスク | 単発の質問、学習、壁打ち、比較、文章作成 | 調査、分析、複数工程の処理、成果物作成 |
| 向いている場面 | 「これについて考えたい」 | 「この仕事を完了させたい」 |
ただし、ここで注意したいのは、Chatでは簡単なことしかできず、Workの方が上位版である、という関係ではないことです。
ChatでもWeb検索やファイル参照、文章作成、比較、意思決定支援など、幅広いことができます。
OpenAI自身もChatを、日常的な質問からアイデア相談、Web検索、画像生成、比較、意思決定まで対応する体験として説明しています。
そのため、ChatとWorkの違いを理解するときは、「どちらが高性能か」ではなく、AIに何を任せたいのかを見ることが重要です。
Chatは対話を中心とした体験、Workは複数ステップの仕事を進めるエージェントとして、それぞれ異なる目的に最適化されています。
Chatとは?対話を中心としたChatGPTの基本体験
Chatは、私たちがこれまで「ChatGPT」と聞いて最もイメージしやすかった使い方です。
OpenAIはChatについて、質問、学習、日常のサポートを中心とした体験として説明しています。
具体的には、日常的な疑問への回答だけでなく、
- 質問への回答
- 概念の説明
- Web検索を使った情報収集
- 画像生成
- 文章(記事・メールなど)の下書き作成
- 選択肢の比較
- 意思決定の検討
などにも利用できます。
重要なのは、Chatでは基本的に人間とAIの対話そのものが仕事を進める中心になることです。
たとえば、Webサイトの新しい機能について考えているとします。
最初に、「この機能を実装するとしたら、どのような設計がよいだろう?」と質問します。
ChatGPTから設計案が返ってきたら、
- 「既存機能との競合はない?」
- 「この方式だと保守性はどうなる?」
- 「別の実装方法も比較したい」
と対話を続けていくことができます。
このように、Chatでは人間が問いを投げ、その回答をもとに次の問いを作ることで、思考が少しずつ深まっていきます。
Chatは「短い仕事専用」ではない
ここは誤解しやすいポイントです。
Workが長いタスク向けだからといって、Chatが必ず短時間の作業しか扱えないわけではありません。
Chatでも長い議論や複雑な分析は可能ですし、プロジェクトを利用して文脈を維持しながら作業することもできます。
そのため、
- 「短い仕事=Chat」
- 「長い仕事=Work」
だけで判断すると、少し単純化しすぎます。
より本質的なのは、誰が仕事の進行を主導するのかです。
Chatでは、人間が会話を進めることでタスクが前に進む傾向があります。
一方、Workでは、人間が目的や条件を与えたあと、AI側が複数の工程をまとめて進めることを前提としています。
この違いを理解すると、ChatとWorkの境界が見えやすくなります。
Workとは?複数ステップの仕事を進めるエージェント
ChatGPT Work は、OpenAIが「業務タスクを最初から最後まで完了する」ためのAIエージェントとして提供している体験です。
OpenAIの公式説明では、Workは関連情報やアプリ、ツールを利用しながら、次のような成果物を作成・編集できるとされています。
- ドキュメント
- スライド資料
- スプレッドシート
- グラフ
- 画像
- その他の成果物
ここで注目したいのは、単に「ファイルを作れる」という点ではありません。
Workの本質は、成果物を作るまでに必要となる複数の工程を、一つの仕事として扱えることにあります。
たとえば、ある事業について市場調査を依頼するとします。
Chatであれば、
- 「市場規模を調べてください」
- 「競合も調べてください」
- 「今度は比較表にしてください」
- 「この情報からレポートを書いてください」
というように、人間が段階ごとに指示を追加することができます。
もちろん、この使い方でも十分に仕事は進みます。
一方でWorkは、最初から、「この市場について調査し、競合を比較し、重要な傾向を整理したレポートを作成してください」というように、完成させたい仕事そのものを渡す使い方と相性が良くなっています。
Workは必要な情報を集め、分析し、複数の工程を進めながら、完成した成果物へ向かって作業します。
OpenAIもWorkを、長めの調査や複数ステップの作業、完成した資料の作成に向いた別のChatGPT体験として説明しています。
Workでは既存のツールや情報も利用できる
Workでは、ChatGPTに接続したアプリや関連情報を利用しながら仕事を進めることができます。
OpenAIはWorkの利用例として、カレンダー、メッセージ、ドキュメントなどを参照して週次ブリーフを作成したり、計画資料からプロジェクトトラッカーを作成したりする例を紹介しています。
これは、Workを理解するうえで重要な特徴です。
AIが単独で文章を生成するのではなく、
「既存の情報を確認する」
↓
「必要な情報を整理する」
↓
「分析する」
↓
「成果物へ変換する」
という一連の作業を扱えるからです。
その意味では、Workは「回答を生成するAI」よりも、仕事の流れそのものに参加するAIに近づいています。
Workはどのプランで利用できる?
2026年8月時点では、WorkはChatGPTの対象有料プランを中心に提供されています。
OpenAIの最新案内 では、Plus、Pro、Business、EnterpriseなどでWorkへのアクセスが提供されています。
一方で、利用できる機能や展開状況はプラン、地域、Workspace設定、利用しているアプリなどによって異なる場合があります。
そのため、「PlusならすべてのWork機能が必ず同じ条件で使える」と考えるのではなく、実際のChatGPT画面やOpenAI公式情報で現在の利用条件を確認することが安全です。
OpenAIの製品は更新頻度が高く、Workも登場後に継続して機能が追加されています。
この記事でも、2026年8月時点で公開されているOpenAI公式情報を基準として解説しています。
ChatとWorkの違いを比較
ここまでの内容を整理すると、ChatとWorkの違いは「使える機能の数」だけでは説明できません。
むしろ、AIとの仕事の進め方そのものが違うと考えると理解しやすくなります。
| 比較軸 | Chat | Work |
|---|---|---|
| 基本的な目的 | 質問・相談・対話 | 仕事を最初から最後まで進める |
| AIとの関係 | 対話相手 | 業務を遂行するエージェント |
| 仕事の進め方 | 人間が会話を進める | AIが複数工程をまとめて進める |
| 得意な利用例 | 質問、学習、壁打ち、比較、設計相談 | 調査、分析、資料作成、プロジェクト作業 |
| 外部情報 | Webや利用可能なアプリなどを参照可能 | 接続アプリや関連情報を横断する仕事と相性が良い |
| 成果物 | 回答、文章、提案など | ドキュメント、スライド、表計算、レポートなど |
| 人間の主な役割 | 問いを作り、対話を進める | 目的・条件を与え、結果を確認する |
この違いを見ると、Workを「Chatより多くのことができるモード」とだけ理解すると、本質を捉えにくいことが分かります。
ChatにもWeb検索や文章作成、アプリ連携などの機能があります。
Workにも人間との対話があります。
つまり、両者には重なる部分があります。
それでもOpenAIがChatとWorkを分けているのは、同じ機能を使っていても、その機能をどのような仕事の流れの中で使うのかが異なるからだと考えると理解しやすくなります。
違いを判断するときは、AIと会話しながら考えたいのか、それとも複数工程を含む仕事をAIに進めてもらいたいのかを見ることが重要です。
ChatとWorkは中身も別物なのか?
ChatとWorkを実際に使ってみると、もう一つ疑問が生まれます。
画面は非常によく似ています。
同じChatGPTの中で切り替えて利用するため、「見た目が同じなら、中身もほとんど同じなのでは?」と感じるかもしれません。
この点については、OpenAIが公式に公開している事実と、そこから考えられる設計上の違いを分けて理解する必要があります。
公式情報で確認できること
OpenAIは現在のChatGPTを、大きくChat、Work、Codexという異なる体験として整理しています。
- Chat
- 質問や会話、学習、日常的な支援を中心としたものと説明しています。
- Work
- 長めの調査や複数ステップの仕事を担当し、完成した成果物を作成するエージェントと説明しています。
- Codex
- コードの理解、実装、テスト、レビューなど、ソフトウェア開発に特化したエージェントとして位置づけています。
デスクトップ版でも、ChatGPTを選んだうえでChatまたはWorkを切り替え、Codexは別の体験として選択する構造になっています。
つまり、少なくとも製品設計上、OpenAIはChatとWorkを異なる目的を持つ体験として区別しています。
公式情報から理解できる設計上の違い
この公式説明をもとにすると、ChatとWorkは次のように整理できます。
Chatは、人間とAIの対話を中心として思考を進める設計です。
一方Workは、目的を受け取り、複数の工程を通して仕事を完成させる設計です。
これはOpenAIが公開している内部実装そのものを説明したものではありません。
しかし、Chatを「質問・学習・日常のサポート」、Workを「業務タスクを最初から最後まで完了するエージェント」と位置づけている以上、製品として最適化している仕事の構造が異なる、と理解することはできます。
言い換えると、
- ChatはAIと一緒に考える場所
- WorkはAIにまとまった仕事を進めてもらう場所
という整理です。
この違いは、単なるUI上の名称変更よりも大きな意味を持っています。
公開されていない内部仕様は断定できない
一方で、ここから先は慎重に考える必要があります。
2026年8月時点でOpenAIが公開している情報だけでは、たとえば次のような内部仕様までは確認できません。
- ChatとWorkで必ず異なる基盤モデルが使われているのか
- Work内部でエージェントループが具体的にどのように実装されているのか
- ChatとWorkでコンテキスト管理方式がどこまで違うのか
- 内部の推論処理やツール選択ロジックがどのように分離されているのか
そのため、
- 「WorkはChatとは完全に別のAIシステムである」
- 「Workでは内部モデルそのものが違う」
といった説明は、OpenAIが公開している以上の内容を推測することになります。
Nexus AIでは、ここを明確に区別します。
公式に確認できるのは、ChatとWorkが異なる目的に最適化された体験として設計されていることです。内部実装まで完全に別物かどうかは、公開情報だけでは判断できません。
この区別は、ChatGPTのように変化の速いサービスを理解するときにとても重要です。
UIだけを見て「同じもの」と判断することも、製品名だけを見て「内部まで完全に別物」と判断することも避ける必要があります。
確認できる事実を土台に、その上で構造を理解する。
そうすると、ChatとWorkの違いもずっと分かりやすくなります。
そして実際に使い分ける段階では、さらに重要な問いが出てきます。
GitHubのようなPluginや外部サービスを使う場合、本当にWorkを選ぶ必要があるのでしょうか。
ここを整理すると、ChatとWorkを選ぶ基準が、機能一覧ではなく「仕事の構造」にあることがさらに明確になります。
GitHub Pluginを使うならWorkなのか?
ChatとWorkの違いを理解すると、実務ではさらに具体的な疑問が出てきます。
たとえば、GitHubのような外部サービスとChatGPTを連携して使う場合です。
GitHubにはソースコードだけでなく、README、Issue、Pull Request、変更履歴など、開発を進めるための重要な情報が集まっています。
ChatGPTからこれらの情報を参照できれば、単なる一般論ではなく、実際のプロジェクトの状態を踏まえて分析できるようになります。
では、GitHub Pluginを利用するならWorkを選ぶべきなのでしょうか。
結論から言えば、「GitHubを使うからWork」と考える必要はありません。
重要なのは、GitHubというツールを使うかどうかではなく、GitHubの情報を使ってAIに何をしてもらうのかです。
PluginはWorkだけの機能ではない
ここを理解するためには、現在のChatGPTにおけるPluginの位置づけを整理する必要があります。
OpenAIは2026年7月9日、従来のApp DirectoryをPlugin Directoryへ移行 しました。
現在のPluginは、ChatGPTやCodexで利用するワークフロー機能をまとめる仕組みとして位置づけられています。
Pluginには、外部サービスへ接続するApps、特定の作業方法を提供するSkills、App Templatesなどを含めることができます。
つまり、Pluginは「Work専用の拡張機能」という位置づけではありません。
OpenAIはPlugin Directoryについて、ChatGPTのWeb版・デスクトップ版から利用でき、WorkやCodexにも対応すると説明しています。
ただし、実際に特定のPluginをインストール・利用できるかどうかは、プラン、Workspace設定、役割、利用している画面、地域、Pluginに含まれるAppの機能などによって変わります。
したがって、「Pluginを使う=Work」という対応関係ではなく、「ChatGPT全体にPluginという拡張の仕組みがあり、その能力をChatやWorkなどの体験から利用する」と考えた方が現在の製品構造に近くなります。
GitHub連携でできること
OpenAI公式情報 では、GitHubをChatGPTへ接続すると、リポジトリ内のコード、README、その他のドキュメントなどの情報を取得し、その内容をもとにChatGPTが分析・推論できると説明されています。
たとえば、次のような使い方ができます。
- 特定のコードがどのような役割を持つのか確認する
- リポジトリ内の実装について質問する
- READMEやドキュメントを参照する
- コードベースを調査して関連箇所を探す
ここで重要なのは、GitHubに接続できること自体と、ChatとWorkのどちらを使うべきかは別の問題だということです。
たとえば、
- 「このクラスは何をしている?」
- 「このIssueについて設計を相談したい」
- 「この実装方法にはどのような問題がある?」
というように、GitHubの情報を参照しながら一つの問いについて考えるなら、Chatでも自然に扱えます。
一方、
- 「現在のIssueとPull Requestを確認し、実装内容が要件を満たしているか検証し、問題があれば修正方針を整理する」
という仕事になると、複数の情報取得と判断が連続します。
このような仕事は、長めの複数ステップ作業を前提としているWorkと相性が良くなります。
GitHubの情報を使って「一つの問いを考える」のか、「複数工程を含む仕事を進める」のかによって、ChatとWorkを使い分けると理解しやすくなります。
ChatとWorkはどう使い分ければいい?
ここまでの違いを理解すると、ChatとWorkを選ぶ基準はかなりシンプルになります。
AIと対話しながら考えたいならChat、まとまった仕事を目的まで進めてもらいたいならWorkです。
もちろん、これは絶対的な境界ではありません。
Chatでも複雑な作業はできますし、Workでも途中でAIと対話できます。
両者には重なる能力があります。
そのため、「この機能があるからこちら」という機能表だけで選ぶよりも、AIへ渡そうとしている仕事の形を見る方が実用的です。
Chatが向いている場面
Chatは、人間自身も思考プロセスへ深く参加したい仕事と相性があります。
判断の目安は、次のような場面かどうかです。
- 分からないことについて質問したい
- アイデアを一緒に考えたい
- 自分の考えを整理したい
- 複数の選択肢を比較したい
- 設計や戦略について壁打ちしたい
- 一つの問題について詳しく分析したい
この場合、重要なのは最初から完成した仕事を依頼することではありません。
AIから返ってきた回答を見ながら、
- 「なぜそうなるのか」
- 「別の可能性はないか」
- 「この前提は正しいのか」
と問いを重ねていくこと自体に価値があります。
Chatは、こうした対話によって思考を前進させる使い方に向いています。
Workが向いている場面
Workは、最終的に到達したい状態が比較的明確な仕事と相性があります。
判断の目安は、次のような仕事の性質を持っているかどうかです。
- 複数の資料を調査してレポートへまとめる仕事
- 複数のデータを分析して成果物を作る仕事
- 接続したアプリから情報を集めて整理する仕事
- いくつもの工程を経て一つの仕事を完成させる仕事
- 現在の状態を確認し、必要な処理を順番に進める仕事
この場合、人間が一工程ずつ、
- 「次はこれをしてください」
と指示するよりも、
- 「最終的にこの状態まで進めてください」
と目的を渡した方がWorkの特性を活かしやすくなります。
つまり、ChatとWorkの選択では、命令の長さではなく、仕事の粒度を見ることが重要です。
「何を聞くか」と「何を完了させるか」で考える
迷ったときは、次の問いを使うと判断しやすくなります。
私はAIに何かを聞こうとしているのか。それとも、何かを完了してもらおうとしているのか。
前者ならChatが自然です。
後者ならWorkを検討する価値があります。
たとえば、「このPull Requestの設計についてどう思う?」ならChatとの対話に向いています。
一方で、「Issueの要件と最新Pull Requestを確認し、実装が要件を満たしているかレビューしてください」ならWorkとの相性が良くなります。
同じGitHubを使っていても、AIに渡している仕事の構造は違います。この違いこそが、ChatとWorkを使い分ける中心的な判断基準です。
厳密な機能境界ではありませんが、実務では非常に分かりやすい判断基準になります。
AI開発ではChat・Work・Codexをどう使い分ける?
ChatとWorkの違いは、AIを使ったソフトウェア開発で考えるとさらに分かりやすくなります。
Nexus AIでは、実際の開発にChatGPT、Work、Codex、GitHubを組み合わせています。
これはOpenAIが指定している標準的な開発フローではなく、実際にAI共同開発を進める中で構築してきたNexus AI独自の運用例です。
現在は、おおむね次のように役割を分けています。
人間
├─ 意思決定・最終承認
│
├─ Chat
│ └─ 技術相談・設計・壁打ち
│
├─ Work
│ └─ GitHub確認・レビュー・プロジェクト進行
│
└─ Codex
└─ 実装・修正・テスト
↓
GitHub
この構造では、それぞれのAIを「どれが一番優秀か」で比較していません。
仕事の種類によって役割を分けています。
Chatは設計や壁打ちに使う
開発前には、コードを書くより先に考えなければならないことがあります。
たとえば、
- どのようなアーキテクチャにするか
- 既存機能との責務をどう分離するか
- この要件にはどの設計が適切か
- 将来的な拡張をどこまで考えるか
といった問題です。
このような問いには、必ずしも一つの正解がありません。
複数の可能性を比較し、人間とAIが対話しながら設計を絞り込んでいく必要があります。
そのため、こうした場面ではChatを使うことがあります。
Chatは、1回の質問だけで終わらせず、何度も深掘りする対話に非常に向いています。
私が普段から重視している、対話で内容を深める方法とマッチしているため、こちらも用途を見極めて継続して利用しています。
リサーチのような、答えを一つに絞らず可能性を広げていく作業にも適していると感じています。
WorkはGitHubを確認しながらレビューと進行を担当する
一方、実装が始まると必要な仕事が変わります。
Nexus AIでは、WorkからGitHubの情報を確認しながら、Pull Requestのレビューや開発進行を任せる使い方をしています。
たとえば、次のような流れです。
- 対象Issueの要件を確認する
- 最新のPull Requestを取得する
- 実装内容や変更差分を確認する
- Issueの要求を満たしているか検証する
- 問題があれば修正方針を整理する
- 問題がなければ次の開発判断へ進む
一つ一つはChatでも実行できる作業です。
しかし、この一連の流れを「Pull Requestをレビューする」という一つの仕事として考えると、複数工程の処理を前提とするWorkとの相性が良くなります。
ここでWorkを使っている理由は、単純にGitHub Pluginが利用できるからではありません。
GitHubから情報を取得し、それを分析し、開発の現在地を判断し、次の行動へつなげるという仕事全体を扱いたいからです。
これは、実際に使い続ける中で見えてきた大きな違いでした。
現在は、非公開で進めているプロジェクトをすべてWorkでレビューしながら進めています。
Chatでレビューを試したこともありますが、GitHubの誤操作などが起こり、詳細な工程を進めるにはやや厳しいように感じました。
プロジェクトを進めたり成果物を作成する場合には、Workは非常に強力です。
複数の情報源を横断するAIエージェントという役割も、実際に使ってみて納得できる動きでした。
CodexもAIエージェントとして動いているので、Chat・Work・Codexそれぞれが適切に役割分担できていると感じています。
この使用量はCodexなどと共有しているため、どの作業をWorkに任せるかは見極めが必要です。
Codexはソフトウェア開発を実行する
Codexはさらに役割が異なります。
OpenAIはCodexを、ソフトウェア開発に特化したコーディングエージェントとして位置づけています。
コードの理解、実装、デバッグ、テスト、変更レビューなど、開発作業そのものを担当できます。
そのためNexus AIでは、設計や開発方針を決めたあと、実際のコード実装をCodexへ任せています。
この役割分担によって、
Chatで考える
↓
Workでプロジェクトを確認・進行する
↓
Codexで実装する
↓
GitHubへ開発状態を蓄積する
という流れが成立します。
もちろん、これが唯一の正しい使い方ではありません。
プロジェクトの規模や開発方法によって、Chatだけで十分な場合もありますし、Codexを中心に進めた方が効率的な場合もあります。
重要なのは、AIを一つの万能ツールとして扱うのではなく、仕事に応じて役割を設計することです。
Chat・Work・Codexという三つの役割分担は、GitやGitHub、Codexそのものの基礎知識があると、より具体的にイメージしやすくなります。
また、実際にCodexと連携しながら開発を進める環境として、VSCodeを使っている方も多いはずです。
Nexus AIでは、このChatGPT・Codex・GitHubを組み合わせた開発方法そのものについても、実際の開発経験をもとに詳しく整理しています。
今回の記事ではChatとWorkの違いに焦点を絞っていますが、AIを開発チームのように役割分担させる考え方まで理解したい場合は、こちらの記事と組み合わせることで全体像が見えやすくなります。
【まとめ】Chatは「対話」、Workは「仕事の遂行」で選ぶ
ChatとWorkは、同じChatGPTの中に存在し、画面もよく似ています。
しかし、OpenAIは両者を異なる目的に向けた体験として位置づけています。
Chatは、質問、相談、学習、アイデア整理など、人間とAIの対話を中心に仕事を進めることに向いています。
Workは、調査、分析、外部情報の利用、成果物作成など、複数ステップを含む仕事を目的まで進めることに向いたエージェントです。
ただし、両者を完全に分離して考える必要はありません。
Chatでも複雑な分析や外部情報の参照はできますし、Workでも人間との対話は行われます。
PluginもWorkだけに閉じた仕組みではありません。
2026年8月時点では、PluginはChatGPTやCodexを横断してワークフロー能力を追加する仕組みとして提供されています。
そのため、使い分けるときに見るべきなのは「どちらの方が多くの機能を持っているか」ではありません。
見るべきなのは、AIへ渡そうとしている仕事の構造です。
- AIと対話しながら考えたい → Chat
- 複数工程を含む仕事を進めてもらいたい → Work
- ソフトウェア開発そのものを任せたい → Codex
このように考えると、それぞれの役割が明確になります。
AIの選択は、性能ランキングだけで決めるものではなくなりつつあります。
同じChatGPTの中でも、
- 「何を考えてもらうのか」
- 「何を完了してもらうのか」
- 「何を実装してもらうのか」
によって、適した体験は変わります。
ChatとWorkの違いを理解する鍵は、「どちらが高性能か」ではなく、「AIに何を任せたいのか」にあります。
この視点を持てば、新しい機能が増えても、機能名を一つずつ暗記する必要はありません。
自分がAIへ渡そうとしている仕事を見て、最適な役割を選ぶ。
ChatとWorkの使い分けは、そのための一つの設計なのです。
関連情報(公式ページ)
この記事は、2026年8月時点で公開されているOpenAI公式情報を参照して作成しています。
ChatGPTは更新頻度が高いため、利用できる機能、対象プラン、Pluginの対応範囲などは今後変更される可能性があります。
最新情報を確認する場合は、以下のOpenAI公式ページを参照してください。
ChatGPTのChatとWorkの違いに関するFAQ
ChatGPTのChatとWorkの一番大きな違いは何ですか?
ChatはAIとの「対話」を中心に考える体験、Workは複数工程を含む「仕事の遂行」をAIに任せる体験です。
ChatGPTのChatとWorkはどのように使い分ければよいですか?
AIと対話しながら考えたい場合はChat、最終的な目的までまとまった仕事を進めてもらいたい場合はWorkが向いています。
ChatGPTのWorkはChatより高性能な上位版ですか?
WorkはChatの単純な上位版ではなく、Chatは対話、Workは複数ステップの仕事にそれぞれ最適化されています。
ChatGPTのWorkはどのような仕事に向いていますか?
Workは、調査・分析・情報整理・成果物作成など、複数の工程を経て一つの仕事を完成させる用途に向いています。
GitHub Pluginなどの外部サービスを使う場合はWorkを選ぶべきですか?
必ずしもWorkを選ぶ必要はなく、一つの問いを考えるならChat、複数工程を含む仕事を進めるならWorkという基準で判断できます。
ChatGPTのChatとWorkは内部のAIシステムも違うのですか?
異なる目的に最適化された体験であることは確認できますが、基盤モデルや内部処理まで別物かどうかは公開情報だけでは判断できません。
AI開発ではChat・Work・Codexをどう使い分ければよいですか?
Nexus AIでは、Chatを設計や壁打ち、WorkをGitHub確認やレビュー・進行、Codexを実装・修正・テストに使い分けています。