ChatGPT Work のローカルセキュリティ

ChatGPT Work は、ユーザーのコンピューター上にある承認済みのファイル、アプリケーション、ブラウザセッションを使用して、ローカルタスクを完了できます。アクセスできる範囲は、ワークスペースの権限、ユーザーが既存のアカウントで持つアクセス権、オペレーティングシステムの権限、アプリケーションの承認、サポート対象のデバイスポリシーによって決まります。

セキュリティ制御の概要については、ChatGPT Work エンタープライズセキュリティホワイトペーパーを参照してください。

ローカル機能は、サポート対象のデスクトップアプリ、オペレーティングシステム、ワークスペースの利用資格、ロール権限、デバイスポリシー、製品のロールアウト状況によって異なります。

セキュリティの概要

• ローカルのステップは ChatGPT デスクトップアプリを通じて実行されます。Work Cloud によるローカルコンピューターへのアクセスでは、OpenAI のクラウドがタスクを調整し、接続中のコンピューターが、そのコンピューターを必要とするステップを実行します。

• 利用可能なローカルおよびホスト型 Work の制御機能は、ワークスペースの構成とロールアウト状況によって異なります。

• ファイルアクセス、Computer Use、ブラウザ、接続済みアプリでは、それぞれ異なる権限と承認が使用されます。

• 企業システムにすでにサインインしているブラウザやアプリケーションでは、その既存アカウントの権限がタスクから利用可能になる場合があります。

• サポート対象の管理対象デバイスポリシーでは、ワークスペースのアクセス制御を置き換えることなく、ローカル機能を制限できます。

• 対象となる OpenAI サービスで処理される Business、Enterprise、Edu ワークスペースのデータは、転送中および保存時に暗号化され、デフォルトでは OpenAI モデルのトレーニングに使用されません。

• ローカルファイル、タスクのコンテキスト、ブラウザデータ、接続先システムのレコード、監査イベントには、それぞれ異なる保存および保持ルールが適用される場合があります。

ローカルタスクが実行される場所

ローカル実行では、ユーザーのコンピューター上のデスクトップアプリを通じて、承認されたリソースにアクセスします。Work Cloud によるローカルコンピューターへのアクセスを有効にすると、OpenAI のクラウドがタスクを調整し、ローカル実行が必要なステップで接続中のコンピューターを呼び出します。これらのステップを実行するには、コンピューターがオンラインで接続されている必要があります。

Work Cloud によるローカルコンピューターへのアクセスは、同期を有効にした後に作成されたタスクにのみ適用されます。プロジェクト内のタスクを含む既存のタスクは、ローカルのみ、またはローカルファイルへのアクセスがないクラウドという、元のモードを維持します。この機能を使用するには、新しいタスクを開始してください。

新しいターンの開始時にコンピューターが利用できない場合、Work Cloud によるローカルコンピューターへのアクセスを使用している既存の対象タスクは、クラウドコンテナーで続行できます。クラウドコンテナーは、利用できないコンピューター上のファイルやツールにはアクセスできません。また、ローカル実行におけるエンタープライズ要件も適用しません。ターンの途中で、タスクをローカル実行からクラウドに切り替えることはできません。

ローカルファイル自体はデバイスに残すことができますが、タスクを完了するために、関連するファイルの抜粋、プロンプト、スクリーンショット、ブラウザのコンテンツ、ツールの結果が OpenAI サービスへ送信される場合があります。ローカル実行は、オフラインまたはデバイス上のみでモデル推論が行われることを意味しません。

ファイルとデバイスへのアクセス

ローカルタスクでは、サポート対象のファイル、アプリケーションのコンテンツ、ブラウザセッション、承認済みの接続先システムなど、ユーザーが提供または利用可能にした情報を操作できます。アクセスできる範囲は、ユーザーの既存の権限と、その機能を管理する制御によって決まります。

ローカル Work へのアクセスを許可しても、すべてのアプリケーションが自動的に承認されたり、管理者権限が付与されたり、別のシステムへのアクセスに使用するアカウントの権限が回避されたりすることはありません。承認済みの共有接続は、ユーザーの個人アカウントとは異なる権限を持つ場合があります。

ファイルの直接読み取り、ファイルの編集、シェルコマンドの実行には、タスクのサンドボックス設定と承認設定が適用されます。Computer Use は、承認済みのネイティブアプリケーションを通じて、そのアプリケーションの権限でコンテンツにアクセスします。ファイルへの直接アクセスを制限しても、それだけでアプリケーションが開けるファイルに同じ制限が適用されるわけではありません。

Computer Use とアプリケーションの承認

Work Local を利用できるユーザーは、ワークスペースの権限によって決まります。管理者ポリシーでは、Computer Use が操作できるネイティブアプリケーションや、アプリケーションの承認を今後のセッション用に保存できるかどうかをさらに制限できます。必要なオペレーティングシステムの権限とアプリケーションの承認は、引き続き適用されます。タスクがアプリケーションやサインイン済みのアカウントを使用する場合、利用できる情報や操作は、そのアカウントの権限によって決まります。

管理者ポリシーでアプリケーションを許可しても、必要なプラグインがインストールされたり、オペレーティングシステムの権限が付与されたり、引き続きレビューが必要な操作が承認されたりするわけではありません。サポートされている制御と設定例については、ブラウザーと Computer Use の管理制御を参照してください。

macOS では、画面収録を許可すると Computer Use がアプリケーションのコンテンツを認識でき、アクセシビリティを許可するとクリック、入力、移動ができるようになります。サポート対象の macOS タスクはバックグラウンドで実行できます。Windows では、Computer Use はアクティブで表示中のデスクトップ上で動作し、ユーザーが同じセッションを使用し続けている間はバックグラウンドで実行できません。

ユーザーはいつでもタスクを停止できます。Computer Use は、オペレーティングシステムのセキュリティプロンプトを承認したり、管理者として認証したり、ターミナルアプリケーションや ChatGPT 自体を自動操作したりすることはできません。

ロックされたデバイス

サポートされている macOS 構成では、Mac がロックされた後も、承認済みの Computer Use タスクを続行できるように設定できます。利用できるかどうかは、アプリのバージョン、機能のロールアウト状況、適用される要件、リモート制御の利用資格によって異なります。

Locked Use を有効にすると、macOS の認可プラグインがインストールされ、実行中の信頼された Computer Use ターンのために Mac のロックを一時的に解除できるようになります。一時的なロック解除中は、ChatGPT がすべてのディスプレイを覆います。ローカルのキーボードやポインターからの入力を検知すると、Mac を再びロックし、ユーザーが手動でロックを解除するまで自動ロック解除を一時停止します。Locked Use の仕組みを参照してください。

管理者は、管理対象の Mac でユーザーが Locked Use を有効にすることを禁止できます。この要件は、すでに有効になっている Locked Use を無効にはしません。Windows の Computer Use には、アクティブでロックされていないデスクトップが必要です。Locked Use の制限を参照してください。

ブラウザセッションと既存のサインイン

Work Local が、すべてのブラウザや企業アカウントへのアクセスを自動的に取得することはありません。アクセスできる範囲は、使用するブラウザ、サインインしているアカウント、そのブラウザ体験に必要な承認によって決まります。

サポートされている Browser Use ポリシーでは、サイトへのアクセス、アップロード、ダウンロード、ブラウザー履歴へのアクセス、ブラウザーのデバッグ用の Chrome DevTools Protocol (CDP) へのフルアクセスを制限できます。管理者は、承認の自動レビュー、承認の保存、サイトアクセスの承認の有効期間も制限できます。ユーザーの承認で管理者による拒否を上書きすることはできません。ブラウザーの管理制御を参照してください。

ホスト型のクラウドブラウザーはユーザーのローカルブラウザーとは別であり、既存のサインイン状態を自動的に引き継ぐことはありません。Enterprise または Edu ワークスペースでは、クラウドブラウザーを通じたウェブサイトへのサインインは利用できません。

アプリ、プラグイン、接続済みアカウント

接続済みアプリは、別のシステムにある情報や操作へのアクセスを提供できます。プラグインは、アプリを基盤となるツールとして使用できます。プラグインを利用可能にしても、必要なアプリが自動的に有効になったり、アカウントが承認されたり、すべての操作が許可されたりすることはありません。

プラグインとアプリのデフォルト設定は、プランと、ワークスペースが新規か既存かによって異なります。新規の Enterprise および Edu ワークスペースでは、選定された一部のアプリが有効な状態で開始されます。これらのデフォルト設定は既存のワークスペース設定を変更せず、Healthcare ワークスペースにも適用されません。一般に、Enterprise と Edu では、新しいプラグインとアプリはデフォルトで無効です。Business では、アプリはデフォルトで有効です。管理者は利用可否を変更できます。現在のプラグインとアプリのデフォルト設定と ChatGPT Work の概要を参照してください。

タスクで接続先システムを使用する前に、ワークスペースでアプリと必要なプラグインが許可されていること、接続が承認されていること、接続済みアカウントがリクエストされた情報または操作にアクセスできることを確認してください。読み取り専用設定、許可される操作、確認要件は統合ごとに異なります。

ブラウザー機能や Computer Use 機能を提供するプラグインには、利用可否とインストールに関する個別のレビューが必要です。プラグインを利用可能にしても、管理対象のブラウザーポリシーやネイティブアプリのポリシー、オペレーティングシステムの権限、必要な承認を上書きすることはありません。デスクトップ専用のプラグインやローカルで提供されるツールでは、インストール方法が異なる場合があります。プラグインの制御を参照してください。

個人接続と共有接続

個人接続では、接続したユーザーが接続元システムで持つ権限が使用されます。共有接続またはエージェント所有の接続では、接続済みアカウントの権限が使用されます。これは、ユーザー自身のアクセス権より広い場合があります。

共有アカウントがアクセスできるデータと操作を必要最小限に抑え、使用できるユーザーを制限し、サポート対象の操作制御または確認制御を適用してください。接続先システムのレコードには、引き続きそのシステムの権限と保持ポリシーが適用されます。

管理者アクセスと管理対象デバイスのポリシー

Work Cloud によるローカルコンピューターへのアクセスでは、ワークスペースの同期権限と、ローカル実行に関する Agent Security の要件の両方を確認してください。

ローカル実行では、MDM および従来の管理対象デバイスの要件が Agent Security より優先されます。デバイスのシステム要件ファイルの優先順位は Agent Security より低くなります。同一ポリシー内では、OS 固有の環境オーバーライドがすべての OS に適用される環境オーバーライドより優先され、その次に Global が適用されます。優先順位の低いポリシーのほうが具体的であっても、優先順位の高いポリシーが優先されます。一部の要件には、フィールド固有のマージルールがあります。

Global 設定の管理にはポリシー API を使用します。Local または Codex Cloud の設定を管理するには、Agent Security UI を使用します。既存の Global API ワークフローは、移行後も引き続き利用できます。スクリプトと Terraform 連携をテストし、ポリシーの割り当てと順序が変わっていないことを確認してください。

ローカルアクセスを備えた Work と dots では、管理ポリシーが有効な場合、サポート対象の Global ポリシーが共有クラウドオーケストレーターを通じて適用されます。接続中のコンピューターでの実行は、適用対象となるローカルの requirements.toml の要件に従います。Work のクラウドコンテナーと dots のクラウドコンピューターは、他の実行タイプが使用する管理対象環境バンドルではなく、独自の実行設定と要件を使用します。ローカル実行の制限は、これらのクラウドコンピューターには自動で適用されません。クラウド機能の権限を確認し、ローカル実行とクラウド実行をそれぞれテストしてください。

同期を有効にする前に、次の要件を確認してください。

• MDM のみで配信されるポリシー。MDM はデバイスにポリシーを配信します。同期を有効にする前に、サポート対象のローカル実行要件に対する Agent Security のベースラインを作成してください。

• エンタープライズフック。 ワークスペースで有効になっている場合、Work Cloud によるローカルコンピューターへのアクセスは、サポート対象のライフサイクルイベントとツールイベントに対して、クラウドコーディネーター（オーケストレーター）上で実行される管理者定義の MCP フックをサポートします。クラウドオーケストレーションでは、ツールがローカルで実行される場合でも、コマンドフックや、ローカル設定またはプラグインによるフックはサポートされません。オーケストレーションと実行の両方がローカルの場合、既存のサポート対象フックは、ローカルのみの Work および Codex のスレッドで引き続き動作します。管理者は、これらのワークフローに対して、Agent Security でサポート対象の管理フックを引き続き設定できます。

• 監査。 これらのフックを利用する前に、コールバック接続をテストし、受信するイベントを確認して、障害がタスクに与える影響を調べてください。MCP フックでは、完全な Compliance API の監査証跡は得られません。

ワークスペース設定 > 権限とロール で利用可能な Work の制御設定を確認してください。ローカルの Work とホスト型の Work が別々の権限として表示されるかどうかは、ワークスペースの構成とロールアウト状況によって異なります。詳しくは、Work 管理者向け FAQ を参照してください。

ユーザーまたはグループごとに承認された実行環境のみを有効にし、変更後に実際に適用されるアクセス権を確認してください。

ワークスペースの権限によって、Work を使用できるユーザーが決まります。管理者は、requirements.toml で定義された強制要件を通じて、サポート対象のデスクトップ機能を制限することもできます。デプロイ方法に応じて、これらの要件は、ワークスペースで管理される構成、システムレベルの構成ファイル、またはサポート対象の macOS モバイルデバイス管理ツールを通じて配布できます。

強制要件は、個々のユーザーが上書きすることはできません。一方、管理対象のデフォルトは初期設定を定めるものであり、ユーザーが変更できる場合があります。どちらも、ワークスペースのロールやオペレーティングシステムの権限を置き換えるものではありません。

既存のローカル設定パスを使用するローカルクライアントでは、設定の読み込み時に管理対象の要件が読み込まれます。バックグラウンドでの更新により、次回以降の読み込みに向けてクラウドの要件を準備できます。また、macOS の MDM 変更は、次回のクライアント起動時に読み込まれます。ローカルポリシーを変更した後は、該当するローカルクライアントを再起動して確認してください。

Work Cloud でのローカルコンピューターへのアクセスを無効にすると、現在実行中のターンが中断されます。ユーザーは既存のクラウド上の会話で新しいターンを開始できます。そのターンでは、ローカルファイルへのアクセスを伴わない Work Cloud が自動的に使用されます。

このローカルでの読み込み動作からは、Work Cloud でのローカルコンピューターへのアクセスを使用している実行中のタスクに、クラウドポリシーの変更がいつ適用されるかは判断できません。更新が適用されたと判断する前に、タスクで実際に有効な制御設定を確認してください。

これらは制限の例であり、デフォルトで有効な設定の一覧ではありません。機能の要件を指定しない場合は、通常のクライアント、プラットフォーム、ロールアウト、ユーザーの設定が引き続き適用されます。Browser Use の機能フラグ、組み込みブラウザーペイン、ネイティブの Computer Use は、それぞれ独立した制御設定です。各ブラウザーの利用経路を個別に確認してください。

利用可能な設定と配信方法は、クライアント、オペレーティングシステム、ワークスペース、デプロイ構成によって異なります。代表的な管理対象デバイスで制限を確認してください。サポートされているポリシー設定、設定例、MDM のセットアップ手順については、管理対象の設定を参照してください。

ローカルネットワークとプライベートリソース

Work Local は、ブラウザー、ネイティブアプリケーション、接続済みアプリ、その他の対応ツールを通じて社内情報にアクセスできます。ネットワーク制御の適用方法は経路ごとに異なります。また、企業の VPN にアクセスできること自体が、タスクによる内部リソースの使用を許可するわけではありません。

管理対象のネットワーク要件と Browser Use のオリジンポリシーは、別々にチェックされます。ネットワーク制限によって Browser Use を制限できると判断する前に、導入環境のアプリバージョンとオペレーティングシステムで両方を確認してください。ブラウザーポリシーのチェックが行われても、ブラウザーの通信がコマンド用ネットワークプロキシを経由するとは限りません。また、Browser Use のポリシーはネイティブアプリケーションからの通信には適用されません。

[experimental_network] 配下の管理対象のネットワーク要件は実験的なものであり、変更される可能性があります。Windows のサポートは限定的です。Windows ユーザーに適用する前に、実際に使用するクライアントと環境でテストしてください。ドメインルールだけでは管理対象のプロキシは有効になりません。experimental_network.enabled = true が必要であり、この設定によってネットワークを無効にしているサンドボックスの制限が上書きされることはありません。

ワークフローで必要となる接続、サインイン済みアカウント、接続先、操作を確認してください。設定の詳細とプラットフォームの制限については、ネットワークアクセス要件を参照してください。

データ処理と保持

Work Cloud でのローカルコンピューターへのアクセスでは、ステップがコンピューター上で実行される場合でも、クラウドによる調整がワークフローに含まれます。会話データとタスクのコンテキストは、ツールが使用するローカルファイルとは分けて確認してください。ローカルで実行されることから、データがデバイス上にのみ保存される、あるいはフォルダー内のすべてのファイルがアップロードされると推測しないでください。

Work Cloud でのローカルコンピューターへのアクセスでは、厳密なゼロデータ保持は提供されません。データレジデンシーと推論レジデンシーの対象は、適格なコンテンツと、サポートされているワークロード、リージョン、構成に限られます。Enterprise Key Management（EKM）は、対象となるワークスペースに保存された、サポート対象のコンテンツに適用されます。UAE の推論レジデンシーでは Work はサポートされていません。展開前に、ワークスペースのストレージ、保持、監査の対象範囲を確認してください。組織で ZDR が必須の場合は、この機能を有効にしないでください。いずれかのクラウドポリシーで enforce_residency が有効になっている場合、Work と dots の両方でローカルコンピューターへのアクセスを許可 が無効になります。この保護措置は、ワークスペースのレジデンシーを設定するものではなく、それ自体で Work Cloud や dots を無効にするものでもありません。

組織のエンドポイント、ファイルアクセス、プロキシ、データ損失防止の制御を、対象となるデバイスとワークフローに適用してください。処理を開始する前に、それらの制御によって機密情報がタスクに取り込まれるのを防止できるか確認してください。監査ログとコンプライアンスエクスポートは監視と調査に役立ちますが、それ自体で処理を阻止するものではありません。

保存と保持の方法は、情報のカテゴリと保存場所によって異なります。

サポート対象の Business、Enterprise、Edu ワークスペースでは、対象となる OpenAI サービスで処理されるビジネスデータは転送中および保存時に暗号化され、デフォルトでは OpenAI モデルのトレーニングや改善に使用されません。これらの保護があっても、OpenAI がすべてのデバイスファイル、サードパーティ製アプリケーション、ブラウザプロファイル、接続元システムのレコードを管理するわけではありません。

特定のデータカテゴリに適用されることを確認せずに、ホスト型の会話、一時アップロード、コンプライアンスログの保持期間をローカルレコードへ適用しないでください。

監査とコンプライアンスの可視性

Work Cloud でのローカルコンピューターへのアクセスを有効にすると、既存の OpenTelemetry（OTel）コレクターが受信する内容が変わります。ローカルの実行コンポーネントは、引き続きサポート対象の実行イベントをエクスポートできます。クラウドのオーケストレーションイベントは、既存の OpenTelemetry コレクターには届きません。

サポート対象のクラウド記録には Compliance API を使用してください。コレクターのエンドポイントを変更しても、クラウドのオーケストレーションイベントを再び受信できるようにはなりません。Compliance API の記録は、以前の OpenTelemetry ストリームに含まれていたすべてのイベントを代替するものではありません。OpenTelemetry と監査の対象範囲を確認するを参照してください。

利用可能なレポートは、ワークスペースのプラン、製品体験、イベント、接続済みアプリケーション、デプロイされた構成によって異なります。インシデント対応や規制上のレビューでワークスペースのエクスポートに依存する前に、Work Local が対象に含まれていることを確認してください。

対応バージョンでは、Browser Use はサイトアクセス、アップロード、ダウンロードなどの機能チェックに関する OpenTelemetry イベントを出力できます。これらのイベントには、判定とその判定元が記録され、利用可能な場合はポリシーの詳細も含まれます。判定元が不明な場合もあります。エクスポートが設定されている場合、これらのイベントは他のローカルランタイムのテレメトリとともに、お客様の OpenTelemetry エンドポイントに送信されます。

OpenTelemetry のエクスポートは、Compliance API の記録とは別に設定してください。これらのイベントでは、ブラウザーやネイティブアプリでのすべての操作を完全に記録することはできません。OpenTelemetry の設定を参照してください。

関連システムに、タスクの ID、サポート対象のプロンプトと応答、接続済みアプリの呼び出し、ブラウザの承認、アプリケーションの操作、ローカルファイルのアクティビティ、エンドポイントイベントのどれが記録されるかを確認してください。接続元システムやデバイスのレコードでは、ChatGPT ワークスペースのレコードとは異なる情報を確認できる場合があります。

OpenAI は、拡張機能を通じて実行された Chrome 操作について、完全なレコードを別途保存することはありません。すべてのローカルファイル操作、スクリーンショット、ブラウザ操作、承認、外部更新が Compliance API に記録されるとは限りません。

1 つの承認済みタスクから始める

チームが使用する管理対象デバイスで、ローカルの Work を検証してください。選択した財務ワークブックの比較など、承認済みのタスクを実行します。各ユーザーの Work へのアクセス権を確認し、そのタスクに必要なファイル、アプリケーション、ブラウザーセッション、接続済みアカウントのみを提供してください。

承認済みの操作が機能し、制限対象の操作がブロックされ、利用可能な記録が監視のニーズを満たしていることを確認してください。ユーザーに結果を確認してもらい、ファイルや接続先システムへの変更が依頼内容に沿っていることを確かめてください。