↓ メインコンテンツへスキップ
CypherpunkGuide.
JA
主権ガイド

セルフホスティングと主権2026:5つの観点で依存を点検する

銀白の髪に静かな赤い瞳の女性が、スポットライトの当たる小さな一段高い舞台の上に、端然と立っている。だが薄っぺらな舞台装置の裏側では——深い紺を背に、水色と赤のネオンに照らされて——舞台を実際に支える配線とサーバーラックと鋼鉄の支柱の絡み合いが、むき出しになっている

資金について(2026年10月):CypherpunkGuideは監視型広告、広告ネットワーク、トラッキングピクセル、スポンサー記事を使わない。一部の記事には、手数料を受け取る可能性を明示したアフィリエイトリンクがある。この記事にはない。読者からの寄付も運営資金の一つである。

2026年10月1日の訂正: 旧版は5層の最低評価を客観的な主権の点数として扱い、想定上の構成例を実際に試験したように記述していた。所有機器の保護、CLOUD Actの管轄、SMTPによる開示、身元記録の影響も過大に説明していた。また、機密コンピューティングだけが事業者のアクセスを防ぐ手段だとし、裏付けのない本人確認の割合を使っていた。これらを訂正した。以下の3例は条件を定めた想定例であり、運用実験や市場全体の調査結果ではない。

自分で管理する機器へサービスを移せば、アプリの提供事業者をデータの経路から外せる場合がある。その代わり、更新、アクセス制御、復旧を自分で担う。プライバシーが改善するかどうかは、どこで暗号化し、どこで元の内容に戻すのか、そして誰を警戒するのかで決まる。

ホスティング事業者から文書を隠すこと、自宅の所在地につながる情報を隠すこと、障害後にサービスを復旧することは別の目的だ。すべてを「主権」と呼んでも、一つの構成で全部が解決するわけではない。

デジタル主権は、何を自分で管理するかで考える
#

デジタル主権は、特定の依存先に対してどこまで管理権限を持てるかを表す考え方だ。すべての依存や法的義務が消えることを意味しない。 自宅サーバーならクラウドのアカウントを不要にできても、回線、電力、ソフトウェア、バックアップへの依存は残る。

5層の枠組みで問うのは、誰がデータを読み、変更し、サービスを止め、本人と結び付けられるかである。「最も弱い層を先に直す」という考えは、目的を妨げる依存を見つけるための編集上の目安だ。最低評価が総合的な安全性を決めるという数式ではない。他の防御もそれぞれ役立つ。請求記録からアカウントの持ち主が判明しても、端末側で暗号化したファイルまで復号されるとは限らない。通信が止まっても、暗号化したバックアップは復旧に使える。

AIによる身元の特定を扱った記事では、記録の照合を考察している。重要なのは、相手がどの記録を取得し、組み合わせられるかだ。一つの痕跡があれば必ずすべて分かる、という話ではない。

5つの観点で構成を点検する
#

鍵の管理、データ、実行環境、通信、身元を別々に点検し、判断の前提を書き残す。 重なる部分はあるが、それぞれ異なる依存を見つけるための項目だ。あらゆる構成を一列に順位付けする表ではない。

観点確かめること残るリスク
鍵の管理鍵、管理者の認証情報、復旧用の秘密情報を誰が持つか侵害、端末の盗難、バックアップへのアクセス、鍵の紛失
データ暗号化していない内容がどこに現れ、誰が復号できるかサーバーでの処理、利用端末、通信などの付随情報、複製
実行環境機器と、その基盤となる環境を誰が管理するかホスト側の権限、遠隔管理、ソフトウェアの弱点、物理的な接触
通信接続先、時刻、通信量を誰が見られるか回線事業者や中継者の観測、公開アドレス、通信に付加されるヘッダー情報
身元サービスやアカウントを個人と結ぶ記録は何か請求、登録、支払い、開示、照合

優先する項目は目的で変わる。ファイルの秘密を守るなら、元の内容と鍵に誰が触れるかが中心になる。自宅の接続元を隠すなら通信経路が重要だ。本人との関連付けを許容できても、復旧にはバックアップと稼働の計画が要る。

判断用ワークシートには、後述する想定例の前提を15行で記録した。全言語共通の英語CSVである。この記事のために作成した編集上の資料であり、実測点数や実験結果ではない。

所有機器とVPSでは、誰を信頼するかが違う
#

機器の所有はホスティング事業者の管理権限を一部なくすが、遠隔侵害を防ぐ保証にはならない。通常のVPSでサーバーが処理する平文を守るには、ホスト側への信頼が必要になる。 VPSは、事業者の物理機器上で動く仮想サーバーだ。平文とは、暗号化されていない元の内容を指す。

通常の仮想マシンでは、物理機器を管理するホスト側がハイパーバイザーを管理する。これは仮想マシンを動かすためのソフトウェアである。ホスト側の強い権限は、仮想マシンのメモリや実行内容へのアクセスにつながり得る。アプリがそこで平文を処理したり復号鍵を持ったりするなら、通常のディスク暗号化では稼働中のアクセスを防げない。これは権限の説明であり、特定の事業者が利用者のファイルを読んだという証拠ではない。

Nextcloudの暗号化の文書は、サーバー側暗号化とエンドツーエンド暗号化を区別している。Nextcloudは、ファイルなどを自分のサーバーで管理するためのソフトウェアだ。サーバー側暗号化は、設計上の対象となる保存ファイルを保護する。ただし、サーバーは処理のために復号できる。そのサーバーの管理者から内容を隠す保護とは扱えない。

エンドツーエンド暗号化では、利用端末が暗号化と復号を行い、内容の鍵をサーバーへ渡さない。この区別が成立するには、実装と鍵の管理が対応している必要がある。そうすればサーバーは元の内容を受け取らずに暗号化したファイルを保管できる。機密コンピューティングを使わずに、事業者が内容へアクセスできる範囲を限る方法でもある。

一方、サーバー上で元の内容を扱う機能には制限が生じる。端末の侵害、鍵の紛失、メタデータと呼ばれる付随情報、サーバーによる削除や停止も残る。使うアプリと機能が実際に対応しているか確認する必要がある。この記事は特定の運用構成の安全性を保証しない。

AMD SEV-SNPとIntel TDXは、ホスト側から仮想マシンのメモリへアクセスできる範囲を減らすためのハードウェア保護だ。機密コンピューティングは、仮想マシン内で平文を処理する必要がある場合の保護にも使われる。どこまで信頼できるかは、ファームウェアやソフトウェアの前提、保護される部品の範囲、アテステーションに依存する。アテステーションとは、想定した保護環境で処理が動いていることを確かめる証明である。

この保護だけで付随情報を隠せるわけでも、稼働を保証できるわけでも、すべての部品を守れるわけでもない。対象の料金プランと設定を確認する必要がある。市場での普及率や価格について、この記事は断定しない。

構成変えられること残る確認項目
通常のVPS仮想マシン内のアプリとOSを自分で管理する実行内容や稼働中の平文に対するホスト側の権限
端末側で暗号化したファイルをVPSへ置くサーバーへ元の内容や鍵を渡さずに済む端末の健全性、鍵の復旧、付随情報、機能制限
機密保護付き仮想マシン保護対象メモリへのホスト側アクセスを減らせるアテステーション、ファームウェア、保護範囲、アプリの安全性、稼働
自分で所有する機器ホスティング事業者が基盤機器を管理しない遠隔管理、OSやアプリの侵害、端末、バックアップ、物理的接触

アプリ、管理者アカウント、遠隔管理機能を侵害できれば、攻撃者は所有機器に直接触れる必要がない。所有は通常の管理者を変えるもので、他者が権限を得ない証明ではない。Nextcloudの脅威モデルは、攻撃者の立場を区別する際に役立つ。

通信で分かる情報は、経路と規約で変わる
#

内容の暗号化は、通信の付随情報まで自動的に隠すものではない。自前の運用がクラウドより多くの情報を漏らすとも、一律には言えない。 比較には通信経路、観測者、規約の具体的な条件が必要だ。

直接接続なら、回線事業者は相手のIPアドレス、時刻、通信量を観測できる。ドメイン名まで分かるかは、名前を調べるDNS、暗号化通信のTLS、経路の選択による。トンネルを使えば直近の接続先は変わるが、別の相手への信頼や経路への依存が加わる。電子フロンティア財団(EFF)のメタデータ解説は、内容が暗号化されても通信記録が重要になる理由を説明している。

自宅で直接公開したサービスは、継続して使う住宅回線のIPアドレスを示す場合がある。中継やトンネルを使えば経路は変わる。この違いだけで、自宅の運用は常に、あるいは通常、クラウドより多くの情報を漏らすとは結論できない。

メール配送の規約であるSMTPのRFC 5321第4.4節は、受信サーバーにReceivedという配送経路の記録を先頭へ加えることを求める。SMTP接続では、そのFROM欄に直前に送ってきたホストのアドレスを含めるべきだとしている。接続元IPの記載は推奨(SHOULD)であり、すべてのメールに例外なく要求する規定ではない。

直前のホストは、自宅のメールサーバー、VPS、中継サーバーのいずれでもあり得る。利用者のパソコンやスマートフォンとは限らない。端末のアドレスが開示されるかは、送信受付ソフトウェアや事業者の方針にもよる。自宅から直接配送すれば自宅サーバーのIPが記録され得るが、中継経由なら別の直前ホストになる。実際の配送経路のヘッダーを確認して判断する必要がある。

身元の記録と法的管轄を分けて確かめる
#

請求や登録の記録は、相手が取得して照合できれば、サービスを個人と結び付け得る。ただし、自動的に公開されるわけでも、別の暗号化データを復号するわけでもない。 ドメイン登録事業者が持つ情報、公開情報、決済記録、相手が実際に取得できる範囲を分けて考える。

規制対象の取引所の一部は、KYC(顧客の本人確認)を求める。この記事は取引所の割合を示さず、法定通貨で購入するすべての経路にKYCが必要だとも主張しない。購入やホスティングの支払いが本人に結び付いていれば、調査に関係する記録が残る場合がある。だが、それはノード運用の必須条件でも、直ちにすべての匿名性が失われる証拠でもない。オンチェーンの支払いとプライバシーと強要を受けたときの自己管理は、それぞれ異なるリスクを扱っている。

保存場所だけでも法的な範囲は決まらない。米国法18 U.S.C. §2713は、電子通信サービスや遠隔コンピューティングサービスの提供者が、関係する米国の法的手続きに基づいて負う義務を扱う。米司法省のCLOUD Act白書とFAQは、米国の裁判権がその提供者に及ぶことと、情報が提供者の保有・管理・支配下にあることを説明している。これらの条件の下では、海外に保存しているというだけで適法な提出義務を免れるわけではない。

米国で設立された会社かどうかだけで決まる規則ではない。外国の提供者も、米国との接点や法的状況によって米国の管轄下に置かれ得る。CLOUD Actは、世界中のどんな情報でも自由に取得できる規則でも、一般的な復号能力を与える法律でもない。

機器の所有によって第三者経由の開示先を一つ減らせても、現地の法的義務、押収のリスク、他の提供者が持つ記録は残る。この説明は2026年10月1日時点で確認した米国の出典の範囲に限る。世界各国の法律を評価したものではない。

条件を定めた3つの想定例
#

以下は条件を指定した構成例であり、実際の導入試験や製品全体への採点ではない。 暗号化、経路、請求、ウォレットの構成を変えれば、判断も変わる。

想定する構成得られる管理権限点検する依存
所有機器上の自宅Bitcoinフルノード。公開ネットワークへ直接接続し、ノードにウォレットの鍵を置かないブロックと取引を自分で検証する回線事業者から見える接続、ソフトウェア管理、別途接続するウォレットや支払いの記録
通常のVPS上のNextcloud。サーバー側暗号化を使い、事業者の請求記録に身元が結び付くアプリと設定を自分で管理するサーバーで処理する平文へのホスト側アクセス、管理者アカウントの侵害、バックアップ、請求
所有する自宅機器上のメールサーバー。外向きのSMTP配送を直接行うメールサービスと手元の保存データを管理する配送記録に現れ得る自宅の送信ホストIP、受信側のシステム、安全性、稼働

Bitcoinフルノードはブロックと取引を検証する。ウォレットは鍵と支払いを管理する。両者を統合することはできるが、ノードを動かすためにBitcoinを買ったり、ノードにウォレットの鍵を保存したりする必要はない。Bitcoin.orgのフルノードの手引きは、検証と接続を説明している。鍵の管理は別に評価し、ノードを所有するだけで安全とみなしてはならない。

Nextcloudの例で端末側のエンドツーエンド暗号化を使えば、内容へのアクセス範囲と機能が変わる。メールの例で中継やVPSを使えば、SMTPで直前に送信するホストが変わる。いずれも別の依存を持ち込む変更であり、一つの総合点数を与えるものではない。

サイファーパンクの原則は、特定の依存を減らすこと
#

普段信頼している相手が期待どおりに動かなくても、特定のプライバシー保護が残る設計を目指す。その際、残る依存も明らかにする。 これは設計の方向であり、絶対的な独立の約束ではない。

Eric Hughesは『サイファーパンク宣言』で、プライバシーを得たいなら自分たちで守る必要がある、と述べた。宣言の議論は保護を仕組みに組み込む考えを支えるが、現代のVPSやメールの構成が持つ安全性を証明するものではない。

端末だけでファイルの鍵を持てば、サーバーがそのファイルを読む能力をなくせる場合がある。機器の所有はホスティング管理者を外せる。試験済みのバックアップは一台の機器への依存を減らす。それぞれの改善は、別の依存が残っていても役立つ。

結び:目的を妨げるリスクから優先する
#

目的を妨げ得る依存を先に見つけ、変更で何を取り除き、何を加えるかを確かめる。 「主権」という名前だけを得るために移行してはならない。

  1. 守るものと相手を決めよ。 ファイルの秘密、自宅の情報、復旧には別々の対策が要る。
  2. 平文と鍵の場所を書き出せ。 利用端末、稼働中のサーバー、バックアップを含める。サーバー側暗号化と端末だけが持つ鍵を区別すること。
  3. 通信経路と記録を確かめよ。 サービスのアドレス、メールのヘッダー、請求や登録情報へのアクセスを点検する。すべての記録が公開されると決め付けないこと。
  4. 新たに担う責任を確認せよ。 更新、遠隔アクセス、復旧、法的な影響を含める。実際に試したことと仮定を分けて記録すること。

よくある質問
#

自前の運用はクラウドよりプライバシーを守れますか?
#

目的を限定すれば、守れる場合があります。所有機器は事業者のアクセスを一部なくす一方、保守や物理的なリスクを加えます。端末側での暗号化なら、他者の機器に置く内容を守れる場合もあります。実際のデータの流れ、経路、記録を比較してください。

VPS事業者は暗号化ファイルを読めますか?
#

通常のホストには、仮想マシン内で処理する平文や鍵へアクセスできる権限があります。サーバー側暗号化では、稼働中のその条件はなくなりません。信頼できる端末で暗号化し、内容の鍵をサーバーへ渡さないファイルは別です。ただし付随情報、端末の侵害、削除、復旧には引き続き注意が要ります。

欧州にデータを置けば米国の法律は届きませんか?
#

保存場所だけでは決まりません。引用した規則は、米国の管轄が及ぶ対象の提供者に、適法な手続きを通じて、その保有・管理・支配下の情報を提出させるものです。海外の保存情報も含みます。外国で会社を設立しただけでも適用除外の保証にはなりません。個別の判断には提供者と具体的な事情が必要です。

自宅のBitcoinノードにはKYCを経たコインが必要ですか?ウォレットの鍵も公開されますか?
#

ノードを動かすこと自体に、どちらも伴うわけではありません。フルノードは検証を行い、ウォレットは鍵を管理します。この記事の想定ノードにウォレットの鍵はありません。運用のためのBitcoin購入も不要です。接続するウォレットや支払いの記録は別に評価してください。

どの層を先に直すべきですか?
#

目的を妨げる可能性があり、意味のある改善ができる層です。あらゆる構成に共通する「最も弱い層」はありません。請求記録との関連付けが匿名性に及ぼす影響と、暗号化ファイルの秘密に及ぼす影響は違います。バックアップは稼働や復旧の問題を扱います。

出典と確認の範囲
#

以下の原典は、説明した技術的・法的な条件を支える。ワークシートは著者が作成した判断の枠組みである。 訂正にあたり、2026年10月1日に現行資料と既存の日時を特定した保存版を確認した。保存版はそれぞれの取得日の資料を示すもので、現在の運用構成を保証するものではない。

出典原URL保存版
米国法18 U.S.C. §2713https://www.law.cornell.edu/uscode/text/18/2713https://web.archive.org/web/20260720135734/https://www.law.cornell.edu/uscode/text/18/2713
米司法省 CLOUD Act白書・FAQhttps://www.justice.gov/d9/press-releases/attachments/2019/04/10/department_of_justice_cloud_act_white_paper_2019_04_10_final_0.pdfhttps://web.archive.org/web/20260824213242/https://www.justice.gov/d9/press-releases/attachments/2019/04/10/department_of_justice_cloud_act_white_paper_2019_04_10_final_0.pdf
Nextcloud 暗号化の文書https://docs.nextcloud.com/server/latest/admin_manual/configuration_files/encryption_configuration.htmlhttps://web.archive.org/web/20260927071512/https://docs.nextcloud.com/server/latest/admin_manual/configuration_files/encryption_configuration.html
Nextcloud 脅威モデルhttps://nextcloud.com/security/threat-model/https://web.archive.org/web/20260918073957/https://nextcloud.com/security/threat-model/
AMD SEVhttps://www.amd.com/en/developer/sev.htmlhttps://web.archive.org/web/20260905101556/https://www.amd.com/en/developer/sev.html
Intel TDXhttps://www.intel.com/content/www/us/en/support/articles/000097227/processors/intel-xeon-processors.htmlhttps://web.archive.org/web/20260207161750/https://www.intel.com/content/www/us/en/support/articles/000097227/processors/intel-xeon-processors.html
RFC 5321 §4.4https://www.rfc-editor.org/rfc/rfc5321https://web.archive.org/web/20260421205902/https://www.rfc-editor.org/rfc/rfc5321
Bitcoin.org フルノードの手引きhttps://bitcoin.org/en/full-nodehttps://web.archive.org/web/20260911145657/https://bitcoin.org/en/full-node
EFF メタデータの解説https://ssd.eff.org/module/why-metadata-mattershttps://web.archive.org/web/20260912145625/https://ssd.eff.org/module/why-metadata-matters
Eric Hughes『サイファーパンク宣言』https://www.activism.net/cypherpunk/manifesto.htmlhttps://web.archive.org/web/20260921035451/https://www.activism.net/cypherpunk/manifesto.html