OpenAIが発表したChatGPT Workは、質問に答えるチャットから、アプリやファイルをまたいで成果物まで仕上げるエージェントへ寄せた機能です。Slackやメール、カレンダー、コードリポジトリなどにつながり、何時間でもタスクに付き合う想定で設計されています。競合としてのClaude CoworkやCopilot Coworkと同じく、「会話」ではなく「仕事の完遂」が製品の顔になっています。

ただ、実際に触ってみると、多くの人が似た違和感を口にします。「プランは同じなのに、以前よりすぐに利用制限に当たる」。追加の基本料金が突然発生したわけではないのに、体感としての「使える時間」が短くなったように感じる。この記事では、その理由をアーキテクチャ側から読み解き、開発現場で現実的に効くリソース節約の3手まで落とします。

なお、「どこまで任せてどこで止めるか」の設計思想そのものは、AIエージェントを使うとき、どこまで任せてどこで止める？やAI活用の次の地図——指示する仕事から委任する仕事へ、エージェントの「手綱」としてのハーネスエンジニアリングでも扱っています。本記事はそこに踏み込みすぎず、ChatGPT Work特有のクラウド実行と利用枠の話に絞ります。

ChatGPT Workの裏側——ローカルではなく「常時つながるクラウドVM」

まず押さえておきたいのは、ChatGPT Workが「ブラウザの中で賢い返答を返す」だけでなく、クラウド上で長く動き続けられる実行環境を前提にしている点です。OpenAIの製品マネージャーはVentureBeatの取材で、ChatGPT Workの核を「クラウド上の仮想マシンで、常時オン」だと説明しています。端末の電源やネットワークに依存しにくい点が、ローカル常駐型のエージェントとの大きな違いです（VentureBeatの取材記事）。

外部SaaSとの接続は、プラグイン経由で行われます。同取材では、Gmail、Google Calendar、Slack、GitHubなどの連携がMCP（Model Context Protocol）ベースであることも確認されています。公式アナウンスでも、SlackやMicrosoft Teams、Google DriveやSharePoint、メール、カレンダー、CRMなどへ接続し、コンテキストを集めながらドキュメントやスライド、分析資料、Sitesといった成果物まで仕上げる流れが示されています（OpenAI公式発表、機能ページ）。

使い手から見ると、「指示を出す → 裏で調べる → ツールを叩く → 下書きを直し続ける → 必要なら承認を待つ」というループが、端末の前にいなくても進みます。Scheduled Tasksで、TeamsやSlackの新着を資料更新につなげるような運用も公式に想定されています。便利さの源泉はここにある一方で、利用枠の消費の仕方が、従来のチャットとまったく違うことも、同じ設計の裏側です。

なぜ「以前よりすぐ切れる」と感じるのか

公式はかなり率直です。ChatGPT Workは典型的なチャット要求より長く複雑な仕事向けに設計されており、必要な作業量に応じて利用量が変わり、複雑なタスクほどプランに含まれる利用枠をより多く使う、とされています。その利用の枠組みはCodexと同じ構造です（OpenAI公式発表）。つまり「Workが別課金になった」というより、同じエージェント系の枠のなかで、チャット1往復よりずっと重いジョブが走る、というイメージに近いです。

従来のChatGPTは、ざっくり言えば「1回の指示に対して1回（または短い往復で）返す」処理でした。一方のWorkは、専用の実行環境上で推論とツール呼び出しを繰り返し、GitHubからコードを取得し、ログを読み、修正案を試し、だめなら別案を試す——といったループを、ユーザーが見ていない時間帯にも回せます。表では「バグを直して」の一言でも、裏では通常の対話の何十往復分に相当するトークンや計算が積み上がりやすい。だから、クラウド側のリソース上限（プランに含まれるエージェント利用）に、以前より早く届く感覚が出ます。

Enterprise / Edu向けには、管理コンソールで利用の支出制御も用意されています。組織としてWorkを広げたいほど、「枠の設計」と「指示の設計」をセットで見る必要が出てきます。ここから先は、課金表を暗記する話ではなく、無駄な探索・無駄な再試行・終わりのない改善ループをプロンプトと運用で切る話になります。

エージェントの「暴走」を抑え、リソースを節約する3つの工夫

強力なエージェントは、指示が曖昧なままだと「優秀なクラウド資源の浪費装置」になり得ます。逆に、エンジニアがガードレールを先に書くと、同じタスクでも消費はかなり抑えられます。現場で効きやすいのは、次の3つです。スコープ、人間の承認、終了条件——いずれもハーネスの一部として捉えると、製品横断でも再利用しやすいです。

スコープ（探索範囲）を極限まで絞る

エージェントにリポジトリ全体や「関係しそうなところ全部」を読ませると、不要なファイルまで入力コンテキストに入り、インプットトークンが一気に膨らみます。調査対象が広いほど、読み込み回数も増えます。

悪い例は「このリポジトリのメモリリークを調査して」です。良い例は、「src/services/dataProcessor.ts 内のメモリリークを調査してください。探索対象は関連する2ファイルのみに限定し、他のディレクトリは読み込まないこと」です。ルート原因の仮説まで出揃った時点で一度止め、次のファイルを開けるかを人が決める、という二段階にするとさらに安定します。

Human-in-the-loop（人間の介入）をあえて挟む

見当違いの方向へ自律処理が進むと、手戻りのための再推論がコストそのものになります。公式も、重要なアクションの前に承認を求める運用を想定しています（OpenAI公式発表）。権限や止め方の考え方は、Anthropicの実測研究をまとめた記事とセットで読むとしっくりきます。

悪い例は「Slackのエラーを分析して、すべての該当リポジトリに修正Issueを立てておいて」です。良い例は、「エラーを分析し、作成すべきIssueのドラフトだけを作ってください。実際に起票する前に処理を一時停止し、私の承認（Goサイン）を待つこと」です。分析と起票を一続きにしないだけで、誤ったIssue量産と、その後の掃除コストの両方を防げます。

成果物のゴール（Definition of Done）を厳密に指定する

「いつ終えてよいのか」が曖昧だと、エージェントはより良い正解を求めて試行錯誤を延ばしがちです。終わりが見えないループは、利用枠を最も静かに削ります。

悪い例は「決済APIのパフォーマンスをいい感じに改善して」です。良い例は、「DBクエリを最適化してください。①N+1問題の解消、②テストコードのパス、③変更サマリの出力、という3条件をすべて満たしたらタスク完了とし、追加の最適化はせず速やかに実行を終了すること」です。完了条件は、技術者ならテストや差分レビューと同じノリで書けます。曖昧な形容詞は捨てて、観測可能な条件に落とすのがコツです。

そのまま使えるプロンプトの型（開発向け）

上の3つを、1本の指示にまとめると次のような型になります。動かす条件は、ChatGPT Work（または同等のエージェント機能）が利用可能なプランで、対象リポジトリやSlackへの接続（プラグイン）を事前に許可していること、本番書き込み権限は付与しない（または承認必須）ことです。個人情報や本番シークレットはプロンプトに含めないでください。

目的

src/services/dataProcessor.ts のメモリ使用が増え続ける問題の原因候補を特定する。

スコープ（厳守）

読むファイルは次の2つだけ：
- src/services/dataProcessor.ts
- src/services/dataProcessor.test.ts
上記以外のディレクトリ・ファイルは開かない
ウェブ検索はしない

Human-in-the-loop

原因仮説と、提案する修正方針のドラフトまでで止める
コード変更の適用、Issue作成、PR作成は、私の「Go」があるまで行わない

Definition of Done

次を満たしたら完了し、追加調査はしない：

疑わしい箇所をコード引用付きで1〜3点に整理した
各仮説に「確認方法（テスト／計測）」を1つ付けた
「次に人が承認すべきアクション」を箇条書きで提示した

出力形式

Markdown。結論を先に、根拠を後に。

この型のポイントは、エージェントに「賢くなってほしいこと」ではなく、「どこで止めてほしいか」を先に書くことです。Workが長く付き合うほど、終わり方の設計がそのままコスト設計になります。委任単位の切り方は、指示する仕事から委任する仕事へのステップ2の発想とも同じです。

まとめ——制約のある委任が、Workの真価を出す

ChatGPT Workは、曖昧な指示で放置するほど強く見える一方で、同じ設計ゆえに利用枠を早く消費します。クラウドVMで長く動き、MCP経由でSaaSに触れ、Codexと同じ系統の利用枠を使う——その前提を先に知っておくと、「すぐ切れる」は不具合ではなくエージェント利用の正常な副作用に見えてきます。

第一に、範囲を切る

読む場所と触る場所を、ファイル単位・ディレクトリ単位で先に閉じます。

第二に、承認ポイントを置く

書き込みや起票、送信の直前で止め、人がGoを出すまで進ませません。

第三に、完了条件を書く

観測可能なDefinition of Doneを満たしたら、改善欲求をあえて止めます。

自律型エージェントを日々の開発に組み込む勝負は、モデル名の比較より、こうした小さな制約の積み重ねにあります。仕組みを理解したうえで、リソースを賢く使いながら、「任せる仕事」の単位を少しずつ広げていく。その進め方が、結果として一番長くWorkを味方につけられるはずです。

作成日: 2026年7月14日