2026.10.09 ChatGPT

ChatGPT workspace agentsとは？API起動・Slack連携・権限設計【2026年10月】

ChatGPTのworkspace agents（ワークスペースエージェント）は、チームで共有して使うエージェントを作る機能で、OpenAIが2026年4月22日に発表しました。この記事では、対象プランとクレジット単価、作成と共有の手順、アプリ接続の認証方式と書き込みの承認、Slackに置くときの条件、そしてWorkspace Agents APIで社内システムから起動するcurlとPythonのコードまでを、公式ドキュメントの記載をもとに整理します。数値と仕様は2026年10月9日時点の公式情報です。

まとめ：ChatGPT workspace agentsを入れる前に決める接続・承認・起動経路

workspace agentsは、GPTsの後継にあたる「チームの業務手順を覚えたエージェント」です。Codexの実行環境の上で動き、ChatGPT・Slack・スケジュール・APIの4経路から起動できます。

導入前に決めるのは3点です。1つめはアプリ接続の認証方式で、実行者ごとの接続か共有接続かによって、誰の権限でデータが動くかが変わります。Slackに置くなら共有接続しか選べません。2つめは書き込みの承認で、既定の「Always ask」を外すなら送信先や対象を絞る制約とセットにします。3つめは起動経路です。2026年10月時点でAPIは実行を受け付けるだけで、回答本文は受け取れません。回答を自社システムで使いたいなら自社構築が早道です。

ChatGPT workspace agentsの基本仕様と対象プラン・GPTsからの変化

まず、発表時点と現在の仕様を分けて押さえます。

Codexの実行環境で動き続けるチーム共有エージェントの仕組み

OpenAIの発表記事は、workspace agentsを「GPTsの進化版」と位置づけています。土台はCodexで、クラウド上にファイル・コード・ツール・メモリを置く作業場を持ち、利用者が不在でも作業を続けます。実行できる作業の範囲は、コードの実行、接続したアプリの操作、学んだことの記憶までです。

GPTsとの違いは、会話の外で動けることです。GPTs（カスタムGPT）の作り方と公開条件で見たGPTsは会話への応答を整える仕組みで、workspace agentsは定期実行やSlackの投稿をきっかけに自分で仕事を始めます。GPTsは引き続き使え、GPTsからの変換機能は「近日提供」とされています。

Business・Enterprise・Eduの提供状況とクレジット課金の開始日

発表本文では、Business・Enterprise・Edu・Teachersの各プランでのリサーチプレビューでした。その後、同じ発表ページの冒頭に「Business・Enterprise・Eduで一般提供（GA）」という追記が入っています。Free・Go・Plus・Proは対象外です。Enterpriseでは提供開始時点で既定がオフで、管理者が有効にして初めて使えます。

料金は2026年5月6日まで無料で、同日からクレジット課金に移りました。ChatGPTのクレジット単価表では、workspace agentsはGPT-5.6で100万トークンあたり入力100・キャッシュ入力10・出力500クレジットです。1回の実行の目安は5〜25クレジット。Businessでは、ChatGPT Work・Codex・Excel・PowerPoint・Wordと同じ利用枠とクレジットを共有します。プランごとの席単価と枠の違いはChatGPT EnterpriseとBusinessの料金比較で整理しました。

GPTs・ChatGPT Work・dots・Agents SDKとの違いを比べる判断軸

OpenAIには作業を任せる仕組みが複数あります。違いは「誰が作り、何をきっかけに動くか」で見ると分かりやすくなります。

仕組み	使う単位	作る人	起動のきっかけ
workspace agents	チームで共有	業務担当者（ノーコード）	ChatGPT・Slack・定期実行・API
GPTs	個人または共有	業務担当者（ノーコード）	ChatGPTでの会話
ChatGPT Work	依頼ごと	不要（既製）	ChatGPTでの依頼
dots	1人に1体	不要（既製）	本人の目標・会話
Agents SDK	自社アプリに組み込み	開発者（コード）	自社システム

依頼ごとに成果物まで運ぶのがChatGPT Workの仕組み、1人に付いて目標を持ち続けるのが常時稼働エージェントのOpenAI Dotsです。workspace agentsはその間にあり、部署の決まった手順を固めて複数人で使い回す用途に向きます。

エージェントビルダーで業務手順をワークスペースエージェントにする作成手順

作成と共有はChatGPTの画面で完結します。手順はヘルプセンターのworkspace agents解説に沿っています。

Agentsタブから自然文で下書きを作り公開するまでの5手順

ChatGPTの左サイドバーで「Agents」を開き、「Create」を選ぶ
任せたい業務を文章で説明する（白紙から作るなら「Start blank」）
ChatGPTが示す下書きの計画を確認し、「Build this agent」で組み立てる
ビルダーでモデルと推論の強さ、ツール、手順を整え、「Preview」で試す
右上の「Create」で作成し、公開後の変更は「Update」で反映する

財務・営業・マーケティング向けのテンプレートから始める方法もあります。下書きを更新しても、利用者が引き続き使うのは公開済みの版です。版の履歴から前の版を公開し直せるので、手順の変更は下書きで試してから公開します。

ツール・アプリ・カスタムMCP・スキル・ファイルの追加と512MBの上限

ビルダーの「Tools」からは、Google Calendar・Google Drive・Slack・SharePointなどのアプリ、自社で用意したカスタムMCP、画像生成とWeb検索を追加できます。使えるアプリの範囲は、ワークスペースで有効になっているものだけです。社内のSaaSをMCP経由でつなぐ場合の権限の切り方は、Slack MCPサーバーの接続手順と権限設計の考え方がそのまま当てはまります。

ファイルは1つ512MBまで、エージェント全体で10GBまでです。ファイルが増えるほど性能が落ちるとされているため、社内規程を丸ごと入れず、業務に必要な文書だけを分割して入れます。

Can chat・Can edit・Ownerの3権限とグループ共有の設定

共有の範囲は「自分だけ」「リンクを知る組織内の人」「組織のディレクトリに公開」の3段階です。保守を複数人で分担するときは、メンバーかワークスペースのグループに編集権限を渡します。

権限	できること	できないこと
Can chat	実行と設定の閲覧	下書きの編集
Can edit	下書きの編集と新しい版の公開	共有範囲の変更・削除・チャネル設定
Owner	権限管理・ディレクトリ公開・削除まで全部	なし

リンク共有やディレクトリ公開をしても、全員が編集者になるわけではありません。同時編集はリアルタイムで統合されず、先に保存した人の変更が残ります。後から保存しようとした側には「Save conflict」が出るため、大きな変更は担当者を決めてから行います。

アプリ接続で使う認証方式の選択と書き込み承認・操作対象を絞る制約の設定

workspace agentsの安全性は、どの資格情報でアプリを操作させるかで大半が決まります。ここでは接続時の認証方式、書き込み承認、Connector Action Constraintsによる操作対象の制約を順に整理します。

エンドユーザーアカウントとエージェント所有アカウントを選び分ける基準

アプリ接続ごとに選ぶ認証方式は、次に示す2つです。「End-user account」は実行する人が自分のアカウントで接続する方式で、見えるデータはその人の権限の範囲に収まります。「Agent-owned account」は共有の接続を1つ持たせる方式で、実行する人は認証しなくて済みます。

共有接続には、個人のアカウントではなくサービスアカウントを使います。ヘルプセンターも、個人アカウントで共有接続を作ると、エージェントを使う他の人がその人の権限でデータを読み書きできてしまうと警告しています。判断の目安は単純です。人によって見えてよい範囲が違うデータ（人事・顧客・経理）はEnd-user account、全員に同じ範囲を見せてよいデータは権限を絞ったサービスアカウントのAgent-owned accountにします。

Always askによる書き込み承認と操作の送信先・対象を絞る制約の設定例

アプリへの書き込み操作は、既定で「Always ask」（実行中に毎回確認）です。アプリによっては「Never ask」や、操作ごとの「Custom」にも変えられます。メールの送信、スプレッドシートの編集、予定の追加のように外へ影響が出る操作は、確認を残すのが原則です。

確認を外したい場合は、Connector Action Constraintsで操作の中身を縛ります。たとえば「メールの宛先は自社ドメインだけ」「読めるのは特定のGoogle Doc 1つだけ」といった制約を自然文で書くと、ビルダーがルールを生成し、確認してから保存します。注意点は、制約が縛るのはエージェントが頼める操作であって、アプリが返すデータではないことです。「confidential」を含むメールの検索を禁じても、別の許可された検索の結果にその語を含むメールが入ることは防げません。

Slackチャンネルに置くとき共有接続が必須になる条件と準備

Slackで使うには、エージェントのアプリ接続をすべて共有接続にする必要があります。個人の接続が1つでも残っているとSlackには置けません。準備は次の順です。

ChatGPTのWorkspace Settingsで「Apps」から「Workspace Agents in Slack」を対象ロールに有効化する
Slackの対象チャンネルの「Integrations」から「ChatGPT Agents」アプリを追加する
エージェントの「Channels」で「Connect Slack」を選び、Slackハンドルとチャンネルを決める
全メッセージに応答するか、メンションされたときだけ応答するかを選ぶ

チャンネルの参加者は全員、共有接続の権限でエージェントを動かせます。ヘルプセンターも、社員だけの信頼できるチャンネルに限って置くよう勧めています。また、Slackに配備中のエージェントで、アプリと接続の追加・変更を行えるのはOwnerだけです。

Workspace Agents APIで社内システムからエージェントを起動する実装手順

問い合わせ管理やジョブ管理など、ChatGPTの外で起きた出来事をきっかけにエージェントを動かすのがAPIトリガーです。

管理者のトークン作成許可からAPIチャネル追加までの事前設定4手順

Workspace Agentのアクセストークンの解説によると、APIを呼ぶにはOpenAI PlatformのAPIキーではなく、ChatGPT側で発行する専用トークンを使います。

管理者がworkspace agentsを有効にし、「Admin」の「Permissions & roles」で「Allow users to create personal access tokens」をオンにする
エージェントのビルダーでAPIチャネルを追加し、エージェントを公開する
「Admin」の「Access tokens」でトークンを作り、スコープに「Workspace Agents」を選ぶ
トークンをシークレット管理に保存し、APIチャネルの識別子（agtch_ で始まる値）を控える

このトークンで呼べるのはWorkspace Agents APIの操作だけです。APIチャネルは、エージェントを公開して初めて有効になります。

curlによる起動トリガーの最小リクエストと受付後のステータス・会話URL

「Trigger workspace agent runs」のドキュメントどおりの最小リクエストです。本文の input は必須、conversation_key は同じ会話を続けたいときに付ける任意の識別子です。

export AGENT_ACCESS_TOKEN="（シークレット管理から読み込む）"
export API_TRIGGER_ID="agtch_xxxxxxxx"

curl -i https://api.chatgpt.com/v1/workspace_agents/$API_TRIGGER_ID/trigger \
  -X POST \
  -H "Authorization: Bearer $AGENT_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -H "OpenAI-Beta: workspace_agent_runs=v1" \
  -H "Idempotency-Key: inquiry-20261009-0001" \
  -d '{"conversation_key":"support_daily","input":"本日分の問い合わせを要約し、対応方針を提案してください。"}'

受け付けられると 202 Accepted が返り、本文にChatGPT上の会話URL conversation_url が入ります。OpenAI-Beta: workspace_agent_runs=v1 を付けたときだけ、実行ID agent_trigger_run_id（apirun_ で始まる値）も返ります。この状態取得はベータ機能です。

Pythonで実行状態をポーリングし冪等キーで再送を安全にするコード

実行IDで状態を問い合わせ、completed か failed になるまで待つ例です。requests だけで動きます。

pip install requests
python run_agent.py

import os
import time
import uuid

import requests

BASE = "https://api.chatgpt.com/v1/workspace_agents"
TRIGGER_ID = os.environ["API_TRIGGER_ID"]  # agtch_ で始まるAPIチャネルの識別子
AUTH = {"Authorization": f"Bearer {os.environ['AGENT_ACCESS_TOKEN']}"}


def trigger(text: str, conversation_key: str, idempotency_key: str) -> dict:
    headers = {
        **AUTH,
        "Content-Type": "application/json",
        "OpenAI-Beta": "workspace_agent_runs=v1",  # 実行IDを受け取るためのベータヘッダ
        "Idempotency-Key": idempotency_key,  # 同じ出来事を再送するときだけ同じ値を使う
    }
    body = {"input": text, "conversation_key": conversation_key}
    for attempt in range(3):
        try:
            r = requests.post(f"{BASE}/{TRIGGER_ID}/trigger", headers=headers, json=body, timeout=30)
        except requests.ConnectionError:
            time.sleep(2 ** attempt)  # 通信断は同じ冪等キーで再送しても二重起動にならない
            continue
        if r.status_code == 409:
            raise RuntimeError("エージェントかAPIチャネルが実行できない状態です（公開済みか確認）")
        r.raise_for_status()  # 401・403・404 はここで例外にする
        return r.json()
    raise RuntimeError("トリガーを送れませんでした")


def wait_run(run_id: str, interval: int = 10, max_wait: int = 1800) -> dict:
    deadline = time.monotonic() + max_wait
    while time.monotonic() < deadline:
        r = requests.get(f"{BASE}/{TRIGGER_ID}/runs/{run_id}", headers=AUTH, timeout=30)
        r.raise_for_status()
        run = r.json()
        if run["status"] in ("completed", "failed"):  # 終了状態はこの2つだけ
            return run
        time.sleep(interval)  # queued・in_progress・suspended の間は待つ
    raise TimeoutError(run_id)


if __name__ == "__main__":
    accepted = trigger(
        "本日分の問い合わせを要約し、対応方針を提案してください。",
        conversation_key="support_daily",
        idempotency_key=str(uuid.uuid4()),
    )
    print("会話URL:", accepted["conversation_url"])
    run_id = accepted.get("agent_trigger_run_id")
    if run_id is None:  # ベータの状態取得が無効なら受付までで終える
        raise SystemExit(0)
    run = wait_run(run_id)
    print(run["status"], run.get("error"))

状態は queued・in_progress・suspended・completed・failed の5つです。suspended は外部の操作やツールを待っている状態で、終了状態ではないため待ち続けます。上の例は30分で打ち切ります。失敗時の error.code は dispatch_failed（起動前の失敗）か run_failed（実行中の失敗）です。

401・403・404・409の切り分けと回答本文をAPIで取得できない制約

ステータス	意味	まず確かめること
401	トークンが無い・期限切れ・失効・不正	PlatformのAPIキーを使っていないか
403	トークンは有効だが起動の権限が無い	トークンの持ち主がそのエージェントを実行できるか
404	トリガーか実行IDが見えない	`agtch_` の識別子か・同一ワークスペースか
409	チャネルかエージェントが実行できない状態	最新の下書きを公開したか

設計上いちばん効く制約は、回答本文をAPIで取れないことです。状態取得で分かるのは終わったかどうかだけで、結果は会話URLかSlack投稿などで受け取ります。なおヘルプセンターは「202で本文は無く、実行IDも返さない」と書いており、開発者ドキュメントとは記述が食い違う点に注意が必要です。実装は開発者ドキュメントの仕様で組み、上のコードのように実行IDが無ければ待たずに終える分岐を入れておきます。

管理者が設定するRBACの4権限とCompliance APIによる監査・停止の運用

利用者に開放する前に、管理者が権限の線を引きます。

利用・作成・公開・共有接続での公開を個別に分ける4つのロール権限

ヘルプセンターによると、ロールごとに次の4つを個別に許可できます。

Enable agents：エージェントを探して実行できる
Enable agent building：エージェントを作成・編集・複製できる
Enable agent publishing：組織のディレクトリに公開できる
Enable agent publishing with agent-owned connections：個人や共有の認証済み接続を持つエージェントを公開できる

4つめは、作った人の資格情報で他の人がデータを読み書きできる状態を許す権限です。最初は「利用」を全員、「作成」を各部署の担当者、公開系の2つを情報システム部門だけに渡すと、野良エージェントの公開を防げます。この設定はCodexのWorkspace Agentsプラグイン（ベータ）にも同じく効きます。

Compliance APIで構成変更と実行履歴を追い問題のあるエージェントを止める運用

発表記事によると、OpenAIのCompliance PlatformのCompliance APIから、各エージェントの構成・更新・実行を確認でき、管理者はエージェントを停止できます。ChatGPT EnterpriseとEduでは、ユーザーグループごとに使える接続ツールと操作も制限できます。

点検の優先順位は、Agent-owned accountで書き込みが「Never ask」になっているエージェントが先頭です。所有者の退職時は、エージェントと共有接続の引き継ぎ先を決めてから権限を外す手順を入退社のチェックリストに入れておきます。

ChatGPT workspace agentsの採否を分ける業務条件と自社構築の判断

接続先・共有接続の権限・回答の受け取り方の3軸で結論を出します。

公式アプリ内で完結する部署の定型ワークフローは採用してよい条件

採用してよいのは、Google Drive・SharePoint・Slackなど既に用意されたアプリの中で完結し、手順が文章で書ける部署の定型業務です。OpenAIが例に挙げるソフトウェア申請の審査、週次の指標レポート、製品フィードバックの振り分けはこの型に入ります。結果を人がChatGPTかSlackで読む前提なら、回答をAPIで取れない制約も問題になりません。

個人アカウントの共有接続や外部の人がいるチャンネルでの利用は見送る場面

見送るのは2つの場合です。1つは、サービスアカウントを用意できず、個人のアカウントで共有接続を作るしかない業務。作った人の権限で全員が動けてしまい、退職時に業務も止まります。もう1つは、社外の参加者がいるSlackチャンネルに置く計画で、共有接続の権限が社外の人の発言で動きます。「まず本番の顧客データで試す」も避けるべき失敗パターンです。

回答を自社システムで受け取る要件はAgents SDKで作り込むべき線引き

エージェントの出力を基幹システムに書き戻したい、処理結果をAPIの戻り値として受け取りたい、という要件はworkspace agentsの守備範囲の外です。この場合はOpenAI Agents SDKでhandoffやガードレールを実装する方法のように、自社のアプリケーションにエージェントを組み込むほうが筋が通ります。手間がかかるのはコードより、認可・監査ログ・承認フローといった統制の設計です。社内に実装の経験が乏しければ、要件が固まった段階でAIエージェント開発の相談窓口に持ち込むと、workspace agentsで済む部分と作り込む部分の切り分けから一緒に進められます。

ChatGPT workspace agents導入時のよくある質問と公式情報による回答

導入の検討でよく出る疑問に、2026年10月9日時点の公式情報で答えます。

「OpenAI Agent Workspace」とworkspace agentsは同じものですか？

OpenAIの公式サイト・ヘルプセンター・開発者ドキュメントを2026年10月9日に確認した範囲では、「Agent Workspace」という名称の製品は見当たりません。社内の業務を共有エージェントに任せる仕組みとして公式に提供されているのは、この記事で扱うChatGPTのworkspace agentsです。名称で調べて見つからない場合は、「workspace agents」で公式ドキュメントを探すと該当の情報にたどり着けます。

ChatGPT PlusやProでもworkspace agentsを使えますか？

使えません。対象はChatGPT Business・Enterprise・Eduで、発表時のリサーチプレビューではTeachersも含まれていました。Enterpriseでは提供開始時点で既定がオフのため、管理者がロール単位で有効にする必要があります。個人で常駐型のエージェントを使いたい場合は、ProとBusiness Premiumが対象のdotsが近い選択肢です。