サーバーでClaude Codeを安全に実行する方法

サーバー上で Claude Code を安全に実行する方法

サーバー上で Claude Code を安全に実行するには、権限確認プロンプトを有効にしたまま、専用の非特権ユーザーとして実行してください。さらに、非対話実行には、信頼するだけでなく、実際の隔離境界を設けます。組み込みの sandbox、コンテナ、または重要なデータを置かない使い捨ての VPS などを使用します。--dangerously-skip-permissions フラグを指定すると、モデルとシェルの間にある承認手順がなくなります。このトレードオフは非対話処理では合理的な場合があります。ただし、1 つの不正なコマンドが到達できる範囲を制限する隔離境界の内側でのみ使用してください。このガイドでは、このフラグが実際に変更する内容と、隔離レベルを段階的に高めながらその境界を構築する方法を説明します。

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

Claude Code は、ターミナルで動作するコーディングエージェントです。ファイルを読み取り、ファイルを書き込み、起動したユーザーの権限でシェルコマンドを実行します。このツールの価値はそこにあります。リポジトリの clone、コードの編集、テストの実行、失敗内容の確認、コードの修正をループで実行できるため、各コマンドを手入力する必要がありません。まだサーバー上で設定していない場合は、tmux で VPS 上の Claude Code を実行するでインストールとセッション管理を説明しています。このページでは、設定後に Claude Code へ与える権限について説明します。

リスクについては、同じ説明をもう一度読む必要があります。ユーザーの権限でシェルコマンドを実行するプロセスは、そのユーザーが実行できることをすべて実行できます。ユーザーが開ける ~/.ssh/id_ed25519、~/.aws/credentials、およびすべての .env ファイルを読み取れます。curl を実行し、サーバーから到達可能な任意のホストへデータを送信できます。git push --force も実行できます。エージェント自身に目的があるわけではありません。危険なのは、タスクの実行を誤ること、または作業中に読み取ったテキストに第三者が書いた指示が含まれていることです。たとえば、取得した Web ページや、修正を依頼された issue のコメントなどです。後者はプロンプトインジェクションと呼ばれます。そのため、「モデルは通常は適切に判断する」ことをセキュリティ計画にしてはいけません。指示は、より身近な場所から届くこともあります。同じサーバー上の 2 つの Claude Code セッションが相互にテキストを送信できるためです。兄弟セッションからのメッセージも、受信側のエージェントが読み取る単なるテキストです。平均的な実行ではなく、異常な実行を前提に計画してください。

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

初期状態では、Claude Code は操作する前に確認を求めます。プロジェクト内のファイルの読み取りは何も表示せずに行われますが、ファイルの編集やシェルコマンドの実行では、先に編集内容やコマンドの正確な内容を表示し、承認を待ちます。1 回の操作だけを承認することも、同じ種類の操作をセッションの残りの期間について承認することもできます。これらの承認はセッション単位です。CLI を終了すると、次のセッションは再び慎重な状態で開始します。維持したいルールは、設定ファイルの allow、ask、deny リストに永続化できます。たとえば、git status は許可し、git push では確認を求め、.env の読み取りは拒否します。deny ルールが常に優先されます。この基本動作自体も変わる予定です。2026 年 8 月 14 日からは auto mode がデフォルトになるため、監視できないサーバーでどのモードを使用するか決める前に、各権限モードで実際に許可される操作を把握しておく価値があります。

この設計は、人間が端末を監視していることを前提にしています。ラップトップでは通常その前提が成り立ちます。しかしサーバーでは、誰も監視していないことが多くあります。tmux 内で長時間のタスクを開始して就寝すると、午前 2 時に質問への回答を求めて停止したエージェントは、朝まで処理を進められません。この停止は時間だけでなく費用も発生させます。アイドル状態の Claude Code セッションではウォームなプロンプトキャッシュが失われるため、次のターンで再構築の費用がかかるからです。これが、サーバーで skip フラグを使いたくなる正直な理由であり、それによって解決される問題も現実のものです。このガイドの以降の内容では、すべての安全策を手放さずにこの問題を解決する方法を説明します。

--dangerously-skip-permissions で変わること

claude --dangerously-skip-permissions は承認手順を無効にします。編集は確認なしで実行されます。シェルコマンドも確認なしで実行されます。通常は機密性の高い場所を保護するパスのチェックもスキップされます。明示的な deny ルールは引き続き適用されます。また、いくつかの極端な操作では確認が求められます。それでも要点は単純です。モデルが実行すると判断した処理は、そのまま実行されます。

サーバーでは、このフラグに関して2つの点が重要です。1つ目は、Linux と macOS で Claude Code を root または sudo として実行すると、このフラグがブロックされることです。確認なしで root を使うと、マシン上の任意のファイルやサービスを変更できるためです。エージェントには、いずれにしても専用の非特権アカウントが必要であり、このフラグはその条件を強制します。2つ目は、このフラグがモデルの動作を一切変更しないことです。人間を処理のループから外すだけで、それ以外は何も変わりません。そのため、確認によって防げたはずの誤りも、すべて実行されます。

したがって、判断は明確です。権限確認をスキップすると、セキュリティ上の問いは「エージェントが悪い処理を実行するか」から「1つの誤った処理でどれだけの被害が出るか」に変わります。個々の判断をすべて制御するのではなく、被害の範囲を制御することになります。その答えが封じ込めであり、複数の段階に分けて実施します。

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

段階的な設定に入る前に、Claude Code には実行するコマンド向けの OS レベルのサンドボックスが組み込まれていることを確認してください。これにより、skip フラグを使う主な理由の多くがなくなります。Linux では、ファイルシステムの分離に bubblewrap を使用し、socat によってネットワークトラフィックをプロキシ経由で転送します。サンドボックス内のコマンドが書き込めるのは、プロジェクトディレクトリとセッション用の一時ディレクトリだけです。ネットワークには、すべてのドメインを許可リストと照合するプロキシ経由でのみアクセスできます。コマンドが新しいドメインへ初めて接続しようとすると、Claude Code が確認を求めます。

セッション内で /sandbox コマンドを実行して有効にします。Ubuntu と Debian では、先に必要な2つのパッケージをインストールします。

sudo apt install bubblewrap socat

Ubuntu 24.04 以降では、既定の AppArmor ポリシーによって、bubblewrap が必要とするユーザー名前空間を作成できません。サンドボックスパネルには不足している設定が表示されます。また、Claude Code のサンドボックスドキュメントには、この問題を修正する短い AppArmor プロファイルが記載されています。

サンドボックスには自動許可モードがあります。サンドボックス化されたコマンドは、強制された境界が従来プロンプトの担っていた役割を果たすため、確認なしで実行されます。サンドボックス内で実行できないコマンドは通常の権限確認フローに戻るため、本当に特殊な操作では引き続き確認が求められます。ほとんどのサーバーワークフローでは、これは skip フラグの適切な代替です。確認を完全になくすのではなく、OS による強制境界によって確認の回数を大幅に減らせるためです。

制限も正しく理解してください。既定では、サンドボックス化されたコマンドは、アクセスを拒否するパスを指定しない限り、認証情報ファイルを含むファイルシステムの大部分を読み取れます。これには sandbox.credentials 設定を使用します。ネットワークプロキシはドメイン名を確認しますが、トラフィック自体は検査しません。そのため、github.com のように広範囲を許可すると、データを外部へ持ち出す余地が残ります。Docker はサンドボックス内では動作しません。サンドボックスによって最低限の安全性は大きく向上します。しかし、完全な分離境界ではありません。そのため、以下の段階的な設定も引き続き重要です。

隔離レベル

隔離レベルは3段階あり、下に行くほど分離が強くなります。サーバー上で共存しているものに合う、最も低い段階を選んでください。

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

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

アカウントの境界により、エージェントが SSH キーや、サーバー上の他のプロジェクトを含む自分のファイルへアクセスするのを防げます。また、skip フラグは root として実行すると拒否されるため、この構成にすると初めて使用できます。これは、すべてのサービスを非特権ユーザーとして実行する原則をエージェントに適用したものです。レベル1で制限できないのは、ネットワークと、サーバー上で全ユーザーから読み取り可能なものです。

レベル2: コンテナ。 Anthropic は、非 root ユーザーとして Claude Code を実行し、エージェントが接続できるホストをファイアウォールルールで制限する、リファレンス用の devcontainer を公開しています。自分で構築するコンテナでも同じ構成にできます。ファイルシステムはマウントしたボリュームだけに限定され、外向き通信もコンテナのルールで許可した範囲に限定されます。サーバー上で重要な他のサービスを運用している場合に適した中間の段階です。ただし、コンテナはホストのカーネルを共有します。また、不用意なマウントを1つ設定すると境界が失われます。コンテナに /var/run/docker.sock を渡すと、ホスト全体へアクセスできます。

レベル3: 専用 VPS。 最も強力な段階は、最も単純な方法でもあります。重要なものが何も入っていないマシン全体をエージェント専用にします。小規模な VPS なら、月数ドルで利用できます。新しい VPS の最初の10分で行う手順に従って構築し、クリーンな状態のスナップショットを作成してから、エージェントを実行します。そこには他のものを置きません。個人用の SSH キーは配置せず、1つのリポジトリだけに権限を限定した deploy key を使用します。クラウド認証情報も本番データも置きません。実行に問題が発生した場合や、単にクリーンな状態へ戻したい場合は、数分でスナップショットを復元するか、サーバーを破棄して再構築できます。被害範囲は VPS の利用料金に限定されます。最悪でもサーバーを再構築し、1つのトークンを失効させるだけなので、この構成では --dangerously-skip-permissions も恐ろしくありません。

これらの段階は組み合わせて使えます。非特権ユーザーとして実行するサンドボックス化されたエージェントを、使い捨て可能な VPS 上で動かしても、追加費用はほとんどかかりません。問題が起きても、対応を単調な作業にできます。それが目的です。

認証情報を保護する

他のすべての対策の基盤となるルールは、エージェントのユーザーが他の用途の Secret を読み取れないようにすることです。

API key はエージェントだけに渡し、それ以外には渡しません。エージェントのユーザーが所有する mode 600 のファイルに保存し、shell の起動時に読み込みます。

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 では、home directory が同じシステム上のすべてのユーザーから読み取り可能な状態で作成されることがよくあります。そのため、自分の home directory の権限を chmod 750 /home/youruser で厳しくします。ls -ld /home/* で確認し、エージェントのアカウントが一覧表示できるものがあれば修正します。

すべての token の範囲を限定します。1 つの repository のみに制限した fine-grained GitHub token や、repository ごとの deploy key を使えば、認証情報が漏洩しても影響はアカウント全体ではなく 1 つの project に限定されます。sandbox を使う場合は、credential settings に ~/.ssh と ~/.aws を追加し、読み取りも拒否します。また、production の認証情報は完全に別の場所で管理します。最初からその認証情報が存在しなければ、エージェントが漏洩させることもないためです。これらの Secret を self-hosted password manager に保存する場合は、エージェントとは別のサーバーで運用し、独自にレビューします。暗号化された vault 自体ではなく、Vaultwarden の弱点は admin token と backup file です。

Git は安全網です

エージェントが行うすべての変更はレビュー可能で、元に戻せる必要があります。エージェントがブランチ上で作業すれば、Git によってその両方を無料で実現できます。

git switch -c agent/refactor-auth

作業後に git diff main...agent/refactor-auth で変更をレビューし、適切な変更をマージします。成果がなければブランチを削除します。3 つのファイルだけを変更した作業のほうが、モジュールの半分を書き換えた作業よりも、朝に確認しやすくなります。これは、動作する最小限の変更にエージェントを従わせるスキルを使う実際的な理由です。forge 側で main ブランチを保護し、エージェントの token がそこへ push できないようにします。また、どこへも force-push できないようにします。コミット履歴は、ユーザーが眠っている間に何が起きたかを記録する監査ログとしても機能します。これは、端末のスクロールバックをどれだけ残すよりも価値があります。

ネットワークも影響範囲に含まれます

エージェントは curl を実行できます。この一文が送信トラフィックの問題全体を示しています。エージェントが読み取れるものは、どこかへ送信することもできます。プロンプトインジェクションを受けたエージェントなら、実際に送信する可能性があります。通常の権限を持たないユーザーだけでは、この範囲を制限できません。どのユーザーも、サーバーから到達できるすべての宛先へ接続できるためです。サンドボックスでは、プロキシを通じてドメイン単位で制限できます。コンテナでは、コンテナ独自のファイアウォールルールで制限できます。専用 VPS では、そもそも漏えい対象となるデータを減らせます。3 つの方法の中では、これが最も堅牢な対策です。

送信トラフィックの制御を ufw だけで解決しようとしないでください。ufw はデフォルトで送信トラフィックをすべて許可します。apt、npm、git、Claude API への接続を許可しながら送信ルールを作成するのは煩雑で、気付かないうちに壊れます。代わりに、サンドボックス、コンテナ、またはマシンのレベルで境界を設定してください。ドメインの許可リストを使うか、専用マシンをそのまま使えば、同じ目的を明確に実現できます。

Claude Code を実行するのではなく、API を使って独自のエージェントを構築する場合も、考え方は変わりません。VPS 上で Claude を使って AI エージェントを構築する では、その方法を説明しています。そのエージェントにも、同じ専用ユーザー、同じ範囲に限定したトークン、同じ使い捨ての環境を用意してください。

最初にサーバーを堅牢化する

どの段階を選んでも、エージェントを導入する前にマシン自体の基本的な対策が必要です。SSH 鍵認証のみを許可し、root ログインを無効にし、デフォルト拒否のファイアウォールを設定し、セキュリティ更新を自動適用します。ここでチェックリストを作成し、1 回ずつ確認していきます。

FAQ

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

それだけでは安全とはいえません。このフラグを指定すると、すべての承認プロンプトがなくなるため、モデルが最初の危険なコマンドを生成した時点で実行されます。影響範囲を限定できる場合は、許容できるトレードオフになります。最低限、専用の非特権ユーザーを使用してください。完全に無人で実行する場合は、1 つのプロジェクトとスコープを限定した 1 つのトークンだけを保持するコンテナまたは使い捨ての VPS を使用します。本番の認証情報や、失うことのできないデータを保持するマシンでは決して使用しないでください。

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

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

skip フラグはなぜ root での実行を拒否するのですか？

root で承認プロンプトがない場合、システム上のあらゆるファイルやサービスを変更できるためです。Claude Code は、Linux と macOS で root または sudo の下で実行される場合、--dangerously-skip-permissions をブロックします。対処方法は、このチェックを回避することではありません。エージェント用の非特権ユーザーを作成し、そのユーザーで実行してください。ユーザーアカウントの境界が、最初に設ける最も安価な封じ込め層になります。

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

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

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

エージェント作業専用の安価な VPS を使用する方法です。10 分でハードニングを行い、クリーンな状態でスナップショットを取得します。Claude Code は、サンドボックスを有効にした状態で非特権ユーザーとして実行し、API キーはモード 600 のファイルに保存します。リポジトリごとにデプロイキーを用意し、作業はすべて、マージ前に確認するブランチ上で行います。実行に問題が起きても、1 つのトークンを失効させてスナップショットを復元するだけで済みます。所有する他の環境には影響しません。