クラウド（Web）で使う

クラウドセッションは、手元のマシンではなくクラウド上で Claude Code を動かす仕組みです。既定では Anthropic が管理するインフラで動き、組織がセルフホスト環境へ回している場合はそちらで動きます。PC を閉じても続き、どの端末からも確認・操作できます。

• 対象プランは Pro・Max・Team と、プレミアムシートまたは「Chat + Claude Code」シートを持つ Enterprise ユーザーです
• 始める入口は、ブラウザ（claude.ai/code）、モバイルアプリの「Code」タブ、デスクトップアプリの「Cloud」、ターミナルの claude --cloud、ルーティン
• リポジトリは新しい VM にクローンされ、Claude が変更してブランチを push します。レビューと PR 作成は同じ会話の中で続けられます
• 向いているのは、並行タスク、手元にないリポジトリ、細かく指示しなくてよい定型の作業、コードの調査です
• 手元の設定やツールが要る作業は、ローカル実行かリモートコントロールが向きます
• クラウドセッションが GitHub からクローンして push するには、GitHub を連携します（次の節）。リポジトリが GitLab・Bitbucket などにあるなら、できることを「制限事項」の節で確かめます

動き方#

次の手順は Anthropic ホスト環境のものです。セルフホスト環境では、クローン以降が組織のランナーで動き、ネットワーク境界・セットアップ・push の挙動は運用側が決めます。

1. クローンと準備：リポジトリが Anthropic 管理の VM にクローンされ、設定していればセットアップスクリプトが走る
2. ネットワーク設定：環境のアクセスレベルに従って、インターネットへの接続が決まる
3. 作業：Claude がコードを解析し、変更し、テストを実行して確かめる。途中で見守って指示を出すことも、離れることもできる
4. ブランチの push：区切りまで進むと、ブランチを GitHub に push する。差分を見てインラインコメントを付ける、PR を作る、続きを依頼する、が選べる

ブランチを push してもセッションは閉じません。PR の作成も追加の編集も同じ会話で行います。

実行場所の比較#

Claude Code の動きはどこでも同じで、違うのは、セッションがどこで動くかと、手元の設定が使えるかです。

GitHub を連携する#

初回に1度だけ行います。連携方法は2つあります。

Claude GitHub App をリポジトリに入れると、そのリポジトリの PR で Auto-fix も使えるようになります。プロジェクトのスレッドは、どちらの方法でも、クローンする各リポジトリに Claude GitHub App が必要です。

Anthropic ホスト環境では、GitHub の認証情報は暗号化されて Anthropic のサーバーに置かれ、VM には入りません。VM からの GitHub 操作は GitHub プロキシを通り、サーバー側で認証情報が付きます。

ブラウザで連携する#

1. claude.ai/code に claude.ai アカウントでサインインする
2. GitHub 連携の案内に従い、GitHub の認可ページで承認する
3. 非公開リポジトリを使うアカウント・組織に Claude GitHub App を入れる（組織は所有者の承認が要る場合がある。後で入れるなら「Skip」）
4. Default 環境を用意する

連携すると、Claude は自分が所有する GitHub アカウントのうち Claude GitHub App が入っているものも、Claude の組織に関連づけます。Team・Enterprise では、管理者が連携済みの GitHub アカウントの一覧でそれらを見られます（組織への導入と管理設定）。

Team・Enterprise では、組織の Owner が「Organization settings > Connectors」で GitHub コネクタをオンにするまで、サインインの手順が進みません（「GitHub access is required for Claude Code cloud sessions」と表示される）。「Organization settings > Claude Code」の Quick setup は任意のトグルで、オンにすると /web-setup が使え、オンボーディングが環境を作ります。

Default 環境の作られ方はプランで変わります。

Default は Trusted のネットワークアクセスで、主要なパッケージレジストリなど許可リストのドメインだけに届きます。最初のプロジェクトにはそのまま使えます。

Team・Enterprise の Quick setup#

Quick setup は、メンバーの GitHub と環境の設定の手順を減らす組織設定です。Team・Enterprise では既定でオフです。オンにすると、メンバーには次のことが変わります。

• /web-setup：GitHub を /web-setup でつなげる。オフの間はこのコマンドが隠れる
• GitHub App の案内：ブラウザのオンボーディングが、Claude GitHub App のインストールの案内を飛ばす
• 最初の環境：オンボーディングが、環境のフォームを出さず Default 環境を作る

オンにするのは Owner で、「Organization settings > Claude Code」の「Quick setup」のトグルです。

ターミナルから連携する（/web-setup）#

gh を使っている人向けです。Claude Code CLI が必要で、Team・Enterprise では Owner が Quick setup をオンにした後だけ使えます。

/web-setup は、gh auth token が出すトークンを読み、確認を取ってから Anthropic に送ります。トークンは claude.ai アカウントに暗号化して保存され、削除するまでクラウドセッションの GitHub アクセスに使われます。自分で始めたクラウドセッションは、そのトークンが届くリポジトリすべてにアクセスでき、Claude GitHub App は不要です。すでにブラウザで連携済みなら、続行すると連携が置き換わる旨の警告が出ます。

1. gh auth login で GitHub CLI を認証する
2. CLI で /login を実行し、claude.ai アカウントでサインインする（API キー認証では不可。/status の「Login method」で確認）
3. CLI で /web-setup を実行し、gh のトークンを送る確認に同意する。成功すると Connected as <your-github-username> と出て、claude.ai/code が開く

環境がまだなければ、Trusted のネットワークアクセスでセットアップスクリプトなしの環境が作られます。完了後は、--cloud で端末からクラウドセッションを始めたり、/schedule でルーティンを設定したりできます。

トークンを削除するには、claude.ai/customize/connectors で GitHub の連携を解除します。ブラウザ由来か /web-setup 由来かにかかわらずクラウドセッション用の認証情報が消え、再連携まで GitHub アクセスを失います。手元の gh はサインインしたままで、トークン自体も GitHub 上では有効です。無効にするには GitHub で取り消します（ブラウザで gh にサインインした場合は「Settings > Applications > Authorized OAuth Apps」の「GitHub CLI」。取り消すと手元の GitHub CLI もサインアウトされます）。

タスクを始める#

1. claude.ai/code かモバイルアプリの「Code」タブで、入力欄の下のリポジトリセレクタからリポジトリを選ぶ。ブランチセレクタで、既定以外のブランチから始められる。複数のリポジトリを追加すると1セッションで横断して作業できる
2. 入力横のモードのドロップダウンで権限モードを選ぶ
3. 内容を具体的に書いて Enter を押す

クラウドセッションには Manual と Bypass permissions がありません（権限モード）。

URL でセッションを事前入力する#

claude.ai/code の URL にクエリパラメータを付けると、プロンプト・リポジトリ・環境を埋めた状態で新規セッションを開けます。課題管理ツールのボタンから課題の説明をプロンプトとして開く、といった連携に使えます。各値は URL エンコードします。

https://claude.ai/code?prompt=Fix%20the%20login%20bug&repositories=acme/webapp

レビューして続ける#

1. 差分を開く：セッション全体の追加・削除行数（例：+42 -18）を選ぶと、左にファイル一覧、右に変更が出る。既定ではセッションのベースブランチと比較し、「Compare against」で別のブランチとも比較できる
2. インラインコメント：差分の行を選んで入力し Enter。次のメッセージを送るまでキューに入り、まとめて送られる。Claude には「src/auth.ts:47 で、ここでエラーを握りつぶさないで」のように場所つきで届く
3. PR 作成：差分の上部の「Create PR」。通常の PR、ドラフト、タイトルと説明を生成した GitHub の作成ページへの移動から選べる
4. PR 後も続ける：セッションは生きているので、CI の失敗出力やレビューコメントを貼って対応を頼める。自動で監視させるならAuto-fix

差分は、リポジトリに設定された diff ドライバーや textconv フィルターを使わず、生の git blob の内容から計算されます。

ターミナルとクラウドの間で作業を移す#

CLI で同じ claude.ai アカウントにサインインしている必要があります。CLI からのセッションの移動は一方向で、クラウドのセッションを --teleport でターミナルへ引き込めますが、既存のターミナルセッションをクラウドへ送ることはできません。デスクトップアプリは、Code タブのローカルセッションを「Open in」メニューからクラウドへ送れます（デスクトップアプリ）。

ターミナルからクラウドへ（--cloud）#

claude --cloud "Fix the authentication bug in src/auth/login.ts"

claude.ai に新しいクラウドセッションを作ります。クラウド VM は、手元のチェックアウトではなく、現在のディレクトリの GitHub リモートの現在のブランチをクローンするので、ローカルのコミットがあれば先に push します。タスクはクラウドで動き、手元では別の作業を続けられます。--cloud は一度に1つのリポジトリです。古い綴りの --remote は非推奨の別名として残っています。

• コンテナの起動中は、クローンやセットアップスクリプトのチェックリストが CLI に出ます。この間に入力したメッセージはキューに入り、準備が済んでから送られます
• Claude が質問してセッションが止まっていても、環境の有効期限までなら、戻ってから答えて続けられます
• --remote-control は無関係です。ローカルの CLI セッションを claude.ai やアプリから見守り・操作するためのものです（リモートコントロール）

完了したら、claude.ai/code から PR を作るか、セッションをターミナルへ teleport して続けます。

GitHub なしでローカルリポジトリを送る#

git のリモートがないリポジトリや、Claude GitHub App が入っていない github.com のリポジトリで claude --cloud を実行すると、Claude Code がローカルリポジトリを束ねて直接アップロードします。/web-setup で連携済みでも同じです。フルクローンのとき、束ねる内容は、全ブランチの履歴全体と、追跡中のファイルへのコミット前の変更です。

コミット前の変更のうち、機密になりうるファイルの扱いは、プラットフォームで違います。

• macOS・Linux・WSL：.env・Terraform の *.tfvars・id_rsa や *.pem などの鍵ファイルのような、認証情報や鍵の名前に見えるファイルの変更は、アップロードから外します。Git LFS のような git フィルターが管理するファイルのコミット前の変更も外します。外したファイルは Left on this machine: の通知に出て、セッションは、コミット済みのバージョン（なければファイルなし）で始まります
• Windows（ネイティブ）：追跡中のファイルのコミット前の変更は、ファイル名に関係なくそのままアップロードされます。クラウドセッションに入れたくない編集は、始める前に stash するか戻します

macOS・Linux・WSL では、アップロードに git 2.31 以降と、対応するチェックアウトの形も要ります（Windows ネイティブはどちらの検査もなしでアップロードします）。満たさないチェックアウトでは、Claude Code はセッションを始めず、Not uploading this working tree: を含むエラーで、原因と直し方を示します。よくある原因は次のとおりです。

• git が古い：インストールされた git が 2.31 より古い。git を更新して再試行する
• 対応しないチェックアウトの形：サブモジュールの中、git clone に --separate-git-dir・--shared・--reference を付けて作ったクローン、core.worktree を設定したチェックアウト、refs を reftable 形式で持つリポジトリで始めた。素の git clone で作ったクローンのメインのチェックアウトから始める
• スパースチェックアウトのリンクされた worktree：git sparse-checkout は設定を worktree 自身の config.worktree に書き、アップロードはそれを受け付けないので、その設定のある worktree も、worktree.sparsePaths で Claude Code が作った worktree も、アップロードされない。リポジトリのメインのチェックアウトから始める
• 作業ツリーの中にある git の設定：git の設定が、チェックアウトの内側にあるファイル（リポジトリの中を指す include.path など）を含む。そのファイルを作業ツリーの外へ移すか、include を外して再試行する

macOS・Linux・WSL では、git clone --filter で作った部分クローンは、追跡中のすべてのファイルが手元にあれば、履歴なしの作業ツリーのスナップショットとしてアップロードされます。

claude --cloud で、リポジトリが GitHub にあるなら、アップロードとその要件を避けられます。ブランチを push し、リポジトリに Claude GitHub App を入れて、セッションを始め直すと、GitHub からクローンされます。

リモートからのクローンで足りる場合でも束ねて送るには、CCR_FORCE_BUNDLE=1 を付けます。

CCR_FORCE_BUNDLE=1 claude --cloud "Run the test suite and fix any failures"

束ねるリポジトリの制約です。

• 1つ以上のコミットがある git リポジトリであること
• 100 MB 未満であること。超える場合は現在のブランチだけの束に、それでも大きければ作業ツリーの単一のスナップショットにフォールバックし、それでも大きいと失敗する
• 追跡されていないファイルは含まれない。見せたいファイルは git add する
• macOS・Linux・WSL では、ファイルに適用される属性ルールに影響する git 設定（core.attributesFile を include した設定ファイルに置いた場合など）を追えないとき、アップロードを拒否する。拒否のメッセージが設定名と対処を示す
• 束ねて作ったセッションが GitHub のリモートへ push できるのは、GitHub 連携にそのリポジトリへの push 権限があるときだけ

CLI からフォローアップを送る#

実行中のクラウドセッションには、claude auth login でログインした任意のマシンの claude CLI から追加メッセージを送れます。ローカルのセッション状態は送らないので、始めたマシンでなくてもよく、どのシェルでも同じです。1件を投稿して終了します。

claude -p "your message" --cloud <session-id>

メッセージはキューに入り、返信を待たずに終了します。長く動いているセッションの舵取り、現在の処理が終わる前に次の指示を積む、CI スクリプトからの送信に使えます。標準入力からも渡せます（echo "your message" | claude -p --cloud <session-id>）。<session-id> は session_... や cse_... の ID か、claude.ai/code/<id> の URL（スキームやクエリの有無は問わない）で、ID は claude.ai/code のセッション一覧で分かります。

成功すると、セッション ID と閲覧リンクが出ます。--output-format json なら、成功時は {ok, session_id, url}、送信失敗時（セッションがない、アーカイブ済みなど）は {ok: false, session_id, error} です。プロバイダー未対応や組織ポリシー無効のような設定エラーは JSON にならず標準エラーに出ます。--output-format stream-json は --cloud <session-id> で使えません。エラーには Error: が付き、配信失敗は failed to send message to cloud session <id>: <reason> の形です。

クラウドからターミナルへ（teleport）#

次のいずれかで、クラウドセッションをターミナルへ引き込めます。

teleport すると、Claude が正しいリポジトリにいることを確認し、クラウドセッションのブランチを fetch してチェックアウトし、会話履歴全体をターミナルに読み込みます。ターミナルにはセッションの複製ができ、そこでの新しい作業はローカルに留まり、claude.ai やモバイルアプリのクラウドセッションには出ません。teleport 後も手元から操作したいときは、ローカルセッションで /remote-control を始めます。--teleport と --resume は別物で、--resume はこのマシンのローカル履歴の会話を開き、クラウドセッションは一覧に出ません。

teleport の前提条件です。

teleport がセッションのブランチを fetch するとき、fetch は端末で入力を待ちません。git や ssh がパスワード・鍵のパスフレーズ・新しい SSH ホストの確認を求める場面では fetch が失敗し、そのあとのチェックアウトは、手元のクローンにすでにそのブランチがあるときだけ成功します。SSH の2つの場合は、鍵を ssh-agent に読み込み、先に git fetch を1回手で実行してホストを記録します。

--teleport が使えない場合は、claude.ai サブスクリプション認証が必要なので、API キー認証なら /login で claude.ai アカウントにサインインします。エラーがプロバイダー名を挙げているなら、サードパーティプロバイダーではクラウドセッションは使えません。claude.ai でサインイン済みでも使えないなら、組織がクラウドセッションを無効にしている可能性があります。

セッションの操作#

セッションは claude.ai/code のサイドバーに並びます。

• キューのメッセージの取り消し：Claude の作業中に送ったメッセージは、読まれるまでキューに入ります。メッセージの ✕ を押すと、テキストが入力欄に戻ります。Claude がすでに読んだメッセージは会話に残ります
• 権限モードは、作成時にも実行中にも、モードのドロップダウンから選べます。Anthropic ホスト環境が期限切れになった後にセッションを開き直したとき、またはセルフホストのランナーがアイドル中に解放したセッションへ送信したときは、元の権限モードで再開します
• 差分レビューは前節の「レビューして続ける」と同じです。

コンテキストの管理#

ターミナル専用の UI でしか動かない /plugin・/resume などは使えません。ピッカーやパネルを開くコマンドは、クラウドでは動きが違います。

コンテキストが上限に近づくと自動で圧縮されます。クラウドセッションは CLAUDE_AUTOCOMPACT_PCT_OVERRIDE を自分で設定するので、窓がいっぱいになる前に自動圧縮が始まります。環境変数に同じ変数を足しても、セッション側の値が優先されて効きません。自動圧縮の窓を変えるには、環境変数に CLAUDE_CODE_AUTO_COMPACT_WINDOW を設定するか、その変数が未設定のセッションで /autocompact にトークン数を渡します。

サブエージェントはローカルと同じに動き、リポジトリの .claude/agents/ のものは自動で読み込まれます。エージェントチームは既定でオフで、環境変数に CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 を足すと有効になります。

セッションの共有#

セッションの公開範囲を切り替えてからリンクを共有します。受け取った人はリンクを開いた時点の最新状態を見ますが、リアルタイムには更新されません。

受け取る人にリポジトリアクセスを求める、または名前を隠すには、「Settings > Claude Code > Sharing settings」で設定します。

アーカイブと削除#

• アーカイブ：サイドバーでセッションにマウスを重ねてアーカイブアイコンを選ぶ。既定の一覧からは隠れ、アーカイブの絞り込みで見られる
• 削除：セッションとデータを完全に削除し、元に戻せない。サイドバーでアーカイブを絞り込んで削除アイコンを選ぶか、セッションを開いてタイトル横のドロップダウンから「Delete」を選ぶ。確認が出る

Auto-fix（PR の自動対応）#

Claude は PR を見張り、CI の失敗やレビューコメントに自動で対応します。PR の GitHub アクティビティを購読し、チェックの失敗やコメントがあると、調べて、明確な修正があれば push します。Claude GitHub App をリポジトリに入れておく必要があります。

Auto-fix は PR ごとのトグルです。止めるには、claude.ai/code のセッションの CI ステータスバーで「Auto-fix」を外すか、Claude に監視をやめるよう伝えます。

Claude のイベントへの対応です。

• 明確な修正：自信があり、以前の指示と矛盾しなければ、変更して push し、セッションで説明する
• 曖昧な依頼：レビューコメントが複数に解釈できる、または設計上重要なときは、行動する前に尋ねる
• 重複や対応不要のイベント：セッションに記録して先へ進む

ベースブランチが進んでマージ競合が起きても GitHub は webhook を出さないので、Auto-fix は自分では反応できません。競合の解消はセッションで Claude にリベースを頼みます。Claude がレビューコメントのスレッドに返信することがあり、その返信は自分の GitHub アカウントで投稿されます（Claude Code からの返信と分かるラベルが付く）。

クラウド環境（Cloud environment）#

すべてのクラウドセッションは、ネットワークアクセス・環境変数・セットアップスクリプトを保存した「環境」で動きます。同じ環境が、ブラウザ・ターミナル・Claude Tag・ルーティン・モバイルとデスクトップのアプリのどこから始めても使われます。リモートコントロールのセッションは自分のマシンのネットワークとファイルを使うので、クラウド環境を使いません。Claude Tag のチャンネルのセッションは、組織単位の環境（共有環境かセルフホスト環境）だけを使います（Slack と Claude Tag）。

Default 環境#

環境がまだないとき、オンボーディングが「Default」を用意します。CLI の /web-setup と、Pro・Max の Web オンボーディングは自動で作り、Team・Enterprise の Web オンボーディングはフォームを出します（Owner が Quick setup をオンにしていれば自動）。Default は独自の設定を持たず、Trusted のネットワークアクセスだけで、環境変数もセットアップスクリプトもなく、プリインストールのツールだけで始まります。

環境が1つなら、すべてのセッションがそれで動きます。複数あるときは入口ごとに選ばれ方が違います。

• デスクトップ・モバイル・claude.ai/code：自分で始めるセッションは、セレクタに表示されている環境を使う。選んでいなければ、Owner が設定した組織の既定が入る。プロジェクトのスレッドは、プロジェクトの設定の環境を使う
• CLI：/remote-env で選んだものを使う。なければ、一覧に Anthropic ホスト環境があればそれ、なければ一覧の最初の環境（リモートコントロールが自分のマシンを表すために登録するブリッジ環境を除く）。セルフホスト環境へは、セッションを dispatch するときに --environment <environment-id>（ccpool_ の ID）を渡すと、その呼び出しに限って /remote-env とフォールバックより優先される。Anthropic ホストの env_ ID はこのフラグでは拒否されるので /remote-env を使う。このフラグは Claude Code v2.1.224 以降

環境の作成・編集・アーカイブ#

環境セレクタは、Web オンボーディング後の claude.ai/code と、デスクトップアプリのプロンプト欄から開きます。自分で作った環境は自分のアカウント専用で、Owner が作った共有環境も同じセレクタに出ます。

1. claude.ai/code で、メッセージ欄の上の行にある、現在の環境名が出たクラウドアイコンを選ぶ（設定ページや直接の URL はない）
2. 「Cloud」を選んで環境の一覧を出す。続けて「Add cloud environment」を選ぶか、既存の環境にマウスを重ねて右に出る設定アイコンを選ぶ。ダイアログには名前・ネットワークアクセスのレベル・環境変数・セットアップスクリプトがある。Pro・Max で既存のクラウド環境を編集するときは、API 認証情報の欄も出る

• アーカイブ：自分の環境は編集画面で「Archive」。共有環境は Owner が管理設定の「Cloud environments」ページで行う。環境は削除できず、アーカイブだけ
• アーカイブは新しいセッションにだけ効く。実行中のセッションは動き続け、環境はセレクタと /remote-env から消える。環境の API 認証情報は実行中のセッションに付いたままなので、不要なら先に削除する。アーカイブした環境では、どの入口からも新しいセッションを始められない。保存していた CLI の既定の環境だった場合は、一覧に Anthropic ホスト環境があればそれ、なければ最初のブリッジ以外の環境で CLI のクラウドセッションが始まる。環境を明示しているルーティンなどは、別の環境に向け直す

環境変数#

.env 形式で、1行に1組の KEY=value。通常の値は引用符が不要で、対の引用符で囲めば引用符は値に入りません。複数行にまたがる値や # を含む値は引用符で囲みます（引用符なしの値では # から行末がコメントになる）。

NODE_ENV=development
LOG_LEVEL=debug
DATABASE_URL=postgres://localhost:5432/myapp

値は通常の環境変数として、Claude が実行する任意のコマンドから読めます。ただし OTEL_* は Claude Code 自身のテレメトリ用で、実行するコマンドには渡しません。

• Anthropic ホスト環境のセッションは、作成時と、その後 VM で Claude Code が再び起動するたび（アイドル後に VM が復元されたとき、解放された VM が再構築されたとき）に値を読み直す
• 変数を編集・追加・削除しても、既存のセッションは、VM が次に復元か再構築されるまで以前の値を使う。すぐ使うには、Claude に実行するコマンドで直接設定させる（例：LOG_LEVEL=trace npm test）か、新しいセッションを始める
• セッションが自分で設定する変数（CLAUDE_AUTOCOMPACT_PCT_OVERRIDE など）は、ここに足しても効かない
• 環境を使う人は誰でも値を読める。秘密は入れない

API 認証情報（API credentials。Pro・Max のみ）#

環境に保存した API キーやトークンを、Claude が見ずに API を呼べるようにする機能です。Anthropic のエージェントプロキシが、リクエストが VM を出た後に、指定したホスト宛ての要求へキーを付けます。キーは Claude にも、実行するコマンドにも、セッションの環境変数にも届きません。Team・Enterprise では使えず、環境ダイアログに「API credentials」の欄が出ません。

追加できる条件は次のとおりです。

• 役割：claude.ai 組織の管理者の役割（Team・Enterprise では Owner が持ち、Admin は持たない。Pro・Max では自分の組織で持っている）。Owner に共有環境へ追加してもらい、そこでセッションを動かす
• 環境の種類：すでにある Anthropic ホストのクラウド環境（セルフホスト環境には API 認証情報がない）
• API の到達性：リクエストは Anthropic のネットワークから出るので、API がインターネットからの接続を受けること
• 暗号鍵：組織が顧客管理の暗号鍵を使っていると、認証情報を保存できない

追加は1件ずつ行い、追加した認証情報は編集できません（ホストや値を変えるには削除して追加し直す）。

1. claude.ai/code で環境を編集し、「Edit environment」の「API credentials」の欄を開く
2. 「Add credential」を選ぶ。「Credential type」は、リクエストヘッダーで渡す API キーなら既定の「Bearer」のままにして、次を入れる
   • 「Name」：認証情報の名前（例：Internal billing API）
   • 「Allowed websites」：API のホスト（例：api.example.com。先頭の *. で全サブドメイン）
   • 「Custom headers」：キーを運ぶヘッダーの1行。「Name」は Authorization、「Prefix」は Bearer が初期値で、「Value」にキーを貼る。X-Api-Key のようにそのままの値を取るヘッダーなら、名前を変えて Prefix を空にする
3. 「Connect」を選ぶ。「Save changes」ボタンを使わずに一覧へ保存される。保存後は値を再表示できない

別の方式で認証する API には、別の「Credential type」を選びます（Claude Tag の接続と同じ一覧）。動作の確認は、環境でセッションを始め、Claude に curl などで API を呼ばせます。一覧に「Not sent」と出たものは、その下の注記が理由と対処を示します。ホストが重なって完全一致しない2つの認証情報は印が付かず、エージェントプロキシは片方だけを送ります。

プロキシは、リクエストのホストが認証情報に載せたホストに一致するとき付与し、環境のネットワークアクセスのレベルが許さないホストでも、そのホストには届きます（次の除外を除く）。認証情報は、環境で動くすべてのセッションに、誰が始めたかを問わず、削除するまで効きます。付与されないリクエストは次のとおりです。

• GitHub：GitHub プロキシが別に認証するので API 認証情報は不要
• Anthropic の API と公開パッケージレジストリ：api.anthropic.com、registry.npmjs.org、jsr.io、npm.jsr.io、pypi.org、files.pythonhosted.org、index.crates.io、proxy.golang.org
• セットアップスクリプトのリクエスト：Claude Code がエージェントプロキシに接続するのは、セットアップスクリプトが終わった後の起動時
• Claude Code のテレメトリ送信：コマンド経由ではなく Claude Code 自身が送るので、プロキシを通らない

CLI から環境を選ぶ（/remote-env）#

ターミナルの /remote-env で、claude --cloud などCLIから作るクラウドセッションの既定の環境を選びます。既存の環境のピッカーが開き、選択はユーザー設定の remote.defaultEnvironmentId に保存され、同じキーがより優先順位の高い設定の層（リポジトリのプロジェクト設定など）にない限り、このマシンの全プロジェクトに効きます。セルフホスト環境の ID（ccpool_...）には、より厳しい出どころの規則があります（設定キー一覧）。/remote-env は既定を決めるだけで、セッションを始めることも、環境の追加・編集もできません。

組織共有の環境#

Team・Enterprise では、Owner が組織全員に共有するクラウド環境を作れます。管理設定の「Cloud environments」ページで、セルフホスト環境も含めて管理します（Admin はページを開けません）。共有環境は各メンバーのセレクタで、自分の環境（「Personal」）の後ろの「Organization」見出しの下に出ます。設定アイコンを選ぶと、Owner を含む全員に読み取り専用の概要が開きます。

作る方法は2つあります。

• 共有環境を作る：管理設定の「Cloud environments」ページ。名前・ネットワークアクセスのレベル・.env 形式の環境変数・セットアップスクリプトを持つ。ここで編集・アーカイブもする
• 個人の環境を共有する：環境セレクタで自分の環境を編集し、「Who can use it」の行から共有する。環境の ID は変わらないので、すでに使っているセッションやルーティンに影響しない

組織の既定の環境は、Owner が claude.ai/admin-settings/claude-code で別に決めます。共有環境の変数は全メンバーのセッションが読むので、秘密を入れません（API 認証情報は Team・Enterprise ではまだ使えない）。

Claude Tag のチャンネルでは Claude は組織共通の ID として動くので、組織単位の環境（共有環境かセルフホスト環境）だけを使います。.NET のようなプリインストールされていないツールチェーンが要るときは、Owner がセットアップスクリプト付きの共有環境を作ります。環境の指定は、組織の既定の環境にするか、Claude Tag の管理設定でチャンネルに固定します。

ネットワークアクセス#

環境ごとに1つのレベルを設定し、そのセッションが張れる外向きの接続を制御します。環境を編集して、ダイアログの「Network access」で変えます。共有環境は読み取り専用で開くので、Owner が管理設定の「Cloud environments」ページで変えます。Anthropic ホスト環境で変更すると、既存のセッションも約1分以内に新しい設定に従います（セッションのネットワーク許可リストを通る要求について）。新しいセッションにする必要はありません。

どのレベルでも、次の経路はセッションのネットワーク許可リストを通らずに届きます。

• GitHub（別のプロキシ経由）
• 有効にした MCP コネクタ（トラフィックが Anthropic のサーバーを通る。使わないコネクタはオフにして、Claude が届くツールを絞る）
• 環境の API 認証情報に載せたホスト（認証情報が付かないホストを除く）
• Claude Code 自身のリクエストのための Anthropic API（None でも届く）

Trusted にないドメインを許可するには、「Custom」を選び、「Allowed domains」に1行に1ドメインで書きます。先頭の *. で全サブドメインに一致します。

api.example.com
*.internal.example.com
registry.example.com

「Also include default list of common package managers」にチェックを入れると、Trusted のドメインも許可し、外すと書いたものだけを許可します。環境ごとに許可リストを持ち、全メンバーの環境へ配る組織単位の許可リストはなく、サーバー管理設定でもドメインは足せません。チーム共通のリストは、Custom の組織共有環境で作ります。

組織でアーティファクトを使っていても、セッションが読むのに *.frame.claudeusercontent.com は不要です（リストにないときは Anthropic への接続経由で読む）。このホストを許可リストに残すのは、そのセッションが別の組織の公開アーティファクトを開くとき、またはローカル CLI やセルフホストのランナーを設定するときです。

GitHub プロキシ#

Anthropic ホスト環境では、アクセスレベルに関係なく、すべての GitHub 操作が専用のプロキシを通り、本物の GitHub の認証情報が VM の外に置かれます。

• Git の認証情報：VM 内の git クライアントは範囲を絞った認証情報を使い、プロキシが検証して本物のトークンに差し替える
• API リクエスト：組み込みの GitHub ツールと、proxy-injected のプレースホルダーを使う gh からの要求は、本物の認証情報に置き換わって出る
• push の制限：プロキシは、ブランチの削除と、タグのようなブランチ以外の push を拒否する。push が更新できるブランチは制限しない。制限するには GitHub のブランチ保護ルールかルールセットを使う
• リポジトリの範囲：GitHub API とリリースアセットの要求は、セッションに紐づいたリポジトリだけに届く。紐づいていないリポジトリのリリースアセットをセットアップスクリプトで取ると 403 になる
• GraphQL の制限：PR のワークフロー用の固定された操作だけを通し、それ以外は This GraphQL query is not enabled for this session の 403 で拒否される。自分で設定した GH_TOKEN でも同じ。Projects v2 のように GraphQL にしかない API には届かない

公開リポジトリのコミット済みファイルは raw.githubusercontent.com から届き、こちらはセキュリティプロキシが扱います（Trusted のリストに入っています）。

セキュリティプロキシ#

Anthropic ホスト環境のセッションは、セキュリティと不正利用の防止のため、HTTP/HTTPS のネットワークプロキシの背後で動きます。外向きのインターネット通信がすべてここを通り、悪意のあるリクエストへの保護、レート制限と不正利用の防止、コンテンツフィルタリング、要求したホスト名の DNS レベルの監査記録を提供します。

クラウドセッションの中身#

Anthropic ホスト環境では、手元の OS や CPU にかかわらず、セッションごとに新しい VM（Ubuntu 24.04、x86_64）で、リポジトリがクローンされ、主要なツールチェーンが入った状態で始まります。ネイティブ拡張付きの Ruby gem や事前ビルドの Python wheel など、バイナリを持つ依存関係は x86_64 Linux 向けのものを使います。セルフホスト環境はランナーイメージのツールを使います。

手元の設定から引き継がれるもの#

セッションはリポジトリの新しいクローンから始まります。リポジトリにコミットしたものは使え、自分のマシンにだけ入れたものは使えません。組織のポリシーはサーバー管理設定で別に届きます。

プリインストールされているツール#

（注）bun は入っていますが、パッケージ取得でプロキシとの互換性に既知の問題があります。

• 主なツールのバージョンは、Claude に check-tools を実行させて調べます（VM 内のシェルコマンドで、/ のコマンドではない）。出ないツール（Ruby・PHP・bun・PostgreSQL・Redis）は、psql --version のようにそのツールのバージョンコマンドを実行させます
• Node.js は /opt/node20・/opt/node21・/opt/node22 にあり、22 が既定で PATH にあります。別のバージョンを使うには、その bin（例：/opt/node20/bin）を PATH の先頭に足すよう Claude に頼みます
• .NET SDK のようにこの一覧にないツールチェーンは、パッケージレジストリが許可リストにあっても入っていないので、セットアップスクリプトで入れます

GitHub の課題と PR#

組み込みの GitHub ツールで、課題の読み取り、PR の一覧、差分の取得、コメントの投稿が設定なしでできます。認証は、GitHub 認証方法の設定に従って GitHub プロキシ経由で行われ、トークンはコンテナに入りません。

• GH_TOKEN か GITHUB_TOKEN を環境設定で自分で設定すると、そのままコンテナに渡り、スクリプトや gh が直接使う
• どちらも設定せず、GitHub プロキシが認証しているときは、Claude が実行するコマンドの中で両方の変数が proxy-injected というプレースホルダーになり、プロキシが外向きの GitHub 要求で本物の認証情報に置き換える。gh はそのまま動くが、GITHUB_TOKEN を直接読むスクリプトは使えるトークンを得られない
• どちらのケースかは、Claude に echo $GH_TOKEN を実行させて確かめる
• gh は導入済み。gh release や gh workflow run など組み込みツールにないコマンドは、Claude に実行させる。gh auth login は不要

セッションへのリンクを成果物に残す#

各クラウドセッションには claude.ai 上の文字起こし URL があり、セッション ID は環境変数 CLAUDE_CODE_REMOTE_SESSION_ID で読めます。PR 本文・コミットメッセージ・Slack の投稿・生成したレポートに、たどれるリンクを入れるのに使えます。クラウドセッションで Claude が作るコミットには Claude-Session: <url> の git トレーラーが付き、PR 本文にはセッション URL が1行入ります。外すには attribution.sessionUrl を false にします。コミットや PR 以外にリンクを入れるときは、Claude に次を実行させて出力を使います（変数の値の cse_ を、文字起こし URL が期待する session_ に変えます）。

echo "https://claude.ai/code/${CLAUDE_CODE_REMOTE_SESSION_ID/#cse_/session_}"

テスト、サービス、パッケージ#

セッションの VM にシェルはなく、Claude がコマンドをすべて実行するので、依頼として書きます。

• テスト：「tests/ の失敗しているテストを直して」「変更のたびに pytest を実行して」のように頼む。pytest や cargo test などプリインストールのツールチェーンのテストランナーは設定なしで動く。jest のようにプロジェクトの依存に宣言したものは、依存関係と一緒に入る
• サービス：PostgreSQL と Redis は入っているが起動していない。Claude に起動を頼む（実行するのは service postgresql start と service redis-server start）。Docker も使え、docker compose up でプロジェクトのサービスを起動させる。イメージの取得は環境のアクセスレベルに従い、Trusted の既定には Docker Hub などが入っている
• イメージが大きい・遅いときは、セットアップスクリプトに docker compose pull か docker compose build を足す。環境キャッシュがイメージを残すが、保存されるのはファイルだけでプロセスは含まれないので、コンテナはセッションごとに起動する
• パッケージ：プリインストールにないものは、セットアップスクリプトで入れる。環境キャッシュが残すので、全セッションの開始時から使える。セッション中に Claude に入れさせることもできるが、ほかのセッションには引き継がれない

リソースと時間の上限#

Anthropic ホスト環境のセッションのリソースは、おおよそ次の上限で、変わることがあります。

大きなビルドやメモリを大量に使うテストは、VM に止められることがあります。それを超える作業は、リモートコントロールで自分のハードウェアで動かすか、組織が運用するコンピュートのセルフホスト環境で動かします。

時間の上限（Anthropic ホスト環境）です。

環境のコマンドのタイムアウトを上げるには、環境変数に BASH_DEFAULT_TIMEOUT_MS と BASH_MAX_TIMEOUT_MS（ミリ秒）を足します（例：BASH_DEFAULT_TIMEOUT_MS=600000 で既定を10分に）。

セットアップスクリプト#

新しいクラウドセッションの開始時、Claude Code が起動する前に実行される Bash スクリプトです。依存関係のインストール、ツールの設定、プリインストールにないものの取得に使います。Ubuntu 24.04 で root として動くので、apt install や多くの言語のパッケージマネージャーが使えます。環境設定ダイアログの「Setup script」欄に書きます。

#!/bin/bash
apt update && apt install -y shellcheck

書くときの制約は3つです。

• 終了コードは0：非ゼロで終わるとセッションが始まらない。重要でないコマンドには || true を付けて、一時的な失敗が止めないようにする
• おおよそ5分以内に終える：超えると環境がキャッシュされない。独立したインストールは & と wait で並列にし、1つで収まらないダウンロードは、SessionStart フックでバックグラウンドで起動する
• インストール用のネットワーク：パッケージのインストールにはレジストリへの接続が要る。Trusted は npm・PyPI・RubyGems・crates.io などを含み、None では失敗する

環境キャッシュ#

セットアップスクリプトは、環境で最初にセッションを始めたときに走ります。おおよそ5分以内に完了すると、Anthropic がファイルシステムのスナップショットを取り、後のセッションの出発点として再利用します。新しいセッションは、依存関係・ツール・Docker イメージがディスクにある状態で始まり、セットアップスクリプトの段階を飛ばします。5分を超えるとキャッシュされません。

• キャッシュはファイルシステムのスナップショットなので、インストールしたパッケージ、取得した Docker イメージ、書いたファイルは残り、起動していたデータベースや docker compose up のスタックなどバックグラウンドのプロセスは残らない。それらはセッションごとに Claude に頼むか、SessionStart フックで起動する
• 環境のセットアップスクリプトか許可ネットワークのホストを変えたとき、およびキャッシュがおおよそ7日で期限切れになったときに、キャッシュを作り直すためスクリプトが再実行される
• Anthropic ホスト環境では、アイドル後に VM が復元されたときはスクリプトが走らないので、スクリプトの変更が既存のセッションに届くのは、VM が解放されて再構築されたときだけ。すぐ反映するには、セッションでコマンドを実行するか、新しいセッションを始める
• キャッシュの有効化やスナップショットの管理は不要

セットアップスクリプトと SessionStart フック#

セットアップスクリプトは VM そのもの（プリインストールにないツールチェーンや CLI）の準備に、SessionStart フックはクラウドでもローカルでも走らせたい npm install のようなプロジェクトの準備に使います。

ユーザー設定 ~/.claude/settings.json の SessionStart フックは、クラウドでは動きません。Anthropic ホスト環境ではリポジトリと組織のサーバー管理設定のフックが走ります（Claude Tag のセッションはサーバー管理設定を受け取らないので、そのフックは走らない）。セルフホスト環境では、運用者がランナーホストの ~/.claude/ から用意したフックと、ランナーイメージの管理設定ファイルのフックも走ります。

クラウドだけで依存関係を入れるには、SessionStart フックと、実行場所を確かめるスクリプトを組み合わせます。リポジトリの .claude/settings.json に、セッションの開始・再開時に scripts/install_pkgs.sh を走らせるフックを書きます。

{
  "hooks": {
    "SessionStart": [
      {
        "matcher": "startup|resume",
        "hooks": [
          {
            "type": "command",
            "command": "bash \"$CLAUDE_PROJECT_DIR\"/scripts/install_pkgs.sh"
          }
        ]
      }
    ]
  }
}

matcher で startup と resume に限り、$CLAUDE_PROJECT_DIR がリポジトリのルートになるので、作業ディレクトリに関係なくスクリプトが見つかります。スクリプトはクラウド以外では何もせず終了します。

#!/bin/bash

if [ "$CLAUDE_CODE_REMOTE" != "true" ]; then
  exit 0
fi

npm install
pip install -r requirements.txt
exit 0

セッション VM の環境は CLAUDE_CODE_REMOTE が true で、ローカルでは true にならないため、手元では何も入れずに終わります。

クラウドでの SessionStart フックの注意点です。

• 1リポジトリのセッションのみ：複数リポジトリのセッションは、どのリポジトリの .claude/settings.json のフックも読まない。その場合の依存関係は、セットアップスクリプトで入れる
• クラウド専用の絞り込みはない：ローカルでも走るので、CLAUDE_CODE_REMOTE が true でなければ早く終了する
• ネットワークが要る：None ではフックが失敗する。Trusted は npm・PyPI・RubyGems・crates.io をカバーする
• プロキシとの互換性：Anthropic ホスト環境の外向き通信はセキュリティプロキシを通り、Bun など正しく動かないパッケージマネージャーがある
• 起動の遅れ：セッションの開始・再開のたびに走る（環境キャッシュの恩恵がない）ので、すでに入っているかを確認してから入れる

ベースイメージのカスタマイズは、提供イメージの上にセットアップスクリプトで必要なものを入れるか、docker compose で自前のイメージを Claude と並べて動かします。ベースイメージの置き換えはまだ対応していません。

Trusted の既定の許可ドメイン#

Trusted のネットワークアクセスでは、次のドメインに届きます。* はワイルドカードのサブドメイン（*.gcr.io は gcr.io の任意のサブドメイン）です。

トラブルシューティング#

実行時の API エラー（API Error: 500、529 Overloaded、429、Prompt is too long）は CLI・デスクトップと共通です（エラー一覧）。

制限事項#

• レート制限：クラウドセッションは、アカウントの Claude と Claude Code のほかの利用と同じ上限を共有します。並行タスクを増やすと、そのぶん消費します。クラウド VM の別途の計算費用はありません（コストを抑える）
• 時間の上限：コマンドと SessionStart フックには既定のタイムアウトがあり、セットアップスクリプトがキャッシュされるのはおおよそ5分以内に終わるときだけです
• リポジトリの認証：クラウドセッションをターミナルへ引き込めるのは、同じアカウントで認証しているときだけです
• プラットフォーム：リポジトリのクローンと PR 作成には GitHub が要ります。セルフホストの GitHub Enterprise Server は Team・Enterprise で対応しています。GitLab・Bitbucket などは、CCR_FORCE_BUNDLE=1 でローカルの束として送れますが、結果をそのリモートへ push し返せません
• 組織の IP 許可リスト：Anthropic ホストのクラウドセッションは、自分のネットワークではなく Anthropic の管理するインフラから Anthropic API を呼びます（セルフホスト環境は自分のネットワークから）。IP 許可リストを有効にしていると、Anthropic ホストのすべてのクラウドセッションが認証エラーで失敗します。コードレビューと、Anthropic ホスト環境で動くルーティンも同じです。Anthropic ホストのサービスを許可リストから除外するには Anthropic サポートに連絡します

セキュリティと分離#

• 分離された VM：セッションごとに分離された Anthropic 管理の VM で動く。セルフホスト環境に回したセッションは自社のインフラで動き、分離は配備側の責任になる
• ネットワーク制御：Anthropic ホスト環境では、既定で制限され、無効にもできる。ネットワークアクセスをなしにしても、Claude Code は Anthropic API と通信でき、データが VM の外へ出る可能性がある
• 認証情報の保護：Anthropic ホスト環境では、git の認証情報と署名鍵がサンドボックスの外にあり、プロキシが範囲を絞った認証情報でセッションの代わりに認証する。セルフホスト環境では配備側が git の認証情報を用意する
• API 認証情報：Pro・Max の Anthropic ホスト環境で環境に追加したキーも、同様にサンドボックスの外にあり、セッションを出た後のリクエストに付く。セルフホスト環境には API 認証情報がなく、Team・Enterprise でもまだ使えない
• 安全な解析：コードは、PR を作る前に、セッションの分離された環境の中で解析・変更される

関連：Claude Tagは、同じクラウドインフラで動く、組織管理の Slack 上の @Claude です。自分のマシンを操作する方法はリモートコントロールとモバイル、データの扱いはセキュリティとデータの扱いを見てください。