自宅NASにClaude Code専用サンドボックスを作った全記録｜DXP2800 × Tailscale × Docker

更新日：2026年8月5日｜カテゴリ：その他・技術メモ

1. なぜ自宅 PC ではなく NAS に Claude Code を置いたのか

もともと私は、自宅 Windows 11 デスクトップの WSL（Ubuntu）で claude --dangerously-skip-permissions を動かしていました。気持ちが揺らいだのは、出張中に「自宅でやりかけのリポジトリを少しだけ触りたい」と思った瞬間です。ノート PC にも同じ環境を作れば動きますが、プロジェクトファイルは自宅のデスクトップに置きっぱなし。コミット前の作業や検証用フォルダはそうそう持ち出せません。

もう 1 つ気になっていたのが、--dangerously-skip-permissions のリスクです。確認なしにファイル操作やコマンド実行が走るため、Web から拾ったサンプルコードを誤ってフル権限のセッションで実行すれば、母艦の WSL 環境を壊しかねません。母艦のファイルシステムから完全に切り離すほうが筋がいい、と感じていました。

2. 全体構成の俯瞰：Tailscale と Docker をどう組み合わせたか

先に完成形を言葉で書いておきます。クライアントから NAS のコンテナまで、データはこういう順で流れます。

[ Win11 PC / Mac / スマホ / 他PC ]
   ↓  Tailscale VPN（WireGuard、tag:client のデバイスだけ）
[ Tailscale Tailnet（100.x.x.x プライベートIP空間）]
   ↓
[ DXP2800 NAS ]
  ├─ ts-sandbox コンテナ（Tailscale 本体、ネット入口）
  └─ claude-workspace コンテナ
       └ network_mode: service:tailscale（独自NIC無し）
       ├─ /workspace ← /volume1/sandbox/projects（bind mount）
       └─ Docker volume × 5（Claude設定 / gh / git / secrets / ssh）

2 つのコンテナを Docker Compose で動かしています。1 つは Tailscale 本体だけが入った軽量な ts-sandbox、もう 1 つは Claude Code・GitHub CLI・OpenSSH サーバ・ビルドツールを詰めた claude-workspace。両者を network_mode: "service:tailscale" でつなぎ、claude-workspace 側は独自のネットワークインターフェースを持たない構成にしています。

この設計の旨味は「LAN からの直接 SSH の経路が構成上できない」点です（設定を誤らない限り、の前提つき）。普通に Docker でポートをマッピングする方式だと NAS の LAN IP に 22 番が開いて家の Wi-Fi 内から見つけられる余地が残ります。一方、Tailscale コンテナへの相乗り構成ならコンテナの 22 番は Tailnet 上の仮想 IP にしか露出しません。Tailscale を持っていないデバイスからは存在自体が見えない、という遮断層になります。

永続化も最初から意識しました。プロジェクト本体は NAS シェアフォルダ /volume1/sandbox/projects/ に置いてコンテナ内 /workspace/ に bind mount。コンテナを作り直しても作業ファイルは消えず、Windows のエクスプローラから SMB 経由で覗けます。Claude 設定、gh 認証、SSH 公開鍵、シークレットは Docker ボリュームに分けて、Windows から不用意に開けないよう区分けしました。

3. 主要な設計判断 5 つ

④ を選んだ時点で「フル権限の Claude Code が外部に何かを持ち出す経路が技術的にはある」状態になります。設計だけでは塞ぎきれないので、シークレット隔離・信頼境界・GitHub 二重化といった運用ルールでカバーする方針にしました。具体的なルールはClaude Code を --dangerously-skip-permissions で安全に使うための運用ルールで詳しく解説しています。

4. 構築プロセスのハイライト：うまくいった所

全手順を書くと相当な分量になるので、本記事では「うまくハマった」要点だけ抜粋します。コマンド全文は続く詳細記事に譲ります。

4-1. 「永続化すべきもの」を最初に紙へ書き出した

これが一番効きました。プロジェクト本体、Claude 設定、gh 認証、Git 設定、シークレット（パーミッション 700）、SSH 鍵、Tailscale ステート。書き始める前にメモアプリへ洗い出してから docker-compose.yml に落としたので、後の手戻りが小さく済みました。とくに SSH 公開鍵（authorized_keys）はコンテナ再ビルドで消えやすい要注意ポイントで、named volume での永続化設計はDocker × OpenSSH で公開鍵を永続化する正しい設計で詳しく解説しています。

4-2. Compose のコアは「相乗り」と「ヘルスチェック」

Compose で重要なのは 2 か所です。1 つは claude-workspace 側の network_mode: "service:tailscale"。もう 1 つは depends_on の condition: service_healthy と、Tailscale 側の healthcheck（tailscale status をプローブにする）のセット。これがないと Tailscale のセッション確立前に sshd が起動して、再起動直後だけ SSH が拒否される症状に悩まされます。

4-3. ベースイメージは node:20-slim（UID 1000 重複に注意）

Claude Code は 2026 年以降ネイティブインストーラが既定ですが、コンテナでバージョンを固定したいなら公式 devcontainer でも使われる npm install -g @anthropic-ai/claude-code が確実で、node:20-slim ベースが素直に使えます。ただしこのイメージには既に UID 1000 の node ユーザーがあるので、Dockerfile の冒頭で userdel -r node してから自分のユーザーを作っています。cc='claude --dangerously-skip-permissions' という短いエイリアスを ~/.bashrc に入れて、タイプ数節約と意識付けを兼ねさせている小ネタもあります。

※ 補足（2026 年 7 月時点）：Node.js 20 は 2026 年 4 月にメンテナンス終了（EOL）を迎えました。これから新しく構築する場合は node:22-slim など現行 LTS ベースへの置き換えを推奨します（本記事の手順・考え方はそのまま使えます）。

4-4. Tailscale ACL は新しい grants 文法

Web 上の解説は古い acls 文法のものが多いのですが、私のテナントは新しい grants 文法（Tailscale 公式 Docs「Grants」）が初期値でした。tagOwners で tag を登録し、grants で「tag:client から tag:sandbox へだけ通す」と書く形に落ち着いています。締め出し防止に「自分自身（admin）はどこにでも入れる」grants を 1 行入れておくのが、運用上の保険として効きました。ポート開放ゼロで NAS を外に出さない Tailscale × Docker の設計手順は、Tailscale × Docker で NAS を公開しないリモート開発環境を作る方法で個別にまとめています。

5. ハマって学んだ 4 エピソード

うまくいった話だけだと楽勝に見えるので、特に学びが大きかった 4 つを抜粋します。

5-1. Docker グループの「再ログイン忘れ」

UGOS Pro 上で Docker を入れた直後に docker compose up を叩くと permission denied while trying to connect to the Docker daemon socket が出ます。sudo usermod -aG docker $(whoami) はDocker 公式の手順どおりですが、ログアウトと再ログインを挟まないと反映されないのがトラップでした。最初に docker ps を sudo なしで叩いてテストするのが、NAS Docker を触るときの私の鉄則になりました。

5-2. Tailscale ACL を書く前に Auth Key を発行した

Admin Console で Auth Key に tag:sandbox を付けたものの、ACL 側で tagOwners に登録していなかったため、コンテナ側で requested tags [tag:sandbox] are invalid or not permitted になり unhealthy になりました。正しい順序は「ACL を先に書く → Auth Key を発行 → コンテナを起動」。Tailscale 関連は「ACL ファースト」が時短のコツです。

5-3. Tailscale SSH で failed to look up local user エラーの原因と対処

症状：tailscale ssh を有効にして接続すると failed to look up local user が返り、ログインできない。 原因：network_mode: "service:tailscale" の相乗り構成では、Tailscale 本体コンテナ（ts-sandbox）側に claude-workspace のユーザーが存在しないため、Tailscale SSH がローカルユーザーを解決できない。 解決：Tailscale SSH をあきらめ、claude-workspace に OpenSSH サーバを立てて公開鍵認証に任せる（本記事の設計判断⑤と同じ結論）。相乗り構成では OpenSSH のほうが素直に通る。単独 NIC 構成に組み替えれば Tailscale SSH も使えますが、LAN 直アクセス不能という設計利益を捨てることになるので、私は OpenSSH を選びました。

5-4. Claude Desktop の Code タブからだけ SSH が通らない

最終盤で一番厄介だったのが、Claude Desktop からの SSH 接続です。PowerShell の ssh では問題なく繋がるのに、Code タブからだけ Permission denied (publickey) や「All configured authentication methods failed」が出る。詰まっていたのは Claude Desktop が呼ぶ ssh（Git for Windows 同梱版）が passphrase を対話で聞こうとしていて、Code タブには答える入力欄がないことでした。解決は ssh-keygen -t ed25519 で passphrase なしの鍵を作り直し、~/.ssh/config の IdentityFile でその鍵だけを使わせるだけ。丸 2 日溶かしたので、切り分けから解決手順までを独立記事にまとめました。

関連記事：Claude Desktop の Code タブで Permission denied (publickey) が出る本当の原因と解決法

ここまでの 4 つのつまずきは、どれも「自分の機材（NAS）の上に環境を作る」ゆえの手間です。同じ隔離環境をクラウド側に置く選択肢もあり、ConoHa VPS はサーバー作成時に選べるテンプレートとして Claude Code のスタートアップスクリプトを用意していると案内しています（利用には Anthropic 側の契約が別途必要／ソースコードを自宅の外に置くことになる点は、私が NAS を選んだ理由の裏返しです）。

スタートアップスクリプトの内容・前提条件はConoHa 公式ドキュメント「Claude Code」を参照（2026 年 8 月 5 日確認）。料金・性能は当サイトでは検証していません。

6. 完成した環境でできるようになった 4 つのこと

構築が終わってみると、当初の目論見以上に多くの経路から同じ環境に入れるようになりました。日常的に使っている 4 経路です。

クライアントを増やすときも、Tailscale で tag:client を付けて公開鍵を authorized_keys に足すだけ。「コンテナ側は何も変えずにクライアントを増やせる」のは Tailscale + 公開鍵認証の恩恵が分かりやすく出る場面です。

7. 数週間運用してみての所感

2026 年 4 月から運用を始めて約 3 か月（初稿時点では数週間）。使い心地と改善したい点を率直に書きます。

意外だったのは、「自宅 LAN 内にいるときも、わざわざ Tailscale 経由で繋ぐ」習慣がついたことです。経路を 1 本に絞ると運用の頭の使い方がシンプルになり、入り口は常に dxp2800-sandbox-1。VPN を使い慣れていない方ほど、想像以上にメリットを感じる部分だと思います。

8. これから NAS で Claude Code をやってみたい方へ

NAS 本体をこれから選ぶ場合は、Docker が快適に動く x86 CPU 搭載機（DXP2800 や Synology DS225+ など）を選ぶのがポイントです。N100 などの x86 機なら Docker も Claude Code も"そのまま"動き、ARM 機で「対応イメージが無い」と詰まる回り道を最初から避けられるのが最大のベネフィットです。予算帯ごとの候補は家庭用NASおすすめ予算別ランキングで比較できます。

私自身が本記事で使っている実機は UGREEN DXP2800（Intel N100・8GB DDR5・M.2 NVMe ×2）です。M.2 スロットを持つ x86 2 ベイ機は、workspace や git を NVMe SSD に載せて I/O 律速を減らせるため、Claude Code のような対話 CLI との相性が良好でした。

DXP2800・DS225+ はどちらも HDD 別売なので、NAS 用ドライブを 1 本用意しておくと届いた初日から動かせます。私の DXP2800 も購入時は本体のみで、WD Red Plus 4TB を後追いで導入しました。NAS 用 HDD は連続稼働・振動耐性・エラー訂正リカバリの設計がデスクトップ向け HDD より一段強く、常時稼働の Claude Code サンドボックスのような用途ではその差が効いてきます（PC 用の一般 HDD で代用すると、24 時間稼働の熱と振動で寿命が短くなりがち）。

容量は最初の 1 本なら 4TB か 8TB が扱いやすく、Claude Code のワークスペース・Docker イメージ・ビルドキャッシュ・SMB 共有まで含めても当面の余裕が確保できます。RAID を組みたい場合は同容量 2 本セットが基本で、私の構成でも同じモデルを 2 本用意しました。容量選定の考え方はNAS用HDDおすすめランキングに詳しくまとめています。まず 1 本試すなら、実測で回した中では次の WD Red Plus 4TB が扱いやすく定番です。

9. よくある質問（FAQ）

※ 本構成の各論は別記事で詳しく解説しています：Tailscale × Docker 設計／OpenSSH 鍵の永続化／フル権限運用ルール。

10. まとめ：NAS は Claude Code 専用サーバとして十分に化ける

NAS は写真や動画の倉庫としての印象が強い機器ですが、Docker と VPN を組み合わせると「常時稼働の自宅開発サーバ」に化けます。本記事は全体俯瞰のメインで、ネットワーク設計、SSH トラブルシュート、永続化パターン、フル権限運用ルールといった各論は独立した記事で詳しく解説しています。下の各論から、興味のある切り口で読み進めていただければと思います。

関連記事：Tailscale × Docker で NAS を公開しないリモート開発環境を作る方法【ポート開放ゼロ】

関連記事：Docker × OpenSSH で公開鍵を永続化する正しい設計｜authorized_keys を消さない構成

関連記事：フル権限 Claude Code（--dangerously-skip-permissions）を安全に運用する 5 つの運用ルール

関連記事：Claude Desktop の Code タブで Permission denied (publickey) が出る本当の原因と解決法