見出し画像

スマホから始めたClaude Codeを、PCで拾う ── 3つの落とし穴と定型文3種

📓 Okeya Graph | AIツール(Claude / Claude Code / Gemini / ChatGPT / Genspark)を毎日触って、引っかかったところを淡々と書きます。
この記事は 約 8 分。前半だけでも「へぇ、スマホからでも新規で頼めるんだ」が持ち帰れます。後半は「自分でも同じ引き取り方を組みたい」人向けの詳しめの話です。


外出中に「あ、あのバグ、いま直せそう」と思ったのに、家に着くまで指示ひとつ出せなかった——そんな経験、ありませんか?

私はよくありました。iPhone をポケットから出して、Claude アプリを開いて、それでもコードには触れなかった。「見るだけ」の道具で、「頼む」ためのものではなかったんです。

その状況が、最近になって変わりました。

iPhone の Claude アプリで「Code」タブを開いたら、以前はなかったはずの「新規」ボタンが目に入ったんです。GitHub リポジトリを選んで、タスクを書いて、送信する。それだけで、こちらのパソコンが起動していなくても Claude が動き出す

以前は違いました。もっと前はスマホから触ることさえできず、しばらく前になってようやく「PC で走っているセッションを、スマホから覗く」段階になり、それでも新規に立ち上げることはできなかった。PC で区切って再開するという縛りが、ずっとあったんです。

いつからスマホ発の新規セッションが本格的に使えるようになったのか、公式のドキュメントを遡っても正確な日付は特定しきれませんでした。私の体感では、この数ヶ月の間のどこかで急に手触りが変わった。触ってみると便利で、何度か助けられました。同時に、いくつか自分自身のミスでハマったんです。git の競合以外のバグが出て、しばらく原因を追いかけたこともあります。

この記事は、その実験ログです。「スマホで始めた続きを、PC の Claude Code CLI で引き取る」ときに、私が実際にやっている手順と、避けたい落とし穴と、そのままコピペで使える PC 側の指示テンプレを 3 つ、置いておきます。同じところでつまずいている人に届けば嬉しいです。

1. これまでできなかったこと、いま何ができるようになったか

過去にあった痛いところを 3 つ、思い出しておきます。

痛かったこと 1: セッションを区切って再開するには、PC が必須だったんです。iPhone で見ていた会話をどこかで一旦止めて、翌日 PC で「続き」を始めたい。この「区切って再開」がずっとスマホ側では成立しませんでした。同一セッションの中で意思決定を続けることはできても、いったん閉じて、別の入り口から続きに戻る動線がなかった。

痛かったこと 2: 同一セッション内はスマホで完結できるけど、常にコンテキストウィンドウを気にしないといけなかった。会話を長く続けると、履歴が肥大化して Claude の判断精度が落ちてくるんです。PC 側なら /compact で圧縮するか、別セッションに切り替えて頭を整理する選択肢がありましたが、スマホでは可視化が弱くて、いつ切り替えるべきかの判断が難しい。「もう少し粘れるはず」と粘って、結局スマホでは決着つかず、家に帰ってから PC で再スタート、という流れになりがちでした。

痛かったこと 3: そもそもスマホから新規セッションを立てられなかった。外出中に「あ、あのリポジトリのあのバグ、いま思いつく方法で直せるかもしれない」と思っても、PC に着くまで指示を出せなかったんです。

(図)過去の 3 縛りのうち、いま外れたのは 3 つ目だけ。残り 2 つは仕組みとしてまだ残っている。

いま、これらのうち 3 番目が明確に外れた、というのが今回のポイントです。1 と 2 は仕組みとしてはまだ残っている。新規で始められるのは"セッション"であって、しかも「リポジトリがあるもの」に限定されている——ここが最初にわかっておくと、迷わなくなる肝です。

なぜかというと、スマホ発のセッションは Anthropic 管理のクラウド VM で走ります。この VM は毎回、指定した GitHub リポジトリを新規クローンして立ち上がる仕組みだからです。リポジトリを指定しないタスクは、そもそも VM が起動しない。「ちょっと調べ物」レベルの単発対話ならスマホの通常チャットで完結しますが、コードを触る新規タスクを立てるには、必ず GitHub リポジトリを 1 つ選ぶ必要があります。

2. スマホから新規セッションを立てる手順

拍子抜けするくらい単純です。

  1. iPhone の Claude アプリで 「Code」タブ を開く

  2. 画面下の入力欄の近くにあるリポジトリセレクタで GitHub リポジトリを選ぶ(初回は Claude GitHub App のインストールを求められます)

  3. ブランチを選ぶ(既定は main、必要なら feature ブランチ)

  4. タスクを 入力欄に書く

  5. 送信 → クラウド VM が起動して Claude が動き出す

タスク文の書き方は、CLI と同じ発想で問題ないです。ただしスマホから長文を打つのはつらいので、私は以下のような短いプロンプトのテンプレを頭に置いています。

[目的] <1 行で書く>
[対象] <ファイル or モジュール or 症状>
[進め方] まず現状把握 → 変更案を提示 → 私の承認後に実装
[制約] <あれば書く>
(図)4 ブロックの型。[目的]/[対象]/[進め方]/[制約]。特に「承認後に実装」は必須枠。

「承認後に実装」を入れておくのが大事です。スマホから離れている間に勝手にコミット・push まで走ってしまうと、後述する PC 引き取り時のトラブル に直結するんです。

送信すると、クラウド VM がリポジトリをクローンし、Claude が作業を始めます。スマホの画面から通知を切っておかない限り、途中経過や質問が push 通知で届く。移動中の電車の中でも、答えられる範囲で答えられるんです。この「席を立たなくてもいい」体験が、今回のいちばんの気持ちよさでした。

(図)iPhone の Code タブで GitHub リポジトリ + ブランチ + タスクを送信すると、Anthropic のクラウド VM が clone して走り出す。

3. 実運用で遭遇した 3 つの落とし穴

便利さと引き換えに、落とし穴も出てきます。私が実際にハマった順に 3 つ。

落とし穴 1: リポジトリ紐付けの限界

まずGitHub 必須です。GitLab や Bitbucket は「ローカルバンドル」としてアップロードすることはできるけど、結果をリモートに push し返せないんです。私の環境は GitHub なので直接の障害にはなっていませんが、他ホスティングだと現状かなり厳しい。

もうひとつ、Claude GitHub App の権限を付与済みなのに、リポジトリセレクタに何も出てこない、というバグ報告があります。App の再インストールで直ることが多いようです。

そして意外と忘れがちなのが、ローカルの未 push コミットは VM に届かない、ということ。VM は GitHub からクローンするので、あなたの PC のディスク上にしかない変更は、そもそも見えていないんです。スマホから新規セッションを立てる前に、PC で作業中のブランチを push してあるかを一度確認しておく。それだけで、ズレを防げます。

(図)リポジトリの持ち先で、できることが変わる。GitHub は往復可、GitLab/Bitbucket は bundle 送るのみで push は戻せない、ローカル未 push コミットは VM に届かない。


落とし穴 2: コンテキストウィンドウを気にし続ける必要が、まだある

痛かったこと 2 と同じ話です。同一セッション内で意思決定を続けていると、履歴が長くなって Claude の判断が鈍り始めます。スマホでは PC のように「何%消費」のような可視化が弱いので、感覚で判断せざるを得ない。

私は目安として、「同じセッションの中で、話題が 3 回大きく切り替わったら別セッション化を検討する」というルールを緩く決めています。厳密ではないですが、行き詰まる前に区切れる回数の目安として、それなりに役に立っています。区切るときは、いったん「ここまでの決定と残タスクを 5 行で要約して」と Claude 自身に頼んでから、その要約を新規セッションの冒頭に貼って再スタートする。この受け渡しは、慣れると 30 秒くらいで済みます。

落とし穴 3: スマホ指示が反映しきる前に、PC で作業を再開する

これが今回、この記事を書きたくなった直接の理由です。

私が実際に踏んだ順序はこうでした。

  1. 外出中に iPhone の Code タブから、あるリポジトリに変更指示を投げる

  2. 移動が忙しくて、通知に気付かないまま帰宅

  3. 完了通知が来ているか確認せず、PC を立ち上げて CLI で作業再開しようとする

  4. スマホ側でも同時に「その続き」の追加指示を追いかけで送る

  5. PC でも同じブランチを触り始める

  6. なんとなくおかしな挙動が始まる。git の競合ではない。コミットは残っていて、ブランチは切り替わっていて、git status はきれい。なのに動作が変


(図)私が実際にハマった時系列。13:00 と 13:05 の同時発火ゾーンで、"git 競合以外のバグ" が生まれた。


git status はきれいなのに動作がおかしい——これが、いちばん不気味でした。競合していれば git が教えてくれます。競合していないのに壊れているとき、どこを疑えばいいのかが分からない。私はこのとき、原因を探すのに数十分溶かしました

正確な発症条件はまだ再現途上ですが、体感の仮説は 3 つあります。

  • スマホ発セッションが VM 上でまだ走行中で、遅れて push が飛んできて、PC 側のローカルコミット順序と噛み合わなくなった

  • 同時に PC でも指示を出したことで、両方の指示が別々の判断で同じファイルを触った(結果、機能としては壊れているのに git 上は綺麗に残る)

  • VM 内でインストールされた依存パッケージが、ローカルに反映されていない状態でテストを回したので、動作結果だけが不整合になった

3 つのどれもクラッシュに直結する組み合わせを持っていて、正確にいうと「クラッシュ」というよりも「同じブランチが 2 つの意思で書き換えられた結果、想定と違う実装になり、後段でクラッシュする」に近い挙動でした。


(図)なぜ動作が変になるのか、3 仮説カード。①VM 遅延 push ②同時タッチ ③依存の非対称。実際は 3 つがからみ合って発症している気配。

原因追跡は途中で諦めたんです。代わりに運用ルールを厳格にしました。スマホから指示を出したら、必ず「完了通知」を待ってから PC を触る。この 1 つで、再発は今のところ止まっています。

4. スマホ発を、PC の CLI で引き取る 4 ステップ

ここからがこの記事の核です。

「スマホで立てた新規セッションの続きを、PC の CLI でやりたい」ときに、私が実際にやっている 4 ステップを置いておきます。

STEP 1: スマホ側の終了時に、必ずやること

  • タスクを 明示的に「完了」or「一旦ここまで」で締める(Claude に「ここまでの結果をコミットして push してください」と伝えて、確認を待つ)

  • push 通知が来るまで PC を触らない(何度書いてもいいくらい、これが最重要です)

  • 作業ブランチ名を メモしておく(自動生成の場合 claude/<slug> 形式が多い)

  • クラウドセッション自体は「終了」ではなく、開いたまま放置しておく(VM 上のセッションは、あとで --teleport で引き取る際にまだ生きている必要があるんです)

STEP 2: PC 側の cwd 選択

CLI を立ち上げるときの 作業ディレクトリ(cwd) の選び方が、意外と大事です。

  • リポジトリはローカルに事前 clone しておく(git clone <repo-url> <path>)

  • Windows と Mac の両方で作業するなら、同じ絶対パスに clone しておくと、あとから --resume の相性がよくなります(余談ですが --cwd フラグは存在しないんです。「使え」と Claude 自身が誤誘導してくる報告もあるので、鵜呑みにしないほうがいい)

  • claude を起動するときの cwd は必ずリポジトリのルートを指す(サブディレクトリではダメ)

ここで判断が分かれるのは、新規 clone するか、既存の clone に fetch するかです。私はケースバイケースで使い分けています。

  • 新規 clone を選ぶとき: そのリポジトリを PC で触るのが初めて/過去にいじった残骸が残っていて綺麗にしたい/ディスク余裕あり

  • 既存 clone に fetch を選ぶとき: すでに main を追いかけている/既存の worktree が複数ある/ディスクを増やしたくない

どちらの場合も、cwd はリポジトリルートで claude を起動し、次のステップで Claude 自身に fetch/switch を頼みます。


(図)STEP 3-4: 完了通知が来たらブランチ名をメモ、PC で cwd = リポジトリのルートで claude 起動、定型文 A/B/C を投げて着地。

STEP 3: pull 依頼の定型文 3 種

CLI 起動直後に投げるプロンプト定型文を、私は 3 種類使い分けています。全部載せます(末尾にコピー用ボックスも再掲します)。

定型文 A: 完全同期優先型(一番安全、時間かかる)

これから PC で作業を再開します。まずは現状把握からお願いします。

1. `git fetch --all --prune` を実行して、リモートの状態を最新化してください
2. `git status` と `git log --oneline -10` を出力して、ローカルとリモートの差分を教えてください
3. スマホ発セッションで作業したブランチは `claude/<slug>`(実際のブランチ名: <ここに埋める>)です。それに `git switch` してください
4. ローカルに未 push の変更が残っていたら、まず `git stash push -m "before mobile handoff"` で退避してください
5. 反映が確認できたら、続きのタスクを教えてくれるので待ってください

定型文 B: モバイル状態確認 → 引き取り型(実運用の主力)

このリポジトリで、直前にスマホの Claude Code で作業していた続きをやります。

- ブランチ名: claude/<slug>
- 最後にスマホで出した指示: <ここに簡潔に書く>
- 私が期待している変更: <ここに 1〜2 行>

以下を順に実行してください。

1. `git fetch origin claude/<slug>`
2. `git switch claude/<slug>`
3. 最新コミットの内容(`git log -3` と `git diff HEAD~1`)を出力
4. スマホで出した指示が反映されているか判定してください。反映が不十分なら「未反映」と言ってください
5. 反映済みなら次のタスクを聞いてください。未反映なら、なぜそう判断したかを説明してください

定型文 C: teleport 型(会話履歴ごと引き取りたい)

クラウドセッション <session-id> を CLI に引き取りたいです。

1. まず `git status` を確認してください。未コミット変更があれば `git stash push -m "pre-teleport"` で退避
2. `/teleport <session-id>` を実行
3. 成功したら、現在の会話履歴の最後 3 ターンを要約してください
4. 失敗したらエラーメッセージをそのまま共有してください(`--rewind` の可否も含めて判断します)

使い分け:

  • 「時間の余裕はある、事故は絶対に嫌」→ A

  • 「効率よく引き取って続きに入りたい」→ B

  • 「クラウド側の会話履歴も含めて引き継ぎたい」→ C


(図)定型文の使い分け決定木。迷ったら B から。
Q1「会話履歴も持ち帰りたい?」→ Yes なら C、No なら Q2 へ。
Q2「事故を絶対避けたい?」→ Yes なら A、No なら B。

teleport(定型文 C)は便利な反面、直後に tool use concurrency の API 400 エラーが出る体験談も報告されています。エラー時は /rewind を試す、それでもダメなら会話は諦めて定型文 B に切り替える、というフォールバック順で私は使っています。

コツは、AT-009 の記事にも書きましたが、「判定基準を先に渡しておく」こと。定型文 B の「反映が不十分なら『未反映』と言ってください」の一行が、それです。Claude が「たぶん反映されてます」で流してしまうのを防げます。

STEP 4: 引き取り後のバグ確認チェックリスト

引き取ったあと、すぐに実装に手を出さず、以下を確認してから次のタスクに移ります。

  • コミットログが期待通りに進んでいるか(git log --oneline -10)

  • CI が通っているか(GitHub 側の Actions を確認)

  • ローカルでテストを回してみる(npm test / pytest / cargo test など)

  • VM 側でインストールされた依存が、ローカルに反映されているかを確認(package.json / pyproject.toml の diff を見て、必要なら npm install / uv sync を実行)

この 4 つ目が、落とし穴 3 の「git 競合以外のバグ」を防ぐいちばんの砦でした。VM が入れたパッケージが、あなたのローカルには入っていない。この単純な非対称性を忘れると、原因不明のクラッシュに数十分溶かします。私自身、この 4 つ目に気づくまで、何度か同じ穴にはまりました。

5. それでも、まだ痛いところ

正直に書きます。この運用でも、以下は詰まりやすい部分として残っています。

  • CLI で始めたセッションをクラウドに送る「逆 teleport」がまだない。CLI で書き始めた作業を、外出中にスマホで続けたいとき、いまだに手動で状況を要約して新規クラウドセッションに貼り直すしかないんです

  • --cwd フラグは存在しないのに、Claude 自身が「使え」と誤誘導してくる報告があります。回避策はやはり「セッション作成時と同じディレクトリから --resume する」以外にありません

  • スマホの完了通知の粒度が粗い。「push しました」と「タスク完了しました」が混ざっていて、後者を信頼しきれないことがある

  • コンテキストウィンドウの残量表示がスマホでは薄い。長時間のスマホ運用では、「あれ、そろそろ切ったほうがいいかな」の判断が経験頼みになります

  • Web セッション中に GitHub push が突然 403 になる体験報告もあります(OAuth OK でも GitHub App のインストールが未完了だと発症する)

これらは Anthropic の週次アップデートを追いかけていると、少しずつ埋まってきています。「いつの間にか、また改善されていた」の連続なので、しばらく追いつづける価値はあります。

6. 鉄則ひとつ:「クラウドで走らせている間は、PC を触らない」

スマホから新規セッションを立てられるようになったのは、明らかに大きな変化です。移動中に「あの直しは今 30 分でできるはず」と思えたら、そのまま Claude に投げて席を立たなくてよくなった。

その便利さと引き換えに、同時に触るべきでない場面が生まれました。私が今回書きたかった、いちばん大事な鉄則はこれだけです。

(図)鉄則の看板。ひとつだけ覚えて帰ってほしいのが、これ。わかりますか?
「クラウドで走らせている間は、PC を触らない」

クラウドで走らせている間は、PC を触らない


これを守れば、git の競合以外のバグの多くは避けられます。そのうえで、PC で引き取るときは定型文で迷わない状態を作っておく。この 2 つのセットが、今の私の運用です。

「いつの間にか、スマホで新規セッションが立てられるようになっていた」——そう思ったのが、たぶん半分の人がまだ気づいていないところで、半分の人はすでにハマっているところ。もし後者だったら、この記事のどこかが役に立てば嬉しいです。


7. おまけ ── pull 依頼の定型文 3 種(コピー用)

定型文 A: 完全同期優先型

これから PC で作業を再開します。まずは現状把握からお願いします。

1. `git fetch --all --prune` を実行して、リモートの状態を最新化してください
2. `git status` と `git log --oneline -10` を出力して、ローカルとリモートの差分を教えてください
3. スマホ発セッションで作業したブランチは `claude/<slug>`(実際のブランチ名: <ここに埋める>)です。それに `git switch` してください
4. ローカルに未 push の変更が残っていたら、まず `git stash push -m "before mobile handoff"` で退避してください
5. 反映が確認できたら、続きのタスクを教えてくれるので待ってください

定型文 B: モバイル状態確認 → 引き取り型

このリポジトリで、直前にスマホの Claude Code で作業していた続きをやります。

- ブランチ名: claude/<slug>
- 最後にスマホで出した指示: <ここに簡潔に書く>
- 私が期待している変更: <ここに 1〜2 行>

以下を順に実行してください。

1. `git fetch origin claude/<slug>`
2. `git switch claude/<slug>`
3. 最新コミットの内容(`git log -3` と `git diff HEAD~1`)を出力
4. スマホで出した指示が反映されているか判定してください。反映が不十分なら「未反映」と言ってください
5. 反映済みなら次のタスクを聞いてください。未反映なら、なぜそう判断したかを説明してください

定型文 C: teleport 型

クラウドセッション <session-id> を CLI に引き取りたいです。

1. まず `git status` を確認してください。未コミット変更があれば `git stash push -m "pre-teleport"` で退避
2. `/teleport <session-id>` を実行
3. 成功したら、現在の会話履歴の最後 3 ターンを要約してください
4. 失敗したらエラーメッセージをそのまま共有してください(`--rewind` の可否も含めて判断します)

※これらの定型文は、私の環境(Claude Code CLI + Windows + iPhone Claude アプリ)でうまくいったものです。多少環境が違っても、AI は賢いので、ご自身の環境への微調整は容易かと思います。コツは、<slug> と <session-id> を埋めて、判定基準(「反映が不十分なら『未反映』と言ってください」の類)を必ず一言足すこと。うまくいかなかったら、私に教えてください。


このnoteは「Okeya Graph」の 9 本目 です。
{既刊記事へのリンク(HEP 手動)}
AIを毎日触って、引っかかったところを淡々と。
今回は「クラウドで走らせている間は、PCを触らない、という話」でした。


#Claude #ClaudeCode #AI活用 #iPhone #Anthropic #生産性 #開発ワークフロー

いいなと思ったら応援しよう!