Claude Code Ultraplan実践ガイド — クラウド計画×ローカル実行で大規模リファクタリングを安全に進める

claude -p で自律開発デーモンを24時間回していると、計画フェーズでターミナルが10分以上占有されるのが地味に痛い。「計画が終わるまで別のタスクに手を付けられない」——CLI中心の開発者なら一度は感じたことがあるはずだ。

4月にresearch previewとしてリリースされた「Ultraplan」は、計画だけをクラウドのOpus 4.6に委譲し、ターミナルを即座に解放してくれる機能だ。本記事では /ultraplan の基本操作から、teleportとクラウドPR作成の判断フロー、既存Plan modeとの棲み分け、30分制限下でのタスク分割戦略まで、実際に試した結果をコード付きで紹介する。

Ultraplanとは何か — 従来の/planとの根本的な違い

計画フェーズをクラウドに委譲する発想

従来の /plan コマンドは、ローカルのClaude Codeセッション内で計画を生成する。計画の品質自体は高いが、生成中はターミナルが完全に占有される。大規模なリファクタリングの場合、計画だけで10〜15分かかることも珍しくない。

Ultraplanはこの問題をシンプルに解決する。計画生成をクラウド環境上のOpus 4.6に委譲し、ローカルのターミナルは即座に解放される。計画生成はクラウド側で行われるため、ローカルマシンのリソースを一切消費しない。

/plan vs /ultraplan：ローカル占有 vs ターミナル解放

以下の比較表で、計画に関わる4つの機能の棲み分けを整理する。

# 従来の /plan — 計画完了までターミナルが占有される
> /plan このモノレポのルーティング層を47ファイルからドメイン単位に再構成して

# Ultraplan — 即座にWebエディタURLが返り、ターミナルは自由に使える
> /ultraplan このモノレポのルーティング層を47ファイルからドメイン単位に再構成して
# → ブラウザでWebエディタが開き、計画の進行をリアルタイムで確認
# → ターミナルでは別の作業を継続可能

なお、Ultraplanの利用にはClaude Code v2.1.91以降に加え、Claude Code on the webアカウントとGitHubリポジトリが必要だ。claude --version で確認し、古い場合は claude update でアップデートしておこう。

起動から計画完成まで — 3つの起動方法と操作フロー

/ultraplanコマンド・キーワード・昇格ダイアログの使い分け

Ultraplanの起動方法は3つある。

1. /ultraplan コマンド直接入力 — 最も明示的。計画内容をそのまま引数として渡す
2. プロンプトに「ultraplan」キーワードを含める — 自然な会話の流れで起動できる
3. ローカル /plan の承認ダイアログから昇格 — まず /plan で始めて、規模が大きいと判断したらクラウドに切り替える

個人的には、最初から規模感がわかっているタスクは1番、試しに計画を見てから判断したい場合は3番を使うことが多い。

Webエディタでのインラインレビュー体験

起動後、ステータスが「◆ ultraplan ready」に変わったら、表示されるセッションリンクをブラウザで開く。計画の生成過程をリアルタイムで確認でき、インラインでコメントやフィードバックを入れることも可能だ。

サードパーティの解析によると、内部的には複数のA/Bテストバリアント（simple_plan、visual_plan、three_subagents_with_critiqueなど）が動的に割り当てられているとされる（公式ドキュメントには記載がなく、リークされたソースコード由来の情報である点に注意）。ユーザー側で選択することはできないが、マルチエージェント構成が割り当てられた場合、単一エージェントより網羅的な計画が生成される傾向がある。

計画が完了すると、2つの選択肢が提示される。

• Approve Claude's plan and start coding — クラウド上でそのまま実装し、PRを作成する
• Approve plan and teleport back to terminal — 計画をローカルに持ち帰り、手元で実行する

この判断が Ultraplan運用の最も重要なポイントなので、次のセクションで詳しく解説する。

teleport vs クラウドPR作成 — 判断フローチャート

クラウド実行が適するケース

クラウド実行→PR作成は、以下の条件を満たすタスクに最適だ。

• ビルド・テストが自己完結する（外部サービスへの接続が不要）
• ローカル環境固有の依存がない（特定のDBファイルや環境変数に依存しない）
• 独立性の高いリファクタリング（型定義の整理、命名規則の統一など）

teleportが適するケース

一方、以下のケースではteleportでローカルに持ち帰るべきだ。

• ローカルDB（SQLite）を使うテスト — クラウド環境上にはローカルのDBファイルがない
• 環境変数に依存する処理 — .env はスナップショットに含まれないことがある
• 段階的に動作確認したいUI変更 — ブラウザで逐次確認しながら進めたい場合

teleport後は3つの選択肢が表示される。

? What would you like to do with the plan?
❯ Implement here          — このターミナルで計画を実行
  Start new session       — 新しいセッションで実行
  Cancel                  — 計画をファイルとして保存して終了

実体験として、自律開発デーモンの daemon.ts を大規模リファクタリングした際、Ultraplanで計画を生成してからteleportでローカル実行した。理由は単純で、SQLiteのDBファイルやSlack Webhook用の環境変数がローカルにしかなかったからだ。計画自体はクラウドのOpus 4.6が15分かけて生成してくれたが、その間ターミナルでは別のバグ修正を進められた。正直、この体験だけでUltraplanの価値を実感した。

判断フローチャート

graph TD
    A[Ultraplanで計画完成] --> B{ローカルDB・環境変数に依存する?}
    B -->|Yes| C[teleport → ローカル実行]
    B -->|No| D{段階的な動作確認が必要?}
    D -->|Yes| C
    D -->|No| E{ビルド・テストが自己完結する?}
    E -->|Yes| F[クラウド実行 → PR作成]
    E -->|No| C

30分制限下でのタスク分割戦略

research previewの制約を理解する

research preview段階でのUltraplanには、いくつかの制約がある。

• 30分のセッション制限 — 計画生成＋実行（クラウド実行の場合）を合わせて30分が上限
• Remote Controlとの排他制御 — Ultraplan実行中はリモート操作ができない
• スナップショットベース — 計画生成中にローカルで行ったファイル変更は、クラウド側には反映されない

大規模タスクを30分単位に分割する実践テクニック

47のルート定義を持つモノレポをドメイン単位で再構成した際、以下のように3回のUltraplanセッションに分割して進めた。

# 1回目：全体設計 + 共通基盤（30分以内で完了する粒度に絞る）
> /ultraplan
ルーティング層の再構成計画を立てて。
スコープ: 全体のディレクトリ構造設計と共通ユーティリティの抽出のみ。
個別ドメインの移行は後続セッションで行う。
現状: src/routes/ に47ファイルがフラットに配置されている。

# 2回目：認証・ユーザードメインの移行
> /ultraplan
前回の計画で決定したディレクトリ構造に従い、
認証系（auth-*.ts, session-*.ts）とユーザー系（user-*.ts, profile-*.ts）の
ルートを src/routes/auth/ と src/routes/user/ に移行して。
共通ユーティリティは src/routes/shared/ に抽出済み。

# 3回目：残りのドメイン移行
> /ultraplan
残りのルート（payment-*, order-*, admin-*）を
それぞれ src/routes/payment/, src/routes/order/, src/routes/admin/ に移行して。
前2回で確立したパターンに従うこと。

ポイントは「1回目で全体設計を固め、2回目以降はドメイン単位で独立実行する」という構造にすることだ。各セッションが自己完結するようスコープを切れば、30分制限に収まりやすい。

ハマりポイントと回避策

よくあるエラーと対処法

バージョン不足

# まずバージョンを確認
claude --version
# v2.1.91未満の場合
claude update

gitリポジトリでない場合

クラウド実行にはgitが必須だ。リポジトリが未初期化の場合、git init してからUltraplanを起動すること。

既知の制約とワークアラウンド

スナップショット転送が遅い場合

大きなリポジトリでは、クラウドへのスナップショット転送に時間がかかることがある。.claudeignore で不要なファイルを除外すると改善する。

# .claudeignore
node_modules/
data/
logs/
*.db
.next/
dist/
coverage/

Webエディタでの編集タイミング

Webエディタ上で計画にフィードバックを入れる場合、計画生成が完了してから編集すること。生成中に編集すると、変更が上書きされる場合がある。

research previewの注意点

この機能はresearch preview段階であり、仕様や制約は予告なく変更される可能性がある。本記事の内容も、今後のアップデートで変わりうる点は留意してほしい。

まとめ

Ultraplanは「計画はクラウドに任せ、ターミナルは手元で使い続ける」というシンプルな発想の機能だが、CLI中心の開発者にとっては作業フローを根本から変える可能性がある。特に大規模リファクタリングやモノレポの構造変更など、計画だけで10分以上かかるタスクでは効果が大きい。

ただしresearch preview段階であり、30分制限やRemote Controlとの排他制御など制約も残る。まずは影響範囲の小さいリファクタリングで試し、本記事の判断フローチャートを参考にteleportとクラウドPRを使い分けていくのがおすすめだ。