ラズパイ 自宅サーバー構築｜Samba/Nextcloud/VPN

Raspberry Pi 5で自宅サーバーを始めるなら、まずはSambaでLAN内の共有フォルダを作り、外出先からはWireGuard経由で入る構成にすると、最短で実用品になります。
筆者の自宅でもこの役割分担にしてから家族のPCやスマホからの接続が安定し、共有はLAN内、リモートアクセスはVPNという明確な線引きで運用が楽になりました。

この記事では、SambaとNextcloud、およびWireGuardとOpenVPNの違いを表で整理し、初めての1台で無理なく回る現実的な構成を決めていきます。
Raspberry Pi の推奨容量を踏まえ、通常版は32GB以上、Lite版は16GB以上を前提にします。
ヘッドレス初期設定から共有フォルダ、VPN、最低限のセキュリティとバックアップまでを順に解説します。

ポイントは、共有を増やす前に固定IPかDHCP予約を決め、外部公開はポート転送とDDNSをWireGuard用にだけ使い、Sambaをインターネットへ直接さらさないことです。
派手な構成より、役割を絞った小さな成功を先に作るほうが、ラズパイの1台目は長く安定して動きます。

関連記事Linux入門｜初心者向けのインストールと基本操作Linux入門。WSL・仮想環境・実機の選び方を比較し、Ubuntu 24.04 LTSの安全な導入手順と初期設定、基本コマンド10選、権限/sudo、トラブル対処まで1本で網羅。Windows利用者のWSL要件やバックアップ必須ポイントも整理します。

ラズパイで自宅サーバーを作ると何ができるか

自宅サーバーとは

自宅サーバーは、自宅に置いたコンピュータを常時動かし、家庭向けのサービスを自分で提供する運用形態です。
用途は身近で、たとえばSambaで家の中のPC同士が同じ共有フォルダを使えるようにしたり、写真や書類の置き場としてバックアップ先にしたり、WireGuardやOpenVPNで外出先から自宅LANへ安全に入ったり、Nextcloudでブラウザやスマホからアクセスできる自前クラウドを作ったりできます。
動画や音楽の配信基盤として使う構成もよく見られます。

この形の魅力は、既製品のNASやクラウドサービスでは触れにくい部分まで自分で決められることです。
保存先をUSB接続SSDにするか、共有方法をSambaにするかNextcloudにするかといった設計は、自宅の事情に合わせて組み立てられます。
外からの入口をVPNのみに絞るかといった点も、自宅の事情に合わせて決められます。
Raspberry Pi Documentation - Getting startedRaspberry Pi Documentation - Getting startedでも、ヘッドレスでの初期設定やSSH有効化の流れが整理されていて、画面やキーボードを常時つながなくても運用へ入りやすくなっています。

一方で、自由度の高さはそのまま自己管理の範囲にもつながります。
障害対応、更新、バックアップ、アクセス制御まで自分で面倒を見る前提です。
市販のクラウドに任せれば裏で吸収される作業を、自宅サーバーでは自分で理解して回すことになります。
だからこそ、最初の1台は役割を絞る構成が合っています。
共有、バックアップ、遠隔接続の3つを分けて考えると、何を置き、何を外へ出さないかが見えやすくなります。

raspberry-piが向く向かない用途">Raspberry Piが向く/向かない用途

Raspberry Piはもともと教育向けに広がったARM系のシングルボードコンピュータですが、今ではホビーからIoT、軽いサーバー用途まで守備範囲が広い機械です。
自宅サーバーに向く理由は、低消費電力で常時稼働に回しやすく、Linuxの学習と家庭内サービスを1台で両立できるからです。
ファイル置き場、家庭内バックアップ先、VPNサーバー、ちょっとしたWeb UIを持つCasaOSベースのホームサーバーなどは、Raspberry Piの得意分野に入ります。

新しく組むならRaspberry Pi 5はとくに扱いやすい世代です。
Benchmarking Raspberry Pi 5（https://www.raspberrypi.com/news/benchmarking-raspberry-pi-5/では、暗号処理性能がPi 4比で45倍高速という紹介があり、VPNのように暗号化を常用する用途で余裕が出ます。
加えてギガビットLANとUSBストレージの組み合わせは、家庭内サーバーの体感に効きます。
筆者の感覚でも、Pi 5に外付けSSDをつなぎ、有線LANで固めた構成にすると、家の中で大きめの動画ファイルやバックアップイメージをコピーする場面で待ち時間がはっきり短くなりました。
数字のベンチマーク以前に、「コピーを始めて別の作業に移るまでの間」がひと息ぶん縮まる感覚があります）。

逆に、公開Webサービスを大勢が同時に使う構成や、高トラフィックが前提の用途はRaspberry Piの勝ち筋ではありません。
不特定多数がアクセスするサイト、重いデータベース処理、大規模な動画配信、常時高負荷のコンテナ群を1台で受けるような運用なら、VPSやクラウドのほうが素直です。
家庭内で数人が使う共有基盤としては優秀でも、商用公開サービスの土台として考えると守るべき範囲が増えすぎます。

古い世代の実測例としては、Pi 3B+でSambaの大容量ファイル転送が13MB/s前後、19MB/s前後だったという報告があります。
ただ、ここはそのまま最新機種の期待値に置き換えないほうが正確です。
Pi 5ではCPU、USBまわり、ストレージ、暗号処理の余裕が変わるので、詰まりやすい場所も別になります。
microSD運用なのか、USB接続SSDなのか、有線LANなのかWi‑Fiなのかで、待ち時間の正体は違ってきます。
古い実測は「ラズパイでも共有サーバーとして成立する」参考にはなりますが、Pi 5ではストレージやネットワーク設計のほうが体感差を左右します。

ファイル共有とVPNの役割分担

初めての自宅サーバーで混乱しやすいのが、「共有」と「安全な遠隔接続」を同じものとして考えてしまうことです。
役割を切り分けると、構成はずっと見通しがよくなります。
家の中でファイルをやり取りする担当はSambaかNextcloudです。
外出先から安全に自宅へ入る担当はWireGuardかOpenVPNです。
共有は共有、入口は入口と分けて考えるのが基本です。

Sambaは、WindowsのLAN共有と相性がよく、エクスプローラーから共有フォルダとして扱えるのが強みです。
家のPC同士で動画、写真、文書を置く用途なら、まずここから始めるのが自然です。
macOSやLinuxからも参加しやすく、家庭内の「共通の棚」として機能します。
大きいファイルをまとめて置く用途とも相性がよく、バックアップ先としても扱いやすい部類です。
その一方で、小さいファイルを大量に並べたフォルダでは、一覧表示や転送のテンポが鈍ることがあります。

Nextcloudは方向性が少し違います。
ブラウザでアクセスしたり、スマホアプリで写真を同期したり、外部共有リンクのようなクラウド寄りの使い方を自前で持ちたいときに向きます。
単なる共有フォルダではなく、アカウント管理やWeb UIまで含めた「自宅クラウド」です。
そのぶんSambaより構成要素が増え、データベース、権限、保存先の設計まで考える必要があります。
ラズパイで動かすなら、OS本体はmicroSD、データ領域はext4の外付けSSDに置く、という分け方が収まりやすいです。

VPN側では、新規構築ならWireGuardが第一候補です。
OpenVPNは実績と柔軟性がありますが、構成はやや重めです。
WireGuardは仕組みが比較的シンプルで、PiVPNのような導入補助ツールを使うとクライアント設定の作成やQRコード配布まで流れがきれいにまとまります。
Pi 5では暗号処理の余裕が増したことで、OpenVPNでも以前より現実的に回しやすくなっていますが、初手の1本としてはWireGuardのほうが構成の見通しが立てやすい印象です。

この役割分担にしておくと、共有のトラブルと遠隔接続のトラブルを別々に追えるのも利点です。
たとえば家の中ではSambaだけで完結させ、外出先ではまずVPNで自宅LANに入り、その先で共有フォルダを開く形にすると、インターネット側へ直接見せる面積を絞れます。
自宅サーバーは何でも1つに寄せるほど複雑になります。
Raspberry Piではとくに、1台に役割を詰め込みすぎず、共有はSambaまたはNextcloud、安全な遠隔はWireGuardまたはOpenVPNと整理したほうが、長く安定して回る構成になります。

関連記事ラズパイ初期設定｜ImagerでOS書込みとSSHRaspberry Piの初期設定は、いまはRaspberry Pi Imagerを起点に組み立てるのが最短です。この記事では、microSDへのOS書き込みから初回起動、SSH接続までを30〜60分で終える流れを、HDMIとキーボードを使う方法と、PCだけで進めるヘッドレスの方法に分けて整理します。

まず決めること｜Samba・Nextcloud・VPNの使い分け

用途別：Samba vs Nextcloud

ここでは、「何を共有したいのか」よりも「どう使いたいのか」で決めると迷いません。
Sambaは自宅LANの中で共有フォルダを見せる仕組み、Nextcloudはブラウザやスマホアプリから使う自前クラウドです。
前のセクションで触れた通り、VPNはこのどちらかの代わりではなく、外から自宅LANへ入るための安全な通路です。

Sambaが向くのは、家の中のWindows、macOS、Linuxから同じフォルダを開きたい場面です。
エクスプローラーやFinderからそのまま扱えるので、「共有ドライブを1つ置く」という感覚に近くなります。
動画素材、RAW写真、バックアップ用の大きなファイルをまとめて置く用途では、まずSambaのほうが構成を素直に保てます。
筆者も家族共有フォルダを作るときは、最初からNextcloudまで広げず、Sambaだけで運用を始めたほうが手戻りが少なく感じました。
共有したい相手が家の中のPC中心なら、ブラウザ画面や同期クライアントを増やさないぶん、トラブルの切り分け先も減るからです。

一方のNextcloudは、単なる共有フォルダより「クラウドストレージの置き換え」に近い立ち位置です。
ブラウザからファイルを見たい、スマホ写真を自動で上げたい、家族ごとにアクセス権を分けたい、削除ファイルをゴミ箱から戻したい、といった要件が出てくるとNextcloudの価値が出ます。
外部共有リンクや履歴管理も取り込みやすく、PCだけでなくスマホ中心の運用にも合わせやすい構成です。
その代わり、ストレージの置き方、権限、アプリ更新、データベースまで考える範囲が広がります。

用途の違いを表にすると、次のように整理できます。

用途	Samba	Nextcloud
家庭内の大容量コピー	向いている。OS標準のファイル共有として扱える	できるが主戦場ではない
家族写真の自動同期	補助的。手動コピー中心	向いている。スマホアプリ連携を組みやすい
外部共有	向かない	向いている。共有リンク運用を組み込みやすい
履歴管理	基本は弱い	向いている。バージョン管理機能を持てる
ゴミ箱機能	基本はOS側依存	向いている。Web側で扱える
アクセス制御	共有単位・ユーザー単位で管理	より細かく設計しやすい

この表を見ると、Nextcloudのほうが高機能なので最初から入れたくなりますが、実際には必要な機能が増えた時点で追加するほうが組み立てやすいです。
家庭内の共有フォルダが主目的ならSamba単体で十分なことが多く、外出先から同じ共有へ入りたくなったら、その時点でVPNを足せば筋が通ります。
逆に、最初から「スマホ写真を自動で集約したい」「ブラウザで閲覧したい」「家族以外にも限定共有したい」と決まっているなら、Nextcloudを中心に据えたほうが設計がぶれません。

VPN方式比較：WireGuard vs OpenVPN

VPNの役割は、外出先のスマホやノートPCを安全に自宅LANへ参加させることです。
その先でSamba共有を見るのか、Nextcloudの管理画面へ入るのかは別レイヤーの話になります。
ここを分けて考えると、設定項目が多く見えても整理しやすくなります。

新規構築でまず候補に上がるのはWireGuardです。
設定ファイルの見通しがよく、クライアント側もシンプルで、ラズパイとの相性もよいからです。
RaspberryTipsのOpenVPN vs WireGuard on Raspberry PiRaspberryTipsのOpenVPN vs WireGuard on Raspberry Piでも、WireGuardは軽量で高性能寄り、新しく作るVPNでは有力候補という整理です。
PiVPNを使う構成ならWireGuardとOpenVPNの両方を選べて、クライアント追加やQRコード配布まで流れをそろえられます）。

OpenVPNは古くから使われてきた実績があり、柔軟な設定も可能です。
既存環境に合わせたいときや、すでにOpenVPN前提の運用経験があるなら候補に入ります。
ただ、ラズパイで1台目を立てる文脈では、設定の重さと処理負荷のぶん、入口が少し深くなります。
とくに暗号化を伴う通信ではCPUの余力が効くので、軽量なWireGuardのほうが「まずつながる形」を作りやすい、というのが実感に近いところです。

比較を表にするとこうなります。

項目	WireGuard	OpenVPN
傾向	軽量・高速寄り	実績・柔軟性寄り
Raspberry Piとの相性	高い	十分使えるが構成は重め
導入の見通し	比較的シンプル	設定項目が多め
新規構築との相性	強い	既存資産があると有力
クライアント配布	QRや設定ファイルで扱いやすい	証明書運用を含める構成が多い

性能差の傾向も見ておくと判断しやすくなります。
Tristamの比較例では、OpenWRTルーター用途でWireGuardが197Mbps、OpenVPNが43Mbps、Wi-Fi経由でもWireGuardが123Mbps、OpenVPNが59Mbpsという差が出ています。
ラズパイの構成そのものではありませんが、WireGuardのほうが暗号化付き通信で伸びやすいという方向性はつかめます。
Raspberry Pi 5では暗号処理の伸びも効くので、家庭用VPNではWireGuardが先に候補へ上がりやすいわけです。

運用面では、スマホから入る頻度が高いほどWireGuardの軽さが効きます。
設定を1回配ってしまえば、外から家に戻る入口として扱いやすく、Samba側かNextcloud側かを後から変えてもVPN部分はそのまま残せます。
つまりVPNの方式選定は、「どの共有方式を選ぶか」と切り離して考えられる設計ポイントです。

Raspberry Pi: OpenVPN vs WireGuard, Which One Is the Best?

If you are looking for a VPN software, OpenVPN is still the most popular solution, but WireGuard is a suggestion that we

raspberrytips.com

最初の構成の決め方フローチャート

最初の1台で迷うときは、機能の多さではなく最短で満たしたい用途から決めるのが近道です。
家庭内ファイル共有、外出先アクセス、スマホ同期の3つに分けると、構成が決まりやすくなります。

1. 家の中だけで共有できれば足りるか 家庭内のPC同士でフォルダを共有したいだけなら、Sambaから始める構成が素直です。
   Windowsなら共有フォルダ、macOSならサーバ接続という感覚で入れます。
   まず共有基盤を1つ作り、ファイルの置き場とユーザー権限を固める段階です。

2. 外出先から同じ共有へ入りたいか この段階で必要になるのはNextcloudではなく、まずVPNです。
   自宅LANへ安全に入る通路としてWireGuardを追加してください。
   その先でSambaへアクセスする構成がもっとも筋がよく、家庭内共有と外部アクセスの責務が明確になります。

3. ブラウザ閲覧やスマホ写真の自動同期が欲しいか ここまで来るとNextcloudの出番です。
   PCの共有フォルダというより、自前クラウドとして設計したほうが目的に合います。
   写真アップロード、共有リンク、履歴、ゴミ箱、ユーザー別管理まで必要なら、Nextcloud + WireGuard の組み合わせが軸になります。

文章でたどると、判断は次の流れになります。

LAN内の共有が主目的ならSamba。
外出先からも同じ共有へ入りたいならSamba + WireGuard。
ブラウザやスマホ同期を中心に据えるならNextcloud + WireGuard。

この順番にしておくと、最初から全部入りにして混乱しにくくなります。
家族共有フォルダのスタート地点はSamba単体のほうが整理しやすく、あとから「写真を自動で集めたい」「共有リンクを作りたい」という要求が出た時点でNextcloudを足す形のほうが自然でした。
ラズパイの自宅サーバーは、役割を1つずつ増やすほうが壊れた時の見通しも保てます。
ここで構成を先に決めておくと、次のセットアップ工程で何を入れるかが一気に明確になります。

必要なもの｜Raspberry Pi 5で始める最小構成

最小構成チェックリスト

最初の1台で迷わないように、まずは「これだけあれば動く」という線をはっきりさせます。
中心になるのはRaspberry Pi 5本体、起動用ストレージ、安定した電源、ネットワーク接続、そしてデータ置き場です。
新規導入ならRaspberry Pi 5が素直で、メモリは用途に応じて選べます。
軽いファイル共有やVPNの入口を作るところから始めるなら少なめのRAMでも回りますし、あとでNextcloudや複数サービスを載せる前提なら余裕のあるモデルのほうが構成変更に強くなります。
現行ラインアップでは最大16GBまで確認できます。

手元にそろえるものを並べると、次の最小構成になります。

• Raspberry Pi 5本体
• 起動用のmicroSDカードまたはUSB接続SSD

この中で見落とされがちなのが、起動用ストレージとデータ保存先を分けて考えることです。
たとえばSambaで家族共有フォルダを作るなら、OSはmicroSDカードに入れ、共有データは外付けSSDやHDDへ置く形にすると整理しやすくなります。
OSの再構築とデータ保全を切り分けられるので、障害時の切り戻しも速くなります。

筆者は最初からSSD起動に寄せるより、まずmicroSDカードで構築して全体を安定させ、そのあとSSDへ移す流れをよく使います。
この順番だと、設定を触って起動しなくなったときもカードを差し替えるだけで元の状態へ戻しやすく、学習の段階で詰まりにくいからです。
最初の構成では「最速」より「戻せる」が効きます。

価格面では、Raspberry Pi公式ニュースでRaspberry Pi 5の1GB版が45ドルと案内され、あわせて価格改定にも触れられています。
一方で日本国内の販売価格は時期ごとの振れ幅が大きく、同じモデルでも見え方が変わります。
ここでは金額を固定せず、国内流通価格は執筆時点で幅が出る前提で見ておくのが実態に合います。

ストレージ選び

ストレージは、起動用と保存用を分けると判断が一気に楽になります。起動用はmicroSDカードかUSB接続SSD、保存用は外付けSSDかHDDという考え方です。

Raspberry Pi Documentation - Getting startedRaspberry Pi Documentation - Getting startedでは、通常版のRaspberry Pi OSに32GB以上が案内されています。
Raspberry Pi OS Liteには16GB以上が案内されています。
最小構成で始めるなら、この基準に合わせるのが素直です。
デスクトップ付きOSを入れるなら32GB以上、CLI中心のLiteなら16GB以上が目安になります。

microSDカードの利点は、導入の手間が少なく、起動までの流れが単純なことです。
Raspberry Pi Imagerで書き込んで差し込めば始められるので、最初の検証には向いています。
容量は通常版OSで32GB以上、Liteなら16GB以上を起点に考え、余裕を見たいなら64GBクラスが扱いやすい選択肢です。
常時稼働でログや更新が積み上がる用途では、高耐久寄りのカードを選んでおくと運用が安定します。

一方、速度と信頼性を優先するならUSB接続SSDが有力です。
USBストレージは理論上5 Gbit/s級の帯域を使えるため、起動後の更新やパッケージ展開、データベースを伴う処理ではmicroSDカードとの差が出ます。
ファイル共有を長く続ける前提なら、OSごとSSDへ寄せる構成のほうが後々の不満が出にくくなります。
特にNextcloudのように小さなファイル更新が積み重なる用途では、microSDの消耗を避けたい場面が増えます。

データ保存先としての外付けSSD/HDDにも触れておきます。
共有フォルダの本体は、Linux系で扱いやすいext4にしておくと運用が素直です。
動画や写真の保管が中心で、容量を優先するならHDDという選択もありますが、バスパワー駆動の外付けドライブは電力面で不安が残ることがあります。
常時接続の保存先として置くなら、外付けSSDのほうが取り回しが安定しやすく、振動や待機復帰で悩まされにくい印象です。

容量の考え方も、用途別に見れば複雑ではありません。
OSだけなら前述の基準で足りますが、家族写真やPCバックアップの置き場を兼ねるなら、保存先の容量が主役になります。
起動用ストレージはOSと設定ファイルのための領域、外付けSSD/HDDは実データのための領域と割り切ると、どこに何を置くかがぶれません。

電源・冷却のポイント

Raspberry Pi 5では、電源と放熱を軽く見ないほうが安定した構成になります。
必要なのはUSB Type-Cの5V 3A級以上の安定電源です。
電圧降下や瞬断があると、ストレージの認識不良や不意の再起動につながります。
とくに外付けSSDやHDDをつなぐ構成では、本体だけではなく周辺機器側の消費電力まで意識したほうが組みやすくなります。
基準としては公式電源を軸に考えるのがわかりやすいです。

ネットワークは、最小構成ならまず有線LANを優先したいところです。
Sambaの共有先として使うなら、ケーブル1本で接続状態が固定される有線のほうが切り分けが明快です。
Wi-Fiでも動きますが、初期構築の段階では「サービス設定の問題なのか、無線品質の問題なのか」が混ざりやすくなります。
外出先アクセス用にWireGuardを足すときも、サーバー側が有線LANだと全体の見通しが立てやすくなります。

冷却もPi 5では実用品として見ておくべき要素です。
Benchmarking Raspberry Pi 5（https://www.raspberrypi.com/news/benchmarking-raspberry-pi-5/で触れられている通り、Pi 5は前世代より計算性能が伸びており、暗号処理でも差が出ます。
そのぶん発熱も増えるので、裸基板のまま長時間動かすより、ケースにヒートシンクやファンを組み合わせた構成のほうが安心です。
VPN、ファイル共有、コンテナ実行を重ねると発熱源が分散せず、温度が積み上がります）。

ケース選びでは、見た目よりもエアフローを優先すると失敗が減ります。
密閉気味の小型ケースは机上では収まりが良く見えても、連続運転では熱がこもりやすくなります。
ヒートシンク付きケースやアクティブファン対応ケースなら、夏場や高負荷時のクロック低下を避けやすく、共有速度やVPN応答の落ち込みも抑えやすくなります。

外付けドライブ側の電源も無視できません。
セルフパワー型の外付けHDDや、電源条件に余裕のあるSSDケースのほうが安定運用に向きます。
本体の電源、冷却、ストレージ給電の3点をそろえると、あとからソフトウェアを積み増しても土台が崩れにくくなります。
ここが固まっていれば、この先のOS書き込みや共有設定の工程で悩むポイントをぐっと減らせます。

Step 1 初期セットアップ｜Raspberry Pi OS Liteをヘッドレスで入れる

Imagerでの書き込みと事前設定

ここからは、Raspberry Pi OS Lite（64-bit）を画面なしで入れる流れです。
使うストレージは前のセクションで触れた通り、起動用ならmicroSDカードかSSDのどちらでも構いません。
容量の目安はRaspberry Pi Documentation - Getting started（https://www.raspberrypi.com/documentation/computers/getting-started.htmlでも整理されていて、通常版OSは32GB以上、Lite版は16GB以上が基準です。
今回のようにSambaやWireGuardの土台としてCLI中心で使うなら、まずはLite版で十分です。
データ本体は外付けSSD/HDDへ分ける前提なので、起動用ストレージはOSと設定を置く場所として考えると構成がぶれません）。

ヘッドレス導入ではRaspberry Pi Imagerを使うのが最短です。
ホストOSはWindows、macOS、Linuxに対応しているので、手元のPCからそのまま書き込みできます。
OS選択ではRaspberry Pi OS Lite（64-bit）を選び、書き込み前の詳細設定でホスト名、ユーザー名、SSH有効化、ネットワーク情報を先に入れておきます。
LAN接続を前提にするなら、ここではWi-Fi設定を無理に埋めず、有線中心で進めるほうが切り分けが素直です。
逆に設置場所の都合で無線しか使えないなら、SSIDとパスワード、国設定までここで入れておくと初回起動後の作業が減ります。

ホスト名は、あとで共有やVPNを足したときに識別しやすい名前にしておくと混乱が減ります。
たとえばpi5-homeのように、機種や役割が見える名前だと宅内で複数台動かす場面でも埋もれません。
ユーザー名もデフォルト任せにせず、自分で決めておくと後工程で権限やファイル所有者を読むときに迷いません。
SSHは公開鍵認証まで最初から入れられるなら、その形のほうが運用はきれいです。
まだ鍵運用に慣れていない段階では、まずパスワードで入って後から公開鍵へ切り替えても十分進められます。

ハード面では、Pi本体に起動用のmicroSDまたはSSD、5V 3A電源、有線LAN、保存用の外付けSSD/HDD、そしてケースと冷却をそろえた状態でこの工程に入ると、その後の確認が途切れません。
Pi 5は性能が上がったぶん熱も持ちやすいので、裸基板よりケースとヒートシンク、できればファン付き構成のほうが連続運転で落ち着きます。
セットアップ直後は更新やパッケージ展開が続くため、冷却が不十分だと最初の作業で温度が上がり、その後の挙動確認まで見通しが悪くなります。

初回起動とSSH接続

書き込みが終わったら、Pi本体に起動用ストレージを入れ、LANケーブルを接続し、5V 3Aの電源で起動します。
外付けSSD/HDDはこの時点でつないでいても構いませんが、OSの初回起動確認だけを先に済ませるなら、いったん本体だけで立ち上げても流れは明快です。
ケースに収めたあとでLANや電源が抜けかけていないかだけ見ておくと、起動確認で余計な寄り道が減ります。

接続先は、書き込み時に設定したホスト名かIPアドレスです。たとえば手元のPCやMacのターミナルから次のように入ります。

ssh ユーザー名@ホスト名.local

あるいはIPアドレスがわかっているなら、次の形でも接続できます。

ssh ユーザー名@192.168.x.x

.local で見つからない場合は、ルーターの接続端末一覧からPiのアドレスを確認すると早いです。
筆者はこの段階でSSH接続まで通れば、ディスプレイとキーボードを足さずにそのまま進めます。
自宅サーバー用途では、普段の運用もほぼリモート管理になるので、最初からその前提で組んだほうが後の姿に近い状態で慣れられます。

ログインできたら、まずOSとパッケージを更新します。

sudo apt update
sudo apt full-upgrade -y
sudo reboot

apt update はパッケージ一覧の取得、full-upgrade は依存関係の変化を含めて更新を進めるためのコマンドです。
初回セットアップではこの順番で入れておくと、その後にSambaやWireGuard関連パッケージを追加するときに古い依存関係へ引っ張られにくくなります。
再起動後、もう一度SSHで入り直せば、OSの土台はひとまず整った状態です。

この時点では、まだ共有データ用の外付けSSD/HDDを本格的に触らなくて構いません。
起動用ストレージでOSが安定して上がり、LAN経由でSSH接続できることを先に確認しておくと、問題が起きたときに「OS側なのか、保存先ストレージなのか」を切り分けやすくなります。
特にmicroSD起動と外付けSSD/HDD保存を分ける構成では、境界をひとつずつ固めるほうが後から追いやすくなります。

更新と固定IP/DHCP予約

初期更新が済んだら、宅内でPiのIPアドレスを安定させます。
Samba共有やVPNでは、接続先の住所が毎回変わると管理が一気に面倒になります。
方法は2つで、Pi側に固定IPを設定するか、ルーター側でDHCP予約を入れてMACアドレスに対して同じIPを払い出すかです。
どちらでも実現できますが、家庭用ルーターではDHCP予約のほうが扱いやすく、設定の所在も明確です。
OS再インストールをしてもルーター側の予約が残るので、入れ直し後の復旧も短く済みます。

筆者は自宅のPiを組むとき、先にDHCP予約を決めてからセットアップに入ることが多いです。
この順番にしてから、Sambaの接続先やVPNの転送先で「どのIPだったか」を掘り返す場面がぐっと減りました。
共有フォルダをWindowsのUNCパスで固定したり、ルーター側でポート転送先を指定したりするときも、IPがぶれないだけで設定票そのものが読みやすくなります。

Pi側で固定IPにするなら、OSのネットワーク設定を編集してアドレス、ゲートウェイ、DNSを明示します。
一方、DHCP予約ならルーターの管理画面でPiのMACアドレスを選び、配布IPを固定します。
家庭内で完結する自宅サーバーでは、後者のほうがメンテナンスの責任範囲がルーターに寄るので見通しが立てやすいです。
すでにルーターで接続機器一覧が見える環境なら、Piのホスト名とMACアドレスを結びつけて予約するだけで済みます。

ストレージ容量の考え方も、この段階でもう一度整理しておくと後工程が楽です。
起動用が通常版OSなら32GB以上、Lite版なら16GB以上という基準はそのまま有効で、今回の構成ではLite版の起動領域と、保存用の外付けSSD/HDDを分けるのが自然です。
写真、動画、PCバックアップを置くなら、容量の主役は外付け側です。
起動用microSDまたはSSDにデータを詰め込まず、OSはOS、共有データは外付けストレージという役割分担にしておくと、この先の自動マウント設定やバックアップ設計まで一直線でつながります。

Step 2 LAN内ファイル共有｜Sambaで共有フォルダを作る

外付けストレージの準備

ここからは、共有データを置く外付けSSDやHDDをRaspberry Piに載せていきます。
前の手順でRaspberry Pi Imagerを使ってOSを書き込み、SSH有効化、ユーザー作成、ホスト名設定、Wi-Fiまたは有線の初期設定、更新、固定IPまたはDHCP予約まで済んでいれば、あとは保存先を安定してマウントできる状態に整える流れです。
OS用と共有データ用の役割を分けると、あとで切り分けが明快になります。

Linux系で運用する共有ストレージは、まず ext4 でフォーマットしておくと扱いが素直です。
接続したドライブを確認して、対象デバイスを ext4 にしたうえで、UUID を使って自動マウントします。
デバイス名の /dev/sda1 などをそのまま fstab に書く方法もありますが、接続順で名前が変わる余地があるので、UUID 固定のほうが意図がぶれません。Raspberry Pi Documentation - Getting started の流れでヘッドレス導入したあとも、この方針なら再起動後に同じ場所へ戻ってきます。

まずは接続状態とUUIDを確認します。

lsblk -f
sudo blkid

共有データの置き場所として、たとえば /srv/share をマウント先に作ります。

sudo mkdir -p /srv/share

/etc/fstab には、6フィールド形式で1行追加します。典型例は次の形です。

UUID=取得したUUID /srv/share ext4 defaults,nofail 0 2

nofail を入れておくと、外付けストレージが一時的に見えないときでもOSの起動そのものは継続できます。fstab を編集したら、その場でマウント確認をしておくと、再起動してから慌てずに済みます。

sudo mount -a
df -h

マウントできたら、共有先ディレクトリの所有者と権限を整えます。
ここが曖昧なままだと、Samba の設定が正しくても書き込みで詰まります。
まず対象ユーザーの UID と GID を見ておきます。

id ユーザー名

そのうえで、共有先の所有者を合わせます。

sudo chown -R ユーザー名:ユーザー名 /srv/share
sudo chmod 2775 /srv/share

chown は所有者とグループの変更、chmod 2775 はグループ共有を意識した権限設定です。
先頭の 2 は setgid で、この配下に作られたファイルやフォルダが親ディレクトリのグループを引き継ぎます。
家族や複数端末で扱う共有フォルダでは、この一手間で権限の散らかり方が変わります。
単独ユーザー運用なら、まず所有者を明示してから必要最小限の権限に寄せる、という順番を守るだけでも事故が減ります。

外付けSSDはUSB接続なので、ケースや変換チップとの組み合わせで挙動が変わることがあります。
筆者はKingstonやSanDiskのポータブルSSDを使うとき、まず lsblk と dmesg で認識を見てから fstab に進めます。
マウント前の確認を1回挟むだけで、電力不足や認識の揺れを設定ミスと取り違えずに済みます。

Sambaの導入と共有設定

ストレージの土台ができたら、Sambaを入れてLAN内共有にします。
WindowsもmacOSも標準でSMBに対応しているので、家庭内ファイルサーバーの入口として扱いやすい構成です。

パッケージ導入は次のコマンドで進めます。

sudo apt update
sudo apt install -y samba

設定ファイルは /etc/samba/smb.conf です。
既定の内容を残したままでも動きますが、共有フォルダを1つ明示しておくと意図が伝わります。
最小構成の例を示します。

[share]
   path = /srv/share
   browseable = yes
   read only = no
   valid users = ユーザー名
   create mask = 0664
   directory mask = 2775

path は共有の実体、read only = no で書き込みを許可、valid users で接続ユーザーを絞ります。create mask と directory mask は、作られるファイルやディレクトリの基本権限をそろえるための指定です。
Linux側の所有者設定と、Samba側の共有設定が同じ方向を向いていることがポイントです。
片方だけ整えても、もう片方で引っかかります。

設定を書いたら、文法チェックを入れます。

testparm

問題なければ、Samba用のパスワードを作成します。
Linuxのログインユーザーがそのまま自動でSMB利用者になるわけではないので、smbpasswd で追加します。

sudo smbpasswd -a ユーザー名
sudo systemctl restart smbd

この -a はユーザー追加です。
ここで設定した資格情報を、あとでWindowsやmacOSから入力します。
家庭内だけで使うとしても、guest ok = yes のような匿名共有を最初から開けないほうが管理の線が崩れません。
誰が書いたか、どの資格情報で入ったかを追える状態にしておくと、運用が長引いたときに差が出ます。

性能面では、Sambaは大きな動画ファイルやバックアップアーカイブのような連続転送と相性がよく、LAN内コピーの主役として十分実用になります。
その一方で、多数の小ファイルをまとめて送る場面では待ち時間が目立ちます。
筆者の手元でも、写真ライブラリのように小さなファイルが大量に並ぶフォルダは、そのまま移動するより先にZipで固めてから送ったほうが体感が軽くなりました。
共有の遅さというより、ファイル1個ごとのやり取りが積み重なる性質として見ておくと納得しやすいところです。

Windows/macOSからの接続

共有設定まで終わったら、クライアント側から見える形にします。
固定IPまたはDHCP予約を前段で決めてあるなら、接続先の表記が安定します。
ホスト名で名前解決できるならそれでも構いませんが、まずはIPアドレスでつなぐと切り分けが速くなります。

Windowsではエクスプローラーのアドレス欄に UNC パスを入力します。
形式は \\サーバー名\共有名 です。
IPアドレスでつなぐなら、たとえば次のようになります。

\\192.168.x.x\share

資格情報の入力画面が出たら、smbpasswd で登録したユーザー名とパスワードを入れます。
毎回入力したくなければ、資格情報を保存してネットワークドライブとして割り当てておくと、普段のローカルフォルダに近い感覚で扱えます。

macOSではFinderの「サーバへ接続」から SMB のURLを指定します。書式は次の形です。

smb://192.168.x.x/share

接続後に認証情報をキーチェーンへ保存しておけば、次回以降の再接続が静かになります。
家族共有のMacでも、どのアカウントでマウントしているかが見えやすくなるので、権限トラブルを整理しやすくなります。

つながらないときは、順番に切り分けると迷いません。
Raspberry PiへSSHで入れるか、ping が通るか、systemctl status smbd でサービスが動いているか、testparm で設定に崩れがないか、共有パスの所有者と権限が合っているかを見ていくと、ネットワーク、Samba設定、ファイル権限のどこに線が切れているかが見えてきます。
初回セットアップでホスト名、ユーザー作成、SSH有効化、Wi-Fiまたは有線の接続までRaspberry Pi Imagerで事前に入れておく意味は、こういう後工程の切り分けが短くなるところにもあります。

Step 3 外出先アクセス｜WireGuard VPNを構築する

WireGuardを選ぶ理由

外出先から自宅のSamba共有や管理画面へ入る経路としては、WireGuardを先に検討する構成が扱いやすいです。
理由は、設定の骨格が比較的シンプルで、暗号化の処理負荷も抑えやすいからです。
OpenVPNは実績と柔軟性があり、既存環境との互換や細かな要件では今も有力ですが、Raspberry Piで新規に1台立てるならWireGuardのほうが見通しを立てやすい場面が多くなります。

性能面でもその傾向ははっきりしています。
Tristamの比較例では、WireGuardが197Mbpsに達した構成に対して、OpenVPNは43Mbpsという差が出ています。
Wi-Fi経由の比較でもWireGuard 123Mbps、OpenVPN 59Mbpsという結果で、同じ「家の外から安全に入る」という目的でも、方式の違いが体感に直結します。
自宅サーバーでは動画の持ち出しより、管理画面の操作やファイル取得が中心になりがちですが、待ち時間が短いだけで運用の心理的ハードルが下がります。

Raspberry Pi 5を使う意味もここにあります。
Raspberry Pi公式のBenchmarking Raspberry Pi 5では、暗号処理のベンチマークでPi 4比45倍高速という紹介があり、VPNのように暗号化が主役になる用途と相性が良いことが見えてきます。
サーバー用途ではCPUクロックだけでなく、暗号処理をどれだけ素直に回せるかが効くので、Pi 5は単なる新型というより、VPNサーバー役としての余裕を持ちやすい世代です。

とはいえ、OpenVPNを切り捨てる必要はありません。
証明書ベースで既存の運用が組まれていたり、対応機器の事情でOpenVPN前提になっていたりするなら、そのまま乗るほうが自然です。
選び分けの感覚を表で置くと、次の整理になります。

項目	WireGuard	OpenVPN	向いている場面
傾向	軽量・高速寄り	実績・柔軟性寄り	新規構築か既存資産活用かで分かれる
Raspberry Piとの相性	高い	十分使える	Piで最初の1台を作るならWireGuardが入りやすい
設定の見通し	比較的シンプル	項目が多い	手早く動かすならWireGuard
クライアント配布	設定ファイルやQRコードで配布しやすい	証明書を含む構成が多い	スマホ中心ならWireGuardが軽快
採用しやすい条件	新しく自宅VPNを立てる	既存のOpenVPN資産がある	要件次第でどちらも成立する

PiVPNでの構築ステップ

WireGuardを素の設定ファイルから組んでもよいのですが、初回はPiVPNを使うと流れがつかみやすくなります。
PiVPNはWireGuardとOpenVPNの両方に対応していて、インストール時にどちらを使うか選べます。
鍵の生成、サーバー側設定、クライアント追加、設定ファイルの出力までを一続きで進められるので、Linuxにまだ慣れていない段階でも全体像を崩さずに進められます。

前段のセットアップで使ったRaspberry Pi Imagerの事前設定が、ここでも効いてきます。
OS書き込みの段階でSSH有効化、ユーザー作成、ホスト名の設定、Wi-Fiまたは有線のネットワーク情報を入れておけば、起動後すぐにSSHで入り、VPN構築へ進めます。
Raspberry Pi Documentation - Getting started（https://www.raspberrypi.com/documentation/computers/getting-started.htmlでも、こうした初期セットアップの流れが整理されています。
OSは前述の通りRaspberry Pi OS Liteで十分で、容量はLiteなら16GB以上、通常版なら32GB以上が目安です）。

VPNサーバーはLAN内での宛先が安定している必要があるため、この段階で固定IPまたはDHCP予約を入れておきます。
ここは役割を切り分けて考えると混乱しません。
固定IPやDHCP予約は、家の中でRaspberry PiのIPアドレスを変わらない状態にするための設定です。
VPNそのものを外から見つけてもらう仕組みではなく、ルーターが「外から来た通信を、家の中のどの機器へ渡すか」を迷わないようにするための前提です。

セットアップは次の順番で進めると詰まりにくいです。

1. Raspberry Pi ImagerでRaspberry Pi OS Liteを書き込み、SSH有効化、ユーザー作成、ホスト名、Wi-Fiまたは有線の設定を事前入力する
2. 初回起動後にSSHでログインし、OSを更新する
3. Raspberry Piに固定IPまたはDHCP予約を割り当てる
4. PiVPNを導入し、VPN方式にWireGuardを選ぶ
5. クライアント設定を生成し、スマホはQRコードで読み込む

OS更新は先に済ませておくほうが落ち着きます。たとえば次の形です。

sudo apt update
sudo apt full-upgrade -y

update はパッケージ一覧の更新、full-upgrade は依存関係の変化を含めてまとめて反映するためのコマンドです。
VPNのインストール前に土台をそろえておくと、あとで切り分ける対象が減ります。

PiVPNの導入は、公式ドキュメントで案内されているワンライナーから始められます。

curl -L [https://install.pivpn.io](https://install.pivpn.io) | bash

インストーラーでは、利用するVPN方式としてWireGuardを選択し、待ち受けポートやDNSまわりの項目を順に決めていきます。
ここで指定したサーバーのLAN内IPが、先ほどの固定IPまたはDHCP予約と結びつきます。
クライアントの追加は導入後に pivpn add、スマホ用のQR表示は pivpn -qr で進められます。
スマホのWireGuardアプリはQRコードの読み込みに対応しているので、手入力より事故が起きにくく、配布の導線も短く済みます。

筆者はこの段階で、接続先の名前や用途がわかるクライアント名を付けています。iphone-main や ipad-home のように端末ごとに分けておくと、あとで無効化や再発行が必要になったときに迷いません。
VPNは「つながれば終わり」ではなく、家族のスマホ追加や端末買い替えで少しずつ管理対象が増えるので、最初の命名が後から効いてきます。

ポート転送・DDNS・外部からの接続検証

外出先から自宅のWireGuardへ届くまでには、3つの部品があります。
LAN内IPを安定させるのが固定IPまたはDHCP予約、インターネット側から来た通信をRaspberry Piへ渡すのがポート転送、変わる可能性がある自宅のグローバルIPに名前を付けるのがDDNSです。
この3つは役割がまったく違います。
ここが混ざると、設定が正しく見えても接続できません。

まず、ルーターでUDPポートをWireGuardサーバーへ転送します。
多くの導入例では UDP/51820 が用いられることが多く、ルーターでその UDP ポートを Pi に転送する設定例がよく見られます（ポート番号は任意に変更可能）。
出典例: PiVPN ドキュメントPiVPN ドキュメント。

次に、固定グローバルIPがない回線ではDDNSを使います。
DDNSは、自宅回線のグローバルIPが変わったときに、その変化をホスト名へ追従させる仕組みです。
たとえばDuckDNSのようなサービス名を使って覚えやすい名前を持たせておけば、クライアント側はIPアドレス直打ちではなくホスト名で接続できます。
ここで注意したいのは、DDNSは名前解決の担当であり、ポート転送の代わりにはならないことです。
DDNSだけ設定しても、ルーターが通信をRaspberry Piへ渡していなければ外から入りません。

この「外からの確認」は、実際の工数に直結します。
筆者の環境でも、モバイル回線での接続試験を先に組み込んだときは、DDNSの更新先ホスト名が1文字ずれていたことにすぐ気づけました。
宅内Wi-Fiのまま検証を続けていると、LAN内の名前解決やローカル到達性で一見つながってしまい、ポート転送の設定ミスを見落としがちです。
スマホのWi-Fiを切り、モバイル回線だけでWireGuardをONにして、自宅の共有や管理画面へ入れるかを見るほうが手戻りが少なくなります。

接続できないときの切り分けも、順番を固定すると迷いません。
まずRaspberry Pi自体へSSHで入れてWireGuardサービスが動いているかを見る。
次にルーターのポート転送先IPが固定IPまたはDHCP予約の値と一致しているかを確認する。
そのうえで、クライアント設定の接続先がDDNS名または正しいグローバルIPになっているかを見ます。
スマホはQRコード読み込みで設定の打ち間違いを減らせるので、つながらない原因はサーバー側かルーター側に寄りやすくなります。

ここまで通れば、外出先から自宅LANへ安全に入る入口が整います。
以後はSamba共有を直接インターネットへ見せるのではなく、WireGuardで家の中へ入ってから使う形になります。
公開範囲をVPNの入り口に絞れるので、構成全体の見通しが保ちやすく、後でNextcloudや他の管理サービスを足すときも整理が崩れません。

Step 4 ブラウザ型の自前クラウドが欲しい場合｜Nextcloudを追加する

Nextcloudの適材適所

Sambaで足りるのは、基本的に家の中でPC同士が共有フォルダを開く場面です。
エクスプローラーやFinderから普通のネットワークドライブとして触れるので、LAN内の大きなファイルを置く用途とは相性が合います。
一方で、Nextcloudが受け持つのは、ブラウザからファイルへ入る、自動で写真を吸い上げる、家族や知人に共有リンクを渡す、消したファイルや更新履歴をあとから追う、といったWeb経由の自前クラウド体験です。
ここはSambaだけでは埋まりません。

役割分担を先に決めておくと、構成が素直になります。
SambaはLAN向け、NextcloudはWeb向け、WireGuardは外出先から自宅LANへ安全に入るための入口です。
この線引きができていれば、どの通信をどこまで見せるかで迷いにくくなります。
前述の通り、Sambaを直接インターネットへ公開する考え方は取りません。
外から使いたいときはWireGuardで家に入ってから触るか、Nextcloud側に役割を寄せるほうが設計として筋が通ります。

Nextcloudを足すかどうかの判断基準は、ファイル共有そのものよりも「Webアプリとして何を求めるか」です。
たとえばスマホ写真の自動同期はNextcloudの得意分野ですし、共有リンクを期限付きで渡す運用も組み込みやすいです。
逆に、家の中のWindows機から大きな動画ファイルをまとめて置くだけなら、Sambaのほうが経路が短く、構成も軽く保てます。
筆者は、家庭内の保管庫としてはSambaを残しつつ、外で触る導線とモバイル同期はNextcloudに寄せる形に落ち着きました。
この分け方だと、トラブル時に「共有の問題」なのか「Webアプリの問題」なのかを切り分けやすくなります。

導入パスの比較

Nextcloudの入れ方はいくつかありますが、初回構築では管理の単純さを優先したほうが失敗が少なくなります。
手軽さで入るならCasaOS上でDockerアプリとして管理する方法がわかりやすく、画面からコンテナやボリュームを見渡せます。
CasaOSの対応状況はCasaOS Wikiの Get Started でも案内されていますし、ラズパイに載せる入口としては自然です。
もう少し中身を理解しながら進めるなら、Docker ComposeでNextcloud本体とデータベースを分ける最小構成が扱いやすいです。
公式寄りの流れを重視するなら、Ubuntu ApplianceのNextcloud on Raspberry Piも候補に入ります。

筆者は趣味運用ではDocker Composeを選ぶことが多いです。
NextcloudコンテナとDBコンテナを分けておくと、バックアップ対象が整理されますし、アップグレード後に問題が出たときも戻し先が明確です。
単一コンテナに全部詰め込む形より、どこで状態を持っているかを追いやすく、切り戻しの判断も早くなりました。
業務でインフラを触っていると当たり前に見える分離ですが、自宅サーバーでもこの考え方は効きます。

ラズパイ世代との相性も見ておきたいところです。
Raspberry Pi 5では暗号処理の伸びが大きく、Benchmarking Raspberry Pi 5 でもその方向性が示されています。
VPNと併用しながらクラウド機能を足していく前提なら、新規構築をPi 5中心で考える意味があります。
加えて、Nextcloudは32bitより64bit前提で組んだほうが無理がありません。
32bit環境では4GBを超えるファイルで制約が出る報告があり、写真や動画を扱う自前クラウドとして見ると避けたい条件です。
Pi 5で始めるなら、最初から64bitで設計しておいたほうが後の拡張と噛み合います。

OSの置き場とデータの置き場も分けて考えると見通しがよくなります。
Raspberry Pi Documentation - Getting startedでは通常版のRaspberry Pi OSに32GB以上、Lite版に16GB以上という目安が示されています。
Nextcloudまで載せるなら、microSDはOSと最低限の作業領域にとどめ、ユーザーデータは外付けSSDへ逃がす構成が安定します。
Webアプリの本体更新と、増え続ける写真や書類の保管先を分離しておくと、障害対応でもバックアップでも考える範囲が狭くなります。

外部ストレージと権限

Nextcloudでつまずきやすいのは、アプリ本体よりもデータ領域の取り込みです。
保存先に外付けSSDを使うなら、ファイルシステムはext4でそろえるのが無難です。
Linux側の所有権と権限を素直に扱えますし、コンテナ運用でもマウント先の意味がぶれません。
/etc/fstabでUUID指定にして自動マウントしておけば、再起動後も保存先が安定します。
ここでマウントポイントだけ作って満足すると、あとでNextcloudが書き込めないという形で表面化します。

書き込み不可やサムネイル生成失敗の原因になりやすいのが、www-data あるいはコンテナ内ユーザーへの所有権付与漏れです。
Nextcloudは画面から見えるファイルだけでなく、プレビュー用キャッシュや各種メタデータも扱います。
見た目ではマウントできていても、実際には一部のディレクトリだけ書けず、アップロードだけ失敗することがあります。
筆者はここで何度か時間を溶かしたので、マウント完了と権限設定は別の作業として切り分けるようになりました。
Linuxの ls -l で所有者が合っているか、コンテナなら中から実ユーザーを見て整合しているかを確認すると、原因が見えやすくなります。

外部ストレージをNextcloudへどう見せるかも設計。
アプリのデータディレクトリそのものをSSDへ置く方法と、外部ストレージとして追加する方法では、バックアップの切り方と権限管理の考え方が変わります。
前者は構造が単純で、最初の1台には向いています。
後者は既存の保管庫を後から取り込みたいときに便利ですが、誰にどこまで見せるかをNextcloud側でも整理する必要があります。
Samba共有で使っていたディレクトリをそのまま見せる場合は、OS側の権限とNextcloudのユーザー権限が二重に関わるので、どちらが拒否しているのかを意識して追う必要があります。

公開の設計もここで固めておくと混乱が減ります。
NextcloudはWebアプリなので、直接インターネットへ公開する構成自体は取れますが、その場合はリバースプロキシ、TLS証明書、公開ドメイン、ヘッダーまわりの整合まで面倒を見る必要があります。
最初の運用では、そこまで一気に広げず、WireGuard経由の安全圏で使い始めるほうが安定します。
ブラウザ型クラウドの体験は得つつ、外への露出はVPNの入口に集約できるからです。

関連記事Docker Compose 使い方｜複数コンテナ管理入門Docker Composeは、ばらばらの docker run を並べる段階から一歩進んで、compose.yaml ひとつで Web と DB をまとめて扱いたい人に向いた道具です。

運用のコツとトラブル対策

最低限の安全対策チェックリスト

自宅サーバーは、作った直後よりも動かし続ける段階で差がつきます。
公開後につまずきやすいのは、設定そのものより「どこまで戻せるか」と「何を外に見せているか」が曖昧なまま運用に入ってしまうことです。
筆者はまず、バックアップ、更新、公開面の棚卸しを同じ枠で扱うようにしています。
障害対応では、この3つがつながっているからです。

バックアップは3-2-1原則で考えると整理しやすくなります。
つまり、3つのコピーを持ち、2種類の媒体に分け、1つはオフサイトへ逃がすという考え方です。
ラズパイ本体だけに置いたバックアップは、電源事故やストレージ故障でまとめて失う可能性があります。
Sambaなら共有フォルダの中身だけでなく、/etc/samba/smb.confのような設定ファイルと、ユーザー管理に関わる内容も戻せる形で残しておくと復旧が早くなります。
Nextcloudではユーザーデータに加えて、設定ファイル、データディレクトリ、データベースをひとまとまりで扱うのが基本です。
ファイルだけ戻しても、設定やDBが欠けると元の状態には戻りません。

自動バックアップを組んだあとも、そこで安心しきらないほうが運用は安定します。
筆者は成功ログを毎回ざっと眺める流れにしてから、復旧時の冷や汗が減りました。
ジョブが動いているつもりでも、保存先の空き容量やマウント切れで中身が空のまま終わることがあるからです。
手間を増やすというより、失敗を早く見つけるための小さな習慣として効きます。

更新まわりでは、OSとパッケージの定期アップデートを止めないことが土台になります。
セキュリティ修正が入るだけでなく、周辺パッケージの不整合もため込みにくくなります。
SambaやWireGuard、Web側のミドルウェアを入れている構成では、公開前後で開放ポートの棚卸しもセットで行うと事故を減らせます。
たとえばVPN用に開けたUDPポートだけで済んでいるのか、テスト用に一時的に開けたWeb管理画面やSSHの待受が残っていないか、という確認です。
宅内では見えていなくても、外からは露出していることがあります。

公開確認の方法にも落とし穴があります。
到達確認は、宅内Wi-Fiではなくスマホ回線などの外部回線で見るのが確実です。
家庭用ルーターではNATループバックの挙動で、家の中からアクセスできても外からは入れない、あるいはその逆に見えることがあります。
自宅のWi-Fiで成功した表示だけを頼りにすると、公開できたと誤判定しやすい場面です。

電源/ストレージまわりの典型トラブル

ラズパイ運用で見逃されがちなのが、ソフトウェアより先に電源とストレージが限界を出すことです。
典型的な症状は、突然の再起動とUSBストレージの切断です。
Sambaでコピー中に共有が消えたり、Nextcloudのアップロード途中で失敗が出たりすると設定ミスに見えますが、実際には給電不足だった、ということが珍しくありません。

Raspberry Pi 5は処理性能が上がったぶん、安定した電源と十分な冷却を前提にしたほうが運用が落ち着きます。
負荷がかかったときに電圧がふらつくと、OSは動いていてもUSB側だけ不安定になることがあります。
外付けSSDをつないで常時稼働させるなら、OSの設定だけ整っていても片手落ちです。
コピーや同期、サムネイル生成のようにI/Oが重なる場面で症状が出ると、原因の切り分けが難しくなります。

USBストレージでは、ストレージそのものの消費電力も意識したいところです。
バスパワー動作のケースや変換アダプタは、接続できていても負荷時に落ちることがあります。
こういうときはセルフパワーのUSBハブや外部電源付きのSSDケースを使うと、切断や認識不良が収まりやすくなります。
ラズパイ本体から見れば同じUSB接続でも、電力の供給元を分けるだけで安定度が変わります。

ストレージの自動マウントも、運用面では地味に効きます。
/etc/fstabでUUID指定にしていても、起動順や一時的な認識失敗でマウントされないと、共有先が空ディレクトリに見えることがあります。
こうなると「ファイルが消えた」と感じやすいのですが、実際には本物のストレージが載っていないだけ、というケースがあります。
nofailやx-systemd.automountを使った設計は、起動失敗を避けながら後追いでマウントさせる運用に向いています。
設定を変えたあとに、再起動後も意図したマウントポイントへ載っているかまで見ておくと、共有トラブルの芽を早く摘めます。

速度が出ない時の見直しポイント

速度の不満は、回線やCPUよりも「どんなファイルをどう運んでいるか」で印象が変わります。
Sambaで大きな動画ファイルを数本コピーする場面は比較的素直に流れますが、写真のサムネイル、文書、設定ファイルのような多数の小ファイルをまとめて運ぶと、体感が急に鈍くなります。
ラズパイ界隈でもPi 3B+で大容量ファイル転送が十数MB/s台という報告がありましたが、小ファイル主体ではその数字より遅く感じやすいのが実際のところです。
転送ごとにメタデータ処理が細かく挟まるためです。

このタイプの遅さには、ファイルを圧縮してまとめるだけで効くことがあります。
大量の小さなファイルをそのまま投げるより、ひとつのアーカイブにしてから移すほうが、通信もディスクアクセスも単純になります。
バックアップ用途ならrsyncで差分転送に寄せると、毎回すべてを舐め直す負担を減らせます。
ブラウザやスマホとの同期を中心に使うなら、Nextcloudのクライアント同期へ寄せたほうが運用に合う場面もあります。
ファイル共有と同期は似て見えて、得意なワークロードが違うからです。

遅いときに見直したいのは、保存先がmicroSDのままになっていないか、USBストレージが不安定になっていないかという点です。
OS用のmicroSDとデータ用SSDを分けているつもりでも、一部のキャッシュや一時ファイルが遅い側へ残っていると、全体の印象が引っ張られます。
特にNextcloudでは、アップロード先だけでなくプレビュー生成やアプリ側の書き込み先も絡むため、どこにI/Oが集中しているかを意識したほうが状況を読みやすくなります。

外部公開まわりの速度確認でも、測る場所を間違えると判断を誤ります。
自宅内のWi-Fiでブラウザ表示が速いからといって、外からも同じとは限りません。
公開確認と同じで、速度の印象もスマホ回線などの外部回線で見たほうが実態に近づきます。
宅内からの試験は通っていても、外部経路ではVPNの経路、DNS、ポート転送の設定が絡んで別のボトルネックが見えることがあります。
こうした確認を内側と外側で分けておくと、「LANでは快適、外では遅い」という症状の原因を追いやすくなります。

どの構成から始めるべきか

初心者向け3構成

最初の一台で迷ったら、構成は欲張らずに3択まで絞ると判断が早くなります。
基準になるのは、家の中だけで使うのか、外出先から入りたいのか、スマホ写真を自動で集めたいのかの3点です。
ここに、使う人数と、どこまで管理を背負えるかを重ねると選びやすくなります。

1. Sambaだけ

   最短で動かしたいなら、ここから始めるのが素直です。
   家のPC同士で共有フォルダを使う、バックアップ置き場を作る、動画や写真を宅内で読む、といった用途なら十分戦えます。
   ブラウザ画面やデータベースを持たないぶん、見る場所が少なく、トラブル時も追いかける対象が絞れます。
   利用者が少なく、アクセスする場所も自宅LANの中に限るなら、この構成がいちばん軽く回ります。

2. Samba+WireGuard

   外出先から自宅の共有フォルダに安全に入りたいなら、この組み合わせが現実的です。
   普段は宅内でSambaを使い、必要なときだけWireGuardで自宅LANへ入る形なので、役割分担がはっきりしています。
   OpenWRTルーターの比較例ではWireGuardが197Mbps、OpenVPNが43Mbpsという差が出ており、VPNを新しく組むならWireGuardのほうが入りやすい構成です。
   筆者の家庭でもこの形に落ち着いていて、家族のPCバックアップと、出先で必要になった写真の取り出しが止まらず回るようになりました。
   共有はファイル共有のまま、外から入る経路だけを増やすので、構成変更の影響範囲も読み取りやすくなります。

3. Nextcloud+WireGuard

   ブラウザから触りたい、スマホアプリで写真を同期したい、家族ごとに見せる範囲を細かく分けたいならこちらです。
   単なる共有フォルダではなく、自前クラウドとして使う発想に近くなります。
   その代わり、ファイル置き場だけでなく、データベースや権限設計、保存先の考え方まで面倒を見る必要があります。
   複数人で使い、スマホ自動同期を日常運用に入れたいなら価値がありますが、最初の一歩としてはSambaより管理項目が増えます。

選ぶときは、利用者数が1人か家族共有か、外出先アクセスがたまに必要なのか日常なのか、スマホの自動同期が必須か、そして自分がDBや権限設計まで持てるかで決めると外しにくくなります。
ストレージの使い方も分かれ目で、単純な共有倉庫ならSamba、写真同期や履歴管理まで欲しいならNextcloud寄りです。
OS用にはRaspberry Pi OS Liteなら16GB以上、通常版なら32GB以上が目安なので、まずはLiteで軽く始め、データ本体は外付けSSDに逃がす組み方が収まりやすいと感じます。

次のアクション

ここまで読んで方針が見えたら、作業順は一直線で進めるのが失敗を減らします。
最初から全部入れず、1段ずつ確認しながら積むほうが、どこで崩れたかを切り分けられます。

• Raspberry Pi OS Liteを入れて、まずSSHで入れる状態にする
• LAN内だけでSamba共有を作り、PCから読み書きできることを確認する
• 外から使いたくなった段階でWireGuardを追加する
• ブラウザ利用やスマホ同期が必要になったらNextcloudを載せる
• 運用前にバックアップ方針と復旧手順を決めておく

公開時の編集作業として、本文内の該当箇所へ内部リンクを最低2本追加してください（現時点でサイトに既存記事がないため、本文には実リンクを挿入していません）。

この順番なら、最初のゴールを「LAN内で共有が動く」に置けます。
そこまで到達してから外部アクセスや同期機能を足すと、設定の意味が頭の中でつながります。
まずは動かして、必要になった機能だけを増やす進め方が、初めての自宅サーバーではいちばん息切れしません。