---
publishDate: 2026-07-04T17:05:00Z
lang: 'ja'
translationKey: 'remote-desktop-data-sovereignty-gdpr'
draft: false
title: 'リモートデスクトップのデータ主権とGDPR：セルフホスティングという選択肢'
excerpt: 'セルフホスティングによって、規制対象のチームはランデブーサーバー・リレー・デバイスデータをどこまで管理できるのか。そしてGDPRやコンプライアンスにおいてなお残る論点とは。'
image: '~/assets/images/blog/remote-desktop-data-sovereignty-gdpr-og.png'
category: 'セキュリティ'
tags: ['RustDesk', 'セキュリティ', 'GDPR', 'セルフホスティング']
author: 'RustDesk Team'
slug: "remote-desktop-data-sovereignty-gdpr-ja"
faq:
  - question: 'RustDeskはISO 27001、SOC 2、HIPAAに準拠していますか？'
    answer: 'RustDeskはセルフホスト型のため、コンプライアンスの中心はお客様自身の環境にあります。リモートアクセスはお客様自身のISO 27001やHIPAAの適用範囲および既存の管理策の中で運用され、オープンソースソフトウェアであるため、信頼に頼るのではなく直接監査することができます。ベンダー側のSOC 2レポート、署名済みのBAA、DPA、またはセキュリティ質問票への回答が具体的に必要な場合は、sales@rustdesk.comまでお問い合わせのうえ、お客様のシナリオに対応可能な内容をご確認ください。'
  - question: 'RustDeskをセルフホスティングすることはGDPR対応に役立ちますか？'
    answer: 'はい。GDPRが本来求めているコントロールを手に入れることができます。ID/ランデブーサーバー、リレー、コンソール、デバイスデータをどこに置くかを自ら選択し、自社が運用するインフラ上でリージョン内に保持できます。ただしこれは強力な土台ではあっても、自動的な保証ではありません。GDPRは一つのプログラムであり、法的根拠、管理者/処理者の役割、保持期間、アクセス制御、エンドポイントの所在地、インシデント対応などは依然として自社で定義する必要があり、管理者(コントローラー)としての責任は変わらず残ります。'
  - question: 'RustDeskのセッションデータは実際にはどこを通るのですか？'
    answer: 'RustDeskはまず直接のピアツーピア接続を試み、それが失敗した場合に設定済みのリレーを経由して通信します。セルフホスティングによって、ベンダーが運用するランデブーサーバーやリレーを経路から排除できますが、異なる国にあるエンドポイント間のセッションは、それでもそれらのネットワークを経由します。サーバーの設置場所だけでは、すべてのトラフィックを単一の法域内に収めることはできません。'
  - question: 'RustDeskを使ってリモートデスクトップのデータをEU域内にとどめることはできますか？'
    answer: 'ID/ランデブーサーバー、リレー、コンソール、保存されるデバイスデータをEU域内のデータセンターに配置することは可能です。セッションのトラフィックについても制約したい場合は、両方のエンドポイントが境界内にあり、かつポリシーによってトラフィックを承認済みのリレー経由に強制する必要があります。サーバーの設置場所とあわせて、エンドポイントの所在地と経路も文書化してください。'
  - question: 'GDPR対応に役立つRustDeskの機能は何ですか？'
    answer: 'セルフホスティングにより、データは自社が管理するインフラ上にとどまります。ホスト型のRustDeskサービスが処理するはずの利用テレメトリは、セルフホスティングすることで自社サーバー上にとどまり、Server Proのライセンス確認を除けば、rustdesk.comへ到達する必要のある通信はほとんどありません。Server Proには、ログローテーション機能を備えた監査ログ、きめ細かなアクセス制御とコントロールロール、SSO/LDAPおよび制御対象デバイスの2FA、プライバシーモードと接続ごとの同意確認、そして削除・保持要求に対応するためのユーザー・デバイス・記録の直接削除(REST API経由を含む)といった機能が追加されます。'
metadata:
  description: 'リモートデスクトップのデータ主権とGDPR：セルフホスティングで何が制御できるのか、直接接続とリレー経由のセッションはどう違うのか、そしてコンプライアンスにサーバーの設置場所以上のものが必要な理由を解説します。'
  keywords: 'リモートデスクトップ データ主権, GDPR リモートアクセス, リモートデスクトップ データレジデンシー, セルフホスト型リモートアクセス コンプライアンス'
---

自社がGDPR、医療分野のプライバシー規制、あるいは「データは自社インフラ内にとどめる」という公共部門の義務に縛られている場合、どのリモートデスクトップツールを候補に入れられるかは、たった一つの問いで決まります。**セッションデータは実際にはどこを通るのか？**

主流のリモートアクセス製品の多くでは、その答えは「ベンダーのクラウドを経由する」です。技術者が接続し、エンドポイントが接続すると、そのトラフィックは自社が所有しておらず、場合によっては管理も及ばない法域にあるサーバーによって仲介されます。多くの購入者にとってはそれで問題ありません。しかし規制対象のチームにとっては、誰かが画面を共有する前からすでにコンプライアンス上の問題なのです。

本ガイドのテーマは**リモートデスクトップのデータ主権**です。それが何を意味するのか、規制対象やEUの購入者にとってなぜ重要なのか、そしてリモートアクセス導入のどの部分をセルフホスティングによってコントロールできるのかを取り上げます。具体例としてRustDeskを使用します。

## リモートアクセスにおける「データ主権」の意味

データ主権とは、データが物理的に保存・処理されている国の法律に従うという原則です。リモートサポートにおいて機密性が高いのは、転送するファイルだけではありません。セッションそのもの、つまり画面に表示される内容、管理しているデバイスの一覧、接続に関するメタデータ、そして多くの場合リアルタイムで転送される画面のピクセルデータの経路も含まれます。

核心となる問いは次のとおりです。**どのシステムがメタデータを保存し、どのシステムがトラフィックを中継し、両方のエンドポイントはどこにあるのか？** セルフホスティングは、ベンダーが運用するランデブーサーバーやリレーサービスを経路から排除できますが、異なる国にあるエンドポイント間のセッションが単一の法域内にとどまることまでは保証できません。

## 本質的な違い：ベンダーのクラウド vs. 自社インフラ

ここで結果を左右するのは、マーケティングではなくアーキテクチャです。

**RustDesk Server Proはセルフホスト型です。** ID/ランデブーサーバー、リレーサーバー、Webコンソール、管理対象デバイスのデータは、お客様が選択したインフラ上で稼働します。RustDeskはまずホールパンチングによる直接のピアツーピア接続を試み、それが失敗した場合はセッショントラフィックが設定済みのリレーを経由します。これによりランデブー/リレー層と保存されるデバイスデータをコントロールできますが、直接通信がどこを通るかは、依然としてエンドポイントとそのネットワーク経路によって決まります。

|                              | ベンダークラウド型ツール | セルフホスト型RustDesk                                                                          |
| ---------------------------- | ------------------------ | ----------------------------------------------------------------------------------------------- |
| セッションの調整場所         | ベンダーのクラウド       | 自社のID/ランデブーサーバー                                                                     |
| セッショントラフィックの経路 | ベンダーが定める経路     | 可能な場合はエンドポイント間で直接通信、それ以外は自社のリレーを経由                            |
| データレジデンシーの管理主体 | ベンダー                 | サーバー側の設置場所とリレーポリシーを自社で選択(エンドポイントも依然として重要)                |
| クライアントの監査可能性     | 通常はクローズドソース   | [オープンソース(AGPL)](https://github.com/rustdesk/rustdesk) — 自分でコードを読み、ビルドできる |
| サーバーの運用者             | ベンダー                 | 自社チーム                                                                                      |

セルフホスティングを検討するチームは、ランデブーサーバー、リレー、管理システムの設置場所と運用者を自ら選択できる点をよく挙げます。これは意味のあるコントロールですが、エンドポイントの所在地や経路の挙動とあわせて文書化する必要があります。

## メリット1：サーバー側のデータ設置場所をコントロールできる

ID、リレー、管理サービスをドイツのデータセンターに配置すれば、それらのサービスと保存データがどこに存在するかを文書化できます。両方のエンドポイントも必要な境界内にあり、かつポリシーによってトラフィックが承認済みのリレーを経由するよう強制されていれば、より制約された経路を設計できます。こうした追加のコントロールがなければ、サーバーの設置場所だけでは、すべてのセッショントラフィックがドイツ国内にとどまることは保証されません。

## メリット2：オープンソースだから「信じる」のではなく「証明できる」

データ主権は設置場所だけの問題ではなく、ソフトウェアが何をしているかを知ることでもあります。RustDeskのコアは**AGPLの下でオープンソース化**されています。お客様(またはセキュリティチーム)は、コードを読み、クライアントが正確に何を行っているかを監査し、自分でビルドし、無料のコミュニティサーバーを無期限に運用できます。この監査可能性は、リモートアクセスにおいて通常以上の重みを持っています。ソフトウェアにはマシンを完全に制御する権限が委ねられるため、規制の厳しい業界の購入者は、ベンダーの言葉をうのみにするのではなく、クライアントが何を行っているかを自ら検証したいと考えることが増えています。クライアントを自ら検証できることは、「それをどうやって確認するのか」という問いに対する具体的な答えになります。

## メリット3：主権の確保に「ライセンス税」は不要

RustDeskの標準プランは**ログインユーザー数と管理対象デバイス数**に応じてライセンスされ、同時接続数は無制限です。一方[Customized V2](https://rustdesk.com/pricing#custom2)は、同時接続数に上限を設けて課金する方式です。要件の変化に応じて[ライセンスをアップグレード](/ja/blog/upgrade-rustdesk-license-mid-subscription-ja)することもできます。購入前に最新のプラン一覧をご確認ください。

このアーキテクチャは規模の拡大にも対応します。RustDeskは、より大規模な導入を検討するチーム向けに[大規模フリート向けの計画ガイダンス](/ja/blog/rustdesk-scale-50000-200000-devices-ja)を公開しています。[ユーザー単位のアクセス制御](https://rustdesk.com/docs/ja/self-host/rustdesk-server-pro/permissions/)については、セルフホスト型の導入に[Webコンソール](https://rustdesk.com/docs)、カスタムブランドのクライアント生成機能、共有アドレス帳を備えたデバイスグループ、そしてBasicプラン以上で利用可能な[LDAP/SSO](https://rustdesk.com/docs/ja/self-host/rustdesk-server-pro/ldap/) (OIDC)が含まれます。

## RustDeskがISO 27001、SOC 2、HIPAA要件にどう適合するか

企業の調達部門や医療分野のチームは、リモートアクセスツールがISO 27001、SOC 2、HIPAAにどう対応するかをほぼ必ず尋ねます。クラウド製品の場合、お客様は*ベンダー自身の*インフラに対する認証を引き継ぎ、それに依存することになります。RustDeskのモデルはこれとは異なり、規制対象のチームにとってこの違いは通常有利に働きます。**セルフホスティング**するため、リモートアクセスはお客様がすでに管理・監査している環境内で稼働し、第三者のものではなく*お客様自身の\_ISO 27001やHIPAAの適用範囲、そして*お客様自身の\_既存の管理策の下に置かれます。ID、リレー、コンソールは、お客様のプログラムがすでにカバーしているインフラ上に配置でき、さらにRustDeskは[オープンソース](https://github.com/rustdesk/rustdesk)であるため、セキュリティチームはクローズドなバイナリを信頼する代わりに、評価の一環としてそれが正確に何を行っているかを読んで検証できます。

実務上のポイントをいくつか挙げます。

- セルフホスティングにより、機密性の高いシステム(ランデブーサーバー、リレー、コンソール、デバイスデータ)は自社が所有するハードウェア上にとどまります。これはまさに、データレジデンシーやHIPAAの管理策が通常保証しようとしていることです。この後に掲載する導入チェックリストが、それを文書化されたコントロールへと落とし込みます。
- 調達要件としてベンダー側のSOC 2レポート、署名済みの業務提携契約(BAA)、DPA、またはセキュリティ質問票への回答が具体的に必要な場合は、[sales@rustdesk.com](mailto:sales@rustdesk.com)のRustDeskチームに、お客様のシナリオで現在何が提供可能かをお問い合わせください。
- RustDeskはオープンソースであるため、「それが何をしているか、どうやって確認するのか」という問いには、信じるしかない証明書ではなく、実際の検証によって答えることができます。

つまるところ、セルフホスティングによって、リモートアクセスをお客様がすでに運用しているコンプライアンスプログラムに組み込むことができます。これは多くの場合、認証済みのブラックボックスをレンタルするよりも、規制対象のチームにとって強い立場となります。

## セルフホスト型のGDPRプログラムを支えるコントロール

セルフホスティングは土台であり、その上でRustDeskは、セルフホストするチームが実際にGDPRへ対応する際に頼りにする具体的なコントロールを提供します。

- **テレメトリはRustDeskではなく自社サーバーに送られます。** RustDeskのプライバシーポリシーに記載されている利用データ(アプリの起動、IPアドレス、基本的なマシン統計、セッション時間、RustDesk ID)は、RustDeskの**公開ホスト型サービス**が処理するものです。自社でID/ランデブーサーバーとリレーサーバーを運用する場合、そのデータは代わりに**自社**のインフラ上にとどまります。Server Proのライセンス確認を除けば、rustdesk.comへ到達する必要のある通信はほとんどありません。導入するクライアントビルドと設定について、実際の送信先を確認してください。これにより、セッションデータと利用データはデフォルトで自社が管理するインフラ上にとどまり、強力なデータ最小化の姿勢となります。
- **組み込みの監査ログローテーションと保持。** Server Proの監査ログは、接続、ファイル転送、アラーム、コンソール操作の4つのカテゴリーで構成され、**組み込みのログローテーション機能**により監査データが無期限に保持されることはありません(保存制限)。処理記録のために、Webコンソールまたは REST API 経由でエクスポートすることもできます。
- **きめ細かく範囲を限定したアクセス。** ユーザー単位の割り当て、デバイスグループ、グループ横断ルール、そしてコントロールロール(技術者がセッション中に何を行えるか — キーボード/マウス、クリップボード、ファイル転送、音声、カメラ、ターミナル、印刷、録画など)により、最小権限の原則と目的の限定が実現され、SSO/LDAPと制御対象デバイスの2FAがそれを支えます。
- **プライバシーモードと接続ごとの同意確認。** 制御される側は、着信接続に確認を要求したり、セッション中に画面を暗転させたり(プライバシーモード、WindowsとmacOSでサポート)することができ、画面上の個人データが意図せず露出することを制限します。
- **自社の裁量による削除。** データは自社サーバー上にあるため、ユーザーの無効化・削除、デバイスや記録の削除(REST API経由を含む)を行うことができ、消去要求や保持要求に直接対応できます。
- **リージョン内・自社運用のインフラ。** ID/ランデブーサーバー、リレー、コンソール、保存データは、自社が管理するハードウェア上の、自社が配置した場所で稼働します。
- **カスタムクライアントのビルドでさえデータを残しません。** ブランド化されたクライアントの生成は、RustDeskのビルドサービスを使用する唯一の工程であり、意図的に一時的なものとなっています。送信したビルド設定はRustDeskのビルドサーバー上に保持されず(ビルド完了後に削除されます)、生成されたインストーラーも約1日後に自動的に削除されるため、自分でダウンロードして保管する必要があります。

これらは、GDPRプログラムが実際に動かせるレバーです。文書化して運用するのは自社の役割ですが、データ主体からの要求への対応をベンダー任せにする必要はありません。

## 目に見える形で示せる主権

ランデブーサーバー、リレー、コンソール、保存データを自らホストすることで、コンプライアンスプログラムに具体的な拠り所が生まれます。それは、自社が配置し、運用し、監査するインフラです。これはゴールではなく土台ですが、他のすべてがその上に成り立つ部分です。

## GDPRと主権のための導入チェックリスト

セルフホスティングは選択肢を与えてくれますが、それを実際のコントロールへと変えるのは導入作業です。

- IDサーバー、リレー、コンソール、バックアップ、ログ、管理者の所在地を文書化する。
- 直接のピアツーピア経路とリレー経由の経路を分けてマッピングする。ドイツにあるサーバーは、ドイツと別の国との間の直接セッションをドイツ国内にとどめてはくれません。
- 管理された場所を経由する経路が、ピアツーピアのパフォーマンスよりも重要になる場合に、リレーを強制するタイミングを決める。
- デバイス、アカウント、監査、接続に関するメタデータについて、目的、保持期間、アクセスポリシーを記録する。
- 最小権限のデバイスグループ、利用可能な場合はMFA/SSO、そして技術者向けのJML(入社・異動・退職)プロセスを適用する。
- WebコンソールをHTTPSの背後に置き、管理用のネットワークアクセスを制限し、バックアップの復元をテストする。
- 自社のユースケースに応じて、処理記録、処理者レビュー、移転評価、DPIAなど、適切な法的評価を完了する。

RustDeskは主権を確保するアーキテクチャを支えることができますが、そのアーキテクチャと法的根拠についての責任は、管理者(コントローラー)に残り続けます。

## 自社の境界内で評価する

評価は自社の条件で進めることができます。無料のオープンソースコミュニティサーバーを今すぐセルフホストするか、Pro機能の現在の評価条件については[sales@rustdesk.com](mailto:sales@rustdesk.com)までメールでお問い合わせください。現在のプランと詳しい機能は[rustdesk.com/pricing](https://rustdesk.com/pricing)でご確認いただけます。まずは見てみたい方には、[RustDesk YouTubeチャンネル](https://www.youtube.com/@rustdesk)に完全版の動画ウォークスルーがあります。
