【Claude Code 2.1.146 アップデート徹底解説】/simplify→/code-review 改名と effort レベル/AskUserQuestion 抑制解除/don't ask again 永続化ほか16変更
SINYBLOG — 【Claude Code 2.1.146 アップデート徹底解説】/simplify→/code-review 改名と effort レベル/AskUserQuestion 抑制解除/don't ask again 永続化ほか16変更

スポンサードリンク



目次

Anthropic Official · 2026 Edition

さよりも「審査の精度」「確認の確実さ」「許可の記憶」を磨き込んだ、地味だが効くアップデート。Claude Code 2.1.146(2026年5月21日リリース)は /simplify/code-review へ改名し、optional な effort レベル(例:/code-review high)を取り込んだ。同時に Auto モードが AskUserQuestion を握り潰さなくなり、バックグラウンドセッションで「次回から確認しない」と答えた権限が本当に再質問されなくなった。さらに Windows PowerShell / NTFS junction / MCP ページネーション / GNOME 端末ペーストといった「環境を選ぶバグ」が一掃された 16 変更を、本記事は全て一次情報ベースで日本語解説する。所要時間 12 分。

user@sinyblog:~/article 01_overview.md2.1.146 の輪郭 — 「審査・確認・記憶」を整える

Claude Code v2.1.146 は 2026 年 5 月 21 日に公式 Changelog で公開された [1]。前バージョン 2.1.145(agents の JSON 出力・OTEL span 拡張)と異なり、新機能の追加よりも「これまでこっそり外していた挙動を直す」リリースだ。16 個の変更は要点で 3 軸にまとめられる。

代表的な変更 体感される効果
審査(Code Review) /simplify/code-review 改名 + effort レベル PR レビューを「気軽 (low)」「本気 (high)」で打ち分け可能に
確認(Ask & Approve) Auto モードが AskUserQuestion を握り潰さない/管理ポリシー強化 スキルが「必須質問」を出せる/組織のログイン制約が破られない
記憶(Permission & State) バックグラウンドセッションが don't ask again を保持/CLAUDE_CODE_SUBAGENT_MODEL が子プロセスへ伝播 「許可済み」の権限が再質問されない/サブエージェントが想定モデルで動く
今回のリリースが「効く人」

① PR レビューに Claude を本気投入していたチーム(章2〜4)、② スキルや MCP に依存して開発しているユーザー(章5・8・10・12)、③ Windows / GNOME など 主流ではない端末環境 で時々詰まっていた人(章7・9・14)。ここに該当するなら、最低でも 2.1.146 までアップデートしておく価値がある。

本記事はリリース直後に公式 Changelog [1]・GitHub 上の plugin 定義 [2]・公式 Settings ドキュメント [3] を突き合わせて書いている。各章で 一次ソースが何を言っているか実運用でどう影響するか古い情報や憶測との切り分け を順に並べた。

user@sinyblog:~/article 02_rename.md/simplify/code-review 改名の真意

Changelog の「Other changes」セクションに、地味だが影響範囲の大きい一行がある [1]

Renamed /simplify to /code-review with an optional effort level (e.g. /code-review high)

CHANGELOG.md — v2.1.146 / [1]

これは「単純な改名」では ない/simplify という旧名は、英語話者には「コードを簡潔化する(リファクタの提案を出す)コマンド」と読まれがちだった。だが実体はずっと プルリクエストを多エージェントで監査するコマンド だ。名前と実体が食い違っていたところに、effort レベルというノブが追加されたタイミングで /code-review へ正式に名前を寄せた、というのが今回の改名である。

旧名はまだ叩けるか?

公式 Changelog には旧名のエイリアス維持に関する明示記載はない(2.1.144 で /extra-usage/usage-credits のエイリアスとして残された例とは扱いが異なる)。スクリプトやドキュメントで /simplify を直接叩いている箇所は /code-review に書き換えておくのが安全だ。

そして今回新設された optional な effort レベル。Changelog では「/code-review high」が例として挙げられているのみで、具体的な内部挙動の明文化はまだ最小限だ。だが GitHub 公開済みの plugin 定義(plugins/code-review/commands/code-review.md)を読むと [2]、このコマンドが どれだけ重いことをしているか がわかる。次章でその中身を分解する。

user@sinyblog:~/article 03_code_review_internals.md/code-review の中身を分解 — 9ステップ・最大7エージェント

/code-review は単一エージェントが PR を読むコマンドではない。公式 plugin 定義に書かれた 9 ステップは、最大で 7 エージェント(haiku 1 + sonnet 3 + opus 2 + validator N)が直列・並列で走るマルチエージェントワークフローだ [2]

  1. Pre-flight check(haiku) — PR が closed / draft / 自動化 PR / Claude が既にコメント済 のいずれかなら停止。
  2. CLAUDE.md ファイル列挙(haiku) — ルートと差分対象ディレクトリの CLAUDE.md パスだけ取得(中身は読まない)。
  3. 差分サマリ(sonnet) — PR を gh で参照して変更内容の要約を作る。
  4. 並列レビュー × 4(sonnet 2 + opus 2) — CLAUDE.md 準拠監査を 2 並列、バグ検出と論理・セキュリティ問題を opus 2 並列。
  5. Issue 検証(opus / sonnet) — 検出された各 issue をさらに別エージェントが「本当に問題か」検証する。
  6. フィルタ — 検証で「真の問題」と確認できたものだけ残す(false positive を捨てる)。
  7. 結果出力 — issue リストまたは「No issues found.」を端末に表示。--comment が無ければここで停止。
  8. コメント計画(自分用) — 投稿予定の inline コメントを内部的に列挙。
  9. GitHub への inline コメント投稿mcp__github_inline_comment__create_inline_comment で 1 issue 1 コメントで投下。

ポイントは「High signal only」の徹底だ。plugin 定義は「flag するのは ① コンパイル/パースが通らないコード、② 入力に関わらず必ず誤動作するロジックエラー、③ 明らかな CLAUDE.md 違反(該当ルールを引用できるもの)」の 3 種に限ると明記している [2]。スタイル提案・linter で拾えるレベルのもの・「条件次第で問題かも」程度の指摘は 意図的に外す。これが Anthropic 公式のレビュー観だ。

bash— /code-review の基本的な叩き方


# 端末確認のみ(PR にコメントは付かない)
/code-review 1234

# PR にコメントも自動投稿(high signal issue のみ)
/code-review 1234 --comment

# Effort レベルを上げて、より深い監査をかける
/code-review 1234 high --comment
公式 plugin 定義のワークフロー [2] を踏まえた一般的な呼び出し例
CLAUDE.md は「スコープ付き」で評価される

plugin 定義には「ファイルごとの CLAUDE.md 評価は、そのファイルとその親ディレクトリにある CLAUDE.md のみを参照する」と明記されている [2]。モノレポでサブパッケージごとに CLAUDE.md を置いている場合、無関係パッケージのルールで指摘されない設計だ。「全リポジトリ横断ルール」はモノレポでは ルートの CLAUDE.md に書く必要がある

user@sinyblog:~/article 04_effort_levels.md--effort レベル(low / medium / high)の使い分け

Changelog の表記は「/code-review high」だけなので、low / medium / high の 内部仕様 は現時点で公式 plugin md に詳細化されていない [2]。だが 9 ステップ・最大 7 エージェントのアーキテクチャから推測できる調整軸は明確だ。本節は changelog の言及範囲 (high が指定可能な optional level) と、それを踏まえた 実用上の使い分けの考え方 を区別して書く。

レベル changelog で確認できる範囲 運用上の推奨シーン(筆者の整理)
low 指定可能な値の一つ(changelog 例示は high 個人プロジェクト・ドラフト PR・「とりあえず明らかなバグだけ拾いたい」とき
medium(デフォルト相当) 明示記載なし。/code-review を引数なしで叩いた場合の挙動 普段の社内 PR レビュー。9 ステップを標準速度で回す
high changelog で唯一例示されている値 /code-review high 本番マージ前・セキュリティ機微・大規模 refactor PR。bug/logic 検証を増やしたいとき
「effort」と「--comment」は別軸

effort は 監査の深さ--commentGitHub へ書き込むか否か。dry-run 的に「high で監査して、結果は端末だけで見る」「low で監査して即コメント投稿」など組み合わせが可能だ。最初のうちは --comment を付けずに精度を見て、信頼できると感じたら自動コメント投稿に切り替えるのが安全。

なお、changelog では「effort level」は形容詞ではなく 引数 として受け取る形式(/code-review high)が例示されている [1]--effort=high のようなフラグ形式は明示されていないので、まずは引数として渡す呼び出し方を試すのが正しい。

user@sinyblog:~/article 05_askuserquestion.mdAuto モードが AskUserQuestion を尊重するようになった

2 つ目の目玉は Auto モード(権限質問を自動回避するモード)の挙動修正だ。

Auto mode no longer suppresses AskUserQuestion when the user or a skill explicitly relies on it

CHANGELOG.md — v2.1.146 / [1]

AskUserQuestion は、Claude Code が 選択式の質問をユーザーに投げる ための公式ツールだ。スキル開発側はこれを通じて「曖昧な要件を構造化された決定に変換する」ように設計する [4]。たとえば spec 駆動の skill では、コードを書く前に「DB は PostgreSQL / SQLite / インメモリのどれを想定?」のような 必須クラリフィケーションAskUserQuestion で出す。

ところが Auto モードはこれまで、「ユーザーの確認待ちを最小化する」名目で AskUserQuestion の呼び出しごと握り潰すケースがあった。結果として、本来出るはずの選択肢が出ないままスキルがゴミ仕様で先に進む という、極めて気持ち悪い不具合が発生していた。issue でも報告例がある [5]。2.1.146 ではこの抑制が解除され、ユーザーやスキルが明示的に依存している場合は質問を 必ず 出すように改められた。

影響を受けやすかったスキルの傾向

① 開発前に要件を確定する spec / scaffolding 系スキル、② 複数選択肢から方針を選ばせるプラン系スキル、③ 危険な破壊的アクションの前に確認を入れる 自作スキル。これらを使っていて「最近 Auto モードだと変な動きをするな」と感じていたら、2.1.146 で改善している可能性が高い。

json— スキル側の AskUserQuestion 宣言例


{
  "name": "spec-driven-build",
  "description": "要件を AskUserQuestion で確定してから実装する",
  "allowed-tools": [
    "AskUserQuestion",
    "Read",
    "Write",
    "Edit"
  ]
}
スキル定義で AskUserQuestion を allowed-tools に含めるイメージ [4]

user@sinyblog:~/article 06_dont_ask_again_persist.mdバックグラウンドセッションが「don't ask again」を保持する

3 つ目の目玉。これも体感が大きい。

Fixed backgrounded sessions re-prompting for tool permissions you already granted with "don't ask again"

CHANGELOG.md — v2.1.146 / [1]

Claude Code のバックグラウンドセッション(/backgroundclaude --bg、Agent view から起動した非対話セッション)は、メインセッションから切り離して長時間タスクを走らせる仕組みだ。v2.1.144 で /resume でも復帰できるようになっており [6]、最近の Claude Code 運用では中核機能のひとつになっている。

しかし 2.1.145 までは、バックグラウンドセッションを attach し直すと、一度「次回から確認しない」と答えたはずのツール権限が再び確認ダイアログを出す 不具合があった。長時間タスクが進捗 80% 地点で「Bash 実行を許可しますか?」と止まり、ユーザーは「もう許可してるのに……」とため息をつくことになる。2.1.146 ではこの永続化が修正されている。

バックグラウンド運用の安心ライン

2.1.146 以降は「don't ask again をクリックする = そのセッションの寿命中ずっと有効」と素直に考えてよい。バックグラウンドで npm testpytest のような繰り返し系をぶん回す運用と相性が良くなった。組織的に 「権限ダイアログは抑制しすぎず、最初だけ丁寧に答える」 ルールに統一する価値が出てきた。

user@sinyblog:~/article 07_pwsh_winget_fix.mdWindows PowerShell — winget/Store 経由 pwsh の壊滅修正

Windows ユーザーは恐らくここを最も歓迎する。

Fixed Windows PowerShell tool failing with "command line is invalid" when pwsh is installed via winget or the Microsoft Store (regression in v2.1.124)

CHANGELOG.md — v2.1.146 / [1]

2.1.124 のどこかで入った変更が、winget や Microsoft Store からインストールされた pwsh 7.x を Claude Code から呼び出すと「command line is invalid」エラーで一切動かなくなる回帰を引き起こしていた。MSI / .exe からインストールした PowerShell では問題なかった一方、Microsoft が公式に推奨している winget 経由のインストールが詰む、という最悪パターン。

同時期にハマっていた人の症状

「Claude Code が pwsh を呼んだ瞬間に毎回失敗する」「powershell.exe(Windows PowerShell 5.1)にフォールバックさせれば動くが、PowerShell 7 の機能が使えない」「Windows 11 を新規セットアップしたマシンほど発生しやすい」あたり。2.1.146 でこの全パターンが直る。

Windows + Claude Code を本気で使うなら、PowerShell 7 系を winget や Microsoft Store で導入しているケースが今や多数派だ [7]。2.1.146 でようやくこの組み合わせが「素直に動く」状態に戻ったので、Windows ユーザーは特に優先度高くアップデートを当てておきたい。

powershell— アップデート後の確認


# Claude Code を最新版へ
claude --upgrade

# Claude Code の中から軽く叩いてみる
# >_ PowerShell tool を呼ぶプロンプト例
# 「pwsh で $PSVersionTable を表示して」
2.1.146 以降は winget 経由 pwsh でも素直に応答する

user@sinyblog:~/article 08_mcp_pagination.mdMCP のページネーション欠落バグ

MCP(Model Context Protocol)まわりにも重要な修正が入った。

Fixed MCP resources/list, resources/templates/list, and prompts/list dropping items past page 1 on paginating servers

CHANGELOG.md — v2.1.146 / [1]

大規模 MCP サーバー(Notion、Google Drive、Slack、独自エンタープライズ MCP など)は、リソース一覧やプロンプトテンプレート一覧をページングして返す。Claude Code 側でこのページング応答を最後まで読み切らず、1 ページ目だけ拾って 2 ページ目以降をドロップする バグが入っていた。

体感としては「MCP サーバー内に大量のリソースがあるはずなのに、Claude Code から見えるのが最初の数件だけ」「resources/templates/list で取れるはずのテンプレが認識されない」といった現象だった。2.1.146 でこれが直り、ページ送りを最後まで追いかけるようになる。

関連:2.1.144 でもページネーション修正があった

2.1.144 で「MCP paginated tool lists now return all pages」という修正があり [1]、ツールリストのページング欠落は先に直っていた。2.1.146 はその修正残りである resources 系・prompts 系の API に対する同種修正と捉えるとよい。MCP 全体としては「ページネーション系の取りこぼし解消」がここでようやく揃ったことになる。

user@sinyblog:~/article 09_terminal_rendering.mdWindows Terminal のストロボ問題&ストリーミング描画

Windows ユーザーが触っていた「あのチカチカ」も今回直る。

Fixed full-screen strobing in attached background sessions on Windows Terminal while Claude is streaming

CHANGELOG.md — v2.1.146 / [1]

バックグラウンドセッションを Windows Terminal に attach した状態で Claude がストリーミング出力している間、画面全体がストロボのように点滅する症状があった。長文の応答を待っている間ずっと目がチカチカするレベルで、放置すると VS Code のターミナルへ退避するユーザーまでいた。

関連して、2.1.144 でも「Terminal output corruption from missed window-resize events」「Progressive terminal display corruption in long sessions」が直っており [1]、ここ数バージョンは Windows まわりのターミナル描画 を集中して直しに来ている流れだ。2.1.146 はその仕上げに近い。

user@sinyblog:~/article 10_ntfs_and_background_input.mdNTFS junction 保護&/background のスキル単独入力対応

地味だが「これがバグだったの怖い」と感じる類の修正が 2 つ並んでいる。

Fixed on Windows, removing a background-job worktree no longer follows NTFS junctions into the main repo

CHANGELOG.md — v2.1.146 / [1]

Claude Code はバックグラウンドジョブ用に git worktree を切って独立した作業ツリーを作る運用がある。終了時にこの worktree を片付ける処理が、Windows の NTFS junction(シンボリックリンクの類)を 追跡してリンク先=メインリポジトリの中身まで削除しに行く 可能性があった。

最悪パターンを想像する

① あるディレクトリに NTFS junction を仕込んでいる Windows ユーザー、② Claude Code のバックグラウンド worktree を多用するワークフロー、③ ジョブ終了時の自動クリーンアップ。3 つが揃うと「ジョブ終了とともにメインリポジトリの中身が削られる」事故が成立しうる。発生条件は限定的だが、起きたときの被害が大きい部類のバグだ。2.1.146 で junction を追跡しないように直された。

Fixed /background refusing sessions whose only typed input was a skill or custom slash command

CHANGELOG.md — v2.1.146 / [1]

もう 1 件。/background でセッションを背景化しようとしたとき、入力が スキル呼び出しだけカスタムスラッシュコマンドだけ の場合に「入力が無い」と判定されて拒否されるバグがあった。「/some-skill を背景で走らせたい」という、自然にやりたい運用が詰む状態だった。2.1.146 でスキル名・カスタムコマンド名だけの入力も「正規の入力」として扱われるようになる。

bash— 2.1.146 で素直に動くようになるパターン


# これだけを入力 → /background で背景化したい
/code-review 1234 high

# あるいは自作スキル単独で背景化
/run-batch-tests

# 2.1.145 までは「入力が無い」と弾かれていた
スキル単独・スラッシュコマンド単独の入力が /background で正しく扱われる

user@sinyblog:~/article 11_managed_settings.md管理ポリシーが第三者プロバイダ・APIキーにも効くように

エンタープライズ運用者が見落とせない修正がここ。

Fixed forceLoginOrgUUID and forceLoginMethod managed-settings policies not being enforced against third-party-provider and API-key sessions

CHANGELOG.md — v2.1.146 / [1]

公式 Settings ドキュメントによれば [3]、Claude Code は managed-settings として次の 2 つのログイン制約を提供している。

ポリシー 仕様(公式 Settings ドキュメントより)
forceLoginOrgUUID 「ログインを特定組織に所属しているアカウントへ制限する。単一 UUID(その組織がログイン時にプリ選択される)または UUID 配列(いずれかに所属していれば許可)を受け付ける。Managed settings で設定された場合、所属していないアカウントのログインは失敗する。空配列は fail-closed でログインをブロックする」[3]
forceLoginMethod claudeai を指定すると Claude.ai アカウントに、console を指定すると Claude Console(API 課金用)アカウントにログイン手段を制限する」[3]

2.1.146 までの問題は、この 2 ポリシーが 第三者プロバイダ(Bedrock / Vertex 等)経由API キー直接設定セッション に対して適用されていなかった点だ。会社が「うちは特定組織アカウントしか許可しない」と policy を仕込んでも、ANTHROPIC_API_KEY を環境変数に置いて直接叩くワークフローや Bedrock 経由のセッションだとすり抜けていた。2.1.146 でこの抜け穴が塞がれる。

json— managed-settings.json の例


{
  "forceLoginMethod": "claudeai",
  "forceLoginOrgUUID": [
    "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy"
  ]
}
公式 Settings ドキュメントより形式を再構成 [3]。2.1.146 以降は API キー・第三者プロバイダ経由にも効く
情シス・SRE 視点でのチェックリスト

① managed-settings.json で forceLoginOrgUUID を設定済みの組織は、社内に「API キー直接運用」「Bedrock / Vertex 経由運用」のメンバーがいないか棚卸しする。② 2.1.145 までは抜けていたので、過去ログを遡って想定外組織のアカウントが繋がっていないか確認する余地がある。③ 2.1.146 以降は当該セッションも fail する(=ログイン拒否される)ので、社内連絡を先に出す。

user@sinyblog:~/article 12_subagent_model_env.mdCLAUDE_CODE_SUBAGENT_MODEL が子プロセスへ伝播するように

マルチエージェント運用に効くもう一つの修正。

Fixed CLAUDE_CODE_SUBAGENT_MODEL not being forwarded to child processes in multi-agent sessions

CHANGELOG.md — v2.1.146 / [1]

CLAUDE_CODE_SUBAGENT_MODEL は、サブエージェント(worker agent)の使用モデルを上書きする環境変数だ [8]。社内 LLM プロキシが特定モデルしか通さない構成や、サブエージェントを安価な Haiku に固定したい場合に重宝する。

2.1.146 以前は、メインプロセスでこの環境変数を設定していても、マルチエージェントセッション中に 子プロセスへ伝播しない ケースがあった。結果として「ローカルでは Haiku になっているはずなのに、サブエージェントだけデフォルトモデルが使われていて課金やレイテンシが想定外」という現象が起こりうる。今回の修正で、子プロセスへも素直に渡るようになる。

bash— サブエージェントを Haiku に固定する例


# macOS / Linux
export CLAUDE_CODE_SUBAGENT_MODEL=claude-haiku-4-5

# Windows PowerShell
$env:CLAUDE_CODE_SUBAGENT_MODEL = "claude-haiku-4-5"

# その後 claude を起動すると、サブエージェントは指定モデルに固定される
claude
2.1.146 以降は子プロセスへ素直に伝播するようになった [8]
運用視点での意味

サブエージェントは「呼び出し回数」が多い。呼び出し回数 × 単価 でコストが効く層なので、ここを Haiku に寄せられるかどうかでひと月の請求が変わる。2.1.146 以降は「環境変数を投げれば狙い通りに効く」という信頼性が手に入る。

user@sinyblog:~/article 13_updater_and_diff.mdAuto-updater リトライ&Diff レンダリング高速化

「Improvements」セクションは 2 行だが、両方とも実用上の効きが大きい。

Improved auto-updater reliability: native version checks and downloads now retry transient network failures instead of failing immediately

Improved diff rendering performance for large file edits

CHANGELOG.md — v2.1.146 / [1]

Auto-updater は、Claude Code 起動時にバージョンチェックと更新ダウンロードを行う仕組みだ。これまでは 一度のネットワーク失敗で即諦め ていたが、2.1.146 からは transient failure(一過性の失敗)に対してリトライを入れる。社内プロキシや一時的なネットワーク不調で「更新できない」と表示されていた現象が減る。

Diff レンダリングは、大きなファイル編集中の 表示パフォーマンス が改善されたもの。Edit / MultiEdit で数百〜数千行のファイルを触ると以前は描画が重く感じることがあったが、大規模 refactor 中のもたつきが軽減する。

アップデート関連は 2.1.146 で「3点セット」が揃った

① 失敗時に 現バージョンを表示 するように修正(fix)、② transient failure にリトライ(improvement)、③(2.1.144 で)api.anthropic.com 到達不可時の起動ハング 75 秒問題が 15 秒タイムアウトに [1]。Auto-updater 周辺のユーザー体験はこの 3 リリースで一気に良くなった。

user@sinyblog:~/article 14_misc_fixes.md細かい修正の一掃 — /theme Esc・Agent SDK・GNOME paste

残りの fix を一気に拾っておく。それぞれ単独では小粒だが、「触る人にとっては触らない人より体感が大きい」タイプの修正だ。

修正 誰に効くか 体感
Auto-updater ステータスラインが、更新失敗時に現在バージョンを表示するように 全ユーザー 「いま自分は何バージョン?」が画面上で確認できる
/theme の color editor と「New custom theme」ダイアログが Esc に反応するように テーマカスタマイザー カラーピッカーから素直に抜けられる
Agent SDK 経由のストリーミングセッション終端で uncaught exception が出ていたのを修正 Agent SDK 利用者 セッション終端でクラッシュしない
GNOME Terminal の右クリック・中クリックペーストが反応しないバグ Linux + GNOME ユーザー マウスでのテキスト貼り付けが復旧

2.1.144 〜 2.1.146 の流れを通じて見ると、Anthropic は 主要環境(macOS)以外の体験を丁寧に均す 方向に投資している。Windows Terminal のチカチカ、winget 経由 pwsh、NTFS junction、GNOME Terminal ペースト、いずれもユーザーが「マイナー環境だから諦めていた」類の不具合だ。これらが順次潰されていることは、Claude Code を 主要 OS の専有ツール から 汎用 CLI ツール へ寄せる路線として読み取れる。

user@sinyblog:~/article 99_summary.mdまとめ — 「速くする」より「外さない」が今期の路線

Claude Code 2.1.146 は派手な新機能リリースではない。だが「これまで地味に外していた挙動を一斉に揃え直す」という意味で、運用者ほど効くアップデートだ。要点は 3 つ。

  1. /simplify/code-review 改名と effort レベル。9 ステップ・最大 7 エージェントの本気 PR レビューを、low / medium / high で打ち分けられるようになった。本番マージ前の high 監査と、ドラフト PR の low 監査をワークフローに組み込んでみる価値がある。
  2. Auto モードが AskUserQuestion を尊重 + バックグラウンドが don't ask again を保持。スキルが必須質問を出せるようになり、長時間タスクが「許可済みのはずなのに止まる」が消える。スキル制作者と長時間タスク運用者の両方に効く。
  3. 環境依存バグの一掃。Windows PowerShell(winget/Store)、NTFS junction、MCP ページネーション、GNOME ペースト、管理ポリシーの抜け穴、サブエージェント環境変数の伝播。マイナー環境を切り捨てない方針が出ているので、「今までうちの環境で詰んでいた」案件はこのバージョンで再確認する価値がある。

アップデートは claude --upgrade 一発。Windows / Linux / Bedrock / Vertex / 第三者プロキシ / 自作スキル開発を全部含めて、2026 年 5 月時点では 2.1.146 を当てておくのが最も安全 という結論で問題ない。

本記事は Claude Code 公式 CHANGELOG.md(v2.1.146、2026 年 5 月 21 日公開)と plugins/code-review/commands/code-review.md を一次情報として参照し、運営者(現役 IT エンジニア・15 年以上の業界経験)が編集・構成しています。プロンプト整形・初稿生成には Anthropic Claude を補助的に使用しており、内容の最終確認・文言調整・出典の突き合わせは人手で実施しました。仕様変更が早い領域のため、最新情報は 公式ドキュメント をご確認ください。

おすすめの記事