導入:Projectsベータは全員には来ていない。でも--cloud/--teleportは今すぐ使える
2026-09-17、Anthropicは「Claude Code Projects」というベータ機能を発表した。1つの会話にまとまった作業を投げると、Claudeがタスクごとにクラウド上の並列スレッド(それぞれが独立したクラウドセッション)を立ち上げ、リポジトリ・指示・メモリを共有しながら調整してくれるというものだ。ノートPCを閉じてもスレッドは走り続け、スマホから進捗を確認・指示できる。
ただし公式ドキュメント(code.claude.com/docs/en/claude-projects)はこう明記している。
Projects are in public beta on Pro and Max plans and rolling out gradually, starting with accounts that have used cloud sessions and don’t have existing projects in claude.ai chat or Cowork. They aren’t available on Team or Enterprise plans yet.
Pro/Maxプランでも「クラウドセッションを使ったことがあるアカウントから段階的に」としか書かれておらず、サイドバーに「Projects」が出ていなければロールアウトがまだ届いていないだけ、ウェイトリストに登録するしかない。Team/Enterpriseは対象外。つまり、この記事を読んでいる多くの人は今日、Projectsベータそのものには触れない。
一方で、Projectsが内部で使っている部品――クラウドセッションを作る--cloudと、クラウドセッションをローカルに引き戻す--teleport――は、Pro/Max/Teamの「research preview」として、GitHub連携さえ済ませればProjectsのロールアウト状況に関係なく今日から使える。公式ドキュメントの「Move tasks between terminal and cloud」節がこの2つを軸に据えているのはそのためだ。
この記事では、Projectsベータそのもの(実際にはアクセスできなかった)の紹介はドキュメントの引用にとどめ、代わりに手元で実際に実行できる--cloud/--teleportのCLI挙動を実機検証した。結果、次の2点を確認した。
- 無人
claude -pパイプラインからは新規クラウドセッションを作れない(--cloudは新規作成時のみインタラクティブ端末必須。このブログ自身の自動投稿パイプラインのような無人実行では使えない) --teleportが無効なセッションIDで失敗すると、通常実行では原因メッセージが一切表示されない(exit code 1だけが返り、実際のエラーは--debug-fileを付けたときだけログに現れる、未文書化の挙動)
使い捨てのGitリポジトリで実際にコマンドを実行し、生のエラー出力を掲載する。実費はかかっていない(すべて認証済みアカウントでのクライアント側バリデーションエラーで、API呼び出しは発生していない)。
一次情報:Projects・--cloud・--teleportの関係を公式ドキュメントで整理する
まず用語を整理する。公式ドキュメント「Use Claude Code in the cloud」(code.claude.com/docs/en/claude-code-on-the-web)はこう書いている。
Cloud sessions are in research preview for Pro, Max, and Team users, and for Enterprise users with premium seats or Chat + Claude Code seats.
クラウドセッション自体(Projectsとは別物)は、Team・一部Enterpriseでも使える。そして同ページの「Move tasks between terminal and cloud」節に、本記事の核心となる一文がある。
From the CLI, session handoff is one-way: you can pull cloud sessions into your terminal with
--teleport, but you can’t push an existing terminal session to the cloud.
つまり「ローカルで今動いているセッションをクラウドに送る」ことはできない。--cloudはあくまで新しいタスクの指示文からクラウドセッションを新規作成するか、既存のクラウドセッションにメッセージを送るかのどちらかであり、ローカルの会話履歴そのものを持ち上げてくれるわけではない。この非対称性は実際にGitHub Issueとしても要望が上がっている。
- Issue #66373(open)「Add a CLI command to hand off a running local session to the cloud (local→web, the inverse of
--teleport)」 - Issue #95073(open)「Feature request: easy way to move a session from Cloud to Local (Local→Cloud nice-to-have)」
どちらも「ローカル→クラウド」方向のハンドオフが今は無いことを前提にした要望であり、公式ドキュメントの記述と一致する。
もう1つ、紛らわしい点がある。手元のclaude --helpにはprojectというサブコマンドが載っているが、これは今回のProjectsベータとは無関係だ。
$ claude project --help
Usage: claude project [options] [command]
Manage Claude Code project state
Commands:
purge [options] [path] Delete all Claude Code state for a project
(transcripts, tasks, file history, config entry)
claude project purgeは「あるディレクトリで使ったClaude Codeのローカル状態(トランスクリプト・タスク履歴・ファイル履歴・設定エントリ)を消す」というハウスキーピングコマンドで、対象の「project」は単に「Claude Codeを使ったことがある作業ディレクトリ」を指す。一方、新しいProjectsベータの「project」は「Claudeが並列クラウドスレッドを調整する1つの会話」を指す。同じ単語が指すものが違うので、”claude project” で検索してこのコマンドに行き着いた人が新機能と勘違いしないよう注意したい。
実務フロー:何を選ぶか
これまでの検証記事(claude-code-worktree-parallel-isolation-verifiedほか)で扱ってきたローカルの並行実行手段と、クラウド側の選択肢を1本の判断フローにまとめる。
| やりたいこと | 選ぶもの | 前提条件 |
|---|---|---|
| 手元のマシンで複数タスクを同時に走らせ、終わったら自分でマージする | --worktree(+--tmux) |
ローカルにディスク・CPU余力があること |
| 1つのタスクを投げっぱなしにして、ノートPCを閉じても進めておきたい | --cloud "タスク内容" |
Pro/Max/Team、GitHub連携(GitHub App or /web-setup)、インタラクティブ端末から実行(後述) |
| 動いているクラウドセッションに追加の指示を送りたい(CI・cronからでも可) | claude -p "指示" --cloud <session-id> |
同じclaude.aiアカウントでログイン済み |
| クラウドで進んだ作業を手元で続けたい | claude --teleport <session-id> |
git作業ツリーがクリーン、同じリポジトリのチェックアウト、対象ブランチがpush済み |
| 複数タスクの割り振り・進捗管理・記憶の共有までClaudeに任せたい | Projects(ベータ) | ロールアウトが届いていること(未到達ならウェイトリスト) |
ポイントは、表の上から3行目まではこのブログの自動投稿パイプラインのような無人claude -p実行の中でも(条件付きで)使えるが、新規クラウドセッションの作成だけは条件が異なるという点だ。これを実機で確かめる。
実機検証の手順:コピペ用プロンプト5本
以下はすべて、実際にこの記事の執筆時に実行し、出力をそのまま貼っている。GitHub連携もクラウドセッションの実作成も行っていない(組織のGitHub App権限や実リポジトリへの影響を避けるため、意図的にクライアント側バリデーションで止まる入力だけを使った)。
プロンプト1(無料・即時・約10秒):バージョンとフラグの存在確認
claude --version
claude --help | grep -A2 -- "--cloud \[description\|session_id\|url\]"
claude --help | grep -A2 -- "--teleport \[session\]"
期待結果:バージョン番号(例 2.1.270 (Claude Code))と、--cloud・--teleportそれぞれの1行説明が表示される。
成功判定:2つのフラグの説明行が出力に含まれていれば、手元のバージョンはこの記事の検証内容をそのまま試せる状態にある。API呼び出しは発生しないため無料。
実際の出力:
2.1.270 (Claude Code)
--cloud [description|session_id|url] Create a cloud session with the given
description, or attach to an existing
one by session ID or claude.ai/code URL
--teleport [session] Resume a teleport session, optionally
specify session ID
プロンプト2:無人パイプラインから新規クラウドセッションは作れないことを確認する
SANDBOX=$(mktemp -d)
cd "$SANDBOX"
git init -q && git config user.email "test@example.com" && git config user.name "Test"
echo "# test" > README.md && git add README.md && git commit -qm "init"
claude -p --cloud "add a hello.txt file" --output-format json
echo "EXIT_CODE=$?"
期待結果:--cloudと-p(print mode)の併用がエラーになる。
成功判定:exit codeが0以外で、標準エラーに「interactive only」という趣旨の文言が含まれること。
実際の出力:
Error: --cloud cannot be combined with --print.
Starting a new cloud session with --cloud is interactive only: drop --print, or drop --cloud to run locally. To message an existing cloud session instead, pass its ID: `claude -p "message" --cloud <session-id>` (find IDs at claude.ai/code).
EXIT_CODE=1
このブログの投稿パイプラインは全工程をclaude -pで無人実行している。同じ構造の自動化に--cloudで新規タスクを投げる処理を組み込もうとすると、この時点でそもそも動かない。CLIのエラーメッセージ自体が「新規作成は諦めて既存セッションへのメッセージ送信に切り替えろ」と代替手段を提示してくれる点は親切だ。
プロンプト3:-pを外しても、TTYが無ければ同じ理由で止まる
cd "$SANDBOX"
claude --cloud "add a hello.txt file"
echo "EXIT_CODE=$?"
期待結果:-pを付けていなくても、実行環境(このブログのパイプラインが動くbashジョブなど)がTTYを持たない限り、やはり新規クラウドセッションは作成できない。
成功判定:「interactive terminal」という趣旨のエラーが出て、exit codeが0以外であること。
実際の出力:
Error: --cloud requires an interactive terminal.
Non-interactive invocations (piped stdout, --init-only, --sdk-url) run locally and would silently ignore --cloud.
EXIT_CODE=1
ここで見落としてはいけないのが2行目だ。「Non-interactive invocations … would silently ignore --cloud」――つまりCLIはこの呼び出し方式ではエラーになったが、別の非対話呼び出し(--init-onlyやSDK経由の--sdk-urlなど)では--cloudが無言で無視されてローカル実行にフォールバックする場合がある、と自ら警告している。今回の-p(またはTTYなし単体起動)では明示的なエラーで止まったが、呼び出し方式によっては「クラウドで動くはずが実は手元で走っていた」という気付きにくい事故になりうる。無人パイプラインに--cloudを組み込む場合は、exit codeとエラーメッセージの両方を確認する必要がある。
プロンプト4:既存セッションへのメッセージ送信は、無効なIDでも原因が明確に返る
cd "$SANDBOX"
claude -p "hello" --cloud "session_bogus123" --output-format json
echo "EXIT_CODE=$?"
期待結果:セッションIDの形式が不正である旨のエラーが、JSON形式で構造化されて返る。
成功判定:JSON中の"ok":falseと"error"フィールドに理由が入っており、jq -r .errorで人間可読な理由が取り出せること。
実際の出力:
{"ok":false,"session_id":"session_bogus123","error":"invalid session ID: must be a cse_… or session_… tagged ID"}
Error: failed to send message to cloud session session_bogus123: invalid session ID: must be a cse_… or session_… tagged ID
EXIT_CODE=1
公式ドキュメントのエラー一覧表には「Session not found: <id>」(存在しないIDの場合)は載っているが、今回のような形式そのものが不正なIDに対するこの「invalid session ID: must be a cse_… or session_… tagged ID」という文言はドキュメントのエラー表には明記されていない。実装上は「まずID形式をクライアント側で検証し、正しい形式なら次にサーバーへ問い合わせて存在確認する」という2段階になっていると推測できる(この段階分けの推測は公式に明言されていない)。いずれにせよ、既存セッションへのメッセージ送信は失敗時も理由がはっきり返る、という点が重要だ。
プロンプト5:--teleportは無効なセッションIDで「無言で」失敗する
まず通常実行(--debug-fileなし)。
cd "$SANDBOX"
echo "STDOUT_START"
claude --teleport "session_bogus123"
echo "STDOUT_END EXIT=$?"
期待結果(予想):プロンプト4と同様、「invalid session ID」のようなエラーメッセージが表示される。
実際の出力:
STDOUT_START
STDOUT_END EXIT=1
何も表示されない。標準出力にも標準エラーにも一切メッセージが出ないまま、exit code 1だけが返る。同じ「不正なセッションID」という入力に対して、プロンプト4(--cloudでのメッセージ送信)は理由を明示したのに、--teleportは完全に沈黙する。
次に、原因を突き止めるため--debug-fileを付けて再実行する。
cd "$SANDBOX"
rm -f /tmp/teleport-debug.log
claude --teleport "session_bogus123" --debug-file /tmp/teleport-debug.log
echo "EXIT=$?"
grep "\[ERROR\]" /tmp/teleport-debug.log
期待結果:デバッグログの中に、実際の失敗理由を示す[ERROR]行が見つかる。
成功判定:grepがヒットし、”Teleport”という語を含むエラー行が出力されること。通常実行で沈黙していた理由がここで初めて分かる。
実際の出力(該当行を抜粋):
2026-09-21T23:44:33.563Z [ERROR] Teleport in print mode failed: invalid session ID: must be a cse_… or session_… tagged ID
デバッグログには、プロンプト4とまったく同じ理由(invalid session ID: must be a cse_… or session_… tagged ID)がちゃんと記録されている。つまり--teleportは原因を正しく検出しているのに、通常実行時にはユーザーへ一切伝えないという実装になっている。ログの文言が”Teleport in print mode failed”となっている点にも注目したい。今回-pは指定していないが、TTYを持たない非対話環境で--teleportを実行すると内部的に「print modeと同じ扱い」で処理され、そのエラー出力経路だけが標準出力/標準エラーに繋がっていないと考えられる(内部実装の推測であり、ソースコードを確認したわけではない)。
公式ドキュメントの「Teleport requirements」表(clean git state / correct repository / branch available / same account)にも、「--teleport is unavailable」節の認証エラー一覧にも、この「無効なセッションIDだと通常実行では完全に無言になる」というケースは記載がない。自動化パイプラインで--teleportを使う場合、必ず--debug-fileを付けてexit code非ゼロ時にログをtailする運用にしないと、失敗原因が分からないまま「なぜか動かない」状態になる。
GitHub Issueとの関連付け
--teleportまわりでは、信頼性・可視性に関する報告が他にも複数ある。いずれも今回発見した「無効IDでの完全な沈黙」とは異なる症状だが、テレポート機能全体の未成熟さを示す傍証として関連付けておく。
- Issue #93892(open)「Docs say
--teleportis cloud-only, but it works on Remote Control sessions from another machine」:ドキュメントの記述と実際の挙動が食い違っているという報告で、本記事が指摘する「ドキュメントに載っていない挙動がある」という傾向と符合する。 - Issue #92144(open)「Cross-device session continuation executes on the origin machine with no indication」:クロスデバイスのセッション継続まわりで「何の表示もないまま」という症状が報告されており、本記事の「無言の失敗」と根の部分で近い可能性がある(症状の詳細は異なるため断定はしない)。
- Issue #92734(open)「teleport: web→local handoff drops prompt history」:テレポート自体が完全に安定した機能ではないことを示す別の報告。
いずれもopenであり、自分で再現確認したわけではない。出典として引用するにとどめる。
活用例:自動化パイプラインへの組み込み方
このブログの投稿パイプライン自身のような無人claude -p実行に、クラウドセッションとの連携を足すなら、今回の検証結果から次の設計になる。
- 新規クラウドセッションの作成はパイプラインに含めない。プロンプト2・3の通り、無人
-p実行や非TTY環境からは作成できないか、呼び出し方式によっては無言でローカル実行にフォールバックしうる(プロンプト3の警告文)。作成は人間が対話セッションかclaude.ai/codeから行う運用にする。 - 既存クラウドセッションへの指示出しはパイプラインに組み込んでよい。
claude -p "指示" --cloud <session-id> --output-format jsonはJSON形式で成否が明確に返るため、jq -r .okで分岐できる。 --teleportを自動化に組み込む場合は、必ず--debug-fileを併用し、exit code非ゼロ時にログの[ERROR]行を出力・通知する。素の--teleportだけでは失敗時に何も分からない。- 上記が使えない・遅い場合の代替として、これまでの記事で検証済みの
--worktree(+--tmux)によるローカル並行実行に切り替える。
注意点・限界
- 実際のクラウドセッション作成・
--teleportの成功パスは検証していない。GitHub App連携や実リポジトリへの副作用(意図しないクラウドVM起動・ブランチ操作)を避けるため、今回はすべて使い捨てのローカルGitリポジトリと、クライアント側バリデーションで止まる無効な入力だけをテストした。したがって「正常系で--cloudから実際にタスクが完了する挙動」「--teleportで本物のセッションを正しく引き戻す挙動」自体は公式ドキュメントの記述に基づく紹介であり、自分で実行して確認した事実ではない。 - Projectsベータそのものにはアクセスできていない。ロールアウト対象かどうかは公式ドキュメントの記述をそのまま引用しており、実際の画面や挙動は未確認。
--teleportの「print modeとして処理される」という説明は、ログの文言(Teleport in print mode failed)からの推測であり、ソースコードで裏取りした事実ではない。- 今回確認した沈黙・エラーメッセージの文言は手元バージョン(2.1.270)時点のものであり、将来のバージョンで修正・変更される可能性がある。
締め
Claude Code Projectsベータは魅力的な機能だが、ロールアウトが届くまで指をくわえて待つ必要はない。--cloudでのメッセージ送信と--teleportは、Pro/Max/Teamで今日から使える部品であり、実際に手を動かしてみると「無人パイプラインでは新規クラウドセッションを作れない」「--teleportの失敗は--debug-fileを付けない限り完全に沈黙する」という、公式ドキュメントのどこにも書かれていない2つの挙動が見えてきた。クラウド連携を自動化に組み込む前に、まず使い捨てリポジトリで一度これらのエラーパスを踏んでおくと、本番で無言のまま失敗して原因調査に時間を溶かす事態を避けられる。
Comments