Claude Code サーバー実行 安全 権限 設定 方法

サーバー上で Claude Code を安全に実行するとは

サーバー上で Claude Code を安全に実行するには、権限確認のプロンプトを有効にしたまま、専用の非特権ユーザーとして実行し、自動実行には信頼ではなく実際の境界を与えます。組み込みサンドボックス、コンテナ、または重要なデータを一切保持しない使い捨ての VPS がその境界です。--dangerously-skip-permissions フラグは、モデルとシェルの間の承認ステップを取り除きます。このトレードオフは自動化された作業では合理的ですが、それは 1 つの誤ったコマンドが到達できる範囲を制限する境界の中でだけです。このガイドでは、このフラグが実際に何を変更するのか、そして隔離レベルを段階的に高めながらその境界を構築する方法を説明します。

Claude Codeがサーバー上で実行できること

Claude Codeは端末で動作するコーディングエージェントです。起動したユーザーとして、ファイルの読み取り、ファイルの書き込み、シェルコマンドの実行を行います。これがこのツールの価値のすべてです。リポジトリのクローン、コードの編集、テストの実行、失敗の読み取り、コードの修正を、ユーザーが毎回コマンドを入力することなくループで実行できます。まだサーバーにセットアップしていない場合は、tmuxを使ったVPSでのClaude Code実行でインストールとセッション管理を解説しています。このページでは、セットアップ後に与える権限の範囲について説明します。

リスクは、同じ文をもう一度読んだものです。ユーザーとしてシェルコマンドを実行するプロセスは、そのユーザーができることはすべて実行できます。~/.ssh/id_ed25519、~/.aws/credentials、そしてユーザーが開けるすべての.envファイルを読み取れます。curlを実行し、サーバーが到達可能な任意のホストにデータを送信できます。git push --forceも実行できます。エージェント自体に動機はありません。危険なのは、タスクが誤った方向に進む場合、あるいは作業中に読み取ったテキストに他者が書いた指示が含まれていた場合です。取得したWebページや、修正を依頼されたIssue内のコメントなどです。後者のケースはプロンプトインジェクションと呼ばれ、「モデルは通常は分別がある」ということがセキュリティ計画にならない理由です。平均的な実行ではなく、悪い実行に備えて計画を立てます。

権限システムを平易に説明する

デフォルトでは、Claude Codeは操作前に確認を求めます。プロジェクト内のファイル読み取りは無言で行われますが、ファイル編集やシェルコマンド実行では、まず具体的な編集内容やコマンドを表示し、承認を待ちます。1つの操作だけを承認するか、その種類の操作をセッション中は常に承認するかを選べます。これらの承認はセッション単位です。CLIを終了すれば、次のセッションは再び慎重な状態から始まります。維持したいルールのために、設定ファイルには永続的な許可・確認・拒否リストがあります。例：git statusを許可、git pushを確認、.envの読み取りを拒否。拒否ルールが常に優先されます。

この設計は、人間が端末を見ていることを前提としており、ノートPCではそれが当てはまります。サーバーでは、誰も見ていないことがしばしば前提です。tmux内で長時間のタスクを開始して就寝した場合、エージェントが午前2時に質問のために停止すると、朝まで何も進みません。この停止は時間だけでなくコストも発生させます。アイドル状態のClaude Codeセッションはウォームプロンプトキャッシュを失い、次のターンでその再構築にコストがかかるからです。これが、サーバーでスキップフラグに手を伸ばす正直な理由であり、それが解決する問題は現実のものです。このガイドの残りの部分は、すべてのガードレールを放棄せずにこの問題を解決する方法について説明します。

--dangerously-skip-permissions が変更するもの

claude --dangerously-skip-permissions は承認ステップを無効にします。編集は確認なしで行われます。シェルコマンドも確認なしで実行されます。通常は重要な場所を保護するパスチェックもスキップされます。明示的な拒否ルールは引き続き適用され、一部の極端な操作では依然として確認を求めますが、動作の要約はシンプルです。モデルが実行を決定したものは、そのまま実行されます。

サーバーにおいて、このフラグに関する重要な事実が二つあります。第一に、Linux および macOS 上で Claude Code が root または sudo で実行されている場合、このフラグはブロックされます。確認なしの root 権限は、マシン上のあらゆるファイルやサービスを変更できるためです。エージェントはいずれにせよ独自の非特権アカウントを必要とし、このフラグはそれを強制します。第二に、このフラグはモデルの動作を一切変更しません。人間をループから外すだけで、他には何も変えないため、本来なら確認プロンプトで防げたはずのミスが、そのまま実行されます。

そこで、率直な判断基準を示します。パーミッションをスキップする場合、セキュリティ上の問いは「エージェントが何か悪いことをするか」から「一度の悪い操作でどれだけの損害が生じうるか」へと変わります。あなたはすべての決定を制御しようとするのをやめ、代わりに被害範囲の制御を始めることになります。封じ込めが答えであり、それは段階的に実現されます。

Claude Code 組み込みサンドボックス

段階的な対策に入る前に、まず知っておくべきことがあります。Claude Code は現在、実行するコマンドに対して OS レベルのサンドボックスを標準搭載しており、これにより、これまでスキップフラグに頼っていた理由のほとんどが解消されます。Linux では、ファイルシステムの隔離に bubblewrap を使用し、ネットワークトラフィックをプロキシ経由でルーティングするために socat を併用します。サンドボックス内では、コマンドはプロジェクトディレクトリとセッション一時ディレクトリにのみ書き込み可能で、ネットワークへは、すべてのドメインを許可リストと照合するプロキシ経由でのみアクセスできます。新しいドメインへのアクセスが初めて要求された場合、Claude Code が確認を求めます。

セッション内で /sandbox コマンドを使用して有効にします。Ubuntu と Debian では、事前に必要な2つのパッケージをインストールしてください。

sudo apt install bubblewrap socat

Ubuntu 24.04 以降では、デフォルトの AppArmor ポリシーにより、bubblewrap が必要とするユーザー名前空間の作成が阻止されます。何か不足している場合、サンドボックスパネルがその旨を通知し、Claude Code のサンドボックスドキュメントには、これを修正する短い AppArmor プロファイルが記載されています。

サンドボックスには自動許可モードがあります。サンドボックス化されたコマンドはプロンプトなしで実行されます。これは、強制された境界が、以前プロンプトが担っていた役割を果たすようになったためです。サンドボックス内で実行できないコマンドは通常の権限フローにフォールバックするため、本当に例外的な操作については引き続き確認が求められます。ほとんどのサーバーワークフローにおいて、これはスキップフラグの正しい代替手段です。OS によって強制される境界により、質問がゼロになるのではなく、大幅に減少するからです。

その限界について正直に理解しておきましょう。デフォルトでは、サンドボックス化されたコマンドは、資格情報ファイルを含むファイルシステムの大部分を依然として読み取ることができます（それらのパスを拒否設定しない限り）。sandbox.credentials 設定はまさにそのために存在します。ネットワークプロキシはドメイン名をチェックし、トラフィック自体は検査しないため、github.com のような広範な許可は依然としてデータ流出の余地を残します。Docker はサンドボックス内では動作しません。サンドボックスは最低限の安全性を大幅に引き上げますが、完全な隔離境界ではないため、以下の段階的な対策が依然として重要です。

隔離のはしご

隔離の強さが増す3段階です。サーバー上で他に何が動いているかに応じて、最も低い段を選んでください。

段1: 専用の非特権ユーザー。 エージェントに専用のアカウント、専用のホームディレクトリ、専用のプロジェクトディレクトリを与え、sudoは付与しません。

sudo adduser --disabled-password --gecos "" agent

アカウントの境界により、エージェントはあなたのファイル（SSH鍵やマシン上の他の全プロジェクト）にアクセスできなくなります。また、skipフラグはrootとしての実行を拒否するため、この境界によってフラグが実際に使用可能になります。これは各サービスを非特権ユーザーとして実行する原則をエージェントに適用したものです。段1が制限しないもの: ネットワーク、およびマシン上で誰でも読み取り可能なあらゆるもの。

段2: コンテナ。 Anthropicは、Claude Codeを非rootユーザーとして実行し、エージェントが到達可能なホストを制限するファイアウォールルールを備えたリファレンスdevcontainerを公開しています。自身でビルドするコンテナでも同様の役割を果たせます。ファイルシステムはマウントしたボリュームのみに縮小され、外向き通信はコンテナのルールが許可するものだけに制限されます。サーバーが他の重要なサービスをホストしている場合、これが適切な中間の段です。この段の限界は、コンテナがホストのカーネルを共有すること、そして不注意なマウント一つで境界が破られることです。コンテナに/var/run/docker.sockを渡すと、ホスト全体に到達可能になります。

段3: 専用VPS。 最も強力な段は、最も単純です。エージェントに、重要なものが何もないマシン全体を与えます。小規模なVPSは月額数ドルで利用できます。新しいVPSの最初の10分間のランブックに従ってセットアップし、クリーンな状態のスナップショットを取得して、エージェントに作業させます。そこには他に何も存在しません。個人のSSH鍵は置かず、対象リポジトリのみにスコープされたデプロイキーのみを配置します。クラウド認証情報も本番データも置きません。実行が失敗した場合や、単にクリーンな状態に戻したい場合は、スナップショットを復元するか、数分でボックスを破棄して再構築します。被害範囲はレンタル料金のみです。このセットアップでは、--dangerously-skip-permissionsは恐ろしくなくなります。なぜなら、現実的に起こりうる最悪の結果は、サーバーの再構築とトークン1つの失効だからです。

これらのはしごの段は積み重ねられます。サンドボックス化されたエージェントを、非特権ユーザーとして、使い捨てのVPS上で実行しても、追加コストはほとんどかからず、障害シナリオは退屈なものになります。退屈であることが目標です。

認証情報を保護する

他のすべてに優先するルール：エージェントのユーザーが、他に属するシークレットを読み取れないようにすること。

APIキーはエージェントにだけ渡し、他には一切渡さない。エージェントのユーザーが所有するファイルにモード600で保存し、シェル起動時に読み込む：

install -m 600 /dev/null /home/agent/claude.env
echo 'export ANTHROPIC_API_KEY=your-key-here' >> /home/agent/claude.env
echo 'source ~/claude.env' >> /home/agent/.bashrc

次に、逆方向を塞ぐ。DebianやUbuntuでは、ホームディレクトリがしばしばマシン上の全ユーザーに読み取り可能な状態で作成されるため、自身のディレクトリを厳しく制限する：chmod 750 /home/youruser。ls -ld /home/*で確認し、エージェントのアカウントが一覧表示できるものをすべて修正する。

すべてのトークンのスコープを絞る。1つのリポジトリに限定したきめ細かいGitHubトークンや、リポジトリごとのデプロイキーを使えば、認証情報が漏洩しても失うのは1つのプロジェクトであり、アカウント全体ではない。サンドボックスを使用する場合は、その認証情報設定を追加し、~/.sshと~/.awsを読み取りであっても拒否する。そして本番環境の認証情報はマシン上に一切置かないこと。エージェントは、そもそも存在しなかったシークレットを漏洩させることはできないからだ。

Gitは安全ネットです

エージェントが行ったすべての変更は、レビュー可能かつ元に戻せるべきです。エージェントがブランチで作業すれば、gitがその両方を無償で提供します。

git switch -c agent/refactor-auth

実行後は git diff main...agent/refactor-auth で内容をレビューし、良い部分をマージしてください。成果がなかった場合はブランチを削除します。フォージ側でメインブランチを保護し、エージェントのトークンがそこにプッシュできないように、またどこにもフォースプッシュできないように設定してください。コミット履歴は、あなたが寝ている間に何が起きたかの監査ログとしても機能します。これは、どれだけのターミナルスクロールバックよりも価値があります。

ネットワークも被害範囲の一部である

エージェントは curl を実行できます。この一文が外向き通信の問題のすべてです。エージェントが読み取れるものは、どこかに送信することも可能であり、プロンプトインジェクションを受けたエージェントは実際にそうするかもしれません。特権のない一般ユーザーであっても、サーバーが到達可能なものすべてに到達できるため、これではまったく制限になりません。サンドボックスはプロキシを通じてドメイン単位で制限します。コンテナは自身のファイアウォールルールで制限できます。専用VPSは、そもそも漏洩しうるもの自体を限定します。これが三つのうちで最も堅牢な回答です。

外向き通信の問題を ufw だけで解決しようとしないでください。ufw はデフォルトですべての発信トラフィックを許可しており、apt、npm、git、Claude API を許可しつつ発信ルールを記述するのは煩雑で、静かに失敗する作業です。代わりに、サンドボックス、コンテナ、マシンのいずれかのレベルで境界を選択してください。そこでは、ドメイン許可リストや最小構成のマシンが同じ役割をすっきりと果たします。

Claude Code を実行するのではなく、APIを利用して独自のエージェントを構築する場合も、同じ考え方がそのまま当てはまります。VPS上でのClaudeによるAIエージェントの構築ではその方法を解説しており、そのエージェントにも同様に、専用ユーザー、必要最小限のトークン、そして使い捨て可能なボックスが与えられるべきです。

まずはマシン自体を堅牢化する

どの段階を選ぶにせよ、エージェントを導入する前にマシン自体の基本対策は必須です。SSH鍵認証のみ許可、rootログイン禁止、デフォルト拒否のファイアウォール、自動セキュリティ更新の適用です。以下のチェックリストを生成し、順に実施してください。

FAQ

--dangerously-skip-permissions はサーバー上で安全に使用できますか？

単体では安全ではありません。このフラグはすべての承認プロンプトを削除するため、モデルが生成した最初の不正なコマンドが即座に実行されます。被害範囲が限定されている場合、これは防御可能なトレードオフとなります。最低限、専用の非特権ユーザーを使用し、完全な自動実行には、1つのプロジェクトとスコープ付きトークンのみを保持するコンテナまたは使い捨てVPSを使用してください。本番環境の認証情報や失いたくないデータを保持するマシンでは決して使用しないでください。

Claude Code にはサンドボックスがありますか？

はい。Claude Code にはシェルコマンド用の組み込みサンドボックスが同梱されており、/sandbox コマンドで起動します。Linuxではbubblewrap、macOSではSeatbeltを使用し、プロジェクトディレクトリへの書き込みを制限し、承認済みドメインのみを許可するプロキシ経由でネットワークアクセスをルーティングします。自動許可モードでは、プロンプトなしでサンドボックス化されたコマンドを実行するため、OS強制の境界を維持しつつ、スキップフラグと同様に中断を削減します。これは完全な隔離境界ではないため、自動実行には専用ユーザーまたは専用マシンと組み合わせてください。

スキップフラグがrootとしての実行を拒否するのはなぜですか？

許可プロンプトなしのrootはシステム上の任意のファイルとサービスを変更できるため、Claude Code はLinuxおよびmacOS上でrootまたはsudo下で実行される場合、--dangerously-skip-permissions をブロックします。修正策はこのチェックに逆らうことではありません。エージェント用に非特権ユーザーを作成し、そこで実行してください。このアカウント境界が、最初の最も低コストな封じ込め層です。

Claude Code は私のSSH鍵や.envファイルを読み取れますか？

実行ユーザーが読み取り可能なものはすべて読み取ることができ、サンドボックスのデフォルトポリシーでさえ、拒否設定を行うまで認証情報パスの読み取りを許可します。そのため、エージェントは専用ユーザーとして実行し、自身のホームディレクトリはモード750以上に保ち、サンドボックス設定で認証情報パスを拒否し、本番環境のシークレットはマシン上に一切置かないでください。ボックスが一度も保持しなかったシークレットは、読み取られることも漏洩することもありません。

Claude Code を自動実行する最も安全な方法は何ですか？

エージェント作業専用の安価なVPSを使用します。10分で堅牢化し、クリーンな状態でスナップショットを作成し、非特権ユーザーでClaude Codeを実行、サンドボックスを有効化、APIキーを保持するモード600のファイル、リポジトリごとのデプロイキーを使用し、すべての作業はマージ前にレビューするブランチ上で行います。実行に問題が発生した場合、1つのトークンを失効させてスナップショットを復元するだけで、所有する他のものには一切影響しません。