Claude Codeワークフロー — Plan Mode/Ultrareview/Checkpointing

要点

Claude Codeのワークフロー機能は、古い解説と現行の仕様がずれやすい分野です。/ultraplan はv2.1.222(2026年8月4日)で削除され、計画はPlan Modeが受け持ちます。/ultrareview は /code-review ultra の別名になりました。

いまの選択肢は、計画・実行・レビュー・共有の4層に分けると見通せます。以下では、手元のどの層が薄いかを探す順に、層ごとの使い分けと落とし穴を並べます。最後に、個人開発から中規模チームまでの組み合わせ方を示します。

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

4層は独立した機能ではなく、前段の結果が次段の入力になります。計画が曖昧なまま実装を走らせると、Checkpointingの巻き戻しが増えます。レビューが属人化していると、共有する設定も定まりません。

計画を固めたい — Plan Modeとultrathink

実装の前に方針を固めたいとき、使うのはPlan Modeです。Claudeはファイルを読み、シェルコマンドで調べ、計画を書きますが、ソースは編集しません。計画を承認するまで、編集は止まります。

入り方は3通りあります。Shift+Tabでモードを切り替える、プロンプトの先頭に /plan を付ける、起動時に指定する、のどれかです。

claude --permission-mode plan

v2.1.289の claude --help では、--permission-mode の選択肢は acceptEdits・auto・bypassPermissions・manual・dontAsk・plan の6つです。Shift+Tabで回るのは default(CLIでの表示名はManual)→ acceptEdits → plan の順で、auto から押すと最初に default へ移ります。

計画が出ると、承認の画面に3つの選択肢が並びます。自動承認モードで始める、編集を1件ずつ確認する、計画に戻って直させる、です。ここで Ctrl+G を押すと、計画をエディタで開いて直接書き換えられます。人間が一度手を入れてから承認する流れにすれば、責任の所在が「AIが立てた計画」から「人間が承認した計画」へ明確に移ります。

計画の質は、プロンプトに書く成功条件と制約で決まります。「OAuth2へ移行したい」だけでなく、「既存セッションを壊さない」「AuthService の公開インターフェースは維持する」まで書くと、計画の粒度が揃います。深く考えさせたい1ターンだけなら、プロンプトに ultrathink を含めます。セッションの /effort は変わらず、そのターンにだけ追加の指示が入ります。

Sonnet 5以降、Opus 4.7以降、Fableの各モデルは、常に適応的推論で動きます。考える量はステップごとにモデルが決めるため、固定の思考予算モードは適用されません。

古い解説にある/ultraplanは動かない

Ultraplanは、計画をクラウドセッションに送り、ブラウザーで見直せる研究プレビューでした。公式ドキュメントによると、削除されたのは3点です。/ultraplan コマンド、ultraplan キーワード、計画承認画面の「Ultraplanで練り直す」選択肢が、まとめて消えました。changelogの記載は、v2.1.222の「Removed ultraplan feature」の1行です。

代わりに示されているのは、ローカルならPlan Mode、ブラウザーで見直したいならクラウドセッションです。古いチュートリアルどおりに打っても何も起きないのは、この削除のためです。経緯と他の廃止機能はClaude Code廃止機能の一覧に、Plan Modeの詳細はPlan Modeの使い方にあります。

計画段階が効くのは、複数ファイルにまたがる機能追加や、認証・課金・マイグレーションのように「やってみてから考える」が高くつく領域です。テストのない既存コードを変えるなら、Claude Codeリファクタリングを安全に進める手順が参考になります。スラッシュコマンド全体の頻度別整理はスラッシュコマンド実用集にあります。

マージ前に重大な見落としを減らしたい — /code-reviewとultra

レビューのコマンドは、ローカルで回るものとクラウドで回るものに分かれます。

ローカルのレビューは、low から max までの強度を引数で選べます。low と medium は確信度の高い指摘だけに絞り、high 以上は確信の低い指摘も含めて範囲を広げます。強度を省くと、直近に自分で打った強度が使われます。

ultraは、起動前に確認画面が出ます。画面には、レビュー範囲、無料枠の残り回数、見積もり費用が並びます。無料枠はProとMaxで3回で、アカウントごとの一回限りです。更新されず、その後はusage creditsが必要で、1回あたり5〜25ドルが目安です。Claudeが勝手に起動することはなく、自分で /code-review ultra と打ったときだけ走ります。研究プレビューのため、機能・料金・提供範囲は変わりえます。

スクリプトやCIからは、サブコマンドで呼びます。v2.1.289の --help は次のとおりです。

$ claude ultrareview --help
Usage: claude ultrareview [options] [target]
 
Run a cloud-hosted multi-agent code review of the current branch (or a PR number
/ base branch) and print the findings
 
Options:
  -h, --help           Display help for command
  --json               Print the raw bugs.json payload instead of formatted
                       findings
  --no-post            Do not post the findings to the PR (the default; accepted
                       for parity with the /ultrareview and /code-review ultra
                       flags)
  --post               Post the finished review's findings to the PR as you (PR
                       targets only; one plain comment, not a review)
  --timeout <minutes>  Maximum minutes to wait for the review to finish
                       (default: 45)

PRへの投稿はオプトインで、--post を付けた実行だけがコメントを残します。コメントはレビューでも承認でもなく、通常の1件のコメントです。手順の全体はClaude Code ultrareviewの使い方にまとめています。/ultrareview が追加された時点の差分は、v2.1.111のリリースノートで触れています。

PRごとに自動でレビューを付ける別の経路もあります。TeamとEnterprise向けのCode Review(GitHub App)は、PRの作成やプッシュを契機にインラインコメントを投稿し、@claude review と書けば手動でも起動できます。Zero Data Retentionの組織では使えません。指摘は承認やブロックを伴わないので、既存のレビュー手順は変わりません。

費用と深さの両立には、強度の違う2つを使い分ける運用があります。/code-review を全PRに、ultraを重要なPRにだけ回す形です。またSubagentと組み合わせれば、セキュリティ観点だけを code-reviewer に任せて、本体のセッションでは実装を続けられます。

途中でやり直したい — Checkpointingと/branch

Checkpointingは、Claudeのファイル編集を自動で記録し、あとから戻せるようにする仕組みです。ターンを始めるプロンプトを送るたびに、チェックポイントが1つ作られます。

/rewind(別名 /checkpoint、/undo)か、入力欄が空のときのEscの2回押しで、巻き戻しのメニューが開きます。選べる操作は次のとおりです。

• コードと会話の両方を戻す
• 会話だけを戻す
• コードだけを戻す
• そこから先、またはそこまでを要約して、コンテキストを空ける

コードだけを戻せるので、「調べた内容は会話に残したまま、実装だけ捨てる」という使い方ができます。Gitのコミットが戻せるのはファイルだけで、会話の状態は戻せません。

戻せないものを先に知っておく

巻き戻しの対象は、Claudeのファイル編集ツールによる変更だけです。範囲の外にあるものは次のとおりです。

保持にも上限があります。ファイルのスナップショットは直近100件のチェックポイント分で、セッションが最後に保存してから約30日で削除されます。削除後に戻そうとすると No files were restored で失敗することがあり、cleanupPeriodDays で保持期間を延ばせます。恒久的な履歴の代わりにはならないので、版管理はGitに任せます。個別の制約はチェックポイントの復元制限で、/rewind の操作は/rewindコマンドの使い方で扱っています。

分岐は/branchとWorktreeで

別案を試したいときは、会話そのものを分岐させます。/branch [名前] は会話を途中でコピーして分岐へ切り替え、元の会話を残します。元には /resume で戻れます。分岐元の会話と見分けやすいよう、/rename で名前を付けられます。名前を省くと、会話の履歴から自動で付きます。分岐は別のセッションとして一覧に並び、同じセッションの複数エントリは1行にまとまって、→ で展開できます。claude --continue --fork-session でも同じ分岐ができます。

/fork は別物です。会話のコピーをバックグラウンドの新しいセッションとして走らせ、手元では作業を続けられます。ファイル側の分岐は、claude --worktree feature-auth(短縮形 -w)で、独立したGitのWorktreeを .claude/worktrees/<名前> に作ります。会話の分岐とファイルの分岐を、同じ軸で扱えるのが利点です。詳細はWorktree完全ガイドにあります。

数十のエージェントで一気に回したい — ダイナミックワークフロー

公式に「ワークフロー」と呼ばれる機能は、いまはこのダイナミックワークフローを指します。タスクに合わせてClaudeがJavaScriptのスクリプトを書き、ランタイムがそれをバックグラウンドで実行して、多数のサブエージェントを束ねます。セッションは動かせるままで、最終結果だけが会話に返ります。

サブエージェントやスキルとの違いは、次の手を誰が決めるかです。サブエージェントではClaudeがターンごとに決め、結果は会話の文脈に溜まります。ワークフローでは分岐も途中結果もスクリプトが持つので、再実行できる単位になります。コードベース全体のバグ探索、数百ファイルの移行、出典を突き合わせる調査のように、1つの会話では回しきれない規模に向きます。

起動の入口は4つあります。

• /deep-research <質問>: 同梱の調査用ワークフロー。複数の角度でWeb検索し、出典を突き合わせて、検証を通った主張だけの報告書を返す
• ultracode というキーワードをプロンプトに含める、または「ワークフローで」と頼む: その1回のタスクだけがワークフローになる
• /effort ultracode: セッションの間、実質的なタスクごとにClaudeがワークフローを組む(off の引数はv2.1.284以降)。起動時に claude --effort ultracode と指定する方法は、v2.1.203以降で使えます
• 保存済みのワークフロー: 実行結果のスクリプトをコマンドとして保存すると、次から / の補完に並ぶ

実行前には、計画された段階を示す承認画面が出ます。選べるのは「実行する」「スクリプトを表示」「キャンセル」です。名前付きのワークフローには「今後は確認しない」も並びます。Ctrl+G でスクリプトをエディタで開けます。実行中は /workflows で、段階ごとのエージェント数・トークン数・経過時間が見えます。p で一時停止、x で停止です。ProプランではDynamic workflowsを /config で先に有効にします。

ultracode を常時有効にすると、すべての依頼でトークンの消費が増え、使用量の上限に早く届きます。設定はultracode設定の解説に、仕組み全体はダイナミックワークフローの解説にあります。

同時数は、環境変数 CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS で1〜256に変えられます(v2.1.269以降)。4,096は parallel() と pipeline() の1回の呼び出しに渡せる件数の上限です。

大規模な実行は、小さな範囲で試してから広げる選択肢があります。25を超えるエージェントを割り当てるか、見積もりのトークン総数が150万を超えると、進捗行に Large workflow の警告が出ます。警告は知らせるだけで、実行は止まりません。エージェント数の目安は /config の workflowSizeGuideline で、small(5未満)・medium(10未満)・large(50未満)から選べます。既定は medium で、Proプランではv2.1.271以降 small です。

途中で人が口を挟めない点にも注意が要ります。実行中に止まるのは、エージェントの権限確認と使用量上限の待機だけです。段階ごとに承認を挟みたい処理は、段階ごとに別のワークフローとして走らせます。

毎回同じ作業を任せたい — Routinesと定期実行

定期実行には、公式に3つの経路があります。

Routinesは、プロンプト・リポジトリ・コネクタを1つにまとめて保存し、自動で走らせる設定です。引き金は3種類あります。スケジュール、HTTP POSTによるAPI呼び出し、PRやリリースなどのGitHubイベントで、1つのRoutineに組み合わせられます。Pro・Max・Team・Enterpriseで使え、claude.ai/code/routines かCLIの /schedule で作ります。研究プレビューです。

選ぶ基準は、どこで動かす必要があるかです。コミットしていない変更に触れるならデスクトップ、パソコンを閉じても回したいならクラウド、セッション中の素早い確認なら /loop です。PRイベントへの反応は、RoutineのGitHubトリガーでもGitHub Actionsでも書けます。

セッション内で繰り返す手順は、カスタムスラッシュコマンドで足ります。.claude/commands/ のファイルは今も動き、.claude/skills/<名前>/SKILL.md のスキルと同じ /名前 を作ります。スキルのほうは、補助ファイルなどの追加機能を持てます。詳しい設計はRoutines完全ガイドにあります。

落とし穴は、自律実行のプロンプトに曖昧さを残すことです。クラウドのRoutineは権限の確認を挟まず最後まで走るため、成功の定義、失敗時の行き先、結果の通知先を、1つのプロンプトに書き込んでおきます。Slackへ要約を送るのかIssueを立てるのかまで決めておけば、失敗に気づかれないまま放置される事故が減ります。

チームで設定を共有する

個人の ~/.claude/ ではなく、プロジェクト配下の .claude/ を正にすると、同じ設定・同じスキル・同じSubagentを全員が共有できます。/team-onboarding はこれとは別物です。過去30日のセッション、コマンド、MCPサーバーの利用履歴から、新メンバーが最初のメッセージとして貼れるMarkdownの案内を作ります。Pro・Max・Team・Enterpriseのclaude.aiユーザーには、チームメイトがそのまま開ける共有リンクも返ります。違いはClaude Codeの/team-onboardingコマンドで扱っています。

共有しておきたいのは次の要素です。

• CLAUDE.md: プロジェクトの方針、書き方、禁則事項
• .claude/settings.json: 権限、フック、MCPサーバー
• .claude/skills/: ドメイン特化のスキル(.claude/commands/ も有効)
• .claude/agents/: レビュー用・調査用などのSubagent

これらをgit管理すれば、cloneした日から同じ構成のClaude Codeが動きます。

見落としやすいのが、権限モードの既定値です。permissions.defaultMode に plan や acceptEdits を書けば、チームの標準を揃えられます。ただし、プロジェクトの .claude/settings.json と .claude/settings.local.json に "auto" を書いても反映されず、組み込みの既定値が使われます。"bypassPermissions" も同じ扱いで、セッションはManualで始まります。それ以外の値は、どの設定ファイルからでも効きます。標準モードの決め方は、チームのリスク許容度で変わります。セキュリティ系の論点はセキュリティガイドでも触れています。

/team-onboarding が追加された経緯は、v2.1.101のリリースノートにあります。

組織サイズ別の運用例

どの機能をどこまで使うかは、組織の規模で変わります。

個人開発では、仕組みを整える時間そのものが稼働を圧迫します。過剰な自動化は後回しで足ります。中規模チームでは、誰が使っても同じ挙動になることが価値なので、.claude/ の整備と導入の自動化に見合う効果が出やすくなります。

小規模チームはその中間です。全員が同じ前提で動ける最低限を先に揃え、レビューの自動化やスケジュール実行は、困った順に足していきます。

まとめ

4層のうち手元で薄いところを見つけ、Plan Modeと /code-review から足していく進め方が、導入の負担を抑えられる選択肢です。