10月6日、claude.dev（Anthropicが提供するClaude Code向けの公式サービス）が「Claude Code in the cloud: a field guide to cloud sessions / claude.dev Blog」と題した記事を公開した。この記事では、Claude Codeをクラウド上のVMで実行する「クラウドセッション」の仕組みと、実際の4セッション・7ワークフローを通じた実践的な活用方法について詳しく紹介されている。
claude.devとは
claude.devは、Anthropicが提供するClaude Code専用のプラットフォームサービスだ。ターミナルで動くClaude Codeをブラウザ・モバイル・Slackなどから扱いやすくするための管理基盤や、今回紹介するクラウドセッション機能を提供している。サードパーティツールではなく、Anthropic公式のエコシステムの一部として位置づけられている。
ローカルのClaude Codeとの決定的な違い
通常、Claude Codeはラップトップ上のターミナルで動く。このローカルセッションには3つの制約がある。作業ツリーを共有するため複数セッションが同一ファイルを取り合う、自分の認証情報で動く、そしてPCがスリープしたり回線が切れると止まる。
クラウドセッションはこれを根本から変える。タスクごとに独立したVMが起動し、リポジトリが新規ブランチにクローンされた状態でClaude Codeが動く。ユーザーはbrowser、モバイルアプリ、Desktop、ターミナル（claude --cloudコマンド）、Slackから起動・監視できる。作業が終われば、そのままプルリクエストに変換できるブランチが残る。
料金面では、Pro・Max・Team・Enterpriseプランに追加コストなしで付属し、クラウドマシンの計算コストは発生しない。利用量はClaude Code全体の上限と共有される形だ。なお記事中では、既存のPro・Maxサブスクライバーを対象にProは$100、Maxは$250のワンタイムボーナスクレジットが紹介されていたが、請求期限は10月7日であり、本記事の公開時点で既に期限を過ぎている可能性が高い。クレジット自体の有効期限は11月4日とされているため、請求済みの方はその点を確認されたい。
並列実行の実力：3タスクを87秒で
記事の核心は、実際に動かした検証結果だ。tidepoolという小さなNode.js APIリポジトリに対し、3つの問題を16秒以内に立ち上げた3つのクラウドセッションで同時に処理した。
claude --cloud "npm test fails maybe one run in four. Find the flaky test, fix the root cause in the code (not the test), and prove it by running the suite at least 30 times in a row."
claude --cloud "docs/API.md is out of date with src/server.js. Rewrite it so every endpoint, parameter, default and response shape matches the code. Start the server and run each curl example to check it."
claude --cloud "Make src/logger.js emit one JSON object per line, keep LOG_LEVEL, and log method, path, status and duration_ms as fields. Add a test for the logger."
結果は以下の通りだった：
- フレーキーテストの修正（65秒）：
TtlCache.getにレースコンディションを発見。ローダー実行中の同一キーへの二重呼び出しが原因で、インフライトのPromiseをキャッシュする修正を施し、テストスイートを40回連続実行してゼロ失敗を確認。 - APIドキュメントの修正（62秒）：サーバーを起動してエンドポイントにcurlを打ち、古いドキュメントの5つの誤りを検出。存在しないフィールド、無視されるパラメータ、フィートで書かれた実際はメートルの単位、欠落エンドポイント、エラーレスポンスの欠如を修正。
- ロガーのJSON化（72秒）：構造化ロガーを実装し5つのテストを追加。ただしキャッシュのレースコンディションに起因するテスト失敗を検出し、別セッションが修正中のため自分では手をつけず、サマリーに「スイートはクリーンでない」と明記した。
3セッション合計で最初の起動から87秒後に全タスク完了。ローカルでは2エージェントが同一チェックアウトを編集するとファイル競合やポート衝突が起きるが、クラウドなら各セッションがVM・ブランチ・プロセスを完全に分離して持つ。
ただし隔離にはトレードオフがある。ロガーセッションはキャッシュ修正に気づけなかったように、並列タスクはファイル境界で分割し、ブランチのマージ順を設計することが推奨されている。
アーキテクチャ上の重要な4点
クラウドセッションの内部構造として、以下の4点が挙げられている。
- タスクごとに独立したVM — セッション間でファイルもポートも共有しない
- GitHubトークンはVMに入らない — プロキシが保持し、セッションには自分のブランチへのpushのみ可能な短命の認証情報が渡される
- リポジトリのClaude設定は引き継がれるが個人設定は引き継がれない —
CLAUDE.md・ルール・スキル・コマンドはリポジトリと一緒に移動するが、~/.claudeはラップトップに残る - アイドル状態のVMは回収される — 再接続すると会話は復元されるが、VMは新しいものになるためコミットが必要
ローカルvsクラウドの選択基準
クラウドセッションはローカルの代替ではなく、多くのユーザーが両方を使い分ける。
ローカルを選ぶべきケース：
- ローカルDBや実データへのアクセスが必要
- VPN越しのサービス接続
- GPU、スマートフォンシミュレータ、物理デバイス
- 変更をすぐ自分のブラウザで確認したい視覚的なタイトループ
- Zero Data Retention設定の組織（クラウドセッションはオフになる）
クラウドに向く7つのワークフローとして記事が挙げているのは、バックログの並列処理、フレーキーテストへの徹底的な修正検証、ドキュメント更新、ライブラリのアップグレード、コードレビューへの対応、スケジュール実行（定期タスク）、モバイルからの起動だ。特にフレーキーテストの修正は「スイートを200回回す」「50コミットにわたってリグレッションをbisectする」といった繰り返し検証を人間のマシンに縛られずに実行できる点で効果が大きいとされている。
ローカルとクラウドを使い分けながら、並列タスクをVMに投げてブランチで受け取るというワークフローは、CI/CDパイプラインの考え方をインタラクティブなAI作業に持ち込む形に近い。まずは「ローカルで詰まりがちな並列作業や長時間検証」を一つクラウドセッションに切り出してみることが、導入の第一歩として現実的だろう。
詳細はClaude Code in the cloud: a field guide to cloud sessions / claude.dev Blogを参照していただきたい。
