2026.06.03 2026.06.03

フル権限 Claude Code（–dangerously-skip-permissions）を安全に運用する 5 つの運用ルール｜NAS サンドボックス実践ガイド

yamakashi

本記事はアフィリエイト広告を含みます

更新日：2026年5月13日｜カテゴリ：NAS応用

結論：`--dangerously-skip-permissions` の利便性を活かしつつ、5 つの運用ルールでリスクを技術と習慣の両面からカバーします

Claude Code を --dangerously-skip-permissions 付きで動かすと、コマンド実行のたびに承認を求められないので開発体験は別物になります。一方でこれは「フル権限の AI エージェントを自分のシェルで走らせる」のと同じです。完全に安全な構成は存在しませんが、シークレット隔離・最小スコープ PAT・信頼境界の明示・GitHub 二重化・Auth Key の取り扱いという 5 つの運用ルールで、現実的な範囲までリスクを下げることはできます。

本記事は、私（yamakashi）が UGREEN DXP2800（NAS）上に Claude Code 専用サンドボックスを構築・運用してきた経験をベースにした実践ガイドです。「絶対安全」「100% 守れる」といった表現は避け、あくまで「破られにくくする・気づきやすくする」ための運用ルールとして整理しています。

1. `--dangerously-skip-permissions` の利便性と本質的なリスク

Claude Code はデフォルトでは、ファイル書き込み・コマンド実行・外部通信など副作用のある操作の前にユーザーに承認を求めます。安全側に倒した設計ですが、自動化スクリプトを長く流したい時や試行錯誤させたい時には、毎回の承認が体感速度を大きく削ります。これを外すのが --dangerously-skip-permissions です。私はサンドボックス内 .bashrc に以下のエイリアスを仕込んでいます。

alias cc='claude --dangerously-skip-permissions'

cc と打つだけで承認プロンプトなしのセッションが立ち上がり、ファイル編集・git 操作・npm/pip インストール・テスト実行までを 1 回の指示でまとめて任せられます。

裏側で何が起きているか
このフラグを付けた Claude Code は、そのプロセスのユーザー権限でできることなら何でも実行できる状態になります。「悪意あるコードに気づかず実行する」「rm -rf 系の事故」「外部にデータを送信する処理」も技術的には止められません。

これは「フラグが危険」というより「フル権限の AI エージェントを使うとはそういうことだ」という話です。ローカル PC で同じ運用をすると、家計簿の Excel から業務リポジトリの未コミット差分まで全部スコープに入ります。そこで私は、NAS 上の Docker コンテナという信頼境界を分けた場所に Claude Code を閉じ込めて、その内側でだけフル権限運用しています。とはいえコンテナという「箱」を用意するだけでは不十分で、技術的な遮断と、運用ルールとしての習慣を組み合わせて、初めて運用が成り立つというのが、半年ほど触ってきた実感です。

2. inbound と outbound の非対称セキュリティモデル

具体的なルールに入る前に、土台になっている考え方を整理します。私のサンドボックス環境は、通信の入口（inbound）と出口（outbound）で守り方を意図的に変えています。

方向	守り方
inbound（外部・LAN からの侵入）	Tailscale VPN + ACL + OpenSSH 公開鍵で多層防御
outbound（Claude API・npm・pip・git push）	原則フリー（運用ルールでカバー）

inbound 側は厳しく作っています。NAS のポートを外部に公開せず、Tailscale Tailnet 経由でしか到達できない構成、network_mode: "service:tailscale" でコンテナを LAN にも露出させない構成、その上で OpenSSH の公開鍵認証のみ、という層構造です（詳細は記事 1・記事 2 で扱う予定）。

一方の outbound はあえて緩くしてあります。Claude API・npm・pip を塞ぐと開発体験が大きく落ちるためです。「outbound を緩く保つ代わりに、抜かれて困るものを物理的にコンテナへ持ち込まない」というのが本記事の前提で、「持ち出されて困るものは最初から中に置かない」「持ち出された時の影響範囲を最小化する」方向で運用ルールを組み立てています。

3. 運用ルール 1：シークレットは `~/.secrets/` に隔離する

もっとも重要なのは、本番環境の認証情報を Claude Code の作業範囲に置かないことです。私の構成ではコンテナ内に 2 つの領域を分けています。

/workspace/               ← Claude Code が自由に触る領域（NAS シェアフォルダにマウント）
/home/yamakashi/.secrets/ ← Claude Code に普段は読ませない領域（700、別ボリューム）

~/.secrets/ は私自身が手動で source しない限り読み込まれない場所で、本番 API キー・DB パスワード・各種クラウド認証情報を .env 形式で置きます。使う時だけ source ~/.secrets/prod-api-keys.env のように手動で読み込みます。

このルールの肝は、「Claude Code に本番認証情報を渡すかどうかを、自分が毎回明示的に判断する」点です。シークレットが /workspace/.env に置かれていると、Claude Code が別ファイルに転記したりログに吐き出したりするリスクが残ります。~/.secrets/ に隔離して手動 source する運用なら、少なくとも「無自覚に渡してしまう」事故は減らせます。

4. 運用ルール 2：GitHub PAT は Fine-grained で最小スコープ

サンドボックスから GitHub にアクセスする時は、必ず Fine-grained Personal Access Token を使い、リポジトリ単位でスコープを絞っています。設定の要点は次のとおりです。

項目	設定値
トークン種別	Fine-grained tokens（Classic ではなく）
Repository access	触る予定のリポジトリだけを個別に選択
Permissions	Contents：R/W、Metadata：R、Pull requests：R/W 程度に最小化
Expiration	90 日（強制ローテーションが起きるように）

Classic PAT は「アカウント全リポジトリ × repo スコープ」のような粗いスコープになりやすく、漏れた時の被害がアカウント全体に広がります。Fine-grained PAT はリポジトリ単位で切れるので、漏れても影響範囲がそのリポジトリに閉じるのが大きな違いです。期限が切れるとサンドボックスでの git push が失敗するので、「いま自分が何のリポジトリにアクセス権を渡しているか」を再点検する習慣にもなります。

5. 運用ルール 3：信頼境界を明示する（trusted / untrusted）

サンドボックスのプロジェクト置き場 /workspace/ は、すべてが同じ温度感のファイルではありません。自分のリポジトリと、Web から拾ってきた検証用コードは扱いを分けるべきです。私はディレクトリ名でこれを明示しています。

/workspace/
  ├── trusted/     ← 自分のリポジトリ、信頼できる OSS
  └── untrusted/   ← 動作未確認の OSS、Web から拾ったコード（~/.secrets/ は読まない）

セッション開始時に Claude Code に対して「今日は /workspace/trusted/blog-system/ で作業して」と明示的に指定するのが、このルールの実運用です。プロジェクトのルートを明示することで、Claude Code が find / のような粗い探索を打つ余地を減らし、作業範囲を絞れます。

エピソード：作業フォルダ未指定でホームディレクトリ起動になった話

この「明示的に指定する」がいかに大事か、私自身が体験したヒヤリの話を共有します。Claude Desktop の Code タブで NAS サンドボックスに SSH 接続できるようになった時、何度か 作業対象フォルダの指定を忘れて接続を始めてしまったことがあります。SSH ログイン直後のカレントディレクトリ /home/yamakashi/ でそのまま Claude Code セッションが立ち上がり、~/.claude/ や ~/.ssh/、~/.secrets/ までもがエージェントの作業範囲に含まれる状態になっていました。Claude Desktop の Code タブはプロンプト入力欄の上に「フォルダを選択」ボタンがあり、これを押して作業対象を指定する操作が必要なのですが、慣れないうちは押し忘れます。

このとき技術的には何が露出していたか
・~/.ssh/authorized_keys（公開鍵リスト）／~/.claude/（認証トークンや会話履歴）
・~/.config/gh/（GitHub CLI 認証）／~/.secrets/（700 だが、実行ユーザー自身は読める）

幸い実害はありませんでしたが、このとき強く実感したのは、セキュリティは設計だけでなく操作習慣の側でも担保しないと成立しないということです。network_mode: "service:tailscale" でいくら LAN を遮断しても、コンテナ内のシェルから始まるパスを操作者が間違えれば、設計が想定する境界はあっさり越えてしまいます。

セッション開始時のチェック
Claude Code 起動前に pwd でカレントディレクトリを確認し、/workspace/trusted/<project> か /workspace/untrusted/<project> のいずれかに cd 済みであることを確認する。Claude Desktop の Code タブからの接続では「フォルダを選択」を必ず押す。

6. 運用ルール 4：重要プロジェクトは GitHub に二重化する

4 つ目はセキュリティというより耐障害性の話です。サンドボックスを NAS 上に作っていると、NAS 自体の障害・誤操作・ファイル消失のリスクがついて回ります。フル権限 Claude Code を走らせる以上、操作ミスで rm -rf 系のコマンドが実行される可能性もゼロではありません。

私の運用では、価値のあるプロジェクトはすべて GitHub に push しておきます。git push 習慣を徹底することで、NAS 側で何か起きても別マシンで git clone し直せば元の状態に戻せます。付随する細かい習慣として、ローカル開発機にも同じリポジトリを clone しておく・UGOS Pro 側のスナップショット機能を併用する・大きめの変更を Claude Code に任せる前に push する、といったことを心がけています。NAS は便利だが特別な保険にはならない、というのが個人 NAS を 10 年以上運用してきての所感です。

7. 運用ルール 5：TS_AUTHKEY と認証情報の取り扱い

サンドボックスを Tailscale で組んでいる関係で、もうひとつ気を遣うのが Tailscale Auth Key（TS_AUTHKEY）の取り扱いです。Auth Key は Tailnet にデバイスを参加させる権限を持つので、漏れると「自分の Tailnet に勝手にデバイスを足される」リスクがあります。

項目	運用
配置場所	`/volume1/sandbox/docker/claude-workspace/.env`
シェアフォルダ権限	自分のユーザーのみ R/W、ゲストアクセス無効
git の扱い	`.gitignore` に `.env` を必ず含める
有効期限	Expiration を短めに（90 日など）
漏洩疑いがあったら	Admin Console → Settings → Keys から即時 revoke

Tailscale Admin Console は Auth Key の発行・失効を Web UI から数クリックで行えるので、何かおかしいと感じた瞬間に止められる体制を作っておくのが大事です。発展形として HashiCorp Vault や 1Password CLI のようなシークレットマネージャを使う方向もありますが、個人ホームラボの規模だとオーバーキルになりがちなので、「ファイル権限を絞る + 漏れたらすぐ revoke できるようにしておく」あたりが現実的なラインです。

SSH 公開鍵・GitHub PAT も同じ発想で扱う
SSH 鍵は authorized_keys から該当行を削る、GitHub PAT は Settings → Developer settings から Revoke、Tailscale デバイスは Admin Console から Remove。これらの「止め方」を平時から把握しておくこと自体がセキュリティの一部です。

8. 月 1 回の異変チェックを習慣にする

5 つのルールを徹底しても、想定外のことは起きます。気づかないうちに何かが起きていないかを定期的にチェックする習慣として、私は月 1 回ほどの軽い点検を入れています。

チェック項目	見るポイント
UGOS Pro のリソースモニタ	CPU・帯域に不自然な張り付きがないか
`docker stats claude-workspace`	アイドル時にネットワーク送出が続いていないか
Tailscale Admin Console → Logs	身に覚えのない認証試行・新規デバイス追加がないか
GitHub Settings → Security → Audit log	想定外の時刻・IP からのトークン利用がないか

docker stats は私が一番頻繁に見ている指標です。Claude Code を使っていない時間帯でも常に外部に大量送信しているコンテナがいたら、何かが裏で動いている可能性があります。「いつもと違う」と気づける状態を保つのが、ホームラボ規模の現実的なモニタリングだと思います。

9. 将来 outbound 制限を入れたくなったら

現状の私の運用は outbound フリーですが、扱うデータの機微度が上がった時の選択肢として 2 つの方向性があります。1 つは Tailscale Exit Node 経由で、別マシン（VPS や Raspberry Pi）を Exit Node 化してそこに出口を集約し、AdGuard Home や Squid プロキシでドメイン単位のフィルタやログ取得を行う方法。もう 1 つは iptables でホワイトリスト制御で、tailscale コンテナの cap_add: NET_ADMIN を使い、ipset + DNS 解決スクリプトで定期更新する運用になります。

どちらも一手間かかるので、私は今のところ「運用ルールでカバーする」方向で割り切っています。重要なのは、必要になった時にいつでも追加できる構成上の余地を残しておくことです。network_mode: "service:tailscale" でコンテナの出口を 1 か所にまとめておくと、後から制限を入れる時の作業箇所が小さくて済みます。

10. よくある質問（FAQ）

Q1. SSH 鍵には passphrase を付けたほうがよいですか？

A. 環境によります。Tailscale VPN のように到達経路自体に強い制限がある場合は passphrase なしでも脅威モデルは小さめですが、PC を持ち歩く・家族と共用するような場合は付ける価値が高くなります。Claude Desktop の Code タブのように対話的に passphrase を入力できないクライアントでは ssh-agent 併用が前提になる点に注意してください。私自身は Tailscale + 単一の Windows 個人 PC という構成のため、現在は passphrase なしで運用しています。

Q2. Claude Code 自体が信頼できるかどうか、どう考えていますか？

A. 「100% 信頼している」とは私も言えません。私は Anthropic 社の利用規約とセキュリティ設計を信頼してフル権限を渡していますが、Claude Code が引っ張ってきたコード（npm パッケージや Web 由来のスニペット）に悪意あるものが混じる可能性は別問題として残ります。だからこそ本記事のシークレット隔離・信頼境界のルールが効いてきます。エージェント本体ではなく、エージェントが扱うコード・データ・認証情報側でリスクを管理する発想です。

Q3. 子供にも触らせていい環境ですか？

A. 私の構成をそのまま家族と共用するのはおすすめしません。--dangerously-skip-permissions は「自分が責任を持って指示を出す」前提だからです。学習用途で触ってもらうなら、フル権限フラグを外したデフォルト Claude Code に切り替える、コンテナ内 OS ユーザーを分ける、といった工夫が必要になります。

Q4. 業務用途でも同じ構成でいけますか？

A. 個人開発・個人事業主の範囲なら本記事のルールでスタートラインには立てると思います。会社の業務データを扱う場合は所属組織のセキュリティポリシーが優先で、outbound 制限・SSO 連携 Tailscale・シークレットマネージャ必須化など、一段重い構成になることが多いです。本記事はあくまで「個人ホームラボの運用例」と位置づけてください。

Q5. 仮想マシン（VM）と比べて Docker コンテナで十分ですか？

A. 分離レベルは VM のほうが強いです（独立カーネル）。一方コンテナは起動コスト・ディスク使用量・ネットワーク設計の柔軟性で勝ります。「NAS 上にリモート開発環境を作りたい」「network_mode: service:tailscale を使いたい」目的ならコンテナで十分実用的です。目的に対して過剰でない範囲で、できるだけ分離を強めるのが現実的な落としどころだと考えています。

11. まとめ：技術と習慣の両輪で運用する

この記事で押さえた 5 つの運用ルール
1. シークレットは ~/.secrets/ に隔離し、/workspace/ 配下に本番認証情報を置かない
2. GitHub PAT は Fine-grained で、リポジトリ単位・最小権限・短い Expiration
3. /workspace/trusted/ と /workspace/untrusted/ で信頼境界を明示し、セッション開始時にフォルダを必ず指定する
4. 重要プロジェクトは GitHub に二重化し、NAS 消失リスクに備える
5. TS_AUTHKEY・SSH 鍵・PAT の「止め方」を平時から把握しておく

フル権限の Claude Code は便利ですが、便利さの背後には「自分が責任を持って範囲を区切る」ことが前提になっています。本記事の 5 つのルールはいずれも難しい技術や高価なサービスを要求するものではなく、日々の操作習慣と最低限のアクセス権設計でほぼ実現できます。技術的な遮断と運用習慣の両輪で運用するという発想を持っておくと、Claude Code のようなフル権限エージェントとも、必要以上に身構えずに付き合えるはずです。

私自身、半年ほどこの構成で運用してきて「絶対安全」と言えるラインには到達していません。ただし、「いつもと違う」に気づける状態を保ち、漏れた時の影響範囲を小さくしておくだけで、フル権限フラグをオンにするハードルはだいぶ下がります。本記事が、これから Claude Code をホームラボに迎え入れる方の参考になれば嬉しいです。

関連記事：自宅 NAS に Claude Code 専用サンドボックスを作った全記録（公開準備中）／Tailscale × Docker で公開しないリモート開発環境を作る方法（公開準備中）／Claude Desktop の Code タブで Permission denied (publickey) が出る本当の原因と解決法／Docker × OpenSSH で公開鍵を永続化する正しい設計（公開準備中）

ABOUT ME