クラウド環境のネットワークアクセス設定 — 許可ドメインとプロキシ
Claude Codeのクラウド環境は4段階のネットワークアクセスレベルを持ちます。Customでの許可ドメイン追加と、通信が通らないときの症状別の切り分けをまとめました。
セッションのネットワークは環境ごとに決まる
Claude Codeのクラウドセッションは、Anthropicが管理する仮想マシン(VM)上で動きます。VMがどこへ外向きに通信できるかは、環境ごとの「Network access」設定で決まります。レベルは4段階で、既定はnpmやGitHubなど主要な配布元だけを許可する「Trusted」です。同じVMに最初から入っているツールやCPU・メモリ・ディスクの上限は、Claude Codeクラウドセッションで使えるツールとリソース制限に書いています。
この設定は、Web版・claude --cloud・Claude Tag・ルーチン・モバイルアプリ・デスクトップアプリのどの入口から起動しても同じ環境設定として効きます。入口ごとに別々の設定は持たないので、CLIで通らなかった通信をWeb版で設定し直す必要はありません。環境セレクターで環境を開き、「Network access」欄から選びます。
4段階のアクセスレベル
| レベル | 外部接続の範囲 | 向くケース |
|---|---|---|
| None | 外部接続の範囲セッションのネットワーク経由の接続なし | 向くケース機密性の高いコードを外部に出したくない検証 |
| Trusted(既定) | 外部接続の範囲npm・PyPI・GitHubなど許可済みドメインのみ | 向くケース一般的な開発。依存関係の大半がそのまま入る |
| Full | 外部接続の範囲任意のドメイン | 向くケース許可リストで賄いきれない外部サービスを使うとき |
| Custom | 外部接続の範囲自分で指定したドメインのみ(既定リストとの併用可) | 向くケース社内APIだけを足し、それ以外は塞ぎたいとき |
Trustedの許可リストは十数カテゴリに分かれています。Anthropicサービス(api.anthropic.comなど)、バージョン管理(GitHub・GitLab・Bitbucket)、コンテナレジストリ(Docker Hub・GHCR・GCRなど)、クラウド(Google Cloud・AWS・Azure)、言語ごとのパッケージマネージャー(npm・PyPI・RubyGems・crates.io・Go・JVM)、Linuxディストリビューション、開発ツール、CDNなどです。AWSやAzureを使っているだけの理由でCustomに切り替える必要はありません。社内のレジストリやSaaSがこの一覧に無いと分かった時点が、Customを検討するタイミングです。
Noneでも外に出られる4つの経路
Noneは「クラウド環境を完全に遮断する設定」ではなく、Claudeが実行するコマンドの外向き通信を絞る設定です。次の4つは、どのレベルでもセッションのネットワークの許可リストを通りません。
許可リストを通らない経路
GitHubプロキシ
git操作とGitHub API呼び出しは専用プロキシ経由です。レベルの影響を受けません。
MCPコネクタ
有効にしたコネクタの通信はAnthropicのサーバーを通るので、Allowed domainsへの追加が不要です。
APIクレデンシャルの登録先
環境に登録したクレデンシャルの対象ホストへの通信は、エージェントプロキシが認証情報を付けて転送します。クレデンシャルの登録はProとMaxプランの機能で、TeamとEnterpriseにはまだありません。
Claude Code自身のAPI通信
Noneの環境でもAnthropic APIへの通信は確保されます。データがVMの外へ出る余地が残る、という点は公式もセキュリティ上の注意として書いています。
Customで許可ドメインを足す
Customの設定手順
- 1
Customに切り替える
環境の編集ダイアログを開き、Network accessをCustomにします。共有環境は読み取り専用で開くため、変更はOwnerが管理者設定の「Cloud environments」ページから行います。
- 2
Allowed domainsに1行1ドメインで書く
先頭に
*.を付けると全サブドメインを指します。 - 3
既定リストを併用するか決める
「Also include default list of common package managers」にチェックを入れるとTrustedのドメインも残ります。外したままなら、書いたものだけが通ります。
api.example.com
*.internal.example.com
registry.example.comこの例なら、api.example.com・internal.example.com の任意のサブドメイン・registry.example.com だけがセッションのネットワークから届きます。
チェックの有無で何が変わるか
併用チェックあり
npmやPyPIも社内APIも通ります。セットアップスクリプトで依存関係を入れつつ、社内サービスにも接続したい場合の組み合わせです。
併用チェックなし
書いたドメイン以外は塞がります。npmもPyPIも届かなくなるので、依存関係は社内ミラーのホストを列挙して賄う構成になります。
許可ドメインは環境ごとの個別設定です。全メンバーの環境へ一括で反映される組織レベルの許可リストは無く、サーバー管理設定から環境の許可リストにドメインを足すこともできません。チームで同じリストを使いたいときは、Ownerが「Custom」に統一リストを入れた組織共有の環境を作る運用になります。
通信が通らないときの切り分け
症状から原因をたどる順に並べます。
npm installやpip installが失敗する
まずレベルを見ます。Noneならインストールは必ず失敗します。Customなら、併用チェックが外れていないかを確認します。外したまま社内ドメインだけを書くと、上のCompareのとおりnpmやPyPIへの経路が消えます。
セットアップスクリプトのダウンロードが403で落ちる
GitHubのリリースアセットやAPIへのリクエストは、そのセッションに紐づけたリポジトリだけに絞られます。紐づけていない別リポジトリからアセットを取ろうとすると403になります。ドメインの許可漏れではなくリポジトリの範囲の問題なので、Customにドメインを足しても直りません。
gh api graphqlが「This GraphQL query is not enabled for this session」で403になる
GitHubプロキシがGraphQLで通すのは、プルリクエスト関連の決まった操作だけです。それ以外は、GH_TOKEN を自分で設定していても同じ403で拒否されます。Projects v2のようにGraphQLにしかないAPIは、プロキシ経由では使えません。エラー文は代替として gh api repos/{owner}/{repo}/... 形式のREST呼び出しを示します。
git pushが拒否される
GitHubプロキシがpushを通すのは、セッションの作業ブランチだけです。
Bunだけがパッケージを取れない
セキュリティプロキシとの互換性問題で、公式に挙がっている既知の例です。VMにはBunが入っていますが、パッケージ取得に限って問題があります。npmやpnpmで代替できるか確認します。
登録したAPIキーが付かない
APIクレデンシャルはProとMaxプランの機能で、TeamとEnterpriseの環境では登録できません。登録できる環境でも、エージェントプロキシがクレデンシャルを付けないリクエストがあります。GitHub、api.anthropic.com と registry.npmjs.org・pypi.org などの公開パッケージレジストリ、セットアップスクリプト内のリクエスト、Claude Codeのテレメトリ送信です。セットアップスクリプトの時点ではエージェントプロキシがまだつながっていないため、スクリプト内でAPIを叩くキーは環境変数に置く必要があります。
raw.githubusercontent.comから取れない
公開リポジトリのコミット済みファイルは、GitHubプロキシではなくセキュリティプロキシ経由で届きます。このドメインはTrustedに入っているので、Trustedなら通り、Noneでは塞がります。
Artifactsを読み込めない
*.frame.claudeusercontent.com を許可リストに入れなくても、組織でArtifactsを使っていれば、Claude CodeはAnthropicへの接続経由でArtifactsの内容を読みます。ホストを許可リストに残すのは、別組織の公開Artifactsをセッション内で開く場合か、ローカルCLI・セルフホストランナーを構成する場合です。
CLIから環境を指定するときの入口
ターミナルからクラウドセッションを作るフラグは、claude --help に次のように出ます(v2.1.285で確認)。
--cloud [description|session_id|url] Create a cloud session with the given
description, or attach to an existing
one by session ID or claude.ai/code URL
--environment <environment_id> Create a new cloud session that runs on
the given self-hosted environment
(ccpool_...).--environment の説明にあるとおり、指定できるのはセルフホスト環境(ccpool_ で始まるID)です。Anthropic管理環境の切り替えは、セッション内の /remote-env で選びます。claude --cloud はどちらの場合も、ここまで見てきた環境のネットワーク設定を引き継ぎます。
設定を変えたあとのキャッシュ
セットアップスクリプトの結果は環境キャッシュに保存され、スクリプトを変えたときと、許可するネットワークのホストを変えたときに再構築されます。有効期限は約7日で、既存セッションを再開してもスクリプトは再実行されません。許可ドメインを足した直後の最初のセッションは、キャッシュの再構築ぶん起動が遅くなる可能性があります。
セキュリティプロキシとセルフホスト環境の違い
Anthropic管理の環境では、外向き通信のすべてがHTTP/HTTPSのセキュリティプロキシを通り、悪意あるリクエストの遮断・レート制限・コンテンツフィルタリング・DNSレベルの監査ログが働きます。セルフホスト環境ではこのプロキシを使わず、自社のネットワーク境界から外向き通信が出ます。GitHubの認証は、デプロイ側が用意するクレデンシャルを使う構成と、同じGitHubプロキシへのopt-inを選べる構成があります。
よくある質問
組織でIPアドレス制限を有効にしていると、クラウドセッションは動きますか
動きません。クラウドセッションはAnthropicが管理するインフラからAnthropic APIを呼ぶため、IP許可リストを有効にした組織ではセッションが認証エラーで失敗します。Code Reviewや、Anthropic管理環境で動くルーチンも同じです。ネットワークアクセスの設定では直らず、Anthropicサポートに連絡して、Anthropic管理サービスをIP制限の対象から除外してもらう手順になります。セルフホスト環境へ振ったルーチンは、自社ネットワークからAPIを呼びます。
Trustedの一覧にワイルドカードは含まれますか
含まれます。*.gcr.io のようにサブドメインを一括で含むエントリと、AWSの *.amazonaws.com のような広い指定が混在します。特定のドメインだけを塞ぎたい場合、Trustedから個別に外す設定は見当たらないため、Customで必要なドメインだけを列挙する形になります。
まとめ
通信が通らないときは、レベルの選び方(None・Customの併用チェック)、GitHubプロキシの範囲(リポジトリ・GraphQL・ブランチ)、クレデンシャルの適用外、セキュリティプロキシとの相性のどこに当たるかを、症状から見分けます。当たりをつけずにFullへ切り替えると、通ったように見えても原因が残ります。設定を変えたあとは、依存関係のインストールが走るかをセットアップスクリプトの書き方と合わせて確認してください。共通の設定を組織で配る運用は、組織共有の環境が受け皿になります。