/verify（ヴェリファイ）

Claudeの「直しました」という返事を鵜呑みにせず、本当に直ったか自分の目で確かめたい人向け

Claudeにコードを直してもらった後、「直しました」という返事だけを信じて画面を閉じる。これ、けっこう怖いです。テストが緑でも、実際にアプリを動かすと狙った通りに直っていないことは普通にあります。/verify は、その「本当に直ったの?」を、テストや型チェックの結果に逃げずに、アプリを実際に組み立てて走らせて確かめる同梱スキルです。

料理ブログサイトのレシピ並び順を直したつもりでも、ブラウザで開いたら順番が変わっていない、みたいなズレ。そこを潰すための合否確認だと思ってください。

噛み砕くと

新しい職場で書類の修正を頼んで、戻ってきた書類に「直しました」と付箋が貼ってある状態を想像してください。付箋を信じてそのまま提出するか、自分の目で中身を開いて確認するか。/verify は後者です。

しかも「チェックリストに丸が付いてるからOK」では済ませません。実物を動かして、目で結果を見る。それがこのスキルの立ち位置です。

公式の説明文がそのまま核を言い当てています。

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 の性格を決めています。

大事な前提：これは「動かして見る」コマンドなので、走らせられるアプリが要る

/verify はコードを読むだけでは終わりません。アプリを組み立てて実際に走らせます。なので、走らせる対象が成立していることが土台になります。料理ブログなら、ブラウザで開けるサイトとして動く状態ですね。

嬉しいのは、事前のお膳立てが基本いらないことです。公式はこう書いています。

/run and /verify work without setup. They infer the launch from your project type ... and from what's in your README, package.json, or Makefile.

訳すと「/run と /verify は準備なしで動く。プロジェクトの種類や、README・package.json・Makefile の中身から起動方法を推測する」という意味です。

つまりフォルダの中身を見て「これはこう起動するやつだな」とClaude側が当てにいきます。料理ブログがよくある作りなら、それだけで走り出します。

「料理ブログ」を例に、実際の手順を見る

世界の魚を紹介する料理ブログサイトを作っているとします。トップページのレシピが「登録が古い順」で並んでいて、これを「新しい順」に直したい。Claudeに修正を頼んだ後、/verify で本当に直ったかを確かめる流れを追います。

ステップ1: まず修正を頼む

レシピの並び順を新しい順に変えてほしい、と普通に頼みます。Claudeがコードを書き換えて「並び替えのコードを新しい順に直しました」と返してきます。

トップページのレシピを、登録が新しい順に並べ替えて

ここで「直しました」を鵜呑みにして終わると、後で泣きます。

ステップ2: /verify を叩く

修正の直後に、コマンドだけを打ちます。後ろに何も書き足しません。

/verify

ここで初心者がやりがちな勘違いがひとつ。/verify の後ろにテストファイル名を書いて「テストを回すコマンド」だと思ってしまうことです。逆です。このスキルはテストに頼らず、アプリそのものを動かして確かめにいきます。

ステップ3: Claudeがアプリを組み立てて走らせる

Claudeは料理ブログのフォルダを見て起動方法を推測し、サイトを組み立てて走らせます。READMEや設定ファイルに「こう起動する」と書いてあれば、それをなぞります。

ステップ4: 結果を観察する

走らせたサイトのトップページを実際に見て、レシピが新しい順に並んでいるかを目で確かめます。型チェックが通ったから、ではなく、現物の並びを見て判断するのがポイントです。

ステップ5: ズレがあれば、そこで初めて気づける

仮に「コードは直したのに、画面では古い順のまま」だったとします。テストだけ見ていたら見逃すズレです。実走させているからこそ、ここで食い違いが表に出ます。

ステップ6: 直し直して、もう一度確かめる

ズレが見つかったら直して、また /verify。狙い通りに並ぶまでこのループを回します。「画面で新しい順になっている」を自分の目で確認できて、ようやく完了です。

つまり /verify は何をしてくれるのか

• やってくれる: アプリを組み立てて実際に走らせ、変更が狙い通りかを現物の動きで確認する。テストや型チェックの合否に逃げない
• やってくれない: テストを回して合否レポートを出すこと。それは /verify の役目ではありません（むしろ真逆の発想）
• 意味が薄い場面: 走らせるアプリがそもそも成立していない段階。組み立てて走らせる対象がないと、確認のしようがありません

使いどころ3シナリオ（具体題材で再現）

シナリオ1: 料理ブログの検索ボックスを直した直後

「魚の名前で検索しても結果が出ない」を直してもらったとします。コードを直してもらっても、実際に「サバ」と打って一覧が出るかは、走らせて打ってみないと分かりません。/verify で組み立てて走らせれば、検索が本当に効いているかを現物で確かめられます。型チェックが緑でも検索結果がゼロ、というのは普通にあるズレです。

シナリオ2: 家計簿アプリの合計金額がズレていたのを直したとき

支出の合計がなぜか1件分多く計算されていた、という不具合を直したとします。テストが古いままだと「直したつもりが直っていない」を見逃します。/verify で実際にアプリを動かして、適当な支出を3件入れて合計が正しく出るかを目で見る。数字のズレは実走で見るのが一番確実です。

シナリオ3: 「テストは全部緑なのに、なんか不安」なとき

テストが全部通っていても、肝心の画面の見え方や挙動までは保証されません。料理ブログのレシピ詳細ページで、写真が表示される直しを入れた後、テスト緑でも実際に写真が出ているかは別問題です。テストの緑だけでは安心しきれないとき、/verify で現物を走らせて目視で詰める。緑と現実の隙間を埋めるのがこのスキルです。

初心者が踏みやすい落とし穴

• テストを回すコマンドだと思い込む。真逆です。/verify はテストや型チェックに頼らず、アプリを実走させて確かめるスキルです。公式が "rather than relying on tests or type checks" と明記しています
• テストが緑だから /verify は不要だと考える。テスト緑でも実画面のズレは残ります。そこを実走で潰すのがこのスキルの存在意義です
• /run と完全に同じだと思う。温度差があります。/run は起動して動かして「変更が効いているのを見る」観察寄り、/verify は組み立てて走らせて「狙い通りか確認する」合否確認寄りです
• 事前に設定をいろいろ用意しないと動かないと思う。基本は準備なしで動きます。READMEや設定ファイルから起動方法を推測してくれます
• どんなプロジェクトでも推測が必ず当たると思う。データベースが要る、設定ファイルが要る、画面付きの実行環境が要る、組み立てが何段階もある、この4つのどれかに当てはまると推測が外れやすくなります
• 推測が外れたとき、毎回手で起動方法を教え直す。その場合は /run-skill-generator を1回走らせると、起動レシピをプロジェクトごとに記録してくれて、以後 /verify もそのレシピをなぞります
• 古いバージョンで叩いて反応しない。この3つのスキルは Claude Code v2.1.145 以降が必要です。動かないときはまずバージョンを確認してください

書き方

/verify

やってみるとこうなる

入力

/verify

出力例

Claudeがプロジェクトの種類やREADME・設定ファイルから起動方法を推測し、アプリを組み立てて走らせ、変更が狙い通りに働いているかを実走結果で確認する。テストや型チェックの合否には頼らない（実行中の具体的な対話や画面表示は環境による）

関連項目

• /run（ラン）
• /run-skill-generator（ランスキルジェネレーター）
• Skills（スキルズ）
• /debug（デバッグ）

公式ドキュメント

https://code.claude.com/docs/en/skills#run-and-verify-your-app