ChatGPTのworkspace（ワークスペース）は、メンバー、管理者設定、共有リソースや利用権限をまとめる組織の利用環境です。workspace agentsは、その環境の中で作成・共有し、決めた業務手順を繰り返すためのAIエージェントです。workspace自体や単発のチャットを指す言葉ではありません。
workspace agentsは共有する設定をチームで再利用したい場合、Workは調査や成果物を進める案件で候補です。Workにも定期実行があるため、スケジュールだけでなく共有設定・権限、実行場所、データ、運用責任で選びます。Chatは短い質問、Codexは開発、OpenClawは実行環境を自社運用する場合に検討します。
要点
- workspaceは組織の利用環境、workspace agentはその中で共有・再利用するワークフローであり、両者は同じものではありません。
- Workにも定期実行があるため、スケジュールの有無だけでは選びません。共有する設定・権限、成果物、開発の必要性、自己運用の責任で比較します。
- 導入時は実行場所だけで安全性を判断せず、データ接続、アカウントの権限、読み書きや送信の許可、承認、記録範囲を個別に確認します。
workspace agentsの作成・提供条件はOpenAI公式cookbook、Workの実行・権限・データ境界はWork Overviewと管理者向けFAQ、Work Cloudのセキュリティ説明、OpenClawのGatewayとsandboxingは公式ドキュメントを参照しました（2026年10月26日）。提供条件はプラン・workspace・展開状況で異なります。
Workspace agentsとは何か｜workspaceとエージェントを切り分ける
workspace agentsは、ChatGPT内で作成し、指示や利用アプリ、スキル、共有範囲を設定して、チームの反復業務に使う共有エージェントです。OpenAIの公式cookbookは、商談前の情報収集とブリーフ作成を例に、カレンダーやSharePoint等のアプリを接続し、プレビューで試し、スケジュール実行や同僚との共有へ進む方法を示しています。説明にある提供形態はBusiness、Enterprise、Edu向けのresearch previewです。実際に利用できるか、作成・公開できる役割が誰か、必要なアプリが使えるかはworkspaceの設定と展開状況を管理者と確認します。
ここでいう「共有」は、全員が同じ設定を編集できることや、全員が同じデータ権限を持つことを意味しません。誰が作成・公開・利用できるか、接続先を個人アカウントにするか共有・agent-ownedアカウントにするか、コネクターにどの操作を許可するかは別々の設定です。
ChatGPT Workは、調査・分析、文書や表計算などの成果物作成を、進捗確認や追加指示を挟みながら進める体験です。Workもプラグインやscheduled taskでワークフローを繰り返せます。Workで個別案件の文脈を進めるか、共有エージェントの指示・接続先・利用者・権限を管理するかで選びます。定期実行できるかだけでなく、共有する設定・接続アカウント・許可操作を管理できるかで比較してください。詳細はWorkの定期更新の説明を確認してください。
Work・workspace agents・Chat・Codex・OpenClawの選び方
次の図は、組織で共有する権限・承認と、端末やツールを構成する運用を概念的に対比したものです。製品名や機能の対応を絵だけで判断せず、実際の機能と実行場所は表で比較してください。
| 選択肢 | 主な仕事・再利用の単位 | 実行・管理の考え方 | 導入時に見る点 |
|---|---|---|---|
| Chat | 質問、検索、短い相談、要約や文章のたたき台。会話やプロジェクト単位で使う | その場の依頼に答える。長い手順の定期実行やチーム共有が中心ではない | 入力情報、回答の根拠、出力の確認者 |
| ChatGPT Work | 一つの案件の調査・分析、文書、表計算、プレゼン、レポート等の作成 | 利用可能な設定に応じてクラウドや許可された接続コンピューターで作業する。途中確認や追加指示ができる | 対象プランとworkspace設定、実行場所、接続データ、成果物レビュー、利用量 |
| workspace agents | 商談準備、定期レポート、受付の分類など、チームで繰り返すワークフロー | 指示、スキル、接続アプリ、スケジュール、共有対象を設定し、プレビュー後に利用する。各設定の可否はworkspaceとアプリによる | 作成・公開できる担当者、個人／共有アカウント、アクション範囲、実行停止条件 |
| Codex | コード作成・修正、テスト、コマンド実行、差分レビューなどのソフトウェア開発 | リポジトリや開発タスクを中心に、ファイルと実行環境の範囲を定める | 対象リポジトリ、変更範囲、実行権限、テストと人のレビュー |
| OpenClaw | 自分で構成した端末・サーバーのGatewayやツールを使うエージェント運用 | 自己運用環境の設定、モデル接続、メッセージング経路、ツール、ネットワークを運用者が管理する | Gatewayの公開範囲、認証情報、実行権限、サンドボックス、モデル提供先、更新・監視の担当 |
選定では、顧客資料から提案方針を作る案件ならWork、毎週の商談ブリーフならWorkの定期更新か、指示・接続・権限を共有管理するworkspace agentsを検討します。CRM連携の実装・テストはCodex、短い質問はChatです。ChatGPTとCodexの開発範囲を比べる場合は、ChatGPTとCodexの違いも確認できます。
OpenClawは単に「ローカルAI」を選ぶことと同義ではありません。Gatewayや実行環境を自分の端末またはサーバーで運用できる一方、接続するモデル提供元、メッセージングアプリ、ツール、ネットワークを自ら選びます。自社サーバーでGatewayを動かしても、モデルへのリクエストまで必ず端末内で完結するとは限らないため、データの送信先と契約・保持条件を個別に確認します。
営業チームの架空例｜商談準備をどう分けるか
従業員数百人規模の架空のSaaS企業が、翌日の商談に向けた顧客ブリーフを整えるとします。担当者の予定、CRMの商談履歴、サポート記録、公開情報から、直近の変化、確認すべき論点、質問案をまとめます。対象のカレンダーやCRMに承認済みコネクターがあり、そのアクションを許可できることが前提です。
- 特定の大口顧客について過去資料と複数部門の情報を読み、経営会議向けの提案書まで作る日はWorkを使う。
- 平日に翌日の商談を確認し、決めた形式のブリーフを担当者に用意する定型業務は、Workのscheduled taskでも実行できます。共有する指示・接続アプリ・権限をチームで再利用する必要があればworkspace agentを試します。カレンダーを担当者ごとの個人接続、CRMの参照を用途限定した接続に分け、メール送信は試行中に無効化します。
- CRMのデータモデルやブリーフ生成コードを改修する場合はCodexを使う。顧客に関する単発の質問や文面の調整ならChatで足りる。
- データが社内ネットワーク内の独自システムにしかなく、自社でGateway・認証・ネットワーク・更新を運用できる場合はOpenClawを候補にする。自己運用できないなら、自由度だけを理由に採用しない。
これは製品の標準機能を保証する事例ではなく、選定の考え方を示す架空例です。試行では過去の商談20件を使い、必須項目をすべて埋めたブリーフが18件以上あること、主要な事実が元のCRM記録や文書までたどれること、許可していない更新・送信が0件であることを確認します。さらに、現行の準備時間との比較、担当者の修正時間、1回あたりの利用量を、開始前に合意した基準と照らします。結果が基準に届かなければ、接続範囲、指示、停止条件を修正して再評価します。
企業導入で確認するデータ境界・承認・運用責任
実行場所とデータ境界は別の論点です。ChatGPT WorkのLocal computer access with Work Cloudでは、クラウドがタスクを調整し、個々の処理がクラウド環境か許可された接続コンピューターで実行されます。ローカルのファイルやツールを使う処理には、そのコンピューターがオンラインで接続されている必要があります。この設定を有効にした後に作る対象タスクに適用され、既存タスクは元の実行モードを維持します。ローカル処理を含めても、会話やタスクの文脈まで端末内だけに留まるという意味ではなく、厳格なゼロデータ保持を提供するものでもありません。
クラウド環境は、接続端末のファイル、アプリ、ブラウザーセッション、社内ネットワークを自動で引き継ぎません。ローカルコンピューターへのアクセスが設定されている場合は、許可されたローカルツールを接続端末経由で別に使えます。Workのクラウドブラウザーもローカルブラウザーとは別のセッションです。ブラウザー、Web検索、接続アプリ、コード・シェルのネットワーク設定は独立した制御として確認します。
接続アプリでは、アプリが利用可能か、誰が認証したか、どの操作を許したか、いつ確認を求めるかを分けて設計します。個人接続はその人のアクセス権を使います。共有またはagent-ownedアカウントは接続元アカウントの権限を使うため、依頼者本人では見られないデータや実行できない操作へ届く場合があります。共有する前に、対象フォルダーやデータ、許可操作、利用者を絞り、不要な権限を削ってください。アカウント、接続権限、保持や監査の境界は、Work Cloudのセキュリティ説明も参照し、実際に有効な設定と照合します。
操作は、読み取り、下書き、更新・削除、共有・送信、スケジュール、コード・シェル実行に分けて考えます。管理者が対応アプリを読み取り専用や個別アクションに制限できる場合は、最初は参照だけを許し、更新・送信を後から別の判断で追加します。確認ダイアログも「何をするか」と「いつ人の確認を挟むか」を制御する設定です。許可ポリシー次第では個別確認なしで許可済みの更新が実行できるため、「重要操作は毎回必ずプロンプトが出る」とは想定せず、必要な承認点を試行時に検証します。Human in the Loop（HITL）は、確認が必要な判断点を業務手順として定める考え方です。
WorkとCodexの利用量・クレジットは共通の仕組みを使う場合があり、消費はモデル、処理量、推論設定、ツール利用、実行回数で変わります。BusinessとEnterprise・Eduで管理設定が同じとは限らず、利用可能な上限や費用を一律の価格表のように扱えません。workspaceで現在使える利用状況、上限、アラートを確認し、定期実行や大量データ検索のコストを別に測ります。
監査も「すべてが一つのログに残る」とは限りません。適格なEnterprise・Edu環境ではWorkのプロンプトと応答を含む記録が提供される場合がありますが、接続アプリの呼び出し記録は別で、すべてのファイル操作、ブラウザー操作、ツール呼び出し、承認が管理者向けログに含まれるとは限りません。必要なイベントがどの製品・接続元に記録されるかを、実際の試行で確認し、業務側でも入力元・出力・承認・公開結果を追えるようにします。
OpenClawでは、自己運用の自由度と一緒にホスト、Gatewayの公開範囲、認証情報、接続アプリ、利用モデル、ツール呼び出し（Tool Use）の許可、更新、ログ保管を運用者が引き受けます。公式のsandboxing説明では、ツール実行のサンドボックスは初期状態で無効とされ、Gatewayそのものはホスト上で動きます。サンドボックスを有効にしても全体の安全性が自動的に保証されるわけではありません。接続するモデルの提供元へ情報が送られるか、どのツールがホスト上で何をできるか、障害時に誰が停止・復旧するかを含めて設計します。
6段階で進める小さな試行と失敗時の対応
- 反復業務を一つ選ぶ。 月間件数、現在の処理時間、手戻り、対象データ、業務責任者を記録します。機密性や対外影響が高い仕事は、最初の試行から外します。
- 成果物と合格基準を決める。 入力、必要な項目、根拠の示し方、許容できない誤り、処理時間、利用量を定めます。単発の調査・資料作成ならWork、繰り返す同じ手順ならworkspace agents、コード変更ならCodexという候補もここで絞ります。
- データとアカウントを棚卸しする。 必要な情報源、個人接続と共有接続の別、接続アカウントの権限、閲覧対象の部署・フォルダーを台帳化します。ローカルファイルが必要なら、対応するWork設定、対象端末、オンライン接続条件、クラウド側の処理を確認します。
- 操作ごとに許可と承認を分ける。 まず読み取りと下書きだけにし、更新、削除、送信、公開、スケジュール実行は必要性と確認者を個別に定義します。停止条件と、誤作動時に接続・タスクを止める担当も決めます。
- サンプルと例外で試す。 通常例だけでなく、データ不足、同姓の顧客、古い記録、重複予定、接続切れを含めて評価します。事実の出典、必須項目、未確認の扱い、未承認操作の遮断が合格基準を満たすかを確認し、必要なら指示や権限を修正します。「ローカル端末の接続可否」「エージェントの共有権限」「外部操作の承認」の3点は、成果物の品質とは別の試験項目として確認します。
- 対象者を絞って運用し、定期レビューする。 利用者、接続先、実行頻度を限定して始め、成果品質、修正時間、失敗、利用量、記録の有無を追います。役割や接続権限の変更、費用増加、誤送信、監査不足があれば拡大を止め、接続や自動実行を見直します。
| 失敗の兆候 | 起きやすい原因 | 先に行う対応 |
|---|---|---|
| 依頼者には見えない顧客情報が出力に混ざる | agent-owned／共有アカウントが依頼者より広い権限を持つ | 共有接続を止め、接続元の権限・対象範囲・利用者を確認してから再開する |
| 顧客への送信やCRM更新が想定外に実行される | 下書きと実行を同じ許可として扱い、確認条件を検証していない | 書き込み・送信を無効化し、アクション制御と承認者を別々に再設定する |
| ローカルの資料や最新の記録が見つからない | 対象タスクの作成時点、端末のオンライン状態、クラウドとローカルの境界を誤認している | 対象タスクの実行条件を見直し、利用できる接続資料を入力するか処理を保留する |
| 定期実行の結果が急に不安定になり利用量も増える | 元データ、接続権限、取得量、実行頻度、再試行が変化した | スケジュールを止め、直近の入力・変更・利用量を確認してから小さい範囲で再試験する |
| 後から誰が何を承認したか確認できない | 製品ログに全操作が記録されると想定し、必要なイベントを検証していない | 利用可能なログ範囲を確認し、業務上必要な承認・出力・送信結果の記録を別途補う |
| OpenClawのGatewayや秘密情報へ想定外のアクセスがある | 公開範囲、ホスト権限、ツール、認証情報、初期状態のサンドボックス設定を点検していない | 外部アクセスを遮断し、資格情報を失効・更新して、ホストとツールの権限を再点検する |
よくある質問
ChatGPTのworkspaceとworkspace agentsは何が違いますか？
workspaceはメンバーや管理者設定、共有リソース、権限をまとめる組織の利用環境です。workspace agentsは、その環境内で作成・共有し、同じ業務手順を繰り返すエージェントです。workspaceそのものをエージェントと呼ぶわけではありません。
workspace agentsとChatGPT Workは同じものですか？
用途は重なります。Workも定期更新やワークフローを実行できます。個別案件の文脈で成果物を作るか、共有エージェントとして指示・接続先・利用者・権限・起動条件をまとめて管理するかを比べ、業務の共有範囲や例外処理を試して選びます。
workspace agentsはどのプランでも使えますか？
OpenAIの公式cookbookはBusiness、Enterprise、Edu向けのresearch previewとして案内しています。利用可否や作成・共有権限は、プランだけでなくworkspaceの管理設定、担当者の役割、展開状況にも左右されます。申込み前に管理画面の現状を確認してください。
ChatGPT Workはローカルファイルを使えますか？
設定によります。Local computer access with Work Cloudが利用可能な場合、対象機能を有効にした後に作成するタスクは、許可された接続コンピューター上のファイルやツールを使う処理を行えます。その端末はオンラインで接続されている必要があり、タスクの調整や文脈まで端末内だけで完結するわけではありません。
ローカル端末がオフラインになったら、作業はどうなりますか？
ローカル処理には接続端末のオンライン状態が必要です。条件を満たす既存タスクは、新しいターンからクラウドで続けられる場合がありますが、クラウドは利用できない端末のファイルやツールにアクセスしません。同じターンの実行中にローカル実行からクラウド実行へ切り替えることはできません。
共有エージェントの接続先は利用者本人の権限と同じですか？
接続方式によります。個人接続なら、その利用者のアカウント権限が使われます。共有またはagent-ownedアカウントは、接続アカウントの権限を使うため、利用者本人なら見られない情報や実行できない操作に届く可能性があります。共有前にデータ範囲、操作、利用者を絞ってください。
Workやworkspace agentsは、更新や送信のたびに必ず確認を求めますか？
必ずではありません。確認の出方はworkspaceやアプリの設定、許可された操作によって異なり、設定が許せば個別確認なしで許可済みの変更を実行できる場合があります。読み取り、下書き、更新、送信を別のアクションとして試し、業務上必要な承認点が実際に働くことを確認してください。
OpenClawはローカルで動くので安全ですか？
ローカルまたは自社サーバーで運用できることだけでは、安全性は判断できません。モデル接続先へ情報を送る場合があり、Gateway、ツール、ホスト権限、ネットワーク、認証情報の管理も必要です。公式ドキュメントではツール実行のsandboxingが初期状態で無効と説明されているため、運用者が設定と外部接続を確認します。
