Claude Code のクラウドセッションは、GitHub の1つのリポジトリだけを触らせ、本番のサーバーにはそのリポジトリを「取りに行かせる」だけにすれば、本番への入口を増やさずに開発を任せられます。ただ、そこまで組む途中で何度か足が止まりました。この記事は、筆者（このサイトの運営者）が2026年10月4日に別の開発プロジェクトで使い始めたときの記録を、公式ドキュメントの原文で確かめ直したものです。

クラウドが触る範囲

GitHub の1リポジトリだけ

Claude の GitHub App は「Only select repositories」で、今回のリポジトリだけに入れる。

本番のサーバー

取りに行くだけ

読み取り専用の鍵で本番から取得する。クラウドにも GitHub にも本番の鍵を渡さない。

クラウドの環境

プロジェクトごとに新しく

環境変数はその環境を使う人なら誰でも読める。秘密の値を入れない。

出典：Use Claude Code in the cloud、Configure cloud environments。2026年10月4日確認。仕組み・始め方・料金の全体像は「Claude Codeのクラウドセッションとは」へ。

目次

1. 本番を守る構成——本番は「取りに行くだけ」

GitHub を経由すると本番のサーバーへの入口が増えるのでは、というのが一番の心配でした。筆者は次の構成にしました（公式の推奨ではなく、筆者が選んだ形です）。矢印は、データを取りに行く向きです。

  • クラウドセッションコードを書き、ブランチを push する（本番には入れない）
  • →push
  • GitHub の非公開リポジトリApp を入れたのはこの1つだけ
  • ←取得
  • 本番のサーバー読み取り専用の Deploy key で取りに行き、デプロイは人が実行する
鍵本番に、そのリポジトリ専用の読み取り専用の鍵（Deploy key）を置く。GitHub の公式ドキュメントによると、Deploy key は1つのリポジトリにだけアクセスでき、既定で読み取り専用。
やらないことGitHub Actions に本番の鍵を渡して自動デプロイ、はしない。本番に入れる経路が1本増えるため。
デプロイ人が手で実行する。本番の側のスクリプトが最新のコードを取り込み、ビルドして入れ替える。失敗したら、動いている版はそのまま残る。

筆者は最初、別のリポジトリ用の鍵を使い回そうとして、GitHub に「Key is already in use（その鍵はもう使われている）」と断られました。GitHub のドキュメントによると、鍵が別のアカウントやリポジトリにすでに登録されていると出る表示です。リポジトリごとに鍵を分けるので、1本が漏れても読まれるのはそのリポジトリだけで済みます。

2. GitHub なしで始めると何が送られるか

筆者はふだん、コードを自分のサーバーの git リポジトリで管理しているので、最初は GitHub なしで使うことを考えました。公式ドキュメントによると、リモートの無いリポジトリなどで claude --cloud "作業内容" を実行すると、手元のリポジトリを1つにまとめて（バンドルして）クラウドへ送ります。送られるものは次のとおりです。

履歴すべてのブランチの履歴。昔コミットして消したファイルも、履歴の中に残っていれば送られる。
未コミットの変更git で管理しているファイルの、まだコミットしていない変更。
送られないものgit で管理していないファイル（必要なら git add する）。

macOS・Linux・WSL

秘密らしい名前は残す

.env・*.tfvars・id_rsa・*.pem のような名前のファイルは、未コミットの変更を送らずに手元に残す。

Windows（WSL でない）

名前に関係なく送る

git で管理しているファイルの未コミットの変更は、そのまま送られる。送りたくない変更は、始める前に退避するか元に戻す。

危ないのは、秘密の値を含むファイルを git で管理していて書き換えている場合と、過去に秘密の値をコミットしたことがある場合です。.gitignore で外した .env は、そもそも送られません。

もう1つ、バンドルから作ったセッションが push できるのは、公式ドキュメントによると「GitHub の連携に push の権限があるリポジトリ」だけです。GitHub 以外の自前のリポジトリへ結果を直接戻す方法は、ドキュメントからは読み取れませんでした。筆者は手順書まで書いたところで、素直に GitHub に非公開リポジトリを作りました。

3. 実際に詰まった5つの点

GitHub に非公開リポジトリを作ってから、実際に始めるまでに詰まった点を、症状・原因・対処の順に並べます。

① リポジトリが一覧に出ない

症状作ったはずのリポジトリが一覧に無い。出てくるのは、以前に試しで作った別のアカウントのテスト用リポジトリだけ。
原因claude.ai につながっている GitHub アカウントが、ふだん使うものと違っていた。以前に別のアカウントで連携したまま忘れていた。
対処claude.ai/customize/connectors で GitHub の連携を切断し、ブラウザで正しいアカウントにログインし直してから連携をやり直した。切断するとクラウドセッションが使う GitHub の認証情報が消える、と公式ドキュメントにある。

② GitHub App をどこまで入れるか

症状連携の途中で、Claude の GitHub App を入れる範囲を聞かれる。「All repositories」を選ぶと、そのアカウントや組織のすべてのリポジトリに入る。
原因筆者のアカウントは取引先の案件の組織にも所属していて、そこまで Claude に触らせたくなかった。
対処インストール先は自社の組織だけにし、「Only select repositories」で今回のリポジトリ1つだけを選んだ。組織によっては、インストールに組織のオーナーの承認が要る。

③ App を入れていない組織のリポジトリが一覧に出る

症状範囲を絞ったのに、別の組織のリポジトリがいくつか一覧に出てきた。
原因どれも公開リポジトリだった。公式ドキュメントの表では、GitHub App で連携した場合に使えるのは「すべての公開リポジトリと、App を入れた非公開リポジトリ」。
対処対処は不要。公開リポジトリはもともと誰でも読めるので、新しく漏れるものは無い。非公開リポジトリは App を入れたものしか使えない。

④ 以前のクラウドの「環境」が残っていた

症状クラウドの「環境」（ネットワークの許可範囲・環境変数・セットアップスクリプトを持つ保存された設定）に、別のプロジェクトで作ったものが残っていた。
原因公式ドキュメントによると、環境を使う人なら誰でも、その環境変数とセットアップスクリプトを読める。使い回すと、当時の値が新しいプロジェクトからも見える。
対処プロジェクトごとに新しい環境を作り、環境変数には何も入れなかった。ネットワークは既定の「Trusted」のまま。API の鍵が要るなら、Pro・Max では環境変数でなく「API credentials」に登録すると、セッションは鍵の中身を読めない（Team・Enterprise ではまだ使えない）。

⑤ 手元のファイルを読ませようとした

症状最初の指示に「手元のフォルダにある手順書を読んで」と書こうとした。
原因クラウドのセッションからは手元の PC のファイルは見えない。公式ドキュメントの比較表でも、クラウドセッションは手元の設定を使わず、使うのは「リポジトリだけ」。
対処プロジェクトのルール・安全のために守ること・本番の約束を、すべて最初のメッセージに書き、仕様書は添付した。くり返し使うルールは、リポジトリの CLAUDE.md に書いてコミットしておくと、毎回書かずに済む。

4. クラウドの権限モードの違い

送る直前、権限モードが「Accept edits」になっていました。名前からすると一番どんどん進みそうですが、公式ドキュメントによると、クラウドの Accept edits は手元の Claude Code でいう通常のモード（Manual）に当たります。クラウドではファイルの編集がどのモードでも先に許可されているので、通常のモードがこの名前で表示されているだけです。

Accept edits

コマンドで止まる

ファイルの編集は自動で通る。npm install・ビルド・git push などのコマンドは、そのたびに承認を待つ。

Plan

まず計画を立てる

変更する前に、何をするかの計画を作って見せる。

Auto

任せて進める

承認を求める代わりに、分類器（安全の判定の仕組み）が操作を確かめて進める。組織が許可し、選んだモデルが対応しているときだけ出る。

放っておいても進んでほしかったので、筆者は Auto に切り替えました。なお、クラウドではすべての確認を飛ばすモード（bypass permissions）は選べず、リポジトリの設定ファイルに書いてあっても無視されます。各モードの詳しい違いは「Claude Code の権限モード」にまとめています。

5. 始める前のチェックリスト

  • GitHub アカウントclaude.ai につながっているのは、使いたいアカウントか。
  • App の範囲「Only select repositories」で、必要なリポジトリだけに入れたか。
  • 履歴過去にコミットした秘密の値が、リポジトリの履歴に残っていないか。
  • 環境このプロジェクト用に新しく作ったか。環境変数に秘密の値を入れていないか。
  • 本番クラウドや GitHub から本番に入れる経路を作っていないか（本番から取りに行く形か）。
  • ルールくり返し使うルールは、リポジトリの CLAUDE.md に入れたか。
  • 権限モード任せるなら Auto、1つずつ確かめるなら Accept edits を選んだか。

まとめ

本番を守ってクラウドセッションを使う形は、クラウドは GitHub の1つのリポジトリだけを触り、本番はそれを読み取り専用の鍵で取りに行き、デプロイは人が実行する、の3点に尽きます。GitHub なしでも始められますが、リポジトリはすべてのブランチの履歴ごと送られ、Windows では管理下のファイルの未コミットの変更も名前に関係なく送られます。

実際に詰まったのは、別の GitHub アカウントにつながっていたこと、App の範囲、残っていた古い環境、手元のファイルが見えないこと、そして「Accept edits」がコマンドのたびに止まることでした。どれも始める前のチェックリストで防げます。

FAQ

Q. GitHub を使わずにクラウドセッションを試せますか？

A. 試せます。claude --cloud "作業内容" で手元のリポジトリをまとめて送れます。100MB 未満で、コミットが1つ以上あることが条件です。すべてのブランチの履歴が送られ、結果を GitHub 以外のリポジトリへ直接戻す方法は公式ドキュメントにありません。

Q. 一覧に、App を入れていない組織のリポジトリが出てきます。漏れていますか？

A. 公開リポジトリなら心配ありません。GitHub App で連携すると、クラウドセッションはすべての公開リポジトリを使えるので候補に出ます。非公開リポジトリは、App を入れたものしか使えません。

Q. 環境変数に API キーを入れても大丈夫ですか？

A. おすすめしません。公式ドキュメントは、環境を使う人なら誰でも環境変数を読めるとして、秘密の値を入れないよう警告しています。Pro・Max なら、セッションが中身を読めない「API credentials」に登録する方法があります。

Q. 「Accept edits」にしたのに、コマンドのたびに止まります。

A. 仕様です。クラウドでは編集がどのモードでも許可されているため、通常のモードが「Accept edits」という名前で出ています。コマンドを承認なしで進めたいなら Auto を選びます（組織が許可し、モデルが対応しているときだけ表示されます）。

Q. 期間限定のクレジットは、この使い方にも使えますか？

A. 使えます。Pro・Max 向けのクレジット（Pro $100・Max $250）はクラウドセッションの利用に自動で使われ、残っている間はプランの利用上限に数えられません。受け取りは米国太平洋時間の10月7日まで、失効は11月4日の終わり（日本時間11月5日16時59分）です。Projects・Routines・Remote Control などには使えません。詳しくは公式のサポート記事と「Claude Codeのクラウドセッションとは」を参照してください。

出典

公式の仕様はいずれも2026年10月4日に原文を確認しました。設定の記録は筆者の1回・1つのプロジェクトでのもので、画面の表示は版や時期によって変わることがあります。