8月5日、Shlokが「Unpacking ChatGPT Work: the Agent for a Billion Users」と題した記事を公開した。OpenAIが7月9日にリリースしたエージェント製品「ChatGPT Work」のアーキテクチャを、メモリ・永続性・プロアクティビティ・スケジューリングといった観点から外部視点で詳細に分解・再構成したものだ。
ChatGPT Workとは何か
ChatGPT Workは、7月9日にOpenAIがリリースしたナレッジワーク向けのエージェント製品だ。Slack、メール、Google Drive、カレンダー、CRM、プロジェクト管理ツールなど数百のプラグインと接続し、それらをまたいでコンテキストを収集しながら「完成した成果物」を生成する。
リリースから3週間で、Codexと合わせて1,000万ユーザーを突破したと報告されている。ChatGPT自体は2026年6月に月間アクティブユーザー10億人を突破し、週間アクティブユーザーも10億人に迫る勢いだ。
現在、ChatGPT内でChatモードとWorkモードは並立しているが、Greg Brockmanは年内に両者を統合すると明言している。つまりWorkは一部パワーユーザー向けのニッチ製品ではなく、10億人規模のユーザーが近い将来使う体験のプレビューという位置づけだ。
技術的な構成としては以下の通りだ。
- Codexハーネス上で動作し、同じモデル・サブエージェント・ブラウザ操作能力を継承
- クラウドコンピュータ（マイクロVM）上に常駐。Proアカウントは8 CPU、RAM 20GB、64GBディスク。Plusは14GB RAM
- 成果物としてSheets・Docs・Slides、さらにSites（ホスト済みWebアプリ）を生成・公開可能
- デスクトップアプリではクラウドモードとローカルモードが選択可能。ローカルモードは実質的に開発者向けUIを取り除いたCodexに相当する
最も面白いポイント：「タスクをまたいだ状態管理」の設計思想
エンジニアが最も気になるのは、エージェントがどうやって複数タスクにわたって状態とコンテキストを持ち続けるかという設計だ。ここにWorkの本質的な賭けが現れている。
永続性の仕組み
Workのクラウドコンピュータは永続的だが、「1台のVMがずっと動き続ける」方式ではない。ワークスペースは永続ストレージに同期され、必要に応じて隔離されたマイクロVM上に復元される。つまり裏側のマシンは変わっても、作業状態は引き継がれる。
各タスク（スレッド）は /workspace/scratch 以下に専用のワーキングディレクトリを持つ。エージェントはそこで自由にフォルダ作成・依存関係のインストール・スクリプト実行・データベース管理が可能だ。同一スレッドでのフォローアップであれば、前の作業状態に戻って編集を継続できる。
タスクをまたぐとどうなるか
問題は「別スレッドのコンテキストが必要なとき」だ。エージェントは他スレッドのワーキングディレクトリを自由に歩き回ることはしない。代わりに、ChatGPT製品レイヤーが提供する専用の仕組みに頼る。
- Personal Context：過去のチャット・Workの履歴全体をクエリし、関連する箇所を返す専用ツール。任意のタスク横断的な参照はここを経由する
- Library：全ファイルとアーティファクトを一元管理する中央リポジトリ。会話履歴の生テキストはコンピュータ上には保存されず、Libraryが唯一の参照先となる。Personal Contextがテキスト検索的な役割を担うのに対し、LibraryはファイルやドキュメントのストレージとしてPersonal Contextと役割が分離されている
- メモリ：ユーザーの統合プロファイルとして非同期に管理され、タスク開始時に供給される。エージェント自身は変更不可
新しいスレッドが始まると、直近のタスクと作業済みファイルの圧縮サマリーが自動的に提供される。サマリーの形式はこのようなものだ。
20260731T15:55 Prepare Acme pilot plan:||||
Turn the attached notes into a one-page plan for the Acme pilot,
with an objective, deadline, and next steps.
<<File name="acme_notes.txt">>
さらに興味深い点として、ファイルのコピーはLibraryとワーキングディレクトリの2箇所に存在するが、両者は同期しない。スレッドAがアップロードしたファイルを、スレッドBがLibrary上で変更しても、スレッドAはローカルの古いコピーを読み続ける。
なぜ「コンピュータ上で全部管理」しないのか
著者のShlokはこの設計判断の理由として3点を挙げている。
- 既存のChatGPTプリミティブ（会話・Library・メモリ）の上に構築しているため、それをコンピュータ内に全部移植するには10億ユーザーが使うスタックの大規模なリファクタリングが必要になる
- 安全上のガードレール。全ファイル・会話・メモリへの無制限アクセスを認める方式（OpenClawのような一部のオープンソースエージェントフレームワークが採用する設計）は、セキュリティリスクとして問題視されてきた経緯がある
- OpenAIがプロダクト制御を維持するため。UI表示・コンテキスト管理・共有・デバイス間同期・ファイルバージョニングはすべて、エージェントが環境を自由に変更できる状態では実装が難しくなる
プロアクティビティ：エージェントが自分で考える
現在のAI製品はまだ「反応型」だ。ユーザーが何かに気づき、コンテキストを集め、プロンプトを組み立てて初めてエージェントが動く。Workはこの構造に手を入れようとしている。
新しいWorkの会話を開くと、作曲エリアと並んでユーザー自身のコンテキストから生成されたパーソナライズ済みタスク候補が表示される。エージェントが「あなたに必要そうなこと」を自発的に提案する形だ。
現時点の限界と今後
Shlokは、Workに現状欠けているものとしてメタレイヤーエージェントを挙げる。個々のタスクやプロジェクトの上位レベルで動作し、複数タスク間を横断的に調整する存在だ（すでにCodexをこの用途で使っているユーザーも一部いる）。
また、明示的な指示があれば別タスクのscratchディレクトリを参照・編集することは技術的に可能だが、エージェントが自律的にそれを行うことはなく、ディレクトリ名も不透明で会話との対応関係も整理されていない。
記事の結論として「Workはまだ若く、アーキテクチャは数週間後に大きく変わりうる」とShlokは述べている。
詳細はUnpacking ChatGPT Work: the Agent for a Billion Usersを参照していただきたい。
