ふだんPCの端末（ターミナル）で Claude Code を実行していると、作業フロー全体が手元のノートPCに深く縛られます。同じリポジトリに対して同時に2つのセッションを開くとローカルファイルが互いに競合して乱れやすく、テストサーバーも同一のネットワークポート（例えばどちらも3000番ポートを占有しようとするなど）を取り合ってエラーになります。セッションはローカルマシンのSSHキーやクラウドのログイン認証情報と同じ環境に同居しており、PCがスリープするとタスクの進行が止まり、ネットワークが切断されるとモデル呼び出しやリモートサービスを伴うステップが遮断されます。

Claude Code のクラウドセッション（Cloud Sessions）は、タスクをクラウド環境へ移行して実行します。タスクを送信すると、システムがクラウド上に新しい独立した仮想マシン（VM：クラウド上に割り当てられた仮想コンピューターであり、タスク同士が互いに干渉しません）を一時的に起動し、専用の新規ブランチにコードリポジトリをクローンして全自動で作業を進めます。停止ポイントに達すると、変更を含んだリモートブランチをプッシュし、その変更群を Pull Request（PR：チームでコードをレビューしてマージするためのプルリクエスト）へと変換できます。

この機能は Pro、Max、Team、および Premium または Chat + Claude Code シートが割り当てられた Enterprise の有料プランに含まれており、追加のクラウドコンピューティング費用は不要です。タスクは現在のアカウントの利用枠に直接計上されます。

クイック判断：どのタスクをクラウドに任せ、どれをローカルに残すべきか？

クラウドセッションはローカル端末を完全に置き換えるものではありません。両者の対応範囲を理解しておくことで、日々の開発においてタスクを適切に振り分けることができます。

以下の場合はローカル実行を推奨

• プライベートデータと特定ネットワーク：ローカルの Docker 内にのみ保持されているテスト用データベースの読み取りが必要なタスク、あるいは社内専用の VPN に接続しなければアクセスできないサービスに依存するタスク。
• 物理ハードウェアへの依存：ローカルPCの物理GPU、外付けハードウェア開発ボードの呼び出しが必要な場合、またはローカルで動作するモバイルエミュレータに依存する場合。
• フロントエンドの高頻度なビジュアルデバッグ：スタイルを1行修正してローカルブラウザで即座に視覚的フィードバックを確認したいインタラクションの微調整。
• 厳格なコンプライアンス制限：企業で「データ保持ゼロ」ポリシー（Zero Data Retention、ZDR：このポリシーが有効な場合、クラウドセッション機能は自動的に無効化されます）が有効になっている場合。

ローカル環境を利用しつつ作業席を離れたい場合は、リモートコントロール（Remote Control：計算は手元のPCで実行し、スマートフォンやブラウザからは指示出しと進捗確認のみを行う）を利用できます。また、Team または Enterprise プランの企業であれば、セルフホスト環境（Self-hosted Environments：商用プラン向けに提供されているベータ機能で、企業自前のインフラ上でセッションを実行する）の導入も検討できます。これらの制約がなければ、クラウドへ直接任せることで手元のPCリソースを大幅に開放できます。

ステップ1：ブラウザで GitHub リポジトリの接続を確立する

クラウド上でプライベートコードを取得するにあたり、重要な前提となるのは独立した2種類の GitHub 権限を整理しておくことです。

1. GitHub アカウントで Claude にログインする：システムに対して「あなたがどのユーザーであるか」を認証するものであり、公開オープンソースリポジトリを取得するための基本的な身元情報のみを持ちます。
2. Claude GitHub App をインストールする：Claude に対し「どのプライベートリポジトリを読み書きする権限があるか」を明示的に付与し、その後の自動修正やイベント通知を連携させます。

4つの接続方式はいずれも公開リポジトリを読み取ることができますが、プライベートリポジトリと自動連携の違いは以下のとおりです。

ここでの自動連携とは、Auto-fix、GitHub イベントトリガー、および Projects を指します。通常の定期実行 Routine は、App のインストールを一律の前提とはしていません。

ルートA：ブラウザのGUI接続（初めて利用する場合の推奨手順）

モダンブラウザのみで全工程を完了でき、手元に Node.js、Git、CLI ツールなどをインストールする必要はありません。

事前のアカウント・権限要件：

• 有効なアカウントとシート：クラウドセッションの利用には、有料プランを契約した claude.ai アカウント（Pro、Max、Team、または Premium や Chat + Claude Code シートが割り当てられた Enterprise）が必要です。Anthropic Console から発行した単体の API Key や、サードパーティのクラウドプロバイダー（AWS Bedrock、Google Cloud Vertex AI など）経由ではクラウドセッションを利用できません。
• 企業の管理者設定：Team または Enterprise プランの場合、組織のオーナー（Owner）が管理画面であらかじめ2つの機能を有効にしておく必要があります。claude.ai/admin-settings/connectors で GitHub コネクタ（GitHub Connector）を有効化し、claude.ai/admin-settings/claude-code でクラウドセッション（Cloud sessions）の権限を有効化します。GitHub コネクタが有効になっていない場合、画面に「GitHub access is required for Claude Code cloud sessions」と表示されることがあります。

ブラウザ接続の4ステップ：

1. Claude アカウントへログイン：ブラウザで claude.ai/code を開き、上記の有効な有料プランを持つ claude.ai アカウントでログインします。GitHub が未連携の場合、自動的に接続フローへ誘導されます（公式接続ページの claude.ai/connect-github に直接アクセスすることも可能です）。
2. GitHub の個人アカウントを連携：画面中央の Connect to GitHub（GitHub に接続）ボタンをクリックすると、GitHub 公式の認可画面へ遷移します。個人の基本アカウントでログインを承認します：

3. Claude GitHub App のインストール：ログインが完了すると、Claude GitHub App のインストール画面へ誘導されます。個人アカウントまたは対象の組織を選択し、リポジトリのアクセス権限として All repositories（すべてのリポジトリ）または Only select repositories（選択したリポジトリのみ）を選択します：

4. 接続成功シグナルの確認：認可が完了すると、ページは自動的に claude.ai/code へ戻ります。接続が正常に完了したことを示す明確なシグナルは以下の2点です。
   • 入力欄の横にあるリポジトリセレクターで、認可されたプライベートリポジトリが正しく検索・選択できるようになっていること。
   • 入力欄の上にある環境セレクターで、デフォルトの Default 環境が選択可能な状態になっていること。

ブラウザ接続でつまずいた場合のトラブルシューティング

認可後にページが正常に戻らない場合や、リポジトリ一覧が空のままの場合は、以下の公式チェックポイントを確認してください。

• トラブル1：ドロップダウンリストにプライベートリポジトリが一切表示されない
  原因と対処法：そのリポジトリを所有するアカウントや組織に App がインストールされていないか、インストール時に対象リポジトリから漏れています。GitHub の個人または組織の Settings > Applications > Installed GitHub Apps に進み、Claude を見つけて対象リポジトリを認可リストに追加してください。
  
• トラブル2：「連携には組織の管理者（Owner）である必要があります」と表示される
  原因と対処法：組織でメンバーシップ保護や権限審査ポリシーが有効になっています。組織のオーナー（Owner）が GitHub App 設定を開いて権限リクエストを承認し、管理画面でインストール済み App に対して「IP allow list inheritance（IP許可リストの継承）」を有効化するか、SAML シングルサインオン設定で Claude へのアクセス権を明示的に付与する必要があります。Team または Enterprise プランの場合、オーナーはあらかじめ claude.ai/admin-settings/connectors で GitHub コネクタを有効化しておく必要もあります。
  
• トラブル3：認可に成功したあと、組織配下のコードリポジトリが突然すべて消えてしまう
  原因と対処法：組織で SAML シングルサインオン（SSO）が有効化されており、GitHub 認可ポップアップの「Single sign-on to your organizations」一覧のステップをスキップしてしまった可能性があります。GitHub の個人設定にある Applications > Authorized OAuth Apps を開き、Claude を探して所属組織の横にある Authorize をクリックして再認可し、再ログインしてください。
• トラブル4：セッション全体で一律に「Authentication Error」が発生する
  原因と対処法：企業が Claude コンソール側でアクセス元 IP アドレスのホワイトリストを設定している可能性があります。Anthropic のクラウドインフラストラクチャのサービス IP をホワイトリストの免除リストに追加するよう管理者に依頼してください。

付録：CLI のローカル初回インストール（任意：端末操作に慣れている開発者向け）

ローカルのコマンドラインツールを使って認証情報を同期したりタスクを発行したりする場合は、まずシステムの端末で公式インストーラーを実行します（Web版のみを使用する読者は本節を読み飛ばして構いません）：

• macOS、Linux、WSL：

  curl -fsSL https://claude.ai/install.sh | bash
  

• Windows PowerShell：

  irm https://claude.ai/install.ps1 | iex
  

インストール完了後、新しい端末ウィンドウを開いて claude --version を実行します。バージョン番号が正しく出力されれば、インストールが完了し PATH 環境変数が適用されています。
シェル環境の注意：Windows ユーザーは必ず PowerShell ウィンドウで実行してください。'irm' is not recognized と表示される場合は、旧来のコマンドプロンプト（CMD）で実行している可能性があります。

ルートB：端末から既存の gh 認証情報を同期（CLI に慣れた開発者向け）

手元の環境に GitHub 公式 CLI ツール gh が設定済みであれば、端末から手早く認証情報を同期できます。システムの端末コマンドと Claude 対話セッション内のスラッシュコマンドの違いに注意してください：

1. システムの端末で、GitHub にログイン済みであることを確認します：

   gh auth login
   

2. システムの端末で claude と入力し、Claude Code の対話セッションを起動します：

   claude
   

3. Claude Code のプロンプトで、ログイン認証情報を確認します：
   • 未ログインの場合は、スラッシュコマンドを入力してログインします：

     /login
     

   • /status を入力して状態を確認し、Login method が claude.ai のサブスクリプションアカウントとして明示されていることを確認します（API Key によるログインではクラウド機能を利用できません）。
4. Claude Code のプロンプト内で認証情報同期コマンドを入力します（Team/Enterprise ではオーナーが事前に管理画面で Quick setup を有効にしておく必要があります）：

   /web-setup
   

5. 認証情報アップロードの明示的な確認：Claude Code は gh auth token を呼び出してローカルの Token を読み取り、端末上に確認プロンプトを表示します（この Token を Claude アカウントへアップロードして紐付けるかどうかを明示的に確認するものであり、バックグラウンドで無断実行されることはありません）。
6. 同意すると、Token が暗号化転送されてクラウドのアカウントに紐付けられます。端末に Connected as <あなたのGitHubユーザー名> と表示され、ブラウザで claude.ai/code が自動的に開きます。
7. ワークフロー権限不足のトラブルシューティング：端末に workflow scope が不足している警告が表示された場合は、一旦システムの端末に戻って次を実行します：

   gh auth refresh -s workflow
   

   権限を追加したあと、再度 Claude Code に入り直して /web-setup を実行し、Token を再アップロードする必要があります。これを行わないと権限の変更が反映されません。
8. 連携解除時の影響：のちに claude.ai/customize/connectors から GitHub 連携を削除した場合、削除されるのは Anthropic クラウド側に保存された認証情報のみであり、ローカルPC上の gh のログイン状態が自動的にログアウトされたり無効化されたりすることは一切ありません。Token を完全に失効させたい場合は、GitHub の個人設定にある Applications > Authorized OAuth Apps から GitHub CLI の認可を取り消す必要があります。

ルートC：リモートリポジトリがない場合の一括パッケージ送信（Bundle）

まだ GitHub にプッシュしていないローカルの新規プロジェクトや、App が未導入のリポジトリでは、ローカル端末で以下を実行します：

claude --cloud "タスクの説明"

システムがローカルコードを自動でアーカイブ（Bundle）し、クラウドの仮想マシンへアップロードします。リモートリポジトリは存在するものの、強制的にローカルアーカイブ方式で実行したい場合は、Bash/Zsh で環境変数を明示して実行できます：

CCR_FORCE_BUNDLE=1 claude --cloud "タスクの説明"

アーカイブ実行前の事前確認：

• ローカルが少なくとも1回以上の Git commit を含んだ有効な Git リポジトリであること。
• アーカイブの容量上限は 100MB です。超過した場合は現在のブランチのみ、あるいは単一の圧縮スナップショットへと縮小されますが、それでも上限を超える場合はアップロードが拒否されます。
• 未追跡ファイル（Untracked files）は一切アーカイブされません。実行前に必ず git add で必要なファイルをステージングエリアに追加してください。
• プラットフォームごとの機密ファイル処理の差異：macOS、Linux、WSL 環境では、Claude Code は機密ファイル（.env、*.tfvars、id_rsa、*.pem、および Git LFS 管理ファイル）の未コミットの変更を自動的に除外し、端末に Left on this machine: と表示します。クラウド側にはすでにコミット済みの履歴バージョンのみが反映されます。一方、Windows のネイティブ端末環境では、追跡対象ファイルの未コミットの変更がそのままアップロードされます。
• このモードで起動されたクラウドセッションは、のちに連携されたアカウントに対象リモートリポジトリへの書き込み権限がない場合、変更を GitHub へプッシュできず、GitLab や Bitbucket への直接プッシュにも対応していません。

ステップ2：クラウド環境とプロジェクト規約ファイルの設定

Default 環境には Node.js、Python、Go、Rust、Git、Docker などの一般的なツールがあらかじめインストールされており、Trusted ネットワークアクセスが適用されています。初回は Default をそのまま選択し、ステップ3のタスク送信へ進んで構いません。プロジェクトに独自のツール、依存関係、検証コマンドが必要になった段階で、以下の手順に従って Setup スクリプト、SessionStart フック、CLAUDE.md を設定します。

1. 環境セレクターの確認と Default 環境の作成

claude.ai/code の画面では、入力欄の上の行全体に現在バインドされている実行環境が表示されています（デフォルトでは雲アイコンの付いた Default ボタンが表示されます）：

• Pro および Max プラン：初回アクセス時に、システムによって Default という名前のデフォルト環境が自動生成されます。
• Team および Enterprise プラン：管理者がクイックセットアップを有効にしていない場合、初回アクセス時に「Create your first cloud environment」ダイアログが表示されます。デフォルトの Default という名称と Trusted ネットワークアクセスを維持したまま、Create & finish（作成して完了）をクリックすれば作成が完了します。

プロジェクトで特殊なシステムツール、環境変数、特定のネットワークアクセスが必要な場合は、このアイコンをクリックし、メニューから Cloud を選択して Add cloud environment（クラウド環境を追加）をクリックして新規作成するか、既存の環境の右側にカーソルを合わせて歯車アイコンをクリックして編集します：

2. 環境設定の主要プロパティと保存・確認

環境の新規作成または編集時には、以下のパラメータを設定して保存します。

• 環境名（Name）：tidepool-env など、判別しやすい名前を入力します。
• ネットワークアクセスレベル（Network access）：
  • Trusted（デフォルト推奨）：主要なパッケージマネージャー（npm、PyPI、RubyGems、crates.io など）、GitHub ドメイン、主要なクラウドサービス SDK へのアクセスを許可します。
  • None（最も厳格なネットワーク分離）：セッションからの通常の外部送信リクエストをすべて遮断します。ただし注意点として、仮想マシンと Anthropic API 間のモデル呼び出し通信、および作業ブランチ自体への Git プッシュ経路は引き続き許可されます。したがって、None は物理的な完全オフラインを意味するわけではありません。
  • Custom：ドメインのホワイトリストを1行ずつ指定できます（*.internal.example.com などのワイルドカードに対応）。変更後は約1分で現在のセッションに同期・反映されます。
  • Full：外部ネットワークへの全面的なアクセスを許可します。
• 環境変数（Environment Variables）：.env のプレーンテキスト形式で記述します（例：LOG_LEVEL=debug）。注意点として、この環境を使用する権限を持つすべての共同作業者が平文で閲覧できるため、プライベートな秘密鍵をここに直接貼り付けてはいけません。
• API 認証情報管理（API Credentials：Pro および Max 専用）：サードパーティの非公開 API を呼び出す必要がある場合、環境を保存したあとで編集ダイアログを再度開きます。下部の API credentials エリアにある Add credential（認証情報を追加）をクリックすることで、クラウドのプロキシ層が指定ドメイン宛てのリクエストヘッダー（Bearer Token など）を動的に注入します。秘密情報は仮想マシンの外部に保持されるため、仮想マシン内の端末、環境変数、コードから直接覗き見ることはできません。
• 保存と反映の確認：新規作成時は Create environment（環境を作成）、既存環境の変更時は Save changes（変更を保存）をクリックします。保存後、メイン画面の入力欄上部にある雲アイコンの右側の名前を確認し、作成した環境名に切り替わっていることを確認します。

3. システムレベルの Setup スクリプトとリポジトリレベルの SessionStart フックの使い分け

環境設定の要点は、「仮想マシンのOS層」と「リポジトリのコード依存関係層」を明確に区別することです。

手順A：仮想マシンの Setup スクリプトを記述（必要に応じたシステムツールの導入）

プロジェクトがシステムレベルの CLI ツール（shellcheck など）に依存している場合、環境設定ダイアログの Setup script 欄に純粋な Bash スクリプトを入力します（ローカルファイルではなく、クラウド環境側に直接保存されます）。インストール失敗時に即座に中断するよう set -e を付与し、終了コードは必ず 0 にする必要があります。スクリプトが約5分以内に正常完了すると、システムはそのファイル状態をスナップショットとしてキャッシュします。以降の新規セッションはこのツール導入済みスナップショットから起動します。スクリプトや許可ホストを変更した場合、または約7日が経過して有効期限が切れた場合にキャッシュが再構築されます。

#!/bin/bash
set -e

# プロジェクトのビルドに必要な Linux システムツールを必要に応じてインストール（ここでは shellcheck の例であり、必須ではありません）
apt-get update
apt-get install -y shellcheck

仮想マシンのディスクスナップショットはファイルのみをキャッシュし、実行中のメモリプロセスは一切保存しません。そのため、service postgresql start や service redis-server start などのバックグラウンドデータベースサービスは、Setup スクリプトに記述しても新規セッション起動時には停止状態となります。これらはセッションフック側で起動するか、Agent 自身に起動させる必要があります。

手順B：リポジトリレベルの SessionStart フックを記述（Node.js プロジェクトの例）

プロジェクトのコードレベルの依存関係（npm install など）は、ローカルリポジトリ側の設定として固定化します。リポジトリのルートに .claude/settings.json を作成または編集します。

マージルール：リポジトリにすでに .claude/settings.json が存在する場合、ファイル全体やキー全体を上書きしてはいけません！既存の設定内にすでに "hooks" キーがある場合は、既存の "hooks" オブジェクト内に SessionStart の配列項目を追加マージするか、他のフックイベントと統合し、チーム既存の権限ルールやその他の設定を失わないようにしてください。

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

続いて、リポジトリ内に対応するスクリプト scripts/install_pkgs.sh を作成します。以下のスクリプトは Node.js プロジェクト向けです。ローカルセッションを起動するたびに不要なパッケージ再インストールが走るのを防ぐため、CLAUDE_CODE_REMOTE 環境変数を判定してクラウドコンテナを識別し、エラーが見過ごされないよう set -e を付与しています。

#!/bin/bash
set -e

# クラウド仮想マシン環境でない場合はそのまま正常終了し、ローカル開発に影響を与えない
if [ "$CLAUDE_CODE_REMOTE" != "true" ]; then
  exit 0
fi

# プロジェクトルートに移動し、Node プロジェクトの依存関係をインストール
cd "$CLAUDE_PROJECT_DIR"
npm install

手順C：プロジェクト規約を CLAUDE.md に固定化

開発者のローカルPCにある ~/.claude 設定はクラウドへアップロードされないため、チームがクラウド上でも適用したいプロジェクト指示はリポジトリ内に記述する必要があります。プロジェクトのルートディレクトリに CLAUDE.md を作成してコミットします。

コマンド確認の注意：本文中の npm start、npm test、npm run lint は Node.js プロジェクトの例です。記述する前に必ずローカルの package.json 内の scripts フィールドを確認してください。プロジェクトに lint スクリプトがない場合は対応する行を削除してください。開発サーバーが3000番ポートをリッスンしていない場合は実際のポートに合わせて調整し、すべてのプロジェクトに lint が用意されている、あるいは3000番ポートを使用していると決めつけないようにしてください。

# プロジェクト開発および検証規約

## よく使うコマンド
- 依存関係のインストール：`npm install`
- サービスの起動：`npm start`（package.json を確認し、実際のポートに合わせて調整）
- テストの実行：`npm test`（package.json の実際のテストコマンドを確認）
- コードチェック：`npm run lint`（package.json にスクリプトがない場合は削除）

## 検収およびコミットフロー
1. コードを修正する際は必ず根本原因を特定し、エラー回避のためにテストのアサーションを直接書き換えることを禁止します。
2. ロジックの修正が完了するたびに、関連する自動テストコマンドを実行してすべてのテストがパスすることを確認してください。
3. コミットメッセージの規約：`fix:`、`feat:`、`docs:`、`refactor:` などのセマンティックプレフィックスを採用してください。

手順D：ローカルの3ファイルをコミットして有効化を確認

上記3つのファイル（.claude/settings.json、scripts/install_pkgs.sh、CLAUDE.md）はいずれもローカルリポジトリのファイルです。ローカル端末でこれらをコミットし、リモートリポジトリへプッシュします：

git add .claude/settings.json scripts/install_pkgs.sh CLAUDE.md
git commit -m "build: 配置云端环境安装钩子与项目规范"
git push

確認可能な検証シグナル：

1. git status を実行して未コミットの変更がないことを確認し、ブランチがリモートと同期していることを確認します。
2. 次に claude.ai/code で簡単なクラウド新規セッションを開始し、セッション初期化ログや準備ステップにおいて、SessionStart フックがトリガーされて npm install が正常終了したことを確認します。さらに Agent に CLAUDE.md に従ってテストを実行させ、実際の出力を報告させます。

ステップ3：タスクを送信し、変更範囲と検証方法を明記する

1. Web画面で最初のタスクを送信する

1. ブラウザで claude.ai/code を開き、権限が付与されたアカウントでログインします。
2. 入力欄の横にあるリポジトリセレクター（Select repo ボタン）をクリックして認可済みの対象コードリポジトリを選択し、リポジトリ名の横にあるブランチセレクター（Branch）をクリックして作業開始の基準となるブランチを決定します（デフォルトは default ブランチ、特定の feature ブランチに切り替えることも可能）。
3. 入力欄の横にある権限承認モード（Permission Mode ドロップダウン）を確認します：
   • Auto：分類器が Agent の操作を審査します。表示されるかどうかは組織の設定と選択したモデルに依存します。
   • Accept edits：ファイルの変更やブランチのプッシュを段階的な確認なしで全自動で進行します。
   • Plan：分析と計画案の出力のみを行い、計画を承認するボタンをクリックするまで実際のファイル変更は行いません。
   • （注：クラウドセッションでは、コマンドを1つずつ確認する Manual モードや、制限を完全に解除する Bypass モードは提供されていません。）
4. タスク指示を入力し、Enter キーを押して送信します。送信後はブラウザを閉じたりスマートフォンの画面をオフにしたりしても、仮想マシンはバックグラウンドで稼働し続けます。

初回は、「送信 → 結果確認 → Diff確認」の流れを把握するために、小さめのタスクから送信することをおすすめします：

README のインストールとテストに関する説明が、リポジトリの現在のコードと一致しているか確認してください。
まず package.json と関連スクリプトを読み込み、実際に存在するインストールコマンドやテストコマンドを実行してください。
ドキュメントの不一致のみを修正し、業務コードは変更しないでください。
チェックした項目、実際に実行したコマンドとその出力、検証できなかった部分を報告してください。
完了したらコミットし、Diff を確認できるよう本セッションの作業ブランチへプッシュしてください。

パラメータ付きの URL を使用して新規セッションの入力内容を事前入力しておくことも可能です（日本語や特殊文字のパースエラーを防ぐため、すべてのパラメータ値は標準的な URL エンコードを行う必要があります）。ブックマークやチケット管理システムとの連携に便利です：

https://claude.ai/code?prompt=Fix%20flaky%20auth%20tests&repositories=acme-labs%2Ftidepool&environment=Default

2. 端末から claude --cloud で新規タスクを発行する一連の操作

端末からのタスク発行を好む場合は、CLI から直接クラウドセッションを割り当てることができます：

1. プロジェクトディレクトリへ移動：システムの端末で cd /path/to/your-repo を実行してプロジェクトのルートディレクトリに移動します。
2. リモートと作業ディレクトリの状態確認：git status を実行して作業ディレクトリがクリーンであることを確認し、git remote -v を実行して正しい GitHub リモートリポジトリが設定されていることを確認します。
3. ローカルのコミットは事前にプッシュ必須：クラウドの仮想マシンは GitHub のリモートから現在のブランチのコードを直接クローンするため、ローカルの未プッシュ（unpushed）なコミットはクラウド側には一切反映されません！そのため、発行前に必ず git push を実行してください（リモートリポジトリのないローカル新規プロジェクトの場合は、前述のルートCのアーカイブ方式を使用します）。
4. クラウドタスクの発行：端末で以下を実行します：

   claude --cloud "タスクの説明と実行可能な検証コマンド"
   

5. 専用 Web URL の取得：コマンドを発行すると、CLI が端末上に仮想マシンの起動チェックリスト（コードのクローン、Setup スクリプトの実行など）を表示します。準備が整うと、そのタスク専用の Web セッション URL（例：https://claude.ai/code/session_01ABC...）が出力されます。クリックしてブラウザで開くか、スマートフォンの Claude アプリからいつでも進捗を追跡できます。

3. そのまま使えるタスク指示テンプレート

クラウドにタスクを発行する際は、タスクの目的と完了条件をあわせて伝えます。背景となる事象を説明し、修正範囲を限定し、完了度を検証するための実行可能な検証コマンドを明記します。

サンプル置き換えの注意：テンプレート内の auth.spec.ts はファイル名の例です。必ずプロジェクトの実際の対象ファイルと症状に合わせて置き換えてください。クラウドセッションを初めて試す場合は、「README のデプロイ手順を更新してリンクを検証する」といったリスクの極めて低い小タスクを選ぶことも推奨されます。テンプレート内の業務ファイル名をそのままコピーして使用しないでください。

以下の実行可能な作業指示テンプレートをコピーして適宜置き換えて使用できます：

【タスクの目的】
認証モジュールのテスト（例：auth.spec.ts）において、間欠的に失敗する不安定なテスト（Flaky test）を修正してください。

【技術要件と調査指針】
1. まず package.json に記載された既存の test scripts、対象のテストファイル、および実装コードを確認してください。根本原因が並行処理の競合であると決めつけず、実際のコードロジックに基づいて分析してください。
2. エラーを隠蔽するためにテストのアサーションを改ざんしたり、テストケースを削除したりすることは固く禁じます。修正範囲を厳格に限定し、本問題に関係のない業務ファイルには一切手を加えないでください。
3. 既存の外部インターフェースおよび関数の引数・戻り値の後方互換性を維持してください。

【反復再検証の要件】
クラウドの Bash 端末で以下の統計ループコマンドを実行して再検証を行ってください（npm test は package.json の実際のテストコマンドに置き換えてください）：
fails=0; for i in $(seq 1 30); do npm test >/dev/null 2>&1 || fails=$((fails+1)); done; echo "runs=30 fails=$fails"
連続 30 回の実行で失敗回数が 0 であることを必須とします。依然として失敗がある場合は、失敗原因と不合格項目をありのまま報告してください。30 回失敗ゼロは「その検証サイクル内では問題が再現しなかった」ことを示すものであり、「すべての潜在リスクを完全に根絶した」と誇大に主張しないでください。

【納品基準】
- 実際に特定した問題の原因と、修正したファイル一覧を報告すること。
- 実行した再検証コマンドおよび端末の出力結果（runs=30 fails=0 または具体的な不合格項目）を報告すること。
- git commit を自動完了し、claude/ 作業ブランチへプッシュすること。

4. セッション進行中の非同期な介入と追跡

• いつでも追加指示が可能：セッションがクラウドで実行されている最中でも、Web画面の入力欄からいつでも補足説明を追加できます。新しいメッセージはキューに自動で並びます。指示内容を間違えた場合は、キューから取り消すことも可能です。
• 端末からのリモート追記：同一アカウントでログインしたシステムの端末から、-p を使用してメッセージを追加できます。セッション ID は専用 URL の session_... 部分または端末出力から取得します：

  SESSION_ID="ここに実際のセッションIDを貼り付け"
  claude -p "ブランチを main に対してリベースし、コンフリクトを解消した上で再度テストを実行してください" --cloud "$SESSION_ID"
  

ステップ4：変更内容とテストを確認し、並行ブランチを処理する

セッション終了後は、実際に何が変更され、どのようなテストが実行されたかを確認した上で、マージするかどうかを判断します。完了の表示は「そのタスクが停止した」ことを意味しているに過ぎないため、テスト結果はログで個別に確認する必要があります。

Diff を開いて確認し、フィードバックをセッションへ送信する

claude.ai/code の Web画面で、以下の5つの手順に沿ってレビューと微調整を行います。

1. セッション概要を精読し、コマンドと不合格項目を照合する：
   • セッション状態が完了になっていることだけで判断してはいけません。まず Agent がセッション末尾に生成したテキスト概要を精読し、問題解決のために実際に実行された Bash コマンドを確認します。
   • 一部のテストが通過しなかった旨が率直に報告されていないかを重点的に確認します（後述の実験のように、ログタスクは自身のコード実装を完了したものの、テストスイート内にキャッシュテストの間欠的な失敗が残っていることを明記していました）。
2. 変更行数インジケーターをクリックして Diff ビューを開く：
   • 画面上部に現在のブランチの追加・削除行数の統計（例：+42 -18）が表示されます。このインジケーターをクリックすると、Diff コード比較ビューが開きます。
   • 左側が変更されたファイル一覧、右側がメインのコード比較ウィンドウです。パネル上部の Compare against（比較対象）をクリックすると、基準ブランチを切り替えることができます（デフォルトは現在の作業ブランチの分岐元、main ブランチへの切り替えも可能）。
3. ファイルごとに変更範囲を精査する：
   • ファイルを1つずつクリックし、各修正が指示された業務範囲内に厳格に収まっているかを確認します。
   • Agent が共通インターフェースの定義を勝手に改変していないか、無関係な設定やテストアサーションを変更していないかを確認します。
4. インラインコメントを記入し、メッセージと一緒に送信する：
   • Diff 画面で特定のコード行をクリックし、レビューフィードバックを直接入力します（例：src/cache.js:35 において、例外キャッチ後に map 内の pending な Promise を明示的に削除し、不正なエントリがキャッシュに残り続けないようにしてください）。Enter キーを押して確定します。
   • 重要な操作の仕組み：Enter キーを押した段階では、そのコメントはローカルのキューに一時保持されているだけで、まだ Agent には送信されていません！下部の対話入力欄に戻り、メインメッセージ（例：Diff ビュー上でキャッシュのクリーンアップに関するインラインコメントを記載しました。これに沿ってコードを修正し、再検証を実行してください）を入力して送信ボタンをクリックすることで、一時保持されていたすべてのインラインコメントがメインメッセージとともに一括して Agent へ送信されます。
5. Agent に再検証を実行させる：
   • Agent はコメントを受け取ると再度コードを修正し、クラウド上でテストコマンドを再実行します。完了後、二次レビューのためにブランチが再プッシュされます。

並行実験の分析：なぜ「Done 表示だけを見てはいけない」のか？

クラウドによる複数マシンの独立並行作業の価値と実際の境界線を示すため、Addy Osmani は教育用の架空プロジェクト tidepool（Node.js で書かれた潮汐予測 API のモック事例）を題材に、実際のセッションを並行実行しました。

これら4つのセッションは実際にクラウド上で実行されたものです。本文中のデモ画面は、セッション記録をローカルで再現したものになります。以下の所要時間にはサンプルリポジトリの再構築が含まれており、今回の小規模実験における実績値を示しています。

実際の検証では、著者は16秒の間に3つのタスクセッションを順次発行しました。

1. 間欠的なテストの修正：テストスイートが約4分の1の確率で落ちる問題の修正。
2. APIドキュメントの書き直し：コードの実装と乖離していた過去の API ドキュメントの修正。
3. 構造化ログへのリファクタリング：文字列連結によるログ出力を JSON 構造化出力へと刷新。

サンプルプロジェクトはプロンプトに含まれるファイルから各マシン上でリポジトリを再構築したため、準備工程に各マシンの総実行時間の3分の1から半分強が費やされました（正規の GitHub リポジトリ接続時は通常の clone 時間となります）。3台のマシンのそれぞれの稼働時間は 61秒、65秒、72秒 であり、最初のタスク発行を起点とすると、すべて 87秒 の時点で終了しました。

1. タスク1：間欠テストの修正とキャッシュ競合の書き直し

Agent はコードを精査し、キャッシュモジュールの TtlCache.get に競合状態（Race Condition）が存在することを発見しました：

• 古いコードの欠陥の仕組み：キャッシュが空の初期状態（Cold Cache）で最初のリクエストが到着し、非同期読み込みがトリガーされます。しかし、その読み込みが完了する前に、同一キーに対する2つ目の並行リクエストが到着します。古い実装では非同期読み込みが完全に完了して結果を取得した後にしかキャッシュ辞書にエントリを書き込まなかったため、2つ目の並行リクエストは進行中の読み込みにヒットできず、重複してデータ読み込みをトリガーしてしまいました。その結果、タイミングの乱れが生じ、テストケースが約4分の1の確率で失敗していました。
• コード修正の実装：Agent は、リクエスト発生と同時に pending 状態の Promise オブジェクトをキャッシュ辞書に直接保存する形に書き直しました。後から来た並行読み込みはこの共有 Promise の完了を直接待機するため、重複読み込みが回避されます。同時に失敗時のクリーンアップ処理も追加され、読み込みで例外が発生した場合は直ちに該当エントリをキャッシュから削除するようにしました。

修正後、Agent はクラウドの Bash 端末で統計ループテストコマンドを実行しました：

fails=0
for i in $(seq 1 40); do
  npm test >/dev/null 2>&1 || fails=$((fails+1))
done
echo "runs=40 fails=$fails"

（注：コマンドはクラウドの Bash で実行されたものです。npm test は実際の package.json のテストコマンドに置き換える必要があります。このコマンドは各テストの出力を null デバイスにリダイレクトし、失敗時にカウンタを加算します）

端末の出力には runs=40 fails=0 と表示され、40回連続で失敗ゼロでパスしました。このセッションでは修正前に以前の失敗を再現させる工程は行われておらず、40回失敗ゼロは修正後の反復検証結果です。

2. タスク2：APIドキュメントの更新と実測検証

ドキュメント担当の仮想マシンはバックグラウンドで API サーバープロセスを起動し、すべてのエンドポイントに対して curl で1つずつ実測を行いました。その結果、古いドキュメントに存在した5箇所の重大な乖離を特定しました：

• ドキュメントに記載されていたが、実際には /stations が返さない lat、lon フィールド。
• ドキュメントに記載されていた days パラメータがコード上ではとっくに無視されており、実際のフィルタパラメータは from と hours（デフォルト24時間）であったこと。
• メートル法による高さの単位「m」が誤って「ft（フィート）」と記載されていたこと。
• /next-high エンドポイントの記載が漏れていたこと。
• 400 および 404 のエラーレスポンスが記載されていなかったこと。

さらに Agent は、from や hours パラメータの形式が不正な場合、サーバーがエラーを返さず静かに HTTP 200 と空配列 [] を返す挙動も実測で突き止めました。Agent はタスク範囲外のビジネスロジックを勝手に変更することはせず、この仕様を「注意事項」としてドキュメントにありのまま追記しました。

3. タスク3：構造化ログと環境分離の代償

3台目のマシンは、ログ出力を method、path、status、duration_ms を含む JSON 形式へ変更し、ログモジュール向けに5つの単体テストを書き足しました。しかし、コードをコミットした際、テストスイート内に1件のエラーが残ったままでした。その後、Agent はキャッシュモジュールのテストを連続で8回再実行し、そのうち5回失敗したことから、1台目のマシンとまったく同じキャッシュ競合が原因であることを正確に特定しました。

しかし、各クラウド仮想マシンの環境は完全に独立して隔離されているため、1台目のマシンが並行してそのキャッシュ欠陥を修正中であることを知る術はありませんでした。また自身のタスク境界の制約から、権限を越えてキャッシュコードに手を加えることはせず、コミット報告においてテストスイートがまだ完全にはパスしていない事実をありのまま報告するにとどまりました。

並行セッション同士はお互いのコード変更を感知できません。クラウドにタスクを分散する際は、できる限りファイルやモジュールの境界に沿ってタスクを分割し、各ブランチを1つずつマージしたあとに、全体としての結合テストを再度実行して全体検証を行う必要があります。

ステップ5：ブランチのマージ、ローカルへの引き継ぎ、長期的な自動化

Diff ビューからの PR 作成と GitHub マージ検証のクローズドループ

コードの変更を確認し、テストに問題がないことを確認したら、クラウドからマージフローを開始できます：

1. Diff ビュー上部の Create PR をクリック： Web画面の Diff パネル右上にある Create PR（PR を作成）ボタンをクリックします。3種類のプルリクエスト形式から選択できます：
   • Full PR（正式なプルリクエスト）：GitHub 上に正式な PR を直接作成し、リポジトリに設定されたチェックとレビューのプロセスに入ります。
   • Draft PR（ドラフトプルリクエスト）：チームが事前に確認するための下書き PR を作成し、準備が整った段階でレビュー可能状態にします。
   • GitHub 作成画面（GitHub Compose）：GitHub 公式の PR 作成ページへ遷移します。実際のコード変更に基づいて Claude が生成したタイトルと詳細な説明が自動入力されており、手動で調整してから送信できます。
2. 重要な認識：PR 作成はコードのマージを意味しない： Claude の画面で Create PR をクリックすることは、claude/ ブランチを GitHub へプッシュしてプルリクエストを作成したことに過ぎません。コードのマージは必ず GitHub リポジトリ側で完了させる必要があります：
   • 対象 PR の GitHub ページを開き、CI（継続的インテグレーション）による自動チェック結果とチームメンバーのレビューコメントを確認します。
   • チームが設定したブランチ保護ルール（Branch protection rules）に従い、すべてのチェックを通過したことを確認してから Merge pull request をクリックします。
3. マージ後の対象ブランチに対するローカル最終再検証： コードが GitHub 上で対象のメインブランチ（main など）にマージされたら、ローカルPCの端末に戻り、最新のメインブランチのコードをプルして実際のテストコマンド（npm test など）を実行し、本番投入前の最終確認を行います。

Team および Enterprise のユーザーは、セッションの公開範囲を Team に設定して同僚に変更プロセスを共有することも可能です。クラウドからコミットされた際の Claude-Session 追記情報には、該当セッション記録へのリンクが含まれます。

シナリオ1：積み上がった細かいバックログ（Backlog）の並行消化

日々の開発で溜まりがちな API の微修正や境界テストの追加といった小さなタスクは、複数のセッションを同時に起動して一気に進めることができます。ローカルのポートや作業ディレクトリを取り合うことはありません。Pro や Max で提供されている Projects のパブリックベータを利用する場合、Projects では1日あたり最大200個の新規スレッドを起動でき、その作業もプランの利用枠を消費します。また、メインの調整用セッションを立ち上げ、これら複数のセッションの進捗状況を一元的にディスパッチ・追跡することも可能です。

シナリオ2：長時間のビルドと反復検証（Flaky Tests）

数百回繰り返すような大規模な結合テストや、間欠的な不具合の調査は、クラウドに任せて実行します。仮想マシンのフォアグラウンド実行コマンドはデフォルトで 2分 でタイムアウトします（環境変数 BASH_DEFAULT_TIMEOUT_MS および BASH_MAX_TIMEOUT_MS によりミリ秒単位で調整可能、最大10分）。タイムアウトした処理は自動的にバックグラウンドへ移され、最大30分間実行を継続します。

シナリオ3：Plan -> Cloud -> Teleport の連携クローズドループ

アーキテクチャのリファクタリングや大規模な移行作業では、ローカルとクラウドを連携させた引き継ぎ運用が推奨されます：

# 1. ローカル端末で計画モードを起動し、アプローチを検討する
claude --permission-mode plan

# 議論がまとまったら、計画を docs/migration-plan.md として保存し、コミットしてリモートへプッシュする

# 2. 重たい作業をクラウドへ発行し、手元のPCを他の作業に解放する
claude --cloud "docs/migration-plan.md に記載された移行計画を厳格に実行してください"

# 3. クラウド側で完了後、ローカル端末でブランチをプルして現場に引き継ぐ
claude --teleport            # クラウドセッションセレクターが開き、完了したタスクを選択

• 引き継ぎの入り口：
  • Web画面のセッションメニューから Open in > Terminal を選択して復帰コマンドをコピーします。
  • システムの端末で直接 claude --teleport を実行して対話型セレクターを開くか（session-id を推測したり手入力したりする必要はありません）、claude --teleport <session-id> を指定して復帰します。
  • ローカルの Claude 端末内で /teleport または /tp を入力してセレクターメニューを開きます（/tasks 一覧で t を押して接続することも可能です）。
• Teleport の実行前提：ローカル作業ディレクトリがクリーンであること（未コミットの変更がないこと。ある場合は stash を促されます）、同一リポジトリのチェックアウトディレクトリであること（fork リポジトリは不可）、リモートブランチがプッシュ済みであること、そして端末が同一の claude.ai アカウントでログインされていることが必要です。
• 重要な仕組み：Teleport はローカルでブランチをチェックアウトし、クラウドの対話履歴を読み込みます。ただし、ローカルに引き継いだあとに発生した新たな変更はローカルコピーにのみ属し、クラウドのWeb画面側へ自動で逆同期されることはありません。引き継ぎ後もスマートフォンから誘導を続けたい場合は、ローカルの Claude セッション内で /remote-control を起動します。

シナリオ4：スマートフォンからのフォローと複雑なコード診断

スマートフォンの Claude アプリの Code タブを開けば、いつでもクラウドタスクの状態を確認し、確認質問に返答できます。

スマートフォンセッションは、デスクを離れている間の深いコード分析にも適しています。著者の検証では、スマートフォンの画面から4つ目のセッションに対して tidepool の潮汐予測アルゴリズムとタイムウィンドウ境界の欠陥の診断を指示しました。Agent はその場でコードを実行してシミュレーションを行い、2つの潜在的なバグを特定しました：

1. 両端の極値の計算漏れ：アルゴリズムのループ処理が極大値・極小値を抽出する際、インデックスが中間部分（i=1 から length-2）しか走査していませんでした。そのため、満潮のピークがタイムウィンドウのちょうど先頭（例えばピークが 02:12Z にあり、ウィンドウがちょうど 02:12Z から始まる場合。ウィンドウの起点を1サンプリングステップ手前の 02:06Z に前倒しすると認識できる）に位置していると、プログラムはその満潮点を丸ごと見落としてしまいます。
2. 平坦部で先頭を取得することによる3分間のズレ：潮位をミリメートル単位で四捨五入すると、隣接する同一高さのサンプリング点によって平坦なプラトー（台地状の平坦部）が形成されます。現行のアルゴリズムはプラトーの中心ではなく先頭のサンプリング点を直接取得するため、タイムウィンドウの起点が3分ズレるだけで、同一の満潮点の報告時刻が 02:12 から 02:15 へとドリフトしてしまいます。さらにウィンドウの開始点がプラトーの途中にある場合も、極値そのものを見落とします。

Agent はさらに、データ内の隣接する同一高さサンプリング点の分布状況をリストアップしました：

• Gull Harbor 観測所：90/116
• Half Moon Bay 観測所：73/116
• Port Ellis 観測所：39/116

上記の3つの数値は隣接する同一高さサンプリング点のカウント数であり、予測の正解率ではありません。修正方針として、タイムウィンドウの両側にサンプリング点を1点ずつ追加して計算に参加させ、その後に結果を元のウィンドウ範囲にフィルタリングして戻す方法が提案されました。この診断ではコードの実行シミュレーションのみを行い、業務のソースファイルは変更していません。

シナリオ5：PR の自動巡回と自動修正（Auto-fix）

リポジトリに Claude GitHub App をインストールすると、Web画面のセッションにある CI ステータスバーから直接 Auto-fix スイッチをオンにできます。また、PR ブランチで Claude Code を起動したあとに内部コマンド /autofix-pr（システムのシェルコマンドではなく Claude の対話コマンド。CLI が gh を介して PR を検出し、クラウド側の監視を起動します）を入力するか、スマートフォンアプリや新規セッションから PR の監視を直接指示することも可能です。

CI ビルドでエラーが発生した場合や、同僚が PR にレビューコメントを投稿した場合、Claude はコンテキストを自動で取得して調査し、アクションを起こします：

• 確実性の高い修正：修正の意図が明確で確信がある場合、修正コミットを直接プッシュし、セッション内で変更理由を説明します。
• 曖昧な意見やアーキテクチャに関わる意見：レビューコメントに複数の解釈の余地がある場合や、重要なアーキテクチャの意思決定に関わる場合、Claude は独断で変更せず、事前に質問して確認を求めます。
• コメントの表示名と自動化への影響：GitHub のレビューディスカッションにおける Claude の返信は、連携しているあなたの GitHub アカウント名義で投稿されますが、Claude Code の識別表示が明確に付与されます。チームが Atlantis などのコメントをトリガーとするデプロイ自動化ツールを使用している場合、これらの返信によってパイプラインが起動する可能性があるため、有効化する前に権限の影響を評価しておく必要があります。
• マージコンフリクトへの対応：ターゲットブランチが更新されてマージコンフリクトが発生した場合、Claude は GitHub からの通知を自動で受信しません。セッション内で明示的に rebase 指示を出し、最新コードを取り込んで競合を解消させる必要があります。

シナリオ6：スケジュールおよびイベント駆動型の定期巡回（Routines）

定期タスク（Routines：現在リサーチプレビュー段階）は、プロンプト、コードリポジトリ、コネクタ（Connectors）、および実行環境をパッケージ化し、トリガーによって自律実行させることができます。

完全な設定手順

1. 新規タスクの作成：claude.ai/code/routines にアクセスし、New routine（新規ルーティン）をクリックします（ローカルの Claude Code セッション内で /schedule を使って作成することも可能です）。
2. 命名と指示の入力：タスク名（Name）を設定し、実行モデル（Model）を選択した上で、プロンプト（Prompt）に自己完結したタスク目標と完了基準を明記します。
3. リポジトリの選択（Repositories）：1つ以上の GitHub リポジトリを追加します。タスクはデフォルトブランチをチェックアウトし、claude/ プレフィックスの付いた新しいブランチに変更をコミットします。
4. 環境の選択（Environment）：ネットワークアクセスレベル（デフォルトの Trusted ホワイトリストなど）、環境変数、初期化 setup script を設定します。
5. 初回トリガーの設定（Trigger）：
   • スケジュール（Schedule）：毎時、毎日、平日、毎週の定期実行、または将来の単一の時点を指定できます。設定可能な最短間隔は1時間に1回です。スケジュールトリガーの利用にはリポジトリへの GitHub App のインストールは不要です。
   • イベント（GitHub event）：PR のオープン時やリリースの公開時にトリガーされます。GitHub event トリガーを利用する場合にのみ、Claude GitHub App のインストールが必須となります。
6. コネクタの厳選（Connectors）：デフォルトのフォームでは、接続済みのすべての MCP コネクタが自動選択されています。Routine はシェルコマンドの実行やコネクタの呼び出しを自律的に行い、一部の Artifact 操作を除き通常は人間の承認を待たないため、無関係なコネクタのチェックを外し、書き込み権限や外部呼び出しのリスクを絞り込んでください。
7. 保存と即時テスト：Create（作成）をクリックしてタスクを保存します。その後、詳細ページで Run now（今すぐ実行）をクリックして即時テストを実行できます。
8. セッションを開いて結果を検証：実行一覧で対応するクラウドセッションをクリックして開き、実行された具体的なコマンド、出力ログ、生成されたブランチを確認します。特に注意すべき点として、実行一覧で緑色（成功）と表示されているのは、インフラの起動と終了にエラーがなかったことのみを示しており、プロンプトで設定した業務目標の達成を保証するものではありません。必ずセッションを開いて実際の実行結果を確認してください。

コピーして使える巡回用 Prompt の例

リポジトリのメインブランチに最近マージされたコミットを確認し、単体テストとコードスタイルチェックを実行してください。テストの失敗や設定エラーが見つかった場合は根本原因を分析して修正コードを記述し、テストを実行して完全にパスすることを確認した上で claude/ ブランチにプッシュし、変更内容の要約を出力してください。

外部からの API トリガー設定

Routine を保存したあと、専用の HTTP インターフェースを有効化して外部のアラートやリリースパイプラインと連携させることができます：

1. claude.ai/code/routines を開いて対象タスクをクリックし、名前の横のメニューから Edit（編集）を選択します。
2. トリガー設定エリアまでスクロールし、Add another trigger（別のトリガーを追加）をクリックして API を選択します。
3. プラットフォームが生成した専用の Webhook URL をコピーし、Generate token（トークンを生成）をクリックして認証トークンを発行します（Token はダイアログ内で一度しか表示されず、閉じた後は再確認できないため、直ちにコピーしてシークレット管理システムに保存してください）。
4. プラットフォームが提示するサンプルの curl コマンドをコピーします。外部呼び出しは POST メソッドを使用し、リクエストヘッダーに Authorization: Bearer <token> を付加します。リクエストボディには動的な実行コンテキスト（アラート詳細やエラーログなど）を含む JSON を渡すことができます：

   ROUTINE_URL="プラットフォームに表示された専用URLを貼り付け"
   # 呼び出し側のシステムの Secret に ROUTINE_TOKEN を設定し、本物のトークンをコードリポジトリに書き込まないこと
   curl -X POST "$ROUTINE_URL" \
     -H "Authorization: Bearer $ROUTINE_TOKEN" \
     -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
     -H "anthropic-version: 2023-06-01" \
     -H "Content-Type: application/json" \
     -d '{"text": "监控报警触发，附带排查上下文"}'
   

5. 呼び出しが成功すると、API は claude_code_session_id と claude_code_session_url を含むセッション URL を返します。そのリンクをクリックすることでブラウザからリアルタイムに実行状況を追跡できます。

利用枠と独立したレート制限

Routine の実行は契約プランの日常的な利用枠に直接計上され、リアルタイムの消費状況は claude.ai/settings/usage で確認できます。これに加えて、定期実行、手動実行、API トリガーのそれぞれに1時間あたりの独立した頻度上限（レートリミット）が設けられており、実行頻度はこれらの制限も受けます。詳細は公式の利用量と制限事項を参照してください。

シナリオ7：信頼できないサードパーティ製コードのサンドボックス検証

未検証のオープンソース PR や、未知のインストールスクリプトを含むサードパーティ製依存関係を処理する際は、クラウドに任せてそのまま実行させます：

• 仮想マシンは使い捨ての独立サンドボックスであり、ホストマシンの SSH キーやローカルの個人認証情報は一切含まれていません。
• ネットワークアクセスレベルを Trusted または None に制限できます。ただし None に設定した場合でも、Claude と Anthropic API の通信、およびブランチへのコードプッシュは引き続き許可されるため、外部へデータを一切送信できない物理的隔離と見なすことはできません。

コアメカニズム：セキュリティ境界、ライフサイクル、リソース仕様

1. リソース構成仕様：Anthropic がホストする各仮想マシンは Ubuntu 24.04 イメージ（x86_64 アーキテクチャ）であり、およそ 4つの仮想コア vCPU、16GB メモリ、30GB のストレージ容量 を備えています。
2. 認証情報プロキシによる分離：開発者の本物の GitHub 認可 Token は、仮想マシンの外部にある GitHub Proxy 層に保持されます。仮想マシン内の Claude が保持するのは短時間のみ有効な低権限の一時認証情報であり、そのプッシュ権限は自身の作業ブランチに厳格に限定されます（この認証情報は VM 内部から認可範囲内の関連リポジトリを読み取ることは可能ですが、他の保護ブランチへ無断でプッシュしたりブランチを削除したりすることは禁止されています）。
3. 設定ファイルの持ち込み仕様：リポジトリ内の CLAUDE.md、.claude/settings.json、.claude/rules/、.claude/skills/、および .mcp.json は Git リポジトリとともにクラウド仮想マシン内へ持ち込まれます（単一リポジトリのセッションでは自動ロードされます）。一方、開発者のローカルPCにある ~/.claude のユーザーグローバルなプライベート設定は、常にローカルPC側に留まります。
4. 仮想マシンの一時停止（Pause）と回収（Reclaim）、およびデータのライフサイクル：
   • 一時停止（Pause）：セッションで数分間操作がない場合、仮想マシンは自動的に一時停止し、ディスクファイルが完全に保持されます。新たなメッセージを送信すると、同一の仮想マシンが稼働を再開します。
   • 回収（Reclaim）とセッションの保持：長期間操作のないアイドル状態の仮想マシンは、システムによって完全に回収・解放されます。ただし、仮想マシンの回収によってチャット履歴が削除されることはありません。完全なセッション履歴は Anthropic によって保持され、保持期間はユーザーの契約プランおよびモデル改善の設定に依存します。セッション自体を削除すると対応するデータも消去されます。後日セッションを再び開いた場合、システムは新しい仮想マシンを再度割り当てて会話履歴を復元しますが、以前のマシンで動作していたバックグラウンドプロセスや未コミットのコード変更は保持されません。長期にわたるタスクでは Agent に適時コミットとプッシュを行わせ、保存すべき成果物はリモートブランチを基準として管理してください。
5. 利用枠と並行消費：クラウドセッションには個別のマシン利用料請求はなく、既存プランの利用枠がそのまま使用されます。5つのタスクを並行して実行した場合、プランの利用枠の消費速度は単一セッションの約5倍になります。既存の個人向け Pro および Max サブスクリプションユーザー向けには、期間限定のクラウドセッション専用お試しクレジット（Pro は $100、Max は $250）が提供されており、claude.ai/code/claim-credit の申請ページまたは Claude Code セッション内で /claim-credit と入力して受け取ることができます。このクレジットはクラウドセッションの利用に限定され、Projects や Routines には適用されません。使い切るか期限が切れると自動的に通常のプラン利用枠へ戻ります。詳細はプロモーションクレジット利用規約を参照してください。
6. モデル学習ポリシー：Team および Enterprise の商用プランでは、組織管理者が自ら有効化（org opt-in）しない限り、コードやプロンプトが基盤モデルの学習に使用されることはデフォルトでありません。個人の Pro および Max プランでは、プライバシー管理ダッシュボード内の「モデルの改善（Model Improvement）」スイッチの設定に従います。