クラウド実行を始める手順 — GitHub接続から最初のタスクまで

前章では、ローカルとクラウドをどう選ぶかという判断軸を扱いました。この章は、その先です。クラウドを選んだとして、実際どこから手を付けるのかを、通しの手順として書きます。

学習者

4軸で選べというのは分かったけど、そもそも最初に何をすればいいの？

判断の話ではなく操作の話なので、画面の名前やコマンドが出てきます。UIは変わりうるので、変わっても効く部分（なぜその順序なのか）を一緒に書きます。

全体は5ステップ

3と4が本番です。1・2・5は画面の指示に従えば終わります。

1. GitHubを接続する

クラウドのVMは、あなたのリポジトリをクローンし、作業ブランチへpushします。そのための接続経路は2つあります。

2. 実行環境を作る

環境とは、ネットワークの範囲・環境変数・起動時スクリプトをまとめた設定です。セッションは必ずどれかの環境で動きます。

ネットワークは4段階から選びます。

既定の Trusted で npm install は通ります。ただし、ここに落とし穴があります。

リンク切れ検査のように「任意のドメインに対して疎通を確認する」種類のタスクをクラウドに投げたいなら、Full か Custom を選ぶ必要があります。ここを既定のまま投げると、原因の分かりにくい失敗になります。

3. 依存インストールの置き場所を決める

ここが最初の関門です。環境設定にはセットアップスクリプトという欄があるので、そこに npm ci と書きたくなります。書くと、セッションが起動せずに落ちます。

npm error code EUSAGE
npm error The `npm ci` command can only install with an existing package-lock.json
npm error or npm-shrinkwrap.json with lockfileVersion >= 1.

package-lock.json はリポジトリにコミットされているのに、見つからないと言われます。理由は役割の違いです。

セットアップスクリプトの結果は環境単位でキャッシュされて使い回されます。つまり特定のリポジトリの中身に依存する処理は、そもそも置き場所として合っていません。公式も役割をこう分けています。

正しい書き方はこうです。リポジトリの .claude/settings.json に、こう置きます。

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

そして scripts/install_pkgs.sh を用意します。

#!/bin/bash
# クラウドセッションのときだけ依存を入れる。
# ローカルでは CLAUDE_CODE_REMOTE が true にならないので、何もせず終了する。
if [ "$CLAUDE_CODE_REMOTE" != "true" ]; then
  exit 0
fi
 
cd "$CLAUDE_PROJECT_DIR" || exit 0
 
# resume のたびに走るので、すでに入っていれば何もしない
if [ -d node_modules ]; then
  exit 0
fi
 
npm ci
exit 0

末尾を exit 0 で終えているのは、インストールに失敗してもセッションの開始自体は妨げないためです。フックが非ゼロで終わると、起動が止まります。

4. pushしてからタスクを投げる

前章で書いたとおり、クラウドが見るのはリモートのブランチです。手元でコミットしただけ、編集しただけの変更は届きません。

先生

投げる前に git status と git log origin/main..main を見る。これを習慣にするだけで、事故がほとんど消えるよ。

タスクを投げるときに指定するのは3つです。

権限モードは、隔離されたVMであることを踏まえて緩めて構いません。ここは前章の「隔離されているから緩められる」がそのまま当てはまります。

最初の1本は、正解がリポジトリの中にあるタスクを選ぶと学習効率が高くなります。仕様の判断が要るタスクだと、結果が良くなかったときに、指示が悪いのか環境が悪いのか切り分けられません。

5. 結果を受け取る

セッションは、追加・削除の行数付きで差分を表示します。差分の行にコメントを付けて、次のメッセージと一緒に送り返すこともできます。

受け取り方は3つあります。

引き寄せるには、手元に未コミットの変更がないこと、同じリポジトリのチェックアウトであること、クラウド側のブランチがpush済みであることが要ります。

スマホから使う

同じセッションはスマホのClaudeアプリからも操作できます。設定はアカウントに紐づくので、接続や環境の作成をやり直す必要はありません。

アプリの Code タブから、リポジトリとブランチを選んでタスクを送ります。1つだけ制約があります。

なお同じCodeタブには、自分のマシンで動いているセッションをスマホから操作する機能（Remote Control）も並んでいます。こちらはマシンを起動したままにする必要があるので、クラウド実行とは別物です。「デバイスを追加」と出てきたらそちらの機能で、クラウドには不要です。

よくあるハマりどころ

npm install をセットアップスクリプトに置く。 置き場所はリポジトリ側のSessionStartフックです。

環境を作り直して同名が並ぶ。 削除できないので、名前を変えて区別します。

Trusted のまま外部への疎通を伴うタスクを投げる。 許可リスト外には届きません。

pushを忘れる。 前章の再掲ですが、実際に最も多い失敗です。

Remote Controlと混同する。 マシンを閉じてよいのはクラウド実行のほうです。

ちゃんと使うためのポイント

• 接続はGitHub Appの認可か /web-setup。CLIが無ければ前者
• 環境は削除できない。名前を付けて区別する
• 既定の Trusted はパッケージレジストリには届くが、任意の外部URLには届かない
• 依存のインストールはリポジトリの SessionStartフックへ。セットアップスクリプトはVMを用意する側
• フックは CLAUDE_CODE_REMOTE で分岐し、末尾を exit 0 で終える
• 投げる前にpushされているかを確認する
• 最初の1本は正解がリポジトリの中にあるタスクから

次の章では、ここで「緩めてよい」と書いた権限そのものを扱います。どこまで省いてよいかは、環境の隔離と対で決まります。

参考リンク

• Use Claude Code on the web（公式） — GitHub接続の2経路、権限モード、差分レビュー、teleportの条件
• Configure cloud environments（公式） — ネットワークの4レベル、環境のアーカイブ、セットアップスクリプトとSessionStartフックの使い分け
• Claude Code on mobile（公式） — Codeタブ、スマホで選べる権限モード、Remote Controlとの違い