Claude Codeが工程を勝手に走らせない｜v2.1.215

「頼んでいないのに、AIが勝手に検証やレビューを走らせて時間とトークンを食う」——AIに作業を任せるほど、この"余計な工程"のもやもやは大きくなります。

結論から言うと、Claude Code v2.1.215で /verify と /code-review が自分から走らなくなり、使いたいときだけ明示的に呼び出す形に変わりました。無人運用では、この「工程の割り込みを止める」設計こそが安定の鍵になります。

株式会社Fyveは、複数のジョブを無人で回しながらAI活用を設計しています。私自身が「工程を明示的に組む」運用をしている立場から、この変更が実務のどこに効くのかをお伝えします。

Claude Code v2.1.215で何が変わったのか

2026年7月19日に公開された Claude Code v2.1.215 で、/verify（検証）と /code-review（コードレビュー）のスキルが、Claude の判断で自動的に走ることがなくなりました。公式チェンジログには次のように記載されています。

「Claude no longer runs the /verify and /code-review skills on its own; invoke them with /verify or /code-review when you want them」（Claude Code 公式チェンジログ／releasebot・ともに2026年7月19日付で同一文言を確認）

意訳すると「Claude はもう /verify と /code-review を自分から走らせない。使いたいときは /verify や /code-review と明示的に呼び出してほしい」という変更です。つまり「自動で気を利かせる」から「頼まれたときだけ動く」へ既定の振る舞いが変わったということになります。

/verify と /code-review はそもそも何をするスキルか

この2つは、Claude Code に組み込まれた作業品質のチェック工程です。

/verify — 変更が「実際に意図どおり動くか」をエンドツーエンドで確かめる工程。テストやビルドだけでなく、影響範囲を実際に動かして挙動を観察します。
/code-review — 差分をレビューし、バグや簡素化の余地を指摘する工程。人間のコードレビューに近い視点を自動で当てます。

どちらも「品質を上げる」ための有用な工程です。問題は、それが呼んでいないのに走ってしまう場面がある、という点にありました。

「勝手に走る」の何が問題だったか

気を利かせて検証やレビューが挟まるのは、対話しながら一緒に作業しているときには便利です。ですが、次のような場面では逆に困ります。

トークンと時間の予期せぬ消費 — 小さな編集のつもりが、裏で重い検証まで走って枠を食う。
出力が読めなくなる — 同じ指示でも走る工程が変わると、結果が毎回ぶれて再現しにくくなる。
無人運用での制御不能 — 人が見ていない場で余計な工程が割り込むと、止めることも巻き戻すこともできない。

v2.1.215は、この「頼んでいない工程の割り込み」を既定で止める守りの変更だと私は捉えています。

自分の環境が対応しているか確認する

この挙動はv2.1.215以降の既定です。手元のバージョンが古いと、まだ従来どおり検証・レビューが自動で走る場合があります。

バージョンを確認する — Claude Code上で /status や起動時の表示からバージョンを確認し、v2.1.215以上かを見ます。
古ければ更新する — 更新すると、以降は明示呼び出しが既定になります。無人ジョブを組んでいるなら、更新のタイミングで工程の呼び出しが手順に書けているかも合わせて見直すと安全です。

細かなマイナー更新なので見落としがちですが、無人でジョブを回している場合は「いつから工程が自動で走らなくなるか」を把握しておくと、挙動の変化に驚かずに済みます。

なぜ無人運用でこの変更が効くのか

私は、Mac mini を常時起動させて複数のジョブを無人で回しています。無人でAIを走らせるとき、私がいちばん神経を使うのは「頼んだ工程だけが、頼んだ順に走る」ことを保証する設計です。

人が横で見ていれば、AIが余計なことを始めても「それはいい」と止められます。しかし無人ジョブでは、その一言を挟む人がいません。だからこそ工程は自動で増えないほうがいい——気を利かせて挟まる1工程が、トークンの浪費にも、出力のばらつきにも直結するからです。

v2.1.215の「自分から走らせない」は、まさにこの決め打ちで工程を組みたい運用者の要望に、ツールの既定を寄せた変更です。私のように無人ジョブを組む立場からすると、「余計な工程が勝手に増えない」という保証が既定で得られるのは、地味ですが効く改善でした。

「気を利かせる」より「明示する」ほうが壊れにくい

AIに任せる範囲が広がるほど、「自動で判断して動く」機能はもろ刃になります。判断が当たれば便利ですが、外れたときに人が気づけない場面では、事故のもとになります。

だから私は、無人で回す工程ほど「明示的に呼び出したものだけが走る」状態に寄せます。検証もレビューも、必要なタイミングで自分で /verify・/code-review と叩く。そのほうが、いつ・何が走ったのかを後から追えます。

読者特典・無料ダウンロードClaude Codeを「素のまま」使うな無料でダウンロード →

明示呼び出しを前提にした工程設計

この変更を活かすには、「工程は自分で呼ぶもの」という前提で運用を組み直すのが近道です。私が無人ジョブで実践している考え方を、4つの制御軸に整理します。

制御軸	何を止めるか	効く場面
工程の明示呼び出し（v2.1.215）	頼んでいない検証・レビューの割り込み	決め打ちで工程を固定したい無人ジョブ
Web検索の回数上限	検索ループの暴走によるトークン浪費	調べ物が絡む長時間タスク
deny 設定	消す・送る・課金する等の危険操作	人が見ていない場での事故防止
--model 明示	意図しない高コストモデルの起動	定型ジョブのコスト固定

共通する思想は「AIに気を利かせてもらう範囲を、先に狭めておく」ことです。工程・検索回数・操作権限・モデルのどれも、放っておくと自動で膨らむ余地があります。無人で回すなら、膨らむ前に天井を決めておくほうが安全です。

無人ジョブでは「呼ぶ工程」を手順書に固定する

自動で走らなくなった工程は、裏を返せば「自分で書いておかないと二度と走らない」ということでもあります。ここを曖昧にすると、今度は「本当は検証したかったのに、誰も呼ばずに素通りした」という逆の事故が起きます。

私は無人ジョブを組むとき、次の順で工程を固定しています。

やる工程を先に列挙する — 「本文を書く→図解を作る→検証する→レビューする」のように、走らせたい工程を手順書に明示する。
呼び出しを手順に埋め込む — 検証やレビューが必要な工程なら、その場で /verify・/code-review を呼ぶことを手順に書く。AIの気配りに任せない。
やらない工程は書かない — 手順に無いものは走らない、という状態を既定にする。これで「頼んだ工程だけが走る」が保証される。

v2.1.215は、この「手順に書いたものだけが走る」運用と相性が良い変更です。ツールが勝手に工程を足さなくなったぶん、手順書がそのまま実行結果になる——無人運用の再現性は、この一致から生まれます。

対話しながら使うときはどうなるか

普段Claude Codeと対話しながらコードを書いている人にとっては、「検証やレビューが自動で挟まらなくなって不便では」と感じるかもしれません。

実際には、必要なタイミングで /verify や /code-review と打つだけなので、手間はほとんど増えません。むしろ「いま検証したい」「ここでレビューしたい」を自分で決められるぶん、余計な待ち時間やトークン消費が減ります。自動で気を利かせてもらうより、呼ぶ癖をつけるほうが、対話でも無人でも扱いやすくなります。