Claude Code の v2.1.289 〜 v2.1.296 には多数の変更が入りましたが、その中から実務への影響が大きいと思われるものを5つ選んで深掘りします。網羅的な変更点一覧は前回の記事にまとめてあるので、今回は「なぜ注目に値するか」にフォーカスします。

1. フックの `onFailure: "block"`（v2.1.295）

command / HTTP フックが「起動できない」「タイムアウトした」「想定外の終了コードで終わった」場合に、これまでは処理が素通りしていましたが、onFailure: "block" を指定するとそのアクションをブロックできます。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "./scripts/guard.sh", "onFailure": "block" }
        ]
      }
    ]
  }
}

なぜ注目に値するか

セキュリティや品質のゲートとしてフックを使う場合、「フック自体が壊れたら守りが消える」（fail-open）ことが弱点でした。onFailure: "block" により、ゲートを fail-closed に倒せます。あわせて v2.1.296 では、managed settings の PreToolUse フックが "continue": false で拒否してもターンが終わらない問題が修正され、v2.1.292 ではフック出力中の <system-reminder> タグがエスケープされるようになりました。フックを安全装置として使う土台が、この数バージョンで一気に固まっています。

また --debug でフックの command・plugin・結果・所要時間がログされるようになったため（v2.1.296）、遅いフックの特定も容易になりました。

2. サブエージェント制御の強化（v2.1.292 / v2.1.296）

Agent ツールの effort パラメータ（v2.1.292）: 指定した努力レベルでサブエージェントを実行
autoCompactWindow（v2.1.296）: サブエージェントの frontmatter と --agents 定義で指定でき、メイン会話より早く auto-compact
CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL（v2.1.296）: Workflow のエージェントすべてを 1 つのモデルで実行

---
name: log-summarizer
description: ログを要約する軽量エージェント
autoCompactWindow: 100000
---

なぜ注目に値するか

サブエージェントを多用すると、コストとコンテキストの管理が課題になります。調査系は軽いモデル・低い effort、設計系は重いモデル・高い effort といった使い分けを、プロンプトや設定で宣言的に書けるようになりました。後述の Haiku 5.5 と組み合わせると、大量並列のワークフローをかなり安く回せます。

3. Claude Haiku 5.5 の登場と料金改定（v2.1.293 / v2.1.296）

v2.1.293 で claude-haiku-5-5 が追加され、Anthropic API の既定 Haiku モデルになりました。1M コンテキストで、料金は $0.10 / $0.50 per Mtok（100K 超のプロンプトは $0.50 / $2.50）です。v2.1.296 では Sonnet 5.5 のキャッシュ読み取りも $0.20 → $0.10 / 百万トークンに下がり、/cost・ステータスライン・--max-budget-usd の見積もりに反映されます。

なぜ注目に値するか

第三者の紹介記事では、Haiku 5.5 は 2026年10月7日に公開された Anthropic で最速のモデルで、Haiku として初めて effort レベルを備えるとされています（Anthropic Releases Claude Haiku 5.5 | AI Catchup）。要約・分類・サブエージェントのような大量処理向けで、複雑なエージェント型コーディングの主力には Sonnet 5.5 / Opus 5.5 が引き続き適する、という位置づけです。Haiku 4.5 向けに書いたコードがそのままでは動かない可能性も指摘されており、モデル ID を固定している場合は移行時の確認が必要です。

4. MCP プロトコル 2026-07-28 の既定化（v2.1.292 / v2.1.295 / v2.1.296）

ローカル（stdio）MCP サーバーは、全インストールで MCP プロトコル 2026-07-28 を既定でネゴシエーション（v2.1.292）
claude.ai コネクタも同様（v2.1.295）
MCP_PROTOCOL_NEGOTIATION=legacy でオプトアウト
新プロトコルを理解しない stdio サーバーは、1 回遅い接続になった後 7 日間記憶され、旧方式で待ち時間なく接続（v2.1.292）
tool search 経由の MCP ツール説明の上限は 2,048 → 16,384 文字（v2.1.295）。先出しの説明と instructions の既定上限は 2,048 → 4,096 文字（v2.1.296）

# 問題が出る場合は旧方式に戻す
export MCP_PROTOCOL_NEGOTIATION=legacy

なぜ注目に値するか

Anthropic の発表では、2026-07-28 版は MCP を双方向・ステートフルなプロトコルからリクエスト/レスポンス型へ移すものと説明されています（Bringing MCP 2026-07-28 to Claude）。自作や社内の MCP サーバーを使っている場合、起動の遅さや接続エラーとして影響が出る可能性があります。エスケープハッチが用意されているので、アップデート後に MCP の挙動がおかしいときは真っ先に試せます。

5. Read の `allow_large` と Grep・各ツールの入力寛容化（v2.1.292 / v2.1.295 / v2.1.296）

Read ツールに allow_large（v2.1.296）: 全体が必要でコンテキストに余裕があるとき、通常のサイズ上限を超えるテキストを 1 回で読める
Grep が file_path を path の代わりに受け付ける（v2.1.292）。-l / -c / -r フラグ付きの検索も失敗せず実行される（v2.1.295）
Write・WebFetch・Read は、余計なパラメータを無視して呼び出しを失敗させない（v2.1.292）

なぜ注目に値するか

派手さはありませんが、「ツール呼び出しが入力の細かな違いで失敗して、1 ターン無駄になる」ことは日常的に起きていました。入力の揺れを吸収する変更が積み重なると、ターン数とトークンの節約になります。大きなファイルを諦めて分割読みする必要が減る点も、地味に効きます。

まとめ

テーマ	内容
安全性	フックを fail-closed にできる `onFailure: "block"`
コスト・並列実行	`effort` / `autoCompactWindow` / ワークフロー用モデル指定
モデル	Haiku 5.5 と Sonnet 5.5 のキャッシュ料金改定
互換性	MCP プロトコル 2026-07-28 の既定化（`legacy` で戻せる）
使い勝手	Read `allow_large`、ツール入力の寛容化

特に 1 と 4 は、アップデートするだけで挙動や互換性に関わります。フックを安全装置にしているチームは onFailure の指定を、MCP サーバーを自作しているチームは新プロトコルでの接続確認をおすすめします。

参考