Claude Codeの/runコマンドでアプリを動かして変更を確認する

Claude Codeの/runは何をするコマンドか

/runは、テストの通過だけに頼らず、実際にプロジェクトのアプリを起動して変更が動いていることを確認するバンドルスキルです。公式ドキュメントの説明は「Launch and drive your app to see a change working, not only passing tests(テストの通過だけでなく、実際にアプリを起動して操作し、変更が動いていることを確認する)」。コードを読んで正しさを判断する代わりに、動かして見る一段階を、コマンド1つで挟み込みます。

Claude Codeのバンドルスキルは、詳細な手順をClaudeに渡し、ツールの使い方をClaude自身に組み立てさせるプロンプトベースの仕組みです。/initのようにCLI内に処理が書き込まれた組み込みコマンドと違い、プロジェクトの構成を見てその場でやり方を決めます。

呼び出しは引数なしです。

/run

事前のセットアップは要りません。Claude Codeはプロジェクトの種類(CLI・サーバー・TUI・ブラウザー駆動)と、READMEやpackage.json、Makefileの記述から起動方法を推測します。Streamlit製アプリならstreamlit runの起動を拾えます。作り方はClaude CodeでStreamlitアプリを作る手順にあります。

起動に失敗するとき: 推測を記録済みレシピに置き換える

推測が当たるのは、標準的な起動で完結するプロジェクトです。データベース、環境変数ファイル、グラフィカルなセッション、複数段階のビルドのどれかが絡むと、公式ドキュメントも「推測が当てにならなくなる」としています。/runを呼んでも起動で止まる場合は、原因はコードでなく起動手順の推測側にあります。

対処が/run-skill-generatorです。手順は次の流れになります。

/run-skill-generator

「クリーンな環境から」という条件は、手元のマシンにだけ残っている前提を洗い出すためのものです。過去に手動で入れた依存関係や設定済みの環境変数が残った状態でレシピを作ると、他の開発者やCIでは欠けている前提を見落としかねません。

どんな変更で効くか

効き方は変更の種類で分かれます。段階は編集上の目安で、公式の分類ではありません。

内部ロジックだけの変更でテストが十分にカバーしているなら、/runより型チェックやテストのほうが早く済みます。逆に、テストが通っていても見た目が崩れる、CLIの出力が想定と違う、といった不具合は実行しないと見えません。/runはテストを置き換えるものではなく、テストが見ない軸を足すものです。

/runと/verifyの違いは「記録するのは誰か」

同じ起動の仕組みを使う2つのスキルですが、目的とレシピの扱いが違います。

/verifyが書いたレシピがリポジトリルートにあると、同梱の/verifyはその記録に置き換わります。書き換えは、コマンドが失敗した・手順が欠けていたなど、実行が誤った方向に進んだときに限られます。v2.1.205より前は、実行で学んだことを何でも書き足す指示だったため、マージ衝突が頻発していました。詳しい経緯はClaude Code verifyコマンドとは何かで扱っています。

名前が衝突した場合の扱いも公式に書かれています。同じ名前のskillをプロジェクトや個人の場所に置くと、同梱のコマンドを置き換えます。/run-skill-generatorが作るrun-<name>はrunとは別の名前なので、/runを置き換えるものではありません。置き換えは別名までは及ばず、たとえばプロジェクトのcode-reviewskillは/code-reviewを置き換えても、同梱の別名/reviewはそのスキルを実行しません。

/runを止めたい・隠したいとき

組織やプロジェクトの都合で/runを使わせたくないときは、範囲の広さで手段が分かれます。

組織の管理設定でdisableBundledSkillsが有効なら、手元でも/runは呼べません。/doctorのように、disableBundledSkillsが有効でも打てるコマンドもあります(v2.1.205以降)が、/runはこの例外に含まれていません。

skillOverridesの値は"on"・"name-only"・"user-invocable-only"・"off"の4種で、v2.1.129で設定として機能するようになりました。"user-invocable-only"は、モデルからは隠すが自分では打てる状態を指します。公式がバンドルスキルで明記している値は"off"だけで、/runに"user-invocable-only"が効くかどうかは確かめられていません。

v2.1.285のclaude --helpで確認した無効化の出力

手元のv2.1.285で、モデルを呼ばないコマンドだけを実行して確かめました。

claude --version
claude --help | grep -A1 -E "disable-slash|safe-mode"

出力は次のとおりです。

2.1.285 (Claude Code)
  --disable-slash-commands              Disable all skills
--
  --safe-mode                           Start with all customizations
                                        (CLAUDE.md, skills, installed plugins,

--disable-slash-commandsのヘルプは「Disable all skills」の1行で、公式のCLIリファレンスは「skills and commands for this session」とさらに広く書いています。/runだけを狙うフラグではなく、skillとコマンドをまとめて止める手段です。

--safe-modeはCLAUDE.md・skill・プラグイン・hooksなどのカスタマイズ全部を無効にして起動します。/runが想定どおり動かないとき、原因がプロジェクト側のskillやhooksにあるかを切り分ける用途に使えます。

--bareは、ヘルプに「Skills still resolve via /skill-name」とあります。一方、CLIリファレンスではhooks・skill・カスタムコマンドの自動探索を飛ばす最小構成と説明され、--add-dirで渡したディレクトリのskillだけが読み込まれます。プロジェクトの.claude/skills/にあるレシピは自動では拾われない可能性があるため、切り分けには--safe-modeのほうが向きます。

なお/run自体はモデルを呼ぶスキルなので、この確認では起動していません。

Claudeが自分で/runを呼ぶことはあるか

/verifyと/code-reviewは、v2.1.215で「Claudeが自分の判断で実行しない、明示的に呼ぶ専用」になりました。公式のコマンド一覧が手動専用と明記しているのは/verifyで、変更履歴には/code-reviewも並んでいます。ただし/code-reviewはその後の版でClaudeが再び自分で起動できるようになり、v2.1.246で全環境に広がりました。/runはどちらにも名前がありません。

一方、スキルのページには「Claudeが関連性のあるときに自動で呼ぶバンドルスキルもあれば、/verifyのように自分で呼んだときだけ動くものもある」という趣旨の説明があります。/runがどちらかは公式の記述からは断定できないので、Claudeに呼ばせたくない場合は、前節のskillOverridesで明示的に隠す手があります。

まとめ

/runはセットアップ不要で使えますが、起動で止まるプロジェクトでは/run-skill-generatorで一度レシピを固定するほうが早道です。記録する側は/run-skill-generatorと/verifyで、/runが自分で記録するという記述は公式に無く、読む側として扱うのが安全です。止めたいときは、範囲に応じて設定・環境変数・起動フラグを使い分けます。