クラウドセッションは、あなたのマシンではなくクラウドインフラストラクチャ上で実行されるClaude Codeセッションで、GitHubリポジトリのコードを操作します。claude.ai/codeのClaude CodeウェブサイトからClaude Mobileから、Claude Desktopから、またはターミナルからclaude --cloudで開始できます。この記事では、クラウドセッションの仕組み、ターミナルやIDEのローカルセッションの代わりに使用する場合、およびそれらが実現するワークフローについて説明します。
クラウドセッションが提供するもの
クラウドセッションを使用すると、あなたの積極的な監督なしに実行されるタスクをClaudeに委任できます。GitHubリポジトリを選択し、実行したい内容を説明すると、Claudeはクラウドでタスクに取り組みます。Claude Codeがタスクの処理を開始したら、ページを完全に離れることができます。Claudeは作業を続けます。完了すると、Claudeは自動的にレビュー用の変更を含むプルリクエストを作成します。
この機能は、ローカルマシンにない可能性があるリポジトリで機能します。ローカルにクローンしたり、開発環境をセットアップしたりする必要なく、アクセス権のあるGitHubリポジトリでタスクを開始できます。これにより、時々貢献するプロジェクトや、まだ学習中のコードベースを探索するのに役立ちます。
クラウドセッションは非同期開発ワークフローを実現します。ターミナルまたはエディタのローカルセッションでは、通常、同期的に作業します。リクエストを行い、Claudeの応答を待ち、変更をレビューしてから、別のリクエストを行います。このような同期的な作業は細かい制御を提供しますが、プロセス全体を通じてあなたの注意が必要です。クラウドセッションは異なる方法で処理します。より大きなタスクを割り当て、Claudeが独立して作業するようにして、後で完了した作業をレビューするために戻ることができます。
複数のタスクを並行して実行することもできます。各タスクは独立した環境で実行されるため、Claudeが複数の異なる問題またはリポジトリで同時に作業することができます。各タスクは独立して進行し、完了時に独自のプルリクエストを作成します。複数のタスクが同時に同じリポジトリで作業できます。
仕組み
クラウドセッションを開始すると、Claude Codeはあなたの作業用に分離された仮想マシンを作成します。GitHubリポジトリはこの環境にクローンされ、一般的な開発ツールと言語エコシステムが事前に構成されています。
Claudeは、リポジトリの設定で定義したセットアップコマンドを実行して環境を準備します。これには、依存関係のインストール、データベースのセットアップ、またはプロジェクトが必要とする他の初期化ステップが含まれます。タスクがパッケージをインストールしたりデータを取得したりするためにネットワークアクセスが必要な場合、環境が持つインターネットアクセスのレベルを構成できます。
環境の準備ができたら、Claudeはタスクの処理を開始します。Claudeはコードを読み、変更を加え、テストを書き、コマンドを実行して作業を検証します。必要に応じて、ウェブインターフェースを通じて進捗を監視し、ガイダンスを提供できます。
Claudeがタスクを完了すると、変更をGitHubリポジトリの新しいブランチにプッシュします。通知を受け取り、変更をレビューしてから、インターフェースから直接プルリクエストを作成できます。プルリクエストにはClaudeのすべての作業が含まれており、レビューと追加の変更の準備ができています。
各タスクは完全に分離された状態で実行されます。仮想マシンはその特定のタスクのためだけに存在し、ネットワークアクセスの制限と認証情報の保護などのセキュリティ制御が含まれています。GitHub認証はセキュアプロキシを通じて管理されるため、認証情報はClaudeが作業している環境に直接存在しません。
クラウドセッションとローカルセッションを使用する場合
一部のタスクはクラウドで非同期に実行するのに適していますが、他のタスクはターミナルまたはIDEでローカルに実行するのが最適です。
クラウドセッションを使用する場合：
明確な要件を持つ明確に定義されたタスク：実行する必要があることを正確に説明でき、タスク中にClaudeを操舵する必要がないと予想される場合、クラウドセッションを使用すると、作業を開始して完了時に戻ることができます。
バグバックログでのバックグラウンド作業：バックログから複数の問題をClaudeに割り当て、並行して実行させることができます。各タスクは独立して進行し、各タスクを個別に監視することなく、複数の修正に同時に対処できます。
ローカルにないリポジトリ：クローンしていないリポジトリまたはマシンにセットアップしたくないリポジトリに変更を加える必要がある場合、クラウドセッションは環境セットアップを処理します。
キューに入れたいタスク：実行する変更のリストがあるが、今すぐ作業したくない場合、クラウドで開始して、後で結果をレビューできます。これにより、同様の作業をバッチ処理したり、他のことに集中している間にタスクを委任したりできます。
ターミナルまたはIDEでローカルセッションを使用する場合：
頻繁なコース修正が必要なタスク：正しいアプローチが正確に何であるかが不確かな場合、または見たものに基づいてClaudeをリダイレクトする必要があると予想される場合、ターミナルで作業すると即座のフィードバックが得られます。Claudeが作業している間に方向を調整でき、完全な結果を待つ必要はありません。
要件が不明確な探索的作業：問題の解決方法を理解しているか、異なるアプローチを調査している場合、ターミナルを使用すると、学習に応じてリクエストを改善できます。やり取りは、最初は明らかでなかった要件を明確にするのに役立ちます。
コミットされていない変更を伴うローカル開発：積極的に開発していて、ローカルリポジトリにコミットされていない作業がある場合、ターミナルでClaude Codeを使用すると、すべてが1か所に保たれます。準備ができていない作業をコミットまたはプッシュする必要なく、変更を迅速に反復できます。
即座のフィードバックが必要なタスク：結果をすぐに確認したい場合、迅速に反復したい場合、ターミナルはより低いレイテンシを提供します。Claudeがリアルタイムで作業するのを見ることができ、プロセスの早い段階で何か問題が発生した場合は停止またはリダイレクトできます。
ユースケースの例
テスト駆動開発によるバックエンド変更
Claudeに期待される動作を定義するテストを書かせ、それらのテストを成功させるコードを実装させます。これは、自動テストを通じて動作を検証できるバックエンド変更に特に適しています。
プロンプトの例：
Add rate limiting to the /api/search endpoint.
The rate limiter should:
- Allow 100 requests per minute per API key
- Return 429 status when limit exceeded
- Reset limits after 60 seconds
- Track different API keys independently
Use a TDD approach: write comprehensive tests first, then implement the rate limiting logic to pass them.
このアプローチを使用する場合：テストがClaudeに明確な検証基準を提供するため、これはクラウドセッションで機能します。テストが問題をキャッチし、反復を機能するソリューションに導くため、Claudeの進捗を監視する必要はありません。Claudeがテストを書いてから成功させるというタスクの自己完結的な性質は、開始後の入力を必要としません。
これが効果的な理由：Claudeはあなたの監督なしに実装を反復でき、テスト失敗を使用して問題を特定して修正できます。タスクは単純なコード変更よりも長く実行されますが、バックグラウンドで完了させることができます。プルリクエストをレビューするとき、テストと実装の両方が準備でき、テストが成功するため、ソリューションが機能することに確信があります。
ドキュメント更新
READMEファイル、APIドキュメント、コードコメント、ユーザーガイドなどの技術ドキュメントを生成または更新します。
プロンプトの例：
Update CHANGELOG.md with all changes since the v2.3.0 release:
- Review commits on main branch since that tag.
- Categorize changes into "Added, "Changed, "Fixed", and "Removed" sections.
- Include the commit hash for each entry.
このアプローチを使用する場合：Claudeがコミット履歴を独立してレビューし、ガイダンスなしでエントリをフォーマットできるため、変更ログの更新はクラウドセッションに適しています。タスクは手動で実行するのは退屈ですが、Claudeが含めるコミットやそれらを分類する方法についての質問なしに完了するのに十分簡潔です。
これが効果的な理由：変更ログ全体の更新を委任し、完了時に結果をレビューできます。Claudeはコミットを読み、意味のある変更を抽出し、既存の変更ログ形式に従います。
明確なスコープでのリファクタリング
変更の明確な境界を定義できる場合、コードを再構成して組織またはreadabilityを改善します。これには、コードの抽出、大きなファイルの分割、またはモジュール構造の整理が含まれます。
プロンプトの例：
The UserService class in /src/services/user.go has 800 lines long.
Split it into three focused services:
- UserAuthService (login/logout/sessions)
- UserProfileService (profile CRUD operations)
- UserPreferencesService (settings/preferences)
Ensure all tests still pass.
このアプローチを使用する場合：明確な制約を持つリファクタリングは、Claudeが従うべき明確な境界を設定できるため、クラウドセッションで機能します。テストスイートは検証を提供でき、Claudeがリファクタが既存の機能を破壊しなかったことを確認できます。
これが効果的な理由：タスクは時間がかかりますが、構造が定義されたら積極的な入力は必要ありません。リファクタを開始して、Claudeがタスクを処理している間に監視するのではなく、後で整理された結果をレビューできます。明確なスコープは、Claudeがタスク中にガイダンスを必要とする可能性が低いことを意味します。
効果的な使用のためのヒント
Claudeがタスクを正常に完了したことをより簡単に検証できるように、リポジトリにテストスイートを追加することを検討してください
「改善」や「修正」などの曖昧な目標ではなく、成功基準を指定してください
プロンプトで何が変わるべきか、何が同じままであるべきかを定義してください
Claudeが中途半端なガイダンスを必要としないように、明確な境界を持つタスクをスコープしてください
「まずこれがどのように進むかを見る必要があります」と考えている場合は、代わりにターミナルの使用を検討してください
タスク中にガイダンスを提供する必要があることに気付いた場合は、「CLIで開く」を使用してください