Claude Code の権限拒否から復旧する: 止まった理由を次の安全手順に変える

Claude Code がコマンドを拒否されたとき、失敗ではなく安全装置が働いたと考えるほうが実務では安定します。大事なのは、拒否をその場で許可に変えないことです。

この記事では、権限拒否を recovery prompt に変える手順を扱います。理由、代替手順、証拠、再試行条件を分ければ、止まった後も安全に進められます。

あわせて読む: claude-code-approval-sandbox-guide, claude-code-permission-audit-before-deploy, claude-code-security-best-practices. 公式の前提条件は Anthropic Claude Code getting started.

なぜ最初のコマンド前に必要か

このテーマの中心は 拒否理由を安全な次手順へ変えること です。Claude Code は速く動けますが、最初に渡す情報が広すぎると、重要ではない差分、古い仮説、収益に関係しない整形まで同じ重さで扱います。

権限設定を強くしたら Claude Code が止まって困った人 にとって大切なのは、作業を大きく見せることではありません。読むもの、触らないもの、最初に試すもの、失敗したときに戻る場所を短く決めることです。これは記事運用でもプロダクト開発でも同じです。

実務で使う手順

1. 拒否されたコマンドをそのまま記録する
2. なぜ危険だったかを人間向けの言葉に直す
3. 安全な代替手順を一つだけ選ぶ
4. build、diff、スクショなど証拠が揃ったら再試行する

この順番にすると、Claude Code への依頼が「自由に考えて」から「この範囲で証拠を残して」に変わります。作業の自由度は残しつつ、危ない場所だけを先に閉じられます。

場面	安全な進め方	確認する証拠
デプロイ	公開前に build と URL 確認を通してから wrangler を再試行する	build, diff, URL
ファイル削除	削除ではなく一覧と影響範囲の確認に戻す	build, diff, URL
外部 API	本番キーではなく dry-run とサンプル payload で確認する	build, diff, URL

この証拠があると、Claude Code の返答を雰囲気ではなく作業結果で判断できます。

コピペ用プロンプトとコード

この権限拒否を復旧手順に変えてください。拒否されたコマンド、拒否理由、安全な代替手順、必要な証拠、再試行してよい条件に分けてください。許可範囲はまだ広げないでください。

const denial = {
  command: "npx wrangler pages deploy site/dist",
  reason: "production deploy needs proof first",
  safeAlternative: "run build and verify local dist before retrying deploy",
  proof: ["ASTRO_TELEMETRY_DISABLED=1 npm.cmd run build", "git diff --stat"],
};

function recoveryPrompt(item) {
  return `The command was denied: ${item.command}\nReason: ${item.reason}\nDo instead: ${item.safeAlternative}\nProof required: ${item.proof.join(", ")}`;
}

console.log(recoveryPrompt(denial));

コードは小さなチェック用です。実際のプロジェクトでは、この出力をそのまま CLAUDE.md、issue、または handoff note に貼ると、次のセッションでも同じ判断を再利用できます。

実例と失敗例

場面	安全な進め方	確認する証拠
デプロイ	公開前に build と URL 確認を通してから wrangler を再試行する	build, diff, URL
ファイル削除	削除ではなく一覧と影響範囲の確認に戻す	build, diff, URL
外部 API	本番キーではなく dry-run とサンプル payload で確認する	build, diff, URL

• 拒否された直後に allow を広げると、権限設計の意味がなくなります。
• 理由を書かないと、次回も同じ拒否で止まります。
• 代替手順が複数あると、Claude Code がまた広い作業を選びがちです。

失敗例の共通点は、Claude Code の能力不足ではなく、入力の境界が薄いことです。境界が薄いと、AI は親切心で作業を広げます。収益導線がある記事では、無料 PDF、Gumroad、相談のどれへ送るかも境界の一部です。

実務で使うときは、さらに「誰が最後に確認するか」まで書いておくと安定します。拒否理由を安全な次手順へ変えること は、Claude Code だけのためのメモではありません。翌日見返す自分、レビューする同僚、相談を受ける相手にも、なぜその小さな作業を選んだのかを説明する記録です。特に記事や商品導線を触る場合は、文章の自然さだけでなく、読者がどの段階にいるかを残します。まだコマンドに慣れていない人には無料 PDF、実務で繰り返す人には Gumroad、チームや本番運用で迷う人には相談、という判断を書いておくと、CTA が感覚でぶれにくくなります。

もう一つのコツは、最初の完了条件を小さくすることです。大きな改善を一度に頼むと、Claude Code は親切に範囲を広げます。最初は一つの slug、一つの component、一つの command に絞り、build とスクリーンショットまで見てから次へ進みます。これだけで、作業速度を落とさずに事故の戻し時間を減らせます。

最後のレビューでは、差分の量よりも「読者が次に何をするか」を見ます。タイトルと h1 が検索意図に合っているか、本文冒頭で約束した作業がコード例まで続いているか、CTA が無料 PDF、Gumroad、相談の順に無理なく並んでいるかを確認します。ここで商品リンクだけ強くすると、初心者は離脱します。逆に無料 PDF だけだと、実務で困っている読者を次の教材や相談へ送れません。小さな記事改善でも、読者段階、証拠、次の行動を同時に見ることが収益導線の基本です。公開後のスクリーンショットでは、h1 だけでなく本文冒頭と CTA 付近を同時に見ます。翻訳済みの見出しに英語本文が残っていないか、ボタンがスマホ幅で折り返しても読めるか、Gumroad と相談リンクが別の記事意図にずれていないかまで確認して完了です。数字を見る日を決めておくと、次回の改善が感覚ではなく、PDF 登録、教材クリック、相談導線のどこが弱いかから始められます。迷ったら、読者が今日すぐ実行できる一手と、明日買う理由が自然につながっているかを基準にします。この小さな基準が、毎日の改善を売上に近づけます。継続して見ます。

無料PDF・Gumroad・相談へのつなぎ方

まだ基本コマンドが曖昧なら 無料チートシート で毎日の型を固めます。設定、権限、CLAUDE.md、MCP、CI まで整える段階なら Setup Guide が次の有料ステップです。レビュー、デバッグ、リファクタリングの依頼文を毎回考えているなら 50 Prompt Templates が合います。チーム導入や収益導線まで含めて設計したい場合は 導入相談 に進み、教材比較は products で確認できます。

記事本文の CTA は最後に一つだけ置けばよいわけではありません。導入部では無料 PDF、実装例の後では Gumroad 教材、チームや本番運用の話では相談というように、読者の不安が強くなった場所で次の選択肢を出すほうが自然です。

公開後に見る数字

次は permissions 系記事から Setup Guide と相談ページへの移動を見ます。

公開後は PV だけでなく、本文冒頭の読了、内部リンククリック、無料 PDF 登録、Gumroad クリック、相談ページ移動を分けて見ます。HTTP 200 だけでは成功ではありません。h1、canonical、heroImage、CTA、本文の言語がそろって、読者が次の行動を選べる状態まで確認します。