はじめに
サーバーワークスの池田です。
今週（5/31〜6/6）の Claude Code は、フォールバックモデルが対話セッションでも効くようになり、権限まわりの安全策が強化され、動的ワークフローの起動キーワードが ultracode に変わりました。派手な目玉機能は少なく、毎日使う人ほど効いてくる地に足のついた改善が中心の1週間です。
対象は v2.1.159 から v2.1.167 までの8バージョンです（v2.1.164 は欠番）。
なお今週は公式の「What's new」ダイジェストがまだ公開されていない期間です。本記事では公式 CHANGELOG とドキュメントを突き合わせ、実務で意味のある変更を選んで解説します。
この記事で分かること
- 主モデルが過負荷のとき自動で別モデルに切り替える フォールバックモデル（fallback model）が対話セッションでも効くようになった点
- シェル起動ファイルやビルド設定ファイルへの書き込みを事前確認するようになった 権限まわりの安全強化
- 動的ワークフローの起動キーワードが
workflowからultracodeに変わった点と、混同しやすい注意点 /plugin listの追加やclaude mcpのシークレット秘匿など、その他の実務的な変更点
今週の主要アップデート一覧
| 機能 | バージョン | 主な変更点 | 参照 |
|---|---|---|---|
| フォールバックモデル | v2.1.166 | 主モデルが過負荷・利用不可のとき別モデルへ自動切り替えする --fallback-model が、対話セッションにも適用されるように。非リトライエラー時の1回再試行も追加 |
Releases v2.1.166 |
| 権限まわりの安全強化 | v2.1.160・v2.1.166 | シェル起動ファイルやビルド設定ファイルへの書き込みを事前確認。セッション間メッセージがユーザー権限を持ち越さないよう厳格化 | Releases v2.1.160 |
| ワークフロー起動キーワードの変更 | v2.1.160 | 動的ワークフローを一発起動するキーワードが workflow から ultracode に変更。誤起動を防ぐための変更とみられる |
Workflows |
フォールバックモデルが対話セッションでも効くようになった
v2.1.166 で、主モデルが過負荷・利用不可のときに別のモデルへ自動で切り替えるフォールバックモデルまわりが改善されました。Opus に処理が集中してリクエストが弾かれる場面で、作業を止めずに継続するための保険です。
設定方法は2通り
フォールバック先は --fallback-model フラグで指定できます。
claude --fallback-model sonnet
settings.json の fallbackModel に配列で指定することもできます。毎回フラグを渡さなくても、常にフォールバックを効かせられます。複数指定すると、主モデルが使えないときにリストの先頭から順に試します。
{ "fallbackModel": ["claude-sonnet-4-6"] }
公式 CHANGELOG によると、これまで非対話の実行（-p やバックグラウンド）向けだった --fallback-model が、v2.1.166 で対話セッションにも適用されるようになりました。
設定しても普段は何も変わらないように見える
ここは誤解しやすいポイントです。--fallback-model sonnet を付けて起動しても、主モデル（Opus 4.8）が正常なうちは Opus のまま動きます。ヘッダーのモデル表示も Opus のままです。
フォールバックは「主モデルが使えないときの保険」なので、Opus が実際に過負荷で弾かれるまでは何も起きません。Sonnet に切り替わるのは Opus がコケたときだけです。設定が効いているのに表示が変わらないのは、正常な状態だと考えてよいでしょう。
公式ドキュメントも「Claude Code はモデルのバージョンを黙って切り替えることはない。Opus のクォータ到達などの特定の場合にフォールバックする」と説明しています。
--fallback-model sonnet を付けて起動しても、Opus が正常なうちはヘッダーも動作も Opus 4.8 のままです
あわせて入った関連の改善
同じ v2.1.166 で、API が想定外のエラーを返したときの挙動も変わりました。リトライ不可のエラーをサーバーが返した場合でも、フォールバックモデルで1回だけターンを再試行するようになっています。
ただし認証エラー・レート制限・リクエストサイズ超過・通信エラーは、これまでどおり即座に表示されます。これらはフォールバックでは解決しないため、再試行せずにすぐ知らせる設計です。
なお既定では、フォールバックがトリガーされるのは Opus モデルで過負荷エラーが繰り返し発生したときです。すべての主モデルでフォールバックを効かせたい場合は、環境変数 FALLBACK_FOR_ALL_PRIMARY_MODELS を設定します。
権限まわりの安全強化 起動ファイルとビルド設定の書き込み確認
先週は、Claude が書いたコードの脆弱性をその場で検知する security-guidance プラグインが話題になりました。今週はその流れを継ぐように、Claude のファイル操作そのものに対する安全策が複数入っています。
ここで前提を整理します。Claude Code には権限モードがあり、default は編集のたびに確認を出し、acceptEdits はファイル編集を自動承認します。今週の変更は、この「自動承認するモードでも、危険なファイルだけは例外的に確認する」という性質のものです。
acceptEdits でもビルド設定ファイルは確認する
これが今週の変更の中心です。編集を自動承認する acceptEdits モードは、これまでファイル編集をすべて確認なしで通していました。v2.1.160 で、コード実行を許してしまうビルド設定ファイルだけは、acceptEdits でも書き込み前に確認するようになりました。
対象は次のようなファイルです。いずれもインストールやビルドの過程で任意コマンドを実行しうるものです。
| ファイル | 主な役割 |
|---|---|
.npmrc / .yarnrc* |
npm / Yarn の設定（インストール時フック等） |
bunfig.toml |
Bun の設定 |
.bazelrc |
Bazel のビルド設定 |
.pre-commit-config.yaml |
pre-commit フックの定義 |
.devcontainer/ |
開発コンテナの設定 |
公式 CHANGELOG では、上記に加えてその他のビルド設定ファイルも対象になると記載されています。acceptEdits で快適に作業しつつ、危険度の高いファイルだけは人間の確認を挟む、という現実的な落としどころです。
シェル起動ファイルへの書き込みを事前確認
v2.1.160 で、シェルの起動ファイルや Git の設定ディレクトリに書き込む前に確認を求めるようになりました。対象は次のとおりです。
| ファイル | 主な役割 |
|---|---|
.zshenv / .zlogin / .bash_login |
シェル起動時に読み込まれる設定 |
~/.config/git/ 配下 |
Git の設定 |
これらは意図しないコマンド実行につながりうるため、書き込み前に一度立ち止まる設計になりました。default モードでは元々ファイル編集に確認が出ますが、今回の追加で、これらのファイルが「特に気をつけるべき対象」として扱われるようになっています。
実際に編集を自動承認する acceptEdits モードで .zshenv を編集させると、自動承認されずに確認のプロンプトが表示されます。
acceptEdits モードでも、.zshenv への書き込みは自動承認されず確認が表示されます
ただし、すべての確認をスキップする bypass permissions モードでは、この確認も出ません。公式ドキュメントでも、bypass permissions は権限レイヤーそのものを通さないと説明されています。普段からこのモードで運用している場合は、起動ファイルへの書き込みも確認なしで通る点に注意が必要です。
セッション間メッセージの権限を厳格化
v2.1.166 では、複数の Claude セッションをまたぐメッセージのやり取りも強化されました。
SendMessage で別のセッションから中継されたメッセージは、ユーザーの権限を持ち越さなくなりました。受信側は中継された権限リクエストを拒否し、auto モードでもブロックします。あるセッションの権限を別セッション経由で勝手に行使される事故を防ぐ変更です。
あわせて、deny ルールのツール名にグロブパターンが使えるようになりました。"*" を指定すると全ツールを拒否できます。一律で絞ってから必要なものだけ許可する、という運用がしやすくなります。
動的ワークフローを一発起動するキーワードが ultracode に変わった
先週、Claude が自分でスクリプトを書いて多数のサブエージェントを動かす 動的ワークフロー（dynamic workflows）が研究プレビューとして公開されました。今週 v2.1.160 で、その起動方法のうち1つが変わっています。
まず用語を整理する
ここは「コマンド」と「キーワード」が混ざりやすいところです。混同を避けるため、ワークフローを動かす方法を3つに整理します。
| 方法 | 種類 | 何をするか |
|---|---|---|
プロンプトに ultracode と書く |
プロンプト内のキーワード | そのタスク1回だけをワークフローとして実行する |
/effort ultracode |
スラッシュコマンド（/effort の引数） |
セッション全体で Claude が毎回ワークフローを使うか判断する |
/workflows |
スラッシュコマンド | 実行中・完了したワークフローの一覧と進捗を見る |
今週変わったのは1つ目の「プロンプトに書くキーワード」だけです。/effort や /workflows といったスラッシュコマンドは従来どおり使えます。/ultracode というスラッシュコマンドは存在しません。
何が変わったのか
プロンプト本文に書くと、そのタスクをワークフローとして一発起動するキーワードが workflow から ultracode に変更されました。公式ドキュメントも「v2.1.160 より前はキーワードが workflow だった」と境界を明記しています。
ultracode: src/routes/ 配下の全 API エンドポイントを認証チェック漏れがないか調べて
このようにプロンプトの先頭に ultracode と書くと、Claude がそのタスク用のワークフロースクリプトを書いて実行します。
workflow は日常的によく使う英単語のため、「この workflow を直して」などと書いただけで意図せずワークフローが起動してしまう場面がありました。偶然タイプしない ultracode に置き換えることで、誤起動を防ぐ狙いとみられます。
なお、use a workflow・run a workflow のように自然な言葉でワークフローを依頼する方法は、バージョンに関係なく（v2.1.160 の前後どちらでも）従来どおり使えます。
意図せず起動してしまったら
キーワードに反応させたくないときは、送信前に入力のハイライトを解除します。操作は次のとおりです。
| 操作 | 動作 |
|---|---|
Option+W（macOS）/ Alt+W（Windows・Linux） |
送信前の入力のハイライトを解除 |
ハイライトされたキーワード直後で Backspace |
同上 |
/config の「Ultracode keyword trigger」をオフ |
キーワードによる起動を完全に無効化 |
補足:
ultracodeはモデルの努力レベル（effort level）ではなく、xhighの推論と自動ワークフローを組み合わせた Claude Code 側の設定だと公式は説明しています。動的ワークフローそのものの仕組みや使い方は、Claude Opus 4.8 とあわせて別の記事で扱う予定です。
その他の変更点
注目アップデート以外にも、実務に効く変更が複数ありました。公式 CHANGELOG に記載されたものから抜粋します。
| 変更点 | バージョン | 参照 |
|---|---|---|
/plugin list コマンドを追加（--enabled / --disabled で絞り込み可能） |
v2.1.163 | Releases v2.1.163 |
requiredMinimumVersion / requiredMaximumVersion 管理設定を追加。許可範囲外のバージョンでは起動を拒否 |
v2.1.163 | Releases v2.1.163 |
claude mcp の list / get / add がシークレットを出力しないよう修正。${VAR} を展開せず、認証ヘッダや URL の秘匿情報をマスク |
v2.1.161 | Releases v2.1.161 |
管理設定の allowedMcpServers / deniedMcpServers が ${VAR} 参照でマッチしない不具合を修正 |
v2.1.166 | Releases v2.1.166 |
/effort が、選んだレベルを新規セッションの既定として保存するとき確認するように変更 |
v2.1.162 | Releases v2.1.162 |
| 自動補完のスラッシュコマンドをクリックしても即実行せず、入力欄に挿入するよう変更（Enter で実行） | v2.1.162 | Releases v2.1.162 |
MAX_THINKING_TOKENS=0 や --thinking disabled で、既定で思考するモデルの思考を無効化できるように（Claude API 経由のモデルのみ。サードパーティプロバイダは対象外） |
v2.1.166 | Releases v2.1.166 |
OTEL_RESOURCE_ATTRIBUTES の値をメトリクスのラベルに含めるように。チームやリポジトリ単位で利用量を分析可能に |
v2.1.161 | Releases v2.1.161 |
| 並列ツール呼び出しで、1つの Bash コマンドが失敗しても同じバッチの他の呼び出しをキャンセルしないよう修正 | v2.1.161 | Releases v2.1.161 |
| JetBrains 系 IDE（IntelliJ・PyCharm・WebStorm 等）2026.1 以降のターミナルのちらつきを修正 | v2.1.166 | Releases v2.1.166 |
まとめ・次週の注目ポイント
今週は単発の派手な機能よりも、過負荷対策・権限の安全強化・MCP の整備といった、運用の足場を固める改善が並んだ1週間でした。
なかでもフォールバックモデルが対話セッションでも効くようになった点は、Opus への負荷集中で作業が止まる場面が増えてきた今、--fallback-model を付けて起動するだけで効く実用的な改善です。権限まわりの安全強化も、Claude にファイル操作を任せる範囲が広がるほど効いてきます。
動的ワークフローの起動キーワードの変更からは、研究プレビューで公開された機能が実運用に向けて細部を詰めている様子がうかがえます。次週も、こうした新機能まわりの整備や安定化が続くか、引き続き注目していきます。
