--- read_when: - operator スコープがないエラーのデバッグ - デバイスまたはノードのペアリング承認の確認 - Gateway RPC メソッドの追加または分類 summary: Gateway クライアント向けのオペレーターのロール、スコープ、および承認時チェック title: オペレーターのスコープ x-i18n: generated_at: "2026-05-04T05:00:23Z" model: gpt-5.5 provider: openai source_hash: f05d6bdbf9bdad2aef1c9664bb7ebb4b6241334b8aefac7993104e9977e40450 source_path: gateway/operator-scopes.md workflow: 16 --- オペレータースコープは、Gateway クライアントが認証後に何を実行できるかを定義します。 これは、1つの信頼された Gateway オペレータードメイン内のコントロールプレーンのガードレールであり、 敵対的なマルチテナント分離ではありません。人、チーム、またはマシンの間で強い分離が必要な場合は、 別々の OS ユーザーまたはホストの下で別々の Gateway を実行してください。 関連: [セキュリティ](/ja-JP/gateway/security), [Gateway プロトコル](/ja-JP/gateway/protocol), [Gateway ペアリング](/ja-JP/gateway/pairing), [デバイス CLI](/ja-JP/cli/devices). ## ロール Gateway WebSocket クライアントは、1つのロールで接続します。 - `operator`: CLI、Control UI、自動化、信頼されたヘルパープロセスなどのコントロールプレーンクライアント。 - `node`: `node.invoke` を通じてコマンドを公開する macOS、iOS、Android、またはヘッドレス Node などのケイパビリティホスト。 オペレーター RPC メソッドには `operator` ロールが必要です。Node 起点のメソッドには `node` ロールが必要です。 ## スコープレベル | スコープ | 意味 | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `operator.read` | 読み取り専用のステータス、リスト、カタログ、ログ、セッション読み取り、その他の非変更系コントロールプレーン呼び出し。 | | `operator.write` | メッセージ送信、ツール呼び出し、talk/voice 設定の更新、Node コマンドリレーなど、通常の変更系オペレーターアクション。`operator.read` も満たします。 | | `operator.admin` | 管理用コントロールプレーンアクセス。すべての `operator.*` スコープを満たします。設定変更、更新、ネイティブフック、機密性の高い予約済み名前空間、高リスク承認に必要です。 | | `operator.pairing` | ペアリングレコードまたはデバイストークンの一覧表示、承認、拒否、削除、ローテーション、失効を含む、デバイスおよび Node のペアリング管理。 | | `operator.approvals` | exec および Plugin 承認 API。 | | `operator.talk.secrets` | シークレットを含めた Talk 設定の読み取り。 | 未知の将来の `operator.*` スコープでは、呼び出し元が `operator.admin` を持っていない限り、 完全一致が必要です。 ## メソッドスコープは最初のゲートにすぎない 各 Gateway RPC には最小権限のメソッドスコープがあります。そのメソッドスコープは、 リクエストがハンドラーに到達できるかどうかを決定します。その後、一部のハンドラーは、 承認または変更される具体的な対象に基づいて、承認時により厳格なチェックを適用します。 例: - `device.pair.approve` は `operator.pairing` で到達できますが、オペレーターデバイスの承認で発行または保持できるのは、呼び出し元がすでに保持しているスコープだけです。 - `node.pair.approve` は `operator.pairing` で到達でき、その後、保留中の Node コマンドリストから追加の承認スコープを導出します。 - `chat.send` は通常、write スコープのメソッドですが、永続的な `/config set` および `/config unset` には、コマンドレベルで `operator.admin` が必要です。 これにより、低スコープのオペレーターは、すべてのペアリング承認を管理者専用にすることなく、 低リスクのペアリングアクションを実行できます。 ## デバイスペアリング承認 デバイスペアリングレコードは、承認済みロールとスコープの永続的な情報源です。 すでにペアリング済みのデバイスが、ひそかにより広いアクセス権を得ることはありません。より広いロールまたはより広いスコープを要求する再接続は、新しい保留中のアップグレードリクエストを作成します。 デバイスリクエストを承認する場合: - オペレーターロールを持たないリクエストでは、オペレータートークンスコープの承認は不要です。 - `operator.read`、`operator.write`、`operator.approvals`、 `operator.pairing`、または `operator.talk.secrets` のリクエストでは、呼び出し元が それらのスコープ、または `operator.admin` を持っている必要があります。 - `operator.admin` のリクエストには `operator.admin` が必要です。 - 明示的なスコープを持たない修復リクエストは、既存のオペレータートークンスコープを継承できます。その既存トークンが admin スコープの場合でも、承認には `operator.admin` が必要です。 ペアリング済みデバイストークンセッションでは、呼び出し元が `operator.admin` も持っていない限り、 管理は自己スコープです。非管理者の呼び出し元には自分自身のペアリングエントリのみが表示され、 自分自身の保留中リクエストのみを承認または拒否でき、自分自身のデバイスエントリのみをローテーション、失効、または削除できます。 ## Node ペアリング承認 レガシーの `node.pair.*` は、Gateway が所有する別個の Node ペアリングストアを使用します。WS Node は `role: node` でデバイスペアリングを使用しますが、同じ承認レベルの語彙が適用されます。 `node.pair.approve` は、保留中リクエストのコマンドリストを使用して、追加で必要なスコープを導出します。 - コマンドなしのリクエスト: `operator.pairing` - exec 以外の Node コマンド: `operator.pairing` + `operator.write` - `system.run`、`system.run.prepare`、または `system.which`: `operator.pairing` + `operator.admin` Node ペアリングは ID と信頼を確立します。これは Node 独自の `system.run` exec 承認ポリシーを置き換えるものではありません。 ## 共有シークレット認証 共有 Gateway トークン/パスワード認証は、その Gateway に対する信頼されたオペレーターアクセスとして扱われます。OpenAI 互換 HTTP サーフェスと `/tools/invoke` は、 呼び出し元がより狭い宣言済みスコープを送信した場合でも、共有シークレット bearer 認証に対して通常の完全なオペレーター既定スコープセットを復元します。 信頼されたプロキシ認証や private-ingress `none` などの ID 付きモードでは、 明示的な宣言済みスコープを引き続き尊重できます。実際の信頼境界の分離には、別々の Gateway を使用してください。