Claude Codeに作らせた変更を、実際の画面で動かして確かめたい人向け
Claudeに変更を入れてもらってテストは通ったけれど、本当に画面で直っているか分からない場面で叩く。/run と打つとClaudeがアプリを立ち上げて動かし、テストの中だけでなく走っているアプリそのもので変更が効いているかを確かめてくれる
Claude Codeに料理ブログの修正を頼んで、テストが全部通ったと返ってきた。でも本当に画面で直っているのかは、まだ誰も見ていません。/run はそのギャップを埋める同梱スキルです。プロジェクトのアプリを実際に立ち上げて動かし、加えた変更が「動いているアプリ」で効いているのを目で確かめます。
公式は役割をはっきり言い切っています。/run は「変更が動いているのを見るためにアプリを起動して動かす」もの。テストの中だけで満足せず、走っているアプリで見る。ここが眼目です。使うにはClaude Code v2.1.145以降が必要です。
噛み砕くと
料理を作ったあと、レシピ通りに手順を踏めたかチェックするのがテストだとすると、/run は実際に一口食べて味を確かめる工程です。手順が合っていても、塩を入れ忘れていたら食べれば分かる。テストが緑でも画面が崩れていることはあります。だから走らせて見る。
もう一つの特徴は、固定の処理をそのまま実行する組み込みコマンドと違って、/run は「同梱スキル」だという点です。Claudeが指示書を読みながら、自分の道具を使って起動の段取りを組み立てて進めます。決まった1本道を流すのではなく、その場のプロジェクトに合わせて動く。
大事な前提：このコマンドは「動かせるアプリがあるプロジェクト」で叩く
公式によると、/run は事前の準備なしで動きます。プロジェクトの種類（コマンドで動かす道具・サーバー・文字だけの画面アプリ・ブラウザで動かすもの）と、README・package.json・Makefile の中身から起動方法を推測するからです。
逆に言うと、推測が当たる前提があってこそ。料理ブログがいつものやり方で立ち上がるなら、そのまま叩けます。
「料理ブログ」を例に、実際の手順を見る
世界の魚を紹介する料理ブログを作っていて、トップページに新着レシピの一覧を出す改修をClaudeに頼んだとします。テストは通った。でも本当に一覧が表示されているかは別の話。ここで /run の出番です。
ステップ1: まず変更をClaudeに入れてもらう
「トップに新着レシピ3件を出して」と頼み、Claudeがコードを書き換えます。この時点では、まだ画面では確認していません。
ステップ2: テストが緑でも、そこで止めない
Claudeが「テスト通りました」と返してきます。よくあるのはここで終わらせてしまうパターン。でも一覧のレイアウトが崩れていたり、3件のはずが2件しか出ていなかったり、テストでは拾えないズレが残ります。
ステップ3: /run と打つ
コマンドの後ろには何も足しません。これだけです。
/runステップ4: Claudeが起動方法を推測する
料理ブログのREADMEやpackage.jsonを読んで、Claudeが「このプロジェクトはこう立ち上げる」と判断し、アプリを起動します。設定を自分で書く必要はありません。
ステップ5: 走っているアプリで変更を見る
Claudeがアプリを動かし、トップページの新着レシピ一覧が実際に出ているかを確かめます。テストの緑ランプではなく、動いている画面そのもので確認する。これが /run の核心です。
ステップ6: ここで初心者がやりがちな勘違い
「/run はテストを回すコマンドでしょ」と思いがちですが、逆です。公式の言葉では「テストの中だけでなく（not just in tests）」走っているアプリで見る、が眼目。テスト実行コマンドではありません。
つまり /run は何をしてくれるのか
- やってくれる: アプリを起動して動かし、加えた変更が走っているアプリで効いているのを確かめる
- やってくれない: テストや型チェックを回して合否を出すこと。それはテスト実行の役割で、
/runの仕事ではない - 意味が薄い場面: そもそも起動できる形になっていないプロジェクトや、いつものやり方では立ち上がらない（後述の特殊条件がある）プロジェクト
使いどころ3シナリオ（具体題材で再現）
シナリオ1: 料理ブログの見た目を直したとき
魚の写真が縦長で崩れていたのを「横幅に合わせて」と直してもらった場面。レイアウトの崩れはテストでは拾いきれません。/run でアプリを立ち上げ、写真がちゃんと収まっているかを画面で見る。見た目の修正こそ走らせて確かめる価値があります。
シナリオ2: 家計簿アプリに新しいボタンを足したとき
「支出を追加」ボタンを置いてもらったあと、押したら本当に1件増えるのか。コードが書けていることとボタンが効くことは別です。/run で動かし、実際にクリックして増えるところまで見届けます。
シナリオ3: clone直後のプロジェクトで初動を見たいとき
GitHubから持ってきたプロジェクトを自分のパソコンにコピーした直後、まず「これは動くのか」を知りたい場面。/run はREADMEやpackage.jsonから起動方法を推測して立ち上げてくれるので、手探りで起動コマンドを探さずに済みます。ただし特殊な準備が要るプロジェクトでは推測が外れます（次の落とし穴へ）。
初心者が踏みやすい落とし穴
- テストを回すコマンドだと思う。逆です。テストでなく走っているアプリで見るのが眼目で、公式も「not just in tests」と明言しています。
- 事前に設定が要ると思って身構える。不要です。READMEやpackage.json、Makefileの中身から起動方法を推測してくれます。
- どんなプロジェクトでも当たると思う。標準の立ち上げを超える条件があると推測は外れます。具体的にはデータベースが要る・設定ファイルが要る・画面付きの実行環境が要る・組み立てが多段になる場合です。
- 推測が外れたまま叩き続ける。そういうプロジェクトは
/run-skill-generatorで起動レシピを一度記録すれば、以後/runはそのレシピをなぞって安定して立ち上げます。 - /verify と同じだと思う。役割が違います。
/runは起動して動かして見る（観察寄り）、/verifyは組み立てて起動して変更が狙い通りかを確認する（合否判定寄り）。どちらもv2.1.145以降の同梱スキルです。 - 古いバージョンで叩いて反応しない。Claude Code v2.1.145以降が必要です。動かないときはバージョンを確認してください。
- コマンドの後ろに何か足そうとする。
/runはそのまま叩くだけ。後ろに対象を書き足す使い方ではありません。
書き方
/runやってみるとこうなる
入力
/run出力例
Claudeがプロジェクトの種類とREADMEやpackage.jsonの中身から起動方法を推測してアプリを立ち上げ、加えた変更が走っているアプリで効いているかを確かめる（実行時の具体的な対話や画面出力は公式に記載がないため省略）このページに出てきた言葉
- 同梱スキル
- Claude Codeに最初から入っている、Claudeが指示書を読みながら道具を使って進めるタイプのコマンド。固定の処理を直接実行する組み込みコマンドとは別もの
- サーバー
- ブラウザでアクセスすると画面を返してくれる、裏で動き続けるプログラム。料理ブログのようなサイトはこの形が多い
- README
- プロジェクトの説明や起動手順を書いた案内ファイル。Claudeはここを読んで起動方法を推測する
- データベース
- レシピやユーザー情報などのデータをまとめて保存しておく入れ物。これが要るアプリは起動時に追加の準備がいる
- 起動レシピ
- そのプロジェクトを立ち上げる手順をまとめて記録したもの。<code>/run-skill-generator</code> が作り、以後 <code>/run</code> がなぞる
関連項目
公式ドキュメント
https://code.claude.com/docs/en/skills#run-and-verify-your-app