ChatGPT Workとは​何か​ ──AIが​資料まで​作って​仕事を​「完了」させる​新機能を​解説

気になるAIの話を、分かりやすく ｜ 最新動向を、現場目線で

2026年7月9日、OpenAIは新モデルGPT-5.6と同時に「ChatGPT Work」を発表した。先に結論を言うと、今回のニュースの主役はモデルの性能ではなく、このChatGPT Workのほうだ。

ChatGPT Workは、AIに「ゴール」を渡すと、会社のファイルやアプリから必要な情報を集め、複数のAIが手分けして作業し、スライド・シート・ドキュメント・サイトといった成果物に仕上げ、人の承認と記録（監査）を挟みながら仕事を完了まで運ぶ——OpenAIはそう説明している^[2]。つまりChatGPTは「質問に答える道具」から「仕事を任せられる場所」に変わり始めた。

この記事では、①何が変わったのか ②何が新しいのか ③実際の仕事で何に使えるのか ④任せる前に知っておくべき注意点——の順に、専門用語なしで見ていく。私たち電脳技巧集団（AI職人ギルド）も日々AIエージェントで開発している側なので、その現場感で軽く一筆添える。

なお本文で使う「仕事OS」はOpenAIの公式な製品名ではなく、この記事の分析の枠組みだ。文脈・道具・段取り・成果物・検証・権限・監査・スケジュールが、ひとつの面でまとめて扱われ始めた——だから"OS"と呼んでいる。（機能はOpenAI公式の記載に基づく。CAG自身の検証ではない。）

01変わったのは​「仕事の​単位」だ

今回いちばん見落とされがちなのが、AIの扱う"単位"がまるごとずれたことだ^[2]。

• 入力：プロンプト → ゴール（目的）。
• 実行：1回の応答 → 数時間続くプロジェクト。
• 出力：文章 → そのまま共有できる成果物（スライド・シート・ドキュメント・サイト）。
• 操作対象：チャット欄 → 複数のアプリ・ファイル・ブラウザ・デスクトップ。
• 管理対象：品質 → 権限・承認・監査・支出まで。

この変化は、AIを「便利なアプリ」と見るか「仕事の実行基盤」と見るかの境目になる。そしてAIが仕事OSになると、人間の役割も変わる。プロンプトを書く人から、目的・受入条件・権限・予算・検証方法を設計する人へ。コーディング用の Codex も同じデスクトップアプリに統合され、"コードを書く"と"知的作業"の境目が薄くなった^[2]。

02モデルは​"CPU"、​仕事OSは​その​周り全部

ここで、頭の中を整理する比喩を置いておく。モデル（GPT-5.6）はCPU＝計算する頭脳だ。速くて賢いに越したことはない。だが、CPUだけではパソコンとして使えない。文脈を渡すメモリ、道具をつなぐ入出力、成果物を保存する場所、正しさを確かめる仕組み、勝手に動かないための権限管理——その周り全部があって、初めて"仕事"になる。

これは、以前このブログで書いた「モデルは脳、harnessは職場」という話と地続きだ。強い脳を用意することと、その脳が安全に働ける職場を作ることは、別の仕事なのだ。

関連記事 ｜ この命題の前段AI開発の主戦場は、モデル比較から「作業環境」へ移った ──モデルは脳、harnessは職場 →

では、その"周り全部"は具体的に何か。今回の動きを整理すると、7つの層として見える。次章で見る。

03"仕事OS"を​構成する​7層

AIに仕事を完了させるには、少なくともこれだけの層が要る^{[記事分析]}。表にすると、どこで失敗するかがよく見える。

層	役割	今回の実装例	ここが欠けると
① ゴール／仕様	何を"完了"とするか定義	Plan mode・明示的ゴール・完了の定義	途中でも「完了」と誤認
② 文脈	会社・案件の情報を集める	plugins・files・apps・browser	古い情報・毎回"新人"に戻る
③ 段取り	分解・並列化・再統合	ultra・Responses multi-agent	重複・競合・統合漏れ・浪費
④ 道具の実行	外部システムを読み書き	Programmatic Tool Calling・MCP・browser	誤操作・権限逸脱・往復過多
⑤ 成果物	読める納品物へ仕上げる	docs・sheets・slides・Sites・PR	答えはあるが納品物がない
⑥ 検証	完成条件を"証拠"で判定	tests・Auto-review・人のレビュー	未検証を完成扱い・体裁だけ
⑦ 統制・継続	安全に運用し続ける	承認・権限・Compliance API・Scheduled Tasks・spend control	情報漏れ・暴走・費用超過

この7層が大事な理由はシンプルだ。モデル比較が競っているのは、主に③と④の一部、そして推論の質だけ。でも実務の失敗は、①の受入条件不足、②の文脈欠落、⑤の成果物不備、⑥の検証不足、⑦の権限・監査不足でも起きる。だから、モデルだけを強くしても、仕事全体の成功率は頭打ちになる。

04GPT-5.6が​担う​"実行エンジン"

もちろんモデルが要らないわけではない。GPT-5.6は、この仕事面の「より強い脳」であると同時に、③④を効率化する実行エンジンでもある^[1]。

• ultra：複数のエージェントを並列で協調させるモード（既定で4エージェント）。research・セキュリティ点検・不足テストの洗い出し、のように独立した観点を同時に走らせ、まとめ役が重複や矛盾を統合する。
• Programmatic Tool Calling：大量の道具の出力を毎回モデルに返すのではなく、その場でコードを書いて filter / join / rank / dedupe し、小さく整えた結果だけを扱う。往復とトークンを減らす。
• multi-agent（ベータ）：1リクエストの中で親エージェントが子を生成し、結果を統合する。

要するにGPT-5.6は、「賢い1体」を超えて、「手分けして・道具を段取りする」ためのruntimeを内蔵してきた。モデル単体でなく、モデルとruntimeを一体で設計したのが今回の差分だ。

05でも、​"全部​エージェント任せ"は​失敗する

ここが本当に大事なところ。複数エージェントは、いつでも速いわけではない。OpenAIの公式ドキュメント自身が、万能視していない^[1]。

• 並列が効く：独立して切り分けられる作業（別々の観点の調査など）。
• 並列が不利：順序に依存する作業、同じ可変リソースへの書き込み、単一の重い処理。むしろ競合や統合漏れを生み、トークンも余計に食う。

Programmatic Tool Calling にも境界がある。集計のような予測できる処理には効くが、承認が要る書き込みや、最終的な成果物の検証は、コード任せにせず直接の道具呼び出し（と人間）に戻すのが推奨だ。

つまり仕事OSの本質は「全部AIに任せる」ことではなく、「どこを自動化し、どこに境界を置くか」を設計することにある。CAGでも、実務で効くのはここだ。読み取り／下書き／書き込み／取り返しのつかない操作で承認レベルを分け、"完了"は体裁でなく証拠で判定する。私たちの完了観は「調べた」ではなく、テストが通り・DBに保存され・実画面で確認でき・デプロイがREADYになり・メールが届いた——そこまで見て初めて完了だ。これは7層でいう⑥検証と⑦統制に当たる。

06まとめ ──次に​競うのは​「どう​完了させるか」

最後に、冷静な但し書きを2つ。ひとつ、ここで挙げたOpenAIの社内データや顧客事例は、いずれもベンダー自身が出したもので、母数・比較基準・失敗例は公開されていない。方向性は強いが、そのまま自社に当てはめず、小さく試して確かめるのが正しい^{[記事分析]}。ふたつ、「モデル性能はもう関係ない」わけではない。複雑な判断や未知の問題、最終品質には、モデルの地力が依然として効く。

そのうえで、今回の本線はこうだ。AIが「答えを出すエンジン」から、「成果物を完了させる仕事OS」へ近づいた。複数エージェント・道具・ブラウザ・成果物・承認・監査が、ひとつの仕事面に集まり始めた。

だから、次に競う軸も動く。「どのAIが賢いか」ではなく、「その仕事を、どう安全に完了させるか」。強いのは、モデル性能×仕事OSの掛け算を設計できる側だ。

関連記事 ｜ 仕事OSを組む＝運用設計の全体像"AIを使える"から"AIを運用できる"へ ──AIエージェント運用設計、5つの土台【まとめ】 →

観点	回答エンジン（これまで）	仕事OS（これから）
入力	プロンプト	ゴール（目的・受入条件）
実行	1回の応答	数時間続くプロジェクト
出力	文章・答え	共有できる成果物
完了の判定	それらしければOK	証拠（テスト・実画面・反映）で判定
人の役割	プロンプトを書く	目的・権限・予算・検証を設計する