2026年7月11日時点で、OpenAIはWorkspace AgentsをChatGPT Business、Enterprise、Edu、Teachers向けのresearch previewとして案内しています。現在のヘルプには、テンプレートやプロンプトからの作成、Preview、アプリ、ファイル、skills、custom MCP、ChatGPTとSlack、スケジュール、APIトリガー、共同編集、バージョン履歴、分析、RBACまで掲載されています。
ただし、機能が多いことと、最初から広い権限を与えてよいことは別です。最初の候補は、定期的に発生し、参照元を限定でき、出力を下書きとして人が確認できる社内業務にします。顧客への外部送信、全メールボックスの操作、データベースの直接更新、復旧方法のない処理から始めるべきではありません。
作り始める前にアクセス経路を確認する
公式のWorkspace Agents製品ページは対象としてBusiness、Enterprise、Edu、Teachersを挙げています。実際の操作と管理の基準はHelp Centerです。ChatGPTのサイドバーでAgentsを開き、テンプレート、自然言語の説明、または空のビルダーから開始し、公開前にPreviewで試します。
| 確認したいこと | 現在の境界 | 次に行うこと |
|---|---|---|
| Agentsが表示されない | ログイン中のworkspace、ロール、管理者設定で可視性が変わる | ブラウザを疑う前にworkspaceとRBACを確認する |
| 個人のProで使えるか | 公開ページはワークスペース向けプランを列挙し、個人Proを記載していない | 個人契約名から企業機能の権限を推測しない |
| ChatGPT以外で動かせるか | Slack、Schedule、API channelを設定できる | 各経路を別々の認証・公開範囲・リスク判断として扱う |
| APIで回答も受け取れるか | 現在のtriggerは実行をキューに入れるだけ | 同期応答やrun IDによるポーリングを前提にしない |
| 現在の料金はいくらか | 公開中の製品ページとヘルプには一律の安定した数値価格表がない | サインイン済みworkspace、現行プラン、契約担当で確認する |
2026年5月6日まで無料だったという公開時の案内は期限切れです。現在の予算根拠として再利用してはいけません。また、ヘルプの例にアプリ名があることは、自社workspaceでそのconnectorや同じactionが有効である証明にはなりません。
Workspace Agentにする価値がある業務か
Workspace Agentが向くのは、チームで共有し、同じ条件で繰り返し、承認された情報やツールを使い、開始条件と出力と停止条件を言語化できる仕事です。たとえば、指定資料からの週次状況レポート、会議記録からのアクション候補、顧客引き継ぎの要約、ナレッジ更新案などは、最初の検証対象にできます。
一度限りの調査は通常のChatGPTの方が軽く、会話型の再利用だけなら既存GPTを保つ選択もあります。規則が完全に固定されているなら、決定論的な自動化の方が挙動を説明しやすい場合があります。新しい名称だけを理由に移行せず、共有実行、スケジュール、チャンネル、ツール、共同所有、承認、履歴のどこに実益があるかを先に特定します。
候補を一文で定義できない、参照範囲を列挙できない、最初から不可逆な外部操作が必要、共有資格情報の所有者がいない、失敗後に戻せない、という場合は構築を止めます。まず「読む、下書きを作る、人が確認する」という小さい形に再設計します。
最初の安全なエージェントを構築する
ビルダーでは次の順序が実用的です。
- 業務と成果物の所有者を一文で定義します。
- 手動、メンション、時刻、イベント、APIからトリガーを一つ選びます。
- 読み取りを許可する文書、アプリ、データ範囲を列挙します。
- 出力を要約、提案、チェックリスト、メッセージ下書き、更新提案のいずれかに固定します。
- 必須のアプリ、ファイル、skill、custom MCPだけを追加します。
- Previewで通常ケース、情報不足、情報矛盾、範囲外の依頼を試します。
- 送信、編集、公開、削除などの書き込みは承認付きにします。
- 成功指標、停止条件、資格情報の所有者、復旧する既知の正常版を記録します。
良いinstructionは人格設定ではなく運用契約です。「毎週月曜、指定した三つの資料だけを読み、根拠を示したリスク要約を作成し、不足情報を列挙し、担当者の承認までSlackへ送らない」のように、時刻、情報源、出力、根拠、所有者、書き込み境界が含まれます。「カスタマーサクセスを自律的に処理する」では合否も停止も決められません。
Previewでは成功例だけでなく、アクセスできない資料、古い資料、相互に矛盾する資料、宛先が範囲外の依頼も試します。Agentが不足を推測で埋めず、明示的に止まれるかを見ることが、本番らしい長いデモより重要です。
アプリ、skills、MCP、チャンネルは権限モデルではない
アプリやconnectorは外部システムを接続します。ファイルは固定された文脈を渡します。skillsは再利用する手順を表します。custom MCPは専用のデータやツールを追加します。チャンネルはどこから起動するかを決めます。どれも単独ではアクセス制御や承認方針を代替しません。
アプリ接続は、利用者本人のアカウントを使う方式と、Agent-ownedのshared connectionを使う方式があります。共有接続には可能ならservice accountを使い、システム所有者を明記します。個人のアカウントを組織インフラとして扱うと、その人の私的情報、異動、退職、権限変更が運用リスクになります。
書き込みは種類ごとに分けます。内部の下書き作成、外部メール送信、契約文書編集、ファイル削除、顧客DB変更は同じリスクではありません。最初はAlways askを維持し、誰が何を承認し、どこに記録が残るかを決めます。数回成功しただけで、すべての操作を一括で自動承認に変えないでください。
API triggerは実行を開始するが、回答を返さない
API channelを使うと、社内システム、定期ジョブ、サポートツールなどからWorkspace Agentの実行を開始できます。ChatGPT AdminでWorkspace Agents scopeのaccess tokenを作成します。トークンはブラウザや公開クライアントに置かず、サーバー側だけで保管し、周辺システムの権限も対象業務に絞ります。
現在の重要な制約は応答です。OpenAIの説明では、triggerは実行をキューに入れ、202 Acceptedを返しますがresponse bodyはありません。run IDも返らず、そのtriggerを通してAgentの回答を取得することもできません。したがって、結果や副作用が別の既知の場所に現れる「起動だけ」の用途には合いますが、呼び出し元が即座に文章を表示するAPIや、run単位で状態を追う統合には合いません。
| 必要な体験 | 現在選びやすい経路 | 中止条件 |
|---|---|---|
| 同僚が起動して結果を読む | ChatGPT | ここで安定するまで他チャンネルを追加しない |
| チームチャンネルから利用 | Slack | shared auth、対象範囲、書き込み承認がなければ公開しない |
| 時刻で繰り返す | Schedule | 複数回の手動Previewより先に有効化しない |
| 内部システムは起動だけ必要 | API trigger | 応答やrun IDが必要なら採用しない |
APIが202を返したことだけを成功指標にしてはいけません。それはキュー投入の受理であり、業務出力の正確性、外部操作の完了、承認の実行を証明しません。結果が現れる場所と、運用担当が失敗を確認する方法を別に決める必要があります。
Connector Action Constraintsの限界を理解する
Connector Action Constraintsは、対応するactionの使い方を狭めます。たとえば、メールの宛先を特定ドメインに限定したり、一つのGoogle Docだけを対象にしたりできます。しかし、許可したactionが返すすべてのデータを自動的にフィルタする仕組みではありません。
そのため、自然言語で制限を書くだけでは不十分です。接続アカウント自体をleast privilegeにし、connectorのscopeを狭め、Agentを共有するaudienceを制限し、書き込みを承認し、合法な一回の呼び出しが実際にどのフィールドを返すかを確認します。メール、CRM、人事、財務、顧客データでは特に、戻り値の範囲を試験項目に入れます。
Constraintsは多層防御の一部です。ビルダーのinstruction、RBAC、接続先の権限、action constraint、承認、ログ、利用者の公開範囲を組み合わせて初めて、意図した境界に近づきます。
共同編集、Owner権限、バージョン復旧
Ownerは個人または対象workspaceのグループにCan chatやCan editを付与できます。Editorは共有draft、instruction、ファイル、skills、対応アプリやconnectorを更新できます。一方で、共有範囲の変更、workspace全体への配布、削除、チャンネル設定、一部の接続リソースなどはOwnerに残ります。
multiplayer editingは同じdraftを扱えるという意味で、リアルタイムの競合なしマージではありません。他の編集者が先に保存すると、ページ更新時に未保存のローカル変更が失われる可能性があります。大きな変更は担当者を一人決め、refresh前に未保存内容をコピーし、公開後はversion historyで差分を確認します。問題があれば、既知の正常なversionを再公開できるようにします。
運用開始前に三つの責任を割り当てます。workflow ownerは業務成果と評価基準、agent ownerは共有・公開・チャンネル、system ownerは共有認証とconnector権限を担当します。Analyticsのunique usersやrun数は利用状況を示しますが、回答品質、承認監査、事故対応の責任を代替しません。
SlackはChatGPT側の検証後に追加する
Slackは実行チャンネルであり、権限モデルではありません。Slack adminの承認が必要な場合があり、Agentのすべてのapp connectionはshared authenticationを使う必要があります。対象workspace、channelまたはuser group、応答形式、共有アカウントのOwner、書き込み承認を公開前に確定します。
最初はmentionによる手動テストに限定します。顧客向け文章は下書きまでにし、ファイルやDB更新は明示承認とログを必須にします。プライベートチャンネルの情報が、Agentを別グループに共有しただけで広い利用者へ届かないことも確認します。Slack workspaceを変更した場合の再接続も手順書に含めます。
料金と可用性は意思決定時に再確認する
プラン、connector、action、上限、料金は変化します。現在の公開情報はBusiness、Enterprise、Edu、Teachersをresearch preview対象として示しますが、すべてのworkspaceに適用できる一つの数値料金を示していません。高頻度schedule、多数のtool、大規模共有を予算化する際は、サインイン済みworkspace、最新の公式プラン、契約情報を使います。
テスト記録にはworkspace、ロール、有効なapps、認証方式、起動経路、承認policy、公開versionを残します。同じ名前のAgentでも、この条件が違えば結果とリスクは同じではありません。
展開前チェックリスト
対象プランとロール、一つのtriggerとoutput、最小の情報源、認証Owner、Previewの結果、書き込み承認、channelのaudience、ログの場所、停止条件、復旧versionを確認します。scheduleや広い公開の前に、現在の利用条件と費用も再確認します。
良い指標は接続したシステム数ではありません。繰り返し業務が速くなり、その一方でチームが情報源、権限、承認、失敗責任、復旧手順を説明できることが成功です。
FAQ
個人向けChatGPT ProでWorkspace Agentsを利用できますか？
現在の公開対象はBusiness、Enterprise、Edu、Teachersです。個人Proは列挙されていないため、個人契約名ではなくログイン中のworkspaceとロールを確認してください。
既存のGPTはWorkspace Agentへ必ず移行すべきですか？
いいえ。共有実行、tool、schedule、channel、共同管理、ガバナンスで明確な改善が証明されるまで、既存GPTや自動化をfallbackとして維持できます。
同じ会社で表示される人と表示されない人がいるのはなぜですか？
利用中のworkspaceやRBACロールが異なる可能性があります。Enterpriseでは管理者による有効化も関係します。Codex Workspace Agents pluginも同じRBACを使い、Codex専用の別toggleはありません。
API triggerでAgentの回答を同期取得できますか？
現在はできません。202 Acceptedでキュー投入を受理しますが、body、run ID、回答取得機能を返しません。
複数人で一つのAgentを編集できますか？
Can editやグループ共有を使えます。ただし同時変更は自動マージされず、一部操作はOwner限定です。大きな編集を調整し、version historyをrollbackに使います。
Connector Action Constraintsは機密データの返却も防ぎますか？
actionの使い方を制限しますが、許可したactionの全戻り値をフィルタするものではありません。least privilege、狭いscope、audience制御、承認、データ確認を併用します。
最初のAgentにはどの業務が適していますか？
反復し、情報源が既知で、レビュー可能な下書きを作り、人のOwnerと簡単なrollbackがある社内業務です。外部送信、全メール、不可逆なDB操作から始めないでください。
まとめ
Workspace Agentsの価値は、何でも自動化することではなく、チームの反復業務を共有・権限管理・検証・復旧できる実行に変えることです。まずworkspaceとロールを確認し、一つの狭い仕事をPreviewで安定させ、危険な書き込みには承認を残します。ChatGPT側で予測可能になり、Owner、ログ、停止条件、rollbackが揃ってから、Slack、schedule、API、グループ共有、広いconnectorへ段階的に進めてください。
