Claude Code /ultraplanの使い方と/planとの違い -- 実務で使って分かった判断基準

コードをかかないAIエンジニア

2026/04/11

はじめまして、もるふぉです。

エンジニアをやりながら、今はほぼコードを書かない開発スタイルに移行しました。

「書けないから書かない」じゃなくて、「書けるから書かなくていい」という話です。

実案件ベースで気づいたことだけ書いています。

よければXもフォローしてもらえると嬉しいです → X(@morphox_ai)

Claude Code /ultraplanの話をします。

/planを実行したまま、Slackの返信もできずにターミナルを眺めたことありませんか？

「計画中だからちょっと待ってください」って言いながら、コーヒー入れに行って戻ってきても、まだ動いてる。

大きめのタスクほど待ち時間が長くなって、あの地味なストレスが積み重なっていく感じ、Claude Codeユーザーなら一度は経験しているはずです。

Claude Code /ultraplanは、その問題にドストレートに答えてくれるコマンドです。

計画生成をクラウドに渡して、手元のターミナルを即座に解放してくれます。

今回は/planとの違いや使い分けの判断基準、実務での使いどころを整理します。

Claude Code /ultraplanとは何か -- クラウドで計画を立てる新コマンド

まず前提として、ultraplanはv2.1.91以降で使えるリサーチプレビュー機能です。

ざっくり言うと「CLIで入力した計画タスクを、Claude Code on the webに飛ばしてクラウド上で計画を生成する」仕組みです。

ここで大事なのが、ultraplanは単なる「/planのクラウド版」ではないということ。

/planがターミナル内で完結する計画モードなのに対して、ultraplanはCLIとWebを橋渡しする計画モードです。

計画はブラウザ上で表示されて、インラインコメントや絵文字リアクションでレビューできます。

作った計画をWebでそのまま実装に進めることも、ターミナルに戻して手元で実装することもできます。

この「計画と実装の場所を分離できる」のが、/planとの根本的な違いです。

/planと/ultraplanの本質的な違い -- ローカル vs クラウドの分岐点

両者の違いを表にまとめるとこうなります。

項目

/plan

/ultraplan

計画の実行場所

ローカルターミナル

クラウド（Claude Code on the web）

計画中のターミナル

占有される

解放される

計画のレビュー方法

CLIでの承認/拒否

ブラウザでインラインコメント・絵文字

実装先の選択

そのままターミナルで実行

Web実行 or ターミナル返却を選択可能

即時性

高い（すぐ対話できる）

やや低い（ブラウザに移動が必要）

チームレビュー

難しい

URLを共有すれば可能

一番目を引くのは「計画中のターミナル」の行だと思います。

ここが、ultraplanの本質です。

ターミナルが解放される本当の価値

/planで大きめのタスクの計画を立てると、10分から30分程度かかるケースも想定されます。

その間、ターミナルは完全に占有されます。

「別のターミナルを開けばいいじゃん」と思いますよね。

確かにそうなんですが、Claude Codeのセッションが動いているターミナルでそのまま別の作業を進めたいケースって実は多いんです。

PRレビューのためにgit diffを確認したい、別ブランチで急ぎのバグ修正を入れたい、テストを流したい。

こういう「計画待ちのアイドルタイム」がultraplanだとゼロになります。

計画はクラウドで進めてもらって、手元のターミナルは自由に使える。

いわばクラウドを「計画専用の別スタッフ」に任せて、自分は手元の作業に集中し続けられる感覚です。

これだけで開発のリズムが変わります。

次は、ultraplanが単なる「ターミナル解放ツール」以上の存在である理由をブラウザ側の体験から見ていきます。

ブラウザレビュー機能 -- ultraplan計画をインタラクティブに磨く

ultraplanの差別化ポイントは、ターミナルの解放だけじゃないんですよ。

ブラウザ上でのリッチなレビュー体験が、もう一本の柱です。

/planだとCLI上で「承認する/しない」の二択しかありませんが、ultraplanは計画の中身に対してもっと細かいフィードバックができます。

ultraplanのインラインコメントと絵文字リアクションの使い方

ブラウザに表示された計画に対して、以下の操作ができます。

インラインコメント: 計画の任意の箇所にコメントを残せる
絵文字リアクション: 承認・懸念のシグナルを送れる
アウトラインサイドバー: セクション間をジャンプして全体を俯瞰
イテレーション: コメントをもとにClaudeが計画を修正、何度でも繰り返し可能

想像してみてください。

「このマイグレーションの順序、先にインデックス貼ってからデータ移行のほうがよくない？」というピンポイントのフィードバックを、計画の該当行に直接書き込めます。

/planだと「全体として承認するけど、ここだけ直してほしい」を伝えるのが面倒でした。

ultraplanならその「ここだけ」をインラインで指定できる。

コードレビューでPRの特定行にコメントを残す感覚、あれをそのまま計画レビューに持ち込めるわけです。

承認後の2つの選択肢 -- Webで実装 or ターミナルに戻す

計画のレビューが終わったら、実行先を選びます。

ここに2つの分岐があります。

Web実行を選ぶ場合

「Approve Claude's plan and start coding」を選択します。

同じクラウドセッションでそのまま実装が始まります。

実装が完了するとdiffがブラウザに表示されて、そのままPR作成まで進めます。

ブラウザで完結させたい場合に便利です。

ターミナルに返却する場合

「Approve plan and teleport back to terminal」を選択します。

するとCLI側に戻されて、3つの選択肢が表示されます。

Implement here: 現在の会話に計画を注入して、そのまま実装を続行
Start new session: 計画だけをコンテキストに持った新規セッションを開始
Cancel: 計画をファイルに保存して終了（ファイルパスが表示される）

実務では「Implement here」を選ぶケースが多いでしょう。

ultraplanで練り上げた計画を、慣れたターミナル環境でそのまま実装に移せるのが気持ちいいですよ。

「Start new session」はコンテキストが重くなっているときに有効です。

計画だけをクリーンなセッションに持ち込めるので、実装時のトークン効率が上がります。

「Cancel」を選ぶと計画がローカルファイルに保存されて、パスが表示されます。

なお、「Start new session」では claude --resume コマンドが表示されるので、必要であれば前の会話に戻ることもできます。

この体験を実際に動かすには、起動方法を知っておく必要があります。

3パターンあるので、状況に応じて使い分けてみてください。

Claude Code /ultraplanの3つの起動方法と使い方

ultraplanの起動方法は3パターンあります。

状況に応じて使い分けられるので、全部覚えておくと便利です。

/ultraplanコマンドで直接起動する

一番シンプルな方法です。

CLIで/ultraplanと打って、続けてプロンプトを入力します。

/ultraplan migrate the auth service from sessions to JWTs

実行すると、起動前に確認ダイアログが表示されます。

確認後、CLIにステータスが表示されます。

ステータス表示

意味

◇ ultraplan

コードベースを調査中・計画を作成中

◇ ultraplan needs your input

Claudeから質問あり。ブラウザで確認

◆ ultraplan ready

計画のレビュー準備が完了

needs your inputが出たらブラウザに移動して質問に答えます。

readyになったらブラウザで計画をレビューできます。

ここ、ちょっと注目してください。

ステータスが変わるまでの間、ターミナルは自由に使えます。

計画の進行状況を横目で確認しながら、普通にコマンドを打ち続けられるわけです。

プロンプトにultraplanキーワードを含める方法

コマンドを覚えなくても使えるのがこの方法です。

プロンプトの中に「ultraplan」というキーワードを含めるだけで、自動的にultraplanモードになります。

認証サービスのセッション管理をJWTに移行する計画をultraplanで立てて

こちらも起動前に確認ダイアログが表示されます。

「え、それだけ？」って思いますよね。

本当にそれだけです。

スラッシュコマンドの存在を忘れていても、自然言語の中にキーワードを混ぜるだけで起動するのは気が利いています。

ローカル/planからultraplanに切り替える

実務で一番使いやすいと感じるのがこのパターンです。

まず普通に/planで計画を立て始めます。

計画が出てきて承認を求められたときに、「No, refine with Ultraplan on Claude Code on the web」という選択肢が表示されます。

これを選ぶと、ローカルで作った計画がクラウドに引き継がれて、ブラウザ上でさらに練り直せます。

このフローの何がいいかというと、最初から「ultraplanで行くぞ」と決めなくていいことです。

まず/planでサクッと計画を出す。

出てきた計画を見て「これはもっと練りたいな」と思ったらultraplanに切り替える。

なお、/planからの切り替えではダイアログは表示されません。

選択自体が確認として機能する仕組みです。

既存の/planワークフローを崩さずに、必要なときだけultraplanにエスカレーションできるのが実務的に使いやすいです。

起動方法がわかったところで、「じゃあどっちを使えばいいの？」という判断基準を整理します。

実務での使い分け判断基準 -- /planとultraplanどちらを選ぶか

「大きいタスクならultraplan」と単純に言い切りたいところですが、実際はそう簡単ではありません。

タスクの性質、チーム状況、環境制約を掛け合わせて判断する必要があります。

/planで十分なケース

以下に当てはまるなら、/planのほうが向いています。

5分以内に終わる計画: 小〜中規模のタスクなら、わざわざクラウドに飛ばすオーバーヘッドが無駄です。ターミナル内でサクッと計画を立てて、そのまま実装に入るほうが速い
対話的にすぐ修正したい: 計画を見て「ここ違う」とすぐフィードバックしたいとき。/planならCLI上で即座にやりとりできます
Bedrock / Vertex AI / Foundry環境: これらの環境ではultraplanがそもそも使えません。この場合は/plan一択です

ポイントは「即時性」です。

パッと計画を立てて、パッと直して、パッと実装に入る。

このスピード感が欲しいときは/planが最適です。

ultraplanが本領を発揮するケース

逆に、ultraplanが輝くのはこういう場面です。

計画に10分以上かかりそうな大規模タスク: 大規模リファクタリング、DB設計変更、マイクロサービス分割など。計画待ちの間にターミナルを使えるのが決定的に違います
チームメンバーに計画をレビューしてもらいたい: ブラウザ上の計画URLを共有すれば、インラインコメントでフィードバックをもらえます。設計レビューのフローに組み込めます
計画待ちの間に他の作業を進めたい: PRレビュー、別ブランチの修正、テスト実行。マルチタスクで動いている人ほどultraplanのメリットを感じるはずです

シンプルに判断するなら、「この計画、5分で終わる？」という問いが基準になります。

Yesなら/plan、Noならultraplanです。

ただ、ultraplanには制限もあります。

「自分の環境で使えるのか」を確認するために、次のセクションは必ず読んでおいてください。