Claude Codeのクラウドセッションを並列で回す — 3タスクが87秒で完了
Claude Codeのクラウドセッションで3タスクを同時に走らせた実験を紹介。87秒は再作成の工程込みの小さなリポジトリでの値です。Pro・Max向けの一回限りのボーナスクレジット($100・$250)も扱います。
claude.dev開発者ブログに、Addy Osmaniによるクラウドセッションの実践ガイド(2026年10月6日公開)が載りました。小さなサンプルリポジトリで3つのタスクを同時に走らせ、3つとも87秒で終わった記録が中心です。同じ日に、Pro・Maxの既存ユーザーが一回だけ受け取れるクラウドセッション用ボーナスクレジットも案内されています。
要点
ブログの実験で出た数字
3セッションの所要時間
61〜72秒
最初の開始から全完了まで87秒
不安定なテストの検証
40回連続成功
npm testを1コマンドで反復
Pro向けボーナス
$100
Maxは$250。一回限り
- 並列の実証: 開始時刻が16秒以内の3セッションが、別々のVM・ブランチ・プロセスで動き、互いのポートやファイルに触れなかった
- ローカルとの使い分け: 手元にしかない資源(実データのDB、VPN越しのサービス、GPUなど)が要るタスクはローカル、それ以外はクラウドの候補になる
- GitHub接続の落とし穴: 「GitHubでサインイン」と「Claude GitHub Appのインストール」は別の許可で、プライベートリポジトリにはアプリが要る
- クレジットの期限: 申請は10月7日まで、クレジット自体は11月4日に失効する
全体としては、クラウドセッションを「手元の代わり」ではなく「手元が塞がっている間に並行して進める作業場」として使う提案です。
あなたの利用フローはどう変わるか
個人のPro・Maxユーザー
クラウドセッションは追加料金なしで使え、利用枠は通常のClaude Codeと同じものを消費します。ボーナスクレジットは、既存の個人Pro・Maxが対象で、プランの上限とは別枠です。
- Proは$100、Maxは$250
- 申請先は
claude.ai/code/claim-creditか、Claude Code内の/claim-credit - 申請期限は10月7日、クレジットの失効は11月4日
- ProjectsとRoutinesには使えない
使い切るか失効すると、通常のプラン枠に戻ります。ブログは条件の詳細を「Promotional Credit Offer Terms」に委ねています。申請期限の時刻はブログにも条件文にも明記がないため、早めの申請が安全です。
Team・Enterpriseの管理者
プランによっては、オーナーがクラウドセッションを先に有効化する必要があります。管理者向けの確認項目は次の4つです。
- 管理画面でGitHubコネクタをオンにする
- Claude Codeの管理設定でクラウドセッションを許可する
- 組織のリポジトリにClaude GitHub Appを入れる(メンバーの申請を承認する形でもよい)
- Quick setupを有効にするかを決める
IPアドレス許可リストを使う組織やGitHub Enterprise Serverには追加の手順があります。IP許可リスト下で全セッションが認証エラーになる場合は、サポートにAnthropic提供サービスの除外を依頼する流れです。GitHub接続の方式ごとの違いはClaude Code WebのGitHub認証で比べています。
すでにCLIで使っている開発者
端末からの入口はclaude --cloudです。GitHubのリモートを現在のブランチでクローンするため、先にローカルのコミットをpushしておく必要があります。
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."プロンプトは「何が壊れているか・終わりの条件・証明の方法」を含む自己完結したチケットとして書く、というのがブログの書き方です。上の例は、ブログが短縮して示した3つのプロンプトのうち1つです。
大きな変更では、計画だけ手元で詰める流れも紹介されています。plan modeで方針を決めてdocs/migration-plan.mdにコミット・pushし、その計画をクラウドに実行させます。終わったらclaude --teleportでセッションを手元に引き取ります。引き取りの条件と失敗時の挙動はClaude Code teleportの使い方に詳しくあります。
実験の中身と、設計の前提
3つのタスクと結果
題材は、3つの架空の港の潮位を予測する小さなNode APIです。次の3つの問題があり、1問題につき1セッションを割り当てています。
| 問題 | 結果 |
|---|---|
| 4回に1回失敗するテスト | 結果TtlCache.getの競合を特定し、読み込み中のPromiseを保持する形に変更。40回連続で失敗0 |
| 実装と食い違うAPI文書 | 結果サーバーを起動して全エンドポイントにcurlし、5種類の誤りを修正 |
| 文字列連結のロガー | 結果1行1JSONへ変更し、テスト5件を追加 |
リポジトリの再作成がセッション時間の約3分の1から半分強を占めました。tidepoolがGitHubに無かったため、各セッションがプロンプト内のファイルからリポジトリを組み立てているからです。実際のリポジトリならこの工程は不要になります。
文書セッションが見つけた誤りは、返さないフィールドの記載、コードが読まないdaysパラメータ、メートルであるべき高さのフィート表記、/next-highの記載漏れ、エラー応答の欠落です。不正なfrom=が200で空配列を返す挙動は、サーバーコードを直さず注意書きとして文書に残しています。依頼範囲を超えて挙動を変えない判断です。
実行環境の前提
クラウドセッションはAnthropicが管理する基盤か、組織の自前環境で動きます。クラウドセッションが働き方を変える点として挙がっているのは次のとおりです。
クラウドセッションの設計上の前提
タスクごとにVM
新しいVMにリポジトリをクローンし、新しいブランチを切ります。
GitHubトークンはVMの外
プロキシが保持し、セッションには自分の作業ブランチにだけpushできる短命の認証情報を渡します。
リポジトリの設定だけ同行
CLAUDE.md・ルール・スキル・エージェント・コマンドは付いてきますが、個人の
~/.claudeは付いてきません。放置したVMは回収
再開すると、会話が復元された新しいVMになります。大事な作業はコミットしておきます。
VMの規模は、4 vCPU・16 GBのRAM・30 GBのディスク程度です。ツールの一覧やリソース上限の詳しい扱いはClaude Codeクラウドセッションで使えるツールとリソース制限にあり、この記事は実験と並列運用の側を扱います。重いインストールはセットアップスクリプトに入れると、キャッシュされたスナップショットに載ります。スクリプトはroot権限で動き、終了コード0でなければセッションが始まりません。5分程度で終わらせるとキャッシュされ、スクリプトや許可ホストを変更したときと約7日ごとに作り直されます。環境変数は環境を使う全員に見えるため、秘密は入れないという注意もあります。スクリプトとSessionStartフックの役割分担はセットアップスクリプトとフックの使い分けが扱っています。
向く仕事と向かない仕事
7つのワークフローが紹介されています。バックログの並列消化、繰り返しの検証、計画から実行への受け渡し、スマホからの確認、CIとレビューコメントの引き渡し、Routinesによる自動起動、信頼できないコードの実行です。
CIの引き渡しは、対象リポジトリにClaude GitHub Appを入れておくことが前提です。そのうえで、セッションのCIバーのAuto-fixか、PRブランチ上での/autofix-prなどで監視を始めます。Claudeは明確な失敗を直してpushし、曖昧な点や設計に関わる点は人に確認します。ベースブランチとのマージ競合は通知されないため、リベースは自分で頼みます。操作の詳細はClaude Code autofix-prの解説にあります。
ローカルに残す条件も挙がっています。実データのあるDB、VPN越しのサービス、GPU、スマホのシミュレーター、手元のハードウェア、数秒ごとに画面を見たい作業です。Zero Data Retentionで運用する組織では、クラウドセッションそのものが無効になります。
並列は「同じ問題を二重に見つける」ことがある
この実験で最も示唆が大きいのは、3番目のロガーのセッションです。コミット時にテストが1件失敗していたため、Claudeはキャッシュのテストを8回再実行して5回の失敗を確認し、1番目のセッションが直していたのと同じ競合に行き着きました。同じ修正案を出しながら、タスク外だとしてキャッシュには触れず、スイートがクリーンでないことを要約に書いています。
この挙動は、隔離の裏返しです。各セッションは別のコピーで動くので、他方の修正は見えません。ファイル境界でタスクを分けても、共有された不具合は複数のセッションが別々に見つけます。
並列で回すと、見つけた不具合の報告が重複する前提で運用することになります。対処は、ブランチを妥当な順にマージし、残りのセッションへclaude -p "rebase on main and fix any conflicts" --cloud <session-id>のような追いプロンプトを送る形です。
もう一つ、数字の読み方にも注意が要ります。87秒は、再作成の工程を含んだ小さなリポジトリでの値です。実際のリポジトリの所要時間の目安にはなりません。一方で、並列セッションは利用枠も並列に消費するため、5セッションは1セッションの約5倍の速さで枠を使います。クラウドのVM自体には別の計算料金は付きませんが、枠の消費は手元と同じです。
関連して、ProjectsとRoutinesにボーナスクレジットが使えない点は、並列を自動化する用途では効かないことを意味します。Routinesの設計はClaude Code Routines完全ガイドにまとまっています。
まとめ
- Pro・Maxの個人ユーザー: ボーナスクレジットの申請期限は10月7日。使うなら11月4日までに消化し、ProjectsとRoutinesは対象外と覚えておく
- 並列で小さな修正を回したい人: 1タスク1セッションで、終了条件を実行コマンドで書く。マージ順とリベース指示も段取りに入れる
- GitHub連携でつまずきやすい人: サインインとアプリのインストールは別。プライベートリポジトリには後者が要る
- 手元の資源に依存する作業: DB・VPN・GPUが要る作業は、これまでどおりローカルが向く
クラウドセッションの全体像と始め方はClaude Code Web版の入門にあります。