Claude Codeの/runコマンドでアプリを動かして変更を確認する
/runは実際にアプリを起動して変更を確認するバンドルスキルです。起動方法の推測が外れる場面と、/run-skill-generatorが記録したプロジェクト固有のレシピを優先する設計を扱います。
Claude Codeの/runは何をするコマンドか
/runは、テストの通過だけに頼らず、実際にプロジェクトのアプリを起動して変更が動いていることを確認するバンドルスキルです。公式ドキュメントは「Launch and drive your app to see a change working, not only passing tests(テストの通過だけでなく、実際にアプリを起動して操作し、変更が動いていることを確認する)」と説明しています。コードを読んで正しさを判断するのではなく、動かして見るという一段階を、コマンド1つで挟み込む工程です。
/runはClaude Codeが持つ「バンドルスキル」の1つです。バンドルスキルは、Claudeに詳細な手順を渡してツールの使い方をClaude自身に組み立てさせる、プロンプトベースの仕組みです。/renameや/resumeのようにあらかじめ決まった処理をそのまま実行する組み込みコマンドとは性質が異なり、プロジェクトの構成を見てその場でやり方を判断します。利用にはClaude Code v2.1.145以降が必要で、バージョンはclaude --versionまたは/statusコマンドで確認できます。
/runの使い方
セッション内でスラッシュコマンドとして呼び出すだけです。
/run引数は不要です。呼び出すとClaude Codeはプロジェクトの種類(CLI・サーバー・TUI・ブラウザー駆動)を判定します。READMEやpackage.json、Makefileの記述から起動方法を推測して、実際にアプリを起動する仕組みです。事前のセットアップは要りません。
この「セットアップ不要」の推測は、標準的な起動で完結するプロジェクトでは高い確率でうまくいきます。しかしデータベース接続・環境変数ファイル・グラフィカルなセッション・複数段階のビルドのように、標準の起動を超える要素が絡むプロジェクトでは、推測が不安定になります。ここで効いてくるのが、次に説明するプロジェクト固有のレシピです。
推測が不安定な場面ではプロジェクト固有のskillを先に探す
/runは呼び出されるたびに、プロジェクトの構成から起動方法を推測し直すわけではありません。プロジェクト固有に記録済みのレシピが.claude/skills/run-<name>/にあれば、/runはまずそれに従います。推測はレシピが無いときの代替手段という位置付けです。
このレシピを作るのが/run-skill-generatorです。クリーンな環境からアプリを実際に起動し、うまくいったインストールコマンド・環境変数・起動スクリプトを記録します。それをプロジェクト固有のskillとして.claude/skills/run-<name>/にコミットする仕組みです。一度記録すれば、以降は/runだけでなく/verifyや、リポジトリ内で動く他のエージェントも、この記録済みレシピに従うようになります。プロジェクトごとに1回実行し、ビルドや起動の手順が変わったときは再実行します。
/run-skill-generatorデータベース接続や環境変数ファイル、複数段階のビルドが必要なプロジェクトほど、/runを最初に呼ぶ前に/run-skill-generatorを1回通しておく価値があります。推測に頼る運用から、記録済みレシピに従う運用に切り替わり、/runの成功率が安定します。/run-skill-generator自体にもv2.1.145以降が必要です。
クリーンな環境から記録するという設計にも理由があります。普段作業しているマシンには、過去に手動で入れた依存関係や設定済みの環境変数が残っていることが珍しくありません。そういう状態からレシピを作ると、他の開発者のマシンやCI環境では欠けている前提を、レシピの側が見落とします。/run-skill-generatorがクリーンな環境からの起動を出発点にするのは、あなたの手元でだけ動く隠れた前提を洗い出し、誰の環境でも再現できる手順に落とし込むためです。
利用形態によって恩恵は変わる
/runが効くかどうかは、変更の種類によって差があります。
| 変更の種類 | 恩恵 | 理由 |
|---|---|---|
| UIの見た目・レイアウトの変更 | 恩恵明確な恩恵あり | 理由実際に起動して目視しないと確認できない |
| CLIの出力・エラーメッセージの文言変更 | 恩恵明確な恩恵あり | 理由起動して実行結果を見るのが最短の確認方法 |
| APIのレスポンス内容・ステータスコードの変更 | 恩恵明確な恩恵あり | 理由テストでカバーしていない組み合わせも実行で拾える |
| 型チェックだけで十分な静的な変更 | 恩恵ほぼ影響なし | 理由起動を伴わない確認の方が速い |
| データベースや複数段階ビルドが絡む複雑な環境 | 恩恵条件次第 | 理由事前に/run-skill-generatorでレシピを記録しておくと安定する |
/verify・/run-skill-generatorとの役割分担
3つのバンドルスキルは連携して動きますが、確認する内容と記録の仕方が異なります。
| スキル | 目的 | レシピの記録 |
|---|---|---|
/run | 目的変更が動いていることを実際に起動して確認する | レシピの記録記録しない(/run-skill-generatorが記録したものに従うだけ) |
/verify | 目的テストや型チェックに頼らず、ビルド・起動・観察でコード変更の正しさを確認する | レシピの記録v2.1.200以降、記録済みレシピが無いときに自分で.claude/skills/verify/SKILL.mdへ記録する |
/run-skill-generator | 目的クリーンな環境からの起動手順をプロジェクト固有のskillとして記録する | レシピの記録記録すること自体が役割 |
ここが/runと/verifyの実務上の違いです。/verifyはレシピが無ければ自分で記録を残しますが、/runは自分では記録せず、/run-skill-generatorが作ったレシピに従うだけの立場です。/verifyの自己記録・レシピの安定化の経緯はClaude Code verifyコマンドとは何かで詳しく扱っています。
「動いていることを見る」ことに主眼がある/runに対して、「コード変更が意図通りかどうか」の確認に主眼があるのが/verifyです。似た起動処理を共有しつつ、目的の力点が違うと考えると使い分けやすくなります。
使うタイミングの目安
/runが向くのは、コードを読むだけでは判断しづらい、実際の挙動を目視したい場面です。
- UIの見た目やレイアウトが変わる変更を加えたとき
- CLIツールの出力やエラーメッセージの文言を変えたとき
- APIのレスポンス内容やステータスコードを変えたとき
- 「テストは通っているはずだが、実際に起動して確認したい」と感じる変更をしたとき
逆に、内部ロジックだけを変更してテストが十分にカバーしている場合や、静的な型エラーの有無を知りたいだけの場合は、/runより型チェックやテスト実行の方が早く済みます。
コード変更 → /runで実際に動かして目視確認 → 問題なければ/verifyでビルド・起動・観察の一連を確認、という順で組み込む使い方もできます。両方とも同じ起動推測とレシピの仕組みを共有しているため、/runで一度動作を確認した直後に/verifyを呼んでも、起動そのものは同じ手順を踏むだけで二度手間にはなりません。
テストの代わりにはならない
/runの説明文にある「not only passing tests(テストの通過だけでなく)」という言い回しが示すとおり、/runはテストを不要にするものではありません。単体テストや型チェックは、決まった入力に対する期待どおりの出力を機械的に検証する手段です。/runはそれとは別の軸で、実際に起動して操作した結果を人(またはClaude自身)が観察する手段を追加します。テストが通っていても見た目が崩れている、CLIの出力が想定と違う、といった実行時にしか分からない不具合は、テストだけでは拾いきれません。/runはその隙間を埋める補完的な役割で、既存のテストスイートを置き換えるものではありません。
無効化と個別の非表示設定
組織やプロジェクトの都合で/runを使わせたくない場面もあります。バンドルスキル全体を止めるにはsettings.jsonのdisableBundledSkillsを有効にします。/runだけを個別に隠したい場合はskillOverridesで"run": "off"と設定します。値は"on"・"name-only"・"user-invocable-only"・"off"の4種類があり、個別制御にはv2.1.129以降が必要です。環境変数CLAUDE_CODE_DISABLE_BUNDLED_SKILLS=1でも、disableBundledSkillsと同じ効果でバンドルスキル全体を止められます。組織の管理設定でこれが有効になっている場合、手元では/runを呼び出せない状態になっている可能性があります。
よくあるつまずき
- 標準的な起動を超えるプロジェクトで推測が外れる: データベース接続や環境変数、複数段階のビルドが必要な場合は、
/run-skill-generatorを先に実行してレシピを記録すると解消しやすくなります /runがレシピを自分で更新してくれると思い込む:/run自体はレシピを記録しません。起動手順を変えたら/run-skill-generatorを再実行する必要があります/verifyと役割を混同する:/runは動いていることを見る手段、/verifyはコード変更の正しさを確認する手段です。同じ起動処理を経由しますが目的が違います
よくある質問
/runにオプションはありますか
/runは引数なしで呼び出すコマンドで、公式ドキュメントに個別のオプションの記載はありません。起動方法の判定はプロジェクトの構成(READMEやpackage.json、Makefile)、または/run-skill-generatorが記録したレシピから自動的に決まります。
/runと/verifyはどう使い分けますか
決まった順序はありません。実際に起動して動きを見たいだけなら/run、コード変更が意図通りかを確認したいなら/verifyを使います。どちらも同じ起動推測・記録済みレシピの仕組みを共有しているため、/run-skill-generatorでレシピを1回記録しておけば両方の成功率が上がります。
/run-skill-generatorはどのくらいの頻度で実行しますか
プロジェクトごとに1回で足ります。ビルドや起動の手順(依存関係の追加、環境変数の変更、起動スクリプトの変更など)が変わったときだけ再実行します。
/runはClaudeが自分の判断で呼び出すこともありますか
/verifyと/code-reviewはv2.1.215で、Claudeが自分の判断で自動実行することがなくなり、明示的に呼び出す専用になりました。この変更の対象は/verifyと/code-reviewの2つに限られており、/run自体はこのバージョンの変更対象に含まれていません。バンドルスキル全般について、公式ドキュメントは「関連性があればClaudeが自動で呼び出すこともある」としているため、/runの呼び出しタイミングを厳密に制御したい場合は、/verifyと同様に個別の無効化設定を検討する余地があります。
モノレポでも.claude/skills/run-<name>/は使えますか
公式ドキュメントはモノレポでの/run固有のパス分岐を明記していません。/verifyの自己記録はモノレポで変更したパッケージ配下に書かれる仕様があるため、/run-skill-generatorのレシピ配置もプロジェクト構成によって挙動が変わる可能性があります。実際の配置はリポジトリで/run-skill-generatorを実行して確認するのが確実です。
まとめ
/runは、テストの通過だけに頼らず実際にアプリを起動して変更を確認するバンドルスキルです。README・package.json・Makefileから起動方法を推測しますが、データベース接続や複数段階のビルドが絡むプロジェクトでは推測が不安定になります。/run-skill-generatorで一度レシピを記録しておけば、/runはそれに従うだけになり、/verifyや他のエージェントも同じレシピを使い回せます。/run自身はレシピを記録しない点が、自己記録機能を持つ/verifyとの実務上の違いです。呼び出し方はどちらもシンプルですが、この記録の有無を知っているかどうかで、日々の確認作業の安定度が変わってきます。