クラウド環境のネットワークアクセス設定 — 許可ドメインとプロキシ
Claude Codeのクラウド環境は4段階のネットワークアクセスレベルを持ちます。Custom設定での許可ドメイン追加、GitHub/セキュリティプロキシの扱いをまとめました。
クラウド環境のネットワークアクセスとは
Claude Codeのクラウドセッションは、Anthropicが管理する仮想マシン上で動きます。そのVMがインターネットのどこにアクセスできるかを決めるのが、環境ごとの「ネットワークアクセス」設定です。設定できるレベルは4段階、既定はnpmやGitHubなど主要な配布元だけを許可する「Trusted」です。同じVM上で最初から使えるツールや、CPU・メモリ・ディスクの上限についてはClaude Codeクラウドセッションで使えるツールとリソース制限にまとめています。
ネットワークアクセスはWeb版・claude --cloud・Claude Tag・ルーチン・モバイルアプリ・デスクトップアプリなど、クラウドセッションを起動するすべての入口で共通の環境設定として適用されます。claude.ai/codeの環境セレクターで環境を開き、「Network access」欄から選びます。
4段階のアクセスレベル
| レベル | 外部接続の範囲 | 向くケース |
|---|---|---|
| None | 外部接続の範囲セッションのネットワーク経由の接続なし | 向くケース機密性の高いコードを外部に一切出したくない検証 |
| Trusted(既定) | 外部接続の範囲npm・PyPI・GitHubなど許可済みドメインのみ | 向くケース一般的な開発。追加設定なしで大半の依存関係が入る |
| Full | 外部接続の範囲任意のドメイン | 向くケース社内API・特殊なレジストリなど許可リストで賄いきれない場合 |
| 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、MCPまで、公式には十数カテゴリにわたって許可ドメインが定義されています。一般的なNode.js / Pythonプロジェクトなら、Trustedのままでセットアップスクリプトの依存関係インストールが問題なく完了することがほとんどです。
許可リストはこうしたカテゴリ単位で管理されています。バージョン管理系はgithub.com・gitlab.com・bitbucket.orgとそのAPIエンドポイントです。コンテナレジストリ系はDocker Hub(registry-1.docker.io等)・ghcr.io・gcr.io・public.ecr.awsなどが対象です。クラウドプラットフォーム系はGoogle Cloud(cloud.google.com・gcloud.google.comなど)に加えて、AWS(*.amazonaws.com)、Azure(azure.com・dev.azure.com・*.microsoftonline.com)も既定で許可されています。AWSやAzureを使っているだけの理由でCustomに切り替える必要はありません。ワイルドカード表記の *.gcr.io のように、サブドメインを一括で含むエントリも混在しています。社内で使っているレジストリやSaaSがこの一覧に無ければ、その時点でTrustedからCustomへの切り替えを検討します。
Customで許可ドメインを追加する手順
社内APIなど許可リスト外のドメインにアクセスさせたいときは、Customを選んで自分でドメインを列挙します。
- 環境セレクターで対象の環境を開き、Network accessをCustomに切り替える
- Allowed domainsの欄に、1行1ドメインで許可したいホストを列挙する
- Trustedの既定リストも併用したい場合は「Also include default list of common package managers」にチェックを入れる
api.example.com
*.internal.example.com
registry.example.com先頭に *. を付けると、そのドメインの全サブドメインを一括で許可できます。上の例なら internal.example.com の任意のサブドメインにアクセスできるようになります。
Artifactsを使うセッションでは、*.frame.claudeusercontent.com を許可リストに含める必要があります。Claude CodeはArtifactsのコンテンツをこのホストから取得するため、抜けているとセッション内でArtifactsが読み込めません。組織のドメイン許可リストは環境ごとの個別設定で、全メンバーの環境に一括で反映される組織レベルの許可リストは存在しません。
アクセスレベルの外側にある3つの抜け道
ネットワークアクセスをNoneにしても、セッションのネットワーク経由の許可リストを通らない3つの経路は生きたままです。これを知らずに「Noneなら完全に外部遮断できる」と考えると、想定と違う動作に戸惑います。
- GitHubプロキシ: git操作とGitHub API呼び出しは専用プロキシを通り、アクセスレベルの影響を受けません
- MCPコネクタ: セッションやルーチンで有効化したMCPコネクタの通信はAnthropicのサーバー経由になり、Allowed domainsへの追加は不要です
- APIクレデンシャルの登録先ホスト: 環境に登録したAPIクレデンシャルが対象とするホストへのリクエストは、エージェントプロキシがクレデンシャルを付与して転送します
さらに、Claude Code自身がAnthropicのAPIと通信するリクエストは、Noneの環境でも許可されます。セッションを完全にネットワークから隔離する機能ではなく、あくまでClaudeが実行するコマンドの外向き通信を制御する仕組みだという理解が実務では役立ちます。
GitHubプロキシの仕組み
Anthropicが管理する環境では、GitHubに関わる操作がすべて専用プロキシを経由し、実際のGitHubトークンはセッションのVM内に置かれません。git clientはスコープ済みの一時クレデンシャルを使い、プロキシ側で本物のトークンに差し替えられます。
このプロキシには制約もあります。git push はセッションの作業ブランチに対してしか通りません。GitHub APIとリリースアセットへのリクエストは、そのセッションに紐づいたリポジトリだけに絞られるため、無関係なリポジトリからアセットを取得しようとするセットアップスクリプトは403で失敗します。GraphQLエンドポイントもプルリクエスト関連の操作だけに絞られており、Projects v2のようなGraphQL専用APIには、GH_TOKEN を自分で設定しても届きません。
セキュリティプロキシの役割
Anthropicが管理する環境のセッションは、すべての外向き通信がHTTP/HTTPSのセキュリティプロキシを通ります。悪意あるリクエストの遮断、レート制限、コンテンツフィルタリング、DNSレベルの監査ログ記録を担っています。セルフホスト環境ではこのプロキシを使わず、代わりに自社のネットワーク境界から外向き通信が出ていきます。
このプロキシが原因で、一部のパッケージマネージャーが正しく動かないことがあります。Bunはその代表例として公式に挙げられています。npmやpipで問題が起きるときとは切り分けて調べる必要があります。
よくあるつまずき
- Custom設定後もセットアップスクリプトのインストールが失敗する: 「Also include default list of common package managers」のチェックを外したまま社内ドメインだけを列挙すると、npmやPyPIへの到達経路が失われます。両方が必要ならチェックを入れます
- Artifactsが読み込めない:
*.frame.claudeusercontent.comの許可漏れが原因のことが大半です。Customに切り替えた際に見落としやすい項目です - Noneにしたのに一部の通信が通る: 前述の3つの抜け道(GitHubプロキシ・MCPコネクタ・APIクレデンシャル)とAnthropic APIへの通信は、Noneでも遮断されません。仕様どおりの挙動です
- Bunでパッケージ取得に失敗する: セキュリティプロキシとの相性問題が公式に挙げられている代表例です。npmやpipで代替できないか検討します
- セルフホスト環境でCustomの挙動が想定と違う: セルフホスト環境はAnthropicが管理するセキュリティプロキシを使わず、自社のネットワーク境界を経由します。GitHub認証もその環境が用意するクレデンシャルを使う構成になり、Anthropic管理環境とは経路が異なります
よくある質問
NoneにするとClaude Code自体が動かなくなりますか
動きます。Claudeが実行するコマンドの外向き通信は遮断されますが、Claude Code自身がAnthropicのAPIと通信する経路は、Noneの環境でも確保されています。
Trustedの許可リストにあるドメインを個別に外せますか
外せません。Trustedは固定の許可リストで、個別にドメインを除外する設定はありません。特定のドメインだけを制限したい場合は、Customに切り替えて必要なドメインだけを列挙します。
Web版とCLIの --cloud で設定は別々になりますか
なりません。ネットワークアクセスは環境単位の設定で、Web版・モバイルアプリ・デスクトップアプリ・CLIの --cloud ・Claude Tag・ルーチンなど、どの入口からクラウドセッションを起動しても同じ環境設定が適用されます。
組織の管理者は全メンバーの許可ドメインを一括設定できますか
できません。許可ドメインのリストは環境ごとの個別設定です。組織で共有したい場合は、管理者が組織共有の環境を作成し、必要なドメインを設定した上でメンバーに使わせる運用になります。
まとめ
Claude Codeのクラウド環境は、None・Trusted・Full・Customの4段階でネットワークアクセスを制御します。既定のTrustedは主要なパッケージレジストリとGitHubをカバーしており、社内APIなど許可リスト外のドメインが必要になった時点でCustomへの切り替えを検討します。GitHubプロキシ・MCPコネクタ・APIクレデンシャルの3経路はアクセスレベルの影響を受けないため、Noneを「完全遮断」と誤解しないことが設定を読み解くうえでの要点です。セットアップスクリプトを書く際の注意点は、ネットワークアクセスの設定と合わせて確認しておくと、依存関係のインストール失敗を防げます。