【2026年】Vault系セルフホスト2026｜Vaultwarden+Authelia+Headscale

このエコシステムを構築することで、ユーザーは「一度の認証」で、すべての自前サービスに安全にアクセスできる環境を手に入れることができます。

サーバーハードウェアとソフトウェアの選定基準

2026年現在のセルフホスト環境において、ハードウェアの選定は「電力効率（Performance per Watt）」と「初期投資（CAPEX）」のバランスが重要な判断軸となります。特に24時間365日の稼働を前提とする場合、月間の電気代は運用継続性を左右する要素です。

エッジコンピューティングの進化により、Intel N100（Alder Lake-N）を搭載したミニPCや、Raspberry Pi 5（8GBモデル）が、主要な選択肢となっています。Intel N100搭載のミニPCは、低い消費電力でありながら4コア/4スレッドの性能を持ち、Dockerコンテナを多数同時に稼働させる能力を有しています。一方、Raspberry Pi 5は、ARMアーキテクチャによる低コストと、広いコミュニティによる周辺モジュールの豊富さが魅力です。

ソフトウェアの選定においては、管理の容易さと、将来的なスケーラビリティを考慮する必要があります。以下の比較表は、導入を検討すべき主要なハードウェアの特性をまとめたものです。

【ハードウェア比較：エッジサーバー選定】

x86_64系のIntel N100搭載機は、AES-NIによる暗号化処理の高速化により、Vaultwardenの暗号化リクエストやAutheliaの認証処理を効率よくさばけます。Raspberry Pi 5はさらに省電力ですが、microSDカードはI/Oのボトルネックと寿命の懸念があるため、NVMe SSDへのブート構成を推奨します。

実装の基本構成（docker-compose）

ここでは、Vaultwarden・Authelia・Headscale・Caddy を Docker Compose で起動する最小構成の例を示します。実際の運用ではドメイン名・シークレット・ボリュームパスを自身の環境に合わせて置き換えてください。シークレットは .env ファイルや Docker secrets で管理し、リポジトリにコミットしないようにします。

# docker-compose.yml（最小構成の例）
services:
  caddy:
    image: caddy:2
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config

  vaultwarden:
    image: vaultwarden/server:latest
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "false"   # 初期ユーザー登録後は false 推奨
    volumes:
      - vw_data:/data

  authelia:
    image: authelia/authelia:latest
    restart: unless-stopped
    volumes:
      - ./authelia:/config
    environment:
      TZ: "Asia/Tokyo"

  headscale:
    image: headscale/headscale:latest
    restart: unless-stopped
    command: serve
    volumes:
      - ./headscale/config:/etc/headscale
      - headscale_data:/var/lib/headscale
    ports:
      - "8080:8080"   # Headscale API/コントロールプレーン

volumes:
  caddy_data:
  caddy_config:
  vw_data:
  headscale_data:

リバースプロキシには Caddy を採用すると、ACME プロトコルによる Let's Encrypt 証明書の取得・更新が自動化され、設定が簡潔になります。以下は Vaultwarden と Authelia を公開する Caddyfile の最小例です。

# Caddyfile（最小構成の例）
vault.example.com {
    reverse_proxy vaultwarden:80
}

auth.example.com {
    reverse_proxy authelia:9091
}

Authelia は YAML の設定ファイルで認証ポリシーやユーザーを定義します。下記は、既定で二要素認証を要求する最小ポリシーの例です（セッション用の secret などは環境変数または Docker secrets で注入し、平文での直書きは避けてください）。

# authelia/configuration.yml（最小構成の例）
default_redirection_url: https://vault.example.com

access_control:
  default_policy: deny
  rules:
    - domain: vault.example.com
      policy: two_factor

session:
  name: authelia_session
  domain: example.com
  expiration: 1h
  inactivity: 5m

storage:
  local:
    path: /config/db.sqlite3

notifier:
  filesystem:
    filename: /config/notification.txt

小規模であれば Authelia・Vaultwarden ともにストレージは SQLite で十分ですが、ユーザー数や同時アクセスが増えてファイルロックによる書き込み遅延が問題になる場合は、PostgreSQL への移行を検討します。

実装における技術的障壁と回避策

Vault系セルフホスト環境の構築において、多くのエンジニアが直面する課題は「リバースプロキシの構成」と「SSL/TLS証明書の自動更新」、「Split-DNSの整合性」の3点です。これらを適切に処理できないと、外部ネットワークからの接続時に403 Forbiddenや401 Unauthorized、あるいは証明書エラーによるプライバシー警告が発生し、サービスの信頼性が低下します。

まず、リバースプロキシの選定です。Nginx Proxy Manager (NPM) はGUIによる管理が容易ですが、より高度な動的設定や、Caddy・Traefikのような構成を求める場合は、Caddyの採用が手軽です。CaddyはACMEプロトコルを用いたLet's Encryptの自動更新を標準で備えており、設定ファイル（Caddyfile）の記述を最小限に抑えることが可能です。

次に、Headscale導入時の「Split-DNS」問題です。Headscaleを利用して内部ネットワークを構築すると、service.home.arpaのような内部ドメインと、外部のパブリックドメインが混在します。この際、DNSリゾルバ（Pi-holeやAdGuard Home）において、Headscaleのネットワークインターフェース（tailscale0）経由のクエリに対し、正しい内部IPアドレスを返すように設定しなければなりません。DNS応答遅延は、できるだけ低く抑えることがユーザー体験を損なわない運用の前提となります。

また、データベースの管理についても注意が必要です。Vaultwardenの初期設定ではSQLiteを使用しますが、家族メンバーが増加し、同時アクセス数が増大する場合、ファイルロックによる書き込み遅延が発生するリスクがあります。運用規模が拡大する場合は、PostgreSQLへの移行を検討すべきです。

【リバースプロキシ・ネットワーク技術比較】

さらに、バックアップ戦略の欠如は致命的な失敗を招きます。Vaultwardenのdb.sqlite3（またはPostgreSQLのダンプ）は、Resticなどのツールを用いて、Backblaze B2やAWS S3といったオブジェクトストレージへ、暗号化した状態で定期的に同期する仕組みを構築してください。

運用コストの最適化とスケーラビリティの設計

セルフホストの価値は、月額コストを抑えつつ、商用クラウドサービス（Bitwarden CloudやTailscale）と同等のセキュリティレベルを維持できる点にあります。本記事では運用コストの試算をすべて「Intel N100クラスを24時間稼働・平均消費電力10W・電力単価31円/kWh」という単一の前提に統一します。

この前提では、月間の消費電力量は 10W × 24h × 30日 = 7.2kWh となり、電気代は 7.2kWh × 31円 ≒ 約223円です。これに、Backblaze B2などの安価なクラウドストレージへのバックアップ費用（100GB程度であれば月額数十円）を加算しても、運用コストの総計はおおむね月額数百円に収まります。

スケーラビリティの観点では、家族メンバー（Family Members）の追加を想定した設計が重要です。Vaultwardenは、ユーザー数が増えてもリソース消費の増分が小さいため、1台の小型サーバーで5〜10人程度の家族・グループメンバーを管理するのに十分な性能を持っています。ただし、各メンバーがモバイルデバイス（iOS/Android）から頻繁に同期を行う場合、データベースのI/O負荷が増大するため、ストレージにはNVMe SSD（例: Samsung 990 Pro等）を採用し、I/O性能を確保しておくと安心です。

【運用コスト試算（前提: 10W・31円/kWh・5ユーザー想定）】

【セルフホスト運用に関するFAQ】

1. Q: 外部からアクセスする際、ポート開放は必要ですか？ A: HeadscaleやCloudflare Tunnelを利用すれば、自宅ルーターのポート開放（Port Forwarding）は不要です。これにより、セキュリティを大幅に向上させられます。
2. Q: Raspberry Pi 5の8GBモデルで、AutheliaとVaultwardenは同時に動きますか？ A: はい、十分に可能です。Dockerコンテナとして分離して稼働させても、メモリ使用量は合計で2GB未満に収まります。
3. Q: データベースのバックアップはどの頻度で行うべきですか？ A: データの更新頻度によりますが、Vaultwardenの場合は1日1回、できれば12時間ごとのスナップショット取得を推奨します。
4. Q: 家族が外出先（4G/5G回線）から接続する場合の注意点は？ A: Headscale経由のWireGuard接続であれば、モバイル回線でも低レイテンシで接続可能です。ただし、モバイル通信量（Data Usage）の消費には注意してください。
5. Q: SSL証明書の更新に失敗した場合、サービスはどうなりますか？ A: 証明書の有効期限が切れると、ブラウザで「保護されていない通信」と警告が表示され、ログインできなくなります。Caddy等の自動更新機能を信頼できる構成にすることが不可欠です。
6. Q: サーバーのハードウェア故障に備えた冗長化は可能ですか？ A: Proxmox VEなどのハイパーバイザ上で仮想マシン（VM）として運用し、定期的に別の物理マシンへバックアップをリストアする構成が現実的です。
7. Q: どの程度の知識があれば構築できますか？ A: Linux（Ubuntu Server等）の基本操作、Docker/Docker Composeの概念、およびDNSとリバースプロキシの基礎知識があれば、構築可能です。

主要製品・構成案の徹底比較

2026年におけるセルフホスト環境の構築は、単なる「データの自己管理」から、「いかに低消費電力かつ高可用なインフラを、家族全員のデバイスに透過的に提供するか」というフェーズへ移行しています。特に、Vaultwardenを中心としたパスワード管理、Autheliaによる認証統合、そしてHeadscaleを用いたメッシュネットワークの構築は、従来のVPN運用における複雑さを軽減し、Tailscaleのような利便性を自前で実現するためのスタックとして定着しつつあります。

ただし、ハードウェアの選定ミスは、月間の電気代増大や、メンテナンスコスト（運用工数）の増大に直結します。ここでは、導入検討者が直面する「計算リソース」「ソフトウェア機能」「ネットワークセキュリティ」「ストレージ信頼性」「運用コスト（TCO）」の5つの観点から、構成案を比較検証します。

1. 実行基盤（ホストハードウェア）のスペック比較

まず検討すべきは、Dockerコンテナを稼働させる物理レイヤーです。2026年現在、電力効率に優れたIntel N100搭載のミニPCが、Raspberry Pi 5の代替として、あるいは上位の選択肢として、セルフホスティングで広く使われています。電気代は本記事共通の前提（消費電力×24時間×30日×31円/kWh）で試算しています。

Raspberry Pi 5は消費電力を低く抑えられるため24時間運用での電気代を低減できますが、I/Oのボトルネックを避けるためNVMe SSDへのブート構成を推奨します。一方で、Intel N100は、アイドル時10W程度ながら、AES-NIによる暗号化処理の高速化により、Vaultwardenの暗号化リクエストやAutheliaの認証処理において安定したレスポンス性能を発揮します。

2. パスワード管理ソフトウェアの機能マトリクス

次に、コアとなるVaultwarden（Bitwarden互換）と、既存のSaaSおよびローカル管理ツールの比較です。ここでは、家族利用を想定した「多デバイス同期」と「MFA（多要素認証）の柔軟性」に注目します。SaaS価格は2026年時点の公開プランに基づく目安です。

Vaultwardenの利点は、Bitwardenの公式クライアントをそのまま使用できる点にあります。Autheliaと組み合わせることで、WebAuthn（指紋認証やセキュリティキー）を用いたシングルサインオン（SSO）環境を、追加のソフトウェア費用なしで構築できます。

3. ネットワーク・アクセス制御の構成比較

Headscaleを用いた自前コントロールプレーンの運用は、Tailscaleの利便性を維持しつつ、通信のプライバシーを自分の管理下に置くための選択肢です。

Headscaleを利用することで、Tailscaleの管理サーバーを介さず、自身のインフラ内でノード間のルーティングを制御できます。Autheliaによる追加のIDP（Identity Provider）層を挟むことで、VPN接続後にのみ、特定のWebサービス（Vaultwarden等）へのアクセスを許可する、ゼロトラスト・ネットワークの構築が可能です。

4. データ永続性とバックアップ戦略

セルフホストにおける大きな懸念は、ストレージの物理的故障です。Vaultwardenの暗号化データベース（SQLite/[PostgreSQL）の毀損を防ぐための、バックアップ先と信頼性の比較です。

2026年の推奨構成は、N100マシン上のNVMe SSDに一次データを保持し、定期的にRestic等のツールを用いて、AWS S3やGoogle Driveへ暗号化済みのスナップショットを転送する、ハイブリッド構成です。

5. 家族利用における年間総所有コスト (TCO) 比較

最後に、5人の家族メンバーが利用する場合の、年間コストのシミュレーションです。電気代は本記事共通の前提（10W・31円/kWh）で算出しています。

自前構築案（N100）では、本記事の前提で電気代が年間約¥2,700、ソフトウェア費用なしに抑えられます。Bitwarden Families（年$47.88）や1Password Families（年$71.88前後）と比べると、為替や電気料金の変動を考慮しても、ソフトウェアライセンス料が不要になる点が経済的なメリットです。ただし、ここにはハードウェアの初期投資額（おおむね¥15,000〜¥20,000）は含まれておらず、削減効果を実感できるまでには相応の運用期間が必要です。電気代換算は1ドル=おおよそ150円前後を前提とした概算であり、実際の負担は契約プランや為替によって変動します。

よくある質問

Q1. Intel N100搭載ミニPCとRaspberry Pi 5、どちらが運用コスト面で有利ですか？

電気代の観点では、アイドル時消費電力が10W前後のIntel N100搭載ミニPCでも、本記事の前提（24時間稼働・31円/kWh）で月額約223円に収まります。Raspberry Pi 5（8GBモデル）はさらに低消費電力ですが、周辺機器やSDカードの寿命を考慮すると、コストパフォーマンスと安定性のバランスではN100搭載機が扱いやすい選択肢です。

Q2. 家族5人で利用する場合、月間の追加コストはどのくらいかかりますか？

Vaultwarden、Authelia、Headscaleを自前で運用する場合、月間の追加コストはおおむね数百円程度に抑えられます（本記事の試算では電気代・ストレージ・ドメインで合計約408円）。家族全員が個別のログイン情報を持っても、サーバーのスペック（RAM 8GB以上推奨）が足りている限り、追加のライセンス料は発生しません。

Q3. Vaultwardenと公式のBitwarden、どちらを選ぶべきでしょうか？

リソースの制約があるセルフホスト環境であれば、Vaultwardenが有力です。公式のBitwardenサーバーは比較的多くのRAMを消費しますが、VaultwardenはRustで実装されており、コンテナ単体でのメモリ消費量を小さく抑えられます。機能面でも、Bitwardenの主要な機能の多くに対応しており、Bitwarden公式のiOS/Androidアプリからそのまま利用可能です。

Q4. Headscaleを利用する最大のメリットは何ですか？

最大のメリットは、Tailscaleのコントロールプレーンを自前で管理し、通信の主導権を自分の管理下に保持できる点です。Tailscaleの無料プランには接続デバイス数などの制限がありますが、Headscaleを使用すれば、自前のサーバー（U[bun](/glossary/bun-runtime)tu 24.04 LTS等）上でノードを管理できます。2026年現在、プライバシー保護の観点から、外部の管理サーバーを介さないHeadscaleへの関心が高まっています。

Q5. Autheliaを導入することで、他のサービスにもログイン制限をかけられますか？

はい、可能です。AutheliaはOpenID Connect (OIDC) およびSAMLに対応しているため、NextcloudやGiteaなどの、認証プロトコルに対応したアプリケーションに対して、共通の認証基盤を提供できます。これにより、各サービスごとに個別のユーザー管理を行う手間が省け、2要素認証（2FA）を一括して適用できるため、セキュリティレベルを向上させることが可能です。

Q6. Vaultwardenのモバイルアプリやブラウザ拡張機能はそのまま使えますか？

問題なく使用できます。VaultwardenはBitwardenのAPIと互換性を持たせて開発されているため、Bitwarden公式が提供するChrome/Edge拡張機能や、iOS/Android向けの公式アプリから利用できます。ただし、自前サーバーのURL（例：https://vault.example.com）を、各クライアントの「サーバーURL設定」から指定する作業が必要となります。

Q7. 万が一のサーバー故障に備えた、最適なバックアップ構成を教えてください。

「3-2-1ルール」に基づき、Dockerのボリュームデータ（vw-data等）を、ResticやRcloneを用いて、地理的に離れた場所に保存するのが理想です。具体的には、ローカルのNAS（Synology等）に1次バックアップを取り、さらにBackblaze B2やAWS S3などのクラウドストレージへ暗号化した状態で転送する構成を推奨します。これにより、自宅の停電や物理的なディスク故障、災害時でもパスワード情報を失うリスクを最小化できます。

Q8. SSL/TLS証明書の更新作業は自動化できますか？

Caddyサーバーを使用することで、自動化できます。CaddyはLet's EncryptやZeroSSLの証明書発行・更新プロセスを自動で処理し、HTTP-01チャレンジやDNS-01チャレンジ（Cloudflare API連携等）をバックグラウンドで行います。これにより、証明書更新に伴う「サイトにアクセスできない」といった運用ミスや、手動での設定変更の手間を減らすことが可能です。

Q9. YubiKeyなどの物理的なセキュリティキーは利用できますか？

はい、利用可能です。VaultwardenはWebAuthn規格に対応しているため、YubiKey 5 SeriesなどのFIDO2/WebAuthn対応デバイスを、強力な2要素認証（2FA）として登録できます。パスワードが万が一流出したとしても、物理的な鍵がなければログインできないため、セキュリティ強度を高められます。Authelia側でも、WebAuthnを用いた多要素認証を構成できるため、システム全体の防御力を底上げできます。

Q10. 今後の技術トレンド（耐量子計算機暗号）への影響はありますか？

今後、耐量子計算機暗号（PQC）への移行が段階的に進むと考えられます。TLSなどの通信プロトコルでは、量子コンピュータによる解読耐性を高めるためのアルゴリズム標準化が進められています。HeadscaleやVaultwardenを利用している場合、基盤となるDockerイメージやOpenSSL、Go言語のアップデートを通じて、新しい暗号方式が順次適用されていく形になります。運用者は、常に最新の安定版イメージを使用することが重要です。

まとめ

2026年におけるVault系セルフホスト環境の構築は、単なるパスワード管理の枠を超え、ネットワーク、認証、機密情報を自律的に管理するプライバシー保護手段となります。

• Vaultwardenによる、Bitwarden互換で利便性の高いパスワード管理。
• Autheliaの導入による、自前サービス全体へのSSOおよび2FA（多要素認証）の適用。
• Headscaleを活用した、ポート開放不要なセキュアなリモートアクセス環境（Tailscale互換）。
• Raspberry Pi 5やIntel N100搭載ミニPCを用いた、低消費電力（本記事の前提で月間電気代 約223円）な運用。
• 家族利用を前提としても、1ユーザーあたりの月間コストを数百円以下に抑えられる経済性。
• Dockerコンテナによる、構成管理とバックアップの容易なインフラ構築。

まずは手元のRaspberry Piや、安価なN100搭載ミニPCを用意し、Docker環境の構築から始めてみてください。スモールステップでサービスを一つずつ統合していくことが、堅牢な自律型インフラへの近道です。

HeadscaleでTailscaleコントロールプレーンをセルフホスト。独立運用を具体例で解説する。