Claude Code on the web の設定項目を整理する：環境変数・API認証情報・ネットワーク・スクリプト

こんにちは、けーまです。

Claude CodeのWeb版で環境設定を開くと、ネットワークアクセスや環境変数、API認証情報、セットアップスクリプトといった項目が並んでいます。
「どの欄に何を設定すべきなのか」「設定を変更したとき、既存のセッションにはどう反映されるのか」と疑問に思ったことはないでしょうか。

私自身も設定ごとの違いを整理したくなり、専用のprivateリポジトリとクラウド環境を用意して挙動を確かめてみました。

0. 検証環境を用意する

今回の検証対象は、Anthropic側の基盤で実行されるClaude Codeのクラウドセッションです。

Claude CodeのWeb画面を開き、入力欄の上にある環境名をクリックします。
「クラウド」から「クラウド環境を追加」を選び、検証用の名前を付けました。

新規作成の画面。この時点ではAPI認証情報の欄はない

1. 環境変数をコマンドから読む

環境変数の欄には、セッション内で実行するコマンドへ渡したい設定値を入力します。
今回は次の値を環境の「環境変数」欄に貼り付けて保存しました。

LAB_REV=before
LAB_HASH="alpha#beta"
LAB_MULTILINE="line1
line2"

「環境変数」の欄に.env形式で貼り付ける

新規セッションを作成し、次のコマンドを実行するようClaudeに依頼します。
ほかの環境変数まで出力されないよう、読み取る変数名を絞り込んでいます。

python3 - <<'PYTHON'
import json, os
names = ["LAB_REV", "LAB_HASH", "LAB_MULTILINE", "LAB_EXPORTED"]
print(json.dumps({name: os.environ.get(name) for name in names}, ensure_ascii=False, indent=2))
PYTHON

実際の出力結果です。

{
  "LAB_REV": "before",
  "LAB_HASH": "alpha#beta",
  "LAB_MULTILINE": "line1\nline2",
  "LAB_EXPORTED": null
}

入力した3つの値がそのまま読める

前後の引用符自体は値に含まれず、# や改行文字はそのまま保持されていました。

2. セットアップスクリプトを動かす

「セットアップスクリプト」欄に、次のスクリプトを登録してみました。
Web画面で登録した環境変数（LAB_REV）をファイルに書き出しつつ、スクリプト内で新しく LAB_EXPORTED をエクスポートしてセッションへ渡せるかを試す内容です。

#!/bin/bash
set -eu
printf "setup_rev=%s\n" "$LAB_REV" > /tmp/claude-env-lab.txt
date -u +%FT%TZ >> /tmp/claude-env-lab.txt
export LAB_EXPORTED=from_setup

環境の編集画面の「セットアップスクリプト」欄に入力して保存する

ところが新規セッションを開始すると、準備の手順一覧に「セットアップスクリプトが失敗しました」と表示され、「詳細を表示」を開くと次のエラーが出て停止してしまいました。

Setup script failed with exit code 1.
LAB_REV: unbound variable

Claude Codeは起動されず、詳細に LAB_REV: unbound variable が出ている

セッション内のコマンドからは読めていた LAB_REV が、セットアップスクリプトの実行時点では未定義でした。
そのため set -u によって未定義変数の参照エラーとなり、スクリプトが停止してしまったわけです。

そこで、変数が未定義の場合でも処理を止めずにその事実を記録できるよう、スクリプトを書き換えて再検証しました。

#!/bin/bash
set -eu
printf "setup_revision=2\n" > /tmp/claude-env-lab.txt
printf "setup_LAB_REV=%s\n" "${LAB_REV-unset}" >> /tmp/claude-env-lab.txt
date -u +%FT%TZ >> /tmp/claude-env-lab.txt
export LAB_EXPORTED=from_setup

新規セッションを開始し、Claudeにファイルの内容と、スクリプト内で export した LAB_EXPORTED が見えるかを確認してもらいました。

cat /tmp/claude-env-lab.txt
python3 -c 'import json, os; print(json.dumps({n: os.environ.get(n) for n in ["LAB_REV", "LAB_EXPORTED"]}))'

実際の出力結果です。

setup_revision=2
setup_LAB_REV=unset
2026-09-26T08:20:04Z

{"LAB_REV": "before", "LAB_EXPORTED": null}

setup_revision=2 が残っているのに、LAB_EXPORTED は null

ファイル自体は正常に作成され、セットアップスクリプト実行中の LAB_REV は未定義であることが確認できました。
また、スクリプトが最後の export の行まで実行されたにもかかわらず、同じセッションから読んだ LAB_EXPORTED は null でした。
私の環境では、セットアップスクリプト内での export をセッションへ環境変数を引き渡す手段としては利用できませんでした。

セッション内で使いたい値は、素直に「環境変数」の入力欄へ設定するのが確実です。

3. ネットワークアクセスを比較する

ネットワークアクセスの各設定ごとに新規セッションを作成し、同じ3つの宛先に対して接続を試しました。
この章ではAPI認証情報は登録していません。

選択肢は「なし」「Trusted」「Full」「カスタム」の4つ

Claudeにはリポジトリのファイルを変更させず、次のコマンドのみを実行するよう依頼しています。
結果が読みやすいよう、レスポンスは1行目だけを表示し、curl 自体の終了コードを curl_exit として出しています。

for url in https://example.com https://registry.npmjs.org https://httpbin.org/get; do
  printf '\nURL=%s\n' "$url"
  curl -sS -I --connect-timeout 8 --max-time 15 "$url" | head -1
  printf 'curl_exit=%s\n' "${PIPESTATUS[0]}"
done

Custom設定では、許可ドメインを example.com のみとし、「一般的なパッケージマネージャーのデフォルトリストも含める」はオフにしました。

許可するドメインに example.com だけを入れ、デフォルトリストのチェックを外す

実測結果は次のとおりです。

表の「拒否（接続時）」と「403」は、どの段階で断られたかが違います。
セッション内の curl は外部へ直接つながらず、まずプロキシに CONNECT で「この宛先までの通路を作ってほしい」と頼み、できた通路（トンネル）の中で本来のリクエストを送ります。

上は通路を作る前にプロキシが断るので curl がエラー（56）、下は通路の先から HTTP 403 が返るので curl は成功扱い（0）

なお、npmレジストリの403をプロキシとnpm側のどちらが返したのかまでは、今回の検証では確認していません。

Trustedではnpmレジストリへの通信が通り、Customでドメインを明示的に絞り込むとnpmへの通信は拒否されました。
Fullに設定した場合は、今回試した3つの宛先すべてに到達できています。

同じ「拒否」でも、npmはHTTP 403で curl_exit=0、httpbin.orgは接続時点で失敗して curl_exit=56

許可されていない宛先は、プロキシとの接続の段階で CONNECT tunnel failed, response 403 となり、curl の終了コードは56でした。
一方でnpmレジストリへのリクエストは、接続自体は確立したうえでHTTP 403が返り、curl の終了コードは0でした。
そのため、接続の可否をシェルスクリプトで判定するなら、終了コードだけでなくHTTPステータスコードまで確認するのが確実です。

公式ドキュメントにおける設定区分は次のとおりです。

• なし（None）: 通常の外向き通信を拒否

• Trusted: デフォルトの許可先

• Custom: 指定した許可先

• Full: 任意のドメイン

GitHubやMCPコネクター、Claude自身のAnthropic APIへの接続などは別経路で処理されるため、Noneを「一切の通信が遮断される状態」と捉えないよう注意が必要です。

引用元：Configure cloud environments / Access levels

4. API認証情報を登録する

4.1. 環境変数との違い

API認証情報は、APIキーそのものをセッション内のコマンドへ渡すのではなく、指定したホストへのアウトバウンドリクエストに対して後から付与する設定です。
公式ドキュメントによると、セッションのVMからリクエストが送信された後、Anthropicのエージェントプロキシが認証ヘッダーなどを付与する仕組みと説明されています。

Anthropic's agent proxy adds the key to requests for the hosts you list, after each request leaves the session's VM.

引用元：Configure cloud environments / Add API credentials

環境変数と並べると、値が置かれる場所の違いは次のとおりです。
環境変数はVMの中にあるのでコマンドから読めますが、API認証情報のキーはVMの外のプロキシだけが持っています。

たとえば Authorization: Bearer ... が必要な外部APIであっても、Claudeに生キーを見せることなく認証済みのリクエストを送信させることができます。

4.2. 作成済み環境の編集画面から追加する

私の画面では、クラウド環境を新規作成する初期フォームにはAPI認証情報の入力欄がありませんでした。
環境を作成したあと、編集画面を開き直すことで環境変数の下に設定欄が表示されます。

編集画面では環境変数の下に「API認証情報」と「認証情報を追加」が並ぶ

「認証情報を追加」を開き、今回は次の値を設定しました。
なお、この文字列は実際のサービスでは使用できないダミー値です。

値の欄は入力中も伏せ字で表示される

認証方式の選択肢には、次の9種類が表示されていました。

• Basic

• Bearer

• Body parameter

• AWS SigV4

• GCP access token

• GCP IAP

• OAuth 2.0 JWT bearer

• OAuth 2.0 client credentials

• MCP Connector

今回実際に検証したのはBearerのみです。

Bearerを含めて9種類が選べる

追加フォームで「連携/連携させる」をクリックすると保存されました。
環境編集画面全体の「変更を保存」を押さなくても一覧に即時反映され、保存後にキーの値そのものを再表示・再編集する欄は用意されていませんでした。

一覧には名前と許可ウェブサイトだけが表示され、値は見えない

4.3. Noneでも登録先へ接続できた

ネットワーク設定をNone（外向き通信なし）にしたまま、既存のセッションで次のコマンドを実行してみました。
httpbin.org/headers は受け取ったヘッダーをレスポンス本文として返すため、本物のAPIキーでは絶対に試さず、必ずダミー値を使ってください。

python3 - <<'PYTHON'
import json
import os
import subprocess

# httpbin.org にリクエストを送り、自身に付与されたリクエストヘッダーを取得する
r = subprocess.run(
    ["curl", "-sS", "--connect-timeout", "8", "--max-time", "20",
     "https://httpbin.org/headers"],
    capture_output=True, text=True, check=True,
)
headers = json.loads(r.stdout).get("headers", {})
auth = headers.get("Authorization", "")

# 1. Authorizationヘッダーが付与されているか確認
print("Authorization exists:", "Authorization" in headers)
# 2. Bearerトークン形式になっているか確認
print("Starts with Bearer:", auth.startswith("Bearer "))
# 3. トークンの文字数を確認（生の値を出力せずに長さをチェック）
print("Length:", len(auth))
# 4. 登録したAPIキーがVM内の環境変数に漏れていないか確認
print(any("not-a-real-key-env-lab-20260922" in v for v in os.environ.values()))
PYTHON

実際の出力結果です。

Authorization exists: True
Starts with Bearer: True
Length: 38
False

ネットワーク設定はNoneのまま、httpbin.orgへのリクエストにBearerヘッダーが付いた

登録前は拒否されていたホストへリクエストが通り、Authorizationヘッダーも付与されていました。
一方で、ダミーキーを含む環境変数は存在しませんでした（出力末尾の False）。
ただし、この確認は環境変数だけを対象にしたもので、VM内のファイル全体をくまなく探したわけではない点はお含みおきください。

同じセッションで、3章と同じ3つの宛先への接続も確かめました。

通るようになったのは、認証情報の許可ウェブサイトに入れたhttpbin.orgだけ

公式ドキュメントでも、API認証情報に登録された送信先は通常のネットワークアクセス制限とは独立して到達可能になると説明されています。
許可ウェブサイトには、利用予定のAPIホストを必要最小限の範囲で指定するのが安全です。

引用元：Configure cloud environments / Add API credentials

4.4. セットアップスクリプト中には付与されない

「セットアップスクリプト内でプライベートなパッケージやリポジトリを取得したい場合、API認証情報が自動で付与されるのか」も気になるところです。

そこでネットワーク設定をFullにしたうえで、2章で動かしたセットアップスクリプトの末尾に、httpbin.org/headers を呼び出す処理を追加してみました。

#!/bin/bash
set -eu
printf "setup_revision=3\n" > /tmp/claude-env-lab.txt
printf "setup_LAB_REV=%s\n" "${LAB_REV-unset}" >> /tmp/claude-env-lab.txt
date -u +%FT%TZ >> /tmp/claude-env-lab.txt
export LAB_EXPORTED=from_setup

# --- ここから下を追加 ---
# セットアップスクリプト実行中に httpbin.org へリクエストを送り、ログファイルへ追記する
python3 - <<'PYTHON' >> /tmp/claude-env-lab.txt
import json
import subprocess

r = subprocess.run(
    ["curl", "-sS", "--connect-timeout", "8", "--max-time", "20",
     "https://httpbin.org/headers"],
    capture_output=True, text=True,
)
# curl の終了コードをログファイルに記録
print("setup_curl_exit=" + str(r.returncode))

if r.returncode == 0:
    # 通信成功時：ヘッダーを解析して Authorization ヘッダーが付与されているか判定
    data = json.loads(r.stdout)
    print("setup_authorization_present=" + str("Authorization" in data.get("headers", {})))
else:
    # タイムアウト等で失敗した場合
    print("setup_request_failed")
PYTHON

ネットワークはFull、API認証情報は登録したまま、セットアップスクリプト内にAPI呼び出しを記述

スクリプトが残したログファイルを確認した結果です。

setup_curl_exit=0
setup_authorization_present=False

この出力は次の2つを表しています。

• setup_curl_exit=0: ネットワークがFullのため、セットアップスクリプト内からの外部通信（curl）自体はエラーなく正常に完了したこと

• setup_authorization_present=False: 返ってきたリクエストヘッダーの中に、API認証情報で登録した Authorization ヘッダーが含まれていなかったこと

通信自体は成功（curl_exit=0）したが、Authorizationヘッダーは付いていない（False）

つまり、通信自体は成功したものの 認証ヘッダーは付与されていませんでした。

この理由は公式ドキュメントに明記されています。
認証ヘッダーを付与する「エージェントプロキシ」に接続されるのは、セットアップスクリプトがすべて完了して Claude Code が起動した後 だからです。

Setup script requests: Claude Code connects to the agent proxy when it launches, after the setup script has run

引用元：Configure cloud environments / Add API credentials

そのため、「API認証情報に登録しておけば、セットアップスクリプト中の通信にも自動でキーが付与される」ということはありません。セットアップスクリプト内で認証が必要な通信を行う場合は、別の手段を検討する必要があります。

5. 設定変更は、どのタイミングで反映されたか

環境編集画面には「環境への変更は新しいセッションに適用されます。」と表示されます。
公式ドキュメントでも、環境変数はセッション起動時に一度だけコピーされ、実行中のセッションは開始時の値を保持し続けると説明されています。

Each session copies the environment's values once, at startup, into ordinary environment variables that any command Claude runs can read. Because running sessions don't re-read the configuration, editing or adding variables affects sessions you start afterward; sessions already running keep the values they started with.

引用元：Configure cloud environments / Set environment variables

実際に、Trusted・LAB_REV=before で始めたセッションのあと、環境を LAB_REV=after・Noneに変更して保存し、既存のセッションへ追加で依頼してみました。

環境変数を LAB_REV=after に、ネットワークアクセスを「なし」に変えて保存する

結果は次のとおりでした。

設定変更後も、既存のセッションでは LAB_REV=before、npmも200のまま保持されていた

公式ドキュメントの説明どおり、設定を変更しても実行中の既存セッションには反映されず、開始時の値（LAB_REV=before、npm通信成功）がそのまま残っていました。
変更後の設定が反映されたのは、設定保存後に新しく作成したセッションからです。

そのため、環境設定を変更した場合は既存のセッションを使い続けるのではなく、新規セッションを作成して作業するのが確実です。

6. おわりに

今回の検証を通じて分かったポイントをまとめます。

実際に手を動かして検証してみたことで、コマンドから直接参照できる「環境変数」と、プロキシ経由でヘッダーを注入する「API認証情報」の役割の違いが明確になりました。
セッションの外部接続を制限する際は、ネットワークアクセス設定だけでなく、API認証情報の送信先ホストも含めて設計・確認していきたいと思います。

参考

• Configure cloud environments | Claude Code Docs

• Configure cloud environments（Markdown版）| Claude Code Docs