Claude Code の正典にも賞味期限がある——週次リリースノートを読み切って見つかった、前提が変わっていた4件

はじめに

AIコーディングアシスタントの仕様を、一度まとめて資料にしたことがある。以後はその資料（以下、正典と呼ぶ）を都度参照して運用している。だが、対象の製品は週次でアップデートが続いている。正典を作った時点の理解が、今もそのまま正しいとは限らない。

そこで、週次のリリースノートをまとめて読み切ることにした。目的は新機能を追うことではなく、自分たちの正典の記述と、実際の仕様がどこでずれているかを機械的に洗い出すことだった。結果、運用ルールの前提が変わっていたものが複数見つかった。そしてもう一つ、想定していなかった発見もあった——正典そのもの、それも数日前に自分が書いた説明文の中に、引用の欠けが見つかったのだ。

発見1: 分類器を経ない、無条件の拒否ルールが増えていた

権限のルールには、AIの判断（過去のやり取りを踏まえて可否を判定する分類器）を経由するものと、経由しないものがある。ある週のリリースノートに、後者の新しい設定項目があった。

New settings.autoMode.hard_deny rules block matching actions unconditionally in auto mode, regardless of allow exceptions, for actions that should never run automatically even when broader allow rules apply

分類器の判断を挟まず、無条件でその行為を止める拒否ルールが新設されていた。これまで確認していた仕組みでは、拒否ルール以外の判定はほぼすべて分類器（AI自身の判断）を通っていた。判断を経由しない、より硬い壁の選択肢が新たに増えていたことになる。

発見2: 人間に確認していたはずの操作が、今は判断に置き換わっていた

もう1つ、別の週のリリースノートには、既存の安全確認の仕組みそのものが変わっていた記述があった。

In auto mode, the checks for dangerous rm commands, background jobs, and suspicious Windows paths no longer open permission dialogs; the auto-mode classifier adjudicates them instead

危険な削除コマンド・バックグラウンドで動く処理・不審なWindowsのパス操作は、以前は人間への確認画面が出ていた。今はその確認画面が出ず、AI自身の判断（分類器）に置き換わっている。 「危険な操作は必ず人間が確認する」という前提を持っていた場合、その前提はバージョンが上がった時点で静かに変わっていたことになる。

発見3: モデルの切り替わりには、3種類の引き金があった

以前、別の資料を読んでいて「モデルが自動で切り替わる条件」を1つ確認していた。今回、別の週のリリースノートを読むと、同じ現象を指す別の条件が見つかった。

Claude Code now switches to your configured --fallback-model for the rest of the session when the primary model is not found, instead of failing every request

「利用したいモデルが見つからない場合」という3つ目の引き金があり、しかもこの場合はセッションが終わるまでずっと切り替わったままになる。以前確認していた「AIの安全判断による切り替え」はセッション継続、また別の資料にあった「一時的な利用不可による切り替え」はそのやり取り一回限り——同じ「モデルが切り替わる」という現象でも、引き金によって元に戻るタイミングが違う、ということが3つ目の資料を読んで初めて分かった。

発見4: 自分が数日前に書いた説明文に、原文の条件が欠けていた

ここまでは製品側の変化だったが、最後の発見は方向が違った。以前、別の記事で「セッション内で会話の文脈を引き継いだまま作業を分岐させる」機能について、次のように書いていた。

セッション内の forked subagent は /subtask に改名された

これを、該当する公式資料の原文と一字ずつ突き合わせてみた。

A forked subagent, started with /subtask, is a subagent that inherits your full conversation context instead of starting fresh. … With agent view turned off, the forked-subagent command is /fork instead and /subtask isn’t available.

原文には**「ある表示モードが有効になっている場合に限り」という条件節**が付いていた。その表示モードを切っていれば、コマンド名は改名前のままで、/subtask というコマンド自体が存在しない。自分が書いていた説明文は、この条件を落として「無条件に改名された」と一般化してしまっていた。

さらに、身内の資料どうしでも条件節の有無が違っていた

この欠けを見つけた後、念のため同じ機能について書かれた、別の言語向けの技術資料も確認した。片方にはこうある。

Deprecated; ignored. Subagents inherit the parent session’s permission mode; agent-definition frontmatter may override it

もう片方には、同じ項目に条件が付いていた。

The mode field is deprecated and ignored on Claude Code v2.1.212 or later: subagents inherit the parent session’s permission mode, and a subagent definition’s permissionMode can override it, except when the parent uses bypassPermissions, acceptEdits, or auto, and Claude Code ignores a definition’s permissionMode: "bypassPermissions" when bypass mode is disabled by permissions.disableBypassPermissionsMode

同じ製品の、同じ機能について書かれた2つの公式資料ですら、片方には条件節が無く、片方にはある。 片方を読んで済ませてしまうと、条件付きの制約を無条件だと誤解したまま運用することになる。

発見の道のり

起点: 正典を一度作ったまま、都度参照して運用している
      │
      ├─▶ 週次リリースノートを字数の小さい順に、全部読み切る
      │        ├─ 発見1: 分類器を経ない無条件の拒否ルールが新設(hard_deny)
      │        ├─ 発見2: 人間確認だった操作が、判断(分類器)に置き換わっていた
      │        └─ 発見3: モデル切替の引き金が3種類あり、持続時間が違う
      │
      └─▶ ついでに、正典の記述を原文と1文字ずつ突き合わせる ★ここで方向が変わる
               └─ 発見4: 自分が数日前に書いた説明文から条件節が1つ欠けていた
                     │
                     └─▶ 念のため、別言語向けの技術資料でも同じ項目を確認
                              └─(戻りエッジ)──▶ 身内の資料どうしでも条件節の有無が違うと判明
                                                    └─ ⇒ 「昨日の自分」も一次資料ではない、と確定

一次資料の突き合わせを、運用手順に組み込む

[運用] 資料を正典に反映する前の機械確認(要旨)
1. 追記・訂正しようとしている用語を、既存の正典3本でカウントする
   → 既にある場合は「新発見」ではなく「再確認」として記録する
2. 引用する一文は、原文ファイルを直接検索して一字一句突き合わせる
   → 条件節(「〜の場合を除き」「〜が有効な時のみ」)を、要約の過程で落としていないか確認する
3. 同じ機能について複数の資料がある場合、片方だけで確定させない
   → 両方読んでから「片方に条件節がある」という事実そのものを記録する

この手順を通すようになったきっかけが、今回の発見4だった。訂正して終わりではなく、「なぜ条件節を落としたか」を確認すると、原因は毎回同じ——急いでいる時ほど、一文の途中にある「except when」や「unless」を読み飛ばしていた。

正典を作ることと、正典を保つことは別の作業

週次のリリースノートを読み切って分かったのは、製品の仕様が変わり続けているという当たり前の事実だけではなかった。自分が書いた説明文自体も、書いた瞬間から古くなり始める、という事実だった。一度資料を作ったら安心して参照し続けるのではなく、時々、原文に戻って一字ずつ照合し直す必要がある。今回それをやってみたら、製品側の変化が3件、自分たちの記述の側の誤りが1件、合わせて4件の前提のずれが同時に見つかった。

Claude Code の「キャッシュが壊れる」を一次資料まで遡る——Reddit の不具合報告→公式postmortem→arXiv論文2本

Claude Code のオーケストレーター用サブエージェントを廃止した理由——公式harness仕様に基づく構造的な3つの制約

Claude Code の引継ぎ文書が、打ち切った調査を次のセッションに再開させていた — 「進捗」と「規律」に分けて直した記録

4件のうち1件は、製品ではなく自分の要約が原文の条件節を落としていたものだった。機能ごとの資料をいくら丁寧に読んでも、この型は見つからない。変更履歴を版の順に通しで読む経路を、別に1本持っておくこと——今回の読み直しが残したのは、発見4件よりもこの経路の方だ。