Claude Codeワークフロー — Ultraplan / Ultrareview / Checkpointingの使い分け

要点

Claude Codeのワークフロー機能は、2025年後半から2026年春にかけて一気に面が広がりました。/ultraplan による計画駆動、/ultrareview によるレビュー自動化、Checkpointingによる試行錯誤の巻き戻し、/code-review のPRレビュー統合、Routinesによる定型作業の自動化、そして /team-onboarding による組織導入支援。どれも単体では便利に見えますが、実運用では役割が重ならないように組み合わせることで初めて効果が出ます。以下では各機能を「いつ使うか」「何と組み合わせるか」の観点で整理し、最後に個人開発から中規模チームまでの運用パターンを3つ示します。

ワークフロー機能の全体像

まず、関連機能を「計画」「実行」「レビュー」「共有」の4層で俯瞰します。

この4層は独立した機能ではなく、前段の結果が次段の入力になります。計画が曖昧なまま実装を走らせるとCheckpointingの巻き戻し回数が増え、レビューが属人化するとTeam Onboardingが機能しません。以下、層ごとに実運用の勘所を見ていきます。

Ultraplan — 計画駆動

/ultraplan は、拡張思考を最大限使って実装前に計画を固めるためのコマンドです。Plan Mode(Shift+Tabで切り替え、または claude --permission-mode plan で起動)と近い役割ですが、Plan Modeが「読み取り専用で探索しながら計画を立てる」対話モードなのに対し、/ultraplan は現在の会話コンテキストを踏まえて一気に深い計画を出力させるワンショット的な使い方に向きます。

実運用では次のような場面で効きます。

• 複数ファイルにまたがる機能追加を始める前の設計叩き台
• 既存実装のリファクタリング方針を複数案検討したいとき
• 「やってみてから考える」が高コストな領域(認証、課金、マイグレーション)

計画の質を上げるコツは、プロンプト内で成功条件と制約を明示することです。「OAuth2へ移行したい」だけでなく、「既存セッションを破壊しない」「既存の AuthService の公開インターフェースは維持する」といった制約を添えると、計画の粒度が揃います。拡張思考はOpus 4.6 / Sonnet 4.6で適応的推論が効くため、/effort で努力レベルを上げるか、プロンプトに ultrathink を含めるとさらに深く考えさせられます。

計画ができたら、Ctrl+G でエディタに開いて直接編集してから承認する使い方が便利です。Claudeが立てた計画を人間が一度手で触ることで、責任の所在が「AIがやった」から「人間が承認した」に明確に移ります。スラッシュコマンド全体の頻度別整理はスラッシュコマンド実用集にまとめています。

Ultrareview — レビュー自動化

/ultrareview は、変更差分を拡張思考で精査し、バグ・セキュリティ・設計上の懸念を洗い出すためのコマンドです。/code-review や /review がより軽量な差分レビューであるのに対し、/ultrareview は時間をかけてでも重大な見落としを防ぎたい場面向けの位置付けです。

想定される使い分けは次のとおりです。

/ultrareview は拡張思考を前提にするため、トークン消費は大きめです。毎回使うのではなく、ブランチをマージする直前や、本番デプロイに直結するPRに絞ると費用対効果が合います。GitHub Actionsに組み込むなら、/code-review を全PRに、/ultrareview を needs-deep-review ラベル付きPRにだけ走らせる二段構成が現実的です。

また、Subagentと組み合わせると役割分担が明確になります。code-reviewer Subagentにセキュリティ観点だけを担当させ、本体のセッションでは機能実装を続ける、という並行運用が可能です。/ultrareview の追加経緯と当時の差分はv2.1.111のリリースノートで触れています。

Checkpointing — 試行錯誤の保存点

Checkpointingは、セッション中の状態を「保存点」として記録し、あとから戻れるようにする仕組みです。Gitのコミットと役割は似ていますが、コード変更だけでなく会話状態ごと巻き戻せる点が違います。/rewind でセッション内の過去地点に戻ったり、/branch で途中から分岐したりできます。

実装中の試行錯誤でよく起こる「この方向は違った、3ステップ前から別案で進めたい」という場面で威力を発揮します。Gitで戻せるのはファイルだけですが、CheckpointingはClaudeの判断履歴や調査済みの前提も一緒に戻るため、やり直しのコストがずっと軽くなります。

フォークされたセッションはルートセッションの下にグループ化されて /resume のピッカーに表示されるため、「案Aで進めたブランチ」「案Bで進めたブランチ」を並行管理しやすい構造です。ここにGitのWorktree(claude --worktree feature-auth) を重ねると、ファイルレベルの分岐とセッションレベルの分岐を同じ軸で扱えるようになります。

Checkpointingは「失敗してもいい」を前提にする仕組みなので、計画段階で想定しきれなかった選択肢を実装しながら比較検討できる余地が生まれます。/ultraplan で計画 → /rename でセッションに名前付け → 行き詰まったら /rewind か /branch → 完成したら /ultrareview という作業リズムが組み立てやすい形です。

Routines — 定型作業の自動化

Routinesは、毎回同じ手順で走らせたい作業をスクリプト化・スケジュール化する仕組みの総称です。Claude Codeでは次の層で実現できます。

• セッション内で繰り返す手順 → カスタムスラッシュコマンド(.claude/commands/)
• セッションを超えて自動実行 → /loop(現在のCLIセッション内ポーリング)
• マシンを超えて自動実行 → クラウドスケジュール済みタスク、デスクトップスケジュール済みタスク、GitHub Actions

スケジュールを選ぶ基準は「どこで実行する必要があるか」です。コミットされていない変更を触る必要があるならデスクトップ、PRイベントに反応させたいならGitHub Actions、コンピュータがオフでも回したいならクラウドスケジュール、という棲み分けになります。

Routines化する候補としては、次のような定型作業が典型です。

Routines設計の落とし穴は、自律実行されるプロンプトに曖昧さを残すことです。スケジュール実行中のClaudeは追加質問を返せないため、「成功の定義」「失敗時の行き先」「結果の通知先」を一つのプロンプトに畳み込む必要があります。Slackに要約を投げるのかIssueを立てるのかを明示することで、Routineがサイレントに壊れる事故を減らせます。

Team Onboarding — チームで共有する設計

/team-onboarding は、新規メンバーやチーム全体でClaude Codeを導入するときの初期設定を支援するコマンドです。個人の ~/.claude/ ではなく、プロジェクト配下の .claude/ をsource of truthにすることで、同じ設定・同じSkills・同じSubagentsをチーム全員が共有できます。

実運用で最低限揃えておきたいのは次の要素です。

• CLAUDE.md — プロジェクトの方針、書き方、禁則事項
• .claude/settings.json — 権限、フック、MCPサーバー
• .claude/commands/ — チーム共通のスラッシュコマンド
• .claude/agents/ — レビュー用・調査用などのSubagent
• .claude/skills/ — ドメイン特化のSkills

これらをgit管理しておけば、新メンバーがcloneした時点でその日から同じ品質のClaude Codeが動く状態を作れます。個人の ~/.claude/ は叩き台テンプレートの置き場として割り切り、プロジェクトに取り込まれたものが正、という整理が運用しやすいです。

また、Team Onboardingで忘れがちなのが権限設計です。全員が defaultMode: plan を共有するのか、acceptEdits まで許すのか、CI実行時だけ別のモードにするのか、といった判断はチームのリスク許容度で変わります。セキュリティ系の議論はセキュリティガイドでも触れていますが、Team Onboarding時点で「標準はこれ」を決めておくと、後からの個別調整が楽になります。/team-onboarding コマンドが追加された経緯はv2.1.101のリリースノートにあります。

組織サイズ別の運用例3パターン

機能の組み合わせ方は組織サイズによって「全部使うべきか」「一部で十分か」が変わります。典型的な3パターンを並べると次の通りです。

個人開発(1人)

小規模チーム(2-5人)

中規模チーム(6-20人)

個人開発では「仕組みを整える時間」自体が稼働を圧迫するため、過剰な自動化は後回しが現実的です。逆に中規模チームでは、誰が使っても同じ挙動になることが価値になるため、.claude/ 配下の整備とオンボーディング自動化の投資対効果が大きくなります。

小規模チームはこの中間で、「全員が同じ前提で動ける最低限」を先に揃え、レビュー自動化やスケジュール実行は困った順に足していくのが続けやすい形です。ワークフロー機能は一度に全部導入するものではなく、チームの痛みに応じて1つずつ積むという姿勢が合っています。

まとめ

Claude Codeのワークフロー機能は、/ultraplan → Checkpointing → /ultrareview という縦の流れと、Routines・Team Onboardingという横の仕組みが噛み合って初めて効果を発揮します。単体のコマンドを覚えるより、「計画・実行・レビュー・共有」の4層でどこが薄いかを見て、薄い層から足していく考え方が実運用では扱いやすい方針と言えそうです。組織サイズによって必要な厚みが違うため、他チームの運用例をそのまま写すより、自分たちの痛みを軸に一つずつ積み上げる進め方が結果的に遠回りにならない選択肢になります。