はじめに
設計書を仕上げた夜、CTOへの説明資料を開くたびに手が止まる。この設計で本当に正しいのか。Slackに300字のレビューコメントを貼っても返ってくるのは「とりあえずLGTM」。その感覚に覚えがある人に、今日は話したい。
Claude Code Ultraplanは、実装に踏み切るための「確信」を、チーム全員で同時に得るための計画フェーズ機能だ。コマンド1行を入力すると、Opusがリポジトリ全体を約30分で分析し、実装計画をブラウザのWebUIに生成する。チームメンバーは場所を問わずそのURLを開き、計画の各ステップにインラインコメントを付けて議論できる。
Slackの長文レビューで「誰が何をどこまで読んだか分からない」状態が、それで終わる。
ローカルでの `/plan` コマンドを詳しく知りたい場合は当ブログのplan-mode記事を先に参照してほしい。
`/plan` との違い。何が変わったか
Ultraplanと従来の `/plan` は、使う場面が根本的に異なる。
| /plan（ローカル） | /ultraplan（クラウド） | |
|---|---|---|
| 実行場所 | ローカルターミナル | Anthropicクラウド |
| ターミナル占有 | される（待機必要） | されない（他作業可能） |
| レビュー方法 | テキスト出力を読む | ブラウザでインラインコメント |
| チーム共有 | テキストコピーが必要 | WebUI URLを共有するだけ |
| 修正指示 | 追加プロンプトで | 該当箇所に直接コメント |
| 実行先 | ローカルのみ | クラウド継続 or ローカルに「テレポート」 |
差分は「計画をチームに届ける」仕組みにある。従来の `/plan` は計画をターミナルに出力するだけで、チームに共有するには自分でコピーしてNotionやConfluenceに転記する必要があった。Ultraplanはその手間を省き、WebUIのURLを共有するだけで全員が同じ画面を見ながら議論できる。
headless-cicd記事で扱っているCI/CDパイプラインとも役割が異なる。Ultraplanは実装「前」の計画フェーズに特化した機能だ。
実際の動き方と「テレポート」
Step 1: CLIでコマンドを実行する
claude /ultraplan "認証フローをJWT→OAuth2に移行する"
これだけだ。実行後はターミナルが解放される。Opusがクラウドコンテナ上でリポジトリをクローンして分析を始めている間、ローカルで他の作業を続けられる。
Step 2: 30分待つ（ターミナルは自由）
Opusはコードベース全体を網羅的にスキャンし、サービス境界・依存関係・移行順序・リスクを含む実装計画をWebUIにドラフトする。計画の精度は、担当者の記憶や経験に頼った手動設計より見落としが少ない。コードベース全体を均等に読んでいるためだ。
「30分は長い」と感じる人もいるかもしれない。比較対象は手動で設計書を書く2〜4時間だ。しかもその30分の間、自分は別の仕事をしている。実質の待機コストはゼロに近い。
Step 3: ブラウザでチームレビュー
WebUIにアクセスすると、計画がセクション別に整理されている。任意のテキストを選択してコメントを追加でき、絵文字リアクションで承認・懸念を表明できる。アウトラインサイドバーでセクション間をジャンプできるため、自分の担当箇所だけを集中して確認することも可能だ。チームメンバーはスマートフォンからURLを開いてコメントを付けられる。
Slackで起きていた「誰が何をどこまで読んだか分からない」状態が消える。各ステップに誰がOKを出したかが全員に見える。これが確信をチームで同時に得る仕組みだ。
Step 4: 実装先を選ぶ
レビューと修正が終わったら、実行先を選択する。
- クラウドで実行：WebUI内でそのまま実装を開始し、PRの作成まで完了できる
- ローカルにテレポート：計画をローカルセッションに転送して、自分の環境で実装を続ける
Opusが生成した計画がクラウドからローカルに降りてくる感覚を「テレポート」と呼ぶことがある。計画フェーズをクラウドで済ませ、実装フェーズはローカルで継続する。この使い分けが自然にできる。
具体的なユースケース
大規模リファクタリングの計画
モノリシックAPIをマイクロサービスに分割する計画を `/ultraplan` に任せると、サービス境界・依存関係・移行順序・リスクが網羅された計画書が出てくる。EMがURLをチームに共有し、PM・シニアエンジニアが各自の懸念箇所にコメントを付けて一度のレビューサイクルで全員の合意を取る——そのための道具だ。
経営向け説明の根拠として使う
依存ライブラリの最新化計画をUltraplanに生成させると、CVEスコア・影響範囲・工数見積もりが含まれた計画書が届く。「AIが第三者的にコードベース全体を分析した結果」は、自分の判断だけを根拠にした資料より説明の土台が固い。
新機能の実装前レビュー
チェックアウトフローにStripe Elementsを統合する計画なら、UI変更・API設計・エラーハンドリング・テスト計画が自動生成される。フロントエンド担当とバックエンド担当がそれぞれ担当箇所にコメントを付け、計画承認後にクラウドでそのまま実装を開始できる。
設定要件・利用制限・よくある疑問
使い始める前に確認すること
- Claude Code v2.1.91以降が必要（出典: Claude Code公式ドキュメント。公式に明記がない場合は最新版を推奨）
- Pro/Max/Team/Enterpriseプランが対象
- **GitHubリポジトリ接続が必須**（プライベートリポジトリはGitHub App経由）
- リサーチプレビューのため、仕様は今後変更される可能性がある
トークン消費と利用プランの目安
UltraplanはOpus 4.6を最大30分使うため、通常のインタラクティブセッションよりトークン消費量が多い。Claude Codeは5時間ローリングウィンドウで利用枠を管理しており、OpusはSonnetの約1.7倍のコストがかかる。Proプランで1日1〜2回が現実的な目安で、頻繁に使う場合はMaxを検討したい。Ultraplan専用の実行回数制限は現時点で公式に確認できていないため、通常セッションの利用枠制限に準ずると考えておくのが無難だ（出典: Claude Help Center）。
よくある疑問
**Q: GitHubがないと使えない？**
現時点ではGitHubリポジトリ接続が必須だ。ローカルのみのプロジェクトには従来の `/plan` を使う（当ブログのplan-mode記事を参照）。
**Q: 計画の精度は信頼できる？**
コードベース全体をスキャンした上で生成するため、担当者の記憶に頼った手動計画より見落としが少ない。ただしWebUIでのレビューと修正ステップは必ずやること。Ultraplanはレビューをスキップするための道具ではなく、レビューを確実に行うための道具だ。
まとめ
今日、設計書を書き終えたら `/ultraplan` を1行打ってみる。CTOへの説明資料を作り直す時間が、その30分分だけ不要になる。
コメント