Claude Code Ultraplan 完全ガイド：クラウドプランニングのコスト・フロー・実際の使用体験

ターミナルでリファクタリングのコマンドを入力する。Claudeが考え始める。3分が経つ。5分が経つ。ターミナルはロックされたまま——何もできない。新しいタブで別のセッションを開く？コンテキストが切れるかもしれない。このまま待つ？時間だけが過ぎていく。

これはClaude Codeを使うすべての人が経験する問題です。2026年4月、AnthropicはUltraplanをリリースしました。プランニング作業をクラウドのCloud Container Runtimeにオフロードし、ターミナルを即座に解放する機能です。プランが完成すると、ブラウザでGitHub PRレビューに似たインターフェースでセクションごとに確認できます。私たちの編集部はClaude Codeを毎日使っています——リサーチ・執筆・レビューを担うエージェントフリートを運用しています。この記事では実際のユーザー視点からUltraplanを解説します：実際の仕組み、本当のコスト、使う価値がある状況、逆に無駄になる状況を詳しく見ていきます。

TL;DR

• UltraplanはプランニングをCloud Container Runtimeにオフロードします。ターミナルは自由なまま。プランが完成したらブラウザで確認できます
• コストはサブスクリプションのセッションクォータから消費されます（別途課金なし）。完全なセッション（失敗＋プラン＋修正）で5時間クォータの約33%を消費
• 最良のワークフロー：まずローカルのplan modeで素早くドラフト→方向性を確認してから「Refine with Ultraplan」でクラウドに格上げ
• 必要条件：GitHubリポジトリ、v2.1.91以上、ProまたはMaxサブスクリプション。Bedrock/Vertex/Foundry非対応。Remote Controlと同時使用不可

「より長く考える」のではなく「作業を続けさせる」機能

「UltraplanってClaudeがより長く考えられる機能じゃないの？」——これが最もよくある誤解です。

Ultraplanとは何か：UltraplanはClaude Codeのクラウドプランニング機能で、プランニング作業をローカルターミナルからAnthropicのCloud Container Runtimeに移します。クラウド上でリポジトリをクローンし、コンテキストを読み込み、プランを作成する間、ターミナルは完全に自由なままです。プランが完成すると、claude.ai/codeのブラウザインターフェースでGitHub PRレビューに似た方法でセクションごとに確認できます。インラインコメント、絵文字リアクション、アウトラインサイドバーによるナビゲーションが利用できます。

重要なポイント：核心的な価値は「思考時間が長くなること」ではありません（最長30分実行できますが）。価値は2つあります。第一に、ターミナルの解放——第2セッションを開かずに、同じターミナルで別の作業を続けられます。第二に、レビュー体験の向上——ターミナルで200行のプランをスクロールして確認するのと、ブラウザの構造化インターフェースでセクションごとに確認するのは、まったく異なる体験です。

実際の使用経験から言うと、ローカルのplan modeで生成されたプランはターミナルでの確認が面倒なため「これで大丈夫そう」とそのまま実行してしまいがちです。Ultraplanのブラウザインターフェースを使うと、プランの問題点を早期に発見しやすくなり、後の修正コストを削減できます。

3つの起動方法と「ローカル優先・クラウド精査」のゴールデンワークフロー

Ultraplanには3つの起動パスがあり、それぞれ異なるシナリオに適しています。

1. /ultraplan <プロンプト>：直接コマンドを入力——Claudeがすぐにクラウドプランニングを開始します。何をすべきかがすでに明確な場合に最適です。
2. キーワードトリガー：通常のプロンプトに「ultraplan」を含めると、Claudeが自動的にクラウドプランニングモードに切り替わります。
3. ローカルプランからアップグレード：まずローカルのplan modeを実行し、プランを確認してから承認ダイアログで「Refine with Ultraplan on Claude Code on the web」を選択します。

実践者が最も推奨するのは第3の方法です。理由はシンプルです：ローカルのplan modeは速く、通常数秒から数分で結果が出ます。これで方向性を素早く確認し、「もう少し改善したい」と感じた時にクラウドでの高品質な反復に格上げします。この方法はセッションクォータを節約しながら、純粋なローカルプランニングよりも良いプランを得られます。

起動後、ターミナルにはステータスインジケーターが表示されます：◇ ultraplan（プランニング中）→◇ ultraplan needs your input（追加情報が必要）→◆ ultraplan ready（完了、確認可能）。完了するとclaude.ai/codeのレビューインターフェースに自動的に遷移します。

注意点として：ターミナルで作業を一気に進めるのが好みの場合、Ultraplanはその流れを中断します。この機能は「一時停止→確認→判断」という設計です。大規模なリファクタリングや複数ファイルにまたがるタスクに適しており、次のステップがすでに明確な小さな変更には向いていません。

プラン生成後に選べる3つの選択肢

Ultraplanのプラン生成が完了しても、自動的にコードが変更されるわけではありません。判断が必要です。

選択肢A：クラウド実行（Approve and start coding）。プランはAnthropicのクラウド環境で直接実行され、自動的にPRが作成されます。ローカルのツールチェーンへの依存がない、シンプルな環境に最適です。

選択肢B：ターミナルにテレポート（Approve plan and teleport back）。プランがローカルターミナルに転送され、自分の環境で実行できます。テレポート後、ターミナルには3つのサブオプションが表示されます：Implement here（今すぐ実行）、Start new session（新セッションで実行）、Cancel（プランをファイルとして保存して後で処理）。私たちのチームが最もよく使うパスです——エージェントフリートはローカルの設定ファイルとAPIキーへのアクセスが必要なためです。

選択肢C：Stop ultraplan。プランを破棄し、何も保存しません。

選び方の判断フレームワーク：

状況	推奨選択肢
標準的なNode.js/Pythonプロジェクト、直接PRを作成したい	クラウド実行
ローカルの.env、プライベートレジストリ、カスタムツールチェーンが必要	テレポート
プランに満足できない、プロンプトを見直したい	Stop

コストの実態：サブスクリプションクォータは「無料」ではない

「サブスクリプション制だからUltraplanを使っても余計なコストはかからない」——技術的には正しいですが、落とし穴があります。

Ultraplanのトークンはサブスクリプションのセッションクォータとしてカウントされます。Proプランの上限は5時間のアクティブ使用時間（待機時間ではない）で、Maxプランはより高い上限を持ちます。Ultraplanはこのクォータ内で動作し、別途課金はありません。聞こえは良いですが、Better Stackの実測レポートによると、「失敗＋プラン＋リビジョン」の完全なUltraplanセッションで5時間クォータの約33%を消費します。

内訳を見ると：初回プランニングが約15%、リビジョンが約18%です。プランが「もう少し」と感じて修正を要求するたびに、初回プランニング以上のクォータを消費します。プロンプトが曖昧であれば、午後に3回Ultraplanを実行するだけでクォータが底をつく可能性があります。

見落としやすいコストの細部が2点あります。

• Fast modeの落とし穴：Steve Kinneyの分析によると、fast modeは最初のトークンからextra usageとしてカウントされ、セッションクォータからではありません。fast modeを習慣的に使っている場合、Ultraplanのコストが予想より高くなります。
• Opus 4.6の大きなコンテキスト：Steve Kinneyの分析によると、ProプランでOpusを使って1Mコンテキストを処理するにはextra usageが必要です。大規模なリポジトリのUltraplanセッションではこの閾値に達しやすいです。

結論：精確な初期プロンプトが最も重要な最適化です。 Ultraplan内で何度も修正するより、開始前に5分かけて要件を明確にする方が効果的です。曖昧な要件でUltraplanを使うのは、最も高コストな方法で最も粗いプランを作ることに等しいです。

Ultraplanでハマるケース

使い始める前に知っておくべき制限があります。

スナップショット問題が最もよくある落とし穴です。 Ultraplanを起動すると、その時点のリモートリポジトリの状態がクローンされます。起動後にローカルで変更したコードは、クラウドのプランニングセッションには反映されません。30分作業していたのに、Ultraplanが作成したプランは30分前のコードをベースにしていた——というケースが発生します。対策：Ultraplanを起動する前にgit commit && git pushを実行してリモートを最新状態にしてください。

クラウド環境はあなたのラップトップではありません。 Cloud Container RuntimeはAnthropicが管理する環境で、カスタムイメージはサポートしていません。一部のパッケージマネージャー（例：Bun）はプロキシによってブロックされる可能性があります。プロジェクトが非標準ツールに依存している場合、クラウド実行が失敗する可能性があります。その場合はローカルへのテレポートが安全です。

Remote Controlとは同時使用できません。 Remote ControlとUltraplanはどちらもclaude.ai/codeのインターフェースを使用し、同時に使用できません。Remote Controlでコラボレーション中の場合は、Ultraplanを起動する前に終了する必要があります。

プラットフォームのハード制限：

• Amazon Bedrock、Google Cloud Vertex AI、Microsoft Foundryのユーザーは使用できません。UltraplanはAnthropicが管理するCloud Container Runtimeに依存しており、サードパーティのホスティングと互換性がありません。
• バージョン要件：v2.1.91以上が必須、自動クラウド環境作成機能にはv2.1.101以上が推奨。
• GitHubにホストされているリポジトリのみ対応。ローカルのみのリポジトリやGitLab/Bitbucketプロジェクトは現在サポートされていません。

リサーチプレビューの不確実性。 Ultraplanはまだリサーチプレビュー段階です。コミュニティではv2.1.92のバグが報告されており、ターミナルにテレポートした後にplan modeのconstraintsが機能しなくなる問題があります。機能は急速に改善されており、この記事を読む頃には修正済みかもしれません。

次のステップ：Ultrareviewとクラウドツールエコシステム

Ultraplanは単独の機能ではありません。2026年4月16日、Anthropicはv2.1.111で/ultrareviewを追加しました：クラウドでparallel multi-agentによるコードレビューを行う機能です。

この2つを組み合わせると：Ultraplanがプランニングを担当し、Ultrareviewがレビューを担当します。これはクラウドアシスト開発サイクルの雛形です。さらに先行してリリースされたRoutines（クラウドスケジューリング）と合わせると、AnthropicはClaude Codeを「ターミナル内のAIアシスタント」から「完全なクラウド開発プラットフォーム」へと移行させています。

インディー開発者や小規模チームにとって、この方向性は、ターミナルを常時監視することなく多くの開発ワークフローをクラウドで実行できることを意味します。Ultraplanがプランを立て、Routinesが実行をスケジュールし、Ultrareviewが結果を確認します。

しかし、これには実質的なトレードオフがあります：Anthropicのプラットフォームへの依存が深まります。セッションクォータ、クラウド環境の制約、GitHubとの結びつき——これらはワークフローに組み込まれるロックインポイントです。機能は強力ですが、全面的に採用する前に、出口戦略を考えておくことをおすすめします。

まとめ

UltraplanはAIの賢さの問題を解決するものではなく、「ターミナルでAIが何をしているか見えない」という問題を解決するものです。ブラウザのレビューインターフェースはターミナルのスクロールバックよりはるかに使いやすく、それだけで試してみる価値があります。

最も効果的な使い方は、毎回クラウドから始めることではありません：ローカルのplan modeで素早くドラフトを作り、方向性を確認してから「Refine with Ultraplan」で精度の高い反復に格上げする。このワークフローはクォータを節約しながら、純粋なローカルプランニングより高品質なプランを得られます。

ツールは常に更新され、バージョンは上がり続けます。しかし「まず素早く方向性を検証し、それから磨きをかける」という考え方は、Ultraplanに限らず、あらゆる場面で通用します。