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

Work と dot は、OpenAI のクラウドがタスクの進行を管理する間、接続先のコンピューターで使用が許可されているファイルやツールを利用できます。ローカルコンピューターへのアクセスは、機能ごとに有効にします。

まず、以下の共通ポリシー、互換性、監査に関する説明を確認してください。次に、有効にする機能に応じて、Work または dot の設定手順とエンドユーザー向けの説明を参照してください。

このガイドでは、企業のワークスペースオーナーがポリシー要件を確認し、Work と dot でローカルコンピューターへのアクセスを有効にする手順を説明します。利用できる機能は、ワークスペースとロールアウトの状況によって異なります。

グローバルの基本設定、環境別の上書き設定、オーケストレーターとエグゼキューターのフィールド一覧については、エージェントセキュリティを参照してください。

ローカルコンピューターへのアクセスの利点

これらの機能でローカルコンピューターへのアクセスを有効にすると、チームはデバイスを切り替えて作業を続けられます。管理者は、ローカルコンピューターでの実行に適用できる要件をエージェントセキュリティで一元管理できます。Work がクラウドコンテナを使用する場合や、dot がクラウドコンピューターを使用する場合、これらの実行要件は適用されません。クラウドでの実行には、ブラウザへのアクセス、ネットワークアクセス、コンピューターの使用に関する別の制御が適用されます。

Work

メンバーはデバイスを切り替えて Work を続けることができ、接続先のコンピューターを通じて承認済みのローカルリソースを利用できます。管理者は、エージェントセキュリティでローカル実行要件を管理し、クラウドでの実行については別途確認できます。

dot

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

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

• 対応するタスクでのデスクトップアプリとローカルブラウザの利用　クラウドブラウザでは完了できず、ローカルでのサインインが必要なタスクにも対応します。

Work Cloud でローカルコンピューターへのアクセスを有効にした場合の変更点

タスクには、進行管理と実行という 2 つの側面があります。進行管理では、次に行うステップを決めて会話を進めます。実行とは、シェルコマンドの実行など、ツールが行う作業を指します。この機能を有効にすると、進行管理は OpenAI のクラウドに移りますが、すべてのツールやファイルがコンピューターの外に移るわけではありません。

ローカルコンピューターへのアクセスの設定手順

エージェントセキュリティでのポリシーの確認

設定の確認場所

「管理コンソール」→「エージェントセキュリティ」を開きます。「エージェントセキュリティ」は従来の「ポリシーと設定」に代わるものです。Work と dot のローカルコンピューターへのアクセスとは別にロールアウトされます。

• ポリシー設定： グローバルの基本設定と、ローカル環境の上書き設定を確認します。承認やウェブ検索など、オーケストレーターの制御はグローバルで設定してください。環境ごとに上書きすることはできません。許可する承認ポリシーや許可するウェブ検索モードなど、専用の UI がある項目はそこで設定し、それ以外の対応フィールドは TOML で設定します。各設定の適用範囲は、オーケストレーターとエグゼキューターの制御を参照してください。

• 要件とデフォルト値： 要件は、ユーザーが上書きできない制限を定めます。デフォルト値は、その制限内での初期値です。デフォルト値で要件を上書きすることはできません。

• 機能へのアクセス： 「管理コンソール」→「権限」で設定します。ローカルコンピューターへのアクセスは、Work と dot で個別に有効にします。

移行時に引き継がれる設定

移行対象の従来のクラウドポリシーは、割り当てと順序を維持したまま、設定がグローバルに引き継がれます。エージェントセキュリティで移行後のポリシーを確認し、以下の表で現在の構成に応じた確認事項を参照してください。ポリシー更新を自動化している場合は、最後の行も確認してください。移行については、エージェントセキュリティを参照してください。

ポリシーの優先順位

優先順位のルールは、適用するレベルによって異なります。以下の矢印は、優先順位が高いものから低いものへの順序を示します。

• ポリシー間： 優先順位の低いポリシーのほうが具体的でも、優先順位の高いポリシーが優先されます。

• 同一ポリシー内： 対応する実行設定の優先順位は、環境別の上書き設定 → グローバル設定です。上書き設定がない環境は、該当するグローバル設定を継承します。

• ローカル要件： macOS の MDM 要件 → 要件として解釈される従来の managed_config.toml のフィールド → エージェントセキュリティでクラウド管理される要件 → システムの requirements.toml の順です。MDM の要件は macOS に適用されます。デフォルト値には別の設定ルールが適用されます。

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

Work と dot へのポリシーの適用範囲

ローカルアクセスを使用する Work と dot には、以下の共通ルールが適用されます。

• タスクの進行管理： 管理対象ポリシーが有効な場合、タスクの進行を管理するクラウドサービスが、エージェントセキュリティのグローバル設定のうち、対応する要件を適用します。たとえば、承認要件や許可されるウェブ検索モードが該当します。

• ローカル実行： ツールが接続先のコンピューターで動作する場合、エージェントセキュリティの対応するローカル実行要件と、そのデバイスに適用されるポリシーに従います。MDM に対応する環境では、MDM で配信されたポリシーも対象です。これらには、ファイルシステムやネットワークの制限が含まれる場合があります。適用されるのは、ローカルエグゼキューターが対応するフィールドのみです。MDM やローカルの requirements.toml にフィールドを設定しても、ローカルでの適用が保証されるわけではありません。

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

互換性とデータ要件の確認

どちらの機能も、有効にする前に利用条件、対象となるデータ、組織が必要とする制御を確認してください。Work と dot はインフラストラクチャを共有していますが、対応範囲は異なります。

Work と dot の利用条件

• Work： レジデンシーは、対象コンテンツと、対応するワークロード、リージョン、構成にのみ適用されます。EKM の対象は、利用条件を満たすワークスペースに保存された対応コンテンツです。ローカルアクセスを使うすべてのステップや接続済みの連携先が対象とは限らないため、実際のワークフローで適用範囲を確認してください。推論レジデンシーを UAE に設定した環境では、Work は利用できません。データレジデンシーと推論レジデンシーおよび Work のクラウドセキュリティを参照してください。

• dot のレジデンシー： Enterprise ベータ期間中、dot はデータレジデンシーにも推論レジデンシーにも対応していません。利用条件を満たすワークスペースは、これらの制限を了承したうえで利用を開始できます。dot を有効にしても、そのデータや処理がレジデンシー要件に準拠するわけではありません。

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

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

• クラウドでの処理： ローカルアクセスを使用する Work と dot でも、タスクの進行はクラウドが管理します。会話、ツールの実行結果、その他のタスクのコンテキストは、接続先のコンピューターの外でも扱われます。

• レジデンシーの保護措置： いずれかのクラウドポリシーで enforce_residency が有効な場合、Work と dot のどちらでも「ローカルコンピューターへのアクセスを許可」は利用できません。この保護措置は、ワークスペースのレジデンシーを設定するものではなく、それだけで Work Cloud や dot が無効になることもありません。利用条件を満たすワークスペースは、ベータ版のレジデンシーに関する制限を了承すれば dot の利用を開始できますが、ローカルアクセスは引き続きブロックされます。

• データの保持とアクセス： どちらの機能も厳密なゼロデータ保持には対応していません。API のゼロデータ保持は、API 向けの独立した制御です。人がデータを閲覧しないという確約や、不正利用の監視に関する制御も、ゼロデータ保持とは異なります。データを一切保持しないことが要件となるワークフローでは、これらの機能を有効にしないでください。

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

フックとネットワークの互換性

• フックの互換性： ローカルアクセスを有効にする前に、ワークスペースの設定とエージェントセキュリティに互換性に関する警告が表示されていないか確認し、表示されている場合は内容を確認してください。ワークフローに必要なフックを、クラウドでのオーケストレーションに対応するフックと照合してください。ローカルコマンドやプラグインのフックに依存するワークフローは、引き続きローカルでのみ実行してください。

• 障害時の動作と監査範囲： コールバックの接続、必要なイベント、コールバックでエラーやタイムアウトが発生した後のツールの動作をテストしてください。PreToolUse フックが失敗しても、ツールが実行される場合があります。フックでは、内部サブエージェントのすべての実行経路を網羅できません。取得できる監査記録も別途確認してください。

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

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

ローカルコンピューターへのアクセスの有効化

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

ロールアウト前に、上記のポリシーと互換性の要件を確認してください。エージェントセキュリティでのポリシーの確認または作成を推奨しますが、アクセスを有効にする際の確認手順では、事前にポリシーを作成しておく必要はありません。ポリシーを移行しても、ローカルコンピューターへのアクセス権は付与されません。

Work

1. ワークスペースオーナーとして、管理コンソール > 権限を開きます。

2. 対象ユーザーの Work Cloud を有効にします。この機能を利用するために、ChatGPT デスクトップアプリで Codex をローカルで使用を有効にする必要はありません。

3. Work Cloud の下にあるローカルコンピューターへのアクセスを許可をオンにします。確認ダイアログの内容を確認し、エージェントセキュリティを開いてポリシーを確認または設定するか、そのまま確定してアクセスを有効にします。

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

5. 対象の権限を持つメンバーに、デスクトップアプリのコンポーザーでクラウドを選び、新しいタスクを開始してもらいます。そのコンピューターを接続したまま、別の対応デバイスからタスクを続け、承認済みのローカルファイルまたはツールにアクセスできることを確認します。

dot

1. ワークスペースオーナーとして、管理コンソール > 権限を開き、上記の利用条件に従って対象ユーザーの dot を有効にします。

2. dot を使用の下にあるローカルコンピューターへのアクセスを許可をオンにします。確認ダイアログの内容を確認し、エージェントセキュリティを開いてポリシーを確認または設定するか、そのまま確定してアクセスを有効にします。

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

4. ユーザーに、以下の dot のエンドユーザー向け手順に従ってコンピューターを接続してもらいます。

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

OpenTelemetry と監査範囲の確認

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

対応するクラウドの記録は Compliance API で取得してください。コレクターのエンドポイントを変更しても、クラウドのオーケストレーションイベントは受信できません。Compliance API の記録では、従来の OpenTelemetry ストリームのすべてのイベントを代替できるわけではありません。

dot の利用状況には Analytics API を、対応する監査記録には Compliance API を使用してください。ワークフローに必要な記録を取得できることと、ローカルコレクターにイベントが届くことの両方を確認してください。MCP フックは監査の代わりにはなりません。

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

エンドユーザー向けの手順と動作

Work と dot のどちらでも、ローカルでステップを実行するには、対象のコンピューターがオンラインかつ接続済みである必要があります。そのコンピューターで ChatGPT デスクトップアプリを起動し、対象のアカウントとワークスペースにサインインした状態を維持してください。

Work

メンバーは「ChatGPT でサインイン」を使って対象のワークスペースにサインインする必要があります。API キーや Codex アクセストークンでは、この機能を有効にできません。対象となるタスクの開始手順と、コンピューターがオフラインのときにタスクを続ける手順は、デバイスを切り替えて Work を続けるをメンバーに共有してください。この機能を無効にする前に、ロールバック手順を確認してください。

dot

• コンピューターの接続　ChatGPT デスクトップアプリで dot の詳細を開き、「コンピューター」を選択します。「お使いのコンピューター」（またはコンピューター名）を探して許可を選び、「アクセスを許可」で確定します。これで、対応するローカル環境のタスクでそのコンピューターを使用できます。

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

• アクセス権の取り消し　「アクセスを取り消す」を選んで確定すると、そのコンピューターに対する dot のアクセス権が削除されます。「切断済み」はアクセス権が削除された状態を示し、「オフライン」とは異なります。

• 管理者によるアクセス設定の変更　管理者が dot のローカルコンピューターへのアクセスを無効にしても、すでに許可されたローカル環境のタスクは、完了まで処理を続けている場合があります。Work のように実行中のターンが直ちに中断されるとは限りません。

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