Claude Code権限セーフティラダー: 初心者がallowを広げる順番

Claude Codeを使い始めた人が悩むのは、どこまで自動実行を許すかです。全部askにすると遅く、全部allowにすると怖い。権限セーフティラダーは、read-only、検証コマンド、限定編集、deploy確認の順に広げるための実務ルールです。

人気の権限記事を読んだ読者は、抽象論ではなく自分のsettingsに落とせる順番を探しています。ここでは、最初の一週間で広げてもよい範囲と、最後までdenyに残す範囲を分けます。

関連して読む記事: claude-code-permissions-guide, claude-code-security-best-practices, claude-code-harness-lite-workflow.

なぜ最初にこの型を作るのか

Claude Codeは、作業の境界が明確なときに一番強くなります。よい境界は、読んでよいファイル、編集してよいファイル、実行してはいけない操作、作業を終える証拠を名前で示します。この境界がないと、初心者向けの小さな依頼でも大きな書き換えになり、コンテンツ変更が無料PDF、Gumroad、導入相談の導線を静かに壊すことがあります。

この型は収益作業にも効きます。技術的な証拠と読者側の証拠を同じチェックに入れるからです。ローカルでbuildできても、違う読者を違う商品へ送っているページは未完成です。scope、command、public URL、CTAを残す運用なら、明日も記憶ではなく記録から改善できます。

実務で使うワークフロー

1. Level 0はRead、Glob、Grepだけをallowにする
2. Level 1でgit status、git diff、buildなど証拠コマンドを追加する
3. Level 2でcontentやtestsなど限定パスのWrite/Editをaskにする
4. Level 3でdeployは自動実行ではなく確認付きにする
5. secrets、force push、削除系、課金系はdenyか人間承認に残す

場面	安全な進め方	確認方法
個人ブログ	MDX記事と画像の編集はask、buildはallow、deployは確認付きにします。CTAリンク確認もproofに入れます。	build, diff, URL
SaaS管理画面	UIコンポーネントとテストは限定編集、auth、billing、migrationは最後まで承認制にします。	screenshot, test
チーム運用	CLAUDE.mdに権限レベルを書き、レビュー時にどのレベルで作業したかを残します。	log, command, handoff

最初の確認は短くします。監査が作るべきものは巨大なレポートではなく判断です。20分後も判断が曖昧なら、編集を始めるのではなく、追加で読むべき1ファイルを決めます。

そのまま使えるプロンプトとコード

このリポジトリのClaude Code権限を4段階に分けて提案してください。read-only、proof commands、limited edits、deploy checksを分け、denyに残す操作も列挙してください。

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)",
      "Bash(npm.cmd run build)",
      "Bash(git status --short)",
      "Bash(git diff --stat)"
    ],
    "ask": [
      "Write(site/src/content/**)",
      "Edit(site/src/content/**)",
      "Bash(npm install *)",
      "Bash(npx wrangler pages deploy *)"
    ],
    "deny": [
      "Bash(git push --force*)",
      "Bash(rm -rf*)",
      "Read(.env*)"
    ]
  }
}

このコードはわざと小さくしています。運用上の考えを、scopeがあるか、保護領域があるか、少なくとも1つの検証コマンドがあるかという確認可能な形に変えるためです。記事公開、アプリ開発、デバッグ、チーム引き継ぎに合わせて形を変えられます。

3つの実例

個人ブログ

MDX記事と画像の編集はask、buildはallow、deployは確認付きにします。CTAリンク確認もproofに入れます。

大事なのは証拠です。1つのコマンド、1つの表示ページ、または読者に届いたことを示す1つのメモを残します。

SaaS管理画面

UIコンポーネントとテストは限定編集、auth、billing、migrationは最後まで承認制にします。

大事なのは証拠です。1つのコマンド、1つの表示ページ、または読者に届いたことを示す1つのメモを残します。

チーム運用

CLAUDE.mdに権限レベルを書き、レビュー時にどのレベルで作業したかを残します。

大事なのは証拠です。1つのコマンド、1つの表示ページ、または読者に届いたことを示す1つのメモを残します。

よくある失敗例

• 便利さを理由にdeployやpushまでallowすると、検証前に公開されます。
• 逆に全操作をaskにすると、毎回判断が必要で運用が続きません。
• denyを書かない設定は、危険操作を曖昧に残します。

もう1つの見落としは多言語のずれです。英語版では正しい商品導線を説明していても、別言語では古いCTAが残ることがあります。だから公開確認では frontmatter の lang だけでなく、h1、本文冒頭、CTAの言語まで見ます。

無料PDF、Gumroad、導入相談へのつなぎ方

基本操作を手元に置きたい場合は 無料チートシート から始めてください。設定、権限、CLAUDE.md、CI/CD まで整えたい読者には Setup Guide が合います。レビュー、デバッグ、リファクタリングの入力を毎回考えている読者には 50 Prompt Templates を勧めます。チーム展開や収益導線まで含む設計が必要なら 導入相談 に進むのが自然です。商品一覧を比較したい場合は products も確認できます。

すべての読者をいきなり有料商品へ送る必要はありません。初心者には摩擦の低いPDFが合います。同じプロンプトを繰り返す中級者はテンプレートに近く、権限、CLAUDE.md、hooks、MCP、CI/CDで止まる読者はSetup Guideに近い。チームや運用設計の相談は導入相談に近いです。

公開前後に見る検証ポイント

この記事では、h1、本文冒頭、heroImage、内部リンク、Gumroadリンク、相談導線が同じ意図でつながるかを確認対象にします。HTTP 200 だけでは完了にせず、読者が次の行動を選べる状態かを見ます。

多言語公開では、日本語、英語、中国語、韓国語、スペイン語、フランス語、ドイツ語、ポルトガル語、ヒンディー語、インドネシア語を別々に確認します。slugが一致しても本文が古い場合があります。モバイル幅のスクリーンショットなら、冒頭本文とCTAを同時に見られるため発見が早くなります。

次に見るべき数字

次に見る数字は、このslugのPDF開始、Gumroadクリック、products訪問、training訪問、検索流入、国別比率、記事からCTAへのクリック率です。PVが増えてもGumroadクリックが増えないなら商品対応を強めます。技術記事から相談訪問が増えるなら、読者は一般チュートリアルではなくワークフロー設計を求めています。公開後の改善では、記事単体の順位だけを見ず、どの段落のあとに読者が商品導線へ進んだかを見ます。無料PDFで止まるなら初心者向けの説明を厚くし、Gumroadで止まるなら商品名ではなく解決できる作業を具体化します。相談ページまで進んで離脱するなら、誰向けの相談か、何を持ち帰れるか、英語商品との関係をさらに明確にします。特に多言語記事では、英語版のGumroad商品が主軸であることを隠さず、読者が英語教材へ進む理由を本文中で説明します。日本語読者には、無料PDFで操作を試し、Setup Guideで設定を固め、必要なら相談で自分の運用に落とすという順番を明示します。この順番があると、広告的な押し売りではなく、次の作業を選ぶ案内になります。最後に、公開後のスクリーンショットで冒頭とCTA付近を見直し、本文の約束とボタンの行き先がずれていないことを確認します。これで記事はPVだけでなく次の行動まで評価できます。