2026.05.06 · 16分で読める

Claude Code 5月新機能解説2026|/ultrareviewとproject purgeで開発が変わる

2026年5月6日時点で、Claude Codeは 4月20日〜5月4日のあいだに大型新機能と細部改善を立て続けに公開しました。公式の週次デジェストによれば、Week 17(4月20〜24日)で /ultrareview の公開研究プレビューが解禁され、Session Recap・Custom Themes・Web再設計が同時着地。続く v2.1.120〜v2.1.128(4月28日〜5月4日)では、CI向けのclaude ultrareviewサブコマンド、破壊的コマンドclaude project purge、Auto modeの透明性改善まで一気に揃いました。

結論を先に言うと、5月のClaude Codeは「個人で雲のレビュー資源を呼び出して、ローカルでフローを切らさず使う」方向に強く振り切っています。たとえるなら、1人の開発者が「自分のターミナル」と「雲のバグハンターのチーム」と「破壊的だが安全な掃除コマンド」を同時に持つ感覚です。本記事は、5月の主要アップデートを実践者目線で7つに絞って解説し、自分のワークフローにどう組み込むかまで踏み込みます。前提となるプラン体系はClaude Max週次クォータ完全ガイドで整理しているため、料金前提が知りたい方はあわせて参照してください。

なぜ5月のClaude Codeが「節目」と言えるのか

4月16日にOpus 4.7が新デフォルトに着地してから、Claude Codeは「モデル側の刷新」と「CLI側のワークフロー改善」を二段ロケットで重ねてきました。Claude Opus 4.7完全ガイドでも触れた通り、Opus 4.7はxhigh effortレベルとネイティブ1Mコンテキストを実装。続いてWeek 17で /ultrareview が公開研究プレビューとして解禁され、雲のバグハンター群がCLI/Desktopに連動する形が整いました。5月はこの「個人ターミナル+雲のレビューチーム」というハイブリッドが標準装備に変わった月として節目に当たります。

象徴的なのは、4月28日のv2.1.120でclaude ultrareviewがCLI非対話サブコマンドとして昇格したこと。これによりGitHub Actionsからのpre-merge自動レビュー、ローカルcronからの定期チェック、自分が組んだ自動化パイプラインへの組み込みが現実的になります。Week 17時点では「自分でCLIから呼ぶ」前提の機能でしたが、わずか1週間で「機械が自分のために呼んでくれる」ところまで進みました。スピード感としては、Anthropicが2026年4月に Google・Broadcomと結んだ計算資源提携 を背景に、雲側のレビュー計算を惜しまず投入できる構造が立ち上がっていることが伺えます。

もうひとつの軸が「破壊的コマンドの安全な作法」。5月1日のv2.1.126で追加されたclaude project purgeは、–dry-run/-i/-y を全部揃えた状態で公開されたのが特徴です。これは「便利だが事故ると痛いコマンドを、最初から防御的に出す」という、運用思想の成熟を示しています。月$50で365日回るAI自動化7システムでも触れたとおり、長期運用では「壊れたときに被害を最小化する設計」が肝で、5月のClaude Codeはまさにその思想で揃えられた印象です。

Claude Code 5月アップデート俯瞰 Week 17から v2.1.128 までの主要機能とリリース日 Claude Code 5月アップデート俯瞰 v2.1.114 → v2.1.128 / 4月20日 → 5月4日 4/20 Week17 /ultrareview 公開研究PR 4/23 v2.1.119 /config 永続化 設定一元化 4/28 v2.1.120 CI ultrareview 非対話呼出 5/1 v2.1.126 project purge 破壊的cmd 5/4 v2.1.128 Auto mode 透明性改善 5月の方向性 = 雲のレビュー × 破壊的コマンドの安全化 雲側を呼び出す /ultrareview claude ultrareview Routines連携 破壊的を安全化 project purge –dry-run / -i Auto mode 透明化 AI Lab OISHI

/ultrareview|雲のバグ狩りエージェントが標準装備に

/ultrareviewは雲側で動くバグハンターエージェント群を呼び出し、現在のブランチやPRを多角的にレビューする機能です。CLIで/ultrareviewと打つと現在ブランチ、/ultrareview 1234と打つとPR #1234を対象に、複数のエージェントが並列で論理エラー・セキュリティ・パフォーマンス・スタイル違反を探しに行きます。公式ガイドでは「auth系やデータマイグレーションなど、致命的影響の出るマージ前に走らせること」が推奨されています。

イメージとしては「自分が書いたコードを別人が30分かけて読み直してくれる」のようなものです。私の運用では、PRを上げる直前に/ultrareviewを必ず1回叩き、雲側からの指摘が返ってくる間に他タスクへ意識を切り替えるフローに統一しました。エージェントが返してくる指摘は粒度が高く、自分が見落とした境界条件や、ストリーム処理のレース、認証フローの分岐忘れを1〜3件は毎回拾ってくれるのが実感です。レビュー精度の高さよりも、「自分が次の作業に進んでいる間に並列で動いてくれる」非同期性のほうが効きます。言い換えると、レビュー待ちで自分の作業が止まらないのが本質的な価値です。

4月28日のv2.1.120から、claude ultrareview [target]がCLI非対話サブコマンドとして使えるようになりました。これが大きいのはGitHub Actionsやローカルcronから自動的に呼び出せること。たとえばマージ前のworkflowにclaude ultrareview HEADを1ステップ足すだけで、人間がレビューを依頼し忘れても雲のエージェントが必ず一発走ります。Claude Code Routinesガイドと組み合わせれば、毎日決まった時刻に主要ブランチの差分レビューを自動実行する運用も成立します。

/ultrareview の実行フロー CLIから雲のエージェント群へ、結果が戻る非同期フロー /ultrareview の実行フロー CLI / Desktop /ultrareview 雲側ディスパッチ 並列エージェント 論理レビュー セキュリティ パフォーマンス CLI 自動帰還 指摘リスト CIから claude ultrareview HEAD で自動呼出も可能 人間は次の作業に進み、雲側が並列で進行 マージ前の致命傷検出が「儀式」として組み込める AI Lab OISHI

Session Recap|席外し中の進捗を一行で取り戻す

Session Recapは、ターミナルからフォーカスを外して戻ってきたときに「席外し中に何が起きたか」を1行サマリで返す機能です。複数セッションを並列で動かしている人ほど効果が大きく、たとえるなら「会議中に席を外したスタッフが、戻ってきたときに30秒で空白の時間を埋めてくれる」イメージ。デフォルトで自動表示、/recapで任意のタイミングで手動生成、/configから自動表示をオフにすることも可能です。

具体的な使いどころとして、tmuxで4〜6セッション並べて回している人が一番恩恵を受けます。これまでは別タブの長文trnscriptをスクロールバックして「ここまで読んだか…次に何を頼んだか…」を再確認する時間が、セッション切り替えのたびに30秒〜1分発生していました。Session Recapが入ってからは、戻った瞬間に「直前の作業:feature-x branchのテスト追加完了、次のステップ:CI待ち」のような1行が出るので、思考のキャッシュが温度を保ったまま続けられます。

同時期に追加された Forked subagents(CLAUDE_CODE_FORK_SUBAGENT=1)と組み合わせると、親セッションのコンテキストを引き継ぐ子セッションを作って並列レビューを走らせ、戻ってきたときにSession Recapで「子の進捗」を1行で確認、という運用が成立します。Claude Codeデスクトップ並列セッション完全ガイドで並列運用の前提を整理しているので、複数タブを使い倒す方はあわせて確認してください。

Custom Themes|小さな視覚効率を軽視しない

v2.1.118で/themeから名前付きカラーテーマを作って切り替えできるようになりました。手書きで~/.claude/themes/のJSONを編集する道もあり、ベースプリセットを選んで気になるトークンだけオーバーライドする差分管理が公式に整っています。プラグインからテーマを配布することもできるため、社内チームで「会社用テーマ」を共有する運用も現実的です。

軽視されがちな機能ですが、テーマ整備は実は1日の集中力を底上げする小さなレバーです。私はAuto modeで安全な操作が走るときは緑系、慎重な確認が必要なときは琥珀系、コミット直前の最終確認時は赤系というように、ターミナルの色そのものを「いまどのフェーズか」を示すモードランプのような役割として使う設計にしています。いわば信号機を自分のターミナルに置く感覚で、週20〜30時間Claude Codeを触る人ほど、視覚的なフェーズ識別の効果は積み上がります。

5月4日のv2.1.128では引数なしの/colorが現在のセッション色をランダムに切り替える小ワザも入りました。これは「手元の作業を区別したいが、テーマ設計を毎回考えたくない」ときに便利。並列セッションを起動するたびに自動で違う色を当てれば、複数ターミナルが視覚的に区別しやすくなります。テーマもセッション色も、「自分のフローを切らさない補助輪」として静かに効きます。

claude project purge|プロジェクト状態を一掃する破壊的コマンド

5月1日のv2.1.126で追加されたclaude project purge [path]は、対象プロジェクトのClaude Code内部ステートをまとめて削除する破壊的コマンドです。削除対象は会話トランスクリプト、タスク、ファイル履歴、設定ファイルに記録されたそのプロジェクトのエントリ。ソースコード自体は触りませんが、Claude Code側が記憶している「そのプロジェクトの過去の文脈」が完全にリセットされます。

使いどころは3つあります。1つ目はPoCを大量に試して破棄するワークフロー。試作したプロジェクトのClaude側ステートを残し続けるとSession Recapや/contextの引き当てが汚染されるため、PoC終了時にclaude project purge ~/Projects/poc-x --yesで1発掃除。2つ目はコンテキストが汚染されたと感じたときのリセット。3つ目はプロジェクトを完全に手放すときの機密性確保で、内部ログを残さない運用に切り替えられます。

運用上の鉄則は「本番案件で使う前は必ず--dry-runで対象を確認」。–dry-runは削除対象を全部リストアップするだけで実害ゼロなので、最初の数回はこれを儀式として挟むのが安全です。-iは個別確認、-yは全自動、–allは複数プロジェクト一括という3段階のレバーが揃っており、「破壊的だが事故りにくい」設計になっています。これは月$50で365日回る自動化システムでも触れた、長期運用のための「壊れたときの被害最小化設計」と同じ思想です。

claude project purge の安全弁設計 –dry-run / -i / -y / –all の4レバー claude project purge の安全弁設計 破壊的だが事故りにくい4レバー –dry-run 削除せず 対象列挙のみ 最初の儀式 -i / –interactive 個別確認 残したいログを 途中で除外 -y / –yes 対話なし cron / CI 向け –all 複数一括 PoC清掃 月次運用 運用鉄則:本番前は必ず –dry-run で対象確認 削除対象:会話 / タスク / ファイル履歴 / 設定エントリ ソースコード本体は対象外(安心して使える境界) AI Lab OISHI

Auto mode改善|赤スピナーと診断ヒントで透明性が一段上がる

Auto modeはもともと「安全な操作はそのまま走り、危険な操作は止まって判断を仰ぐ」ための分類器ベースの権限ゲートです。7システム自動化の運用でも標準的に使っており、5月のアップデートで「動いていないのに気づかない」シナリオが大幅に減ったのが大きい変化です。具体的には2つ。

1つ目は5月1日のv2.1.126で追加された赤スピナー。Auto modeの権限チェックが何らかの理由で停滞したとき、スピナーが赤に変わって明示的に「ここで判断介入が必要」を示します。これまでは画面上のスピナーが「処理が遅いだけ」なのか「何かが詰まっている」のか区別が付きにくく、5〜10分平気で待ってしまうケースがありました。赤スピナーは「停滞=赤」という単純な視覚マッピングで人間側に明示的な判断を促します。

2つ目は5月4日のv2.1.128で追加された分類器の判定不能エラーへの診断ヒント。Auto modeの分類器が「これは安全か危険か判断できない」状態に入ったとき、エラーメッセージに「retry/compact--debug」のどれを試せ、というヒントが付くようになりました。公式CHANGELOGでも明示されている改善です。原因の半分以上はコンテキスト過剰なので/compactで大半が直るのが体感ですが、ヒントが付くだけで「次の手」を考える時間がゼロになる効果はバカにできません。

MCP運用|alwaysLoadとworkspace予約でツール検索遅延を消す

4月28日のv2.1.121でMCPサーバー設定にalwaysLoadオプションが追加されました。これは「このサーバーのツール群はtool-search deferralをスキップして、常時ロードしておく」という設定で、毎日叩くMCPサーバーのツール検索遅延が体感ゼロになります。私の場合、x-postやquality-gateのMCPサーバーはalwaysLoad: trueに倒す方針で、初手のリクエストが体感1秒以内で返ってくるようになりました。

もう1つ、5月4日のv2.1.128でworkspaceがMCPサーバーの予約名になりました。既存設定でworkspaceという名前のサーバーがいた場合、警告とともにスキップされます。これはClaude Code側の組み込みworkspace機能との衝突を避ける措置で、もし旧設定を持っている人は別名(たとえばmy-workspace)に変更する必要があります。再接続時のツール名フラッディング修正も同時に入っており、MCPサーバーの安定性が一段上がったのが5月の特徴です。

地味ですが効くのが/mcpコマンドが各サーバーのツール件数を表示するようになったこと(v2.1.128)。「接続したのに0ツール」のサーバーがフラグ付きで分かるため、設定ミスや権限漏れの即時検出に役立ちます。さらに4月28日(v2.1.122)では、claude.aiコネクタが手動MCPサーバーで上書きされている状態も/mcpで確認可能になりました。MCPの可視性は実装当初から課題でしたが、5月のひと続きで「使う側が状況を把握しやすい」設計に整っています。

MCP運用 Before / After 5月のMCP関連改善が日常運用に与える効果 MCP運用 Before / After v2.1.121 / v2.1.128 の3点強化 BEFORE(4月以前) 毎日のMCP初回呼出が3〜5秒遅延 /mcp で空サーバー判別不能 再接続時にツール名が氾濫 workspace 名衝突に気付けない connector上書きが見えない AFTER(5月以降) alwaysLoad で初回遅延ゼロ /mcp が0ツール接続をフラグ表示 再接続時の名前氾濫を抑制 workspace 予約名で衝突を予防 connector上書きが /mcp で可視 日常運用での体感差は「初手1秒」と「設定ミスの即時検出」 AI Lab OISHI

隠れた強化|Windows PowerShell・–channels・EnterWorktree

派手ではないが日常運用で効く改善が3つあります。1つ目はWindows環境でのPowerShellネイティブ対応。v2.1.120で「Git for Windows(Git Bash)が無い場合、Claude CodeはPowerShellをshell toolとして使う」設計に変わり、v2.1.126ではPowerShellがインストール済みならBashの代わりにPowerShellを優先shellとして扱うようになりました。Windowsエンジニアの「Bashを別途入れないと動かない」呪縛がここで解けます。

2つ目は--channelsオプションがコンソール(API key)認証で動くようになったこと(v2.1.128)。Channelsはチームでセッションを共有する機能ですが、これまではClaude.ai SSO前提でした。コンソール認証で使えるようになったためAPI keyベースのCI/自動化システムでchannels機能を活用できる道筋ができました。コンソール組織の管理設定でchannelsEnabled: trueを有効化する必要があります。

3つ目はEnterWorktreeがドキュメント通りの挙動に修正された件(v2.1.128)。これまでは新ブランチをorigin/<default-branch>から作っていたのが、ローカルHEADから作るように修正されました。これは並列セッション運用でworktreeを多用する人ほど利益が大きく、「ローカルで進めた変更が自動で引き継がれる」期待通りの動作になります。地味ですが、こうした「直感どおりに動く」修正が積み上がるのが安定運用フェーズの証です。

自分のワークフローへの組み込み方

5月のアップデートを実際にどう自分のワークフローへ組み込むか、4ステップで整理します。1日目:/ultrareviewをPR上げの儀式に組み込む。CLI上で/ultrareviewを打つ→雲側が並列レビュー→自分は次の作業に意識を切る、という流れを2〜3PRで体に馴染ませます。同時に/recapも使い始め、複数セッション運用時の切り替えコストを下げます。

2日目:CIにclaude ultrareview HEADを1ステップ追加。GitHub ActionsかローカルcronかRoutinesで、毎日朝9時のmainブランチ自動レビューを儀式化。これだけで「他人が見てくれている」状況を365日継続できます。Routinesガイドを参照しながら、自分の運用に合うトリガを選びます。

3日目:claude project purge --dry-runで月次清掃の儀式を作る。手元のPoCディレクトリを月1で--dry-run→対象確認→-yで実行、というフローを定着させます。同時にAuto modeの赤スピナーが出たときの初動を「/compactを1発」と決めておくと、停滞時間が体感ゼロに近づきます。

4日目:MCPサーバーのalwaysLoadを整備。毎日叩くサーバー(quality-gate、x-post、社内DBなど)にalwaysLoad: trueを付けて、初手の遅延を消します。さらにテーマを「フェーズ識別ランプ」として整備し、視覚的に「いまどの状態か」を一目で把握できる設定に。これで5月のアップデートが自分のフローの一部として定着します。

5月アップデートの組み込み4ステップ 1日目から4日目までの段階導入プラン 5月アップデートの組み込み4ステップ DAY 1 /ultrareview PR儀式化 /recap 並走 DAY 2 CI ultrareview Actions / cron 毎日自動 DAY 3 project purge 月次清掃 Auto mode 整備 DAY 4 MCP alwaysLoad テーマ整備 フェーズ識別 4日で「5月の新機能を全部使える」状態に 大きな再構築不要、既存フローに静かに組み込む 所要:実工数2〜3時間、効果は365日継続 AI Lab OISHI

5月のアップデートが示す方向性

5月のClaude Codeを通読すると、進化の方向性が3つに収束しているのが分かります。1つ目は「人間のフローを切らさない設計」。Session Recap、custom themes、Auto modeの赤スピナー、MCPのalwaysLoadはすべて「視覚と意識のスイッチコストを下げる」方向の改善です。2つ目は「雲側の計算資源を呼び出す側になる」。/ultrareview、CI向けclaude ultrareview、Forked subagentsは「個人ターミナルが雲のチームを並列で動かす」現代的な構図を実装しています。

3つ目は「破壊的コマンドを最初から防御的に出す」運用思想。claude project purge–dry-run/-i/-y/–allを揃えた状態で世に出されたのが象徴的で、これは「便利だが事故ると痛い」コマンドの新標準を示しました。Anthropic×Google×Broadcomの計算資源提携を背景に、雲側の余力が増えるほど「個人がそれを安全に呼び出すための作法」が重要になるはずです。5月のClaude Codeはまさにその作法の整備フェーズに入った印象です。

個人開発者の目線で見ると、5月の新機能を組み込むことで「自分のターミナル」と「雲のレビューチーム」を1人で並列に動かす感覚が標準化します。月$50で365日回る自動化7システムのような個人レイヤーの実装と組み合わせれば、1人で4〜7チャネル運用がさらに楽になります。いわば「個人が小さな雲のレビュー部屋を持つ」状態が日常化するということで、5月以前と以後では同じClaude Codeでも体験の手触りが変わります。次のWeek 18/Week 19のデジェストが公開されたら、引き続き本ブログで実践目線の解説を続けます。

最後に、本記事で扱った機能を試すときの運用上の注意点を1つだけ。/ultrareview もproject purgeも雲側/ローカル側で書き込みが発生する操作のため、初回は必ず安全な検証用ブランチや使い捨てプロジェクトで試すのが定石です。たとえるなら新車を買って初日にいきなり高速道路へ出るのではなく、近所の駐車場で挙動を確かめる感覚と同じで、「便利だが事故ると痛い」コマンドほど初回の慣らし運転を省略しないのが長期運用のコツです。

FAQ|よくある質問

Q1. /ultrareview はどのプランで使えますか?

A. CLI/Desktop両方で動作する公開研究プレビュー機能ですが、料金はプランのincludedクォータではなく 追加usage(extra usage)として課金されます。1回あたり$5〜$20程度(規模により変動、公式ドキュメント基準)。Pro/Maxには初期に3回の無料実行枠が付与されていましたが、この無料枠は2026-05-05で期限終了済みのため、5/6時点では基本的にextra usage課金が発生する点に注意。CI/自動化から非対話で呼ぶ場合はclaude ultrareview <target>サブコマンドが利用可能です。Bedrock/Vertex AI/Foundry/ZDR組織では非対応で、Claude.ai認証が必須。

Q2. claude project purge は元に戻せますか?

A. 元に戻せません。会話トランスクリプト・タスク・ファイル履歴・設定エントリが完全に削除されます。本番運用では必ず--dry-runで対象を確認してから実行する運用が推奨です。ソースコードそのものは対象外なので安全です。

Q3. Session Recap は無効化できますか?

A. 可能です。/configから自動表示をオフにできます。任意のタイミングで手動生成したいときは/recapコマンドを実行してください。

Q4. Auto mode の赤スピナーが頻発するときの対処は?

A. ほぼ全ての停滞は/compactでコンテキストを縮約すれば解決します。直らない場合は--debugでログを確認するか、retry を試してください。

Q5. Windows PowerShell ネイティブ対応はGit Bashを完全に置き換えますか?

A. Git Bashが入っていれば従来通り使えます。入っていない場合に自動的にPowerShellがshell toolとして使われる仕様です。v2.1.126ではPowerShellがインストール済みであればBashより優先される設計に変わりました。

参照元・出典

← Blog一覧へ