Claude Code verifyコマンドとは何か — 検証範囲といつ使うか

/verifyはClaude Codeのバンドルスキルの1つで、テストや型チェックに頼らず実際にアプリをビルド・起動してコード変更が意図通り動くかを確認するコマンドです。本稿では、/verifyが具体的に何を検証するか、/run・/run-skill-generatorとの役割分担、そしてv2.1.215で自動実行から明示呼び出しへ変わった経緯までを扱います。Claude Code全体の導入や権限設計はClaude Code(クロードコード)とはで解説しています。

テストや型チェックでは拾えないものを確認する

/verifyは公式ドキュメントで「Confirm a code change does what it should by building your project's app, running it, and observing the result, rather than relying on tests or type checks(テストや型チェックに頼らず、プロジェクトのアプリをビルド・起動して観察することで、コード変更が意図通り動くか確認する)」と定義されています。単体テストや型チェックが通っていても、実際に起動したときだけ表面化する不具合があります。/verifyはその隙間を埋めるためのコマンドです。

Claude Codeには/verifyを含めて3つの関連バンドルスキルがあります。/runは変更が動いていることを、テストの通過だけでなく実際に起動して確認するコマンドです。/verifyはビルド・起動・観察でコード変更の正しさを確認します。/run-skill-generatorは、クリーンな環境からのビルド・起動手順をプロジェクト固有のスキルとして記録するためのコマンドで、他の2つが推測に頼らず動くための土台を作ります。

3つはいずれもClaude Code v2.1.145以降が必要です。バージョンはclaude --versionまたは/statusコマンドで確認できます。

/verifyは「バンドルスキル」という枠組みに属します。バンドルスキルは、SKILL.mdで自分で書くスキルと同じ仕組みで動く、Claudeに渡されるプロンプトです。関連性があればClaudeが自動で呼び出すこともできます。つまり/verifyはClaude Code本体に組み込まれた特別なコマンドではなく、あらかじめ用意されたスキルの1つです。この枠組みが、後半の「v2.1.215で変わったこと」で扱う自動実行の話にも関わってきます。

/verifyは「セットアップ不要」で動く設計です。READMEやpackage.json、Makefileからプロジェクトの種類(CLI・サーバー・TUI・ブラウザー駆動)と起動方法を推測します。ただしデータベース接続や環境変数ファイル、複数段階のビルドが必要なプロジェクトでは、この推測が不安定になることがあります。

ビルド・起動・観察で何を見ているか

/verifyが行うのは「ビルドして、起動して、結果を観察する」という一連の動作確認です。ユニットテストやリンター、セキュリティスキャンの実行ではありません。設計思想としては、静的な検査(型チェック・テスト)をすり抜けてしまう、実行時にしか出ない不具合を拾うための手段です。

/verifyが検証しない範囲もあわせて押さえておくと過信を避けられます。

• コードの静的な正しさ(型の整合性・構文エラー)はテストや型チェックの領分で、/verifyは代替しません
• コードを読んで正しさのバグと整理余地を見つけるのは/code-review、セキュリティ上の懸念を見つけるのは/security-reviewの役割です
• データベース接続や外部APIなど、標準的な起動を超える依存関係が必要なプロジェクトでは起動方法の推測が外れることがあります

推測が外れた場合や、起動に固有の手順が必要な場合は、次に説明する「レシピの記録」で解決します。

起動手順をレシピとして残す

/verifyは記録済みの手順(レシピ)が無い状態でビルド・起動を行うと、うまくいった手順を.claude/skills/verify/SKILL.md(モノレポでは変更したパッケージ配下)に書き込みます。リポジトリのルートでは、この記録済みスキルがバンドル版/verifyの代わりに使われるようになります。この自己記録の挙動にはClaude Code v2.1.200以降が必要です。

記録ファイルの更新は、Claudeが実行を誤った方向に進めたとき(コマンドが失敗した、手順が抜けていた等)に限られます。v2.1.205より前は、実行のたびに学んだことを無条件で書き足す仕様だったため、頻繁なマージコンフリクトの原因になっていました。v2.1.205でこの挙動が修正され、記録済みの手順が実態と合わなくなったときだけ書き換わるようになっています(公式changelogでは「記録済みのコマンドが変わったとき」と表現されています)。

/run-skill-generatorを1回実行すると、インストールコマンドや環境変数、起動スクリプトを含む起動手順を.claude/skills/run-<name>/にプロジェクト固有のスキルとして記録できます。以後は/run・/verifyだけでなく他のエージェントも、この記録済みレシピに従います。ビルドや起動の手順を変えたときは、プロジェクトごとにもう一度/run-skill-generatorを実行します。/verifyが推測に失敗しやすいプロジェクトほど、先に/run-skill-generatorを回しておく価値があります。

呼び出し方とタイミングの目安

/verifyはClaude Codeのセッション内でスラッシュコマンドとして呼び出します。

/verify

引数は不要です。呼び出すとClaude Codeがプロジェクトの種類を判定し、記録済みレシピがあればそれに従ってビルド・起動し、無ければREADMEや設定ファイルから起動方法を推測してビルド・起動・観察を行います。

呼び出すタイミングの目安は、コード変更後に「テストは通っているが、実際に動かして確認したい」場面です。具体的には、マージ前の最終確認、UIやAPIレスポンスなど実行結果を目視したい変更、テストが薄い(またはまだ書かれていない)箇所の変更があった直後です。

無効化と個別の非表示設定

組織やプロジェクトの都合で/verifyを使わせたくない場面もあります。settings.jsonの設定項目で無効化・非表示にできます。

バンドルスキル全体を止めるには、設定のdisableBundledSkillsを有効にします。バンドルスキルとワークフローは丸ごと取り除かれ、/verifyも呼び出せなくなります。/initや/doctorのような組み込みコマンドは入力自体はできますが、Claudeからは見えなくなります(/doctorを隠すには環境変数DISABLE_DOCTOR_COMMANDを使います)。環境変数CLAUDE_CODE_DISABLE_BUNDLED_SKILLS=1でも同じ効果になります。組織の管理設定でこれが有効になっていると、手元では/verifyが動かない状態になります。

/verifyだけを個別に隠したい場合はskillOverridesを使います。"verify": "off"と設定すれば/verifyだけが呼び出し不可になり、他のバンドルスキルは残せます。値は"on"・"name-only"・"user-invocable-only"・"off"の4種類で、この個別制御にはv2.1.129以降が必要です。

v2.1.215で変わったこと — 自動実行から明示呼び出しへ

v2.1.215(2026年7月19日)で、/verifyと/code-reviewの呼び出し方が変わりました。公式changelogの記述は次のとおりです。

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が/verifyと/code-reviewのスキルを自分の判断で実行することはなくなり、使いたいときに/verifyまたは/code-reviewで明示的に呼び出す」形になりました。v2.1.215より前は、Claudeが必要だと判断すれば/verifyや/code-reviewを自律的に実行することがありました。

/verifyと/code-reviewは「実行に時間とトークンを要する長めのチェック」です。それをいつ実行するかをユーザー側の制御下に置くのが、今回の変更の意図です。他のバンドルスキルはこれまで通り、必要に応じてClaudeが自動で呼び出すことがあります。

自動実行に慣れていた運用では、「急に/verifyが走らなくなった」と感じることがあります。その場合は不具合ではなく、v2.1.215以降の仕様どおりの挙動です。検証が必要なタイミングで、自分で/verifyを呼び出す運用に切り替える必要があります。バージョンごとの他の変更点はClaude Code v2.1.215の詳細で確認できます。

v2.1.145からv2.1.215までの拡張の流れ

/verifyまわりの仕様は複数バージョンにまたがって整備されてきました。

v2.1.145からv2.1.215までのおよそ2か月で、「セットアップ不要な自動判定」から「明示的な呼び出しでユーザーが実行タイミングを制御する」方向へ調整されてきました。トークンと実行時間を要するチェックほど、Claude任せではなく呼び出し側の制御下に置く判断です。

/code-reviewとの役割分担を早見表で見る

どちらもv2.1.215で明示呼び出しに変わった長時間チェックですが、確認する対象が異なります。

/verifyはテストが通っていても残る問題を拾う補完で、/code-reviewはテストの有無にかかわらずコードの中身を評価します。両方を組み合わせることで、動作面と正しさの両方をカバーできます。片方だけを使い続けると、/verifyのみではコードを読まないと気づけない正しさの問題(エッジケース・退行)を見逃し、/code-reviewのみでは実行時にしか出ない不具合を見逃すことになります。他のスラッシュコマンドとの全体的な役割分担はClaude Codeスラッシュコマンド一覧にまとめています。

利用形態によって恩恵は変わる

利用形態によって/verifyの恩恵は変わります。

よくあるつまずき

• v2.1.215以降、放っておいても走らなくなった: 仕様どおりです。/verifyは明示的に呼び出す必要があります
• 起動方法の推測が外れる: データベース接続や環境変数、複数段階ビルドが必要なプロジェクトでは、README等からの推測が不安定になります。/run-skill-generatorを先に実行してレシピを記録すると解消しやすくなります
• 記録済みレシピが古いまま: v2.1.205以降、記録ファイルが更新されるのはClaudeが実行を誤った方向に進めたとき(コマンドが失敗した、手順が抜けていた等)だけです。起動手順自体を変えた場合は、記録ファイルが追従しているか確認します
• /verifyが単体テストの代わりになると誤解する: /verifyはテストに頼らない別軸の確認手段であって、テストを不要にするものではありません。テストと/verifyは補完関係にあります

よくある質問

/verifyはなぜテストの代わりになるのか

代わりになる、というより補完する関係です。公式ドキュメントは/verifyを「テストや型チェックに頼らず」動作を確認する手段と説明しています。テストや型チェックは静的な正しさを検証しますが、実際に起動して初めて分かる不具合(画面の表示崩れ、APIの応答内容など)は検出できません。/verifyはその領域を、実際にビルド・起動・観察することでカバーします。

/verifyと/runは何が違いますか

どちらも「実際に起動して確認する」という点では共通していますが、公式ドキュメントの説明文の力点が異なります。/runは「変更が動いていることを見る」ことに主眼があり、/verifyは「コード変更が意図通りかどうかを確認する」ことに主眼があります。/run-skill-generatorはこの2つが安定して動くための起動レシピを作る役割です。

レシピが更新されないのはなぜか

v2.1.205以降、記録ファイルが更新されるのはClaudeが実行を誤った方向に進めたとき(コマンドが失敗した、手順が抜けていた等)だけです。ビルド・起動が想定通りに進んでいる限り、記録ファイルは変更されません。これは不具合ではなく、頻繁なマージコンフリクトを避けるための仕様です。

v2.1.215より前でも/verifyは使えたか

/verify自体はv2.1.145以降で使えます。ただしv2.1.215より前のバージョンでは、ユーザーが呼び出さなくてもClaudeの判断で/verifyが実行されることがありました。v2.1.215以降は、呼び出し方自体は同じでも「使いたいときに自分で呼び出す」運用に一本化されています。

まとめ

/verifyは、テストや型チェックでは拾いきれない実行時の不具合を、実際にビルド・起動・観察することで確認するコマンドです。セットアップ不要の推測ベース設計にはv2.1.145以降、自己レシピ記録にはv2.1.200以降が必要で、v2.1.205でレシピ書き換えが安定化し、v2.1.215で自動実行から明示呼び出しへと変わりました。/verifyとタイプするだけで、記録済みレシピがあればそれに従い、無ければプロジェクトの構成から起動方法を推測して検証が走ります。/code-reviewとは確認する対象が異なります。両方を状況に応じて使い分ける運用が実務的です。