Claude Code のクラウドセッションとは ― 制作会社に任せる前に確認したい 7 つのこと

・ 約11分で読めます

  1. ホーム
  2. テックブログ
  3. Claude Code のクラウドセッションとは ― 制作会社に任せる前に確認したい 7 つのこと

「この修正は AI エージェントにクラウドで作業させます」と制作会社から言われて、何を確認すればよいか迷ったことはないでしょうか。この記事は、Web サイトやシステムの開発を外部に依頼している企業の担当者に向けて、Anthropic の「Claude Code のクラウドセッション」の仕組みと、許可する前に確かめたい点をまとめます。内容は 2026 年 11 月時点の公式ドキュメントにもとづいています。

クラウドセッションとは

Claude Code は、Anthropic が提供する AI のコーディングエージェントです。エージェントとは、指示を受けて自分でファイルを読み、コードを書き換え、テストを動かすところまで進める AI のことです。もともとは開発者のパソコンの中で動かす道具でした。

クラウドセッションは、この Claude Code を開発者のパソコンではなく、Anthropic が管理するクラウド上の仮想マシンで動かす仕組みです。以前は「Claude Code on the web」と呼ばれていました。公式ドキュメントには「ノートパソコンを閉じても、セッションは動き続ける」と書かれています。2026 年 11 月時点では、Pro・Max・Ultra・Team の各プランと、Enterprise の一部の席で使えます。

1 回の作業の流れは、次のようになります。

sequenceDiagram participant Dev as 制作会社のエンジニア participant VM as クラウドの仮想マシン(作業ごとに新規) participant GH as GitHub(お客様のリポジトリ) Dev->>VM: ブラウザやスマホから作業を指示 VM->>GH: リポジトリを複製(プロキシ経由) VM->>VM: コードを読む・直す・テストする VM->>GH: 作業用ブランチに push Dev->>GH: 差分を確認し、プルリクエストでレビュー Note over VM: しばらく使わないと仮想マシンは片付けられる

ポイントは 3 つあります。

1 つめは、作業ごとに新しい仮想マシンが用意されることです。前の作業の残りや、ほかのお客様の案件のファイルは入っていません。作業が終わってしばらく使われないと、仮想マシンは片付けられます。

2 つめは、コードのやり取りが GitHub を通ることです。仮想マシンはリポジトリ(ソースコードの保管場所)を GitHub から複製し、作業の結果をブランチとして GitHub に戻します。GitHub はソースコードの管理サービスで、多くの制作会社が使っています。

3 つめは、結果は「提案」として戻ってくることです。Claude が直接本番サイトを書き換えるのではなく、作業用のブランチに変更を置き、人がプルリクエスト(変更の取り込み依頼)で中身を確かめてから取り込みます。

依頼する側にとって何が変わるか

利点

同時に進められる作業が増えます。 クラウドセッションは 1 つずつ独立して動くので、エンジニア 1 人が「問い合わせフォームの不具合」「表記ゆれの修正」「依存ライブラリの更新」を並行して任せられます。エンジニアのパソコンを占有しないため、待ち時間が減り、小さな修正の回転が速くなることが期待できます。

エンジニアの手元の環境に左右されにくくなります。 毎回まっさらな仮想マシンから始まるので、「担当者のパソコンでは動いた」という食い違いが起きにくくなります。必要な道具の入れ方は、後で説明する「環境」の設定として残せます。

作業の記録が残ります。 指示の内容、Claude が実行したコマンド、変更の差分が会話として残り、最後は GitHub のプルリクエストになります。公式のセキュリティのページには、クラウドセッションの操作は監査のために記録されると書かれています。「誰が、何を、なぜ変えたか」をあとから追いやすくなるのは、依頼する側にとっても安心材料です。

限界

人の確認はなくなりません。 AI が書いたコードにも誤りはあります。テストが通っても、仕様の読み違いまでは見つけられません。プルリクエストを人がレビューする工程は、むしろ大事になります。

つながらないものには手が出せません。 クラウドの仮想マシンから届くのは、GitHub と、許可されたインターネット上の場所だけです。社内ネットワークの中にある検証サーバーや、お客様の社内システムには、そのままでは届きません。こうした作業は、エンジニアのパソコンで行うことになります。

GitHub が前提です。 公式の環境では、リポジトリの複製とプルリクエストの作成に GitHub を使います。GitLab や Bitbucket のコードを持ち込む方法もありますが、その場合は結果を元の場所に push できません。お客様のコードが GitHub 以外にあるなら、どう運用するかを先に決める必要があります。

安全の仕組み ― ツールが守る部分と、運用で決まる部分

依頼する側がいちばん気になるのは、「自社のコードや秘密情報が漏れないか」だと思います。公式ドキュメントに書かれている仕組みと、制作会社の設定や運用で変わる部分を分けて整理します。

項目 ツールの仕組み(公式) 制作会社の運用で決まること
隔離 作業ごとに独立した仮想マシン 1 つの作業で複数のお客様のリポジトリを混ぜないか
GitHub の認証情報 仮想マシンの中には入らない。GitHub への通信はプロキシ経由で、短い期間だけ有効な資格情報を使う どのリポジトリへのアクセスを許可しているか
push の制限 ブランチの削除やタグの push はプロキシが拒否する 本番用ブランチを保護ルールで守っているか
ネットワーク 標準は「信頼済み」の場所だけ(パッケージの配布元・GitHub・主要クラウドなど) 許可する場所を増やしていないか、「すべて許可」にしていないか
API キーなどの秘密情報 「ネットワークシークレット」に保存すれば、Claude からキーの値は見えない 環境変数にキーを書いていないか

いくつか補足します。

ブランチの保護は GitHub 側の設定次第

公式ドキュメントには、プロキシは「どのブランチを更新できるかは制限しない。制限するには GitHub のブランチ保護ルールを使う」と書かれています。つまり、本番に反映されるブランチ(main など)を守るのは、GitHub の設定です。「本番ブランチには、レビュー済みのプルリクエストからしか取り込めない」というルールが入っていれば、AI が誤った変更を作っても、本番に直接入ることはありません。

ネットワークの設定は 4 段階

ネットワークは「なし」「信頼済み(標準)」「すべて」「カスタム」から選べます。標準の「信頼済み」では、npm や Packagist などのパッケージの配布元、GitHub、主要なクラウドの窓口など、開発でよく使う場所だけに届きます。公式によれば、「なし」にしても Claude Code 自身が Anthropic の API と通信するため、データが仮想マシンの外に出る経路はゼロにはなりません。

環境変数に秘密情報を書かない

クラウドセッションの「環境」には、環境変数(プログラムに渡す設定値)を保存できます。ただし、公式ドキュメントでは、その環境を使える人なら誰でも値を読めるとされています。外部サービスの API キーなどは、環境変数ではなく「ネットワークシークレット」に保存するのが公式の方法です。こちらは、通信が仮想マシンを出たあとにプロキシがキーを付け足すので、仮想マシンの中にも Claude にもキーの値は渡りません。

利用できない組織もある

公式ドキュメントによれば、データを保持しない設定(Zero Data Retention)や HIPAA 向けの設定をした組織、顧客管理の暗号鍵(CMEK)を使う組織では、クラウドセッションは使えません。また、Amazon Bedrock などほかのクラウド経由で Claude を使っている場合も対象外です。自社のセキュリティ方針で AI の利用先を決めているなら、その方針と合うかを確かめる必要があります。

任せてよい作業・慎重にしたい作業

クラウドセッションが得意なのは、範囲がはっきりしていて、結果を差分で確かめられる作業です。

任せやすい作業 慎重にしたい作業
文言・表記の修正、画像の差し替え 決済・会員情報など、お金や個人情報に関わる処理
依存ライブラリの更新と、テストでの確認 本番データベースの構造を変える作業
小さな不具合の調査と修正 社内ネットワーク内のシステムとつなぐ作業
テストコードの追加 仕様が固まっていない新機能の設計

右の列が「AI に任せてはいけない」わけではありません。人が設計を決め、変更を細かく区切り、レビューを厚くすれば任せられる部分もあります。大事なのは、どの作業をどこまで任せるかを、制作会社が説明できることです。

制作会社に確認したい 7 つのこと

クラウドセッションの利用を許可するかどうか判断するときは、次の点を制作会社に聞いてみてください。きちんと運用している会社なら、すぐに答えられる内容です。

  • どの作業にクラウドセッションを使い、どの作業には使わないか
  • AI が作った変更は、誰がどうレビューしてから本番に入れるか
  • 本番用のブランチに、GitHub の保護ルールが入っているか
  • ネットワークの設定は標準のままか。広げているなら、どこを許可しているか
  • API キーなどの秘密情報を、どこに保存しているか(環境変数に書いていないか)
  • 本番のデータや個人情報を、クラウドセッションに渡していないか
  • 契約上、ソースコードを外部の AI サービスで扱ってよいことになっているか

答えの良し悪しを見分ける目安もあげておきます。たとえば 2 つめの質問に「AI が作ったものは担当エンジニアが差分をすべて読み、検証環境で動作を確かめてから取り込みます」と、手順と担当者まで答えられれば安心です。逆に「AI なので大丈夫です」「テストが通れば取り込みます」のように、人の確認が見えない答えなら、もう一段詳しく聞いてみてください。

費用の面では、公式ドキュメントによれば、クラウドの仮想マシンに別料金はかからず、制作会社が契約しているプランの利用枠を使います。お客様側に新しい契約や費用が発生するものではありません。

最後の項目は、技術というより契約の話です。秘密保持契約の中で、ソースコードを第三者のサービスで扱うことをどう定めているかを確かめ、必要なら AI の利用について取り決めを追加しておくと、あとで揉めずに済みます。

まとめ

  • クラウドセッションは、作業ごとに用意される隔離された仮想マシンで Claude Code を動かし、結果を GitHub のブランチとして返す仕組みです
  • GitHub の認証情報を仮想マシンに入れない、ネットワークを標準で絞るなど、ツール側にも守りの仕組みがあります。一方で、本番ブランチの保護や秘密情報の置き場所は、制作会社の設定と運用で決まります
  • 許可するかどうかは、チェックリストの 7 項目に制作会社が答えられるかで判断できます

チームでの AI エージェントの使い方(ルールの書き方や権限の決め方)は、「AI コーディングエージェントを受託開発に組み込む ― AGENTS.md・権限・検証の設計」で詳しく紹介しています。自社のサイトやシステムで AI を使った開発を任せてよいか迷ったら、お気軽にご相談ください。

参考リンク

記事一覧へ

お問い合わせ

プロジェクトのご相談、お見積もり、技術的なご質問など、お気軽にお問い合わせください。

WEB

フォームからご連絡ください。

お問い合わせフォーム

CONSULTING

  • システム導入相談
  • サイト制作相談
  • 技術課題解決
  • 運用・保守