Work Cloud と dots のローカルコンピューターアクセス

Work と dots は、OpenAI のクラウドがタスクを調整する間、接続されたコンピューター上の許可されたファイルとツールを使用できます。ローカルコンピューターアクセスは、機能ごとに個別に有効にしてください。

まず、以下の共通のポリシー、互換性、監査に関するガイダンスを確認してから、有効にする機能に応じて Work または dots の設定とエンドユーザー向けのガイダンスに従ってください。

このガイドは、Enterprise ワークスペースの所有者がポリシー要件を確認し、Work と dots のローカルコンピューターアクセスを有効にするためのものです。利用可否は、ワークスペースとロールアウト状況によって異なります。

Global のベースライン、環境別のオーバーライド、オーケストレーターとエグゼキューターのフィールド一覧については、Agent Securityを参照してください。

ローカルコンピューターアクセスのメリット

これらの機能でローカルコンピューターアクセスを有効にすると、チームはデバイスを切り替えて作業を継続できます。管理者は、ローカルコンピューターでの実行について、サポートされている要件を Agent Security で一元管理できます。これらの実行要件は、Work がクラウドコンテナーを使用する場合や、dot がクラウドコンピューターを使用する場合には適用されません。クラウドでの実行には、ブラウザーアクセス、ネットワークアクセス、コンピューター操作に対する個別のコントロールが使用されます。

Work

  • 1 つの Work の会話を複数のデバイスで継続できます。 コンピューターで開始し、その後 Web またはモバイルアプリで結果を確認したり、追加の指示を出したりできます。Work Cloud でローカルコンピューターアクセスを使用するタスクは、クラウドで調整されます。

  • コンピューター上の承認済みリソースを使用できます。 この機能を使用するタスクは、接続されたコンピューターを通じて、許可されたローカルファイルとツールを使用できます。その間、別のデバイスから進行状況を確認できます。そのコンピューターを必要とするステップでは、オンラインで接続された状態を維持してください。

  • ローカル実行の要件を一元管理できます。 ローカル実行について、サポートされている Enterprise の要件を Agent Security で設定します。クラウド実行については、Work Cloud のポリシーを別途確認してください。

Dots

  • エンジニアリング作業をローカルで実行できます。 許可されたローカルリポジトリ、開発者ツール、スキルを使用して、バグの調査、変更の実装、ビルドの実行を行えます。

  • コーディング作業を調整できます。 ローカルの Work または Codex のスレッドを作成し、既存のローカル Codex スレッドを制御できます。

  • サポートされているタスクにデスクトップアプリとローカルブラウザーを使用できます。 これには、クラウドブラウザーでは完了できず、ローカルでのサインインが必要なタスクも含まれます。

Work Cloud のローカルコンピューターアクセスを有効にする前と後

タスクは、調整と実行の 2 つの部分から成ります。調整では、どのステップを実行するかを決め、会話を進めます。実行は、シェルコマンドの実行など、ツールによって行われる作業です。この機能は、調整を OpenAI のクラウドに移します。すべてのツールやファイルをコンピューターの外に移すわけではありません。

項目 この機能を有効にする前 この機能を有効にした後
ローカルの Work の会話の継続 利用可能な場合、メンバーはローカルまたはクラウドの Work スレッドを選択します。 メンバーが Cloud を選択すると、対象となる新しい会話はクラウドで調整され、デバイスを切り替えて継続できます。Local を選択すると、調整と実行はどちらも引き続きローカルで行われます。Enterprise では、提供開始時点でアプリ内の Local/Cloud 切り替えとそのデフォルト設定は変わりません。
タスクの調整 既存のローカルまたはクラウドのワークフローが適用されます。 OpenAI のクラウドが Work のタスクを調整します。
ユーザーのコンピューターを必要とするステップ ローカルの Work はコンピューターのツールとファイルを使用できます。クラウドの Work はそのコンピューターを使用できません。 引き続きそのコンピューターがツールとファイルを提供するため、オンラインで接続された状態である必要があります。
Enterprise の要件 既存のローカル要件と優先順位がローカルの Work に適用されます。 接続されたコンピューターにはローカル実行の要件が適用されます。管理ポリシーが有効な場合、サポートされている Global ポリシーがクラウドオーケストレーションに適用されます。Work のクラウドコンテナーは、独自の実行設定と要件を使用します。
ローカル実行のコントロール サポートされているデバイスとオペレーティングシステムのコントロールが適用されます。 ローカル実行では、MDM と従来の管理対象デバイスの要件が Agent Security より優先されます。システム要件ファイルの優先順位は Agent Security より低くなります。
Codex 既存の Codex の動作が適用されます。 Codex の動作と会話履歴は引き続き別に扱われます。

ローカルコンピューターアクセスの設定方法

Agent Security でポリシーを確認する

確認する場所

管理コンソール → Agent Security を開きます。Agent Security は「ポリシーと設定」に代わるものです。そのロールアウトは、Work と dots のローカルコンピューターアクセスとは独立しています。

  • ポリシー設定: Global のベースラインと Local のオーバーライドを確認します。承認や Web 検索を含むオーケストレーターのコントロールは Global に設定してください。環境側でこれらをオーバーライドすることはできません。許可する承認ポリシー や許可する Web 検索モード など、専用の UI コントロールがある場合はそれを使用し、その他のサポート対象フィールドには TOML を使用します。各設定の適用範囲については、オーケストレーターとエグゼキューターのコントロールを参照してください。

  • 要件とデフォルト値: 要件は、ユーザーがオーバーライドできない制限を定めます。デフォルト値は、その制限内での初期値を提供するもので、要件をオーバーライドすることはできません。

  • 機能へのアクセス: ワークスペース設定 → 権限とロールを使用します。ローカルコンピューターアクセスは、Work と dots それぞれについて個別にオプトインする必要があります。

引き継がれる内容

対象となる従来のクラウドポリシーを移行すると、その設定は Global に引き継がれ、ポリシーの割り当てと順序は維持されます。Agent Security で移行済みのポリシーを確認し、以下の表を使って現在の設定を確認してください。ポリシーの更新を自動化している場合は、最後の行も確認してください。移行のガイダンスについては、Agent Securityを参照してください。

現在の設定 この機能を有効にする前に行うこと
既存のクラウドポリシー 移行された Global のベースラインを、組織で必要なコントロールと比較します。設定を記録し、許可されたアクションが成功し、制限されたアクションがブロックされることをテストします。
MDM のみを通じて配信されるポリシー MDM はデバイスにポリシーを配信します。この機能を有効にする前に、ローカル実行でサポートされている Enterprise の要件を Agent Security で設定します。ローカル実行では、MDM と従来の管理対象デバイスの要件が引き続き Agent Security より優先されます。
Terraform またはポリシー更新スクリプト Global の設定を管理するには、ポリシー API を使用します。Local または Codex Cloud の設定を管理するには、Agent Security の UI を使用します。既存の Global API ワークフローは移行後も利用できます。スクリプトと Terraform の連携をテストし、ポリシーの割り当てと順序が変わっていないことを確認してください。

どのポリシーが優先されるか

これらのルールは、異なるレベルに適用されます。以下の各矢印は、優先順位の高いものから低いものへの順序を示します。

  • ポリシー間: 優先順位の低いポリシーの方が具体的であっても、優先順位の高いポリシーが優先されます。

  • 1 つのポリシー内: サポートされている実行設定では、環境別のオーバーライド → Global の順に優先されます。オーバーライドのない環境は、該当する Global の設定を継承します。

  • ローカル要件: macOS MDM の要件 → 要件として解釈される従来の managed_config.toml フィールド → Agent Security のクラウド管理要件 → システムの requirements.toml の順に優先されます。MDM レイヤーは macOS に適用されます。デフォルト値には、別の設定ルールが適用されます。

一部の要件には、フィールド固有のマージルールがあります。ポリシーのスコープ、サポートされているフィールド、実行のスコープについては、管理対象設定と設定リファレンスを参照してください。

Work と dots へのポリシーの適用方法

ローカルアクセスを使用する Work と dots に共通する動作は、以下のスコープにわたります。

  • タスクの調整: 管理ポリシーが有効な場合、タスクを調整するクラウドサービスは、承認要件や許可された Web 検索モードなど、Agent Security の Global でサポートされている要件を適用します。

  • ローカル実行: ツールが接続されたコンピューターで実行されると、Agent Security でサポートされているローカル実行要件と、該当するデバイスポリシーが適用されます。サポートされている場合は、MDM を通じて配信されるポリシーも含まれます。これらには、ファイルシステムとネットワークの制限が含まれる場合があります。適用されるのはローカルエグゼキューターがサポートするフィールドのみです。MDM またはローカルの requirements.toml でフィールドを設定しても、ローカルで適用されるとは限りません。

  • クラウド実行: Work のクラウドコンテナーと dots のクラウドコンピューターは、個別の実行コントロールを使用します。ローカルのファイルシステムとネットワークの制限は、これらのクラウド環境には自動的に適用されません。

共通のクラウド機能を設定するには、管理コンソール → 権限とロール → ワークスペース機能 → クラウドコンピューター機能に移動します。これらの権限は、Work Cloud と dots の両方に適用されます。クラウドブラウザーの使用 とクラウドネットワークアクセス は個別に確認してください。一方を設定しても、もう一方は設定されません。Global ポリシーと Codex Cloud のオーバーライドでは、これらの権限は設定されません。

互換性とデータ要件を確認する

いずれの機能を有効にする場合も、その前に、利用条件、データの適用範囲、組織が依存するコントロールを確認してください。共通のインフラストラクチャを使用していても、Work と dots のサポート内容が同一とは限りません。

Work と dots の利用条件を確認する

  • Work: レジデンシーは、対象となるコンテンツと、サポートされているワークロード、リージョン、設定にのみ適用されます。EKM は、対象となるワークスペースに保存された、サポート対象のコンテンツを保護します。すべてのローカルアクセスのステップや接続された連携が対象であると想定せず、ワークフローの適用範囲を確認してください。Work は UAE の推論レジデンシーではサポートされていません。データレジデンシーと推論レジデンシー、および Work のクラウドセキュリティを参照してください。

  • Dots のレジデンシー: Enterprise ベータ期間中、dots はデータレジデンシーと推論レジデンシーをサポートしていません。対象となるワークスペースは、これらの制限を了承したうえでオプトインできます。dots を有効にしても、そのデータや処理がレジデンシー要件に準拠するわけではありません。

  • Dots の対象外条件: Dots は、FedRAMP ワークスペース、EKM を使用するワークスペース、推論レジデンシーが AE(UAE)に設定されているワークスペースでは利用できません。HIPAA ワークスペースは、その他の利用条件を満たしていれば参加できます。

データの取り扱いとローカルアクセスの保護措置を確認する

  • クラウド処理: ローカルアクセスを使用する Work と dots も、クラウドでの調整を使用します。会話、ツールの結果、その他のタスクのコンテキストが、接続されたコンピューター内だけに留まるわけではありません。

  • レジデンシーの保護措置: いずれかのクラウドポリシーで enforce_residency が有効になっている場合、Work と dots のどちらでもローカルコンピューターアクセスを許可 は利用できません。この保護措置はワークスペースのレジデンシーを設定するものではなく、これだけで Work Cloud や dots を無効にすることもありません。対象となるワークスペースは、ベータ版のレジデンシーに関する制限を了承したうえで、引き続き dots にオプトインできます。ただし、ローカルアクセスはブロックされたままです。

  • データの保持とアクセス: どちらの機能も、厳密なゼロデータ保持を提供するものではありません。API Zero Data Retention は、API 向けの別のコントロールです。「Eyes-off」に関する確約と不正使用監視のコントロールも、ゼロデータ保持とは異なります。ワークフローでデータを一切保持しないことが必要な場合は、これらの機能でそのワークフローを有効にしないでください。

ロールアウト前に、実際に使用するデータとツールについて、保持、削除、監査の適用範囲を確認してください。Work では、会話、ホストされた実行状態、ファイル、接続されたアプリのデータが、それぞれ異なるライフサイクルに従う場合があります。会話を削除しても、関連するすべてのコピーが削除されるわけではありません。

フックとネットワークの互換性を確認する

  • サポートされている Enterprise フック: 管理ポリシーとリモートフックが有効な場合、ローカルアクセスを使用する Work Cloud と dots は、管理者が管理するリモート MCP フックを使用します。クラウドオーケストレーターは、サポートされているタスクイベントとツールイベントで、接続された MCP サービスを呼び出します。Global の requirements.toml に mcp_tool ハンドラーを設定してください。ローカルアクセスを使用しない Work Cloud は、これらのフックを使用しません。これらの Enterprise フックは、個人アカウントでは利用できません。

  • ローカルアクセスを使用する Work Cloud と dots: コマンド/シェル、プロンプト、エージェントの各ハンドラー、ローカル設定・プラグイン・ローカルディレクトリからのフック、環境スコープのフック、SessionEnd MCP フックは、タスクがコンピューター上でツールを実行する場合でも、クラウドオーケストレーションではサポートされません。ワークフローがこれらのフックのいずれかに依存している場合は、代替手段を検討するまで、そのフックをサポートするローカルのみのワークフローを引き続き使用してください。

  • Work と Codex のローカルのみのスレッド: オーケストレーションと実行の両方がローカルの場合、既存のサポート対象フックは引き続き動作します。管理者は、このワークフローでサポートされている管理対象フックを、引き続き Agent Security で設定できます。

  • 失敗時の動作と監査の適用範囲: コールバックの接続性、必要なイベント、失敗時の動作をテストしてください。サポートされている明示的な拒否はアクションをブロックできますが、PreToolUse コールバックのエラー、タイムアウト、不正な形式の応答では、ツールをブロックせずにフックだけが失敗する場合があります。フックは完全な Compliance API の監査証跡を提供するものではなく、内部サブエージェントのすべての経路を網羅するものでもありません。

  • ネットワークとアプリのコントロール: 設定リファレンスで、フィールド、配信経路、実行環境を確認してください。クラウドオーケストレーターが設定を使用しない場合でも、アプリやデバイスによって適用されるコントロールは引き続き有効な場合があります。管理対象の HTTP/SOCKS リスナーポートと、ループバック以外のプロキシリスナーは、クラウドランタイムではサポートされていません。ソケットルールのサポートは実行経路によって異なります。ネットワークポリシーの優先順位とランタイムの制限を確認してから、許可されるアクションとブロックされるアクション、および必要な接続性をテストしてください。

ローカルファイル、クラウド実行、ポリシーの優先順位に関する質問については、Work 管理者向け FAQ、Work のローカルセキュリティ、Work のクラウドセキュリティを参照してください。

ローカルコンピューターアクセスを有効にする

ローカルコンピューターアクセスは、Work と dots で個別に付与します。ワークスペースのデフォルト設定と、サポートされているカスタムロールを使用して、対象のユーザーまたはグループにアクセスを付与してください。

ロールアウト前に、上記のポリシーと互換性要件を確認してください。Agent Security でポリシーを確認または作成することをおすすめしますが、確認フローでは、アクセスを有効にする前にポリシーを作成することは必須ではありません。ポリシーを移行しても、ローカルコンピューターアクセスは付与されません。

Work

  1. ワークスペースの所有者として、ワークスペース設定 > 権限とロール を開きます。

  2. 対象のユーザーに対して Work Cloud を有効にします。ChatGPT デスクトップアプリで Codex をローカルで使用 は、この機能の前提条件ではありません。

  3. Work Cloud の下で、ローカルコンピューターアクセスを許可 をオンにします。確認モーダルの内容を確認し、Agent Security を開いてポリシーを確認または設定するか、確定してアクセスをオンにします。

  4. ユーザーに ChatGPT デスクトップアプリをバージョン 26.929 以降に更新してもらいます。Work Cloud のローカルコンピューターアクセスを有効にするには、この更新が必要です。

  5. 対象の権限を持つメンバーに、デスクトップの入力欄で Cloud を選択し、新しいタスクを開始してもらいます。サポートされている別のデバイスからタスクを続け、コンピューターが接続されている間に、承認済みのローカルファイルまたはツールにアクセスできることを確認します。

Dots

  1. ワークスペースの所有者として、ワークスペース設定 > 権限とロール を開き、上記の利用条件に従って、対象のユーザーに対して dots を有効にします。

  2. Dots を使用 の下で、ローカルコンピューターアクセスを許可 をオンにします。確認モーダルの内容を確認し、Agent Security を開いてポリシーを確認または設定するか、確定してアクセスをオンにします。

  3. ユーザーに ChatGPT デスクトップアプリをバージョン 26.929 以降に更新してもらいます。ローカルコンピューターアクセスを有効にするには、この更新が必要です。

  4. ユーザーに ChatGPT デスクトップアプリで自分の dot の詳細を開き、コンピューター を選択してもらいます。自分のコンピューター(またはコンピューター名)を見つけて許可 を選択し、アクセスを許可 で確定します。

  5. 対象の権限を持ち、コンピューターを接続しているメンバーに、自分の dot でローカルタスクをテストしてもらいます。

OpenTelemetry と監査の適用範囲を確認する

ローカルアクセスを使用する Work と dots について OpenTelemetry(OTel)の適用範囲を確認する際は、ローカル実行のテレメトリーとクラウドの監査記録を区別してください。ローカルエグゼキューターは、サポートされている実行イベントを引き続きエクスポートできます。クラウドオーケストレーションのイベントは、既存の OpenTelemetry コレクターには届きません。

サポートされているクラウドの記録には、Compliance API を使用してください。コレクターのエンドポイントを変更しても、クラウドオーケストレーションのイベントを再び受信できるようにはなりません。Compliance API の記録は、以前の OpenTelemetry ストリームのすべてのイベントを置き換えるものではありません。

dots では、利用状況には Analytics API、サポートされている監査記録には Compliance API を使用します。ローカルコレクターへの配信と併せて、ワークフローに必要な記録を検証してください。MCP フックは監査の代わりにはなりません。

クラウドの監査の適用範囲については、Work のクラウドセキュリティを参照してください。

エンドユーザーの利用体験

Work と dots のどちらでも、ローカルのステップを実行するには、対象のコンピューターがオンラインで接続されており、ChatGPT デスクトップアプリが起動して、適切なアカウントとワークスペースにサインインしている必要があります。

Work

  • 対象となるタスク。 ChatGPT デスクトップアプリで Cloud を選択して開始した、対象となる新しいタスクは、そのコンピューターが接続され、ローカルアクセスが有効になっている間、そのコンピューターのローカルエグゼキューターを使用できます。

  • サインイン。 目的のワークスペースで「ChatGPT でサインイン」を使用してください。API key と Codex アクセストークンでは、Work Cloud のローカルコンピューターアクセスを有効にできません。

  • コンピューターを利用できない場合。 新しいターンの開始時にコンピューターを利用できない場合、既存の対象タスクは、そのコンピューターのローカルファイルやツールを使用せずに、クラウドコンテナーで継続できます。このコンテナーには、ローカル実行の Enterprise 要件は適用されません。タスクは、ターンの途中でローカル実行からクラウドに切り替えることはできません。

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

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

  • Local/Cloud 設定。 Enterprise では、提供開始時点でアプリ内の Local/Cloud 切り替えとそのデフォルト設定は変わりません。Cloud を選択した対象タスクは、クラウドでの調整を使用し、ローカルのステップには接続されたコンピューターを使用します。

Dots

  • コンピューターを接続する。 ChatGPT デスクトップアプリで dot の詳細を開き、「コンピューター」を選択します。「自分のコンピューター」(またはコンピューター名)を見つけて許可 を選択し、「アクセスを許可」で確定します。そのコンピューターを、サポートされているローカルタスクに使用できるようになります。

  • コンピューターがオフラインの場合。 保存されたアクセス許可は維持されますが、そのコンピューターを必要とする作業は、コンピューターを利用できない間は進められません。「オフライン」は、アクセスが取り消されたことを意味しません。

  • アクセスを削除する。 「アクセスを取り消す」を選択して確定すると、そのコンピューターに対する dot のアクセス許可が削除されます。「切断済み」はアクセスが削除されたことを意味し、「オフライン」とは異なります。

  • 管理者によるアクセスの変更。 管理者が dots のローカルコンピューターアクセスを無効にしても、すでに認可されたローカルタスクは、完了に向けて動作を続けている場合があります。実行中のターンを直ちに中断する Work の動作が、dots にも適用されると考えないでください。

  • 実行中のタスク。 実行中のローカルタスクが、自動的にクラウドに移行することはありません。接続の変更によって、作業が中断されたり、ランタイムが再読み込みされたりする場合があります。dot は後続の作業を自身のクラウドコンピューターで続けることがありますが、アクセスを失ったローカルの子タスクは、そのコンピューター上で再開できず、自動的にクラウドへ移動することもありません。