
Claude Codeのクラウドセッションを企業で使うなら? 管理設定・ネットワーク・セキュリティの注意点
Claude Codeのクラウドセッションは、Claude CodeをAnthropic側の仮想マシンで動かし、ノートPCを閉じても作業を続けられる機能です(2026年9月24日、日本時間で一般提供開始)。この記事では、できることとXでの使われ方に加えて、企業で使う前に確認したい管理設定・ネットワーク・セキュリティの注意点を整理します。
発表の直後、Xでは「Proに100ドル、Maxに250ドルのクレジットがもらえる」という話題が一気に広がりました。noteでも、受け取り方や個人での使い方を紹介する記事がすでに並んでいます。
一方で、会社のリポジトリで使う立場で公式ドキュメントを読むと、別のところが気になりました。組織のポリシーを有効にしないと使えないこと、IP許可リストを入れている組織ではそのままでは動かないこと、PRの自動修正が本人のGitHubアカウント名で返信することなどです。公式ドキュメント、国内の報道、第三者の検証記事、X上の声をもとにまとめました。
1. Claude Codeのクラウドセッションとは:PCを閉じても動くClaude Code
クラウドセッションは、Claude Codeのセッションを手元のマシンではなくクラウドで動かす仕組みです。既定ではAnthropicが管理する基盤で動き、組織が用意した自己ホスト環境に振り向けることもできます。セッションはノートPCを閉じても動き続け、ブラウザやスマホから進み具合を確認したり、指示を足したりできます。

出典:@ClaudeDevs
Anthropicの開発者向けアカウントが正式提供を告知したのは、日本時間9月24日の午前6時23分です。この投稿は、翌25日の時点で389万回以上表示されていました。
機能そのものは新しくありません。i-Styleのブログによると、2025年10月に「Claude Code on the web」の名前で試験公開されたもので、今回リサーチプレビューの扱いが外れ、呼び名もクラウドセッションになりました。

手元のPCで動くClaude Codeをスマホから操作する「Remote Control」とは別の機能です。Remote Controlはセッション自体が手元にあり、クラウドセッションはセッションそのものが向こう側にあります。
2. できること:並列で投げて、あとからPRを確認する
公式ドキュメントに載っている使い方は、大きく4つに分けられます。
1つ目は、ターミナルからクラウドに仕事を投げることです。claude --cloud "Fix the authentication bug" と打つと、現在のブランチのGitHubリモートをクラウドの仮想マシンにクローンして作業が始まります。コマンドを複数回打てば、それぞれ別のセッションとして並行して動きます。公式ドキュメントでは、不安定なテストの修正、APIドキュメントの更新、ログ出力の書き換えを同時に投げる例が挙がっています。
2つ目は、手元で計画を立ててからクラウドで実行する使い方です。手元のplan modeで方針を固め、計画ファイルをコミットしてpushしてから、claude --cloud で実行を任せます。
3つ目は、クラウドの結果を手元に引き取ることです。claude --teleport を使うと、クラウドのセッションのブランチと会話履歴を手元のターミナルに取り込めます。ただしCLIでの引き継ぎは一方通行で、手元のセッションをCLIからクラウドへ送ることはできません。デスクトップアプリには、手元のセッションをクラウドに送る「Continue in」メニューがあります。
4つ目は、PRの自動修正(Auto-fix)です。Claude GitHub Appを入れたリポジトリでは、PRのCIが失敗したりレビューコメントが付いたりすると、Claudeが調べて修正をpushします。解釈が分かれるコメントや設計に関わる指摘には、手を出す前に確認を求めます。
3. すごいところ:Claude Codeの仕事が手元のPCから離れた
ここからは、すごいところを「実行場所」(3-1)、「外部からの指示」(3-2)、「料金」(3-3)の順に見ていきます。
3-1. 実行場所:PCを閉じても止まらない
これまでClaude Codeに長い作業を頼むと、終わるまでPCを開けておく必要がありました。クラウドセッションでは、作業がAnthropic側の仮想マシンで進むので、PCを閉じても止まりません。
i-Styleの検証では、ほぼ空のリポジトリを送ったところ、手元でコマンドを実行してから約8秒でクラウド側が動き出しました。仮想マシンは4コア、メモリ約15GB、空きディスク30GBだったそうです。公式ドキュメントの目安は4 vCPU・16GB・30GBで、変わることがあると注記されています。
3-2. 外部からの指示:スクリプトから1通送れる
地味ですが、企業の自動化では効きそうなのが claude -p "メッセージ" --cloud <session-id> です。ログインしている別のマシンから、動いているクラウドセッションに指示を送り、返事を待たずに終了できます。公式ドキュメントも、CIのスクリプトから追加の指示を送る使い方に触れています。
人が画面の前に座って操作する道具から、外から仕事を積める作業者に近づいたように見えます。後で紹介するように、X上でもこの点を評価する声がありました。
3-3. 料金:仮想マシンの別料金はなく、試用クレジット付き
公式ドキュメントによると、クラウドセッションはアカウント内の他のClaude・Claude Codeの利用と同じ上限を共有し、仮想マシンの別料金はかかりません。並列で動かせば、そのぶん上限に早く届きます。
告知の直後は「クラウドが有料になったのか」という受け止めも広がりました。約4時間半後、公式アカウントが補足を出しています。

出典:@ClaudeDevs
補足の内容は、「クラウドセッションはProやMaxのプランで動く。クレジットは任意の特典で、クラウドセッションが先に消費し、尽きたら通常のプランの枠に戻る」というものです。クレジットの受け取り期限は日本時間10月8日15時59分、有効期限は11月5日16時59分と窓の杜は報じています。
4. で、企業ではどう使う?:先に組織の設定と社内ルールを決める
個人のPro・Maxなら、クレジットを受け取ってGitHubをつなげばすぐ試せます。TeamやEnterpriseで使う場合は、公式ドキュメントを読む限り、先に決めておくことがいくつかあります。ここからは「管理設定」(4-1)、「セキュリティ」(4-2)、「運用」(4-3)の順に見ていきます。
4-1. 管理設定:組織のポリシーとIP許可リスト
まず、組織として使える状態かどうかです。claude --cloud を使うには、組織ポリシー allow_remote_sessions が有効になっている必要があり、これはOwnerがClaude Codeの管理設定で切り替えます。TeamとEnterpriseでは、GitHubをCLIからつなぐ /web-setup を含む「Quick web setup」が既定でオフです。
次に、使えない組織の条件があります。Zero Data Retention(ZDR)を有効にしている組織は、クラウドセッションの機能を使えません。Claude CodeをAmazon BedrockやGoogle Cloud経由で使っている場合も、--cloud は使えず、Anthropicのアカウントが必要です。
見落としやすいのが、組織のIP許可リストです。Anthropic管理のクラウドセッションは、社内ネットワークではなくAnthropic側の基盤からAPIを呼びます。そのため、IP許可リストを有効にしている組織では、すべてのクラウドセッションが認証エラーになります。Code ReviewやRoutinesも同じで、公式ドキュメントはサポートに除外を依頼するよう案内しています。
もう1つ、MDMや管理設定ファイルで端末に配った設定は、Anthropic管理の仮想マシンには届きません。サーバー側で管理する設定は適用されます。端末の管理だけでClaude Codeの挙動を統制している組織は、ここを確認しておく必要があります。
4-2. セキュリティ:ネットワーク制限と自己ホスト環境
セッションごとに隔離された仮想マシンが使われ、ネットワークは既定で「Trusted」(パッケージの配布元、GitHub、クラウドSDKなど許可リストの宛先だけ)に絞られています。None(外部通信なし)や、自社で許可先を書くCustomも選べます。ただしNoneにしても、Claude Code自身のAnthropic APIへの通信は残り、公式ドキュメントも「データが仮想マシンの外に出る可能性がある」と書いています。MCPコネクタの通信も、許可リストとは別の経路を通ります。
秘密情報の置き場所にも注意が要ります。キーをセッションから見えない形で渡す「API credentials」は、現時点ではProとMaxだけの機能で、TeamとEnterpriseではまだ使えません。Ownerが作る組織共有の環境では、環境変数を全メンバーが読めます。公式ドキュメントは、そこに秘密情報を入れないよう注意しています。
社内のデータベースやVPNの中のAPIに触れる作業は、Anthropic管理の環境では扱えません。そうした作業のために、TeamとEnterpriseには「自己ホスト環境」があります。社内のサーバーでランナーを動かし、セッションを社内ネットワークの中で実行する仕組みで、Anthropicから社内に接続しにいくことはありません。ただしパブリックベータで既定はオフ、ZDRの組織では使えず、推論はAnthropic APIに固定されます。リポジトリや成果物は社内に残せますが、セッションの内容はモデルの推論のためにAnthropicへ送られます。
4-3. 運用:Auto-fixとセッション共有の範囲
運用面では、Auto-fixの扱いを決めておきたいところです。Auto-fixがレビューコメントに返信するとき、投稿はClaude Codeによるものと表示されつつ、開始した人のGitHubアカウント名で出ます。公式ドキュメントは、PRへのコメントでAtlantisやTerraform Cloud、issue_commentで動くGitHub Actionsが走るリポジトリでは、Claudeの返信がそれらを起動しうるとして、無効化を検討するよう書いています。コメントがインフラの変更につながるリポジトリでは、Auto-fixを使わない判断もありそうです。
セッションの共有範囲も確認しておきます。TeamとEnterpriseでは「Private」か、組織内に見せる「Team」を選べます。個人のProとMaxでは「Public」を選ぶと、claude.aiにログインした人なら誰でも見られる状態になり、リポジトリへのアクセス確認も既定では有効になっていません。社員が個人プランで会社のコードを扱っている場合は、共有の設定を一度見直したほうがよさそうです。
もう1つ、非アクティブの時間が続くと仮想マシンは回収されます。会話を開き直せば続きから再開できますが、裏で動いていたサブエージェントやシェルのコマンドは戻りません。MCPの承認待ちの間も非アクティブとして数えられます。夜間に長く走らせる作業では、承認待ちで止まったまま回収されないよう、許可の設定を事前に見直しておきたいところです。
導入前の確認項目をまとめると、次の3つです。
組織でクラウドセッションを使えるか:allow_remote_sessions、ZDRの有無、IP許可リストの除外、Bedrock等の経由ではないか
どの環境で動かすか:Anthropic管理か自己ホストか、ネットワークレベル、共有環境の環境変数に秘密情報がないか
誰の名前で何が動くか:Auto-fixを使うリポジトリの範囲、セッションの共有範囲、並列実行による利用枠の消費
5. Xの実例:何が作られ、どう使われているか
Xでは、告知の直後はクレジットの受け取り方の投稿が目立ちました。時間がたつにつれ、使い方や、向かない仕事を整理する投稿も出ています。ここからは「受け取る」(5-1)、「開発で使う」(5-2)、「任せ方を変える」(5-3)、「冷静な評価」(5-4)の順に見ていきます。
5-1. 受け取る:期限と対象をスクリーンショットで確認
テツメモさんは、受け取りの手順と日本時間の期限をまとめています。投稿に付いた受け取り画面には、「プロジェクトとルーチンは対象外です」と書かれています。クレジットはクラウドセッション専用で、通常のチャットや手元のClaude Codeには使えません。

出典:@tetumemo
この投稿は41万回以上表示されていました。受け取り画面の文言が、公式の告知文より細かい条件を伝えている点は、企業で案内を出すときにも参考になります。
5-2. 開発で使う:CLIから投げて、別のマシンから指示を送る
@fujibeeさんは、--cloud、--teleport、claude -p ... --cloud の違いと、Remote Controlとの使い分けを整理しています。投稿の最後では、claude -p ... --cloud によって、人が見ていなくてもスクリプトなどから指示を送れるようになった点を一番大きな変化として挙げています。長い投稿のため、画像は冒頭部分のみです。

出典:@fujibee
GUIの操作や手元のMCPが必要な仕事はクラウドに持っていけない、という指摘も入っています。
5-3. 任せ方を変える:Projectsで複数のセッションを束ねる
クラウドセッションの上に載っているのが、9月17日にベータで登場した「Projects」です。1つの会話にやりたいことを書くと、Claudeが作業を分けて、複数のクラウドセッションを並列で動かします。@k_matsumaruさんは、人が複数のClaude Codeを管理する形から、Claudeが複数のClaude Codeを管理する形に変わったと説明しています。長い投稿のため、画像は冒頭部分のみです。

出典:@k_matsumaru
@yagiryuuuさんは、Projectsの仕組みに加えて注意点を挙げています。初期設定では全スレッドがOpusのhigh effortで動くため使用量の減りが速いこと、プロジェクトは個人専用で他の人と共有できないこと(9月18日時点)です。投稿には動画が付いていて、元の投稿で見られます。画像は冒頭部分のみです。

出典:@yagiryuuu
企業で使う場合、並列で動くスレッドの数とモデルの設定が、そのまま利用枠の消費量になります。チームで導入するなら、既定の設定をそのまま使わない運用ルールが必要になりそうです。
5-4. 冷静な評価:向かない仕事と「完了」の確かめ方
@RadineerE10さんは、ビジネスの現場向けに変化を5つに整理したうえで、「万能ではない」として向かない仕事を挙げています。社内ネットワーク限定の資源、ブラウザにログインした状態が必要な自動化、巨大なローカルデータを使う処理です。画像は冒頭部分のみです。

出典:@RadineerE10
関岡 冴俊さんのX記事は、発表当日のX投稿99件を分類し、実際にクラウドに仕事を出した報告は9件だったとしています。その中には、一晩任せたら「完了」と報告されたものの、テストの半分が手つかずのブランチだったという声もあったそうです。記事は、クラウドに出す前に「push済みか」「画面操作が要らないか」「手元だけの設定に頼らないか」「4 vCPU・16GBに収まるか」を確かめるよう勧めています。長い記事のため、画像は冒頭部分のみです。

出典:@SatoshiSsSs
見ていない間に進む仕組みだからこそ、終わった後に何を確かめるかを決めておく必要があります。企業では、テストの実行結果をPRに残す、レビューを通るまでマージしない、といった既存の手順にクラウドセッションの成果物を乗せる形が現実的だと思います。
6. まとめ:試す前に、組織の設定と任せる範囲を決めておく
Claude Codeのクラウドセッションは、Anthropic管理の仮想マシンで動き、PCを閉じても作業が続く。料金はプランの利用枠を共有し、仮想マシンの別料金はない
企業では、allow_remote_sessions、ZDR、IP許可リスト、Bedrock等の経由といった「そもそも使えるか」の条件を先に確認したい
ネットワークレベル、秘密情報の置き場所、Auto-fixとセッション共有の範囲を決めてから、小さなタスクで試すのがよさそう
今回の発表は、クレジットの配布が話題の中心でした。ただ、Projectsや自己ホスト環境、claude -p ... --cloud と並べて見ると、Claude Codeを手元の道具から、組織が運用するエージェントの実行基盤に広げる動きとして読めます。
そうなると、問われるのは「どのモデルを使うか」だけではなくなります。どの環境で、誰の権限で、どこまで任せ、終わった後に何を確かめるか。これまで人の作業に対して決めていたルールを、エージェントの作業にも当てはめる準備が必要になりそうです。
このnoteでは、話題のAIニュースを「で、企業ではどう使う?」の視点で整理しています。